[Xorp-users] Unreachable default route.

[Ben Greear]

Pavlin Radoslavov wrote:

> You need to install a different type of route in the kernel which I
> believe in Linux is RTN_UNREACHABLE instead of RTN_BLACKHOLE.
> However, XORP doesn't support such routes.
> You could try experimenting with such routes by replacing all
> references (I counted two references) of RTN_BLACKHOLE with
> RTN_UNREACHABLE inside file
> fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc
> 
> This is not the right solution, but allows you to play with such
> routes.

Yeah, I figured I could do this..but I am also interested in learning
how to do it the right way:

new option for Interface:
   unreachable: true

And propagate that through like you do the "discard: true" option currently.

Is this a major task, or just a few hours of work?

I'm willing to attempt it assuming it's not horribly complex or requires all new infrastructure.


> Just curious, could you describe your particular scenario you have
> that requires installing RTN_UNREACHABLE routes.

Suppose I have a virtual router with subnets A, B, C hanging off of it and no default gateway.
When I ping through this VR to subnet D, I would like to
get an ICMP message that says something like 'no route to host', not
just no response (which can take a while to realize).

The reason I need a bogus default route (unreachable and/or blackhole) is that
it appears Linux will try other routing tables if there is no matching route
in the table you specify.  This basically breaks VRs if you don't have a
catch-all default route entry because it will try the local routing table and
may immediately find a destination (that does not go through the virtual
routes & links.)

>> In the meantime, I'll work on a patch that makes the 'static' priority
>> configurable with an environment variable.
> 
> I should tell you upfront that configurable admin distances in RIB
> has been on our TODO list for quite some time. However it is not
> trivial if we want to do it properly by taking into account various
> considerations.
> E.g., one of the goals is to be able to configure the priorities (on
> the fly) inside the XORP config file.
> 
> Hence, most likely we won't use a solution that is based on
> setting an environmental variable (or something like this).
> In other words, don't be offended if your patch is not applied to
> the CVS.
> Though, if I were in your position I would use such shortcut in my
> local XORP copy.

I agree.  It would be much nicer to be able to specify it in
the config file on a per-route basis.  But, this will probably work
for me.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com