CBWFQ & IPSec VPN

Answered Question

Hello,


We have an IPSec tunnel established between our office and another site using 2 ASA 5510s running 8.0(3).


We have a T1 connecting these sites. I want to be able to use CBWFQ on the serial interfaces of the routers. How can I copy the "copy" the DSCP value into the IP header of the ESP packet on the ASA, if the DSCP is set on the ingress interface of the ASA? I want certain VPN traffic to be placed into different queues on the serial interfaces. I see there the "qos pre-classify" command that exists for routers. Does the ASA have something simular? If no, what can I do?


Thanks!

Correct Answer by Marwan ALshawi about 8 years 6 months ago

good luck


please, if helpful rate

Correct Answer by Farrukh Haroon about 8 years 6 months ago

I thought the DSCP bit is automatically coped from the inner header to the outer header as per the RFC?


QOS pre-classify is only required if you need to apply QOS policies based on other parameters (not copied or visible) at the egress interace.

E.g. in case of IPSEC tunnel mode the layer 4 port-numbers are not visible. For transport mode more fields are visible.


Regards


Farrukh



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Correct Answer
Farrukh Haroon Mon, 08/11/2008 - 18:26

I thought the DSCP bit is automatically coped from the inner header to the outer header as per the RFC?


QOS pre-classify is only required if you need to apply QOS policies based on other parameters (not copied or visible) at the egress interace.

E.g. in case of IPSEC tunnel mode the layer 4 port-numbers are not visible. For transport mode more fields are visible.


Regards


Farrukh



Marwan ALshawi Mon, 08/11/2008 - 19:00

i agree with Farrukh


according to cisco SRND

In Cisco AVVID solutions, the IP Phone and gateways provide the capability to set the ToS byte so

routers can make the appropriate QoS decision. However, most data applications do not set the ToS byte

and queuing decisions must be based on other fields of the IP header, including source/destination IP

address, port numbers, and protocol

Once the original IP packet is encrypted by IPSec, fields other than ToS byte, such as port numbers,

protocol and source/destination IP address fields, are no longer in clear text and cannot match an output

service policy. QoS Pre-Classify is an Cisco IOS software feature to allow fancy queuing,

CBWFQ/WFQ, at the output interface to match on these other fields in the original IP header, even after

the original IP header is encrypted


howver

u can use matching in the calss map and make the matching based on ur vpn tunnel-gourp that u have

in the case u can play with priority or bandwidth limitation


check the following link


PIX/ASA 7.x and Later: Bandwidth Management(Rate Limit) Using QoS Policies


http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008084de0c.shtml


good luck


please, if helpful Rate

Awesome! I did not realize the RFC called for that ToS bytes to be copied from the inner header to the outer header. I was planning on testing this out today by creating the policy-maps and running a capture on the other VPN endpoint to see if I see the DSCP bits set in the outer headers. I will let you guys know what I find.


Thanks!

Actions

This Discussion