Troubleshooting OSPF
Because it is a link-state routing protocol, OSPF scales well with a growing network. But this scalability introduces complexity in design, configuration, and maintenance. This section introduces some of the common issues surrounding an OSPF network and offers a flowchart approach to troubleshooting these issues.
Components of Troubleshooting OSPF
Troubleshooting OSPF requires an understanding of the operation of the protocol as well as a specific approach methodology. Figure 4-8 shows the major components of OSPF troubleshooting and the order in which the process flows.
Figure 4-8 Components of Troubleshooting OSPF
The major components of OSPF troubleshooting include the following:
- OSPF neighbor adjacencies
- The OSPF routing table
- OSPF authentication
Troubleshooting OSPF Neighbor Adjacencies
The first component to troubleshoot and verify is the OSPF neighbor adjacency. Figure 4-9 shows the verification/troubleshooting components for neighbor adjacencies.
Figure 4-9 Troubleshooting OSPF Neighbor Adjacencies
A healthy OSPF neighbor state is “Full.” If the OSPF neighbor state remains in any other state, it may indicate a problem. Example 4-12 demonstrates sample output from the show ip ospf neighbor command to gather this information.
Example 4-12 Verifying OSPF Neighbor State
RouterX#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 172.16.31.100 0 Full/ - 00:00:31 10.140.1.1 Serial0/0/0 192.168.1.81 0 Full/ - 00:00:31 10.23.23.2 Serial0/0/1
To determine whether a possible Layer 1 or Layer 2 problem exists with a connection, display the status of an interface using the show ip ospf neighbor command. “Administratively Down” indicates that the interface is not enabled. If the status of the interface is not up/up, there will be no OSPF neighbor adjacencies. In Example 4-13, serial 0/0/1 is up/up.
Example 4-13 Verifying Interface Status
RouterX#show ip ospf interface Serial0/0/1 is up, line protocol is up Internet Address 10.23.23.1/24, Area 0 Process ID 100, Router ID 192.168.1.65, Network Type POINT_TO_POINT, Cost: 1562
For OSPF to create an adjacency with a directly connected neighbor router, both routers must agree on the maximum transmission unit (MTU) size. To check the MTU size of an interface, use the show interface command. In Example 4-14, the MTU size is 1500 bytes.
Example 4-14 Verifying Interface MTU Size
RouterX#show ip interface fa0/0 FastEthernet0/0 is up, line protocol is up Internet address is 10.2.2.3/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set
The network command that you configure under the OSPF routing process indicates which router interfaces participate in OSPF and determines inwhich area the interface belongs. If an interface appears under the show ip ospf interface command, that interface is running OSPF. In Example 4-15, interfaces serial 0/0/1 and serial 0/0/0 are running OSPF.
Example 4-15 Verifying Whether an Interface Is Running OSPF
RouterX#show ip ospf interface Serial0/0/1 is up, line protocol is up Internet Address 10.23.23.1/24, Area 0 Process ID 100, Router ID 192.168.1.65, Network Type POINT_TO_POINT, Cost: 1562 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 Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 192.168.1.81 Suppress hello for 0 neighbor(s) Simple password authentication enabled Serial0/0/0 is up, line protocol is up Internet Address 10.140.1.2/24, Area 0 Process ID 100, Router ID 192.168.1.65, Network Type POINT_TO_POINT, Cost: 1562 Transmit Delay is 1 sec, State POINT_TO_POINT,
OSPF routers exchange hello packets to create neighbor adjacencies. Four items in an OSPF hello packet must match before an OSPF adjacency can occur:
- Area ID
- Hello and dead intervals
- Authentication password
- Stub area flag
To determine whether any of these hello packet options do not match, use the debug ip ospf adj command. The output in Example 4-16 illustrates a successful adjacency on the serial 0/0/1 interface.
Example 4-16 Verifying OSPF Adjacencies
*Feb 17 18:41:51.242: OSPF: Interface Serial0/0/1 going Up *Feb 17 18:41:51.742: OSPF: Build router LSA for area 0, router ID 10.1.1.1, seq 0x80000013 *Feb 17 18:41:52.242: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up *Feb 17 18:42:01.250: OSPF: 2 Way Communication to 10.2.2.2 on Serial0/0/1, state 2WAY *Feb 17 18:42:01.250: OSPF: Send DBD to 10.2.2.2 on Serial0/0/1 seq 0x9B6 opt 0x52 flag 0x7 len 32 *Feb 17 18:42:01.262: OSPF: Rcv DBD from 10.2.2.2 on Serial0/0/1 seq 0x23ED opt0x52 flag 0x7 len 32 mtu 1500 state EXSTART *Feb 17 18:42:01.262: OSPF: NBR Negotiation Done. We are the SLAVE *Feb 17 18:42:01.262: OSPF: Send DBD to 10.2.2.2 on Serial0/0/1 seq 0x23ED opt 0x52 flag 0x2 len 72 *Feb 17 18:42:01.294: OSPF: Rcv DBD from 10.2.2.2 on Serial0/0/1 seq 0x23EE opt0x52 flag 0x3 len 72 mtu 1500 state EXCHANGE *Feb 17 18:42:01.294: OSPF: Send DBD to 10.2.2.2 on Serial0/0/1 seq 0x23EE opt 0x52 flag 0x0 len 32 *Feb 17 18:42:01.294: OSPF: Database request to 10.2.2.2 *Feb 17 18:42:01.294: OSPF: sent LS REQ packet to 192.168.1.102, length 12 *Feb 17 18:42:01.314: OSPF: Rcv DBD from 10.2.2.2 on Serial0/0/1 seq 0x23EF opt0x52 flag 0x1 len 32 mtu 1500 state EXCHANGE *Feb 17 18:42:01.314: OSPF: Exchange Done with 10.2.2.2 on Serial0/0/1 *Feb 17 18:42:01.314: OSPF: Send DBD to 10.2.2.2 on Serial0/0/1 seq 0x23EF opt 0x52 flag 0x0 len 32 *Feb 17 18:42:01.326: OSPF: Synchronized with 10.2.2.2 on Serial0/0/1, state FULL *Feb 17 18:42:01.330: %OSPF-5-ADJCHG: Process 10, Nbr 10.2.2.2 on Serial0/0/1 from LOADING to FULL, Loading Done *Feb 17 18:42:01.830: OSPF: Build router LSA for area 0, router ID 10.1.1.1, seq 0x80000014
Troubleshooting OSPF Routing Tables
After you have verified that the adjacencies are correct, the next step is to troubleshoot/verify the routing tables. Figure 4-10 shows the procedures for verifying the routing tables.
Figure 4-10 Troubleshooting OSPF Routing Tables
An OSPF route found in the routing table can have a variety of different codes:
- O: OSPF intra-area, within the same area, route from a router within the same OSPF area
- O IA: OSPF inter-area, from another area in the OSPF network, route from a router in a different OSPF area
- O E1 or E2: An external OSPF route from another autonomous system
If you have a single OSPF area, you should not see O IA routes in the routing table. Example 4-17 has both an O IA and an O E2 route.
Example 4-17 Determining OSPF Route Types
RouterX#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 ia - IS-IS inter area, * - candidate default, o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/32 is subnetted, 1 subnets O 172.16.31.100 [110/1563] via 10.140.1.1, 00:03:15, Serial0/0/0 10.0.0.0/24 is subnetted, 5 subnets C 10.2.2.0 is directly connected, FastEthernet0/0 O IA 10.1.1.0 [110/1563] via 10.140.1.1, 00:03:15, Serial0/0/0 O 10.140.2.0 [110/3124] via 10.140.1.1, 00:03:15, Serial0/0/0 [110/3124] via 10.23.23.2, 00:03:15, Serial0/0/1 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.64/28 is directly connected, Loopback0 E2 192.168.1.81/32 [110/1563] via 10.23.23.2, 00:03:17, Serial0/0/1
The network command that you configure under the OSPF routing process also indicates which networks OSPF advertises.
The show ip protocols command indicates whether any route filters have been implemented, which can affect which routes are seen in the routing table. The command, as shown in Example 4-18, also displays the networks that have been configured to be advertised to other OSPF routers.
Example 4-18 Determining Whether Route Filters Have Been Implemented
RouterX#show ip protocols Routing Protocol is "ospf 100" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Router ID 192.168.1.65 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 10.2.2.3 0.0.0.0 area 0 10.23.23.1 0.0.0.0 area 0 10.140.1.2 0.0.0.0 area 0 192.168.1.65 0.0.0.0 area 0 Reference bandwidth unit is 100 mbps Routing Information Sources: Gateway Distance Last Update 192.168.1.81 110 00:04:52 172.16.31.100 110 00:04:52 Distance: (default is 110)
Troubleshooting Plaintext Password Authentication
If you are using OSPF password authentication, you must also be prepared to troubleshoot any authentication problems that may occur during the adjacency process.
You can use the debug ip ospf adj command to display OSPF adjacency-related events. This command is useful when troubleshooting authentication.
If plaintext password authentication is configured on the Router X serial 0/0/1 interface but no authentication is configured on the Router Y serial 0/0/1 interface, the routers will not be able to form an adjacency over that link. The output of the debug ip ospf adj command shown in Example 4-19 illustrates that the routers report a mismatch in authentication type; no OSPF packets will be sent between the neighbors.
Example 4-19 Determining Whether an Authentication Mismatch Exists
RouterX#debug ip ospf adj *Feb 17 18:51:31.242: OSPF: Rcv pkt from 192.168.1.102, Serial0/0/1 : Mismatch Authentication type. Input packet specified type 0, we use type 1 RouterY#debug ip ospf adj *Feb 17 18:50:43.046: OSPF: Rcv pkt from 192.168.1.101, Serial0/0/1 : Mismatch Authentication type. Input packet specified type 1, we use type 0
NOTE The different types of authentication have these codes:
- Null is type 0
- Simple password is type 1
- MD5 is type 2
If plaintext password authentication is configured on the Router X serial 0/0/1 interface and on the router Y serial 0/0/1 interface, but the interfaces are configured with different passwords, the routers will not be able to form an adjacency over that link.
The output of the debug ip ospf adj command shown in Example 4-20 illustrates that the routers report a mismatch in authentication key; no OSPF packets will be sent between the neighbors.
Example 4-20 debug ip ospf adj Command Output Confirms an Authentication Mismatch
RouterX#debug ip osp adj *Feb 17 18:54:01.238: OSPF: Rcv pkt from 192.168.1.102, Serial0/0/1 : Mismatch Authentication Key - Clear Text RouterY#debug ip ospf adj *Feb 17 18:53:13.050: OSPF: Rcv pkt from 192.168.1.101, Serial0/0/1 : Mismatch Authentication Key - Clear Text
More Resources