IP SLA – Covering ENARSI topics of configuring SLA to detect jitter, tracking objects, delay, connectivity issues!

IPSLA

Wanted to cover this in a non-fancy lab, very straight forward, as this is a very forgettable subject for me as you kind of set it and forget it on real life networks.

What IP SLA is and how it can be used to optimize your network

Not to be confused with “Tracking Objects” for FHRP’s (SWITCH), this actually send a type of specified traffic out to either the Internet to test connectivity, or actually to an IP SLA Responder that sites on across the internet that gave give you statistics on Jitter / Delay which is what drives Performance Routing.

My 7200 series emulated router images cannot touch PfR unfortunately, so I’ll just give a simple demo here of how to set it up, and the commands to do so as of IOS 15.x as it has changed just a bit from 12.2.x IOS.

The IP SLA Responder is typically setup if you have a high SLA with your Service Provider, with which you can send traffic that mimics jitter or delay that a phone might experience, and the IP SLA Responder will report back to total RRT minus any time itself took to process the traffic and send it back to your IP SLA enabled router.

Using IP SLA to detect Connectivity Issues on your networks Internet

I will use the usual icmp-echo SLA out to my ISP’s to detect if one is down, the router can perform a manual failover to ISP2, which with the emergence of SD-WAN this won’t be tested on a whole lot longer I wouldn’t imagine πŸ™‚

So the configuration goes like this:

Branch1(config)#ip sla 1
Branch1(config-ip-sla)#?
IP SLAs entry configuration commands:
dhcp DHCP Operation
dns DNS Query Operation
ethernet Ethernet Operations
exit Exit Operation Configuration
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo Operation
mpls MPLS Operation
path-echo Path Discovered ICMP Echo Operation
path-jitter Path Discovered ICMP Jitter Operation
tcp-connect TCP Connect Operation
udp-echo UDP Echo Operation
udp-jitter UDP Jitter Operation

Branch1(config-ip-sla)#icmp-echo ?
Hostname or A.B.C.D Destination IP address or hostname, broadcast disallowed

Branch1(config-ip-sla)#icmp-echo 100.100.100.1 ?
source-interface Source Interface (ingress icmp packet interface)
source-ip Source Address
<cr>

Branch1(config-ip-sla)#icmp-echo 100.100.100.1 source-interface fa1/0 ?
<cr>

Branch1(config-ip-sla)#icmp-echo 100.100.100.1 source-interface fa1/0

You now have a Ping going to ISP1 with a frequency of every 5 seconds!

But now what are you going to do with it? What happens if that Ping stops responding to the SLA you just configured? Panic???

No!

I want to display the different options for an icmp-echo SLA shown here:

Branch1(config-ip-sla-echo)#?
IP SLAs Icmp Echo Configuration Commands:
default Set a command to its defaults
exit Exit operation configuration
frequency Frequency of an operation
history History and Distribution Data
no Negate a command or set its defaults
owner Owner of Entry
request-data-size Request data size
tag User defined tag
threshold Operation threshold in milliseconds
timeout Timeout of an operation
tos Type Of Service
verify-data Verify data
vrf Configure IP SLAs for a VPN Routing/Forwarding instance

