1. CISCO IOS IP SERVICE LEVEL AGREEMENTS: TECHNICAL OVERVIEW
TOM ZINGALE
INTERNET TECHNOLOGIES DIVISION
SEPTEMBER 2004
This presentation introduces Cisco IP Service Level Agreement (IP SLA), previously called Cisco Service Assurance Agent (SAA) in Cisco IOS Software.

2. Cisco IOS IP Service Level Agreement: A New Direction
Cisco solution that assures IP service levels, proactively verifies network operation, and accurately measures network performance
Comprehensive hardware support
Committed Cisco partner support
Cisco IOS Software, the world’s leading network infrastructure software
Enterprise and Small Medium Business
Service Providers
Understand Network
Performance &
Ease Deployment
Verify Service Levels
Verify Outsourced SLAs
Measure and provide
SLAs
Today, customers are adding voice, video, and other delay-sensitive applications (such as virtual private networks) to their IP data networks. The need for network performance monitoring has moved from being something used by service providers to something required by networks running converged IP services.
Having network monitoring capabilities in place helps networks verify service level guarantees, validate network performance, improve mean-time-to-restore, and reduce the time required for network troubleshooting.
Access
Enterprise Backbone
Enterprise Premise Edge
Service Provider Aggregation Edge
Service Provider Core
Cisco IOS Software

3. The Need for IP-Based Service Levels
PROBLEM
RESULT
40% of companies delay launching new applications due to network performance concerns2
Reduced business productivity
59% of companies simply add bandwidth to ensure application efficiency2
Increased network costs
55% of companies only identify some of their network traffic2
Reduced understanding of network behavior
Cost of application downtime and degradation is $13,000 per minute for an ERP application3
Lowered network performance can be costly
Infonetics Research Study “Cost of Enterprise Downtime”
Network World Application Performance Market Study
3 Forrester Research

4. Cisco IOS IP SLA Benefits
OPTIMIZED APPLICATIONS & SERVICES
REDUCED TOTAL COST OF OWNERSHIP AND OpEx
Performance visibility
Prove service levels
Enhance Customer satisfaction
Enhance acceptance of business- critical services
Reduce deployment time
Lower mean time to restore and downtime
Proactive identification of issues enforces higher reliability
Measurements and Metrics
Proactive
Automated Intelligence
Continuous
Predictable Reliable
Today, customers are adding voice, video, and other delay-sensitive applications (such as virtual private networks) to their IP data networks. The need for network performance monitoring has moved from being something used by service providers to something required by networks running converged IP services.
Having network monitoring capabilities in place helps networks verify service level guarantees, validate network performance, improve mean-time-to-restore, and reduce the time required for network troubleshooting.

5. Cisco IOS IP SLAs Life Cycle
Understand network performance baseline Confidence to deploy
new IP services
and applications
Baseline network
performance Verify network readiness for new services with Cisco IOS IP SLA capabilities.
Assure application
and service deployment 2 1
Quantify results
Reduce deployment time
Prove service and application differentiation
Verify service levels
Reduce network down time
Manage demand for the network
Fine tune and optimize
Ongoing measurements to understand behavior
with proactive notification 3 4

6. Example: Multi-Protocol Measurement and Management with Cisco IOS IP SLAs
Applications
Availability
Network
Performance
Monitoring
VoIP
Monitoring
Service Level
Agreement
(SLA)
Monitoring
Network
Assessment
Multiprotocol
Label
Switching
(MPLS)
Monitoring
Trouble
Shooting
Measurement Metrics
Latency
Packet
Loss
Network
Jitter
Dist. of
Stats
Connectivity
Protocols
Jitter
FTP
DNS
DHCP
DLSW
ICMP
UDP
TCP
HTTP
LDP
H.323
SIP
RTP
Radius
Video
Defined Packet Size, Spacing
COS and Protocol
IP Server
IP SLA
Cisco IOS
Software
IP Server
Source
MIB Data
Active Generated Traffic to measure the network
Destination
IP SLA
Cisco IOS
Software
IP SLA
Cisco IOS
Software
Responder

7. Comprehensive Hardware Support
Enterprise & Aggregation/Edge
Core
Cisco IOS Software Release 12.2S
Cisco Series
Cisco Catalyst 6500; Cisco 7600 Series
Cisco Series
Cisco 7300 Series
Cisco Series
Access
Cisco IOS Software Releases 12.3T and 12.4
Cisco 2900, 3550, & Series
Cisco 7200 & Series
Cisco 2600
2800 Series
Cisco Series
Cisco 1700
1800 Series
Cisco 800 Series

8. SLA Verification and Management
Access router may be managed or unmanaged
Data typically provided by the service provider for the customer includes availability, QoS, and Jitter SLAs
Service Provider needs visibility in the 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

9. Network Monitoring Cisco IOS IP SLA answers the following question:
What is the jitter, latency, or packet loss between any two points in the network?
IP Services can be simulated by specifying various packet sizes, ports, class of service, packet spacing, and measurement frequencies
Uni-directional and highly accurate measurements
Measurements per class of service to validate service differentiation for data, voice, and video
Cisco IOS IP SLA will identify an edge to edge network performance baseline and allow the user to understand trends and anomalies from the baseline

10. IP Network Readiness
Network assessment tool built into Cisco IOS Software
Simulate IP Services and verify how well they will work in the network
How well is QoS working in the network pre-deployment
Post deployment continued verification of network performance per IP service

