[j-nsp] ispf support on Juniper routers

[Andrew Jimmy]

Does Juniper router support ispf feature so that router only recalculate a
portion of the Shortest Path Tree when receive local link state
advertisements

Cisco

router ospf 1

ispf

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

[Stefan Fouant]

Yes it does. Jeff Doyle speaks of this in his book 'OSPF vs. IS-IS'.
I am mobile right now and don't have my book here for reference, but
IIRC Juniper supports incremental SPF runs when the additions to a
given node are stub networks only. Harry
Reynolds and many other knowledgeable folks are on this list - I'm
sure they will correct me if I am wrong.

--
Sent from Gmail for mobile | mobile.google.com

Stefan Fouant

Stay the patient course.
Of little worth is your ire.
The network is down.

[Paul Goyette]

Having just recently looked at this area of the code, I can
confirm that Juniper runs incremental SPF whenever possible.

Paul Goyette
Juniper Networks Customer Service
JTAC Senior Escalation Engineer
Juniper Security Incident Response Team
PGP Key ID 0x53BA7731 Fingerprint:
FA29 0E3B 35AF E8AE 6651
0786 F758 55DE 53BA 7731

[Masood Ahmad Shah]

JUNOS software does not support ISPF but does perform partial route
calculations when the ospf topology is stble and only routing information
changes, you can mix this process up even further with spf-options...I guess
you will have ispf (enable/disable) in same hierarchy :)

jahil@R1# top set protocols ospf spf-options ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
delay Time to wait before running an SPF (50..8000
milliseconds)
holddown Time to hold down before running an SPF (2000..20000
milliseconds)
rapid-runs Number of maximum rapid SPF runs before holddown
(1..5)
{master}[edit]

Regards,
Masood

-----Original Message-----
From: juniper-n...@puck.nether.net
[mailto:juniper-n...@puck.nether.net] On Behalf Of Stefan Fouant
Sent: Thursday, March 05, 2009 4:22 PM
To: Andrew Jimmy; junip...@puck.nether.net
Subject: Re: [j-nsp] ispf support on Juniper routers

[Phil Mayers]

Paul Goyette wrote:
> Having just recently looked at this area of the code, I can
> confirm that Juniper runs incremental SPF whenever possible

As I understand it, there are two types of ispf:

* ISPF where the LSDB changes are type5 LSA i.e. at the leaves of the
SPF tree, which can be done incrementally. I believe both IOS and JunOS
do this by default?

* the "extra" ispf that the Cisco IOS command does, which applies to
type1/2 LSA changes:

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfispf.html

Does JunOS do both or only the former?

[Paul Goyette]

JUNOS will perform ONLY external route recalculation if a
Exzternal (Type-5) or NSSA (Type-7) LSA changes.

JUNOS will perform ONLY inter-area and external route
recalculation if a Network Summary (Type-3) LSA changes,
AND the area from which the LSA originates is NOT known
to be a virtual-link transit area.

JUNOS will perform a full SPF for intra- and inter-area
routes as well as externals for all other LSA changes.

JUNOS does not have Incremental SPF (for intra-area SPF);
if JUNOS needs to run SPF for intra-area routes, it runs
a full SPF.

Paul Goyette
Juniper Networks Customer Service
JTAC Senior Escalation Engineer
Juniper Security Incident Response Team
PGP Key ID 0x53BA7731 Fingerprint:
FA29 0E3B 35AF E8AE 6651
0786 F758 55DE 53BA 7731

> -----Original Message-----
> From: Phil Mayers [mailto:p.ma...@imperial.ac.uk]
> Sent: Monday, March 09, 2009 5:00 AM
> To: Paul Goyette
> Cc: Stefan Fouant; Andrew Jimmy; junip...@puck.nether.net
> Subject: Re: [j-nsp] ispf support on Juniper routers
>

[Phil Mayers]

Paul Goyette wrote:
> JUNOS will perform ONLY external route recalculation if a
> Exzternal (Type-5) or NSSA (Type-7) LSA changes.
>
> JUNOS will perform ONLY inter-area and external route
> recalculation if a Network Summary (Type-3) LSA changes,
> AND the area from which the LSA originates is NOT known
> to be a virtual-link transit area.
>
> JUNOS will perform a full SPF for intra- and inter-area
> routes as well as externals for all other LSA changes.
>
> JUNOS does not have Incremental SPF (for intra-area SPF);
> if JUNOS needs to run SPF for intra-area routes, it runs
> a full SPF.

An extremely comprehensive answer! Thanks for taking the time!

Cheers,
Phil

[Mark Tinka]

On Monday 09 March 2009 08:34:35 pm Paul Goyette wrote:

> JUNOS will perform a full SPF for intra- and inter-area
> routes as well as externals for all other LSA changes.
>
> JUNOS does not have Incremental SPF (for intra-area SPF);
> if JUNOS needs to run SPF for intra-area routes, it runs
> a full SPF.

