What Is IP SLA in Networking?
Also known as: IP SLA, Cisco IP SLA, IP SLA definition, CCNP ENCOR IP SLA, network performance monitoring
On This Page
Quick Definition
IP SLA stands for Internet Protocol Service-Level Agreement. It is a feature built into Cisco routers and switches that lets you test your network by sending fake test traffic between devices. You can measure things like delay, jitter, packet loss, and how long it takes for a response to come back. This helps you see if your network is meeting performance goals without needing a real user to be online.
Must Know for Exams
IP SLA is a recurring topic in the Cisco CCNP Enterprise (350-401 ENCOR) exam, and it also appears in the CCNA and CCNP concentration exams like ENARSI (300-410). In the ENCOR exam, IP SLA is covered under the Network Assurance domain, which includes performance monitoring, troubleshooting, and automation. You are expected to understand what IP SLA is, how to configure basic operations, and how to interpret the results to verify service levels.
Exam questions often ask you to identify the correct configuration for an IP SLA operation. For example, you might be given a scenario where a branch office has a primary MPLS link and a backup 4G link. The question asks you to configure IP SLA to monitor the primary link and automatically fail over to the 4G link if the ping fails. You need to know the commands: "ip sla 1", "icmp-echo", "frequency", "ip sla schedule", and then how to tie that to a static route using "track" and "ip route" with a track object.
Another common exam topic is interpreting IP SLA output. You may be shown a show ip sla statistics command output and asked to determine whether a service level agreement is being met given a threshold for RTT or packet loss. You need to read the fields correctly—like Latest RTT, Packet Loss Count, and Success Rate—and compare them to the defined thresholds. The exam may also test your understanding of the difference between ICMP echo and UDP jitter operations, and when each is appropriate.
Additionally, the ENCOR exam expects you to understand how IP SLA integrates with other technologies like Object Tracking, route maps, and EEM (Embedded Event Manager). You may be asked to select the correct tracking method for a specific failover scenario. The key is to remember that IP SLA provides the data, and tracking decides what to do with it. The exam does not require memorizing every single command, but you must understand the workflow: configure the probe, schedule it, create a track object, and then use that object in a routing decision.
Simple Meaning
Imagine you are the facilities manager for a large office building. You need to know if the elevators are fast enough, if the hallways are clear, and if the coffee machine in the break room is working properly. You could wait for employees to complain, but by then people are already unhappy. A smarter approach is to walk around regularly with a stopwatch, riding the elevator, checking the hallway, and timing how long it takes to get a cup of coffee. That is exactly what IP SLA does for a computer network.
IP SLA is a tool that lives inside Cisco routers and switches. It creates fake test traffic that looks like real network traffic—like a video call, a web page request, or a file transfer—and sends it from one device to another across the network. The sending device stamps the test packet with a precise time before it leaves, and the receiving device sends back a reply. The original device then calculates how long the round trip took. Over time, it can track if those times are getting worse, which indicates something is wrong, like congestion or a failing cable.
Think of it as your personal network postman. Instead of waiting for a package to get lost and a customer to complain, you send a test letter every few minutes and time how long it takes to come back. If the test letter starts taking too long, you know something is wrong before any real package is impacted. That is the core idea of IP SLA: proactive performance measurement using synthetic traffic.
Full Technical Definition
IP SLA (Service-Level Agreement) is a Cisco IOS feature that enables active performance monitoring of network paths by generating and analyzing synthetic traffic. It operates at the application layer and can emulate various protocols including ICMP (ping), UDP, TCP, HTTP, DHCP, and DNS. Each IP SLA operation is configured with a source and destination IP address, a protocol type, a frequency, and thresholds for acceptable performance.
The operation works in a client-server model. The source device acts as the IP SLA sender, which constructs a probe packet with a timestamp. This packet is sent to a target device, which can be another IP SLA responder or a regular endpoint. The target device echoes the packet back to the source with its own timestamp. The source calculates metrics such as round-trip time (RTT), one-way delay, jitter (variation in delay), packet loss percentage, and connectivity availability. For more advanced measurements like Voice over IP (VoIP) quality, IP SLA can simulate a voice codec stream and compute Mean Opinion Score (MOS).
Cisco routers and switches store the results in local memory. These results can be used in several ways. First, they can be logged for historical analysis with tools like SNMP and NetFlow. Second, they can trigger reaction conditions—for example, if RTT exceeds 200 milliseconds for three consecutive probes, the router can log an alert or even trigger a backup route using static routes with tracking or Enhanced Object Tracking (EOT). Third, they can be used by routing protocols like EIGRP or OSPF through IP SLA tracking combined with Policy-Based Routing (PBR) or route map manipulation to reroute traffic away from a degraded path.
IP SLA is configured in global configuration mode using the "ip sla" command followed by an operation number. The administrator specifies the type of operation, the target address, the frequency in seconds, and optionally thresholds for reaction. Multiple operations can run simultaneously on different paths. The feature requires no additional hardware or software licenses on most Cisco enterprise platforms, making it a cost-effective monitoring solution. It is widely used in enterprise WANs, data centers, and MPLS VPN environments to certify that service providers are meeting contracted service levels.
Real-Life Example
Imagine you manage a large public library with multiple floors and several study rooms. You promised visitors that they can always find a book within ten minutes and that the Wi-Fi is fast enough to load a video. You cannot just wait for complaints because by then trust is lost. So you decide to run a daily test: every morning, you walk from the front desk to the farthest study room on the third floor, pick a random book from the shelf, bring it back, and time the whole trip. If the round trip takes more than twelve minutes, you know the elevators are slow or the shelves are too crowded.
This is exactly what IP SLA does in networking. The library building is your corporate network. The front desk is your local router, and the study room is a remote server or branch office. The book you pick is a synthetic test packet. The time you record is the round-trip time (RTT) metric. When you run this test every morning at 9 AM, you are performing an IP SLA operation with a frequency of 86400 seconds (once a day). If you instead run it every 30 minutes, you catch slow downs faster.
Now suppose you also want to know if the Wi-Fi in the study room is actually good for video streaming. You cannot just check by loading a web page because that is different from video. So you carry a tablet that simulates a Zoom call—sending and receiving small chunks of data continuously for one minute. You measure how often the video freezes (packet loss) and how much the speed varies (jitter). That is an advanced IP SLA operation simulating a voice or video stream.
If your test shows that the return trip from the third floor is consistently above 12 minutes, you might decide to take the stairs instead of the elevator. In network terms, that means your router detects a failing path and automatically switches to a backup link using IP SLA tracking with static routes. The library doesn't wait for a visitor to complain about slow service—you fixed it before they even noticed.
Why This Term Matters
In real IT work, networks are the circulatory system of an organization. If the network slows down or drops packets, everything suffers: email lags, video calls freeze, cloud applications time out, and customer transactions fail. Without active monitoring, you only discover problems when users call the help desk complaining. By that point, productivity has already been lost, and the root cause may be hard to trace. IP SLA gives you proactive visibility into network health, allowing you to detect performance degradation long before users are affected.
For network engineers, IP SLA is a critical troubleshooting tool. When a branch office reports choppy voice calls, you can run an IP SLA operation that mimics a voice codec and compare the jitter and packet loss against known thresholds. If the results are within limits, the problem is likely not the network but the VoIP endpoint itself. This saves hours of guesswork. Similarly, if a new WAN link is installed, IP SLA can verify that the carrier is meeting the promised latency and packet loss figures before you cut over production traffic.
IP SLA also enables intelligent traffic steering. In a dual-WAN or load-balanced environment, you can configure IP SLA to track the health of each link. If one link starts dropping packets or becoming too slow, the router can automatically adjust routing tables or policy-based routing to send traffic over the faster link. This is far more reliable than assuming all links are always healthy. In cloud and hybrid environments, IP SLA can probe connectivity to cloud gateways or VPN endpoints, ensuring that remote workers and critical applications have a clear path.
Finally, IP SLA is heavily used for compliance and auditing. Many industries require documented proof that network performance meets service levels. IP SLA logs provide timestamped evidence of latency, jitter, and uptime. This can be exported to monitoring systems like SolarWinds, PRTG, or Cisco Prime to generate reports. Without IP SLA, you would have to rely on passive metrics from NetFlow or packet captures, which are harder to correlate to specific service guarantees.
How It Appears in Exam Questions
Scenario-based questions are the most common type for IP SLA. For example: A network engineer needs to ensure that traffic from a head office to a remote data center uses the primary link when it is healthy but automatically switches to a backup link when the primary link's latency exceeds 100 milliseconds. The candidate must identify the correct configuration sequence, which includes an IP SLA ICMP-echo probe, a track object referencing that probe, and a static route (or PBR) with a higher administrative distance that is conditional on the track object being down.
Configuration completion questions present a partially written router configuration with blank lines or missing parameters. The candidate selects the correct command from a list to complete the IP SLA operation. For instance, the question might show "ip sla 10" and then a blank, with options like "icmp-echo 10.1.1.1" or "udp-jitter 10.1.1.1 5000". You need to choose the correct probe type based on the scenario—if monitoring VoIP quality, UDP jitter is correct; for basic reachability, ICMP-echo is correct.
Troubleshooting questions show an IP SLA configuration that is not working as expected. The output of "show ip sla statistics" might show zero packets sent or the probe in an "inactive" state. The candidate must identify the missing command, such as "ip sla schedule 10 start now life forever" or a failure to configure the responder side. Some questions also test understanding of thresholds and reaction conditions, such as "show track" output showing the track object as "down" even though the target is reachable, because the reaction threshold is set too tightly.
Less common but still possible are design questions: a company with multiple remote sites wants to monitor performance to a centralized server. The candidate must decide how many IP SLA operations are needed, whether UDP or ICMP probes are appropriate, and how frequently to run them without impacting production traffic. These questions test understanding of IP SLA's overhead and its role in SLA verification.
Study encor
Test your understanding with exam-style practice questions.
Example Scenario
A medium-sized retail company has its main office in Chicago and a backup data center in Dallas. Their primary connection is a 100 Mbps MPLS link. For redundancy, they also have a 50 Mbps broadband connection. The network administrator, Priya, wants to ensure that if the MPLS link becomes slow or drops packets, traffic automatically fails over to the broadband link within 30 seconds.
Priya configures IP SLA on the Chicago router. She sets up operation number 1 as an ICMP echo probe targeting the Dallas router's IP address. She sets the frequency to 10 seconds and schedules it to start immediately and run forever. Next, she creates a track object (track 1) that monitors the IP SLA operation. She configures the track to go down if the IP SLA success rate drops below 80% over three consecutive probes.
Finally, Priya adjusts the default static route to the data center. She keeps the primary static route pointing to the MPLS link with an administrative distance of 1. But she creates a floating static route pointing to the broadband link with an administrative distance of 10, and she ties that route to track 1 being down. Under normal conditions, the MPLS route is preferred. When IP SLA detects that the MPLS link is failing, track 1 goes down, the floating static route is installed in the routing table, and all traffic to Dallas now uses the broadband link. When the MPLS link recovers, IP SLA starts reporting success again, track 1 comes up, the floating route is removed, and traffic returns to the primary link.
Common Mistakes
Thinking IP SLA only works with ICMP ping and can only measure reachability.
IP SLA supports many protocol probes including UDP jitter, TCP connect, HTTP, DHCP, DNS, and VoIP codec simulation. Using only ICMP misses critical metrics like jitter and packet loss that affect voice and video traffic.
Match the probe type to the application you need to monitor. For voice quality, use UDP jitter. For web server availability, use HTTP or TCP connect. ICMP is fine for basic connectivity but not sufficient for service-level verification.
Forgetting to schedule the IP SLA operation after configuring it.
The "ip sla schedule" command is required to start the probe. Without it, the operation is configured but never runs, and statistics remain empty. This is a common exam trap and a real-world oversight.
Always include the command "ip sla schedule <operation-number> start now life forever" (or a specific start time and duration) after configuring the operation. Verify with "show ip sla schedule" to confirm the operation is active.
Confusing the IP SLA source and target, especially in a one-way measurement scenario.
In IP SLA, the source is the device that initiates the probe and calculates the metrics. The target is the device that responds. If you reverse them in your head, you might configure the probe on the wrong router or misunderstand the measurement path.
Remember: the IP SLA sender (the router you configure) is the source. The target is the far-end device you are testing. The source always measures the round trip from itself to the target and back.
Assuming IP SLA works across the internet without a responder or firewall considerations.
IP SLA probes, especially UDP jitter, may be blocked by firewalls or require a dedicated IP SLA responder on the target device. Without proper configuration, probes can time out, giving false negatives about network health.
For UDP jitter and other non-ICMP probes, configure the target device as an IP SLA responder using the "ip sla responder" command. Also ensure firewalls along the path permit the probe traffic, usually on UDP port 1967 for the responder.
Exam Trap — Don't Get Fooled
The exam shows a configuration where an IP SLA ICMP-echo probe is configured but the track object uses the wrong threshold type, such as "threshold milliseconds 100" instead of "reaction 1 timeout 100". The candidate thinks the track will react to latency, but it actually only goes down when the probe completely fails (no reply). Understand the separation between IP SLA and tracking.
IP SLA collects data and can generate a 'reaction' event (like a timeout or threshold violation) that puts the track into a down state. The track object itself does not interpret latency values directly; you must configure a reaction condition inside the IP SLA operation that triggers the track. In the exam, read carefully whether the question asks about making the track go down based on latency or just based on complete loss of connectivity.
For latency-based failover, you need both an IP SLA threshold and a reaction configuration that triggers the track.
Commonly Confused With
ICMP ping is a simple utility that sends a single echo request and waits for a reply. It tells you if a host is reachable and roughly how long it takes. IP SLA is a programmable feature that can send packets on a schedule, measure multiple metrics over time, and trigger automatic actions based on results. Ping is a one-time test you run manually; IP SLA is an automated monitoring and response system.
You use ping to check if a server is up right now. You use IP SLA to monitor that same server every 30 seconds for a month, and if three pings fail, it automatically switches to a backup server.
NetFlow is a passive monitoring technology that captures metadata about real traffic flowing through a router, such as source and destination IPs, ports, and byte counts. It does not generate its own traffic. IP SLA is active monitoring that creates synthetic traffic to test the network. NetFlow shows what is happening; IP SLA tests what could happen or verifies that the network is meeting its promises.
NetFlow tells you that users are downloading 10 GB of data to the server. IP SLA tells you that the delay from the router to that server is 45 milliseconds. You need both to fully understand the network.
SNMP polling is a method where a management station periodically queries a device for specific data, such as interface utilization or error counters. It is a management-plane activity and does not measure end-to-end performance. IP SLA measures actual path performance between two devices, including application-level metrics like jitter. SNMP tells you about the device's internal state; IP SLA tells you about the quality of the network path between two points.
SNMP polls a router's interface and shows it is 50% utilized. IP SLA sends a test packet across that same interface and discovers that jitter is high because of a faulty cable. SNMP cannot directly reveal the jitter problem.
Step-by-Step Breakdown
Identify the Monitoring Goal
Decide what you want to measure. Is it just reachability, or do you need to measure latency, jitter, or packet loss? Also decide on the endpoints: which two devices define the path you want to test. This step determines the probe type and target.
Configure the IP SLA Operation
On the source router, enter global configuration mode and use the command "ip sla <operation-number>" to start the operation. Then specify the probe type, for example "icmp-echo 10.1.1.1" for a ping test or "udp-jitter 10.1.1.1 5000" for a voice simulation. Set optional parameters like frequency, timeout, and type-of-service (ToS) bits.
Set Thresholds and Reaction Conditions (Optional)
Use the "threshold" command inside the operation configuration to define, for example, a maximum acceptable RTT. Then use the "reaction" command to specify what should happen when the threshold is violated, such as sending a log message or toggling a track object. Without this step, the operation only collects data but does not trigger actions.
Schedule the Operation
Use the "ip sla schedule <operation-number> start now life forever" command to activate the probe. You can also schedule a specific start time, an end time, or a number of repetitions. Verify with "show ip sla schedule" that the operation is active.
Create a Track Object (If Needed)
If you want the IP SLA results to influence routing or other policies, create a track object with "track <track-number> ip sla <operation-number> reachability" (or other criteria). This object will be up or down based on the IP SLA results. It can also track reaction events.
Apply the Track Object to a Routing Decision
Use the track object in a static route (e.g., "ip route 0.0.0.0 0.0.0.0 10.2.2.2 track 1"), in policy-based routing with a route map, or in interface configuration to adjust parameters. The network will now react automatically when the IP SLA probe indicates a problem.
Verify and Monitor
Use commands like "show ip sla statistics", "show track", and "show ip route" to confirm the configuration is working. Monitor over time. Adjust thresholds or probe frequency if needed based on historical data.
Practical Mini-Lesson
IP SLA is one of those Cisco features that separates a good network engineer from a reactive one. You do not need expensive third-party tools to know if your MPLS link is degrading. With IP SLA, the router itself becomes a monitoring device. But to use it effectively, you must understand its capabilities and limitations.
First, always choose the right probe type. For a simple link health check, ICMP echo is fine. But if you support VoIP, you need UDP jitter. The UDP jitter probe sends a stream of packets at a configured interval and calculates jitter, packet loss, and latency per direction. It even provides a Mean Opinion Score estimate. If you are monitoring HTTP server availability, use the HTTP probe which actually fetches a URL and measures response time. Never use ICMP to simulate a voice call—the results are meaningless for real-time applications.
Second, understand that IP SLA generates real traffic. A single ICMP probe every 10 seconds is negligible, but a UDP jitter probe sending 100 packets per second is not. On a busy router with many operations, you can consume significant CPU and bandwidth. Cisco recommends using IP SLA sparingly on production routers. In practice, limit it to a handful of critical paths. For large-scale monitoring, offload to a dedicated probe appliance.
Third, integrate IP SLA with other Cisco technologies. The most common combination is IP SLA with Object Tracking and floating static routes for WAN failover. But you can also use it with EEM to trigger custom scripts, with PBR to route traffic based on path quality, and with IP Service Level Agreements (IP SLA) responder to allow non-Cisco devices to participate. For example, you can configure a Linux server with a responder daemon so that IP SLA can measure latency to it using UDP jitter.
Fourth, be careful about SNMP and logging. IP SLA results can be exported via SNMP and collected by monitoring platforms. You can set up traps when a threshold is violated. This is how you build a dashboard that shows WAN link performance over time. Without logging and visualization, IP SLA data is just numbers in a router buffer.
Finally, remember that IP SLA is not a replacement for real user monitoring. Synthetic traffic is predictable and does not capture the user experience of, say, a slow database query caused by server-side issues. But for verifying the network's performance and ensuring automatic failover, IP SLA is an indispensable tool in any enterprise environment.
Memory Tip
Think of IP SLA as your network's early warning system: it sends test packets to verify the path before users feel the pain. The three keys are Probe (type of test), Schedule (when it runs), and Track (what action it triggers).
Covered in These Exams
Related Glossary Terms
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
An A record is a DNS record that maps a domain name to the IPv4 address of the server hosting that domain.
Frequently Asked Questions
Does IP SLA work on all Cisco devices?
IP SLA is available on most Cisco IOS routers, switches, and ASR/ISR series platforms. However, some low-end switches may not support it. Check the device datasheet or use the command "show ip sla application" to see supported features.
Can IP SLA measure one-way delay instead of round-trip time?
Yes, but it requires an IP SLA responder on both ends and precise clock synchronization (NTP). The responder stamps the packet with its local time, and the difference gives one-way delay. Without synchronized clocks, one-way delay is inaccurate.
What is the difference between an IP SLA responder and a regular target?
A regular target (like any server) will reply to ICMP probes but cannot handle advanced probes like UDP jitter. An IP SLA responder is a Cisco device configured with "ip sla responder" that can timestamp packets and respond to complex probe types accurately.
How many IP SLA operations can I run on one router?
The limit depends on the router model and available memory. Older routers may support only 10-20 operations, while newer ASR 1000 series can handle hundreds. However, CPU usage is the real constraint—too many operations can degrade routing performance.
Can I use IP SLA to monitor cloud services like AWS or Azure?
Yes, you can point an IP SLA ICMP echo probe to any public IP. However, many cloud providers block ICMP or advanced probes. UDP jitter is often blocked by cloud firewalls. Always verify that your target allows the probe traffic.
Does IP SLA require a license?
On most Cisco enterprise routers, IP SLA is included in the base IOS image. Some advanced features, like Voice over IP (VoIP) codec simulation, may require an advanced IP services license. Check the licensing documentation for your specific platform.
What happens if I do not schedule an IP SLA operation?
The operation will be configured in the running configuration but will never send probes. It will appear as "inactive" in show commands. You must explicitly schedule it with the "ip sla schedule" command to start it.
Can IP SLA trigger an email alert?
IP SLA itself cannot send emails. But it can generate SNMP traps or syslog messages, which can be picked up by a monitoring system like Cisco Prime, SolarWinds, or custom scripts that then send an email alert.
Summary
IP SLA is a powerful, built-in Cisco feature that transforms a router from a simple packet forwarder into an active performance monitor. By generating synthetic traffic on a schedule, it measures critical network metrics like round-trip time, jitter, packet loss, and application response time. This data enables network engineers to verify service-level agreements, detect degradation before users complain, and automate failover decisions when a link fails.
In CCNP and CCNA exams, IP SLA appears in configuration and troubleshooting scenarios, often integrated with Object Tracking and static routes. To avoid exam traps, remember that scheduling is mandatory, probe types must match the application, and track objects only see a binary up/down state unless you configure reaction conditions. For real-world networking, IP SLA is your most cost-effective tool for proactive network health monitoring and intelligent traffic steering.