Thanks for the response. It really doesn't bear directly on my situation, but it does have references to what I need in RFC 8365. Now that I know the terminology for these features, "Split Horizon" and "Local Bias" (neither of which seems to fit very well to me), it's easier to find more info. I understand the approach outlined in RFC 8365. Makes it look more like something is not working right in our implementation. I did some definitive packet captures showing that BUM traffic is going in the non-designated member of the ESI and looping back out of the designated forwarder. Not all BUM traffic is looped, just a small fraction. I want to investigate next if the events have something to do with MAC address tables or some other timers. The switches doing it are two Arista 7050SX3 with a single instance VXLAN EVPN. It should be a pretty simple setup. Not aware of any knobs to modify any of this behavior or what we could be missing. On Thu, Nov 17, 2022 at 1:30 PM Tarko Tikan <tarko@lanparty.ee> wrote:
hey,
"The EVPN split-horizon procedure ensures that the BUM traffic originated by the multi-homed PE and sent from the non-DF to the DF, is not replicated back to the CE (echoed packets on the CE). To avoid these echoed packets, the non-DF (PE1) sends all the BUM packets to the DF (PE2) with an indication of the source Ethernet-Segment. That indication is the ESI Label (ESI2 in the example), previously signaled by PE2 in the AD per-ESI route for the Ethernet-Segment. When PE2 receives an EVPN packet (after the EVPN label lookup), the PE2 finds the ESI label that identifies its local Ethernet-Segment ESI2. The BUM packet is replicated to other local CEs but not to the ESI2 SAP."
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-split-horizon
-- tarko