Data Networks Design

Introduction

Over the past few years, I’ve designed numerous communication networks and security systems, and I have come to appreciate the value of a systematic approach in avoiding unnecessary costs and technical issues. This article outline the essential stages of communication network design, covering how to define requirements, design network architecture, and detail each step for effective project management. In future articles, I’ll discuss financial design, procurement strategies, and best practices for technical and financial oversight.

Design stages

As with other domains, the process of designing a communication network and establishing its information security involves three primary phases:

1. Functional Requirements: This initial stage, often referred to as the Functional Description (FD) or Functional Specifications (FS), involves establishing the project’s objectives and determining what the network needs to accomplish. It’s all about defining the “what.”
2. Architectural Design: Next, the High-Level Design (HLD) phase focuses on the overall framework and guidelines for the network. This stage defines the big picture and how the different components will fit together.
3. Detailed Design: Finally, the Low-Level Design (LLD) provides the specific, concrete instructions for building and configuring the network. This is where you get into the technical details needed for practical implementation.

There is no official standard for the design approach I’m outlining, and different vendors often use their own terminology. While a quick search online will yield thousands of design document examples, particularly from manufacturers like Cisco, the core principles remain the same.

In the following sections, we will break down each design stage, outlining its requirements and expected outcomes. Although this framework can be applied to various fields, such as server or software design, our primary focus will be on communication networks and their security.

Functional Requirements (Functional Specification)

The purpose of functional design is to translate business needs into technical requirements. In simple terms, this is where you precisely define what you expect the project to achieve.

You’ll start by outlining the main project goals. This could be anything from improving network application performance or implementing and monitoring software to cutting costs or meeting specific information security regulations.

Functional requirements can be, for example (real examples from projects):

1. Equipment Replacement: The need to replace network hardware because it has reached its end-of-life (EOL) for product or service support.
2. High Availability: A business requirement for a more resilient network with a goal of achieving “five nines” (99.999%) availability, which translates to a maximum of about five minutes of downtime per year.
3. Data Privacy: The need to comply with regulations, such as those from the Privacy Protection Authority, which mandates the separation and security of databases.
4. Increased Bandwidth: The demand for more bandwidth to support a new, high-demand application from a software development team.
5. Network Segmentation: Regulatory requirements to separate IT (Information Technology) and OT (Operational Technology) networks for security and control.
6. Cost Reduction: The goal of reduce overall communication expenses.

The result of the functional requirements should be what we want from the network, with the requirements being defined in a precise way that will allow the planner to approach the design of the network architecture (Green field design) or the design of changes to the existing network (Brown field design). It is very important not to skip this step, and to define precisely what we need, so that later we can design the network according to the company’s needs and not plan (and especially pay for..) things we don’t need. We will prepare the functional requirements, because only we know what we need.

Network Architecture (High Level Design / HLD)

We have received the functional requirements, and now we know what needs to be addressed. The result will be the design of network architecture, or information security architecture, according to the requirements we have defined. This design will include everything required to understand how the system works, including documents, drawings in Visio or DrawIO, tables, etc., including (depending on the project, a partial list):

1. All components of the required system/network, including switches, routers, servers for control systems, etc., for example:
   • A control system will be run on a server that will be installed in the center of the network
   • Central FWs will be activated to protect the Data Center, and additional FWs will be activated to protect access to the Internet.
   • FW+IDPS protections will be activated on the central FWs, and full UTM will be activated on the FWs at the Internet exit
2. Location of communication components, including switches, routers, WAFs, Load Balancers, protection vehicles, etc., including a basic drawing of the required network, for example:
   • Location of routers in the network, survivability scheme between them (HSRP, VRRP, etc.), recommended routing protocols to work with, required survivability times, etc.
   • VLAN requirements (without VLAN IDs), traffic routing, traffic diagrams, for example between which VLANs routing will be defined and between which ones it will not be defined, etc.
3. What protocols will we use, including recommendations and an explanation of why these protocols were chosen (in case the document is released to potential suppliers, and we want to receive additional feedback on the design), for example:
   • The OSPF routing protocol will be activated on the internal networks, different VRFs will be defined for administrative and marketing networks, and PIM will be defined for the distribution of classified information on the network
   • Layer 7 filtering mechanisms will be activated on FWs for classified information, for regular information, an alternative path will be defined directly through the core switches.

The HLD document provides the working principles according to which the detailed design (the LLD) will be prepared. Who will prepare the document? This is a somewhat sensitive issue, and there are two options.

Option 1: The Provider Designs to Your Requirements

In this approach, you’ll prepare the functional requirements and have the project provider handle the network design. You might, for example, specify a backup time of less than 50ms or require specific network parameters like bandwidth, delay, and packet loss.

The main advantage is that the provider is responsible for meeting your strict conditions—the “how” is up to them. However, a significant drawback is that you have less control over the final solution, and you’ll need to meticulously verify that their design truly meets your needs.

Option 2: You Design, and the Provider Implements

In this scenario, you take full control of the network design, and the supplier is then tasked with providing a solution that adheres to your specifications. You can build flexibility into the design, perhaps by offering two different network configurations or allowing for the use of various protocols.

