Network Design, Deployment and Professional Decision-Making

Introduction and Context

A computer network is not merely a collection of switches, routers, cables, wireless access points and servers. It is an engineered service intended to support organisational goals. A school may require reliable access to learning platforms; a hospital may prioritise availability, segmentation and auditability; a small business may need secure Internet access at a controlled cost. Network design therefore begins with requirements and constraints, not with the selection of a favourite brand or device.

Network design translates business, technical and regulatory requirements into two related descriptions:

• Logical design: how users, applications, addressing, routing, security zones and services are organised.
• Physical design: where devices, links, racks, power systems and transmission media are installed.

Professional decision-making connects these designs to capacity, cost, resilience, service-level agreements (SLAs), operational capability and future growth. A technically impressive network can still be unsuitable if it is unaffordable, difficult to operate, non-compliant or excessive for the actual workload.

Learning Objectives

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

1. Gather and prioritise network requirements.
2. Produce an appropriate logical and physical network design.
3. Select devices, transmission media and network services using explicit criteria.
4. Estimate bandwidth, addressing capacity, availability and total cost.
5. Design for redundancy and explain common availability trade-offs.
6. Prepare useful network documentation and acceptance tests.
7. Compare vendors and evaluate SLAs without relying only on marketing claims.
8. Recognise security, ethical, regulatory and sustainability implications.

From Requirements to Design Criteria

A design brief should identify stakeholders, sites, users, applications, traffic patterns, performance expectations, security obligations, available facilities, budget and implementation constraints. Requirements should be testable wherever possible. “The network must be fast” is weak; “the wireless network must support 120 concurrent users with an application response time below 200 ms under the stated workload” is more useful.

Requirements commonly fall into six groups:

Requirements should be classified as mandatory, desirable or optional. Conflicting requirements must be made visible. For example, strict inspection of all traffic can improve security but may increase latency and require more processing capacity. A low-cost single Internet connection may conflict with a high availability target.

A traceability matrix links each requirement to a design feature and an acceptance test. For example, the requirement “guest users must not access internal servers” may map to a guest VLAN, firewall policy, separate address pool and a test that attempts both permitted Internet access and prohibited internal access.

Capacity and Demand Estimation

Capacity planning should begin with demand rather than interface speed. Important inputs include the number of users, concurrency, application traffic, peak periods, protocol overhead, replication, backups and expected growth.

A simple planning estimate for average offered traffic is:

where:

• D_avg is estimated average traffic demand in bit/s;
• N is the number of users or devices;
• c is the average concurrent-use factor, from 0 to 1;
• r is the average traffic rate per active user in bit/s.

This is an approximation. It assumes users are sufficiently similar and that traffic is represented by an average rate. It does not predict bursts. A design should also consider a peak estimate, application-specific measurements and a capacity margin. If the estimated peak demand is D_peak and the target utilisation is u, where 0 < u < 1, the minimum nominal capacity is:

The units of D_peak and C_min must be identical. The utilisation target is not a universal constant: interactive traffic, voice, wireless networks and oversubscribed service-provider links may require different values. Capacity alone does not guarantee good performance because latency, queueing, loss, server capacity and wireless interference also matter.

Worked example. A training centre has 80 users. During the busiest period, 60% are active, and each active user generates an estimated 2 Mbit/s. Peak demand is therefore:

D_peak = 80 × 0.60 × 2 = 96 Mbit/s.

If the design limits expected utilisation to 70%:

C_min = 96 ÷ 0.70 ≈ 137.1 Mbit/s.

A 1 Gbit/s access link may therefore be appropriate, but the final choice must also consider the provider’s service profile, upload demand, Internet contention, growth and cost. The calculation is an estimate, not a performance guarantee.

Bursting is especially important for backups, software distribution and cloud synchronisation. Packet capture, NetFlow/IPFIX records, wireless controller statistics and application monitoring can replace assumptions with evidence.

Logical Network Design

