To begin, I’d like to start with a stark contrast between Frame-Relay CIR (Committed Information Rate) provided by the FR provider, and IP SLA.
As the FR Provider guarantees at least a certain up-time and bandwidth availability, that makes no claims for over-utilization or perfect uptime, and this helps to have those minimums in place to plan your WAN usage and priority.
The IP SLA is based on that same concept of minimum guaranteed performance, but instead of company to FR-Provider, it will generally be from internal clients of the company to the network team asking for priority of certain protocols.
Speaking of protocols, lets take a look at the beginning configuration of “ip sla” and what kind of protocols we can guarantee some minimum performance for:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip sla ?
<1-2147483647> Entry Number
apm IP SLAs Application Performance Monitoring
Configuration
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
reset IP SLAs Reset
responder Enable IP SLAs Responder
restart Restart An Active Entry
schedule IP SLAs Entry Scheduling
slm Service Level Management
R1(config)#ip sla 5
R1(config-ip-sla)#
We will just go with an Entry number for now, but I wanted to show the modifiers for “ip sla …” in case we run into them later, also as you can see this drops me into “ip-sla” config mode.
So from that mode, lets see whats available for ip sla:
R1(config-ip-sla)#?
IP SLAs entry configuration commands:
dhcp DHCP Operation
dlsw DLSW Operation
dns DNS Query Operation
exit Exit Operation Configuration
frame-relay Frame-relay Operation
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo Operation
icmp-jitter ICMP Jitter Operation
path-echo Path Discovered ICMP Echo Operation
path-jitter Path Discovered ICMP Jitter Operation
slm SLM Operation
tcp-connect TCP Connect Operation
udp-echo UDP Echo Operation
udp-jitter UDP Jitter Operation
voip Voice Over IP Operation
R1(config-ip-sla)#
As can be seen, just about any protocol expected to come into our go out of your network, though I myself generally see “ip sla tracking” which will be covered shortly in another post.
Now to set up any of these options, it requires a source and a responder, and to start things off the source sends control packets to the responder via UDP port 1967 in an attempt to create a control connection similar to FTP. This connection is not the actual SLA test / operation, but an agreement between sender and respond on the rules of communication (much like a VPN tunnel build).
The information being sent in this initial communication is the port number to be listening on for the test, and the time limits for the testing, and should the responder agree it will send back a message indicating the decision and starts listening on that port.
If it does not agree, it will respond back with that, and that is the end of that.
Once agreed we not going from controlling to probing, as the source sends test back to the responder, to see if the packets are indeed echoed back as well as how long the process takes. This is because the responder will add Timestamps to those test packets as they’re received and once they’re return to the sender – The sender now knows the processing time of the responder as well as the overall round trip time.
This is assuming that all parties have the networks synchronized using NTP, of course.
So lets continue the configuration of IP SLA on R1:
R1(config-ip-sla)#icmp-echo ?
Hostname or A.B.C.D Destination IP address or hostname, broadcast disallowed
R1(config-ip-sla)#icmp-echo 172.12.123.3 ?
source-interface Source Interface (ingress icmp packet interface)
source-ip Source Address
<cr>
R1(config-ip-sla)#icmp-echo 172.12.123.3
R1(config-ip-sla-echo)#
I’ve decided to go with “icmp-echo” down to my spoke 172.12.123.3, note the “Broadcast disallowed” when specifying the host, as well as the two other options available where you can set a different source interface or IP if needed for any reason (perhaps a logical interface that won’t go down unless administratively or if the router goes down).
However I just took the <cr> way out, which dropped me now into configuration mode for ip-sla-echo, so lets look at the commands we have here:
R1(config-ip-sla-echo)#?
IP SLAs 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
R1(config-ip-sla-echo)#frequency ?
<1-604800> Frequency in seconds (default 60)
R1(config-ip-sla-echo)#frequency 60
R1(config-ip-sla-echo)#
Always a good to use IOS help to see if a command is in milliseconds, hours, years, etc. I set this to its default frequency of 60, so as of right now, this SLA is now configured and ready for use – It just needs to be “scheduled” to run!
Here is how to schedule an SLA from global configuration mode:
R1(config)#ip sla schedule 5 ?
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>
R1(config)#ip sla schedule 5 life ?
<0-2147483647> Life seconds (default 3600)
forever continue running forever
R1(config)#ip sla schedule 5 life forever ?
ageout How long to keep this Entry when inactive
recurring Probe to be scheduled automatically every day
start-time When to start this entry
<cr>
R1(config)#ip sla schedule 5 life forever
R1(config)#
One this not to trip up on, is putting “ip sla 5 schedule” or you will get this:
R1(config)#ip sla 5 schedule ?
% Unrecognized command
R1(config)#ip sla 5 schedule
So remember, when scheduling, your are first defining you are scheduling and then call out the IP SLA “entry” # after.
Now from the output above it seems pretty self explanatory, I just wanted to include it for thoroughness, but I chose to set the schedule of “life” running “forever” in this schedule.
The only thing that is left from the above output that we STILL need, is a start time!
R1(config)#ip sla schedule 5 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
R1(config)#ip sla schedule 5 start-time now
R1(config)#
So you can set it to start at different times in hours minutes and seconds, after a certain amount of time you set or right now. Pending is also a modifier but is used for much more complex SLA configurations that involve events to trigger the SLA, so we will stick to the “now” option.
To verify an SLA configuration, the command is “sh ip sla config”:
R1#sh ip sla config
IP SLAs Infrastructure Engine-II
Entry number: 5
Owner:
Tag:
Type of operation to perform: icmp-echo
Target address/Source address: 172.12.123.3/0.0.0.0
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Vrf Name:
Request size (ARR data portion): 28
Verify data: No
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
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
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:
R1#
So here we see all the SLA information you’d about ever need. You have the Entry # / Type of Operation / Destination and Source (Source all 0’s because we didn’t change it during config) / The frequency schedule (60 seconds) / Next Scheduled Start Time (Already passed means it is currently running) / Life (seconds): Forever!
So now that we have verified the configuration is correct, lets verify the operation and see how that is going:
R1#sh ip sla statistics
IPSLAs operation id: 5
Latest RTT: 43 milliseconds
Latest operation start time: 12:42:24.904 UTC Mon Apr 17 2017
Latest operation return code: OK
Number of successes: 11
Number of failures: 0
Operation time to live: Forever
R1#
So our successes vs failure ratio is exactly what we want to see, we see the operation “start time” as well as the operation id (entry).
Now lets say we wanted to change something with this SLA:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip sla 5
Entry already running and cannot be modified
(only can delete (no) and start over)
(check to see if the probe has finished exiting)
R1(config)#
Get a message from the router saying back off, because you cannot modify an SLA entry that is already running, the command even tells you that you can only delete it with “no” and start over (and check to see if the probe has finished exiting).
So you do have to delete it and start over creating a new ip sla.
Now to see what failure looks like, you can find me on linkedin, or we can go over to R3 and shut down that interface to see if R1 starts spitting out some error messages:
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int s0/2
R3(config-if)#shut
R3(config-if)#
Apr 17 12:50:31.176: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/2 from FULL to DOWN, Neighbor Down: Interface down or detached
R3(config-if)#
ASR#1
[Resuming connection 1 to r1 … ]
R1(config)#
I left it cooking for a minute or two and no console messages, so I issued a “sh ip sla stat” to see if that is showing a pile up of errors:
R1#sh ip sla stat
Round Trip Time (RTT) for Index 5
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 12:52:24.905 UTC Mon Apr 17 2017
Latest operation return code: Timeout
Number of successes: 19
Number of failures: 2
Operation time to live: Forever
R1#
Sure enough it is, so you won’t get console message telling you there is an issue, you will need to use the “sh ip sla stat” to find errors (or they may also end up in “sh log” if configured properly).
R1#sh ip sla stat
Round Trip Time (RTT) for Index 5
Latest RTT: 44 milliseconds
Latest operation start time: 12:54:24.905 UTC Mon Apr 17 2017
Latest operation return code: OK
Number of successes: 20
Number of failures: 3
Operation time to live: Forever
R1#
So while I was over opening the interface back up on R3 we got another failure, but then it begins to increment successes again so we are good to go there!
That concludes this IP SLA overview, next up is Tracking with SLA, I cannot wait! 🙂
The DEVNET GRIND! 