Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows.
Ooops. Sorry about that I missed it. Thanks for pointing this out! I will send a patch soon to update the NEWS and . It does make sense to add the OVS release version for them as well. I'm not sure why we weren't doing it beforehand ... -- Alin. -Original Message- From: Ilya Maximets Sent: Monday, April 25, 2022 8:33 PM To: Alin-Gabriel Serdean ; 'ldejing' ; d...@openvswitch.org Cc: 'ldejing' ; i.maxim...@ovn.org Subject: Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows. On 4/22/22 11:32, Alin-Gabriel Serdean wrote: > Applied on master. Thank you for working on the feature! Thanks, Alin, for taking care of these patches! Could you, please, fix the NEWS file though? The change there doesn't look correct to me. The new section got added for some reason. And maybe we should also add a NEWS entry for the previous change "IPv6 Geneve" along the way? And another question: I see that in the docs it's just stated "YES" for Windows datapath features support, while on other columns we have versions specified. Do you think it makes sense to specify 2.18 as a release version for these 2 new features? Best regards, Ilya Maximets. > > -Original Message- > From: dev On Behalf Of ldejing > Sent: Monday, April 11, 2022 10:18 AM > To: d...@openvswitch.org > Cc: ldejing > Subject: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack > support on Windows. > > From: ldejing > > Implementation on Windows: > Currently, IPv4 conntrack was supported on the windows platform. > In this patch we have implemented ipv6 conntrack functions according > to the current logic of the IPv4 conntrack. This implementation has > included TcpV6(nat and normal scenario), UdpV6(nat and normal > scenario), > IcmpV6 conntrack of echo request/reply packet and FtpV6(nat and normal > scenario). > > Testing Topology: > On the Windows VM runs on the ESXi host, two hyper-v ports attached to > the ovs bridge; one hyper-v port worked as client and the other port > worked as server. > > Testing Case: > 1. TcpV6 > a) Tcp request/reply conntrack for normal scenario. > In this scenario, 20::1 as client, 20::2 as server, it will generate > following conntrack entry: > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), > > reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=tcp) > > b) Tcp request/reply conntrack for nat scenario. > In this scenario, 20::1 as client, 20::10 as floating ip, 21::3 > as server, > it will generate following conntrack entry: > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), > reply(src=21::3, src_port=1556, dst=20::1, dst_port= > 1555),protocol=tcp) > > 2. UdpV6 > a) Udp request/reply conntrack for normal scenario. > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), > reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=udp) > b) Udp request/reply conntrack for nat scenario. > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), > reply(src=21::3, src_port=1556, dst=20::1, dst_port= > 1555),protocol=udp) > > 3. IcmpV6: > a) Icmpv6 request/reply conntrack for normal scenario. > Currently Icmpv6 only support to construct conntrack for > echo request/reply packet, take (20::1 -> 20::2) for example, > it will generate following conntrack entry: > (origin(src = 20::1, dst=20::2), reply(src=20::2, dst=20::1), > protocol=icmp) > b) Icmp request/reply conntrack for dnat scenario, > for example (20::1->20::10->21::3), 20::1 is > client, 20::10 is floating ip, 21::3 is server ip. > It will generate flow like below: > (origin(src=20::1, dst=20::10), reply(src=21::3, dst=20::1), > protocol=icmp) > > 4. FtpV6 > a) Ftp request/reply conntrack for normal scenario. > In this scenario, take 20::1 as client, 20::2 as server, it will > generate > two conntrack entries: > Ftp active mode > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), > reply(src=20::2, src_port=21, dst=20::1, dst_port=1555), protocol=tcp) > (Origin(src=20::2, src_port=20, dst=20::1, dst_port=1556), > reply(src=20::1, src_port=1556, dst=20::2, dst_port=20), > protocol=tcp) > > Ftp passive mode > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), > reply(src=20::2,src_port=21,dst=20::1,dst_port=1555),protocol=tcp) > (Origin(src=20::1, src_port=1556, dst=20::2, dst_port=1557), > reply(src=20::2,src_port=1557, dst=20::1, dst_port=1556) > protocol=tcp) > > b) Ftp request/reply conntrack for nat scenario. > Ftp passive mode, &
Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows.
On 4/22/22 11:32, Alin-Gabriel Serdean wrote: > Applied on master. Thank you for working on the feature! Thanks, Alin, for taking care of these patches! Could you, please, fix the NEWS file though? The change there doesn't look correct to me. The new section got added for some reason. And maybe we should also add a NEWS entry for the previous change "IPv6 Geneve" along the way? And another question: I see that in the docs it's just stated "YES" for Windows datapath features support, while on other columns we have versions specified. Do you think it makes sense to specify 2.18 as a release version for these 2 new features? Best regards, Ilya Maximets. > > -Original Message- > From: dev On Behalf Of ldejing > Sent: Monday, April 11, 2022 10:18 AM > To: d...@openvswitch.org > Cc: ldejing > Subject: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack > support on Windows. > > From: ldejing > > Implementation on Windows: > Currently, IPv4 conntrack was supported on the windows platform. > In this patch we have implemented ipv6 conntrack functions according > to the current logic of the IPv4 conntrack. This implementation has > included TcpV6(nat and normal scenario), UdpV6(nat and normal scenario), > IcmpV6 conntrack of echo request/reply packet and > FtpV6(nat and normal scenario). > > Testing Topology: > On the Windows VM runs on the ESXi host, two hyper-v ports attached > to the ovs bridge; one hyper-v port worked as client and the > other port worked as server. > > Testing Case: > 1. TcpV6 > a) Tcp request/reply conntrack for normal scenario. > In this scenario, 20::1 as client, 20::2 as server, it will generate > following conntrack entry: > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), > reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=tcp) > > b) Tcp request/reply conntrack for nat scenario. > In this scenario, 20::1 as client, 20::10 as floating ip, 21::3 as > server, > it will generate following conntrack entry: > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), > reply(src=21::3, src_port=1556, dst=20::1, dst_port= > 1555),protocol=tcp) > > 2. UdpV6 > a) Udp request/reply conntrack for normal scenario. > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), > reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=udp) > b) Udp request/reply conntrack for nat scenario. > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), > reply(src=21::3, src_port=1556, dst=20::1, dst_port= > 1555),protocol=udp) > > 3. IcmpV6: > a) Icmpv6 request/reply conntrack for normal scenario. > Currently Icmpv6 only support to construct conntrack for > echo request/reply packet, take (20::1 -> 20::2) for example, > it will generate following conntrack entry: > (origin(src = 20::1, dst=20::2), reply(src=20::2, dst=20::1), > protocol=icmp) > b) Icmp request/reply conntrack for dnat scenario, > for example (20::1->20::10->21::3), 20::1 is > client, 20::10 is floating ip, 21::3 is server ip. > It will generate flow like below: > (origin(src=20::1, dst=20::10), reply(src=21::3, dst=20::1), > protocol=icmp) > > 4. FtpV6 > a) Ftp request/reply conntrack for normal scenario. > In this scenario, take 20::1 as client, 20::2 as server, it will > generate > two conntrack entries: > Ftp active mode > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), > reply(src=20::2, src_port=21, dst=20::1, dst_port=1555), protocol=tcp) > (Origin(src=20::2, src_port=20, dst=20::1, dst_port=1556), > reply(src=20::1, src_port=1556, dst=20::2, dst_port=20), protocol=tcp) > > Ftp passive mode > (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), > reply(src=20::2,src_port=21,dst=20::1,dst_port=1555),protocol=tcp) > (Origin(src=20::1, src_port=1556, dst=20::2, dst_port=1557), > reply(src=20::2,src_port=1557, dst=20::1, dst_port=1556) protocol=tcp) > > b) Ftp request/reply conntrack for nat scenario. > Ftp passive mode, > In this secnario, 20::1 as client, 20::10 as floating ip, 21::3 as > server > ip. It will generate following flow: > (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=21), > reply(src=21::3, src_port=21, dst=20::1, dst_port= 1555),protocol=tcp) > (Origin(src=20::1, src_port=1556, dst=20::10, dst_port=1557), > reply(src=21::3, src_port=1557, dst=20::1, dst_port= > 1556),protocol=tcp) > > 5. Regression test for IpV4 in Antrea project (about 60 test case) > > Future work: > 1) IcmpV6 redirect packet conntrack. > 2) IpV6 fragment support on Udp. > 3) Support napt for IPv6. > 4) FtpV6 active mode for nat. > > Signed-off-by: ldejing > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows.
Applied on master. Thank you for working on the feature! -Original Message- From: dev On Behalf Of ldejing Sent: Monday, April 11, 2022 10:18 AM To: d...@openvswitch.org Cc: ldejing Subject: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows. From: ldejing Implementation on Windows: Currently, IPv4 conntrack was supported on the windows platform. In this patch we have implemented ipv6 conntrack functions according to the current logic of the IPv4 conntrack. This implementation has included TcpV6(nat and normal scenario), UdpV6(nat and normal scenario), IcmpV6 conntrack of echo request/reply packet and FtpV6(nat and normal scenario). Testing Topology: On the Windows VM runs on the ESXi host, two hyper-v ports attached to the ovs bridge; one hyper-v port worked as client and the other port worked as server. Testing Case: 1. TcpV6 a) Tcp request/reply conntrack for normal scenario. In this scenario, 20::1 as client, 20::2 as server, it will generate following conntrack entry: (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=tcp) b) Tcp request/reply conntrack for nat scenario. In this scenario, 20::1 as client, 20::10 as floating ip, 21::3 as server, it will generate following conntrack entry: (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=tcp) 2. UdpV6 a) Udp request/reply conntrack for normal scenario. (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=udp) b) Udp request/reply conntrack for nat scenario. (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=udp) 3. IcmpV6: a) Icmpv6 request/reply conntrack for normal scenario. Currently Icmpv6 only support to construct conntrack for echo request/reply packet, take (20::1 -> 20::2) for example, it will generate following conntrack entry: (origin(src = 20::1, dst=20::2), reply(src=20::2, dst=20::1), protocol=icmp) b) Icmp request/reply conntrack for dnat scenario, for example (20::1->20::10->21::3), 20::1 is client, 20::10 is floating ip, 21::3 is server ip. It will generate flow like below: (origin(src=20::1, dst=20::10), reply(src=21::3, dst=20::1), protocol=icmp) 4. FtpV6 a) Ftp request/reply conntrack for normal scenario. In this scenario, take 20::1 as client, 20::2 as server, it will generate two conntrack entries: Ftp active mode (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), reply(src=20::2, src_port=21, dst=20::1, dst_port=1555), protocol=tcp) (Origin(src=20::2, src_port=20, dst=20::1, dst_port=1556), reply(src=20::1, src_port=1556, dst=20::2, dst_port=20), protocol=tcp) Ftp passive mode (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), reply(src=20::2,src_port=21,dst=20::1,dst_port=1555),protocol=tcp) (Origin(src=20::1, src_port=1556, dst=20::2, dst_port=1557), reply(src=20::2,src_port=1557, dst=20::1, dst_port=1556) protocol=tcp) b) Ftp request/reply conntrack for nat scenario. Ftp passive mode, In this secnario, 20::1 as client, 20::10 as floating ip, 21::3 as server ip. It will generate following flow: (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=21), reply(src=21::3, src_port=21, dst=20::1, dst_port= 1555),protocol=tcp) (Origin(src=20::1, src_port=1556, dst=20::10, dst_port=1557), reply(src=21::3, src_port=1557, dst=20::1, dst_port= 1556),protocol=tcp) 5. Regression test for IpV4 in Antrea project (about 60 test case) Future work: 1) IcmpV6 redirect packet conntrack. 2) IpV6 fragment support on Udp. 3) Support napt for IPv6. 4) FtpV6 active mode for nat. Signed-off-by: ldejing ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows.
References: <20220411071810.41542-1-svc.ovs-commun...@vmware.com> Bleep bloop. Greetings ldejing, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. build: reading sources... [ 88%] topics/ovsdb-relay reading sources... [ 89%] topics/ovsdb-replication reading sources... [ 90%] topics/porting reading sources... [ 90%] topics/record-replay reading sources... [ 91%] topics/testing reading sources... [ 92%] topics/tracing reading sources... [ 93%] topics/usdt-probes reading sources... [ 94%] topics/userspace-tso reading sources... [ 95%] topics/userspace-tx-steering reading sources... [ 95%] topics/windows reading sources... [ 96%] tutorials/faucet reading sources... [ 97%] tutorials/index reading sources... [ 98%] tutorials/ipsec reading sources... [ 99%] tutorials/ovs-advanced reading sources... [100%] tutorials/ovs-conntrack deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_ io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12- 16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: i o.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since "Docutils 0.10 (2012-12-16)" and will soon be removed.deprecation warning: io.FileInput() argument `handle_io_errors` is ignored since
Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows.
References: <20220411055233.14435-1-svc.ovs-commun...@vmware.com> Bleep bloop. Greetings ldejing, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. build: Tunnel - VXLAN 3.12 1.10 2.4 YES Tunnel - Geneve 3.18 2.4 2.4 YES Tunnel - GRE-IPv6 4.18 2.6 2.6 NO Tunnel - VXLAN-IPv6 4.32.6 2.6 NO Tunnel - Geneve-IPv64.42.6 2.6 YES Tunnel - ERSPAN 4.18 2.10 2.10 NO Tunnel - ERSPAN-IPv64.18 2.10 2.10 NO Tunnel - GTP-U NO NO 2.14 NO Tunnel - Bareudp5.7NO NO NO QoS - Policing YES1.1 2.6 NO QoS - Shaping YES1.1 NO NO sFlow YES1.0 1.0 NO IPFIX 3.10 1.11 1.11 YES Set action YES1.0 1.0PARTIAL NIC Bonding YES1.0 1.0 YES Multiple VTEPs YES1.10 1.10 YES Meter action4.15 2.10 2.7 NO check_pkt_len action5.22.12 2.12 NO == == == = === make[2]: *** [docs-check] Error 1 make[2]: Leaving directory `/var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace' make: *** [all] Error 2 Please check this out. If you feel there has been an error, please email acon...@redhat.com Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: Add IPv6 conntrack support on Windows.
References: <20220411024241.81927-1-svc.ovs-commun...@vmware.com> Bleep bloop. Greetings ldejing, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. checkpatch: WARNING: Line is 80 characters long (recommended limit is 79) #153 FILE: Documentation/intro/install/windows.rst:781: > netsh int ipv6 set neighbors $Vif38Name $Vif40Address $Vif40MacAddressCli WARNING: Line is 80 characters long (recommended limit is 79) #154 FILE: Documentation/intro/install/windows.rst:782: > netsh int ipv6 set neighbors $Vif40Name $Vif38Address $Vif38MacAddressCli WARNING: Line is 110 characters long (recommended limit is 79) #156 FILE: Documentation/intro/install/windows.rst:784: > ovs-ofctl add-flow br-int "table=0,priority=1,ip6,ipv6_dst=$Vif40Address,$Protocol,actions=ct(table=1)" WARNING: Line is 110 characters long (recommended limit is 79) #157 FILE: Documentation/intro/install/windows.rst:785: > ovs-ofctl add-flow br-int "table=0,priority=1,ip6,ipv6_dst=$Vif38Address,$Protocol,actions=ct(table=1)" WARNING: Line is 112 characters long (recommended limit is 79) #158 FILE: Documentation/intro/install/windows.rst:786: > ovs-ofctl add-flow br-int "table=1,priority=1,ip6,ct_state=+new+trk,$Protocol,actions=ct(commit,table=2)" WARNING: Line is 116 characters long (recommended limit is 79) #159 FILE: Documentation/intro/install/windows.rst:787: > ovs-ofctl add-flow br-int "table=1,priority=2,ip6,ct_state=-new+rpl+trk,$Protocol,actions=ct(commit,table=2)" WARNING: Line is 116 characters long (recommended limit is 79) #160 FILE: Documentation/intro/install/windows.rst:788: > ovs-ofctl add-flow br-int "table=1,priority=1,ip6,ct_state=+trk+est-new,$Protocol,actions=ct(commit,table=2)" WARNING: Line is 116 characters long (recommended limit is 79) #161 FILE: Documentation/intro/install/windows.rst:789: > ovs-ofctl add-flow br-int "table=2,priority=1,ip6,ipv6_dst=$Vif38Address,$Protocol,actions=output:$Vif38Port" WARNING: Line is 116 characters long (recommended limit is 79) #162 FILE: Documentation/intro/install/windows.rst:790: > ovs-ofctl add-flow br-int "table=2,priority=1,ip6,ipv6_dst=$Vif40Address,$Protocol,actions=output:$Vif40Port" WARNING: Line is 103 characters long (recommended limit is 79) #166 FILE: Documentation/intro/install/windows.rst:794: Due to not construct flow to return neighbor mac address, we set the neighbor mac address manually WARNING: Line is 138 characters long (recommended limit is 79) #183 FILE: Documentation/intro/install/windows.rst:811: > ovs-ofctl add-flow br-int "table=0, priority=2,ipv6,dl_dst=$NatMacAddress,ct_state=-trk,$Protocol actions=ct(table=1,zone=456,nat)" WARNING: Line is 121 characters long (recommended limit is 79) #184 FILE: Documentation/intro/install/windows.rst:812: > ovs-ofctl add-flow br-int "table=0, priority=1,ipv6,ct_state=-trk,ip6,$Protocol actions=ct(nat, zone=456,table=1)" WARNING: Line is 262 characters long (recommended limit is 79) #185 FILE: Documentation/intro/install/windows.rst:813: > ovs-ofctl add-flow br-int "table=1, ipv6,in_port=$Vif38Port,ipv6_dst=$NatAddress,$Protocol,ct_state=+trk+new, actions=ct(commit,nat(dst=$Vif42Ip),zone=456,exec(set_field:1->ct_mark)),mod_dl_src=$NatMacAddress,mod_dl_dst=$Vif42MacAddress,output:$Vif42Port" WARNING: Line is 93 characters long (recommended limit is 79) #186 FILE: Documentation/intro/install/windows.rst:814: > ovs-ofctl add-flow br-int "table=1, ipv6,ct_state=+dnat,$Protocol,action=resubmit(,2)" WARNING: Line is 97 characters long (recommended limit is 79) #187 FILE: Documentation/intro/install/windows.rst:815: > ovs-ofctl add-flow br-int "table=1, ipv6,ct_state=+trk+snat,$Protocol,action=resubmit(,2)" WARNING: Line is 176 characters long (recommended limit is 79) #188 FILE: Documentation/intro/install/windows.rst:816: > ovs-ofctl add-flow br-int "table=2, ipv6,in_port=$Vif38Port,ipv6_dst=$Vif42Ip,$Protocol, actions=mod_dl_src=$NatMacAddress,mod_dl_dst=$Vif42MacAddress,output:$Vif42Port" WARNING: Line is 197 characters long (recommended limit is 79) #189 FILE: Documentation/intro/install/windows.rst:817: > ovs-ofctl add-flow br-int "table=2, ipv6,in_port=$Vif42Port,ct_state=-new+est,ct_mark=1,ct_zone=456,$Protocol,actions=mod_dl_src=$NatMacAddress,mod_dl_dst=$Vif38MacAddress,output:$Vif38Port" WARNING: Line is 91 characters long (recommended limit is 79) #193 FILE: Documentation/intro/install/windows.rst:821: Ftp is a specific protocol, it contains an related flow, we need to match is related state. WARNING: Line is 80 characters long (recommended limit is 79) #208 FILE: Documentation/intro/install/windows.rst:836: > netsh int ipv6 set neighbors $Vif38Name $Vif40Address $Vif40MacAddressCli WARNING: Line is 80 characters long (recommended limit is 79) #209 FILE:
