X
    Categories Performance Monitoring

Verifying Network Performance SLAs

Service-level agreements (SLAs) are an interesting concept because unless  there is a major disruption, it is difficult to guarantee they are being met daily.

How do you know your carrier is meeting the requirements you are paying for? And if you  are a carrier, how can you prove to your clients that you are delivering the service as agreed? Network and application performance issues can turn into a finger pointing war between a carrier and a customer. For a resolution to the endless argument, both sides need to be proactively monitor their networks to meet SLAs 24/7 and report accurately and consistently on service delivery.

The rapid growth of cloud computing, software-as-a-service (SaaS) and infrastructure-as-a-service (IaaS), coupled with the centralization of IT resources, means that more and more users are “remote” from the applications and data they are accessing. Business-critical network traffic must therefore move over WANs, service provider networks and the Internet.

All businesses and employees need uninterrupted access to these IP-based applications. But when network performance degrades, the performance of today’s network-dependent applications – including VoIP, videoconferencing, virtual desktop infrastructure (VDI) and IP storage – quickly degrades along with it. This makes monitoring and validation of network performance service-level agreements (SLAs) increasingly vital to business productivity.

SLAs specify the Quality of Service (QoS) that IT departments and other service providers are mandated to deliver. Business stakeholders point to SLAs as a way to quantify network performance and reliability in business terms. IT departments can benefit from SLAs  as a way to illustrate service value, justify funding and compare price/performance against outsourced providers.

But monitoring QoS and isolating SLA violations and other problems over today’s complex, distributed and hyper-busy networks can be extremely difficult.

How do you verify QoS from the perspective of remote users accessing remote resources over networks you don’t own?

How do you deploy and manage the tools required to verify SLAs without introducing yet more network traffic and adding burdensome operational costs?

Many organizations still have no end-to-end visibility into the performance of public networks or those managed by service providers. Common technologies like IP SLA and SNMP cannot reach beyond a company’s own routers and switches.!

When the performance of IP-based applications starts to degrade below agreed levels, many network managers have no tools to accurately pinpoint the source of the problem. Is it with their network, or with a service provider network, or with the SaaS/IaaS provider? The result can be frustrating rounds of finger-pointing and flurries of calls to the Help Desk.

To verify SLAs and efficiently rectify violations and other network performance issues, network managers need three fundamental capabilities:

  • End-to-end visibility into key metrics like bandwidth, latency, packet loss and jitter across the network path between services and remote users
  • Hop-to-hop diagnostics that clearly pinpoint where problems are occurring, even over third-party or public networks
  • Remote performance monitoring tools that automatically send alerts when performance drops below SLA thresholds

These insights let network managers “see beyond their own routers” to ensure an agreed level of QoS to their users, monitor third-party compliance with SLAs, and minimize – or even proactively eliminate — the impact of problems on business activities.

The PathView Cloud network performance management solution provides end-to-end SLA monitoring capabilities that meet today’s demands for comprehensive insight. Delivered as a zero administration, cloud-based service, PathView Cloud measures real-time performance against specified SLAs to any target with an IP address, delivering advanced diagnostics whenever and wherever problems arise.

Team AppNeta: