• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Question about router screen capture?

ScottFern

Diamond Member
Ok, I had an analysis done on our frame relay line here at work to see if we were maxing out the bandwidth. The NOC told me we were indeed at our limits but how do I decipher that from this screenshot he took?
1N20-R01>sho int s0
Serial0 is up, line protocol is up
Hardware is QUICC Serial
Description: CKT AREC517894 DNA 2117144 URN MKE1AA-101
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, rely 255/255, load 18/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
LMI enq sent 7156, LMI stat recvd 7156, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 2390/0, interface broadcasts 6
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: priority-list 2
Output queue (queue priority: size/max/drops):
high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0
5 minute input rate 11000 bits/sec, 7 packets/sec
5 minute output rate 4000 bits/sec, 6 packets/sec
188028 packets input, 61781355 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
152400 packets output, 12162492 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

1N20-R01>sho int s0.1
Serial0.1 is up, line protocol is up
Hardware is QUICC Serial
Description: TO STINHUB-R12/H3/0
Internet address is 10.254.96.234/30
MTU 1500 bytes, BW 16 Kbit, DLY 20000 usec, rely 255/255, load 18/255
Encapsulation FRAME-RELAY
1N20-R01>sho int s0.2
Serial0.2 is up, line protocol is up
Hardware is QUICC Serial
Description: TO STINHUB-R11/H3/0
Internet address is 10.254.140.234/30
MTU 1500 bytes, BW 16 Kbit, DLY 20000 usec, rely 255/255, load 18/255
Encapsulation FRAME-RELAY
1N20-R01>

Thanks!

He said that the load 18/255 was high and once it reaches 30/255 we would start to drop packets?
 
load is a value out of 255 of the bandwidth configured on the interface.

From the serial port
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, rely 255/255, load 18/255

What's important is the load on the serial port, not necessarily the sub interface.

You guy's aren't using anywhere near the capacity of your link. The statement about dropping packets is also so far from the truth this noc monkey should be fired for incompetence. Also if that really is a 56k circuit, that is incredibly, painfully slow.
 
I just did. The load statement.

There's also this:
5 minute input rate 11000 bits/sec, 7 packets/sec
5 minute output rate 4000 bits/sec, 6 packets/sec

That is your input and output rate. 11 kbit in, 4 kbit out. Keep in mind that these cournters are a rolling 5 minute average so the counters should be cleared, then a large file transfer started, then record the output of show interface. Show frame-relay map is also a good command to see what the frame switch set your CIR to.
 
See now I am stuck in this whole mess......My boss just called me because I sent this to him in an email and he said that this proves nothing and he wants to wait until after we switch Circuit providers (basically switching to a new circuit card) and then run the test again. But when I got off the phone with the NOC at EDS he told me that our circuit was definitely maxed. WTF gives?

Thanks for the explanation!
 
Originally posted by: spidey07
Not only is that noc clueless. So is your boss.

So this frame relay connection is definitely extremely slow and most likely the cause of our continued slow responses for our software that connects over this frame line?
 
It's barely faster than a modem.

Absolutely the cause of your slow response. Changing to another 56k circuit will yield absolutely no improvement.
 
Right thats the point I am trying to get through to my boss. I think he is simply denying the idea that it is too slow because its an extra cost each month.
 
Back
Top