Network Design and Proof of Concept Testing
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.
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
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.
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.
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 the author of
Network Design Fundamentals
More Network Troubleshooting and Support Articles:
• Calculating VoIP Bandwidth
• Wireless Network Troubleshooting
• Steps For Designing a Crisis Management Plan
• Network Log Collection and Monitoring
• Network Cabling Design
• Incredibly Bad Network Designs That Still Work
• How Snort's Stealth TCP Port Scanning Works
• Fiber Optics Troubleshooting
• SME Network Internet IP Addressing Strategies
• Turning Names (URLs) Into IP Addresses