Tecnms 3043 PDF

Getting Network Visibility via Cisco IP SLA
TECNMS-3043
Sumanth Kakaraparthi (Product Manager)

Sohayb Aiyub (Engineering)
Gaurang Mokashi (Engineering)
Abstract
 This session is intended for attendees that are already familiar with Cisco IP
SLA technology and want to go beyond the basics.
 Attendees will learn about recent additions to Cisco IP SLA such as IP SLA
auto discovery, Ethernet probes, multicast functionality, percentile support,
OnDemand UDP probes and RFC compliance 6812.
 In addition, we will talk about proactive threshold monitoring, EEM integration,

Accuracy Enhancements and more.
TECNMS-3043 © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda
 Overview and history
 IP SLA Architecture
 Manageability and Compliance
 New Probes
 Advanced Features
 Support and Documentation
Performance Monitoring - Technologies
Performance Monitoring
Active monitoring Passive monitoring
Mediatrace IPSLA TWAMP Unified Monitoring
Media Performance
IPSLA-VO Netflow
Monitoring Agent
Passive Monitoring – Component Positioning
Netflow • Basic network metrics
Media-monitoring • Voice & Video metrics
Performance • Application and TCP metrics

Agent
• Unified Architecture
Unified Monitoring • (Provisioning, Aggregation & Reporting)
Active Monitoring – Component Positioning
• Synthetic probe to calculate network and

IPSLA application metrics
IPSLA-VO • Synthetic probe for Video operations
Mediatrace • Path identification and fault locator
TWAMP • Standards based probe
What is a SLA?
 SLA stands for Service Level Agreement
 A SLA is a contract between a customer and a service provider to provide a

certain quality of service for the goods provided
 In the networking world, an SLA contract typically means providing a

guaranteed level of throughput, packet loss, jitter, availability, etc.
How can you tell if you are getting your SLA?
Answer: You measure it!
Cisco IP SLA
 Cisco IP SLA provides you with the tools to measure SLAs and get better
visibility of your network all within the routers you already own
 Active Measurements vs. Passive Measurements
 Probes: UDP, TCP, ICMP, Ethernet, HTTP, DNS, DHCP, FTP, Voip, Video,
Multicast, MPLS
 Metrics: Throughput, availability, RTT, jitter, latency, packet loss, packet

reorder
History Engine 1
 All version prior to IOS Software Release 12.2(13)T
 Original feature name called RTR (response time reporter)
 Feature name changed to SAA (service assurance agent) in 12.0(5)T
 Limited number of probes and functionality
 CLI name rtr
History Engine 2
 Released in 12.2(13)T, present in all 12.3 and later trains
 Major code rewrite for improved memory and performance, unlimited

operations, microsecond time stamping
 IPv6 support (limited)
 Feature name changed to IP SLA
 CLI name ip sla monitor, ip sla
History Engine 3
 Released in 15.1(1)T and later
 Modularization, cross OS rewrite
 Portability and feature consistency across platforms and trains
 New probes, template based configuration, QOS integration, auto discovery
 CLI name ip sla
Deployment - Enterprise
IPSLA
WAN1 WAN2
Jitter Jitter
100 ms
 40 ms WAN1
Pkt lossPkt
 100
loss  0 (IP-VPN)
WAN2
(IP-VPN)
HQ
Deployment - Service Provider
IPSLA
Access Aggregation Edge Multiservice Core

Aggregatio Distribution
Node Node
Residential ASR901 VoD TV SIP
ASR901
Ethernet
STB BNG Content Network
Aggregation IP/MPLS
Business Network
Corporate
IP/MPLS Core Core
Residential Business Network
DSL PE
STB ASR901
ASR901
PON
ASR9K
•Rich set of metrics and scale when using Cisco –on- Cisco equipment
IPSLA
Datacenter Deployment
L3 VPN IPSLA
WAN Edge
(ASR9K)
DCI
•Special probes to measure network
parameters on Fabric path
IPSLA-
Agg/
Fabric
Leaf (N7K)
Access
L2 or L3
(N5K, N6K)
Fabric •Delay can be measured from the UCS
(CSR) to WAN edge (ASr9K)
IPSLA-
ToR
Switches
Cloud
(N3K)
Software
Switches
/Routers
(CSR)
Agenda
 IP SLA Architecture Overview
 Proactive Threshold Monitoring
 Integration with Embedded Event Manager (EEM)
 IP SLA Tracking
 IP SLA Auto Discovery
 RFC 6812
IP SLA Architecture Overview
 Turn Cisco IOS/IOS-XE/IOS-XR/Nexus into an active probing device
 Monitor an endpoint using IP SLA probe
 Different monitoring protocols
 Each probe type has various supported statistics
IP SLA integration
Protocols and Technologies
Object Interface and

CLI SNMP EEM
Tracking Clients
IP SLA
IP SLA Infrastructure
Protocols &
HTTP/F DHCP/ VoIP/Vi Y.1731/
ICMP UDP TCP Path MPLS
TP DNS deo CFM Technologies
IP SLA Probe architecture
Components of an IP SLA probe
Scheduler Statistics
• Individual • Latest
• Group • Hourly
• Enhanced
• Distributed
Configuration
• Operation type
• History Reaction
• Owner/Tag
• VRF
• TOS
SLA
• Frequency Probe
IP SLA UDP-Jitter Probe
 Measures the delay, delay variation (jitter), corruption, out-of-sequence and
packet loss
 One-way results for jitter, packet-loss, delay
 MOS and ICPIF score for voice clarity estimation
 Statistics in ms or microseconds
 This operation always requires IPSLA responder
How UDP jitter works
Receive train of packets at
Send train of UDP packets with Interval impacted by network
constant Interval
IP SLAs Responder
IP SLAs Source
Per-direction (SD/DS) inter-packet delay (Jitter)

Per-direction (SD/DS) packet loss Time stamp when Rxed
IP SLA UDP-Jitter
 Configuration Example
IP SLA Sender
ip sla 1
udp-jitter 10.1.1.1 6500 num-packets 10 interval 20
frequency 60
ip sla schedule 1 start-time now life forever
IP SLA Responder
ip sla responder
IP SLA UDP-Jitter phases
IP SLA Sender SLA Responder

IP SLA Control Message
Control Port
Control
Phase
T1 IP SLA probe packet T2
Probing T3
Phase T4
RTT = (T4-T1)-(T3-T2)
IP SLA UDP-Jitter Statistics
Latest operation return code: OK
RTT Values:
Number Of RTT: 10 RTT Min/Avg/Max: 1/5/10 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 10
Source to Destination Latency one way Min/Avg/Max: 1/1/1 milliseconds
Destination to Source Latency one way Min/Avg/Max: 1/5/9 milliseconds
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/2/3 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/2/5 milliseconds
Packet Loss Values:
Loss Source to Destination: 0
Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 1
Number of failures: 0
IP SLA Improved Time Stamp for ASR1k
 In Classic IOS, IP SLA UDP packets has access to IP Stack time stamp on
packet receive
 On ASR1K platform, from 15.2(4)S - 3.7.0S IOS-XE, new CLI to enable this
support
ip sla 1
precision microsecond
optimize timestamp
IP SLA Architecture Overview
Q&A
Agenda
 IP SLA Tracking
 RFC 6812
Use SNMP Trap to notify NMS
Network
Management
System
(NMS)
SNMP
Trap
Measure
IP SLA Sender
Measure
Proactive Threshold Monitoring Overview
 Alarm system for Cisco IP SLA
 Called “reaction” in IP SLA terminology
 Comes from the ability of IP SLA to “react” to certain measured conditions
Proactive Threshold Monitoring Overview
 Reactions provides the ability to set threshold values for metrics collected and
take actions
 Actions include:
 Sending an SNMP Trap
 Executing another IP SLA operation
 Executing an Embedded Event Manager (EEM) script
 Multiple reaction elements can be monitored for a single probe
What makes up the Reaction Component?
Action
Types:
• Trap
• Syslog
• Trigger
Reaction Threshold
Types types
• Statistics metrics
such as RTT, Reaction •
•
Immediate
Average
Jitter along with
threshold value • XofY
Component • Consecutive
Reaction Configuration Example
IP SLA Sender
ip sla 1
frequency 60
ip sla reaction-configuration 1 react rtt threshold-value 60 40 action-type trapOnly threshold-type

immediate
Threshold-value defines the upper and lower limit

