resilient network design

advertisement
Matěj Grégr
RESILIENT NETWORK DESIGN
PAGE
1/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Campus Best Practices - Resilient network design
 Campus Best Practices documents share knowledge within
several technical areas (physical infrastructure, campus
networking, wireless, security, etc.)
 Campus Best Practice Documents are available at:
http://www.terena.org/activities/campus-bp/bpd.html
 Resilient network design is described mainly in:
 Recommended Resilient Campus Network Design, March 2010 (CBPD114,
the Czech Republic)
 Recommended configuration of switches in campus networks, May 2010
(UFS105, Norway)
PAGE
2/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Resilient network design
 Enterprise campus requires highly available and secure
network infrastructure, to support business solutions such as
voice, video, wireless, and mission-critical data applications.
 Resiliency—Ability to provide non-stop business
communication with rapid sub-second network recovery
during abnormal network failures or even network upgrades.
 The goal of resilient topology is to eliminate downtime and
convergence time during crashes and device upgrades
PAGE
3/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Network design ①




Single broadcast domain
Single security domain
No backup
Central switch performance
PAGE
4/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Network design ②
 Routers can separate network
 Smaller broadcast domains
 Possibility to control traffic path
 Routers are pretty expensive
 Number of ports in an ordinary router is limited
PAGE
5/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Resilient Campus design
Servers and users access
ports
Aggregation traffic from
access layer
High speed switching/routing
PAGE
6/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Access layer






Entry point for clients into the network
Provides Layer 2 (VLAN) connectivity between users
High port density
PoE
Security mechanism – 802.1x
QoS classification
PAGE
7/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Access layer
 Problems:
 Access switches are single points of failure in a network
• Redundant connection for end users is very expensive
• Resiliency has to be integrated into the device
• Redundant supervisor, power outlet …
 Recommendations:
 Disable Etherchannel and trunk negotiation for end users
• Prevents VLAN hopping attacks
 Enable edge ports (PortFast) for access ports
PAGE
8/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Server access layer redundancy
 Servers need redundant network connection
 Possible solutions:




PAGE
9/36
Link aggregation protocol (LACP, PAgP)
Ethernet card bonding
Server virtualization
Service load balancing
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Link aggregation (Etherchannel)
 Allows combination of several physical links to one
logical channel
Physical view
Logical view
 Load balancing
 MAC, IP, IP+TCP/UDP
 Simplify configuration
 only logical port configuration is necessary
 Simplify other protocol operation
 STP sees only Etherchannel link
PAGE
10/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Link aggregation protocol
 Two signaling protocols exist (PAgP, LACP)
 LACP – IEEE 802.3ad is recommended, PAgP is Cisco
proprietary
 Modes:
 Active/Passive: request/response channel establishment
 On/Off: static configuration
 Recommendation:
 Use static configuration (mode on): dynamic configuration
delays channel establishment
PAGE
11/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Etherchannel configuration
 Prerequisites to established channel
 Same speed/duplex
 Same mode (trunk – same vlans enabled, access – same
access vlan)
 Same STP cost and mode (edge/non-edge)
 Cisco
Switch1(config)# interface range gi 0/1 - 2
Switch1(config-if-range)# channel-group 1 mode active
 HP
Switch1(config)# trunk g1-g2 trk1 lacp
PAGE
12/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Ethernet card bonding
 Useful, when server does not support aggregation
protocol
 Linux - supported in kernel
 Windows – supported in Ethernet card drivers
 Several modes:
 backup
 transmit load balancing: load balance in transmit direction
 adaptive load balancing: rewrite MAC addresses, different
peers use different MAC address, no switch support is
necessary
PAGE
13/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Server virtualization
 Virtualization brings simplification in network
resilient design
 Virtual servers are connected through Virtual Switch
 Virtual switch – redundant connection to resilient
network
 All virtual servers have resilient connection to
Internet
PAGE
14/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Server Load Balancing
 SLB provides a virtual server IP address to which
clients can connect, representing a group of real
physical servers in a server farm
 Load balancing: according to:
 L4 - L7 information
 Software implementation
 Hardware implementation
• Cisco Application Control Engine modul needed
 Advantages:
 Reduced server load
 Higher security – real IP address is not visible
 Downtime elimination if more servers are used
PAGE
15/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
SLB modes
 Dispatched mode
 Every server in server farm has own real IP together with virtual
IP address (secondary IP or loopback IP) of whole server farm
 Traffic redirection: packet with virtual IP is put in Ethernet frame
with MAC address of real server
 All servers in SLB farm have to be in same IP subnet
 Directed mode
 Every server has only own real IP address
 Servers do not know virtual IP address of whole server farm
 NAT is used – virtual IP address of the farm is translated to real
IP address of a server
PAGE
16/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Distribution layer
 Purpose is to provide L2 distribution through
switched network
 Topology contains loops (needed for redundancy)
 L2 loop protocol (STP) is needed
 Gateway redundancy, high availability
 Packet filtering,
PAGE
17/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Spanning tree protocol
 Necessary for loop elimination
 802.1D
 Original version has very long convergence time > 30s
 Did not support VLAN – support added in 802.1t, extend
BID, now integrated into 802.1D
 Recommendation is to use RSTP (802.1w), RPVSTP+
or MSTP (802.1s)
PAGE
18/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Rapid Spanning Tree (RSTP)




IEEE 802.1w
Convergence time < 1s
Backward compatibility with 802.1D
Several Cisco 802.1D improvements were integrated
into 802.1w standard (UplinkFast, BackboneFast …)
 Configuration:
 Cisco: Switch(config)# spanning-tree mode rapid-pvst
 HP: Switch(config)# spanning-tree force-version
rstp-operation
PAGE
19/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
STP load balancing
 Scenario:
 Port-priority or port cost can be used
 Example:
