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. Mickey _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev