QoS for VPN

When a packet is encapsulated using GRE for instance or encrypted using IPSec, by default, Cisco IOS router copies the ToS (Type of Service) byte into the new IP header of encapsulated/ encrypted packet from the original IP header. This allows the ISP to look up at least ToS byte to perform QoS functions.

However, in some case you might want to perform QoS features on the egress (i.e. outgoing interface towards ISP on R2 router above). But then the outgoing packets could be encrypted/encapsulated and original IP header information is not available.

Cisco IOS has a feature called QoS Pre-classification. On VPN endpoints, we can refer to the original IP header for QoS decisions even after the packet is encapsulated or encrypted. The IOS keeps the original unencrypted packet in the memory until QoS actions are taken.


QoS for IPSec VPN:

First, QoS for IPSec VPN is illustrated here. An IPSec VPN is setup between R2 and R3 routers. All ICMP traffic originating from R1 router towards R4 router and in reverse direction, will be forced through IPSec VPN.

Case 1: No QoS Pre-classification on R2 router and R1 router sends ICMP traffic with ToS = 160 (i.e IP Precedence = 5)

Traffic Classification on R2

ip access-list extended ESP
 permit esp any any       ! matches all ESP traffic
!
class-map PREC_5
 match ip precedence 5    ! matches traffic marked with IP Precedence 5
!class-map IPSEC_TRAFFIC
 match access-group name ESP
!
policy-map TRAFFIC
 class PREC_5 class IPSEC_TRAFFIC
 class class-default
!
interface fastethernet 0/1
 service-policy output TRAFFIC
!

Now R1 router sends ICMP traffic to R4 router with IP Precedence 5 (ToS 160). By default, the ToS byte will be copied to the new IP header. So the following output shows that R2 router can recognize IP Precedence 5 packets from R1 router on its outgoing interface. However, the packet count for ESP traffic is 0. The reason being the IP Precedence 5 packets are matched first on R1 router since the policy-map has the IP Precedence 5 matching class before ESP/IPSec matching class.

R2# show policy-map  Policy Map TRAFFIC
    Class PREC_5
    Class IPSEC_TRAFFIC
    Class class-default

R2# show policy-map interface
 FastEthernet0/1

  Service-policy output: TRAFFIC

    Class-map: PREC_5 (match-all)
      5 packets, 830 bytes
      5 minute offered rate 0 bps
      Match: ip precedence 5

    Class-map: IPSEC_TRAFFIC (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: access-group name ESP

    Class-map: class-default (match-any)
      1 packets, 74 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Case 2: No QoS Pre-classification on R2 router and R1 router sends traffic with no IP Precedence values

This time the PREC_5 does not match the traffic since there is no IP Precedence values in the ICMP packets. However, the packets are recognized as ESP packets and hence classified by IPSEC_TRAFFIC class-map. This information is not useful and hence QoS Pre-classification is required.

R1# ping 10.5.5.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.5.5.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 120/184/300 ms

R2# show policy-map interface
 FastEthernet0/1

  Service-policy output: TRAFFIC

    Class-map: PREC_5 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: ip precedence 5

    Class-map: IPSEC_TRAFFIC (match-all)
      5 packets, 830 bytes
      5 minute offered rate 0 bps
      Match: access-group name ESP

    Class-map: class-default (match-any)
      4 packets, 282 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Case 3: QoS Pre-classification on R2 router

The QoS Pre-classify feature can be enabled under crypto-map configuration. Another class-map matching ICMP traffic is added.

QoS Pre-classify on R2

class-map ICMP_TRAFFIC
 match protocol icmp
!
policy-map TRAFFIC
 class ICMP_TRAFFIC
!
crypto map STATIC 10 ipsec-isakmp
 qos pre-classify
!

The output shows that now R2 can recognize the type of packet encrypted by IPSec. It can figure out that the encrypted traffic is ICMP.

ICMP Traffic Recognized

R2# show policy-map
  Policy Map TRAFFIC
    Class IPSEC_TRAFFIC
    Class ICMP_TRAFFIC
    Class class-default

R2# show policy-map interface
 FastEthernet0/1

  Service-policy output: TRAFFIC

    Class-map: IPSEC_TRAFFIC (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: access-group name ESP

    Class-map: ICMP_TRAFFIC (match-all)
      5 packets, 570 bytes
      5 minute offered rate 0 bps
      Match: protocol icmp

    Class-map: class-default (match-any)
      2 packets, 148 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any