output drops metro ethernet

Unanswered Question
Jul 25th, 2007

Hi Cisco Gurus,

I got a 6M Metro Ethernet connecting to ISP ( for online portal) Over at the ISP end, they rate-limit the bandwidth to 6M, so at my end, i do a shape average 6M. however, when traffic starts to pick up, I'm seeing output drops.

can someone help, how to prevent this output drops?

FastEthernet0/0 is up, line protocol is up

Hardware is DEC21140A, address is 001b.1220.c566 (bia 001b.1220.c566)

Description: 6M

Internet address is x.x.x.x/30

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 8/255, rxload 2/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

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 2d15h

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

Queueing strategy: fifo

Output queue: 0/256 (size/max)

5 minute input rate 869000 bits/sec, 994 packets/sec

5 minute output rate 3345000 bits/sec, 783 packets/sec

76710288 packets input, 4270347388 bytes

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

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog

0 input packets with dribble condition detected

51537740 packets output, 2096654250 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

-------------------------

policy-map Portal

class class-default

shape average 6000000

----------------------------

interface FastEthernet0/0

description 6M

ip address x.x.x.x 255.255.255.252

ip access-group 102 in

duplex full

crypto map portal

service-policy output Portal

hold-queue 256 out

-----------------------------

Service-policy output: Portal

Class-map: class-default (match-any)

51913677 packets, 28077461511 bytes

5 minute offered rate 3471000 bps, drop rate 42000 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

6000000/6000000 37500 150000 150000 25 18750

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 51728147 2199183656 4474112 2501511188 no

------------------------------

FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):

0 in free list (0 min, 400 max allowed)

400 hits, 0 fallbacks

400 max cache size, 271 in cache

461922581 hits in cache, 0 misses in cache

14 buffer threshold, 0 threshold transitions

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Thu, 07/26/2007 - 05:03

Hello,

you have 6 Mbps traffic shaping configured, so everything the traffic exceeds that, and beyond burst, there will be drops.

Hope this helps, please rate post if it does!

tiew_lenny Thu, 07/26/2007 - 05:29

Hello,

Output offer rate is 3471000 bps, and seeing drops. Why is it?

what is this command doing " shape ave 6000000 "

Paolo Bevilacqua Thu, 07/26/2007 - 05:40

You can be having traffic peaks and not seeing them. The offered rate is even average over some interval of time.

What the command does is to shape average output to 6 Mbps. As I mentioned before, excess traffic beyond allowed burst size, is consequently dropped.

Zeek Ferraros Wed, 01/09/2013 - 09:23

I have a similar problem and wondering if there is any way to resolve the output drops?

For example:

If I see output drops on a 6M MetroE link with a "shape average 6M" in place

what can I do to reduce the output drops?

lower the number on the "shape average" command? like "shape average 5.5M" ?

Any help would be appreciated.

Joseph W. Doherty Wed, 01/09/2013 - 14:36

Disclaimer


The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

If the drops are caused by transient bursting, what might mitigate drops is increased queue depths (although this trades reduced drops for increased latency).  (Note: I recall not all platform/IOS combinations allow queue depth modification for a shaper.)

Actions

This Discussion