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

Guru Shetty guru at ovn.org
Fri Nov 4 16:54:53 UTC 2016


On 3 November 2016 at 20:42, Mickey Spiegel <mickeys.dev at gmail.com> wrote:

> On Thu, Nov 3, 2016 at 6:06 PM, Guru Shetty <guru.ovn at gmail.com> wrote:
>
> <snip>
>
>
>> > 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.
>
>
> Coming back to this option because IMO it is the most straightforward in
> terms of understanding what the knobs do, even if figuring out what knobs
> to provide is not so straightforward.
>
> For the trigger, I am somewhat torn between putting it in the DNAT and LB
> rules, versus a gateway router option. I can think of cases where it is
> driven by topology (your multiple gateway case), as well as cases where it
> is driven by application (whether direct server return works with the
> application or not). If the trigger goes in the DNAT and LB rules, then a
> force_snat column of type boolean in the NAT and Load_Balancer tables would
> take care of the trigger.
>
> The part that is not as obvious is where to specify the IP address that
> replaces the packet's source IP address. I would lean towards specifying
> this separately from the existing NAT table, partly because the terminology
> of the existing NAT table (logical_ip/external_ip) does not match the use
> case, and partly because my somewhat hazy memory of hardware load balancer
> configuration involves specification of a reference to a NAT pool, i.e. it
> is not a separate SNAT rule specification but just the extra bit of
> specification necessary to make the SNAT part work. If my memory is right,
> that involved a relatively complex reference from the DNAT or LB rule to a
> NAT pool. The equivalent of your SNAT 0.0.0.0/0 rule would be just a
> single SNAT IP address on the gateway router for all force_snat cases,
> rather than a reference to one of many IP addresses or IP address pools.
>
> As long as the trigger is only needed for DNAT and LB in the gateway
> router itself, a force_snat flag should work. If you want a trigger for
> other cases such as stateful services in a switch upstream from the gateway
> router, at first glance it does not seem like this option can handle such a
> case. You would need interface related configuration in order to identify
> the subset of traffic, and some pipeline stage with conntrack so that you
> could weed out ct.rpl traffic.
>

Thanks. I think the trigger is only needed for LB and DNAT use cases. I am
thinking of going with the following approach:

* options:force-snat="$IP" in the gateway router.

Whenever there is a DNAT or LB done on the gateway router, you get a force
snat done with the set IP address.  If application specific use cases come
up as we go forward, then it is a matter of providing the same knob in LB
and NAT tables too - which can be designed better when the use cases are
more obvious.




> Mickey
>



More information about the dev mailing list