[c-nsp] Rationale for ISIS default origination behavior

John Neiberger jneiberger at gmail.com
Mon Jan 21 14:36:57 EST 2013


In the part of the network I'm thinking of, we do use iBGP, so the peers
all learn the default in BGP. However, we also configure the routers with
eBGP peers to originate defaults into the IGP, presumably for faster
convergence, although given the design I really don't know that convergence
will be that much faster.  ISIS carries loopbacks, internal links, and a
default. It's single area, all L2, and we have "default-info originate" in
ISIS. Everything else is in iBGP. I'll have to ponder that design decision
a bit more. It seems that we'd get fewer complications if we didn't
originate a default into ISIS and just let iBGP deal with it.

Conditional advertisement is a recent choice by our design engineers to
solve this problem, but it seems like it shouldn't be necessary if ISIS
were implemented more like OSPF. OSPF won't originate a default if it is
learning an external OSPF default from another router. This is far more
sensible. ISIS does not seem to make that distinction. As long as it has a
default in the RIB, no matter what the source, it will generate its own
default into the area.

Thanks!
John


On Mon, Jan 21, 2013 at 12:11 PM, David Freedman <
david.freedman at uk.clara.net> wrote:

> >I've been discussing this with some other engineers at work and no one has
> >any idea why Cisco would implement it this way.
>
> I doubt many people make use of an IS-IS default (as I'm sure the L1/ATT
> behaviour is also seen as an annoyance in modern IP networks), many
> networks I've seen running IS-IS and BGP tend to do all their routing in
> the iBGP and keep IS-IS for pure infrastructure prefixes (loopbacks and
> sometimes transfer networks).
>
> In your scenario, the default can be brought from your external peers into
> your iBGP, this would seem quite sensible since you would be avoiding
> redistribution and/or conditional default advertisement (which you can
> achieve with IS-IS through the use of route-maps).
>
> Dave.
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list