Custom QoS Policy Check Please

Answered Question
Apr 17th, 2008

Greetings, im putting together a QoS policy to be applied to CPE routers on an MPLS network with a single hub site and multiple spoke sites.

Our provider uses the 4 Class model and supports both IPP and DSCP, These are referred to as Gold (IPP 5) Silver (IPP 4) Bronze (IPP 2) and Default (IPP 0) ive used AutoQos in the past but thought about giving a manual config a go, could someone clarify if im heading in the right direction?

The policy will be applied on the MPLS facing interface going outbound of each CPE router.

!

class-map match-any REALTIME_GOLD

match ip dscp ef (VOIP)

class-map match-any CRITICAL_SILVER

match ip dscp af31 (Call Signalling)

match ip dscp cs3 (Call Signalling)

match ip dscp cs6 (IP Routing BGP)

match ip dscp af21 (Unix Database Access)

class-map match-any BEST_EFFORT_BRONZE

match ip dscp 0 (Web Traffic/Email/Pritning)

class-map match-any SCAVENGER

match ip dscp CS1 (P2P/Misc)

!

policy-map CUSTOMER_CPE

class REALTIME_GOLD

priority percent 50

class CRITICAL_SILVER

bandwidth percent 24

random-detect dscp-based

class BEST_EFFORT_BRONZE

bandwidth percent 25

random-detect dscp-based

class SCAVENGER

bandwidth percent 1

I haven't included access list to define traffic yet but any comments would be appreciated.

Regards

I have this problem too.
0 votes
Correct Answer by Joseph W. Doherty about 8 years 7 months ago

Unclear the meaning of the various QoS bandwidth allocations, less than the line's bandwidth, unless this is for real-time traffic. Also unclear the 6 Mbps bearer over the 10 Mbps, unless this is a 10 Mbps Ethernet handoff but traffic above 6 Mbps is rate limited or shaped. (Important to know, also whether it applies both for ingress and egress, since your spoke sites tally 8 Mbps.)

You written you have a hub and spoke. Does this mean there should not be traffic between spoke sites, or there can not be traffic between spoke sites? If traffic is only between the hub and spokes, and you don't have that many spokes, you could configure QoS on the hub unique for each spoke and not rely on the provider's QoS model.

In my prior note, I asked whether you could verify bandwidth allocations for the provider's non-real-time classes. Some models use classes of nearly the same bandwidths, some with very different allocations. For either, if CBWFQ is being used, it's important to understand the bandwidth allocation define a minimum and sets the ratios between classes.

If for instance, the bandwidths were something like Silver 40%, Bronze 20% and BE 10%, the ratio of 4:2:1 is maintained if the classes want additional bandwidth and it's available. If both Silver and BE wanted all the bandwidth (and there's no Bronze traffic), Silver would obtain 80% and BE 20%. If Silver only used 50% (again no Bronze), and BE wanted all the bandwidth, it would get the other 50%. So, when choosing what classes to place different types of traffic in, not only determine the minimum that traffic needs, but whether it should obtain more available bandwidth than other classes.

Know how you want to use the classes, then determine how to mark the traffic to be placed into the classes.

Within your network, if possible, you can classify and mark traffic on the first network device and later, if you chose, use those marking for congestion management. On your CE router, it's often possible to combine the classification and congestion management at the same time.

An example of separate classification and congestion management on CE.

(pseudo code)

class-map match-any classifyGold

match dscp EF

class-map match-any classifySilver

match protocol citrix

match protocol telnet

class-map match-any classifyScavenger

match protocol ftp

policy-map classifyMyTraffic

class classifyGold

set dscp ef

class classifySilver

set dscp cs3

class classifyScavenger

set dscp af13

class class-default

set dscp be

class match-any Gold

match dscp ef

class match-any Silver

match dscp cs3

class match-any Scavenger

match dscp af31

policy-map toMPLS

class Gold

priority percent 40

set ip precedence 5

class Silver

bandwidth remaining percent ##

set ip precedence 4

class Scavenger

bandwidth remaining percent 1

set ip precedence 2

class class-default

set ip precedence 0

fastethernet 1

service policy input classifyMyTraffic

serial 1

service policy output toMPLS

An example of combined classification and congestion management on CE.

(pseudo code)

class match-any Gold

match dscp EF

class match-any Silver

match protocol citrix

match protocol telnet

class match-any Scavenger

match protocol ftp

policy-map toMPLS

