VMware ESXi and vSphere Cluster Management

OSPF Neighbor Discovery and Hello Packet Requirements

Learn how OSPF routers discover neighbors, how Hello packets and timers work, which settings must match, and how OSPF router IDs are selected.

OSPF routers do not exchange routing information with every device on a network. Before they can synchronize link-state databases or calculate routes, they must identify compatible OSPF-speaking routers on directly connected links. This recognized peer relationship is called an OSPF neighbor relationship.

This lesson focuses on neighbor discovery and the requirements for forming that relationship. Neighbor discovery comes before later OSPF work such as adjacency formation, database synchronization, and route calculation.

Why OSPF Neighbor Relationships Are Required

An OSPF neighbor is a directly reachable OSPF-speaking router with which a router has established a recognized peer relationship. A router must first confirm that the other device is an appropriate OSPF peer before exchanging useful link-state information.

The general sequence is:

1. OSPF is enabled on an interface.
2. The interface sends Hello packets and listens for Hellos from other OSPF routers.
3. Each router validates important settings received from the other router.
4. Compatible routers recognize one another as neighbors.
5. They can then proceed through adjacency formation and link-state database synchronization.
6. After receiving link-state information, each router calculates routes using the SPF algorithm.

Neighbor discovery is therefore not the same as route calculation. A router may be physically connected and able to exchange IP traffic, yet still fail to become an OSPF neighbor because an OSPF setting is incompatible.

OSPF Hello Packets

A Hello packet is an OSPF control packet used for neighbor discovery and liveness detection. OSPF-enabled interfaces transmit Hellos periodically and examine received Hellos for information about the sending router and the shared link.

On Ethernet broadcast networks, OSPF Hello packets use the IPv4 multicast destination 224.0.0.5, known as the AllSPFRouters address. OSPF-enabled routers listening on the segment can receive these packets without the sender needing to know every neighbor's unicast address.

Receiving valid periodic Hellos maintains a neighbor relationship. If valid Hellos stop arriving for long enough, the receiving router eventually declares the neighbor unavailable.

Hello Interval

The Hello interval is the time between periodic Hello transmissions. The common Ethernet default is 10 seconds.

Dead Interval

The Dead interval is the maximum time a router waits without receiving a valid Hello before considering a neighbor down. The common Ethernet default is 40 seconds.

On many Ethernet configurations, the Dead interval is four times the Hello interval: a 10-second Hello interval and a 40-second Dead interval. The important requirement is not merely the numeric default. The timer values must agree between prospective neighbors.

OSPF Neighbor Compatibility Requirements

Two connected routers need compatible OSPF settings before a neighbor relationship can form. The exact implementation details can vary by OSPF network type and platform, but the following settings are central to single-area OSPF troubleshooting.

Subnet and Network Mask Expectations

The interfaces should be addressed as members of the same intended directly connected subnet. A mask mismatch or incorrect subnet assignment can prevent the routers from treating the link as a valid shared OSPF network.

Area ID

The Area ID is the OSPF area assignment for an interface. For example, if R1 places a shared Ethernet interface in area 0 while R2 places its interface in area 1, Layer 3 reachability alone does not make them OSPF neighbors. The area assignment on the shared link must be corrected so both interfaces belong to the same area.

Authentication

OSPF authentication validates OSPF control traffic. Both routers must agree on the absence or presence of authentication, the authentication method, and compatible credentials. Enabling authentication on only one side is a common reason for failed neighbor discovery.

Stub-Area Capability

The stub flag is Hello packet capability information related to whether an interface belongs to a stub area. Routers on the same link must have compatible stub-area expectations. A stub-area configuration mismatch can prevent Hellos from being accepted.

MTU and Adjacency Progress

MTU, or Maximum Transmission Unit, is the largest packet size an interface can transmit at the IP layer without fragmentation. MTU compatibility is related to OSPF adjacency progress, but it should be distinguished from the basic requirement to receive and accept Hello packets. An MTU problem may allow initial neighbor discovery while causing the adjacency to stall later when larger OSPF database-exchange packets are processed.

Step-by-Step Neighbor Discovery Example

Consider R1 and R2 connected to the same Ethernet segment:

R1 GigabitEthernet0/0: 192.0.2.1/24, OSPF area 0
R2 GigabitEthernet0/0: 192.0.2.2/24, OSPF area 0
Hello interval: 10 seconds on both interfaces
Dead interval: 40 seconds on both interfaces
Authentication: disabled on both interfaces
Stub capability: compatible

1. OSPF is enabled on both GigabitEthernet0/0 interfaces.
2. R1 sends a Hello to 224.0.0.5, and R2 sends a Hello to 224.0.0.5.
3. Each router receives the other router's Hello on the shared Ethernet segment.
4. Each router compares the received area, network mask expectations, Hello interval, Dead interval, authentication information, and stub capability with its local configuration.
5. Because the settings are compatible, R1 recognizes R2 and R2 recognizes R1 as OSPF neighbors.
6. Valid Hellos continue to arrive periodically, keeping the relationship alive. The routers can then progress to later adjacency and database synchronization stages.

Hello Timer Mismatch

