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

On 18 Mar 2022, at 10:49, Ole Troan via lists.fd.io mailto:otroan=employees@lists.fd.io>> wrote: Hi, 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 st

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

Hi, 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. The change here https://gerrit.fd.io/r/c/vpp/+/35

Re: [vpp-dev] vpp hangs with bfd configuration along with mpls (inner and outer ctxt)

Hi Rajith, Thank you for the help. Even I suspect some issue with mpls forward route. Could you pls check below? Labelled route: vpp# show mpls fib 16 MPLS, fib_index:0 locks:[API:5, ] 16:eos/21 fib:0 index:403 locks:2 API refs:1 entry-flags:uRPF-exempt, src-flags:added,contributing,active, p

Re: [vpp-dev] vpp hangs with bfd configuration along with mpls (inner and outer ctxt)

Hi Rajith, One more imp point here is, when you say " mpls php route without eos" , this looks like into mpls fib table 0 and my issue is on inner context or inner data packet. here Eth interface is more on outer context and IP is inner context (VRF). I guess we see issue in VRF. Could you pl

Re: [vpp-dev] Meanings of different vector rates and questions about NAT44 handoff queue size

Hi Klement, thanks for your elaboration and I would try to see this issue with some counters. Best wishes Pan 发件人: Klement Sekera 发送时间: 2022年3月17日 17:13 收件人: Pan Yueyang 抄送: vpp-dev@lists.fd.io 主题: Re: [vpp-dev] Meanings of different vector rates and questions about NAT44 handoff