Monitoring Troubleshooting an OSPF Network | OSPF Network Design Solutions

Table of Contents

No OSPF neighbors were formed between Routers A & C, A & D, or B & D. The only link that was actively carrying routed traffic was between Routers C & B. Unfortunately, this circuit was a 0K CIR Frame Relay link. This meant that all traffic between routers C & B was being marked as discard eligible (DE) by the Frame Relay switches in the Frame Relay cloud. (That is, all traffic between Router C& B was set at such a low priority for packet delivery and could be dropped at any time.) As is discussed later in this case study, the Cisco router commands to show this information are show ip ospf neighbors and show frame pvc. The output for show frame pvc follows. Note that the number of input packets and the number of in DE packets are the same.

    ROUTER_C#Show frame pvc    PVC Statistics for interface Serial0/0:0.2 (Frame Relay DTE)    DLCI = 700, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =    Serial0/0:0.2       input pkts 31341659    output pkts 12061107    in bytes 757769644       out bytes 2564616415   dropped pkts 0          in FECN pkts 17       in BECN pkts 0         out FECN pkts 0         out BECN pkts 0       in DE pkts 31341659    out DE pkts 0       out bcast pkts 2690375  out bcast bytes 250333218       pvc create time 15w5d, last time pvc status changed 4w2d

Output Drops

A large number of output drops were noted on Router C’s only active OSPF WAN interface (the one with the 0K CIR Frame Relay PVC). Output drops signify that the router is processing a very large number of outbound frames. In this case, the circuit could not accommodate the vast amount of data that the router was trying to output into it, so, as a result, the router was dropping frames. This observation is important because it directly affects the number of retransmits that the router sends and contributes to slow end-user throughput. This happens in a router when the circuit and router are overloaded with a large amount of input or output traffic. As discussed later in this case study, the Cisco command to see this happening is show interface serial <interface number>. The next section will specifically cover the numbers of input and output drops in the output of this useful IOS command.

Input Drops

Large numbers of input drops were observed on Router B’s only active WAN interface (0K CIR Frame Relay PVC). Input drops signify that the router is processing a very large number of inbound frames. The router could not keep up with the data stream because there was so much inbound traffic. Consequently, the router was dropping many inbound frames resulting in large number of input drops being reported. This observation is important because it directly affects the number of retransmits that the router sends, contributing to slower end-user throughput. As discussed previously, the Cisco router command to do this is show interface serial <interface number>. The output of Router B’s WAN interface follows:

    ROUTER_B#show int s0/0:0    Serial0/0:0 is up, line protocol is up      Hardware is DSX1      Description: Frame Relay Circuit to Downtown      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 11212, LMI stat recvd 11212, 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/421238 (size/max/drops); Total output drops: 32333      Queueing strategy: weighted fair      Output queue: 0/64/32333 (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

Gather More Facts

In an attempt to gather more facts to form an action plan, we needed to know if the problem was related to a hardware problem or a software problem. Through the use of Telnet, we determined that we could successfully connect to all routers, although the performance was slow. This ruled out the possibility of a complete hardware failure on any of the routers. We then began to shift our focus on the router configurations. Our initial examination of Router A’s configuration showed that PVCs to C and D were defined, configured, and active (line up and line protocol up). The configuration that we observed follows:

    ROUTER_A# show running-config    !    interface Serial1     description Frame Relay PVCs Downtown to Router C     no ip address     encapsulation frame-relay IETF     bandwidth 56     no fair-queue     frame-relay lmi-type ansi    !    interface Serial1.1 point-to-point     description 768K CIR PVC to router C     ip address 177.36.252.6 255.255.255.252     frame-relay interface-dlci 700    !    interface Serial2     description Frame Relay PVCs Downtown to Router D     no ip address     encapsulation frame-relay IETF     bandwidth 56     no fair-queue     frame-relay lmi-type ansi    !    interface Serial2.1 point-to-point     description 768K PVC to Router D     ip address 177.36.252.26 255.255.255.252     frame-relay interface-dlci 701    !    router ospf 204     network 177.36.253.0 0.0.0.255 area 0     network 177.36.252.2 0.0.0.0 area 2.1.0.0     network 177.36.252.24 0.0.0.0 area 2.1.0.0     area 2.1.0.0 authentication     area 2.1.0.0 stub

Table of Contents