Sponsored Post: IP SLA What, Why and When?
The IP SLA is a very powerful tool for monitoring the health of your VoIP network.
The IP SLA is a very powerful tool for monitoring the health of your VoIP network. Using it properly usually requires finding a good middle ground that provides you the monitoring you need without having any negative effects. The last thing you want after a switch goes down (or even just the PoE on a mod, or whatever) is for your phones to stagnate when they should be trying to reestablish the service connection. With late night changes, you could wind up staying up at the office waiting for the phones to come back up so you can confirm service. During the day, well, that just kills your uptime statistics.
Here are a few tips to use IP SLAs to monitor the health of your VoIP network. They are pulled directly from a conversation started by one of the community members, sjocchiogrosso , on the SolarWinds blog, Geek Speak. If you'd like, you can join in on the original conversation here.
IP SLAs That Are Useful in a VoIP Deployment
UDP Jitter--This one goes without saying, as it is probably the most common IP SLA that is deployed in a VoIP network. After all, keeping track of the jitter within your network could be the first sign of a circuit/WAN/LAN issue or possibly a QoS policy that needs to be looked at.
DHCP--This one is not specific towards the VoIP infrastructure but hear me out. The VoIP phones probably won't be rebooting too often, but if the endpoints are not able to receive their proper IP addresses in a timely fashion, you will definitely receive some tickets from the end users. Without an IP address, those IP phones are not really IP phones at all, are they?
DNS--Like DHCP, this one is not specific for your VoIP infrastructure, but it can be useful if your IP phones are configured to perform DNS lookups to find their Call Manager or to utilize any specific services. Your VoIP infrastructure is more than likely dependent on DNS, so keeping an eye on DNS performance could definitely give you a troubleshooting edge.
Http Operations--Http operations are great to run on user access switches because this gives a better perspective into what the user is experiencing, rather than the monitoring hosts' ability to ping the user. This operation can perform a DNS lookup of a URL along with an HTTP Get.
PathEcho--PathEcho operations provide a hop-by-hop measurement of ICMP response times to the monitored endpoint. Again, this can provide a great perspective into what the end-user is experiencing. PathEcho can also help eliminate those annoying "the network is running slow" calls by showing exactly where in the path any latency exists.
Historical IP SLA Information Can Save You!
Having historical information for IP SLA statistics can be just as useful as the IP SLA tool itself. After all, having basic monitoring to prove network availability is one thing, but being able to provide performance statistics at the application level is another useful level entirely.
The historical information can also be used to identify and/or track peak usage times within the network, especially if you can see performance degradation every day at a specific time.
Yes, You Can Have Too Much of a Good Thing!
IP SLAs can be great for monitoring a network and provide a lot of valuable troubleshooting information. However, you will definitely want to keep in mind the amount of SLA traffic you are generating (especially if you are marking all your UDP Jitter operations as EF/DSCP-46). This could generate issues in itself by wasting precious space in your priority queues if you designed your queues pretty lean.
Something else to consider: If you are terminating all your IP SLAs to a single router you may want to keep a close eye on the resource utilization of that router. The IP SLA process doesn't utilize a lot of resources, but multiply that by 50 or above and it will definitely be a performance hit, and even possibly throw off the IP SLA statistics/results. In worst-case scenarios, if the CPU/memory spikes often enough you could start seeing issues in your data plane forwarding.
So to what extent are you utilizing IP SLA in your network and what operational types are you relying on? Are you even a fan of IP SLAs?