11. Availability Monitoring
Cisco IOS IP SLA 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

12. Troubleshooting with Cisco IOS IP SLA
Proactive notification of problems and issues based on threshold alerts
Testing edge to edge consistently and reliability will save time in finding and pin pointing network performance problem areas
Secondary activation of path operation (ie: path jitter) or activation of operations at a higher frequency to isolate and verify problem areas in the network

13. Cisco IOS IP SLA Source and Responder
Source Router
Cisco IOS Software router that sends data from operation
Cisco IOS Software may or may not be the target
Some operations require the target to run the IP SLA responder
Stores results in MIB
Responder
Responds to IP SLA packets at destination
User defined UDP/TCP ports
IP SLA Control Protocol
MD 5 Authentication
Accurate measurements

14. The Responder takes 2 Timestamps (T2 & T3)
Source Router
Target Router
Responder T2 T1 T3 T4
D = T3 - T2
The Responder takes 2 Timestamps (T2 & T3)
Control Sequence Open up UDP ports.
IP SLA uses a control message on UDP port 1967 but the responder replies back to the control port on another UDP port number. Don’t know what it is but it is a high port number.
The control process is as follows. IP SLA sends control with type, and udp port and duration of probes, for this cycle.
Responder Ack control probe but on another port. Don’t know what the number is but it is high.
Responder then opens up udp port for the duration as instructed in control packet.
Responder received probes and then closes.
Responder is acknowledging probes as it receives them.
IP SLA Response Calculation
Source Router IP SLA processing delay =T5-T4
Responder processing delay = T3-T2
RTT is T5-T1 minus IP SLA and responder processing delays.
RTT = T5-(t1-dS+dT)
dT = Delta on Target Router, dS is delta on source.
Points to make about this slide.
IP SLA probe enters output interface queues as any other packet if you set precedent bits is will go to the back of the appropriate queue.
The dt and ds times are Router processing time these are the removed from all RTT and Jitter Calculations.
Clarification of Responder Time stamp process
When IP SLA or Responder is enabled device checks all IP packets to see if they are IP SLA probes packet is IP SLA probe interrupt is generated and the packet Router time stamped (T2) the IP packet this then queued.
The responder listens on UDP port when it is ready to process it will read IP queued packets. The responder timestamps then packet (T3) when it first receives the packet.
The difference in time T3-T2 is the time that the packet has waited in the IP queue for the responder to start processing the packet. This is idle time when the responder may be busy with another process or the router is busy and as the responder has normal priority other process will take precedence when the Router is busy.
The priorities are Critical, High, Normal and Low. IP SLA has normal.
Responder factors out destination processing time making results highly accurate
Responder allows for one-way measurements for latency, jitter, packet loss, and MOS

15. Cisco IOS IP SLAs Uses and Metrics
*DATA
TRAFFIC
*VoIP
*SERVICE LEVEL AGREEMENT
*AVAILABILITY
**STREAMING
VIDEO
REQUIREMENT
Minimize Delay, Packet Loss
Verify Quality of Service (QoS)
Minimize Delay, Packet Loss, Jitter
Measure Delay, Packet Loss, Jitter
One-way
Connectivity testing
Minimize Delay, Packet Loss
IP SLA MEASURMENT
Jitter
Packet loss
Latency
per QoS
MOS Voice Quality Score
Enhanced accuracy
NTP
Connectivity tests to IP devices
Cisco IP SLA brings customers the ability to create a variety of end-to-end network performance tests based on clear measurement metrics for many network applications, assist in planning, and simplify and speed up network management tasks.
* Currently available
**Limited availability in 9/04; complete in CY’05

16. Cisco IOS IP SLA Reaction Conditions
Reaction Trigger to Events
Can send SNMP traps for certain “triggering” events:
Connection Loss and Timeout
Round Trip Time Threshold
Average Jitter Threshold
Unidirectional packet loss, latency, jitter, MOS Scores
Can trigger another IP SLA operation for further analysis
Trigger
Immediate
Consecutive
X of Y times
Average Exceeded
Threshold
Violation
No Alert
Alert
Threshold
Violation
Alert
Enabling Reaction conditions set up in 2 parts.
1 Configure the threshold in the basic rtr configuration. Default is 5000ms
2 use the rtr reaction-configuration command to specify what you want react to.
A: Threshold, time-out, loss of connection in connection orientated protocols.
B: Threshold type immediate will react as soon as the threshold is crossed, consecutive will require a consecutive number of probes to exceed the threshold, xofy the last x out of y probes must exceed the threshold.
C: action-type what do you want the probe to do if a threshold is violated. Send a trap, trigger another SAA probe on the router.
D: threshold-falling send a trap for first crossing of threshold but don’t send any more until the lower threshold is crossed.
The configuration give does the following
Animation 1 &2 trap sent for first crossing.
Animation 3 no trap sent since not dropped below lower threshold
Animation 4 cross lower threshold rearm trap
Animation 5 cross upper threshold send second trap
100 ms
50 ms
Threshold
violation
Time
Resolution
Cisco IOS IP SLA, Technical, 9/04
Cisco Internal Use Only
© 2004 Cisco Systems, Inc. All rights reserved. 16

