On 30 August 2016 at 14:50, Ben Pfaff <b...@ovn.org> wrote: > On Tue, Aug 30, 2016 at 01:42:06PM -0700, Guru Shetty wrote: > > On 30 August 2016 at 13:03, Ben Pfaff <b...@ovn.org> wrote: > > > > > On Tue, Aug 23, 2016 at 02:46:17AM -0700, Gurucharan Shetty wrote: > > > > Currently ct_lb() logical action is only added for a logical switch > and > > > > we use the conntrack zone allocated for the logical port. A future > > > commit > > > > will use ct_lb() for a logical router too. In that case, use the > > > allocated > > > > DNAT zone. > > > > > > > > Signed-off-by: Gurucharan Shetty <g...@ovn.org> > > > > > > Can you help me to understand why the desired behavior is different in > > > each of these cases? > > > > > > > Currently we do the following conntrack zone allocations. > > 1. A conntrack zone for each logical port. This has to be unique only per > > hypervisor. We use this zone to do both firewall and east-west > > load-balancing. > > > > For firewall, we send the packet to conntrack to defragment it and track > it > > and figure out whether it is invalid, new, established etc. Invalid > packets > > are dropped. new connections are committed. > > > > For load-balancing, defragmented packets are DNATed into one of the > > possible endpoints. We do the load-balancing at the endpoint (instead of > > say in a router) because of the asymmetric nature of OVN router pipeline > > handling for east-west. > > So when we see ct_lb() action on a switch, we can just use the conntrack > > zone allocated for that logical port. > > > > > > 2. Two conntrack zones per gateway router. > > A gateway router only resides in a particular chassis. We have one > > conntrack zone for DNAT and another for SNAT. > > > > Now when I want to add ct_lb() action for the gateway router, I want to > use > > it as part of the gateway router pipeline. Since load-balancing is > nothing > > but a DNAT using one of the chosen endpoint, the conntrack zone has to > be a > > DNAT zone allocated to that gateway router. > > > > Did I give the answer to your question? Or was it something else that you > > were looking an explanation for? > > One underlying question I'm trying to understand is whether this > difference is something inherent in the definition of logical switches > and logical routers, and thus the approach taken here of automatically > choosing a strategy is appropriate, or whether this is just what we > happen to be doing now, in which case it might be better to make how to > select the zone a parameter to ct_lb. >
I see the question now. I don't have a good answer. One way to look at it would be that a "zone" is an internal implementation detail and should not be seen in a action of logical flow. But we can then say that we could rename "zone" as "datapath" in the logical action. But, then we would be limiting it to 2 anyway (datapath=lswitch or datapath=lrouter), because that is all that I can think about - in which case we are inferring it with the current patch anyway. I did start with passing this as an argument to ct_lb, but could not think about a good name. I then decided that for a stateful OVS action, you probably cannot make a very general purpose logical action. Do you have an opinion? I will go with that. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