class Gold

priority percent 40

set ip precedence 5

class Silver

bandwidth remaining percent ##

set ip precedence 4

class Scavenger

bandwidth remaining percent 1

set ip precedence 2

class class-default

set ip precedence 0

serial 1

service policy output toMPLS

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Joseph W. Doherty Fri, 04/18/2008 - 10:46

Within your policy, silver class is matching against different IPP and DSCP tags, which is okay, but unless you remark, the original tags will be treated by the MPLS provider differently. For instance, your Silver class is matching against af31, cs3, cs6 and af21, but you wrote the provider considers silver IPP 4. The solution here might be to just add a "set DSCP cs4" on your outbound policy within the Silver class.

Although all your percentages add up to 100, normally 25% is set aside. You can adjust the set aside (which I recommend against), you can adjust your percentages, or if IOS is new enough, you can use "remaining percent".

You didn't note what bandwidth percentages your provider allocates for the different classes. You also didn't note what the MPLS provider will do with a CS1 packet or other unknown ToS value.

Realize within a "typical" IP over MPLS network, you can manage bandwidth pretty much as you desire upon MPLS ingress. For MPLS egress, you'll need to work within the constraints of the provider's QoS model.

For instance, you have defined a Scavenger class with an allocation of 1%. That's fine for leaving your site. Scavenger traffic is at the bottom of the outbound queuing priority. However, as defined, spoke sites, if there's no other more important traffic, would fill their outbound link with all Scavenger traffic. When it gets to the hub site's MPLS egress, the CS1 goes where? Good chance the provider will treat an unknown making as BE. But that will mix Scavenger traffic with other spoke site traffic that is marked BE. Even if you change the markings to align with the provider's, do they support a Scavenger class of only 1%?

Within both your Silver and Bronze classes, you're using WRED. This is a very difficult technology to configure correctly for its intended purpose, and the default settings don't work very well for the intended purpose (from my experience). The default settings are very nice for getting packets counts with different packet markings. Beware of drops within the WRED stats, unless you understand how to adjust WRED for drop management.

In recap, in principle you're policy makes sense but you'll really need to fully understand what the MPLS provider's QoS model is; markings to classes, class bandwidth allocations, drop processing for classes. Understand and leverage their model, for both MPLS ingress and egress. Reserve additional MPLS ingress modifications as you learn more about QoS and use such modifications so that they still work with the MPLS provider's QoS model.

exonetinf1nity Mon, 04/21/2008 - 02:41

Brilliant reply, thank you, i have now managed to get my hands on an updated document provided by the ISP indicating updated values for the marking of traffic at the CPE edge which makes things a little clearer.

exonetinf1nity Mon, 04/21/2008 - 02:50

Please also find attached the updated ISP document defining new DSCP values along with traditional IPP values and which class they relate too.

Looking over my customer requirements and the services that they run over the WAN i think IPP may be effective but wouldnt want to shoot myself in the foot

Ive also done some editing to the original over the weekend to match the DSCP values with IPP. Your help is much appreciated.

IPP Config:

class-map match-any REALTIME_GOLD

match ip dscp cs5 (voip/signalling)

class-map match-any CRITICAL_SILVER

match ip dscp cs4 (Unix Database Access, BGP)

class-map match-any BEST_EFFORT_BRONZE

match ip dscp cs2 (Web Traffic/Email/Pritning)

policy-map CUSTOMER_CPE

class REALTIME_GOLD

priority percent 30

class CRITICAL_SILVER

bandwidth percent 25

random-detect dscp-based

class BEST_EFFORT_BRONZE

bandwidth percent 20

random-detect dscp-based

class class-default

drop

DSCP Config:

class-map match-any REALTIME_GOLD

match ip dscp EF (voip/signalling)

class-map match-any CRITICAL_SILVER

match ip dscp AF41 (Unix Database Access, BGP)

class-map match-any BEST_EFFORT_BRONZE

match ip dscp AF21 (Web Traffic/Email/Pritning)

policy-map CUSTOMER_CPE

class REALTIME_GOLD

priority percent 30

class CRITICAL_SILVER

bandwidth percent 20

random-detect dscp-based

class BEST_EFFORT_BRONZE

bandwidth percent 20

random-detect dscp-based

class class-default

bandwidth percent 5

random-detect

Regards

Joseph W. Doherty Mon, 04/21/2008 - 03:39

