Network Design, Performance and Lifecycle Decisions

Introduction

Network design is the disciplined process of converting organisational goals into a reliable, secure, maintainable and economically justified communications system. It is more than selecting switches, routers and cables. A sound design connects business requirements to topology, addressing, capacity, quality of service, resilience, operational procedures, contracts and eventual replacement.

A network may be technically impressive yet unsuitable if it is too expensive, difficult to operate, incompatible with existing systems or unable to meet service-level commitments. Conversely, a low-cost design may create unacceptable downtime, security exposure or poor application performance. Network professionals therefore make decisions across the whole lifecycle: requirements analysis, design, procurement, implementation, operation, optimisation and retirement.

This chapter presents a practical framework for making those decisions. It focuses on scalable topologies, IP addressing, device selection, performance engineering, redundancy, high availability, disaster recovery, cost, energy use, interoperability, procurement, service-level agreements (SLAs) and lifecycle risk.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Translate user and business requirements into network design requirements.
2. Select appropriate physical and logical topologies, addressing schemes and network devices.
3. Estimate capacity and interpret performance metrics.
4. Apply QoS, redundancy, high availability and disaster-recovery principles.
5. Compare designs using cost, energy, interoperability and lifecycle criteria.
6. Evaluate procurement documents, vendor claims, SLAs and operational risks.
7. Recommend a justified network design for a realistic organisation.

1. From Business Requirements to Technical Requirements

Design begins with questions, not equipment. Stakeholders may state requirements in business language: “staff must access the cloud,” “the warehouse cannot stop operating,” or “the new campus must support future growth.” The designer translates these statements into measurable technical requirements.

Important requirement categories include:

Requirements should be prioritised. A useful classification is must, should, could and will not. This prevents an attractive but unnecessary feature from displacing a critical requirement. Requirements should also be testable. “High performance” is weak; “maximum median application latency of 50 ms during the busy hour” is testable.

A requirements traceability matrix links each requirement to a design decision and an acceptance test. For example, a requirement for guest isolation may lead to a guest VLAN, firewall policy, captive portal and a test confirming that guest devices cannot reach internal subnets.

2. Topology and Architecture Choices

2.1 Physical and logical topology

A physical topology describes cabling and equipment placement. A logical topology describes how traffic is segmented and forwarded. The two need not be identical: several logical VLANs may use the same physical switch infrastructure.

Common forms include:

• Star: endpoints connect to a central switch. It is easy to manage, but the central device or uplink may be a single point of failure.
• Extended star or hierarchical star: access switches connect to distribution switches, which connect to a core. This supports structured growth and fault isolation.
• Ring: each node connects to two neighbours. Rings can provide path redundancy, but convergence and failure behaviour must be carefully engineered.
• Full mesh: every node has a direct connection to every other node. It offers many alternate paths but becomes expensive and complex as the number of nodes increases.
• Partial mesh: only important nodes have multiple paths. This is common in WAN and data-centre designs.
• Spine-leaf: every leaf switch connects to every spine switch. It provides predictable east–west paths and is widely used in data centres.

For a conventional campus, a hierarchical design commonly separates:

1. Access layer: connects users, phones, access points and local devices.
2. Distribution layer: aggregates access switches, applies policy and provides routing boundaries.
3. Core layer: provides fast, resilient transport between distribution blocks and major services.

Small sites may collapse distribution and core functions into one resilient pair. The correct architecture depends on scale, traffic patterns, skills and budget rather than on a universal rule.

2.2 Physical, virtual and cloud boundaries

Modern networks combine physical switches and routers with virtual switches, software-defined networking (SDN), wireless infrastructure, firewalls and cloud connectivity. The design must identify the control plane, data plane and management plane. Management interfaces should not be exposed unnecessarily to user networks, and administrative access should use strong authentication and logging.

Segmentation can be based on VLANs, VRFs, firewall zones, security groups or overlay networks. Segmentation is not automatically security: a VLAN provides a broadcast boundary, but policy enforcement and permitted communication must also be defined.

2.3 Addressing and naming

An addressing plan should support summarisation, troubleshooting, security policy and future growth. Private IPv4 address space is defined by RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. IPv6 uses a much larger address space and should be planned rather than treated as an afterthought.

For IPv4, a subnet with a prefix length of /p contains 2^(32−p) addresses. In a traditional subnet, two addresses are reserved for the network and directed broadcast, so usable host addresses are:

This formula assumes conventional IPv4 unicast subnetting and excludes special cases such as /31 point-to-point links and /32 host routes. For a /26 network:

