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

Guru Shetty guru.ovn at gmail.com
Fri Nov 4 02:29:20 UTC 2016



> On Nov 3, 2016, at 7:16 PM, Mickey Spiegel <mickeys.dev at gmail.com> wrote:
> 
> See reply at the bottom.
> 
>> On Thu, Nov 3, 2016 at 6:06 PM, Guru Shetty <guru.ovn at gmail.com> wrote:
>> 
>> <snip>
>> 
>> > 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
>> 
>> <snip>
>  
>> > 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.
> 
> This approach imposes symmetry in terms of which traffic is
> subject to SNAT, when an SNAT rule is coarse enough to match
> source IP addresses in both directions, for example 0.0.0.0/0.
> If you wanted SNAT imposed for 0.0.0.0/0 in the inward direction,
> then you will have SNAT imposed for 0.0.0.0/0 in the outward
> direction, with no exceptions except for SNAT longest match
> overrides. I guess that is why you suggested the 'nosnat'
> second patch?

Thanks for the explanation. You are right about the situation. Do you have any design suggestions to solve this overall problem in a easy way?

> 
> Mickey
> 
>> 
>> >
>> > Mickey
>> > _______________________________________________
>> > dev mailing list
>> > dev at openvswitch.org
>> > http://openvswitch.org/mailman/listinfo/dev
> 



More information about the dev mailing list