OSPF Fundamentals

This is a routing protocol you would have been introduced to in your CCNA studies.
OSPF is a link state routing protocol as opposed to EIGRP as a distance routing protocol open standard from the IETF. OSPF can establish adjacencies with other routers. These adjacencies is what allows the routers to send link state updates between one another. OSPF routers sends link state advertisements(LSAs) to other routers in an area. OSPF routers recieves LSAs and is able to construct a link state database from them.
The routers runs the Dijkstra Shortest Path First(SFP) algorithm to determine the shortest path to a network. OSPF attempts to inject the best path for each network into a router’s IP routing table.

Video: The Ultimate Guide to Understanding and Configuring OSPF

OSPF Neighbor Formation

Neighborship vs Adjacency
Although these terms are often used interchangeably, there is a technical distinction that must be clarified elaborately to contrast their differences.

Figure 1.0 – The Ultimate OSPF Configuration Guide

Neighbors are routers that:
Reside on the same network link (meaning that the routers are connected via a switch and able to speak within a subnet)
Exchange Hello messages. These routers residing on the same link exchange Hello Messages by sending Hellos to a Destination OSPF Routers Multicast address 224.0.0.5. This ability to exchange Hellos in itself is able to form neighborship although no
Link State Advertisements have been exchanged by these Neighbors, the truth is that they do not necessarily do that.

Adjacencies are routers that:

1. Are Neighbors
2. Exchange Links State Updates.

let us look at these states:

• State 1: Link Down
• State 2: Link Comes Up
• State 3: Init (Router 2 receive a Hello from Router 2 and recognises that its own Route ID is not in the received Hello message list of Routers known to Router 1.
• Router 2 realises that the Hello is from a Neighbor). At this state, it also sends a Hello to Router 1 which also checks the Hello and recognises its Router ID and realises it has been listed as a Neighbor.
• State 4: Since Router 1 has recognised a Neighbor, it transitions to a 2-WAY State. It now sends a Hello message back to Router 2 and upon receipt of this Hello message, Router 2 recognises its own Router ID listed as a Neighbor and as a result, Router 2 goes into a 2-Way State.
• Stage 5: At this stage both routers are in the 2-Way State and therefore where needed a DR/BDR Election takes place. DR means Designated Router and BDR means Backup Designated Router. Some OSFP types do not require this election process.
• State 6: At this ExStart stage the Primary and Secondary Routers are selected.
• Stage 7: At this Exchange state the Database Description Packets are Exchanged. These are exchange between the primary and secondary routers. The Database Description Packet is a list of LSAs known to the router which sends it.
• Stage 8: At this Loading state the Routers Query One Another (Using LSRs) Link State Requests for Missing Entries (sent in Link State Update Packet).
• Stage 9: At the Full state, the Routers have fully formed adjacency.

Figure 1.0 – Link States in a Typical OSPF Neighborship

OSPF Areas

When setting up an OSPF network, one of the things to configure is an Area assignment.
OSPF uses the concept of areas to carve up a network. We could just do with a single area. The Dijsktra SPF will be ran against the area. But for scalabilty reasosn, many coporate networks like to design very large networks with multiple areas. In such designs, the dijsktra SPF is run against each Area which in effect reduces computational load on the routers responsible to running the large dijsktra algorithm.
In a multiarea topology, there has to be a Backbone Area, and this is normally called a backbone area or Area 0. I almost said Area 51, but that is all the way in Mexico so let’s stick with Area 0. The backbone area typically numbered 0 or decimal as 0.0.0.0 is the area which all other areas directly connect. In simple terms, you cannot have Area 1 and 2 without an Area 0. Every design starts with Area 0.

MultiArea OSPF Design

KeyPhrase: In a Multiple Area Design, the Dijkstra Algorithm runs on the Link State Database for each area.

As you can see from Figure 1.1, all the areas are connected to Area 0. To be able to do this, each area will need to be touching Area 0. So looking at Figure 1.1 again, we can identify two Routers, Router3 and Router7 where each of these have interfaces belonging to the Backbone Area and their home areas. Router 3 has an interface in Area 1 as well as Area 0.

Quick question to you, Which areas does Router 7 have interfaces connecting to?

