a -X (ksekera - PANTHEON TECH SRO at Cisco)
>
> Sent: Tuesday, May 26, 2020 12:14 PM
> To: Miklós Tirpák
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
>
> CAUTION: This email originated from outside of the organization
dev@lists.fd.io
Subject: Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
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.
I think it’s enough if instead
rent (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
$2 = 0
Later, this rewrite length is not considered.
Thanks,
Miklos
From: Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco)
Sent: Tuesday, May 26, 2020 11:22 AM
To: Miklós Tirpák
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] NAT44 does not work with fra
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
Hi Miklos,
thanks for your message. If is_non_first_fragment is set to true then rewrite
will not happen. Can you take a look at what happens in ip4_sv_reass_inline for
the first packet/fragment?
Setting that flag should be pretty fool-proof
498 const u32 fragment_first = ip4_get_
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