values that will trigger an event
Reaction Graphical Example
120
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
120
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
120
Reached rising threshold. Execute Action
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
120
No new action taken
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
120
No new action taken
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
120
Falling threshold reached. Clear action
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
120
No new action taken
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
120
No new action taken
RTT (milliseconds)
100
Falling Threshold
80 Rising Threshold
60
40
20
0
11:58 12:00 12:01 12:02 12:04 12:05 12:07 12:08 12:10
Reaction Trigger CLI
ip sla 1
http get http://10.1.1.1/index.html
tag bob_probe_to_wiki_server
frequency 60
ip sla 2
icmp-echo 10.1.1.1
frequency 5
ip sla schedule 2 start-time pending life forever
ip sla reaction-configuration 1 react timeout action-type trapAndTrigger threshold-type immediate
ip sla reaction-trigger 1 2
Reaction-trigger defines the IP SLA operation to
start when a “trigger” action is specified
SNMP TRAP Output
sysUpTime.0 = 24649
snmpTrapOID.0 = rttMonNotification
rttMonCtrlAdminLongTag.1 = bob_probe_to_wiki_server
rttMonHistoryCollectionAddress.1 = AC 1B 77 01
rttMonReactVar.1 = 1
rttMonReactOccurred.1 = 1
rttMonReactValue.1 = 8
rttMonReactThresholdRising.1 = 4
rttMonReactThresholdFalling.1 = 3
Reaction Configuration CLI
Router(config)# ip sla logging traps Enable syslog

messages
Router(config)# snmp-server host 10.1.1.1 version 2c public ipsla
Router(config)# snmp-server enable traps ipsla
Configure snmp server host
Enable IP SLA SNMP traps
Proactive Threshold Monitoring
Q&A
Agenda
 IP SLA Tracking
 RFC 6812
Detecting IP SLA events
 Problem
 When connectivity is lost to the host, Bob wants to automatically add a static route to
the routing table and also send an email to Bob’s team informing of the changes
 Solution
 Use EEM to create CLI applet policy or a TCL script to add the entry in the routing
table when reachability goes down and send an email
 Remove the static route entry from the routing table once host is reachable again and
also send email informing the team that the host is reachable again
Integration with Embedded Event Manager (EEM)
Cisco IOS
 EEM is a policy-based framework that
provides a way to monitor key system
events and then act on those events
through a set policy
 EEM Server listens to various Event

Detectors such as the IP SLA ED
EEM Policies
 EEM policy is a pre-programmed script
 Script defines actions to be invoked based on an event occurrence
 Users can write two types of EEM policies:
 CLI based policies called applets
 TCL based policies
Embedded Event Manager (EEM) Actions
Execute
CLI cmd Send a
Log to
syslog
CNS
event
Reply to
an SNMP +- EEM
GET/SET counter
request
Send EEM Force

SNMP trap switchover
Actions
Get
Reload system
information
Publish an
application Send e-
specific Exec mail
EEM event EEM
policy
EEM IP SLA Event Detector (ED)
 Available as part of EEM v3.0, introduced in 12.4(22)T
 IP SLA Event Detectors notifies EEM when an event of interest occurs
 Based on this event, an action can be taken; i.e. executes policies that match
the configured criteria
IP SLA ICMP Echo Operation Example
1. Create IP SLA icmp echo operation, reaction configuration, and schedule
Enable reaction alerts

ip sla enable reaction-alerts for EEM integration
ip sla 1
icmp-echo 10.48.164.19
ip sla schedule 1 life forever start-time now
ip sla reaction-configuration 1 react timeout threshold-type consecutive 3
Trigger a reaction
event on 3
consecutive timeouts
EEM IP SLA CLI Applet
2. Create EEM CLI Applet policy using the event manager applet command
Router1(config)#event manager applet sla_failover

Policy name
3. Define the event criteria for the applet

 The event criteria describes the filtering
criteria for the policy to be executed
Router1(config-applet)#event ipsla operation-id 1 reaction-type timeout
Execute the policy sla_failover when an ip sla event with

operation id 1 and reaction-type of timeout occurs
EEM IP SLA CLI Applet Actions
4. Create the EEM actions to be executed when the specified event is triggered
event manager applet sla_failover
event ipsla operation-id 1 reaction-type timeout Timeout
Condition
action 010 string equal $_ipsla_condition "Occurred"
“Occurred”
action 020 if $_string_result eq 1
action 030 syslog msg "Add in the backup route"
action 040 cli command "enable"
action 050 cli command "config t"
action 060 cli command "ip route 0.0.0.0 0.0.0.0 Gig0/0”
action 070 cli command "end”
action 080 mail server mailserver.example.com
to teambob@example.com from bob@example.com
subject "Host X is unreachable"
body "Adding static route to reroute packets”
action 090 syslog msg ”Email sent to Bob“
action 100 end
action 110 string equal $_ipsla_condition "Cleared" Timeout
action 120 if $_string_result eq 1 Condition
action 130 syslog msg "Removing static route" “Cleared”
action 140 cli command "enable"
action 150 cli command "config t"
action 160 cli command "no ip route 0.0.0.0 0.0.0.0 Gig0/0"
action 170 cli command "end"
action 180 mail server mailserver.example.com
to teambob@example.com from bob@example.com
subject "Host X is now reachable"
body ”Removing static route"
action 190 syslog msg ”Email sent to Bob"
action 200 end
Integration with EEM
Q&A
Agenda
 IP SLA Tracking
 RFC 6812
How to use redirect traffic based on IP SLA?
 Can device 1 reroute only the web traffic to device 5 if device 4 is experiencing
congestion?
Switch 2 Main Server
Device 1
Switch 3 Mirror Server
IP SLA Tracking Overview
 Can change routing using object tracking and IP SLA
 Two ways:
– Static routes
– PBR (Policy Based Routing)
 Create IP SLA probe as a tracking object
 Use tracking object in PBR clause or static route
IP SLA tracking for PBR
ip sla 1
udp-jitter 10.1.1.1 6500
timeout 50 UDP-Jitter probe with 50
frequency 3 millisecond timeout
track 1 ip sla 1 reachability Track object for IP SLA reachability
Route-map for PBR:

route-map PBR permit 10 1) Go to 11.0.0.1 if IP SLA is
match ip address ACL reachable
set ip next-hop verify-availability 11.0.0.1 10 track 1
set ip next-hop 12.0.0.1
2) Go to 12.0.0.1 if IP SLA is not
reachable
interface eth1/1
ip policy route-map PBR Apply route-map on ingress
interface
IP SLA tracking for Static Route
ip sla 1
icmp-echo 10.1.1.1
frequency 3
ip sla schedule 1 start-time now Track object for IP SLA reachability
track 1 ip sla 1 reachability
ip route 11.0.0.0 0.255.255.255 Ethernet1/0 track 1 This static route is inserted when
track 1 object reports status of up.
Route is removed otherwise.
IP SLA Tracking
Q&A
Agenda
 IP SLA Tracking
 RFC 6812
IP SLA Auto Discovery Overview
 Traditional IP SLA requires that all endpoints IP addresses be known in
advance
 Drawbacks
 Individual endpoint addresses need to be manually provisioned on the sender
 Work Intensive
 Error Prone
 Not practical for CPEs whose IP addresses are frequently changing
 IP SLA Auto Discovery solves this by having the endpoints (responders)

automatically register with the sender
IP SLA Auto Discovery Overview
 Hub and Spoke Configuration IP SLA Sender
Hub
192.168.1.1
ip sla responder
auto-register 192.168.1.1 IP SLA Spokes
endpoint-list my-autolist
IP SLA Auto Components
Auto Group
Auto Scheduler
Endpoint List
Auto Template
IP SLA Auto Discovery Configuration Steps
 Sender
1. Enable auto discovery feature
2. Create endpoint list
3. Create auto template
4. Create auto schedule
5. Create auto group and add endpoint list, auto template, and
auto schedule to the auto group
 Responder
 Enable ip sla responder with auto-register and endpoint list
IP SLA Auto Discovery Summary Configuration
 Sender
ip sla auto discovery
ip sla endpoint-list type ip my-autolist
discover
ip sla auto template type ip icmp-echo my-icmp-echo-template
ip sla auto schedule my-auto-schedule
life forever
start-time now
ip sla auto group type ip my-group
schedule my-auto-schedule
template icmp-echo my-icmp-echo-template
destination my-autolist
 Responder
ip sla responder auto-register 192.168.1.1 endpoint-list my-autolist
Show IP SLA Auto Summary Stats CLI
Router# show ip sla auto summary-statistics group type ip mygroup
IP SLAs Auto Group Summary Statistics
Summmary Statistics:
Auto Group Name: my-group

Template: my-icmp-echo-template
Number of Operations: 2
sno oper-id type n-rtts rtt avg-jitter packet
(min/avg/max) (DS/SD) loss
1 356193376 icmp-echo 20 1/1/1 ms NA NA
2 2123562493 icmp-echo 20 1/1/2 ms NA NA
Auto IP SLA Configuration
 Sender
ip sla auto endpoint-list type ip my-autolist
ip-address 10.1.1.1,10.1.1.2 port 6500
ip-address 11.1.1.1-252 port 6500
ip sla auto template type ip icmp-echo my-icmp-echo-template
ip sla auto schedule my-auto-schedule
life forever
start-time now
ip sla auto group type ip my-group
schedule my-auto-schedule
template icmp-echo my-icmp-echo-template
destination my-autolist
IP SLA Auto Discovery
Q&A
Agenda
 IP SLA Tracking
 RFC 6812
