[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