Dear Alexandru,
MACs that didnt make it through the switch when running 4.12.3.1:
4*:**:**:**:**:** 6*:**:**:**:**:** *4:**:**:**:**:** *6:**:**:**:**:** **:**:*B:**:6*:** **:**:*F:**:4*:**
Can anyone explain the last 2 for me?
On Wed, Dec 07, 2016 at 12:19:02PM +0000, Alexandru Suciu via NANOG wrote:
The root cause for that issue is most likely due to the following bug:
BUG65077 : On the DCS-7150 series, the MPLS label of a frame may be incorrectly overwritten by a DSCP field update in the ASIC. Fixed in 4.11.7 , 4.12.6 , 4.13.0 .
It was not related on the MAC values but rather the incorrect parsing of the MPLS header.
That seems phrased somewhat strange. To me as end user it really does seem related to the MAC values, the NLNOG folk tested: packets destined to MAC address 4*:**:**:**:**:** do not arrive, on the other hand, same packet destined to 3*:**:**:**:**:** does arrive. Keep in mind that in this scenario the 7150 is a layer-2 switch between two MPLS PE routers. The 7150 is used as a layer-2 bridge, NOT as MPLS Label Switching Router. Packet layout probably was something like this: outer Ethernet header Dest MAC A Source MAC B Type: 0x8847 MPLS Header 1 or 2 labels inner Ethernet header Dest MAC C Source MAC D Type: 0x0800 IP src X dst Y ICMP type: request The bug in 4.12.3.1 was triggered if "MAC C" started with a 4 or a 6, but I'd expect that anything below the "outer Ethernet header" (including the MPLS header) is considered just the payload by the switch. Kind regards, Job