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

Introduction to Network Performance Measurement withCisco IOS IP Service Level Agreements

Agenda• Introduction• What is Cisco IP SLAs?• Use Cases• Configuration• Accuracy• Performance and Scalability• Getting the Most out of IP SLAs• Management Tools• Summary and Conclusion

The Business ChallengesWhat Are You Doing About Them? Identify partial or Delay launch of new incomplete network trafficapplications due to network conditions performance concerns Your Lack of Network Slow to Launch New Visibility Services Business Increased TCO Networks Reduced Network Performance Ensure application Experience application efficiency by adding downtime and degradation bandwidth (perhaps unnecessarily) Cisco IP SLAs can help

Cisco IP SLAs – Service Level Agreements Enterprise and Small Medium Business Service Providers Understand Network Verify Service Levels Measure and provide Performance & Verify Outsourced SLAs SLAs Ease Deployment Access Enterprise Backbone Enterprise Service Provider Service Provider Core Premise Edge Aggregation Edge

IP SLAs in a Nutshell• Simple and easy to deploy • Scalability and Performance • Embedded in Cisco IOS • Platform proliferation • Millisecond precision • CLI and SNMP access • Microsecond granularity• Wide Range of Coverage • Built-in Intelligence & Flexibility • Multiple protocols • Scheduling and reporting • Multiple applications • Auto discovery • Multiple operations • QoS Integration • Threshold Notifications Customer-proven Success #CiscoPlusCA

Active | PassiveActive Monitoring (Cisco IP SLAs) Passive Monitoring (NetFlow)Sends synthetic packet for network measurement. Watch for real trafficEnd-to-end Performance Metrics At one pointProactive troubleshooting No traffic == no conclusion

So how does it work? Management Application Destination Configure Collect SNMPConfigure Trap Operation 1 Operation 2 Source Responder Destination

IP SLAs History• Was called RTR - renamed SAA in 12.0(5)T; we call it ―IP SLAs Engine 1‖.• ―IP SLAs Engine 2‖ - major code rewrite to improve speed and memory usage – Introduced in 12.2(15)T2, 12.3(3) and 12.2(25)S, and is therefore present in all later trains – Also planned for 12.0(32)SY and 12.2(18)SXG.• First phase of new CLI appears originally in 12.3(14)T, next phase in 12.4(6)T – MIBs are unchanged.• The latest ‗Engine 3‘ started with 15.1(1)T, currently in T-train only time Engine: Engine 1 Engine 2 Engine 3 Feature Name: RTR SAA IP SLAs CLI: rtr… ip sla mon… ip sla …

Supported Cisco IOS® VersionFeature/Release 11.2 12.0(3)T 12.0(5)T 12.1(1)T 12.2(2)T 12.2(11)T 12.3(4)T 12.3(12)T 12.0(8)S 12.2 (Eng2)ICMP Echo X X X X X X X XICMP Echo Path X X X X X X X XUDP Echo X X X X X X XTCP Connect X X X X X X XUDP Jitter X X X X X XHTTP X X X X X XDNS X X X X X XDHCP X X X X X XDLSw+ X X X X X XSNMP Support X X X X X XUDP Jitter with One Way Latency X X X X XFTP Get X X X X XMPLS/VPN Aware X X X XFrame-Relay (CLI) X X X XICMP Path Jitter X X X XAPM X X X XVoice with MOS/ICPIF Score X XPost Dial Delay H323/SIP X

Supported Cisco IOS® Version (cont)Feature/Release 12.2(2)T 12.2(11)T 12.3(4)T 12.3(12)T 12.4(1) 12.4(6)T 12.4(24)T 15.0(1)M (Eng2)MPLS/VPN Aware X X X X X X X XFrame-Relay (CLI) X X X XICMP Path Jitter X X X X X X X XAPM X X X XVoice with MOS/ICPIF Score X X X X X XPost Dial Delay H323/SIP X X X X XRTP VoIP (W/Codec) X X XIPv6 Support X XAuto Registration client (Responder X Xonly)• Ethernet OAM (CFM) introduced 12.2(33)SRB• MPLS OAM (Health Monitor) introduced 12.2(27)SBC and 12.2(33)SRA• Frame relay and APM removed in 12.4 and 12.4T• ―Auto IP SLAs‖ has been FCS 15.1(1)T.• IPv6 support in 15.0(1)M, 12.4(24)T and others.• Check http://www.cisco.com/go/fn for a full list.