Set the frequency (min on this IOS is 5 seconds), tag (probably used with BGP), ToS (this is kind of like QoS / CoS only we wouldn’t have IP SLA Pings doing VOIP measurements, can also send the pings over specific VRFs if the destination isn’t in the Global IP Route Table.

Scheduling your SLA for WHEN to start and HOW LONG to run

Two of the funniest part of this config since I started studying 10+ years ago!

Note – This used to be under ‘IP SLA Monsitor # or something like that!

Now everything is under “ip sla …” including its “ip sla schedule …”!

Branch1(config)#ip sla schedule 1 start-time ?
after Start after a certain amount of time from now
hh:mm Start time (hh:mm)
hh:mm:ss Start time (hh:mm:ss)
now Start now
pending Start pending

Branch1(config)#ip sla schedule 1 start-time now ?
ageout How long to keep this Entry when inactive
life Length of time to execute in seconds
recurring Probe to be scheduled automatically every day
<cr>

Branch1(config)#ip sla schedule 1 start-time now life ?
<0-2147483647> Life seconds (default 3600)
forever continue running forever

Branch1(config)#ip sla schedule 1 start-time now life forever ?
ageout How long to keep this Entry when inactive
recurring Probe to be scheduled automatically every day
<cr>

Branch1(config)#ip sla schedule 1 start-time now life forever

I just always found it funny you can schedule out when to start an SLA, as its probably incredibly low data usage on your line, I can’t imagine you need a couple hours to prepare all your debugs at all sites and get Cisco TAC on the phone.

Also another thing I found kind of dark humor is the “life” sentence of this SLA is “forever” in the configuration, meaning the purpose of this mechanisms whole life is to ping an IP until it is disabled. Talk about a narrow career path πŸ™‚

So how do we see these SLA statistics? How do we tie them to routes for failover?

We have a whole list of ways we can look at the information from this SLA:

Branch1#sh ip sla ?
application IP SLAs Application
authentication IP SLAs Authentication Information
auto IP SLAs Auto Show Commands
configuration IP SLAs Configuration
endpoint-list IP SLAs Endpoint list configuration
enhanced-history IP SLAs Enhanced History
ethernet-monitor IP SLAs Auto Ethernet Monitor
event-publisher IP SLAs Event Publisher
group IP SLAs Group Scheduling/Configuration
history IP SLAs History
mpls-lsp-monitor IP SLAs MPLS LSP Monitor
reaction-configuration IP SLAs Reaction Configuration
reaction-trigger IP SLAs Reaction Trigger
responder IP SLAs Responder Information
statistics IP SLAs Statistics
summary IP SLAs Statistics Summary
twamp IP SLAs TWAMP

I would use “sh ip sla summ” or “sh ip sla stat” to get fairly general information as this is a ping running to an ISP, its more to detect failover then to give the Net Admin useful info unless you get an IP SLA Responder in place with more advanced SLA settings.

Branch1#sh ip sla summ
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID Type Destination Stats Return Last
(ms) Code Run
———————————————————————–
*1 icmp-echo 100.100.100.2 RTT=15 OK 4 seconds ago

Branch1#sh ip sla stat
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
Latest RTT: 36 milliseconds
Latest operation start time: 12:45:14 UTC Sun Dec 15 2019
Latest operation return code: OK
Number of successes: 9
Number of failures: 0
Operation time to live: Forever
This actually has some decent info, RTT, packet loss to ISP, in determining if the issue is on the Internet Circuit or on the LAN for a customer, which can be critical!

You can use these SLA’s to tie to ISP’s to track if they are down / failover

This is actually regularly done, or has been in the past before idle fail-over links are becoming extinct, but lets take a look at what is still out there today:

Branch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Branch1(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.2
Branch1(config)#ip route 0.0.0.0 0.0.0.0 111.111.111.2 5
Branch1(config)#

I prefer ISP1 so I make that my default route, with ISP having just a slightly higher AD known as a “floating static route” so if ISP1 become unavailable it will inject ISP 2 into the route table to “failover” the Internet. The nice thing with SLA Ping, is it keeps going, so once ISP1 starts responding again, that route is brought back in as the default route!

Tracking objects (like with FHRPs) used for IP SLA Service

Branch1(config)#track 1 ?
interface Select an interface to track
ip IP protocol
list Group objects in a list
stub-object Stub tracking object
<cr>

Branch1(config)#track 1 ip ?
route IP route
sla IP Service Level Agreement

Branch1(config)#track 1 ip sla ?
<1-2147483647> Entry number

Branch1(config)#track 1 ip sla 1 ?
reachability Reachability
state Return code state
<cr>

Branch1(config)#track 1 ip sla 1 reachability ?
<cr>

Branch1(config)#track 1 ip sla 1 reachability

So I chose my “Track object #” to be the same as my SLA # (don’t have to match), defining an IP Address as the target and Reachability as the criteria for this SLA Tracked Object.

Now if I can go from memory here:

Branch1(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.2 ?
<1-255> Distance metric for this route
multicast multicast route
name Specify name of the next hop
permanent permanent route
tag Set tag for this route
track Install route depending on tracked item
<cr>

Branch1(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.2 track ?
<1-1000> tracked object number

Branch1(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.2 track 1 ?
<1-255> Distance metric for this route
multicast multicast route
name Specify name of the next hop
tag Set tag for this route
<cr>

Branch1(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.2 track 1
Branch1(config)#

Its all around very easy, just the SLA configuration is forgettable in terms of exams of knowing it in question format, so if I can get a question, I hope it is about ICMP SLA πŸ™‚

So we now have an SLA tracking ISP1, and the Internet goes down (for 5 seconds!)

SLA_fail1

Suddenly the ISP1 goes down, and now its up to the SLA to cut over to our secondary ISP, lets see how long it takes here!

*Dec 15 13:09:46.143: %TRACKING-5-STATE: 1 ip sla 1 reachability Up->Down

Branch1#sh ip route

Gateway of last resort is 111.111.111.2 to network 0.0.0.0

S* 0.0.0.0/0 [5/0] via 111.111.111.2
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 100.100.100.0/30 is directly connected, FastEthernet1/0
L 100.100.100.1/32 is directly connected, FastEthernet1/0
111.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 111.111.111.0/30 is directly connected, FastEthernet2/0
L 111.111.111.1/32 is directly connected, FastEthernet2/0
Branch1#

That is a basic example of using IP SLA to track your Internet Connectivity.

Using IP SLA to Track Jitter / Delay over your WAN connection

This will actually require the use of an IP SLA Responder that is somewhere on the other side of your WAN cloud, which will report back statistics of the Jitter / Delay SLA back to the Branch Router running the SLA.

For this, lets setup our IP SLA Responder for Jitter / UDP-Echo traffic:

Branch1(config)#ip sla 2
Branch1(config-ip-sla)#udp-jitter ?
Hostname or A.B.C.D Destination IP address or hostname

Branch1(config-ip-sla)#udp-jitter 200.200.200.2 ?
<0-65535> Port Number. For codec options recommended port range is an Even
Port range between 16384-32767 or 49152-65535

Branch1(config-ip-sla)#udp-jitter 200.200.200.2 18000 ?
codec codec type to be configured
control Enable or disable control packets
interval Inter Packet Interval
num-packets Number of Packets to be transmitted
source-ip Source address
source-port Source Port
<cr>

Branch1(config-ip-sla)#udp-jitter 200.200.200.2 18000 codec ?
g711alaw G.711 A Law 64000 bps
g711ulaw G.711 U Law 64000 bps
g729a G.729 8000 bps

Branch1(config-ip-sla)#udp-jitter 200.200.200.2 18000 codec g711alaw ?
advantage-factor Advantage Factor
codec-interval Inter Packet Interval
codec-numpackets Number of Packets to be transmitted
codec-size Number of bytes in payload
control Enable or disable control packets
source-ip Source address
source-port Source Port
<cr>

Branch1(config-ip-sla)#$200.200.200.2 18000 codec g711alaw codec-size ?
<16-16384> Number of bytes in payload

Branch1(config-ip-sla)#$200.200.200.2 18000 codec g711alaw codec-size 2000 ?
advantage-factor Advantage Factor
codec-interval Inter Packet Interval
codec-numpackets Number of Packets to be transmitted
control Enable or disable control packets
source-ip Source address
source-port Source Port
<cr>

Branch1(config-ip-sla)#$0.2 18000 codec g711alaw codec-size 2000 source-ip ?
Hostname or A.B.C.D IP address or hostname, broadcast disallowed

Branch1(config-ip-sla)#$alaw codec-size 2000 source-ip 100.100.100.1 ?
advantage-factor Advantage Factor
codec-interval Inter Packet Interval
codec-numpackets Number of Packets to be transmitted
control Enable or disable control packets
source-port Source Port
<cr>

Branch1(config-ip-sla)#$alaw codec-size 2000 source-ip 100.100.100.1
Branch1(config-ip-sla-jitter)#freq 5

Branch1(config)#ip sla schedule 2 start-time now life forever

The IP SLA Responder is surprisingly simple to configure from what I am finding on Cisco documentation of IP SLA Responder configuration for Jitter:

SLA-RES(config)#ip sla responder udp-echo ?
ipaddress Permanent address
port Permanent port

SLA-RES(config)#ip sla responder udp-echo ipaddress ?
WORD IP Address or IP HostName

SLA-RES(config)#ip sla responder udp-echo ipaddress 100.100.100.1 ?
port Permanent port

SLA-RES(config)#ip sla responder udp-echo ipaddress 100.100.100.1 port 18000 ?
<cr>

SLA-RES(config)#ip sla responder udp-echo ipaddress 100.100.100.1 port 18000
SLA-RES(config)#

So lets checks its stats and see whats up:

Branch1(config)#do sh ip sla stat 2
IPSLAs Latest Operation Statistics

IPSLA operation id: 2
Type of operation: udp-jitter
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 14:49:35 UTC Sun Dec 15 2019
Latest operation return code: No connection

I’ve made sure to bring ISP1 back online, using it for the default gateway, and confirmed routing is working via ping but the SLA is still showing NoConnectivity for some reason:

Branch1#sh ip sla summ
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID Type Destination Stats Return Last
(ms) Code Run
———————————————————————–
*1 icmp-echo 100.100.100.2 RTT=17 OK 0 seconds ago
*2 udp-jitter 200.200.200.2 – No connecti 31 seconds ag
on o
Branch1#

I am not exactly sure what the issue is, there is a lot of great SLA software around now adays to measure VOIP traffic, so I’m not going to spend time really fighting this lab to get it to work – This should be enough to get by any IP SLA questions on the ENARSI.

That will conclude my review of IP SLA

Its such an ancient topic I am honestly amazed its still on Cisco exams with all the free software designed to monitor SLA 24/7 over the WAN for VOIP / Cloud systems, so I won’t go much further than this into the subject, I don’t expect to get whomped with questions on IP SLA on the ENARSI or any future Cisco exams beyond Object Tracking for FHRPs and Route Tracking for fail-over (which SD-WAN is quickly replacing as well).

Cross IP SLA off the list, onto the next topic! πŸ™‚

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s