Transcript Document

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!