An addressing plan should document subnet purpose, location, VLAN, gateway, DHCP range, reserved addresses, route summarisation and ownership. DHCP reduces manual errors for clients, while static or reserved addresses are appropriate for infrastructure that must be predictably reachable. DNS naming should be consistent and should distinguish production, test and management systems.

A good plan allocates space for growth. If a department currently needs 40 addresses and is expected to grow to 55, a /26 is insufficient because it provides only 62 usable addresses once all infrastructure and reserves are considered. A /25 provides 126 usable addresses and may be more appropriate, subject to summarisation and address-conservation requirements.

3. Selecting Network Devices

Device selection should follow traffic, interface, feature and operational requirements.

Performance claims must be interpreted carefully. A device’s aggregate forwarding rate may not equal encrypted throughput, application throughput or throughput with all security features enabled. Designers should ask for tested values under a stated packet size, feature set and traffic pattern.

Other selection factors include:

• interoperability with standards such as Ethernet, IP, IEEE 802.1Q VLAN tagging, 802.1X authentication and routing protocols;
• support for automation APIs, configuration backup and telemetry;
• software-update policy and security-vulnerability response;
• warranty, replacement time and local support;
• licensing model and feature dependence on subscriptions;
• noise, heat, rack space and power consumption; and
• skills required for safe operation.

Vendor diversity can reduce dependence on one supplier, but excessive diversity may increase training, spare-part and integration costs. Interoperability should be tested in a laboratory or pilot rather than assumed from marketing statements.

4. Performance Engineering and Capacity Planning

4.1 Key performance measures

Important measures include throughput, goodput, latency, jitter, packet loss, availability, utilisation and application response time. Throughput is the rate of transmitted data; goodput excludes retransmissions and protocol overhead. Latency is delay, while jitter is variation in delay. A network can have high throughput but poor user experience if latency or loss is excessive.

A link’s utilisation can be expressed as:

Both quantities must use the same units, such as Mb/s. If traffic is 600 Mb/s on a 1,000 Mb/s link, utilisation is 0.60 or 60%. Sustained high utilisation leaves little room for bursts, failures or growth. Engineering thresholds are context-dependent; a designer might establish an alert at 70% and a planning threshold at 80%, but these are policies, not universal laws.

Traffic generated by an application can be approximated by:

Packet size is in bytes and bandwidth is in bits per second. This approximation excludes or separately requires allowance for Ethernet, IP, transport and tunnelling overhead. For example, 10,000 packets/s with an average payload of 1,000 bytes produces:

The actual wire rate will be higher when headers and inter-frame overhead are included.

4.2 Demand estimation

Capacity planning should use measured baselines where possible. A basic forecast is:

This assumes a constant compounded growth rate and is only a planning approximation. If current peak demand is 400 Mb/s, annual growth is 20% and the horizon is three years:

A designer may then add a resilience and operational reserve, but should not conceal that reserve inside an unexplained multiplier. Forecasts should consider busy-hour peaks, backup windows, software updates, cloud traffic, wireless contention and failure scenarios.

4.3 Oversubscription

Access networks commonly aggregate many ports into a smaller uplink. An oversubscription ratio can be expressed as:

A 48-port switch with 1 Gb/s access ports and a 10 Gb/s uplink has a nominal 4.8:1 ratio. This does not mean the design will fail: simultaneous full-rate transmission may be unlikely, and applications may be bursty. However, critical workloads, storage traffic and predictable service objectives may require lower oversubscription or additional uplinks.

5. Quality of Service

QoS manages contention; it does not create bandwidth. A typical QoS process is classification, marking, queuing, scheduling, congestion avoidance and policing or shaping.

Voice and interactive video are sensitive to delay, jitter and loss. Bulk backup traffic is generally less sensitive and can use lower priority. Classification should be based on trusted boundaries and verified markings, because blindly trusting endpoint markings allows abuse.

• Classification and marking: identify traffic and assign a class or DSCP value.
• Queuing: provide separate queues for traffic classes.
• Priority scheduling: serve delay-sensitive traffic preferentially, while preventing starvation of other classes.
• Shaping: deliberately smooth traffic to a configured rate, often at a WAN edge.
• Policing: discard or remark traffic exceeding a rate.
• Congestion avoidance: manage queues before they become completely full.

QoS policy should be documented end-to-end. Markings may be changed at trust boundaries, and a priority queue without adequate bandwidth or admission control can damage other traffic. Testing should measure application outcomes rather than merely checking that a DSCP value appears in packet captures.

6. Redundancy, High Availability and Disaster Recovery

