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