17. UDP Jitter One Way Latency
Availability X
12.2(11)T (Infra2)
12.2(14)S
12.1E
SNMP Support
12.2(2)T
APM
ICMP Path Jitter
Frame-Relay (CLI)
MPLS/VPN Aware
FTP Get
UDP Jitter One Way Latency
DLSw+
DHCP
DNS
HTTP
UDP Jitter
TCP Connect
UDP Echo
SSCP(SNA)
ICMP Echo Path
ICMP Echo
12.2(25)S
12.1(1)T 12.2
12.0(5)T 12.0(8)S
12.0(3)T
11.2
Feature/Release

18. Cisco IOS IP SLA Partners
Cisco Network Management Solution
Cisco IP Solution Center
MPLS VPN and SLA Monitoring
Internetworking Performance Monitor
Enterprise performance measurements
THIRD PARTY PRODUCTS
Cisco partners, including HP and Concord Communications, have integrated IP SLA functions and metrics into their popular network performance tools.

19. Cisco IOS IP SLA Performance with Infrastructure 2: CPU Load by Hardware
Jitter probe
Versus Release 12.3(3)
2,000 active probes
Operations/ Second
Operations/ Minute
Cisco 2600 Series
Cisco 2620XM Series
Cisco 3640 Series
Cisco 3725 Router
Cisco 7200VXR NPE225 4
240 14 7 6 2 8
480 20 9 3 12
720 29 13 16
960 35 15 17
1200 41 19 22 24
1440 48 25 28
1680 56 27 32
1920 63 31 36
2160 67 40
2400 34 38 44
2640 43
2880 42 47 5 52
3120 46 49 10
3360 11 60
3600 58
*Jitter operations are activated sequentially with this testing. Each operation sends 10 packets, 64 bytes each with 20ms spacing

20. Cisco IOS IP SLA Performance Infrastructure 2: CPU Load by Hardware
Jitter probe
Release 12.3(4)T6
IP Plus/Firewall/3DES
2,000 active probes
Operations per second
Operations per minute
Cisco 831 Router
Cisco 837 Router
Cisco Router 4
240 7 10 3 8
480 13 16 12
720 23
960 29 30 17 20
1200 33 34 22 24
1440 35 36 27 28
1680 41 32
1920 47 46
2160 52 50 40
2400 57 56 39 44
2640 62 43 48
2880 66 65
3120 72 68 53
3360 76 71 59 60
3600 81 75

21. Cisco IOS IP SLA VoIP Measurements Q1CY’05
Data Center
Gatekeeper
Registration
Delay
Call Manager
Cluster
Discovery
Delay
Post Dial Delay
H323 or SIP
Headquarters
Responder
Seattle
Sales Office LA
Sales Office
San Jose
Sales Office
New York
Sales Office
Boston
Sales Office
Cleveland
Detroit

22. Digital Signal Processor Based IP SLA Measurements (Q3CY’05)
VoIP Active (test call) measurements using Real-time Transport Protocol (RTP) streams
Voice quality scores and voice metrics from the Digital Signal Processor (DSP)
Call Control
VoIP Metrics
RTP
IP SLA
DSP
IP Server
Responder
RTP IP SLA
Cisco IOS IP SLA RTP Operation Data

23. New IOS IP SLA CLI
The new IOS IP SLA CLI releases Q1CY05 in 12.3(RLS6)T
Phase 1 changes include new syntax for commands and new show commands
New show commands: “show ip sla statistics” and “ show ip sla statistics details”
Older show commands will be deprecated over time and replaced with the new show commands
The RTR keyword was changed to IP SLA Monitor in CLI
The new syntax is used in the presentation. The old syntax before 12.3(pi6)T is shown in the Appendix
This was intentional. They can use the old feature sets for 12.3 to get
around the problem. IP SLA is a value-add feature that was historically free to
use but this has changed. IP SLA is available in VoIP and above. IP Base is
supposed to be a minimum memory foot print package and features were
removed.
In 12.4(pi1)T the responder and ICMP echo will be ported back into IP Base.
So the customer will get some functionality.
OLD CLI
Router (config)#rtr 1
Router (config-rtr)#type echo protocol ipIcmpEcho
Router (config)#rtr schedule 1 start-time now
New CLI
Router (config)#ip sla monitor 1
Router (config-sla-monitor)#icmp-echo
Router (config)#ip sla monitor schedule 1 start-time now

