[c-nsp] Rationale for ISIS default origination behavior

Andrew Miehs andrew at 2sheds.de
Tue Jan 22 09:28:30 EST 2013


On Tue, Jan 22, 2013 at 11:41 PM, Saku Ytti <saku at ytti.fi> wrote:

> On (2013-01-22 21:38 +1100), Andrew Miehs wrote:
>
> > If you have a full routing table, you don't need a default route.
> > If you don't have full routing tables, or want/ need a default route -
> > point it to your two major "up-streams".
>
> If one of the up-streams gets disconnected from core, only connecting to
> your PE. Your PE will keep using static route and blackhole traffic.
>

If you loose a PE (and connected upstream) which connect back to your core
- you have a bigger issue. You need to make sure that PE stops announcing
your network blocks. If the PE is still default routing everything to that
upstream - what difference doesn't make - there shouldnt be any traffic
left connected to it.

Furthermore in OPs question, if you try to set static default to both
> direction in each box, you'll have loop always.


The original poster had the issue that even though his "e2" router was no
longer able to reach the default, and now defaulted back towards "e1" via
"rd", the routing table on "rd" was not updated to mirror this fact.

IMHO - the behaviour that he is see is the same with isis and bgp.
If you use the "default-information" command in isis or the "neighbour
x.x.x.x default-information" command in bgp - you will always announce a
default route to your peer - regardless of whether or not you yourself have
a default route in your routing table. If you want this fact to be
reflected in the announcement, you should be able to use a route map
attached to this command to solve that.

I too would run iBGP on all of the r[abcd] boxes and only have my own
infrastructure in ISIS. Redistributing is never fun at the best of times.

Regards

Andrew


More information about the cisco-nsp mailing list