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 <[email protected]> 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 > >
