Re: [vpp-dev] VPP - ixia tests failing
In the above iperf3 test I only have three machines, macbook, windows and vpp and all three connected via Ethernet. macbook <--> vpp <--> windows MTU on all interfaces is the default 1500 "show nat virtual reassembly" shows: NAT IPv4 virtual fragmentation reassembly is ENABLED max-reassemblies 1024 max-fragments 5 timeout 2sec reassemblies: NAT IPv6 virtual fragmentation reassembly is ENABLED max-reassemblies 1024 max-fragments 5 timeout 2sec reassemblies: Thanks On Fri, Mar 1, 2019 at 1:03 AM Benoit Ganne (bganne) wrote: > Again, VPP tells you the error: on packet 20 (1st packet on > GigabitEthernet5/0/0), you get a fragmented IPv4 packet and NAT reassembly > drops the fragment. Check the status of the reassembly with "show nat > virtual-reassembly" and update your conf accordingly with "nat > virtual-reassembly". > That said, you should not get fragmented packets in the 1st place in a > correctly configured network. Check the MTU of all your interfaces > (including clients, AP etc.). > > Best > Ben > > > -Original Message- > > From: Carlito Nueno > > Sent: vendredi 1 mars 2019 00:09 > > To: Carlito Nueno > > Cc: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io > > Subject: Re: [vpp-dev] VPP - ixia tests failing > > > > Ethernet hardware: > > Ethernet controller: Intel Corporation I211 Gigabit Network Connection > > (rev 03) > > > > I ran a few tests using iperf3, between: > > macbook pro: 10.155.3.21 <--> connected to vpp port 10.155.3.1 > > Windows: 10.155.6.111 <--> connected to vpp port 10.155.6.1 > > > > Ping works from macbook to windows and vice versa. > > > > iperf3 TCP works: iperf3 -s -B > > macbook (10.155.3.21) as server <--> windows (10.155.6.111) as client and > > vice versa > > > > iperf3 tcp trace macbook server: > > https://gist.github.com/ironpillow/3540616a5b32638e895023e3b3e13be8 > > iperf3 tcp trace windows server: > > https://gist.github.com/ironpillow/2b9a421d4e6fbb2a4751727b34f8f5c8 > > > > iperf3 UDP ONLY works > > windows (10.155.6.111) as server <--> macbook (10.155.3.21) as client. > > iperf3 udp trace windows server: > > https://gist.github.com/ironpillow/baecf1391864fba4e79a24670116db60 > > > > iperf3 UDP does NOT work > > macbook ((10.155.3.21) as server <---> windows (10.155.6.111) as client. > > > > 01:17:50:122097: error-drop > > nat44-in2out-reass: Maximum reassemblies exceeded > > > > iperf3 udp trace macbook server: > > https://gist.github.com/ironpillow/ae93db2224de2730ce0115d8df22c9d1 > > > > Thanks. > > > > On Thu, Feb 28, 2019 at 10:22 AM carlito nueno via Lists.Fd.Io > > wrote: > > > > > > Hi Benoit, > > > > > > I had a similar issue without the AP. I connected: > > > client (ixia) --> GigabitEthernet4/0/0.3 --> vpp --> > > > GigabitEthernet5/0/0 (ixia) > > > > > > Same problem. Ixia on GigabitEthernet5/0/0 was not receiving packets. > > > But traffic the other way was working fine. > > > > > > Thanks > > > > > > On Thu, Feb 28, 2019 at 12:49 AM Benoit Ganne (bganne) > > wrote: > > > > > > > > Hi Carlito, > > > > > > > > Something looks fishy in the 1st trace (the failing one): dpdk-input > > advertise a 60B packet length, (which should not happen, this is too > small > > for Ethernet anyway), and you can see the ip4-input reporting that the > > advertised packet length in the IP header is 768B + incorrect checksum. > > > > Finally, error-drop gracefully tells you why it decided to drop it: > > ip4-input: ip4 length > l2 length. And it is probably right. > > > > I would 1st check the packets you receive from the AP as they seem to > > be truncated. That could be an AP issue or (more probable) a dpdk driver > > issue. > > > > > > > > Best > > > > Ben > > > > > > > > > -Original Message- > > > > > From: vpp-dev@lists.fd.io On Behalf Of > > > > > carlito nueno > > > > > Sent: jeudi 28 février 2019 03:44 > > > > > To: vpp-dev@lists.fd.io > > > > > Subject: [vpp-dev] VPP - ixia tests failing > > > > > > > > > > Hi all, > > > > > > > > > > I got a chance to get my hands on an ixia testing box. > > > > > Unfortunately I was not able to test because upstream (from > > > > > ethernet to client) was no
Re: [vpp-dev] VPP - ixia tests failing
Again, VPP tells you the error: on packet 20 (1st packet on GigabitEthernet5/0/0), you get a fragmented IPv4 packet and NAT reassembly drops the fragment. Check the status of the reassembly with "show nat virtual-reassembly" and update your conf accordingly with "nat virtual-reassembly". That said, you should not get fragmented packets in the 1st place in a correctly configured network. Check the MTU of all your interfaces (including clients, AP etc.). Best Ben > -Original Message- > From: Carlito Nueno > Sent: vendredi 1 mars 2019 00:09 > To: Carlito Nueno > Cc: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] VPP - ixia tests failing > > Ethernet hardware: > Ethernet controller: Intel Corporation I211 Gigabit Network Connection > (rev 03) > > I ran a few tests using iperf3, between: > macbook pro: 10.155.3.21 <--> connected to vpp port 10.155.3.1 > Windows: 10.155.6.111 <--> connected to vpp port 10.155.6.1 > > Ping works from macbook to windows and vice versa. > > iperf3 TCP works: iperf3 -s -B > macbook (10.155.3.21) as server <--> windows (10.155.6.111) as client and > vice versa > > iperf3 tcp trace macbook server: > https://gist.github.com/ironpillow/3540616a5b32638e895023e3b3e13be8 > iperf3 tcp trace windows server: > https://gist.github.com/ironpillow/2b9a421d4e6fbb2a4751727b34f8f5c8 > > iperf3 UDP ONLY works > windows (10.155.6.111) as server <--> macbook (10.155.3.21) as client. > iperf3 udp trace windows server: > https://gist.github.com/ironpillow/baecf1391864fba4e79a24670116db60 > > iperf3 UDP does NOT work > macbook ((10.155.3.21) as server <---> windows (10.155.6.111) as client. > > 01:17:50:122097: error-drop > nat44-in2out-reass: Maximum reassemblies exceeded > > iperf3 udp trace macbook server: > https://gist.github.com/ironpillow/ae93db2224de2730ce0115d8df22c9d1 > > Thanks. > > On Thu, Feb 28, 2019 at 10:22 AM carlito nueno via Lists.Fd.Io > wrote: > > > > Hi Benoit, > > > > I had a similar issue without the AP. I connected: > > client (ixia) --> GigabitEthernet4/0/0.3 --> vpp --> > > GigabitEthernet5/0/0 (ixia) > > > > Same problem. Ixia on GigabitEthernet5/0/0 was not receiving packets. > > But traffic the other way was working fine. > > > > Thanks > > > > On Thu, Feb 28, 2019 at 12:49 AM Benoit Ganne (bganne) > wrote: > > > > > > Hi Carlito, > > > > > > Something looks fishy in the 1st trace (the failing one): dpdk-input > advertise a 60B packet length, (which should not happen, this is too small > for Ethernet anyway), and you can see the ip4-input reporting that the > advertised packet length in the IP header is 768B + incorrect checksum. > > > Finally, error-drop gracefully tells you why it decided to drop it: > ip4-input: ip4 length > l2 length. And it is probably right. > > > I would 1st check the packets you receive from the AP as they seem to > be truncated. That could be an AP issue or (more probable) a dpdk driver > issue. > > > > > > Best > > > Ben > > > > > > > -Original Message- > > > > From: vpp-dev@lists.fd.io On Behalf Of > > > > carlito nueno > > > > Sent: jeudi 28 février 2019 03:44 > > > > To: vpp-dev@lists.fd.io > > > > Subject: [vpp-dev] VPP - ixia tests failing > > > > > > > > Hi all, > > > > > > > > I got a chance to get my hands on an ixia testing box. > > > > Unfortunately I was not able to test because upstream (from > > > > ethernet to client) was not > > > > working: > > > > > > > > Not working: ixia on ethernet is not receiving packets client > > > > (ixia) --> WiFi AP --> GigabitEthernet4/0/0.3 --> vpp --> > > > > GigabitEthernet5/0/0 (ixia) > > > > > > > > The other way is working: ixia client is receiving packets > > > > (ixia)GigabitEthernet5/0/0 --> vpp --> GigabitEthernet4/0/0.3 --> > > > > wifi AP > > > > --> client (ixia) > > > > > > > > Both TCP and UDP tests failed. Packets are being dropped by VPP > > > > (error- drop, null-node: blackholed packets). > > > > > > > > running: vpp v18.10-rc0~229-g869031c5 > > > > > > > > ixia mac addresses: > > > > client: 00:21:dd:xx:xx:xx > > > > server: 00:11:dd:xx:xx:xx > > > > > > > > wifi access point mac address: > > > > AP: a4:c5:ef:xx:xx:xx &g
Re: [vpp-dev] VPP - ixia tests failing
Ethernet hardware: Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) I ran a few tests using iperf3, between: macbook pro: 10.155.3.21 <--> connected to vpp port 10.155.3.1 Windows: 10.155.6.111 <--> connected to vpp port 10.155.6.1 Ping works from macbook to windows and vice versa. iperf3 TCP works: iperf3 -s -B macbook (10.155.3.21) as server <--> windows (10.155.6.111) as client and vice versa iperf3 tcp trace macbook server: https://gist.github.com/ironpillow/3540616a5b32638e895023e3b3e13be8 iperf3 tcp trace windows server: https://gist.github.com/ironpillow/2b9a421d4e6fbb2a4751727b34f8f5c8 iperf3 UDP ONLY works windows (10.155.6.111) as server <--> macbook (10.155.3.21) as client. iperf3 udp trace windows server: https://gist.github.com/ironpillow/baecf1391864fba4e79a24670116db60 iperf3 UDP does NOT work macbook ((10.155.3.21) as server <---> windows (10.155.6.111) as client. 01:17:50:122097: error-drop nat44-in2out-reass: Maximum reassemblies exceeded iperf3 udp trace macbook server: https://gist.github.com/ironpillow/ae93db2224de2730ce0115d8df22c9d1 Thanks. On Thu, Feb 28, 2019 at 10:22 AM carlito nueno via Lists.Fd.Io wrote: > > Hi Benoit, > > I had a similar issue without the AP. I connected: > client (ixia) --> GigabitEthernet4/0/0.3 --> vpp --> > GigabitEthernet5/0/0 (ixia) > > Same problem. Ixia on GigabitEthernet5/0/0 was not receiving packets. > But traffic the other way was working fine. > > Thanks > > On Thu, Feb 28, 2019 at 12:49 AM Benoit Ganne (bganne) > wrote: > > > > Hi Carlito, > > > > Something looks fishy in the 1st trace (the failing one): dpdk-input > > advertise a 60B packet length, (which should not happen, this is too small > > for Ethernet anyway), and you can see the ip4-input reporting that the > > advertised packet length in the IP header is 768B + incorrect checksum. > > Finally, error-drop gracefully tells you why it decided to drop it: > > ip4-input: ip4 length > l2 length. And it is probably right. > > I would 1st check the packets you receive from the AP as they seem to be > > truncated. That could be an AP issue or (more probable) a dpdk driver issue. > > > > Best > > Ben > > > > > -----Original Message----- > > > From: vpp-dev@lists.fd.io On Behalf Of carlito nueno > > > Sent: jeudi 28 février 2019 03:44 > > > To: vpp-dev@lists.fd.io > > > Subject: [vpp-dev] VPP - ixia tests failing > > > > > > Hi all, > > > > > > I got a chance to get my hands on an ixia testing box. Unfortunately I was > > > not able to test because upstream (from ethernet to client) was not > > > working: > > > > > > Not working: ixia on ethernet is not receiving packets client (ixia) --> > > > WiFi AP --> GigabitEthernet4/0/0.3 --> vpp --> > > > GigabitEthernet5/0/0 (ixia) > > > > > > The other way is working: ixia client is receiving packets > > > (ixia)GigabitEthernet5/0/0 --> vpp --> GigabitEthernet4/0/0.3 --> wifi AP > > > --> client (ixia) > > > > > > Both TCP and UDP tests failed. Packets are being dropped by VPP (error- > > > drop, null-node: blackholed packets). > > > > > > running: vpp v18.10-rc0~229-g869031c5 > > > > > > ixia mac addresses: > > > client: 00:21:dd:xx:xx:xx > > > server: 00:11:dd:xx:xx:xx > > > > > > wifi access point mac address: > > > AP: a4:c5:ef:xx:xx:xx > > > > > > I don't have ACLs setup. > > > > > > Here is my vpp.conf and packet capture: > > > https://gist.github.com/ironpillow/9b1c5dd0905135ff09eba6067db179ae > > > > > > Any advice? > > > > > > Thanks > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#12391): https://lists.fd.io/g/vpp-dev/message/12391 > Mute This Topic: https://lists.fd.io/mt/30159793/675621 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [carlitonu...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12399): https://lists.fd.io/g/vpp-dev/message/12399 Mute This Topic: https://lists.fd.io/mt/30159793/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP - ixia tests failing
Hi Benoit, I had a similar issue without the AP. I connected: client (ixia) --> GigabitEthernet4/0/0.3 --> vpp --> GigabitEthernet5/0/0 (ixia) Same problem. Ixia on GigabitEthernet5/0/0 was not receiving packets. But traffic the other way was working fine. Thanks On Thu, Feb 28, 2019 at 12:49 AM Benoit Ganne (bganne) wrote: > > Hi Carlito, > > Something looks fishy in the 1st trace (the failing one): dpdk-input > advertise a 60B packet length, (which should not happen, this is too small > for Ethernet anyway), and you can see the ip4-input reporting that the > advertised packet length in the IP header is 768B + incorrect checksum. > Finally, error-drop gracefully tells you why it decided to drop it: > ip4-input: ip4 length > l2 length. And it is probably right. > I would 1st check the packets you receive from the AP as they seem to be > truncated. That could be an AP issue or (more probable) a dpdk driver issue. > > Best > Ben > > > -Original Message- > > From: vpp-dev@lists.fd.io On Behalf Of carlito nueno > > Sent: jeudi 28 février 2019 03:44 > > To: vpp-dev@lists.fd.io > > Subject: [vpp-dev] VPP - ixia tests failing > > > > Hi all, > > > > I got a chance to get my hands on an ixia testing box. Unfortunately I was > > not able to test because upstream (from ethernet to client) was not > > working: > > > > Not working: ixia on ethernet is not receiving packets client (ixia) --> > > WiFi AP --> GigabitEthernet4/0/0.3 --> vpp --> > > GigabitEthernet5/0/0 (ixia) > > > > The other way is working: ixia client is receiving packets > > (ixia)GigabitEthernet5/0/0 --> vpp --> GigabitEthernet4/0/0.3 --> wifi AP > > --> client (ixia) > > > > Both TCP and UDP tests failed. Packets are being dropped by VPP (error- > > drop, null-node: blackholed packets). > > > > running: vpp v18.10-rc0~229-g869031c5 > > > > ixia mac addresses: > > client: 00:21:dd:xx:xx:xx > > server: 00:11:dd:xx:xx:xx > > > > wifi access point mac address: > > AP: a4:c5:ef:xx:xx:xx > > > > I don't have ACLs setup. > > > > Here is my vpp.conf and packet capture: > > https://gist.github.com/ironpillow/9b1c5dd0905135ff09eba6067db179ae > > > > Any advice? > > > > Thanks -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12391): https://lists.fd.io/g/vpp-dev/message/12391 Mute This Topic: https://lists.fd.io/mt/30159793/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP - ixia tests failing
Hi Carlito, Something looks fishy in the 1st trace (the failing one): dpdk-input advertise a 60B packet length, (which should not happen, this is too small for Ethernet anyway), and you can see the ip4-input reporting that the advertised packet length in the IP header is 768B + incorrect checksum. Finally, error-drop gracefully tells you why it decided to drop it: ip4-input: ip4 length > l2 length. And it is probably right. I would 1st check the packets you receive from the AP as they seem to be truncated. That could be an AP issue or (more probable) a dpdk driver issue. Best Ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of carlito nueno > Sent: jeudi 28 février 2019 03:44 > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] VPP - ixia tests failing > > Hi all, > > I got a chance to get my hands on an ixia testing box. Unfortunately I was > not able to test because upstream (from ethernet to client) was not > working: > > Not working: ixia on ethernet is not receiving packets client (ixia) --> > WiFi AP --> GigabitEthernet4/0/0.3 --> vpp --> > GigabitEthernet5/0/0 (ixia) > > The other way is working: ixia client is receiving packets > (ixia)GigabitEthernet5/0/0 --> vpp --> GigabitEthernet4/0/0.3 --> wifi AP > --> client (ixia) > > Both TCP and UDP tests failed. Packets are being dropped by VPP (error- > drop, null-node: blackholed packets). > > running: vpp v18.10-rc0~229-g869031c5 > > ixia mac addresses: > client: 00:21:dd:xx:xx:xx > server: 00:11:dd:xx:xx:xx > > wifi access point mac address: > AP: a4:c5:ef:xx:xx:xx > > I don't have ACLs setup. > > Here is my vpp.conf and packet capture: > https://gist.github.com/ironpillow/9b1c5dd0905135ff09eba6067db179ae > > Any advice? > > Thanks -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12384): https://lists.fd.io/g/vpp-dev/message/12384 Mute This Topic: https://lists.fd.io/mt/30159793/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP - ixia tests failing
Hi all, I got a chance to get my hands on an ixia testing box. Unfortunately I was not able to test because upstream (from ethernet to client) was not working: Not working: ixia on ethernet is not receiving packets client (ixia) --> WiFi AP --> GigabitEthernet4/0/0.3 --> vpp --> GigabitEthernet5/0/0 (ixia) The other way is working: ixia client is receiving packets (ixia)GigabitEthernet5/0/0 --> vpp --> GigabitEthernet4/0/0.3 --> wifi AP --> client (ixia) Both TCP and UDP tests failed. Packets are being dropped by VPP (error-drop, null-node: blackholed packets). running: vpp v18.10-rc0~229-g869031c5 ixia mac addresses: client: 00:21:dd:xx:xx:xx server: 00:11:dd:xx:xx:xx wifi access point mac address: AP: a4:c5:ef:xx:xx:xx I don't have ACLs setup. Here is my vpp.conf and packet capture: https://gist.github.com/ironpillow/9b1c5dd0905135ff09eba6067db179ae Any advice? Thanks -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12380): https://lists.fd.io/g/vpp-dev/message/12380 Mute This Topic: https://lists.fd.io/mt/30159793/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
