Scalable Network
Design
Ryan J. Determan, CCIE 5276
Copyright 2002 DDLS
Internetwork Design Goals
•
•
•
•
•
Functionality
Scalability
Adaptability
Manageability
Cost effectiveness
• Basic trade-off in network design is cost versus
availability
• Recurring costs tend to predominate
Characterizing Scalable
Internetworks
Scalable internetworks need to be:
• Reliable and available
• Responsive
• Efficient
• Adaptable
• Accessible but secure
The Cisco Design Model
Core
Distribution
Access
The Core Layer
The Core is responsible for optimized
transport between remote sites
• No routing
• Load sharing / Efficient use of bandwidth
• Standards based technologies
• Don’t be cheap!
The Distribution Layer
The Distribution Layer is responsible for
Layer 3 resiliency
• Company resources and new services
• Routing peers
• Filter and summarize!
• Inbound security and policy
• Addressing: private or public
The Access Layer
The Access Layer is responsible for
connecting logical workgroups to
backbones
• User segmentation
• Isolate traffic to/from the workgroup
Designing The Core
Layer 1 predetermines network success
• Worth its weight in copper?
• Not a good place for cost efficiency
• Keep it simple and standard
• Layer 1 affects all other layers
Core Design Choices
ATM
•
•
•
Good if available
Can be expensive
Built in QoS mechanism
Point-to-Point Links (T1’s, OC3’s, etc)
•
•
•
Best if available and affordable
Always expensive
Nothing built in
Core Design Choices (cont.)
Frame Relay
•
•
•
Useable but not favorable
Always available
Can perform some limited traffic shaping
Ethernet/LAN
•
•
•
Best choice if applicable
10mb, 100mb, 1000mb
GigE, FastE, FDDI
Designing the Distribution & Access
Layers
A good Layer 2 design can hide Layer 1
problems from Layer 3
• Design for redundancy
• Do you know who your root bridge is?
• Spanning Tree is your friend & foe
How redundant are you?
A fast converging, redundant Layer 2
network will prevent Layer 3 flaps
• Use multiple trunks utilizing different blades
• Don’t mix and match standards (ie 802.1Q & ISL)
• HSRP
Root Bridge?
Proper Layer 2 design denotes a
root bridge
• Defines STP metric for algorithm
• Should be the ‘most’ redundant
• Commonly forgot
Spanning Tree
STP should provide fault tolerance,
not loop avoidance
• Designing ‘looped’ layer 2 networks is beneficial
• Should have ‘primary’ path and secondary
• PVST gets around down time
• Tweak the STP protocol (timers, cache, diameter)
Hot Standby Routing
Protocol
HSRP provides Access Layer fault
tolerance for hosts
• Cisco proprietary solution (VRRP is RFC)
• Allows multiple gateways to respond
• Only need to configure 1 gateway
• No IRDP
HSRP (cont)
HSRP in action:
I need to get
to 172.16.3.127.
Use MAC address
0000.0c07.ac2f.
Router A
Priority 200
172.16.10.82
0010.f6b3.d000
Virtual Router
172.16.10.110
Router B
Priority 100
172.16.10.169
0010.0b79.5800
0000.0c07.ac2f
Core
File Server A
172.16.3.127
Designing Layer 3
Let Layer 3 make the decisions
• Design for layer 3 switching (FS, Netflow, CEF)
• Scalable routing protocols (OSPF, BGP)
• Routers route and firewalls firewall
• Public vs. private addressing and NAT
• Plan for ‘special’ routers
Switching at Layer 3
Different switching technologies allow for
faster path choice
• Fast Switching (route cache)
• NetFlow (IP pair based flow with ACL awareness)
• CEF (express forwarding using a FIB)
• Be careful of the recursive lookup
Scalable Routing Protocols
Choose the correct protocol
• Static routes are not evil
• OSPF for small to medium IGP’s
• ISIS for large IGP’s
• BGP for internet routing policy
Static Routes
Multiple static routes can provide:
• Load balancing
• Fault tolerance
• Good method for BGP advertisements
Designing OSPF
OSPF is stable and efficient in a properly
designed network
• Watch for limits: 50 areas, 3-4 areas per router
• Summarize at area borders
• Implement OSPF features when possible
OSPF Features
Configurable OSPF features:
• Stub, totally stub and not-so-stubby areas
• LSA pacing
• Multiple default-gateways by changing default-cost
• External type 1
• Demand circuits (doesn’t have to be a DDR link)
Designing BGP
BGP is only desirable when you have
multiple internet connections
• Use loopbacks and statics
• Do you need an internet routing table?
• Use IGP to get ‘out’ to the internet
• Use BGP to get traffic ‘in’
• Let the ISP do the work
BGP features
Configurable BGP features:
• Know your attributes (Med, LP, community)
• Default originate
• Many filtering options (as-path, prefix, dist.)
• Large scale: route reflectors and confederations
• Route dampening
Security at Layer 3
Routers connect & firewalls protect
• Standard ACL’s are OK
• Use routers for choke points
• Use firewalls for security and NAT
• Firewall IOS is not a firewall
Addressing Design
At some point you must NAT
• Proper NAT design helps security &
implementation
• Let the Firewalls translate addresses
• Should have distinct ‘line’ of addressing
• Use NAT for services and PAT for users
Special Routers
Router features change quickly, but your
design should not
• Design with ‘router only’ routers
• Design for special purpose/IOS routers to support
changing services
• Don’t hope for the ‘perfect’ IOS
• Run GD code on ‘router only’ routers
Designing Layer 4+
I thought network design ended at L3?
• What about the services and servers
• Content delivery design
• CSS, Cache Engine, Content Engine
Changing Services
Chances are the services your provide as
a business model reside on your
network
• Don’t design yourself out of business
• Design for single points of security
• Have a place to ‘sniff’ traffic
Content Delivery Networks
A new type of design has emerged:
Content Delivery
• How do I get my content to my customer quickly,
reliably, and accurately?
• How can I support 20 million hits per day?
• Can I offload any server traffic?
Content Delivery Networks (cont)
Making content more available
• Push the content to the edge
• Load balance mirrored content
• Creative DNS solutions
Content Delivery Networks (cont)
Content delivery hardware and features
• Cache Engine (cache’s local servers static content
and offloads server of these requests)
• Content Engine (provides web services)
• Content Smart Switch (glue that connects it all
together)
Content Smart Switch
The CSS is a multi-service box
• Can switch/route traffic on any layer 1 - 7
• Can provide DNS server functionality
• Can replicate web updates to all mirrored sites
• Can load balance to local or remote servers based
upon user definable criteria
Questions?
Contact Information:
Ryan J. Determan, CCIE 5276
Ryan.Determan@us.ddls.com
1.800.569.1894