[suggestion] Make it possible to control flooding behaviour individually per VNI

[Tore Anderson]

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.