24. New Cisco IOS IP SLA Show Commands Q1CY’05
Jitter operation “show ip sla monitor statistics (details)”
Router#sh ip sla monitor statistics 15
Round trip time (RTT) Index 15
Latest RTT: 1 ms
Latest operation start time: *05:43: UTC Fri May
Latest operation return code: OK RTT Values
Number Of RTT: 10
RTT Min/Avg/Max: 1/1/1 ms
Latency one-way time milliseconds
Number of one-way Samples: 0
Source to Destination one way Latency Min/Avg/Max: 0/0/0 ms
Desination to source one way Latency Min/Avg/Max: 0/0/0 ms
Jitter time milliseconds
Number of Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 20/20/23 ms
Destination to Source Jitter Min/Avg/Max: 0/0/0 ms
Packet Loss Values
Loss Source to Destination: Loss Destination to Source: 0
Out Of Sequence: Tail Drop: 0 Packet Late Arrival: 0
Number of successes: 1
Number of failures: 0
Operation time to live: 3567 sec
The first phase basically changed “rtr” to “ip sla monitoring” and gave us a new command show ip sla statistics .
Show ip sla monitor statistics We originally had show ip sla statistics but the parser police insisted on monitor. The main reasons are two. Cisco does not have a strict SLA in CLI and by adding the monitor command we definitely let the user understand this. The second reason is we may do more than just monitor in the future with IP SLA. For instance we may automatically change other setting in IOS code based on an SLA (thinking in the future). Aka your TCL script below or integration with EEM. The parser police approve CLI and have been doing this stuff for years. We had no choice but to listen to their wisdom.
Ok we have a new command show ip sla stats and another show ip sla stats details . Both of these commands use the data from the show rtr operation command . The new command being considered will use data from show rtr collections stats or the aggregated data available in that command and display in a similar format to what is below.. We will also eliminate the show ip sla collection stats command over a few releases. The new command format would be show ip sla stats aggregated and show ip sla stats aggregated details
2nd phase implementation:
Hi,
I am working on the phase 2 of the new IP SLA CLI prd. The first phase basically changed rtr to ip sla and gave us a new command show ip sla statistics . I can get you an output of the command if you want to see it.
I am thinking about a template based configuration for IP SLA. This will be similar to what we use for the MPLS auto feature. I want to use a template (example below) to create a set of operations to multiple destinations. The template will be used to generate the individual IP SLA operations. We are also planning an Auto IP SLA feature that I will not discuss, but basically using a signaling protocol to automatically create operations based on a template (this feature is going to be later).
I want to have the user specify a set or range of IP addresses for a template to generate IP SLA probe configuration. Do you think this is worth while and would be useful? I believe it will enhance ease of use.
Example:
Ip sla map 1
type jitter
destination , ,
destination-port 4000
number-packets 1
packet-interval 20
threshold 4000
timeout
request-data-size
owner
tos blah
vrf blah
&
ip sla map scheduler 1
schedule-period 100
frequency 100
schedule-type random
frequency-range 5,10
start time
ip sla map reaction-configuration 1
react timeout
threshold type immediate
action-type trap
We will still have the individual probes created from the template. Should we change the format for the individual probes as well? We can change this completely and make it more intuitive or easier read on a per probe basis.
Today we have the
Ip sla 1
Type blah
We could have
Ip sla monitor 1
destination
I will have a few more s unrelated to this thread on CLI changes. I hope you can participate.

25. New Cisco IOS IP SLA Show Commands Q1CY’05
Jitter operation “show ip sla monitor statistics details”
Round trip time (RTT) Index 2004
Latest RTT: 1 ms
Latest operation start time: *08:41: PST Wed Oct
Latest operation return code: OK
Over thresholds occurred: FALSE
RTT Values
Number Of RTT: 10
RTT Min/Avg/Max: 1/1/1 ms
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 ms
Destination to Source Latency one way Min/Avg/Max: 0/0/0 ms
Source to Destination Latency one way Sum/Sum2: 0/0
Destination to Source Latency one way Sum/Sum2: 0/0
Jitter time:
Number of Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/0/0 ms
Destination to Source Jitter Min/Avg/Max: 0/0/0 ms
Source to destination positive jitter Min/Avg/Max: 0/0/0 ms
Source to destination positive jitter Number/Sum/Sum2: 0/0/0
Source to destination negative jitter Min/Avg/Max: 0/0/0 ms
Source to destination negative jitter Number/Sum/Sum2: 0/0/0
Destination to Source positive jitter Min/Avg/Max: 0/0/0 ms
Destination to Source positive jitter Number/Sum/Sum2: 0/0/0
Destination to Source negative jitter Min/Avg/Max: 0/0/0 ms
Destination to Source negative jitter Number/Sum/Sum2: 0/0/0
Interarrival jitterout: Interarrival jitterin: 0
The first phase basically changed “rtr” to “ip sla monitoring” and gave us a new command show ip sla statistics .
Show ip sla monitor statistics We originally had show ip sla statistics but the parser police insisted on monitor. The main reasons are two. Cisco does not have a strict SLA in CLI and by adding the monitor command we definitely let the user understand this. The second reason is we may do more than just monitor in the future with IP SLA. For instance we may automatically change other setting in IOS code based on an SLA (thinking in the future). Aka your TCL script below or integration with EEM. The parser police approve CLI and have been doing this stuff for years. We had no choice but to listen to their wisdom.
Ok we have a new command show ip sla stats and another show ip sla stats details . Both of these commands use the data from the show rtr operation command . The new command being considered will use data from show rtr collections stats or the aggregated data available in that command and display in a similar format to what is below.. We will also eliminate the show ip sla collection stats command over a few releases. The new command format would be show ip sla stats aggregated and show ip sla stats aggregated details
2nd phase implementation:
Hi,
I am working on the phase 2 of the new IP SLA CLI prd. The first phase basically changed rtr to ip sla and gave us a new command show ip sla statistics . I can get you an output of the command if you want to see it.
I am thinking about a template based configuration for IP SLA. This will be similar to what we use for the MPLS auto feature. I want to use a template (example below) to create a set of operations to multiple destinations. The template will be used to generate the individual IP SLA operations. We are also planning an Auto IP SLA feature that I will not discuss, but basically using a signaling protocol to automatically create operations based on a template (this feature is going to be later).
I want to have the user specify a set or range of IP addresses for a template to generate IP SLA probe configuration. Do you think this is worth while and would be useful? I believe it will enhance ease of use.
Example:
Ip sla map 1
type jitter
destination , ,
destination-port 4000
number-packets 1
packet-interval 20
threshold 4000
timeout
request-data-size
owner
tos blah
vrf blah
&
ip sla map scheduler 1
schedule-period 100
frequency 100
schedule-type random
frequency-range 5,10
start time
ip sla map reaction-configuration 1
react timeout
threshold type immediate
action-type trap
We will still have the individual probes created from the template. Should we change the format for the individual probes as well? We can change this completely and make it more intuitive or easier read on a per probe basis.
Today we have the
Ip sla 1
Type blah
We could have
Ip sla monitor 1
destination
I will have a few more s unrelated to this thread on CLI changes. I hope you can participate.

