Monitoring Troubleshooting an OSPF Network
The action plan was developed to implement steps described previously and will enable OSPF on the identified routers and observe the results after these actions had taken effect. Step 5: Implement the New Action Plan Identifying the steps needed to enable OSPF enabled us to formulate a new plan of action that consisted of taking the following actions to the router’s configuration: ROUTER_A#conf t Enter configuration commands, one per line. End with CNTL/Z ROUTER_A(config)#router ospf 202 ROUTER_A(config-router)#network 177.36.252.0 0.0.0.255 area 2.1.0.0 ROUTER_A(config-router)# area 2.1.0.0 authentication After entering these commands, interfaces s0.1 and s1.2 began to “speak” OSPF and attempted to form an adjacency. The relevant new OSPF configuration in ROUTER A is as follows: ! router ospf 202 network 177.2.254.0 0.0.0.255 area 0 network 177.36.252.0 0.0.0.255 area 2.1.0.0 area 2.1.0.0 authentication ! Step 6 Revisited: Gather Results We then confirmed that the serial links were now “talking” OSPF by once again using the show ip ospf interfaces command. As we discovered, the routers were speaking OSPF, but were not forming adjacencies over the WAN link. This condition was confirmed by the neighbor and adjacency which counts were zero—as indicated by the output in bold that follows.
ROUTER_A#Show ip ospf interface Serial0.2 is up, line protocol is up Internet Address 177.36.252.6/30, Area 2.1.0.0 Process ID 202, RouterID 177.36.252.26, Network Type POINT_TO_POINT, Cost:1 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:03 Neighbor Count is 0, Adjacent neighbor count is 0 Adjacent with neighbor 177.3 Serial1.2 is up, line protocol is down Internet Address 177.36.252.26/30, Area 2.1.0.0 Process ID 202, RouterID 177.36.252.26, Network Type POINT_TO_POINT, Cost:1 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:08 Neighbor Count is 0, Adjacent neighbor count is 0 Our past experiences in troubleshooting OSPF led us to believe that this was still some sort of configuration problem because hardware had been ruled out earlier in the troubleshooting process. Step 7: Reiterate Steps 4-6 We then issued the command show ip ospf neighbors again to ensure the adjacencies had been properly formed. ROUTER_A#show ip ospf neighbors Neighbor ID Pri State Dead Time Address Interface 177.32.252.6 1 FULL/DR 00:00:37 177.2.254.5 Ethernet0 177.36.254.5 1 INIT/ - 00:00:34 177.36.252.5 Serial0.2 177.36.254.25 1 INIT/ - 00:00:35 177.36.252.25 Serial1.2 However, over a period of minutes, we realized that the OSPF Neighbor State had not changed from INIT. This meant that each router has seen its neighbor’s hello packets, but could not mutually agree on the parameters with which to form an adjacency. We certainly were getting closer to problem resolution, but still something else was wrong. We decided that we needed more information to correct this problem, so we turned on OSPF event debugging. Executing the troubleshooting command debug IP OSPF events while in the Enable mode of a router does this. OSPF debugging allows us to uncover the inner workings of the OSPF process in an effort to determine why adjacencies were not properly formed, as demonstrated in the following output: ROUTER_A# debug ip ospf events OSPF events debugging is on ROUTER_A# ter mon
Some more useful information now began to appear on the output from debug ip ospf events. The debug output informed us of an authentication key problem: OSPF: Rcv pkt from 177.36.252.5, Serial0.2: Mismatch Authentication Key-Clear Text OSPF: Rcv pkt from 177.36.252.25, Serial1.2: Mismatch Authentication Key-Clear Text
|
EAN: 2147483647
Pages: 200