topic MPLS QOS in Switching

MPLS QOS

hzarringhalam — Thu, 07 Mar 2019 09:46:45 GMT

Hi,

My customer is looking for the best practice of QoS over it's MPLS network.

They have AF configured by service provider on the MPLS and nothing else.

I went through some Cisco document, but am not sure which configuration is the best for them.

Do I need to configure the QoS for ingress and egress points or egress should be ok?

I do not want to go with policing and simple class based with percentage configuration for the BW should be suffice.

Please let me know.

Thanks in advance,

Hamid

MPLS QOS

Collin Clark — Thu, 18 Aug 2011 19:53:15 GMT

Your design will be determined by the classes your ISP has provided. They typically have a few different service levels like Gold, Silver, and Bronze. An excellent design guide is located here-

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html

Re: MPLS QOS

hzarringhalam — Thu, 18 Aug 2011 22:44:11 GMT

Hi Collin,

Thanks a lot for the information and the link.

Best,

Hamid Zarringhalam

Re: MPLS QOS

Marwan ALshawi — Thu, 18 Aug 2011 23:58:39 GMT

Hi Hamid,

just to add to Collin's post,

first of all you need to identify your company needs in terms of traffic prioritizes and importance

for example do you have VOIP, video, critical applications such as citrix ..etc

then you can make the call which class should you go with before you discuss it with the ISP once you know your traffic needs then you can ask the ISP about the classes they can provide you as they are defer in terms of price and class type

for example if you have voice you will need to have a certain % of you link bandwidth to be allocated to the priority Queue with the MPLS SP network and you need to pay extra for that

about the configurations, normally you will need outbound toward the ISP QoS policy to shape, and priorities based on the agreed classes with the relevant marking, however if for any reason the traffic get remarked with the ISP network then you will need the inbound QoS policy mainly for marking the traffic back

HTH

pls rate the helpful posts

Re: MPLS QOS

Joseph W. Doherty — Fri, 19 Aug 2011 01:31:43 GMT

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

Generally, if a congestion point can adversely impact some of your traffic, you'll want "QoS" at that congestion point.

On a typical MPLS cloud, the congestion points are often at ingress and egress to the cloud.

For cloud egress, you usually select a QoS policy provided by the MPLS provider and then just mark your packets to take advantage of the provider's QoS policy.

For cloud ingress, you can mimic the MPLS provider's QoS policy or use something much more complex (depending on the capabilities of your equipment).

Re: MPLS QOS

hzarringhalam — Fri, 19 Aug 2011 03:55:05 GMT

Hi,

Thank you for your insights.

I was not sure where should I configure the QoS for MPLS traffic, now I can understand it better.

I would like to know what is the best practice recommendation regarding the percentage of Voice, Data and Signaling in QoS configuration.

And is it ok if I use Netflow Analyzer for finding the rate / percentage of different type of traffic and make my decision based on that?

Can you please advise if there is a better way or better application in the market for analyzing the traffic.

Thanks,

Hamid

MPLS QOS

Marwan ALshawi — Fri, 19 Aug 2011 05:16:31 GMT

Hi Hamid,

Cisco Recomendations the Voice priority Queue to be around 33%

however i work on several projects where they use only 10% because they have big pip

that mean you can use the netflow and find out how much voice and other type of traffic is utilizing over yourWAN link then you can make more realistic %

by the way signaling is something you need to consider but not worry about as much as VOIP mdeia/RTP

HTH

pls rate the helpful posts

Re: MPLS QOS

Joseph W. Doherty — Fri, 19 Aug 2011 09:45:50 GMT

Disclaimer

Liability Disclaimer

Posting

Actually bandwidth allocations for specific traffic types really depends on your traffic. You'll also likely find you're restricted to what the MPLS vendor might provide as QoS policy options.

That noted, a very generic policy could be something like about a third of bandwidth allocated for real-time, and remaining bandwidth split into foreground/background with ratios like 2:1 to 10:1, or with an additional scavenger class that gets minimum bandwidth reservation (for example 1%).

Foreground is used for "mission-critical" type traffic. Background for best effort. Scavenger is used for whatever is available bandwidth, such as non-time sensitive backups.

