Hi Florin, Thanks for the quick response.
It means it is expected to see the SYN pkts getting dropped after it is terminated but I was not able to see any SYN-ACK going out of VPP. In both, "show trace" cmd output and also the pcap taken at dspatch graph node level, I was not able to see the SYN-ACK going out. The route to the SYN-ACK destination (which is the original source that started SYN) is also present in the ip fib output. The configuration is the same that was working fine for me in vp 20.05. Is there anything that I can look at for the SYN-ACK not sending issue? On Wed, 16 Mar 2022, 00:40 Florin Coras, <fcoras.li...@gmail.com> wrote: > Hi Vijay, > > I see an_ppe_router_input forwards syns to tcp-input and those packets are > delivered to tcp-listen, i.e., you’ve created a listener that’s matched by > the incoming traffic. > > The thing to keep in mind is that tcp terminates incoming flows and it > does not reuse buffers. That is, the syn hits the listen node and a syn-ack > is programmed for this new connection that still needs to complete the > handshake. The original syn packet is discarded and therefore you see it as > a drop. > > Regards, > Florin > > On Mar 15, 2022, at 3:50 AM, Vijay Kumar <vjkumar2...@gmail.com> wrote: > > The is the output of show trace and show interface > ============================================ > > Packet 36 > > 00:03:26:875694: dpdk-input > VirtualFuncEthernet0/7/0 rx queue 0 > buffer 0x4c1b21: current data 0, length 138, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x1000023 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 0, nb_segs 1, pkt_len 138 > buf_len 2176, data_len 138, ol_flags 0x182, data_off 128, phys_addr > 0xc266c8c0 > packet_type 0x691 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0xde0c21da fdir.hi 0x0 fdir.lo 0xde0c21da > Packet Offload Flags > PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without > extension headers > RTE_PTYPE_L4_NONFRAG (0x0600) Non-fragmented IP packet > IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:97:04:19 802.1q vlan 1556 > IPSEC_ESP: 20.20.99.215 -> 80.80.80.80 > tos 0x00, ttl 64, length 120, checksum 0x21c9 dscp CS0 ecn NON_ECN > fragment id 0x0000, flags DONT_FRAGMENT > 00:03:26:875702: ethernet-input > frame: flags 0x3, hw-if-index 3, sw-if-index 3 > IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:97:04:19 802.1q vlan 1556 > 00:03:26:875708: ip4-input > IPSEC_ESP: 20.20.99.215 -> 80.80.80.80 > tos 0x00, ttl 64, length 120, checksum 0x21c9 dscp CS0 ecn NON_ECN > fragment id 0x0000, flags DONT_FRAGMENT > 00:03:26:875714: ip4-lookup > fib 2 dpo-idx 27 flow hash: 0x00000000 > IPSEC_ESP: 20.20.99.215 -> 80.80.80.80 > tos 0x00, ttl 64, length 120, checksum 0x21c9 dscp CS0 ecn NON_ECN > fragment id 0x0000, flags DONT_FRAGMENT > 00:03:26:875715: ip4-local > IPSEC_ESP: 20.20.99.215 -> 80.80.80.80 > tos 0x00, ttl 64, length 120, checksum 0x21c9 dscp CS0 ecn NON_ECN > fragment id 0x0000, flags DONT_FRAGMENT > 00:03:26:875717: ipsec4-tun-input > IPSec: remote:20.20.99.215 spi:4213 (0x00001075) sa:1 tun:0 seq 1 sa > -2029505104 > 00:03:26:875719: esp4-decrypt-tun > esp: crypto aes-cbc-256 integrity sha1-96 pkt-seq 1 sa-seq 1 sa-seq-hi 0 > 00:03:26:875801: ip4-input-no-checksum > TCP: 44.44.44.44 -> 30.30.30.30 > tos 0x00, ttl 64, length 60, checksum 0x3cfa dscp CS0 ecn NON_ECN > fragment id 0x692e, flags DONT_FRAGMENT > TCP: 45723 -> 1234 > seq. 0x119d35d0 ack 0x00000000 > flags 0x02 SYN, tcp header: 40 bytes > window 64240, checksum 0xd6be > 00:03:26:875803: ip4-lookup > fib 2 dpo-idx 25 flow hash: 0x00000000 > TCP: 44.44.44.44 -> 30.30.30.30 > tos 0x00, ttl 64, length 60, checksum 0x3cfa dscp CS0 ecn NON_ECN > fragment id 0x692e, flags DONT_FRAGMENT > TCP: 45723 -> 1234 > seq. 0x119d35d0 ack 0x00000000 > flags 0x02 SYN, tcp header: 40 bytes > window 64240, checksum 0xd6be > 00:03:26:875803: ip4-local > TCP: 44.44.44.44 -> 30.30.30.30 > tos 0x00, ttl 64, length 60, checksum 0x3cfa dscp CS0 ecn NON_ECN > fragment id 0x692e, flags DONT_FRAGMENT > TCP: 45723 -> 1234 > seq. 0x119d35d0 ack 0x00000000 > flags 0x02 SYN, tcp header: 40 bytes > window 64240, checksum 0xd6be > 00:03:26:875805: an_ppe_router_input > AN_PPE_ROUTER_INPUT: sw_if_index 1, next index 3 > > 00:03:26:875819: tcp4-input > [0:0][T] :::0->:::0 state CLOSED > TCP: 45723 -> 1234 > seq. 0x119d35d0 ack 0x00000000 > flags 0x02 SYN, tcp header: 40 bytes > window 64240, checksum 0xd6be > 00:03:26:875826: tcp4-listen > 1234 -> 45723 (LISTEN) > > > Interface details > ==================== > vpp# show interface > Name Idx State MTU (L3/IP4/IP6/MPLS) > Counter Count > VirtualFuncEthernet0/7/0 3 up 1500/0/0/0 rx > packets 3922 > rx > bytes 239610 > tx > packets 17 > tx > bytes 6704 > drops > 3914 > VirtualFuncEthernet0/7/0.1557 13 up 1500/0/0/0 > VirtualFuncEthernet0/7/0.1556 14 up 1500/0/0/0 rx > packets 22 > rx > bytes 5130 > tx > packets 17 > tx > bytes 6704 > drops > 14 > ip4 > 19 > VirtualFuncEthernet0/8/0 4 down 9000/0/0/0 > gre1 2 up 9000/0/0/0 > ipip0 1 up 9000/0/0/0 rx > packets 5 > rx > bytes 500 > ip4 > 5 > local0 0 down 0/0/0/0 > loop2 8 up 9000/0/0/0 > loop3 9 up 9000/0/0/0 > loop4 10 up 9000/0/0/0 > loop5 11 up 9000/0/0/0 > loop6 12 up 9000/0/0/0 > memif0/0 5 up 0/65535/0/0 rx > packets 1036 > rx > bytes 67766832 > tx > packets 1049 > tx > bytes 67822842 > drops > 2 > ip4 > 1036 > memif128/0 6 up 0/65535/0/0 > memif192/0 7 up 0/65535/0/0 > memif210/0 15 up 0/65535/0/0 > memif210/1 16 up 0/65535/0/0 > vpp# > vpp# > > On Tue, Mar 15, 2022 at 2:32 PM Vijay Kumar via lists.fd.io <vjkumar2003= > gmail....@lists.fd.io> wrote: > >> Hi experts, >> >> I recently integrated vpp stack 21.06 and am running my NAS TCP protocol >> test cases. The pcap dispatch trace that I captured shows the TCP SYN >> packets are coming to tcp-input() and then to tcp-listen() but from here >> pkts are dropped instead of going to tcp-output() graph nodes for sending >> the SYN-ACK >> >> NOTE >> ========= >> The session layer is enabled and the TCP listen IP/port is also showing >> in the session verbose command. >> >> The same test case used to work fine in the VPP 20.05. Am I missing >> anything? >> Let me know if there is anything I need to look at. >> >> vpp# show session verbose >> Connection State >> Rx-f Tx-f >> [0:0][T] 30.30.30.30:1234->0.0.0.0:0 LISTEN >> 0 0 >> Thread 0: active sessions 1 >> Thread 1: no sessions >> >> >> >> > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21028): https://lists.fd.io/g/vpp-dev/message/21028 Mute This Topic: https://lists.fd.io/mt/89793823/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
