Hi Dumitru,
Have updated TODO.rst as you suggested.
Thanks,
Sragdhara
From: Dumitru Ceara <dce...@redhat.com>
Date: Tuesday, August 26, 2025 at 3:22 PM
To: Sragdhara Datta Chaudhuri <sragdha.chau...@nutanix.com>,
ovs-dev@openvswitch.org <ovs-dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH OVN v8 4/5] controller, tests: Network Function
insertion tunneling of cross-host VLAN traffic.
!-------------------------------------------------------------------|
CAUTION: External Email
|-------------------------------------------------------------------!
On 8/25/25 5:52 AM, Sragdhara Datta Chaudhuri wrote:
> For overlay subnets, all cross-host traffic exchanges are tunneled. For VLAN
> subnets, we need to selectively tunnel traffic sent to or coming from the NF
> ports. Consider a from-lport ACL applied to port p1 on host1. The NF ports
> nfp1
> and nfp2 are on host2. A new option in LSP allows the NF ports to be linked.
> The “network-function-linked-port” in nfp1 is to be set to nfp2 and vice
> versa.
> The ingress pipeline on host1 sets the outport to nfp1 and the packet is then
> processed by table REMOTE_OUTPUT.
>
> On host1
> --------
> REMOTE_OUTPUT (table 43):
> It tunnels traffic destined to all non-local overlay ports to their associated
> hosts. The Same rule is now also added for traffic to non-local NF ports. Thus
> the packets from p1 get tunneled to host 2.
>
> Upon reaching host2
> -------------------
> PHY_TO_LOG (table 0):
> Existing priority 100 rule: for each geneve tunnel interface on the chassis,
> copy info from header to inport, outport, metadata registers. Now same rule
> also stores the tun intf id in a register (reg5[16..31]).
>
> CHECK_LOOPBACK (table 46)
> This table has a rule that clears all the registers. The change is to skip the
> clearing of reg5[16..31].
>
> Logical egress pipeline:
> ls_out_stateful priority 120: If the outport is NF port, copy reg5[16..31]
> (table0 had set it) to ct_label.tun_if_id.
>
> LOCAL_OUTPUT (table 45)
> When the packet comes out of the other NF port (nfp2), following two rules
> send
> it back to the host that it originally came from:
> Priority 110: For each NF port local to this host, following rule processes
> the
> packet through CT of linked port:
> match: inport==nfp2 && RECIRC_BIT==0
> action: RECIRC_BIT = 1, ct(zone=nfp1’s zone, table=LOCAL), resubmit table 43
>
> Priority 109: For each local {tunnel_id, nf port}, send the recirculated
> packet
> using tun_if_id in ct zone:
> match: inport==nfp1 && RECIRC_BIT==1 && && ct_label.tun_if_id==<tun-id>
> action: tunnel packet using tun-id
>
> Case where NF responds back on nfp1, instead of forwarding to nfp2
> ------------------------------------------------------------------
> For example, a SYN packet from p1 got redirected to nfp1. Then the NF, which
> is
> a firewall VM, drops the SYN and sends RST back on port nfp1. In this case,
> looking up in linked port (nfp2) ct zone will not give anything. The following
> rule uses ct.inv to identify such scenario and uses nfp1’s CT zone to send the
> packet back. To achieve this, following 2 rules are installed:
>
> in_network_function:
> Priority 100 rule that allows packets incoming from NF type ports, is enhanced
> with additional action to store the tun_if_id from ct_label into reg5[16..31].
>
> LOCAL_OUTPUT (table 45)
> Priority 110 rule: for recirculated packets, if ct (of the linked port) is
> invalid, use the tun id from MFF_LOG_TUN_OFPORT to tunnel the packet back (as
> CT zone info has been overwritten in the above 110 priority rule).
> match: inport==nfp1 && RECIRC_BIT==1 && ct.inv && reg5[16..31]==<tun-id>
> action: tunnel packet using tun-id
>
> Signed-off-by: Sragdhara Datta Chaudhuri <sragdha.chau...@nutanix.com>
> Acked-by: Naveen Yerramneni <naveen.yerramn...@nutanix.com>
> ---
Hi Sragdhara,
Not a full review yet (I still need to do that). This is just a note so
we don't forget to add a TODO item for vxlan per our discussion on the
v6 thread.
> @@ -3260,8 +3535,14 @@ physical_run(struct physical_ctx *p_ctx,
> match_init_catchall(&match);
> ofpbuf_clear(&ofpacts);
> for (int i = 0; i < MFF_N_LOG_REGS; i++) {
> - put_load(0, MFF_REG0 + i, 0, 32, &ofpacts);
> + if ((MFF_REG0 + i) != MFF_LOG_TUN_OFPORT) {
> + put_load(0, MFF_REG0 + i, 0, 32, &ofpacts);
> + }
> }
> + /* In MFF_LOG_TUN_OFPORT, the bits 16..31 are used to store geneve
As discussed on the other thread (on the v6 series), let's not forget to
add a TODO.rst item to mention that vxlan support should be added in the
future.
> + * tunnel id of received packets and these need to be carried over to
> + * the egress pipeline. The remaining bits can be reset to zero. */
> + put_load(0, MFF_LOG_TUN_OFPORT, 0, 16, &ofpacts);
> put_resubmit(OFTABLE_LOG_EGRESS_PIPELINE, &ofpacts);
> ofctrl_add_flow(flow_table, OFTABLE_CHECK_LOOPBACK, 0, 0, &match,
> &ofpacts, hc_uuid);
Regards,
Dumitru
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
