Qos Preclassify, why ?

[illusion_rox]

hi all, i am still confused with the usage of this command as to actually where to use it ? on tunnel or not !! i dont know when this confusion will be cleared :-( so far kindly look at my scenario,

i have used an access-list to match the traffic, i used a class-map and called the access-list, see below

access-list 101 per ip ho 10.1.1.1 any

class-map test

mat ip address 101

poicy-map test1

class test

bandwidth 128

int fas 0/1 ( WAN interface connected to DSL )

service-policy output test1

now on tunnel shall i use qos pre-classify or not, as you can see I AM NOT USING ANY MARKING, so do qos-preclassify still does me any favour ? i am all confused here, i have referred to both of these docs

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

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

sorry but i am all confused here, where and why will i ever used qos pre-classify command ? what is meant by inner header and outer header ? where do the qos features meet the packet ? before or after the encapsulation !! actually quite embarassing sorry but i cant visualize exactly what information will be lost after the packet is encapsulated :-(

kindly guide me in detail to get my concept done once and for all

[lee.reade]

Hi,

QOS Pre-classify will copy the IP Precendence/DSCP bits from the tobe IP packet into the new GRE tunnel header, so that qos operations can still be done correctly.

Say you had already marked the traffic from 10.1.1.1 with DSCP EF, perhaps an input policy on incoming interface/or output on an earlier router/or perhaps on input into the local switchport. And you had also decided that all EF traffic should get 50% bandwidth upon exit from interface fas 0/1, then if you do not do pre-classify, the DSCP marking of EF in the original IP header will not get copied into the new GRE header, and as result your traffic would not get 50% of the bandwidth as you had planned for.

Obviously if you dont mark the ip precendence/dscp earlier in the flow then yes there is no real benefit for you in this case to do qos pre-classify.

HTH

LR

[nikhil.engineer]

Hi,

In normal scenario, packets are encapsulated when traversing through tunnel. Packets are considered identical if there is congestion.Without the qos pre-classify command, packets traversing across the same tunnel have the same tunnel header ie) by default tunneling function won't copy orginal ip header to tunnel header.But in some materials i have seen, that the TOS copying is the function of tunneling mechanism and not by qos-preclassify command. And our classification option matches only on the TOS byte then don't need to use qos-preclassify command.

So,When one want to classify packets based on Tos byte, then no need to enable qos-preclassify.

But when one want to classify packets based on info other than TOS byte in ip header then have to enable qos-preclassify.

HTH.

Cheers,

Nikhil E.

[shrikar.dange]

thnks...deserves rating!!!!

QoS is always like a nightmare for me!!!!

Understood tip of an iceberg!!!

regards,

shri!!!