Troubleshoot DSCP Value in QOS Changes in ASR9000

Introduction

This document describes how to troubleshoot Quality of Service (QOS) policy inheritance in Cisco Aggregation Services Router (ASR) 9000. It indicates the router behaviour when there is Differentiated Services Code Point (DSCP) marking in an ingress policy configuration of a physical port. This policy is enforced for all Layer 2 and Layer 3 subinterfaces under that physical port.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Layer 2 Virtual Private Network (L2VPN) and Ethernet Service configuration in ASR9000

     Cisco ASR 9000 Series Aggregation Services Router L2VPN and Ethernet Services Configuration Guide

• Quality of Service Configuration in ASR9000

     Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Configuration Guide

  

Components Used

The information in this document is based on Cisco ASR9000 Series.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problem: DSCP Value in QOS Changes in One Direction

Packets are remarked in one direction. It shows new Differentiated Services Code Point (DSCP) value in QOS when it passes through a point-to-point Layer 2 (L2) connectivity on Cisco ASR 9000. The L2 connectivity is configured via pseudowires, which are implemented over the MPLS network. There is no specific configuration to change the DSCP value for any of the related subinterfaces involved in this scenario. The original packets send from User A, which is marked as CS4, a DSCP value. However, the packets received by user-B shows the DSCP value set as AF41. This issue is seen in one direction only, that is from A to B.

 

Topology

Troubleshoot

Consider the fact that the traffic flows over L2VPN connection, you need to identify where the DSCP remark occurs in the network.

Packet capture is one of the way to confirm where and in which direction the DSCP value is changed. In this scenario, the traffic is captured from both directions. You can see the issue which occurs in one direction from ASR01 to ASR02. The DSCP values change as soon as it reaches to ASR02. The packet capture confirms that the DSCP values are changed after it leave the ASR01 router.

As per Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Configuration Guide, several methods are performed for the identification of the traffic flow within a single router, such as access control lists (ACLs), protocol match, IP precedence, DSCP, Multiprotocol Label Switching (MPLS) experimental bits (EXP) field in IP packets, or Class of Service (CoS). 

In order to mark the traffic, set IP Precedence or DSCP bits in the IP Type of Service (ToS) byte.

Verify Configuration

In order to find the root cause, you can verify the configuration.

Step 1. Verify L2VPN Configuration.

ASR01- Config:
==============
l2vpn
router-id 172.16.0.1
pw-class TEST 
encapsulation mpls
protocol ldp
!
bridge group DSCP-TEST
bridge-domain DSCP-TEST
mtu 9216
interface Bundle-Ether100.2048
!
vfi DSCP-TEST
neighbor 172.16.0.2 pw-id 2048
pw-class TEST
!
 
ASR02- Config:
============
l2vpn
router-id 172.16.0.2

pw-class TEST
encapsulation mpls
protocol ldp
!
bridge group DSCP-TEST
bridge-domain DSCP-TEST
mtu 9216
interface GigabitEthernet0/2/0/30.2048
!
vfi DSCP-TEST
neighbor 172.16.0.1 pw-id 2048
pw-class TEST

Step 2. Verify Interface Configuration.

There is an ingress service policy configured in the bundle interface 100, which is connected to the end users and carries multiple traffic for different L2VPN services. In order to differentiate the traffic, configure sub interfaces and use unique VLAN for each type of traffic.

ASR01- Interface Configuration:
================================
RP/0/RSP0/CPU0:ASR1# show running-config interface gigabitEthernet 0/1/0/4 
Thu Jun 1 13:17:37.642 AEST
interface GigabitEthernet0/1/0/4
description "TO User-A-TEST"
bundle id 100 mode active
mtu 9192
!
RP/0/RSP0/CPU0:ASR1# show running-config interface Bundle-Ether100.2048
Thu Jun 1 13:17:43.438 AEST
interface Bundle-Ether100.2048 l2transport
encapsulation dot1q 2048 second-dot1q any
mtu 9216
! 
RP/0/RSP0/CPU0:ASR1# show running-config interface gigabitEthernet 0/1/0/4.2048
Thu Jun 1 13:17:43.438 AEST
interface GigabitEthernet0/1/0/4.2048 l2transport
encapsulation dot1q 2048 second-dot1q any
mtu 9216
!
RP/0/RSP0/CPU0:ASR1# show running-config interface Bundle-Ether100
Thu Jun 1 13:20:43.438 AEST
interface Bundle-Ether100
description "To User-A"
mtu 9216
service-policy input INPUT   <<< ========================
service-policy output OUTPUT
bundle maximum-active links 1 
 
ASR02: Interface Configuration:
============================
 
RP/0/RSP0/CPU0:ASR2#show running-config interface gigabitEthernet 0/2/0/30.2048
Thu Jun 1 15:25:06.742 AEST
interface GigabitEthernet0/2/0/30.2048 l2transport
encapsulation dot1q any
rewrite ingress tag push dot1q 2048 symmetric
mtu 9216
monitor-session span ethernet
!
 
