Re: [vpp-dev] Q about VPP NAT

2020-09-10 Thread Klement Sekera via lists.fd.io
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  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]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] Q about VPP NAT

2020-09-10 Thread Filip Varga via lists.fd.io
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  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]
-=-=-=-=-=-=-=-=-=-=-=-


[vpp-dev] Q about VPP NAT

2020-09-10 Thread Nick Zavaritsky
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 (#17360): https://lists.fd.io/g/vpp-dev/message/17360
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]
-=-=-=-=-=-=-=-=-=-=-=-