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.
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.)
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).
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.
