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.
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.
.
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)
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.
Routing-Bits 
Thank you so much for the explanation of great concept in smple words.