All, I just want to come back on behalf of Cisco on this. We just investigated this issue and the issue is not an ASIC bug, but a flag set wrong by SW. We will reach out to the original customer through TAC who posted this in NSP to resolve this issue. sukumar On 12/2/16, 11:50 AM, "NANOG on behalf of Job Snijders" <nanog-bounces@nanog.org on behalf of job@instituut.net> wrote: On Fri, Dec 02, 2016 at 09:32:37AM -0800, Leo Bicknell wrote: > I also do not think this is an IEEE/MAC assignement problem. This is a > vendor's box can't forward a particular payload problem. On Fri, Dec 02, 2016 at 04:59:37PM +0000, Nick Hilliard wrote: > Job Snijders wrote: > > Dear IEEE, please pause assigning MAC addresses that start with a 4 > > or a 6 for the next 6 years. > > Disagree that this is an IEEE problem. This is problem that vendors > need to work around. There is limited MAC space, and deprecating 1/8 of > it due to the inability of vendors to cope properly with it seems like a > really bad long term idea. Yes the vendors are doing a poor job. I also appreciate the argument that IEEE just manages that number space and we should consider these 'just numbers' and the vendors need to make do. On the other hand if IEEE had just stuck to the original allocation plan, you and I wouldn't be dealing with this garbage situation. IEEE told one of my friends: "We changed our allocation methods to prevent vendors using unregistered mac addresses." Does the cost of some squatters on poorly usable MAC space outweight the cost of the community spending countless hours tracking down where those dropped packets went? IEEE could've shown more restrain by (temporary, until IPv4 is dead?) avoiding 4 and 6 and still accomplished some of their goal (if this dubious strategy even is effective). I consider this a cascading failure. Clearly IEEE's change had a ripple effect, and suprised a number of implementers, and ended up hurting us. Kind regards, Job