EVPN ESI BUM Forwarding

Crist Clark cjc+nanog at pumpky.net
Thu Nov 17 21:16:01 UTC 2022


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.

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.

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.

I want to understand how this should be working to maybe understand what’s
not working here and how to fix it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221117/9a99b2a9/attachment.html>


More information about the NANOG mailing list