Network Design — Keeping it simple

Since the dawn of time people have skirted best practice and banged together networks, putting the proverbial square peg in the esoteric round hole. For example, new vendor XYZ’s solution has brought in new requirements for deployment. While it may seem easier for to throw together a new firewall, a switch, and maybe some additional routes, and of course Tom ‘s favorite… NAT — but where does it stop!? As you continue to pile layer upon layer into your uninspired network design you will soon realize that your “beautiful network” has become the ugly duckling that you need help fixing.

That leads me to my first point. Complex systems are expensive, not only in CAPEX, but in OPEX. When you design and build a network, you have to ensure that you are not building something that no one else has dreamed up, or else your problems will also be unique. And without the additional money to hire top tier engineers, you could be short staffed, or worse yet, facing the problem on your own. The more complex your network becomes, the more likely it is to fail. As I’m often quoted as saying, “The complexity required for robustness, often goes again robustness…”, and those systems are often replaced.

As you build upon your complex design, your entire network, once agile because ridged and unable to adapt to changes. While you have to learn to understand that no single design can last for ever, the simpler designs tend to be more flexible and adaptable into your ever changing needs. You have to remember that your network is not just there to serve the end users, or systems. Your network is in the middle of everything your company does and has to be able to mold itself to fit the businesses ecosystem.

Design flexibility starts with simplicity, but also requires adding complexity when it comes to redundancy. Without redundancy upgrades and maintenance impact core services, those impacts could force bad policy into place making it impossible for you to do you maintenance. I’ve worked on far too many enterprise networks that suffer from lack up maintenance windows, which only ends up making the problems worse.

Last, but certainly least I want to talk about testing. One of the biggest things I learned at my last job is that no matter how meticulously you designed your system, no matter how much redundancy you think you have, all of that has to be tested on a regular basis. Changes happen, and it always seems that no matter how much documentation you have, something is going to be left out. The only thing that is going to find these problems is real life, end to end testing… LDAP connections for your VPN, DNS issues, vendor configuration issues, everything that is critical for your business to function needs to be well documented and tested.