Symptom
Exported Netflow packets over IPv6 transport do not follow the configured DSCP value which is to be used in the traffic-class field in the ipv6 header of the Netflow export packet.
Conditions
Explicitly configured TC/DSCP value under flow exporter is not correctly reflected in IPv6 header.
Example configuration
---------
flow exporter-map exporter6
version v9
options sampler-table timeout 180
!
dscp 48 <<< dscp configuration
transport udp 9985
snippet of packet decode with above configuration
-------------
Internet Protocol Version 6,
0110 .... = Version: 6
.... 0011 0000 .... .... .... .... .... = Traffic Class: 0x30 (DSCP: AF12, ECN: Not-ECT) <<< dscp is not 48 as expected.
.... 0011 00.. .... .... .... .... .... = Differentiated Services Codepoint: Assured Forwarding 12 (12)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Workaround
The issue is that the dscp value is right shifted by 2 bit positions. For example if dscp configured is 48, actual value used is 12 (48 >> 2 = 12). Similarly when dscp configured is 63 (the maximum configurable value through CLI), actual value used is 15 (63 >> 2 = 15).
This means that a dscp value from 0 to 15 is still configurable and usable, by configuring a value left shifted by 2 (as an example, to set dscp 15 in the export packet, set value as 63 in the CLI). But a dscp value higher than 15 is still not configurable by this method.
Further Problem Description
This issue affects all IOS-XR platforms. There is no traffic impact. This issue affects all releases prior to 7.3.3, 7.4.2 and 7.5.1. It is fixed on 7.3.3, 7.4.2, 7.5.1 and further releases. Netflow export using ipv4 is not affected.
If the "dscp" command is not used, then this issue can be ignored because the default dscp value of 0 will be used by the system.
