[suggestion] Make it possible to control flooding behaviour individually per VNI
toreanderson opened this issue · comments
Description
FRR provides an undocumented knob to control flooding of BUM traffic in EVPN environments, configurable like so
router bgp 1
address-family l2vpn evpn
! disable BUM flooding
flooding disable
! enable BUM flooding (default)
flooding head-end-replication
This works as expected, but it is unfortunately an all-or-nothing approach, which disables/enables flooding for all configured VNIs.
Since different VNIs might have different use cases, it might be desirable to disable flooding for some, but not all, VNIs.
In our particular use case we would like to disable flooding for all "external" provider networks in our OpenStack installation, because on these all the MAC addresses and IP addresses are known in advance and so the FDB/neigh tables can be pre-provisioned. With those in place and and neighbour suppression enabled, it is known that all traffic between VTEPs will be known unicast, so flooding can be safely disabled.
However we also at the same time need to support "internal" provider networks, where customers are in control. Therefore we cannot pre-provision neigh tables, meaning we at the very least need ARP to work betweeen VTEPs. That in turn means we cannot disable flooding on those VNIs.
Version
FRRouting 9.1 (xps13) on Linux(6.8.9-300.fc40.x86_64).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
'--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--runstatedir=/run' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sbindir=/usr/libexec/frr' '--sysconfdir=/etc/frr' '--libdir=/usr/lib64/frr' '--libexecdir=/usr/libexec/frr' '--localstatedir=/run/frr' '--enable-multipath=64' '--enable-vtysh=yes' '--disable-ospfclient' '--disable-ospfapi' '--enable-snmp=agentx' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-rtadv' '--disable-exampledir' '--enable-systemd=yes' '--enable-static=no' '--disable-ldpd' '--disable-babeld' '--with-moduledir=/usr/lib64/frr/modules' '--with-crypto=openssl' '--enable-fpm' '--enable-grpc' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' 'CC=gcc' 'CXX=g++' 'LT_SYS_LIBRARY_PATH=/usr/lib64:'
How to reproduce
xps13(config)# router bgp 50
xps13(config-router)# address-family l2vpn evpn
xps13(config-router-af)# vni 1234
xps13(config-router-af-vni)# flooding disable
Expected behavior
(I interpret «Expected» as «Desired» here...)
BUM flooding gets disabled for VNI 1234 only.
Actual behavior
Flooding is disabled for all L2VNIs (including unrelated VNI 123 in output below), as the flooding disable
setting is actually inserted outside of the vni 1234
context, resulting in the following configuration:
xps13(config-router-af)# do show running-config bgp
Building configuration...
Current configuration:
!
frr version 9.1
frr defaults traditional
hostname xps13
!
router bgp 50
!
address-family l2vpn evpn
advertise-all-vni
vni 1234
exit-vni
vni 123
exit-vni
flooding disable
exit-address-family
exit
!
end
Additional context
It might well be possible to work around this limitation by selectively suppressing the advertisement of (and/or receipt of) type-3 inclusive multicast routes.
Checklist
- I have searched the open issues for this bug.
- I have not included sensitive information in this report.