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

[Mickey Spiegel]

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.

Mickey