From: <[email protected]> on behalf of karthik karra
<[email protected]>
Date: Thursday, December 6, 2018 at 5:35 PM
To: "[email protected]" <[email protected]>
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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
