Hi, A year ago I saw same situation in 20.03 and 20.06 branches. I fixed this locally applying next patch:
From e96018278b1ccc7598110f1cdcee7a043b707d55 Mon Sep 17 00:00:00 2001 From: Vladislav Odintsov <[email protected]> Date: Wed, 29 Apr 2020 23:47:51 +0300 Subject: [PATCH 2/3] controller: send packets from vxlan tun to l2lkp table Signed-off-by: Vladislav Odintsov <[email protected]> --- controller/lflow.h | 1 + controller/physical.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/controller/lflow.h b/controller/lflow.h index f02f709d7..04e72f08e 100644 --- a/controller/lflow.h +++ b/controller/lflow.h @@ -58,6 +58,7 @@ struct uuid; * you make any changes. */ #define OFTABLE_PHY_TO_LOG 0 #define OFTABLE_LOG_INGRESS_PIPELINE 8 /* First of LOG_PIPELINE_LEN tables. */ +#define OFTABLE_LOG_INGRESS_L2_LKP 25 #define OFTABLE_REMOTE_OUTPUT 32 #define OFTABLE_LOCAL_OUTPUT 33 #define OFTABLE_CHECK_LOOPBACK 34 diff --git a/controller/physical.c b/controller/physical.c index 144aeb7bd..f21080274 100644 --- a/controller/physical.c +++ b/controller/physical.c @@ -1671,7 +1671,7 @@ physical_run(struct physical_ctx *p_ctx, /* For packets received from a vxlan tunnel, set a flag to that * effect. */ put_load(1, MFF_LOG_FLAGS, MLF_RCV_FROM_VXLAN_BIT, 1, &ofpacts); - put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, &ofpacts); + put_resubmit(OFTABLE_LOG_INGRESS_L2_LKP, &ofpacts); ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100, binding->header_.uuid.parts[0], -- 2.24.1 Actually I'm not sure whether this is right approach, but it works well for me and all current functionality also works fine. As I understood, the reason for the issue was that VXLAN tunnel ID have no bits for dest lport, thus we need locally on the HV determine output (VM) port, and the logic is earlier, in the l2_lkp OF table, which is before OF table "log_ingress_pipeline". Maybe, I'm wrong, please ovn guys correct me. Anyway I'm also interested if this patch is correct or not. Regards, Vladislav Odintsov On 26.05.2021, 13:00, "discuss on behalf of Piotr Misiak" <[email protected] on behalf of [email protected]> wrote: Hi, VM on OVN: 10.129.25.83 IP behind VTEP: 10.129.25.170 Traffic initiated from behind the VTEP towards VM on OVN is working correctly, ex. running "ping 10.129.25.83". Traffic initiated from VM on OVN (10.129.25.83) towards VTEP is not, ex. running "ping 10.129.25.170". ICMP requests are reaching 10.129.25.170, and ICMP replies are reaching OVN on VM's hypervisors, but are not reaching VM itself. Packets are dropped on destination OVN node with CT invalid state, I have a following DP entries: recirc_id(0),tunnel(tun_id=0x21a,src=10.129.11.12,dst=10.129.11.25,flags(-df-csum+key)),in_port(114),eth(src=b2:e2:62:08:a1:34,dst=fa:16:3e:d4:b2:64),eth_type(0x0800),ipv4(src=10.129.25.170,dst=0.0.0.0/128.0.0.0,proto=1,frag=no), packets:2, bytes:196, used:0.113s, actions:ct,recirc(0x32c381) recirc_id(0x32c381),tunnel(tun_id=0x21a,src=10.129.11.12,dst=10.129.11.25,flags(-df-csum+key)),in_port(114),ct_state(-new-est-rel-rpl+inv+trk),ct_label(0/0x1),eth(),eth_type(0x0800),ipv4(frag=no), packets:56, bytes:5488, used:0.846s, actions:drop ovn-trace with a default CT state (EST) is showing a correct path, ending in VM's port. ovn-trace with CT invalid state set is showing packet drop (exactly what I'm seeing) I analyzed OpenFlow tables and CT entries. It looks like ICMP reply packets are analyzed by CT in a wrong zone (default 0?) and are not matching to the existing entry created by ICMP request, because it is stored in a different CT zone. I'm testing on OVN 20.12 with OVS software VTEP emulator # ovn-controller --version ovn-controller 20.09.90 Open vSwitch Library 2.14.99 OpenFlow versions 0x6:0x6 SB DB Schema 20.12.0 Is it a bug or I'm missing something in configuration? Thanks _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
