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

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


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



More information about the NANOG mailing list