OSPF Hello & Dead Intervals -> Convergence

[ChrisNewnham_]

Hello

Am I right in thinking that reducing the OSPF Hello interval would improve convergence on a link up event, and reducing the Dead interval improves convergence on a link down event?

Thanks

[M02@rt37]

Hello @ChrisNewnham_

You're correct that reducing the OSPF Hello interval can improve convergence on a link up event, and reducing the Dead interval can improve convergence on a link down event.

By reducing the Hello interval, routers can detect neighbor failures and establish new adjacencies more quickly. This can improve convergence when a link comes up because routers will detect the presence of new neighbors faster and begin exchanging routing information sooner.

By reducing the Dead interval, routers can detect neighbor failures more rapidly, improving convergence when a link goes down. When a router determines that a neighbor is no longer reachable, it can trigger the recalculation of routes to account for the link failure.

But, adjusting the Hello and Dead intervals should be done carefully, considering factors such as network stability, link reliability, and resource utilization. Lowering these intervals can increase control traffic and consume more network bandwidth and processing resources. It's essential to strike a balance between faster convergence and the impact on network performance.

[ChrisNewnham_]

Thanks, I believe using point-to-point interfaces instead of broadcast (when using a directly connected link) also improves convergence?

Due to no DR election process.

[M02@rt37]

@ChrisNewnham_ 

Yes! Using point-to-point interfaces simplifies the network configuration and reduces the overhead associated with DR/BDR election and related control traffic. It also eliminates the need for an additional layer of communication between routers for electing the DR/BDR. This can lead to improved convergence time and reduced complexity in the network. 

[Joseph W. Doherty]

Actually, the question of using OSPF p2p on broadcast media (e.g. Ethernet), came up recently before (in another topic).  I'm for it, as I've stated then, and now, adjacency comes up noticeably faster.  However, to "document" this, I tried both approaches in Packet Tracer, which there too, p2p seemed to establish adjacency about 4x faster, but first, who truly trusts PT and second, PT didn't generate ms adjacency log entries.

So, I next tried a comparison using CML on my PC.

Using the default broadcast OSPF type, got results usually like:

*May 21 21:27:15.724: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
*May 21 21:27:55.734: %OSPF-5-ADJCHG: Process 10, Nbr 192.168.1.1 on GigabitEthernet0/0 from LOADING to FULL, Loading Done

i.e. about 40 seconds.

Using p2p got results like:

*May 21 21:45:37.205: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
*May 21 21:45:47.061: %OSPF-5-ADJCHG: Process 10, Nbr 192.168.1.2 on GigabitEthernet0/0 from LOADING to FULL, Loading Done

I.e. about 10 seconds.

Interesting, CML like PT, p2p network type, again, was about 4x faster.

We can quibble over the meaning of "noticeable", but to me, waiting an additional 30 seconds for adjacency to go to full status, was noticeable.  (Laugh, in fact, one day doing something with OSPF in PT, I began to wonder if I misconfigured OSPF between a pair of routers, as I was waiting so long for full adjacency to establish.  My "misconfiguration" was, forgetting to use p2p.)

Although the above is nice to know, it many modern networks, re-establishing a path often isn't nearly as important as it once was.  This because, often modern networks often provide multiple paths.  Big difference getting the ONLY path back on-line as quickly as possible vs. restoring another path.