Logical design describes relationships independently of the physical location of equipment. It normally includes topology, addressing, VLANs, routing, security zones, wireless services, name resolution, management and traffic policies.

Hierarchy and Modularity

An enterprise LAN is often organised into access, distribution and core functions. In a small network, these functions may be combined in one device; in a larger network, separating them improves scalability and fault isolation.

• Access layer connects end devices and enforces edge policies.
• Distribution layer aggregates access switches, applies routing and policy, and provides a boundary for fault domains.
• Core layer provides fast, resilient interconnection between major network sections.

A campus may use a two-tier collapsed core/distribution architecture when a separate core would add cost without useful benefit. A modular design uses standard interfaces, summarised addressing and clearly defined boundaries so that one change does not require redesigning the entire network.

Segmentation and Addressing

Segmentation reduces broadcast scope, supports policy enforcement and limits the effect of faults or compromise. Common segments include staff, students, voice, servers, management, building systems and guests. VLANs provide Layer 2 separation, but VLANs alone are not a complete security control; inter-VLAN communication must be controlled by routing and firewall policy.

An addressing plan should reserve space for current and future segments, document gateways and DHCP scopes, and support route summarisation. IPv4 subnet sizing is based on powers of two. If a subnet has h host bits, the number of addresses is:

For a conventional IPv4 subnet, two addresses are commonly unavailable to ordinary hosts: the network address and directed broadcast address. Thus:

where H is usable host addresses. This rule has exceptions, including point-to-point conventions and special-purpose prefixes, so the address plan must follow the addressing standard and device behaviour being used.

Example. A department needs 50 ordinary IPv4 host addresses. Six host bits provide 2⁶ − 2 = 62 usable addresses, corresponding to a /26 prefix because 32 − 6 = 26. A /27 provides only 30 usable addresses and is insufficient.

IPv6 planning is different: networks are normally assigned large standard prefixes, and hosts use 128-bit addresses. The design emphasis is hierarchical allocation, security policy, address management and dual-stack transition rather than conserving addresses as in IPv4.

Routing and Services

Routing design should identify default gateways, internal routes, summarisation boundaries, dynamic routing requirements and failure behaviour. Static routes can be suitable for small, stable networks; dynamic protocols are more appropriate when there are multiple paths, frequent changes or a need for automatic convergence.

Essential services include DHCP, DNS, network time, identity and access control, configuration management, monitoring, logging and backup. Service placement should consider dependency: if DNS, authentication and DHCP all depend on a single server or link, that component becomes a hidden single point of failure.

Wireless Design

Wireless planning requires more than placing access points at equal distances. It considers building materials, channel availability, transmit power, client density, roaming, authentication, coverage and capacity. A dense lecture room may need additional access points for capacity even when a single access point provides adequate signal strength. Surveys should measure signal, noise, channel use and actual client performance. Separate staff, student, guest and device networks should be supported by appropriate identity and policy controls.

Physical Network Design

The physical design specifies equipment locations, racks, patch panels, cable routes, power, cooling, grounding, physical security and link types. It should be consistent with the logical design but need not mirror it exactly. Several access switches may connect to a redundant distribution pair, for example.

Devices and Media

Device selection should be based on required features and measured capacity, not port count alone. Relevant criteria include:

• forwarding performance and packet-processing capacity;
• interface speed, PoE budget and uplink options;
• VLAN, routing, quality-of-service and security support;
• management interfaces, telemetry and automation support;
• software lifecycle, licensing and support model;
• power consumption, environmental ratings and physical dimensions.

Copper Ethernet is commonly used for horizontal cabling because it is economical and convenient for end devices. Fibre is preferred for longer distances, high bandwidth, electromagnetic isolation or building-to-building links. The selected medium must meet distance, installation, termination and environmental requirements. A link should not be described simply as “1 Gbit/s” without considering duplex operation, transceiver compatibility, cabling category, patching and actual traffic conditions.