The Routers in Area 0 for example does not need to know of every interlink between routers in Area 1 but must know how to get to that Area 1 subnet and which router to use as the gateway or route to that Area. When the topology is too big, it is only a better idea to break them down into areas which will make computational processor much more efficient. This is true for systems where older router technology was used as today’s routers are more powerful and so a multi area ospf topology not needed.
But what helps is the fact that since OSPF is supported by many vendors, you could decide to put that vendor party in a dedicated OSPF Area for performance reasons.

The Single Area design works well and mostly used by many enterprises.

In a situation where the areas are not directly touching Area 0, although not recommended by Cisco, a Virtual Link can be used to create the connection to Area 0 for Area 2 in Figure 1.2

R7 has a Virtual Link transiting Area 1 into Area 0 and likewise, R3 transits Area 1 to get into Area 2.

A Virtual Link is a logical link that interconnects the backbone area with an area that is not adjacent to the backbone area. The Virtual link makes it appear that Area 2 is connected to the Backbone Area also known as Area 0 or 0.0.0.0.

Basic OSPF Configuration Example

Allow me to let you in on a big secret. When it comes to configuring Routing Protocols, plan well before jumping into configuring. I have created the table below as a good guide to help you configure OSPF anywhere with ease. Yes, I know, thank me later!

The table below identifies the areas and the routers and their interfaces as well as subnets belonging to the relevant areas.

Figure 1.3 – Identify Subnets and Interfaces Belonging to the OSPF Areas (Click on Image to Zoom In)

Figure 1.4 – Identified Interfaces on Routers and their Subnets

Let’s dive straight into configuring OSPF on all Routers.

On Router 1

R1#show run | begin router ospf
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.0.0.0 0.0.0.255 area 1
network 192.168.1.0 0.0.0.255 area 1
!

On Router 2

R2-ABR#show run | begin router ospf
router ospf 1
network 2.2.2.2 0.0.0.0 area 1
network 192.168.0.0 0.0.0.3 area 0
network 192.168.0.4 0.0.0.3 area 0
!

Configuring OSPF for an Interface

This is another method in getting an interface to participate in the OSPF Process- By issuing the command on the interface directly.

R2-ABR#show run int f0/0
Building configuration...

Current configuration : 111 bytes
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
 ip ospf 1 area 1

On Router 3
Let us configure OSPF on this router in a different way, Instead of specifying the subnets, let us be generic by telling OSPF that every active upstate interface must become part of the OSPF Process by issuing the command network 0.0.0.0 255.255.255.255 area 0

R3#show run | begin router ospf
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!

On Router 4

R4#show run | begin router ospf
router ospf 1
network 172.16.2.0 0.0.0.255 area 0
network 192.168.0.4 0.0.0.3 area 0
network 192.168.0.8 0.0.0.3 area 0

Can we now see the OSPF routes?

R2-ABR#show ip route  ospf

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/11] via 10.0.0.1, 00:16:27, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets

O       3.3.3.3 [110/65] via 192.168.0.2, 00:17:02, Serial0/0
     172.16.0.0/24 is subnetted, 2 subnets

O       172.16.1.0 [110/74] via 192.168.0.2, 00:17:02, Serial0/0
O       172.16.2.0 [110/74] via 192.168.0.6, 00:17:02, Serial0/1
     192.168.0.0/30 is subnetted, 3 subnets

O       192.168.0.8 [110/128] via 192.168.0.6, 00:17:02, Serial0/1
                    [110/128] via 192.168.0.2, 00:17:02, Serial0/0
O    192.168.1.0/24 [110/20] via 10.0.0.1, 00:16:27, FastEthernet0/0

OSPF Verification

Let’s perform a verification of OSPF on Router 2 as it’s an Area Border Router and will have knowledge of the InterArea Routes.

R2-ABR#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Se0/1        1     0               192.168.0.5/30     64    P2P   1/1
Se0/0        1     0               192.168.0.1/30     64    P2P   1/1
Lo0          1     1               2.2.2.2/32         1     LOOP  0/0
Fa0/0        1     1               10.0.0.2/24        10    DR    1/1

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           0   FULL/  -        00:00:31    192.168.0.6     Serial0/1
3.3.3.3           0   FULL/  -        00:00:31    192.168.0.2     Serial0/0
1.1.1.1           1   FULL/BDR        00:00:30    10.0.0.1        FastEthernet0/0

