My google-fu and attempts to dig through all of the standards is failing me. I am trying to understand the mechanism to prevent an ESI designated forwarder from looping BUM traffic.<div dir="auto"><br></div><div dir="auto">The scenario I am imagining is BUM traffic coming into the fabric on an ESI link on a non-designated member of the ESI. It still needs to replicate the traffic to all of the VTEPs in the instance, including the other ESI members. Other non-designated members obviously don’t send the BUM traffic out the associated ESI ports, but how does the designated one know not to? It could lookup the source Ethernet address, but MACs move and if it’s new, there’s a race with the BGP NLRI getting there and getting processed before the encapsulated traffic.</div><div dir="auto"><br></div><div dir="auto">We’ve been seeing what looks exactly like this not working. A switch with a port channel to two leaf switches complains MAC addresses flapping between where they really are and the port channel. Doesn’t seem like some endpoint out in the fabric doing it because it’s across a whole bunch of VLANs, and it goes away if we shut down one of the port channel links, leaving only one up.</div><div dir="auto"><br></div><div dir="auto">I want to understand how this should be working to maybe understand what’s not working here and how to fix it.</div>