New Solution Deployment: Best Practices White Paper
Available Languages
Contents
Introduction
This document discusses planning, design, and implementation practices for the deploying new solutions in your network. The biggest challenge when introducing new solutions is keeping the existing network highly available, or minimizing the impact on the existing networking environment. Successful deployment of new solutions requires structured processes that include parties from planning, design, network management, and implementation.
This best-practice document outlines the steps you need to take to successfully deploy a new network solution. We'll look at the following critical steps in detail: Requirements, Management, Validation, and Deployment.
High-Level Process Flow for Deploying New Solutions
The following diagram outlines your workflow for deploying new network solutions. Click on any blue box in the flow for more detailed information about that step.
Solution Requirements
Gathering requirements is the first and most important step in successfully deploying a new network solution. We'll look at the following necessary steps in gathering requirements:
Required Features or Services
Gathering network features or services requires an understanding of applications, basic traffic flows, and user and site counts. You can use this information to create a logical design and feature set that will help network architects understand requirements such as bandwidth, interface requirements, connectivity, configuration, and physical device requirements. This step does not include how you determine performance, manageability, availability, or interoperability of the network.
Performance Service-Level Agreements and Metrics
Use performance service-level agreements (SLAs) and metrics to define and measure the performance of new network solutions to ensure that new solutions meet performance requirements. You can use performance monitoring tools or a simple ping across the proposed network infrastructure. The performance SLAs should include the average expected volume of traffic, peak volume of traffic, average response time, and maximum response time allowed. You can use this information to validate the solution. Ultimately, this information will help determine the required and expected performance and availability of the network, and ensure that the solution is acceptable.
Solution Scalability Objectives
Creating solution scalability objectives helps you design networks that meet future growth requirements and ensure that proposed designs do not experience resource constraints during expected growth of the network. Resource constraints include overall traffic volume, number of routes, number of virtual circuits (VCs), neighbor counts, broadcast domains, device throughput, media capacity, and a number of other scalability-type parameters. You should determine the required life of the design, expected extensions or sites required through the life of the design, volume of new users, and expected traffic volume or change.
Availability Objectives
Creating availability objectives to define the level of service helps ensure that the solution meets end-availability requirements. You can define different classes of service for a particular organization and detail the appropriate network requirements for each class. Different areas of the network may require different levels of availability. A higher availability objective may necessitate increased redundancy and support procedures as well as stable non leading-edge type components. By defining an availability objective for a particular network service and measuring that availability, you can understand components and service-level requirements.
Interoperability with Existing Environment
Interoperability and interoperability testing can be critical to the success of new solution deployments. Interoperability can refer to different hardware vendors or even different topologies or solutions that must mesh during or following a network implementation. Interoperability problems can include hardware signaling through the protocol stack to routing, or transport-type problems. Interoperability planning should include connectivity between different devices and topology issues that might occur during migrations.
Solution Comparison
We recommend comparing different potential designs in relation to other solution requirement practices. This helps ensure that the solution is the best fit for a particular environment and that personal bias does not drive the design process. Factors to compare include cost, resiliency, availability, risk, interoperability, manageability, scalability, and performance. All of these can have a major effect on overall network availability once the design is implemented. Comparisons can be done on media, hierarchy, redundancy, routing protocols, and similar feature capabilities. A chart with factors on the X-axis and potential solutions on the Y-axis helps summarize solution comparisons. Detailed solution comparisons in a lab environment also help to objectively investigate new solutions and features in relation to the different comparison factors.
Documented Network Design
The network design documents should include basic logical network connectivity, ports, addressing, configuration requirements, distances between devices, and alternatives. You should analyze required features, performance requirements, availability objectives, manageability objectives, and interoperability in relation to the design. We recommend documenting the design phase to show how the proposed design model meets solution requirements. Consider and document alternative models including benefits and issues in relation to the design requirements. Physical design issues may also be important during the design phase because of space limitations, distances, chassis capacity, power, or other physical limitations. The physical design requires space planning, power planning, rack design and layouts, device memory and CPU requirements, port and card assignments, cabling requirements, carrier requirements, and physical device security.
Solution Management
Gathering information about managing the network helps you deploy a new network solution that meets your requirements. We'll look at the following necessary steps in network management:
Network Management Objectives
Setting network management objectives requires an understanding of the support process and associated network management tools. Management objectives include an understanding of how new solutions will fit into the existing support and tool model, with references to any potential differences or new requirements. This step is critical to deployment success, because the ability to support new solutions is key to network availability. Network management objectives should include the following:
-
Important Management Information Base (MIB) or network tool information required to support a potential network.
-
Training required to support the new network service.
-
Staffing models for the new service and any other support requirements.
Service-Level Management
An important aspect of network design is defining the level of service you will provide to users or customers. Service-level management typically includes definitions for problem types and severity, and help-desk responsibilities such as escalation path, time before escalation at each tier support level, time to start working on the problem, and time to close targets based on priority. Other important factors to consider are type of service to be provided in the area of capacity management, proactive fault management, change-management notification, thresholds, upgrade criteria, and hardware replacement.
Staffing
Staffing roles include tier 1, tier 2, and tier 3 support, architecture, engineering, installation, lab testing and validation, facilities planning (environment, wire, power), network management tools operations, database, Simple Network Management Protocol (SNMP) and interpretation, documentation, and deployment. We do not recommend that you hire a particular number of technical resources to fill these positions, but that you research and identify the appropriate skillset for each group, and fill these roles with people who have the proper level of expertise.
Solution Validation
Validating a new solution includes the following steps:
Design Review with Vendor
During this phase you should present the design, all aspects of the solution requirements, and scalability expectations to the product vendor. The vendor is responsible for analyzing the design and identifying all potential capacity or scaling issues relative to the identified solution requirements. Because different experience exists within a vendor relationship, sales and support representatives with expertise in the area of network design should participate in the design review. The vendor may analyze any of the following aspects of network design: Level 2 scalability, Level 3 scalability, overall traffic patterns and volumes, buffer and queuing, memory and CPU requirements, card chassis input/output, redundancy, hierarchy, software stability, and configuration.
Simulation and Emulation Tools Validation
Network design simulation and emulation tools can aid you significantly when validating a new network solution. Simulation and emulation tools may also provide traffic estimates and perform capacity or scalability analysis. At present, Cisco supports lab validation and offers Network Verification Service to analyze capacity and scalability issues, because many network environments are unique and difficult to model effectively.
Lab Validation
Lab validation provides information on the functionality, capacity, and scalability of a network solution. Building a model to replicate the intended solution and injecting routes, broadcasts, and traffic into the model provides essential planning and design data. In addition, you can create models to mimic very large-scale topologies by using multiple subinterfaces or virtual interfaces. By injecting routes, Service Access Points (SAPs), or broadcasts into the network at high rates, you can understand the behavior, capacity, and scalability issues in large environments. To simulate a real network, use traffic generators to understand how successful a device is at passing large amounts of traffic under different types of loads. Lab validation measures the following parameters: functionality, CPU averages, buffer and queue utilization, traffic throughput, traffic end-to-end success rates, memory utilization, and routing protocol stability. In addition, you may discover software or hardware defects in a lab validation.
Documented Record of Design Reviews and Tests
Once new solution validation is near completion, it is important to document solution requirements, designs, test results, expected performance, and design review information to finalize the proposed solution. This set of information becomes the foundation on which the new solution is built. The documentation forms a basic level of understanding about the new solution by which potential changes might be made, but not automatically guaranteed. The information also serves as validation to confirm expectations and SLAs are met for the new network solution.
Solution Pilot
In most cases, the network solution, or portions of the network solution, can be piloted in the network. A pilot lasts for a defined period of time, with the result being a better understanding of how well the solution meets expectations. Almost any solution can be piloted in a non-critical manner by carefully choosing the user group and the traffic that flows across the pilot solution. The pilot should consist of a pilot proposal and plan, the pilot itself, and pilot post-mortem report that details the findings of the pilot and whether it met or did not meet expectations. Expectations in the area of performance include feature capability, availability, or manageability. You may also test installation capabilities and operational support of the network solution. The postmortem analysis of the pilot should then review the deployment of the new solution, and recommend and execute any changes in the overall network design. Ultimately, the pilot and post-mortem analysis is the final test in validating the new solution. In some cases, you may find that the new solution does not meet all the objectives and you need to start over with the solution requirements phase.
Final Review and Decision Process
Before deployment, final review of the validations and pilot experience is required to address the identified issues. The review should include a report of the user experiences, technology issues, support experiences, pilot deployment problems, current market situation, and additional steps for improvement. An approval process should be a part of any deployment process.
Solution Deployment
Deploying a new solution includes the following steps:
Solution Templates
Solution templates contain configuration and physical and logical design criteria for individual network modules at the core, distribution, or access layer. You can use the solution template to ensure that common modules are implemented with the same design, configuration, hardware, and support capabilities. A common module is typically a wiring closet, distribution point, or core network location. By specifying requirements for common modules, you can more easily support network environments because of the similar attributes at each location. Typically the solution template includes naming conventions, standard configurations, hardware requirements, addressing requirements, rack layouts, labeling requirements, color coding, out-of-band management requirements, and network management integration requirements.
Baseline Comparison
You should complete a baseline report of the existing network prior to and following deployment to measure expectations for the new solution. Typically, the baseline report includes capacity issues related to CPU, memory, buffer management, link and media utilization, and throughput. The report may also include an availability baseline that demonstrates increased stability and availability of the network environment. It is also helpful to compare baseline reports from old and new network environments to verify solution requirements.
Trained Implementation Staff
When deploying a new solution, you must identify and perform all training requirements. We recommend training the implementation team on new features, testing, and the logical and physical design of the new network solution. Other issues to cover include cabling requirements and identification, power requirements and identification, overall labeling, and testing and verification requirements during implementation. You may also want to have regular review meetings during large implementations to cover any potential issues.
Operations Training and Support Procedures
New deployments generally require operations training and support procedures to ensure that you can easily support new network environments. This is especially important with new configurations, features, or hardware that is unfamiliar to the operations group. Review any specific operational issues, including impact of potential operational commands, hardware replacement, configuration file archival procedures, installation guidelines, software upgrade procedures, change management, troubleshooting guidelines, and manageability guidelines, including polling thresholds. Document and review the support procedures with the network engineering and operations groups prior to implementation. Provide these teams with ample time and opportunity to digest the required operational support requirements prior to implementation.
Implementation Plans
The final stage of deployment planning is developing implementation plans and schedules. The basis of the implementation plan is a step-by-step installation procedure that facilitates a smooth transition and minimizes user impact. Implementation plans may include installation scripts, a method for handling corrections or deviations, quality controls, security controls, identification and scheduling of required resources, defined tasks, hardware and miscellaneous equipment procurement, task dependencies, and time sequencing. Implementation should follow and be approved through established change-management procedures prior to installation.
Feedback