On 2 June 2016 at 14:48, Ben Pfaff <b...@ovn.org> wrote: > On Thu, May 19, 2016 at 01:02:34PM -0700, Gurucharan Shetty wrote: > > For traffic from physical space to virtual space we need DNAT. > > The DNAT happens in the gateway router and reaches the logical > > port. The return traffic should be unDNATed. > > > > Traffic originating in virtual space heading to physical space > > should be SNATed. The return traffic is unSNATted. > > > > East-west traffic with the public destination IP address needs > > a DNAT. This traffic is punted to the l3 gateway where DNAT > > takes place. This traffic is also SNATed and eventually loops back to > > its destination. The SNAT is needed because we need the reverse traffic > > to go back to the l3 gateway and not short-circuit directly to the > source. > > > > This commit introduces 4 new logical actions. > > 1. ct_snat: To send the packet through SNAT zone to unSNAT packets. > > 2. ct_snat(IP): To SNAT to the provided IP address. > > 3. ct_dnat: To send the packet throgh DNAT zone to unDNAT packets. > > 4. ct_dnat(IP): To DNAT to the provided IP. > > > > This commit only provides the ability to do IP based NAT. This will > > eventually be enhanced to do PORT based NAT too. > > > > Command hints: > > > > Consider a distributed router "R1" that has switch foo (192.168.1.0/24) > > with a lport foo1 (192.168.1.2) and bar (192.168.2.0/24) with lport bar1 > > (192.168.2.2) connected to it. You connect "R1" to > > a gateway router "R2" via a switch "join" in (20.0.0.0/24) network. > > > > R2 has a switch "alice" (172.16.1.0/24) connected to it (to simulate > > external network). > > > > case: Add pure DNAT (north-south) > > > > Add a DNAT rule in R2: > > ovn-nbctl set logical_router R2 dnat:"30.0.0.2"=192.168.1.2 > > > > Now alice1 should be able to ping 192.168.1.2 via 30.0.0.2. > > > > case2 : Add pure SNAT (south-north) > > > > Add a SNAT rule in R2: > > > > ovn-nbctl set logical_router R2 snat:"192.168.1.0/24"=30.0.0.1 > > > > (You need a static route in R1 to send packets destined to outside > > world to go through R2) > > > > When foo1 pings alice1, alice1 receives traffic from 30.0.0.1 > > > > case3 : SNAT and DNAT (east-west traffic) > > > > Add a SNAT rule for bar1 > > ovn-nbctl set logical_router R2 snat:"192.168.2.2"=30.0.0.3 > > > > When bar1 pings 30.0.0.2, the traffic jumps to the gateway router > > and loops back to foo1 with a source ip address of 30.0.0.3 > > > > Signed-off-by: Gurucharan Shetty <g...@ovn.org> > > Thanks for working on this! > > The examples above are helpful. Is there someplace in the documentation > where it would be appropriate to include them? > I thought about this for a while and couldn't find a nice way to put this. I am hoping that when the upstream users at OpenStack use it, and based on their feedback, I will try to add some documentation.
> > Can you add some test cases for action parsing to "ovn -- action > parsing" in ovn.at? (As an aside, I like to try to make sure that the > action parsing test cases exercise all the possible syntax errors; > usually that's easy.) > I added a few unit tests. > > Please mention the "ip" prerequisite in the ovn-sb.xml documentation. > Done > > I see a typo in the ovn-northd.8.xml documentation, > s/Northdbound/Northbound/ in a few places, e.g.: > + For each configuration in the OVN Northdbound database, that > asks > ... > + changed based on the configuration in the OVN Northdbound database. > ... > + For each configuration in the OVN Northdbound database, that > asks > Corrected. > > It appears to me that there is a lot of duplicated code in ovn-northd.c > for the different kinds of NAT. For example, I think that the following > would condense the SNAT code a good deal with less code (it does not > update the comments properly though): > The schema will be changed in the next version. I have tried to reduce code duplicity by moving all the NAT related code to a single code block. > Do you think that "non-distributed" is a good term? If it is a standard > term, then it's OK, but, if not, then negative terms are usually better > replaced by positive, for example perhaps "centralized" instead. > I have gotten rid of "non-distributed" and use "Gateway router" in its place. > > The documentation in ovn-sb.xml talks about recirculation. The person > looking at OVN logical flows is a couple of steps removed from > understanding what this means or the consequences. I wonder whether > there is a simple way to explain the meaning or why it is important. > I have re-worked the wordings. I will send the next version. > > Thanks again for implementing the gateway. > > Acked-by: Ben Pfaff <b...@ovn.org> > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
