When a packet is encapsulated and/or encrypted, the ToS byte is by default copied to the new IP header, however the other header fields are no longer available for classification and QoS actions. QoS pre-classify allows IOS to create a temporary copy of a packet in memory to be used for classification so that QoS actions can be performed on the final packet after encapsulation and/or encryption. This example will take a look at the three different ways QoS preclassification can be configured in a GRE over IPsec VPN, what the results are of each, and why each of them behave the way that they do. The following diagram shows the topology for this example:
R1 has a GRE over IPsec tunnel to R3 which will be used to encrypt traffic between each of their LAN subnets. R1 is connected to ‘Host’ which will be used to simulate a host on the LAN for traffic generation to test our QoS preclassify configuration. R3 is using a loopback to simulate its LAN. The relevant portions of each router’s intial configuration are shown below:
Since we will be testing preclassification outbound on R1′s S0/0 interface, we do not want any traffic being sent out the interface besides the traffic that we generate in order to make the results easier to interpret. To accomplish this, we will create static routes on R1 and R3 so that no routing protocol traffic is needed, and disable unnecessary services on R1 that create traffic. R2 does not need any static routes to create full reachability because all traffic between R1 and R3′s LAN subnets will be sent through the VPN and destined to R1 or R3′s S0/0 interfaces, which are directly connected to R2. The config for R1 and R3 is as follows:
Next, let’s create a policy map to use for testing how our traffic is classified. When we test it out, we will generate pings from ‘Host’ to R3′s loopback. Depending on when the classification is performed, the traffic could be classified as either ICMP traffic, GRE traffic, or ESP traffic so we will create a class to match each and add them to a policy map. Finally, we will enable the policy map on R1 S0/0 outbound.
Now we’re ready to look at how traffic is classified in each of the three scenarios. The first scenario is with no preclassification configured – in other words, the default behavior. We ping from ‘Host’ to R3′s loopback and examine the classification results in our policy map on R1:
The packets have been classified as ESP traffic, and the QoS actions (if we had configured any) for that class would be performed on the final outgoing packet. This generally isn’t very useful in a real network, since we don’t know what type of traffic is inside the ESP packet. That’s where QoS preclassification comes in.
The second scenario we will look at is with qos pre-classify configured on the crypto map. We configure this on R1 and clear the counters to remove the traffic statistics from our previous example:
Then we initiate another ping from ‘Host’ to R3′s loopback and view the policy map statistics on R1 again:
This time the packets have been classified as GRE traffic. Again, this is probably not very useful because we do not know what is encapsulated within the GRE packet.
For the third scenario, we will configure qos pre-classify on the Tunnel 0 interface. First remove the qos pre-classify from the crypto map in the previous scenario, then configure it on the tunnel interface and clear the counters:
Then initate a ping from ‘Host’ to R3′s loopback again and view the policy map statistics:
This time the traffic has been classified as ICMP and if we had configured any QoS actions for ICMP traffic, they would be performed on the final ESP packet when it leaves the router.
Why does the router classify the traffic like this in each scenario? It’s probably easiest to start with the third scenario, followed by the second, and finally the first.
Scenario #3 – Preclassify on the tunnel interface
1. R1 receives an ICMP packet from ‘Host’ to R3′s loopback.
2. R1 performs a routing table lookup on the packet and finds 3.3.3.0 /24 out interface Tunnel 0 as the best match, which we configured statically
3. R1 ‘sends’ the packet to Tunnel 0 and finds the qos pre-classify command configured. A temporary copy of the ICMP packet is created at this point to be used for classification, as shown below:
Scenario #2 – Preclassify on the crypto map
1. R1 receives an ICMP packet from ‘Host’ to R3′s loopback.
2. R1 performs a routing table lookup on the packet and finds 3.3.3.0 /24 out interface Tunnel 0 as the best match, which we configured statically
3. R1 ‘sends’ the packet to Tunnel 0. The tunnel mode, which was left at default, is gre ip. R1 adds a GRE header and a new IP header outside the GRE header, using the tunnel source and tunnel destination addresses that are configured on the tunnel interface as the source and destination for the new IP header.
4. R1 performs a routing table lookup on the new destination address, 10.1.23.3, and finds the default route out interface S0/0 as the best match (this was configured statically as well).
5. R1 finds that there is a crypto map configured on S0/0 and finds the qos pre-classify command in the crypto map. A temporary copy of the packet is created at this point to be used for classification, as shown below:
Scenario #1 – No preclassification configured
1. R1 receives an ICMP packet from ‘Host’ to R3′s loopback.
2. R1 performs a routing table lookup on the packet and finds 3.3.3.0 /24 out interface Tunnel 0 as the best match, which we configured statically
3. R1 ‘sends’ the packet to Tunnel 0. The tunnel mode, which was left at default, is gre ip. R1 adds a GRE header and a new IP header outside the GRE header, using the tunnel source and tunnel destination addresses that are configured on the tunnel interface as the source and destination for the new IP header.
4. R1 performs a routing table lookup on the new destination address, 10.1.23.3, and finds the default route out interface S0/0 as the best match (this was configured statically as well).
5. R1 finds that there is a crypto map configured on S0/0 and that the GRE packet matches the ACL in the crypto map. R1 adds an ESP header and a new IP header outside the ESP header, as specified by the crypto map and IPsec transform set.
6. R1 performs classification on the final ESP packet and sends the packet out S0/0, as shown below:
One final scenario to look at is configuring the service policy on the tunnel interface rather than the physical interface without using preclassification:
Then we initiate a ping from ‘Host’ to R3′s loopback again and view the statistics:
Just like the third scenario, the traffic is classified as ICMP, and no preclassification was even needed. However, this service policy will only be applied to traffic exiting Tunnel 0, whereas the first three scenarios would apply to traffic exiting S0/0, Tunnel 0, and any other tunnel interfaces that were configured to use S0/0. Ultimately, the choice of where to apply the service policy and where or if to apply QoS preclassification will depend on what is trying to be accomplished.