The Art of Network Architecture

Transcription

1

2 The Art of Network Architecture Russ White Scott Morris Denise Donohue

3 The Art of Network Architecture Intersecting It Driving It Designing It Selling It 3

4 The Intersection of Business and Technology Why Let Business Drive Technology Decisions? Projects get funded Business succeeds You get a raise??? How Does Technology Drive Business Decisions? Technology Impact is Part of Design Discussion Future Growth Constraints Future Functional Constraints 4

5 Determining Business Requirements Learn the Business Environment The Big Picture Information to gather How to gather it The Competitive Environment Information to gather How to gather it How Does the Network Serve the Business Technologies and Applications in Use Network Evaluation How Does the Network Serve its Customers Internal users External users Guest users 5

6 Learn the Business Environment The Big Picture State of the Business Growing/shrinking/static Future plans Leadership Customers Challenges And how can technology help? Financial Health And how can technology help? Company Website Annual Report Press About the Company Talking to People SWOT Analysis 6

7 Business Environment Example Cisco Overview Cisco Financial Report Cisco Annual Report Stockholder Letter Cisco Annual Report Full Report Strengths Weaknesses Opportunities Threats 7

8 Learn the Business Environment The Competitive Environment State of the Market Lively/growing vs. stagnating Niche or broad? Competitive Pressures How many competitors? How are they doing? Competitors Use of Technology Annual Report Competitor s Website Press About Your Competitors Talking to People 8

9 Competitive Environment Example 9

10 How Does the Network Serve the Business? Does it hold you back Or take you where you want to go? 10

11 How Does the Network Serve the Business? Technologies in Use Applications in Use Network Evaluation LAN WAN Security Flexibility Where does the network Support and improve business processes Hinder them? 11

12 How Does the Network Serve Its Customers? Find out who are the network s customers, and how they use its resources Internal users External users Guest users 12

13 Where Are There Gaps? And How Can Technology Help? Update technologies to Improve processes Reduce cost Increase efficiency Add capabilities, such as VOIP/Video/Presence Mobility (BYOD/CYOD) Redesign part (or all) of the network Equipment refresh is a good time for this Technology or capability additions often require it 13

14 Drive It

15 Business Drivers Capabilities Continuity Cost Change 15

16 Capabilities as a Business Driver Changing Expectations Changing Capability Needs Network Changes Customer and employee expectations Competitive expectations 16

17 Designing New Capabilities How are changes in expectations and competition affecting the business? How is ability to keep pace affecting business finances? What mix of technologies will help them keep pace? 17

18 Designing New Capabilities Changes required to business processes Changes required to the network Changes required to enterprise applications User training required 18

19 Continuity as a Business Driver Most businesses lose $$ if the network is unavailable Highly variable, dependant on the location within the network For instance, within a bank s network: ATM machines can be down for days without impact Branches can be down for ten or fifteen minutes, but after that, losses mount quickly On the trading floor, over $1 million lost in trading fees alone per minute (or second) of downtime Many large networks are now 24/7 19

20 Continuity The trick question is: When is a network down? This often isn t easy to measure or understand Is a single application failing enough to call the entire network down? Is a single section of the network failing enough to call the network down? Business requirements set the standards Critical applications Critical sites Critical portions of the network 20

21 Designing for Continuity Design for failure Redundancy: links, servers, spares, etc. Hot or cold stand by Remote working Plan for failure Detection Troubleshooting Repair Test your plan 21

22 Designing for Continuity Worst Case Analysis?? 23

23 Cost as a Business Driver Most companies strive to reduce costs Unfortunately, cost often compromises the other design goals That can introduce risk Two goals Managing costs Predicting costs Two dimensions Operational Expense (OPEX) Capital Expense (CAPEX) 25

24 Managing Costs Modularity Management Security OPEX Reduces configuration complexity on individual devices Reduces build-out time Limits scope of equipment validation Reduces MTTR (keeping the network in service) CAPEX Limits scope of equipment requirements OPEX Automates configuration management Worst case analysis provides scoping and prioritization OPEX Increases overall network service level Protects information and services 26

