05-23-2011 05:49 AM - edited 03-04-2019 12:29 PM
I have question regarding Qos configuration on my WAN router. we have 100mbps WAN connection that feeds to mutliple site & we have applied Nested MQC. We are using vmwware view & that requires a lot of bandwidth so after voice & view have most of the bandwidth(60Mbps) is assigned .
After looking into the sh policy-map int gi0/1 command , I am finding that there are some drops on vmware view class & default class as well.
if you look at the config I have 5Mbps for voice & 60Mpbs for View traffic assigned. Before adding some more site I wanted to find out about these drops. I believe unclassified traffic will put into the default class but I would like to understand how this 30 second offered rate works ?
so if I have 30Mbps default class traffic than what will be my 30 secod offered rate ??( 30*30Mbps ) ??
Or View Traffic which is 60mbps guranted what will be my 30 second offered rate ? ( I can't believe that I am seeing drops on these)
Policy Map Metro-E
Class class-default
Average Rate Traffic Shaping
cir 100000000 (bps)
service-policy WAN-EDGE-ISP
Policy Map WAN-EDGE-ISP
Class VOICE
priority 5000
Class VOICE-CTRL
bandwidth 512
Class VIDEO
bandwidth 1000
Class VMWARE_VIEW
bandwidth 60000
Class class-default
fair-queue
interface GigabitEthernet0/1
description ISP
ip address X.X.X.X 255.255.255.252
duplex auto
speed auto
service-policy output Metro-E
==================================================
CHKD-WAS-COXATM-RTR#sh policy-map int gi0/1
GigabitEthernet0/1
Service-policy output: Metro-E
Class-map: class-default (match-any)
3135457351 packets, 861119166697 bytes
30 second offered rate 5725000 bps, drop rate 16000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/3247472/1980
(pkts output/bytes output) 3134300024/864967258106
shape (average) cir 100000000, bc 400000, be 400000
target shape rate 100000000
Service-policy : WAN-EDGE-ISP
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/254/254
(pkts output/bytes output) 479284491/82268615766
Class-map: VOICE (match-any)
479281966 packets, 75279196865 bytes
30 second offered rate 313000 bps, drop rate 0 bps
Match: ip dscp ef (46)
9871531 packets, 1293626248 bytes
30 second rate 18000 bps
Match: ip rtp 16384 16383
469413150 packets, 73985973595 bytes
30 second rate 295000 bps
Priority: 5000 kbps, burst bytes 125000, b/w exceed drops: 254
Class-map: VOICE-CTRL (match-any)
19186898 packets, 1737982174 bytes
30 second offered rate 4000 bps, drop rate 0 bps
Match: ip dscp af31 (26)
11 packets, 1914 bytes
30 second rate 0 bps
Match: ip dscp cs3 (24)
17192863 packets, 1225528998 bytes
30 second rate 3000 bps
Match: access-group name QoS_CallControl
1994024 packets, 512451262 bytes
30 second rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/326/2
(pkts output/bytes output) 19186576/1737855104
bandwidth 512 kbps
Class-map: VIDEO (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: ip dscp af41 (34)
0 packets, 0 bytes
30 second rate 0 bps
Match: access-group name QOS_Video
0 packets, 0 bytes
30 second rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 1000 kbps
Class-map: VMWARE_VIEW (match-any)
689809393 packets, 243968733796 bytes
30 second offered rate 784000 bps, drop rate 0 bps
Match: access-group name VMWARE_VIEW
689809393 packets, 243968734588 bytes
30 second rate 784000 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/580301/619
(pkts output/bytes output) 689229090/243609123774
bandwidth 60000 kbps
Class-map: class-default (match-any)
1947181335 packets, 540134080193 bytes
30 second offered rate 4620000 bps, drop rate 16000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/2666591/1105/2665486
(pkts output/bytes output) 1946599864/537351661254
Fair-queue: per-flow queue limit 16
Sincerely,
Viral
Solved! Go to Solution.
05-24-2011 05:44 PM
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
re: "too fast"
Also another possible issue, many IOS shapers, don't account for L2 overhead. I.e. your shaping for 100 Mbps could be "too fast".)
If this doesn't make sense, let me know.
re: "I would like to know how you came up with anywhere near 100 Mbps throughput (about 6 Mbps!)? "
From your 1st post stats, saw:
"30 second offered rate 5725000 bps, drop rate 16000 bps"
5725000 bps = about 6 Mbps, and its dropping packets.
I'm sure you do get more, I wasn't clear (sorry) - packets being dropped at such a low percentage, too me, implies a problem.
What's does the interface show for outbound bandwidth in comparison to the policy stats?
Still suspect your queues are too shallow for 100 Mbps. What's your end-to-end, across WAN, latency?
05-23-2011 05:40 PM
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
BTW, from what you described, and before getting to your specific questions, although you're shaping for your logical WAN interface, what's the bandwidth to the other sites? If not also 100 Mbps or if they are mutiple sites which can inter-communicate, you're likely to have congestion at MetroE egress. (Also another possible issue, many IOS shapers, don't account for L2 overhead. I.e. your shaping for 100 Mbps could be "too fast".)
The bandwidth statements, in non-LLQ classes, are used to set scheduling weight in such a way that you minimum bandwidth should be provided. However, in IOSs w/o HQF like support, class-default can generate multiple flows each contending for bandwidth, which, I believe, can distort defined class bandwidths.
"Offered rate", I believe is a measure of the bandwidth the class "sees". It minus drop rate would be class transmission rate.
From your stats, since your not getting anywhere near 100 Mbps throughput (about 6 Mbps!?), and class-default is dropping packets(!), suspect indivdual queue depth, at 16, is much, much too shallow. Overall queue depth, 64, might also be too shallow for 100 Mbps. Some of the later IOSs allow configuration modifications of these.
Consider at 100 Mbps, 50 ms would be 5,000,000 bits or 625,000 bytes, or about 428 packets with 1460 payload.
05-24-2011 08:34 AM
BTW, from what you described, and before getting to your specific questions, although you're shaping for your logical WAN interface, what's the bandwidth to the other sites? If not also 100 Mbps or if they are mutiple sites which can inter-communicate, you're likely to have congestion at MetroE egress. (Also another possible issue, many IOS shapers, don't account for L2 overhead. I.e. your shaping for 100 Mbps could be "too fast".)
The bandwidth statements, in non-LLQ classes, are used to set scheduling weight in such a way that you minimum bandwidth should be provided. However, in IOSs w/o HQF like support, class-default can generate multiple flows each contending for bandwidth, which, I believe, can distort defined class bandwidths.
"Offered rate", I believe is a measure of the bandwidth the class "sees". It minus drop rate would be class transmission rate.
From your stats, since your not getting anywhere near 100 Mbps throughput (about 6 Mbps!?), and class-default is dropping packets(!), suspect indivdual queue depth, at 16, is much, much too shallow. Overall queue depth, 64, might also be too shallow for 100 Mbps. Some of the later IOSs allow configuration modifications of these.
Consider at 100 Mbps, 50 ms would be 5,000,000 bits or 625,000 bytes, or about 428 packets with 1460 payload.
=============================================================================================
First of all thanks for your reply.
I have Hub & Spoke kind of topology & all my offsite traffic comes into WAN Router. I am wondering if you can explain "your shaping for 100 Mbps could be "too fast"
I would like to know how you came up with anywhere near 100 Mbps throughput (about 6 Mbps!)?
I am currenlty using Version 12.4(20)T on 3845 Series router.
I have sampled the stats : & trying to figure out how the my 30 second offfered rate is just 3.2Mbps & I still have drops on View Traffic.
WAN-RTR#sh policy-map int gi0/1 | be VMWARE
Class-map: VMWARE_VIEW (match-any)
8962790 packets, 3228673040 bytes
30 second offered rate 3272000 bps, drop rate 19000 bps
Match: access-group name VMWARE_VIEW
8962790 packets, 3228673040 bytes
30 second rate 3272000 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 1/13133/0
(pkts output/bytes output) 8949658/3220409068
bandwidth 60000 kbps
Class-map: class-default (match-any)
22528969 packets, 7336523898 bytes
30 second offered rate 5566000 bps, drop rate 30000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 8/68232/0/68232
(pkts output/bytes output) 22468376/7260044601
Fair-queue: per-flow queue limit 16
===============================================================================
WAN-RTR#sh policy-map int gi0/1 | be VMWARE
Class-map: VMWARE_VIEW (match-any)
8964413 packets, 3229562889 bytes
30 second offered rate 3272000 bps, drop rate 19000 bps
Match: access-group name VMWARE_VIEW
8964413 packets, 3229562889 bytes
30 second rate 3272000 bps (3.2Mbps)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/13272/0
(pkts output/bytes output) 8951141/3221185261
bandwidth 60000 kbps
Class-map: class-default (match-any)
22531222 packets, 7337179674 bytes
30 second offered rate 5566000 bps, drop rate 30000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/68234/0/68234
(pkts output/bytes output) 22470636/7260701639
Fair-queue: per-flow queue limit 16
Sincerely,
Viral
05-24-2011 05:44 PM
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
re: "too fast"
Also another possible issue, many IOS shapers, don't account for L2 overhead. I.e. your shaping for 100 Mbps could be "too fast".)
If this doesn't make sense, let me know.
re: "I would like to know how you came up with anywhere near 100 Mbps throughput (about 6 Mbps!)? "
From your 1st post stats, saw:
"30 second offered rate 5725000 bps, drop rate 16000 bps"
5725000 bps = about 6 Mbps, and its dropping packets.
I'm sure you do get more, I wasn't clear (sorry) - packets being dropped at such a low percentage, too me, implies a problem.
What's does the interface show for outbound bandwidth in comparison to the policy stats?
Still suspect your queues are too shallow for 100 Mbps. What's your end-to-end, across WAN, latency?
05-27-2011 10:32 AM
Once Again Thank you for your reply. I removed the shaping but I was still getting drops on View traffic. I removed the Qos altogether :
For 5 hours & some minute no output drops. I am confused now.
sh int gi0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 001e.be10.19c1 (bia 001e.be10.19c1)
Description: COX-METRO-E PRINCESS/VOLVO
Internet address is 10.21.251.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 29/255, rxload 14/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
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 00:03:47
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 77/2000 (size/max)
30 second input rate 5660000 bits/sec, 2367 packets/sec
30 second output rate 11692000 bits/sec, 2320 packets/sec
454942 packets input, 174325805 bytes, 0 no buffer
Received 211 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 9279 multicast, 0 pause input
0 input packets with dribble condition detected
396532 packets output, 178155525 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 001e.be10.19c1 (bia 001e.be10.19c1)
Description: COX-METRO-E PRINCESS/VOLVO
Internet address is 10.21.251.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 22/255, rxload 21/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output 00:00:00, output hang never
Last clearing of "show interface" counters 05:26:24
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/2000 (size/max)
30 second input rate 8326000 bits/sec, 3433 packets/sec
30 second output rate 8865000 bits/sec, 2962 packets/sec
76084253 packets input, 164780924 bytes, 0 no buffer
Received 34671 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1130392 multicast, 0 pause input
0 input packets with dribble condition detected
62475429 packets output, 1028058297 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
86 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
I hope somebody can explain me 30 second offered rate & drop rate ( what should be this value in ideal word if I have assigned 60Mbps to view traffic)
sh policy-map int gi0/1 | be VMWARE_VIEW
Class-map: VMWARE_VIEW (match-any)
158755 packets, 54247240 bytes
30 second offered rate 2351000 bps, drop rate 0 bps
Match: access-group name VMWARE_VIEW
158755 packets, 54247240 bytes
30 second rate 2351000 bps
Queueing
queue limit 128 packets
(queue depth/total drops/no-buffer drops) 0/6/0
(pkts output/bytes output) 158747/54243288
bandwidth 60000 kbps
Class-map: class-default (match-any)
592868 packets, 210011906 bytes
30 second offered rate 7422000 bps, drop rate 105000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 3/1609/0/1609
(pkts output/bytes output) 591574/207979753
Fair-queue: per-flow queue limit 16
############################################################################
sh policy-map int gi0/1 | be VMWARE_VIEW
Class-map: VMWARE_VIEW (match-any)
159579 packets, 54614680 bytes
30 second offered rate 2533000 bps, drop rate 2000 bps ( at one point I was thinking that 2351000 bps is the value ) But other output did not match but I still do not know how IOS is coming up with this 30 second number offered rate & drop rate )
Match: access-group name VMWARE_VIEW
159579 packets, 54614680 bytes
30 second rate 2533000 bps
Queueing
queue limit 128 packets
(queue depth/total drops/no-buffer drops) 4/6/0
(pkts output/bytes output) 159574/54611606
bandwidth 60000 kbps
Class-map: class-default (match-any)
595177 packets, 211237940 bytes
30 second offered rate 7086000 bps, drop rate 91000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 43/1616/0/1616
(pkts output/bytes output) 593878/209195765
Fair-queue: per-flow queue limit 16
05-27-2011 04:05 PM
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
patelvc7601 wrote:
Once Again Thank you for your reply. I removed the shaping but I was still getting drops on View traffic. I removed the Qos altogether :
For 5 hours & some minute no output drops. I am confused now.
sh int gi0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 001e.be10.19c1 (bia 001e.be10.19c1)
Description: COX-METRO-E PRINCESS/VOLVO
Internet address is 10.21.251.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 29/255, rxload 14/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
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 00:03:47
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 77/2000 (size/max)
30 second input rate 5660000 bits/sec, 2367 packets/sec
30 second output rate 11692000 bits/sec, 2320 packets/sec
454942 packets input, 174325805 bytes, 0 no buffer
Received 211 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 9279 multicast, 0 pause input
0 input packets with dribble condition detected
396532 packets output, 178155525 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Look at your queue limit (20000) and current queue depth (77). Compare to prior QoS queue limits.
07-26-2011 09:19 AM
If Anybody have read this post, I wanted to point this out that all these drops turn out to be duplex mismatch with my WAN Carrier. I knew about duplex mismatch is bad but this was not direct connection it was indirect connection which caused the issue. I had a open case with Carrier for few month & one fine day somebody was able to figure out.
My WAN Carrier was providing me the Etherenet Link & I had to stretch out to another building because my wan router was another building . I used the media converter between my WAN Router & Carrier Equipment, Duplex mismatch was between Media Converter to my Carrier Equipment( I did not have any visibility in terms of Error etc..) . I could not see any input or output errors on my Router because my router to media converter connection was good.
In short topology is like :
WAN(R) gi0/1 coper>>>100Base T Media Con 100Base Fiber.<<<<>>>>100Base Fiber Media Con,100Base T>>>>Carrier Equipment
With the same config for week now , Everything looks good. I had a TAC Case opened on this & they told me that micro burst is giving me those output drops.
My output drops disappear.
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 001e.b311.19c1 (bia 001e.b311.19c1)
Description:
Internet address is x.x.x.x/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 23/255, rxload 38/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 100Mbps, media type is RJ45
output flow-control is XON, input flow-control is XON
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 5d14h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/2000/0 (size/max total/drops)
30 second input rate 15284000 bits/sec, 6613 packets/sec
30 second output rate 9138000 bits/sec, 5025 packets/sec
1231779335 packets input, 1547946014 bytes, 0 no buffer
Received 543988 broadcasts (274684 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 553599 multicast, 0 pause input
911257186 packets output, 1770949254 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Thank you
Viral
07-26-2011 04:39 PM
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
Transient congestion might have been caused by retransmissions.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: