When packets pass through a VPN, the original IP header is encapsulated. For eg, in case of GRE tunnel, GRE is the encapsulation protocol and IP becomes the passenger protocol, ofcourse using IP again as the transport protocol.
Original Packet
| IP | TCP | Data |
After entering the VPN tunnel
| New IP Header | Encrypted Original Packet |
However Cisco IOS has a feature, in which it copies the TOS byte of the original IP header to new IP Header. This is good, because intermediate nodes can examine the TOS byte for classification purpose, but are unable to use a multifield classifer, which examines more than just the TOS byte for classifcation purposes.
Qos Preclassify, allows the router which starts the encapsulation and encryption to examine more than the TOS byte. With the Qos Preclassify, it stores headers of the original packet before encapsulation and encrytion in memory. This helps in classifying based on multi field classifiers.
Copied directly from http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml
----------------------------------------------------
Where Do I Apply the Service Policy?
You can apply a service policy to either the tunnel interface or to the underlying physical interface. The decision of where to apply the policy depends on the QoS objectives. It also depends on which header you need to use for classification.
-
Apply the policy to the tunnel interface without qos-preclassify when you want to classify packets based on the pre-tunnel header.
-
Apply the policy to the physical interface without qos-preclassify when you want to classify packets based on the post-tunnel header. In addition, apply the policy to the physical interface when you want to shape or police all traffic belonging to a tunnel, and the physical interface supports several tunnels.
-
Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface when you want to classify packets based on the pre-tunnel header.
Lets verify the usage of qos-preclassify in as mentioned above with out example topology below
| 3640a class-map match-all TELNET match access-group 102 ! ! policy-map telnetmap class TELNET interface Tunnel0 ip address 11.0.0.2 255.255.255.0 load-interval 30 tunnel source Ethernet0/0 tunnel destination 192.168.1.18 interface Ethernet0/0 ip address 192.168.1.17 255.255.255.0 half-duplex ip route 12.0.0.1 255.255.255.255 11.0.0.1 access-list 102 permit tcp any host 12.0.0.1 eq telnet | 2610xm interface Loopback0 ip address 12.0.0.1 255.255.255.255 ! interface Tunnel0 ip address 11.0.0.1 255.255.255.0 tunnel source FastEthernet0/0 tunnel destination 192.168.1.17 ! interface FastEthernet0/0 ip address 192.168.1.18 255.255.255.0 duplex auto speed auto line vty 0 4 password telnet login |
Case 1) Apply the policy to the tunnel interface without qos-preclassify when you want to classify packets based on the pre-tunnel header.
Our match statement above is multi field classifier in class-map TELNET , it has to examine more than the TOS byte to classify packets based on the access-group 102.
| 3640a(config)#int tunnel 0 3640a(config-if)#service-policy output telnetmap 3640a(config-if)#^Z --Generate telnet traffic 3640a#telnet 12.0.0.1 Trying 12.0.0.1 ... Open User Access Verification Password: 2610XM>exit [Connection to 12.0.0.1 closed by foreign host] 3640a#show policy-map int tunnel 0 Tunnel0 Service-policy output: telnetmap Class-map: TELNET (match-all) 30 packets, 1255 bytes 30 second offered rate 0 bps Match: access-group 102 Class-map: class-default (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any 3640a# |
By applying the policy-map to the tunnel interface and generating the telnet traffic to 2610xm, we can see that it classifies packets based on our class-map TELNET rather than class-default, which means the tunnel interface is able to read the pre-tunnel header to perform a multi field classification.
Case 2)Apply the policy to the physical interface without qos-preclassify when you want to classify packets based on the post-tunnel header.
Now we need to apply the service-policy command to the physical interface (remove from the tunnel interface) and it should only be able to the see the post-tunnel header, unable to classify packets based on class-map TELNET. Make sure you issue a clear counters to get a clean slate when using show policy-map int command
| 3640a(config)#int e0/0 3640a(config-if)#service-policy output telnetmap 3640a(config-if)# --Generate telnet traffic 3640a#telnet 12.0.0.1 Trying 12.0.0.1 ... Open User Access Verification Password: 2610XM>exit [Connection to 12.0.0.1 closed by foreign host] 3640a# 3640a#show policy-map int e0/0 Ethernet0/0 Service-policy output: telnetmap Class-map: TELNET (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps Match: access-group 102 Class-map: class-default (match-any) 26 packets, 2040 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: any 3640a# |
As seen, it could not classify packets because the original IP header has been encapsulated, hence all traffic (telnet) matched the class-default.
3) Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface when you want to classify packets based on the pre-tunnel header.
Below will be the output of the show policy-map interface, after adding qos-preclassify to the tunnel interface.
| 3640a#sh policy-map int e0/0 Ethernet0/0 Service-policy output: telnetmap Class-map: TELNET (match-all) 24 packets, 1920 bytes 5 minute offered rate 0 bps Match: access-group 102 Class-map: class-default (match-any) 3 packets, 180 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any 3640a# |
As said, it could successfully classify based on class-map TELNET.
No comments:
Post a Comment