cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1666
Views
15
Helpful
4
Replies

OSPF hello and dead timers

trane.m
Beginner
Beginner

Level of understanding: CCNA

There are different Hello and Dead timers for non-broadcast network types and broadcast and point-to-point network types. I know the timers, but i don't know why there is a difference? Why isn't it just the same for all network types?

2 Accepted Solutions

Accepted Solutions

Hello,

As @MHmh diagram points out the medium these timers are set on are typically for longer distances to travel. Usually the networks with the lower hello/dead time are local routers or in close proximity. The networks that need to traverse half the globe or are on slower links need a higher timer to compensate for the delay. You can manually configure the timers per interface or you can change the network type of the link with the command:

ip ospf network <networktype>   - to set network type
show ip ospf interface <interface#/#>    - to verify network type

 

To change the timers to reflect the network type.

Hope that helps.

-David

 

View solution in original post

Joseph W. Doherty
Hall of Fame
Hall of Fame

Although both @MHM Cisco World and @David Ruess are correct about possible additional delay between router neighbors with some topologies, I suspect Cisco's settings might have more to due with the "complexity" of "hello" peering between routers on certain topologies and/or expectations of how long a network should wait to detect a lost router neighbor.

I.e. what kind of networks needs something like Cisco's default OSPF dead timers of 40 or (especially) 120 seconds?  (In the past I've worked with global networks, using OSPF, running across "slow" [e.g. 64 Kbps] links.  Even from one side of the world to the other, one direction latency generally didn't exceed a quarter of a second.)

A broadcast medium is likely some form of LAN and p2p will often detect loss of neighbor with a concurrent down interface on both ends of the p2p link.  I.e. with a LAN, we might not have multiple peer detection of a lost neighbor from hardware, but can use broadcasts (or multicast) to "quickly" determine status of multiple routers on a shared segment, and as noted, with p2p likely have concurrent down interface detection.

With non-broadcast medium and/or multi-point, complexity of relaying peer status, between neighbors, is more involved.

If you read, for example, OSPFv2's RFC, its hello processing makes distinctions between broadcast, NBMA and multipoint (OSPF RFC hello protocol).

Likely, Cisco set its time defaults to be especially conservative, and to insure they didn't accidentally/incorrectly take down a working connection mistakenly believing it failed.  (In an [earlier?] networking world where there were not many, if any, redundant paths, incorrectly taking down a live connection would be worse then "detecting" a real line drop 40 to 120 seconds after it already happened.)

View solution in original post

4 Replies 4

5125-delay-details-fig5-1.png

from router to router through many L2 and/or L3 there is many delay and this delay must add to dead time.

Hello,

As @MHmh diagram points out the medium these timers are set on are typically for longer distances to travel. Usually the networks with the lower hello/dead time are local routers or in close proximity. The networks that need to traverse half the globe or are on slower links need a higher timer to compensate for the delay. You can manually configure the timers per interface or you can change the network type of the link with the command:

ip ospf network <networktype>   - to set network type
show ip ospf interface <interface#/#>    - to verify network type

 

To change the timers to reflect the network type.

Hope that helps.

-David

 

Joseph W. Doherty
Hall of Fame
Hall of Fame

Although both @MHM Cisco World and @David Ruess are correct about possible additional delay between router neighbors with some topologies, I suspect Cisco's settings might have more to due with the "complexity" of "hello" peering between routers on certain topologies and/or expectations of how long a network should wait to detect a lost router neighbor.

I.e. what kind of networks needs something like Cisco's default OSPF dead timers of 40 or (especially) 120 seconds?  (In the past I've worked with global networks, using OSPF, running across "slow" [e.g. 64 Kbps] links.  Even from one side of the world to the other, one direction latency generally didn't exceed a quarter of a second.)

A broadcast medium is likely some form of LAN and p2p will often detect loss of neighbor with a concurrent down interface on both ends of the p2p link.  I.e. with a LAN, we might not have multiple peer detection of a lost neighbor from hardware, but can use broadcasts (or multicast) to "quickly" determine status of multiple routers on a shared segment, and as noted, with p2p likely have concurrent down interface detection.

With non-broadcast medium and/or multi-point, complexity of relaying peer status, between neighbors, is more involved.

If you read, for example, OSPFv2's RFC, its hello processing makes distinctions between broadcast, NBMA and multipoint (OSPF RFC hello protocol).

Likely, Cisco set its time defaults to be especially conservative, and to insure they didn't accidentally/incorrectly take down a working connection mistakenly believing it failed.  (In an [earlier?] networking world where there were not many, if any, redundant paths, incorrectly taking down a live connection would be worse then "detecting" a real line drop 40 to 120 seconds after it already happened.)

Martin L
VIP
VIP

Long time ago I wonder the same thing   Basically speaking I think the default timer differences is based on bandwidth availability and utilization as well as in technology (LAN vs WAN).  Whether increase of decrease timers depends on link speed, load or utilization and reliability. In order to support OSPF operations, hello packets must be periodically and reliable exchanged.  LAN Ethernet is faster then WAN over Serial link like T1, Frame Relay.  LAN is not only fast but also more reliable comparing to WAN technologies which were originally slow and less reliable.  Secondly, compare type of network: point 2 point and NBMA non-broadcast multi-access.  NBMA, usually hub-spoke topology, may have several links to neighbors coming to the same interface. Here, NBMA link bandwidth must be shared among several neighbors. On low-speed links, you may want to increase the Hello timers so that those packets will use less link bandwidth. Lastly, legacy WAN P2P links (HDLC, PPP and P2P Frame relay) are sort of exception. Despite their low speed/low bandwidth type, I think engineers decided to set 10 second Hello timers based on 2 factors: P2P has only 2 neighbors possible and there is no need for DR/BDR elections.  

Note: original OSPF RFC specification has only 2 modes with with 30 second timers: Non-Broadcast and Point to Multipoint.

Regards, ML
**Please Rate All Helpful Responses **

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: