1 - Pmacct

More documents

Recommendations

Info

The BGP peer who came from NetFlow (and sFlow) – pmacct introduces a Quagga-based BGP daemon •Implemented as a parallel thread within the collector •Maintains per-peer BGP RIBs – Why BGP at the collector? •Telemetry reports on forwarding-plane •Telemetry should not move control-plane information over and over – Basic idea: join routing and telemetry data: •Telemetry agent address == BGP source address/RID © 2010 Cisco Systems, Inc./Cariden Technologies, Inc.. 26
Telemetry export models for capacity planning and TE – PE routers: ingress-only at edge interfaces + BGP: •Traffic matrix for end-to-end view of traffic patterns •Borders (customers, peers and transits) profiling •Coupled with IGP information to simulate and plan failures (strategic solution) – P, PE routers: ingress-only at core interfaces: •Traffic matrices for local view of traffic patterns •No routing information required •Tactical solution (the problem has already occurred) © 2010 Cisco Systems, Inc./Cariden Technologies, Inc.. 27
Page 1 and 2: Best Practices in Network Planning
Page 3 and 4: Introduction & Objective © 2010 Ci
Page 5 and 6: Basic Capacity Planning • Input
Page 7 and 8: Routing Policy - Primary Paths •
Page 9 and 10: QoS policy per-link • Very simple
Page 11 and 12: Over-Provision Factor - Research
Page 13 and 14: Traffic Matrix © 2010 Cisco System
Page 15 and 16: Internal Traffic Matrix • POP to
Page 17 and 18: Internal Traffic Matrix Collection
Page 19 and 20: Demand Estimation • Goal: Derive
Page 21 and 22: Estimation Paradox Explained OAK SJ
Page 23 and 24: Regressed Measurements • Interfac
Page 25: pmacct is open-source, free, GPL’
Page 29 and 30: P, PE routers: telemetry ingress-on
Page 31 and 32: Scalability: aggregation and tempor
Page 33 and 34: Still on scalability - A single col
Page 35 and 36: Further information - http://www.pm
Page 37 and 38: Comprehensive Traffic Management Of
Page 39 and 40: N:1 Savings versus versus • 1:1 P
Page 41 and 42: Planning Methodologies • Monitori
Page 43 and 44: Topology What-If Analysis Scenario:
Page 45 and 46: Optimization/ Traffic Engineering
Page 47 and 48: Network Optimization: Questions •
Page 49 and 50: IP Traffic Engineering: The objecti
Page 51 and 52: IGP metric-based traffic engineerin
Page 53 and 54: IGP metric-based traffic engineerin
Page 55 and 56: Metric TE Case Study: Traffic Overv
Page 57 and 58: Metric TE Case Study: Worst Case Fa
Page 59 and 60: (theoretically optimal max utilizat
Page 61 and 62: Tunnel Sizing • Tunnel sizing is
Page 63 and 64: Tunnel Sizing • When to re-optimi
Page 65 and 66: Traffic “sloshing” •Tunnel #1
Page 67 and 68: Traffic “sloshing” •1 A •1
Page 69 and 70: TE Case Study 1: Global Crossing*
Page 71 and 72: TE Case Study 1: Global Crossing
Page 73 and 74: TE Case Study 3 • Anonymous netwo
Page 75 and 76: Top 50 Utilized Links (failures) +
Page 77 and 78:
Planning for LFA FRR © 2010 Cisco
Page 79 and 80:
One backup path per primary path
Page 81 and 82:
Benefits • Good Scaling • No de
Page 83 and 84:
Deployment Target
Page 85 and 86:
Access/Aggregation Topologies 100%
Page 87 and 88:
IP/Optical Integration © 2010 Cisc
Page 89 and 90:
Circuit ID Link O1-123 R1 O1 • Mu
Page 91 and 92:
Fasted DWDM provisioning © 2010 Ci
Page 93 and 94:
Network Design • For Mobile backb
Page 95 and 96:
Optical network (geographic/schemat
Page 97 and 98:
SRLGs on IP layer 110% Utilization
Page 99 and 100:
Add remote PE’s • 1. Kiel •Cl
Page 101 and 102:
Final IP topology • Highest utili
Page 103 and 104:
IPFRR LFA’s: site view • LFA ap
Page 105 and 106:
Conclusion • Capacity Planning is
Page 107:
References • [Gunnar et al.] •
show all

1 - Pmacct

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?