IP Traffic Management Applications

1. IP Traffic Management Applications Measurement, Analysis, and Optimization

2. 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

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

4. 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…

5. 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?

6. 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…

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

8. Applications • Each Application follows the same model: • Define Goals • Measure • Analyze • Refine Goals • Action • GOTO 1

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

10. 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

11. 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”

12. 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****

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

14. 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

15. 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

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

17. 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)

18. 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)

19. 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

20. 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

21. 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

22. 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

23. 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…

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

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

26. 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!

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

28. 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

29. 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

30. 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

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

32. 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)

33. 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

34. 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

35. 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…

36. 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

37. 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

38. 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

39. 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

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

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

42. 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

43. More Information • Josh Wepman • Ixia NetOps • Jaw@ixiacom.com • 734-222-5460 • Thanks for listening!