Design Decisions

Russ White created his own Rules of Network Design. It has great principles for thinking about design decisions. My blog on network design from 2017 gives practical tips on what has worked for me.


I have been designing networks and services for the last 15 years. Along the way, I have learned and created a workable strategy for network design, implementation, and development. By implementing these themes, I have been able to respond quickly and smoothly to the company’s ongoing networking needs, the demands of a fast-paced business initiatives, future uncertainty, and keeping network infrastructure and services up to date.

Don’t plan one solution

Right from the start, the most important thing: Always think about the whole picture. How does a single solution fit into the overall picture and how can you replicate the new solution to other needs? Rarely the solution now at hand is the only one, there will be probably more of the same. Don’t waste time and get frustrated by repeating the same design work over and over again. Think of a solution that can be replicated and reused right from a start. Try to leave the solution so open that it supports new use cases and extensibility as much as possible.

Look further

Think about where you are with this solution in a couple of years. As noted in the previous paragraph, the environment expands and disperses rapidly, even so much that you are beginning to lose control. See the picture of the environment in the near future and guide development and solutions towards it. How big has the environment expanded, how do traffic or user volumes grow, how are different things connected to the environment, and what new features can come along? You need a little fortune teller talent, but usually, you know something about what your organization does, what it needs, and what the direction is. Usually, things go according to the same formula as before. Always reserve room for growth and think about the expansion path in advance. This will make your life easier later.

Duplicate the same solution

Try to duplicate the same proven solution for many different environments and use cases. Often a particular solution works just fine, even if it is not specifically meant for that use or environment. In this way, you can apply common technologies to create new innovative solutions. It is useless to reinvent the wheel, the important thing is where and how you use the wheel. The same solution in many places usually greatly simplifies the operation and maintenance of services, and thereby also reduces operating costs.

Build modular

Divide the environment so that it consists of as independent interchangeable blocks as possible. This makes updating and changes easier when the entire environment doesn’t need to be renewed or changed at once. Modularity can also be implemented on a logical level, eg. in virtualization. Use multi-vendor supported standardized interfaces between modules and external parties. IP interface and routing is always a pretty bullet-proof choice having control point and measures to manage traffic properly.

Make continuous improvement

To keep the environment up to date, it needs to be constantly developed and updated. The bigger the environment, the harder the job. Update your network infra a little upfront so you don’t fall behind and increase your technical debt. The problem may be funding. How do you justify ongoing replacements? It’s probably easier for everyone to make smaller changes more often than a massive renewal project rarely. The modular design helps, so you can just replace one block at a time and keep investments moderate. Keep the big picture in mind and steer development in the desired direction. Manage the lifecycle of devices and systems, and plan and budget renewal needs for the next few years.

Be one step ahead

In a fast-changing world, you won’t survive without knowing what are your design options and their pros and cons. Keep track of industry developments and products so you know what are the right solutions to think about over the next few years to come. Apply those new ideas to your environment. When someone asks you to provide a solution, you have a few workable options in your pocket already. You may be even able to offer a solution directly, or at least you are on the right track which way to go with your design and testing.

Invest in new technology

Don’t buy old. Choose new products from fresh models with years of continuity and development cycle ahead. This often involves some technological risk and uncertainty. But don’t be too wary with new technology, otherwise you’ll be constantly lagging behind and it’s hard to catch up later. Newer technology usually provides better outcomes. Think about when you should start from a clean slate, throw old system away and build completely new one, rather than trying to reconcile new and old technology. Use well-known simple and loose standard interfaces for interconnections if needed.

Use common technology

Choosing commonly used vendors, device models, and technologies will make your life easier. Well-known vendors tend to have more resellers, support options, the broader community, and better product lifecycle estimates. The importance of the user community should not be underestimated. Many times, a large user base provides community support more easily, better, and faster than the vendor or reseller through official channel. Widely used De facto technology standards are usually emerging in the industry. Follow what and how others are doing things globally and choose the one that fits you best. Also, think about the whole picture. Technology is only a part of the solution and technically the best or fanciest choice is not always the winning solution.

Don’t be afraid of vendor-lockin

Small and medium-sized organizations don’t afford to use multivendor networking. It makes sense to choose one vendor for each function. If you use the same device model as much as possible, you will get a consistent network platform and it will be much easier to provide services and operate it. You can also make use of vendor-specific features and solutions without hesitation if the network or part of it is replaceable with other vendor and product later. Again the modular environment and standardized interfaces help here.

Make it simple enough

The old saying KISS (Keep it simple, stupid) has inflated and I am not a full supporter of it. Networks are complex distributed systems and need complex technology also. My instruction is to make well-functioning fault-tolerant solutions that is simple enough. Too simple or complicated is not beautiful, let alone functional. Avoid clumsiness, tuning and nerd-knobs. Find working, commonly used, and proven solutions to which is good enough.

Segment rationally

Segmentation is often a security issue, but in the network functionality it is worth considering through the failure cases. How is the potential failure reflected in the entire environment and what is the impact aka. blast radius? How do I ensure control and visibility in the event of a failure? Physical separation of devices is a balance between cost, manageability, and usability. Modularity and the use of IP interfaces help with the segmentation. Don’t put all the eggs in the same basket, or at least think of a backdoor if everything collapses.

Make redundant

Don’t miss the redundancy, or it will eventually bite you. Everything is fine just as long as everything works. Don’t believe others, but make everything redundant as far as possible to cover your back. Even small pre-identified and accepted risks often lead to a big fuss when services don’t work. In practice, amazing failures happen. You may not have been able to imagine what could go wrong. Proper decentralization and redundancy is an easy way to save services in a variety of failure cases. Think of a solution so that a single failure does not crash the end-to-end service. Physical separation is better than increasing the fault tolerance of a single device. Be sure to test the redundancy on service and application level.

Know your service

Finally, a reminder that networking people need know services and their features that are run in the network. Nobody else is often able to tell you things accurately enough. Network is the glue of the IT and networking people are usually the ones who understand the whole system from infrastructure to applications. Therefore networking people have the enormous potential to succeed in a converging environment of the future. The need to understand applications comes at the latest when a service layer problem needs to be resolved. There is always a fault in the network until proven otherwise. However, don’t make you a victim, but guide others through the secrets of networking. Knowledge is slowly spreading inside your organization and eventually pays off.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: