Re: [vpp-dev] linux-cp patches 31122 ipv6 mtu TTL issue
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 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 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 >> 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 >>> 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] linux-cp patches 31122 ipv6 mtu TTL issue
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 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 > 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 >> 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] linux-cp patches 31122 ipv6 mtu TTL issue
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 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 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 (#20312): https://lists.fd.io/g/vpp-dev/message/20312 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] linux-cp patches 31122 ipv6 mtu TTL issue
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 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 (#20311): https://lists.fd.io/g/vpp-dev/message/20311 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] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] linux-cp patches 31122 ipv6 mtu TTL issue
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 (#20310): https://lists.fd.io/g/vpp-dev/message/20310 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] -=-=-=-=-=-=-=-=-=-=-=-