Redundancy removes or reduces single points of failure. Examples include dual power supplies, UPS units, redundant links, stacked or virtual-chassis switches, dual routers, dynamic routing, firewall pairs and replicated services. Redundancy adds cost and complexity, so each component should be justified by the business impact of failure.

6.1 Availability and downtime

Availability is commonly calculated as:

For a period with total duration T and downtime D:

If a 30-day month is treated as 43,200 minutes, 99.9% availability permits approximately:

This calculation assumes the SLA defines the measurement period and what counts as downtime. Planned maintenance, customer-caused incidents and force majeure events may be treated differently.

High availability requires more than duplicate hardware. It also requires independent power, diverse paths, synchronised configuration, tested failover, monitoring, operational procedures and staff competence. A pair of devices connected to the same power distribution unit is not fully independent.

6.2 Recovery objectives

A disaster-recovery plan defines:

• RTO (Recovery Time Objective): maximum acceptable time to restore a service.
• RPO (Recovery Point Objective): maximum acceptable age of recoverable data.
• MTTR (Mean Time to Repair/Restore): average time required to restore service.
• MTBF (Mean Time Between Failures): average operating time between failures for a repairable system.

These measures have different meanings and should not be used interchangeably. A service with an RTO of four hours may require a standby environment, documented recovery steps and tested backups. An RPO of fifteen minutes may require replication or backups at least that frequently.

Disaster recovery includes scenarios such as equipment failure, ransomware, fire, flooding, power loss, human error and loss of a provider. Backups should be protected from alteration, stored separately and tested through restoration exercises. A plan that has never been tested is an assumption, not evidence of recoverability.

7. Cost, Energy and Lifecycle Evaluation

Total cost of ownership (TCO) includes more than purchase price:

Capital cost includes equipment, licences, cabling and installation. Operating cost includes power, cooling, circuits, premises and monitoring. Support cost includes contracts, training and personnel. Transition cost includes migration, testing and decommissioning. Residual value may be zero, positive or negative depending on disposal obligations. The formula is a comparison model; all terms should use the same currency and evaluation period.

Energy matters financially and environmentally. Approximate annual energy consumption is:

A continuously operating 0.30 kW device uses approximately 2,628 kWh per year because 0.30 × 8,760 = 2,628. Annual energy cost is energy multiplied by the local price per kWh. Cooling and power-distribution overhead may increase the effective consumption.

Lifecycle planning should record purchase date, warranty end, software support end, security support end, configuration dependencies, spare availability and replacement lead time. End-of-support equipment presents security, compliance and operational risk even if it still functions.

A weighted decision matrix can compare alternatives. Criteria such as resilience, five-year TCO, interoperability, energy use, security capability and operational fit receive weights whose total is 100%. Each option receives a consistent score, for example from 1 to 5. The weighted score is:

Weights and scoring rules must be documented. A numerical score supports discussion; it does not eliminate professional judgement.

8. Procurement, Interoperability and SLAs

A procurement specification should describe outcomes and acceptance tests, not merely a preferred brand. It should state interface speeds, PoE budget, routing scale, security features, management protocols, logging, update commitments, support response and environmental requirements.

A request for proposal should require vendors to identify assumptions, exclusions, recurring licence charges, lead times, dependencies and end-of-life policy. Demonstrations should be validated against a test plan. Reference checks should address actual support quality, not only product performance.

Interoperability testing should cover:

• VLAN trunking and native/untagged-frame handling;
• routing adjacency and route filtering;
• authentication and authorisation systems;
• monitoring, logging and time synchronisation;
• IPv4/IPv6 coexistence;
• failover and configuration synchronisation; and
• backup and restoration of configurations.

An SLA should define the service, measurement point, availability calculation, maintenance windows, response and restoration targets, escalation process, reporting, service credits and exclusions. A response time is not the same as a resolution time. A vendor may answer a ticket quickly without restoring service quickly. SLAs should also address security incident notification, data handling and exit assistance where the service is strategic.

9. Governance, Ethics and Security

Network decisions affect privacy, access to information and organisational power. Monitoring should have a legitimate purpose, proportional collection, defined retention and controlled access. Users should be informed where required by law or policy. Packet inspection and identity-based analytics require particularly careful governance.

Designers should apply least privilege, separation of duties, secure management protocols, multifactor authentication, configuration change control and auditable logging. Procurement should consider supply-chain risk, counterfeit equipment, jurisdiction, vendor access and software provenance. Accessibility and continuity requirements should include users with disabilities and users who depend on assistive technologies.

Environmental responsibility includes selecting efficient equipment, extending useful life safely, reducing unnecessary capacity, consolidating workloads where appropriate and disposing of electronic equipment through approved processes.

