On Wed, Dec 04, 2013 at 12:47:19PM -0800, Matthew Dempsky wrote: > On Wed, Dec 04, 2013 at 02:10:21PM -0500, Kenneth R Westerback wrote: > > No, that was my point. i.e. don't avoid adding the route when given > > a /32 address just because class static routes are also present. > > I think there might be a misunderstanding, so let me back up and try > to clarify. :) > > Compute Engine gives out DHCP leases like "ip: 10.240.77.88, netmask: > 255.255.255.255, gateway: 10.240.0.1". The problem is 10.240.0.1 > isn't routable given a 10.240.77.88/32 IP address.
Ah. That was *not* what I understood you were saying, so there was indeed a misunderstanding. :-) > > ISC DHCP on Linux handles this by special casing netmask == > 255.255.255.255, and adding an extra direct route for the gateway IP. > E.g., for the above assignment, ISC DHCP would run "route add > 10.240.0.1 dev eth0" which tells Linux's network stack "10.240.0.1 is > directly accessible via eth0, even though it's not part of the > 10.240.77.88/32 subnet". (It would then run "route add default > 10.240.0.1" as per normal.) This seems weird and wrong to me, but I hasten to add I don't mean that as an informed opinion of what should be done. It's just that what routing foo I have does not encompass routes via interfaces that don't have an address/mask that allow access to that ip address. Like I said, weird. > > As far as I can tell, there's no authoritative/standard document that > describes this special case, and ISC DHCP only applies this special > case to the default gateway IP specified by DHO_ROUTERS. Notably, it > does *not* apply this direct routing logic for gateway IPs specified > by DHO_STATIC_ROUTES and/or DHO_CLASSLESS_STATIC_ROUTES, but it's > unclear whether that's intentional or accidental. > > > Not from me. This is way bigger that the last three line diff, and > > I have insufficient routing foo to comment on the usefulness of > > all these routes. > > The original three line diff was so short because it mimicked ISC DHCP > and only special cased the default gateway (i.e., DHO_ROUTERS), and > only did so when DHO_ROUTERS was actually used (i.e., when > DHO_CLASSLESS_STATIC_ROUTES is not specified). I was incorrectly reading your desire as wanting to add a route to the address being bound, not a route to the gateway. I also didn't understand why you wanted to do *that*, but it seemed a small, contained change. All the added complexity to attempt to address my misunderstanding was not needed. Sorry about the red herring! > > You suggested we should unconditionally add the route, but it was > unclear to me whether you meant: > > 1. We should always apply the special case logic for adding a > direct route for the default gateway specified by DHO_ROUTERS, even > if DHO_CLASSLESS_STATIC_ROUTES is specified; or > > 2. We should apply the special case logic to add direct routes for > all gateways (i.e., those specified by DHO_CLASSLESS_STATIC_ROUTES > and DHO_STATIC_ROUTES too), not just the default gateway. > > Interpretation #1 didn't seem right, because if > DHO_CLASSLESS_STATIC_ROUTES is specified, then DHO_ROUTERS isn't used > at all, so it might not be meaningful to add a direct route for > DHO_ROUTERS's gateway. > > Interpretation #2 seems reasonable (though deviating from ISC DHCP's > undocumented behavior), so that's what the second patch implemented. > But that's necessarily more code than the original diff, because we > need to repeat the special case logic for each gateway IP as they're > extracted from the DHCP options. > > The change is somewhat bigger and more invasive, but I think not that > much more complex: > > 1. Add a function ensure_direct_route() function that applies ISC > DHCP's /32 logic for a given gateway IP address (same code as from > first patch). > > 2. Call ensure_direct_route() in each of add_default_route(), > add_static_routes(), and add_classless_static_routes() for each > gateway IP address. > > 3. Add extra 'addr' and 'addrmask' parameters to each of the > add_*_routes() functions to pass the extra data needed for > ensure_direct_route(), and fix call sites appropriately. > > 4. In add_static_routes(), rename the local 'addr' variable that > points into option data to 'data' to avoid conflicting with the > new 'addr' parameter. Given the above, I think the original change makes the most sense. .... Ken