The primary benefit is that you define exactly what you want, ensuring that the proposals you receive from suppliers are a perfect match. The downside, however, is that you carry the burden of confirming that the final solution aligns with your design. If any issues arise, the supplier can’t be held accountable for a plan they didn’t create.

The Best Approach

The best approach is a balanced one. Start with an initial design, then gather feedback, perhaps through a Request for Information (RFI). Use this feedback to refine your functional requirements and guidelines. The exact process can be adjusted based on the specific project. While procurement is a complex topic that deserves its own article, I’ll touch on it briefly at the end.

Example of a network drawing in the HLD phase:

The drawing describes an example of the required network structure, proposed location for FWs, bandwidths of the interfaces, locations of VLANs in L3 and connection to servers. From here you can continue to the detailed design

Detailed design (Low Level Design / LLD)

The detailed design includes all that is required to operate the system, from the procurement stage to the stage before acceptance tests, including: equipment specifications, documents, configurations of equipment, software versions, VISIO drawings, tables, etc., including:

1. Server design details: server names, roles, IP addresses, VLAN assignments, services/software running, main and backup servers, for example:
   • List of servers on which ESXi is installed
   • IP address
   • Main or backup server
2. Detailed design of the communication network, including VLANs, IP addresses, routing tables, protocols, etc., for example:
   • Switches and routers – configuration (interfaces, ACLs, protocols, and everything required for full operation and protection of the equipment)
   • Flowcharts with VLAN numbering, routing tables, addresses, Unicast/Multicast flow flowcharts
3. Provide detailed information on security design, including rule settings in firewalls, additional protection component configurations, rule definitions for anomaly detection systems and so on. For example:
   • Complete configuration files for communications equipment
   • Comprehensive rule-based files for firewalls
   • Policy definitions, specifying authorized parties for communication and relevant applications
4. Complete hardware and software specifications include what is installed on each component, connection diagrams between components, etc. For example:
   • Information flow diagrams within the various systems
   • Information flow diagrams between systems

Any topic related to how the system and all its components work, including explanations, drawings and tables, as required for a full implementation of the project by qualified engineers.

It is a common question whether configurations should be included in the Low-Level Design (LLD) documentation. An LLD enables a qualified technician or engineer to install, configure, and operate the network independently, without requiring supplementary documents. Configuration files, such as “show run,” may be appended to LLD or provided separately, either concurrently or following deployment. The essential requirement is that the LLD must accurately specify all actions necessary to ensure full network functionality. Additionally, it is recognized that configuration adjustments may occur throughout the duration of the project.

In the following example, we see an address table (reduced, part of a much larger project):

This table and other tables explain exactly which addresses to configure, and together with accompanying drawings, whoever installs the network knows exactly which addresses to configure. If we take the first table (R-Site-1) for example, we see the router interfaces, where LAG / MC-LAG is defined, which interfaces are defined in TRUNK, address ranges, addresses, and explanations.

Additional processes and documents

In an orderly process of designing and executing a project, there will be a few additional milestones that we will have to go through.

At the beginning of the project, it is possible, and for projects with unique requirements, it is also recommended to request proof of the working capability of what is required (Proof Of Concept / POC), which is designed to check whether the response we received meets the requirement.

For projects with some complexity, consider a phased rollout. A pilot program, which can be as simple as a test run in a single department or branch, allows you to gradually implement the new system and test its capabilities before a full-scale deployment. Depending on the project’s scope, you might even want to run a second pilot to further refine the process.

After the installation is complete, you’ll need to define an Acceptance Test Plan (ATP) to verify that the project meets all the initial requirements. This plan should include several types of tests:

• Go/No-Go tests to determine if the system is stable enough to proceed.
• Functional tests to ensure the system meets specific requirements, such as survivability.
• Performance tests to check that the system operates efficiently under various conditions.

When working on communication network or cybersecurity projects, you’ll encounter some standard project management terms. The process typically begins with a Preliminary Design Review (PDR), where the High-Level Design (HLD) is presented. This is followed by a Critical Design Review (CDR), where the Low-Level Design (LLD) is typically reviewed. While there are many other steps in project management, these two are key to the design process.

How does all this fit into the procurement process

Procurement can be a complex process, but it’s crucial to get it right. In many of the projects I’ve worked on, the scope shifted dramatically after the initial requirements were defined.

For example:

• A project to replace dozens of routers with firewalls ended as a simple ACL update after a closer look at regulatory requirements.
• An SD-WAN project became a standard router installation because the customers’ needs weren’t as complex as initially thought.
• A multi-tenant project worth tens of thousands of dollars was scaled back to a basic software protection project.
• A cellular network with MPLS and BGP-VPNs was simplified to a network with simple OSPF configurations.

To avoid unnecessary costs and project scope creep, it’s essential to precisely define your needs. Always verify your requirements, consult with colleagues, and double-check everything. Small errors like miscalculating licenses or an inaccurate load test can significantly increase the project’s cost.

Summary

Although the process may be extensive, ensuring that the design is organized with a well-defined sequence of steps is crucial for establishing a network that operates both efficiently and securely, providing clarity from initial planning through to implementation.