cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1796
Views
10
Helpful
11
Replies

Qos Pre-classify

illusion_rox
Level 1
Level 1

hi, i have hub n spoke topology with 1 hub router and 5 spokes router. Spokes are connected to hub via gre tunnels. we have a server at each spoke that means total of 6 servers. i want to apply qos so that traffic from server is always given bandwidth of atleast 30%. now the lan interface on my every spoke router is Fa0/0 where the server is placed. Wan interface is Fa0/1 which provides source for tunnel ( tunnel source Fa0/1 ). now as i said i m doing classification and marking on my Fa0/0 i.e. i have applied service-policy input server_traffic_in... which classifies and marks the packets from server to AF41 successfully, now plz tell me where should i apply the outbound policy map, to physical interface ( Fa0/1 ) or to tunnel interface ? any do i need to use pre-classify command also ?? i tried my best not to leave any confusion so plz tell me wat to do in this case

thanks

1 Accepted Solution

Accepted Solutions

Yes, please note that pre-classify was needed in some of the older IOS images where the TOS bit was not copied automatically in the new header created by IPSEC or GRE. In the newer IOS, this is the default behaviour, so you dont need to perform QOS Pre-classification.

Trust this clarifies

View solution in original post

11 Replies 11

Joseph W. Doherty
Hall of Fame
Hall of Fame

If I recall correctly, you'll want to apply your outbound policy on the outbound physical interface and the pre-classify on the tunnel. (BTW: I believe I've noticed some Cisco devices seem to automatically copy the ToS even without using the pre-classify; as in I've seen class match hits on the outbound physical interface's class map.)

PS:

If not already doing so, I would recommend using the MTU auto detection command across the tunnel (don't recall the actual command) and usage of the tcp adjust-mss on the tunnel interface, if supported.

Hi Joseph, i am getting match hits on outbound policy since right now i have applied it on the physical WAN interface (Fa0/1) without pre-classify. So does it mean that its working correctly and i dont need pre-classify ??

Kindly guide me thanks

Yes, please note that pre-classify was needed in some of the older IOS images where the TOS bit was not copied automatically in the new header created by IPSEC or GRE. In the newer IOS, this is the default behaviour, so you dont need to perform QOS Pre-classification.

Trust this clarifies

Hi, is there any document you can refer that addresses this fact

thanks in advance

Quoting Cisco

"If your classification policy matches with the ToS byte, you do not need to use the qos pre-classify command since the ToS value is copied to the outer header by default. You can create a simple QoS policy which sorts traffic into classes based on IP precedence. However, to differentiate traffic within a class and to separate it into multiple flow-based queues, the qos pre-classify command is required.

Note: ToS byte copying is done by the tunneling mechanism and not by the qos pre-classify command. "

http://www.cisco.com/en/US/partner/tech/tk543/tk757/technologies_tech_note09186a00800b3d15.shtml#t4

Hey all. There seems to be a little confusion here, so I hope I can clarify a few grey areas. The 'qos pre-classify' command does NOT turn-on the copying of the TOS field from the original IP header to the VPN IP header. This is enabled automagically using 'newer' versions of IOS when using GRE or IPSEC.

So, whats the point of 'qos pre-classify'. Lets take an example. If you want to police HTTP traffic you would use MQC (define a class-map matching HTTP traffic, reference this class-map within a policy-map and configure policing for the class-map, etc). However, this physical interface is used as an exit point for a IPSEC tunnel. When an IPSEC packet wants to leave the physical interface, the QOS policy will look for a HTTP packet (TCP port 80 typically). However, the packet is encrypted!! So the exit interface cannot determine that this is/was an HTTP packet! If you turn on 'qos pre-classify', the router will create a clone of the IP header prior to IPSEC encryption. When the packet now reaches the physical interface, the router can look at the 'cloned' IP header of the encrypted packet, see that it is an HTTP packet and apply QOS as necessary.

I hope this makes some sense, and explains why the ToS was being copied by default, and what the purpose is of the 'qos pre-classify' command.

Good luck and best regards

Darren

CCIE#20078

Very interesting!

The "clone" header would only be visible on the router doing the encryption? I.e. all downstream devices would only be able to work with the ToS value in the outer packet?

If qos pre-classify is not active, can the encrypting router's outbound interface still use the outer packet's ToS? If qos pre-classify is active, can the encrypting router's outbound interface still use the outer packet's ToS? (I.e. are they mutually exlusive?)

If qos pre-classify is active, is there any distinction between the "cloned" headers and other outbound traffic on the same interface not using encryption? For instance, could we distinguish between outbound non-encrypted HTTP and encrypted HTTP?

Hey there Joseph. You are correct, the 'clone' header is only visible to the router doing the encryption - the 'clone' is not sent anywhere!

Im pretty sure that if pre-classify is not active, then yes you can use TOS against the outer packets QOS. Even if pre-classify is active, then you can still only use the TOS but what would be the point of creating a 'clone' if it is not used!?!?

Hope this clarifies a few points.

Darren

Darren, clarifies? Yes and no.

Why use ToS if clone available? Good question. One answer might be to use an uniform outbound policy.

How far can you go with the "clone" on the outbound physical interface? For instance, can I use original IP address/port analysis against the encrypted packet's "clone"? NBAR? Is there an easy method to distinguish "clone" from other non-encryped traffic on the same physical interface?

The Cisco documentation doesn't seem to infer much beyond copying the original packet's ToS to the encrypted packet's ToS. Any URLs that would further explain, would be most helpful.

Hey there, been kinda busy, hence the late reply.....

I see your point about uniform outbound policy - I guess this is always good practise.

Ive not personally searched for this info on CCO, however it is explained very well (way better than my explanation) in End-to-End QoS Network Design by Tim Szigeti (CiscoPress). If you have this great, if not maybe ask a co-worker or even buy it - go to page 649 and I'm sure it will clear any confusions.

Darren

Hi Daren,

Could you explain me how do you want to figure out TCP port number from the IP header. If QoS pre-classify copied just IP header, TCP header is still not available for QoS purpose. Am I right?

You should be more secific here and said that pre-classify is copying IP and TCP header in to temporary stored not just IP hdr.

Thanks

NetContractor

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: