Total Output Drops Increase

mmaskart · ‎09-28-2009

I'd like some advice on an output drop issue I'm having with a point-to-point T1. The output drops increment up by 200 - 700 every 15 minute interval during business hours. After hours no drops are recorded. Traffic is at approx 50% up and 20% down so the drops shouldn't be from over utilization. (see attached) The traffic on the T1 is 90% HTTP data.

I've read other posts recommending a larger hold-queue. Before I made any changes, I wanted to see what the community thought and if there were any other recommendations.

Is there a hold-queue that is an â€œindustry standardâ€?

Should the A end and Z end serial interfaces have symmetrical hold-queue settings?

Any help would be greatly appreciated.

Serial0/1/0:1 is up, line protocol is up

Hardware is DSX1

Description:

Internet address is x.x.x.x

MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,

reliability 255/255, txload 34/255, rxload 125/255

Encapsulation PPP, LCP Open

Open: IPCP, CDPCP, crc 16, loopback not set

Keepalive set (10 sec)

Last input 00:00:15, output 00:00:00, output hang never

Last clearing of "show interface" counters 5d01h

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 28649

Queueing strategy: weighted fair

Output queue: 0/1000/64/28649 (size/max total/threshold/drops)

Conversations 0/15/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1152 kilobits/sec

5 minute input rate 758000 bits/sec, 140 packets/sec

5 minute output rate 207000 bits/sec, 116 packets/sec

13646945 packets input, 3277093550 bytes, 28649 no buffer

Received 0 broadcasts, 175 runts, 0 giants, 0 throttles

273 input errors, 265 CRC, 8 frame, 0 overrun, 0 ignored, 19 abort

11786125 packets output, 2192650970 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

paolo bevilacqua · ‎09-28-2009

That is normal, your traffic is trying to use more bandwidth than you have.

Increasing hold-queue will only delay the point where packets are discarded, hence is not a real solution.

You should consider if you have business-critical traffic to protect via QoS, that is the only thing you can do beside increasing bandwidth.

Joseph W. Doherty · ‎09-28-2009

"Traffic is at approx 50% up and 20% down so the drops shouldn't be from over utilization."

Unfortunately, such stats usually provide an average load over some time period (often into minutes) while drops often happen down at the millisecond level. As your drops show, less than 100% average utilization doesn't preclude them.

It appears you might be running WFQ on this interface, which generally manages congestion well. Assuming your transient congestion is from TCP bandwidth probing (likely with your noting 90% of traffic is HTTP), it's possible you could reduce your drop rate (which, as a percentage [.24%], appears acceptable) by some amount but you may possibly introduce other adverse effects.

I would recommend you leave things as they are for now.

"Is there a hold-queue that is an â€œindustry standardâ€? "

One might argue for a queue that can support BDP (bandwidth delay product).

"Should the A end and Z end serial interfaces have symmetrical hold-queue settings? "

Depends on different factors, one being whether you also have symmetrical performance.