Left(config)# interface gi1/6
Left(config)# spanning-tree vlan 200 port priority 112
 Recommendation:
 Useful is to set higher priority on undesired port instead of
setting lower priority on desired port
PAGE
20/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
MSTP
 STP or RSTP support only one STP tree for all VLANs
 RPVSTP+ (Cisco proprietary): STP tree per every VLAN
 Main idea of MSTP:
 Administrator can configure several STP instances
 VLANS are mapped to instances
 MSTP internally use RSTP
PAGE
21/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
MSTP configuration
Switch(config)# spanning-tree mode mst
Switch(config)# spanning-tree mst configuration
Switch(config-mst)# name region1
Switch(config-mst)# revision 1
Switch(config-mst)# instance 1 vlan 100
Switch(config-mst)# instance 2 vlan 200
 Configuration needed for every switch
 Increase complexity
 Proprietary solution:
 Use VTPv3
PAGE
22/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
VTPv3




More flexible protocol – can distribute “any” database
Better authentication
VTP can be turned on/off per port
Client can not rewrite database as it was common in
previous versions
 Server/client/transparent switch for databases
 VLAN, MST, Unknown (another database in future)
 Primary/secondary server
 Primary server (only) can modify a database
• Only one server in a domain
 Secondary server: backup server, could be primary
PAGE
23/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
VTPv3 – MSTP configuration
 Configure VTPv3
Switch(config)# vtp
Switch(config)# vtp
Switch(config)# vtp
Switch(config)# end
Switch# vtp primary
version 3
domain NAME
mode server mst
mst
 MSTP configuration similar to previous slide
 MSTP config is distributed within VTPv3 domain
PAGE
24/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Gateway redundancy
 Historic attempts
 Proxy ARP, ICMP Router Discovery Protocol, routing support in
end station
 Does not scale well, software support is needed
 Solution:
 Redundancy using virtual router
 Virtual IP, virtual MAC
 No host configuration needed
Virtual Router
 Proprietary solutions
 HSRP, GLBP
Backup in
Standby
Forwarder
 Standard solution
 VRRP
PAGE
25/36
Internet,
Backbone, etc.
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
VRRP
 Open standard
 IETF RFC 3768 – version 2
 IETF RFC 5798 – version 3 (IPv4 + IPv6)
 VRRP Group – virtual router with virtual IP address
 Virtual MAC address - 0000.5e00.01xx - last byte is
group number
 Master router
 Highest priority
 IP address same as virtual IP (IP address owner) – always win
master role
 Backup router
 Other routers in VRRP group
PAGE
26/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
VRRP configuration
 Cisco configuration
SwitchA(config)# interface vlan10
SwitchA(config-if)# ip address 10.1.10.5 255.255.255.0
! Virtual IP for vrrp group 10
SwitchA(config-if)# vrrp 10 ip 10.1.10.1
! Priority for router in group 10 (standard priority is 100)
SwitchA(config-if)# vrrp 10 priority 150
! Preempt delay
SwitchA(config-if)# vrrp 10 preempt delay minimum 380
 HP configuration
hp
hp
hp
hp
hp
(config)# vlan 223
(vlan-224)# vrrp vrid 1
(vlan-224-vrid-1)# owner
(vlan-224-vrid-1)# virtual-ip-address 10.1.10.5 255.255.255.0
(vlan-224-vrid-1)# enable
 Recommendation
 Use the first IP address from subnet for Master router
 Set preempt-delay-time to let routing protocol converge
PAGE
27/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Gateway Load Balancing Protocol
 HSRP, VRRP may have inactive routers in a group
 Standby and Other routers: cannot be used by end station (do not have
virtual IP/MAC)
 Possible solution: several HSRP/VRRP groups with end stations distributed
among them
 Static configuration!
 GLBP goal is to utilize all routers equally
 Several members of GLBP group should participate in packets
switching/routing
 GLBP solution
 Virtual IP per group
 max. 4 virtual MAC addresses per group
PAGE
28/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
GLBP – fundamental concept
 GLBP group contains two types of members
 Active Virtual Gateway
 Active Virtual Forwarder
 Active virtual gateway (AVG)




Router with highest priority (highest IP address)
There is only one AVG per group
Assign virtual MAC addresses of other members of the GLBP group
Reply to virtual IP ARP requests
• GLBP group controller: end device requesting virtual IP address
obtains some of the assigned virtual MAC addresses
 Active virtual forwarder (AVF)




PAGE
29/36
Max. 4 AVF per group, other routers are in backups
AVF are responsible for assigned virtual MAC/IP address
AVG is also AVF
Communication is done via Hello messages every 3 sec, multicast
address 224.0.0.102 UDP 3222
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
GLBP operation
PAGE
30/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
GLBP load balancing techniques
 Weighted load-balancing algorithm
 Based on weighting parameter
 Per-host (Host-dependent load-balancing algorithm)
 End station has always the same AVF
 Round-robin load-balancing algorithm (default)
 Virtual MAC addresses are rotated per ARP request
PAGE
31/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Core layer




High speed routing
Fast convergence is necessary
Aggregate links from distribution layer
Try to avoid any packet manipulation, (access lists
and filtering), which would slow down the switching
of packets.
 Smaller campus can combine core and distribution
layer functions
PAGE
32/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Is the core layer necessary?
PAGE
33/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Is the core layer necessary?
PAGE
34/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Summary
 Resilient network design eliminates downtime and
convergence time in a network
 If is it properly deployed
 Always depends of “How much money do You have”
PAGE
35/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
PAGE
36/36
nes.at.fit
© 2011 Brno University of Technology, Faculty of Information Technology, Matěj Grégr, igregr@fit.vutbr.cz
Download