Conversely, though, when there's no alternative path, it often doesn't matter much whether the network "knows" the path is broken, vs. traffic being blacked holed.  With, redundant path networks, insuring traffic is redirected to an alternate path, as quickly as possible (ideally so quickly, in-flight flows are impacted so little, the "application" doesn't care) is now the concern, and for that, hello intervals is just one piece of solving that puzzle.

[MHM Cisco World]

The default values are 10 seconds for the hello time, and 40 seconds for the dead time. The usual rule of thumb with OSPF is to keep the dead time value four times the hello interval.
change the hello need to change dead as cisco recommend in end we must have dead 4 time hello times

[MHM Cisco World]

1-dont change default network types 

2-If you want very fast recover use BFD + OSPF 
BFD is light and fast protocol.

[M02@rt37]

@ChrisNewnham_ 

Good idea BFD

BFD stands for Bidirectional Forwarding Detection, which is a protocol used in networking to detect failures in the forwarding path between two devices, such as routers or switches. BFD provides rapid failure detection by monitoring the availability of the forwarding path and quickly notifying the devices involved if a failure is detected.

BFD is commonly used in routing protocols, such as OSPF and BGP, to provide fast failure detection and enhance the convergence of routing protocols. It helps reduce the convergence time and enables faster rerouting of traffic in the event of a failure, leading to improved network stability and availability.

[Joseph W. Doherty]

BFD shouldn't make a difference in how long it takes for a full adjacency to be established, but using p2p, when logical, does.

BFD also, at least in the past, wasn't much faster than basic OSPF fast hellos.  Its claim to fame, it's much less taxing to the platform.

Do not misunderstand the above, if you can use BFD, I too recommend doing so.

[Joseph W. Doherty]

Yes and no.  If up/down event causes port up/down, OSPF will use that as the triggering event, i.e. hello settings don't matter.  Oh, and a port up/down, unless you reconfigure link bounce, takes about 50 ms, I recall.

In modern networks, especially if supporting voice. IMO, waiting up to forty seconds to detect a loss OSPF neighbor is unacceptable.  Without fast OSPF hello support, even a dead time detection of 3 or 4 seconds is bad.  (BTW, I'm assuming there's an alternative path.)  With fast hellos, you might get dead time down to a second, although if doing this on more than a couple of interfaces, might over tax the device.

BFD was mentioned, and it can be used to minimize taxing the device.  It usually allows 1 second down detection, sometimes less.  In my past experience, dead times of close to 500ms seemed possible.

Although you only asked about OSPF hello timers on convergence, there's much more to overall convergence time issues.  For example, you later asked about using OSPF p2p when that's the logical situation on a broadcast media. As M02@rt37 correctly responded, it does (noticeably) decrease the time for OSPF adjacency to be established.

Again, there's much to consider on the subject of convergence time.  For example, QoS should be used to guarantee OSPF hellos are neither delayed nor dropped. (Often this becomes more important when you decrease timers and/or missed hellos.)

Cisco had a great document, discussing adjusting convergence variables for both EIGRP and OSPF, but recently I was unable to find it.

[MHM Cisco World]

M02@rt37 @Joseph W. Doherty 
please share one cisco doc. for lab or network design suggest change the network from broadcast to p2p.

the network type change in these condition 
1- one side support only network type p2p (some FW)
2- we need some control of prefix we change one side to p2p and other side to p2mp


this second post  see suggest change network type, so please share any cisco doc. 

why I so aware about change the network type ? we must sure that in both side of link there is only two peer if there is multi then there will be issue in ospf. so keep default. 
thanks 
MHM

[Joseph W. Doherty]

"please share one cisco doc. for lab or network design suggest change the network from broadcast to p2p."

Why?

Rather, perhaps, you share Cisco documentation describing why changing this particular default is "bad" in this use case.

As I wrote in the other topic, just that something is a default does not make it the best option in all use cases.  The fact a default can be changed supposes there are likely reasons why it should be changed.

Also, as much as I value Cisco's advice, I don't consider it "holy writ", they, from time to time, get it wrong.  (Admittedly, they will usually, eventually, get it right [laugh, or get it closer to being right].)

[MHM Cisco World]

the command is 
ip ospf network type <<- from command words you must know it decide not link but the network type.

change the broadcast to Point-to-Point, it easy to me that say YES it can and it can down your ospf establish time 
but he ask and we must explain to him why use this command and why you must not use it
I have three router connect to one SW 
the network here is broadcast not p2p, so if he see slow ospf he will return to our comment, and use p2p and this break the ospf. 
we must clear to him that p2p use only when you have router to only one router. 
it can reduce the p2p YES sure it can reduce but it not rule, the rule first is check the network then if he have p2p he can reduce the time with using p2p instead of broadcast 
if he can not change the network type 
he can go to fast hello @Joseph W. Doherty  mention which is in subsecond 
if he use old OSPF ver. that not support fast hello he can use BFD which in in mSec

but directly suggest change the network type, I see it not complete answer 

thanks 
MHM

[Joseph W. Doherty]

"but directly suggest change the network type, I see it not complete answer"

It was not suggested as a complete answer, if fact, initally, it wasn't suggested at all by myself or M02@rt37 .  OP's first follow on post had:

"Thanks, I believe using point-to-point interfaces instead of broadcast (when using a directly connected link) also improves convergence?

Due to no DR election process."

On the face of that statement, it's probably totally true (less overhead, less time).  No mention of media, or default network settings.  I.e. that statement could also apply to a serial link between routers where the default network type is p2p.

M02@rt37 confirmed for the implied p2p setup, that setting network type to p2p (if not the default), doing so can lead to improved (i.e. decreased) convergence time.  That reply did not suggest it be used, certainly though it noted advantages of using it.

Your reply "1-dont change default network types", pretty much is a blanket suggestion to never effect this change.

My initial post, along with other convergence considerations, also confirmed (M02@rt37 posting) that I've seen p2p noticeably reduce the time for full adjacency to be established.  Even in that post, I did not recommend p2p be used or it's the total solution, I just documented personal observation of the effect of using that setting.

"but he ask and we must explain to him why use this command and why you must not use it"

OP's follow on question asked for confirmation that it can improve (decrease) convergence time.  I, and likely M02@rt37 , would have noted any reasons to not use it, if we believed there were any (for the p2p topology case).  I'm still waiting for your reason, with supporting 3rd party documentation, why using it for a p2p would be "bad".

"I have three router connect to one SW 
the network here is broadcast not p2p,"

Yup, Ethernet defaults to broadcast.  Two routers connected by a p2p Ethernet link is also, by default, boardcast type.  Your 3 routers, might be in different VLANs, if a VLAN capable switch, so two of them may be in same VLAN and still be, logically, p2p.

Anyway, rather than going on and on, it appears you no longer have a blanket recommendation against changing the network type, from its default, if it serves some purpose, correct?  If so, I certainly agree.

You also now agree a p2p network type might establish adjacency faster, correct?  If so, that, to me, seems the usual case.

You caution against, changing network type, without understanding all the ramifications, correct?  If so, I fully agree.

[Joseph W. Doherty]

"I have three router connect to one SW 
the network here is broadcast not p2p,"

BTW, having logically p2p connections via a transit switch, unfortunately generally negates the other router "seeing" it's port drop when the other router's interface drops.  I.e. whenever possible, having OSPF router connect in such a way their port drops if the other side's port drops.  This generally produces the best down/up detection times, without needing to adjust default hello timers and/or use fast hellos and/or BFD.  The latter two, are not always supported (current gen software and/or hardware, though, likely does support).

Also, BTW, if using optical switches for transit, some of those can down both ends of the path if there's a break anywhere in the transit path.  (This seems to be sometimes an option which you may need to ask the optical network engineer to enable.)