ToS, DSCP and NetFlow…. what the DiffServ? Part 3

Posted in NetFlow on July 30th, 2009 by mike@plixer.com
tos-dscp-and-netflow-what-the-diffserv-part-3

This is part 3 of a series on the ToS field (i.e. Differentiated Services Field) of IP frames. I’m getting closer to how it relates to NetFlow and sFlow.  Make sure you have already read Part 1 and Part 2 of this blog.

ToS part 3
In this blog I copy largely from RFC 2474, which was written in 1998. I discuss how 6 bits of the 8-bit ToS is now the Differentiated Services Code Point. See the screen capture below from my first blog. This is where we are today however, many of us still refer to this field as ToS (i.e. type of service). Sometimes it is called the Differentiated Services Field (DSF) but, not as often.  Read more »

Michael Patterson
Scrutinizer Product Manager
Tags: , , , , , , , , , , , , , ,

The essence of a network map using Cisco NetFlow, sFlow and SNMP

Posted in NetFlow, Network Health Report, Scrutinizer, Third Party Integration on March 17th, 2009 by Jon Mills

What makes a network map good? Useful?
Usually when a customer asks me about the Scrutinizer network maps, I start by saying something like, “We are not a netw+ork map company,” and then I answer the question. Why do I say this? After all, most of our customers like the presentation of our network maps and their unique diagramming ability. I think this is primarily because we have good third-party integration and because the connections between devices change color based on utilization. Connections can change color for more than just Cisco NetFlow; they can also change based on nearly any SNMP OID value like IP SLA MOS (i.e. Mean Opinion Score) values. I’ve also seen NBAR and port errors used to change the color of a link based on a threshold.

Today’s networks are more reliable
I think that’s true; most networks today aren’t seeing the outages we witnessed in the mid-90s. I can remember sitting in tech support at Cabletron Systems telling people to reset the IRM or EMME in the MMAC hub to get the network back up. I think back then people generally accepted the fact that the network was kind of finicky. Today, users don’t take outages in stride as much. This has led to boring network maps with icons that seldom leave the color green.

The largest networks in the world
One of the things that we’ve learned from working on some of the largest networks in the world is that administrators want to be able to answer the question, “Why is it so slow?” Scrutinizer maps outline link by link the major paths through the network, and highlight congested areas of the infrastructure better than most tools on the market. So what is missing?

No auto discovery
Scrutinizer maps are manually created. There is no auto discovery to create the links between devices for you. I encourage customers to limit Scrutinizer maps to the backbone. However, I often witness diagrams with connections to every end user switch. I’ve asked why they put in the time and usually hear something like, “It doesn’t take that long, and my manager loves the maps in Scrutinizer.”

Expect more in Scrutinizer v7
Because of positive customer feedback, we will pour more engineering into Scrutinizer maps in future releases. This will include greater third party integration, which I will extrapolate on later.


Jon Mills
Marketing & Public Relations Manager
Follow Me On Twitter
Tags: , , , , , ,

Plixer and Cisco IP SLA: Jitter – Part 1 of 4

Posted in Denika, General, IP SLA, Network Problem Resolution, Scrutinizer on December 29th, 2008 by Raul J Duran

Hello Everyone,

If you would like to see other blogs on how to setup IP SLAs check out these links.

IP SLA  – ICMP Echo – 2 of 4
IP SLA – TCP Connect – 3 of 4
IP SLA - HTTP - 4 of 4 

I’m going to be putting together a four part series on some common Cisco IP SLA monitor configurations.  Cisco IP SLAs are great ways to get statistics on different types of communications between routers.  They’re relatively simple to set up, and reports can be generated by an SNMP trender.

focus on the Jitter monitor.  You can get a ton of information from the Jitter monitor, starting with latency, Packet Loss, and Jitter.  If the router’s clocks are synchronized you can also get the latencies for each way.  By adding a VoIP codec to the monitor, the router can generate the Mean Opinion Score (MOS), and the Impairment/calculated planning impairment factor (ICPIF) score.

Check out Plixer’s white paper on setting up the Jitter operation.  It will walk you through setting up a Jitter monitor, how to trend the statistics, and generate reports.

If you plan on using the jitter operation to monitor VoIP, pay special attention to make sure that you are using the codec that matches the actual codec being used.

It is also important to have realistic expectations on MOS values pertaining to each codec.  Although Cisco’s scale is 1-5 in their documentation, production environments will not see a 5.  The chart below will help in determining how well your communications are doing.

Cisco VoIP Codec White Paper

Cisco VoIP Codec White Paper

Scrutinizer Netflow Analyzer has a My View page that contains gadgets that can integrate with third party applications.  One of these applications is Denika which can trend the IP SLA statistics.  If you have Scrutinizer and Denika ask us about a custom VoIP gadget to display VoIP IP SLA Statistics.

plixer-ip-sla-voip-monitor
Check out Part 2 of the IP SLA series.

Raul

Tags: , , , , , , , , , , , , , ,