Physical resilience includes diverse cable routes, independent power feeds, uninterruptible power supplies, generator support where justified, adequate cooling and protection from water or unauthorised access. A redundant device connected through one shared cable tray and one power distribution unit may still have a common point of failure.

Availability, Redundancy and Service Levels

Availability is the proportion of an agreed observation period during which a service is usable. A simplified availability measure is:

where MTBF is mean time between failures and MTTR is mean time to repair, both measured in the same time unit. The model assumes repairable failures and a stable long-run average; it does not capture every maintenance, dependency or correlated-failure condition.

For example, if MTBF is 1,000 hours and MTTR is 4 hours:

Availability = 1000 ÷ 1004 ≈ 0.996016, or approximately 99.60%.

A target of 99.9% is not “almost always” in operational terms. The allowable unavailability in a 30-day month is:

where A is availability as a decimal and T is the total time in the measurement period. For 99.9% availability and a 30-day month:

(1 − 0.999) × 720 = 0.72 hours, or about 43.2 minutes.

Actual SLA calculations must define measurement points, exclusions, maintenance windows, rounding, credits and whether availability is measured per service or end-to-end.

Redundancy can reduce risk through:

• dual power supplies and independent power paths;
• link aggregation or alternate links;
• redundant switches, routers or firewalls;
• dual Internet providers;
• replicated servers and diverse data paths;
• backup configurations and tested restoration.

Redundancy is useful only when failover works. Automatic failover can introduce its own risks, including split-brain operation, asymmetric routing, stale state, configuration drift and more complicated troubleshooting. Each redundant design requires failure-mode analysis and testing.

A useful distinction is between resilience and reliability. Reliability concerns avoiding failure; resilience concerns continuing or recovering service when failure occurs. Backup links, spare equipment, documented procedures and trained staff contribute to resilience even when complete redundancy is not economically justified.

Security and Governance by Design

Security should be integrated rather than added at the end. A design should apply least privilege, strong identity, secure management, segmentation, encryption where appropriate, secure defaults, logging and timely patching. Management interfaces should be restricted to authorised administration networks and protected with multifactor authentication where feasible.

Network access control can use identity, device posture, location and service context. Firewall policies should be explicit, ordered, reviewed and logged. Monitoring should support detection and investigation without collecting unnecessary personal information.

Governance questions include:

• Is monitoring proportionate and transparent to users?
• Are logs retained only as long as policy and law require?
• Are personal data, credentials and traffic content protected?
• Are suppliers permitted to access the network remotely, and is that access recorded?
• Does the design meet applicable privacy, education, health, critical-infrastructure or contractual obligations?

Ethical practice requires avoiding covert surveillance, insecure default credentials and unjustified collection of user data. Accessibility and inclusion also matter: network services should not systematically exclude users because of device, location or disability.

Cost, Vendors and Professional Decisions

The initial purchase price is only one part of network cost. Total cost of ownership (TCO) may include hardware, software subscriptions, support, installation, cabling, power, cooling, training, monitoring, replacement, licensing, Internet circuits, downtime and disposal.

A simple planning model is:

The terms represent capital equipment, recurring subscriptions, installation, operating costs, replacement costs and estimated downtime costs over the selected period. The categories must be defined consistently to avoid double counting. Downtime cost is particularly uncertain and should be reported as an estimate or range.

Vendor comparison should use a weighted decision matrix. Let s_i be the score for criterion i, and w_i its weight, where weights sum to 1. A weighted score is:

Scores and weights are decision judgements, not objective facts. The procurement record should explain their basis and perform sensitivity analysis: if a small change in a weight changes the preferred vendor, the decision is sensitive and should not be presented as certain.

Important criteria include interoperability, standards support, security history, support response, local expertise, migration difficulty, licensing transparency, supply continuity, automation capability and exit options. Vendor lock-in is not automatically unacceptable, but it should be recognised and justified.

