Introduction to Network Performance Measurement with Cisco IOS IP Service Level Agreements

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

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

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

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

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

So how does it work?
Management
Application
Destination
Configure

Collect

SNMP
Configure Trap
Operation 1

Operation 2
Source

Responder
Destination

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 …

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

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.

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

Configuration
• What
– Operation / protocol / parameters

• Where
– Destination IP address

• When
– Scheduling
– Distributed start-time

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

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

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
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

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)

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.
IOS RTP RTP RTP RTP RTP
IOS
DSP RTP RTP RTP RTP RTP

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 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

Where? -> How to Probe?
• Optimize judiciously senders and responders placement.
– Full mesh
– Partial mesh (based on traffic matrix)
– Hub-and-Spoke

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

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

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):
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

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

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
etychon-1#sh ip sla op | i start
Latest operation start time: *13:00:14.635 PST Thu Oct 13 2005 #CiscoPlusCA

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…

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.

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

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

Cisco IOS IP SLAs Performance:
CPU Load by Platform
(Jitter Probe Running Eng 2—2000 Active Jitter Oper—Cisco IOS 12.3(3))
Oper/ Oper/ 7200VXR
2600 2620XM 3640 3725
Second Minute 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

Cisco IP SLA´s Performance: CPU
(Jitter Probe Running Eng 2+—2000 Active Jitter Oper—Cisco IOS12.4(PI3)T)
Oper/ Pkts/ Oper/
2800 2811 2851 2691 3745 3845 3825 1841
Second second Minute
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

Each configuration being different, use those numbers with care: they are only an indication.
No SNMP polling were performed to gather the operation results

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

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.

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

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 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

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 This Event
Under Test Was Missed
Delay

Time

Spectrum of Test

Network is Fault Is
Under Test Detected
Delay

Time

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:

Delay

Time
Jitter

Interval Effect of Jitter
• Shorter intervals measurements are more granular, and hence give less
jitter:

Delay

Time
Jitter

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)
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

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

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!

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

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

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.

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

Introduction to Network Performance Measurement with Cisco IOS IP Service Level Agreements

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Introduction to Network Performance Measurement with Cisco IOS IP Service Level Agreements

Semelhante a Introduction to Network Performance Measurement with Cisco IOS IP Service Level Agreements (20)

Mais de Cisco Canada

Mais de Cisco Canada (20)

Último

Último (20)

Introduction to Network Performance Measurement with Cisco IOS IP Service Level Agreements