Scenario 1SLA 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 2Network 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 3IP 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 4Availability 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 5Troubleshooting• Proactive notification of problems and issues based on threshold alerts• Testing edge to edge consistently and reliably will save time in finding and pin-pointing network performance problem areas• Supports activation of a second more granular test upon initial detection of a problem by primary test – Can test at a higher frequency or with different parameters to isolate the problem

Configuration• What – Operation / protocol / parameters• Where – Destination IP address• When – Scheduling – Distributed start-time

What?Which Operation? • ICMP based operations: • Other operations: – ICMP Echo – TCP operation – ICMP Path Echo – HTTP operation – ICMP Path Jitter – DNS operation • Responder-based – DLSW+ operation operations: – DHCP operation – UDP Echo – FTP get operation – UDP Jitter – ATM operation – FR operation – VoIP Proactive monitoring – Video Operation

ICMP Echo Operation (aka: ―ping‖)• One packet sent, reports success and round trip time delay ICMP Echo Probe Source Destination What? Where? When? ip sla 6 icmp-echo 172.29.139.134 frequency 300 ip sla schedule 6 life forever start-time now

ICMP Echo Limitations• One packet only -> no loss statistics• ICMP is low priority ―by design‖ -> not representative• Reports round trip time including processing time on the responding side -> biased results.

UDP Jitter Operation• Measures the delay, delay variation (jitter), corruption, misordering and packet loss by generating periodic UDP traffic• One-way results for jitter and packet-loss – If clocks are synchronized and IOS is at least 12.2(T), one-way delay is also measured.• Detect and report out-of-sequence and corrupted packets• Since 12.3(4)T -- also with MOS and ICPIF score for voice clarity estimation.• Requires IP SLA Responder to be configured on the target – More on IP SLA Responder later …

UDP Jitter - Measurement Example Send Packets STx = sent tstamp Receive packets for packet x. i2 P2 i1 P1 P2 P1 ST2 ST1 RT2 RT1 Source IP Core Destination (Responder) RTx = receive tstamp for packet x. Reflected packets Reply to packets dx = processing time spent between P1 i4 P2 P1 i3 P2 packet arrival and treatment. AT1 AT2 RT1+d1 RT2+d2ATx = receivetstamp for packet x. Each packet contains STx, RTx, ATx, dx and the source can now calculate: JitterSD = (RT2-RT1)-(ST2-ST1) = i2-i1 JitterDS = (AT2-AT1)-((RT2+d2)-(RT1+d1)) = i4-i3

UDP Jitter Operation (Example)• Simulating G.711 VoIP call• Use RTP/UDP ports 16384 and above – packet size is 172 bytes (160 bytes of payload + 12 bytes for RTP)• Packets are sent every 20 milliseconds• Marked with DSCP value of 8 (TOS equivalent 0x20) ip sla 1 udp-jitter 10.52.130.68 16384 num-packets 1000 interval 20 tos 0x20 frequency 60 request-data-size 172 ip sla schedule 1 life forever start-time now B C A A = 20 ms B = 20 s (1000 x 20 ms) C = 40 s (60 s – 20 s)

etychon-1#sh ip sla statistics 1Round trip time (RTT) Index 1 Latest RTT: 1 msLatest operation start time: *10:33:11.335 PST Fri Oct 7 2005Latest operation return code: OKRTT Values Number Of RTT: 20 RTT Min/Avg/Max: 1/1/4 msLatency 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 msJitter 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 msPacket Loss Values Loss Source to Destination: 0 Loss Destination to Source: 0 Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0Voice Score Values Calculated Planning Impairment Factor (ICPIF): 0 Mean Opinion Score (MOS): 0Number of successes: 5Number of failures: 3Operation time to live: 3166 sec