Would this behaviour differ for OSPFv3 and IS-IS, where
topology and prefix information are decoupled, even intra-
area?

Cheers,

Mark.

[Chris Whyte]

As just a side note... What's interesting about this so-called feature is
that it gives people the impression that it an important one in order to
achieve "fast" convergence yet spf calculation times are relatively
negligible (even in large networks). If fast convergence is important to you
then the time to update the forwarding table is where people should be
focusing their effort, imho. This is the true bottleneck. More specifically,
features that involve the pre-installment of backup next-hops for example.

Thanks, Chris

[Paul Goyette]

The other interesting thing is that the router needs to keep
additional state information in the internal OSPF routing
tables to enable ISPF. In my opinion, with today's routers,
memory seems to be more of a limitation than CPU horsepower.

Paul Goyette
Juniper Networks Customer Service
JTAC Senior Escalation Engineer
Juniper Security Incident Response Team
PGP Key ID 0x53BA7731 Fingerprint:
FA29 0E3B 35AF E8AE 6651
0786 F758 55DE 53BA 7731

> -----Original Message-----
> From: Chris Whyte
> Sent: Monday, March 09, 2009 9:31 PM
> To: Phil Mayers; Paul Goyette
> Cc: junip...@puck.nether.net
> Subject: Re: [j-nsp] ispf support on Juniper routers
>

[Mark Tinka]

On Tuesday 10 March 2009 11:53:57 am Paul Goyette wrote:

> The other interesting thing is that the router needs to
> keep additional state information in the internal OSPF
> routing tables to enable ISPF. In my opinion, with
> today's routers, memory seems to be more of a limitation
> than CPU horsepower.

But I imagine we'd be talking about control plane memory
here, not switch fabric memory (FIB), where the former is
more expandable (in relation, since they really aren't the
same thing).

Besides, if networks follow the good practice of using IGP's
to hold infrastructure and Loopback addresses only, and
throw the rest into iBGP, the scalability of the IGP is far
greater.

But I do agree, while iSPF and PRC help make CPU utilization
more efficient, they actually mostly shine during periods
where bad things are happening to the network, e.g. multiple
link or node failures, control plane attacks, e.t.c. So
under normal circumstances, today's routers have quick
enough CPU's for SPF calculations not to be such a huge
problem (good fundamental design being the case. of course).

Cheers,

Mark.

[Richard A Steenbergen]

On Mon, Mar 09, 2009 at 08:53:57PM -0700, Paul Goyette wrote:
> The other interesting thing is that the router needs to keep
> additional state information in the internal OSPF routing
> tables to enable ISPF. In my opinion, with today's routers,
> memory seems to be more of a limitation than CPU horsepower.

Really? It seems like control plane memory is absurdly cheap and
plentiful these days. I can't even think of any situation outside of a
memory leak in which I've run low on memory on a well maintained modern
router (i.e. not dusting off an old 7507 in 2009) in the last 10 years.
Modern Juniper RE's have all been shipping for 4GB for a few years now
(with more to come soon, no doubt), while last I heard rpd can't even
address more than 2GB currently. It doesn't seem like I or anyone else
with a reasonable router config (not counting massive route-server apps
which would be better served by JCS anyways) are in any danger of
running out any time soon.

Meanwhile, my RE's are constrained at 100% CPU every single time there
is any instability or reconvergence event in the network (or sometimes
they're at 100% cpu 24/7 depending on how many unresolved rpd bugs I'm
being affected by at any given moment :P). Given those realities, I'd
gladly trade memory for better performance any day of the week.

--
Richard A Steenbergen <r...@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

[Mark Tinka]

On Tuesday 10 March 2009 01:21:35 pm Richard A Steenbergen
wrote:

> Meanwhile, my RE's are constrained at 100% CPU every
> single time there is any instability or reconvergence
> event in the network (or sometimes they're at 100% cpu
> 24/7 depending on how many unresolved rpd bugs I'm being
> affected by at any given moment :P). Given those
> realities, I'd gladly trade memory for better performance
> any day of the week.

In one of the IS-IS tutorials I've held at past community
events/workshops, we look at limiting exposure of the
control plane CPU by taking advantage of some of the
throttling capabilities available in vendor routers
implementing the popular link state routing protocols today,
i.e., mainly SPF and PRC delay.

As Chris already mentioned, even in the largest of networks,
full SPF runs take only tens of milliseconds to complete,
and generally, events that set off iSPF or PRC do not occur
that often.

Juniper have the 'spf-delay' command, while Cisco have the
'spf-interval' and 'prc-interval' commands. The algorithms
between both vendors differ, but the end goal is the same.

These are particularly useful during times of "badness". The
trick is to have values that are high enough for routers not
to suffer during heavy instability, while still keeping them
low so that reconvergence happens in a timely manner.

Cheers,

Mark.