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 > <[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 <http://lists.fd.io/> > <[email protected] <mailto:[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 <http://lists.fd.io/> >> <[email protected] <mailto:[email protected]>> >> 于2025年11月26日周三 17:15写道： >>> Hi, >>> >>> Inline. >>> >>> > On Nov 25, 2025, at 11:26 PM, Guo Huiliang via lists.fd.io >>> > <http://lists.fd.io/> <[email protected] >>> > <mailto:[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 (#26559): https://lists.fd.io/g/vpp-dev/message/26559 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]] -=-=-=-=-=-=-=-=-=-=-=-
