The document introduces Cisco IP SLAs, which is a feature in Cisco IOS that allows network engineers to monitor and measure performance metrics across their network. It discusses several use cases for IP SLAs including SLA verification, network monitoring, network readiness testing, availability monitoring, and troubleshooting. The document reviews how to configure various IP SLA operations including specifying the operation type, destination, and scheduling. It also discusses the accuracy, performance, and scalability of IP SLA operations.
2. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
3. The Business Challenges
What Are You Doing About Them?
Identify partial or
Delay launch of new incomplete network traffic
applications due to network conditions
performance concerns
Your Lack of Network
Slow to Launch New
Visibility
Services
Business
Increased TCO
Networks Reduced Network
Performance
Ensure application
Experience application
efficiency by adding
downtime and degradation
bandwidth (perhaps
unnecessarily)
Cisco IP SLAs can help
4. Cisco IP SLAs – Service Level Agreements
Enterprise and Small Medium Business Service Providers
Understand Network
Verify Service Levels Measure and provide
Performance &
Verify Outsourced SLAs SLAs
Ease Deployment
Access Enterprise Backbone Enterprise Service Provider Service Provider Core
Premise Edge Aggregation Edge
5. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
6. IP SLAs in a Nutshell
• Simple and easy to deploy • Scalability and Performance
• Embedded in Cisco IOS • Platform proliferation
• Millisecond precision
• CLI and SNMP access
• Microsecond granularity
• Wide Range of Coverage • Built-in Intelligence & Flexibility
• Multiple protocols • Scheduling and reporting
• Multiple applications • Auto discovery
• Multiple operations • QoS Integration
• Threshold Notifications
Customer-proven Success #CiscoPlusCA
7. Active | Passive
Active Monitoring (Cisco IP SLAs) Passive Monitoring (NetFlow)
Sends synthetic packet for network measurement. Watch for real traffic
End-to-end Performance Metrics At one point
Proactive troubleshooting No traffic == no conclusion
8. So how does it work?
Management
Application
Destination
Configure
Collect
SNMP
Configure Trap
Operation 1
Operation 2
Source
Responder
Destination
9. IP SLAs History
• Was called RTR - renamed SAA in 12.0(5)T; we call it ―IP SLAs Engine 1‖.
• ―IP SLAs Engine 2‖ - major code rewrite to improve speed and memory usage
– Introduced in 12.2(15)T2, 12.3(3) and 12.2(25)S, and is therefore present in all later trains
– Also planned for 12.0(32)SY and 12.2(18)SXG.
• First phase of new CLI appears originally in 12.3(14)T, next phase in 12.4(6)T
– MIBs are unchanged.
• The latest ‗Engine 3‘ started with 15.1(1)T, currently in T-train only
time
Engine: Engine 1 Engine 2 Engine 3
Feature Name: RTR SAA IP SLAs
CLI: rtr… ip sla mon… ip sla …
10. Supported Cisco IOS® Version
Feature/Release 11.2 12.0(3)T 12.0(5)T 12.1(1)T 12.2(2)T 12.2(11)T 12.3(4)T 12.3(12)T
12.0(8)S 12.2 (Eng2)
ICMP Echo X X X X X X X X
ICMP Echo Path X X X X X X X X
UDP Echo X X X X X X X
TCP Connect X X X X X X X
UDP Jitter X X X X X X
HTTP X X X X X X
DNS X X X X X X
DHCP X X X X X X
DLSw+ X X X X X X
SNMP Support X X X X X X
UDP Jitter with One Way Latency X X X X X
FTP Get X X X X X
MPLS/VPN Aware X X X X
Frame-Relay (CLI) X X X X
ICMP Path Jitter X X X X
APM X X X X
Voice with MOS/ICPIF Score X X
Post Dial Delay H323/SIP X
11. Supported Cisco IOS® Version (cont)
Feature/Release 12.2(2)T 12.2(11)T 12.3(4)T 12.3(12)T 12.4(1) 12.4(6)T 12.4(24)T 15.0(1)M
(Eng2)
MPLS/VPN Aware X X X X X X X X
Frame-Relay (CLI) X X X X
ICMP Path Jitter X X X X X X X X
APM X X X X
Voice with MOS/ICPIF Score X X X X X X
Post Dial Delay H323/SIP X X X X X
RTP VoIP (W/Codec) X X X
IPv6 Support X X
Auto Registration client (Responder X X
only)
• Ethernet OAM (CFM) introduced 12.2(33)SRB
• MPLS OAM (Health Monitor) introduced 12.2(27)SBC and 12.2(33)SRA
• Frame relay and APM removed in 12.4 and 12.4T
• ―Auto IP SLAs‖ has been FCS 15.1(1)T.
• IPv6 support in 15.0(1)M, 12.4(24)T and others.
• Check http://www.cisco.com/go/fn for a full list.
12. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
13. Scenario 1
SLA Verification & Management
• Customer obtains from Service Provider:
– Availability
– QoS
– Jitter SLAs
• Service Provider needs visibility to Customer Edge, in order to commit to SLAs
• Enterprise will verify SP SLAs by using access router edge to edge
measurements
– Enterprise may provide restricted Simple Network Management Protocol (SNMP)
(RTT, Latency, QoS) visibility into Access router for Service Provider
– Service Provider with restricted access can report SLA as a service back to the
enterprise
14. Scenario 2
Network Monitoring
• Cisco IOS IP SLAs answers the following question:
– What is jitter, latency, or packet loss between any two points in the network?
• IP Services can be simulated
– packet sizes, ports, class of service, packet spacing, and measurement frequencies
• Uni-directional and highly accurate measurements
• Measurements per class of service
– Validates service differentiation for data, voice, and video
• IP SLAs will identify an edge to edge network performance baseline
– Allows user to understand trends and anomalies from baseline
15. Scenario 3
IP Network Readiness
• Network assessment tool built into Cisco IOS Software
• Simulate IP Services and verify how well they will work in the
network
• Pre-deployment uses
– How well is QoS working in the network pre-deployment?
• Post deployment uses
– Continued verification of network performance per IP service
16. Scenario 4
Availability Monitoring
• Cisco IOS IP SLAs uses proactive monitoring for periodic, reliable and
continuous availability measurements
• Connectivity measurements from Cisco router to router or Cisco router to
server
• Threshold notifications when end point is not available
– What is the availability of a Network File System (NFS) server used to store
business critical data from a remote site ?
– Cisco IOS IP SLA UDP active measurement to specific server ports is used
to test remote site to server connectivity
– If server is unavailable, then traps can notify the network management
system
17. Scenario 5
Troubleshooting
• Proactive notification of problems and issues based on
threshold alerts
• Testing edge to edge consistently and reliably will save time
in finding and pin-pointing network performance problem
areas
• Supports activation of a second more granular test upon
initial detection of a problem by primary test
– Can test at a higher frequency or with different parameters to isolate
the problem
18. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
19. Configuration
• What
– Operation / protocol / parameters
• Where
– Destination IP address
• When
– Scheduling
– Distributed start-time
20. What?
Which Operation?
• ICMP based operations: • Other operations:
– ICMP Echo – TCP operation
– ICMP Path Echo – HTTP operation
– ICMP Path Jitter – DNS operation
• Responder-based – DLSW+ operation
operations: – DHCP operation
– UDP Echo – FTP get operation
– UDP Jitter – ATM operation
– FR operation
– VoIP Proactive monitoring
– Video Operation
21. ICMP Echo Operation (aka: ―ping‖)
• One packet sent, reports success and round trip time delay
ICMP Echo Probe
Source Destination
What? Where? When?
ip sla 6
icmp-echo 172.29.139.134
frequency 300
ip sla schedule 6 life forever start-time now
22. ICMP Echo Limitations
• One packet only -> no loss statistics
• ICMP is low priority ―by design‖ -> not representative
• Reports round trip time including processing time on the
responding side -> biased results.
23. UDP Jitter Operation
• Measures the delay, delay variation (jitter), corruption, misordering and
packet loss by generating periodic UDP traffic
• One-way results for jitter and packet-loss
– If clocks are synchronized and IOS is at least 12.2(T), one-way delay is also
measured.
• Detect and report out-of-sequence and corrupted packets
• Since 12.3(4)T -- also with MOS and ICPIF score for voice clarity
estimation.
• Requires IP SLA Responder to be configured on the target
– More on IP SLA Responder later …
24. UDP Jitter - Measurement Example
Send Packets STx = sent tstamp Receive packets
for packet x. i2
P2 i1 P1 P2 P1
ST2 ST1 RT2 RT1
Source IP Core Destination (Responder)
RTx = receive
tstamp for packet x.
Reflected packets Reply to packets dx = processing time
spent between
P1 i4 P2 P1 i3 P2 packet arrival and
treatment.
AT1 AT2 RT1+d1 RT2+d2
ATx = receive
tstamp for packet x.
Each packet contains STx, RTx, ATx, dx and the source
can now calculate:
JitterSD = (RT2-RT1)-(ST2-ST1) = i2-i1
JitterDS = (AT2-AT1)-((RT2+d2)-(RT1+d1)) = i4-i3
25. UDP Jitter Operation (Example)
• Simulating G.711 VoIP call
• Use RTP/UDP ports 16384 and above
– packet size is 172 bytes (160 bytes of payload + 12 bytes for RTP)
• Packets are sent every 20 milliseconds
• Marked with DSCP value of 8 (TOS equivalent 0x20)
ip sla 1
udp-jitter 10.52.130.68 16384
num-packets 1000 interval 20
tos 0x20
frequency 60
request-data-size 172
ip sla schedule 1 life forever start-time now
B C
A A = 20 ms
B = 20 s (1000 x 20 ms)
C = 40 s (60 s – 20 s)
26. etychon-1#sh ip sla statistics 1
Round trip time (RTT) Index 1
Latest RTT: 1 ms
Latest operation start time: *10:33:11.335 PST Fri Oct 7 2005
Latest operation return code: OK
RTT Values
Number Of RTT: 20
RTT Min/Avg/Max: 1/1/4 ms
Latency one-way time milliseconds
Number of Latency one-way Samples: 20
Source to Destination Latency one way Min/Avg/Max: 1/1/2 ms
Destination to Source Latency one way Min/Avg/Max: 1/1/3 ms
Jitter time milliseconds
Number of Jitter Samples: 19
Source to Destination Jitter Min/Avg/Max: 4/4/4 ms
Destination to Source Jitter Min/Avg/Max: 3/3/3 ms
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 5
Number of failures: 3
Operation time to live: 3166 sec
27. UDP Jitter for VoIP
MOS
• Newly introduced in Cisco IOS 12.3(4)T -- ―Advanced‖ feature set
• Modified jitter operation reports both Mean Opinion Score (MOS) and
Calculated Planning Impairment Factor (ICPIF)
• Those results are estimates and should be used for comparison only
– should not be interpreted as reflecting actual customer opinions
• Supported Codecs:
– G.711 A Law (g711alaw: 64 kbps PCM compression method)
– G.711 mu Law (g711ulaw: 64 kbps PCM compression method)
– G.729A (g729a: 8 kbps CS-ACELP compression method)
• Note: this is not a real RTP voice stream, but it has the same
characteristics
– For real RTP stream generation, see IP SLAs‘ ―VoIP RTP‖ operation.
28. UDP Jitter for VoIP
Sample Configuration
• Operation parameters autoconfigured to simulate a G729a codec
• 1000 packets, interval 20 ms, frequency 60 s (default values)
ip sla 30
udp-jitter 192.1.3.2 16001 codec g729a
ip sla schedule 30 start-time now
29. IP SLA RTP VoIP Operation
The Context
• How to evaluate the clarity of a voice call?
• Existing operations measures at the IP level, but have no
idea on how call clarity is impacted.
• How to map jitter/delay/loss with an application experience
like VoIP?
• We move toward service-oriented SLAs, and therefore
looking at the application impact rather than at the pure IP
metrics.
30. The RTP Operation
• Sends a real RTP stream, generated in software.
• Received and Decoded by a real Digital Signal Processor
(DSP).
• The jitter and drop metrics will be measured directly in the
DSP, in hardware.
• We support two DSPs, on a variety of platforms.
IOS RTP RTP RTP RTP RTP
IOS
DSP RTP RTP RTP RTP RTP
31. Collected Set of Statistics
• As of today, the IP SLAs RTP VoIP Operation can measure and report the
following metrics:
– RFC1889 (RTP) inter-arrival Jitter at source and destination
– R-factor at source and destination
– MOS-CQ (Mean Opinion Score -- Conversation Quality) estimated value using R factor
and G.107 R-factor to MOS conversion table.
– Packet Loss at source and destination
– Network round trip time
– Early packets
– Packets Out of Sequence
– Late Packets
32. Cisco IOS Version Support
• Platforms supported: 175x, 2600, 2800, 3600, 3800, 7200
running 12.4(4)T ―IP Voice‖ or higher.
• In the original release, one does only measure in one
direction: responder to sender.
• The bi-directional operation was introduced in 12.4(6)T.
33. IP SLAs RTP VoIP
Config Example
controller E1 0/0
ds0-group 15 timeslots 3 type e&m-wink-start
ip sla 3
voip rtp 10.48.164.20 source-voice-port 0/0:15 codec
g711ulaw
ip sla schedule 3 start-time now
34. IP SLAs RTP VoIP
Output Example
etychon-s#sh ip sla sta 3 details
Round Trip Time (RTT) for Index 3
Type of operation: rtp
Latest operation start time: 07:24:11.941 UTC Mon Feb 27 2006
Latest operation return code: OK
Latest RTT (milliseconds): 0
Source Measurements:
Interarrival Jitter: 0
Packets Lost: 0 Packets OutOfSequence: 0
Packets Late: 0 Packets Early: 0
R-factor: 92 MOS-CQ: 4.34
Over thresholds occurred: FALSE
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
35. Where? -> How to Probe?
• Optimize judiciously senders and responders placement.
– Full mesh
– Partial mesh (based on traffic matrix)
– Hub-and-Spoke
36. Nodes Operations
Where? 2 1
Full Mesh 3 3
4 6
5 10
6 15
7 21
8 28
n2 …
100
…
4950
• Good coverage, but…
• Number of operations is
proportional to the
square of the number of
nodes
• Does not scale
37. Where? • Determine a coverage
objective, ie: 30%.
Partial Mesh
• Build a traffic matrix to
identify the “hottest”
points (hint: use
NetFlow).
• Take the top 30% and
evenly distribute
operations
A B C D E F
B 5 6 7 5
C 1 7 12 12
D 7 5 5 11
E 4 4 12 2
F 3 8 4 18
38. Where?
Hub and Spoke
Some topologies are naturally ―hub and spoke‖
Branch offices
Service Providers with lots of CPEs
etc …
39. When?
When to run a test?
• Scheduling
• Multi-operation scheduling (groups)
• Randomized start-time
40. When?
Scheduling an operation to run
• Schedule operation 1 to start now:
ip sla schedule 1 start-time now
• Or at a specified time (8PM):
ip sla schedule 1 start-time 20:00:00
• Or in a recurrent way (every day at 8PM):
ip sla schedule 1 start-time 20:00:00
life 5 recurring
41. When?
Multi-Operation Scheduler
• Avoid overloading the router at boot with all operations starting at once.
– We introduce the notion of group.
• Starts many operations at once, with automatic smooth ―start-time‖.
– Introduced in 12.3(8)T
• Example: Start operations 1 to 10 within the next 10 seconds:
r1(config)#ip sla group schedule 1 1-10 schedule-period 10
start-time now
r1#sh ip sla op | i start
Latest operation start time: *12:50:51.599 PST Mon Apr 18 2005
Latest operation start time: *12:50:52.599 PST Mon Apr 18 2005
Latest operation start time: *12:50:53.599 PST Mon Apr 18 2005
Latest operation start time: *12:50:34.579 PST Mon Apr 18 2005
Latest operation start time: *12:50:35.579 PST Mon Apr 18 2005
Latest operation start time: *12:50:36.579 PST Mon Apr 18 2005
Latest operation start time: *12:50:37.579 PST Mon Apr 18 2005
Latest operation start time: *12:50:38.579 PST Mon Apr 18 2005
Latest operation start time: *12:50:39.579 PST Mon Apr 18 2005
Latest operation start time: *12:50:40.591 PST Mon Apr 18 2005
42. When?
Randomized start-time
• Group start time can be randomized – avoids ―synchronization effect‖
– ie: test happens always at the same time something else happens, like a route update
• Example: Start operation 1 to 5 within the next 44 seconds, and each
operation will have a random frequency varying between 10 and 15 seconds
ip sla group schedule 1 1-5 schedule-period 44 frequency range 10-15 start-time now
life forever
etychon-1#sh ip sla op | i start
Latest operation start time: *12:56:12.243 PST Thu Oct 13 2005
Latest operation start time: *12:56:06.323 PST Thu Oct 13 2005
Latest operation start time: *12:56:07.743 PST Thu Oct 13 2005
Latest operation start time: *12:56:13.323 PST Thu Oct 13 2005
Latest operation start time: *12:56:08.643 PST Thu Oct 13 2005
etychon-1#sh ip sla op | i start
Latest operation start time: *13:00:19.423 PST Thu Oct 13 2005
Latest operation start time: *13:00:15.895 PST Thu Oct 13 2005
Latest operation start time: *13:00:21.015 PST Thu Oct 13 2005
Latest operation start time: *13:00:25.303 PST Thu Oct 13 2005
Latest operation start time: *13:00:14.635 PST Thu Oct 13 2005 #CiscoPlusCA
43. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
44. IP SLA Accuracy...ICMP Echo Probe
ICMP Echo Probe
Sender Responder
(90% Process Load)
• With unloaded receiver, IPSLA measures 15.0 ms
• With high CPU load on the receiver: 58.5 ms!!
Any System Will Report Wrong Results when Excessive CPU Time Is
Spent on the Receiver Between the ICMP Echo Request and Echo
Reply
Fortunately, We Have a Solution…
45. Processing Time Measurement
• When running the responder, we have a clear advantage,
because…
– provides a mechanism to measure the processing time spent on the
receiving router
– inserts a timestamp when responder receives and sends the packet
– Receive timestamp done at interrupt level
• as soon as the packet is dequeued from the interface driver with absolute
priority over everything else
• Implemented for both UDP Echo and UDP Jitter operations
• Absolute tested accuracy is 1 ms.
– In other words, when it says 35 ms, it could be somewhere between 34
ms and 36 ms.
46. UDP Echo Operation (With IPSLA Responder)
T1 T2
T3
Sender T5 Responder
T4
Processing Delay on the Source: Tps = T5-T4
Processing Delay on the Destination: Tpd = T3-T2
Round Trip Time Delay: T = […] = T2 - T1 + T4 - T3
• We have no control of queuing delay on the source and
destination, but this is experienced by real traffic too, and must be
accounted as such
47. IP SLA Accuracy: UDP Echo Probe
UDP Echo Probe
Sender Responder
(90% Process Load)
• With unloaded receiver: 15.0 ms
• With 90% CPU receiver: 15.3 ms
The IPSLA Responder Processing Delay Will Be Subtracted from the
Final Results
48. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
51. Cisco IP SLA´s Performance:
UDP-Jitter for VoIP
UDP-Jitter Probe for VoIP (G.729a) Running Eng 3—Cisco IOS 15.1(4)M
Default Parameters: Frequency (60secs), Codec Packet Size (32bytes), Codec Interval (20ms), Codec Number of Packets (1000)
1921 2921 3925 3945 3945E
Operations (Total) 150 225 275 400 900
Operations/Second 2.5 3.75 4.58 6.7 15.0
Packets Per Second 2500.0 3750.0 4583.3 6733.3 15000.0
Operations/Min 150 225 275 400 900
CPU Usage ~59% ~61% ~43% ~54% ~43%
Each configuration being different, use those numbers with care: they are only an indication.
No SNMP polling were performed to gather the operation results
53. Performance Conclusions
• Under normal conditions and with reasonable targets, a
performance issue with IP SLA is unlikely
• Memory usage is reasonable, and should never be a
problem on any platform.
54. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
55. IP SLA Reaction Conditions
Reaction Trigger to Events
• Can send SNMP traps for certain ―triggering‖ events: Trigger:
– Connection Loss and Timeout
•Immediate
– Round Trip Time Threshold
•Consecutive
– Average Jitter Threshold
– Unidirectional packet loss, latency, jitter, MOS Scores
•X of Y times
•Average Exceeded
• Can trigger another IP SLA operation for further analysis
Threshold No Alert Threshold
Alert
Violation Violation Alert
100 ms
50 ms
Threshold
Time violation Resolution #CiscoPlusCA
56. Proactive Notification
• Simulating G.711 A-Law codec (64 kbps transmission) VoIP Call
set default values for:
Enables system message - codec-numpackets,
Source # logging globally - codec-size, &
logging on - codec-interval
ip sla 10
udp-jitter 209.165.200.225 dest-port 16384 codec g711alaw advantage-factor 2
owner admin
tag jitter-with-voice-scores
ip sla schedule 10 start-time now
ip sla reaction-configuration 10 react mos threshold-type immediate threshold-
value 490 250 action-type trapOnly
ip sla logging traps connectionLoss,
jitterAvg,
jitterDSAvg,
snmp-server host 10.10.10.10 version 2c public
snmp-server enable traps syslog jitterSDAvg,
Mos,
PacketLossDS,
PacketLossSD
To translate syslog into Rtt,
traps Timeout,
verifyError
57. Common Questions…
• How should I configure my operations to accurately measure
jitter/delay/packet loss?
• How many packets should be sent per operation?
• How frequently?
• What percentage of my bandwidth should be dedicated for
measurement?
58. Spectrum of Test
• This is the proportion of time during which the network is
under test
• A small spectrum of test means a small probability of
catching an event
• For example: running a test for 20 seconds every
60 seconds is equivalent to a 33% spectrum of test
59. Spectrum of Test
Network Is This Event
Under Test Was Missed
Delay
Time
60. Spectrum of Test
Network is Fault Is
Under Test Detected
Delay
Time
61. Number of Packets
• The more packets sent:
The larger the population
The more diluted are the results
• At identical frequency, the longer the operation, and the wider the test
spectrum.
• Example of result dilution with the same spectrum, but a bigger number of
packets per operation.
Non-diluted: Diluted:
62. Frequency
• The operation frequency, as well as
operation duration, have a direct impact
on the SPECTRUM OF COVERAGE
• Increasing the frequency will increase
your spectrum of coverage, and
increase the bandwidth consumed but
will not change the accuracy
63. Interval Effect of Jitter
• Longer intervals ultimately measures bigger jitter, because of coarse
granularity:
Delay
Time
Jitter
64. Interval Effect of Jitter
• Shorter intervals measurements are more granular, and hence give less
jitter:
Delay
Time
Jitter
65. Interval and Jitter
• Compare different jitter measurements ONLY if the
measurement intervals are identical
• Short interval is more accurate, but more expensive
– Use occasionally to have a true application-like jitter
• Long interval is less accurate, but consumes less bandwidth
– Use to expand test spectrum and keep an eye on jitter trends
66. Packet Size
• The main effect of packet size is to modify the
SERIALIZATION DELAY
• On fast links, this is negligible compared to the propagation
delay, so the packet size has little or not effect but to
consume bandwidth
• Use small packets of fast links, like on core network
• Use realistic packets for low-speed access links, where the
serialization delay is a factor we need
to count
67. Auto IP SLA
aka Engine 3
All New in 15.1(1)T
• Template Based CLI (Modular CLI)
• QoS Integration
• End-Point Auto Registration
• Cross-OS code base (works on Linux and FreeBSD)
• Responder performance enhancement
68. What, Where, When...
• ip sla auto-measure group wacho
destination ip-address alist-1 port 16000
type jitter
schedule id wa-sched
• ip sla list ip-address alist-1
ip-addresses 1.1.1.1, 2.2.2.2, 3.3.3.3
ip-addresses 10.1.1.1-100
ip-addresses exclude 10.1.1.5, 10.1.1.8
• ip sla auto-measure schedule wa-sched
start-time now
69. QoS Integration (example)
Observation: Need to send the same operation in each class.
Problem: Provision the same operation multiple times is lengthy, error prone, and
counter productive.
Solution: Discover the QoS classes on the outgoing interface and automatically
instantiate probes.
}
class-map voice-traffic
match dscp EF
QoS Class Definition
class-map data-traffic
match dscp AFnn
Automatically
policy auto-measure instantiate IP SLA
class voice-traffic
measure type ip-sla group voice-traffic-probes-grp
class data-traffic
measure type ip-sla group udp-jitter-probes-grp
} probes
70. End-Point Auto Registration
ip sla auto group test Hub to Spoke-1
measure type udp-jitter ip sla 34567
udp-jitter 10.10.10.2 5000
destination auto-discover dest-port 5000 Hub to Spoke-2
schedule now ip sla 87422
udp-jitter 20.20.20.2 5000
Hub to Spoke-3
Hub ip sla 363435
udp-jitter 30.30.30.2 5000
spoke-3
172.17.0.5
30.30.30.2 ip sla responder auto-register 172.17.0.5
10.10.10.2
20.20.20.2
spoke -1
spoke-2 ip sla responder auto-register 172.17.0.5
ip sla responder auto-register 172.17.0.5
71. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
72. Instrumentation and Management
• IP SLA fits in what is called Device Instrumentation
• Can be used standalone or it can be combined with other instrumentation
– e.g. Enhanced Object Tracking (EOT) Embedded Event Manager (EEM),
Performance Routing (PfR)
• To unleash its full potential, it works best with a Network Management
application
• Configuration
• Topology Management
Network Management • Data Retrieval
Application • Graphing
• Reporting
• Web Portal
• And much more!
73. Cisco Product Support
Cisco Prime Products
• LAN Management Solution
– Probe Configuration and Monitoring
– Most Operations supported
• Unified Operations Manager
– Voice Performance
– Configuration and Monitoring
• Collaboration Manager
– Video Performance
– Configuration and Monitoring
• Performance Manager
– IP SLA Reporting
#CiscoPlusCA
75. Agenda
• Introduction
• What is Cisco IP SLAs?
• Use Cases
• Configuration
• Accuracy
• Performance and Scalability
• Getting the Most out of IP SLAs
• Management Tools
• Summary and Conclusion
76. References
• Cisco IOS IPSLA home page
http://www.cisco.com/go/ipsla
• For questions related to Cisco IP SLAs that cannot be
handled by the Technical Assistance Center (TAC), feel free
to write an email to:
ask-ipsla@cisco.com
• Cisco Prime products
http://www.cisco.com/go/prime
78. Summary and Conclusion
• IP SLA is a Cisco IOS feature available today to actively and
proactively measure and report many network metrics.
• It is easy to use, and is supported by many existing network
management applications.
• We also have Ethernet OAM (for Metro Ethernet
Performance), MPLS OAM (L2 MPLS tests), Gatekeeper
Registration, H323/SIP Call Setup operation, and many other
features.
79. We value your feedback.
Please be sure to complete the Evaluation Form for this session.
Access today‘s presentations at cisco.com/ca/plus
Follow @CiscoCanada and join the #CiscoPlusCA conversation