An SLA should specify service scope, service hours, availability target, latency or packet-loss commitments where relevant, response and restoration times, maintenance notice, measurement method, exclusions, remedies and escalation. A service credit may compensate financially but cannot restore lost teaching time or data. Operational requirements should therefore be supported by architecture, monitoring and tested recovery—not by contractual language alone.

Deployment, Testing and Documentation

Deployment should be staged. A typical lifecycle is:

1. discovery and requirements validation;
2. high-level and low-level design;
3. laboratory or pilot testing;
4. procurement and preparation;
5. controlled implementation;
6. acceptance testing;
7. monitoring, optimisation and handover.

Change management should record the reason, risk, affected services, implementation steps, rollback plan, approver, maintenance window and verification method. A rollback plan is meaningful only if it is feasible within the outage window.

Acceptance tests should include connectivity, addressing, routing, DNS and DHCP, authentication, security isolation, throughput under the stated workload, failover, monitoring, backup restoration and management access. Test results should record date, equipment, configuration version, measured result, pass criterion and responsible person.

Documentation is an operational control. A useful documentation set includes:

• requirements and assumptions register;
• logical topology and physical floor plans;
• IP address, VLAN, circuit and port schedules;
• device inventory and software versions;
• configuration backups and standards;
• firewall and access-control policy;
• rack elevations, cable labels and power information;
• monitoring, escalation and recovery procedures;
• change history and support contacts.

Diagrams should have titles, legends, version dates and consistent symbols. Sensitive information must be stored securely; publishing passwords or unrestricted management addresses in general documentation creates a security risk.

Figure: A lifecycle in which operational evidence feeds the next design decision.

Illustrative Case: Regional Training Centre Network

Background

A fictional regional training centre has two buildings, 180 learners, 25 staff members, voice over IP, cloud learning systems, wireless classrooms, CCTV and a small server room. The existing flat network uses one Internet connection, unmanaged access switches and shared credentials. Complaints include intermittent wireless service and slow access during examinations.

Problem and Analysis

The centre’s requirements are classified as follows: secure separation of staff, learner, guest, voice and security-camera traffic; reliable online examinations; central authentication; improved wireless capacity; documented recovery; and a moderate budget. A short survey finds that peak demand is concentrated in four classrooms rather than evenly distributed. The server room, a single fibre path between buildings and the Internet router are single points of failure.

Approach and Solution

The proposed logical design uses separate VLANs and IP subnets for staff, learners, guests, voice, cameras, servers and management. A firewall controls inter-zone traffic. Guest traffic is Internet-only. Staff and learners use central identity services; device-management access is restricted to the management segment.

The physical design uses managed PoE access switches, fibre uplinks between buildings, two distribution-capable switches in the main building and two Internet-capable firewall appliances in a high-availability arrangement. A second provider is considered, but its benefit is limited unless the building entry path and power are also diversified. Wireless access points are placed according to a capacity-oriented survey rather than signal coverage alone. UPS units protect network equipment, and configurations are backed up to secured storage.

The project uses a pilot classroom, a maintenance window and acceptance tests. Tests include guest isolation, examination-platform performance, voice quality, loss of either uplink, firewall failover, restoration of a switch configuration and alert delivery to the administrator.

Outcome

In this illustrative case, the centre obtains predictable segmentation, improved wireless capacity and a documented recovery process. The design does not promise that every failure is invisible; instead, it identifies residual risks, including provider outages, power loss beyond UPS runtime and insufficient staffing for complex firewall administration.

Learning Points

The case demonstrates that design is a systems decision. A second firewall cannot compensate for poor addressing, weak monitoring or untrained staff. Capacity planning must reflect where and when demand occurs. Resilience must be tested, and documentation must be treated as part of the delivered network rather than as optional paperwork.

Challenges, Limitations and Contemporary Developments

