You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
northd: Drop post-NF flood copies causing MAC flaps.
A Network Function (NF) in inline mode redirects matched traffic
through a service VM. When the redirected traffic is IP
unknown-unicast (destination MAC not yet in the FDB), the packet
coming back from the NF is re-flooded by the switch, because the
destination MAC is still unknown. That re-flood produces a copy on
the same port the packet originally arrived on, causing MAC flaps and
potential L2 loops.
Following are the example packet flows.
Example 1, VLAN switch (MAC flap):
Topology
VM1, VM2 and the NF are on the same logical switch (LS), which is
VLAN-backed (localnet port on every node). VM1 is on N1, VM2 on
N2 (its port has "unknown" in addresses and a to-lport ACL that
redirects to the inline NF on N3).
Flow
1. VM1 sends pkt to dst MAC X (not in FDB).
2. The LS floods the pkt; on N1 the copy exits the localnet port
and the TOR floods it to N2.
3. On N2 the pkt ingresses on localnet; the LS floods it and the
copy reaches VM2 (unknown-addr).
4. The ACL redirects the pkt to the NF on N3; the NF returns it
to N2.
5. X is still not in the FDB, so the LS floods again; on N2 one
copy exits the localnet port.
Result
The TOR now sees VM1's source MAC on N2's port, but it had just
learned VM1's MAC on N1's port, so the MAC flaps on the TOR.
Example 2, VLAN switch with two protected VMs (loop):
Topology
As above, plus VM3 (on N3, same LS) also has "unknown" in
addresses and is also NF-protected.
Flow
1-5 as above; in parallel, the original flood also reaches N3 via
the TOR, where it is redirected to N3's NF, returns, and the
LS re-floods it out N3's localnet port.
6. N3's re-flood reaches N2 via the TOR; the LS floods it on N2,
the copy hits VM2 (unknown-addr), is redirected to the NF, and
re-floods out N2's localnet port.
7. That re-flood reaches N3 via the TOR; the LS floods it on N3,
the copy hits VM3 (also unknown-addr), is redirected to the
NF, re-floods out localnet, ...
Result
The pkt keeps bouncing between N2 and N3 via the TOR, i.e. an
L2 loop, on top of continuous MAC flaps. The loop persists as
long as X stays unknown.
Example 3, overlay switch (copy reflected to inport):
Topology
VM1, VM2 and the NF are on the same LS and all on N1. VM1 and
VM2 both have "unknown" in addresses; VM2's to-lport ACL
redirects to the inline NF.
Flow
1. VM1 sends pkt to dst MAC X (not in FDB).
2. The LS floods to MC_UNKNOWN members on N1; one copy goes to
VM2.
3. VM2's ACL redirects its copy to the NF; the NF returns it to
N1.
4. X is still not in the FDB, so the LS floods to MC_UNKNOWN
again; one copy is headed back out VM1's own port.
Result
VM1 receives a copy of the packet it just sent (reflected to the
inport).
Fix:
Use the nf_learn_orig_inport() / nf_lookup_orig_inport() actions
from the previous commit to remember the original ingress port and
drop the copy if it is about to be sent back out of that port.
- In the NF redirect stage (ls_in_nf for a from-lport ACL,
ls_out_nf for a to-lport ACL), existing priority-99 redirect
flows are updated to learn the original ingress port
(nf_learn_orig_inport()) before redirecting unicast IP packets
to the NF.
- Priority 50 (overlay switches only, in ls_in_nf): learn on
the inport's ingress node when the ACL did not redirect
the packet (REGBIT_NF_ENABLED == 0), so the learn stays
co-located with the lookup even when the redirecting port and
the inport live on different nodes. VLAN-backed switches
do not need this: the post-NF packet is always sent back to
the inport's node.
- On the post-NF return path, run
REGBIT_NF_LOOKUP_HIT = nf_lookup_orig_inport() on both NF ports.
A priority-115 flow in ls_out_pre_acl runs the lookup on
input_port and skips already-traversed egress stages. A
priority-2 flow in ls_out_nf runs the lookup on output_port for
packets redirected from the ingress pipeline (for example, a
from-lport request that is re-flooded after NF processing and
re-enters egress).
- A new priority-110 flow in ls_out_check_port_sec drops packets
with REGBIT_NF_LOOKUP_HIT == 1, i.e. the copies about to be
sent back out of the port they originally arrived on.
All new flows are gated on the switch having an inline NF group on
an ACL.
Acked-by: Aditya Mehakare <aditya.mehakare@nutanix.com>
Fixes: 8e2d6fa ("northd, tests: Network Function insertion logical flow programming.")
CC: Sragdhara Datta Chaudhuri <sragdha.chaudhu@nutanix.com>
Assisted-by: Claude Opus 4.7, Cursor
Signed-off-by: Naveen Yerramneni <naveen.yerramneni@nutanix.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
0 commit comments