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.