RFC 6812 Overview
 Describes Cisco's Service Level Assurance Protocol used in the IP SLA
application
 Protocol used in udp-jitter
 Allows 3rd party clients to communicate with Cisco IP SLA sender and
responder application
 Released in 15.4T
SLA Control Protocol UDP Measurement CSLD
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command | Status | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
| Command length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
| Address Type | Role | Reserved | | Measurement Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
| Session Identifier | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Control Source Port | Reserved |
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Source Address | | Measurement Source Port | Measurement Destination Port |
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Duration |
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Control Destination Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Measurement Source Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter Measurement Request Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Send Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Receive Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Send Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Receive Time |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Clock Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Clock Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence No. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Sequence No. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Data Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Show ip sla responder support for RFC 6812
iou131#sho ip sla responder
General IP SLA Responder on Control port 1967
General IP SLA Responder on Control V2 port 1167
General IP SLA Responder is: Enabled
Number of control message received: 0 Number of errors: 0
Recent sources:
Recent error sources:
Number of control v2 message received: 2 Number of errors: 0

Recent sources:
192.16.0.1 [22:31:32.952 PST Mon Jan 21 2013]
192.16.0.1 [22:30:54.740 PST Mon Jan 21 2013]
Recent error sources:
Permanent Port IP SLA Responder

Permanent Port IP SLA Responder is: Disabled
iou131#
RFC 6812
Q&A
15 Minutes Break
Agenda
 Multicast Feature
 Video Operation Probe
 Ethernet Probes
 Percentile Support
 On-demand UDP Probes
 Feature Matrix
Example Multicast Network
Router B
Receiver 1
Router A
Receiver 2
Server
Multicast Address
Router D
239.1.1.1
Router C
Receiver 3
IP SLA Multicast Feature – Use Case Examples
 Any one-to-many data push applications

– Finance Applications
 Trading Stocks and Commodities
– Streaming Multimedia
 E-Learning
 Corporate communications
– Enterprise Resource Applications
 Data warehousing and content synchronization
IP SLA Multicast Feature – Introduction
 UDP jitter command now supports multicast addresses
– udp-jitter 239.1.1.1 1234 endpoint-list responder_list
 Measures
– one way delay
– jitter
– packet loss
 Full support for all IP SLA udp-jitter command options
– No support for IPv6
 No other configuration required
– IP SLA will issue IGMP JOIN & LEAVE
IP SLA Multicast Feature – Endpoint Introduction
 Multicast uses static endpoint list

– No auto discovery
 Contains list of all destination responders

– Multicast operation ignores port value in endpoint list
 Can be shared between other multicast operations & auto group
IP SLA Multicast Feature – Endpoint List
Configuration
 Endpoint list configuration example:

ip sla endpoint-list type ip mcast-list
ip-address 171.2.25.1,192.68.1.2,192.68.1.15 port 1234
ip-address 192.68.5.4-6 port 4321
ip-address 171.3.51.4 port 33322
 This shows that there can be both a range of address, or individual device
addresses
– The port value from the endpoint-list is actually ignored by the multicast operation
– Operation level destination port is used instead for data packets
IP SLA Multicast Feature – Endpoint List Show
 Here is the output of the show command:
show ip sla endpoint-list
Endpoint-list Name: mcast-list
Description:
List of IPV4 Endpoints:
ip-address 171.2.25.1,192.68.1.2,192.68.1.15 port 1234
ip-address 192.68.5.4-6 port 4321
ip-address 171.3.51.4 port 33322
 Again, the port value here is ignored by the multicast UDP-jitter operation, but it
is used by the auto group (if this endpoint-list is referenced)
IP SLA Multicast Feature – Brief Overview
 Unicast control message sent to each responder
– Used to perform an IGMP Join for the given multicast group
 Wait for all responses, or give up after timeout (at least one must respond)
 Send one way UDP packets on the multicast group
 Poll each valid responder for the statistics
 Use existing “show statistics” IP SLA commands to display values from each
responder
IP SLA Multicast Feature – Unicast Control Setup
Responder
192.68.1.2
Sender
168.16.1.2 Responder
168.16.1.15
Responder
171.2.25.1
IP SLA Multicast Feature – Unicast Control
Response
Responder
192.68.1.2
Sender
168.16.1.15
Responder
171.2.25.1
IP SLA Multicast Feature – Multicast Packet
Transmission
Responder
192.68.1.2
Sender
168.16.1.15
Responder
239.1.1.1 171.2.25.1
IP SLA Multicast Feature – Unicast Statistic
Retrieval
Responder
192.68.1.2
Sender
168.16.1.15
Responder
171.2.25.1
IP SLA Multicast Feature – Unicast Statistic
Retrieval Response
Responder
192.68.1.2
Sender
168.16.1.15
Responder
171.2.25.1
IP SLA Multicast Feature – Similarities to Unicast
UDP-jitter
 Uses existing UDP-jitter operation (both CLI & SNMP)
 Reuse of all existing reaction and scheduling options common to all SLA
operations
 All UDP-jitter sub-mode operations supported
IP SLA Multicast Feature – Requirements &
Restrictions
 List of unicast IP addresses for each responder
– Requires bi-directional UDP unicast routing between sender to responder
 Similar responder software version

– Will not work with legacy responders
 Older responders will be unable to receive control message
 Potential CPU load on responder

– Higher load on responder than on sender
 Opposite of unicast udp-jitter
IP SLA Multicast Feature – Operation Configuration
ipsladev3945-7(config-ip-sla)#udp-jitter 239.1.1.1 43225 endpoint-list mcast ?

codec codec type to be configured
interval Inter Packet Interval
num-packets Number of Packets to be transmitted
source-ip Source address SSM: new
source-port Source Port multicast option
ssm Source Specific multicast configuration
<cr>
IP SLA Multicast Feature – SSM
 SSM: Source Specific Multicast configuration
– This is a new option specific to the multicast version of UDP-jitter
– source-ip & source-port become mandatory parameters (they were optional before)
– Will force the responder to ONLY accept multicast packets from this source
IP SLA Multicast Feature – Changes from Unicast
udp-jitter
 CLI detects multicast address, and presents different options
 “endpoint-list” is required for multicast
 Statistics stored on responder until retrieved by sender
 Reactions happen on sender once statistics are available
IP SLA Control Message Options
ipsladev3945-2(config-ip-sla-multicast-jitter-oper)#?
Allows
IP SLAs Udp Mcast Configuration Commands: modification to the
control Set control protocol parameters control retry &
default Set a command to its defaults timeout
…..
ipsladev3945-2(config-ip-sla-multicast-jitter-oper)#control ?
retry How often the control message should do a retry (default 3 times)
timeout How long to wait for control message timeout (default 5 seconds)
ipsladev3945-2(config-ip-sla-multicast-jitter-oper)#control retry ?
<1-5> Retry count
ipsladev3945-2(config-ip-sla-multicast-jitter-oper)#control timeout ?
<1-10000> control timeout in milliseconds
IP SLA Multicast Feature – Multicast Tree
Receiver 1
Router A
Receiver 2
Server
Router B
Link on multicast Tree Receiver 3
Link not on multicast tree
IP SLA Multicast Feature – Multicast Tree Setup
 Multicast group can either exist or be new
 Option to perform tree setup
– Send packets to enable tree before measuring
 IP SLA created group removed when test measurement is done
tree-init Number of packets to send to setup multicast tree
(default 0)
ipsladev3945-2(config-ip-sla-multicast-jitter-oper)#tree-init ?
<0-10> Number of packets to send to setup multicast tree
IP SLA Multicast Feature – Show Configuration
IP SLAs Infrastructure Engine-III
Entry number: 111
Owner:
Tag:
Operation timeout (milliseconds): 5000 Multicast
Type of operation to perform: mcast destination group
Endpoint list: mcast-list IP address
Target address/Source address: 239.1.1.1/0.0.0.0
Target port/Source port: 43352/0
Type Of Service parameter: 0x0
Request size (ARR data portion): 64
Packet Interval (milliseconds)/Number of packets: 20/10
………
IP SLA Multicast Feature – Show Configuration
contd.
Verify data: No
Vrf Name:
New Options status
DSCP: 0
Number of packets to set multicast tree: 0
SSM: disabled
Control message timeout(seconds): 5000
Control message retry count: 3
Schedule:
………
IP SLA Multicast Feature – Statistic Restrictions
 Only support One Way values (multicast packets by definition are not returned
to sender)
 NTP Sync: required between sender and all responders, otherwise values are
not to be trusted
 Requires unicast path from responder(s) back to sender

– Sender will poll each end device to retrieve the individual responder statistics
IP SLA Multicast Feature – Show Statistics Main
Operation
 Multicast operation creates sub-operations

