Network design overview: goals, the hierarchical model and design methodology

Why networks must be designed

Networks connect people, applications and the services a business runs on. Online customers expect service around the clock, so networks must be available almost 100% of the time, protect themselves against security incidents, and keep application response times steady as traffic changes. Joining boxes together without a plan no longer works.

Good networks are the result of deliberate work. A proven sequence is:

1. Confirm the business goals and technical requirements.
2. Decide the features and functions needed to meet them.
3. Assess whether the current network is ready.
4. Write the solution and a site acceptance test plan.
5. Create the project plan.

The four fundamental design goals

• Scalability: the design can add users, sites and applications without hurting service for existing users.
• Availability: consistent performance 24/7; one failed link or device should not cause a significant outage.
• Security: built in from the start, not added later. Plan where firewalls, filters and security devices sit.
• Manageability: the staff you actually have must be able to run it. A design that is too complex will fail in practice.

The hierarchical model

• Core: moves traffic between distribution blocks as fast and reliably as possible. Keep it simple: avoid slow processing here such as heavy access lists, encryption or address translation.
• Distribution: the boundary between core and access. It applies policy (access lists, filtering), summarises routes, routes between VLANs and controls what reaches the core.
• Access: where users and devices connect. It controls entry with port security and access lists, provides PoE and can connect remote sites over WAN links.

Smaller networks often use a two-tier (collapsed core) design, where one pair of switches does both the core and distribution jobs. Like the OSI model, the hierarchy is a conceptual framework: it makes the network modular, so parts can be added, replaced or removed easily.

Modular enterprise architecture

Large designs are split further into modules, each with its own role:

• Enterprise campus: everything needed for users at one campus or branch.
• Data centre (server farm): protects servers and gives them redundant, high-speed connectivity.
• Enterprise edge: where traffic enters from the internet, WAN and partners; it filters external traffic and routes it inside.

Modules make the design flexible, and they make implementation and troubleshooting easier because problems stay inside one block.

Design methodology

• Identify requirements: separate business goals (how the network helps the business succeed) from technical requirements (how the technology must behave).
• Characterise the existing network: collect and analyse information about what exists today and decide what equipment, cabling and protocols can be reused.
• Design the topology and solutions, using a top-down approach: start from the applications and services, then design the network to support them.
• Prototype or proof of concept: test the design in a lab or pilot site before full rollout.

Real-world example: redesigning a college campus network

A further education college had grown its network one building at a time, and outages in one block often affected the others. The new design started at the top, with business goals rather than equipment: online exams must not fail, the network must support twice as many wireless devices within five years, and student and staff traffic must be separated.

The design team chose a hierarchical layout with a redundant pair of core switches, a distribution pair in each building and access switches on each floor. Each building became a module that could be upgraded without touching the others. Before the summer rollout, the team built a prototype in the lab with two buildings' worth of equipment and tested failover, VLANs and routing. Problems found in the lab, such as a spanning tree setting, were fixed before anyone was affected.