[c-nsp] Rationale for ISIS default origination behavior

Andrew Miehs andrew at 2sheds.de
Wed Jan 23 07:00:26 EST 2013


On Wed, Jan 23, 2013 at 1:41 AM, Saku Ytti <saku at ytti.fi> wrote:

> Say you have
>
> PE1---P1----PE2---INET
> |           |
> +-----P2----+
>
> PE1 default routes to P1, P2 in your scenario.
>
> What if P2 stops being connected to PE2? PE1 still has active static route
> to P2 and will ECMP half the packets to bit-heaven (IP routing, no MPLS)
>
>
In your diagram the only router with an Internet connection is PE2.
PE2 should be the only thing announcing a default back towards your network.
If PE1 also had an Internet connection, then it should also announce a
default back into your network.

Your provider (INET) should be able to announce a default for you if you
request it.

HOWEVER: If we are talking about service provider networks - what is the
purpose of your default route?
If RA, RB, RC, RD, E1 and E2 are iBGP peers in the same AS (and I hope they
are) you have more than enough routes to get to everywhere which is known
to you. Sending traffic out of E1 and E2 is just pumping noise to your
upstreams. If you want the default, so that you can announce this to your
customers, why not announce THEM a default on your edge? - hopefully via
eBGP.

If the above network, E[12],R[ABCD] is an "Enterprise" network, then my two
boxes E1 and E2 would probably only receive a default and would announce
this onto the rest of the network. I am pretty sure this design was just to
demonstrate a problem, and not really how someone would connect up their
network as the chance of splitting your network is extremely high.


More information about the cisco-nsp mailing list