Julian, : > Where in the code? : net/ipv4/fib_semantics.c, fib_check_nh() : : No, we are creating new route which has nexthop(s). For : each nexthop we create, we need to determine its scope. This : scope tells us in route lookups whether we are via GW or just : via device. If the nexthop is via unicast GW IP then we send : the traffic to this IP. If the nexthop is not via GW then : we optionally resolve the destination (dest becomes nexthop) : and then we send the traffic via the specified device. : : > Why couldn't we see the route to the gateway in the specified table? : : The route to the gateway must be reachable in : the normal lookup path, adding it to table is not enough, you need : 'ip rule ... table GW_TABLE' to make it reachable. OK--this makes sense. : No, for example, 192.168.0.1 is not unicast, it is local: : : ifconfig eth0 192.168.0.1 : ip route add 10.0.0.0/8 via 192.168.0.1 : : In such case, we can not use this IP as GW IP. I just tried this example, and I see exactly what you mean. This use of the parameter "via" strikes me as confusing and counterintuitive. : But you are right, if there is no local IP we can assume : the GW IP is unicast. : : > My understanding is that the destination is distinctly not a local IP, : > because of the presence of the parameter "via" in the nexthop definition. : : After "via" you can use local IP in addition to unicast : one. You know it but the kernel is not sure. For me, this is new--I struggle to imagine a case where I would use this sort of syntax. So, if I use "via <local-IP>", the kernel will essentially treat the route as though I had specified "dev <interface>", right? : But, considering the fact that GW IPs are always : onlink (the kernel ignores the many variants of scopes and : lookups only for onlink GWs), Ah-ha! And, as well as an explanation, you have given me a solution. In this case, I can use the following: ip route add 192.168.237.0/24 dev eth0 table 4 ip route add 192.168.236.0/24 via 192.168.237.1 dev eth0 onlink table 4 The onlink tells the kernel what I know; that my use of "via" in this case is for a nexthop as a unicast destination. : I think such check could be removed and we can assume it is "unicast GW : IP" only if (we have to add many checks in addition): : : - output device is UP : - IP protocol is enabled for this device (in_dev_get(dev) succeeds), : currently, that means there are IP addresses on this device : : such checks guarantee we will not break any expectations : in other places in the kernel by creating zombie routes. May : be this was the only remaining reason to keep this check, I'm : not sure. Thanks for taking the time to explain this, Julian. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