– One for each entry in endpoint-list
 Show statistics on main operation

• Shows OK if every sub-operation returns OK
• Displays summary of sub-operation values
• Displays generated operation ID of the sub-operation operation
• Additional detail stats use the generated ID
IP SLA Multicast Feature – Operation Hierarchy
Multicast Operation
(ip sla 111)
Sub-Operation Sub-Operation
(990304393) (1338177948)
IP SLA Multicast Feature
show ip sla statistics 111
IPSLAs Latest Operation Statistics
IP SLA operation id: 111

Type of operation: mcast
Latest operation start time: 00:08:15 PST Wed Feb 29 2013 Summary of Sub-
Latest operation return code: OK Operation (unicast IP
address responder)
oper-id status lossSD delay destination
990304393 OK 0 9/12/17 1.2.3.4
1338177948 OK 0 5/12/17 3.4.5.6
Operation time to live: 3179 sec
IP SLA Multicast Feature – Show Statistics Sub-
operation
 Full details of operation
 Responder specific
 Sub-operations are transient

– Removed when main operation is removed
operation (Cont)
ipsladev3945-2#show ip sla statistics 990304393
Sub-Operation
IP SLA operation id: 990304393 Generated ID
Type of operation: mcast
Multicast operation id: 111
Latest operation start time: 00:08:15 PST Wed Feb 29 2013
NTP sync state: SYNC
operation (Cont)
Inter Packet Delay Variation, RFC 5481 (IPDV):
Number of SD IPDV Samples: 9
Source to Destination IPDV Min/Avg/Max: 0/4/8 milliseconds
Packet Loss Values:
Packet MIA: 0
Out Of Sequence: 0 Tail Drop: 0
Duplicate Sequence Number Count: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Operation time to live: 3168 sec
IP SLA Multicast Feature – Reactions
One way only
 Connection Loss
 Jitter Average in the direction from Source to Destination
 Latency Average from Source to Destination
 Packet Loss in the direction from Source to Destination
 Timeout
IP SLA Multicast Q & A
Multicast Probe Demo
Multicast Demo Topology
responderB
(10.10.10.2)
SenderA Receiver 1
(10.10.10.1)
Server
Multicast Address ResponderD

(10.10.12.2)
239.1.1.1
ResponderC
(10.10.11.2)
Receiver 3
Agenda
 Ethernet Probes
 Feature Matrix
Typical Video Network
Video Source
Remote End
116
TelePresence Jitter Requirements
 http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TelePresence_Ne
twork_Systems_2.0_DG.pdf
 Cisco TelePresence has a peak-to-peak jitter target of 10 ms

Metric Target Threshold 1 Threshold 2
(Warning and (Call Drop)
Downgrade)
End-to-end 10 ms 20 ms 40 ms
Service Provider 5 ms 10 ms 20 ms
TelePresence Loss Requirements
 Cisco TelePresence is highly sensitive to packet loss, and as such has an end-
to-end packet loss target of 0.05%
Metric Target Threshold 1 Threshold 2

(Warning and (Call Drop)
Downgrade)
End-to-end 0.05% 0.10% 0.20%
(1 in 2000) (1 in 1000) (1 in 500)
Service Provider .025% .05% .10%
IP SLA Video – Pre-deployment Planning
 Objective
Enable Clientless deployment and capacity planning
- How many streams at bandwidth x at this time of day can we expect to support?
- What delay/loss impact does the addition of an extra stream at bandwidth X?
 Solution Value
Clientless pre-deployment and provisioning for network readiness assessment
and traffic modeling.
Operations
System (OSS) or
Application
Use case – Test call and troubleshooting
 Objective
Important TelePresence meeting coming up, network admin wants to test the network
for
Capacity (bandwidth + latency) and/or correct configuration.
 Solution Value
Network admin uses NMS to generate realistic video traffic and collect statistics along
the path. Generate
Reports using
Mediatrace
Cat
Generate
3K Realistic Video
IP SLA Video - Introduction
 Generates synthetic traffic
 Provides one way traffic results
 Various video profile types

– IPTV, Video Surveillance
X – Extensible via data file
X
TECNMS-3043 © 2013 Cisco and/or its affiliates. All rights reserved.
 Configurable profiles (platform
specific)
Cisco Public 121

IP SLA Video – Operation Overview
 Profile selection determines generation rate

– This profile simulates an actual video session; no real video is transmitted
 Operation is duration based
 Control Exchange to setup destination
 RTP packets transmitted one way
 Statistics are collected and calculated on the responder
 Sender requests the statistics at the end of the operation
IP SLA Video – Probe Configuration
– video 10.5.139.12 4325 source-ip 172.27.118.132 source-port 4322 profile
Telepresence
default Set a command to its defaults New options for
dscp Configure DSCP video operation
duration Duration of video
exit Exit operation configuration
frequency Frequency of an operation
history History and Distribution Data
no Negate a command or set its defaults
owner Owner of Entry
tag User defined tag
threshold Operation threshold in milliseconds
timeout Timeout of an operation
ttl Time to live
vrf Configure IP SLAs for a VPN Routing/Forwarding instance
IP SLA Video – Profile (default) vs Platform
IP Video
IP TeleVision
Platform\Profile TelePresence Surveillance Cisco Phone
(IPTV)
Camera (IPVSC)
Cisco Catalyst 3k
Cisco Catalyst 4k
Custom
Cisco ISR G2
Profile
IP SLA Video - architecture
SOURCE DESTINATION
CLI Show Ctrl Msg

IP SLA
commands/SNM Stats Req Responder
P MIB API
Ctrl Msg
IP SLA Video
Operation Stats Req
(Sender)
Traffic Media Generator
Profile PI Control status
PI
PD PD
IP SLA Video IP SLA Video
Operation Operation
(Sender) Traffic sink
PI : Platform independent
PD : Platform dependent
IP SLA Video – Control Setup & Response
 Single responder only
 Same for every platform

Sender
171.2.25.1
IP SLA Video – Control Setup & Response
 UDP control message will be sent to the destination device

1. Verify responder resources
SOURCE DESTINATION
2. Setup video responder
CLI Show
Ctrl Msg IP SLA
commands/
SNMP MIB Stats Req Responder
API
Ctrl Msg
 UDP control response is sent back to sender IP SLA

Video
Stats Req
– OK (if fine)
Operation
(Sender)
PI
– Error code (if failure)

PI
PD P
D
IP SLA Video IP SLA Video
Operation Operation
IP SLA Video – Video Packet Flow
 One way traffic only
Sender
171.2.25.1
IP SLA Video – Video Packet Flow
 Each packet has sequence number

SOURCE DESTINATION
and transmit timestamp
CLI Show Ctrl Msg
IP SLA
commands/SN Responder
Stats Req
 Receive side determines: MP MIB API

Ctrl Msg
– Receive Timestamp IP SLA Video

– Sequence Number Operation
(Sender)
Stats Req
– Packet size PI
PI
PD PD
 Common code portion calculates statistics IP SLA Video

Operation
IP SLA Video
Operation
– Number of packets sent ONLY known at

end of duration
IP SLA Video – Statistics Request & Response
 Sender polls for stats
Sender
171.2.25.1
IP SLA Video – Statistics Request & Response
 All statistical calculation performed

SOURCE DESTINATION
on responder
CLI Show Ctrl Msg
IP SLA
commands/SN Responder
Stats Req
MP MIB API
 Sender is required to poll Ctrl Msg
responder for statistical information IP SLA Video

Operation Stats Req
(Sender)
PI
PI
 If connection to responder is lost, no PD PD
statistics will be available IP SLA Video IP SLA Video

Operation Operation
IP SLA Video – Restrictions
 Limited Release Availability
– 12.2(58)SE2, 150-1.SE2 (and later) -- Cat3k
– 15.2(2)T (and later) -- ISR-G2
– 15.1(1)SG (and later) -- Cat4k
 Platform hardware requirements

– Unlike the rest of IP SLA operations, video requires platform support
– Packet generation at application level (where IP SLA resides) would not be fast
enough to simulate a valid video stream
IP SLA Video – Platform Dependence
 Sender platform independent (PI)
– IP SLA operation creation, scheduling, reaction similar to all other operations
 Sender platform dependant (PD)
– Actual packet generation performed by platform
 Different platforms have different methods of generating the packets
– Hardware support required for generation
 Responder PI
– Control protocol and statistic calculations
 Responder PD
– Low level packet read off interface for more accurate timestamp
IP SLA Video – Platform Differences
 Three different platforms that currently support the video operation
– Cat3k
 (Pure software (interrupt based))
– Cat4k
 (FPGA)
– ISR-G2
 (DSP)
 Video needs to be transmitted at a much higher data rate as compared to other
IP SLA operations (udp-jitter, etc)
 Each platform team provided a different way to produce these packets
IP SLA Video – Cat3K
 Software based video packet generation
 3 Default profiles supplied with device

