I'm looking at configuring QoS at one of my remote sites. So far I have only labbed it up in GNS3. I'm trying to learn QoS since I have never configured it before. I would like to create a QoS policy that will prefer outbound traffic from one subnet(office) over the other(guest). This what I have so far:
ip access-list extended Office-Traffic
permit ip 10.31.136.0 0.0.0.255 any
ip access-list extended Guest-Traffic
permit ip any any
class-map match-any MATCHOFFICE
match access-group name Office-Traffic
class-map match-any MATCHGUEST
match access-group name Guest-Traffic
policy-map Office-QoS
class MATCHOFFICE
priority percent 60
class MATCHGUEST
bandwidth remaining percent 90
int t1
qos pre-classify
int t2
qos pre-classify
int fa8
bandwidth 1500
service-policy output Office-QoS
This seems to be working in that when looking at the policy-map(show policy-map int fa8) I can see that the bandwidth is being separated correctly between the two classes of traffic - Office and Guest.
Problem - It seems like the Office traffic is protected by giving it a priority percent of 60 but it also looks like the Office traffic will not be able to use more than 60 percent of the bandwidth if needed. Is there a way to reserve 60 percent of the bandwidth and also use more than 60 percent of the bandwidth if needed?
You might find this helpful:
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html (http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html)
priority is hard-set. so no it will always be given 60%
If you want it to utilize the full link when available then set it as a CBWFQ as you have the guest.
So:
policy-map Office-QoS
class MATCHOFFICE
bandwidth percent 60
class MATCHGUEST
bandwidth remaining percent 90
Honestly QoS is such a jacked up subject. When you think you start to understand whats going on it shifts on you.
Rule of thumb: if you ever have to get complicated with QoS you are doing something wrong.
or reverse it and set the guest with a priority and lock em in.
BTW using ACLs or any type of marking technique on the router is really going to tax the router and degrade performance. You should really mark the traffic as close to the source (access layer) as possible and base your policies on the router off the markings. But real life and such....
1.) What you really want is this since you're really after rate limiting per tunnel from the HQ (from my reading of it?) btw That1guy, you may remember this from a INE TS question LOL
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-per-tunnel-qos.html (http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-per-tunnel-qos.html)
2.) Speaking in basic QoS terms, unfortunately you're all over the shop.
- In principle the standard design is always to mark ingress (i.e. classify traffic with a DSCP marking), then you configure egress queues matching purely on markings already set. Combining them into one egress map is a lot less flexible and gets much messier.
- Priority queue has a built in policer. Always. Use 'bandwidth'.
- Since you're putting the policy map on a Fa0/0, regardless of your bandwidth command the config will not actually QoS properly until there is contention experienced i.e. it reaches 100M (unless of course your carrier shapes immediately - but if you were connecting to another 100M LAN port for example). The proper way to do this is to have an overall egress policy shaping to the bandwidth your link really is, then call a sub-policy with the queueing. This is called Hierarchical Queueing Framework
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/QoSIntro.html#pgfId-46844 (http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/QoSIntro.html#pgfId-46844)
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_hrhqf/configuration/12-4t/qos-hrhqf-12-4t-book/qos-hrhqf.html (http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_hrhqf/configuration/12-4t/qos-hrhqf-12-4t-book/qos-hrhqf.html)
http://networkengineering.stackexchange.com/questions/638/what-is-the-5-level-qos-model-through-config-example (http://networkengineering.stackexchange.com/questions/638/what-is-the-5-level-qos-model-through-config-example)
Also something to think about is to match the Guest traffic by the subnet if you are going to do it that way. I like to leave my any any matches for the default-class and make it scavenger with super low bandwidth so that if something unknown is out there I can get a complaint that it is really slow and maintain control of the network. But you should find plenty about that in the QoS SRND that wintermute000 linked for you. That is an excellent doc to keep handy.
Thanks for all the replies and the links. I have some reading to do ;)
I would do something more along the line of this
policy-map Office-QoS
class MATCHOFFICE
bandwidth percent 60
class MATCHGUEST
bandwidth remaining percent 90
The priority means that if a packet from that section comes in it goes out 1st no matter what, it also says it can't go over that no matter what. The main reason why is priority is normally used for VOIP, now imagine you have a little of the pipe unused that you can extend that VOIP into so you do, and the pipe is fully used, now the Guest starts to pick-up, do you A) not give guest anything, or B) kill your voice traffic? Neither of those are good, and that's why priority works the way it does.
The way it's setup above (I think) either class can take up however much of the traffic they want as long as the pipe is free, but the Office is guaranteed 60% of the bandwidth if it wants it, and the guest is guaranteed 36% of the bandwidth if it wants it.
Quote from: dlots on November 02, 2015, 12:48:53 PM
I would do something more along the line of this
policy-map Office-QoS
class MATCHOFFICE
bandwidth percent 60
class MATCHGUEST
bandwidth remaining percent 90
The priority means that if a packet from that section comes in it goes out 1st no matter what, it also says it can't go over that no matter what. The main reason why is priority is normally used for VOIP, now imagine you have a little of the pipe unused that you can extend that VOIP into so you do, and the pipe is fully used, now the Guest starts to pick-up, do you A) not give guest anything, or B) kill your voice traffic? Neither of those are good, and that's why priority works the way it does.
The way it's setup above (I think) either class can take up however much of the traffic they want as long as the pipe is free, but the Office is guaranteed 60% of the bandwidth if it wants it, and the guest is guaranteed 36% of the bandwidth if it wants it.
You are correct. Another thing worth noting is, you really do not want to prefer subnets, or networks unless for specific purposes. Normally you want to tag protocols{RTP,PCoIP,ICA}/DSCP{EF/AF41} values.
When configuring QoS for a company you need to figure out first what is your company running, and what is important. Do you have video? A plan for video? VoIP phones? Certain applications that are important? Put these questions in a document, find out the business needs, and then scope your QoS accordingly. Most importantly. KEEP IT SIMPLE.
from reading OP's post, I do believe per tunnel QOS is what he's after.
Quote from: wintermute000 on November 05, 2015, 11:01:53 PM
from reading OP's post, I do believe per tunnel QOS is what he's after.
initially yes, but he should first figure out those answers before implementing QoS and then having to completely overhaul it later. It can become a pain in the you know what.
Lynk - I understand your point but I'm more concerned about giving one subnet preference over the other. As long as the corp subnet is given priority over the guest I'm happy ;).
Notably I might look at marking your traffic as close to the source as possable, then matching the markings, that way you only have to do the processor intensive task of matching the traffic ACLs once as opposed to every hop.
Quote from: SofaKing on November 06, 2015, 11:34:05 AM
Lynk - I understand your point but I'm more concerned about giving one subnet preference over the other. As long as the corp subnet is given priority over the guest I'm happy ;).
how are you interconnecting your sites? VPN? If so.. you can remove the QoS option right off the table. QoS needs to be end-to-end.
You might want to look at the document I attached.... Per tunnel qos over dmvpn is very much a thing