26. Cisco IOS IP SLA Multiple Operations Scheduling (Release 12.3(8)T)
Schedule multiple operations in one command
Scalable and sequential activation of IP SLA operations
If the frequency is not specified, the default frequency will be the same as that of the schedule period)
Reduced load on the network
Consistent monitoring coverage
Router (config)#ip sla monitor 1
Router (config-sla-monitor)#type echo protocol ipIcmpEcho
Router (config)# ip sla monitor 2
Router (config-sla-monitor)#type echo protocol ipIcmpEcho
Router (config)# ip sla monitor 3
Router (config-sla-monitor)#type echo protocol ipIcmpEcho
Router (config)# ip sla monitor group schedule sch 20 start now
Router #show ip sla monitor group schedule

27. Cisco IOS IP SLA Random Scheduler Enhancement
Release 12.4(Rls1)T will introduce the following functionality:
Randomness for group scheduler during schedule period
Randomness for the frequency of the operations, which are started by random group scheduler
Based on PRD "IP SLA Random Scheduler Enhancement", what really needs to be done is:
- Introduce randomness for group scheduler during schedule period
- Introduce randomness for the frequency of the probes, which are started by random group scheduler
As suggested in PRD, RFC2330 can be referenced for how to introduce Poisson distribution for the above two randomness.
Based on the thread, there is very strong demand for jitter probe to introduce randomness in the sending time interval of two consecutive packets. [This would not applicable to other probes, which perform measurement only once. The frequency randomness has covered that.] I certainly agree this is very important and valuable as most of you are dealing with customer daily. As discussed in the meeting with Tom and Ning Zhao, we will set this as stretch goal. If it were not done in 12.4Pi1, it would be done in 12.4PI2. If you have any comments, please let me know.
Talking about the implementation of Poisson distribution, there are two ways suggested in RFC2330 page#22:
"In its purest form, Poisson sampling is done by generating independent, exponentially distributed intervals and gathering a single measurement after each interval has elapsed. It can be shown that if starting at time T one performs Poisson sampling over an interval dT, during which a total of N measurements happen to be made, then those measurements will be uniformly distributed over the interval [T, T+dT]. So another way of conducting Poisson sampling is to pick dT and N and generate N random sampling times uniformly over the interval [T, T+dT]. The two approaches are equivalent, except if N and dT are externally known. In that case, the property of not being able to predict measurement times is weakened (the the properties still hold). The N/dT approach has an advantage that dealing with fixed values of N and dT can be simpler than dealing with a fixed lambda but variable numbers of measurements over variably-sized intervals."
The first approach is to generate N number over [0, 1] uniformly, then do a natural logarithm of a floating number (e.g 0.56). By doing this N numbers E1, E2,...En are generated. These number should show the Poisson distribution pattern.
The second approach is to generate N numbers over [T, T+dT] in an uniform way, sorting these N numbers from smallest to biggest, then compute the diff value between two neighbor numbers. The result should show the Poisson distribution pattern as well per Poisson distribution definition.
I can see that the result could be different. E.g the first approach could possibly have a big number Ej, which could be (T+Ej) > (T+dT). However this will not happen in the second approach.
From implementation perspective, the first approach requires natural logarithm/floating point number computation, which IOS doesn't support natively (no FPU). I don't know whether there is such utility existing today in IOS. For this reason, I tend go for the second approach. The potential problem I can see is that if N is very big(e.g. 3000), sorting N numbers could take quite some CPU resource. There is IOS kernel service to generate 32 bits random integer.
I like to hear your opinion. Also if I missed/misunderstanding something, please feel free to point out.
Thanks.
Wenwei Weng

28. Cisco IOS IP SLA Accuracy Feature
High performance and high accuracy measurements
Precision to .1 ms from current 1ms
Improve Cisco IOS IP SLA accuracy under forwarding load and for dedicated routers
Release 12.3(RLS6)T will introduce this functionality in Q1CY’05

29. Cisco IOS IP Service Level Agreement Roadmap
Feature
Release
Target Date
Release 12.3T Features
MOS and ICPIF Scores
12.3(4)T
November 2003
One way latency, jitter, packet loss and MOS Traps
12.3(7)T
March 2003
Multi-Operation Scheduler – Ease of scheduling
12.3(8)T
June 2003
Post Dial and Gatekeeper Delays with SIP and H323
12.3(pi-6)T
Q1CY’05
High accuracy enhancement
Ease of use CLI
Release 12.4T Features
Ease of use CLI Phase 2
12.4(pi-1)T
Q2CY’05
Random scheduler for operations
Voice gateway integration VoIP measurement using DSP
12.4(pi-2)T
Q3CY’05
Ease of use CLI Phase 3
Video operation
Radius response operation
Release 12.2S Features
IP SLA: Auto MPLS VPN Monitoring
12.2(Rls6)S
IP SLA: Auto MPLS VPN Monitoring with ECMP
12.2(Rls7)S
IP SLA: Auto MPLS Monitoring with VCCV
12.2(Rls8)S
Radar
IP SLA: Auto MPLS Monitoring with BFD
IP SLA Multicast
Auto IP SLA Monitoring
IP SLA with DMVPN
ICMP Jitter
IP SLA High Availability
Embedded Event Manager (EEM) Detector
Cisco partners, including HP and Concord Communications, have integrated IP SLA functions and metrics into their popular network performance tools.

