cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
593
Views
5
Helpful
1
Replies
Highlighted
Beginner

How can i configure QoS for solve this problem?

Hello everyone, i am studying QoS for solve a problem in the enterprise that i work. I read that first i need to mark the traffic the most close of the origin so next what? should i go to the other nodes and configure the policies based on the marks. For example if I mark the traffic based on the ip address and i assign the mark of AF21 how can i use this next? is it necessary to go to all equipments and configure the qos based on the mark or this is automaticaly? 

 

The problem is that the next week will be introduce traffic for a new service for the enterprise so we hope to this traffic overwhelm the bandwidth of the branches. we are focus to solve this in the core of the network apllying qos because there are a lot of branches and we do not want to apply the configuration in all these but i don know if this is possible. Another option that i see posible is to mark the new traffic how scavenger because this is not important for the business.

 I would greatly appreciate your advice.

I am not sure if this is the correct label for this subject.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
VIP Expert

Yes, ToS might be set as close to origin as possible, including on the source, itself, but there's more to it than that.

For starters, a ToS marking, like your mention of DSCP AF21, is just a "shortcut" for analysis of a packet's QoS needs. It may, or may not, properly represent the service needs of the marked packet. "Incorrect" markings might be accidentally wrong, intentionally wrong, or just not aligned with your usage of ToS markings. So, when entering your "trust" boundary (the boundary where packets pass into your control/management of ToS), the ToS marking often should be checked to insure that it truly represents the proper classification for that traffic. Lastly, ToS markings are subject to rewrite. This might be done for various reasons, on devices within your management. (It also might be done on network devices under someone else's management.) Again, remember ToS is a "shortcut" to allow a network device to easily/quickly classify a packet's QoS needs, but such classification can be done without using ToS.

Most network devices, by default, don't provide any QoS treatment until configured to do so. So, yes, you often need to go to all your devices and insure they have a QoS policy that meets your service needs. Two things to assist you in dealing with the "burden" of doing this, many Cisco devices have an "auto-QoS" feature, where one command will configure a more, or less, complex QoS policy that Cisco believes will deal with most QoS needs. (Of course, Cisco's auto-QoS policy might not be suitable for your QoS needs, and even if it is, you need to understand their policy to use it optimally.) Second, QoS is only really needed at bottlenecks/choke-points that have congestion that's adverse to service needs. LAN to WAN (i.e. egress WAN ports) is usually a "poster child" for such.

In your case, without knowing more about your devices, topology and service needs, I cannot make detailed suggestions. However, if you're using routers, not switches, for your WAN connections, and the WAN port's physical bandwidth does not have some WAN provider lessor bandwidth limit, the following QoS policy often works very well for multiple needs.

service-policy GeneralQoS
class class-default
fair-queue

interface !wan
service-policy output GeneralQoS

You mention the possibility of marking traffic as "scavenger". That's fine, but then you need a policy that does "something" about scavenger traffic. (I don't recall Cisco's auto-QoS policy supporting scavenger usage.)

The following policy, might support scavenger traffic, and a bit more too.

service-policy GenericQoS
class real-time !might be used for VoIP bearer traffic, etc.
priority percent 35 !Cisco recommends only up to 1/3, but I found up to 40% works pretty well too
class foreground !used for highly important, light bandwidth flows, like VoIP control traffic
bandwidth remaining percent 81
fair-queue !possibly not needed, but good insurance if one flows wants "too much" bandwidth
class background !can be used for scavenger or other bulk data flows
bandwidth remaining percent 1
fair-queue !also possibly not needed, but avoids some other issues with multiple heavy bandwidth usage flows
class class-default !your "BE" class, which should really contain all but traffic you direct to the other classes
fair-queue !highly recommended for this class

bandwidth remaining percent 9

The above requires class-maps to match traffic to other than the class-default, e.g.

class-map match-any real-time
match ip dscp ef

class-map match-any background
match protocol ftp

Feel free to ask additional questions.

View solution in original post

1 REPLY 1
Highlighted
VIP Expert

Yes, ToS might be set as close to origin as possible, including on the source, itself, but there's more to it than that.

For starters, a ToS marking, like your mention of DSCP AF21, is just a "shortcut" for analysis of a packet's QoS needs. It may, or may not, properly represent the service needs of the marked packet. "Incorrect" markings might be accidentally wrong, intentionally wrong, or just not aligned with your usage of ToS markings. So, when entering your "trust" boundary (the boundary where packets pass into your control/management of ToS), the ToS marking often should be checked to insure that it truly represents the proper classification for that traffic. Lastly, ToS markings are subject to rewrite. This might be done for various reasons, on devices within your management. (It also might be done on network devices under someone else's management.) Again, remember ToS is a "shortcut" to allow a network device to easily/quickly classify a packet's QoS needs, but such classification can be done without using ToS.

Most network devices, by default, don't provide any QoS treatment until configured to do so. So, yes, you often need to go to all your devices and insure they have a QoS policy that meets your service needs. Two things to assist you in dealing with the "burden" of doing this, many Cisco devices have an "auto-QoS" feature, where one command will configure a more, or less, complex QoS policy that Cisco believes will deal with most QoS needs. (Of course, Cisco's auto-QoS policy might not be suitable for your QoS needs, and even if it is, you need to understand their policy to use it optimally.) Second, QoS is only really needed at bottlenecks/choke-points that have congestion that's adverse to service needs. LAN to WAN (i.e. egress WAN ports) is usually a "poster child" for such.

In your case, without knowing more about your devices, topology and service needs, I cannot make detailed suggestions. However, if you're using routers, not switches, for your WAN connections, and the WAN port's physical bandwidth does not have some WAN provider lessor bandwidth limit, the following QoS policy often works very well for multiple needs.

service-policy GeneralQoS
class class-default
fair-queue

interface !wan
service-policy output GeneralQoS

You mention the possibility of marking traffic as "scavenger". That's fine, but then you need a policy that does "something" about scavenger traffic. (I don't recall Cisco's auto-QoS policy supporting scavenger usage.)

The following policy, might support scavenger traffic, and a bit more too.

service-policy GenericQoS
class real-time !might be used for VoIP bearer traffic, etc.
priority percent 35 !Cisco recommends only up to 1/3, but I found up to 40% works pretty well too
class foreground !used for highly important, light bandwidth flows, like VoIP control traffic
bandwidth remaining percent 81
fair-queue !possibly not needed, but good insurance if one flows wants "too much" bandwidth
class background !can be used for scavenger or other bulk data flows
bandwidth remaining percent 1
fair-queue !also possibly not needed, but avoids some other issues with multiple heavy bandwidth usage flows
class class-default !your "BE" class, which should really contain all but traffic you direct to the other classes
fair-queue !highly recommended for this class

bandwidth remaining percent 9

The above requires class-maps to match traffic to other than the class-default, e.g.

class-map match-any real-time
match ip dscp ef

class-map match-any background
match protocol ftp

Feel free to ask additional questions.

View solution in original post

Content for Community-Ad