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). 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). 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?
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? L2 IS-IS speakers will propagate all L2 routes to all L2
neighbors. We could not get a L1 and L1/2 design to work early on in
our testing so we chose the flat L2 approach instead. Is there
something else that I'm missing here? Down the road I'll have to
directly connect the borders together due to our upcoming SCE deployment
(longer story).
Thanks
Justin
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
