cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1212
Views
0
Helpful
3
Replies

qos policy mod needed?? int buffer/input errors due to overload??

jacob6000
Level 1
Level 1

Hello,

I have a site that connects to the Internet via cable modem. It is 50 down/3mbps up. I have QoS policy that Mr. Clarke modifed for me. I am running into an issue where a FTP transfer kicks in and the receiving rate goes up. my QoS is outbound. This causes a few seconds of poor performance for the VoIP calls (outsourced voip solution). I am assuming the fa0/1 input errors and "ignored" errors are due to a temporary traffic overload because I see buffer misses as well. The router was rebooted at midnight so all these stats got increased the past few hours when the transfer started.

Questions:

1) I have some legacy RMON commands configured that got put in by AutoQoS back when we used to use those policies. Aren't the RMON messages telling me that packets got dropped? Does that correlate to the out "Output" drops on my fa0/1 interface?

2) Any idea on how to solve this performance issue for my phones? Any feedback in general is appreciated as well.

policy-map VoIP

class QOS_REAL-TIME_VOIP

    priority 784

class class-default

    fair-queue

policy-map shape4upstream

class class-default

    shape average 2550000

  service-policy VoIP

000069: *Nov 25 06:04:20.372: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.82.9499905 has fallen below the falling-threshold value 0

000070: *Nov 25 06:04:20.380: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.98.6655009 has fallen below the falling-threshold value 0

000071: *Nov 25 06:04:20.392: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.114.12496961 has fallen below the falling-threshold value 0

000072: *Nov 25 06:04:20.400: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.130.2260449 has fallen below the falling-threshold value 0

000073: *Nov 25 06:04:20.412: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.146.12687473 has fallen below the falling-threshold value 0

000074: *Nov 25 06:04:20.420: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.162.632273 has fallen below the falling-threshold value 0

000075: *Nov 25 06:04:20.432: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.178.10296481 has fallen below the falling-threshold value 0

000076: *Nov 25 06:04:20.440: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of cbQosCMDropBitRate.66.2065329 has fallen below the falling-threshold value 0

sh int fa0/1

FastEthernet0/1 is up, line protocol is up

  Hardware is Gt96k FE, address is 0015.63c6.b471 (bia 0015.63c6.b471)

  Internet address is X.X.X.X

  MTU 1500 bytes, BW 51200 Kbit/sec, DLY 100 usec,

     reliability 255/255, txload 1/255, rxload 33/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:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

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

  Queueing strategy: Class-based queueing

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

  5 minute input rate 6684000 bits/sec, 595 packets/sec

  5 minute output rate 194000 bits/sec, 342 packets/sec

     3839640 packets input, 672097306 bytes

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

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

     0 watchdog

     0 input packets with dribble condition detected

     2367701 packets output, 254682824 bytes, 0 underruns

     0 output errors, 0 collisions, 2 interface resets

     0 unknown protocol drops

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier

     0 output buffer failures, 0 output buffers swapped out

sh buffers

Buffer elements:

     1029 in free list (1119 max allowed)

     431050 hits, 0 misses, 619 created

Public buffer pools:

Small buffers, 104 bytes (total 92, permanent 50, peak 128 @ 11:25:21):

     89 in free list (20 min, 150 max allowed)

     1549213 hits, 43 misses, 78 trims, 120 created

     0 failures (0 no memory)

Middle buffers, 600 bytes (total 25, permanent 25, peak 82 @ 11:25:21):

     23 in free list (10 min, 150 max allowed)

     445670 hits, 27 misses, 75 trims, 75 created

     0 failures (0 no memory)

Big buffers, 1536 bytes (total 56, permanent 50, peak 56 @ 00:22:25):

     56 in free list (5 min, 150 max allowed)

     94466 hits, 55 misses, 0 trims, 6 created

     45 failures (0 no memory)

VeryBig buffers, 4520 bytes (total 12, permanent 10, peak 12 @ 00:21:54):

     12 in free list (0 min, 100 max allowed)

     25 hits, 24 misses, 0 trims, 2 created

     24 failures (0 no memory)

Large buffers, 5024 bytes (total 2, permanent 0, peak 2 @ 00:21:54):

     2 in free list (0 min, 10 max allowed)

     1 hits, 23 misses, 0 trims, 2 created

     23 failures (0 no memory)

Huge buffers, 18024 bytes (total 2, permanent 0, peak 2 @ 00:22:06):

     2 in free list (0 min, 4 max allowed)

     1 hits, 22 misses, 0 trims, 2 created

     22 failures (0 no memory)

MPHOUCME01#sh policy-map int fa0/1

FastEthernet0/1

  Service-policy output: shape4upstream

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

      2688245 packets, 282284201 bytes

      5 minute offered rate 251000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/320/0

      (pkts output/bytes output) 2687418/280476958

      shape (average) cir 2550000, bc 63750, be 63750

      target shape rate 2550000

      Service-policy : VoIP

        queue stats for all priority classes:

          Queueing

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/0/0

          (pkts output/bytes output) 138899/39892920

        Class-map: QOS_REAL-TIME_VOIP (match-any)

          138899 packets, 39751453 bytes

          5 minute offered rate 4000 bps, drop rate 0 bps

          Match: access-group name VOIP_Traffic

            138899 packets, 39751453 bytes

            5 minute rate 4000 bps

          Priority: 784 kbps, burst bytes 19600, b/w exceed drops: 0

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

          2549348 packets, 242532748 bytes

          5 minute offered rate 242000 bps, drop rate 0 bps

          Match: any

          Queueing

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops/flowdrops) 0/320/0/320

          (pkts output/bytes output) 2548519/240584038

          Fair-queue: per-flow queue limit 16

3 Replies 3

Joseph W. Doherty
Hall of Fame
Hall of Fame

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

What model router?  With 50/3 WAN link, you should have about a 2921.

Your drop count is so low to overall packet counts, doubtful that's an issue.  (Also don't believe the RMON traps are drops related, but are transfer rate related.)

If running FTP, your (from Internet) ingress can saturate your 50 Mbps and disrupt VoIP inbound.  Ingress is very difficult to manage transmitter's rate.  Ideally you want to manage the other side's egress.  If you cannot, you might obtain some benefit from policing some ingress TCP or shaping some egress TCP ACKs.  Doing either normally requires very severe settings to insure adequate headroom for your more important traffic.

Thank you for the response. Our router is a 2801.

Looks I might just need to live with it for now.

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

A 2801 is undersized for 50/3 link.  (It was really designed to handle a T1/E1 or two, although it can probably handle 10 Mbps [duplex].)

If you have the command "show proc c h", looks for bursts of 100% CPU utilization.

Not enough information to say whether the 2801's performance is an issue.

If you have an "intelligent" switch (e.g. 29xx), you might be able to police (and even "shape") traffic to the 2801 (both internal and external) to keep from overloading it.

However, I would first suspect ingress congestion.

Review Cisco Networking for a $25 gift card