Mailing List Archive

how many IGP routes is too many?
Hello,

is there any recent study about how many IGP (isis or ospf, I don't
really care right now) routes are "too many" with current generations of
route processors? Think RSP880, NCS55xx and so on on the cisco side and
PTX1000, PTX10002, etc on the juniper side.

Thanks

Pf


--
Pierfrancesco Caci
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: how many IGP routes is too many? [ In reply to ]
Hey,

> is there any recent study about how many IGP (isis or ospf, I don't
> really care right now) routes are "too many" with current generations of
> route processors? Think RSP880, NCS55xx and so on on the cisco side and
> PTX1000, PTX10002, etc on the juniper side.

SPF complexity doesn't scale with routes, routes are leaves to the
node. You can approximate complexity with O(ElogN) where E is edges
(links) and N is nodes (routers). I've done this before IGP migration
and got net1 and net2 complexity numbers separately and with summed
edge+link counts, got relative difference between summed and separate
and multiplied SPF time with the relative difference number to get
estimated migrated network SPF aggregate time, and it's been spot-on.

At any rate tens of thousands of routes is fine and normal, but if
you'd try in a lab, I'd not be particularly surprised if millions
work. Of course you should not really want to carry anything else but
loop0 and NMS networks in IGP.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: how many IGP routes is too many? [ In reply to ]
On Thursday, 2 April, 2020 09:43, "Saku Ytti" <saku@ytti.fi> said:

> At any rate tens of thousands of routes is fine and normal, but if
> you'd try in a lab, I'd not be particularly surprised if millions
> work. Of course you should not really want to carry anything else but
> loop0 and NMS networks in IGP.

The last is the key point, I think. Is the OP asking the question because they're looking to build a network with a *lot* of devices in, or because they're trying to carry other things in the IGP?

Regards,
Tim.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: how many IGP routes is too many? [ In reply to ]
>>>>> "tim@pelican" == tim@pelican org <tim@pelican.org> writes:


tim@pelican> On Thursday, 2 April, 2020 09:43, "Saku Ytti" <saku@ytti.fi> said:
>> At any rate tens of thousands of routes is fine and normal, but if
>> you'd try in a lab, I'd not be particularly surprised if millions
>> work. Of course you should not really want to carry anything else but
>> loop0 and NMS networks in IGP.

tim@pelican> The last is the key point, I think. Is the OP asking the question
tim@pelican> because they're looking to build a network with a *lot* of devices in,
tim@pelican> or because they're trying to carry other things in the IGP?


I need to clean up some garbage. I need to assess how thorough I have to
be in the cleaning.


--
Pierfrancesco Caci, ik5pvx
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: how many IGP routes is too many? [ In reply to ]
On Thu, 2 Apr 2020 at 21:03, Pierfrancesco Caci <pf@caci.it> wrote:

> I need to clean up some garbage. I need to assess how thorough I have to
> be in the cleaning.

What does that mean? What is going to happen? Are you going to add a
lot of routes in a few LSPs or are you going to add a few routes in a
lot of LSPs? Or are you going to add routers and links?

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: how many IGP routes is too many? [ In reply to ]
Hi,

On Thu, Apr 02, 2020 at 07:57:24PM +0200, Pierfrancesco Caci wrote:
> I need to clean up some garbage. I need to assess how thorough I have to
> be in the cleaning.

In the long run: whatever you do, it needs to be consistent.

So having "all routes from this POP in BGP, all routes from that
POP in OSPF" will hurt your ops people trying to troubleshoot anything.

So whatever you do, make sure it's consistent across all comparable
devices...