UDP Jitter for VoIPMOS• 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 VoIPSample 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 OperationThe Context• How to evaluate the clarity of a voice call?• Existing operations measures at the IP level, but have no idea on how call clarity is impacted.• How to map jitter/delay/loss with an application experience like VoIP?• We move toward service-oriented SLAs, and therefore looking at the application impact rather than at the pure IP metrics.

The RTP Operation• Sends a real RTP stream, generated in software.• Received and Decoded by a real Digital Signal Processor (DSP).• The jitter and drop metrics will be measured directly in the DSP, in hardware.• We support two DSPs, on a variety of platforms. IOS RTP RTP RTP RTP RTP IOS DSP RTP RTP RTP RTP RTP

Collected Set of Statistics• As of today, the IP SLAs RTP VoIP Operation can measure and report the following metrics: – RFC1889 (RTP) inter-arrival Jitter at source and destination – R-factor at source and destination – MOS-CQ (Mean Opinion Score -- Conversation Quality) estimated value using R factor and G.107 R-factor to MOS conversion table. – Packet Loss at source and destination – Network round trip time – Early packets – Packets Out of Sequence – Late Packets

Cisco IOS Version Support• Platforms supported: 175x, 2600, 2800, 3600, 3800, 7200 running 12.4(4)T ―IP Voice‖ or higher.• In the original release, one does only measure in one direction: responder to sender.• The bi-directional operation was introduced in 12.4(6)T.

IP SLAs RTP VoIPConfig Example controller E1 0/0 ds0-group 15 timeslots 3 type e&m-wink-start ip sla 3 voip rtp 10.48.164.20 source-voice-port 0/0:15 codec g711ulaw ip sla schedule 3 start-time now

IP SLAs RTP VoIPOutput Example etychon-s#sh ip sla sta 3 details Round Trip Time (RTT) for Index 3 Type of operation: rtp Latest operation start time: 07:24:11.941 UTC Mon Feb 27 2006 Latest operation return code: OK Latest RTT (milliseconds): 0 Source Measurements: Interarrival Jitter: 0 Packets Lost: 0 Packets OutOfSequence: 0 Packets Late: 0 Packets Early: 0 R-factor: 92 MOS-CQ: 4.34 Over thresholds occurred: FALSE Operation time to live: Forever Operational state of entry: Active Last time this entry was reset: Never

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

Nodes OperationsWhere? 2 1Full Mesh 3 3 4 6 5 10 6 15 7 21 8 28 n2 … 100 … 4950 • Good coverage, but… • Number of operations is proportional to the square of the number of nodes • Does not scale

Where? • Determine a coverage objective, ie: 30%.Partial Mesh • Build a traffic matrix to identify the “hottest” points (hint: use NetFlow). • Take the top 30% and evenly distribute operations A B C D E F B 5 6 7 5 C 1 7 12 12 D 7 5 5 11 E 4 4 12 2 F 3 8 4 18

Where?Hub and Spoke  Some topologies are naturally ―hub and spoke‖  Branch offices  Service Providers with lots of CPEs  etc …

When?When to run a test?• Scheduling• Multi-operation scheduling (groups)• Randomized start-time

When?Scheduling an operation to run• Schedule operation 1 to start now: ip sla schedule 1 start-time now• Or at a specified time (8PM): ip sla schedule 1 start-time 20:00:00• Or in a recurrent way (every day at 8PM): ip sla schedule 1 start-time 20:00:00 life 5 recurring

When?Multi-Operation Scheduler• Avoid overloading the router at boot with all operations starting at once. – We introduce the notion of group.• Starts many operations at once, with automatic smooth ―start-time‖. – Introduced in 12.3(8)T• Example: Start operations 1 to 10 within the next 10 seconds: r1(config)#ip sla group schedule 1 1-10 schedule-period 10 start-time now r1#sh ip sla op | i start Latest operation start time: *12:50:51.599 PST Mon Apr 18 2005 Latest operation start time: *12:50:52.599 PST Mon Apr 18 2005 Latest operation start time: *12:50:53.599 PST Mon Apr 18 2005 Latest operation start time: *12:50:34.579 PST Mon Apr 18 2005 Latest operation start time: *12:50:35.579 PST Mon Apr 18 2005 Latest operation start time: *12:50:36.579 PST Mon Apr 18 2005 Latest operation start time: *12:50:37.579 PST Mon Apr 18 2005 Latest operation start time: *12:50:38.579 PST Mon Apr 18 2005 Latest operation start time: *12:50:39.579 PST Mon Apr 18 2005 Latest operation start time: *12:50:40.591 PST Mon Apr 18 2005

