Network Design

Good network design begins with requirements, not equipment. Hardware models and protocols should be selected only after the business needs, traffic patterns, failure tolerance, security boundaries, growth expectations, and operational constraints are understood.

Gather Requirements

• How many users, devices, racks, sites, and tenants must be supported?
• Which applications are latency-sensitive or bandwidth-intensive?
• What level of downtime is acceptable?
• Which systems require isolation?
• What internet, WAN, and cloud connectivity is required?
• How quickly is the environment expected to grow?
• Who will operate the network and with which tools?
• What budget, support, licensing, and hardware-lifecycle limits apply?

Design for Failure Domains

A failure domain is the portion of the environment affected by one failure. Redundancy is most useful when redundant components do not share the same hidden dependency.

• Two switches on one power circuit are not fully redundant.
• Two carriers entering through the same conduit may fail together.
• Two virtual routers on one hypervisor share a host failure domain.
• Two firewalls with a shared configuration error can fail logically at the same time.

Keep the Topology Understandable

Every layer, protocol, and appliance should solve a defined problem. Simpler designs are usually easier to operate, secure, and recover. Complexity is justified when it materially improves scale, resilience, security, or automation.

Address Planning

Address plans should allow summarization and growth. Allocate contiguous blocks by site, rack, tenant, or function rather than assigning the next available subnet at random.

Layer 2 Boundaries

Stretching VLANs across large distances increases the blast radius of loops, broadcasts, and control-plane failures. Route between logical zones whenever possible. Extend Layer 2 only when an application or migration requirement truly needs it.

Redundancy Choices

• Device redundancy: Multiple routers, switches, firewalls, and power supplies.
• Path redundancy: Diverse uplinks and carrier paths.
• Protocol redundancy: Dynamic routing, first-hop redundancy, and rapid failure detection.
• Service redundancy: Multiple DNS, DHCP, authentication, and monitoring systems.
• Operational redundancy: Backups, out-of-band access, spare hardware, and documented recovery.

Capacity and Oversubscription

Not every access port will transmit at line rate simultaneously. Oversubscription is normal, but it should be intentional. Examine east-west traffic, backups, replication, storage, virtualization migration, and internet demand. Monitor actual use and preserve enough headroom for failures and traffic growth.

Security Architecture

Define trust boundaries during design rather than adding security after deployment. Identify management, server, user, guest, backup, public, and tenant zones. Decide which traffic must pass through stateful inspection and which can be controlled with routed ACLs.

Operations and Lifecycle

• Standardize configuration and naming.
• Select hardware with an understood support lifecycle.
• Ensure licensing costs are sustainable.
• Collect logs, metrics, and flow data from the beginning.
• Back up configurations automatically.
• Document normal failover and maintenance procedures.
• Design an out-of-band management path.

Documentation Deliverables

A network should have documentation that remains useful during an outage:

• Logical topology diagram
• Physical cabling and rack diagram
• IP address and VLAN plan
• Routing and security policy summary
• Carrier circuits and contacts
• Device inventory and software versions
• Change, rollback, and disaster-recovery procedures

Change Planning

Design Review Questions

• What happens when each link, device, power source, and provider fails?
• Can operators reach the environment during an in-band network outage?
• Can routes and addresses be summarized?
• Are trust boundaries explicit?
• Can the network be monitored and backed up?
• Is the design still understandable to someone who did not build it?