Forgot to copy the list on the last reply, but also realized something and asking for one change below.
On Fri, Nov 4, 2016 at 9:54 AM, Guru Shetty <g...@ovn.org> wrote: > > > 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. > That works for me. A bit of explanation is required with regard to which traffic is subject to force-snat, but all in all I think this is easy to understand and avoids complex side effects. I just realized that this is the missing piece that I need to allow centralized load balancing on a distributed router. In that case, I need force-snat for load balancing but not for dnat. Wondering if there should be two options instead: dnat-force-snat="$IP" lb-force-snat="$IP" That also takes care of the explanation. Mickey _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