10. Applied Case: Illustrative Regional College Network

Background

A fictional regional college has 900 students, 120 staff, three buildings, internet-based learning systems, voice services, CCTV and a small administrative data centre. The existing network uses flat addressing, unmanaged access switches in several rooms and a single internet router. Outages during examinations have caused financial and reputational damage.

Problem analysis

The college identifies four critical services: learning management, identity services, voice and examination administration. Guest wireless users must not reach internal systems. Peak internet demand is 650 Mb/s and is forecast to grow by 25% over three years. The college requires an RTO of two hours for identity and learning services and an RPO of fifteen minutes for examination data.

The current design has single points of failure, no documented addressing plan, weak monitoring and limited configuration backups. A flat network also increases broadcast scope and makes policy enforcement difficult.

Approach and solution

The design team proposes:

1. A resilient hierarchical campus topology with dual distribution switches and diverse fibre uplinks.
2. Separate VLANs and routed security zones for staff, students, voice, CCTV, management, servers and guests.
3. A documented IPv4 plan with reserved growth space and an IPv6 pilot for infrastructure and selected services.
4. Dual firewalls in a high-availability configuration and two independent internet paths where financially justified.
5. PoE access switches for phones and access points, with power budgets checked against worst-case demand.
6. QoS marking and queuing for voice and interactive learning traffic, with backup traffic shaped outside teaching hours.
7. Central monitoring, configuration backup, time synchronisation, vulnerability management and alert escalation.
8. Replicated identity and learning services, protected backups and quarterly restoration tests.
9. A procurement process requiring interoperability tests, five-year TCO, energy data, support commitments and end-of-life disclosures.

The three-year peak forecast is:

The college therefore selects a 10 Gb/s resilient campus backbone and a suitable internet service with capacity beyond the forecast peak. The choice is not based only on the calculated value: failure of one backbone link, protocol overhead and future applications are also considered.

Outcome and learning points

The proposed design removes major single points of failure, limits guest access, improves visibility and creates tested recovery procedures. It costs more than replacing the old router with a faster model, but its lifecycle analysis shows lower operational risk and a better match to the college’s strategic requirements.

The case demonstrates that a network decision is a portfolio of linked choices. Addressing, topology, device capability, QoS, recovery, procurement and governance must support the same business outcomes.

11. Contemporary Developments and Practical Best Practice

Networks increasingly use automation, intent-based policy, telemetry, zero-trust principles, cloud-managed infrastructure, SD-WAN and IPv6. These technologies can improve consistency and visibility, but they introduce dependencies on identity systems, APIs, cloud availability, vendor platforms and staff skills.

AI-assisted operations can help detect anomalies, summarise events and suggest configuration changes. Such systems should operate with human approval for consequential changes, protected credentials, audit trails and carefully controlled training data. A generated recommendation is not proof that a change is safe.

Best practice includes:

• maintain current physical, logical and dependency diagrams;
• document requirements, assumptions and acceptance tests;
• design for failure and test failover;
• monitor service outcomes, not only device health;
• keep configuration and software inventories accurate;
• use staged changes, peer review and rollback plans;
• measure capacity during realistic busy periods;
• review TCO, energy and lifecycle risk annually; and
• rehearse disaster recovery and supplier escalation.

Chapter Summary

Network design translates business objectives into measurable technical requirements. Topology, segmentation and addressing should support scalability, security and operational clarity. Device selection must consider features, performance under realistic workloads, interoperability, licensing, support, energy use and staff capability.

Performance engineering uses throughput, utilisation, latency, jitter, loss and growth forecasts. Capacity calculations are approximations that require assumptions, overhead allowances and validation through measurement. QoS manages contention for important traffic but cannot replace adequate capacity.

Redundancy and high availability require independent components, paths, power and tested procedures. RTO, RPO, availability, MTTR and MTBF describe different aspects of continuity. Disaster recovery depends on protected backups and restoration tests.

TCO, energy consumption, procurement quality, SLAs, vendor interoperability and end-of-support dates are strategic design concerns. Ethical monitoring, privacy, supply-chain assurance and responsible disposal must be incorporated into governance. The strongest design is not necessarily the largest or cheapest; it is the design whose risks, costs and capabilities are justified by the organisation’s requirements across its entire lifecycle.

Key Terms

Capacity planning: Estimating future resource requirements and arranging sufficient reserve.

Core layer: High-speed part of a hierarchical network that interconnects major network blocks.

Disaster recovery: Processes and resources used to restore services after a disruptive event.

DSCP: A field used to classify IP packets for differentiated QoS treatment.