25 Predicting Costs Modularity Management Security OPEX Costs can be managed at the module, rather than equipment or network level CAPEX Modules can be treated as a group for equipment upgrades, etc. Provides analysis for predicting network needs over a longer period of time Externally facing OODA loop provides an environment of best practices and trends on which to found modifications in the network Constant evaluation of the network in terms of business goals provides a look ahead capability for predicting new problems to be solved and challenges to be met Worst case analysis provides a realistic estimate of what s needed to meet real world challenges Externally facing OODA loop picks up and anticipates new threats to the network which need to be planned for and met 27

26 Change as a Business Driver Business Growth Organic business growth Scope creep Mergers and acquisitions Business Shrinkage Organic business decline Spin-offs Changing Expectations Customers Employees Modularity Set fixed limits on module sizes within a well defined plan Limit the size of each failure domain Keep configurations repeatable for faster rollouts and modifications Management Accurate baseline and change measurement and analysis Project network needs into the future in a reliable way 28

27 Managing Change An Example Organic growth isn t always visible Start out with 500 remote locations in a hub-and-spoke network Add a new location every other day for a year 675 remotes after one year This will probably work with no additional effort... It appears the network is handling the growth just fine 29

28 Managing Change An Example After a single link failure, however, the network doesn t ever converge The network administrators chase the problem to the hub router A bigger hub router is purchased, and readied for installation Wait! This is really a design problem If the organic growth had been measured and planned for, the network wouldn t have failed 30

29 Managing Change An Example How would modular design help here? If the size of the hub-and-spoke module were intentionally limited Based on testing, best practices, and documentation Once the topology reached a predetermined size, an intentional decision could be made about what to do Build a second topology? Increase the size of the hub router? 31

30 Managing Change Mergers and Acquisitions Mergers and Acquisitions Often involves two or more routing protocols Often involves intense pressure to merge services quickly Often involves two completely different design philosophies, neither of which have been deployed correctly 32

31 Design It

32 Design Toolbox Modularity Resilience Management Security 34

33 Modularity Repeatable Configurations In this network, there are two hub and spoke topologies One uses a point-to-multipoint layer 2 technology the other point-to-point circuits One uses EIGRP, the other OSPF This network is more difficult than it needs to be to manage Each topology should be design and configured using the same tools where possible EIGRP OSPF 35

34 Modularity Assigning Functionality Types of functionality Policy Filtering/aggregating reachability information Forwarding traffic over long(er) geographic distances Modularity divides these pieces up into manageable chunks Much like we divide a piece of software into multiple modules, and connect them through an API Aggregation Packet Filtering 36

35 Increasing Parallelism Modularity Fault Isolation Where do we want to isolate faults? The control plane must calculate for each path between Routers A and B If we split the network into two fault domains... Devices within each fault domain only compute paths within their fault domain This drags the network closer to the MTTR/MTBF balance point Divide complexity from complexity A B MTTR MTBF 37

36 Modularity How Do We Modularize? Hide Information Aggregate or filter control plane state Create a hierarchical design between the various network modules Create multiple overlapping control planes BGP/IGP Virtualization (covered in more detail later) BGP Overlay Aggregation Overlay Topology 38

37 Modularity The Tradeoff If modularity is good, why not build really small modules? Hiding information introduces suboptimal traffic flow Suboptimal routing Stretch A Aggregate to 2001:DB8:9168::/48 Before Aggregation 2001:DB8:9168:1::/ :DB8:9168:2::/64 39

38 Increasing Parallelism Resilience Redundancy In principle, redundancy is easy Any system with more parallel paths through the system will fail less often The problem is a network isn t really a single system It s a group of interacting systems Adding paths is a tradeoff Increases MTBF in one layer Increases MTTR in another layer The key is to balance MTBF and MTTR MTTR MTBF 40

39 Resilience Redundancy In the real world, the point where MTTR and MTBF meet is between two and three parallel structures One is almost always too little if you want resiliency Four is almost always too many And five is right out This applies at all levels of redundancy Circuit/link Device Module Online Data Center Redundant Modules Redundant Links Core Backup Data Center Redundant Equipment 41

40 Resilience Fast Convergence Three steps Detect Notify Link State Flooding Tuned flooding timers Reduce flooding domain Distance Vector Reduce update scope (query range) Calculate Switch Make each step as fast as possible But not at the cost of network stability Detect Notify Calculate & Switch 42

