Hi Nick, The behavior you are seeing is correct. Based on specificatoin TCP sessions / tcp ports should not get reused before transitory timeout passes. WAIT-CLOSED means that these sessions are closed but still waiting for timeout to expire before address and port can be reused. The are not able to be reused by timed out connections or by new connections until they enter CLOSED state. NAT44 implementation doesn’t do scavenging rather maintains LRU list logically order for cheap reuse of CLOSED sessions. The reaping you are talking about (scavenging) looks fine at small number of sessions but exponentionally increases by number of sessions – if we are talking in thousand or milion sessions for exmaple.
Best regards, Filip Varga From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Nick Zavaritsky Sent: Thursday, September 10, 2020 10:53 AM To: vpp-dev@lists.fd.io Subject: [vpp-dev] Q about VPP NAT Importance: High Dear VPP hackers, I need your advice concerning configuring and possibly extremely ending the NAT in VPP. We are currently using nat44 in endpoint-dependent mode. We are witnessing TCP sessions piling up even though clients close connections gracefully. These lingering sessions are categorised as WAIT-CLOSING by show nat44 summary. After a timeout they are considered CLOSED and could get reaped (lazily). I suspect that this behaviour is actually correct, since the NAT seeing FIN/ACK passing by doesn't imply that the packets were actually delivered. Please confirm. It looks like RST doesn't terminate a NAT session (doesn't put it in WAIT-CLOSING state), are there reasons for that as well? Best, N
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17361): https://lists.fd.io/g/vpp-dev/message/17361 Mute This Topic: https://lists.fd.io/mt/76751794/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
