[ovs-dev] [PATCH 3/3] ovn-northd: SNAT in either direction of gateway router.

[Guru Shetty]

> On Nov 3, 2016, at 4:34 PM, Mickey Spiegel <mickeys.dev at gmail.com> wrote:
> 
> Interesting problem. See comments inline.
> 
>> On Thu, Nov 3, 2016 at 3:46 AM, Gurucharan Shetty <guru at 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 at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev