Tuscan Architecture

Overview

All design changes you make to your network must be tested with a proof of concept plan. It is important to test the current design, configuration and IOS versions in a non-production environment or on the production network with limited disruption. Implementation of newer network modules at a router, for instance, could require that you change the current IOS version that is implemented. Making those changes could affect WAN or campus modules already installed at production routers. That is the real value of doing a proof of concept and certifying that the new equipment and IOS versions integrate with each device as well as the network.

Advantages

The following list describes the advantages of doing a proof of concept with your network design.  The proof of concept test results should be examined and used to modify current infrastructure, security and management specifications before generating a design proposal. The proof of concept model suggested here involves prototype design, equipment provisioning, defining tests, building equipment scripts and examining test results.  

The following list describes specific advantages associated with proof of concept testing

•  Address any design concerns without affecting your production network

•  Build and test configuration scripts before implementation

•  Test new IOS, Cat OS and WAN OS versions and firmware

•  Sell design feasibility to the client

Proof of Concept Model

The following numbered list describes all proof of concept components and specific sequence.

1. Prototype Design

2. Provision Equipment

3. Define Tests

4. Build Equipment Scripts

5. Review Test Results

Prototype Design

The prototype is a model for testing design and configuration features in a non-production setting such as a lab. You concern could be with specific protocols or IOS services and how they work with current protocols and IOS services running on your production network. The design should specify topology, equipment, addressing and software versions.

Provision Equipment

Obtain the circuits, cables, devices and servers required for testing. The equipment and software should be identical to the proposed design for specific testing and verification. Connect the equipment as specified with the prototype and make note of specific software versions and firmware being tested.

Define Tests

The tests should be designed to verify the design works as described at all Layers of the OSI model. That would focus on physical, network and application connectivity. The following is a suggested list that should be modified for your particular concerns. Depending on the current network and your tests, it could be an option to implement testing at some access offices with minimal impact on the production network.

The following is a list of typical tests that should be conducted

•  Ping Equipment and Servers

•  Routing and Switching

•  Security Testing

•  Availability Testing

•  Application Load Testing

Build Equipment Scripts

Work with vendors to build the correct scripts for each device. This is particularly relevant if the design will utilize newer equipment and protocols that have yet to be standardized with the industry. Discuss any problems or concerns the vendor has with your current design and, if necessary, modify scripts and design specifics   Review Test Results

The proof of concept test results should discuss specific issues with all defined tests. Note what problems were resolved and those that were referred to a vendor. The test results should be utilized to make changes to the current infrastructure, security and management specifications developed so far before moving on to the design proposal.

Shaun Hummel is author of Network Planning and Design Guide available at amazon.com and CiscoDesignBooks.com featuring Networking Books, eBooks, Certifications, Articles and Design Tools.