> On Nov 3, 2016, at 4:34 PM, Mickey Spiegel <mickeys....@gmail.com> wrote: > > Interesting problem. See comments inline. > >> On Thu, Nov 3, 2016 at 3:46 AM, Gurucharan Shetty <g...@ovn.org> wrote: >> >> When multiple gateway routers exist, a packet can >> enter any gateway router. Once the packet reaches its >> destination, its reverse direction should be via the >> same gateway router. This is achieved by doing a SNAT >> of the packet in the inward direction (towards logical space) >> with a IP address of the gateway router such that packet travels back >> to the same gateway router. >> >> The above means that you can have SNAT rules in the NB >> database for both directions. For e.g. if the logical >> ip address are of the range 192.168.1.0/24, you will have >> one SNAT rule to transform packet from 192.168.1.0/24 to >> an external_ip and another SNAT rule to transform >> "0.0.0.0/0" (all external initiated traffic) to a gateway_ip. >> >> For a particular connection, we should do SNAT in only one >> direction. > > > In certain deployment scenarios, including the one you have > mentioned, this might work. However, I wonder if this is really > addressing the root of the problem, or latching on to a symptom > specific to this deployment scenario. > > It seems to me that the root of the problem has to do with > three issues: > 1. SNAT (and DNAT) rules should not apply to ct.rpl traffic, > instead only UNSNAT (and UNDNAT) rules should apply. > Conntrack can tell which traffic is reply traffic, but this would > require going through conntrack with recirc prior to SNAT.
Correct > 2. If a stateful action such as DNAT or LB is taken on a > gateway router, such that it is necessary for the reverse > packet flow to come back to the same gateway router, > then there should be an SNAT action coupled with the > DNAT or LB action. If we could implement such composite > actions, then there would be no need for a general purpose > SNAT 0.0.0.0/0 catch all. Perhaps instead of SNAT > 0.0.0.0/0, DNAT or LB could set a flag that indicates that > SNAT should be applied? That is one option. But I could not think of a nice way to express it in nb database. The other option is to set it as an option in the gateway router itself. > 3. Currently your gateway router has no sense of direction. > NAT rules are applied on all interfaces. In the scenario > described above, you really want the 192.168.1.0/24 SNAT > rule to apply to outward connections, while you want the > 0.0.0.0/0 SNAT rule to apply to inward connections. Since > the gateway router has no sense of direction, both rules > are applied in both directions. Is there a way to introduce > a sense of direction to a gateway router? It complicates deployment a bit. But can be given more thought. > > And to do that in the pipeline, we check whether a packet >> has already been SNATted and if it has a transformation, we should not >> do it again. > > I think this is a roundabout way of implementing 1 above. If all > gateway router traffic is subject to SNAT, then reply traffic will > always hit UNSNAT and so avoid the SNAT stage. Right. > > The question is whether a solution that requires all traffic to > be subject to SNAT is acceptable, for deployment scenarios > where SNAT rules have coarse enough IP address prefixes > to catch traffic in both directions? I did not understand the above point. Can you elaborate a bit. > > Mickey > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev