BRKRST-3114 The Art of Network Architecture

The Art of Network Architecture
BRKRST-3114
Russ White
Scott Morris
Denise Donohue
The Art of Network Architecture
 Intersecting It
 Driving It
 Designing It
 Selling It
BRKRST-3114 © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
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
Determining Business Requirements
 Learn the Business Environment  How Does the Network Serve its
– The Big Picture Customers
 Information to gather – Internal users
 How to gather it – External users
– The Competitive Environment – Guest users
 Information to gather
 How to gather it
 How Does the Network Serve the

Business
– Technologies and Applications in
Use
– Network Evaluation
Learn the Business Environment
The Big Picture
 State of the Business  Company Website

– Growing/shrinking/static
 Annual Report
– Future plans
– Leadership  Press About the Company
– Customers
 Talking to People
 Challenges
 SWOT Analysis
– And how can technology help?
 Financial Health
– And how can technology help?
Business Environment Example
Cisco Overview Strengths Weaknesses Opportunities Threats
Cisco Financial Report

Cisco Annual Report – Stockholder
Letter
Cisco Annual Report – Full Report
Learn the Business Environment
The Competitive Environment
 State of the Market  Annual Report

– Lively/growing vs. stagnating
 Competitor’s Website
– Niche or broad?
 Press About Your Competitors
 Competitive Pressures
– How many competitors?  Talking to People
– How are they doing?
 Competitors’ Use of
Technology
Competitive Environment Example
How Does the Network Serve the Business?
Does it hold you back…
Or take you where you

want to go?
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?
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
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
Drive It
Business Drivers
 Capabilities
 Continuity
 Cost
 Change
Capabilities as a Business Driver
Changing Expectations  Changing Capability Needs  Network Changes
 Customer and employee expectations
 Competitive expectations
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?
Designing New Capabilities
 Changes required to business processes
 Changes required to the network
 Changes required to enterprise applications
 User training required
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
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
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
Designing for Continuity
Worst Case Analysis
??
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)
Managing Costs
OPEX
• Reduces configuration complexity on individual devices
• Reduces build-out time
Modularity • Limits scope of equipment validation
• Reduces MTTR (keeping the network in service)
CAPEX
• Limits scope of equipment requirements
OPEX
Management • Automates configuration management
• Worst case analysis provides scoping and prioritization
OPEX
Security • Increases overall network service level
• Protects information and services
Predicting Costs
OPEX
• Costs can be managed at the module, rather than equipment or network level
Modularity
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
Management • 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
Security
which need to be planned for and met
Change as a Business Driver
 Business Growth  Modularity
– Organic business growth – Set fixed limits on module sizes
– Scope creep within a well defined plan
– Mergers and acquisitions – Limit the size of each failure
domain
 Business Shrinkage – Keep configurations repeatable for
– Organic business decline faster rollouts and modifications
– Spin-offs
 Management
 Changing Expectations – Accurate baseline and change
– Customers measurement and analysis
– Employees – Project network needs into the
future in a reliable way
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
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
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?
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
Design It
Design Toolbox
 Modularity
 Resilience
 Management
 Security
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 OSPF
circuits
– One uses EIGRP, the other OSPF EIGRP
 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
Modularity
Assigning Functionality
 Types of functionality
– Policy Aggregation
– 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
Packet Filtering
Modularity
Fault Isolation
 Where do we want to isolate A

faults?
– The control plane must calculate for MTTR
each path between Routers A and B
 If we split the network into two fault MTBF
Increasing Parallelism
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
B
Modularity
How Do We Modularize?
 Hide Information
 Aggregate or filter control plane
state
– Create a hierarchical design between
the various network modules
Overlay Topology
 Create multiple overlapping control BGP Overlay
planes
– BGP/IGP Aggregation
– Virtualization (covered in more detail
later)
Modularity
The Tradeoff
 If modularity is good, why not build

really small modules? Aggregate to
A
2001:DB8:9168::/48
 Hiding information introduces
suboptimal traffic flow
– Suboptimal routing
– Stretch
Before
Aggregation
2001:DB8:9168:1::/64 2001:DB8:9168:2::/64
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
MTTR
Increasing Parallelism
– Increases MTBF in one layer
– Increases MTTR in another layer
MTBF
 The key is to balance MTBF and
