Hi Vijay, You won’t see the syn/syn-acks in traces because of the way they are generated. Nonetheless, you can verify that the syns were received with “show error” and check that the syn-acks were actually generated with a pcap trace rxtx <output interface>
Previously tracing worked because buffers were re-used and incoming packets were directly sent to output. More recently we’ve started dispatching syn-acks through the session layer in order to minimize size of tx bursts per dispatch. Regards, Florin > On Mar 15, 2022, at 6:08 PM, Vijay Kumar <vjkumar2...@gmail.com> wrote: > > 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 > <mailto: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 >> <mailto: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 >> <http://lists.fd.io/> <vjkumar2003=gmail....@lists.fd.io >> <mailto: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 <http://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 (#21029): https://lists.fd.io/g/vpp-dev/message/21029 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] -=-=-=-=-=-=-=-=-=-=-=-
