This series fixes a MAC flap / L2 loop scenario triggered by inline
Network Functions (NFs) when the destination MAC of a redirected IP
packet is not yet known to the FDB.
Problem
=======
An inline NF redirects matched traffic through a service VM. When
the NF returns an unknown-unicast IP packet, the switch re-floods it
(the destination MAC is still unknown), producing a copy on the port
the packet originally arrived on:
- VLAN switch: the copy egresses the shared localnet port again,
so the TOR sees the source MAC move between chassis -> MAC flap.
With multiple NF-protected unknown-addr VMs the copy keeps
bouncing between chassis via the TOR -> underlay L2 loop.
- Overlay switch: the copy is reflected back to the source port,
i.e. the source VM receives the packet it just sent.
Fix
===
Remember the original input port keyed by (datapath, src_ip, dst_ip)
before sending the packet to the NF. On overlay switches the redirect
can run on a different node than the source port, so also do this
learn at ingress on every MC_UNKNOWN-member port; that places the
learn on the source-port node.
On the post-NF return path, look up the same key on both NF ports;
if the recorded input port equals the current outport, drop the copy
in ls_out_check_port_sec.
Naveen Yerramneni (2):
actions: Add nf_learn/nf_lookup_orig_src_port actions.
northd: Drop post-NF flood copies causing MAC flaps.
NEWS | 3 +
controller/lflow.h | 1 +
include/ovn/actions.h | 15 ++
include/ovn/logical-fields.h | 16 ++
lib/actions.c | 190 +++++++++++++++++
lib/logical-fields.c | 5 +
lib/ovn-util.c | 2 +-
northd/northd.c | 263 ++++++++++++++++++-----
northd/northd.h | 19 ++
ovn-sb.xml | 65 ++++++
tests/ovn-macros.at | 1 +
tests/ovn-northd.at | 393 +++++++++++++++++++++++++++++------
tests/ovn.at | 135 +++++++++++-
utilities/ovn-trace.c | 15 ++
14 files changed, 1004 insertions(+), 119 deletions(-)
--
2.43.5
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