Network estimates are uncertain because traffic changes, applications move to the cloud, devices behave differently and failure events are not independent. Availability calculations based on component MTBF may overstate end-to-end service availability when components share power, paths, software or administrators. Weighted vendor scores can disguise subjective preferences. SLA credits may not reflect operational harm.

Contemporary networks increasingly use software-defined management, zero-trust principles, cloud-managed platforms, network automation, telemetry and intent-based policy. These approaches can improve consistency and visibility but introduce controller dependence, subscription cost, data-governance questions and new failure modes. AI-assisted operations can help identify anomalies, summarise alerts or suggest configuration changes. It must not be granted uncontrolled authority: recommendations require validation, audit trails, change control and protection against poisoned data or unsafe automation.

Sustainability should be included in professional decisions. Efficient equipment, appropriate capacity, repairability, longer support lifecycles, virtualisation where suitable and responsible recycling can reduce environmental impact. Overprovisioning also consumes power and creates electronic waste, while underprovisioning may cause repeated replacement and poor service. The best design balances present requirements, credible growth and the cost of change.

Best-Practice Decision Framework

A defensible design decision normally follows this sequence:

1. Establish measurable requirements and assumptions.
2. Identify constraints, dependencies and unacceptable risks.
3. Create at least two feasible architectures.
4. Estimate performance, availability, lifecycle cost and operational effort.
5. Evaluate security, compliance, sustainability and vendor dependence.
6. Pilot the preferred design and test failure conditions.
7. Document the decision, alternatives rejected and residual risks.
8. Review the design using operational evidence after deployment.

Professional judgement is not the absence of uncertainty. It is the disciplined process of making assumptions visible, testing important claims and selecting a proportionate solution.

Chapter Summary

Network design translates organisational requirements into logical and physical structures. A sound process begins with measurable requirements, classifies priorities and records assumptions. Capacity estimates should consider concurrency, peak demand, utilisation, bursts and growth; bandwidth alone does not determine user experience. Logical design addresses segmentation, addressing, routing, services, wireless policy and security zones, while physical design addresses devices, media, racks, power, cooling and diverse paths.

Availability depends on failure and repair behaviour, but component calculations do not automatically represent end-to-end service. Redundancy must be evaluated against common points of failure, operational complexity and cost. TCO, weighted decision matrices and carefully written SLAs support transparent procurement decisions. Deployment requires pilots, change control, acceptance testing, rollback planning and secure documentation. Finally, professional network decisions must consider privacy, security, sustainability, vendor dependence, emerging automation and the skills required to operate the result.

Key Terms

Availability: The proportion of an agreed period during which a service is usable.

Capacity planning: Estimating present and future resource requirements.

Common point of failure: A shared component whose failure can disable supposedly redundant systems.

Distribution layer: A network layer that aggregates access devices and applies routing or policy.

Logical design: The organisation of addressing, routing, segmentation, services and policies.

MTBF: Mean time between failures for a repairable system or component.

MTTR: Mean time to repair or restore a failed system or component.

Redundancy: Provision of alternate components or paths to reduce service interruption.

Resilience: The ability to continue or recover service during and after disruption.

SLA: A documented agreement defining service performance and support obligations.

Subnet: A logical IP network defined by an address prefix and associated host range.

Total cost of ownership: The lifecycle cost of acquiring, operating and replacing a solution.

Traceability matrix: A record linking requirements to design features and tests.

VLAN: A logical Layer 2 broadcast domain implemented across suitable switching infrastructure.

Weighted decision matrix: A comparison method combining criterion scores with assigned weights.

Physical design: The placement and interconnection of equipment, cabling, power and facilities.

Capacity margin: The difference between planned demand and available resource capacity.

Failover: The transfer of service to an alternate component or path after failure.

Review Questions

Short Answer Questions

1. Distinguish between logical and physical network design.
2. Why should requirements be classified as mandatory, desirable or optional?
3. State two reasons why VLANs alone do not provide complete security.
4. Define MTBF and MTTR.
5. Identify four items that should appear in network documentation.