– IPTV IP Television traffic (2.6 Mbps)
– IPVSC IP video surveillance camera traffic (2.2 Mbps)
– TELEPRESENCE Cisco Telepresence 1080P traffic (6.6Mbps)
 Ability to load in custom profiles
– Take PCAP file and run it through Cisco provided tool to generate new profile
– Load profile into flash on device, and it gets added to the list of available profiles
– http://www.cisco.com/web/solutions/medianet/knowledgebase/index.html - ~design
IP SLA Video – Cat4K
 FPGA based video packet generation
– Requires SUP-7E or SUP-7LE
 3 Default profiles supplied with device

– IPTV IP Television Traffic (2.30 Mbps Avg)
– IPVSC IP Video Surveillance Camera Traffic (2.30 Mbps Avg)
– Telepresence Cisco Telepresence 720P Traffic (7.15 Mbps Avg)
 NO ability to create custom profiles

– Profiles loaded in FPGA and can not be changed
IP SLA Video – ISR-G2
 DSP based video packet generation
– Able to support more simultaneous video streams (as compared to Cat3K)
– Requires PVDM3 DSP installed into device as additional hardware
 Several default profiles provided at various levels of quality

– Cisco CP-9900 Round Table Phone CIF
– Cisco Telepresence System
 Ability to create custom profiles directly on device (new profiles) by modifying

DSP parameters
IP SLA Video – Statistics

Type of operation: video
Latest operation start time: 10:04:26 PDT Thu Mar 22 2013
Packets: Packet count only
Sender Transmitted: 8081 known at end of
operation
Responder Received: 8081
IP SLA Video – Statistics
NTP sync state: SYNC
Inter Packet Delay Variation, RFC 5481 (IPDV): Required for valid
Number of SD IPDV Samples: 8072 OW Latency values
Source to Destination IPDV Min/Avg/Max: 0/1/8 milliseconds
Packet Loss Values:
Out Of Sequence: 4
IP SLA Video – Reaction
One way traffic only
 Connection Loss
 Jitter
– Inter Arrival Jitter from Source to Destination
– Jitter Average in the direction from Source to Destination
 Latency Average from Source to Destination
 Timeout
 Packet loss from Source to Destination
IP SLA Video – SNMP
 New OID for video
– rttMonEchoAdminVideoTrafficProfile
– rttMonEchoAdminDscp
– rttMonEchoAdminCallDuration
– rttMonEchoAdminReserveDsp (ISR-G2 only)
– rttMonEchoAdminEmulateSourceAddress (ISR-G2 only)
– rttMonEchoAdminEmulateSourcePort (ISR-G2 only)
– rttMonEchoAdminInputInterface (ISR-G2 only)
IP SLA Video – Additional information
 White paper
– Provides additional details on each platform and links to additional documents.
http://www.cisco.com/web/solutions/medianet/docs/IP_SLA_Video_Operation_Across_Platforms.pdf
IP SLA Video Q & A
Agenda
 Ethernet Probes
 Feature Matrix
IP SLA Ethernet Probes
• Delay – 1DM, DMM, DMMv1

Y.1731 probes • Frame Loss – LMM, SLM
• Ethernet Jitter
CFM 802.1ag • Ethernet Echo
probes • Ethernet monitor with Auto-discovery
* Diagram and Text from Wikipedia
Drivers for Ethernet OAM
 Operational Efficiency
–Reduce OPEX, avoid truck-rolls
–Downtime cost
 Management Complexity
–Large Span Networks
–Multiple constituent networks belong to disparate organizations/companies
 OAM benchmarks
–Set by TDM and existing WAN technologies
Ethernet OAM - Protocol Positioning
Connectivity
Access
Customer Aggregation
E-LMI Core Aggregation Customer
Fault Management
Y.1731 Performance
Business Management Business
MPLS
OAM
Ethernet
Ethernet
Ethernet MPLS/IP MPLS/IP
Residential MPLS/IP
Link OAM Residential
UNI NNI NNI NNI UNI
Connectivity Fault Management (CFM) IEEE 802.1ag defines protocols and practices for OAM
(Operations, Administration, and Maintenance) for paths through 802.1 bridges and local area networks
(LANs)
ITU-T recommendation for user-plane OAM functionality in Ethernet networks
OAM Key Concepts
MEP MEP
Metro Carrier Network
CE
PE
PE
CE
CE
UNI
Provider Domain UNI
Customer Domain
 Maintenance Domains: Management space for managing and administering a network. It is owned
and operated by a single entity and defined by the set of ports internal to it and at its boundary.
 Maintenance Endpoints (MEPs): Points at the edge of the domain, which define the boundary for
the domain. Typically associated with an interface. Think of MEPs as IP addresses or mac
addresses in a 802.1ag network.
Use Cases
Ethernet L2 VPN
Ethernet Connectivity – Service provider uses Y.1731 based probes

Ethernet Service Provider
IP-based probe L2 VPN

Y.1731-based probe
Customer
L3 CE
EVC NID /
Access /
Unmanaged Y.1731-based probe EVC Demarcation
L3 CE Device
Shadow
Router NID
Optional IP-based L2 VPN

probe
Customer
L3 CE
EVC = Ethernet Virtual Circuit
NID = Network Interface Device
= CFM Maintenance Association End Point (MEP)
Use case
L3 VPN with Ethernet Access (CE-PE)
IP-based probe
VRF
Internet
Y.1731 Probe
EVC
Aggregator L3 PE
Demarc Device IP / MPLS Core
Managed NID EVC
L3 CE
G.SHDSL Shadow
Router
DSLAM Y.1731 Probe
Managed Optional
L3 CE
IP Third Party Ethernet Service IP

Department Provider Department
Or Transport / Aggregation
EVC = Ethernet Virtual Circuit
Department NID = Network Interface Device
= CFM Maintenance Association End Point (MEP)
Use case
Mobile Backhaul
Distribution Router
Y.1731 Probe
SAE
4G
Demarc EVC Demarc
GW
RNC 3G
Demarc
eNodeB (4G) Cell Site EVC BSC
NodeB (3G) Router 2G
BTS (2G)
Y.1731 Probe
Distribution Router
Mobile Wireline Provider / Mobile Backhaul Mobile

Operator Operator Operator
Cell Site(s) MTSO
eNode B = Enhanced Node B MTSO = Mobile Telephone Switching Office EVC = Ethernet Virtual Circuit
SAE GW = System Arch Evolution GW BTS = Base Transceiver Station NID = Network Interface Device
RNC = Radio Network Controller BSC = Base Station Controller = CFM Maintenance Association End Point (MEP)
Y.1731 Ethernet Performance Management
Cisco IP SLAs Ethernet Synthetic
Ethernet Delay Measurement Ethernet Loss Measurement
Loss Measurement
ETH-DM ETH-LM
ETH-SLM
IP and MPLS Y.173
One-Way Two-Way Single-Ended Dual-Ended Single-Ended ETH-
ETH-DM ETH-DM ETH-LM ETH-LM SLM
Scope
• One-Way delay • Two-Way delay • Unidirectional frame • Unidirectional frame • Unidirectional frame loss
measurements measurements loss measurements loss measurements measurements
• Also One-Way delay • Applicable to P2P • Applicable to P2P • Applicable to P2P and MP
Specifics when synchronized services only services only services
• 1DM PDU • DMM / DMR PDUs • LMM / LMR PDUs • CM PDUs

