Designing High Availability Services © 2004 Cisco Systems, Inc. All rights reserved. Designing High-Availability Enterprise Networks ARCH v1.25-1

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Network Design Considerations for High Availability Where should module and chassis redundancy be deployed in the network? What software reliability features are required for the network? What protocol attributes need to be considered? What high availability features are required for circuits and carriers? What environmental and power features are required for the network? What operations procedures are in place to prevent outages?

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Design Consideration: Redundancy Options Module Redundancy Failover redundant modules only Operating system determines failover Typically cost effective Often only option for edge devices (point-to-point) Chassis Redundancy Redundancy for all modules Protocols determine failover May increase cost and complexity Limitations for point-to-point networks

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Design Consideration: Parallel Versus Serial Implementations Considerations: Device cost Port usage WAN circuit costs Management complexity

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Other Redundancy Design Considerations Will the solution allow for load sharing? Which components are redundant? What active/standby fault-detection methods are used? What is the MTBF for a module? What is the MTTR for a module? Should the module be redundant? How long does it take to recover a failure? How long does it take to do an upgrade? Are hot swapping and OIR available?

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Implementing Software Features Protect gateway routers with HSRP or VRRP. Implement resilient routing protocols: –EIGRP –OSPF –RIP v2 –IS-IS –BGP Use floating static routes and Access Control Lists to reduce load in case of failure. Consider protocol attributes: –Complexity to manage and maintain –Convergence properties –Hold times –Signal overhead

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Circuit and Carrier Planning Understand the carrier network. Consider multi-homing to different vendors. Monitor carrier availability. Review carrier notification and escalation procedures to reduce repair times.

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Power and Environment Best Practices for High Availability Refer to the IEEE recommended practice for powering and grounding sensitive electronic equipment (Standard ). Source: Worldwatch Institute Electrical interruptions will cost U.S. companies some $80 billion a year.

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v High-Availability Design Conclusions Reduce complexity, increase modularity and consistency. Consider solution manageability. Minimize the size of failure domains. Consider protocol attributes. Consider budget, requirements, and areas of the network that contribute the most downtime or are at greatest risk. Test before deployment.

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Five Steps to Best Practices for High Availability Step 1: Analyze technical goals and constraints. Step 2: Determine the availability budget for the network. Step 3: Create application profiles for the business applications. Step 4: Define availability and performance standards. Step 5: Create an operations support plan.

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Achieving 99.99% Availability (Four Nines) Four nines, even with redundancy, will be a challenge if you have any of these problems: Single point of failure Outage required for hardware and software upgrades Long recovery time for reboot or switchover No tested hardware spares available on-site Long repair times due to a lack of troubleshooting guides and process Inappropriate environmental conditions

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Achieving % Availability (Five Nines) You cannot get to five nines if you have any of these problems: High probability of failure of redundant modules High probability of more than one failure on the network Long convergence time for rerouting traffic around a failed trunk or router in the core Insufficient operational control

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Building Access Submodule High-Availability Features Spanning Tree Protocols IEEE 802.1D Rapid Spanning Tree Protocol (802.1w) Multiple Spanning Tree (802.1s) Spanning Tree Features UplinkFast Portfast

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Building Access Design for High Availability

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Building Distribution Submodule High-Availability Features Spanning-Tree Features Use RSTP Set STP root Root board HSRP Provides first-hop redundancy HSRP timers reduce failover HSRP track offers optimal routing

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Building Distribution Design for High Availability

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Campus Backbone Submodule High-Availability Features Incorporate device and network topology redundancy. Incorporate HSRP.

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Guidelines for Server Farm High Availability Use redundant components in infrastructure systems. Use redundant traffic paths provided by redundant links. Use optional end-system dual homing.

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Enterprise Edge High-Availability Features

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Enterprise Edge Design for High Availability

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: High-Availability Design

© 2004 Cisco Systems, Inc. All rights reserved. ARCH v Summary When designing a network for high availability, you will consider the reliability of each network component, redundancy, and other features that contribute to the overall availability of the network. Cisco has developed a set of best practices recommendations to ensure network high availability. Each submodule of the Campus Infrastructure module must be designed to incorporate fault tolerance and redundancy to provide a highly available network. Each module of the Enterprise Edge functional area must incorporate high availability features from the service provider edge to the enterprise campus network. High availability in the enterprise site can involve deploying highly fault-tolerant devices, redundant topologies, spanning- tree protocols, and HSRP.