RP/0/RSP0/CPU0:ASR2#show running-config interface gigabitEthernet 0/2/0/30
Thu Jun 1 15:25:00.516 AEST
interface GigabitEthernet0/2/0/30
description "To User-B"
mtu 9216
monitor-session span ethernet
speed 1000
transceiver permit pid all
!

Step 3. Verify Service Policy Configuration.

The configuration indicates that there is a policy map for Video traffic which matches the packet marked as CS4 and remarks it to AF41.

Moreover, this policy is configured for another L2VPN service with different VLAN tag. However, it applies on the main bundle interface which affects all the ingress traffic meeting this condition.

policy-map INPUT
class CS4
set dscp af41
!
class-map match-any CS4
description Video Traffic
match cos 4
end-class-map
!
policy-map OUTPUT
class DSCP
set cos 4
priority level 2 
police rate percent 33 
conform-action transmit
exceed-action drop
!
class-map match-any DSCP
description Video Traffic
match dscp af41 
end-class-map

Recreate the Test Scenario In the LAB 

You can recreate the same scenario in the LAB and verify how this service policy configuration impacts DSCP values of the incoming traffic. 

Step 1. Configure the similar scenario without any service policy and capture the packet in the destination.

DSCP value is set to CS4 for incoming traffic and it remains same at the destination.
  

Ethernet II, Src: XeroxCor_00:0a:00 (00:00:01:00:0a:00), Dst: CiscoInc_e2:05:be (18:ef:63:e2:05:be)
    Destination: CiscoInc_e2:05:be (18:ef:63:e2:05:be)
    Source: XeroxCor_00:0a:00 (00:00:01:00:0a:00)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: 2020::1, Dst: 2020::2
    0110 .... = Version: 6
    .... 1000 0000 .... .... .... .... .... = Traffic class: 0x80 (DSCP: CS4, ECN: Not-ECT) << ============
    .... .... .... 0000 0000 0000 0000 0000 = Flow label: 0x00000
    Payload length: 20

Step 2. Apply the same service policy at ingress direction of the interface connected to the traffic generator.

Step 3. Generate two types of traffic. One with DSCP value set to CS4 and the second one with any other DSCP value.

The packet captured after ASR02 indicates:

When DSCP value of the incoming traffic is set to CS4, the packet received at destination shows the  DSCP value as AF41. However, if you set any other DSCP value, which doesn't mach the service policy criteria, the DSCP value of the packet remains the same when it arrives at the destination.

Ethernet II, Src: XeroxCor_00:0a:00 (00:00:01:00:0a:00), Dst: CiscoInc_e2:05:be (18:ef:63:e2:05:be)

    Destination: CiscoInc_e2:05:be (18:ef:63:e2:05:be)

    Source: XeroxCor_00:0a:00 (00:00:01:00:0a:00)

    Type: IPv6 (0x86dd)

Internet Protocol Version 6, Src: 2020::1, Dst: 2020::2

    0110 .... = Version: 6

    .... 1000 1000 .... .... .... .... .... = Traffic class: 0x88 (DSCP: AF41, ECN: Not-ECT) << ============

    .... .... .... 0000 0000 0000 0000 0000 = Flow label: 0x00000

    Payload length: 20

  

 Solution

The ingress service policy configured at the bundle interface (bundle 100) in ASR01 device re-writes the DSCP values for the packets which match its criteria. It searches for CS4 value and remark it with AF41. Therefore, you must remove the ingress service policy to resolve this issue.

Configuring Modular QoS Service Packet Classification document describes the policy inheritance. When a policy map is applied on a physical port, the policy is enforced for all Layer 2 and Layer 3 subinterfaces under that physical port.

This is the default marking behavior in ASR 9000:

When the VLAN tags or MPLS labels are added in an ingress or egress interface, the default value for the CoS and EXP moves to those tags and labels. The default value can be then overwritten based on the policy map. The default value for CoS and EXP is based on a trusted field in the packet upon ingress to the system. The router implements an implicit trust of certain fields based on the packet type and ingress interface forwarding type (Layer 2 or Layer 3).

By default, the router does not modify the IP precedence or DSCP without a policy-map being configured.

This is the default behavior of the router: 

• On an ingress or egress Layer 2 interface, such as xconnect or bridge-domain, the outermost CoS value is used for any field that gets added in the ingress interface. If there is a VLAN tag that gets added due to a Layer 2 rewrite, the incoming outermost CoS value is used for the new VLAN tag. If an MPLS label is added, the CoS value is used for the EXP bits in the MPLS tag.

• On an ingress or egress Layer 3 interface (routed or label weighted for IPv4 or IPv6 packets), the three DSCP and precedence bits are identified in the incoming packet. For MPLS packets, the outermost label of EXP bit is identified, and this value is used for any new field that gets added at the ingress interface. If an MPLS label is added, then the identified precedence, DSCP, or MPLS EXP value is used for the EXP bits in the newly added MPLS tag.