[192981] in North American Network Operators' Group
Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was:
daemon@ATHENA.MIT.EDU (Alexandru Suciu via NANOG)
Wed Dec 7 12:31:14 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <CAAAas8H3XFvT0dEiBqS5JUcHzdGRdsb7kFF-Msog5ovr7vKjPQ@mail.gmail.com>
Date: Wed, 7 Dec 2016 12:19:02 +0000
To: Mike Jones <mike@mikejones.in>
From: Alexandru Suciu via NANOG <nanog@nanog.org>
Reply-To: Alexandru Suciu <asuciu@arista.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
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.
On Tue, Dec 6, 2016 at 12:50 PM, Mike Jones <mike@mikejones.in> wrote:
> > 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?
>
> I was under the impression that this bug was mainly caused by some
> optimistic attempt to detect raw IPv4 or IPv6 payloads by checking for
> a version at the start of the frame. This does not explain why it
> would be looking at the 5th octet.
>
> I also would assume that there must be something else to the last 2
> examples beyond just the B or F and 4 or 6 because otherwise it would
> match way too many addresses to have not been noticed before. Perhaps
> the full MAC address looks like some other protocol with a 4 byte
> header?
>
> Thanks,
> Mike
>
--
Regards,
Alexandru Suciu