30. NetFlow Virtual private networks are a growing IP application.
IP SLA can monitor the connectivity of MPLS VPNs for one or more classes of service.

31. Flow Is Defined By Seven Unique Keys
Traffic
Source IP address
Destination IP address
Source port
Destination port
Layer 3 protocol type
TOS byte (DSCP)
Input logical interface (ifIndex)
Enable NetFlow
New SNMP MIB Interface
NetFlow
Export Packets
SNMP Poller
Traditional Export &
Collector
GUI
Cisco IOS NetFlow Overview, 2/04
© 2004 Cisco Systems, Inc. All rights reserved. 31 31 31

32. Non-Aggregated Flows—Export Version 5 or 9
NetFlow Cache Example
Create and update flows in NetFlow cache
Srclf
SrclPadd
Dstlf
DstlPadd
Protocol
TOS
Flgs
Pkts
Src Port
Src Msk
Src AS
Dst Port
DstMsk
Dst AS
NextHop
Bytes/Pkt
Active
Idle
Fa1/0
Fa0/0 11 80 10
11000
00A2
/24 5 15
1528
1745 4 6 40
2491
/26
196
740
41.5 1
10000
00A1
180
1428
1145.5 3
2210 19
/30
1040
24.5 14
Inactive timer expired (15 sec is default)
Active timer expired (30 min (1800 sec) is default)
NetFlow cache is full (oldest flows are expired)
RST or FIN TCP Flag
Expiration
Srclf
SrclPadd
Dstlf
DstlPadd
Protocol
TOS
Flgs
Pkts
Src Port
Src Msk
Src AS
Dst Port
DstMsk
Dst AS
NextHop
Bytes/Pkt
Active
Idle
Fa1/0
Fa0/0 11 80 10
11000
00A2
/24 5 15
1528
1800 4
Aggregation No
Yes
e.g. Protocol-Port Aggregation Scheme Becomes
Export version
Non-Aggregated Flows—Export Version 5 or 9
Protocol
Pkts
SrcPort
DstPort
Bytes/Pkt 11
11000
00A2
1528
Export
Packet
Payload
(Flows)
Transport protocol
Header
Aggregated Flows—Export Version 8 or 9

33. Principle Netflow Benefits
Service Provider
Enterprise
Peering arrangements
Network Planning
Traffic Engineering
Accounting and billing
Security Monitoring
Internet access monitoring (protocol distribution, where traffic is going/coming)
User Monitoring
Application Monitoring
Charge Back billing for departments
Security Monitoring

34. Tracking Users Who are the top users?
How long are the users on the network?
What Internet sites do they use?
Where do the users go on the network?
What percentage of traffic do they use?
What applications do they use?
What are the user usage patterns?

35. NetFlow for Security: Flow Information Helps Mitigate Attacks
Identify the attack
Count the Flows
Inactive flows signal a worm attack
Classify the attack
Small size flows to same destination
What is being attacked and origination of attack
Key Partners: Arbor Networks, Protego, NetQos, Adlex

36. Capacity Planning
Capacity planning is the process of determining the network resources required to prevent a performance or availability impact on business-critical applications
Key areas to monitor
Application usage
Identify which applications consume bandwidth
Who are the top ten nodes that consume bandwidth
Output data circuit forecasts
Current network utilization and capacity being used

37. Billing IP Accounting and Billing Usage-based billing considerations
Time of day
Within or outside of the network
Application
Distance-based
Quality of Service (QoS) / Class of Service (CoS)
Bandwidth usage
Transit or peer
Data transferred
Traffic class

38. How Cisco IT uses NetFlow
Characterize IP traffic and account for how and where it flows
Total Avoidance of SQL Slammer Worm
Transition from Managed DSL service to Internet VPN
Detection of Unauthorized WAN Traffic
Reduction in Peak WAN Traffic
Validation of QoS Parameters and BW allocation
Analysis of VPN Traffic and Tele-Commuter Behavior
Calculating Total Cost of Ownership for Applications
Use of NetFlow
NMS and Usage
Security Monitoring
Network traffic analysis by application with BGP. Anomaly detection Arbor Networks
WAN Aggregation and Edge
Network traffic analysis by application, for capacity planning using NetQOS
Core routers and Nat Gateway
Collection of historical data, useful for forensics and diagnostics with Flow Tools

39. Comprehensive Hardware Support
Enterprise & Aggregation/Edge
Core
Cisco IOS Software Release 12.2S
Release 12.0S
Cisco Series
ASIC
Cisco Catalyst 6500; Cisco Series
Cisco 10000
Series ASIC
Cisco 7300 Series
Cisco 4500
Series ASIC
Cisco 7200 Series
Access
Cisco IOS Software Releases 12.3T & 12.4
Cisco 7200/
7300 Series
Cisco 2600 Series
Cisco 3700 Series
Cisco Series
Cisco 800 Series

