[c-nsp] DS1 Output Queue Drops
Sean Shepard
sean.shepard at ewavepartners.com
Tue Jun 12 18:23:13 EDT 2007
Definitely reset your load-interval (temporarily) to something shorter [30
or 60 seconds] and look for bursts of traffic that come in a short period of
time. You might also try something like Wireshark (ethereal) to capture
some information to identify the nature and "burstiness" of the traffic.
If you're overdriving the interface for short bursts, you might get some
relief by increasing the queue depth but there are other implications to
that. Based on your comments, I'm assuming you've read:
http://www.cisco.com/warp/public/63/queue_drops.html
Are you getting drops on any other interfaces?
Show int sum
(look at OQD column)
It's not necessarily unusual to get drops with big traffic bursts as
dropping packets is sometimes a device's way of saying "whooooahhh, slow
down..."
Other things to consider include: what does your CPU utilization, buffer and
memory situation look like?
show proc cpu hist
show buffers
and if there are buffer failures due to no memory
show mem
I just went through something similar related to MLPPP connections and
tweaking the hold queues helped tremendously. Typically this isn't needed
for T1 connections as I understand things.
I know there are wiser souls here but there are a few thoughts.
Regards,
Sean Shepard
President & COO
Integrated Business Communications, Inc and
OfficeTone, LLC http://www.officetone.com/
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peder @
NetworkOblivion
Sent: Tuesday, June 12, 2007 5:07 PM
To: Cisco-NSP Mailing List
Subject: [c-nsp] DS1 Output Queue Drops
I am running a 7505 with RSP4 and CT3IP card. I am getting what I think
is a large number of output queue drops and I am not sure what to do.
Here is an example, I reset the counters less than 4 minutes ago and got
74 drops already out of 13,888 packets. The 5 minutes average is ~
155,000 bps, so it is not even close to full T1 speed.
Serial1/0/0:8 is up, line protocol is up
Hardware is cyBus T3
Description: Cust1
Internet address is 192.168.1.1/30
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 25/255, rxload 13/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input 00:00:05, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:03:22
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 74
Queueing strategy: VIP-based fair queuing
Output queue: 0/40 (size/max)
5 minute input rate 83000 bits/sec, 57 packets/sec
5 minute output rate 155000 bits/sec, 61 packets/sec
12671 packets input, 1775939 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
13888 packets output, 5887080 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions no alarm present
Timeslot(s) Used: 1-24, Transmitter delay is 0 flags
non-inverted data
I have a service-policy applied and I am not seeing any drops there.
Here is output from there after about 10 minutes. No drops and it
doesn't appear to be even close to congestion.
TPN7505#sh pol int s 1/0/0:8
Serial1/0/0:8
Service-policy output: CUSTOMER-MAP
queue stats for all priority classes:
queue size 0, queue limit 192
packets output 7932, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Class-map: CUSTOMER (match-all)
7948 packets, 1655855 bytes
5 minute offered rate 42000 bps, drop rate 0 bps
Match: access-group name ToCustomer
Match: ip precedence 5
Priority: kbps 768, burst bytes 19200, b/w exceed drops: 0
Class-map: class-default (match-any)
17637 packets, 6537788 bytes
5 minute offered rate 50000 bps, drop rate 0 bps
Match: any
queue size 0, queue limit 192
packets output 17649, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Fair-queue: per-flow queue limit 48
My guess is that it goes through the policy and then to the output queue
where it gets dropped, but that is just a guess. If that's the case, I
can't figure out why there are no drops on the policy, but there are in
the output queue. I've looked at lots of docs on cisco.com related to
queues and none of it really helps much. Any ideas?
Peder
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list