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 (CW)
• 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 talkmoreslowly

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 Nortons The Art of Peering
• See Sun Tzus 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
AS100
AS1
AS2
AS3
14
Inter-Domain Peering Optimization

• Deployment Scenario Flow Export
• Collection on Core access links
• Sampling granularity - moderate (150100)
• 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
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 competitors customers based on load
• Source
• Sink
• Total (source sink)
• Send in the jackals

24
Customer Acquisition
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
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 gt 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
• Dont 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_at_ixiacom.com
• 734-222-5460
• Thanks for listening!