Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)
job at instituut.net
Wed Dec 7 19:46:15 UTC 2016
> > > MACs that didnt make it through the switch when running 188.8.131.52:
> > >
> > > 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
1 or 2 labels
inner Ethernet header
Dest MAC C
Source MAC D
The bug in 184.108.40.206 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
More information about the NANOG