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