Hello, On Mon, 5 May 2003, Martin A. Brown wrote: > Where in the code? > > : It is not necessary, but requires a bit of thinking net/ipv4/fib_semantics.c, fib_check_nh() > : IMO, this check is necessary because without seeing the > : route to the gateway we can not know whether this gateway is: > > I still don't understand....the nexthop for the new route already exists > in the table I have specified. 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. > : - local IP (and the resulting route should be device-only, GW IP > : is ignored) > : > : - unicast IP (and the resulting route should be via device and GW IP) > > I am using the parameter "via" in the problematic route statement. > Doesn't that implicitly mean that the route is a unicast IP route? 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. The same is achieved in this way: ifconfig eth0 192.168.0.1 ip route add 10.0.0.0/8 dev eth0 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. But, considering the fact that GW IPs are always onlink (the kernel ignores the many variants of scopes and lookups only for onlink GWs), 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. > : If you do not like this policy you can use static routes > : to solve the problem. > > And now I'm really feeling like a dunce! I understand "proto static" (I > think), but I don't see how that would solve this problem. Sorry, after checking the source ... may be not for your case, it is done only when the device is down, in short, the nh scope determination is delayed until device UP event. Regards -- Julian Anastasov <ja@xxxxxx>