41 Resilience Fast Reroute Detect Notify Link State Flooding Tuned flooding timers Reduce flooding domain Fast reroute eliminates these steps Distance Vector Reduce update scope (query range) Calculate Switch Detect Notify Calculate Switch 43

42 The OODA Loop Management and Security Background Management A slower loop Reacts to organic threats Changes in the business, technology, etc. Business drivers Security A faster loop Reacts to inorganic threats Attacks designed to deny service, obtain access, discover information, etc. 44

43 Management Network Documentation Baseline Performance Baseline Utilization Change Analysis Business Ecosystem Business Processes Technology Ecosystem Design Modification Replace Technology Inject Technology Add Services Policy Modification Best Fit Analysis Root Cause Analysis Business Trends Best Practices Case Studies Shape to Models Technology Trends Business Trends Best Practices Case Studies Change Management Worst Case Analysis 45

44 Management Observe What You Should Document Topology Layer 2 and 3 Policy Where its applied The intent behind the policy Modular Boundaries Where they are The intent behind the boundary Per link utilization Time of day, seasonal, etc. Normal failure rates 46

45 Management Orient What You Should Know Best practices Network architecture models Business models 47

46 Management Decide What You Should Plan There is no such thing as a free lunch Remember the tradeoffs Document the tradeoffs you ve made Follow best practices or not? 48

47 Management Act What You Should Do Make a plan for change Know how to back out Or what your alternatives are in the case of failure Worst case analysis 49

48 Security Network Documentation Baseline Performance Baseline Utilization Anomaly Detection Best Fit Analysis Root Cause Analysis Security Trends Best Practices Case Studies Design Modification Replace Technology Inject Technology Add Services Modify Policy Shape to Models Technology Trends Best Practices Change Management Risks of Failure 50

49 Security Crunchy on the Outside A solid DMZ was once the best you could do in security design for your network Crunchy on the outside, chewy in the middle 51

50 Security Crunchy Through and Through Every device has security Automatic (fast) feedback loops Crunchy through and through IDS 52

51 Security Comparison of OODA Loops Crunchy on the Outside Observe One of my machines has been zombied Orient What is the address of the master host? On what port did they get through? Decide Where do I implement new filters to stop this from happening in the future? What is the best way to block this specific attack? Act Wait for a change window Implement the new filters Test Crunchy Through and Through Observe Automated anomaly detection Data analytics on network traffic Orient What type of attack? From where? Decide Do I toss this traffic, scrub it, honeypot it, or?? Do I need to change my edge policies? Act Allow the automated process to handle Modify edge policies as needed 53

52 Selling It

53 Selling Your Design Why should they spend this money / Implement this change? How do you convey the need? 56

54 Tools for Selling Your Design Justify Your Design: Create a Business Case How does it benefit the company? Risks and costs Include the risk and cost of doing nothing Tools ROI analysis Worst-case analysis Explain Your Design High level, but be prepared for low level details 57

55 Tools for Selling Your Design Typical Components of a Business Case Executive Summary Problem Assessment Solution Information Overview Options Recommendation Financial Analysis Costs Benefits Assumptions and Risks Timeline Next Steps 58

56 Tools for Selling Your Design ROI Illustrations 59

57 Summary The Art of Network Architecture lies in the intersection between business needs and good technology Network architects must be more than technical they must have a foot in the business world also Use your network design toolbox: Modularity Resilience Management Security Good design is not enough, you must be able to Understand and design to the underlying business drivers Present the business as well as technical advantages of your design 60

58 You can't create a good design by adding Band-Aids to a poor design. Terry Slattery CCIE #1026

59 Complete Your Online Session Evaluation Give us your feedback and you could win fabulous prizes. Winners announced daily. Receive 20 Cisco Daily Challenge points for each session evaluation you complete. Complete your session evaluation online now through either the mobile app or internet kiosk stations. Maximize your Cisco Live experience with your free Cisco Live 365 account. Download session PDFs, view sessions on-demand and participate in live activities throughout the year. Click the Enter Cisco Live 365 button in your Cisco Live portal to log in. 62

60