(We run "loopbacks in EIGRP or OSPF or OSPFv3, plus BGP for the rest",
and I sometimes question the wisdom of this...)

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: how many IGP routes is too many? [ In reply to ]
> Pierfrancesco Caci
> Sent: Thursday, April 2, 2020 8:46 AM
>
> Hello,
>
> is there any recent study about how many IGP (isis or ospf, I don't really
care
> right now) routes are "too many" with current generations of route
> processors? Think RSP880, NCS55xx and so on on the cisco side and PTX1000,
> PTX10002, etc on the juniper side.
>
Guessing it was in ~2012 one of the Tier1s asked cisco for 1M IGP routes -so
guessing 1M was too much when they tested back then.
The fact you're asking here tells me you're not one of the big folks trying
to break a sweat on IGP, so my guess is you'll be fine (assuming the usual
"don't redistribute DFZ to IGP"...).

But as Saku eluded to, there will be a threshold above which the SPF
calculation will take a significant time -which might negatively impact
convergence or CPU load especially in case of a flapping links (and no
dampening measures), back in the days this could have had effect on your
tuning of the IGP (or default settings if you didn't to any tuning) so
readjusting was needed to get optimal results.
Nowadays however, in times of FRR (-well that one has u-loops), but for
instance ti-LFA or classical RSVP-TE Bypass... and BGP PIC "Core", I'd say
the SPF calculation time is becoming less and less relevant.
So in current designs I'm tuning IGPs for egress edge-node protection only,
i.e. for generating LSP/LSA ASAP and then propagating it to all other
ingress edge-nodes as fast as possible so that BGP PIC "Core" can react to
the missing loopback and switch to an alternate egress edge-node.(reactions
to core-node failures or link-failures are IGP agnostic and driven solely by
loss of light or BFD/LFM...).
*Even in the egress edge-node protection case there are now RSVP-TE and
SR-TE features addressing this.

So I guess only the mem and cpu load and ultimately stability of the RPD (or
IGP process) is the remaining concern in extreme load cases (not the
convergence though).


adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: how many IGP routes is too many? [ In reply to ]
On 2/Apr/20 20:25, Gert Doering wrote:

> (We run "loopbacks in EIGRP or OSPF or OSPFv3, plus BGP for the rest",
> and I sometimes question the wisdom of this...)

Same here. It has been the "gold standard" to scale the routing domain
since about 2003 (or maybe even earlier; I only started teaching about
it in 2004).

It's a design principle that has worked well and stood the test of time.
Perhaps the only challenge I am seeing now is as we run MPLS in the
Metro-E Access, where some vendors deploy very tiny FIB's (think 20,000
slots on the ASR920, for example), there is a risk of exhausting those
due to IGP and LDP state.

I've often found 3107 to be quite complex, and when we get to that
stage, I'm hoping to find a cleverer way to deal with it before the
MX204 becomes the Metro-E gold standard :-).

Mark.
Re: [j-nsp] how many IGP routes is too many? [ In reply to ]
On 5/Apr/20 12:25, adamv0025@netconsultings.com wrote:

> Nowadays however, in times of FRR (-well that one has u-loops), but for
> instance ti-LFA or classical RSVP-TE Bypass... and BGP PIC "Core", I'd say
> the SPF calculation time is becoming less and less relevant. So in
> current designs I'm tuning IGPs for egress edge-node protection only,
> i.e. for generating LSP/LSA ASAP and then propagating it to all other
> ingress edge-nodes as fast as possible so that BGP PIC "Core" can react to
> the missing loopback and switch to an alternate egress
> edge-node.(reactions
> to core-node failures or link-failures are IGP agnostic and driven
> solely by
> loss of light or BFD/LFM...).
> *Even in the egress edge-node protection case there are now RSVP-TE and
> SR-TE features addressing this.
>
> So I guess only the mem and cpu load and ultimately stability of the
> RPD (or
> IGP process) is the remaining concern in extreme load cases (not the
> convergence though).

For me, I'd say small FIB's in a network that runs MPLS all the way into
the Access (where the small FIB's reside) is the biggest risk to scaling
out the IGP. On those boxes, CPU and memory aren't the issue (and they
are nowhere near as powerful as the chassis' in the data centre), it's
the FIB slots.

I have zero worry about IS-IS blowing out all the Intel-based control
planes currently ruling our big a** routers. Wouldn't have been able to
say the same thing 15 years ago, though.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/