Presentation on theme: "CISCO IOS IP SERVICE LEVEL AGREEMENTS: TECHNICAL OVERVIEW"— Presentation transcript:
1CISCO IOS IP SERVICE LEVEL AGREEMENTS: TECHNICAL OVERVIEW TOM ZINGALEINTERNET TECHNOLOGIES DIVISIONSEPTEMBER 2004This presentation introduces Cisco IP Service Level Agreement (IP SLA), previously called Cisco Service Assurance Agent (SAA) in Cisco IOS Software.
2Cisco IOS IP Service Level Agreement: A New Direction Cisco solution that assures IP service levels, proactively verifies network operation, and accurately measures network performanceComprehensive hardware supportCommitted Cisco partner supportCisco IOS Software, the world’s leading network infrastructure softwareEnterprise and Small Medium BusinessService ProvidersUnderstand NetworkPerformance &Ease DeploymentVerify Service LevelsVerify Outsourced SLAsMeasure and provideSLAsToday, 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.AccessEnterprise BackboneEnterprise Premise EdgeService Provider Aggregation EdgeService Provider CoreCisco IOS Software
3The Need for IP-Based Service Levels PROBLEMRESULT40% of companies delay launching new applications due to network performance concerns2Reduced business productivity59% of companies simply add bandwidth to ensure application efficiency2Increased network costs55% of companies only identify some of their network traffic2Reduced understanding of network behaviorCost of application downtime and degradation is $13,000 per minute for an ERP application3Lowered network performance can be costlyInfonetics Research Study “Cost of Enterprise Downtime”Network World Application Performance Market Study3 Forrester Research
4Cisco IOS IP SLA Benefits OPTIMIZED APPLICATIONS & SERVICESREDUCED TOTAL COST OF OWNERSHIP AND OpExPerformance visibilityProve service levelsEnhance Customer satisfactionEnhance acceptance of business- critical servicesReduce deployment timeLower mean time to restore and downtimeProactive identification of issues enforces higher reliabilityMeasurements and MetricsProactiveAutomated IntelligenceContinuousPredictable ReliableToday, 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.
5Cisco IOS IP SLAs Life Cycle Understand network performance baseline Confidence to deploynew IP servicesand applicationsBaseline networkperformance Verify network readiness for new services with Cisco IOS IP SLA capabilities.Assure applicationand service deployment21Quantify resultsReduce deployment timeProve service and application differentiationVerify service levelsReduce network down timeManage demand for the networkFine tune and optimizeOngoing measurements to understand behaviorwith proactive notification34
6Example: Multi-Protocol Measurement and Management with Cisco IOS IP SLAs ApplicationsAvailabilityNetworkPerformanceMonitoringVoIPMonitoringService LevelAgreement(SLA)MonitoringNetworkAssessmentMultiprotocolLabelSwitching(MPLS)MonitoringTroubleShootingMeasurement MetricsLatencyPacketLossNetworkJitterDist. ofStatsConnectivityProtocolsJitterFTPDNSDHCPDLSWICMPUDPTCPHTTPLDPH.323SIPRTPRadiusVideoDefined Packet Size, SpacingCOS and ProtocolIP ServerIP SLACisco IOSSoftwareIP ServerSourceMIB DataActive Generated Traffic to measure the networkDestinationIP SLACisco IOSSoftwareIP SLACisco IOSSoftwareResponder
8SLA Verification and Management Access router may be managed or unmanagedData typically provided by the service provider for the customer includes availability, QoS, and Jitter SLAsService Provider needs visibility in the Customer Edge, in order to commit to SLAsEnterprise will verify SP SLAs by using access router edge to edge measurementsEnterprise may provide restricted Simple Network Management Protocol (SNMP) (RTT, Latency, QoS) visibility into Access router for Service ProviderService Provider with restricted access can report SLA as a service back to the enterprise
9Network 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 frequenciesUni-directional and highly accurate measurementsMeasurements per class of service to validate service differentiation for data, voice, and videoCisco IOS IP SLA will identify an edge to edge network performance baseline and allow the user to understand trends and anomalies from the baseline
10IP Network ReadinessNetwork assessment tool built into Cisco IOS SoftwareSimulate IP Services and verify how well they will work in the networkHow well is QoS working in the network pre-deploymentPost deployment continued verification of network performance per IP service
11Availability Monitoring Cisco IOS IP SLA uses proactive monitoring for periodic, reliable, and continuous availability measurementsConnectivity measurements from Cisco router to router or Cisco router to serverThreshold notifications when end point is not availableWhat 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 connectivityIf server is unavailable, then traps can notify the network management system
12Troubleshooting with Cisco IOS IP SLA Proactive notification of problems and issues based on threshold alertsTesting edge to edge consistently and reliability will save time in finding and pin pointing network performance problem areasSecondary activation of path operation (ie: path jitter) or activation of operations at a higher frequency to isolate and verify problem areas in the network
13Cisco IOS IP SLA Source and Responder Source RouterCisco IOS Software router that sends data from operationCisco IOS Software may or may not be the targetSome operations require the target to run the IP SLA responderStores results in MIBResponderResponds to IP SLA packets at destinationUser defined UDP/TCP portsIP SLA Control ProtocolMD 5 AuthenticationAccurate measurements
14The Responder takes 2 Timestamps (T2 & T3) Source RouterTarget RouterResponderT2T1T3T4D = T3 - T2The 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 CalculationSource Router IP SLA processing delay =T5-T4Responder processing delay = T3-T2RTT 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 processWhen 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 accurateResponder allows for one-way measurements for latency, jitter, packet loss, and MOS
15Cisco IOS IP SLAs Uses and Metrics *DATATRAFFIC*VoIP*SERVICE LEVEL AGREEMENT*AVAILABILITY**STREAMINGVIDEOREQUIREMENTMinimize Delay, Packet LossVerify Quality of Service (QoS)Minimize Delay, Packet Loss, JitterMeasure Delay, Packet Loss, JitterOne-wayConnectivity testingMinimize Delay, Packet LossIP SLA MEASURMENTJitterPacket lossLatencyper QoSMOS Voice Quality ScoreEnhanced accuracyNTPConnectivity tests to IP devicesCisco 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
17UDP Jitter One Way Latency AvailabilityX12.2(11)T (Infra2)12.2(14)S12.1ESNMP Support12.2(2)TAPMICMP Path JitterFrame-Relay (CLI)MPLS/VPN AwareFTP GetUDP Jitter One Way LatencyDLSw+DHCPDNSHTTPUDP JitterTCP ConnectUDP EchoSSCP(SNA)ICMP Echo PathICMP Echo12.2(25)S12.1(1)T 12.212.0(5)T 12.0(8)S12.0(3)T11.2Feature/Release
18Cisco IOS IP SLA Partners Cisco Network Management SolutionCisco IP Solution CenterMPLS VPN and SLA MonitoringInternetworking Performance MonitorEnterprise performance measurementsTHIRD PARTY PRODUCTSCisco partners, including HP and Concord Communications, have integrated IP SLA functions and metrics into their popular network performance tools.
19Cisco IOS IP SLA Performance with Infrastructure 2: CPU Load by Hardware Jitter probeVersus Release 12.3(3)2,000 active probesOperations/ SecondOperations/ MinuteCisco 2600 SeriesCisco 2620XM SeriesCisco 3640 SeriesCisco 3725 RouterCisco 7200VXR NPE225424014762848020931272029131696035151712004119222414404825281680562732192063313621606740240034384426404328804247552312046491033601160360058*Jitter operations are activated sequentially with this testing. Each operation sends 10 packets, 64 bytes each with 20ms spacing
20Cisco IOS IP SLA Performance Infrastructure 2: CPU Load by Hardware Jitter probeRelease 12.3(4)T6IP Plus/Firewall/3DES2,000 active probesOperations per secondOperations per minuteCisco 831 RouterCisco 837 RouterCisco Router424071038480131612720239602930172012003334222414403536272816804132192047462160525040240057563944264062434828806665312072685333607671596036008175
21Cisco IOS IP SLA VoIP Measurements Q1CY’05 Data CenterGatekeeperRegistrationDelayCall ManagerClusterDiscoveryDelayPost Dial DelayH323 or SIPHeadquartersResponderSeattleSales OfficeLASales OfficeSan JoseSales OfficeNew YorkSales OfficeBostonSales OfficeClevelandDetroit
22Digital Signal Processor Based IP SLA Measurements (Q3CY’05) VoIP Active (test call) measurements using Real-time Transport Protocol (RTP) streamsVoice quality scores and voice metrics from the Digital Signal Processor (DSP)Call ControlVoIP MetricsRTPIP SLADSPIP ServerResponderRTP IP SLACisco IOS IP SLA RTP Operation Data
23New IOS IP SLA CLIThe new IOS IP SLA CLI releases Q1CY05 in 12.3(RLS6)TPhase 1 changes include new syntax for commands and new show commandsNew 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 commandsThe RTR keyword was changed to IP SLA Monitor in CLIThe new syntax is used in the presentation. The old syntax before 12.3(pi6)T is shown in the AppendixThis was intentional. They can use the old feature sets for 12.3 to getaround the problem. IP SLA is a value-add feature that was historically free touse but this has changed. IP SLA is available in VoIP and above. IP Base issupposed to be a minimum memory foot print package and features wereremoved.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 CLIRouter (config)#rtr 1Router (config-rtr)#type echo protocol ipIcmpEchoRouter (config)#rtr schedule 1 start-time nowNew CLIRouter (config)#ip sla monitor 1Router (config-sla-monitor)#icmp-echoRouter (config)#ip sla monitor schedule 1 start-time now
24New Cisco IOS IP SLA Show Commands Q1CY’05 Jitter operation “show ip sla monitor statistics (details)”Router#sh ip sla monitor statistics 15Round trip time (RTT) Index 15Latest RTT: 1 msLatest operation start time: *05:43: UTC Fri MayLatest operation return code: OK RTT ValuesNumber Of RTT: 10RTT Min/Avg/Max: 1/1/1 msLatency one-way time millisecondsNumber of one-way Samples: 0Source to Destination one way Latency Min/Avg/Max: 0/0/0 msDesination to source one way Latency Min/Avg/Max: 0/0/0 msJitter time millisecondsNumber of Jitter Samples: 9Source to Destination Jitter Min/Avg/Max: 20/20/23 msDestination to Source Jitter Min/Avg/Max: 0/0/0 msPacket Loss ValuesLoss Source to Destination: Loss Destination to Source: 0Out Of Sequence: Tail Drop: 0 Packet Late Arrival: 0Number of successes: 1Number of failures: 0Operation time to live: 3567 secThe 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 details2nd 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 1type jitterdestination , ,destination-port 4000number-packets 1packet-interval 20threshold 4000timeoutrequest-data-sizeownertos blahvrf blah&ip sla map scheduler 1schedule-period 100frequency 100schedule-type randomfrequency-range 5,10start timeip sla map reaction-configuration 1react timeoutthreshold type immediateaction-type trapWe 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 theIp sla 1Type blahWe could haveIp sla monitor 1destinationI will have a few more s unrelated to this thread on CLI changes. I hope you can participate.
25New Cisco IOS IP SLA Show Commands Q1CY’05 Jitter operation “show ip sla monitor statistics details”Round trip time (RTT) Index 2004Latest RTT: 1 msLatest operation start time: *08:41: PST Wed OctLatest operation return code: OKOver thresholds occurred: FALSERTT ValuesNumber Of RTT: 10RTT Min/Avg/Max: 1/1/1 msLatency one-way time:Number of Latency one-way Samples: 0Source to Destination Latency one way Min/Avg/Max: 0/0/0 msDestination to Source Latency one way Min/Avg/Max: 0/0/0 msSource to Destination Latency one way Sum/Sum2: 0/0Destination to Source Latency one way Sum/Sum2: 0/0Jitter time:Number of Jitter Samples: 9Source to Destination Jitter Min/Avg/Max: 0/0/0 msDestination to Source Jitter Min/Avg/Max: 0/0/0 msSource to destination positive jitter Min/Avg/Max: 0/0/0 msSource to destination positive jitter Number/Sum/Sum2: 0/0/0Source to destination negative jitter Min/Avg/Max: 0/0/0 msSource to destination negative jitter Number/Sum/Sum2: 0/0/0Destination to Source positive jitter Min/Avg/Max: 0/0/0 msDestination to Source positive jitter Number/Sum/Sum2: 0/0/0Destination to Source negative jitter Min/Avg/Max: 0/0/0 msDestination to Source negative jitter Number/Sum/Sum2: 0/0/0Interarrival jitterout: Interarrival jitterin: 0The 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 details2nd 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 1type jitterdestination , ,destination-port 4000number-packets 1packet-interval 20threshold 4000timeoutrequest-data-sizeownertos blahvrf blah&ip sla map scheduler 1schedule-period 100frequency 100schedule-type randomfrequency-range 5,10start timeip sla map reaction-configuration 1react timeoutthreshold type immediateaction-type trapWe 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 theIp sla 1Type blahWe could haveIp sla monitor 1destinationI will have a few more s unrelated to this thread on CLI changes. I hope you can participate.
26Cisco IOS IP SLA Multiple Operations Scheduling (Release 12.3(8)T) Schedule multiple operations in one commandScalable and sequential activation of IP SLA operationsIf the frequency is not specified, the default frequency will be the same as that of the schedule period)Reduced load on the networkConsistent monitoring coverageRouter (config)#ip sla monitor 1Router (config-sla-monitor)#type echo protocol ipIcmpEchoRouter (config)# ip sla monitor 2Router (config-sla-monitor)#type echo protocol ipIcmpEchoRouter (config)# ip sla monitor 3Router (config-sla-monitor)#type echo protocol ipIcmpEchoRouter (config)# ip sla monitor group schedule sch 20 start nowRouter #show ip sla monitor group schedule
27Cisco IOS IP SLA Random Scheduler Enhancement Release 12.4(Rls1)T will introduce the following functionality:Randomness for group scheduler during schedule periodRandomness for the frequency of the operations, which are started by random group schedulerBased 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 schedulerAs 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
28Cisco IOS IP SLA Accuracy Feature High performance and high accuracy measurementsPrecision to .1 ms from current 1msImprove Cisco IOS IP SLA accuracy under forwarding load and for dedicated routersRelease 12.3(RLS6)T will introduce this functionality in Q1CY’05
29Cisco IOS IP Service Level Agreement Roadmap FeatureReleaseTarget DateRelease 12.3T FeaturesMOS and ICPIF Scores12.3(4)TNovember 2003One way latency, jitter, packet loss and MOS Traps12.3(7)TMarch 2003Multi-Operation Scheduler – Ease of scheduling12.3(8)TJune 2003Post Dial and Gatekeeper Delays with SIP and H32312.3(pi-6)TQ1CY’05High accuracy enhancementEase of use CLIRelease 12.4T FeaturesEase of use CLI Phase 212.4(pi-1)TQ2CY’05Random scheduler for operationsVoice gateway integration VoIP measurement using DSP12.4(pi-2)TQ3CY’05Ease of use CLI Phase 3Video operationRadius response operationRelease 12.2S FeaturesIP SLA: Auto MPLS VPN Monitoring12.2(Rls6)SIP SLA: Auto MPLS VPN Monitoring with ECMP12.2(Rls7)SIP SLA: Auto MPLS Monitoring with VCCV12.2(Rls8)SRadarIP SLA: Auto MPLS Monitoring with BFDIP SLA MulticastAuto IP SLA MonitoringIP SLA with DMVPNICMP JitterIP SLA High AvailabilityEmbedded Event Manager (EEM) DetectorCisco partners, including HP and Concord Communications, have integrated IP SLA functions and metrics into their popular network performance tools.
30NetFlow Virtual private networks are a growing IP application. IP SLA can monitor the connectivity of MPLS VPNs for one or more classes of service.
32Non-Aggregated Flows—Export Version 5 or 9 NetFlow Cache ExampleCreate and update flows in NetFlow cacheSrclfSrclPaddDstlfDstlPaddProtocolTOSFlgsPktsSrc PortSrc MskSrc ASDst PortDstMskDst ASNextHopBytes/PktActiveIdleFa1/0Fa0/01180101100000A2/245151528174546402491/2619674041.511000000A118014281145.53221019/30104024.514Inactive 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 FlagExpirationSrclfSrclPaddDstlfDstlPaddProtocolTOSFlgsPktsSrc PortSrc MskSrc ASDst PortDstMskDst ASNextHopBytes/PktActiveIdleFa1/0Fa0/01180101100000A2/24515152818004AggregationNoYese.g. Protocol-Port Aggregation Scheme BecomesExport versionNon-Aggregated Flows—Export Version 5 or 9ProtocolPktsSrcPortDstPortBytes/Pkt111100000A21528ExportPacketPayload(Flows)Transport protocolHeaderAggregated Flows—Export Version 8 or 9
33Principle Netflow Benefits Service ProviderEnterprisePeering arrangementsNetwork PlanningTraffic EngineeringAccounting and billingSecurity MonitoringInternet access monitoring (protocol distribution, where traffic is going/coming)User MonitoringApplication MonitoringCharge Back billing for departmentsSecurity Monitoring
34Tracking 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?
35NetFlow for Security: Flow Information Helps Mitigate Attacks Identify the attackCount the FlowsInactive flows signal a worm attackClassify the attackSmall size flows to same destinationWhat is being attacked and origination of attackKey Partners: Arbor Networks, Protego, NetQos, Adlex
36Capacity PlanningCapacity planning is the process of determining the network resources required to prevent a performance or availability impact on business-critical applicationsKey areas to monitorApplication usageIdentify which applications consume bandwidthWho are the top ten nodes that consume bandwidthOutput data circuit forecastsCurrent network utilization and capacity being used
37Billing IP Accounting and Billing Usage-based billing considerations Time of dayWithin or outside of the networkApplicationDistance-basedQuality of Service (QoS) / Class of Service (CoS)Bandwidth usageTransit or peerData transferredTraffic class
38How Cisco IT uses NetFlow Characterize IP traffic and account for how and where it flowsTotal Avoidance of SQL Slammer WormTransition from Managed DSL service to Internet VPNDetection of Unauthorized WAN TrafficReduction in Peak WAN TrafficValidation of QoS Parameters and BW allocationAnalysis of VPN Traffic and Tele-Commuter BehaviorCalculating Total Cost of Ownership for ApplicationsUse of NetFlowNMS and UsageSecurity MonitoringNetwork traffic analysis by application with BGP. Anomaly detection Arbor NetworksWAN Aggregation and EdgeNetwork traffic analysis by application, for capacity planning using NetQOSCore routers and Nat GatewayCollection of historical data, useful for forensics and diagnostics with Flow Tools
40NetFlow Versions NetFlow Version Comments 1 Original 5 Standard and most common7Specific to Cisco Catalyst 6500 and 7600 Series SwitchesSimilar to Version 5, but does not include AS, interface, TCP Flag & TOS information8Choice of eleven aggregation schemesReduces resource usage9Flexible, extensible file export format to enable easier support of additional fields & technologies; coming out now MPLS, Multicast, & BGP Next HopCisco Catalyst 6500 Series Router will supportversions 5 & 8 in Cisco IOS Software Release 12.1(13)E
41Version 5 - Flow Export Format Packet CountByte CountSource IP AddressDestination IP AddressSource IP AddressDestination IP AddressUsageFrom/ToStart sysUpTimeEnd sysUpTimeTimeof DaySource TCP/UDP PortDestination TCP/UDP PortApplicationPortUtilizationInput ifIndexOutput ifIndexNext Hop AddressSource AS NumberDest. AS NumberSource Prefix MaskDest. Prefix MaskRouting andPeeringType of ServiceTCP FlagsProtocolQoSVersion 5 used extensively todayFlow information
42Why a New Version 9?Fixed export formats are not flexible and adaptableWith each new version Cisco creates new export fieldsPartners need to re-engineer for each new versionSolution: Build a flexible and extensible export format called version 9!
43NetFlow v9 Export Packet To support technologies such asMPLS or Multicast, this export format canbe leveraged to easily insert new fieldsFlows fromInterface AFlows fromInterface BTemplate FlowSetData FlowSetData FlowSetOptionTemplateFlowSetOption DataFlowSetFlowSet IDFlowSet ID #1FlowSet ID #2Template RecordTemplate ID #1(specific Fieldtypes and lengths)Template RecordTemplate ID #2(specific Fieldtypes and lengths)(version,# packets,sequence #,Source ID)Data Record(Field values)Data Record(Field values)Template ID(specificField typesand lengths)OptionDataRecord(Field values)OptionDataRecord(Field values)Data Record(Field values)Matching ID numbers are the way to associate template to the Data RecordsThe Header follows the same format as prior NetFlow versions so Collectors will be backward compatibleEach data record represents one flowIf exported flows have the same fields, then they can be contained in the same Template Record (ie: unicast traffic) can be combined with multicast recordsIf 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)
44NetFlow v9 and IETFInternet Protocol Flow Information eXport (IPFIX) is an IETF Working GroupNetflow version 9 is the basis for the standard in the IETFStandards Track NetFlow version 9New
45IETF: 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 PSAMPTo be improved: the variable length data typeNote: NetFlow is already using some sampling mechanismsNewAlso at
46NetFlow PartnersTraffic AnalysisFlow-ToolsDenial of ServiceBilling
47Cisco Catalyst 6500 Series Switch and Cisco 7600 Series Router Hybrid: Cisco Catalyst OS on PFC/supervisor and Cisco IOS software on MSFCNative Cisco IOS Software: PFC/supervisor and the MSFC both run a single bundled Cisco IOS software imageExport is centrally via the supervisor and MSFC, each linecard has its own hardware NetFlow cache and forwarding table, i.e. distributed platformHybridNative 12.1ENative 12.2SXMSFCxv5v5, v8*Sup1aV7, v8v7N/ASup2v5, v7v5, v7, v8Sup720*No NetFlow Support on MSFC with Sup1a
48Cisco Catalyst 6500 and Cisco 7600 Series Versions and Features Cisco IOS Software Release 12.1(13)E1PFC2 Source/destination interface information (Hybrid 6.3(6))PFC2 Source/destination AS informationPFC2 Support for V5 NetFlow data export (Hybrid 7.5(1))IP Next hopSampled NetFlow is available on PFC in Cisco IOSCisco IOS Software Release 12.2(14)SXVersion 8 in native modePFC3b (Sup720) cardsToS byteHybrid 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
49Cisco Catalyst 4000 Supervisor IV NetFlow Services Card NetFlow Service Card FeaturesNetFlow Statistics Collection and Data Export (NDE)VLAN Statistics CollectionCLI support for NetFlow & VLAN StatsSNMP support for VLAN StatsRequirements:Supervisor IV or VIOS 12.1(13)EWNetFlow Versions 1 & 5, 8w IOS EW
50NetFlow Features supported with Version 9 Multicast NetFlowAvailability: Major Release 12.3(1) and 12.2(18)SIngress Accounting of replicated multicast packetsEgress Per user accounting of multicast packetsMPLS Aware NetFlowAvailability: Release 12.0(26)SLabel and prefix export informationBGP Next HopAvailability: Releases 12.0(26)S, 12.2(18)S, and 12.3Edge to Edge Traffic MatrixBGP traffic destination informationNetFlow for IPv6Availability: Release 12.3(7)TExport IPv6 source and destination information
51NetFlow Product Update Sampled NetFlowAvailability: Releases 12.0(26)S, 12.3(2)T, and 12.2(18)SRandom Sampling of packets per flow with reduce CPUNetFlow MIBAvailability: Releases 12.3(7)T and 12.2(25)STop N Talker in MIBNetFlow configuration using MIBInput Flow FiltersAvailability: Release 12.3(7)T, 12.2(25)SQOS MQC based Filtering entering NetFlowEgress NetFlowAvailability: Release 12.3(11)T, 12.2(Rls6)S-Q1CY05Accounting for Egress IP Flows
52Random Sampled NetFlow Capacity planning may not need every packet per FlowSampling on high speed interfaces will reduce CPU consumptionRandom (select packet to export per statistical principles)Cisco IOS Software Releases 12.0(26)S, 12.2S(18), and 12.3(1)TCisco 800, 1700, 1800, 2600, 2800,3600, 3700, , and 7500 Series RoutersRandom sampling Cisco Series 12.0(28)SCisco Series deterministic sampling todayCisco Catalyst 6500 Series Random and Time based sampling 12.1(13)E
53NetFlow MIB Currently available in Releases 12.3(7)T NetFlow information available using SNMP and without NetFlow exportAdministration of Netflow using the MIB interfaceNetFlow MIB cannot be used to retrieve all Flow information but is very useful for security monitoring and locations where export is not possibleExample objects available:Packet size distributionNumber of Bytes exported per secondNumber of flowsNetFlow MIB with Export of Top N talkersTop N TalkersTop N Flows based on various NetFlow field values ( AS Number, destination, ports…)MIB and CLI support12.2(25)S and 12.3(11)T
54Import Flow Mask Filters Prevent flows from entering NetFlow cache by using Flow FilterIncrease scalability and decrease CPU usageFilters are based on QOS MQC CLI class mapsUser can use ACL to match flows from certain port or sourceDefine Traffic Class (match ACL) and Flow Sampling per Match12.0(27)S, 12.3(4)T, 12.2S(25)Traffic FilterHigh ImportanceSample 1:1 from Server BPacketsTraffic FilterLow ImportanceSample 1:100 from Subnet A
55Egress NetFlow Accounting Egress and IngressPEPEServersIPIPIP or MPLSNetflowIngressNetflowEgress12.3(7)T, 12.2(25)S
56Flexible NetFlow and Flexible Accounting Flexible NetFlow and Flexible Accounting will replace most static accounting technologies available todayFlexible NetFlow user defined Flow keys and export fields within NetFlowFlexible Accounting user defined permanent flow with periodic export and account for defined flows over timeThe data can be polled thru a MIBFlow Groups user defined buckets for specific flow fields valuesExample show me packets and bytes from to on port 21
57SCTP Reliable Transport Flows may be sent in Reliable or unreliable or partial modeSCTP connection to collector and multiple streams per connectionSupported with Version 9. Templates may be sent reliablyCongestion Awareness, retransmission and queuingSend QueueReleases 12.4(2nd)T, 12.2S(Rls7)Data for Export in SCTP StreamCongestion - packets marked unreliable potentially droppedCollector
58NetFlow Security Enhancement Releases 12.4(1st)T Q2CY05 New show commands to understand and parse NetFlow dataFor Example, show flows on port X to destination Yshow ip flow top <N> <aggregate-field> <sort-criteria> <match-criteria>show ip flow top 10 destination-address packets interface ser0 port-range 100 to 135New Flow export fields including Source Mac, TTL, Packet length, ICMP type, and moreAlso will be available in 12.2(rls7)S
59Upcoming New Features: NetFlow Product Update NetFlow Security Enhancements (Q2CY2005)New exports and show commands for security monitoringFlexible NetFlow and Accounting (Q3CY2005)Allow user defined flow keys and aggregation with v.9Reliable and Congestion Aware Export (Q2CY2005)SCTP protocol NetFlow exportNBAR and NetFlow Integration (Radar)Application flow information export
60NetFlow Roadmap Targeting 12.2(Rls6)S 12.0(27)S Input Filter Scalability & FlexibilityEnhancing Cisco technologies’ with Flow AccountingOptimizing data for Flow processingStandardizationNov2003Dec2003Jan2004Feb2004Mar2004Apr2004May2004Jun2004Jul2004Aug2004Sep2004Oct2004Nov2004Dec2004Jan2005Feb2005Mar200512.0(27)SInput FilterTargeting 12.3(2)TNetFlow MIB & Top TalkerNetFlow IPv6Targeting 12.2(Rls6)SEgress NetFlowTargeting 12.3(11)TEgress NetFlowTargeting 12.2(Rls7)SFlexible Flow DefinitionReliable ExportSecurity ExportsMIB Phase 212.3(Rls2)TInput FilterTargeting 12.2(25)SNetFlow MIB & Top TalkerInput FilterTargeting 12.4(Rls1)TSecurity Exports