diff options
| author | Greg Rose <gvrose8192@gmail.com> | 2019-06-19 14:56:54 -0700 |
|---|---|---|
| committer | Ben Pfaff <blp@ovn.org> | 2019-07-05 13:48:58 -0700 |
| commit | 2c3d147dd47e7f19dc5337099d631da264dc8538 (patch) | |
| tree | fde32bf74b12c57a3cbb4a8d194cec9a152f012a /Documentation/tutorials | |
| parent | 393f479c3ead487fb41c73b5aaa9554404e8e2b4 (diff) | |
| download | openvswitch-2c3d147dd47e7f19dc5337099d631da264dc8538.tar.gz | |
Documentation: Clarify connection tracking tutorial
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>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Diffstat (limited to 'Documentation/tutorials')
| -rw-r--r-- | Documentation/tutorials/ovs-conntrack.rst | 12 |
1 files changed, 10 insertions, 2 deletions
diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst index 27d6e04c3..2d94054ea 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 |