[c-nsp] Rationale for ISIS default origination behavior

[Saku Ytti]

On (2013-01-23 01:28 +1100), Andrew Miehs wrote:

> 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.

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)

With recursive static to 8.8.8.8 PE1 will use shortest working IGP path to
PE2.

> 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.

Yes. OP had:
[E1]-----[RA]------[RB]-----[RC]------[RD]------[E2]

If RB and RC both would have static default to both of their directions, RB
would send half of traffic to RC and RC would return half of that back to
RB, due to ECMP.
So in this example, you couldn't use those next-hops.

You could use E1, E2 loopbacks as next-hops. But this would not guarantee
there is INET access.

Using some INET prefix as next-hop would allow finding shortest IGP path to
working egress.

> 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.

Absolutely, loopbacks for ISIS rest for BGP. But no default in BGP or ISIS.
Default statically to recursing next-hop.

-- 
  ++ytti