| Message ID | 1560545066-15722-1-git-send-email-gvrose8192@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [ovs-dev] Documentation: Clarify connection tracking tutorial | expand |
Looks good to me, thanks for the fix. Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com> On Fri, Jun 14, 2019 at 1:44 PM Greg Rose <gvrose8192@gmail.com> 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> > --- > Documentation/tutorials/ovs-conntrack.rst | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst > index 27d6e04..5daffb6 100644 > --- a/Documentation/tutorials/ovs-conntrack.rst > +++ b/Documentation/tutorials/ovs-conntrack.rst > @@ -308,8 +308,14 @@ 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. All packets entering > +OVS for the first time are "untracked" with a minor exception being > +when a packet (re)enters the same datapath that it already belongs to > +there is no need to discard the namespace and other information. In this > +case the connection 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 > -- > 1.8.3.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Hi Greg few comments inline. On Fri, Jun 14, 2019 at 1:44 PM Greg Rose <gvrose8192@gmail.com> 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> > --- > Documentation/tutorials/ovs-conntrack.rst | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Documentation/tutorials/ovs-conntrack.rst > b/Documentation/tutorials/ovs-conntrack.rst > index 27d6e04..5daffb6 100644 > --- a/Documentation/tutorials/ovs-conntrack.rst > +++ b/Documentation/tutorials/ovs-conntrack.rst > @@ -308,8 +308,14 @@ 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. All packets > entering > +OVS for the first time are "untracked" with a Maybe ?: "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." > minor exception being > +when a packet (re)enters the same datapath that it already belongs to > +there is no need to discard the namespace and other information. it might be helpful to expand on "other information" here ? > In this > +case the connection will remain in the tracked state. s/the connection will remain in the tracked state/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 > -- > 1.8.3.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
On 6/14/2019 3:57 PM, Darrell Ball wrote: > Hi Greg > > few comments inline. Thanks for the suggestions Darrell, let me work up a V2 and I'll repost then. - Greg > > On Fri, Jun 14, 2019 at 1:44 PM Greg Rose <gvrose8192@gmail.com > <mailto:gvrose8192@gmail.com>> 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 <mailto:qtian@vmware.com>> > Signed-off-by: Greg Rose <gvrose8192@gmail.com > <mailto:gvrose8192@gmail.com>> > --- > Documentation/tutorials/ovs-conntrack.rst | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Documentation/tutorials/ovs-conntrack.rst > b/Documentation/tutorials/ovs-conntrack.rst > index 27d6e04..5daffb6 100644 > --- a/Documentation/tutorials/ovs-conntrack.rst > +++ b/Documentation/tutorials/ovs-conntrack.rst > @@ -308,8 +308,14 @@ 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. All > packets entering > +OVS for the first time are "untracked" with a > > > Maybe ?: > "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." > > minor exception being > +when a packet (re)enters the same datapath > > that it already belongs to > +there is no need to discard the namespace and other information. > > > it might be helpful to expand on "other information" here ? > > In this > +case the connection will remain in the tracked state. > > > s/the connection will remain in the tracked state/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 > -- > 1.8.3.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org <mailto:dev@openvswitch.org> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst index 27d6e04..5daffb6 100644 --- a/Documentation/tutorials/ovs-conntrack.rst +++ b/Documentation/tutorials/ovs-conntrack.rst @@ -308,8 +308,14 @@ 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. All packets entering +OVS for the first time are "untracked" with a minor exception being +when a packet (re)enters the same datapath that it already belongs to +there is no need to discard the namespace and other information. In this +case the connection 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 | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)