R2-ABR#show ip protocols
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 2.2.2.2
  It is an area border router
  Number of areas in this router is 2. 2 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    2.2.2.2 0.0.0.0 area 1
    192.168.0.0 0.0.0.3 area 0
    192.168.0.4 0.0.0.3 area 0
  Routing on Interfaces Configured Explicitly (Area 1):
    FastEthernet0/0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    1.1.1.1              110      00:20:20
    4.4.4.4              110      00:20:56
    3.3.3.3              110      00:20:56
  Distance: (default is 110)

R2-ABR#show ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1368        0x80000002 0x00CE5F 4
3.3.3.3         3.3.3.3         1367        0x80000002 0x002FFD 6
4.4.4.4         4.4.4.4         1366        0x80000002 0x002616 5

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         2.2.2.2         1325        0x80000001 0x008D98
2.2.2.2         2.2.2.2         1370        0x80000001 0x00FA31
10.0.0.0        2.2.2.2         1360        0x80000002 0x002DF2
192.168.1.0     2.2.2.2         1325        0x80000001 0x00595D

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1330        0x80000003 0x000D62 3
2.2.2.2         2.2.2.2         1329        0x80000003 0x002DB8 2

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.0.2        2.2.2.2         1329        0x80000001 0x0043D6

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
3.3.3.3         2.2.2.2         1371        0x80000001 0x004F98
172.16.1.0      2.2.2.2         1371        0x80000001 0x00A389
172.16.2.0      2.2.2.2         1371        0x80000001 0x009893
192.168.0.0     2.2.2.2         1381        0x80000001 0x000C82
192.168.0.4     2.2.2.2         1381        0x80000001 0x00E3A6
192.168.0.8     2.2.2.2         1371        0x80000001 0x003E08
R2-ABR#

OSPF Network Types
When we have a router interface configured for OSPF, it’s going to have a certain OSPF Network Type. Let’s talk about some of the characteristics of the different network types.

Broadcast Network Type:

Multiple Routers connected to a Broadcast Medium perhaps some flavour of ethernet. In order for all these routers to share he same OSPF database, someone may think they will have to form a full mesh of adjacencies with one another. We can elect a DR which will form a FULL adjacency with every router in the subnet. Incase the DR goes down the Backup Designated Router (BDR) will take over. The Broadcast Network Type will elect a DR and a BDR and associate the network type with a hello timer. The default Hello Interval on this network type is 10 seconds. The Dead interval is derived from the equation Hello Timer * 4 which is a full 40 second non-response for Hellos from Neighboring Routers. After that 40 seconds, the neighbor is considered as unavailable. We don’t need to type the Neighbor command on this network type as we can use Multicast to dynamically discover a neighbor.

Point to Point Network Type:

In this design, we might have a couple of routers interconnected over a WAN protocol, HDLC , Frame Relay. No scalability concerns here as there are only two routers. Because there are not many adjacencies like in the Broadcast Network Type, we will not need to Elect a DR and BDR. The default Hello Interval remains 10 seconds. The Dead Timer interval just like in the Boradcast Network Type is also 4 * Hello Timer which is 4 * 10seconds = 40 seconds. The Neighbor command is not required in this OSPF Network Type.

Non-Broadcast OSPF Network Type:

This network could be a Frame Relay as pictured here, let’s imagine that R1 is at our Head Quarters and R2,R3 and R4 are at different Remote offices. They can all be part of the same subnet, it will be a good idea to elect a Designtated Router here [DR and BDR] but the challenge is, this is a Non-Broadcast Network and bacause of that we will not be able to use Multicast to dynamically discover our neighbors. Instead, we will have to statically configure the IP Address of our Neighbors. We need to strategically select that DR. We need to pick a Designated Router that can be adjacent to every other router.
From this topology, R1 is the best candidate for DR. But to make sure no other router attempts to become the DR or the BDR for that matter, we will have to set the OSPF Priority to 0 for those routers so they do not even attempt to become a DR or BDR. Since we want R1 to be the Designated Router, we can set it’s OSPF Priority to a Non-Zero value so it becomes the DR of choice. The Hello Interval on the Non-Broadcast OSPF Network Type is rather longer than the ones we have discussed earlier. The Default Hello Interval is 30 Seconds which in turn will make the Dead Timer 4 * 30 seconds = 120 seconds. And like I said earlier, because this is a Non-Broadcast Network, we will have to statically define our Neighbors by using the neighbor Command.

Point to Multipoint:

