12-24-2009 05:07 AM - edited 03-01-2019 04:29 PM
Technical background:
Qaulity Of Service (QOS) become a crucial service and feature in the modern IP networks specially with the implementations of VOIP and video over IP networks. QOS works as the gear of the modern networks because it mark/remark traffic ( classifications) reserve and prioritize some sort of traffic over others ( queuing) and in case of congestion it is able to start drop less important traffic based on classifications before the important traffic ( Weighted random early detection WRED). All the above features and services can be implemented and deployed to achieve what is know as end-to-end QOS network. with this approach we can grantee to a large extent that our sensitve traffic such as voice and video is guaranteed and prioritized over none sensitive traffic ( none real time ) such as web traffic and FTP.
In addition to the congestion management and congestion avoidance mechanisms mentioned above QOC can be used for security and/or rate limiting to make sure that the traffic going over the WAN link is not over subscribing the actual WAN link bandwidth and not over utilized, by policing or shaping the traffic going out that WAN interface, also we can deploy the policing and shaping to limit some traffic to certain amount of bandwidth which is useful also to have some level of security, for example we may use it to limit the management traffic such as telnet or SNMP traffic distend to the WAN router or any other device in the network.
Cisco IOS has several ways and mechanisms that can be used to implement and configure QOS, one of the best and commonly used method now is Modular Quality of service Command-Line MQC
Inthis document we will discuss a configuration example of how to use and configure MQC to meet a businesses requirements example, also we will see how to achieve the same goal by using more than one method
QOS Requirements:
company xyz.com has a WAN link between the HQ office and a branch office the WAN link bandwidth is 1Mbps
the comapny run VOIP traffic over this WAN link with the following marking:
VOIP RTP DSCP EF
VOIP Signaling CS3
VOIP RTP traffic must be serviced first in the case of interface congestion and guaranteed and limited at all times to 30 % of the WAN interface bandwidth
VOIP Signaling need a guaranteed bandwidth of 8 % of the interface in case of congestion
Telnet traffic need 3 % to be guaranteed in case of congestion
However telnet traffic to a host with the IP address 130.1.1.1 needs 5 % of the interface bandwidth to be guaranteed in the case of congestion
Routing traffic:
if there are 30 packets in the queue with CS 6 ( routing traffic ) the router has to start drop from these packets, if the packets reach 40, a 25 % of the packets must be dropped, if it go beyond 40 packet all the packet with CS 6 must be dropped
Configurations:
to achieve the above requirements we need first to identify our traffic classes this will be done by using class maps
access-list 100 permit tcp any host 130.1.1.1 eq telnet
this ACL used to match Telnet traffic going to the host 130.1.1.1 as required to have differnt QOS treatment than other tenet traffic
class-map match-all VOIP_SIG
match dscp cs3
class-map match-all TELNET
match protocol telnet
class-map match-all RTP_VOIP
match ip dscp ef
class-map match-all TELNET_HOST130
match access-group 100
as it shown above we matched the traffic based on the specified requirements above ( for end to end QOS you need to make sue that your end point or the switch send the traffic with the appropriate DSCP marking or you can use port numbers to match traffic with ACLs)
after we have our traffic class maps created now we need to create a policy to give the traffic the required bandwidth and QOS treatment in the case of interface congestion, this will be achieved by using policy maps:
But before we see the configurations of the policy map lets review the VOIP RTP requirement above, the requirement need VOIP traffic to have a prioritization and traffic guaranteed as 30 % of the WAN link bandwidth and also at all times
this imply that we need to give a guaranteed bandwidth of 30 % from the 1Mbps and also this need to be serviced first in the case of congestion
this can be archived by using low latency queuing mechanism LLQ, but LLQ will NOT police or limit this class bandwidth in the case of NO congestion.
to limit the VOIP RTP traffic at all times to 30 % of the WAN link we can use a nested policy map under the class map configuration this is also called Hierarchal Quality of service HQOS
policy-map VOIP
class class-default
police cir 300000 --- 1Mb = 100000 x 0.3 = 300000 bps
for the routing traffic
the requirements:
routing traffic by default marked as CS 6 and as stated in the requirements above traffic with CS 6 need to be configured with WRED
please note that WRED to be configured under class default or any cither class you need to configure either bandwidth command or enable fair queuing for that class
min CS 6 queue dropping threshold 30 max 40 dropping probability 25 % = 1/4
class class-default
fair-queue
random-detect
random-detect precedence 6 30 40 4
the outbound policy config:
policy-map P1
class RTP_VOIP
priority percent 30
service-policy VOIP
class VOIP_SIG
bandwidth percent 8
class TELNET_HOST130
bandwidth percent 5
class TELNET
bandwidth percent 3
class class-default
fair-queue
random-detect
random-detect precedence 6 30 40 4
now we nned to apply the above policy map under the WAN interface in the OUTBOUND direction
interface FastEthernet1/0
service-policy output P1
verification:
WAN_rtr#show policy-map interface fastEthernet 1/0
FastEthernet1/0
Service-policy output: P1
Class-map: RTP_VOIP (match-all)
4 packets, 456 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 30 (%)
Bandwidth 30000 (kbps) Burst 750000 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Service-policy : VOIP
Class-map: class-default (match-any)
4 packets, 456 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
police:
cir 300000 bps, bc 9375 bytes
conformed 4 packets, 456 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: VOIP_SIG (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp cs3 (24)
Queueing
Output Queue: Conversation 265
Bandwidth 8 (%)
Bandwidth 8000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET_HOST130 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100
Queueing
Output Queue: Conversation 266
Bandwidth 5 (%)
Bandwidth 5000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol telnet
Queueing
Output Queue: Conversation 267
Bandwidth 3 (%)
Bandwidth 3000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
375 packets, 37786 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 347/34921 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 30 40 1/10
6 0/0 0/0 0/0 30 40 1/4
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
as it obvious from the above show command we have the bandwidth allocated incorrectly by our policy map !!!
for example the VOIP allocated under the LLQ calss 30000 Kbps which is 30 Mbps while it supposed to be 300 Kbps
same for other classes !!
this is because we are using the default interface bandwidth in our case fastethernet with 100Mbos and the policy map reference the interface bandwidth to allocate the bandwidth and also to consider the interface congested or not,
lets change the interface bandwidth to 1 M bps and see the difference
interface FastEthernet1/0
bandwidth 1000
WAN_rtr#show policy-map interface fastEthernet 1/0
FastEthernet1/0
Service-policy output: P1
Class-map: RTP_VOIP (match-all)
1569 packets, 1051356 bytes
5 minute offered rate 5000 bps, drop rate 0 bps
Match: ip dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 30 (%)
Bandwidth 300 (kbps) Burst 7500 (Bytes)
(pkts matched/bytes matched) 3/402
(total drops/bytes drops) 0/0
Service-policy : VOIP
Class-map: class-default (match-any)
1569 packets, 1051356 bytes
5 minute offered rate 5000 bps, drop rate 0 bps
Match: any
police:
cir 300000 bps, bc 9375 bytes
conformed 1011 packets, 318144 bytes; actions:
transmit
exceeded 558 packets, 733212 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: VOIP_SIG (match-all)
30 packets, 3420 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp cs3 (24)
Queueing
Output Queue: Conversation 265
Bandwidth 8 (%)
Bandwidth 80 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET_HOST130 (match-all)
23 packets, 1283 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100
Queueing
Output Queue: Conversation 266
Bandwidth 5 (%)
Bandwidth 50 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET (match-all)
22 packets, 1229 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol telnet
Queueing
Output Queue: Conversation 267
Bandwidth 3 (%)
Bandwidth 30 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
899 packets, 323243 bytes
5 minute offered rate 2000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 55/5653 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 30 40 1/10
6 428/275592 0/0 0/0 30 40 1/4
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
now everything is working as expected and the bandwidth allocation is as required
now lets remove our policy map P1 also we put the bandwidth of the Fa0/1 to tdefault vhe alue which is 100Mbps
int fa1/0
no service-policy output P1
no bandwidth 1000
we can achieve the same result as we did above but without changing the interface bandwidth, this time we will use HQOS with a shaper
we are going to create a parent policy and shape all traffic for that policy to 1Mb and then we apply our policy map P1 under it
policy-map P2
class class-default
shape average 1000000
service-policy P1
interface FastEthernet1/0
service-policy output P2
verification:
WAN_rtr#show int fa1/0 | include BW
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
WAN_rtr#show policy-map interface fastEthernet 1/0
FastEthernet1/0
Service-policy output: P2
Class-map: class-default (match-any)
218 packets, 238044 bytes
5 minute offered rate 8000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
1000000/1000000 6250 25000 25000 25 3125
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 213 231474 24 31536 no
Service-policy : P1
Class-map: RTP_VOIP (match-all)
102 packets, 134028 bytes
5 minute offered rate 4000 bps, drop rate 0 bps
Match: ip dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 30 (%)
Bandwidth 300 (kbps) Burst 7500 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Service-policy : VOIP
Class-map: class-default (match-any)
102 packets, 134028 bytes
5 minute offered rate 4000 bps, drop rate 0 bps
Match: any
police:
cir 300000 bps, bc 9375 bytes
conformed 97 packets, 127458 bytes; actions:
transmit
exceeded 5 packets, 6570 bytes; actions:
drop
conformed 4000 bps, exceed 0 bps
Class-map: VOIP_SIG (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp cs3 (24)
Queueing
Output Queue: Conversation 73
Bandwidth 8 (%)
Bandwidth 80 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET_HOST130 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100
Queueing
Output Queue: Conversation 74
Bandwidth 5 (%)
Bandwidth 50 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol telnet
Queueing
Output Queue: Conversation 75
Bandwidth 3 (%)
Bandwidth 30 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
116 packets, 104016 bytes
5 minute offered rate 4000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 40/4152 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 30 40 1/10
6 76/99864 0/0 0/0 30 40 1/4
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
Although the interface bandwidth is 100M but our policy now allocating bandwidth percentage based on 1M this is because it is a nested policy under a shaped policy with 1Mbp
Note:
I intended to put multiple ways of QOS configurations such as matching with and without ACL using a class map, shaping and policing to cover most of the common simple and standard methods used in configuring QOS
Thank you
Marwan Alshawi
Excellent work, Marawan.
Thx.
mohAmed
I see that in your second example you shaped the traffic first, but for my understanding this will shape all traffic including the RTP voip traffic. This will introduce unnecessary jitter and if your WAN link will not be able to handle the proposed 1Mbit, possibly drop VoIP packets. Shouldn't there be a priority queue for VoIP first and then shape the remaining BW??
Patrick
With hierarchal QOS
There will be two QOS policies
The first policy used above t shape the entire link to the amount allocated to that interface
Lets say the interface 100Mb and you shape it to 10 Mb
This shaping is just to make sure you not seeding to the other end more traffic than the amount allocated to that interface otherwise this extra traffic will be dropped in the other end
One more important thing is that when you shape it to 10Mb and the interface get congested the QOS policy will get kicked and the policy maps will start prioritize traffic as configured
In other words the first policy just to shape the interface to the actual bandwidth
The second policy ( sub policy ) will be used for LLQ.. etc
I understand absolutely what you are trying to do with this construct. I only want to clarify what happens when more traffic than the 10mb will arrive on that router. When you first shape all traffic and the shaper buffers the surplus traffic, all packets (incl voice) will be delayed to be transferred later. If the stream will continue at a higher input rate than 10mb, the shaper possibly will be exhausted and starts dropping packets. Because the shaper is first, all kinds of packets will be dropped before we look for the second policy, which only prioritizes the traffic which will make it through the shaper. How can you take the voice traffic out of the shaping process, so that we shape only data, because we should neither shape nor drop voip?
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 should happen is the shaper, for the packets it delays, should push them into the child policy's queues and also dequeue from those queues as it transmits packets. If this is done, LLQ should be not be dropped if its traffic meets its bandwidth restraints regardless of other traffic's bandwidth offering. In other words the parent policy's shaper should act much like a physical interface would with a bound single level CBWFQ policy.
However, reason I use the word should, I've seen some platform/IOS combinations, which support showing active flow queues, appear to indicate that a parent policy shaper might continue to maintain it's own set of queues in addition to the child policy queues. Before HQF, CBWFQ embedded shapers, alone, acted like an interface's GTS actually queued using their own WFQ. For these, it seemed child LLQ packets were delayed a little more than I thought they should be, here too, perhaps similar to an actual interface's FIFO TX ring queue that's has an attached CBWFQ policy. The two differences being, the shaper using WFQ instead of FIFO and often the platform not allowing any adjustment to the shaper's WFQ overall queue limit or per flow queue limit. Regardless, in practice, beyond perhaps a little more latency and jitter than expected, I've not seen it adversely impact end-to-end VoIP service requirements.
If you find a case where Cisco's actual implementation does adversely impact the service requirements of LLQ traffic, you can define a LLQ in the parent policy, bypassing the shaper, add an explicit policer to the parent LLQ and reduce the shaper's bandwidth allocation by the amount provided the parent's LLQ policer. The disadvantage of this, unused LLQ bandwidth will not be available to the child policy traffic.
What if you have subinterface off the FA and want to limit the bandwidth on the subint. For example:
Int fa 1/0.1
bandwidth 10000
Do you still keep the main interface FA1/0 with "no bandwidth" or put in either "bandwidth 10000" also. Thanks
So, is this the entire outout with the second option?
Basically, P2 will shape the outbound to 1Mbps, and P1 will handle QoS once congestion occurs.
policy-map P1
class RTP_VOIP
priority percent 30
service-policy VOIP
class VOIP_SIG
bandwidth percent 8
class TELNET_HOST130
bandwidth percent 5
class TELNET
bandwidth percent 3
class class-default
fair-queue
random-detect
random-detect precedence 6 30 40 4
!
policy-map P2
class class-default
shape average 1000000
service-policy P1
!
interface FastEthernet1/0
service-policy output P2
!
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
Basically, what you have now is correct. However, you might want to decrease the shaper's Tc. It look like yours is an older version that defaults to 25 ms. To support VoIP, I would recommends 10 ms. This can be done (if supported by your IOS) by setting the shaper's 2nd parameter to 1/100 (?) of the first value.
Other "tweaks" you might consider: removing WRED from class-default (as you're already configured FQ), combining your 3 defined non-LLQ classes into one class with the bandwidth aggregated, using FQ in the other defined non-LLQ classes (feature only available in later HQF versions of IOS).
This is the config that we are testing in the lab.
Basically, we are handed off a 12Mbps circuit from the carrier. Under congestion, SSH would be guaranteed 50% of the bandwidth. While FTP would get 50% of the remaining bandwidth (3Mbps), WWW would get 25% of the remaining bandwidth (1.5Mbps), and everything else would get 25% of the remaining bandwidth (1.5Mbps).
Does this look right? Thank you.
class-map match-any SSH
match protocol ssh
class-map match-any WWW
match protocol http
class-map match-any FTP
match protocol ftp
!
policy-map QOS-OUT
class SSH
priority percent 50
class WWW
bandwidth remaining percent 25
class FTP
bandwidth remaining percent 50
class class-default
bandwidth remaining percent 25
!
policy-map 12MBPS
class class-default
shape average 12000000
service-policy QOS-OUT
!
interface FastEthernet1/0
service-policy output 12MBPS
!
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
"Does this look right?"
Well, depends on what your goals are. It should "guarantee" bandwidth as you describe. That said, normally you only use LLQ for real-time traffic, which SSH really isn't. (Also for SSH, it will match against SCP. [Something I overlooked years ago in one of my production policies.])
You might find just placing all your traffic into a class-default using fair-queue might work as well or better than the policy you've defined. (Depending on whether your version of IOS is pre-HQF, the shaper, alone, may use FQ.)
PS:
BTW, Cisco documentation is somewhat unclear whether all shapers include L2 overhead. If your does not, you may need to shape 5 to 15% slower than nomimal bandwidth to allow for L2 overhead.
it was a sample config with ssh, to simulate using a traffic generator and test the qos.
in the live environment, we adjusted the LLQ for sip, h323, etc ... and it works well!
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: