Open zzachattack2 opened 8 months ago
Can anyone address this? If EVPN-MH support in FRR is incomplete, that is understandable. What is not understandable is FRR pretending it is complete in the documentation. The documentation should ideally be prefaced that EVPN-MH in FRR is only partially complete, and that cumulus or another system is necessary for full functionality. But at the very minimum the following paragraphs should removed from the documentation, given that the statements are completely false.
"BUM traffic is rxed via the overlay by all PEs attached to a server but only the DF can forward the de-capsulated traffic to the access port. To accommodate that non-DF filters are installed in the dataplane to drop the traffic.
Similarly traffic received from ES peers via the overlay cannot be forwarded to the server. This is split-horizon-filtering with local bias."
Description
In my EVPN-MH setup, split horizon filters are not being implemented at the DF -- BUM traffic that is received on a shared segment at the non-DF will flood to the DF and be forwarded back down the shared segment.
Version
How to reproduce
Configured topology derived in part from the EVPN-MH topotests.
Topology:
Network config
FRR Config:
Network state:
BUM Traffic received at R2 (non-DF) is flooded to R1 (DF), and then forwarded back down the shared segment:
Expected behavior
Split-horizon filters should prevent traffic flooded from the non-DF VTEP on a shared segment from being forwarded back down the shared segment at the DF VTEP. The codebase indicates the SPH filters are implemented in the data-plane, but it is unclear to me how exactly they are implemented. Are the filters supposed to work with the kernel as the data-plane?
Actual behavior
BUM Traffic received at R2 (non-DF) is flooded to R1 (DF), and then forwarded back down the shared segment:
Additional context
Seems related to discussion towards end of https://github.com/FRRouting/frr/discussions/11487
Checklist