h1

Using Netflow’s verbose output with QOS

July 15, 2009

In the previous article I showed how useful Netflow can be, but that is only the beginning. The “verbose” output provides even more useful information, specifically the TOS-Byte. That field is necessary when you want to verify if QOS marking is correctly applied to traffic classes.

But first you have to understand a little about QOS (Quality of Service) and the TOS-byte/DS-Field in the IP header.

The IP header is defined in RFC 791, includes a 1-byte field called the Type of Service (ToS) byte. The ToS byte was intended to be used as a field to mark a packet for treatment with QoS tools. The ToS byte itself was initially further subdivided, with the high-order 3 bits defined as the IP Precedence (IPP) field. Bits 3 through 6 were not used very often, and bit 7 was never defined, so over time the entire ToS byte’s purpose was to hold the 3-bit IPP field. 3 bits (23 = 8 ) allowed 8 possible markings.

Tos-Byte

With the need for more than 3 bits for marking, a series of RFCs collectively called Differentiated Services (DiffServ) was developed and  standardized a redefinition of the ToS byte. The ToS byte itself was renamed the Differentiated Services (DS) field, and IPP was replaced with a 6-bit field (high-order bits 0–5) called the Differentiated Services Code Point (DSCP) field.  The Diffserv Model does include values for Backwards compatibility for 3-bits IPP field. Later, RFC 3168 defined the low-order 2 bits of the DS field for use with the QoS Explicit Congestion Notification (ECN) feature. For a complete list of the DSCP values go here.

DS-Field

.

Why is relevant to the verbose output of Netflow. Simply put the difference of 2 bits.  The DiffServ Model’s DSCP decimal values only represent the first 6-bits of the DS-field where the TOS-Byte coloum in the verbose output, represents the full DS-Field (8 bits) in Hex.  So in order to interpret the output you need to know how to work out the value you are looking for or expecting to see.

Look at the following verbose output to see how to do the conversion:  (some info is omitted for brevity)

cache flow verbose

The “verbose” keyword is used, and as a result one can see the TOS field amongst other fields are now showing extra.
The first flow has a TOS-Byte (DS-Field) value/marking in Hex of 48:

  • Convert 48 in hex to binary to get the 8-bit breakdown : 48 = 01001000
  • Since we are only interested in the first 6 bits that make up the DSCP value, remove the last 2 zeros.
  • Convert the remaining 6 bits (010010) to decimal
  • And you will get a DSCP decimal value of 18 or AF21

Lets look at the last flow. What does a TOS-Byte value of 28 in Hex give you?

  • 28 in hex = 00101000 in binary
  • Remove the last 2 zeros.
  • 001010 in binary = 10 in DSCP Decimal or AF11

Easy Right? Obviously  converting from a DSCP Decimal (6-bits)  value to a TOS-Byte (8-bits) works just the other way around.
Lets take DSCP decimal value 46 or EF which is commonly used for voice:

  • Convert 46 to binary : 101110
  • Add 2 zeros to the end  (the ECN bits) to complete the DS-Field
  • Convert 10111000 to hex  to get the TOS-Byte value of  B8

One last thing to mention about the output of Netflow. This shows traffic flow and their statistics BEFORE ANY local  input interface markings.
So the traffic one see in the output above, has already been marked with the respective QOS values at least 1 hop before, regardless whether or not any remarking is configured on the input interface.

Advertisements

One comment

  1. Thank you so much for the explanation of great concept in smple words.



Please leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s