Menu

ospf hello packet interval

OSPF Hello and Dead Intervals – Exclusive Details

OSPF Hello and Dead Intervals – Exclusive Details

/ /

OSPF Hello and Dead Interval_1

Devices enable OSPF to constantly track the status of their neighbors, sending and receiving hello packets. Hello, packets show whether each neighbour still is functioning, and sending and receiving link-state advertisement and acknowledgment packets. OSPF sends hello packets and expects to receive Hello packets at particular intervals. The Hello and Dead Intervals timer is included in the OSPF Hello messages.

  • Hello Interval- The Hello Interval defines how often routing devices send the hello packet. The time is fixed on all interfaces, including virtual links, to establish and maintain neighbour relationships. The hello interval time is specified in seconds before the routing device sends a hello packet out of an interface. This hello-interval time must be the same on all routing devices. The default hello time is 10 seconds in broadcast and point-to-point networks and 30 seconds in nonbroadcast multiple access (NBMA) networks.
  • Dead Interval- Dead interval defines how long we should wait for hello packets before we declare the neighbour dead and out of reach. If an OSPF enabled device does not receive a hello packet from a neighbour within a fixed time, the routing device changes its topology database showing that the neighbour is nonoperational. The dead time is specified in seconds. The router waits according to the dead Interval timer before declaring the device non-operational and unavailable. The Dead Interval timer must be the same on all routing devices on a shared network. By default, Dead Interval is four times the default hello interval.

The OSPF Hello and Dead intervals are configurable per interface. As shown in Figure 1, we can check the current configured value using the “show ip ospf interface” command. The GigabitEthernet 0/0 Hello and Dead intervals are set to the default 10 seconds and 40 seconds.

OSPF Hello and Dead Intervals

In Figure 2, the “show ip ospf neighbor” command is used on R1 to verify that R1 is adjacent to R2 and R3. The command is used subsequently several times. Notice that the output of the command illustrates that the dead time is counting down from 40 seconds. By default, this value is refreshed every 10 seconds when R1 receives a Hello from the neighbours.

Modifying OSPFv2 Intervals

Sometimes, we need to change the default Hello and Dead Intervals so that routers identify network failures in less time. Less timers increase traffic, but it reduces the convergence time. The default timer is prepared for most of the network because it is based on best practices and should only be altered in rare situations. The Hello and Dead Intervals are configurable values in interface configuration modes.

  • ip ospf hello-interval <seconds>
  • ip ospf dead-interval <seconds>

We can reset the Hello Interval and Dead Intervals to their default values using the “no ip ospf hello-interval” and “no ip ospf dead-interval” commands.

If we change the Hello interval to 5 seconds, immediately after changing the Hello interval, the Cisco IOS automatically changes the Dead interval to four times the Hello interval. However, it is not a good practice; it is always good to modify the timer manually. It is also important to modify the Hello and Dead Intervals on all adjacent routers because if alter one side of the OSPF link, when the Dead Timer expires on that router, it will lose the adjacency. The reason is that the values have only been changed on one side of the OSPF link. Therefore, the OSPF Hello and Dead intervals must match between neighbors.

Modifying OSPFv3 Intervals

We can also modify and change the OSPFv3 intervals just like OSPFv2. We can modify the Hello and Dead Interval using the following interface configuration mode command.

  • ipv6 ospf hello-interval seconds
  • ipv6 ospf dead-interval seconds

Similarly to OSPFv2, we can restore the interval values to their default using the “no ipv6 ospf hello-interval” and “no ipv6 ospf dead-interval” commands.

Similar to OSPFv2, if the OSPFv3 Hello Interval is changed to 5 seconds, Immediately after changing the Hello interval, the Cisco IOs automatically modify the Dead interval to four times the Hello interval. However, changing the dead interval manually to 20 seconds is also required. We can verify using the “show ipv6 ospf neighbor command.  The show ipv6 ospf interface command can also verify the Hello and Dead Intervals.

Introduction to Hello Packets

Introduction to Hello Packets

/ /

Hello, Packets Type 1 are OSPF packets sent periodically on all interfaces, including virtual links, to establish and maintain neighbor adjacency. It is a multicast packet with a multicast and broadcast capability, enabling dynamic discovery of neighboring routers. Hello packets advertise parameters on which routers agree to become neighbors. It also elects the Designated Router (DR) and Backup Designated Router (BDR) on multi-access networks. Point-to-point links do not require DR or BDR. The figure below illustrates the hello packet:

#image_title
  • Type—This is an eight-bit field that identifies the type of packet. It has three types: Type 1 indicates a Hello packet, Type 2 indicates a DBD packet, Type 3 indicates an LSR packet, Type 4 indicates an LSU packet and Type 5 is an LSAck packet.
  • Router ID—This is a 32-bit field expressed in dotted decimal notation that uniquely identifies the originating router.
  • Area ID– Area ID is also a 32 bit file that identifies the originated area of the packet.
  • Network Mask– Network mask associated with the sending interface

Note:– the above four fields are the part of OSPF header and the below six fields are the parts of OSPF hello Field.

  • Hello Interval– This field defines how often we send the hello packet. Hello interval also defines the frequency, in seconds, at which a router sends Hello packets. The default Hello interval on multi-access networks is 10 seconds. This hello-interval timer must be the same on neighbouring routers if not, an adjacency is not possible.
  • Router Priority– This field is used in a DR/BDR election. The default priority for all OSPF routers is 1 but we can also manually configure router priority from 0 to 255. The higher the value, the router becomes the DR on the link.
  • Dead Interval– This field defines how long we should wait for hello packets before declaring the neighbor dead and out of service. By default, the router Dead Interval is four times the Hello interval. This timer must be the same on neighboring routers; otherwise, an adjacency will not be established.
  • Designated Router (DR)– This is the Router ID of the DR.
  • Backup Designated Router (BDR)– This field defines the Router ID of the BDR.
  • List of Neighbors– This field identifies the router IDs of all adjacent routers.
Explanation of OSPF Packets Types

Explanation of OSPF Packets Types

/ /

Open Shortest Path First (OSPF) uses link-state packets (LSPs) to establish and maintain neighbour adjacencies. It also uses LSPs to exchange routing updates. There are five different OSPF packets type. The beginning of all OSPF packets is specified by the standard header of 24 bytes. A list of link state advertisements is to deal with all OSPF packets type. The figure below illustrates the five different OSPF packets types. Each link-state packet (LSPs) serves a specific purpose in the OSPF routing process:

Hello packet– This packet establishes and maintains adjacency with other Open Shortest Path First (OSPF) routers. The Open Shortest Path First (OSPF) protocol sends these packets periodically on all interfaces. This is a multicast packet discovering neighbouring routers dynamically.

Database Description (DBD) packet– This packet has an abbreviated list of the sending router’s Link-state Database (LSDBs). The receiving routers used DBD to check against the local Link-state Database (LSDBs). The Link-state Database (LSDBs); must be equal on all link-state routers within an area to build a perfect SPF tree. The database is designed from multiple packets.

Link-State Request (LSR) packet – When receiving routers read the DBD then receiving router can request more information about any entry in the DBD, sending an LSR packet. The router uses LSR packets for requesting the pieces of the neighbour’s database which are more up to date and complete. The router can also send multiple Link State Request packets.

Link-State Update (LSU) packet – This packet is used to reply link-state request (LRS) packet. The link-state update (LSU) contain further seven types of packets.

Link-State Acknowledgment (LSAck) packet – When the router receives an LSU packet, it sends an LSAck packet to the sender router to confirm receipt of the LSU packet. The LSAck data field is empty. Single Link State Acknowledgement packet can acknowledge the multiple link state advertisements.