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
