Monitoring Troubleshooting an OSPF Network

Previous Table of Contents Next


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.


TIPS:  
Under a normal show interface command, the up status reported refers to the data link layer keepalive packet. The same is true when performing a show ip ospf interface command.
            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 


Notes:  
ter mon stands for “terminal monitor” and is a useful IOS command that allows the output from a debug session to be displayed on the current terminal that the user is working on. To disable ter mon, use the IOS command ter no 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 


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net