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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-nsp] 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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-nsp] 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

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-nsp] how many IGP routes is too many? [ In reply to ]
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-nsp] how many IGP routes is too many? [ In reply to ]
On Wed, 8 Apr 2020 at 00:55, Nick Schmalenberger via juniper-nsp
<juniper-nsp@puck.nether.net> wrote:

> Yes, according to this very interesting experiment
> http://www.blackhole-networks.com/OSPF_overload/ it is mostly
> about memory and cpu load :)

Interesting, but this is the worst case scenario for ISIS, single
router advertising many routes. In ISIS this would have had less happy
ending, as you only have 255 LSP numbers, ~1500B each, so after ~370kB
or so, you'll run out of space where to put your routes.
There are some protection mechanism for this scenario, IOS has
'lsp-full suppress interlevel external' and JunOS has
'prefix-export-limit'

Very different to advertise say 1M routes from 1router (won't work)
than advertising 1k routes from 1k routers each (no particular reason
why it wouldn't work).
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-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.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-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.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-nsp] how many IGP routes is too many? [ In reply to ]
> Mark Tinka
> Sent: Wednesday, April 8, 2020 12:55 PM
>
> 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.
>
Right, but there are bunch of techniques to address the FIB scaling problem
of MPLS all the way to access layer (cell tower) deployments.

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [c-nsp] how many IGP routes is too many? [ In reply to ]
On 9/Apr/20 10:55, adamv0025@netconsultings.com wrote:

> Right, but there are bunch of techniques to address the FIB scaling problem
> of MPLS all the way to access layer (cell tower) deployments.

Agreed.

The goal is always to implement the least complex one (bearing in mind,
of course, that "complex" means different things to different people).

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp