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_fragment_offset_bytes
(ip0);
...
549 vnet_buffer (b0)->ip.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 <[email protected]> wrote:
>
> 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 IP is correctly NATed but the ICMP
> identifier (port) is not changed. Hence, the NAT session cannot be found for
> the ICMP reply. This works correctly with smaller packets, the problem is
> only with fragmented ones.
>
> I could reproduce this with both VPP 20.01 and master, and could see that
> ip.reass.is_non_first_fragment is true for every packet. Therefore,
> icmp_in2out() does not update the ICMP header I think.
>
> 712 if (!vnet_buffer (b0)->ip.reass.is_non_first_fragment)
> (gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.reass
> $17 = {{{next_index = 1056456440, error_next_index = 0}, {owner_thread_index
> = 270}}, {{{l4_src_port = 16120,
> l4_dst_port = 16120, tcp_ack_number = 0, save_rewrite_length = 14
> '\016', ip_proto = 1 '\001',
> icmp_type_or_tcp_flags = 8 '\b', is_non_first_fragment = 1 '\001',
> tcp_seq_number = 0}, {estimated_mtu = 16120}}}, {
> fragment_first = 16120, fragment_last = 16120, range_first = 0,
> range_last = 0, next_range_bi = 17301774,
> ip6_frag_hdr_offset = 0}}
>
> The node trace seems to be fine:
> ... ip4-lookup -> ip4-rewrite -> ip4-sv-reassembly-output-feature ->
> nat44-in2out-output -> nat44-in2out-output-slowpath
>
> The NAT session is also correct, it includes the new port:
>
> DBGvpp# sh nat44 sessions detail
> NAT44 sessions:
> -------- thread 0 vpp_main: 0 sessions --------
> -------- thread 1 vpp_wk_0: 1 sessions --------
> 100.64.100.1: 1 dynamic translations, 0 static translations
> i2o 100.64.100.1 proto icmp port 63550 fib 1
> o2i 172.16.17.2 proto icmp port 16253 fib 0
> index 0
> last heard 44.16
> total pkts 80, total bytes 63040
> dynamic translation
>
> Do you know if this is a configuration issue or a possible bug? Thank you!
>
> Thanks,
> Miklos
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16487): https://lists.fd.io/g/vpp-dev/message/16487
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
