On 6 February 2017 at 09:08, Pravin Shelar <pshe...@ovn.org> wrote: > On Thu, Feb 2, 2017 at 5:10 PM, Jarno Rajahalme <ja...@ovn.org> wrote: >> Stateful network admission policy may allow connections to one >> direction and reject connections initiated in the other direction. >> After policy change it is possible that for a new connection an >> overlapping conntrack entry already exist, where the connection >> original direction is opposed to the new connection's initial packet. >> >> Most importantly, conntrack state relating to the current packet gets >> the "reply" designation based on whether the original direction tuple >> or the reply direction tuple matched. If this "directionality" is >> wrong w.r.t. to the stateful network admission policy it may happen >> that packets in neither direction are correctly admitted. >> > Why not have the check in all commit actions? I am not sure in which > case user would not want forced commit considering this can cause > packet admission issue?
Seems like this case has involved one direction of a connection being handled by a flow that committed the connection. Then something has changed and you end up with a flow handling the opposite direction, committing the connection. What if the first flow wasn't actually removed? Plausibly you could end up with constant ct entry churn as the connection is recreated each time there is a packet from an alternating direction. Having a separate flag may assist with respect to shooting one's own foot..