When?Randomized start-time• Group start time can be randomized – avoids ―synchronization effect‖ – ie: test happens always at the same time something else happens, like a route update• Example: Start operation 1 to 5 within the next 44 seconds, and each operation will have a random frequency varying between 10 and 15 seconds ip sla group schedule 1 1-5 schedule-period 44 frequency range 10-15 start-time now life forever etychon-1#sh ip sla op | i start Latest operation start time: *12:56:12.243 PST Thu Oct 13 2005 Latest operation start time: *12:56:06.323 PST Thu Oct 13 2005 Latest operation start time: *12:56:07.743 PST Thu Oct 13 2005 Latest operation start time: *12:56:13.323 PST Thu Oct 13 2005 Latest operation start time: *12:56:08.643 PST Thu Oct 13 2005 etychon-1#sh ip sla op | i start Latest operation start time: *13:00:19.423 PST Thu Oct 13 2005 Latest operation start time: *13:00:15.895 PST Thu Oct 13 2005 Latest operation start time: *13:00:21.015 PST Thu Oct 13 2005 Latest operation start time: *13:00:25.303 PST Thu Oct 13 2005 Latest operation start time: *13:00:14.635 PST Thu Oct 13 2005 #CiscoPlusCA

IP SLA Accuracy...ICMP Echo Probe ICMP Echo Probe Sender Responder (90% Process Load) • With unloaded receiver, IPSLA measures 15.0 ms • With high CPU load on the receiver: 58.5 ms!! Any System Will Report Wrong Results when Excessive CPU Time Is Spent on the Receiver Between the ICMP Echo Request and Echo Reply Fortunately, We Have a Solution…

Processing Time Measurement• When running the responder, we have a clear advantage, because… – provides a mechanism to measure the processing time spent on the receiving router – inserts a timestamp when responder receives and sends the packet – Receive timestamp done at interrupt level • as soon as the packet is dequeued from the interface driver with absolute priority over everything else• Implemented for both UDP Echo and UDP Jitter operations• Absolute tested accuracy is 1 ms. – In other words, when it says 35 ms, it could be somewhere between 34 ms and 36 ms.

UDP Echo Operation (With IPSLA Responder) T1 T2 T3 Sender T5 Responder T4 Processing Delay on the Source: Tps = T5-T4 Processing Delay on the Destination: Tpd = T3-T2 Round Trip Time Delay: T = […] = T2 - T1 + T4 - T3• We have no control of queuing delay on the source and destination, but this is experienced by real traffic too, and must be accounted as such

IP SLA Accuracy: UDP Echo Probe UDP Echo Probe Sender Responder (90% Process Load) • With unloaded receiver: 15.0 ms • With 90% CPU receiver: 15.3 ms The IPSLA Responder Processing Delay Will Be Subtracted from the Final Results

Cisco IOS IP SLAs Performance: CPU Load by Platform(Jitter Probe Running Eng 2—2000 Active Jitter Oper—Cisco IOS 12.3(3)) Oper/ Oper/ 7200VXR 2600 2620XM 3640 3725 Second Minute NPE225 4 240 14 7 6 2 4 8 480 20 8 9 3 3 12 720 29 12 13 2 3 16 960 35 15 17 3 3 20 1200 41 19 22 2 3 24 1440 48 24 25 3 3 28 1680 56 27 28 3 3 32 1920 63 28 31 2 4 36 2160 67 31 35 2 3 40 2400 34 38 3 7 44 2640 38 43 4 8 48 2880 42 47 5 8 52 3120 46 49 5 10 56 3360 48 43 6 11 60 3600 52 58 6 11

