The challenge
The scenario describes a university serving about 60,000 students and 5,750 staff across 16 campuses. Its legacy network struggled with peak demand, had limited resilience, and lacked an established recovery plan. These constraints also made the university cautious about supporting personal devices and remote study or work.
The project set out to support expected growth while improving availability, performance, secure access and operational manageability.
Part 1: Network redesign
The proposed design replaces the flat, router-bottlenecked estate with a redundant three-tier campus network, an MPLS WAN and Azure-hosted services reached over ExpressRoute. The requirements include a 99.9% availability design target, sub-second response for interactive applications, capacity for 50% enrolment growth, secure BYOD and remote access, and a manageable operating model.
Logical and physical design
The design uses core, distribution and access layers, with redundant equipment at key points. It separates campus traffic into functional networks, prioritises delay-sensitive teaching and collaboration traffic, and moves the remote backup environment to Azure. The proposal describes 1 Gbps desktop access, higher-speed fibre uplinks and distributed cabling to improve capacity and ease of maintenance.
Routing, switching and operations are designed around standard protocols and an FCAPS management model: fault, configuration, accounting, performance and security. Network monitoring combines device logs, performance baselines, inventory and change records.
Figures from the report
These are the original report diagrams. They illustrate the scenario design and are not diagrams of a deployed NexusOne or university network.
Part 2: Network security plan
The security plan connects the network design to the assets, people, policies and recovery processes that need protection.
Assets and risk
The assessment considers network and server equipment, student and employee records, research relationships and university reputation. It prioritises congestion, single points of failure, malware, weak authentication, hardware aging and risks introduced by BYOD and remote work.
Security policies
Policy areas cover acceptable use, network security, wireless and BYOD, physical access, personnel, data handling, and systems maintenance. The controls include managed endpoints, separate guest and BYOD access, encryption, audit logging, vulnerability reviews and staff responsibilities.
Continuity and recovery
A business impact analysis groups services by maximum tolerable downtime. The plan describes separate-region backups, incident response, restoration teams, digital forensics, insurance and regular exercises.
Residual risk
Remaining risks are treated by avoidance, reduction, transfer or acceptance. The report calls for owners, review and a stated risk appetite rather than assuming controls remove all risk.
Part 3: Azure proof of concept
The original project reports five controls built and tested in a lab. The results below describe that proof of concept only; the 99.9% availability figure remains a design target.
| Control | Reported lab result |
|---|---|
| Backup and recovery | A server was backed up to a Recovery Services vault and restored from a restore point. |
| Identity integration | A server joined managed domain services, and user and group synchronization was checked. |
| File-service authorization | Folder permissions separated student, faculty and IT access; actions were audited. The report recommends replacing clear-text FTP with a protected alternative for production. |
| Load balancing | Traffic failed over between two test web servers when either server was stopped. |
| Remote access | A certificate-holding test client connected; a client without a certificate was refused. |
The report's review also records corrections to the original 2018 work, including modernized wireless and password guidance, improved recovery and logging expectations, and safer production boundaries for test services.
Outcomes and lessons
- 99.9%availability design target, not measured production uptime
- 50%projected enrolment growth included in the design brief
- 5security-control areas explored in the Azure proof of concept
- Security architecture and performance architecture are connected; avoid making one device a bottleneck for every function.
- Policies and tested controls help make secure BYOD and remote access acceptable to users and IT.
- Test a full restore instead of assuming that a successful backup is sufficient.
- Plan addressing and recovery for cloud, partner connections and future growth.
Related case study
See how the same scenario is re-imagined with a 2026 Zero Trust and cloud-first proposal.
Modernizing the university network for 2026