@@ -308,8 +308,16 @@ Let's add that flow::
A TCP syn packet sent from "left" namespace will match flow #1
because the packet is coming to OVS from veth_l0 port and it is not being
-tracked. (as the packet just entered OVS. All packets entering OVS for the
-first time are "untracked")
+tracked. This is because the packet just entered OVS. When a packet
+enters a namespace for the first time, a new connection tracker context
+is entered, hence, the packet will be initially "untracked" in that
+namespace.
+When a packet (re)enters the same datapath that it already belongs to
+there is no need to discard the namespace and other information
+associated with the conntrack flow. In this case the packet will
+remain in the tracked state. If the namespace has changed then it is
+discarded and a new connection tracker is created since connection
+tracking information is logically separate for different namespaces.
The flow will send the packet to the connection tracker due to the action "ct".
Also "table=0" in the "ct" action forks the pipeline processing in two. The
original instance of packet will continue processing the current action list
The current documentation states that "all packets entering OVS for the first time are "untracked"". However there is a minor exception to this in the case where a packet (re)enters the same datapath and the namespace has not changed. In that case there is no need to scrub the packet and in this case the connection may already be in the "tracked" state. Reported-by: Quan Tian <qtian@vmware.com> Signed-off-by: Greg Rose <gvrose8192@gmail.com> --- Documentation/tutorials/ovs-conntrack.rst | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)