Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

Job Snijders job at
Wed Dec 7 19:46:15 UTC 2016

Dear Alexandru,

> > > MACs that didnt make it through the switch when running
> > >
> > >     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
        src X
        dst Y
        type: request

The bug in 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

Kind regards,


More information about the NANOG mailing list