Long Answer Questions

1. Explain how a requirement traceability matrix supports network deployment and acceptance.
2. Discuss the principal factors involved in selecting switches, routers, firewalls and transmission media.
3. Explain how segmentation, routing and security policy work together in an enterprise network.
4. Evaluate the benefits and risks of redundancy in a campus network.
5. Describe how TCO and SLAs should influence a vendor-selection decision.

Analytical / Application Questions

1. A site has 120 users, a peak concurrency of 50% and an estimated rate of 3 Mbit/s per active user. Calculate peak demand. If planned utilisation is 75%, calculate the minimum nominal capacity and state two reasons why the result requires validation.
2. A service has MTBF of 2,000 hours and MTTR of 10 hours. Estimate availability using the simplified formula and explain one limitation of this estimate.
3. Design a high-level network for a two-building college requiring staff, learner, guest, voice and server separation. Identify logical segments, physical redundancies, key tests and one residual risk.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes logical from physical network design?

A. Logical design specifies cable lengths, while physical design specifies IP addresses.

B. Logical design specifies relationships and policies, while physical design specifies equipment placement and interconnection.

C. Logical design applies only to wireless networks, while physical design applies only to wired networks.

D. Logical design is completed after deployment, while physical design is completed before requirements gathering.

Correct Answer: B. Logical design specifies relationships and policies, while physical design specifies equipment placement and interconnection.

Question 2

A network has 80 users, 60% concurrency and 2 Mbit/s per active user. What is the estimated demand?

A. 16 Mbit/s

B. 48 Mbit/s

C. 96 Mbit/s

D. 160 Mbit/s

Correct Answer: C. 96 Mbit/s

Question 3

Which control most directly prevents a guest VLAN from reaching internal servers?

A. Increasing the switch backplane speed

B. Changing the cable category

C. Applying routing or firewall policy between the guest and internal zones

D. Adding more DHCP addresses

Correct Answer: C. Applying routing or firewall policy between the guest and internal zones

Question 4

A conventional IPv4 subnet with 6 host bits provides how many usable host addresses?

A. 30

B. เป็น 62

C. 64

D. 126

Correct Answer: B. เป็น 62

Question 5

Using Availability = MTBF ÷ (MTBF + MTTR), what is the approximate availability when MTBF is 1,000 hours and MTTR is 4 hours?

A. 90.0%

B. 96.0%

C. 99.6%

D. 99.99%

Correct Answer: C. 99.6%

Question 6

Which is a common point of failure?

A. Two independent providers with diverse building entries

B. Two switches connected through one shared power unit and cable route

C. A tested backup configuration stored securely

D. Two independently powered firewall appliances

Correct Answer: B. Two switches connected through one shared power unit and cable route

Question 7

Which item is most appropriate for an SLA?

A. The designer’s preferred colour scheme

B. An undefined promise of maximum speed

C. The measurement method, service target, exclusions and remedies

D. A list of all employee hobbies

Correct Answer: C. The measurement method, service target, exclusions and remedies

Question 8

What is the principal purpose of a pilot deployment?

A. To eliminate the need for documentation

B. To test the design and implementation approach under controlled conditions

C. To guarantee that no future maintenance will be required

D. To replace all acceptance testing

Correct Answer: B. To test the design and implementation approach under controlled conditions

Question 9

Which factor should be included in total cost of ownership?

A. Only the initial hardware purchase price

B. Only the number of switch ports

C. Operating, support, replacement and potentially downtime costs

D. The physical colour of equipment

Correct Answer: C. Operating, support, replacement and potentially downtime costs

Question 10

Why should AI-assisted network changes require validation and change control?

A. AI cannot process any network information

B. Automated recommendations can be incorrect or unsafe and must be auditable

C. Change control is needed only for paper documents

D. Validation prevents all network failures

Correct Answer: B. Automated recommendations can be incorrect or unsafe and must be auditable