MTTR
Resilience
Redundancy
Redundant Modules
 In the real world, the point where
MTTR and MTBF meet is between
two and three parallel structures Online Backup
– One is almost always too little if you Data Data
want resiliency Center Redundant Center
– Four is almost always too many Links
– And five is right out
 This applies at all levels of
redundancy
Redundant
– Circuit/link Equipment
– Device
Core
– Module
Resilience
Fast Convergence
 Three steps
– Detect
– Notify
 Link State Flooding
– Tuned flooding timers
– Reduce flooding domain
 Distance Vector
– Reduce update scope (query range)
– Calculate Detect
– Switch Notify Calculate & Switch
 Make each step as fast as possible
– But not at the cost of network
stability
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)
Detect
 Calculate
Notify Switch
 Switch
Calculate
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.
Management
Network Documentation
Baseline Performance Best Fit Analysis
Baseline Utilization Root Cause Analysis
Change Analysis Business Trends
Business Ecosystem Best Practices
Business Processes Case Studies
Technology Ecosystem
Shape to Models
Design Modification Technology Trends
Replace Technology Business Trends
Inject Technology Best Practices
Add Services Case Studies
Policy Modification Change Management
Worst Case Analysis
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
Management
Orient — What You Should Know
 Best practices
 Network architecture models
 Business models
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?
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
Security
Best Fit Analysis

Network Documentation
Root Cause Analysis
Baseline Performance
Security Trends
Baseline Utilization
Best Practices
Anomaly Detection
Case Studies
Design Modification
Shape to Models
Replace Technology
Technology Trends
Inject Technology
Best Practices
Add Services
Change Management
Modify Policy
Risks of Failure
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
Security
Crunchy Through and Through
 Every device has security

 Automatic (fast) feedback loops
 Crunchy through and through
IDS
Security
Comparison of OODA Loops
 Crunchy on the Outside  Crunchy Through and Through

– Observe – Observe
 One of my machines has been zombied  Automated anomaly detection
– Orient  Data analytics on network traffic
 What is the address of the master host? – Orient
 On what port did they get through?  What type of attack?
– Decide  From where?
 Where do I implement new filters to stop – Decide
this from happening in the future?  Do I toss this traffic, scrub it, honeypot
 What is the best way to block this it, or… ??
specific attack?  Do I need to change my edge policies?
– Act – Act
 Wait for a change window  Allow the automated process to handle
 Implement the new filters  Modify edge policies as needed
 Test
Selling It
“Selling” Your Design
 Why should they spend this money / Implement this change?
 How do you convey the need?
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
Typical Components of a Business Case
 Executive Summary  Financial Analysis

– Costs
 Problem Assessment
– Benefits
 Solution Information
 Assumptions and Risks
– Overview
– Options  Timeline
– Recommendation
 Next Steps
ROI Illustrations
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
‟ You can't create a good design by adding Band-Aids to
a poor design.”
• Terry Slattery
• CCIE #1026
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.

BRKRST-3114 The Art of Network Architecture

Uploaded by

Copyright:

Available Formats

BRKRST-3114 The Art of Network Architecture

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRKRST-3114 The Art of Network Architecture

Uploaded by

Copyright:

Available Formats

How does the document describe determining business requirements?

How does the document describe determining business requirements?

What are some tools described for 'selling' a network design?

What are some tools described for 'selling' a network design?

The Art of Network Architecture

 How Does the Network Serve the

 State of the Business  Company Website

Cisco Financial Report

 State of the Market  Annual Report

Or take you where you

 Customer and employee expectations

 How is ability to keep pace affecting business finances?

 What mix of technologies will help them keep pace?

 The trick question is: When is a network down?

 Organic growth isn’t always visible

 After a single link failure, however,

 How would modular design help

 Mergers and Acquisitions

 In this network, there are two hub

 This network is more difficult than

 Where do we want to isolate A

 If modularity is good, why not build

 In principle, redundancy is easy

 There is no such thing as a free

 Make a plan for change

Best Fit Analysis

 A solid DMZ was once the best

 Every device has security

 Crunchy on the Outside  Crunchy Through and Through

 How do you convey the need?

 Justify Your Design: Create a Business Case

 Explain Your Design

 Executive Summary  Financial Analysis

You might also like