Cisco IP SLA´s Performance: CPU(Jitter Probe Running Eng 2+—2000 Active Jitter Oper—Cisco IOS12.4(PI3)T) Oper/ Pkts/ Oper/ 2800 2811 2851 2691 3745 3845 3825 1841 Second second Minute 4 200 240 3 3 1 2 1 0 2 3 8 400 480 6 5 2 3 1 1 3 4 12 600 720 8 7 3 4 2 2 5 6 16 800 960 10 9 4 5 2 2 7 8 20 1000 1200 13 11 4 6 3 3 8 10 24 1200 1440 15 13 5 8 4 4 10 11 28 1400 1680 18 14 6 9 4 4 12 13 32 1600 1920 20 16 7 10 5 5 14 15 36 1800 2160 23 18 8 11 5 6 16 17 40 2000 2400 24 20 9 12 6 6 17 18 44 2200 2640 27 21 10 14 7 7 19 20 48 2400 2880 29 21 11 15 7 8 21 22 52 2600 3120 32 22 12 16 8 8 23 23 56 2800 3360 34 22 13 17 9 9 26 24 60 3000 3600 36 23 14 18 9 9 27 26 Each configuration being different, use those numbers with care: they are only an indication. No SNMP polling were performed to gather the operation results

Cisco IP SLA´s Performance: UDP-Jitter for VoIPUDP-Jitter Probe for VoIP (G.729a) Running Eng 3—Cisco IOS 15.1(4)MDefault Parameters: Frequency (60secs), Codec Packet Size (32bytes), Codec Interval (20ms), Codec Number of Packets (1000) 1921 2921 3925 3945 3945E Operations (Total) 150 225 275 400 900 Operations/Second 2.5 3.75 4.58 6.7 15.0 Packets Per Second 2500.0 3750.0 4583.3 6733.3 15000.0 Operations/Min 150 225 275 400 900 CPU Usage ~59% ~61% ~43% ~54% ~43% Each configuration being different, use those numbers with care: they are only an indication. No SNMP polling were performed to gather the operation results

IP SLAs Typical Memory Usage Eng2 12.2(13)T UDP Jitter < 14KB UDP Echo < 3.5KB ICMP Echo < 3.2 KB

Performance Conclusions• Under normal conditions and with reasonable targets, a performance issue with IP SLA is unlikely• Memory usage is reasonable, and should never be a problem on any platform.

IP SLA Reaction ConditionsReaction Trigger to Events• Can send SNMP traps for certain ―triggering‖ events: Trigger: – Connection Loss and Timeout •Immediate – Round Trip Time Threshold •Consecutive – Average Jitter Threshold – Unidirectional packet loss, latency, jitter, MOS Scores •X of Y times •Average Exceeded• Can trigger another IP SLA operation for further analysis Threshold No Alert Threshold Alert Violation Violation Alert 100 ms 50 ms Threshold Time violation Resolution #CiscoPlusCA

Proactive Notification• Simulating G.711 A-Law codec (64 kbps transmission) VoIP Call set default values for: Enables system message - codec-numpackets,Source # logging globally - codec-size, & logging on - codec-interval ip sla 10 udp-jitter 209.165.200.225 dest-port 16384 codec g711alaw advantage-factor 2 owner admin tag jitter-with-voice-scores ip sla schedule 10 start-time now ip sla reaction-configuration 10 react mos threshold-type immediate threshold-value 490 250 action-type trapOnly ip sla logging traps connectionLoss, jitterAvg, jitterDSAvg, snmp-server host 10.10.10.10 version 2c public snmp-server enable traps syslog jitterSDAvg, Mos, PacketLossDS, PacketLossSD To translate syslog into Rtt, traps Timeout, verifyError

Common Questions…• How should I configure my operations to accurately measure jitter/delay/packet loss?• How many packets should be sent per operation?• How frequently?• What percentage of my bandwidth should be dedicated for measurement?

Spectrum of Test• This is the proportion of time during which the network is under test• A small spectrum of test means a small probability of catching an event• For example: running a test for 20 seconds every 60 seconds is equivalent to a 33% spectrum of test

Spectrum of Test Network Is This Event Under Test Was Missed Delay Time

