Reputation: 1
I use multiple actions in flow table using openvswitch. When I want to modify TCP ipv4_dst and copy the packet to the other outport, the ack number of the packet is changed randomly. And I do not change other fields in IP header. Why does this happen? I don't want to see the change of ack number.
the flow table items : OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=6.846s, table=0, n_packets=0, n_bytes=0, priority=6,tcp,nw_src=10.0.0.2,nw_dst=10.0.0.1 actions=output:1
cookie=0x0, duration=6.846s, table=0, n_packets=0, n_bytes=0, priority=7,tcp,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=output:2,set_field:10.0.0.3->ip_dst,set_field:00:00:00:00:00:03->eth_dst,output:3
cookie=0x0, duration=6.846s, table=0, n_packets=0, n_bytes=0, priority=8,tcp,nw_src=10.0.0.3,nw_dst=10.0.0.1 actions=output:1
cookie=0x0, duration=6.847s, table=0, n_packets=0, n_bytes=0, priority=0 actions=CONTROLLER:65535
the topology: 10.0.0.1--------switch--------10.0.0.2 | | 10.0.0.3
Upvotes: 0
Views: 445
Reputation: 1
I have found the answer. Because of the monitoring of tcp connection in Linux kernel, we cannot copy the tcp state.
Upvotes: 0
Reputation: 13133
After reproducing your setup with Mininet, I am unable to reproduce the issue.
I used ovs-appctl ofproto/trace
to trace Open vSwitch's behavior when receiving a TCP packet:
ovs-appctl ofproto/trace s1 in_port=1,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,tcp,nw_src=10.0.0.1,nw_dst=10.0.0.2
The output doesn't include any sequence number modification.
I compared packets on ports 2 and 3 using Wireshark. They have the exact same ACK numbers in my case.
These three points lead me to believe that your problem doesn't come from Open vSwitch. Could the ACK number modification come from some other piece of software? Are you running your experiments in Mininet or on physical hosts?
Upvotes: 0