40. NetFlow Versions NetFlow Version Comments 1 Original 5
Standard and most common 7
Specific to Cisco Catalyst 6500 and 7600 Series Switches
Similar to Version 5, but does not include AS, interface, TCP Flag & TOS information 8
Choice of eleven aggregation schemes
Reduces resource usage 9
Flexible, extensible file export format to enable easier support of additional fields & technologies; coming out now MPLS, Multicast, & BGP Next Hop
Cisco Catalyst 6500 Series Router will support
versions 5 & 8 in Cisco IOS Software Release 12.1(13)E

41. Version 5 - Flow Export Format
Packet Count
Byte Count
Source IP Address
Destination IP Address
Source IP Address
Destination IP Address
Usage
From/To
Start sysUpTime
End sysUpTime
Time
of Day
Source TCP/UDP Port
Destination TCP/UDP Port
Application
Port
Utilization
Input ifIndex
Output ifIndex
Next Hop Address
Source AS Number
Dest. AS Number
Source Prefix Mask
Dest. Prefix Mask
Routing and
Peering
Type of Service
TCP Flags
Protocol
QoS
Version 5 used extensively today
Flow information

42. Why a New Version 9?
Fixed export formats are not flexible and adaptable
With each new version Cisco creates new export fields
Partners need to re-engineer for each new version
Solution: Build a flexible and extensible export format called version 9!

43. NetFlow v9 Export Packet
To support technologies such as
MPLS or Multicast, this export format can
be leveraged to easily insert new fields
Flows from
Interface A
Flows from
Interface B
Template FlowSet
Data FlowSet
Data FlowSet
Option
Template
FlowSet
Option Data
FlowSet
FlowSet ID
FlowSet ID #1
FlowSet ID #2
Template Record
Template ID #1
(specific Field
types and lengths)
Template Record
Template ID #2
(specific Field
types and lengths)
(version,
# packets,
sequence #,
Source ID)
Data Record
(Field values)
Data Record
(Field values)
Template ID
(specific
Field types
and lengths)
Option
Data
Record
(Field values)
Option
Data
Record
(Field values)
Data Record
(Field values)
Matching ID numbers are the way to associate template to the Data Records
The Header follows the same format as prior NetFlow versions so Collectors will be backward compatible
Each data record represents one flow
If exported flows have the same fields, then they can be contained in the same Template Record (ie: unicast traffic) can be combined with multicast records
If exported flows have different fields, then they cannot be contained in the same Template Record (ie: BGP next-hop cannot be combined with MPLS Aware NetFlow records)

44. NetFlow v9 and IETF
Internet Protocol Flow Information eXport (IPFIX) is an IETF Working Group
Netflow version 9 is the basis for the standard in the IETF
Standards Track NetFlow version 9
New

45. IETF: Packet SAMPling WG (PSAMP)
PSAMP web site for the charter, archive, drafts, etc. psamp.ccrle.nec.de/
Agreed to use IPFIX for export protocol if suitable for PSAMP
To be improved: the variable length data type
Note: NetFlow is already using some sampling mechanisms
New
Also at

46. NetFlow Partners
Traffic Analysis
Flow-Tools
Denial of Service
Billing

47. Cisco Catalyst 6500 Series Switch and Cisco 7600 Series Router
Hybrid: Cisco Catalyst OS on PFC/supervisor and Cisco IOS software on MSFC
Native Cisco IOS Software: PFC/supervisor and the MSFC both run a single bundled Cisco IOS software image
Export is centrally via the supervisor and MSFC, each linecard has its own hardware NetFlow cache and forwarding table, i.e. distributed platform
Hybrid
Native 12.1E
Native 12.2SX
MSFCx v5
v5, v8*
Sup1a
V7, v8 v7
N/A
Sup2
v5, v7
v5, v7, v8
Sup720
*No NetFlow Support on MSFC with Sup1a

48. Cisco Catalyst 6500 and Cisco 7600 Series Versions and Features
Cisco IOS Software Release 12.1(13)E1
PFC2 Source/destination interface information (Hybrid 6.3(6))
PFC2 Source/destination AS information
PFC2 Support for V5 NetFlow data export (Hybrid 7.5(1))
IP Next hop
Sampled NetFlow is available on PFC in Cisco IOS
Cisco IOS Software Release 12.2(14)SX
Version 8 in native mode
PFC3b (Sup720) cards
ToS byte
Hybrid Catalyst OS 7.2(1)
L2 switched traffic (vlan x to vlan y) support (doesn’t require MSFC)
Hybrid Catalyst OS 7.3(1)
Destination and source IfIndex enabled by default

49. Cisco Catalyst 4000 Supervisor IV NetFlow Services Card
NetFlow Service Card Features
NetFlow Statistics Collection and Data Export (NDE)
VLAN Statistics Collection
CLI support for NetFlow & VLAN Stats
SNMP support for VLAN Stats
Requirements:
Supervisor IV or V
IOS 12.1(13)EW
NetFlow Versions 1 & 5, 8
w IOS EW

50. NetFlow Features supported with Version 9
Multicast NetFlow
Availability: Major Release 12.3(1) and 12.2(18)S
Ingress Accounting of replicated multicast packets
Egress Per user accounting of multicast packets
MPLS Aware NetFlow
Availability: Release 12.0(26)S
Label and prefix export information
BGP Next Hop
Availability: Releases 12.0(26)S, 12.2(18)S, and 12.3
Edge to Edge Traffic Matrix
BGP traffic destination information
NetFlow for IPv6
Availability: Release 12.3(7)T
Export IPv6 source and destination information

