Hello, thank you very much for you help!
-- Best regards, Krzysztof Tomaszewski ________________________________ From: Ilya Maximets <i.maxim...@ovn.org> Sent: 12 November 2024 9:28 PM To: Krzysztof Tomaszewski <ktomaszew...@cloudferro.com>; ovs-discuss@openvswitch.org <ovs-discuss@openvswitch.org> Cc: i.maxim...@ovn.org <i.maxim...@ovn.org> Subject: Re: [ovs-discuss] ofproto/trace for ICMP reply to VM on DPDK network node/gateway problem On 11/8/24 11:15, Krzysztof Tomaszewski via discuss wrote: > Hello, > > I am trying to trace ICMP ping reply packet on DPDK + bond gateway node and I > am struggling. > It looks like ovs-appctl ofproto/trace is not applying conntrack base data > and in trace flow > packet is not unSNAT-ed. > > Of course, ICMP ping is working properly - packet is going back to the VM - > the problem seems to be with > ofproto/trace only. <CUT > > What I am missing here? Hi, Krzystzof. Unfortunately, trace can only mimic behavior of the connection tracking, but it doesn't use the actual conntrack states in the datapath. The main reason is that passing packets through connection tracking will change the state of the connection tracker, potentially breaking the real traffic flow. You can use ct-next flag to give trace a hint on what should be a resulted ct state, but it doesn't really help with unSNAT case. The only option here, I think, is for you to modify (unSNAT) the packet yourself and use ofproto/trace-packet-out with actions=resubmit(,<table-id>) to continue processing from the table the previous trace stopped. This will not help with debuggign the conntrack itself, but should be useful if you just want to know where the packet supposed to go next. Best regards, Ilya Maximets. > > -- > Regards, > > Krzystzof Tomaszewski
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
