Network Design and Validation: IT Matters

With the complexity of our industry, two things should be obviously necessary. These two things are Network Design and Validation Testing. Design requires identifying the requirements of the business and of dependent systems. This could include things like minimum bandwidth, maximum jitter, convergence time, recovery time, minimal redundancy, etc. It is also important to understand that more rigorous requirements often contribute to cost and operational complexity. Operational complexity creates additional challenges that often erode the very parameters that have been identified as requirements. When this is found true, there are some conversations that need to be had about what is and is not achievable, given the operational and capital budgets–as well as the realistic capabilities of the staff managing the environment.

Validation is also critically important. I posted an article a few weeks ago that illustrated an interesting failure with CAPWAP. Avoiding issues like this require us to first design our network then validate the behavior against the design. Allow me to make a bold statement–If you haven’t designed and validated your network, you DON’T know how it works. Without validation–How do you know that your convergence is subsecond? How do you know that your backup routes work with applications? How do you know that you aren’t introducing unexpected asymmetry that is yielding your IPS even more useless than encryption? The answer is that you don’t know.

You don’t know that the wrong HSRP peer is active, that a switch in some closet is the STP Root, that RSTP portfast is not set up correctly, that LDP Sync was omitted, that NSR/NSF has been overlooked on that VSS pair, or that a bug exists in a key feature since the last upgrade. Maybe you are just that good, but my guess is that none of us are. There are so many things that can lead to unexpected behavior. Therefore, we MUST test against anything that is truly a requirement and part of our Design.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

Readers of this article may also enjoy:

  1. Failure Analysis: An Interesting way to Break CAPWAP

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Other. Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.