Distributed network monitoring with IP SLA!
The Cisco IP Service Level Agreement (IP SLA) technology is nothing new to network engineers. In its basic operations, IP SLA enables routers and switches to use a protocol like ICMP to check end-to-end response time between the device itself and a destination IP device.
As stated in the Cisco IP SLA configuration guide, “IP SLAs uses active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance”.
One of the most common uses of IP SLA is configuring floating static routes to determine the preferred active link or, in HSRP, to assure that the router with the highest priority to take over that gateway function has access to the default route.
Configuring IP SLA for basic operations is fairly simple. The following example shows how to configure a ping test with IP SLA with a 15 second interval and 5 seconds of timeout:
ip sla monitor 6
type echo protocol ipIcmpEcho 126.96.36.199 source-ipaddr 10.0.0.1
ip sla monitor schedule 6 life forever start-time now
IP SLA not only permits the verification of connectivity and network performance of network infrastructure, but also the monitoring and troubleshooting of application issues. For example, other protocols like DNS, HTTP, and VoIP are available and can be used to verify DNS and HTTP response time or Mean Opinion Score (MOS).
If you are looking to monitor application performance using IP SLA, one thing to keep in mind is that the source of the traffic shouldn’t be a router, but a real end user device plugged into the access layer. Otherwise, the actual measurement and troubleshooting will lose visibility in the “last mile”. In this specific case, the last mile is the network portion between the router and the access layer where users connect.
The implementation of an active distributed monitoring solution like NetBeez allows you to run the same set of tests available in IP SLA but on an end-user device, generally a dedicated probe like the Raspberry Pi or an existing Linux workstation. This way, you can monitor the real end-to-end connectivity and performance between a client and a server, like an HTTP or DNS transaction, or between two clients, like it is the case for voice or video conferencing communications.
Here are the two most common scenarios where a distributed network monitoring solution can really make the difference between a reactive and a proactive way to detect and handle network issues:
- Monitoring and enforcing service level agreements with Internet service providers: In this case, network administrators have a way to continuously verify the uptime and performance (packet loss and round-trip-time) of their remote offices’ WAN links and proactively detect connectivity issues.
- Verifying availability and response time for web and DNS services through periodic HTTP requests and DNS queries performed from different network segments (e.g. distributed network monitoring). This technique not only enables proactive detection of service outages, but also pinpoints whether the problem is limited to only one location (one sensor), thus indicating a local network problem, or common to all the sensors, indicating a global problem with the service itself.
This screenshot replicates the aforementioned IP SLA configuration: a continuous ping test running from a NetBeez agent to a Google DNS server with a 15 second interval and a 5 second timeout.
As you can see in this case, the network sensor running the ping test triggered an alert because the average packet loss for the last 15 minutes was above the 10% threshold set. This is a very simple example where active monitoring can lead to quick detection of performance issues before they cause further inconvenience to your end users.
When enough active sensors are installed on the network to provide proper coverage to all the user locations, network or application performance issues can be very easily detected and troubleshot.
If you want to learn more about NetBeez, please check out this PDF, which gives an overview of the specifications and features of the system.
Stefano Gridelli is cofounder and CEO of NetBeez(netbeez.net), a Pittsburgh-based company that has released a distributed network monitoring solution for enterprises. Before NetBeez, Stefano worked as a network engineer, leading network design and implementation projects in complex network environments. He is Cisco CCNP certified and holds a Service Routing Architect (SRA) certification from Alcatel-Lucent.