[c-nsp] IS-IS default route quandary

[Oliver Boehmer (oboehmer)]

Justin Shore <> wrote on Thursday, July 03, 2008 12:57 AM:

> I'm trying to figure out a default route issue that stems from our
> original IS-IS deployment.  The entire IS-IS deployment is a flat L2
> design. 
> 
>       A    B
>       |\  /|
>       | \/ |
>       | /\ |
>       |/  \|
>       C    D
> 
> A & B are border routers and C & D are our 7600 core.  Each border is
> dual-homed to each core router.  The access edge routers (DSL, cable,
> metroE, dialup, etc) are dual-homed to the core routers as well.  Full
> BGP tables are extended to core (A-D are in an iBGP mesh).  The access
> edge can't handle full routes.  Customer routes are still in IS-IS but
> I'm slowly moving them to iBGP.  To dynamically learn a default route
> on the access edge via IS-IS I have to originate it somewhere
> upstream. 
> The borders currently originate the default route in IS-IS and
> advertise it to the core which propagates that on to the access edge.
> 
> On each border router we also have a static default route pointed to
> the physical interface of the upstream peers (which if memory serves
> me correctly that's a bad idea because it causes an ARP to be sent for
> every flow that requires that specific route).

right, if this is not a p2p interface. So a very bad idea..

>  This is a hold-over from 
> my predecessor and hasn't been scrutinized until now.  When I pull the
> static default from either A or B it relearns the default from the
> core routers, C & D.  Now when I do this it still has routes pointing
to all 
> the advertised prefixes on the Internet thanks to the full tables so I
> don't think I'll have any reachability issues.  Or will I?  My main
> concerns are that this will cause a routing loop between the borders
> and core for any routes that aren't in the borders' RIB.  This would
> mainly be BOGONs and other non-routable space that we use internally
(so it
> may not be a real problem). 

and, in addition, such packets should not show up on your borders unless
you have downstream peers/customers on the borders as well and they
point a default towards you.

> In theory I shouldn't ever have to rely
> on a default route to my upstreams thanks to my full tables.  I'm also
> concerned with how this may affect my uRPF and RTBH setup.  Would this
> catchall route nullify the effect of a iBGP-learned null-route from my
> RTBH setup?

Well, if your current static default doesn't affect your uRPF and RTBH
setup, why would a dynamic default do?
 
> I would prefer my borders to not have a default route vs a default
> pointing back to my core.  Is there a way to not accept the default
> via IS-IS?

IS-IS doesn't have something like OSPF's "distribute-list in" to filter
routes from being entered into the RIB, but you can use the "distance"
command to achieve something similar:

access-list 10 permit 0.0.0.0
router isis <foo>
 distance 255 0.0.0.0 255.255.255.255 10

this will assign distance 255 to the default-route (originated by
whatever neighbor), and 255 will suppress installation into the RIB.

Or you originate a default in iBGP and run your access nodes with a
limited BGP table only.

	oli