Network

l J

DR

BDR

_

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-11 Two OSPF Routers

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

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 SerialO 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

Interface

Serial0

A#show ip ospf neighbors

Neighbor ID Pri State

Interface

172.19.10.1 1 EXCHANGE/

Serial0

rp-4700-13A#sho ip ospf nei

Dead Time Address 00:00:35 172.19.1.2

Dead Time Address

Neighbor ID Pri State

Interface

Serial0

A#show ip ospf neighbors

Neighbor ID Pri State

Interface

172.19.10.1 1 EXCHANGE/

Serial0

Dead Time Address

Dead Time Address

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 ping ing 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

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

seconds:

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.

Was this article helpful?

0 0

Post a comment