I resolved this issue. The problem is the instructions have the user perform tests with scapy. However the linux kernel was interfering with the traffic as I was sending TCP packets to ports that were not open on L4, so the kernel by default RST the packets. I needed to add the following iptables rule in the left and right name spaces. Be aware I did not use the two different subnets as the guide suggests. Left = 192.168.0.1, and Right = 192.168.0.2. So this rule will work for my set up. Add another rule for any other subnets being used.
sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.0.0/24 -j DROP I would recommend updating the guide to include the user add this rule in the name spaces if they plan to follow the guide as is. - Dave On Fri, Jul 22, 2022 at 2:56 PM Dave Houser <davehous...@gmail.com> wrote: > I am trying to follow the conntrack tutorial found here: > https://docs.openvswitch.org/en/latest/tutorials/ovs-conntrack/ > > However I am getting undesired results based on what the tutorial is > showing. > > Here is the commands I used to run my setup > > $ br="br0" > $ ns1="left" > $ ns2="right" > $ int_host1="veth_l1" > $ int_br1="veth_l0" > $ int_host2="veth_r1" > $ int_br2="veth_r0" > $ ip1="192.168.0.1/24" > $ ip2="192.168.0.2/24" > $ sudo ip netns add $ns1 > $ sudo ip netns add $ns2 > $ sudo ip link add $int_host1 type veth peer name $int_br1 > $ sudo ip link add $int_host2 type veth peer name $int_br2 > $ sudo ip link set $int_host1 netns $ns1 > $ sudo ip link set $int_host2 netns $ns2 > $ sudo ip netns exec $ns1 ip addr add $ip1 dev $int_host1 > $ sudo ip netns exec $ns1 ip link set $int_host1 up > $ sudo ip link set $int_br1 up > $ sudo ip netns exec $ns2 ip addr add $ip2 dev $int_host2 > $ sudo ip netns exec $ns2 ip link set $int_host2 up > $ sudo ip link set $int_br2 up > $ sudo ovs-vsctl add-br $br > $ sudo ovs-vsctl add-port $br $int_br1 > $ sudo ovs-vsctl add-port $br $int_br2 > $ sudo ip netns exec $ns1 sudo ip link set lo up 2>/dev/null > $ sudo ip netns exec $ns2 sudo ip link set lo up 2>/dev/null > > I added the following rules: > > sudo ovs-ofctl add-flow br0 "table=0, priority=50, ct_state=-trk, tcp, > in_port=veth_l0, actions=ct(table=0)" > sudo ovs-ofctl add-flow br0 "table=0, priority=50, ct_state=+trk+new, tcp, > in_port=veth_l0, actions=ct(commit),veth_r0" > sudo ovs-ofctl add-flow br0 "table=0, priority=50, ct_state=-trk, tcp, > in_port=veth_r0, actions=ct(table=0)" > sudo ovs-ofctl add-flow br0 "table=0, priority=50, ct_state=+trk+est, tcp, > in_port=veth_r0, actions=veth_l0" > > In the "left" name space I ran the following from scapy (Simulate a SYN) > $ >>> sendp(Ether()/IP(src="192.168.0.1", > dst="192.168.0.2")/TCP(sport=1024, dport=2048, flags=0x02, seq=100), > iface="veth_l1") > > Then in the "right" name space I ran the following from scapy (Simulate a > SYN-ACK) > $>>> sendp(Ether()/IP(src="192.168.0.2", > dst="192.168.0.1")/TCP(sport=2048, dport=1024, flags=0x12, seq=200, > ack=101), iface="veth_r1") > > I then run the following to gather flow dumps > $sudo ovs-appctl dpctl/dump-flows system@ovs-system | grep 192 > > And I get no output. I found out I have to wait some period of time before > trying to send traffic again and checking flow dump output with ovs-appctl > (I can only assume this is because of flow timers?) But the guide mentions > nothing of this. > > After waiting a period of time (2 min or so?) I run the Scapy commands > again, and try to gather data, this is what I see. > > $sudo ovs-appctl dpctl/dump-flows system@ovs-system > recirc_id(0x3d),in_port(5),ct_state(+new+trk),eth(),eth_type(0x0800),ipv4(proto=6,frag=no), > packets:0, bytes:0, used:never, actions:ct(commit),6 > recirc_id(0),in_port(6),ct_state(-trk),eth(),eth_type(0x0800),ipv4(proto=6,frag=no), > packets:0, bytes:0, used:never, actions:ct,recirc(0x3e) > recirc_id(0x3e),in_port(6),ct_state(-new+est+trk),eth(),eth_type(0x0800),ipv4(proto=6,frag=no), > packets:0, bytes:0, used:never, actions:5 > recirc_id(0),in_port(6),ct_state(-new-est-trk),eth(),eth_type(0x0806), > packets:0, bytes:0, used:never, actions:drop > recirc_id(0),in_port(5),ct_state(-trk),eth(),eth_type(0x0800),ipv4(proto=6,frag=no), > packets:0, bytes:0, used:never, actions:ct,recirc(0x3d) > > This is not what I expect. I expect to see the output that the guide is > showing like this: > > - For a SYN packet (LEFT -> RIGHT) > $ ovs-appctl dpctl/dump-conntrack system@ovs-system | grep "192.168.0.2" > > tcp,orig=(src=192.168.0.1,dst=192.168.0.2,sport=1024,dport=2048),reply=(src=192.168.0.1,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=SYN_SENT) > - For a SYN-ACK packet (RIGHT -> LEFT) > $ ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2" > > tcp,orig=(src=192.168.0.2,dst=192.168.0.1,sport=1024,dport=2048),reply=(src=192.168.0.2,dst=192.168.0.1,sport=2048,dport=1024),protoinfo=(state=ESTABLISHED) > > BTW, running just " ovs-appctl dpctl/dump-conntrack" By itself gives an > error that I need to select a datapath as there are multiple datapaths. I > rand the following to get my datapath and why I adjusted the above command > to include "system@ovs-system" > > $sudo ovs-dpctl dump-dps > 2022-07-22T18:48:38Z|00001|dpif_netlink|INFO|Kernel does not correctly > support feature negotiation. Using standard features. > system@ovs-system > > I believe the flow data is being recognized as we when I run the following > I can see each flow and its idle_age change whenever I send traffic with > Scapy. The "tile_age" reset. > > $ sudo ovs-ofctl dump-flows br0 > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=164.209s, table=0, n_packets=2, n_bytes=108, > idle_age=75, priority=50,ct_state=-trk,tcp,in_port=1 actions=ct(table=0) > cookie=0x0, duration=164.190s, table=0, n_packets=2, n_bytes=108, > idle_age=56, priority=50,ct_state=-trk,tcp,in_port=2 actions=ct(table=0) > cookie=0x0, duration=164.199s, table=0, n_packets=2, n_bytes=108, > idle_age=75, priority=50,ct_state=+new+trk,tcp,in_port=1 > actions=ct(commit),output:2 > cookie=0x0, duration=164.180s, table=0, n_packets=2, n_bytes=108, > idle_age=56, priority=50,ct_state=+est+trk,tcp,in_port=2 actions=output:1 > > > Why am I not seeing the same output that the conntrack tutorial shows? > Why do I have to wait a period of time to show any type of captured > conntrack data when running `sudo ovs-appctl dpctl/dump-conntrack > system@ovs-system`? > > - Dave >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