Topologically, this looks like our Point to Point OSPF Network Type and so what is the difference? Consider R1, that interface that goes out to our frame relay service provider network in this case, if that OSPF interface is configured for the point to multipoint network type, it’s going to treat each of those dashed lines going to R2, R3 and R4 as separate point to point connections. Each of those dashed lines represent separate subnets.
A DR and and BDR is not required as they all each appear as their own point to point network. The Hello timer for a Point-to-Multipoint Network is 30 seconds and so the Dead timer will be 120 seconds. This does not require the neighbor command. R1 can discover R2 over the dashed lines. So will R1 to R3 and R4 to R1.

Figure 1.4 – OSPF Network Types Defaults

• Broadcast is the default network type on Ethernet networks.
• Point-to-Point is the default network type on Frame Relay point-to-point subinterfaces.
• Non-Broadcast(NBMA) is the default network type on Frame Relay physical interfaces and multipoint subinterfaces.

How do we determine, what is the OSPF Network Type for a particular interface?

R2-ABR#show ip ospf interface

R2-ABR#show ip ospf interface
Serial0/1 is up, line protocol is up
  Internet Address 192.168.0.5/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Index 2/4, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 4
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 4.4.4.4
  Suppress hello for 0 neighbor(s)
Serial0/0 is up, line protocol is up
  Internet Address 192.168.0.1/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Index 1/3, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 4
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 3.3.3.3
  Suppress hello for 0 neighbor(s)
Loopback0 is up, line protocol is up
  Internet Address 2.2.2.2/32, Area 1
  Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1
  Loopback interface is treated as a stub Host
FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.2/24, Area 1
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:08
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 7
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)
R2-ABR#

How do we determine, what is the OSPF Network Type for a particular interface?

To make your router to only show you the OSPF Network Types:

R2-ABR#show ip ospf interface | inc Network Type
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10

• Broadcast is the default network type on Ethernet networks.
• Point-to-Point is the default network type on Frame Relay point-to-point subinterfaces.
• Non-Broadcast(NBMA) is the default network type on Frame Relay physical interfaces and multipoint subinterfaces.

Make it only show you the Network Types:
R2-ABR:show ip ospf interface | inc Network Type

What if you really want to specify the type of network instead of automatically specified?
Type the command under the interface;

int s0/0
ip ospf network  [broadcast]

Designated Routers and Backup Designated Routers
We have already said routers in the same area need to have the same database view of that area. So they are going to need to exchange information and we have talked about how we can form adjacency between a couple of routers, however consider a multiaccess network like we have here, maybe a local area network with multiple routers connected to the same subnet that are going into something like a Cisco Catalyst Switch. Since they all have interfaces on the same subnet, instead of forming a full adjacency from every router to every other router, we can elect a DR, a Designated Router and BDR, a Backup Designated Router should the DR go down. We do this because having a full adjacency from every router to every other router does not scale well. In the topology below, we have 6 routers and so if every router formed adjacency with every other router, then its going to be [6 * (6-1)] /2 = 6*5 /2 = 15 Adjacencies. Now if 6 routers = 15 Adjacencies then 10 Routers will be (10* (10-1)/2 = 90/2 = 45 Adjacencies. So to summarise, in a scenario like the one we have here, it’s always a best practice to elect a DR and a BDR which mitigates the need to have too many Adjacencies and too many chat of Hellos. This reduces the mess the number of adjacencies can create in a broadcast network.

The number of adjacencies = [n * (n-1)] /2 , where n is the number of nodes or routers. What do you think the Number of Adjacencies will be for the topology below in Figure 1.5?

The Routers will now use the Multicast Address for OSPF to communicate.

224.0.0.5 – All OSPF Routers
224.0.0.6 – All Designated Routers

How does a DR get Elected?

The Hello protocol is used to elect a DR. During a DR election, the router with the highest OSPF priority value wins. Note that the OSPF priority value is associated with an interface and can be a value in the range 0 – 255. If we ver statically configure the OSPF priority value of O, this will then mean that the router will not become the DR. This was a popular practice on a frame relay topology so one of the spokes does not decide to become the DR. The OSPF priority of an interface can be configured using the ip ospf priority value command in interface configuration mode.
What if the priorities tie? In a situation like such, the Router with the highest router ID (RID) becomes the DR. A router’s RID can be configured in router configuration mode, with the command router-id ID. This is not a popular practice as when the RID is not configured, the highest IP address of a loopback interface(that is currently up) becomes the RID. If a router has no loopback interfaces, the highest IP address of a non-lopback interface(that is currently up becomes the RID). Which election happens first? The DR is elected first and then the BDR is elected afterwards.

Since there is no premption with OSPF, another router which may have a higher OSPF priority cannot just show up and become the DR. This makes the OSPF network safe preserving the architectural integrity without unexpected changes causing unexpected results. So a tip for you: Seeing a DR not having the highest OSPF priority is not strange as it could simply mean that the DR came online first.

If you are in a lab environment, you could change the OSPF Priority and then shut and no shut the interface to cause the OSPF to recalculate. Use clear ip ospf process

How to find out who is the DR on the network

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:32    10.0.0.2        FastEthernet0/0

Since the FastEthernet0/0 is the interface where the DR is sourced from let us see what else that interface has to show us regarding the BDR.

FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.1/24, Area 1
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:02
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Designated Router)
  Suppress hello for 0 neighbor(s)

