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. 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? 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? 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. 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? Mickey _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
