[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