Cisco Cisco IOS Software Release 12.0(1a) 白皮書

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.

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 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.

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.

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.