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 routers 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 22.214.171.124 0.0.0.255 area 126.96.36.199 ROUTER_A(config-router)# area 188.8.131.52 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 184.108.40.206 0.0.0.255 area 0 network 220.127.116.11 0.0.0.255 area 18.104.22.168 area 22.214.171.124 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 zeroas indicated by the output in bold that follows.
ROUTER_A#Show ip ospf interface Serial0.2 is up, line protocol is up Internet Address 126.96.36.199/30, Area 188.8.131.52 Process ID 202, RouterID 184.108.40.206, 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 220.127.116.11/30, Area 18.104.22.168 Process ID 202, RouterID 22.214.171.124, 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 126.96.36.199 1 FULL/DR 00:00:37 188.8.131.52 Ethernet0 184.108.40.206 1 INIT/ - 00:00:34 220.127.116.11 Serial0.2 18.104.22.168 1 INIT/ - 00:00:35 22.214.171.124 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 neighbors 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 126.96.36.199, Serial0.2: Mismatch Authentication Key-Clear Text OSPF: Rcv pkt from 188.8.131.52, Serial1.2: Mismatch Authentication Key-Clear Text