[j-nsp] [c-nsp] how many IGP routes is too many?

Nick Schmalenberger nick at schmalenberger.us
Tue Apr 7 17:49:52 EDT 2020


On Sun, Apr 05, 2020 at 11:25:25AM +0100, adamv0025 at netconsultings.com wrote:
> > 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     
>
Yes, according to this very interesting experiment
http://www.blackhole-networks.com/OSPF_overload/ it is mostly
about memory and cpu load :)
-Nick


More information about the juniper-nsp mailing list