cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3442
Views
35
Helpful
16
Replies

Many Output Queue drops and 255 txload 255 rxload on ASR1002

N3t W0rK3r
Level 3
Level 3

We're troubleshooting an issue with our Internet performance.  We are provisioned with a 1Gbps symmetrical link from our ISP and currently the ASR outside interface (gi0/0/0) shows around 30% utilization:

 

INTERNET-ROUTER#sh int gi0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
Hardware is 4XGE-BUILT-IN, address is 001f.ca15.ed00 (bia 001f.ca15.ed00)
Description: OUTSIDE TO ISP
Internet address is a.b.c.d
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 49/255, rxload 61/255
Encapsulation ARPA, loopback not set
Keepalive not supported
Full Duplex, 1000Mbps, link type is auto, media type is T
output flow-control is on, input flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:11, output 00:01:24, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/2497/1030 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 239675000 bits/sec, 49780 packets/sec
5 minute output rate 193607000 bits/sec, 44036 packets/sec
108538977078 packets input, 55832140065374 bytes, 0 no buffer
Received 326948 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
99430287225 packets output, 38558895093668 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

 

Now looking at the inside interface (Gi0/0/3) we see problems with txload, rxload and output queue drops:

 

INTERNET-ROUTER#sh int gi0/0/3
GigabitEthernet0/0/3 is up, line protocol is up
Hardware is 4XGE-BUILT-IN, address is 001f.ca15.ed03 (bia 001f.ca15.ed03)
Description: INSIDE TO ASA
Internet address is e.f.g.h
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 255/255, rxload 255/255
Encapsulation ARPA, loopback not set
Keepalive not supported
Full Duplex, 1000Mbps, link type is force-up, media type is T
output flow-control is on, input flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 800781112
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 110959000 bits/sec, 28364 packets/sec
5 minute output rate 231570000 bits/sec, 39173 packets/sec
50404755765 packets input, 21397119353119 bytes, 0 no buffer
Received 398901 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2940620 multicast, 0 pause input
65949758049 packets output, 56288732167788 bytes, 0 underruns
0 output errors, 0 collisions, 6 interface resets
270970 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

 

So my question is, txload/rxload seems to indicate the interface is saturated but the input rate/output rate doesnt indicate anything close to the 1 Gbps link speed capable.  How is this possible?  Is this a bug or a defect in the hardware?

 

Our ASR 1002 is running version 03.16.10.S.

 

Our observations on speed tests run using Speedtest.net is that our download speed is often a third (or more) of our upload.

 

Thanks in advance for any light you can shed on this issue.

16 Replies 16

Well, we had our maintenance window last night and tried changing the neighboring ports to auto/auto.  Although the ports came back successfully, this did not correct the bandwidth reported issue, the output drops or improve the speed test results.

We then provisioned a new port, with a new SFP on the 5-port SPA card with a new patch cable.  This worked perfectly in all aspects.

Out of curiosity, we replaced the patch cable with the original cable and observed the same positive results across the board (1 Gbps reported, 0 output drops and almost 900 Mbps download in speed test).

So, it looks like perhaps the problem was with the SFP or SPA port itself.

 

Thanks again for all of your input.  I am relieved to finally put this behind me!

 

Cheers and stay safe.

 

Hi,

Good to hear that the issue is resolved.

Seems to be a SFP issue from the outcome you have mentioned which also triggered auto negotiation not to work as expected.

Have a great day

Regards

Naresh M

Review Cisco Networking products for a $25 gift card