Hoi Pim, I assume it's just because the flooding is implemented via L2INPUT_FEAT that is applied only on ingress :) I agree with you that egress flooding on non-flood interface makes little sense (and we even have a separate knob to disable it in our custom fork).
On Tue, 17 Feb 2026 at 18:07, Pim van Pelt via lists.fd.io <pim= [email protected]> wrote: > Hoi, > > I have a question about 'l2 flood' on egress versus ingress. Assume the > following topolgy: > > vpp0, bridge-doain 100 vpp1, > bridge-domain 100 > GigabitEthernet10/0/0 SHG 0 > GigabitEthernet10/0/0 SHG 0 > vxlan_tunnel0 SHG 1, L2 Learn disable < v4 > vxlan_tunnel0 > SHG 1, L2 Learn disable > vxlan_tunnel1 SHG 1, L2 Learn+*Flood disable* < v6 > vxlan_tunnel1 > SHG 1, L2 Learn+*Flood disable* > > > Some BUM packet (eg ARP or IP6 neighbor discovery) comes in on vpp0 > Gi10/0/0 > - src MAC gets learned on Gi10/0/0, this is fine (learning is on) > - gets flooded to vxlan_tunnel0 (ipv4 packet A), this is fine (flooding is > on) > *- gets flooded to vxlan_tunnel1 (ipv6 packet B), I find this questionable > (flooding is off)* > > BUM now comes in on vpp1 twice > - ipv4 packet gets accepted and flooded, this is fine (flooding is on) > - ipv6 packet gets dropped, this is fine (flooding is off) > > Looking at the packet trace on vpp0: > 17:00:06:603931: l2-learn > l2-learn: sw_if_index 3 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > bd_index 3 > 17:00:06:603932: l2-flood > l2-flood: sw_if_index 3 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > bd_index 3 > l2-flood: sw_if_index 3 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > bd_index 3 > 17:00:06:603934: l2-output > * l2-output: sw_if_index 14 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > data 86 dd 60 07 03 49 00 40 3a 01 fe 80 * > l2-output: sw_if_index 15 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > data 86 dd 60 07 03 49 00 40 3a 01 fe 80 > 17:00:06:611511: vxlan6-encap > VXLAN encap to vxlan_tunnel1 vni 20040 (Packet B) > 17:00:06:611513: vxlan4-encap > VXLAN encap to vxlan_tunnel0 vni 20040 (Packet A) > > I am wondering, if "L2 Flooding" is off, should we be sending the packet > to sw_if_index 14 (the one with flooding disabled)? > No real harm is done, because on the remote side, on vpp1, the second > packet is dropped: > Packet A: > 23:39:08:908750: vxlan4-input > VXLAN decap from vxlan_tunnel0 vni 20040 next 1 error 0 > 23:39:08:908752: l2-input > l2-input: sw_if_index 13 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > [l2-flood ] > 23:39:08:908753: l2-flood > l2-flood: sw_if_index 13 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > bd_index 2 > 23:39:08:908761: l2-output > l2-output: sw_if_index 4 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 > data 86 dd 60 07 03 49 00 40 3a 01 fe 80 > > Packet B: > 23:39:08:908748: vxlan6-input > VXLAN decap from vxlan_tunnel1 vni 20040 next 1 error 0 > 23:39:08:908752: l2-input > l2-input: sw_if_index 14 dst 33:33:00:00:00:01 src 52:54:00:f0:10:03 [] > 23:39:08:908753: feature-bitmap-drop > feat_bitmap_drop: feature bitmap 0x00000001 > 23:39:08:908755: error-drop > rx:vxlan_tunnel2 > 23:39:08:908762: drop > feature-bitmap-drop: L2 feature forwarding disabled > > We correctly drop the packet and refuse to flood on vpp1, end to end it > works, although two packets are sent. I think it may be better to drop the > packets before sending them, if the interface is marked as not FLOOD. This > fix itself is quite simple, but can somebody think of a reason to flood > *egress* on L2 interfaces with the FLOOD bit disabled ? > > groet, > Pim > > -- > Pim van Pelt <[email protected]> <[email protected]> > PBVP1-RIPE https://ipng.ch/ > > > > > -- Best regards Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26821): https://lists.fd.io/g/vpp-dev/message/26821 Mute This Topic: https://lists.fd.io/mt/117860165/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