Perhaps there's some confusion between classification of traffic and marking it for the provider's QoS model. I'm pressed for time this morning; I'll try to clarify either this evening or tomorrow.

In the meantime, see if you can verify that you can specify the bandwidth allocations for the different classes the provider offers (appears to be true based on your attachment). Also, whether the provider can provide different drop methods or thresholds within a class based on markings (not mentioned within the document).

exonetinf1nity Mon, 04/21/2008 - 05:10

We are currently looking at one hub site and 6 spoke sites.

Ive been quoted the following from the ISP, but not being familiar with MPLS im unsure how the QoS reservations reflect on the CPE configs

Hub Site

10Mb Leased Line, 6Mb Bearer, 1Mb QoS

Spoke Site A

2Mb Leased Line, 126Kbps QoS

Spoke Site B

2Mb Leased Line, 126Kbps QoS

Spoke Site C

2Mb Leased Line, 126Kbps QoS

Spoke Site D

1Mb SDSL, 126Kbps QoS

Spoke Site E

1Mb SDSL, 126Kbps QoS

Thank you for your time on this matter.

Regards

Correct Answer
Joseph W. Doherty Tue, 04/22/2008 - 07:04

Unclear the meaning of the various QoS bandwidth allocations, less than the line's bandwidth, unless this is for real-time traffic. Also unclear the 6 Mbps bearer over the 10 Mbps, unless this is a 10 Mbps Ethernet handoff but traffic above 6 Mbps is rate limited or shaped. (Important to know, also whether it applies both for ingress and egress, since your spoke sites tally 8 Mbps.)

You written you have a hub and spoke. Does this mean there should not be traffic between spoke sites, or there can not be traffic between spoke sites? If traffic is only between the hub and spokes, and you don't have that many spokes, you could configure QoS on the hub unique for each spoke and not rely on the provider's QoS model.

In my prior note, I asked whether you could verify bandwidth allocations for the provider's non-real-time classes. Some models use classes of nearly the same bandwidths, some with very different allocations. For either, if CBWFQ is being used, it's important to understand the bandwidth allocation define a minimum and sets the ratios between classes.

If for instance, the bandwidths were something like Silver 40%, Bronze 20% and BE 10%, the ratio of 4:2:1 is maintained if the classes want additional bandwidth and it's available. If both Silver and BE wanted all the bandwidth (and there's no Bronze traffic), Silver would obtain 80% and BE 20%. If Silver only used 50% (again no Bronze), and BE wanted all the bandwidth, it would get the other 50%. So, when choosing what classes to place different types of traffic in, not only determine the minimum that traffic needs, but whether it should obtain more available bandwidth than other classes.

Know how you want to use the classes, then determine how to mark the traffic to be placed into the classes.

Within your network, if possible, you can classify and mark traffic on the first network device and later, if you chose, use those marking for congestion management. On your CE router, it's often possible to combine the classification and congestion management at the same time.

An example of separate classification and congestion management on CE.

(pseudo code)

class-map match-any classifyGold

match dscp EF

class-map match-any classifySilver

match protocol citrix

match protocol telnet

class-map match-any classifyScavenger

match protocol ftp

policy-map classifyMyTraffic

class classifyGold

set dscp ef

class classifySilver

set dscp cs3

class classifyScavenger

set dscp af13

class class-default

set dscp be

class match-any Gold

match dscp ef

class match-any Silver

match dscp cs3

class match-any Scavenger

match dscp af31

policy-map toMPLS

class Gold

priority percent 40

set ip precedence 5

class Silver

bandwidth remaining percent ##

set ip precedence 4

class Scavenger

bandwidth remaining percent 1

set ip precedence 2

class class-default

set ip precedence 0

fastethernet 1

service policy input classifyMyTraffic

serial 1

service policy output toMPLS

An example of combined classification and congestion management on CE.

(pseudo code)

class match-any Gold

match dscp EF

class match-any Silver

match protocol citrix

match protocol telnet

class match-any Scavenger

match protocol ftp

policy-map toMPLS

class Gold

priority percent 40

set ip precedence 5

class Silver

bandwidth remaining percent ##

set ip precedence 4

class Scavenger

bandwidth remaining percent 1

set ip precedence 2

class class-default

set ip precedence 0

serial 1

service policy output toMPLS

exonetinf1nity Fri, 04/25/2008 - 03:43

Thank very much for your help, it has certainly opened my eyes for both MPLS and QoS.

Actions

This Discussion