Thank you Han, I will check out this fix. From: Han Zhou <zhou...@gmail.com> Sent: Thursday, May 2, 2019 10:11 PM To: Zhang, Jing C. (Nokia - CA/Ottawa) <jing.c.zh...@nokia.com> Cc: ovs-discuss@openvswitch.org Subject: Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty payload TCP packets continued
On Thu, May 2, 2019 at 6:04 PM Zhang, Jing C. (Nokia - CA/Ottawa) <jing.c.zh...@nokia.com<mailto:jing.c.zh...@nokia.com>> wrote: > > We (our VNFs) continue to observe the same empty payload TCP (ACK) packet > drop with native firewall (see original post below) after upgrading to Centos > 7.6. This packet drop results in unacceptable TCP performance, by that native > firewall still can not be enabled in product. > > https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047263.html > > $ uname -a > Linux overcloud-sriovperformancecompute-0 3.10.0-957.10.1.el7.x86_64 #1 SMP > Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > > $ ovs-vswitchd --version > ovs-vswitchd (Open vSwitch) 2.9.0 > DPDK 17.11.0 > > The scenario: OVS provider VLAN network is used > > > in physical interface of ovs compute zero length tcp payload packet arrives > as padded to 64 bytes (and vlan tag is included in ethernet header) > same packet does not appear anymore in the tcpdump taken from tap-xyz > interface (once vlan tag is removed and packet is cut by 4 bytes to 60 bytes) > > > Tcpdump on physical port: > > 00:25:24.468423 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q > (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id > 6893, offset 0, flags [DF], proto TCP (6), length 2656) > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013 > (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP > 00:25:24.468593 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q > (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id > 56318, offset 0, flags [DF], proto TCP (6), length 40) > 192.168.10.60.57576 > 192.168.10.52.80: Flags [.], cksum 0x1d34 > (correct), seq 78, ack 11577, win 391, length 0 > 00:25:24.475848 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q > (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id > 56319, offset 0, flags [DF], proto TCP (6), length 40) > 192.168.10.60.57576 > 192.168.10.52.80: Flags [F.], cksum 0x1d33 > (correct), seq 78, ack 11577, win 391, length 0 > 00:25:24.480337 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q > (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id > 6894, offset 0, flags [DF], proto TCP (6), length 2656) > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013 > (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP > > Tcpdump on vm tap interface: > > 00:25:24.468419 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype IPv4 > (0x0800), length 2670: (tos 0x0, ttl 64, id 6893, offset 0, flags [DF], proto > TCP (6), length 2656) > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013 > (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP > 00:25:24.480331 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype IPv4 > (0x0800), length 2670: (tos 0x0, ttl 64, id 6894, offset 0, flags [DF], proto > TCP (6), length 2656) > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013 > (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP > > Very straightforward to see the issue: > > > Configure neutron OVS agent to use native firewall > Create a pair of VMs on separate computes on provider vLAN > Disable TCP timestamp inside the VMs > Exchange TCP traffic between the VMs, e.g. http download. > Tcpdump on the physical and vm port, and compare. > > > I wonder why such obvious issue is not widely discussed? > > Jing > Maybe it's fixed by: https://github.com/openvswitch/ovs/commit/9171c63532ee9cbc63bb8cfae364ab071f44389b
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
