IP Traffic Management Applications Measurement, Analysis,

IP Traffic Management Applications Measurement, Analysis, and Optimization

Who We Are Josh Wepman, Ixia – Applications Engineer Andrew Lange, Exodus (C&W) – Principal Network Architect Matt Meyer, GBLX – Senior IP Traffic Engineer Joe Abley, MFN – Toolmaker/Engineer

If You Recall from Last Time A process can be defined: 1. 2. 3. 4. 5. 6. Define Goals Measure Analyze Refine Goals Action GOTO 1 Specifically addressing IDTE

Miami taught us a few things More detail on problem statements and measurement plans More real examples of problems and applied solutions Josh must talk more slowly

So what is Josh Talking About? What broader sets of applications exist for Routing and Flow data? – What are the problem statements? – What are the issues and scale of measurement in providing solutions to the problem statements?

So what is Josh Talking About? Solutions to problems must: – Solve real business problems!!! – Cut costs or drive revenue – Proposed “Solutions” must be less expensive than the “Problems” ****** – Provide relevant engineering data Problem Statement Relevant Collect what is needed, not everything you can

Applications List Inter-Domain Peering Optimization Inter-Domain Congestion Mitigation Customer Acquisition Network Policy Enforcement Intra-Domain Traffic Engineering Others (there are many )

Applications Each Application follows the same model: 1. 2. 3. 4. 5. 6. Define Goals Measure Analyze Refine Goals Action GOTO 1

Applications Focus for each application is on: Define Goals – Problem Statement Measure – Network Scenario – Deployment Scenario – Deployment Implications

Applications More collection specific technical detail can be found in Miami Tutorial slides on the NANOG website: www.nanog.org/mtg-0202/ppt/te/index.htm

Inter-Domain Peering Optimization Problem Statement – Reduce inter-domain transit costs while increasing quality of connectivity Cheaper Finer grain control (increases complexity) Closer to end consumers Clear cost savings This is NANOG – why am I preaching the value of peering For more info: – See Bill Norton’s “The Art of Peering” – See Sun Tzu’s “The Art of War”

Inter-Domain Peering Optimization Network Scenario – – – – – Hierarchical network design Core transit facilities Edge Ingress/Egress facilities Peers are not offered transit services Outbound load is of primary concern****

Inter-Domain Peering Optimization AS100 AS1 AS2 AS3 Border Router Border Router Transit Router Transit Router

Inter-Domain Peering Optimization Deployment Scenario – Flow Export – Collection on Core “access” links – Sampling granularity - moderate (1:50 100) Can depend on link speed – platform – Real link characteristics extrapolated based on “valid sampling data” Sampling for a longer period of time will not validate invalid sampled data – Scale is moderate – one collection host per region or set of border routers

Inter-Domain Peering Optimization Deployment Scenario – BGP – For OUTBOUND load only IBGP to edge box required – For problem statements with edge links Route-reflection is required from either edge box or existing route-reflection servers (core boxes) – Goal is to communicate BGP routes that correlate to traffic flows DST IP needs to find a match in BGP in order to generate useful data

Inter-Domain Peering Optimization AS100 AS1 Flow AS2 AS3 Border Router Border Router Transit Router Transit Router BGP Collector

Inter-Domain Peering Optimization Deployment Implications – Collection Nodes: Low/Moderate – Disk Usage: Low Metrics include: – – – – Time (how long do you keep the data?) Interfaces (generally linear multiplier) Flow diversity (hard question to answer) Flow-export version – CPU: Low Metrics include: – – – – Interfaces (n x streams of flow data) Flow diversity (hard question to answer) BGP model (route-reflection scaling issues) Flow-export version (5 vs. 8)

Paths to the Source (****) Deployment Scenario – Paths to the source – Mapping routing data to destination IP addresses has a very strong correlation to the forwarding path – Mapping routing data to the source IP address has a very weak correlation to the forwarding path – Origins and Peers can sometimes be known, the middle mile to the source is much harder There is no way to state with reasonable confidence that the path announced to you for the source was followed to you (policy is complicated and not passed inter-domain)

Inter-Domain Congestion Mitigation Problem Statement – Save money by identifying and eliciting control over discrete traffic segments that are causing congestion Congestion is “usually” bad Can cost providers money Finding the right size “fix” in order to consistently and persistently address problem Higher quality service Lower operational costs

Inter-Domain Congestion Mitigation Network and Deployment Scenarios – Very similar to Peering Optimization – Time domain much shorter Days and hours as opposed to months – Goal is MUCH more specific Offload at link (neighbor) level instead of abstracted domain Requires retention of more detail to answer more specific questions

Inter-Domain Congestion Mitigation Deployment Implications – Collection Nodes: Low – Disk Usage: Moderate Metrics include: – Time (Added detail for more discrete time frames) – Flow diversity – Data Types (as, net, proto) – CPU: Low Metrics include: – – – – Interfaces Flow diversity BGP model Flow-export Version

Customer Acquisition Problem Statement – Increase revenues by identifying and targeting potential customers based on current traffic trends Publicly unpopular, privately VERY popular Is anyone not in need of more consumers in order to offset generally static network costs? Find your competitors customers and target the ones that use your bandwidth already Increase revenue and potentially decrease peering traffic

