Re: [LARTC] iproute2: gatewayed routes in ancillary tables

["Martin A. Brown" <mabrown-lartc@securepipe.com>]

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@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/