Introduction to Network Performance
Measurement with
Cisco IOS IP Service Level Agreements
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
Delay launch of new applications due to network
performance concerns
What Are You Doing About Them?
The Business Challenges
Cisco IP SLAs can help
Ensure application efficiency by adding bandwidth (perhaps
unnecessarily)
Experience application downtime and degradation
Slow to Launch New Services
Increased TCO
Identify partial or incomplete network traffic conditions
Lack of Network Visibility
Reduced Network Performance
Your
Business
Networks
Cisco IP SLAs – Service Level Agreements
Access Enterprise Backbone Enterprise Premise Edge
Service Provider Aggregation Edge
Service Provider Core
Enterprise and Small Medium Business
Understand Network
Performance &
Ease Deployment
Verify Service Levels
Verify Outsourced SLAs
Measure and provide
SLAs
Service Providers
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
IP SLAs in a Nutshell
• Simple and easy to deploy
• Embedded in Cisco IOS
• CLI and SNMP access
• Wide Range of Coverage
• Multiple protocols
• Multiple applications
• Multiple operations
#CiscoPlusCA
Customer-proven Success
• Scalability and Performance
• Platform proliferation
• Millisecond precision
• Microsecond granularity
• Built-in Intelligence & Flexibility
• Scheduling and reporting
• Auto discovery
• QoS Integration
• Threshold Notifications
Active | Passive
Active Monitoring (Cisco IP SLAs) Passive Monitoring (NetFlow)
Sends synthetic packet for network measurement.
End-to-end Performance Metrics
Proactive troubleshooting
Watch for real traffic
At one point
No traffic == no conclusion
So how does it work?
Source
Management
Application
Configure
Destination
Destination
Responder
Operation 2
Operation 1
Configure
Collect
SNMP
Trap
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
Engine 1 Engine 2
RTR SAA IP SLAs
Engine:
Feature Name:
CLI: rtr… ip sla mon…
time
ip sla …
Engine 3
Supported Cisco IOS® Version Feature/Release 11.2 12.0(3)T 12.0(5)T
12.0(8)S
12.1(1)T
12.2
12.2(2)T 12.2(11)T
(Eng2)
12.3(4)T 12.3(12)T
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
Supported Cisco IOS® Version (cont) Feature/Release 12.2(2)T 12.2(11)T
(Eng2)
12.3(4)T 12.3(12)T 12.4(1) 12.4(6)T 12.4(24)T 15.0(1)M
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
only)
X X
• 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. http://www.cisco.com/go/fn
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
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
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
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
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
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
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
Configuration
• What – Operation / protocol / parameters
• Where – Destination IP address
• When – Scheduling
– Distributed start-time
What? Which Operation?
• ICMP based operations: – ICMP Echo
– ICMP Path Echo
– ICMP Path Jitter
• Responder-based operations:
– UDP Echo
– UDP Jitter
– FR operation
– VoIP Proactive monitoring
– Video Operation
• Other operations: – TCP operation
– HTTP operation
– DNS operation
– DLSW+ operation
– DHCP operation
– FTP get operation
– ATM operation
ICMP Echo Operation (aka: ―ping‖)
• One packet sent, reports success and round trip time delay
ICMP Echo Probe
Destination Source
What? Where? When?
ip sla 6
icmp-echo 172.29.139.134
frequency 300
ip sla schedule 6 life forever start-time now
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.
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 …
UDP Jitter - Measurement Example
Source RTx = receive
tstamp for packet x.
Send Packets
ST2
P2
ST1
P1 P2 i1
RT2 RT1
Receive packets
P2 P1 i2
RT1+d1 RT2+d2
Reply to packets
P2 P1 i3
AT1 AT2
Reflected packets
P2 P1 i4
Destination (Responder)
dx = processing time
spent between
packet arrival and
treatment.
IP Core
STx = sent 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
ATx = receive
tstamp for packet x.
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)
A
B C A = 20 ms
B = 20 s (1000 x 20 ms)
C = 40 s (60 s – 20 s)
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
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
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.
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
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.
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.
RTP RTP RTP RTP RTP
RTP RTP RTP RTP RTP
IOS IOS
DSP
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
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.
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
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
IP SLAs RTP VoIP Output Example
Where? -> How to Probe?
• Optimize judiciously senders and responders placement.
– Full mesh
– Partial mesh (based on traffic matrix)
– Hub-and-Spoke
Where? Full Mesh
• Good coverage, but…
• Number of operations is proportional to the square of the number of nodes
• Does not scale
Nodes Operations
2 1
3 3
4 6 5 10
6 15
7 21
8 28
… …
100 4950 n2
Where? Partial Mesh
• Determine a coverage objective, ie: 30%.
• 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
Where? Hub and Spoke
Some topologies are naturally ―hub and spoke‖
Branch offices
Service Providers with lots of CPEs
etc …
When? When to run a test?
• Scheduling
• Multi-operation scheduling (groups)
• Randomized start-time
When? Scheduling an operation to run
• Schedule operation 1 to start now:
• Or at a specified time (8PM):
• Or in a recurrent way (every day at 8PM):
ip sla schedule 1 start-time now
ip sla schedule 1 start-time 20:00:00
ip sla schedule 1 start-time 20:00:00 \
life 5 recurring
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
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
#CiscoPlusCA
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
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
IP SLA Accuracy...ICMP Echo Probe
• With unloaded receiver, IPSLA measures 15.0 ms
• With high CPU load on the receiver: 58.5 ms!!
ICMP Echo Probe
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…
(90% Process Load)
Responder Sender
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.
T2
UDP Echo Operation (With IPSLA Responder)
• 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
T5
T4
T3
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
Sender Responder
T1
The IPSLA Responder Processing Delay Will Be Subtracted from the
Final Results
• With unloaded receiver: 15.0 ms
• With 90% CPU receiver: 15.3 ms
IP SLA Accuracy: UDP Echo Probe
UDP Echo Probe
Responder Sender
(90% Process Load)
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
Cisco IOS IP SLAs Performance:
CPU Load by Platform
Oper/
Second
Oper/
Minute 2600 2620XM 3640 3725
7200VXR
NPE225
4 240 14 7 6 2 4
8 480 20 8 9 3 3
12 720 29 12 13 2 3
16 960 35 15 17 3 3
20 1200 41 19 22 2 3
24 1440 48 24 25 3 3
28 1680 56 27 28 3 3
32 1920 63 28 31 2 4
36 2160 67 31 35 2 3
40 2400 34 38 3 7
44 2640 38 43 4 8
48 2880 42 47 5 8
52 3120 46 49 5 10
56 3360 48 43 6 11
60 3600 52 58 6 11
(Jitter Probe Running Eng 2—2000 Active Jitter Oper—Cisco IOS 12.3(3))
Cisco IP SLA´s Performance: CPU
Oper/
Second
Pkts/
second
Oper/
Minute 2800 2811 2851 2691 3745 3845 3825 1841
4 200 240 3 3 1 2 1 0 2 3
8 400 480 6 5 2 3 1 1 3 4
12 600 720 8 7 3 4 2 2 5 6
16 800 960 10 9 4 5 2 2 7 8
20 1000 1200 13 11 4 6 3 3 8 10
24 1200 1440 15 13 5 8 4 4 10 11
28 1400 1680 18 14 6 9 4 4 12 13
32 1600 1920 20 16 7 10 5 5 14 15
36 1800 2160 23 18 8 11 5 6 16 17
40 2000 2400 24 20 9 12 6 6 17 18
44 2200 2640 27 21 10 14 7 7 19 20
48 2400 2880 29 21 11 15 7 8 21 22
52 2600 3120 32 22 12 16 8 8 23 23
56 2800 3360 34 22 13 17 9 9 26 24
60 3000 3600 36 23 14 18 9 9 27 26
(Jitter Probe Running Eng 2+—2000 Active Jitter Oper—Cisco IOS12.4(PI3)T)
No SNMP polling were performed to gather the operation results
Each configuration being different, use those numbers with care: they are only an indication.
Cisco IP SLA´s Performance:
UDP-Jitter for VoIP
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%
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)
No SNMP polling were performed to gather the operation results Each configuration being different, use those numbers with care: they are only an indication.
IP SLAs Typical Memory Usage
Eng2
12.2(13)T
UDP Jitter < 14KB
UDP Echo < 3.5KB
ICMP Echo < 3.2 KB
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.
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
IP SLA Reaction Conditions Reaction Trigger to Events
• Can send SNMP traps for certain ―triggering‖ events: – Connection Loss and Timeout
– Round Trip Time Threshold
– Average Jitter Threshold
– Unidirectional packet loss, latency, jitter, MOS Scores
• Can trigger another IP SLA operation for further analysis
#CiscoPlusCA
Trigger:
•Immediate
•Consecutive
•X of Y times
•Average Exceeded
Threshold
Violation
Threshold
violation
No Alert
100 ms
50 ms
Time
Alert Alert
Resolution
Threshold
Violation
Source #
logging on
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
snmp-server host 10.10.10.10 version 2c public
snmp-server enable traps syslog
Proactive Notification • Simulating G.711 A-Law codec (64 kbps transmission) VoIP Call
set default values for:
- codec-numpackets,
- codec-size, &
- codec-interval
To translate syslog into
traps
Enables system message
logging globally
connectionLoss,
jitterAvg,
jitterDSAvg,
jitterSDAvg,
Mos,
PacketLossDS,
PacketLossSD
Rtt,
Timeout,
verifyError
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?
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
Spectrum of Test
Network Is Under Test
This Event Was Missed
Time
De
lay
Spectrum of Test
Network is Under Test
Time
De
lay
Fault Is Detected
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:
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
Interval Effect of Jitter • Longer intervals ultimately measures bigger jitter, because of coarse
granularity:
Time
De
lay
Jit
ter
Interval Effect of Jitter • Shorter intervals measurements are more granular, and hence give less
jitter:
Time
De
lay
Jit
ter
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
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
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
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
QoS Integration (example)
class-map voice-traffic
match dscp EF
class-map data-traffic
match dscp AFnn
policy auto-measure
class voice-traffic
measure type ip-sla group voice-traffic-probes-grp
class data-traffic
measure type ip-sla group udp-jitter-probes-grp
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.
QoS Class Definition } Automatically
instantiate IP SLA
probes }
End-Point Auto Registration
30.30.30.2
spoke-3
10.10.10.2
spoke -1
172.17.0.5
Hub
ip sla auto group test
measure type udp-jitter
destination auto-discover dest-port 5000
schedule now
Hub to Spoke-1
ip sla 34567
udp-jitter 10.10.10.2 5000
Hub to Spoke-2
ip sla 87422
udp-jitter 20.20.20.2 5000
Hub to Spoke-3
ip sla 363435
udp-jitter 30.30.30.2 5000
spoke-2
20.20.20.2
ip sla responder auto-register 172.17.0.5
ip sla responder auto-register 172.17.0.5 ip sla responder auto-register 172.17.0.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
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
Network Management
Application
• Configuration
• Topology Management
• Data Retrieval
• Graphing
• Reporting
• Web Portal
• And much more!
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
IP SLA Partners
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
References
• Cisco IOS IPSLA home page
• For questions related to Cisco IP SLAs that cannot be
handled by the Technical Assistance Center (TAC), feel free
to write an email to:
• Cisco Prime products
http://www.cisco.com/go/ipsla
http://www.cisco.com/go/prime
Q&A
#CiscoPlusCA
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.
Follow @CiscoCanada and join the #CiscoPlusCA conversation
Access today‘s presentations at cisco.com/ca/plus
We value your feedback. Please be sure to complete the Evaluation Form for this session.