51. NetFlow Product Update
Sampled NetFlow
Availability: Releases 12.0(26)S, 12.3(2)T, and 12.2(18)S
Random Sampling of packets per flow with reduce CPU
NetFlow MIB
Availability: Releases 12.3(7)T and 12.2(25)S
Top N Talker in MIB
NetFlow configuration using MIB
Input Flow Filters
Availability: Release 12.3(7)T, 12.2(25)S
QOS MQC based Filtering entering NetFlow
Egress NetFlow
Availability: Release 12.3(11)T, 12.2(Rls6)S-Q1CY05
Accounting for Egress IP Flows

52. Random Sampled NetFlow
Capacity planning may not need every packet per Flow
Sampling on high speed interfaces will reduce CPU consumption
Random (select packet to export per statistical principles)
Cisco IOS Software Releases 12.0(26)S, 12.2S(18), and 12.3(1)T
Cisco 800, 1700, 1800, 2600, 2800,3600, 3700, , and 7500 Series Routers
Random sampling Cisco Series 12.0(28)S
Cisco Series deterministic sampling today
Cisco Catalyst 6500 Series Random and Time based sampling 12.1(13)E

53. NetFlow MIB Currently available in Releases 12.3(7)T
NetFlow information available using SNMP and without NetFlow export
Administration of Netflow using the MIB interface
NetFlow MIB cannot be used to retrieve all Flow information but is very useful for security monitoring and locations where export is not possible
Example objects available:
Packet size distribution
Number of Bytes exported per second
Number of flowsNetFlow MIB with Export of Top N talkers
Top N Talkers
Top N Flows based on various NetFlow field values ( AS Number, destination, ports…)
MIB and CLI support
12.2(25)S and 12.3(11)T

54. Import Flow Mask Filters
Prevent flows from entering NetFlow cache by using Flow Filter
Increase scalability and decrease CPU usage
Filters are based on QOS MQC CLI class maps
User can use ACL to match flows from certain port or source
Define Traffic Class (match ACL) and Flow Sampling per Match
12.0(27)S, 12.3(4)T, 12.2S(25)
Traffic Filter
High Importance
Sample 1:1 from Server B
Packets
Traffic Filter
Low Importance
Sample 1:100 from Subnet A

55. Egress NetFlow Accounting
Egress and Ingress PE PE
Servers IP IP
IP or MPLS
Netflow
Ingress
Netflow
Egress
12.3(7)T, 12.2(25)S

56. Flexible NetFlow and Flexible Accounting
Flexible NetFlow and Flexible Accounting will replace most static accounting technologies available today
Flexible NetFlow user defined Flow keys and export fields within NetFlow
Flexible Accounting user defined permanent flow with periodic export and account for defined flows over time
The data can be polled thru a MIB
Flow Groups user defined buckets for specific flow fields values
Example show me packets and bytes from to on port 21

57. SCTP Reliable Transport
Flows may be sent in Reliable or unreliable or partial mode
SCTP connection to collector and multiple streams per connection
Supported with Version 9. Templates may be sent reliably
Congestion Awareness, retransmission and queuing
Send Queue
Releases 12.4(2nd)T, 12.2S(Rls7)
Data for Export in SCTP Stream
Congestion - packets marked unreliable potentially dropped
Collector

58. NetFlow Security Enhancement Releases 12.4(1st)T Q2CY05
New show commands to understand and parse NetFlow data
For Example, show flows on port X to destination Y
show ip flow top <N> <aggregate-field> <sort-criteria> <match-criteria>
show ip flow top 10 destination-address packets interface ser0 port-range 100 to 135
New Flow export fields including Source Mac, TTL, Packet length, ICMP type, and more
Also will be available in 12.2(rls7)S

59. Upcoming New Features: NetFlow Product Update
NetFlow Security Enhancements (Q2CY2005)
New exports and show commands for security monitoring
Flexible NetFlow and Accounting (Q3CY2005)
Allow user defined flow keys and aggregation with v.9
Reliable and Congestion Aware Export (Q2CY2005)
SCTP protocol NetFlow export
NBAR and NetFlow Integration (Radar)
Application flow information export

60. NetFlow Roadmap Targeting 12.2(Rls6)S 12.0(27)S Input Filter
Scalability & Flexibility
Enhancing Cisco technologies’ with Flow Accounting
Optimizing data for Flow processing
Standardization
Nov
2003
Dec
2003
Jan
2004
Feb
2004
Mar
2004
Apr
2004
May
2004
Jun
2004
Jul
2004
Aug
2004
Sep
2004
Oct
2004
Nov
2004
Dec
2004
Jan
2005
Feb
2005
Mar
2005
12.0(27)S
Input Filter
Targeting 12.3(2)T
NetFlow MIB & Top Talker
NetFlow IPv6
Targeting 12.2(Rls6)S
Egress NetFlow
Targeting 12.3(11)T
Egress NetFlow
Targeting 12.2(Rls7)S
Flexible Flow Definition
Reliable Export
Security Exports
MIB Phase 2
12.3(Rls2)T
Input Filter
Targeting 12.2(25)S
NetFlow MIB & Top Talker
Input Filter
Targeting 12.4(Rls1)T
Security Exports