• 09/17/2013
    6:54 PM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

9 Immutable Laws of Network Design

Follow these simple rules to ensure your network is stable, secure and built to last as you overlay new services and applications.
Each year, my company has the opportunity to work with many clients on their network architectures, designs and configurations. We also work with clients when they have network issues and need troubleshooting assistance. Based on those many years of experience with a variety of environments and customers, I've developed this list of nine immutable laws of network design.

Following these simple rules helps you create and maintain a stable, long-lasting network infrastructure that will be invaluable as your organization begins to overlay additional services or applications. Whether you’re redesigning for wireless, preparing for software-defined networking (SDN) or simply expanding your virtualized environments, designing by these rules will increase the stability, manageability and security of your network.

1. Know, Don’t Guess

Two phrases uttered frequently during network design are “I’m pretty sure” and “I think.” As a professional tasked with discovering, researching and documenting client networks, I can tell you those phrases don’t cut it in our organization, and they shouldn’t be accepted in yours. There’s more than a 50% chance what you think you know is wrong. Networks are inherited, many admins may touch them, and they’re frequently changed in a fit of fury, troubleshooting or testing. When documenting a network or committing even a minor change, you should always look, verify and know--never guess. The mantra in our office is, “No information is better than wrong information.”

2. Avoid Dangling Networks

As SDN, virtualization and application-based technologies creep into our networks, we need to take a hard look at configuration sprawl and prepare for a massive cleanup. Avoid dangling and mismatched networks and VLANs throughout the infrastructure. It’s not unusual to see VLANs tagged where they should be untagged, or a VLAN dead end into an untagged VLAN. There are some instances of think-outside-the-box moments where a configuration like this is needed, either for a transition period or to work around a specific situation, but the practice should be the exception, not the rule.

3. Route Where Needed, Not Where Possible

Routing at the edge sounds like an advanced approach to network architecture, but it can cause more problems than it solves. Sure, you may get some additional speed, but in most networks, that speed will never be measurable, and the complexities of overly distributed routing lead to management and security headaches.

4. See All, Manage All

You certainly can’t manage what you can’t see. Visibility into the network has always been important, and it’s going to be even more essential as networks evolve to solve the demands of virtualization and applications. Know what you have, where it is, and monitor it constantly.

5. Know When To Standardize

There are times when standardizing offers great advantages, and other times when it will be working at cross-purposes to your objectives. This might mean standardizing on a single vendor for interoperability, or it may mean standardizing on configurations, security settings and management. Either way, make sure your choice is serving a purpose and providing flexibility as your network grows in the future. Don’t get pigeonholed in to a single-vendor solution when the costs outweigh the benefits, and don’t miss opportunities to standardize on platforms that can increase effectiveness of management and security.

[ Common errors like mismatched masks and duplicate IPs can spell disaster on a network. Find out the top mistakes to avoid in "The 10 Deadliest Networking Mistakes."]

6. Layer 1 Is King

Your sleek new infrastructure of VLANs and virtual devices is complete trash if the foundation of your network is faulty. Layer 1 is king, and disruptions in Layer 1 still contribute to a huge volume of detrimental network outages. As network capabilities develop and grow, Layer 1 requirements will evolve and remain the most critical consideration.

7. Simple Always Wins

Just because you can do it doesn’t mean you should. Labs and test environments are the place to play and think outside the box with your configurations. In an enterprise production environment, you’re best served following the K.I.S.S. model, and keeping your network as simple as it can be while maintaining the required connectivity and security.

8. Power Is Important

To say we’ve been spoiled in recent decades with our power sources seems strange, but it’s true. As power demands increase with newer technology, availability and consistency of power is more critical than ever. The addition of virtualized machines and software-based appliances that are more sensitive to power issues compounds the problem. Oftentimes, power issues can cause widespread network disruptions without ever triggering an alert. Clean, conditioned, consistent power used to be a luxury, but is now a necessity in the network.

9. Embrace Documentation

You may have flashbacks of writing book reports in high school, but maintaining documentation on your network is the easiest way to ensure you’re following best practices, tracking changes and creating the means to troubleshoot effectively. As we layer on more technology and applications, documentation will increase in significance. Embrace it, live it, love it, do it. Twenty minutes of documentation now, even if you feel you don’t have 20 minutes to spare, may save you 20 hours down the road.

Do these rules resonate with you? Are there any you would add to the list? Please add your comments below.

[Find out how to eliminate unnecessary network traffic, ensure you get the throughput you paid for, and rid the network of packet loss in "11 Things You Can Do When You Get Back to the Office to Improve Network Performance." at Interop New York Sept. 30-Oct. 4. Register today!]


Network Design Basics

I'm currently taking a network infrastructure basics course and the 1st assignment is a network design project. Is there a resource for network design that isn't guessing? I often feel these assignment are so vague that there is no "right" answer. :/

Great Tips
This an excellent article! I have shared it with quite a few people just because of the simplicity of it and how easy it is to read. Thank you
Been a while, but for SDN this needs to be mentioned....

It has been a while since I have seen this; however, a lot of these are simply not "immutable laws". I could get into picking this to pieces; however, I am going to pick on #3 because it flies in the face of current best practices for reducing broadcast domains, eliminating spanning-tree, and all but opposite of design for SDN.

Routing at the edge is far superior than layer 2 at the edge with routing at the core. Not only is this applicable in the Data Center this is applicable in the enterprise network. For one obvious reason, reducing the broadcast domain to smaller segments, isolating spanning-tree to smaller, more local segments, and utilizing more industry standard ECMP algorithms to avoid the ugly "polarizing" nature of layer 2 port-channel hashing (all because you bundle 4 10GbE links doesn't mean you have 40GbE available bandwidth).

Also, with layer 3 designs, both DC and enterprise, your VLANs become locally significant; thus, you can reuse VLAN IDs and implement more standard "cut-n-paste" deployments without worrying about duplicate VLAN IDs. Also, you're preventing spanning-tree loops from taking out your entire network when your DC or campus network is interconnected at layer 2. Layer 3 is also VERY predictable, especially when sticking to link-state routing protocols like OSPF and IS-IS or the slow, but trusty, BGP routing protocol. If you have a failure in your layer 2 environment, are you positive what the next step your network will take following a topology change?

Finally, SDN, especially with NSX, where you've made the network layer a commodity and not a differentiated service, is reliant on layer 3 because of all the aforementioned benefits and scalability of layer 3.

For the longest time we have tried to extend layer 2 using all types of technology to reduce spanning-tree and its many headaches. First we had overlays, such as NVGRE and OTV, with OTV winning the contest for layer 2 extensions and for DCI over a standard layer 3 link. Then came SDN, namely, VXLAN, and now we've reduced layer 2 to a virtual overlay segment which rides over a, GASP, a collapsed CLOS layer 3 environment!

I think the industry has spoken on #3, routing wherever possible is the way to go because the additional configuration required to get OSPF running is minimal at best but provides an overwhelming number of benefits to any network, DC or campus. If the "complexity" argument is used I would say you're guilty of of the Appeal to Complexity fallacy and not taking into consideration most switch vendors offer excellent OSPF deployment best practices and training on the protocol. Also, #2 mentions SDN but mentions only layer 2, which is entirely irrelevant in a SDN environment using VXLAN.

Thus, I propose these are not "immutable laws" and should just be "Guidelines for largely layer 2 networks" because #3 basically brings it all together to name this article as such.