After speaking with our network design team, we received the correct OSPF authentication key and placed it on Serial0.2 and Serial1.2 on ROUTER A. Almost instantly, the OSPF adjacencies were formed and the states were FULL. The output that follows shows the relevant configuration modification and resulting OSPF events. ROUTER_A#conf t Enter configuration commands, one per line. End with CNTL/Z. ROUTER_A(config)#int s0.2 ROUTER_A(config-subif)#ip ospf authentication-key secretkey ROUTER_A(config-subif)# OSPF: Receive dbd from 177.36.253.6 seq 0x2503 OSPF: 2 Way Communication to neighbor 177.36.254.5 OSPF: send DBD packet to 177.36.252.5 seq 0x22C3 OSPF: NBR Negotiation Done We are the SLAVE OSPF: send DBD packet to 177.36.252.5 seq 0x2503 OSPF: Receive dbd from 177.36.254.5 seq 0x2504 OSPF: send DBD packet to 177.36.252.5 seq 0x2504 OSPF: Database request to 177.36.254.5 OSPF: sent LS REQ packet to 177.36.252.5, length 864 OSPF: Receive dbd from 177.36.254.5 seq 0x2505 OSPF: send DBD packet to 177.36.252.5 seq 0x2505 OSPF: Database request to 177.36.254.5 OSPF: sent LS REQ packet to 177.36.252.5, length 1080 OSPF: Receive dbd from 177.36.254.5 seq 0x2506 OSPF: Exchange Done with neighbor 177.36.254.5 OSPF: send DBD packet to 177.36.252.5 seq 0x2506 OSPF: Synchronized with neighbor 177.36.254.5, state:FULL OSPF_ROUTER_A(config-subif)# OSPF: Neighbor 177.36.254.25 is dead OSPF: neighbor 177.36.254.25 is dead, state DOWN OSPF: Tried to build Router LSA within MinLSInterval OSPF: Rcv pkt from 177.36.252.25, Serial1.2 : Mismatch Authentication Key - Clear Textint s1.2 OSPF_ROUTER_A(config-subif)#ip ospf authentication-key secretkey OSPF: Rcv pkt from 177.36.252.25, Serial1.2 : Mismatch Authentication Key - Clear Text OSPF_ROUTER_A(config-subif)# OSPF: 2 Way Communication to neighbor 177.36.254.25 OSPF: send DBD packet to 177.36.252.25 seq 0xCC5 OSPF: Receive dbd from 177.36.254.25 seq 0x794 OSPF: NBR Negotiation Done We are the SLAVE OSPF: send DBD packet to 177.36.252.25 seq 0x794 OSPF: Receive dbd from 177.36.254.25 seq 0x795 OSPF: send DBD packet to 177.36.252.25 seq 0x795 OSPF: Receive dbd from 177.36.254.25 seq 0x796 OSPF: send DBD packet to 177.36.252.25 seq 0x796 OSPF: Receive dbd from 177.36.254.25 seq 0x797 OSPF: Exchange Done with neighbor 177.36.254.25 OSPF: Synchronized with neighbor 177.36.254.25, state:FULL Step 6 Revisited Again: Gather Results We then confirmed that the OSPF adjacency STATES were now correct because they both were FULL. This meant that the OSPF link-state databases for all routers were 100 percent synchronized with each other, and, most importantly, routing was now working correctly as shown in the following output. ROUTER_A#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 177.32.253.6 1 FULL/DR 00:00:31 177.2.254.5 Ethernet0 177.36.254.5 1 FULL/ - 00:00:39 177.36.252.5 Serial0.2 177.36.254.25 1 FULL/ - 00:00:30 177.36.252.25 Serial1.2 By executing some trace routes, we confirmed that the primary links (768K Frame Links) were now routing traffic through the proper primary path, namely Router A. The final relevant OSPF router configuration for Router A was 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 area 2.1.0.0 stub ! This was certainly a solid fix relating to the originally reported routing problem. However, users were still complaining of a slowdown. Problem #2: Performance IssuesIn Step 3, we identified that there were, in fact, two problems being seen in the network. These two problems (routing and performance) were causing the customers slow downs. At this point we have successfully resolved problem #1 and its routing issues. So we must now resolve the second problem: network performance. Step 1: Define the Problem At this point, the network was routing according to design, but there still was a high percentage of traffic coming into Router A from the LAN segment Downtown. Users Downtown were still complaining of a slowdown, so we had a clear problem definition. We used the troubleshooting model again to develop and implement an action plan. Step 2: Gather Facts We observed that there were still a significant amount of output drops on Router C and Router D. The following output is for Router C: ROUTER_C#show int s0/0:0 Serial0/0:0 is up, line protocol is up Hardware is DSX1 Description: Frame Relay Circuit to Headquarters MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec, rely 255/255, load 6/255 Encapsulation FRAME-RELAY IETF, loopback not set, keepalive set (10 sec) LMI enq sent 16732, LMI stat recvd 16732, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE Broadcast queue 0/64, broadcasts sent/dropped 983815/57443, interface broadcasts 1035677 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1d22h Input queue: 0/75/48 (size/max/drops); Total output drops: 1500632 Queueing strategy: weighted fair Output queue: 0/64/19 (size/threshold/drops) Conversations 0/51 (active/max active) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 50000 bits/sec, 19 packets/sec 5 minute output rate 42000 bits/sec, 8 packets/sec 1493015 packets input, 320768751 bytes, 0 no buffer Received 0 broadcasts, 2 runts, 0 giants, 0 throttles 48 input errors, 35 CRC, 13 frame, 0 overrun, 0 ignored, 2 abort 2335606 packets output, 845399484 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets This output is very useful in troubleshooting suspected utilization issues. The statistics that are presented here will show, for example, if the circuit is taking errors. Additionally, it will describe what kinds of errors the circuit is seeing. In this case, the output showed a large number of output drops. The vast number of output drops was a signal that there was a lot of unnecessary traffic being routed across the WAN links. Essentially, a vicious cycle of repeated retransmits was formed, further aggravating the problem.
|