Spectrum of Test Network is Fault Is Under Test Detected Delay Time

Number of Packets• The more packets sent: The larger the population The more diluted are the results• At identical frequency, the longer the operation, and the wider the test spectrum.• Example of result dilution with the same spectrum, but a bigger number of packets per operation. Non-diluted: Diluted:

Frequency• The operation frequency, as well as operation duration, have a direct impact on the SPECTRUM OF COVERAGE• Increasing the frequency will increase your spectrum of coverage, and increase the bandwidth consumed but will not change the accuracy

Interval Effect of Jitter• Longer intervals ultimately measures bigger jitter, because of coarse granularity: Delay Time Jitter

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

Interval and Jitter• Compare different jitter measurements ONLY if the measurement intervals are identical• Short interval is more accurate, but more expensive – Use occasionally to have a true application-like jitter• Long interval is less accurate, but consumes less bandwidth – Use to expand test spectrum and keep an eye on jitter trends

Packet Size• The main effect of packet size is to modify the SERIALIZATION DELAY• On fast links, this is negligible compared to the propagation delay, so the packet size has little or not effect but to consume bandwidth• Use small packets of fast links, like on core network• Use realistic packets for low-speed access links, where the serialization delay is a factor we need to count

Auto IP SLAaka Engine 3  All New in 15.1(1)T• Template Based CLI (Modular CLI)• QoS Integration• End-Point Auto Registration• Cross-OS code base (works on Linux and FreeBSD)• Responder performance enhancement

What, Where, When...• ip sla auto-measure group wacho destination ip-address alist-1 port 16000 type jitter schedule id wa-sched• ip sla list ip-address alist-1 ip-addresses 1.1.1.1, 2.2.2.2, 3.3.3.3 ip-addresses 10.1.1.1-100 ip-addresses exclude 10.1.1.5, 10.1.1.8• ip sla auto-measure schedule wa-sched start-time now

QoS Integration (example) Observation: Need to send the same operation in each class. Problem: Provision the same operation multiple times is lengthy, error prone, and counter productive. Solution: Discover the QoS classes on the outgoing interface and automatically instantiate probes. } class-map voice-traffic match dscp EF QoS Class Definition class-map data-traffic match dscp AFnn Automatically policy auto-measure instantiate IP SLA class voice-traffic measure type ip-sla group voice-traffic-probes-grp class data-traffic measure type ip-sla group udp-jitter-probes-grp } probes

End-Point Auto Registration ip sla auto group test Hub to Spoke-1 measure type udp-jitter ip sla 34567 udp-jitter 10.10.10.2 5000 destination auto-discover dest-port 5000 Hub to Spoke-2 schedule now ip sla 87422 udp-jitter 20.20.20.2 5000 Hub to Spoke-3 Hub ip sla 363435 udp-jitter 30.30.30.2 5000 spoke-3 172.17.0.5 30.30.30.2 ip sla responder auto-register 172.17.0.5 10.10.10.2 20.20.20.2 spoke -1 spoke-2 ip sla responder auto-register 172.17.0.5ip sla responder auto-register 172.17.0.5

Instrumentation and Management• IP SLA fits in what is called Device Instrumentation• Can be used standalone or it can be combined with other instrumentation – e.g. Enhanced Object Tracking (EOT) Embedded Event Manager (EEM), Performance Routing (PfR)• To unleash its full potential, it works best with a Network Management application • Configuration • Topology Management Network Management • Data Retrieval Application • Graphing • Reporting • Web Portal • And much more!

Cisco Product SupportCisco 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

References• Cisco IOS IPSLA home page http://www.cisco.com/go/ipsla• For questions related to Cisco IP SLAs that cannot be handled by the Technical Assistance Center (TAC), feel free to write an email to: ask-ipsla@cisco.com• Cisco Prime products http://www.cisco.com/go/prime

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.

We value your feedback.Please be sure to complete the Evaluation Form for this session. Access today‘s presentations at cisco.com/ca/plus Follow @CiscoCanada and join the #CiscoPlusCA conversation

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

by Cisco Canada on Jun 06, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

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