On Mon, Feb 6, 2017 at 11:28 PM, Joe Stringer <j...@ovn.org> wrote: > 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..
I see. Thanks for explanation.
