* Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
[not found] ` <SJ0PR11MB5120426D474963E08936DD2493359@SJ0PR11MB5120.namprd11.prod.outlook.com>
@ 2022-02-17 2:59 ` David Ahern
2022-02-24 9:04 ` Xiao, Jiguang
0 siblings, 1 reply; 8+ messages in thread
From: David Ahern @ 2022-02-17 2:59 UTC (permalink / raw)
To: Xiao, Jiguang, davem, yoshfuji, kuba, netdev, linux-kernel
On 2/16/22 3:36 AM, Xiao, Jiguang wrote:
> Hello,
>
> I found a counter in the kernel(5.10.49) that did not follow the RFC4293
> specification. The test steps are as follows:
>
>
>
> Topology:
>
> |VM 1| ------ |linux| ------ |VM 2|
>
>
>
> Steps:
>
> 1. Verify that “VM1” is reachable from “VM 2” and vice versa using ping6
> command.
>
> 2. On “linux” node, in proper fib, remove default route to NW address
> which “VM 2” resides in. This way, the packet won’t be forwarded by
> “linux” due to no route pointing to destination address of “VM 2”.
>
> 3. Collect the corresponding SNMP counters from “linux” node.
>
> 4. Verify that there is no connectivity from “VM 1” to “VM 2” using
> ping6 command.
>
> 5. Check the counters again.
>
>
>
> The test results:
>
> The counter “ip6InNoRoutes” in “/proc/net/dev_snmp6/” has not increased
> accordingly. In my test environment, it was always zero.
>
>
>
> My question is :
>
> Within RFC4293, “ipSystemStatsInNoRoutes” is defined as follows:
>
> “The number of input IP datagrams discarded because no route could be
> found to transmit them to their destination.”
>
> Does this version of the kernel comply with the RFC4293 specification?
>
>
I see that counter incrementing. Look at the fib6 tracepoints and see
what the lookups are returning:
perf record -e fib6:* -a
<run test>
Ctrl-C
perf script
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
2022-02-17 2:59 ` This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation David Ahern
@ 2022-02-24 9:04 ` Xiao, Jiguang
2022-03-09 2:16 ` Xiao, Jiguang
0 siblings, 1 reply; 8+ messages in thread
From: Xiao, Jiguang @ 2022-02-24 9:04 UTC (permalink / raw)
To: David Ahern, davem, yoshfuji, kuba, netdev, linux-kernel; +Cc: Pudak, Filip
[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]
Hi David
Thanks for guiding me how to proceed. I have captured the output result of perf (perf_output_5.10.49).
To confirm the problem, I tested it again on Ubuntu (kernel version is 5.4.0-79) using Docker and the results were the same, the only difference is the kernel version. I also collected the perf results and added them to the attachment (perf_output_5.4.0).
Best Regards
Xiao Jiguang
-----Original Message-----
From: David Ahern <dsahern@kernel.org>
Sent: 2022年2月17日 11:00
To: Xiao, Jiguang <Jiguang.Xiao@windriver.com>; davem@davemloft.net; yoshfuji@linux-ipv6.org; kuba@kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
[Please note: This e-mail is from an EXTERNAL e-mail address]
On 2/16/22 3:36 AM, Xiao, Jiguang wrote:
> Hello,
>
> I found a counter in the kernel(5.10.49) that did not follow the
> RFC4293 specification. The test steps are as follows:
>
>
>
> Topology:
>
> |VM 1| ------ |linux| ------ |VM 2|
>
>
>
> Steps:
>
> 1. Verify that “VM1” is reachable from “VM 2” and vice versa using
> ping6 command.
>
> 2. On “linux” node, in proper fib, remove default route to NW address
> which “VM 2” resides in. This way, the packet won’t be forwarded by
> “linux” due to no route pointing to destination address of “VM 2”.
>
> 3. Collect the corresponding SNMP counters from “linux” node.
>
> 4. Verify that there is no connectivity from “VM 1” to “VM 2” using
> ping6 command.
>
> 5. Check the counters again.
>
>
>
> The test results:
>
> The counter “ip6InNoRoutes” in “/proc/net/dev_snmp6/” has not
> increased accordingly. In my test environment, it was always zero.
>
>
>
> My question is :
>
> Within RFC4293, “ipSystemStatsInNoRoutes” is defined as follows:
>
> “The number of input IP datagrams discarded because no route could
> be found to transmit them to their destination.”
>
> Does this version of the kernel comply with the RFC4293 specification?
>
>
I see that counter incrementing. Look at the fib6 tracepoints and see what the lookups are returning:
perf record -e fib6:* -a
<run test>
Ctrl-C
perf script
[-- Attachment #2: perf_output_5.4.0 --]
[-- Type: application/octet-stream, Size: 12160 bytes --]
######################################### route reachable #########################################
ping6 128601 [002] 5784.123604: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 17 ::/37556 -> 2001:da8:2004:1000:202:116:160:41/1025 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5784.123611: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 17 ::/37556 -> 2001:da8:2004:1000:202:116:160:41/1025 tos 0 scope 0 flags 0 ==> dev eth0 gw 2001:eb:8001:e01:3::1 err 0
ping6 128601 [002] 5784.123761: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5784.123764: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev eth0 gw 2001:eb:8001:e01:3::1 err 0
ping6 128601 [002] 5784.123825: fib6:fib6_table_lookup: table 255 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5784.123830: fib6:fib6_table_lookup: table 254 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 128601 [002] 5784.123837: fib6:fib6_table_lookup: table 255 oif 4 iif 1 proto 58 fe80::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5784.123839: fib6:fib6_table_lookup: table 254 oif 4 iif 1 proto 58 fe80::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 128601 [002] 5784.123874: fib6:fib6_table_lookup: table 255 oif 0 iif 5 proto 58 fe80::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 128601 [002] 5784.123883: fib6:fib6_table_lookup: table 255 oif 5 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev - gw :: err 0
ping6 128601 [002] 5784.123889: fib6:fib6_table_lookup: table 254 oif 5 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5784.123893: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev - gw :: err 0
ping6 128601 [002] 5784.123895: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5784.123909: fib6:fib6_table_lookup: table 255 oif 0 iif 7 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 128601 [002] 5784.123916: fib6:fib6_table_lookup: table 255 oif 7 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5784.123919: fib6:fib6_table_lookup: table 254 oif 7 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 128601 [002] 5784.123949: fib6:fib6_table_lookup: table 255 oif 0 iif 5 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 128601 [002] 5785.150373: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5785.150380: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev eth0 gw 2001:eb:8001:e01:3::1 err 0
ping6 128601 [002] 5785.150433: fib6:fib6_table_lookup: table 255 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5785.150436: fib6:fib6_table_lookup: table 254 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 128601 [002] 5785.150441: fib6:fib6_table_lookup: table 255 oif 4 iif 1 proto 58 fe80::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5785.150443: fib6:fib6_table_lookup: table 254 oif 4 iif 1 proto 58 fe80::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 128601 [002] 5785.150467: fib6:fib6_table_lookup: table 255 oif 0 iif 5 proto 58 fe80::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 128601 [002] 5785.150473: fib6:fib6_table_lookup: table 255 oif 5 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev - gw :: err 0
ping6 128601 [002] 5785.150477: fib6:fib6_table_lookup: table 254 oif 5 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5785.150480: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev - gw :: err 0
ping6 128601 [002] 5785.150481: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 0 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5785.150491: fib6:fib6_table_lookup: table 255 oif 0 iif 7 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 128601 [002] 5785.150496: fib6:fib6_table_lookup: table 255 oif 7 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 128601 [002] 5785.150498: fib6:fib6_table_lookup: table 254 oif 7 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 128601 [002] 5785.150516: fib6:fib6_table_lookup: table 255 oif 0 iif 5 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
swapper 0 [013] 5785.662437: fib6:fib6_table_lookup: table 255 oif 0 iif 5 proto 58 fe80::42:acff:fe1e:3/0 -> fe80::42:acff:fe1e:2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
swapper 0 [013] 5785.662464: fib6:fib6_table_lookup: table 255 oif 0 iif 7 proto 58 fe80::42:acff:fe1e:2/0 -> fe80::42:acff:fe1e:3/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
######################################### route unreachable #########################################
ping6 129220 [009] 5825.675528: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 17 ::/37803 -> 2001:da8:2004:1000:202:116:160:41/1025 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5825.675532: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 17 ::/37803 -> 2001:da8:2004:1000:202:116:160:41/1025 tos 0 scope 0 flags 0 ==> dev eth0 gw 2001:eb:8001:e01:3::1 err 0
ping6 129220 [009] 5825.675618: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5825.675619: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev eth0 gw 2001:eb:8001:e01:3::1 err 0
ping6 129220 [009] 5825.675654: fib6:fib6_table_lookup: table 255 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5825.675656: fib6:fib6_table_lookup: table 254 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5825.675659: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5825.675661: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 129220 [009] 5825.675662: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5825.675663: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 129220 [009] 5825.675670: fib6:fib6_table_lookup: table 255 oif 4 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5825.675671: fib6:fib6_table_lookup: table 254 oif 4 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 129220 [009] 5825.675686: fib6:fib6_table_lookup: table 255 oif 0 iif 5 proto 58 2001:eb:8001:e01:3::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
ping6 129220 [009] 5826.685831: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5826.685838: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev eth0 gw 2001:eb:8001:e01:3::1 err 0
ping6 129220 [009] 5826.685895: fib6:fib6_table_lookup: table 255 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5826.685898: fib6:fib6_table_lookup: table 254 oif 0 iif 4 proto 58 2001:eb:8001:e01:3::2/0 -> 2001:da8:2004:1000:202:116:160:41/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5826.685904: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5826.685906: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 129220 [009] 5826.685909: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5826.685910: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 129220 [009] 5826.685922: fib6:fib6_table_lookup: table 255 oif 4 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ping6 129220 [009] 5826.685924: fib6:fib6_table_lookup: table 254 oif 4 iif 1 proto 58 2001:da8:2004:1000:202:116:160:41/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev br-e4b149b0780f gw :: err 0
ping6 129220 [009] 5826.685948: fib6:fib6_table_lookup: table 255 oif 0 iif 5 proto 58 2001:eb:8001:e01:3::1/0 -> 2001:eb:8001:e01:3::2/0 tos 0 scope 0 flags 0 ==> dev eth0 gw :: err 0
swapper 0 [003] 5827.886676: fib6:fib6_table_lookup: table 255 oif 0 iif 2 proto 17 fe80::21e:67ff:fe94:a878/0 -> ff02::1:2/0 tos 0 scope 0 flags 0 ==> dev eno1 gw :: err 0
[-- Attachment #3: perf_output_5.10.49 --]
[-- Type: application/octet-stream, Size: 4151 bytes --]
######################################### With the default route to vlan2 up #########################################
capid 559 [000] 8980.556347: fib6:fib6_table_lookup: table 255 oif 0 iif 16 proto 58 <vlan_1_vm_address> -> <vlan_2_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
capid 559 [000] 8980.556370: fib6:fib6_table_lookup: table 254 oif 0 iif 16 proto 58 <vlan_1_vm_address> -> <vlan_2_vm_address> tos 0 scope 0 flags 0 ==> dev <vlan_2_linux_if> gw :: err 0
ksoftirqd/0 12 [000] 8980.556884: fib6:fib6_table_lookup: table 255 oif 0 iif 17 proto 58 <vlan_2_vm_address> -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
ksoftirqd/0 12 [000] 8980.556889: fib6:fib6_table_lookup: table 254 oif 0 iif 17 proto 58 <vlan_2_vm_address> -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
ksoftirqd/0 12 [000] 8985.594403: fib6:fib6_table_lookup: table 255 oif 0 iif 16 proto 58 <vlan_1_vm_address> -> <link_local_node_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
ksoftirqd/0 12 [000] 8985.594528: fib6:fib6_table_lookup: table 255 oif 0 iif 17 proto 58 <vlan_2_vm_address> -> <link_local_node_address> tos 0 scope 0 flags 0 ==> dev <vlan_2_linux_if> gw :: err 0
swapper 0 [000] 8985.671952: fib6:fib6_table_lookup: table 255 oif 0 iif 17 proto 58 <link_local_vm2_address> -> <vlan_2_node_address> tos 0 scope 0 flags 0 ==> dev <vlan_2_linux_if> gw :: err 0
swapper 0 [000] 8985.686970: fib6:fib6_table_lookup: table 255 oif 0 iif 16 proto 58 <link_local_vm1_address> -> <vlan_1_node_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
######################################## With the default route to vlan2 down ########################################
swapper 0 [000] 9402.547217: fib6:fib6_table_lookup: table 255 oif 0 iif 16 proto 58 <vlan_1_vm_address> -> <vlan_2_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
swapper 0 [000] 9402.547235: fib6:fib6_table_lookup: table 254 oif 0 iif 16 proto 58 <vlan_1_vm_address> -> <vlan_2_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
swapper 0 [000] 9402.547261: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
swapper 0 [000] 9402.547272: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
swapper 0 [000] 9402.547289: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
swapper 0 [000] 9402.547298: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
swapper 0 [000] 9402.547316: fib6:fib6_table_lookup: table 255 oif 0 iif 1 proto 58 ::/0 -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
swapper 0 [000] 9402.547325: fib6:fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
swapper 0 [000] 9402.547342: fib6:fib6_table_lookup: table 255 oif 16 iif 1 proto 58 <vlan_2_vm_address> -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev lo gw :: err -113
swapper 0 [000] 9402.547349: fib6:fib6_table_lookup: table 254 oif 16 iif 1 proto 58 <vlan_2_vm_address> -> <vlan_1_vm_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
swapper 0 [000] 9407.574215: fib6:fib6_table_lookup: table 255 oif 0 iif 16 proto 58 <link_local_vm1_address> -> <vlan_1_node_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
dpsd 3271 [000] 9407.738436: fib6:fib6_table_lookup: table 255 oif 0 iif 16 proto 58 <vlan_1_vm_address> -> <link_local_node_address> tos 0 scope 0 flags 0 ==> dev <vlan_1_linux_if> gw :: err 0
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
2022-02-24 9:04 ` Xiao, Jiguang
@ 2022-03-09 2:16 ` Xiao, Jiguang
2022-03-09 4:50 ` David Ahern
0 siblings, 1 reply; 8+ messages in thread
From: Xiao, Jiguang @ 2022-03-09 2:16 UTC (permalink / raw)
To: David Ahern, davem, yoshfuji, kuba, netdev, linux-kernel; +Cc: Pudak, Filip
Hi David
To confirm whether my test method is correct, could you please briefly describe your test procedure?
Best Regards
Xiao Jiguang
-----Original Message-----
From: Xiao, Jiguang
Sent: 2022年2月24日 17:04
To: David Ahern <dsahern@kernel.org>; davem@davemloft.net; yoshfuji@linux-ipv6.org; kuba@kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Pudak, Filip <Filip.Pudak@windriver.com>
Subject: RE: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
Hi David
Thanks for guiding me how to proceed. I have captured the output result of perf (perf_output_5.10.49).
To confirm the problem, I tested it again on Ubuntu (kernel version is 5.4.0-79) using Docker and the results were the same, the only difference is the kernel version. I also collected the perf results and added them to the attachment (perf_output_5.4.0).
Best Regards
Xiao Jiguang
-----Original Message-----
From: David Ahern <dsahern@kernel.org>
Sent: 2022年2月17日 11:00
To: Xiao, Jiguang <Jiguang.Xiao@windriver.com>; davem@davemloft.net; yoshfuji@linux-ipv6.org; kuba@kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
[Please note: This e-mail is from an EXTERNAL e-mail address]
On 2/16/22 3:36 AM, Xiao, Jiguang wrote:
> Hello,
>
> I found a counter in the kernel(5.10.49) that did not follow the
> RFC4293 specification. The test steps are as follows:
>
>
>
> Topology:
>
> |VM 1| ------ |linux| ------ |VM 2|
>
>
>
> Steps:
>
> 1. Verify that “VM1” is reachable from “VM 2” and vice versa using
> ping6 command.
>
> 2. On “linux” node, in proper fib, remove default route to NW address
> which “VM 2” resides in. This way, the packet won’t be forwarded by
> “linux” due to no route pointing to destination address of “VM 2”.
>
> 3. Collect the corresponding SNMP counters from “linux” node.
>
> 4. Verify that there is no connectivity from “VM 1” to “VM 2” using
> ping6 command.
>
> 5. Check the counters again.
>
>
>
> The test results:
>
> The counter “ip6InNoRoutes” in “/proc/net/dev_snmp6/” has not
> increased accordingly. In my test environment, it was always zero.
>
>
>
> My question is :
>
> Within RFC4293, “ipSystemStatsInNoRoutes” is defined as follows:
>
> “The number of input IP datagrams discarded because no route could
> be found to transmit them to their destination.”
>
> Does this version of the kernel comply with the RFC4293 specification?
>
>
I see that counter incrementing. Look at the fib6 tracepoints and see what the lookups are returning:
perf record -e fib6:* -a
<run test>
Ctrl-C
perf script
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
2022-03-09 2:16 ` Xiao, Jiguang
@ 2022-03-09 4:50 ` David Ahern
2022-03-31 9:13 ` Pudak, Filip
0 siblings, 1 reply; 8+ messages in thread
From: David Ahern @ 2022-03-09 4:50 UTC (permalink / raw)
To: Xiao, Jiguang, davem, yoshfuji, kuba, netdev, linux-kernel; +Cc: Pudak, Filip
On 3/8/22 7:16 PM, Xiao, Jiguang wrote:
> Hi David
>
> To confirm whether my test method is correct, could you please briefly describe your test procedure?
>
>
>
no formal test. Code analysis (ip6_pkt_discard{,_out} -> ip6_pkt_drop)
shows the counters that should be incrementing and then looking at the
counters on a local server.
FIB Lookup failures should generate a dst with one of these handlers:
static void ip6_rt_init_dst_reject(struct rt6_info *rt, u8 fib6_type)
{
rt->dst.error = ip6_rt_type_to_error(fib6_type);
switch (fib6_type) {
case RTN_BLACKHOLE:
rt->dst.output = dst_discard_out;
rt->dst.input = dst_discard;
break;
case RTN_PROHIBIT:
rt->dst.output = ip6_pkt_prohibit_out;
rt->dst.input = ip6_pkt_prohibit;
break;
case RTN_THROW:
case RTN_UNREACHABLE:
default:
rt->dst.output = ip6_pkt_discard_out;
rt->dst.input = ip6_pkt_discard;
break;
}
}
They all drop the packet with a given counter bumped.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
2022-03-09 4:50 ` David Ahern
@ 2022-03-31 9:13 ` Pudak, Filip
2022-03-31 14:13 ` David Ahern
0 siblings, 1 reply; 8+ messages in thread
From: Pudak, Filip @ 2022-03-31 9:13 UTC (permalink / raw)
To: David Ahern, Xiao, Jiguang, davem, yoshfuji, kuba, netdev, linux-kernel
Hi David,
So we end up in ip6_pkt_discard -> ip6_pkt_drop :
---
if (netif_is_l3_master(skb->dev) &&
dst->dev == net->loopback_dev)
idev = __in6_dev_get_safely(dev_get_by_index_rcu(net, IP6CB(skb)->iif));
else
idev = ip6_dst_idev(dst);
switch (ipstats_mib_noroutes) {
case IPSTATS_MIB_INNOROUTES:
type = ipv6_addr_type(&ipv6_hdr(skb)->daddr);
if (type == IPV6_ADDR_ANY) {
IP6_INC_STATS(net, idev, IPSTATS_MIB_INADDRERRORS);
break;
}
fallthrough;
case IPSTATS_MIB_OUTNOROUTES:
IP6_INC_STATS(net, idev, ipstats_mib_noroutes);
break;
}
---
What happens in the case where the l3mdev is not used, is that we go into the else branch(idev = ip6_dst_idev(dst);) and then we can see that the counter is incremented on the loopback IF.
So is the only option that l3mdev should be used or is it strange to expect that the idev where the INNOROUTES should increment is the ingress device by default in this case?
Best Regards,
Filip Pudak
-----Original Message-----
From: David Ahern <dsahern@kernel.org>
Sent: Wednesday, 9 March 2022 05:50
To: Xiao, Jiguang <Jiguang.Xiao@windriver.com>; davem@davemloft.net; yoshfuji@linux-ipv6.org; kuba@kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Pudak, Filip <Filip.Pudak@windriver.com>
Subject: Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
On 3/8/22 7:16 PM, Xiao, Jiguang wrote:
> Hi David
>
> To confirm whether my test method is correct, could you please briefly describe your test procedure?
>
>
>
no formal test. Code analysis (ip6_pkt_discard{,_out} -> ip6_pkt_drop) shows the counters that should be incrementing and then looking at the counters on a local server.
FIB Lookup failures should generate a dst with one of these handlers:
static void ip6_rt_init_dst_reject(struct rt6_info *rt, u8 fib6_type) {
rt->dst.error = ip6_rt_type_to_error(fib6_type);
switch (fib6_type) {
case RTN_BLACKHOLE:
rt->dst.output = dst_discard_out;
rt->dst.input = dst_discard;
break;
case RTN_PROHIBIT:
rt->dst.output = ip6_pkt_prohibit_out;
rt->dst.input = ip6_pkt_prohibit;
break;
case RTN_THROW:
case RTN_UNREACHABLE:
default:
rt->dst.output = ip6_pkt_discard_out;
rt->dst.input = ip6_pkt_discard;
break;
}
}
They all drop the packet with a given counter bumped.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
2022-03-31 9:13 ` Pudak, Filip
@ 2022-03-31 14:13 ` David Ahern
2022-04-04 7:09 ` Pudak, Filip
0 siblings, 1 reply; 8+ messages in thread
From: David Ahern @ 2022-03-31 14:13 UTC (permalink / raw)
To: Pudak, Filip, Xiao, Jiguang, davem, yoshfuji, kuba, netdev, linux-kernel
On 3/31/22 3:13 AM, Pudak, Filip wrote:
> Hi David,
>
> So we end up in ip6_pkt_discard -> ip6_pkt_drop :
>
> ---
> if (netif_is_l3_master(skb->dev) &&
> dst->dev == net->loopback_dev)
That's a bug. I can not think of a case where those 2 conditions will
ever be true at the same time. I think that should '||'
> idev = __in6_dev_get_safely(dev_get_by_index_rcu(net, IP6CB(skb)->iif));
> else
> idev = ip6_dst_idev(dst);
>
> switch (ipstats_mib_noroutes) {
> case IPSTATS_MIB_INNOROUTES:
> type = ipv6_addr_type(&ipv6_hdr(skb)->daddr);
> if (type == IPV6_ADDR_ANY) {
> IP6_INC_STATS(net, idev, IPSTATS_MIB_INADDRERRORS);
> break;
> }
> fallthrough;
> case IPSTATS_MIB_OUTNOROUTES:
> IP6_INC_STATS(net, idev, ipstats_mib_noroutes);
> break;
> }
>
> ---
> What happens in the case where the l3mdev is not used, is that we go into the else branch(idev = ip6_dst_idev(dst);) and then we can see that the counter is incremented on the loopback IF.
>
> So is the only option that l3mdev should be used or is it strange to expect that the idev where the INNOROUTES should increment is the ingress device by default in this case?
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
2022-03-31 14:13 ` David Ahern
@ 2022-04-04 7:09 ` Pudak, Filip
2022-04-04 15:09 ` David Ahern
0 siblings, 1 reply; 8+ messages in thread
From: Pudak, Filip @ 2022-04-04 7:09 UTC (permalink / raw)
To: David Ahern, Xiao, Jiguang, davem, yoshfuji, kuba, netdev, linux-kernel
Hi David,
It was indeed a bug. We've retested with '||' and the counter is incremented properly.
How do we go about including this change to the kernel? Will you perform the update?
Thanks,
Filip Pudak
-----Original Message-----
From: David Ahern <dsahern@kernel.org>
Sent: Thursday, 31 March 2022 16:13
To: Pudak, Filip <Filip.Pudak@windriver.com>; Xiao, Jiguang <Jiguang.Xiao@windriver.com>; davem@davemloft.net; yoshfuji@linux-ipv6.org; kuba@kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
On 3/31/22 3:13 AM, Pudak, Filip wrote:
> Hi David,
>
> So we end up in ip6_pkt_discard -> ip6_pkt_drop :
>
> ---
> if (netif_is_l3_master(skb->dev) &&
> dst->dev == net->loopback_dev)
That's a bug. I can not think of a case where those 2 conditions will ever be true at the same time. I think that should '||'
> idev = __in6_dev_get_safely(dev_get_by_index_rcu(net, IP6CB(skb)->iif));
> else
> idev = ip6_dst_idev(dst);
>
> switch (ipstats_mib_noroutes) {
> case IPSTATS_MIB_INNOROUTES:
> type = ipv6_addr_type(&ipv6_hdr(skb)->daddr);
> if (type == IPV6_ADDR_ANY) {
> IP6_INC_STATS(net, idev, IPSTATS_MIB_INADDRERRORS);
> break;
> }
> fallthrough;
> case IPSTATS_MIB_OUTNOROUTES:
> IP6_INC_STATS(net, idev, ipstats_mib_noroutes);
> break;
> }
>
> ---
> What happens in the case where the l3mdev is not used, is that we go into the else branch(idev = ip6_dst_idev(dst);) and then we can see that the counter is incremented on the loopback IF.
>
> So is the only option that l3mdev should be used or is it strange to expect that the idev where the INNOROUTES should increment is the ingress device by default in this case?
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation
2022-04-04 7:09 ` Pudak, Filip
@ 2022-04-04 15:09 ` David Ahern
0 siblings, 0 replies; 8+ messages in thread
From: David Ahern @ 2022-04-04 15:09 UTC (permalink / raw)
To: Pudak, Filip, Xiao, Jiguang, davem, yoshfuji, kuba, netdev, linux-kernel
On 4/4/22 1:09 AM, Pudak, Filip wrote:
> It was indeed a bug. We've retested with '||' and the counter is incremented properly.
>
> How do we go about including this change to the kernel? Will you perform the update?
patch sent.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-04-04 15:09 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <SJ0PR11MB51207CBDB5145A89B8A0A15393359@SJ0PR11MB5120.namprd11.prod.outlook.com>
[not found] ` <SJ0PR11MB51202FA2365341740048A64593359@SJ0PR11MB5120.namprd11.prod.outlook.com>
[not found] ` <SJ0PR11MB51209200786235187572EE0D93359@SJ0PR11MB5120.namprd11.prod.outlook.com>
[not found] ` <SJ0PR11MB5120426D474963E08936DD2493359@SJ0PR11MB5120.namprd11.prod.outlook.com>
2022-02-17 2:59 ` This counter "ip6InNoRoutes" does not follow the RFC4293 specification implementation David Ahern
2022-02-24 9:04 ` Xiao, Jiguang
2022-03-09 2:16 ` Xiao, Jiguang
2022-03-09 4:50 ` David Ahern
2022-03-31 9:13 ` Pudak, Filip
2022-03-31 14:13 ` David Ahern
2022-04-04 7:09 ` Pudak, Filip
2022-04-04 15:09 ` David Ahern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).