• Synthetic traffic with two • Synthetic traffic with • On-demand operation • Proactive operation • SLM / SLR PDUs
(2) timestamps two (2) mandatory and • Based on actual • Based on actual • Based on statistical sampling
• Need for Time-of-Day two (2) optional Service Frame Loss Service Frame Loss • Exchange of synthetic frame
synchronization timestamps • Exchange of service • Exchange of service counters
frame counters frame counters
ITU-T Y.1731 – Cisco support
Cisco IP
Cisco IP SLAs
SLAs Ethernet Synthetic
Ethernet Delay Measurement Ethernet Loss Measurement
Loss Measurement
ETH-DM ETH-LM
ETH-SLM
IPand
IP andMPLS
MPLS Y.173Y.173
One-Way Two-Way Single-Ended Dual-Ended Single-Ended ETH-
ETH-DM ETH-DM ETH-LM ETH-LM SLM
No implementation
plans
Single-ended ETH-LM IP SLA probe:
IP SLA probe: IP SLA probe: IP SLA probe:
and Single-ended ethernet y1731
ethernet y1731 ethernet y1731 ethernet y1731 ETH-SLM used with
loss LMM loss SLM
delay 1DM delay DMM probe scheduler (IP
SLA achieve proactive
behavior
CFM-based Alternatives ( non- ITU-T Y.1731)
Cisco IP SLAs
Standard CFM PDUs Vendor-specific CFM PDUs
Scope IP and MPLS Y.173

• Two-Way delay measurements • Two-Way delay measurements
• One-Way delay when synchronized
• Unidirectional frame loss measurements
Specifics (applicable to P2P and MP services)
• LBM / LBR PDU • Proprietary CFM PDUs

• Interoperable with non-Cisco CFM-capable devices (NO need • Requires Cisco Responder
for Cisco Responder) • Frame loss based on statistical sampling
• RTT measurement includes remote end-point processing (no
timestamps added by Responder)
Support
IP SLA probe: ethernet echo IP SLA probe: ethernet jitter
Cisco IP SLA –Y.1731/CFM highlights
 Cisco IP SLAs Embedded Policy Management
– Scheduling Automation / Policy Alerts / Data Collection
 In-band Performance Management Tool for Ethernet
– Delay, Delay Variation and Packet Loss measurement
– Based on standard ITU-T Y.1731 or follows CFM principles.
 Automatic Discovery of Probe Endpoints for CFM
– Using entries on CFM CCM database
Y.1731 Ethernet Operation
 Configure a Y.1731operation using a specific maintenance endpoint ID
ip sla operation-number
ethernet y1731 delay {1DM | DMM | DMMv1} domain domain-name {{vlan vlan-id| evc evc-id} {mpid mp-id |
mac-address mac-address} cos cos-value source {mpid mp-id | mac-address mac-address}
or
ethernet y1731 loss {LMM | SLM} domain domain-name {{vlan vlan-id| evc evc-id} {mpid mp-id |
mac-address mac-address} cos cos-value source {mpid mp-id | mac-address mac-address}
Manual CFM Ethernet Operation
 Manually configure an Ethernet operation using a specific maintenance
endpoint ID
ip sla operation-number
ethernet echo mpid mp-id domain domain-name vlan vlan-id | evc evc-id
Specify the maintenance point

Or ID for manual operation
ethernet jitter mpid mp-id domain domain-name vlan vlan-id | evc evc-id[interval interframe-
interval] [num-frames frames-number]
Auto Endpoint Discovery Feature
 Provides the ability to automatically discover all maintenance endpoints in a
given maintenance domain and EVC or VLAN
 Similar to IP SLA Auto Discovery for L3 probes
 Configured via ip sla ethernet-monitor command
ip sla ethernet-monitor operation-number
type echo domain domain-name {vlan vlan-id | evc evc-id} [exclude mpids mp-
ids]
Echo and Jitter Operation
Types Supported
or
type jitter domain domain-name {vlan vlan-id | evc evc-id}

[exclude-mpids mp-ids] [interval interframe-interval]
[num-frames frames-number]
Reaction Configuration
 Ethernet Monitor
ip sla ethernet-monitor reaction-configuration operation-
number react monitored-element [action-type {none |trapOnly}] [threshold-
type {average [number-of-measurements] | consecutive [occurrences]
| immediate |never | xofy [x-value y-value]}] [threshold-value upper-
threshold lower-threshold]
 Manual Operation
ip sla reaction-configuration operation-number react monitored-
element [action-type option] [threshold-type {average [number-of-measurements]
| consecutive [occurrences] |immediate | never | xofy [x-value y-value]}]
[threshold-value upper-threshold lower-threshold]
Reaction Element Types Supported
Jitter Delay Loss
• Average • Round trip time • D to S loss ratio

• Average D to S • Max of D to S • S to D loss ratio
• Average S to D • Max of S to D • Unavailability D to S
• Max negative D to S • Unavailability S to D
• Max negative S to D
• Max positive D to S
• Max positive S to D
D = Destination
S = Source
Ethernet Probes Walkthrough
VLAN ID: 101

Domain: PROVIDER_DOMAIN
Intf: Eth1/3
Intf: Eth1/3 Mpid: 6401
Intf: Eth2/1 Intf: Eth2/1

Mpid: 5101 Mpid: 6101
Intf: Eth2/2 Intf: Eth2/2

Mpid: 5201 Mpid: 6201
Intf: Eth2/3
Intf: Eth2/3 Mpid: 6301
Router 1(Initiator) Router 2 (Responder)
Ethernet Probe Walkthrough
Router1#show ethernet cfm maintenance-points remote
--------------------------------------------------------------------------------
MPID Domain Name MacAddress IfSt PtSt
Lvl Domain ID Ingress
RDI MA Name Type Id SrvcInst
EVC Name Age
Local MEP Info
--------------------------------------------------------------------------------
6201 PROVIDER_DOMAIN aabb.cc00.ca99 AdmDn Up
4 PROVIDER_DOMAIN Et2/0.1
RDI customer_101_provider BD-V 101 N/A Use this command to
customer_101_provider@101 8s
MPID: 5201 Domain: PROVIDER_DOMAIN MA: customer_101_provider
display all remote
6301 PROVIDER_DOMAIN aabb.cc00.ca99 AdmDn Up maintenance points in
4 PROVIDER_DOMAIN Et2/0.1 the ethernet network
RDI customer_101_provider BD-V 101 N/A
6101 PROVIDER_DOMAIN aabb.cc00.ca99 Up Up
6401 PROVIDER_DOMAIN aabb.cc00.ca99 AdmDn Up
Y.1731 Probe Walkthrough
 Create an IP SLA probe to get one-way and two-way delay using the
Y.1731 delay DMM based probe.
ip sla 4
ethernet y1731 delay DMM domain PROVIDER_DOMAIN vlan 101 mpid 6401 cos 2 source mpid 5401
ip sla schedule 4 schedule-period 60 start-time now
ip sla reaction-configuration 4 react jitterAvg threshold-type consecutive 3
Enable reaction for the

probe
Router1#show ip sla configuration 4
Entry Number : 4
Operation timeout (milliseconds): 5000 Use this command display
Ethernet Y1731 Delay Operation the probe configuration
Frame Type: DMM
Domain: PROVIDER_DOMAIN
Vlan: 101
Target Mpid: 6401
Source Mpid: 5401
CoS: 2
Request size (Padding portion): 64
Frame Interval: 1000
Threshold (milliseconds): 5000
… .. ..
Router1#show ip sla reaction-configuration 4

Entry Number : 4
Index: 1
Reaction: jitterAvg
Threshold Type: Consecutive
Rising (milliseconds): 100
Falling (milliseconds): 100
Action Type: None
 Use show ip sla statistics as usual to display the statistics for the
operation
Router1#show ip sla statistics 4 details
…
Delay:
Number of forward observations: 211
Min/Avg/Max forward: 1/2/10
Time of occurrence forward:
Min - 17:12:22.472 PST Mon Jan 16 2013
Max - 17:12:37.473 PST Mon Jan 16 2013
.. .. … …
Delay Variance:
Number of forward positive observations: 100
Min/Avg/Max forward positive: 0/1/2
Auto-discovery Walkthrough
 Create an ethernet monitor to automatically find all mpids in domain
PROVIDER_DOMAIN and vlan 101 and execute the echo operation
ip sla ethernet-monitor 1
type echo domain PROVIDER_DOMAIN vlan 101
ip sla ethernet-monitor schedule 1 schedule-period 60 start-time now
ip sla ethernet-monitor reaction-configuration 1 react connectionLoss

threshold-type consecutive 3 action-type trapOnly
Enable reaction
monitoring for all
discovered mpids
Router1#show ip sla ethernet-monitor configuration 1
Entry Number : 1 Use this command
Modification time : *21:06:55.573 PST Fri Mar 30 2013 display the ethernet-
Operation Type : echo monitor configuration
Domain Name : PROVIDER_DOMAIN
VLAN ID : 101
Excluded MPIDs :
Owner :
Tag : Operations
Timeout(ms) : 5000 automatically created
Threshold(ms) : 5000 based on the number
Frequency(sec) : 60 of mpids discovered
Operations List : 100001,100004,100005,100006
Schedule Period(sec): 60
Request size : 66
CoS : 0
Start Time : Start Time already passed
SNMP RowStatus : Active
… .. ..
Reaction Configs :
Reaction Index : 1
Reaction : connectionLoss
Threshold Type : Consecutive
Threshold CountX : 3
Threshold CountY : 5
Action Type : None
 Use show ip sla configuration to identify the mpid associated with the
operation id
Router1#show ip sla configuration 100001
Entry number: 100001
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: 802.1ag Echo
Target domain: PROVIDER_DOMAIN
Target MPID: 6401
Target VLAN ID: 101
Request size (Padding portion): 66
Class Of Service parameters: 0
Threshold (milliseconds): 5000
 Use show ip sla statistics as usual to display the statistics for the
ethernet echo operation
Router1#show ip sla statistics 100001

Type of operation: ethernet-echo
Latest RTT: 1 milliseconds
Latest operation start time: 23:07:08 PST Mon Apr 2 2013
RTT Values:
Operation time to live: Forever
 Use show ip sla reaction-configuration to display the reaction
configurations for the created ethernet operations
Router1#show ip sla reaction-configuration 100007
Entry number: 100007
Index: 1
Reaction: connectionLoss
Threshold Type: Consecutive
Action Type: None
Ethernet Probes Q & A
Agenda
 Ethernet Probes
 On-demand UDP probes
 Feature Matrix
Percentile Support – Use Case Examples
What is the 90th percentile

for Round Trip Time(RTT)? Round Trip Time (RTT)
40
35
30
?
25
What is the average
90th percentile
RTT excluding top 20
10% samples?
15
10
5
What is the 95th
percentile for 0
average Jitter? 1 3 5 ..
49
.. 23 25 .. .. 47
Percentile support – Introduction
Samples ignored for
 Include samples for calculations percentile calculations
only below user configured percentile
40
Round Trip Time (RTT)
RTT Values:
Number Of RTT: 50 35
RTT Min/Avg/Max: 1/5/34 milliseconds 30
Percentile RTT Values (90%): 25
Number Of Percentile RTT: 45
RTT Min/Avg/Max: 1/3/12 milliseconds 20
15
RTT Avg with all 50
samples = 5 10
5
90% Percentile RTT Avg
with 45 samples = 5 0
1 3 5 .. 23 25 .. .. 47
49
Percentile support – probes and parameters
 Percentile support is available for

– UDP Jitter, ICMP Jitter and Ethernet Jitter
 Percentile based filtering applies for following parameters

– Round Trip Time (RTT)
– Jitter
– Source to destination jitter
– Destination to source jitter
– Source to destination one way delay
– Destination to source one way delay
Percentile support – Configuration example
 Percentile configuration example:
ip sla 444
udp-jitter 10.10.13.1 45666 num-packets 50
percentile rtt 90
percentile owsd 90
percentile owds 90
percentile jittersd 95
percentile jitterds 95
percentile jitteravg 90
Percentile support – Configuration
ipsladev3945-2(config-ip-sla)#udp-jitter 10.10.13.1 45666

ipsladev3945-2(config-ip-sla-jitter)#?
IP SLAs Udp Jitter Configuration Commands:
clock-tolerance Set acceptable clock synchronization error
.. … … … New percentile
operation-packet-priority Set operation packet properties option.
optimize Optimize timestamp of measurement
owner Owner of Entry
percentile Set percentile statistics levels
precision Set precision of measurement
.. .. .. … ..
vrf Configure IP SLAs for a VPN Routing/Forwarding
instance
Percentile support - Options
ipsladev3945-2(config-ip-sla-jitter)#percentile ?
jitteravg % of Average Jitter values to use (default 100%)
jitterds % of JitterDS values to use (default 100%)
jittersd % of JitterSD values to use (default 100%)
owds % of OWDS values to use (default 100%)
owsd % of OWSD values to use (default 100%)
rtt % of RTT values to use (default 100%)
ipsladev3945-2(config-ip-sla-jitter)#percentile jittersd ?
<90-100> value in %
Parameters can be
set to different
percentile values.
Percentile support – Show Configuration
show ip sla config 444
Entry number: 444
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: udp-jitter
… …. …. …. …. …. Percentile values for
Enhanced History: various parameters
Percentile:
RTT: 90% OWSD: 90% OWDS: 90%
JitterSD: 95% JitterDS: 95% JitterAvg: 90%
Percentile support – Show Statistics
show ip sla statistics 444
IPSLAs Latest Operation Statistics New percentile
IPSLA operation id: 444 calculations
………
RTT Values:
Percentile RTT Values (90%):
Number Of Percentile RTT: 45 RTT Min/Avg/Max: 1/3/12 milliseconds
………
Percentile Jitter Time:
Number of Percentile SD Jitter Samples (90%): 45
Number of Percentile DS Jitter Samples (90%): 45
Percentile Source to Destination Jitter Min/Avg/Max: 0/1/5 milliseconds
Percentile Destination to Source Jitter Min/Avg/Max: 0/2/4 milliseconds
Percentile support – Reactions
 Jitter Percentile
– Average
– Average from Destination to Source
– Average from Source to Destination
 Latency Percentile Jitter Percentile

– Round Trip Time
– Average Source to Destination
– Average Destination to Source
– Max of Source to Destination
– Max of Destination to Source
Percentile support Q & A
Agenda
 Ethernet Probes
 Feature Matrix
Use Case - On-demand UDP probes
Sender
Responder
168.16.1.2
171.2.25.1
X
Bob wants to quickly check the connectivity but does not have access to config
mode on the sender. He also wants more information than just a ping command.
On-demand UDP probes – Use Case contd.
Sender
Responder
168.16.1.2
171.2.25.1
Bob executes on-demand UDP probe
X
from the exec mode.
ipsladev3945-2#ip sla udp-jitter 171.2.25.1 34899 source-ip 168.16.1.2 source-port 35899
On-demand UDP probes - output
ipsladev3945-2#ip sla udp-jitter 171.2.25.1 34899 source-ip 168.16.1.2
Sender
Responder
168.16.1.2
171.2.25.1
Type of operation: udp-jitter
X
Latest operation start time: 18:06:19 PST Sun Apr 7 2013
RTT Values:
…. …. …
On-demand UDP probes - parameters
 Following parameters are available
– Destination address, destination port
– Source address, source port
– Inter packet interval
– Number of packets to be transmitted
– Optimize timestamp of measurement
– Precision of measurement
– Type of service
– vrf
On-demand UDP probes – UDP echo
ipsladev3945-2#ip sla udp-echo 171.2.25.1 34799

UDP echo probe
result
Latest operation start time: 10:54:52 PST Mon Apr 8 2013
On-demand UDP probes – UDP jitter
ipsladev3945-2#ip sla udp-jitter 171.2.25.1 34899 source-ip 168.16.1.2 source-port 35899 interval 30 num-packets 100
Type of operation: udp-jitter
Latest operation start time: 18:06:19 PST Sun Apr 7 2013 UDP jitter probe
Latest operation return code: OK result
RTT Values:
…. …. …
Jitter Time:
Number of SD Jitter Samples: 99
Number of DS Jitter Samples: 99
Source to Destination Jitter Min/Avg/Max: 0/1/8 milliseconds
Destination to Source Jitter Min/Avg/Max: 1/1/3 milliseconds
On-Demand UDP probes
Requirements & Restrictions
 UDP-jitter and UDP-echo probes are supported for on demand operation.
 The on-demand probes are not available through MIB interface.

– Show commands cannot be used to look at the output.
 The on-demand probe will block the exec prompt while the probe completes or
times out.
On-demand UDP probes Q & A
Agenda
 Ethernet Probes
 Feature Matrix
Platform Feature Comparison
Feature Cisco ISR Cisco ISR-G2 Cisco 72/73xx ASR1000
ICMP Echo 12.0(3)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA

ICMP Echo Path 12.0(3)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
ICMP Path Jitter 12.2(2)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
Responder (For UDP only) 12.0(3)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
UDP Echo 12.0(3)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
UDP Jitter 12.0(5)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
UDP Jitter one way measurement 12.1(1)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
TCP Connect 12.0(3)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
HTTP 12.0(5)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
FTP 12.1(1)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
DHCP 12.0(5)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
UDP jitter for VoIP (G711/G729) 12.1(1)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
VoIP RTP (DSP w Codec) 12.4(6) T 15.0(1)M N/A N/A
Available Now Not Available Roadmap

VoIP H323/SIP Post Dial Delay 12.3(14)T 15.0(1)M
VoIP H323 GK Delay 12.3(14)T 15.0(1)M
Voice with MOS/ICPIF Score 12.3(14)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
LSP Health Monitor 12.4(4)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
LSP Auto Discovery & Scheduling 12.4(6)M 15.0(1)M 12.2(33)SRB 12.2(33)XNA
Auto SLA for PWE3 via VCCV 15.1(3)T 15.1(3)T 12.2(33)SRB
Ethernet Echo (802.1ag) 12.2(33)SRB
Ethernet Jitter 12.2(33)SRB
Ethernet auto discovery/schedule 12.2(33)SRB
Engine III Features 15.1(3)T 15.1(3)T Radar
TWAMP Responder 15.2(3)T 15.2(2)S
Video Operation 15.2(2)T Radar
Percentile Support 15.3(2)T 15.3(3)S
OnDemand UDP probes 15.3(1)T 15.3(3)S
Y1731 PM Radar
MPLS/VRF Awareness I 12.2(2)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
MPLS/VRF Awareness II 12.4(2)T 15.0(1)M 12.2(33)XNA
DLSw+ 12.0(5)M 15.0(1)M 12.2(33)SRB 12.2(33)XNA
Engine III Features 15.1(1)T 15.0(1)M Radar
IPv6 Phase I 12.4(24)T 15.0(1)M 12.2(33)SRB 15.3(1)S
UDP Jitter Multicast Phase I 15.2(4)M 15.3(2)S
Micro Sec Accuracy Precision 12.4(22)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
SNMP Support 12.0(5)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
IPv6 Phase 2 15.2(3)T 15.3(1)S
Aggregated Statistics 12.4(9)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
Group/Random Scheduler 12.4(2)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
Reaction Threshold 12.4(2)T 15.0(1)M 12.2(33)SRB 12.2(33)XNA
Feature Cat6500 Cat4500 Cat3750 NGWC
ICMP Echo 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
ICMP Echo Path 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
ICMP Path Jitter 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
Responder (For UDP only) 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
UDP Echo 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
UDP Jitter 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
UDP Jitter one way measurement 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
TCP Connect 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
HTTP 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
FTP 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
DHCP 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
UDP jitter for VoIP (G711/G729) 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
VoIP RTP (DSP)
Feature Cat6500 Cat4500 Cat3K NGWC
VoIP H323/SIP Post Dial Delay
VoIP H323 GK Delay
Voice with MOS/ICPIF Score 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
LSP Ping 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
LSP Trace 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
LSP Auto Discovery & Scheduling 12.2(44)SG 12.2(40)SE 15.0(1)EX
VCCV PWE3 Echo
Ethernet Echo (802.1ag) 12.2(1st)SXI 12.2(40)SE Radar
Ethernet Jitter 12.2(1st)SXI 12.2(40)SE Radar
Ethernet auto discovery/schedule 12.2(1st)SXI 12.2(40)SE Radar
Engine III Features Radar Radar Radar Radar

TWAMP Responder Radar Radar Radar Radar
Video Operation Radar 15.1(1)SG 12.2(58)SE Radar
Feature Cat6500 Cat4500 Cat3K NGWC
Y1731 PM
MPLS/VRF Awareness 1 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
MPLS/VRF Awareness 2 Radar Radar Radar Radar
IPv6 Phase I 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
UDP Jitter Multicast Phase I Radar Radar Radar Radar
Micro Sec Accuracy Precision Radar Radar Radar Radar
SNMP Support 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
IPv6 Phase 2 Radar Radar Radar Radar
Aggregated Statistics 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
Group/Random Scheduler 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX
Reaction Threshold 12.2(1st)SXI 12.2(44)SG 12.2(40)SE 15.0(1)EX

Feature Nexus 7K Nexus 5K Nexus 3K/2K Nexus 1K
ICMP Echo NX-OS 6.2 Radar Radar Radar
ICMP Echo Path NX-OS 6.2 Radar Radar Radar
ICMP Path Jitter NX-OS 6.2 Radar Radar Radar
Responder (For UDP only) NX-OS 6.1 Radar Radar Radar
UDP Echo NX-OS 6.1 Radar Radar Radar
UDP Jitter NX-OS 6.1 Radar Radar Radar
UDP Jitter one way measurement NX-OS 6.1 Radar Radar Radar
TCP Connect NX-OS 6.1 Radar Radar Radar
HTTP NX-OS 6.2 Radar Radar Radar
FTP NX-OS 6.2 Radar Radar Radar
DHCP NX-OS 6.2 Radar Radar Radar
UDP jitter for VoIP (G711/G729) NX-OS 6.1 Radar Radar Radar
VoIP RTP (DSP)
TWAMP Responder Radar Radar Radar Radar
Video Operation Radar Radar Radar Radar
Y1731 PM
MPLS/VRF Awareness 1 NX-OS 6.1 Radar Radar Radar
MPLS/VRF Awareness 2 Radar Radar Radar Radar
IPv6 Phase I NX-OS 6.2 Radar Radar Radar
UDP Jitter Multicast Phase I Radar Radar Radar Radar
Micro Sec Accuracy Precision Radar Radar Radar Radar
SNMP Support NX-OS 6.1 Radar Radar Radar
IPv6 Phase 2 NX-OS 6.2 Radar Radar Radar
Aggregated Statistics NX-OS 6.1 Radar Radar Radar
Group/Random Scheduler NX-OS 6.1 Radar Radar Radar
Reaction Threshold NX-OS 6.1 Radar Radar Radar
References
 Cisco IOS IP SLA Web site on CCO:
– http://www.cisco.com/go/ipsla
– This page contains links to executive and technical
documents, documentation, and white papers
 Suggested reading:
– Cisco IOS IP Service Level Agreements User Guide
– Accurate Network Performance Monitoring using
Cisco IOS IP SLA
URLs and Email Aliases
 Cisco Beyond
• Embedded Event Manager (EEM) Scripting Community
• An open EEM script repository
• http://cisco.com/go/ciscobeyond
 Embedded Event Manager CCO Page
• http://www.cisco.com/go/eem
 askabouteem@external.cisco.com
External EEM alias
Documents
 Embedded Event Manager Overview
 http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_overvie
w.html
 Writing Embedded Event Manager Policies Using Tcl
 http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_policy_t
cl.html
 Writing Embedded Event Manager Policies Using CLI
 http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_policy_
cli.html
IP SLA Email Aliases
 Cisco IOS IP SLAs External Self-Help User Community:
– cisco-ios-ipsla-questions-approval@cisco.com
– cisco-ios-ipsla-questions@external.cisco.com
 Cisco IOS IP SLAs External Announcements:

– cisco-ios-ipsla-announce-approval@cisco.com
– cisco-ios-ipsla-announce@external.cisco.com
Final Thoughts
 Visit www.ciscoLive365.com after the event for updated PDFs, on-

demand session videos, networking, and more!
 Follow Cisco Live! using social media:
– Facebook: https://www.facebook.com/ciscoliveus
– Twitter: https://twitter.com/#!/CiscoLive
– LinkedIn Group: http://linkd.in/CiscoLI
Complete Your Online Session Evaluation
 Give us your feedback and
you could win fabulous prizes.
Winners announced daily.
 Receive 20 Cisco Daily Challenge
points for each session evaluation
you complete.
 Complete your session evaluation
online now through either the mobile
app or internet kiosk stations.
Maximize your Cisco Live experience with your
free Cisco Live 365 account. Download session
PDFs, view sessions on-demand and participate in
live activities throughout the year. Click the Enter
Cisco Live 365 button in your Cisco Live portal to
log in.

Tecnms 3043 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tecnms 3043 PDF

Uploaded by

Copyright:

Available Formats

Getting Network Visibility via Cisco IP SLA

Sumanth Kakaraparthi (Product Manager)

 In addition, we will talk about proactive threshold monitoring, EEM integration,

 Manageability and Compliance

 Support and Documentation

Active monitoring Passive monitoring

Mediatrace IPSLA TWAMP Unified Monitoring

Netflow • Basic network metrics

Media-monitoring • Voice & Video metrics

Performance • Application and TCP metrics

• Synthetic probe to calculate network and

IPSLA-VO • Synthetic probe for Video operations

Mediatrace • Path identification and fault locator

TWAMP • Standards based probe

 A SLA is a contract between a customer and a service provider to provide a

 In the networking world, an SLA contract typically means providing a

Answer: You measure it!

 Active Measurements vs. Passive Measurements

 Metrics: Throughput, availability, RTT, jitter, latency, packet loss, packet

 Original feature name called RTR (response time reporter)

 Feature name changed to SAA (service assurance agent) in 12.0(5)T

 Limited number of probes and functionality

 CLI name rtr

 Major code rewrite for improved memory and performance, unlimited

 IPv6 support (limited)

 Feature name changed to IP SLA

 CLI name ip sla monitor, ip sla

 Released in 15.1(1)T and later

 Modularization, cross OS rewrite

 Portability and feature consistency across platforms and trains

 New probes, template based configuration, QOS integration, auto discovery

 CLI name ip sla

Access Aggregation Edge Multiservice Core

Object Interface and

Per-direction (SD/DS) inter-packet delay (Jitter)

IP SLA Sender SLA Responder

 Executing another IP SLA operation

 Executing an Embedded Event Manager (EEM) script

 Multiple reaction elements can be monitored for a single probe

ip sla reaction-configuration 1 react rtt threshold-value 60 40 action-type trapOnly threshold-type

Threshold-value defines the upper and lower limit

Router(config)# ip sla logging traps Enable syslog

Router(config)# snmp-server enable traps ipsla

Configure snmp server host

Enable IP SLA SNMP traps

 EEM Server listens to various Event

 EEM policy is a pre-programmed script

 Script defines actions to be invoked based on an event occurrence

 Users can write two types of EEM policies:

 CLI based policies called applets

 TCL based policies

Send EEM Force

 IP SLA Event Detectors notifies EEM when an event of interest occurs

Enable reaction alerts

Router1(config)#event manager applet sla_failover

3. Define the event criteria for the applet

Router1(config-applet)#event ipsla operation-id 1 reaction-type timeout

Execute the policy sla_failover when an ip sla event with

Switch 2 Main Server

track 1 ip sla 1 reachability Track object for IP SLA reachability

Route-map for PBR:

 IP SLA Auto Discovery solves this by having the endpoints (responders)

Auto Group Name: my-group