Router 2 confirms this.

R2-ABR#show ip ospf int f0/1
%OSPF: OSPF not enabled on FastEthernet0/1
R2-ABR#show ip ospf int f0/0
FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.2/24, Area 1
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 7, maximum is 7
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)

OSPF Timers

OSPF uses a couple of Timers. There is the Hello Timer (Hello Interval).
The Hello Timer measures the interval in seconds at which a router sends Hello messages out of an OSPF-enabled interface.

Dead Timer (Dead Interval) : If I haven’t heard from a specific adjacency, I am going to consider it as dead. The time in seconds measured for an OSPF-enabled interface as it waits to receive a Hello message from an adjacency, before considering that adjacency to be down. The Dead Timer = Hello Timer x 4. If the Hello timer is 5 seconds, the Dead timer is 5×4 = 20 seconds.

From our earlier outputs, see what the Hello and Dead Timers are for the Point_to_Point Network.

R2-ABR#show ip ospf interface
Serial0/1 is up, line protocol is up
  Internet Address 192.168.0.5/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04

Let’s see what the default timers are for a different OSPF Network type – Let us set the OSPF Network type to Non-Broadcast.

R2-ABR(config)#int s0/0
R2-ABR(config-if)#ip ospf network non-broadcast

You should lose adjacency at this point:

*Mar  1 00:01:46.895: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

Hang on, you will have to repeat the same for the end interface. Go to the Neighbor’s interface and match the network type as per below:

R3(config)#int s0/0
R3(config-if)#ip ospf network non-broadcast

Let’s Verifiy for R2-ABR#

R2-ABR#show ip ospf interface s0/0
Serial0/0 is up, line protocol is up
  Internet Address 192.168.0.1/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State WAITING, Priority 1
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120

Let’s verify for R3

R3#show ip ospf interface s0/0
Serial0/0 is up, line protocol is up
  Internet Address 192.168.0.2/30, Area 0
  Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 3.3.3.3, Interface address 192.168.0.2
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120

So as you can clearly see from above, the Hello and Dead Timer Intervals changes depending on the type of OSPF Network.

Hello TImer (Hello Interval)
Dead Timer : If I haven;t heard from an adjacency, I am going to consider it as dead.

OSPF Passive Interface

let’s consider the passive interface option for OSPF. Let’s say we have an interface that we want OSPF to advertise. Let’s take R1 topology and we can see that it has the 192.168.1.0/24 subnet space. This connects out to end users only. It is not connecting to another router and so will not need to advertise OSPF Messages from it’s Internet. When an interface is passive, it will not forward OSPF Messages out of that interface typically when it has no routers connected to it. You don’t want someone to show up with a Rogue Router to form neighborship to R1, this will be a security concern. We want that interface to be advertised to other routers but not for it to advertise OSPF message out of its interface.

This is how we do this;

R1(config)#router ospf 1
R1(config-router)#passive-interface fa 0/0
R1(config-router)#end

show ip ospf interface brief

show ip protocols

Related Articles:
Understanding OSPF Adjacency

Cisco has a good discussion on configuring OSPF. This might be a great resource to expand your knowledge.

Once upon a time, we walked together holding hands, we enjoyed the breeze together, we called ourselves neighbors but could we say the same of our OSPF Neighbor Adjacency?

OSPF Neighbor Adjacency – Do I need to worry about it?

Troubleshooting OSPF Neigbor Adjacency is an important skill to have as a network engineer. OSPF is the most popular routing protocol loved by many and so with a good article as per below, you should be able to troubleshoot OSPF issues without difficulties.

