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

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


• Use Cases

• Configuration

• Accuracy





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

http://www.cisco.com/go/fn

http://www.cisco.com/go/fn

Agenda

• Introduction


• Use Cases

• Configuration

• Accuracy





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


• Use Cases

• Configuration

• Accuracy





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


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










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





etychon-1#sh ip sla op | i start






Agenda

• Introduction


• Use Cases

• Configuration

• Accuracy





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


• Use Cases

• Configuration

• Accuracy





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


• Use Cases

• Configuration

• Accuracy





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


• Use Cases

• Configuration

• Accuracy





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


• Use Cases

• Configuration

• Accuracy





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

[email protected]

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.

introduction to network performance measurement with cisco ios ip service level agreements

Technology

ip slas engine

t auto ip slas

ip slas history

unnecessarilycisco ip

video ip slas

ip services

slas enterprise

sp slas