qos pre-classify

Absolutely elegant discussion of qos pre-classify at href="http://packetlife.net/blog/2009/jun/17/qos-pre-classification.

I'm reposting it below (with crappy formatting) simply as a backup. Please give credit where credit is due.

QoS pre-classification

By stretch | Wednesday, June 17, 2009 at 10:37 a.m. UTC

Implementing quality of service provisions on virtual tunnel interfaces (VTIs) poses a challenge: QoS policy enforcement is normally applied only after tunnel encapsulation has taken place. Consider the following service policy applied to a GRE tunnel:

class-map match-all ICMP
match access-group name MATCH_ICMP
class-map match-all GRE
match access-group name MATCH_GRE
!
!
policy-map MyPolicy
class ICMP
class GRE
!
interface Tunnel0
ip address 192.168.0.1 255.255.255.252
tunnel source 10.0.0.1
tunnel destination 10.0.0.2
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.252
service-policy output MyPolicy
!
ip access-list extended MATCH_GRE
permit gre any any
ip access-list extended MATCH_ICMP
permit icmp any any

(Note that the policy map used as an example here does not actually enforce any policy; its class maps are included simply to illustrate the manner in which packets are being matched.)

In default operation, our QoS policy will be applied to packets exiting the physical interface only after they have undergone tunnel encapsulation.

When we generate ICMP traffic to the far end of the tunnel, we can verify that our policy only matches the packets as GRE traffic:

R1# ping 192.168.0.2 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 8/10/24 ms
R1# show policy-map interface f0/0
FastEthernet0/0

Service-policy output: MyPolicy

Class-map: ICMP (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: protocol icmp

Class-map: GRE (match-all)
10 packets, 1240 bytes
30 second offered rate 0 bps
Match: protocol gre

Class-map: class-default (match-any)
5 packets, 620 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

This hinders our ability to differentiate between packets which have undergone tunnel encapsulation. However, enabling QoS pre-classification configures the tunnel interface to maintain a copy of the original packet in memory long enough for the physical interface policy to inspect it.

After enabling pre-classification, our policy is applied to the original "inner" header instead of the encapsulation header:

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# interface tunnel0
R1(config-if)# qos pre-classify
R1(config-if)# ^Z
R1# clear counters f0/0
Clear "show interface" counters on this interface [confirm]
R1# ping 192.168.0.2 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 4/8/12 ms
R1# show policy-map interface f0/0
FastEthernet0/0

Service-policy output: MyPolicy

Class-map: ICMP (match-all)
10 packets, 1240 bytes
30 second offered rate 0 bps
Match: access-group name MATCH_ICMP

Class-map: GRE (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: access-group name MATCH_GRE

Class-map: class-default (match-any)
2 packets, 120 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
A couple side notes from my experiments on IOS 12.4(22)T:

I initially wrote the class maps to utilize NBAR (match protocol), but for some reason the ICMP class map didn't appear to take effect, so I switched to extended ACLs. Your mileage may vary.

Pre-classification seems to have no effect when applied to a VTI performing native IPsec encapsulation (versus a crypto map). Again, this may be IOS version-specific.