Re: [vpp-dev] NAT44-ed state machine

> > If the FIN was received, then this should be okey I think. Both sides are > aware that the session is closing. > > If the FIN and all of its re-transmits are lost, then this can become a > problem indeed. When the other side sends data after an hour, the packets > will be dropped and it ca

Re: [vpp-dev] NAT44-ed state machine

On 18 Mar 2022, at 18:46, Klement Sekera mailto:klem...@graphiant.com>> wrote: On 18 Mar 2022, at 18:43, Ole Troan mailto:otr...@employees.org>> wrote: On 18 Mar 2022, at 17:40, Klement Sekera mailto:klem...@graphiant.com>> wrote: I like the idea of VPP sending RST for cases where the s

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 18:43, Ole Troan wrote: > > > >> On 18 Mar 2022, at 17:40, Klement Sekera wrote: >> >> I like the idea of VPP sending RST for cases where the session doesn’t exist >> or for some reason the state is invalid. >> >> It might also be a good idea to implement VPP sending

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 17:29, Miklós Tirpák wrote: > >  > Getting back to some of the topics, > >> >> The main concern about RST was to recover from a 3rd party sending RSTs into >> the session. > This would require the sender to spoof the src IP, right? > Are you aware of any scenario when a

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 17:40, Klement Sekera wrote: > > I like the idea of VPP sending RST for cases where the session doesn’t exist > or for some reason the state is invalid. > > It might also be a good idea to implement VPP sending TCP keepalives for idle > sessions to discover whether the p

Re: [vpp-dev] NAT44-ed state machine

On 18 Mar 2022, at 17:28, Miklós Tirpák mailto:miklos.tir...@emnify.com>> wrote: Getting back to some of the topics, The main concern about RST was to recover from a 3rd party sending RSTs into the session. This would require the sender to spoof the src IP, right? Are you aware of any scenar

Re: [vpp-dev] NAT44-ed state machine

Getting back to some of the topics, The main concern about RST was to recover from a 3rd party sending RSTs into the session. This would require the sender to spoof the src IP, right? Are you aware of any scenario when an RST followed by subsequent data could happen during a "normal" session an

Re: [vpp-dev] NAT44-ed state machine

Hi, > On 18 Mar 2022, at 12:18, otr...@employees.org wrote: > > Klement, > >>> Following up on this thread. >>> The changes in 34877 led to some undesired behaviour in the "real >>> world(tm)". >>> In the close pattern below it left sessions in established state, and >>> with

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 12:18, otr...@employees.org wrote: > > Klement, > >>> Following up on this thread. >>> The changes in 34877 led to some undesired behaviour in the "real >>> world(tm)". >>> In the close pattern below it left sessions in established state, and >>> with

Re: [vpp-dev] NAT44-ed state machine

Klement, >> Following up on this thread. >> The changes in 34877 led to some undesired behaviour in the "real >> world(tm)". >> In the close pattern below it left sessions in established state, and >> with a relatively low cps >> would consume the whole session table. >>

Re: [vpp-dev] NAT44-ed state machine

On 18 Mar 2022, at 11:46, otr...@employees.org wrote: Klement, Following up on this thread. The changes in 34877 led to some undesired behaviour in the "real world(tm)". In the close pattern below it left sessions in established state, and with a relatively low c

Re: [vpp-dev] NAT44-ed state machine

Klement, Following up on this thread. The changes in 34877 led to some undesired behaviour in the "real world(tm)". In the close pattern below it left sessions in established state, and with a relatively low cps would consume the whole session table. Th

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 11:22, otr...@employees.org wrote: > > Thanks for quick replies Klement! > >>> Following up on this thread. >>> The changes in 34877 led to some undesired behaviour in the "real >>> world(tm)". >>> In the close pattern below it left sessions in established state, and with

Re: [vpp-dev] NAT44-ed state machine

Thanks for quick replies Klement! >> Following up on this thread. >> The changes in 34877 led to some undesired behaviour in the "real world(tm)". >> In the close pattern below it left sessions in established state, and with a >> relatively low cps >> would consume the whole session table. >> >

Re: [vpp-dev] NAT44-ed state machine

34877/7/src/plugins/nat/nat44-ed/tcp_conn_track.rst > > Thanks, > Klement > > From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> > mailto:vpp-dev@lists.fd.io>> on behalf of Miklos Tirpak > mailto:miklos.tir...@emnify.com>> > Date: Wednesday, January 5, 2022 at

Re: [vpp-dev] NAT44-ed state machine

it.fd.io/r/c/vpp/+/34877/7/src/plugins/nat/nat44-ed/tcp_conn_track.rst > > Thanks, > Klement > > From: vpp-dev@lists.fd.io on behalf of Miklos Tirpak > > Date: Wednesday, January 5, 2022 at 6:23 PM > To: vpp-dev > Subject: [vpp-dev] NAT44-ed state machine > > Hi, &g

Re: [vpp-dev] NAT44-ed state machine

/tcp_conn_track.rst Thanks, Klement From: vpp-dev@lists.fd.io on behalf of Miklos Tirpak Date: Wednesday, January 5, 2022 at 6:23 PM To: vpp-dev Subject: [vpp-dev] NAT44-ed state machine Hi, we have observed couple of problems with the NAT44-ed state machine and would appreciate your advice to fix

Re: [vpp-dev] NAT44-ed state machine

From: Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) Sent: Monday, January 10, 2022 12:35 PM To: Miklós Tirpák ; vpp-dev Subject: Re: [vpp-dev] NAT44-ed state machine CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [vpp-dev] NAT44-ed state machine

@lists.fd.io on behalf of Miklos Tirpak Date: Monday, January 10, 2022 at 12:33 PM To: vpp-dev , Miklós Tirpák Subject: Re: [vpp-dev] NAT44-ed state machine Hi, I have opened the review https://gerrit.fd.io/r/c/vpp/+/34851 for the first issue, the [SYN, ACK] retransmission. Could you please have a look

Re: [vpp-dev] NAT44-ed state machine

, 2022 6:23 PM To: vpp-dev Subject: [vpp-dev] NAT44-ed state machine CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, we have observed couple of problems with the NAT44-ed

[vpp-dev] NAT44-ed state machine

Hi, we have observed couple of problems with the NAT44-ed state machine and would appreciate your advice to fix them. In our use case, the clients can have a lossy connection, which results in retransmissions. In some cases, these retransmissions do not seem to be handled correctly. 1. The