Just like our behaviour in the real world, the fact that routers are neighbors is not sufficient enough to guarantee exchange of link-state updates; they must perform adjacencies which is based on a set of laid down requirements in order to exchange link-state updates. Adjacency is an advanced form of neighborship formed by routers that are willing to participate in the exchange of routing information after negotiating parameters of such an exchange. Routers therefore can only reach a FULL state of adjacency when they have synchronized views on a link-state database.

Interface type plays a major role in how the adjacencies are formed. For example, neighbors on point-to-point links always try to become adjacent, while routers attached to broadcast media such as Ethernet can choose to become adjacent only with a subset of neighboring routers on the interface.

Once a router decides to form an adjacency with a neighbor, it starts by exchanging a full copy of its link-state database. The neighbor, in turn says hi, I have some more updates and so doing, exchanges a full copy of its link-state database with the router. After passing through several neighbor states, the routers become fully adjacent.

OSPF Adjacency Requirements,

From the perspective of OSPF, there are a couple of things that must match for a OSPF neighborship to establish; these include:

1. The devices must be in the same area
2. The devices must have the same authentication configuration
3. The devices must be on the same subnet
4. The devices hello and dead intervals must match
5. The devices must have matching stub flags

OSPF Adjacency Formation States
During the adjacency formation process, two OSPF routers transition through several states, which include:

Down. Down is the starting state for all OSPF routers. A start event, such as configuring the protocol, transitions the router to the Init state. The local router may list a neighbor in this state when no hello packets have been received within the specified router dead interval for that interface.
Init. The Init state is reached when an OSPF router receives a hello packet but the local router ID is not listed in the received Neighbor field. This means that bidirectional communication has not been established between the peers.

Attempt. The Attempt state is valid only for Non-Broadcast Multi-Access (NBMA) networks. It means that a hello packet has not been received from the neighbor and the local router is going to send a unicast hello packet to that neighbor within the specified hello interval period.

2-Way. The 2-Way state indicates that the local router has received a hello packet with its own router ID in the Neighbor field. Thus, bidirectional communication has been established and the peers are now OSPF neighbors. (And this is where you stand and clap for the ingenuity of the neighborship concept. Note that till the point of Neighborship formation, databases haven’t been exchanged. It is only before they become adjacent that they exchange databases which is explained below.)

ExStart. In the ExStart state, the local router and its neighbor establish which router is in charge of the database synchronization process. The higher router ID of the two neighbors controls which router becomes the master.

Exchange. In the Exchange state, the local router and its neighbor exchange DD packets that describe their local databases.
Loading. Should the local router require complete LSA information from its neighbor, it transitions to the Loading state and begins to send link-state request packets.

Full. The Full state represents a fully functional OSPF adjacency, with the local router having received a complete link-state database from its peer. Both neighboring routers in this state add the adjacency to their local database and advertise the relationship in a link-state update packet.

Figure 1.0 – OSPF Neighbor Adjacency States and OSPF Neighbor Forming Process

Run the show ip ospf neighbor command to initiate the troubleshooting process for the lost OSPF neighbor adjacency,

Router1# show ip ospf neighbor

OSPF routers go through the seven states while building neighborship with other routers.

1. Down state
2. Attempt/Init state
3. Two ways state
4. Exstart state
5. Exchange state
6. Loading state
7. Full state

You can use the show ip ospf neighbor command in order to determine the state of the OSPF neighbor or neighbors. The output of this command will most likely reveal one of these:
nothing at all

state = down
state = init
state = exstart
state = exchange
state = 2-way
state = loading

OSPF Neighborship Requirement;
In order to become an OSPF neighbor, the following values must be match on both routers.

• Area ID
• Authentication
• Hello and Dead Intervals

Stub Flag
MTU Size

OSPF Stuck in INIT,

The init state indicates that a router sees Hello packets from the neighbor, but two-way communication has not been established. A Cisco router includes the router IDs of all neighbors in the init (or higher) state in the neighbor field of its Hello packets. Example 3-15 shows sample output of the show ip ospf neighbor command.

