Case Study: Troubleshooting OSPF Adjacency Problems
One of the various problems that you often run into with OSPF is when a pair of routers is attached to the same network, but they won't become fully adjacent. If you know the right things to look for, this type of problem can be quickly dealt with.
Before troubleshooting neighbors, which won't bring up an adjacency, you need to make certain that they should become fully adjacent. For example, the routers in Figure 5-10 are connected to the same link, but they will never become fully adjacent.
Assume that Router A becomes the designated router (DR) on this network, and Router B becomes the backup designated router (BDR). Since the DR is responsible for sending Router C any information it learns from Router D, there isn't any reason for Router C and Router D to become fully adjacent.
And, as a matter of fact, they won't. Routers C and D will build their neighbor relationship to the two-way state only, and they will never build a full adjacency.
The routers in Figure 5-11, however, should be building a full OSPF adjacency; they are connected through a point-to-point link, and they are both in area 0.
Figure 5-10. Neighbor Relationships on a Broadcast Network
Figure 5-11. Two OSPF Routers
When you look at the show ip ospf neighbor output from either router, however, you can see that the adjacency isn't being built.
From Router A the output is as follows:
A#sho ip ospf nei
A#
The first thing to do when this type of problem occurs is to run debug ip ospf adj on one of the routers. Once again, from Router A, the output is as follows:
A#debug ip ospf adj
OSPF adjacency events debugging is on
A#
20:12:35: OSPF: Rcv hello from 172.19.10.1 area 0 from Serial0 172.19.1.2
20:12:35: OSPF: Mismatched hello parameters from 172.19.1.2
20:12:35: Dead R 40 C 80, Hello R 10 C 20
This output reveals that you have mismatched hello parameters, in this case the Dead and Hello timers are mismatched. The Hello timer on this router (labeled C in the debug output) is 20, while the Hello timer on the remote router (labeled R in the debug output) is 10. Looking at the configuration on Router A, you see the following:
!
interface Serial0
ip address 172.19.1.1 255.255.255.0
no ip directed-broadcast
ip ospf hello-interval 20
no ip mroute-cache
!
The OSPF Hello interval on this interface has been set to 20. Correcting this should fix the problem. The Hello interval, Dead interval, wait time, and link type all have to match for OSPF routers to become fully adjacent.
However, other problems aren't so easy to find quickly, unless you know specifically what you are looking for. Next, correct the timers and see if the neighbors will come up into FULL state. A few executions of the show ip ospf neighbor command reveals the following:
A#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
172.19.10.1 1 INIT/ - 00:00:35 172.19.1.2 Serial0
A#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
172.19.10.1 1 EXCHANGE/ - 00:00:35 172.19.1.2 Serial0
rp-4700-13A#sho ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
172.19.10.1 1 INIT/ - 00:00:35 172.19.1.2 Serial0
A#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
172.19.10.1 1 EXCHANGE/ - 00:00:35 172.19.1.2 Serial0
Even though the mismatched timers have been corrected, the routers still won't become adjacent. They just flip-flop between INIT and EXCHANGE modes.
EXCHANGE state means you are trying to exchange databases with the neighbor. So, the logical assumption is that you are getting hello packets across the link, but not database information.
Why would hello packets be okay and database packets not be okay? Well, hello packets are small, while database packets are large. Prove this theory by pinging with some various sized packets across the link between the two routers using an extended ping as follows:
A#ping
Protocol [ip]:
Target IP address: 172.19.1.2
Repeat count [5]: 1
Extended commands [n]: y
Sweep range of sizes [n]: y
Sweep min size [36]: 100
Sweep max size [18024]: 1500
Sweep interval [1]: 100
Type escape sequence to abort.
Sending 15, [100..1500]-byte ICMP Echos to 172.19.1.2, timeout is 2 seconds:
!…………..
Success rate is 6 percent (1/15), round-trip min/avg/max = 1/1/1 ms
You can see from the preceding output that the ping fails with a packet size of 200 bytes, which seems very small. Take a look at the router on the other end of the link and see how the interface is configured:
interface Serial0
mtu 100
ip address 172.19.1.2 255.255.255.0
So, it looks like you've found the problem—the MTU size is mismatched on the link. One router thinks the MTU is 100 bytes, while the other end thinks it is 1500 bytes. Because the hello packets are only 64 bytes, both routers can send and receive them with no problems. But when it comes time to send and receive maximum sized database descriptor (DBD) packets, Router B, with an MTU of 100 bytes, will drop the 1500 bytes packets generated by Router A.
One side note—Cisco routers running newer software will not have this problem because the routers exchange the MTU size of the link in their hello packets. When they exchange LSAs or DBDs, they limit their packet sizes to the minimum MTU on the link.
Of course, if the MTU of one end of a link is different than the MTU of the other end of the link, larger packets will still fail to cross the link in one direction, regardless of OSPF's ability to bring up an adjacency. This just shifts the problem from building the adjacency to the more esoteric problem of some applications not working across the link, or FTP control sessions working correctly but data sessions failing.