Heya James, We still have a TAC case open with Cisco, they seem to be scratching their heads as to why this is happening, the usual rigmarole, but did provide 2x bug id's which seems to relate -- CSCvs91974 & CSCvk45012. Right now we've seen the issue mainly affected by some of our customers using mac-based forwarding techniques used by vendors, with Citrix being our main pain at the moment. We're connecting up a couple of Fortigates to the NCSs soon as well, perhaps i'll disable LLDP just to be safe, thanks on that.
For the most part, Cisco and XR BU seems to be interested in resolving it, though they want explanations as to why our customers need to use mac-based forwarding in their solutions.. I'll reply once i have some concrete info from them..... On Tue, Dec 21, 2021 at 6:26 PM James Bensley <[email protected]> wrote: > > Hi Drikus, > > Did you ever resolve this? > > We saw issues with MAC addresses on NCS55K too, but not related to EVPN. > > For example, one can use the commands 'interface foo; mac xxxx.xxxx.xxxx" to > set a custom MAC on a physical interface, XR commits the config but on these > Broadcom chips it doesn't actually do anything. CLI output shows the custom > MAC but a packet capture shows the BIA. > > We had another issue with the MAC address of CDP/LLDP frames addresses on > bundle interface (I can't remember the exact details right now, but I think > the source MAC address of these frames sometimes had the logical bundle MAC > and sometimes had the member link MAC, and it was inconsistent). > > So it seems these chips have issues with MAC address consistency. I'm > wondering if there is some relation to what you are seeing. > > Cheers, > James. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
