Did you know that you could create network maps for each of your locations (physical office or wiring closet) with Scrutinizer? Did you know that you could plot your locations worldwide using Google maps? Or integrate other vendor’s applications in Scrutinizer, to view device statistics with the click of a mouse? (click on mouse to test)
If you would like to see other blogs on how to setup IP SLAs check out these links.
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.
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.
Check out Part 2 of the IP SLA series.
Well, it can be a simple and painless process, with the actual file download being the lengthiest step. Or, with large networks, it can be near to a nightmare configuring the algorithms to complete in the time allotted.
Have you ever been drilling in on a host in your NetFlow or sFlow analyzer hoping to get the kind of juicy details you get with a packet analyzer like Wireshark? If so, you have felt the disappointment that comes about when the details simply aren’t there. Why does this happen and what can be done about it?
The Limitations of NetFlow
NetFlow is an aggregation of traffic. For example, if my PC sends 800 packets to John’s PC and John’s PC sends 20 back to me. This becomes two flows. A single NetFlow v5 packet can contain up to 30 flows (NetFlow v9 contains up to 24). It is easy to understand how a single NetFlow UDP datagram can represent over a dozen hosts communicating over the network with thousands of packets. NetFlows aggregation is pretty good. Alas, it has short comings as well.
What is in NetFlow v5
Because of NetFlow’s aggregation, we only get a few details. For example:
* Source and Destination Interfaces
* Source and Destination Ports
* Source and Destination Autonomous System
* Source and Destination Address Prefix Mask
* Protocol (UDP, TCP, etc.)
* Total Packets, Total Octets
* Start and end times of the flow
* TCP flags
* ToS (i.e. for DSCP)
See more on V5 & V9 NetFlow packet formats
Compare NetFlow to Wireshark
Q: What if you want the raw packets like you get in Wireshark. Can you get the details to and from a host using NetFlow?
A: You can’t get all of the same details but, if you are using Scrutinizer NetFlow & sFlow Analyzer you can get a list of all the flows to and from the host as shown below. This is about as good as it gets with NetFlow and Scrutinizer can do it.
This is just the beginning of what it takes to display NetFlow in HD (High Definition).
If I got a nickel for everytime I’ve seen the symptoms shown below…I could afford to be in the Bahamas right now. But instead, I get the joy of watching all the weather alerts for the state of Maine about the incoming Nor’ Easter. *sigh*
I’m sure many of you may recognize the behavior shown in the above screenshot. You have your devices discovered by Scrutinizer, but there’s no way to know what interface it’s trending because all you see are numbers. This blog may help you out with this issue.
When you discover a device, Scrutinizer attempts to do an SNMP GET to grab definitions for the following:
– Name of the device
– Descriptions of the interfaces
– Port speed associated with each interface.
If you didn’t create a credential in Scrutinizer for your personalized community string prior to the initial discovery, then Scrutinizer would have attempted the discovery using the PUBLIC community string, and you’d be seeing symptoms much like the screenshot shows. Just a bunch of numbers…no details.
If you are certain that you are using the correct community string and yet running an SNMP update still doesn’t work, I would suggest downloading a MIB Browser called GETIF.
GETIF is a really nice 3rd party tool that I use here in the office to diagnose problems such as this.
With GETIF; just provide the IP address of the device in question, the community string that the device should be using and it will test SNMP connectivity using a generic OID.
If GETIF is able to return a value for that OID, then we know the community string that you have defined is correct. Which would turn our focus to Scrutinizer and the credential you created.
If however, GETIF fails to return a value, then we know there’s an issue with the community string that you are using.
I had an interesting call today. A customer who works for a government agency needs to protect very sensitive data within Scrutinizer. He asked if they could control which IP addresses were allowed to connect to his Scrutinizer Web Interface. Specifically, he wanted to deny all connections except for when Scrutinizer was accessed from the local server.
We can do this with a simple edit of the apache httpd.conf file. The file is located in the Scrutinizer/Apache2/conf/ directory. Before making any modifications, you make a copy of the current httpd.conf file so that you can revert to it in case of any problems.
Within the http.conf file look for the following lines:
Modify the lines above to look like the lines below and save the file.
Restart the Scrutinizer_apache2 service so that the changes are applied.
This server will now deny every host attempting to connect to Scrutinizer Web interface with the exception of IP address – 127.0.0.1.
This configuration now forces users to Log in from the local server just to be able to access the web interface subjecting them to any security measures applied to users logging on to a server.
Although this configuration limits access to only one specific IP, it is possible to specify which domains and networks have access and those that don’t.
Today I was working with a customer on an install when we started going down memory lane. He asked how I liked Gotomeeting and I mentioned that nowadays it’s common for us to use it to demonstrate or install Scrutinizer. Trying to be funny I showed my age and said “back when I was a ‘young pup’ we had to do installs like these blind folded, over dial-up, up hill both ways.”
We both chuckled for a few minutes, swapped a few stories and continued with the install. We both agreed that it was nice to be able work on a machine remotely.
The install that we were working on was for our new Flow Analytics module. I don’t know why, but our walk down memory lane made me think . The “Top” gadgets that are included in Scrutinizer’s Flow Analytics package are a great tool. Don’t get me wrong; I thought that they were valuable before, but being able to associate their value with past hard-ships (up hill both ways) made it clear.
I mean, you can see “Top Conversations”, “Top Application”, “Top Protocols” and more, from all of your routers on your network. Think about it, you could see who your “Top Talkers” are from around the world in one easy to see and manage place. How awesome is that? How much time can that save you?
Just like GotoMeeting in the early 90’s, this type of information was not easily available a year ago. Flow Analytics is definitely the future of NetFlow.
Breaking news . . . . .
Scrutinizer Flow Analytics 1.1.0 beta was released today.
“I wonder if I can buy an old 8086 with a 2400 baud modem on ebay? Now that was a processor. Back when I was a kid . . . “
It is interesting what vendors will call free. A free 30 day evaluation to many vendors is really just an evaluation. I guess this is sort of free….. in a way.
Our free version of Scrutinizer NetFlow and sFlow Analyzer is exactly that: FREE. Sure, there are ads that won’t go away unless you have a license key and we drop most of the data at midnight and restrict a few other features but, it doesn’t expire: EVER and the feature set is robust!
The free version of Scrutinizer will collect flows (i.e. NetFlow, sFlow, IP FIX, NetStream, JFlow, etc.) from unlimited devices and interfaces for free. Thousands of free users appreciate our free version. Hopefully, they will someday buy, time will tell.
I just got off a support call about Scheduled Reports in Scrutinizer.
If he scheduled a Custom Report through the Scheduled Reports function in Settings, then all was well, he got exactly the report he expected.
But if he went to Status page, then selected an interface, and clicked on the green down arrow on the left and selected Schedule Report, every time the report ran, he got the same report for the same date – December 9 12:00pm to December 10 12:00pm, even though the time frame was set to last 24 hours.
We had an interesting weekend in Maine. The first ice storm of the season seemed to be a bit problematic for all of us, but it could not stop the Plixer Christmas adventure. The ice knocked out power to our office as well as to an estimated 220,000 homes and businesses in Maine. Some of us are still without power. In this mess, there were some amazing sights only an ice storm can create. I was struck by how the trees encapsulated in ice captured the sun light and lit up the trees. Billions of lights flickered in the winter breeze glimmering on a magnitude that no man made string-o-lights could ever produce.
Every year Plixer does something special for its employees during Christmas. Our Plixer Christmas event had been planned for this weekend; Ice storm or not the show still went on. “The Magic of Christmas” was the title of an amazing show that showcased the Portland Symphony Orchestra. The title was fitting as these great musicians played together in unison – truly magical. I couldn’t help but draw metaphors on what great things can be accomplished with teamwork, a good listening ear, and timing within our networks.
If one musician would have been out of time or delayed in any way, it might have ruined what could have been a perfect . Why should we expect anything less from our Voice communications? In order to listen, we need the right tools to monitor latency, jitter, MOS, and packet loss. Cisco already provides us with these tools (Cisco IP SLA), and all we need to do is configure, and trend it.
The IP SLA statistics can be retrieved through SNMP. The Denika SNMP Performance Trender is the perfect tool to deliver the Cisco IP SLA reports. There are IP SLA MRTG templates already built in to Denika that allow users to create hundreds of reports in seconds. The fact that most configurations are already done makes it quick and simple to deploy. Plixer also has a special My View gadget so that you can see your VoIP statistics within Scrutinizer. 3rd Party integration in both Scrutinizer and Denika allow it to play well with other network monitoring tools. With the right tools, it won’t take years to have your network sounding like a world class symphony orchestra.