Guide to Device Link(Connection) Monitoring
When working in a large enterprise or Telecom network, the most difficult part of diagnostics, is finding where the fault happened on the network.
Different network-device vendors like Cisco, HP and more, provide policy configurations on their devices that provide a top-level view on the complete network.
Policies by different vendors:
- CISCO: IP SLA
- HP: NQA
I’ll talk specifically about Cisco’s policy, i.e., IPSLA
What is IPSLA?
Its a Service Level Agreement, that uses active traffic monitoring — the generation of traffic in a continuous, reliable, and predictable manner — for measuring network performance.
Why we need it?
Using IPSLAs, service provider customers can measure and provide service level agreements, and enterprise customers can verify service levels, verify outsourced service level agreements, and understand network performance.
How it works?
It sends data across the network to measure performance between multiple network locations or across multiple network paths. It simulates network data and IP services, and collects network performance information in real time.
- The information collected includes data about response time, one-way latency, jitter (interpacket delay variance), packet loss, voice quality scoring, network resource availability, application performance, and server response time.
- IP SLAs performs active monitoring by generating and analyzing traffic to measure performance either between Cisco devices or from a Cisco device to a remote IP device such as a network application server.
Measurement statistics provided by the various IP SLAs operations can be used for troubleshooting, for problem analysis, and for designing network topologies.
How to use it?
Depending on the specific IP SLAs operation, statistics of delay, packet loss, jitter, packet sequence, connectivity, path, server response time, and download time can be monitored within the Cisco device and stored in both CLI and SNMP MIBs.
The packets have configurable IP and application layer options such as a source and destination IP address, User Datagram Protocol (UDP)/TCP port numbers, a type of service (ToS) byte (including Differentiated Services Code Point [DSCP] and IP Prefix bits), a Virtual Private Network (VPN) , “scheduling” option, “threshold” of when it fails, “frequency” for verification, routing/forwarding instance (VRF), and a URL web address.
Metrics that we can measure on:
- Delay (both round-trip and one-way)
- Jitter (directional)
- Packet loss (directional)
- Packet sequencing (packet ordering)
- Path (per hop) — Very important metric, to find what happens on the link from hop 1 to hop n.
- Connectivity (directional)
- Server or website download time
- Voice quality scores
- Domain Name System (DNS): uses DNS packet to measure RTT, and latency from source and back to source from the dns server.
- Dynamic Host Control Protocol (DHCP)
- File Transfer Protocol (FTP)
- Hypertext Transfer Protocol (HTTP)
- ICMP echo: Traverse network from source router to destination router using ICMP packet, to get status.
- ICMP jitter
- ICMP path echo: Traverse network from source router to destination router using ICMP packet, to get intermediate hops.
- ICMP path jitter: Traverse network from source router to destination router using ICMP packet, to get intermediate RTT, latency between each hop(s).
- Real-Time Transport Protocol (RTP)-based VoIP
- Transmission Control Protocol (TCP) connect
- UDP echo: Traverse network from source router to destination router using UDP packet, to get status.
- UDP jitter
- UDP jitter for VoIP
- VoIP gatekeeper registration delay
- VoIP post-dial delay