Network Design 101: Scratching the surface


Most of us have been several times in that place where we - as network engineers - contemplate a network diagram and have several questions come to us like lightning strikes: “Is this the best way to do it?” “Could it be improved somehow?” “What if?”

In this write-up I intend to give an introductory view of network design and share situations and conditions that could be present in the process. These situations would affect the final result of a design and, having them in mind along with the correct mindset, would turn the table in your favor.

The goal of this post is to highlight considerations, benefits, drawbacks, when architectures are followed to create a network design, and what could happen when conditions in the environment change. It will not dig deep in a technology discussion from an implementation point of view, as design is not an exact science, and goals can be accomplished in several ways.

Network architecture and network design

In the process of writing this post, several experts gave their support to check and validate the information poured into the following lines. I encountered an interesting debate about the meaning of the words “architecture” and “design” when applied to networking. As a result of being a process that involves several visions, technologies, and perspectives, the corresponding definitions don't have a clear and exact meaning for everybody. They clearly may and will vary depending on roles and people involved. All the contributors were right from their point of view, and the next paragraphs are a result of their advice, knowledge, and experience.

According to The Open Group Architecture Forum (TOGAF), which is a framework followed for developing an enterprise architecture, the term "architecture" is defined in the following ways:

  1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007).

  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

And specifically, when referring to technology architecture, it's described as follows:

Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

Doing a quick change in the wording, hopefully to make it easier to swallow without losing the main goal behind the concept, we could see the architecture as “the big picture,” whose main goal is to envision the network being molded, sculpted, and shaped from its actual state to its ultimate state. When designing a network, it all comes down to creating something that should fulfill business needs/requirements and application requirements within constraints. The process of carving, etching, and creating the network is what we could call network design.

Environmental approach

There are two possible scenarios we can run into, and it's important to highlight the approach needed when dealing with them. Those scenarios could be described in the following manner:

Greenfield: A greenfield is an environment that does not posses any constraint imposed by a previous work. In other words: it's the environment where you start from scratch and build everything from the ground up.

Brownfield: Unlike greenfield, a brownfield is an environment that does have constraints imposed by a previous work. A network already established that needs to be modified while being in production. This is the common case you would find in real world.

The difference in the approach for both scenarios lies in the conditions where they are exposed. Following previous terminology, in a brownfield environment, the network needs to be sculpted to meet business and application requirements, having in mind that there are previous constraints already in place because of an existing design and an already operating infrastructure. On the other hand, when dealing with a greenfield environment, as the network is designed from scratch, it's carved and then delivered, already meeting the requirements considered for its conception from the beginning.

As stated previously, the way we can carve the network is only possible if we know what shape we want it to have; in other words, an artist cannot mold a sculpture without a shape in mind or an inspiration to follow. This is the moment when interaction with the business is required.

To know which design model to follow, which technologies and topologies to implement and how to do it, we need to interact with business. Whatever the implementation intended, it needs to be clear from the beginning about what the business needs are. This phase could be challenging, as there are several visions given by management and technical staff.

Making use of analogies here: If you were to ask technical staff what is needed, you would get a requirement with a budget similar to buying a Ferrari. But, when you go to management with those requirements received from the technical staff, they would have (most probably) enough budget to buy a Kia. Even though everybody (technical guys) would like to have a network that goes from 0 to 100Kmph in 3 seconds (who doesn't?), it's not always the best decision, or even the possible or necessary one, according to business. The wise procedure would be to coordinate meetings to get information and mix the best of two worlds. What are the business needs and how are they accomplished from a technical perspective? What would be the outcome of implementing certain technology over another?

With those requirements in mind, we can design a network having certain technologies working together to accomplish our goal or goals, which should include enabling the network we are designing to deliver the services needed by the applications and allow business to generate revenue.

Businesses often decide to go for the Kia because of budget reasons, and then a major break happens, and fixing it costs the same as the initial Ferrari proposed, or even more. It's always a matter of projection. The discussion should be done with present and future in mind. Technologies that could be adopted in the future and expected network growth are examples of these considerations.

It’s worth mentioning that, as network design is not an exact science, you can’t find an ultimate solution that would work flawlessly for all possible cases, but it always comes down to the specific needs and requirements. The only wrong design is the one conceived without considering business and application requirements. Of course, as requirements, there will also be constraints. Examples of these elements are: legacy technologies already implemented to be considered (compatibility/interoperability between technologies), single-vendor/multi-vendor environments (vendor specific technologies/open standards), economical constraints (limited budget), geographical constraints (where are devices located, service providers available locally, WAN transport availability), application requirements/constraints (jitter sensibility, reconnections, TCP/UDP-based, multicast/unicast transport required, data encryption), and many more details that you should be familiar with would affect the result of your design.

Network design principles

Additionally, along with requirements and constraints, an ideal design should (but doesn't always) possess the following principles as the foundations for its conception:

Hierarchy: It's always ideal to break a big design into smaller areas/layers, have clear segmentation between areas, assign functions to them and devices composing each one of them. Function or functions being executed by each device must be clearly defined.


Modularity: Implementing hierarchy also enhances modularity. As network and functions are divided into several modules/areas, failure domains are limited to certain areas. This means that a failure (hardware/software/link) in a given module/layer/area would represent an impact that affects the area itself and may or may not affect other parts of the network.

Scalability: The capacity the network would have to grow without affecting functions belonging to its module or any other layer or module. Relying also on modularity, making the network grow would be a matter of adding another module.

Resiliency: Guarantee that the network would be highly available to meet users or business expectations about a permanent service offering. The network should be able to work under normal and abnormal circumstances (e.g. device/link/software failures, huge traffic loads, DoS attacks) and scheduled events (eg. maintenance windows). Accretion of availability can be accomplished in several ways; one of them is to have redundant connections between failure domains (these connections are called choke points). This would reduce the time the network would take to recover from a failure and forward traffic around it to guarantee service offering over adverse conditions.

Flexibility: Be able to modify sections of the network, add new technologies and modules, and make protocols work together without having to make a major modification.

Keep in mind that the business could decide to make a sudden change in the design, which would lead to the following questions: is your network design flexible enough for this? Can you make changes without redesigning it completely?

To prevent twists like the one described above, it's important to set the scope and goals of the design, along with constraints, as early as possible. If a new requirement is raised after this, there must be an agreement with the client about how to integrate it with the current design and how it will affect the whole process agreed before (schedule and pricing do matter).

Final thoughts

This blog was intended to explain the design mindset, the thinking involved, and the reasons behind it, along with a taste of real world situations and conditions that do really happen. The idea is to spread the word and to let people know that design is not just putting boxes together to make traffic flow and lights green. It's a process that requires deep thinking, preparation, and analysis.

I hope it somehow helps to clarify doubts. After an extensive review of related literature, I thought this would be a way to put everything together, give a brief introduction, and help to understand topics or terms that could be confusing or hard to catch.


UPDATE: Spanish version can be found here: Vuelo Rasante Sobre el Diseño de Redes