High availability: Design that minimises service interruption through resilience and rapid failover.

Jitter: Variation in packet delay.

Logical topology: The pattern by which traffic is segmented and forwarded.

MTBF: Mean operating time between failures of a repairable system.

MTTR: Mean time required to repair or restore service.

Oversubscription: Aggregation of endpoint capacity onto a smaller upstream capacity.

QoS: Techniques for classifying and managing traffic during contention.

RPO: Maximum acceptable age of recoverable data.

RTO: Maximum acceptable time to restore a service.

Segmentation: Dividing a network into controlled logical or physical zones.

SLA: Contractual agreement defining service performance and support commitments.

Spine-leaf: Data-centre topology in which leaf switches connect to every spine switch.

TCO: Total cost of acquiring, operating, supporting and retiring a solution.

Topology: Arrangement of network nodes, links and traffic relationships.

Utilisation: Proportion of available capacity being used.

Review Questions

Short Answer Questions

1. What is the difference between a physical topology and a logical topology?
2. State two reasons why a network addressing plan should reserve space for growth.
3. Define RTO and RPO.
4. Why does QoS not eliminate the need for capacity planning?
5. Name four components of total cost of ownership.

Long Answer Questions

1. Explain how business requirements can be translated into a requirements traceability matrix and network design.
2. Compare hierarchical star, ring, full-mesh and spine-leaf topologies, including appropriate use cases.
3. Explain the roles of classification, marking, queuing, shaping and policing in QoS.
4. Discuss how high availability and disaster recovery complement, but do not replace, each other.
5. Describe the technical and managerial factors that should be included in a network procurement specification.

Analytical / Application Questions

1. An organisation has current peak traffic of 500 Mb/s, annual growth of 15% and a four-year planning horizon. Estimate future peak traffic using the compounded-growth model, state the model’s assumptions, and recommend what additional design factors should be considered before selecting a link.
2. A campus has 48 access ports at 1 Gb/s connected through a 10 Gb/s uplink. Calculate the nominal oversubscription ratio and discuss why the ratio alone cannot determine whether the design is acceptable.
3. A service operates for a 30-day month and its SLA permits 99.95% availability. Calculate the approximate downtime allowance in minutes and identify at least three SLA definitions that could change the practical interpretation of the result.

Multiple Choice Questions with Answers

Question 1

Which design activity should normally occur first?

A. Select a preferred switch brand

B. Identify and measure business and user requirements

C. Configure QoS markings

D. Purchase spare optics

Correct Answer: B. Identify and measure business and user requirements

Question 2

How many usable host addresses are provided by a conventional IPv4 /26 subnet?

A. 30

B. 32

C. 62

D. 64

Correct Answer: C. 62

Question 3

What does an oversubscription ratio compare?

A. Router memory with routing-table size

B. Sum of access-port rates with uplink rate

C. Downtime with uptime

D. Power consumption with rack space

Correct Answer: B. Sum of access-port rates with uplink rate

Question 4

Which QoS function deliberately smooths traffic to a configured rate?

A. Shaping

B. Routing

C. Address translation

D. Link aggregation

Correct Answer: A. Shaping

Question 5

An organisation’s 30-day month contains 43,200 minutes. Approximately how much downtime corresponds to 99.9% availability?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 4,320 minutes

Correct Answer: B. 43.2 minutes

Question 6

What does an RPO specify?

A. The maximum acceptable time to restore service

B. The average time between hardware failures

C. The maximum acceptable age of recoverable data

D. The vendor’s initial response time

Correct Answer: C. The maximum acceptable age of recoverable data

Question 7

Which statement about redundancy is most accurate?

A. Duplicate devices always provide complete independence

B. Redundancy is useful only for internet routers

C. Redundancy should include consideration of power, paths and failover procedures

D. Redundancy removes the need for monitoring

Correct Answer: C. Redundancy should include consideration of power, paths and failover procedures

Question 8

Which item is normally part of operating cost rather than capital cost?

A. Initial switch purchase

B. Rack installation

C. Annual electricity consumption

D. Initial fibre installation

Correct Answer: C. Annual electricity consumption

Question 9

What is the main purpose of an SLA?

A. To replace network monitoring

B. To define measurable service and support commitments

C. To guarantee that no failures occur

D. To specify only the vendor’s product colour

Correct Answer: B. To define measurable service and support commitments

Question 10

A device operating continuously at 0.30 kW uses approximately how much energy in a 8,760-hour year?

A. 262.8 kWh

B. 876 kWh

C. 2,628 kWh

D. 26,280 kWh

Correct Answer: C. 2,628 kWh