On 3 November 2016 at 20:42, Mickey Spiegel <mickeys....@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 6:06 PM, Guru Shetty <guru....@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 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev