Before OSPF routers can exchange routes, they must first find each other. This neighbor discovery process, driven by Hello packets, is the foundation of OSPF operation and a frequent topic on the CCNA 200-301 exam (Objective 3.4). Understanding how Hellos work, the timers that govern them, and the conditions that must match for adjacency formation is critical for both the exam and real-world OSPF troubleshooting.
Jump to a section
Imagine a neighborhood watch program in a gated community. Each house (router) wants to know who its neighbors are and whether they are still home. The program works like this: every 10 seconds (the Hello timer), each resident steps onto their front porch and waves a flag with their name, their street address, and a secret handshake code (the OSPF router ID, area ID, and authentication key). They also shout out the names of neighbors they've seen waving recently (the Neighbor list). If a resident stops waving for 40 seconds (the Dead interval), the other residents assume that house is empty and remove it from their list. For two residents to become official 'neighbors,' they must agree on several things: the secret handshake code (same authentication), the street they live on (same area), and the frequency of waving (same Hello/Dead timers). If one resident waves every 10 seconds and another waves every 30 seconds, they'll never synchronize and never become neighbors. In a large community, a designated 'block captain' (Designated Router) is elected to reduce the chaos of everyone waving at everyone—only the captain and a backup captain maintain full waving relationships with all houses, while others just wave to the captain. This analogy maps directly to OSPF: Hello packets are the waves, the Hello and Dead timers are the intervals, and the matching parameters (area ID, timers, authentication, subnet mask, stub flag) are the conditions that must be identical for two routers to become neighbors and eventually exchange routing information.
What Are OSPF Hello Packets?
OSPF Hello packets are small, periodic messages sent by OSPF-enabled interfaces to discover and maintain relationships with neighboring routers. They are the first step in the OSPF neighbor state machine, moving routers from the Down state to the Init state and eventually to the Full state. Hello packets are sent to the multicast address 224.0.0.5 (AllSPFRouters) on broadcast and point-to-point networks, and to the unicast address of the neighbor on non-broadcast multi-access (NBMA) networks.
Hello Packet Fields and Their Purpose
Each Hello packet contains:
Router ID: A 32-bit unique identifier for the originating router (usually the highest loopback IP, or the highest active physical IP).
Area ID: The OSPF area from which the packet is sent. Routers must be in the same area to become neighbors.
Authentication: Optional password or cryptographic hash. If authentication is configured, it must match on both sides.
Network Mask: The subnet mask of the interface. On broadcast networks, this must match for the routers to become neighbors.
Hello Interval: The interval (in seconds) between Hello packets (default 10 seconds on broadcast/point-to-point, 30 seconds on NBMA).
Router Dead Interval: The interval (in seconds) after which a neighbor is considered dead if no Hello is received (default 4x Hello interval: 40 seconds on broadcast, 120 seconds on NBMA).
Options: Flags indicating optional capabilities (e.g., External Routing, Multicast, NSSA). The E-bit (External) must match; if one router sets it and the other does not, they will not become neighbors.
Priority: Used for DR/BDR election (default 1). A priority of 0 means the router is ineligible to become DR or BDR.
Designated Router (DR): The IP address of the DR on the segment (0.0.0.0 if none).
Backup Designated Router (BDR): The IP address of the BDR (0.0.0.0 if none).
Neighbor List: The Router IDs of neighbors from which Hellos have been recently received.
The Neighbor Discovery Process Step by Step
Down State: No Hellos received. The router sends Hellos periodically.
Init State: A Hello is received from a neighbor, but the neighbor's Router ID is not in the received Hello's neighbor list. The router adds the neighbor to its neighbor table and transitions to Init.
Two-Way State: The router receives a Hello that contains its own Router ID in the neighbor list. This confirms bidirectional communication. On broadcast networks, at this point DR/BDR election occurs. If no election is needed (point-to-point), routers proceed to ExStart.
ExStart State: The routers negotiate the master/slave relationship and the initial Database Description (DBD) sequence number.
Exchange State: Routers exchange DBD packets containing summaries of their LSDBs.
Loading State: Routers request missing LSAs using Link State Request (LSR) packets and receive them via Link State Update (LSU) packets.
Full State: Routers have identical LSDBs and are fully adjacent.
Hello Timers and Defaults
| Network Type | Hello Interval | Dead Interval | Default Priority | |---|---|---|---| | Broadcast | 10 seconds | 40 seconds | 1 | | Point-to-Point | 10 seconds | 40 seconds | N/A (no DR/BDR) | | NBMA | 30 seconds | 120 seconds | 1 | | Point-to-Multipoint | 30 seconds | 120 seconds | N/A |
Conditions for Neighbor Formation
For two OSPF routers to become neighbors, the following must match in their Hello packets:
Same Area ID: Must be identical (including area 0).
Same Subnet Mask: On broadcast and point-to-point networks, the subnet mask must match.
Same Hello and Dead Intervals: If they differ, the routers will not become neighbors.
Same Authentication: If authentication is configured, the type and password/key must match.
Same Stub Flag (E-bit): Both routers must agree on whether the area is a stub area. One cannot be a stub and the other not.
Same MTU: Although not strictly required for neighbor discovery, mismatched MTU can cause problems during the Exchange state.
IOS CLI Verification Commands
To verify OSPF neighbor relationships, use:
show ip ospf neighborExample output:
Neighbor ID Pri State Dead Time Address Interface
10.1.1.1 1 FULL/DR 00:00:35 192.168.1.2 GigabitEthernet0/1
10.1.1.2 1 2WAY/DROTHER 00:00:38 192.168.1.3 GigabitEthernet0/1To see detailed Hello packet information:
show ip ospf interface gigabitEthernet 0/1Output includes:
Internet Address 192.168.1.1/24, Area 0
Process ID 1, Router ID 10.1.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.1.1.1, Interface address 192.168.1.1
Backup Designated router (ID) 10.1.1.2, Interface address 192.168.1.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5Interaction with Related Protocols
OSPF Hello packets are part of the OSPF protocol (IP protocol 89). They operate independently of TCP or UDP. The neighbor discovery process is essential for forming adjacencies, which then use the reliable flooding mechanism of OSPF (using LSR, LSU, and LSAck packets) to exchange routing information. The Hello protocol also supports the election of DR and BDR on broadcast and NBMA networks, which reduces the number of adjacencies required.
Verify OSPF is enabled on interfaces
Before troubleshooting neighbor issues, confirm that OSPF is configured on the relevant interfaces. Use `show ip ospf interface brief` to see which interfaces are participating in OSPF. If an interface is missing, the `network` statement under the OSPF process may be incorrect or the interface may be in a passive state (no Hellos sent). Check the OSPF process configuration with `show running-config | section router ospf`.
Check neighbor state with show ip ospf neighbor
This command shows the list of OSPF neighbors, their state, and the interface. Look for states like FULL, 2WAY, or INIT. If neighbors are stuck in INIT or EXSTART, there may be a mismatch in parameters or a Layer 2 issue. The 'Dead Time' column shows how long since the last Hello was received. If this counts down to zero, the neighbor is considered dead.
Examine Hello and Dead intervals
Use `show ip ospf interface [interface]` to view the configured Hello and Dead intervals. If these do not match on both sides, the routers will never become neighbors. To change them, use `ip ospf hello-interval [seconds]` and `ip ospf dead-interval [seconds]` under the interface configuration. Remember that the Dead interval should be at least 4 times the Hello interval.
Verify network type consistency
OSPF network types (broadcast, point-to-point, NBMA, etc.) affect Hello timers and DR/BDR election. Use `show ip ospf interface` to see the network type. If one side is broadcast and the other is point-to-point, they may still become neighbors if other parameters match, but DR/BDR election will be inconsistent. To change the network type, use `ip ospf network [type]` on the interface.
Confirm matching subnet masks
On broadcast and point-to-point networks, OSPF requires the subnet mask to match. Use `show ip interface brief` or `show running-config interface [interface]` to verify the IP address and mask. If masks differ, OSPF will not form a neighbor relationship. Correct the mask on one side to match.
Check for ACLs or firewall blocking OSPF
OSPF uses IP protocol 89. Access control lists (ACLs) or firewalls can block OSPF packets. Use `show ip access-lists` to check for any ACLs applied to the interface. Also verify that the interface is not in a passive state under OSPF (which prevents sending Hellos) by checking `show ip ospf interface` for 'Passive' flag. To remove passive, use `no passive-interface [interface]` under the OSPF process.
In enterprise networks, OSPF neighbor discovery is the first thing that must work for dynamic routing to function. One common scenario is a multi-vendor environment where a Cisco router connects to a Juniper router over a point-to-point link. By default, Cisco uses broadcast network type on Ethernet interfaces, while Juniper uses point-to-point. This mismatch can cause Hello timer differences (10 vs 30 seconds) or DR election issues. A network engineer must configure the Cisco interface with ip ospf network point-to-point to match the Juniper side, ensuring Hellos are sent every 10 seconds with no DR election.
Another scenario is in a data center using OSPF over VLAN trunks. If two switches have mismatched MTU values (e.g., one has jumbo frames enabled), they may successfully discover each other via Hellos but then get stuck in the ExStart state because DBD packets exceed the MTU. The engineer must either adjust MTU to match or configure ip ospf mtu-ignore on the interface (though this is not recommended for production).
A third scenario involves OSPF authentication. In a secure environment, engineers often configure MD5 or SHA authentication on OSPF packets. If one router has authentication enabled and the other does not, Hellos are silently dropped, and no neighbor relationship forms. The engineer must either remove authentication or configure it consistently. Using debug ip ospf hello can reveal authentication mismatches.
Scale considerations: In large broadcast networks (e.g., a LAN segment with 50 routers), the DR/BDR election reduces the number of adjacencies from n(n-1)/2 to 2n-3. Without this, Hello traffic and LSA flooding would overwhelm the network. Misconfiguring the priority (e.g., setting a low-end router to priority 255) can cause it to become DR, leading to suboptimal forwarding and potential instability.
The CCNA 200-301 exam tests OSPF neighbor discovery under Objective 3.4 (Configure and verify OSPF). Expect questions that ask you to identify why two routers are not becoming neighbors based on a configuration snippet or show command output.
Most Common Wrong Answers and Why Candidates Choose Them:
"OSPF process ID must match" – Candidates often think the process ID (e.g., router ospf 1) must be the same on both routers. This is FALSE. The process ID is locally significant and can differ. The area ID must match, not the process ID.
"Router IDs must be in the same subnet" – Router IDs are not required to be in the same subnet; they are just 32-bit identifiers. Candidates confuse router ID with interface IP.
"Hello and Dead intervals must be exactly the same" – While they must match for neighbor formation, the exam may trick you by showing one router with Hello 10 and another with Hello 20. The correct answer is that they will not become neighbors because intervals differ. The Dead interval is typically 4x the Hello, but it can be configured independently.
"Authentication must be configured on both sides or neither" – This is actually TRUE, but candidates sometimes think it's optional. If authentication is configured on one side, it must match on the other, or Hellos are dropped.
Specific Values and Command Outputs:
Default Hello interval on broadcast: 10 seconds.
Default Dead interval: 40 seconds.
Default priority: 1.
The show ip ospf neighbor output shows state as FULL, 2WAY, INIT, etc.
The show ip ospf interface output shows timer intervals.
Decision Rule for Scenario Questions:
When given a scenario where two routers are not forming an adjacency, check in this order: 1. Are both interfaces up/up? (Layer 1/2) 2. Are Hellos being sent and received? (Check ACLs, passive interface) 3. Do Hello parameters match? (Area, subnet mask, timers, authentication, stub flag) 4. Is the network type compatible? (Broadcast vs point-to-point) 5. Is there a DR/BDR election issue? (Stuck in 2WAY instead of FULL on broadcast)
Eliminate answers that mention mismatched process IDs or router IDs as the cause of neighbor failure.
OSPF Hello packets are sent to 224.0.0.5 every 10 seconds on broadcast and point-to-point networks.
The Dead interval is 40 seconds by default (4x Hello) on broadcast networks.
For two routers to become neighbors, the following must match: Area ID, subnet mask, Hello/Dead intervals, authentication, and stub flag (E-bit).
The OSPF process ID is locally significant and does not need to match between neighbors.
The `show ip ospf neighbor` command displays neighbor state, dead time, and interface.
On broadcast networks, DR/BDR election occurs after the Two-Way state.
A passive interface does not send Hellos, preventing neighbor discovery on that interface.
These come up on the exam all the time. Here's how to tell them apart.
OSPF Hello Protocol
Uses multicast 224.0.0.5
Sent every 10 seconds (broadcast/point-to-point)
Dead interval 40 seconds (4x Hello)
Requires matching subnet mask, area, timers, authentication, stub flag
Supports DR/BDR election on broadcast networks
EIGRP Hello Protocol
Uses multicast 224.0.0.10
Sent every 5 seconds (most network types)
Hold time 15 seconds (3x Hello)
Requires matching AS number, K-values, authentication
No DR/BDR election; uses Reliable Transport Protocol (RTP)
Mistake
OSPF process IDs must match on neighboring routers.
Correct
Process IDs are locally significant and can differ. Only the area ID must match.
Candidates confuse process ID with area ID because both are numbers configured in the OSPF process.
Mistake
If Hello and Dead intervals are different, the router with the shorter Hello will adjust.
Correct
OSPF does not negotiate timers; if they differ, the routers will not become neighbors.
Some routing protocols like EIGRP can negotiate, but OSPF does not.
Mistake
The router ID must be the IP address of the interface used for adjacency.
Correct
Router ID is a 32-bit identifier, often the highest loopback IP, and does not need to be in the same subnet as neighbors.
Candidates think the router ID is used for routing, but it's just an identifier.
Mistake
OSPF neighbors must be directly connected at Layer 3.
Correct
OSPF neighbors must be directly connected at Layer 2 (same subnet), but they can be multiple hops away if using virtual links or tunnels.
Candidates confuse OSPF with BGP, which can form neighbors across multiple hops.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. The OSPF process ID is locally significant and only identifies the OSPF process on that router. Neighboring routers can have different process IDs (e.g., router ospf 1 and router ospf 2) and still form an adjacency as long as other parameters like area ID, timers, and authentication match.
The Dead Time shows the time remaining (in hours:minutes:seconds) before the neighbor is declared dead if no Hello is received. It starts at the Dead interval (e.g., 40 seconds) and counts down. When it reaches 0, the neighbor is removed from the neighbor table. This timer is reset each time a Hello is received.
On a broadcast multi-access network, the 2WAY state is normal for non-DR/BDR routers. They stay in 2WAY and only form full adjacencies with the DR and BDR. If a router is not the DR or BDR, it will remain in 2WAY with other DROTHERs. Check the DR/BDR election by looking at the state column in `show ip ospf neighbor`.
Use the interface configuration command `ip ospf hello-interval [seconds]`. For example, to set it to 5 seconds: `interface gigabitEthernet 0/1`, then `ip ospf hello-interval 5`. You must also adjust the Dead interval accordingly (usually 4x the Hello) using `ip ospf dead-interval [seconds]`. Both sides must match.
The default network type for an Ethernet interface is broadcast. This means OSPF sends Hellos to 224.0.0.5 every 10 seconds, and DR/BDR election occurs. To change it to point-to-point (e.g., for a point-to-point link), use `ip ospf network point-to-point` on the interface.
On broadcast and point-to-point networks, yes, the subnet mask must match. If one interface has a /24 mask and the other has a /25, they will not become neighbors. On point-to-point links, however, some implementations may not check the mask. For CCNA, assume it must match on broadcast networks.
Use `debug ip ospf hello` to see Hello packets being sent and received. This will show if Hellos are being sent, if they are received from neighbors, and any mismatches in parameters (e.g., area, timers). Be cautious with debug on production networks as it can be CPU-intensive.
You've just covered OSPF Hello Packets and Neighbor Discovery — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?