Suppose R1 uses the usual 10-second Hello interval, but R2 uses a different interval. Both devices may be connected to the same Ethernet subnet, but the timer disagreement prevents normal neighbor formation. The corrective action is to align the Hello interval and verify that the Dead interval also matches.

Area Mismatch

Suppose R1 assigns the shared interface to area 0 while R2 assigns its shared interface to area 1. The routers can successfully exchange ordinary IP traffic because they are on the same subnet, but they do not form an OSPF neighbor relationship. Assign both ends of the shared OSPF link to the same area.

Configuring OSPF on the Shared Interface

The following Cisco IOS-style configuration illustrates interface-based OSPF activation. The process ID is locally significant; it does not need to match on another router.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip ospf 1 area 0

R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip ospf 1 area 0

For a successful example, keep the interface addresses and masks in the same subnet and use matching area assignments at both ends. Other settings, such as timers and authentication, must also be compatible.

OSPF Router ID

The Router ID is a unique 32-bit identifier used by OSPF to identify a router. It is written in dotted-decimal form, such as 1.1.1.1, but it is an identifier rather than necessarily a reachable interface address.

OSPF selects the router ID using this precedence:

Why Use a Deliberate Router ID?

A manually selected router ID is stable and easy to recognize in neighbor output, link-state databases, and troubleshooting logs. Automatic selection can change if interfaces are added, removed, or have their addresses changed. A loopback interface is commonly used as a stable source, but explicitly configuring the router ID makes the intended value unambiguous.

Router ID Selection Examples

If a router has no configured router ID, has loopbacks 10.10.10.1 and 10.10.20.1, and also has physical-interface addresses, OSPF selects 10.10.20.1 because it is the highest IPv4 address among the active loopbacks.

If the router has no configured router ID and no active loopbacks, OSPF selects the highest IPv4 address among its active physical interfaces.

If a router has a manually configured router ID, that value overrides both automatic choices.

Setting a Fixed Router ID

R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1

The process ID 1 is an example and has local significance. Changing a router ID after OSPF has already started may require restarting the OSPF process or clearing OSPF state so the new value takes effect. Plan this change carefully because it can temporarily interrupt OSPF operation.

Verifying Neighbor Discovery

Use these Cisco IOS-style commands to inspect the OSPF process, interface settings, and discovered neighbors:

show ip ospf neighbor
show ip ospf interface GigabitEthernet0/0
show ip ospf

• show ip ospf neighbor verifies whether the expected peer appears in the neighbor table.
• show ip ospf interface GigabitEthernet0/0 displays the interface's area, timers, network type, authentication-related information, and other interface-specific OSPF settings.
• show ip ospf displays process information, including the active router ID.

Troubleshooting OSPF Neighbor Discovery

No Neighbor Appears on a Directly Connected Interface

• Confirm OSPF is enabled on both ends of the shared link.
• Confirm both interfaces are operational and are not configured to prevent OSPF Hello transmission.
• Check that interface addresses and masks place both routers on the same intended subnet.
• Compare the area IDs.
• Compare Hello and Dead intervals.
• Check whether authentication is disabled on both sides or configured with compatible methods and credentials.
• Check stub-area capability and stub flag compatibility.
• Confirm that multicast or OSPF control traffic is not being filtered.

Hello Parameters Differ

Inspect the OSPF interface settings on both routers. Correct the area, timer, authentication, or stub-related mismatch, then verify again with show ip ospf neighbor and show ip ospf interface.

Adjacency Stalls After Initial Discovery

If the routers appear to discover each other but the adjacency does not become fully usable, compare interface MTU values and OSPF MTU handling. This is different from a basic failure to receive or accept Hellos: an MTU inconsistency can interfere with later adjacency progression.

A Previously Working Neighbor Goes Down

The neighbor is declared down when the Dead interval expires without a valid Hello. Investigate link failure, interface state, multicast or control-plane filtering, changed timer values, and any configuration change that stopped valid Hellos from arriving.

The Router ID Is Unexpected

1. Check for an explicitly configured router ID under the OSPF process.
2. If none exists, inspect active loopback IPv4 addresses. The highest one is selected.
3. If no active loopbacks exist, inspect active physical-interface IPv4 addresses. The highest one is selected.
4. Configure a deliberate router ID when a stable value is required, then restart or clear OSPF state if necessary for the new value to take effect.

Exam-Ready Summary

• OSPF uses Hello packets to discover and maintain neighbors.
• On Ethernet broadcast networks, Hellos use AllSPFRouters multicast address 224.0.0.5.
• The common Ethernet defaults are a 10-second Hello interval and a 40-second Dead interval.
• Hello and Dead interval values must match between prospective neighbors.
• Shared subnet expectations, area ID, authentication, and stub capability must be compatible.
• MTU compatibility can affect later adjacency progress and should be checked separately from basic Hello acceptance.
• Neighbor discovery precedes database synchronization and route calculation.
• Router ID selection order is manual router ID, highest active loopback IPv4 address, then highest active physical-interface IPv4 address.
• A deliberate router ID provides more predictable operation than relying on automatic selection.

For a focused review of the discovery process, see OSPF Neighbor Discovery.