I can't reproduce that issue. When you ping from host2 to host1, the hop limit on the echo reply packets would be set by host1. Is host1 using linux kernel networking? You have specifically identified that host2 uses "Vpp+LinuxCP" and omitted that designation from host1, so I presume host1 is not running VPP. If host1 is using linux kernel networking, you could run tcpdump or wireshark to inspect outbound packets from 2a01:500:10::1 to 2a01:500:10::2 to confirm what hop limit is being sset on the echo reply packets sent by host1 to host2.
-Matt On Mon, Oct 11, 2021 at 4:13 PM Petr Boltík <petr.bol...@gmail.com> wrote: > Hi Matt, > thank you - tested, but not fully solved. > IPv4 icmp works fine > IPv6 icmp > > [2a01:500:10::1/64host1]=>ether=>[host2-Vpp+LinuxCP 2a01:500:10::2/64] > host2=>host1 new issue occur, ttl change to 255 after few icmp6, example > below > host1=>host2 works now fine > > Regards > Petr > > 64 bytes from 2a01:500:10::1: icmp_seq=12 ttl=64 time=0.269 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=13 ttl=64 time=0.213 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=14 ttl=64 time=0.239 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=15 ttl=64 time=0.210 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=16 ttl=64 time=5.28 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=17 ttl=64 time=0.240 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=18 ttl=255 time=0.268 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=19 ttl=255 time=0.210 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=20 ttl=255 time=0.276 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=21 ttl=255 time=0.484 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=22 ttl=255 time=3.87 ms >> 64 bytes from 2a01:500:10::1: icmp_seq=23 ttl=255 time=9.34 ms >> > > po 11. 10. 2021 v 21:54 odesílatel Matthew Smith <mgsm...@netgate.com> > napsal: > >> >> Hi Petr, >> >> I don't think it is related to patch 31122, this seems to happen whether >> you are using that patch or not. Both ip4-icmp-echo-request and >> ip6-icmp-echo-request set outbound echo replies to have a TTL/hop-limit of >> 64. The IPv4 node sets the VNET_BUFFER_F_LOCALLY_ORIGINATED flag on the >> packets it sends but the IPv6 node neglects to do this. Setting that flag >> will prevent a rewrite node from decrementing the TTL/hop-limit later on. >> >> Here's a patch which sets the flag for outbound IPv6 echo replies - >> https://gerrit.fd.io/r/c/vpp/+/34040. Can you please test it and report >> whether it solves the problem? >> >> Thanks, >> -Matt >> >> >> On Mon, Oct 11, 2021 at 1:03 PM Petr Boltík <petr.bol...@gmail.com> >> wrote: >> >>> Hi, >>> I have found an issue with with linux-cp patch 31122. >>> [192.168.15.1/24 host1]=>ether=>[host2-Vpp+LinuxCP 192.168.15.2/24] >>> ipv4 icmp TTL >>> host2=>host1 TTL64 >>> host1=>host2 TTL64 >>> >>> ipv6 icmp TTL: >>> host2=>host1 TTL64 >>> host1 =>host2 TTL63 (there should be the same increasing TTL mechanism >>> as in the ipv4) >>> >>> Thanks for report this message to the right hands. >>> Regards Petr >>> >>> >>> >>>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20313): https://lists.fd.io/g/vpp-dev/message/20313 Mute This Topic: https://lists.fd.io/mt/86243713/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
