Article Detail

Description

After decryption from route-based VPN, clear-text packets are not categorized as per the Differentiated Services code point (DSCP) marking in their headers, even though Class of Service (CoS) is configured on the physical interface.

This article gives the reason for such behavior and explains that configuration of CoS classifiers on tunnel interfaces will resolve the issue.

Symptoms

Sample Topology

(192.168.45.1) Host A --- SRX-1 (st0.0) =====vpn===== ge-0/0/2 (st0.1) SRX-2 (ge-0/0/3) --- Host B (192.168.40.2)

Example

"Partial" output of Class-of-Service configuration on SRX-2

set class-of-service classifiers dscp test_dscp forwarding-class BE loss-priority low code-points be
set class-of-service classifiers dscp test_dscp forwarding-class af2x loss-priority low code-points af21
set class-of-service classifiers dscp test_dscp forwarding-class af2x loss-priority high code-points af22
set class-of-service classifiers dscp test_dscp forwarding-class af2x loss-priority high code-points af23
set class-of-service scheduler-maps test-schedulers forwarding-class BE scheduler BE
set class-of-service scheduler-maps test-schedulers forwarding-class af2x scheduler af2x
set class-of-service interfaces ge-0/0/2 scheduler-map test-schedulers
set class-of-service interfaces ge-0/0/2 unit 0 classifiers dscp test_dscp
set class-of-service interfaces ge-0/0/3 scheduler-map test-schedulers
set class-of-service interfaces ge-0/0/3 unit 0 classifiers dscp test_dscp

With the above configuration:

Traffic from Host A is sent towards Host B with the DSCP bits set to 010010 (class AF21).
SRX-1 encrypts the packet and copies the DSCP field of the clear-text packet to the outer ESP packet (by default).
SRX-2 receives this ESP packet (with the DSCP value 010010) and decrypts it. The clear-text packet retains its original DSCP value. However, despite the DSCP marking in the clear-text header, the traffic is not categorized in the af2x queue on the egress interface. In this example, ge-0/0/2 is the ingress interface for the ESP packet and ge-0/0/3 is the egress interface for the clear-text packet.

The following output shows that ICMP traffic with source 192.168.45.1 (Host A IP) to destination 192.168.40.2 (Host B IP) with tos 72 (equivalent to DSCP 010010) is generated. The successful ping shows that the packet has reached the destination and that a response has been received.

SRX-1> ping 192.168.40.2 source 192.168.45.1 tos 72 count 5 
PING 192.168.40.2 (192.168.40.2): 56 data bytes
64 bytes from 192.168.40.2: icmp_seq=0 ttl=63 time=2.932 ms
64 bytes from 192.168.40.2: icmp_seq=1 ttl=63 time=2.431 ms
64 bytes from 192.168.40.2: icmp_seq=2 ttl=63 time=4.931 ms
64 bytes from 192.168.40.2: icmp_seq=3 ttl=63 time=2.532 ms
64 bytes from 192.168.40.2: icmp_seq=4 ttl=63 time=2.497 ms

--- 192.168.40.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.431/3.065/4.931/0.950 ms

However, the following output from SRX-2 shows that the value of Packets/Bytes has not increased even though clear-text packets with DSCP (AF2X) were sent. This means that they are not classified under the AF2X egress queue on ge-0/0/3.

SRX-2> show interfaces queue forwarding-class af2x
Physical interface: ge-0/0/3, Enabled, Physical link is Up
  Interface index: 142, SNMP ifIndex: 516
Forwarding classes: 8 supported, 8 in use
Egress queues: 8 supported, 8 in use
Queue: 2, Forwarding classes: af2x
  Queued:
    Packets              :                     0                     0 pps
    Bytes                :                     0                     0 bps

Solution

In Junos OS releases prior to Junos OS release 15.1X49-D70 (SRX high-end) and Junos OS release 15.1X49-D60 (SRX branch), the inner packet (after decryption) was automatically assigned to the same CoS queue as its encrypted parent (ESP packet) because it was assumed that the inner packet DSCP marking is identical to the outer packet DSCP marking.

However, the newer Junos OS releases do not make this assumption anymore. Instead, they re-classify the packet after decryption based on the actual DSCP marking of the inner IP header. This approach supports previously unsupported scenarios where the inner and outer headers have different DSCP markings.

See Understanding CoS Support on st0 Interfaces and KB29565 - [SRX] IPSec VPN behavior on IP ToS/DSCP field [juniper.net] for more information.

Given that the decrypted packet is being treated as ingressing its corresponding st0 unit, CoS classifiers must be configured on the tunnel interfaces (st0) to modify this behavior. When a classifier is applied on the tunnel interface, the decrypted packet will be properly classified based on its own DSCP marking.

In the above example, addition of the following configuration will enable the decrypted packet to be properly classified:

set class-of-service interfaces st0 scheduler-map test-schedulers
set class-of-service interfaces st0 unit 1 classifiers dscp test_dscp

Verification

SRX-1> ping 192.168.40.2 source 192.168.45.1 tos 72 count 5
PING 192.168.40.2 (192.168.40.2): 56 data bytes
64 bytes from 192.168.40.2: icmp_seq=0 ttl=63 time=2.509 ms
64 bytes from 192.168.40.2: icmp_seq=1 ttl=63 time=3.428 ms
64 bytes from 192.168.40.2: icmp_seq=2 ttl=63 time=2.354 ms
64 bytes from 192.168.40.2: icmp_seq=3 ttl=63 time=2.325 ms
64 bytes from 192.168.40.2: icmp_seq=4 ttl=63 time=2.327 ms

--- 192.168.40.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.325/2.589/3.428/0.425 ms

SRX-2> show interfaces queue forwarding-class af2x
Physical interface: ge-0/0/3, Enabled, Physical link is Up
  Interface index: 142, SNMP ifIndex: 516
Forwarding classes: 8 supported, 8 in use
Egress queues: 8 supported, 8 in use
Queue: 2, Forwarding classes: af2x
  Queued:
    Packets              :                     5                     0 pps
    Bytes                :                   490                     0 bps