ToS, DSCP and NetFlow…. what the DiffServ? Part 4
Posted in NetFlow on August 18th, 2009 by mike@plixer.com
This is part 4 of an 4-part series (so far 4 parts) on the ToS field (i.e. Differentiated Services Field) of IP frames. I finally get into how all this relates to NetFlow in 2009. Make sure you have already read Part 1, Part 2 and Part 3 of this blog.
ToS and DSCP part 4
At the end of Part 3 of this blog series I digressed very briefly on how CBQoS can be used to modify DSCP values on packets which come into the router. In other words, VoIP traffic that comes in on ports 4569 and 5060 could enter a router with one DSCP value 0×00 and leave with a completely different one e.g. 0xEF (i.e. 11101111).
The BIG Question:
How can you confirm that the DSCP value was actually changed? This is important because we might want to make sure using DiffServ that VoIP gets top priority on the network. Fortunately, Scrutinizer provides a way to confirm these changes.
Because we are collecting NetFlow v9 with ingress and egress turned on, we can filter (in Scrutinizer v7) for the destination address (66.186.184.194) after adding both the in (Fa0/0) and out (Fa0/1) interfaces to the report:
Above, 66.144.184.144 is the destination (dst) when it comes in on one interface and when it goes out the other interface. It is important that this be recognize. This is why both ingress and egress flows be exported.
Here are the results; notice the flow looks exactly the same except for the ToS field when it comes in Interface 1 and goes out Interface 2:
(click to expand)
There you have it. :) The flow came in with a DSCP value of 0 and went out with a DSCP value of 46. DiffServ is cool. Your NetFlow Analyzer must be able to report on DSCP values using ingress and egress flows in the same report.
ECN bits are being set in the ToS!
Remember, I joked about the Currently Unused (usually) bits in part 3. Let’s make this a 5th blog in this 4 part series…..
Scrutinizer Product Manager
Follow Me on Twitter
[...] with ingress and egress flows to confirm that DSCP values were changed. I’ll dive into this in blog 4. Michael Patterson Scrutinizer Product Manager Follow Me on Twitter Share and [...]
hi
Can I use Scrutinizer to measure the QoS parameter (delay,loss,jitter, throughput)
Hello, To look at IP SLA information (i.e. delay,loss,jitter) you should be using an SNMP utilitiy like Denika. http://www.plixer.com/products/denika.php
Throughput is possible with NetFlow and Scrutinizer.
Mike
Hi Mike Patterson
Is Denika measure the QoS parameter (loss,delay,jitter) for voip only??
I need to measure these parameters for all applications (i.e. video, http, email,Ftp, videoconference, voice …) ,i.e measure the parameters of each one of applications separately
can Denika do that??
thanks
I believe that There are Jitter operations that can be configured for ICMP operations, but not for standard HTTP gets or calls to services running on NON IP SLA “responder” devices. Jitter is measured both to and from the responder router so the poller/agent relationship is needed for this.
Below are the operations available in IPSLA (in IOS 15.0).
operations IP SLAs entry configuration commands:
dhcp DHCP Operation
dns DNS Query Operation
ethernet Ethernet Operations
exit Exit Operation Configuration
frame-relay Frame-relay Operation
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo Operation
icmp-jitter ICMP Jitter Operation
mpls MPLS Operation
path-echo Path Discovered ICMP Echo Operation
path-jitter Path Discovered ICMP Jitter Operation
tcp-connect TCP Connect Operation
udp-echo UDP Echo Operation
udp-jitter UDP Jitter Operation
voip Voice Over IP Operation
So you have the option of UDP Jitter operations, ICMP jitter and VOIP to provide Jitter statistics.
Generality, time sensitive applications use UDP, I think Cisco realized that there is not much need for TCP Jitter operations like the ones with HTTP monitors since TCP overhead brings jitter to unacceptable levels.
Here is an example of what you get with HTTP operations(via SHOW IP SLA STATISTICS command):
IPSLA operation id: 1
Type of operation: http
Latest RTT: 314 milliseconds
Latest operation start time: *17:32:50.715 UTC Fri Feb 12 2010
Latest operation return code: OK
Latest DNS RTT: 12 ms
Latest TCP Connection RTT: 57 ms
Latest HTTP Transaction RTT: 245 ms
Number of successes: 11
Number of failures: 0
Operation time to live: Forever
Here is the info you can get with a UDP Jitter operation
Type of operation: udp-jitter
Latest RTT: 92 milliseconds
Latest operation start time: *17:32:50.831 UTC Fri Feb 12 2010
Latest operation return code: OK
RTT Values:
Number Of RTT: 1000 RTT Min/Avg/Max: 85/92/139 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/4/31 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/4/30 milliseconds
Packet Loss Values:
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 1
MOS score: 4.34
Number of successes: 10
Number of failures: 0
Operation time to live: Forever
All of the above numbers can be graphed in Denika using the CISCO-RTTMON-MIB as long as it is available from the IOS. Path Jitter is not supported by RTT-MON MIB though.
You may or may not need to create new templates for some of these.
The good news is that you can pester Plixer’s presales engineers or support team to help you. They absolutely LOVE this stuff!
I suspect that Cisco will be increasing their SLA monitoring offerings soon because this segment of monitoring is growing so fast.
I hope my long winded answer better explained what you can do with IP SLA and Jitter.
Thanks Michael Krygeris for your answer and all the detail