Normally this should happen either because 1) tcp peer closed connection, then app is notified via session layer or 2) app closes and eventually vpp cleans up the port.
It’s not clear to me which of the two were hit for the scenario bellow. Regards, Florin > On Nov 28, 2025, at 12:41 AM, Guo Huiliang via lists.fd.io > <[email protected]> wrote: > > Is there any possibility that the port deleted by VPP can notify Nginx > through a certain mechanism, so that Nginx will no longer reuse this deleted > port to send data? > > Best regards, > Huiliang Guo > > Florin Coras via lists.fd.io <http://lists.fd.io/> > <[email protected] <mailto:[email protected]>> > 于2025年11月28日周五 04:43写道： >> Hi, >> >> >>> On Nov 26, 2025, at 11:39 PM, Guo Huiliang via lists.fd.io >>> <http://lists.fd.io/> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> When I use Nginx as a reverse proxy, Nginx acts as a client and creates a >>> TCP connection on a specific port. In VPP's TCP protocol stack, there is >>> tcp_handle_cleanups—when the connection times out, it deletes the session >>> and the connection. >> >> This is the normal path for all connection cleanups. >> >>> However, after the connection is deleted, when the Nginx client initiates a >>> new connection using the same port again, session_lookup_connection_wt4 >>> will throw an error stating that the connection cannot be found, resulting >>> in communication interruption. How to resolve this issue? >> >> If this is a connect port reuse, i.e., src and dst port are reused, it’s >> probably not properly supported today. In fact, I’d expect connect to be >> refused with port in use due to error in transport_alloc_local_endpoint. >> This has been on our todo list for a while. >> >> If however the local port is not reused, this needs more debugging. Maybe >> related to the fib used. >> >> Regards, >> Florin >> >>> >>> the log as below: >>> Nov 27 07:13:57 ubuntu vpp[2224818]: tcp_handle_cleanups:1313: >>> opaque_conn_id: 3081261440 >>> Nov 27 07:13:57 ubuntu vpp[2224818]: session_transport_delete_notify:1201: >>> session index 160 delete, session state: 10, opaque_conn_id: 3081261440 >>> Nov 27 07:13:57 ubuntu vpp[2224818]: session_delete:284: session index 160 >>> delete >>> Nov 27 07:13:57 ubuntu vpp[2224818]: session_lookup_del_session:406: >>> [Preparing to delete listening connection | Local listening >>> address=172.16.102.211:16143 <http://172.16.102.211:16143/> | Session >>> index=160 | Peer listening address=118.195.243.98:443 >>> <http://118.195.243.98:443/>] >>> Nov 27 07:13:59 ubuntu vpp[2224818]: session_lookup_connection_wt4:1023: >>> session_lookup_connection_wt4: Listening connection not found (Local >>> address: 172.16.102.211:16143 <http://172.16.102.211:16143/>, Protocol=0) >>> Nov 27 07:13:59 ubuntu vpp[2224818]: session_lookup_connection_wt4:1027: >>> session_lookup_connection_wt4: Matching connection not found (Quadruple: >>> 172.16.102.211:16143 <http://172.16.102.211:16143/>-> 118.195.243.98:443 >>> <http://118.195.243.98:443/>, Protocol=0, FIB index=1, Namespace index=1) >>> >>> >>> Best regards, >>> Huiliang Guo >>> >>> >>> >> >> >> >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26581): https://lists.fd.io/g/vpp-dev/message/26581 Mute This Topic: https://lists.fd.io/mt/116497693/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
