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

Reply via email to