On 5/7/19 2:20 AM, Hangbin Liu wrote: > On Tue, Apr 30, 2019 at 12:00:46PM -0600, David Ahern wrote: >> On 4/29/19 8:37 PM, Hangbin Liu wrote: >>> An other issue is The IPv4 rule 'from iif' check test failed while IPv6 >>> passed. I haven't found out the reason yet. >>> >>> # ip -netns testns rule add from 192.51.100.3 iif dummy0 table 100 >>> # ip -netns testns route get 192.51.100.2 from 192.51.100.3 iif dummy0 >>> RTNETLINK answers: No route to host >>> >>> TEST: rule4 check: from 192.51.100.3 iif dummy0 [FAIL] >>> >>> # ip -netns testns -6 rule add from 2001:db8:1::3 iif dummy0 table 100 >>> # ip -netns testns -6 route get 2001:db8:1::2 from 2001:db8:1::3 iif dummy0 >>> 2001:db8:1::2 via 2001:db8:1::2 dev dummy0 table 100 metric 1024 iif dummy0 >>> pref medium >>> >>> TEST: rule6 check: from 2001:db8:1::3 iif dummy0 [ OK ] >> >> use perf to look at the fib lookup parameters: >> perf record -e fib:* -- ip -netns testns route get 192.51.100.2 from >> 192.51.100.3 iif dummy0 >> perf script > > Hi David, Roopa, > > From the perf record the result looks good. > fib_table_lookup could get correct route. > > For IPv4: > ip 7155 [001] 8442.915515: fib:fib_table_lookup: table 255 oif 0 iif 2 > proto 0 192.51.100.3/0 -> 192.51.100.2/0 tos 0 scope 0 flags 0 ==> dev - gw > 0.0.0.0 src 0.0.0.0 err -11 > ip 7155 [001] 8442.915517: fib:fib_table_lookup: table 100 oif 0 iif 2 > proto 0 192.51.100.3/0 -> 192.51.100.2/0 tos 0 scope 0 flags 0 ==> dev dummy0 > gw 192.51.100.2 src 198.51.100.1 err 0 > > For IPv6: > ip 6950 [000] 759.328850: fib6:fib6_table_lookup: table 255 oif 0 iif 2 > proto 0 2001:db8:1::3/0 -> 2001:db8:1::2/0 tos 0 scope 0 flags 0 ==> dev lo > gw :: err -113 > ip 6950 [000] 759.328852: fib6:fib6_table_lookup: table 100 oif 0 iif 2 > proto 0 2001:db8:1::3/0 -> 2001:db8:1::2/0 tos 0 scope 0 flags 0 ==> dev > dummy0 gw 2001:db8:1::2 err 0 > > > Then I tracked the code and found in function ip_route_input_slow(), > after fib_lookup(), we got res->type == RTN_UNICAST. So if we haven't > enabled forwarding, it will return -EHOSTUNREACH. > > But even we enabled forwarding, we still need to disable rp_filter as the > source/dest address are in the same subnet. The ip_mkroute_input() > -> __mkroute_input() -> fib_validate_source() -> __fib_validate_source() will > return -EXDEV if we enabled rp_filter. > > So do you think if we should enable forwarding and disble rp_filter before > test "from $SRC_IP iif $DEV" or just diable this test directly? >
seems to me the test is a bit off; the source, gateway and address on dummy are all in the same subnet. egress device == ingress device would cause a redirect. That is right after the valiate_source check.
