Hi Nick, NAT doesn’t do any periodic cleanups, relying on a LRU list to reap stale sessions. This is by design, as it avoids hickups in traffic rate.
Observed behaviour with session moving to WAIT-CLOSED and then CLOSED state is based on RFC, there is no assumption whether FIN/ACK was actually delivered or not. Regarding RST, I’m looking at https://tools.ietf.org/html/rfc7857#section-2.2, which says VPP should wait 4 minutes before deleting the session, which it currently doesn’t. Would you like to take this and make the code change? It should be pretty straightforward. I can review. Thanks, Klement > On 10 Sep 2020, at 10:53, Nick Zavaritsky <nick.zavarit...@emnify.com> wrote: > > 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 (#17362): https://lists.fd.io/g/vpp-dev/message/17362 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] -=-=-=-=-=-=-=-=-=-=-=-