If you have traffic that requires a known and fixed amount of bandwidth, like video streaming, a class to provide it the bandwidth it needs (often its average plus about 10% works well).

PS:

If the platform supports it, NBAR can be used for traffic type analysis too.

Re: MPLS QOS

hzarringhalam — Fri, 19 Aug 2011 12:43:05 GMT

Thank you very much for all these helpful information.

One more area I have doubt about, and it is the QoS for incoming packets from MPLS to the LAN.

Is it something that should be my concern or does Service Provider take care of that?

Do I need to create a policy for incoming packets or just DSCP mapping should be enough or none of these?

Best,

Hamid

MPLS QOS

Marwan ALshawi — Fri, 19 Aug 2011 13:43:21 GMT

for inbound from MPLS SP, yo do not need policing or shaping as the traffic will come based on you allocated bandwidth/classes

however for re marking this is something that you need to make the call about it

for example if your SP support priority queue for VOIP with DSCP EF and you send your VOIP media traffic and signaling under this class to the SP as EF

then in the other end of your network you might need to re classify/mark the traffic based on its original marking

for example Voice RTP EF while signaling CS3 for example

this is just example about the idea where you might need re classifying and marking inbound form the SP

HTH

if helpful rate

Re: MPLS QOS

hzarringhalam — Fri, 19 Aug 2011 14:44:05 GMT

Thanks a lot for the information and your quick replies.

I see the way in front of me illuminated ☺

Very helpful!

Best,

Hamid

Re: MPLS QOS

hzarringhalam — Sat, 20 Aug 2011 01:15:06 GMT

I tried to rate your great help, but did not find the option for that.

Is there any link for that?

Best,

Hamid

Re: MPLS QOS

hzarringhalam — Sat, 20 Aug 2011 02:47:35 GMT

Sorry guys,

One more question,

it is about QoS for DMVPN.

Do I need to have per-tunnel QoS for DMVPN?

Can I configure regular policy based QoS and assign it to all?

Thanks,

Hamid

Re: MPLS QOS

Joseph W. Doherty — Sat, 20 Aug 2011 11:08:53 GMT

Disclaimer

Liability Disclaimer

Posting

If you're doing DMVPN and expect mesh traffic, you cannot do QoS effectively.

If your doing DMVPN and expect hub/spoke traffic, you can define a QoS policy on the tunnel. On the hub you'll likely want a class for each spoke. On both hub and spoke, especially the hub, you'll likely want to shape too.

Re: MPLS QOS

Marwan ALshawi — Sun, 21 Aug 2011 00:55:35 GMT

Hi hamid

Is the question ur customer uses DMVPN over the MPLA wan and you need the traffic inside the tunnel to be classified as per MPLs sp classes ? If yes the as Joseph mentioned apply the qos on the tunnel interface but it is not always hub and spoke as with DMVPN you can have the traffic to be spoke to spoke directly after network discovery

And you need to use the pre classify command in ur VPN config to copy to tos value of the marking outside the encapsulated packet for qos reasons

HTH

Pls rate the helpful posts

Sent from Cisco Technical Support iPhone App

Re: MPLS QOS

Joseph W. Doherty — Sun, 21 Aug 2011 10:47:24 GMT

Disclaimer

Liability Disclaimer

Posting

marwanshawi wrote:

And you need to use the pre classify command in ur VPN config to copy to tos value of the marking outside the encapsulated packet for qos reasons

My understanding of the pre-classify command, it's only needed if you want to examine more than tunnel packet's ToS byte for a service policy placed on the tunnel's physical egress interface (for the device sourcing the tunnel). (NB: pre-classify doesn't allow for all the packet inspection as you could do on the tunnel interface.)

MPLS QOS

Marwan ALshawi — Mon, 22 Aug 2011 00:12:46 GMT

The 'qos pre-classify' command configures the IOS to make a temporary copy of the IP packet before it is encapsulated or encrypted so that the service policy on the (egress) interface can do its classification based on the original (inner) IP packet fields rather than the encapsulating (outer) IP packet header

When we apply a QoS service policy to a tunnel interface, the service policy performs classification on the pre-tunnel IP packet (inner packet).
If we want to apply a QoS service policy to the physical interface, but we want classification to be performed based on the pre-tunnel IP packet, we must use the qos pre-classify command

