Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
Thanks! I’ll push a patch.
Regards,
Klement
> On 26 May 2020, at 12:33, Miklos Tirpak wrote:
>
> Yes, it works with ip0:
>
> vnet_buffer (b0)->ip.reass.is_non_first_fragment =
>! !ip4_get_fragment_offset (ip0);
>
> Thanks,
> Miklos
> From: Klement Sekera -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. 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 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 does not consider
> > ip.save_rewrite_length when it calculates is_non_first_fragment at line 619
> > (master):
> >vnet_buffer (b0)->ip.reass.is_non_first_fragment =
> > ! !ip4_get_fragment_offset (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 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.
> >
> > 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 (#16492): https://lists.fd.io/g/vpp-dev/message/16492
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
Yes, it works with ip0:
vnet_buffer (b0)->ip.reass.is_non_first_fragment =
! !ip4_get_fragment_offset (ip0);
Thanks,
Miklos
From: Klement Sekera -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. 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 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 does not consider
> ip.save_rewrite_length when it calculates is_non_first_fragment at line 619
> (master):
>vnet_buffer (b0)->ip.reass.is_non_first_fragment =
> ! !ip4_get_fragment_offset (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 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.
>
> 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 (#16491): https://lists.fd.io/g/vpp-dev/message/16491
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
I think it’s enough if instead 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 does not consider
> ip.save_rewrite_length when it calculates is_non_first_fragment at line 619
> (master):
>vnet_buffer (b0)->ip.reass.is_non_first_fragment =
> ! !ip4_get_fragment_offset (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 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.
>
> 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 (#16490): https://lists.fd.io/g/vpp-dev/message/16490
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
Hi Klement,
thank you for your response.
ip.reass.is_non_first_fragment is set to 1 also for the first fragment.
(gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.reass.is_non_first_fragment
$8 = 1 '\001'
I think the fragment offset is wrongly calculated from the buffer:
(gdb) p ip4_get_fragment_offset (vlib_buffer_get_current (b0))
$9 = 766
(gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.save_rewrite_length
$1 = 14 '\016'
At the beginning of the function, the header pointer is set from the buffer
with the rewrite length shifted:
ip4_header_t *ip0 =
(ip4_header_t *) u8_ptr_add (vlib_buffer_get_current (b0),
is_output_feature *
vnet_buffer (b0)->
ip.save_rewrite_length);
(gdb) p fragment_first
$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 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.
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 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 (#16489): https://lists.fd.io/g/vpp-dev/message/16489
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
Hi,
I think there is a problem in ip4_sv_reass_inline(), it does not consider
ip.save_rewrite_length when it calculates is_non_first_fragment at line 619
(master):
vnet_buffer (b0)->ip.reass.is_non_first_fragment =
! !ip4_get_fragment_offset (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 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.
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 (#16488): https://lists.fd.io/g/vpp-dev/message/16488
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
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 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: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
