Re: EVPN ESI BUM Forwarding

[Crist Clark <cjc+nanog () pumpky net>]

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