Check out the most advanced Cisco NetFlow capabilities on April 17th when we co-host a webcast with Cisco on Performance Routing (PfR) and network traffic management with Flexible NetFlow.
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
Cisco Performance Routing (PfR) and NetFlow
PfR was well defined by Samuel Yee: “For most medium-to-large networks, you would usually have more than 1 ISP to connect the enterprise network to all the remote sites. Traditional routing (such as OSPF, BGP etc) could route network traffic through a preferred path or load-balance among different paths. It can also automatically change path when a link is dead. For many companies however, this still isn’t good enough.
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
Cisco IOS IP Service Level Agreements (SLAs) help network administrators ensure that a high level of voice and data communication quality is maintained. Cisco IP SLA operations are a proactive method of reliably measuring network performance. IP SLA data can be retrieved and trended with an SNMP Performance trender to enable users to graph performance over time. Cisco IP SLA and SNMP should be in the tool belt of every network administrator. Pair these technologies with a NetFlow analyzer and you’ve got a great setup to help troubleshoot most network problems.
The purpose of this blog is to outline some of the IP SLA configuration changes in newer versions of Cisco’s IOS.
We’ve written a 4-part blog in the past that focuses on the following IP SLA operations:
SteveFor a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
Cisco IP SLA is useful in so many ways, it’s not even funny. There is no doubt that IP SLA can be useful for long term performance trends and in documenting how well, or how bad your network is behaving.
Cisco IP SLA is a lot more than just a monitor for ping, jitter, and packet loss over TCP and UDP. There are so many great tools to use, it’s amazing! Using IP SLA, we can retrieve measurement metrics like round-trip time, packet loss, network jitter, and connectivity.
Current monitor types for IP SLA include jitter, FTP, DNS, DHCP, DLSW, ICMP, UDP, TCP, HTTP, and LDP. Cisco also has a few more types in the pipe. Soon we’ll see H.323, SIP, RTP, RADIUS and video.
I’m sure we can all agree that a key for successful troubleshooting is using the right tools for the job. The job being to detect the problem as quickly and as efficiently as possible right? Right… We don’t have all day to sit and stare at a screen to catch a blip, and this is where the value of setting up IP SLA thresholds and notifications comes in.
IP SLAs can generate SNMP traps upon the violation of a threshold. Because these are traps, we’re going to need to import MIBs to the log manager so that it can decode the OIDs properly. You will want to download the CISCO-SYSLOG-MIB, and the CISCO-RTTMON-MIB.
We can generate events for each violation, whether they be consecutive violations, X of Y violations (to generate a trap), or averaged violations.
If the situation deems necessary, we can configure an IP SLA monitor to activate a second IP SLA operation to gather additional data. IP SLA reaction configurations are done using the ”ip sla monitor reaction-configuration” command via the terminal console.( or ip sla reaction-configuration for those of you whose IOS doesn’t like the word “monitor”).
To tie it all together, using router thresholds and notifications can be a useful tool in troubleshooting a large variety of the “hard to track problems.” Using thresholds and notifications benefit us in troubleshooting problems that happen intermittently, or at odd times. For detailed instructions on how to set these up, Cisco has a white paper on the exact commands to use. Check it out: IP SLAs –Proactive Thresholding Monitoring.
Also check out the 4 part blog on Cisco IP SLA Configuration.
Do like the Shat… Use Cisco IP SLA.
Steve
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
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.
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
There is no question that our Network monitoring tools are our eyes into how our network is being utilized. Moreover, to truly gauge the efficiency of changes made to the network to increase efficiency, it’s critical to have performance trends before and after changes are made.
Scrutinizer QoS reporting can be the key to troubleshooting or evaluating network performance of traffic going through QoS queues.
Today we’ll talk about how we can use Scrutinizer’s custom reporting to analyze the traffic associated with QoS and class maps.
We know that to create a class map, we can specify the DSCP value we want to be included in the class map. In the map below we can see that EF in the name column corresponds to a codepoint of 10111000, for example.
Scrutinizer allows class map reporting by simply adding the Diffserv codepoints assigned to the DSCP Values of your class map to your custom report. It’s just like as if you were creating a class map, except instead of the DSCP Value you use the codepoint.
Let’s say we have a router with a VoIP class map configured to include the EF DSCP Value. Let’s also say we want to analyze traffic associated with this class map on this specific router.
All I need to do now is to create a custom report in Scrutinizer where I have included the 10111000 (EF) Codepoint, select interfaces belonging to this router, and I’m instantly viewing a report of all the traffic flowing through my VoIP class map.
We can also use this same technique to create a custom report on a class map that hasn’t been rolled out yet, so that you can verify that the changes made to the router configuration have resulted in the changes intended in traffic flow.
Ideally, the administrator would pair this with a Cisco IP SLA Jitter monitor that would also give stats on:
• Latencies including source to destination, destination to source, and jitter.
• MOS Score if the class map affects VoIP Traffic
• Packet Loss metrics including late, or out of sequence packets, and tail drop.
By comparing the before and after statistics, verification can be made of increased efficiency and everybody is happy.
If you would like information on how to setup the Cisco Jitter IP SLA, check out the 4 part Cisco IP SLA Blogs on Systrax.
Steve
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
Hello Everyone,
If you would like to see other blogs on how to setup IP SLAs check out these links.
IP SLA – Jitter – 1 of 4
IP SLA – ICMP Echo – 2 of 4
IP SLA – TCP Connect – 3 of 4
We’ve arrived at the fourth and final part of this series. In this blog, we’re talking about the Cisco HTTP IP SLA operation and some ways that it can be useful.
The HTTP IP SLA operation is a very useful tool in the verification of performance of Web servers, Proxy servers, or any other HTTP server.
There are 3 measurements that will provide a total round trip time measurement for the HTTP operation:
• DNS lookup: How much time it takes to complete a domain name lookup.
• TCP Connect: How much time it takes to complete a TCP connection to the HTTP server.
• HTTP transaction time: How long it took to send a request and get a response from the HTTP server.
A good use for this monitor is to confirm that performance stays within the acceptable limits of an SLA and also to gauge your user’s perceptions as to how fast the connection is.
The HTTP IP SLA operation can also be used to monitor proxy servers. One is example is with a VRRP deployment where there is an HTTP proxy server involved. If the HTTP IP SLA operation reports a failed connection to the proxy server, a failover process can be initiated automatically so that a secondary router continues to forward all HTTP requests to the proxy server.
The DNS lookup time is an important factor to a good overall user experience.
“How MySpace is hurting your network”, a Networkworld.com article, explains how social networking sites like MySpace and Facebook may exponentially increase the number of DNS lookups, impacting the performance of your network. You may want to check out your netflow analyzer to see whether too many users are checking out these sites.
Cisco IP SLAs can make a huge difference in how well network administrators can increase efficiency of their network. Pair Cisco IP SLAs with Netflow, good SNMP and Netflow Analyzing applications and you’ll have a winning combination of tools to make sure your network is well tuned.
Thanks for reading this series, good luck and have fun setting up the IP SLAs!
Sincerely,
SteveFor a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
Hello Everyone,
If you would like to see other blogs on how to setup IP SLAs check out these links.
IP SLA – Jitter – 1 of 4
IP SLA – ICMP Echo – 2 of 4
IP SLA – HTTP – 4 of 4
This week we are focusing on the Cisco IP SLA TCP Connect operation. One can consider this to be a ping over TCP. The TCP Connect operation can be useful in several ways. Administrators can set it up to baseline existing performance, and also to monitor changes in performance due to configuration changes.
Some companies use this monitor for their own verification of outsourced service provider SLAs. This information can then be used to negotiate more cost effective SLAs with their service providers.
The TCP Connect operation is also a great alternative to measure response times when ICMP ping is blocked.
If you would like detailed instructions on setting up the Cisco TCP Connect IP SLA operation, check out our white paper on how to set it up.
Check out the next and final part of the series – HTTP IP SLAs.
Steve
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
Hello Everyone,
If you would like to see other blogs on how to setup IP SLAs check out these links.
IP SLA – Jitter – 1 of 4
IP SLA – TCP Connect – 3 of 4
IP SLA – HTTP – 4 of 4
In my first blog, we covered the Cisco Jitter IP SLA Operation and how to set it up. This week the focus will be on the ICMP Echo Operation.
The ICMP Echo IP SLA Operation measures end-to-end response time between a Cisco router and any device with an IP Address. The response time is computed by measuring the time taken between sending an ICMP Echo request and receiving an Echo reply.
The ICMP Echo operation can be useful in several ways. Administrators can set it up to baseline existing performance, and also to monitor changes in performance due to configuration changes.
This operation is easy to set up, and the information made available makes this a great tool for any administrator.
Check out our whitepaper for detailed instructions on how to set it up.
Check out Part 3 of the series focusing on TCP Connect IP SLA.
Steve
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
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
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.
Steve
For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!
