Many many thanks! Florin Coras via lists.fd.io <[email protected]> 于2025年11月27日周四 00:48写道：
> Either the network is very noisy or something about the config is not > exactly right as session layer/tcp generate only about 10k packets but > there are almost 50k blackholed packets, 190k failed uRPF checks. Some of > the former and l2 drops might register as interface drops. > > As for tcp, it apparently accepted around 100 connections, so I’m guessing > 50 per nginx instance, but errors of the type “no listener for dst port” > suggest that either packets are corrupted or nginx stopped listening at one > point (“sh session verbose” to see if the listeners are up). The bvi mac > mismatch errors might also be indicative of potential drops when > establishing new connections. > > Regards, > Florin > > On Nov 26, 2025, at 1:41 AM, Guo Huiliang via lists.fd.io <huiliang.guo= > [email protected]> wrote: > > > run vppctl sh error I got as below: > Count Node Reason > Severity > 48029 null-node blackholed packets > error > 1048 lldp-input lldp packets received on > disabled i error > 164 igmp-input IGMP not enabled on this > interface error > 159031 arp-reply ARP replies sent > info > 4 arp-reply IP4 source address not local > to sub error > 2710 arp-reply IP4 destination address not > local t error > 4 arp-reply ARP request IP4 source > address lear info > 1083 arp-input IP4 destination address is > unset error > 10568 session-queue Packets transmitted > info > 18 ip4-udp-lookup No listener for dst > port error > 36 tcp4-input no listener for dst > port error > 28 tcp4-input Invalid ACK > error > 5 tcp4-input Invalid connection > error > 29 tcp4-input Connection closed > warn > 103 tcp4-listen SYNs received > info > 1 tcp4-rcv-process Packets pushed into rx > fifo info > 420 tcp4-rcv-process Pure ACKs received > info > 7 tcp4-rcv-process Resets received > info > 3 tcp4-rcv-process Segment not in receive > window warn > 82 tcp4-rcv-process FINs received > info > 137 tcp4-syn-sent SYN-ACKs received > info > 19 tcp4-syn-sent Segment not in receive > window warn > 6779 tcp4-established Packets pushed into rx > fifo info > 2 tcp4-established OOO packets pushed into rx > fifo warn > 150 tcp4-established Old segment > warn > 2848 tcp4-established Pure ACKs received > info > 2 tcp4-established Resets received > info > 11 tcp4-established Segment not in receive > window warn > 120 tcp4-established FINs received > info > 65 tcp4-reset Resets sent > info > 10810 tcp4-output Packets sent > info > 53 tcp4-output Resets sent > info > 4 tcp4-output Invalid connection > error > 2 ip4-glean ARP requests sent > info > 2 ip4-arp ARP requests sent > info > 190928 ip4-input Multicast RPF check > failed error > 14 ip4-local bad tcp checksum > error > 18 ip4-icmp-error destination unreachable > response se info > 755959 l2-output L2 output packets > error > 754558 l2-learn L2 learn packets > error > 150 l2-learn L2 learn misses > error > 766931 l2-input L2 input packets > error > 144 l2-fwd Reflection Drop > error > 466729 l2-flood L2 flood packets > error > 48 l2-flood BVI L3 mac mismatch > error > 63697 l2-flood BVI packet with unhandled > ethertype error > 1 arp-term-l2bd ARP probe or announcement > dropped error > 179 eth0-tx Tx packet drops (dpdk tx > failure) error > 1 eth0-output interface is down > error > 56 eth1-output interface is down > error > 45 eth2-output interface is down > error > 3 eth3-output interface is down > error > > Guo Huiliang via lists.fd.io <[email protected]> > 于2025年11月26日周三 17:34写道： > >> Many many thanks! >> >> Since VPP started, the Nginx processes on the two BVI interfaces have >> been utilizing 100% of the CPU. Could there be an error in my VCL or VPP >> configuration files? >> >> When communication is interrupted, port reuse does not occur every time. >> >> >> Florin Coras via lists.fd.io <[email protected]> >> 于2025年11月26日周三 17:15写道： >> >>> Hi, >>> >>> Inline. >>> >>> > On Nov 25, 2025, at 11:26 PM, Guo Huiliang via lists.fd.io >>> <[email protected]> wrote: >>> > >>> > My traffic flow is as follows: >>> > >>> > Client browser → Decryption Nginx (bound to a BVI interface on loop0) >>> > After TLS decryption, the traffic is forwarded to Encryption Nginx >>> (bound to another BVI interface in a separate bridge domain on loop1) >>> > Then it accesses the backend HTTPS server. >>> > The entire pipeline works fine under normal conditions. When I refresh >>> the page in the browser (using regular F5), it succeeds every time—no >>> matter how many times I refresh. >>> > >>> > However, when I perform a hard refresh (Ctrl+F5): >>> > >>> > The first and second attempts still load the webpage successfully. >>> > But starting from the third Ctrl+F5, the page fails to load. >>> > Packet capture analysis shows that between the backend server and the >>> Encryption Nginx, there are massive TCP retransmissions, and even port >>> reuse occurs. After a certain number of retransmissions, both sides send >>> RST packets to terminate the connection. >>> >>> Hard to tell what is going on but given that you’re seeing port reuse, >>> maybe linux side is refusing the handshake because of the initial sequence >>> number. A bit surprised this is happening because port selection on vpp >>> side should be relatively random, so pretty small chance of reuse with a >>> few connections. >>> >>> > >>> > From the command line, I observe that: >>> > >>> > Both the Decryption Nginx and Encryption Nginx processes are consuming >>> 100% CPU. >>> >>> If this is showing only after the bad condition is happening, maybe >>> check with gdb what exactly is looping. Maybe it’s a side effect of some >>> nginx socket option that’s not currently supported by the ldp shim. >>> >>> > Both loop0 (used by Decryption Nginx) and loop1 (used by Encryption >>> Nginx) show significant packet drops. >>> >>> Those drops look like protocol drops, not interface or tcp drops. Check >>> “sh error” and that will hopefully clarify what they are. Maybe they’ll >>> explain the tcp issues as well. >>> >>> > What is the root cause of this failure triggered specifically by >>> Ctrl+F5? >>> >>> Guess the http connections (or at least more of them) are re-established >>> instead of using cached content. >>> >>> Regards, >>> Florin >>> >>> > >>> > How can this issue be resolved? >>> > >>> > <475ea392-3170-41a2-a0ff-a4f669bcff36.png> >>> > >>> > >>> > >>> >>> >>> >>> >>> >> >> >> > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26563): https://lists.fd.io/g/vpp-dev/message/26563 Mute This Topic: https://lists.fd.io/mt/116482254/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
