Hi Prabhjot, In your setup, VPP just switches packets from one interface to the other, irrespective of their L4 checksum. That is, it does not read nor update them. Therefore, since the source Linux interface does not provide correct checksums, the destination rejects all packets.
As you’ve noted lower, although the packets are ultimately delivered to the app, even with the Linux bridge, the checksum is not correctly computed when offloading is on. I suspect the reason for this is an underlying optimization in the Linux kernel whereby local interfaces can exchange L4 packets without the use of checksums. In fact, the approach makes sense because packets never leave the kernel between the sndmsg() and recvmsg() calls so there’s no need to protect data integrity. However, this condition does not hold anymore when vpp does the switching, so the checksums must be computed before the packets leave the kernel (hence the need for checksum offload disabling). Hope this helps, Florin > On Aug 28, 2017, at 11:46 PM, prabh...@techtrueup.com wrote: > > Thanks Florin, > it works with offload disabled, earlier when i tried changing offload > settings i missed doing it on one machine. > > However my question is still about why VPP is unable to handle it, is it a > missing configuration or missing functionality in VPP? > > i can ssh from one vm to another without turning off offload while using > linux bridge, and i don't see any change in the packet as well after being > forwarded. Though tcpdump complains about checksum, but everything works fine. > > packet ingressing into linux bridge from vm-1 > 06:41:58.626869 02:53:71:ef:2f:2a > 02:91:fb:46:9e:43, ethertype IPv4 > (0x0800), length 74: (tos 0x0, ttl 64, id 6341, offset 0, flags [DF], proto > TCP (6), length 60) > 1.1.1.3.51912 > 1.1.1.4.22: Flags [S], cksum 0x0437 (incorrect -> 0xdeae), > seq 2306393024, win 29200, options [mss 1460,sackOK,TS val 1825541 ecr > 0,nop,wscale 7], length 0 > 0x0000: 0291 fb46 9e43 0253 71ef 2f2a 0800 4500 > 0x0010: 003c 18c5 4000 4006 1def 0101 0103 0101 > 0x0020: 0104 cac8 0016 8978 c3c0 0000 0000 a002 > 0x0030: 7210 0437 0000 0204 05b4 0402 080a 001b > 0x0040: db05 0000 0000 0103 0307 > > packet egressing from linux bridge to vm-2 > 06:41:58.627130 02:53:71:ef:2f:2a > 02:91:fb:46:9e:43, ethertype IPv4 > (0x0800), length 74: (tos 0x0, ttl 64, id 6341, offset 0, flags [DF], proto > TCP (6), length 60) > 1.1.1.3.51912 > 1.1.1.4.22: Flags [S], cksum 0x0437 (incorrect -> 0xdeae), > seq 2306393024, win 29200, options [mss 1460,sackOK,TS val 1825541 ecr > 0,nop,wscale 7], length 0 > 0x0000: 0291 fb46 9e43 0253 71ef 2f2a 0800 4500 > 0x0010: 003c 18c5 4000 4006 1def 0101 0103 0101 > 0x0020: 0104 cac8 0016 8978 c3c0 0000 0000 a002 > 0x0030: 7210 0437 0000 0204 05b4 0402 080a 001b > 0x0040: db05 0000 0000 0103 0307 > > > Regards, > Prabhjot > > Quoting Florin Coras <fcoras.li...@gmail.com>: > >> Hi Prabhjot, >> >> From your description, I suspect it may be a linux tcp checksum offload >> issue. Could you try disabling it for all interfaces with: >> >> ethtool --offload <iface_name> rx off tx off >> >> Hope this helps, >> Florin >> >>> On Aug 28, 2017, at 10:56 AM, Prabhjot Singh Sethi >>> <prabh...@techtrueup.com> wrote: >>> >>> We have been trying to use VPP as a L2/L3 forwarding data path between VMs. >>> >>> where we have connected tap interfaces from VM to VPP using "create >>> host-interface name <name>" >>> after adding both the interfaces to same bridge-domain (bd_id = 2), we are >>> able to ping from >>> one VM to another (both in same subnet). However when we try to do ssh we >>> observe that all the >>> tcp packets are transmitted/forwarded by VPP to the other end but they are >>> dropped as >>> "bad segments received". >>> >>> Can anyone help with what could be wrong here, are we missing any other >>> required config? >>> >>> Note:- same VMs works well when connected to linux bridge >>> >>> root@vm-2:~# netstat -s | grep -A11 -i tcp: >>> Tcp: >>> 33 active connections openings >>> 4 passive connection openings >>> 0 failed connection attempts >>> 1 connection resets received >>> 1 connections established >>> 885 segments received >>> 650 segments send out >>> 8 segments retransmited >>> 19 bad segments received. <<<<<<<<<<<<<<<<<<<< Keeps increasing for >>> every tcp packet >>> 2 resets sent >>> InCsumErrors: 19 <<<<<<<<<<<<<<<<<<<< Keeps increasing for >>> every tcp packet >>> root@vm-2:~# >>> >>> Regards, >>> Prabhjot >>> _______________________________________________ >>> vpp-dev mailing list >>> vpp-dev@lists.fd.io >>> https://lists.fd.io/mailman/listinfo/vpp-dev > > _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