The qos pre-classify command

When packets are encapsulated by tunnel or encryption headers, QoS features are unable to examine the original packet headers and correctly classify the packets. Packets traveling across the same tunnel have the same tunnel headers, so the packets are treated identically if the physical interface is congested. With the introduction of the Quality of Service for Virtual Private Networks (VPNs) feature, packets can now be classified before tunneling and encryption occur.

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml#qoscomm

HTH

Re: MPLS QOS

Joseph W. Doherty — Mon, 22 Aug 2011 09:05:51 GMT

Disclaimer

Liability Disclaimer

Posting

Correct, although note it only describes classification; i.e. it doesn't describe the original packet's ToS being copied.

For the latter, you need to look at a command that change the tunnel packet's ToS values, e.g.

tunnel tos

To configure the type of service (ToS) byte value for a tunnel interface, use the tunnel tos command in interface configuration mode. To use the payload ToS byte value (if payload protocol is IP) or 0, use the no form of this command.

tunnel tos tos-bytes

no tunnel tos

Syntax Description


tos-bytes	ToS byte value from 0 to 255 specified in the encapsulating IP header of a tunneled packet. The default value is 0.

Defaults

The default ToS byte value is the payload ToS byte value (if payload protocol is IP); otherwise, 0.

Command Modes

Interface configuration

Command History


Release	Modification
12.0(17)S	This command was introduced.
12.0(17)ST	This command was integrated into Cisco IOS Release 12.0(17)ST.
12.2(8)T	This command was integrated into Cisco IOS Release 12.2(8)T.
12.2(14)S	This command was integrated into Cisco IOS Release 12.2(14)S.

Usage Guidelines

If the tunnel tos command is not configured and the packet to be encapsulated is not an IP packet, the tunnel interface will use a default value of 0. If the tunnel tos command is not configured and the packet to be encapsulated is an IP packet, the tunnel interface will use the ToS byte value of the inner IP packet header.

MPLS QOS

Marwan ALshawi — Mon, 22 Aug 2011 10:21:55 GMT

Hi Joseph

thanks for these Details

again for the TOS/DSCP and marking with tunneling

When we apply a QoS service policy to a physical interface where one or more tunnels emanate, the service policy classifies IP packets based on the post-tunnel IP header fields.
When we apply a QoS service policy to a tunnel interface, the service policy performs classification on the pre-tunnel IP packet (inner packet).

classification and marking can be performed on the physical link if the GRE pre-classify feature is used,

if you apply a service policy to the physical interface the policy wil consider the traffic inside the tunnel as single flow
some solutions to this issue has been interduced by IOS to over come this limitation

- TOS refection which is the command you mentioned above that copy ToS byte to the tunnel header this helps to classify the traffic marking
between tunnel endpoints but some specific flows remain hidden from the physical interface level policy limiting the useful flow-based schedulers such as WFQ

- applying the policy on the tunnel interface works but limited as well for example class based shaping cannot be used with mGRE
and even if dose work it will not reflect the ctual interface traffic to be shaped

- pre classify is very useful feature just enable it and you do not need the tunnel interface service policy just use the physical interface level as normal and it can see the tunnel encapsulated traffic as it pass the interface without encapsulation ( simple )

HTH

Re: MPLS QOS

Joseph W. Doherty — Mon, 22 Aug 2011 10:37:18 GMT

Disclaimer

Liability Disclaimer

Posting

- pre classify is very useful feature just enable it and you do not need the tunnel interface service policy just use the physical interface level as normal and it can see the tunnel encapsulated traffic as it pass the interface without encapsulation ( simple )

Not quite as normal, if you want to do additional classification beyond what's in the IP header, for example NBAR.

- applying the policy on the tunnel interface works but limited as well for example class based shaping cannot be used with mGRE
and even if dose work it will not reflect the ctual interface traffic to be shaped

Not 100% certain, but I believe you can apply a service policy to a mGRE tunnel. If you can, I would expect you could define a class per destination and shape each class. This would allow you to shape to the far side's ingress bandwidth.

It also might be possible to combine this with a policy on the egress interface. If this is also correct, then you can correctly queue for congestion at the source router's egress interface and branch link's ingress interface.