OSPF Neighbor Stuck in INIT—Cause: Access List on One Side Is Blocking OSPF Hellos
OSPF uses a multicast address of 224.0.0.5 for sending and receiving Hello packets. If an access list is defined on the interface and OSPF is enabled on that interface, this multicast address must be explicitly permitted in the access list; otherwise, it can produce problems such as stuck in INIT. The stuck in INIT problem occurs only if one side is blocking OSPF Hellos. If both sides are blocking OSPF Hellos, the output of show ip ospf neighbor returns an empty list.

OSPF Neighbor Stuck in INIT—Cause: Multicast Capabilities Are Broken on One Side
This is a specific situation that is valid only in the case of a Catalyst 6500 switch with the multilayer switch feature card (MSFC). The problem is that one side is sending OSPF Hellos that the other side does not receive.This situation is produced when the command set protocolfilter enabled is entered on the 6500 switch. By default, the protocol filter is disabled. Enabling this command begins altering the multicast frame to and from MSFC and port adapter within the FlexWan module of the 6500 switch. To fix this problem, disable the protocol filter on 6500 switch set protocolfilter disable.

OSPF Neighbor Stuck in INIT—Cause: Cause: Authentication Is Enabled Only on One Side
When authentication is used, it must be enabled on both sides; otherwise, one side will show the neighbor stuck in the INIT state. The router that has authentication enabled will reject all the nonauthenticated packets, and the adjacency will show stuck in INIT. The other side will not detect any problem because the authentication is turned on, so it will simply ignore the authentication in apacket and treat it as a normal packet.

OSPF Neighbor Stuck in INIT—Cause: The Frame-Relay Map/dialer-map Statement on One Side Is Missing the broadcast Keyword
OSPF uses a multicast address of 224.0.0.5 to send and receive OSPF Hellos. If one side is incapable of sending or receiving Hellos, the OSPF neighbor will be stuck in the INIT state. The important thing to note here is that only one side suffers from this multicast prob-lem. R1 sees the neighbor in INIT state but can see the neighbor Hellos without any problem. When R1 sends the Hello to R2, it never reaches R2 because Layer 2 is incapable of sending any broadcast or multicast packets. This is because of the lack of the broadcast keyword in frame-relay map statement on R1. A similar problem can occur in the case of ISDN or dialer interface when the dialer map statement is configured without the broadcast keyword.

OSPF Neighbor Stuck in INIT—Cause: Hellos Are Getting Lost on One Side at Layer 2
This situation happens when there is a problem on the Layer 2 media; for example, the Frame Relay switch is blocking the multicast traffic for some reason. When R1 sends the Hello, R2 never receives it. Because R2 never saw Hellos from R1, the neighbor list of R2 will be empty. However, R1 sees the Hellos from R2, which does not list R1 as a valid neighbor; so, R1 declares this neighbor in the INIT state.

OSPF Stuck in LOADING State
This is a rare problem in OSPF neighbor relationships. When a neighbor is stuck in the LOADING state, the local router has sent a link-state request packet to the neighbor requesting an outdated or missing LSA and is waiting for an update from its neighbor. If a neighbor doesn’t reply or a neighbors’ reply never reaches the local router, the router will be stuck in the LOADING state.
The most common possible causes of this problem are as follows:
1 Mismatched MTU
2 Corrupted link-state request packet

OSPF Neighbor Stuck in LOADING—Cause: Mismatched MTU Size
This is a unique problem that happens when an MTU mismatch occurs. If the MTUs are not the same across the link, this problem occurs. Specifically, if a neighbor’s MTU is greater than the local router’s, the neighbor sends a large MTU packet as a link-state update. This packet never reaches the local router; as a result, the neighbor gets stuck in the LOADING state.

OSPF Neighbor Stuck in LOADING—Cause: Link-State Request Packet Is Corrupted
When a link-state request packet is corrupted, the neighbor discards the packet and the local router never receives the response from the neighbor. This causes the OSPF neighbor to be stuck in the LOADING state.
Link-state request packets usually become corrupted because of the following reasons:
1 A device between the neighbors, such as a switch, is corrupting the packet.
2 The sending router’s packet is invalid. In this case, either the sending router’s interface is bad or the error is caused by a software bug.
3 The receiving router is calculating the wrong checksum. In this case, either the receiving router’s interface is bad or the error is caused by a software bug. This is the least likely cause of this error message.
Most of the time, this problem is fixed by replacing hardware. This could be a simple bad port on the switch or a bad interface card on the sending/receiving router.

OSPF Neighbor Stuck in EXSTART/EXCHANGE

