[ovs-discuss] [OVN][VTEP] returning packets from VTEP have CT invalid state

[Odintsov Vladislav]

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 <odivlad at gmail.com>
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 <odivlad at gmail.com>
---
 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" <ovs-discuss-bounces at openvswitch.org on behalf of piotrmisiak1984 at gmail.com> 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
    discuss at openvswitch.org
    https://mail.openvswitch.org/mailman/listinfo/ovs-discuss