[ovs-dev,V2] Documentation: Clarify connection tracking tutorial
diff mbox series

Message ID 1560981414-6952-1-git-send-email-gvrose8192@gmail.com
State New
Headers show
Series
  • [ovs-dev,V2] Documentation: Clarify connection tracking tutorial
Related show

Commit Message

Gregory Rose June 19, 2019, 9:56 p.m. UTC
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(-)

Comments

Ben Pfaff July 5, 2019, 8:50 p.m. UTC | #1
On Wed, Jun 19, 2019 at 02:56:54PM -0700, Greg Rose wrote:
> 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>

Thanks, applied to master.

Patch
diff mbox series

diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst
index 27d6e04..2d94054 100644
--- a/Documentation/tutorials/ovs-conntrack.rst
+++ b/Documentation/tutorials/ovs-conntrack.rst
@@ -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