MPLS QOS

[hzarringhalam]

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

[Joseph W. Doherty]

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

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.)

[Marwan ALshawi]

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

[Joseph W. Doherty]

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

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.

[Marwan ALshawi]

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

[Joseph W. Doherty]

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

- 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.

[Marwan ALshawi]

shaping on the tunnel interface is not as accurate as applying it on the physical interface interms of marked traffic as you might have ( almost the case ) other type of traffic going through the interface other than the tunneled traffic

technically you can but from best practice design point of view its different

by the way shaping used in egress not ingress direction

[Joseph W. Doherty · Accepted solution]

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

shaping on the tunnel interface is not as accurate as applying it on the physical interface interms of marked traffic as you might have ( almost the case ) other type of traffic going through the interface other than the tunneled traffic 
technically you can but from best practice design point of view its different 

That would be true if you were sending both tunnel and non-tunnel traffic to same destination; which would be an unusal setup.  More common might be using the same physical interface for both tunnel and non-tunnel traffic to different destinations, then you might also need to shape for egress logical bandwidth less than physical interface.  For this, ideally you need two levels of shaping, one for the aggregate to interface, and the other for far side ingress.

by the way shaping used in egress not ingress direction 

Physically, correct, logically, though, it's often used to shape near side's egress to far side's available ingress.  I.e. ". . . source router's egress interface and branch link's ingress interface."

[hzarringhalam]

You guys are amazing.

I need some time to go through the information you emailed about DMVPN.

When I get stuck, I will take your time again ☺

Thank you,

Hamid

[Marwan ALshawi]

u welcome Hamid and rate the helpful posts too

Joseph FYI using new DMVPN features in this case of Hube and Spoke communications topology you can use the bellow logic use tow level of policies

tunnel interface level :

- Per-Tunnel QoS for DMVPN: This feature lets you apply a QoS policy on a DMVPN hub on a per-tunnel-instance (per-spoke) basis in the egress direction for DMVPN hub-to-spoke tunnels. This lets you shape the tunnel traffic to individual spokes (a parent policy) and differentiate individual data flows going through the tunnel for policing (a child policy

- physical interface level:

With Per-Tunnel QoS for DMVPN, the queuing and shaping is performed at the outbound physical interface for the GRE/IPsec tunnel packets. This means that the GRE header, the IPsec header and the L2 (for the physical interface) header are included in the packet-size calculations for shaping and bandwidth queuing of packets under QoS.

HTH

[Marwan ALshawi]

With ingress normally the traffic will be limited to the sending source bandwidth limit and shaper is a software level which is processed after the hardware queue in the ingress direction that why it has no benefit in the inbound ( buffering won't be useful )

While in the outbound it works the other way around that's why shaping used egress only while policing both directions can b used

HTH

Sent from Cisco Technical Support iPhone App

[hzarringhalam]

Hi,

Regarding QoS for DMVPN, I gathered the traffic analysis and BW information and ready to implement QoS for hub-spoke.

My customer asks me for a type of QoS configuration that BW be available for all traffic , but kicks in at critical moment.

For example, they want to have 20% of BW for Voice, but if there is no Voice traffic then BW should be available for other application and services.

But in critical moment 20 percent for voice be available for voice.

Is there any way for implementing this type of QoS?

Thanks,

Hamid

[Marwan ALshawi · Accepted solution]

Hamid,

QoS policy will not kicks in unless the interface is congested

for example if the interface not congested all type of traffic will pass through the interface, once get congested the QoS policy will kicks in and bandwidth reservation and Queuing will start take place

thats why as mentioned above it is important to specify the interface actual bandwidth using either parent policy with shaper or bandwidth command so that the policy can decide when the interface is considered congested and when its not

HTH

plz go through the above posts and rate the helpful ones so other people when read it can know which one was helpful for their benefit

[hzarringhalam]

Thanks Marwan.

Your comments are very helpful.

Best,

Hamid