Hi, sorry, you have right. I have found something terribly wrong with host1. Patch from you works correctly. Many thanks to you. Problem solved.
PS: Host1 was MikroTik device with the current version ROS. This device avoids the second issue. If I change host1 to debian10, everything is fine. Test icmpv6 packet from debian10 to ROS6.48.1 failed after some time as mentioned before. Regards Petr Have a nice day út 12. 10. 2021 v 0:00 odesílatel Matthew Smith <mgsm...@netgate.com> napsal: > > 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 (#20314): https://lists.fd.io/g/vpp-dev/message/20314 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] -=-=-=-=-=-=-=-=-=-=-=-
