Egress NetFlow: Untangle “default” DSCP markings

Quality of Service (QoS) is used in enterprise networks to ensure that business-critical applications have the required priority and are not bogged down by non-business traffic when passing through the enterprise WAN link or even when traversing the Internet.

Cisco devices support a QoS model where packets can be treated with priority even by Intermediate Systems (IS) depending on its DSCP value. Based on a packet's DSCP value, the traffic is put into a specific service class and traffic conditioning functions such as marking, shaping, and policing are done to it. To ensure priority for preferred packets even after it leaves the network, the DSCP markings are done to the outbound traffic at the edge.

Take a traffic conversation moving from the LAN to the WAN with the default priority:

To achieve service delivery when this conversation moves over the WAN, a DSCP based QoS policy  that changes the packet’s DSCP marking from ‘default’ to a high priority ‘EF’ is applied on the outside of the serial interface.

Most enterprises use NetFlow for traffic analytics because NetFlow can provide details while not being resource intensive on the device as well as on the bandwidth. When enabling NetFlow on a Cisco device, the options available are Ingress NetFlow or Egress NetFlow and a majority of the network admins use Ingress NetFlow. With Ingress NetFlow, the IN traffic across an interface is captured. Because NetFlow data also has information about the interface through which the IP conversation exited the device, the same conversation can be attributed as the OUT traffic for the exit interface. So all NetFlow reporting tools can construct the OUT traffic for an interface from the information captured by Ingress NetFlow.

For the TCP conversation we discussed, Ingress NetFlow captures IN traffic at the Fa 0/1 interface where no QoS policy was applied and the DSCP marking was “default”. This conversation exits the router through Serial 1/1 and so the same conversation is attributed as the OUT traffic for Serial 1/1.

And that is the downside. Since traffic was captured by NetFlow from the inbound of Fa 0/1 where there was no QoS policy, the conversation was captured when its DSCP marking was on ‘default’. When the same conversation is attributed as the outbound of Serial 1/1, it will still be shown to have a ‘default’ DSCP marking though in reality the packets have been altered to have an ‘EF’ marking while it was exiting the Se 1/1. This is the behavior with any NetFlow reporting tool.

Then there is Egress NetFlow. Egress NetFlow captures the OUT traffic from an interface and from this OUT traffic, the IN traffic for the entry interface is constructed.

In our example, Egress NetFlow captures traffic when it exits the Serial 1/1 interface but with the correct outbound DSCP marking of EF. This way, your NetFlow reporting tool can report on IP conversations with the modified DSCP marking rather than the pre-QoS policy DSCP marking.

There are other advantages too with Egress NetFlow – such as where you use WAN compression, Egress NetFlow captures traffic after the compression and not at the original level. This way, you see the actual volume of traffic that exited your device and not pre-compression traffic volumes.

To apply Egress NetFlow on your interfaces, use the command “ip flow egress” (traditional NetFlow) or “ip flow monitor monitor_name output” (Flexible NetFlow) and that should get you ready for traffic capture with the correct DSCP values. And if you have not yet used NetFlow, try it with a network traffic monitor to monitor traffic as well as to validate your QoS policy performance.

30 Day Full Feature Trial | Live Product Demo | Product Overview Video | Twitter