Customer Acquisition Network Scenario – Applies to most any network model – Works well in the same hierarchical model – Collection inbound on peer links users want to target for customer acquisition – Abstraction of “N” links to see big picture – Order competitor’s customers based on load: Source Sink Total (source sink) – Send in the jackals

Customer Acquisition AS100 AS1 AS2 AS3 Border Router Border Router Transit Router Transit Router

Customer Acquisition Deployment Scenario – Flow – Collection inbound on peering links – Sampling granularity can be generally coarse – Same data normalization procedure as Peering Optimization

Customer Acquisition Deployment Scenario – BGP – Requires BGP Route-reflection from exporter or representative router Could collect route data from the same router that reflects routes to edge peering router – The routes available to the BGP collector must represent the flows that are being tracked Otherwise “bucket 0” gets very big!

Customer Acquisition AS100 AS1 Flow AS2 AS3 Border Router Border Router Transit Router Transit Router BGP Collector

Customer Acquisition Deployment Implications – Collection Nodes: Low/Moderate – Disk Usage: Moderate Metrics include: – – – – Time Interfaces (larger set) Flow diversity Traffic types – CPU: Moderate Metrics include: – Interfaces (larger set than core links) – Flow diversity – BGP model – N x route reflection N x IBGP

Network Policy Enforcement Problem Statement – Reduce operations costs and outage times by identifying routing and flow issues proactively Catch little problems before they become BIG Catch problems the FIRST time, not the Nth

Network Policy Enforcement Problem Statement (details) Identify traffic that should not be there – Peers dumping traffic on you – Are your “mostly intra-Europe customers” actually sending most of their traffic to the US over those expensive STM-16s? Identify routes that violate BGP policy – Peer A propagating routes from Peer B – Default route from the wrong (any) place

Network Policy Enforcement Network Scenario – – – – Large scale IBGP deployment Complex network policy Multiple exit points for routes Transit and non-transit relationships

Network Policy Enforcement Deployment Scenario - BGP – Full-mesh IBGP collection Allows evaluation of all installed routes in core – Ideally, all core candidate routes could be evaluated in order to catch “snakes in the grass” Some IETF work being done to help: draft-walton-bgp-add-paths-00.txt draft-jabley-bgp-measurement-00.txt – Evaluate every route transaction in real time to evaluate “goodness” – Requires general concept of what is and is not valid in local BGP implementation (policy definition)

Network Policy Enforcement Deployment Scenario – Flow Export – Collect flow data at network ingresses – Should interface X, send traffic flow Y – Are peers sending traffic for routes you did not announce? – Sampling granularity can often be very low – Question tend to be binary (YES/NO) as opposed to quantified (how much) – V5 preferable here for many things

Network Policy Enforcement Deployment Implications (large scale) – Collection Nodes: Moderate/High – Disk Usage: High Metrics include: – – – – Flow Version (trade off in resources) Interfaces nodes Traffic types (raw) – CPU: High Metrics include: – Large number interfaces – Large amount of raw flows – Large amount of processing of flows and BGP events

Intra-Domain Traffic Engineering Problem Statement – Maximize traffic mapping onto existing internal capacity without using all sorts of “expensive” MPLS technology Can obviate costly technology migrations Able to address many offered load concerns MPLS is good too, This is not a replacement, simply an alternative in many scenarios – With only three hours, we cannot possibly have an MPLS debate

Intra-Domain Traffic Engineering Network Scenario – Some arbitrary set of IGP links – BGP selects exit point of network – Derive traffic load per BgpNextHop in order to derive inter-node and inter-pop traffic demands over time – Works in most any conventional network paradigm where IGPs carry intra-domain traffic to BgpNextHop exit point

Intra-Domain Traffic Engineering Deployment Scenario - Flow Export – Collect flow data from edge ingress links of substance Don’t sweat the small stuff Can be done at edge/core aggregation point to reduce #links in a hierarchical network environment – Sampling rate can be moderate This is not billing, this is longish term capacity planning Same concepts apply to normalization

Intra-Domain Traffic Engineering Deployment Scenario - BGP – Route-reflection is required similar to customer acquisition scheme – Traffic mapped onto backbone generally relies on routes propagated from IBGP peers. In order for collectors to see the IBGP installed routes, route-reflection is your friend

Intra-Domain Traffic Engineering Deployment Implications (large scale) – Collection Nodes: High – Disk Usage: Moderate Tabular data reduces disk needs No raw data required Disk usage balloons in proportion to #links Aggregate edges where possible – CPU: Moderate Long term trending reduces “real-time” load Route-reflection does not scale as well as IBGP

Other Applications Usage Based Billing Billing Verification DDOS Security Per Service Network Design

Things it does not do Print Money Correct Accounting Practices Speak in the HAL-9000 voice Make a decent omelet

Summary There are a host of applications that can solve business relevant problems by collecting and analyzing routing and flow data Most work on standard network designs Disk and CPU loads very significantly based on scale, application, and problem statement

More Information Josh Wepman – Ixia NetOps – [email protected] – 734-222-5460 Thanks for listening!