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

attempt to fix the bit flags … Thanks, Klement From: vpp-dev@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

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? Thanks, Miklos From: vpp-dev@lists.fd.io on behalf of Miklos Tirpak via lists.fd.io Sent: Wednesday, January 5

[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

Re: [vpp-dev] generic TCP MSS clamping

: vpp-dev@lists.fd.io on behalf of Miklos Tirpak via lists.fd.io Sent: Sunday, May 31, 2020 6:37 PM To: Paul Vinciguerra Cc: otr...@employees.org ; Mohsin Kazmi (sykazmi) ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] generic TCP MSS clamping CAUTION: This email originated from outside of the

Re: [vpp-dev] generic TCP MSS clamping

, some more tests, cli command updates. I hope I can do this quickly. Thanks, Miklos From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.fd.io>> on behalf of Miklos Tirpak via lists.fd.io<http://lists.fd.io> mailto:emnif

Re: [vpp-dev] generic TCP MSS clamping

set in this code review with some more changes: RX support, bugfix in clamping (mss is changed even if it is low enough), some more tests, cli command updates. I hope I can do this quickly. Thanks, Miklos From: vpp-dev@lists.fd.io on behalf of Miklos Tirpak via

Re: [vpp-dev] generic TCP MSS clamping

os can add that. Cheers, Ole > On 28 May 2020, at 12:23, Mohsin Kazmi (sykazmi) wrote: > > Hi Miklos, > > May be, it will help https://gerrit.fd.io/r/c/vpp/+/15144 > > -br > Mohsin > From: on behalf of Ole Troan > Date: Thursday, May 28, 2020 at 11:23 AM > To

[vpp-dev] generic TCP MSS clamping

Hi, I see the NAT plugin already supports TCP MSS clamping but it is implemented only in in2out direction. We have endpoints with wrong MTUs behind tunnels and not all the traffic is NATed. Hence, it would be very nice to have generic support for MSS clamping that could be enabled on the tunne

Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets

of vlib_buffer_get_current(b0) we just use ip0 (that already takes save_rewrite_length into consideration). Can you please test with this modification? Thanks, Klement > On 26 May 2020, at 11:51, Miklos Tirpak wrote: > > Hi, > > I think there is a problem in ip4_sv_reass_inline(), it

Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets

p.reass.is_non_first_fragment = 550 ! !fragment_first; ... 619 vnet_buffer (b0)->ip.reass.is_non_first_fragment = 620 ! !ip4_get_fragment_offset (vlib_buffer_get_current (b0)); Thanks, Klement > On 26 May 2020, at 09:25, Miklos Tirpak wrote: > > Hi, &

Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets

set (vlib_buffer_get_current (b0)); Let me open a pull request to fix this. Thanks, Miklos From: vpp-dev@lists.fd.io on behalf of Miklos Tirpak via lists.fd.io Sent: Tuesday, May 26, 2020 9:25 AM To: vpp-dev@lists.fd.io Subject: [vpp-dev] NAT44 does not work with fragmented I

[vpp-dev] NAT44 does not work with fragmented ICMP packets

Hi, we have a scenario where an ICMP packet arrives fragmented over a GTP-U tunnel. The outer IP packets are not fragmented, only the inner ones are. After GTP-U decapsulation, the packets are routed via an interface where NAT44 output-feature is configured. In the outgoing packets, the source

[vpp-dev] more than 65K entries in a FIB table

Hi, the FIB table implements two reference counters: /** * per-source number of locks on the table */ u16 *ft_locks; u32 ft_total_locks; While trying to add lots of GTP-U tunnels, which creates a new interface for each tunnel in a FIB table, we have reached the u16 limit ver