IP SLA was also covered in ROUTE studies, but I believe it should be recovered here as two types of FHRP (VRRP / GLBP) use object tracking for their thresholds to participate in their Router Groups, so very important to know solid for the SWITCH exam.
Fundamentals and need to know theory for exam day
SLA (Service Level Agreement) is basically configuring a polling / tracking system to determine what level of performance you are getting from a range of criteria, from jitter / latency on a phone call, to IP Addresses or Interfaces becoming unavailable.
SLA consists of two types of devices:
- SLA Source
- SLA Responder
- Control Connection via UDP 1967
This control connection is not the testing / SLA occurring, but rather a connection for the SLA Source to provide the SLA Responder to communicate on the SLA rules such as Port # / Time limits expected for the Test, so it essentially sets up the SLA test.
If / when the SLA Responder sends an agreement to the SLA Source on the rules, it will begin listening on that port, if the Responder doesn’t agree it will send a message back to the SLA Source indicating it doesn’t agree that is the end of the SLA connection.
Once the SLA Source and Responder Agree, the magic begins to happen!
This is where we go from “controlling” to “probing” in the SLA session, as now packets will be sent by the Source, and processed and sent back to the Source by the Responder.
To break it down into bite sized chunks of info / exchange flow:
- The Source begins to send test packets to the agreed upon ports, looking for both basic echo replies back, but also the time it takes from send to receiving of packet
- The Responder receives the Source test packets, and Timestamps them twice, once when they are received and again when they are sent back out (returned)
- The Timestamps only give an accurate result if devices NTP clocks are synchronized!
One piece of Terminology is going from that Agreement to the Source sending Packets to the Responder is called “Probing” in Cisco terminology, that is a good one to know.
Configuration first of the SLA Source on MLS SW1
We’ll go step by step here to see what options are where:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#ip sla ?
<1-2147483647> Entry Number
enable Enable Event Notifications
group Group Configuration or Group Scheduling
key-chain Use MD5 Authentication for IP SLAs Control Messages
logging Enable Syslog
low-memory Configure Low Water Memory Mark
reaction-configuration IP SLAs Reaction-Configuration
reaction-trigger IP SLAs Trigger Assignment
read Read data for use with IP SLA
reset IP SLAs Reset
responder Enable IP SLAs Responder
restart Restart An Active Entry
schedule Entry Scheduling
SW1(config)#ip sla 1
SW1(config-ip-sla)#
So this drops us into an “SLA Config” mode, so lets keep going:
SW1(config-ip-sla)#?
IP SLAs entry configuration commands:
dhcp DHCP Operation
dns DNS Query Operation
exit Exit Operation Configuration
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo 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
video Video Operation
SW1(config-ip-sla)#icmp-echo ?
Hostname or A.B.C.D Destination IP address or hostname, broadcast disallowed
SW1(config-ip-sla)#icmp-echo 10.0.0.3 ?
source-interface Source Interface (ingress icmp packet interface)
source-ip Source Address
<cr>
SW1(config-ip-sla)#icmp-echo 10.0.0.3
SW1(config-ip-sla-echo)#
So we are dropped down again into an “Echo / SLA Config” prompt to setup configuration, however as of right now this SLA 1’s operation is to ping 10.0.0.3.
Now we just need to give it more purpose with additional configuration:
SW1(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
SW1(config-ip-sla-echo)#frequency ?
<1-604800> Frequency in seconds
SW1(config-ip-sla-echo)#frequency 30 ?
<cr>
SW1(config-ip-sla-echo)#frequency 30
SW1(config-ip-sla-echo)#
We have now set SLA 1 to ping 10.0.0.3 every 30 seconds, the default frequency being 60 seconds, so now we have to apply this SLA somehow to carry out this operation!
Configuration of IP SLA Scheduling parameters to meet your SLA requirements
This is configured back at the Global Config prompt:
SW1(config)#ip sla schedule ?
<1-2147483647> Entry number
SW1(config)#ip sla schedule 1 ?
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
start-time When to start this entry
<cr>
SW1(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
SW1(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>
SW1(config)#ip sla schedule 1 start-time now
SW1(config)#
Notice that we can configure “recurring / life / ageout” all on that same “start-time” line, they do not need to be configured separately as I will for clarity.
If you see multiple schedule options in a single line on exam day, it may be correct!
So now we should have an SLA configured on SW1 to ping 10.0.0.3 (SW3) every 30 seconds, starting now (or back when then was now… or now was then… or… nevermind).
Lets take a look at verifying that SLA 1 is on schedule to ping 10.0.0.3 every 30 seconds!
Verification for SLA / Schedule information (more than you could ever hope for!)
This is going to be a lot of output, but there is some useful info to pick out of it. First though lets look at our show options for SLA:
SW1#sh ip sla ?
application IP SLAs Application
authentication IP SLAs Authentication Information
configuration IP SLAs Configuration
enhanced-history IP SLAs Enhanced History
event-publisher IP SLAs Event Publisher
group IP SLAs Group Scheduling/Configuration
history IP SLAs History
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
Just good to see all the different types of show commands, though the one I will focus on here is the “sh ip sla config” command to verify what we’ve configured:
“sh ip sla config” :
SW1#sh ip sla config
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 10.0.0.3/0.0.0.0
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 30 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): 3600
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
SW1#
The SLA #, Operation Type, Dest / Src Address (all 0’s means no Src info), Frequency, Start Time (Passed), Ageout time (Default never), more advanced stuff like VRF instances!
“sh ip sla stat” :
SW1#sh ip sla stat
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: 1 milliseconds
Latest operation start time: 20:30:13 CDT Sun Feb 28 1993
Latest operation return code: OK
Number of successes: 2
Number of failures: 46
Operation time to live: 2189 sec
SW1#
This command shows you when your operation is failing as mine was, so after some troubleshooting I found the SVI for VLAN 1 on SW3 was incorrect and fixed it – And now the SLA is showing successes increment!
Important behavior and note to know about for exam day!!!
When going to modify my SLA 1, I got stuck with this error:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#ip sla 1
Entry already running and cannot be modified
(only can delete (no) and start over)
(check to see if the probe has finished exiting)
SW1(config)#
You cannot modify a running IP SLA, and if it never ages out (by default), you need to configure a new one or delete the existing one to reconfigure it.
Also the note here, we never got on SW3 and issued a command because we ran a simple ping test here, but for other more advanced testing you would need to issue this command on the remote device that is the Responder:
SW3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW3(config)#ip sla responder ?
auto-register Setup auto-register to hub
tcp-connect Setup tcp-connect responder
udp-echo Setup udp-echo responder
<cr>
SW3(config)#ip sla responder
SW3(config)#
So if your configuring some more heavy duty / complex stuff, configure the Responder 🙂
THAT IS ALL FOR ME ON THIS ONE, THAT IS NTP AND IP SLA DOWN IN ONE DAY!
And a Saturday at that, I have some strange hobbies. Later!
The DEVNET GRIND! 