11-25-2013 09:44 AM - edited 03-07-2019 04:46 PM
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
11-25-2013 10:38 AM
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.
11-25-2013 11:19 AM
Thank you for the response. Our router is a 2801.
Looks I might just need to live with it for now.
11-25-2013 11:48 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide