OVN should clear conntrack state on zone assignment

[Russell Bryant]

When ovn-controller assigns a conntrack zone ID to a port, it's possible for there to be existing entries in that zone that should be cleared. The zone could have been used for a previous port, for example.

The fix isn't completely obvious here for a couple of reasons:

1) We shouldn't assume that the linux kernel conntrack is what's in use. It's datapath specific.

2) If ovn-controller restarts, we actually really do want to make sure we choose the same zone ID, otherwise a restart of ovn-controller has a data path impact, where it really shouldn't.

[Russell Bryant (russellb)]

ovn/controller/binding.c, function update_ct_zones() has this comment:

         /* xxx We should erase any old entries for this
          * xxx zone, but we need a generic interface to the conntrack
          * xxx table. */

[Ramu Ramamurthy (ramu-ramamurthy)]

Taking this bug since this is related to this other one on manipulating conntrack from the ovn-controller.
https://bugs.launchpad.net/networking-ovn/+bug/1536080

I will a) reproduce the problem, b) understand the codepaths and update as a next step. If there are folks working on this already, please take it away...

[Ramu Ramamurthy (ramu-ramamurthy)]

Russell, For the ovn controller restart scenario: During ovn-controller startup, Can we recover the port->zoneid map from the existing flows in the flow table (table 0), as for every port, there would be a flow that loads the zone-id for that ?

[Han Zhou (zhouhan)]

I would suggest to save the zone-id in local ovsdb as an external-id which may be more reliable and less complex in my opinion.

[Ramu Ramamurthy (ramu-ramamurthy)]

Han, your approach is simpler, i will try a fix, that, upon setting a zone to a port adds an external id with a key of "zoneid" to the if table of local ovsdb. Upon ovn-controller startup, these zoneids are recovered from db.

[Ramu Ramamurthy (ramu-ramamurthy)]

The following patch has been submitted to ovn-upstream along the lines of the approach suggested by Han Zhou above.

http://openvswitch.org/pipermail/dev/2016-February/065887.html

[Babu Shanmugam (anbu-p)]

Ramu, are you still working on this? If not, I can take up this.

[Ramu Ramamurthy (ramu-ramamurthy)]

Babu,

Thanks, please take it,
For your reference, the following are earlier patches submitted around this.

Patch:
http://openvswitch.org/pipermail/dev/2016-March/068217.html
The complexity here is in child-port handling.

Restart testcases and discussions around it:
http://openvswitch.org/pipermail/dev/2016-March/067321.html

I could see in the above restart test that the zone-id's are
inconsistently assigned on each restart of
the ovn-controller, but I was unable to prove a datapath impact due to the
inconsistent zone-id allocation (which simple tcp sessions).

Ramu

[Babu Shanmugam (anbu-p)]

Thanks for the imformation Ramu. I will assign this bug to myself.

[Russell Bryant (russellb)]

This was fixed in OVN a while ago. The fix is included in the OVS 2.6 release.