This is an important state during the OSPF adjacency process. In this state, the router elects a master and a slave and the initial sequence number. The whole database also is exchanged during this state. If a neighbor is stuck in EXSTART/EXCHANGE for a long time, it is an indication of a problem.
The most common possible causes of this problem are as follows:

1. Mismatched interface MTU
2.  Duplicate router IDs on neighbors
3.  Inability to ping across with more than certain MTU size
4.  Broken unicast connectivity because of the following:
5. Wrong VC/DLCI mapping in Frame Relay/ATM switch
6.  Access list blocking the unicast
7.  NAT translating the unicast
8.  Network type of point-to-point between PRI and BRI/dialer

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Mismatched Interface MTU
OSPF sends the interface MTU in a database description packet. If there is a MTU mis-match, OSPF will not form an adjacency. The interface MTU option was added in RFC 2178. Previously, there was no mechanism to detect the interface MTU mismatch.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Duplicate Router IDs on Neighbors
When OSPF sends a DBD packet to elect a master and a slave, the router with the highest router ID becomes the master. This happens in the EXSTART process. If there is any problem with election, the router will be stuck in the EXSTART/EXCHANGE state.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Can’t Ping Across with More Than Certain MTU Size
When OSPF begins forming an adjacency with its neighbor, it goes through several states. In EXSTART state, OSPF determines which will be the master and which will be the slave. After the routers decided this, they start exchanging the LSA header in the form of DBD packets. If the database is huge, OSPF uses the interface MTU and tries to send as much data as possible up to the limit of the interface MTU. If there is a problem with Layer 2 accepting large packets that are within the interface MTU range, the OSPF adjacency will be stuck in the EXCHANGE state.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Unicast Connectivity Is Broken
When OSPF routers begin exchanging database information with each other, they send a unicast packet to each other in EXSTART/EXCHANGE state. This happens only if the network type is not a point-to-point link. In cases of a point-to-point link, OSPF sends all multicast packets. If unicast connectivity is broken, OSPF neighbor remains in EXSTART state.
This ping failure could occur for several reasons, including the following:
1 The wrong DLCI or VPI/VCI mapping exists in a Frame Relay or ATM switch, respectively.
2 An access list is blocking the unicast.
3 NAT is translating the unicast.
Wrong DLCI or VPI/VCI Mapping
In cases of Frame Relay or ATM, this is a very common problem. The packet will be lost in the Frame Relay or ATM cloud. To further verify that this is the case, turn on debug ip packet detail with the access list on both routers.

Access List Blocking the Unicast
If an access list is configured on a router, make sure that it’s not blocking the unicast packet.

NAT Is Translating the Unicast
This is another common problem that occurs when NAT is configured on the router. If NAT is misconfigured, it will start translating the unicast packet coming toward it, which will break the unicast connectivity.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Network Type Is Pointto- Point Between PRI and BRI/Dialer
The network type on a PRI interface is point-to-point. This causes OSPF to send multicast packets even after the 2-WAY state. If only one BRI comes up as an OSPF neighbor, it will work fine. However, when multiple BRIs try to form an adjacency with the PRI, the PRI will complain because its network type is point-to-point. Because all OSPF packets are sent as multicast on a point-to-point link, the PRI receives DBD packets from multiple BRI neighbors, and this causes all the neighbors to get into the EXSTART/EXCHANGE state.

OSPF Troubleshooting Summary
Neighborship stuck in down stage : When an OSPF router first receives a hello packet, it verifies that the data in some fields matches its own locally configured information. Should any of the checked data be different, the hello packet is discarded and not processed. The data fields verified are the Area ID, Authentication, Network Mask (on broadcast networks), Hello Interval, Router Dead Interval, and Options fields. If this information doesn’t match, then neighborship is stuck in the down stage.

OSPF adjacency gets stuck in the ExStart state : This occurs due to a final check the routers perform. In the DD packet, each router advertises the IP MTU of the interface it is using. Should the local and remote routers not agree on the MTU of the network link, the database synchronization process stops and both neighbors remain in the ExStart state.

Bonus : Top 8 OSPF Troubleshooting Commands;

show ip protocols
show ip ospf
show ip ospf interface
show ip ospf neighbor
show ip ospf database
debug ip ospf packet
debug ip ospf hello
debug ip ospf adj

Check out our other articles like – Configuring Cisco Router for PPPoE

Reference: PacketPushers  | Prasadkeni