Qos for ipsec traffic over MPLS cloud

[k.hariharan1]

Hi there,

i have two vpn routers in my datacenter which is connected to MPLS cloud and around 1000 branch connected to mpls cloud by using BGP. i want to configure Qos for the ip sec traffic and make sure that this ipsec traffic is getting high priority than the other traffic. kindly find the attach file for my network topology.

i need some clarifications about few points below.

1. if it is  ipsec traffic, the MPLS service provider unable to view the QOS marking (DSCP or IP precedence) because it the encrypted data so is it possible to mark the ipsec traffic in such way that MPLS service provider can receive and map it to MPLS exp bit 5.

2.  if i just add the qos-preclassify command under crypto map and mark the traffic with DSCP or IP precedence or any value , will the service provider can able to identify the traffic and map it to EXP bit.

Kindly let us know the solution for this.

Regards,

Hariharan k

[wzhang · Accepted solution]

Hi,

1) By default, IOS IPSec will preserve the dscp/precedence marking of the data packet in the encapsulating header, so a transit router would still be able to have visibility to that marking even though the payload itself is completely encrypted.

2) Again, if the data packet has the dscp/precedence bits marked (either from the end host or through re-marking via an inbound service policy), the marking will be carried over to the outer encapsulating header by default, you shouldn't need to configure qos pre-classify for that. What qos pre-classify will do for you is to give you visibility to the data packet's other L3/L4 information at the time of classification.

Hope this helps,

Thanks,

Wen

[k.hariharan1]

hi Wen,

thanks for your reply,

Regarding the Qos pre-classify , i understood that it will have the clone of the packet based on which the qos marking is identified also i remember

regarding QoS Pre-Classify is that it is applicable only at the encrypting router's output interface.  how can i map the ipsec traffic which clone by using Qos pre-classify command to MPLS exp bit inorder to get end to end QoS.  

I mean, for the rest of the traffic (non-ipsec) i had set some DSCP values and SP is ready to map that values to MPLS EXP values but According to MPLS SP they will not able to view the DSCP value assigned for IPSEC traffic because all the traffic will flow under  a secure encrypted tunnel.

Regards,

Hariharan k

[Jon Marshall]

I mean, for the rest of the traffic (non-ipsec) i had set some DSCP values and SP is ready to map that values to MPLS EXP values but According to MPLS SP they will not able to view the DSCP value assigned for IPSEC traffic because all the traffic will flow under  a secure encrypted tunnel.

But that is what we are both saying. If the marking is there in the packet before IPSEC then the marking gets copied to header that IPSEC adds to the encrypted packet so the SP will see the marking and be able to map it to an MPLS EXP value.

If the marking is not there, then use qos-preclassify ie. add a marking before IPSEC and then IPSEC will copy that marking to the new IPSEC header.

Either way, there will be a marking for the SP to use.

Jon

[Jon Marshall]

k.hariharan1 wrote:
Hi there,
i have two vpn routers in my datacenter which is connected to MPLS cloud and around 1000 branch connected to mpls cloud by using BGP. i want to configure Qos for the ip sec traffic and make sure that this ipsec traffic is getting high priority than the other traffic. kindly find the attach file for my network topology.
i need some clarifications about few points below.
1. if it is  ipsec traffic, the MPLS service provider unable to view the QOS marking (DSCP or IP precedence) because it the encrypted data so is it possible to mark the ipsec traffic in such way that MPLS service provider can receive and map it to MPLS exp bit 5.
2.  if i just add the qos-preclassify command under crypto map and mark the traffic with DSCP or IP precedence or any value , will the service provider can able to identify the traffic and map it to EXP bit.
Kindly let us know the solution for this.
Regards,
Hariharan k

It depends.

If your traffic is already marked then IPSEC mandates that the ToS header from the original packet is copied to the new header containing the encrypted packert so your SP can use that marking.

If your traffic is not marked before you do the IPSEC then you need to use qos pre-classify to make sure the QOS marking is done before encryption and then the ToS header will be copied as before to the new IPSEC header.

Jon

[wzhang]

Hi, Jon:

Actually, it's a common misconception that the copying of the tos byte has something to do with qos pre-classify - it really doesn't. All qos pre-classify does is to save a copy of the original data packet's L3/L4 information and use it for qos classification. The tos byte is always copied regardless of whether qos pre-classify is configured or not. In the second scenario you mentioned where the packet does not come with any kind of marking, you could mark the packet in one of the 2 ways below:

1. Inbound service policy/pbr to mark or remark, and the new marking will be carried over to the outer encap header.

2. Outbound service policy to mark, this will only mark the outer encap header without touching the inner header's TOS setting.

In either case, no pre-classify is needed. At least this is the behavior by design, and looks to be the case with 12.4(15)T12 which I just verified.

Thanks,

Wen

[Jon Marshall]

wzhang wrote:
Hi, Jon:
Actually, it's a common misconception that the copying of the tos byte has something to do with qos pre-classify - it really doesn't. All qos pre-classify does is to save a copy of the original data packet's L3/L4 information and use it for qos classification. The tos byte is always copied regardless of whether qos pre-classify is configured or not. In the second scenario you mentioned where the packet does not come with any kind of marking, you could mark the packet in one of the 2 ways below:
1. Inbound service policy/pbr to mark or remark, and the new marking will be carried over to the outer encap header.
2. Outbound service policy to mark, this will only mark the outer encap header without touching the inner header's TOS setting.
In either case, no pre-classify is needed. At least this is the behavior by design, and looks to be the case with 12.4(15)T12 which I just verified.
Thanks,
Wen

Wen

Many thanks for clarifying that, that was something i wasn't aware of.

Jon

[k.hariharan1]

hi wen and jon,

Really thanks a lot for you both to clarify my doubt.

so as wen said, if we are configuring qos pre-clasify command or not by default dscp values will be visible by transit routers  which is then used for the qos clasifications and mapping by mpls service provider.

please correct me if i am wrong..

Regards,

Hariharan k

[wzhang]

Hi,

Yes your understanding is correct.

Thanks,

Wen

[k.hariharan1]

hi wen,

i have prepared my cofiguration for Qos as follow,

1.

class-map match-any IPSEC

match access-group name IPSEC-DATA

policy-map QOS

class IPSEC

priority percent 50

set ip dscp af21  ----  i will inform MPLS sp to map this value with mpls exp 5

class class-default

fair-queue

ip access-list extended IPSEC-DATA

permit esp any any

int fa0/0  ------- interface connected to MPLS PE router

service-policy output QOS

                                                 OR

2. since  the original IP ToS byte values are copied  initially to the IP header added by the GRE encapsulation. Then these  values are copied again to the IP header added by IPSec encryption.so if i  set the dscp values to the ip packet before it get encrypted that dscp values will be automatically copied to the IP header added by IPSec encryption later which can be used by the mpls sp for mapping it to exp bit.

correct me if i am wrong...

Regards,

Hariharan k

[wzhang]

Hi,

The two options you outlined below don't quite do the same thing. With option 1), all IPSec traffic will be marked as af21 in the outer delivery header regardless of the inner markings, so essentially any transit router between the tunnel end points will treat all traffic inside of the tunnel equally. With 2), you'd preserve the original marking, so say for example, voice traffic may be treated differently from data even thought they all go inside of the same tunnel. So when deciding which one to use, I guess it'd depend on the end goal you are trying to achieve.

Thanks,

Wen

PS, your first configuration has LLQ applied on a high speed interface, which is likely not going to work unless you put it in a parent shaper unless you have Gig input interfaces and a true FastE provider hand-off.