From: <ovs-discuss-boun...@openvswitch.org> on behalf of karthik karra <karrakarthi...@gmail.com> Date: Thursday, December 6, 2018 at 5:35 PM To: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org> Subject: [ovs-discuss] Changing Destination IP and MAC Address for TCP Connection
Hi All, I have three VMs VM1 - 192.168.1.101 VM2 - 192.168.1.102 VM3 - 192.168.1.103 I am using netcat for testing the flows between the VMs. My scenario is, the netcat server listens on both VM2 and VM3. From VM1, I will provide "nc <vm2_ip_address> <listen_port>". But I have a rule in OVS which mentions if source IP is VM1 and destination IP is VM2, then change the destination IP and MAC address to the VM3's such that the flow is redirected to the VM3. This is working fine for UDP flows. >>>>>>> really ? For TCP, when I have searched for solution, I have found conntrack. I am using OVS 2.6 version as I have seen in one of the videos that from this version it supports the conntrack in user data path. >>>>>> What is the o/p of ‘sudo ovs-vsctl get bridge <your bridge name> >>>>>> datapath_type’ ? >>>>>> What is the o/p ‘sudo ovs-vsctl show’ ? This is the flow rule I am using to match and change the addresses for TCP. I have followed the conntrack tutorial provided in OVS site. ovs-ofctl add-flow ovs_bridge "table=0,priority=50,ct_state=-trk,tcp,nw_src=192.168.1.101,nw_dst=192.168.1.102,tp_dst=8001,idle_timeout=0,actions=ct(table=0),mod_nw_dst=192.168.1.103,mod_dl_dst=08:00:27:be:ce:e0,normal >>>>>> Are you trying to use conntrack for NATing or you don’t care ?; right >>>>>> now, you are doing NAT outside of conntrack and anyways conntrack NAT is not in 2.6, assuming you are really using the userspace datapath ? >>>>>> The above rule sends a packet thru conntrack that will not be very >>>>>> successful, but another copy of the packet will be subjected to >>>>>> nw_dst/dl_dst modification and be sent to the other VMs Normally endpoints talk bidirectionally, but your one rule seems to imply otherwise; can you explain ? What is the full o/p of ‘sudo ovs-ofctl dump-flows <your bridge name> ? The SYN packet is still being sent to 102 rather than to 103. >>>>>> You mean the addresses are changed but the packet goes to VM3 or the >>>>>> addresses are not even changed from your POV ? Maybe the mac binding is not what you expect; first try sending to the openflow port of VM3 in the above rule first and see if that works; i.e. change ‘normal’ to the ‘VM3 port’ You could check ‘sudo ovs-appctl dpif/dump-flows <your bridge name>’ I have read that even the order of actions is important and I have put the "ct(table=0)" at the end. But its of no use. Can anybody please help. Thanks Karra
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss