Uh, I realized another question, sorry for annoying. If controller needs to do arp request for querying gateway’s Mac, then it can customize all flows for NAT, but it still need some method to memorize traffic relation between LAN VM and outside traffic. And conntrack will memorize connection between LAN VM and outside server.
but what action should controller do in OVS? 1. Controller packet out to probe MAC address. 2. Flow for client to LAN default GW(OVS) and do nat. 3. Flow for change client packet src Mac, dst Mac, and output to external port 4. Flow for packet come back from outside. table=0,in_port=$IN,ip,actions=ct(commit,zone=1,nat(src=ext_ip)),actions=table:1 table=1,ct_state=+trk,actions=mod_src_mac:OVS_MAC,mod_dst_mac:GW_MAC,output:$OUT table=0,in_port=$IN,ip,ct_state=+trk,ct_zone=1,actions=??? The flow rules I list is corresponding to controller action list’s 2, 3, 4. But I still don’t understand how OVS transfer packet back to client(It should modify src, dst Mac back), what action should be in 3rd flow? Thanks! --- Best Regards, Wei-Yu Chen Wireless Internet Laboratory Department of Computer Science National Chiao Tung University On 4 May 2018 at 8:42:31 PM, Wei-Yu Chen ([email protected]) wrote: Okay, After your explanation, I understand how to operate with OVS’s NAT function, your answer help with me a lot! Appreciated for your answer! --- Best Regards, Wei-Yu Chen Wireless Internet Laboratory Department of Computer Science National Chiao Tung University On 4 May 2018 at 10:59:01 AM, Guru Shetty ([email protected]) wrote: No, OVS NAT cannot do that. OVS NAT in your situation is more useful with a controller that will program the OVS. And when a packet comes in that needs to reach the gateway, the controller needs to 1. Create a ARP request for the gateway's IP, collect the reply and update the flows such that future packets know the MAC address. On 2 May 2018 at 20:52, Wei-Yu Chen <[email protected]> wrote: > Hi Guru, > > Thanks for your reply, but I can’t make sure what MAC address for Gateway, > doesn’t this should be automatic done by OVS NAT function? > > > --- > Best Regards, > > Wei-Yu Chen > Wireless Internet Laboratory > Department of Computer Science > National Chiao Tung University > > On 30 April 2018 at 11:49:29 PM, Guru Shetty ([email protected]) wrote: > > > > On 26 April 2018 at 06:41, Wei-Yu Chen <[email protected]> wrote: > >> Hello all, >> >> Recently, I’m trying on SNAT with OVS, I tried to apply all possible >> flows to OVS, but SNAT still don’t work, so I post this message for asking >> your help. >> >> In my experiment environment, I used Ubuntu 16.04 with kernel version >> 4.10.0–28-generic, and OVS’s version 2.9.0. >> >> I have a VM in my PC, connected VM and OVS with a Linux bridge, as >> following illustrated: >> >> +———————————–+ >> | | >> | +——+ +—–+ | >> | +–+ br +———+ OVS | | >> | | +——+ vnet2+—+-+ | >> | | | | >> | +–+——+ | | >> | | VM | | | >> | |10.1.1.2 | | | >> | +———+ +—+—-+ | >> | Ubuntu 16.04 | enp2s0 | | >> +————————+——–+-+ >> >> And OVS have 2 IP addresses, 10.1.1.1/24 and an public IP >> address(140.113.x.x) original enp2s0 have. I attached vnet2 and enp2s0 on >> my OVS. >> >> I referred many posts and wrote following script: >> >> #!/bin/sh >> IN="vnet2" >> OUT="enp2s0" >> >> flow1="in_port=$IN,ip,actions=ct(commit,zone=1,nat(src=10.1.1.1)),$OUT" >> flow2="in_port=$OUT,ip,ct_state=-trk,actions=ct(zone=1,nat)" >> flow3="in_port=$OUT,ip,ct_state=+trk,ct_zone=1,actions=$IN" >> >> # Add Flows >> sudo ovs-ofctl add-flow $BR $flow1 >> sudo ovs-ofctl add-flow $BR $flow2 >> sudo ovs-ofctl add-flow $BR $flow3 >> >> But I found ICMP echo to Google DNS from VM (nw_src=10.1.1.2, >> nw_dst=8.8.8.8), when it passed to enp2s0, only source IP address changed >> to 10.1.1.1, but source MAC address keep same as VM’s MAC, and destination >> MAC address keep same as OVS’s MAC address. (VM’s default gateway is >> 10.1.1.1/24, OVS’s vnet2 interface). >> > You need to change the MAC addresses too. > > > >> Tcpdump’s log: >> >> 10.1.1.1 > 8.8.8.8: ICMP echo request, id 725, seq 1, length 64 >> 21:12:09.413082 52:54:00:fd:d6:ce > 70:4d:7b:6e:16:e0, ethertype IPv4 >> (0x0800), length 98: (tos 0x0, ttl 64, id 41649, offset 0, flags [DF], proto >> ICMP (1), length 84) >> >> I also tried to find reason by conntrack tool, but it shows only 10.1.1.2 >> have a NEW connection to 8.8.8.8 but didn’t get any reply. >> >> I can’t figure out why OVS’s SNAT didn’t work, do my flows have wrong? >> Any suggestion and idea is appreciated, Thanks very much. >> >> P.s. Attachment is illustration snapshot, if illustrate broken in mail >> viewer, please take a look on the attachment. >> >> >> --- >> Best Regards, >> >> Wei-Yu Chen >> Wireless Internet Laboratory >> Department of Computer Science >> National Chiao Tung University >> >> _______________________________________________ >> discuss mailing list >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> >
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
