Infrastructure case study · March 2026
Network Infrastructure Upgrade — CIMMYT Nepal Office
A practical redesign of an existing office network in Khumaltar, Lalitpur: introducing VLAN segmentation, guest isolation, firewall policy control, wireless optimization, FortiAP integration, and structured documentation without purchasing new hardware for this phase of the project.
Moving from a flat network to controlled segmentation.
The office network was operating as a largely flat environment with staff devices, guest wireless access, printers, and other endpoints sharing the same broadcast domain. That design provided limited separation between trusted and guest traffic and made troubleshooting and policy enforcement more difficult than necessary.
The objective for this phase was to introduce a cleaner network model using the equipment already available in the office: separate corporate and guest traffic, improve wireless performance, centralize policy enforcement on the FortiGate, and document the resulting environment properly.
Five days of configuration, troubleshooting, validation, and documentation.
| Date | Work completed |
|---|---|
| 20 Mar 2026 | FortiGate 91G configuration, corporate and guest VLANs, DHCP, SD-WAN preparation, and firewall policy work. |
| 20–21 Mar | Three Cisco Catalyst 2960-X switches cleaned, reviewed, and reconfigured with appropriate access and trunk behavior. |
| 21 Mar | Eight Cisco AIR-CAP2702I access points configured for the documented wireless design and channel plan. |
| 22–24 Mar | FortiAP 231F adoption and bridge-mode troubleshooting, including FortiGate management access and VLAN behavior. |
| 25 Mar | Network inventory and addressing documentation completed in NetBox. |
The measurable change came from architecture and configuration.
In the documented test, wireless download performance increased from roughly 7 Mbps before the change to 41.8 Mbps after the redesign, while measured jitter fell to 1 ms. These figures are an observed project result rather than a guarantee of identical improvement in other environments.
Before
After
Reusing the installed equipment before buying more.
This phase concentrated on getting more value from hardware already present in the office. The project covered the following devices.
Internet gateway, VLAN routing, firewall policy enforcement, SD-WAN, and FortiAP management.
PoE switching for the core/access layer and VLAN trunk/access-port configuration.
Existing autonomous wireless access points used across the office during this project phase.
FortiGate-managed AP used to address a documented coverage requirement in the CCR area.
A hierarchical design with separate corporate and guest traffic.
The FortiGate sits at the routing and security boundary. The core switch connects the downstream access switching and AP-facing trunk ports. Corporate and guest traffic are separated at Layer 2 and controlled through FortiGate policy.
Corporate network
Guest network
Routing and security policy became explicit instead of implicit.
The FortiGate configuration introduced VLAN interfaces, DHCP services, internet access policies, and an explicit deny path from the guest network toward corporate resources. The example below is intentionally sanitized and does not expose production addressing.
config system interface
edit "VLAN20_Internal"
set interface "lan"
set type vlan
set vlanid 20
set ip x.x.x.1 255.255.254.0
next
end
# Representative policy intent Guest VLAN 999 -> Internet ACCEPT + NAT Guest VLAN 999 -> Corporate VLAN DENY Corporate VLAN -> Internet ACCEPT + NAT
Band selection and channel planning were treated as design decisions.
Corporate wireless was moved toward 5 GHz use, while the documented 2.4 GHz design used the non-overlapping 1 / 6 / 11 channel pattern across adjacent Cisco APs. This reduced avoidable co-channel overlap compared with the previous configuration.
The FortiAP 231F was integrated under FortiGate management for the additional coverage requirement. For FortiAP management, Fortinet documents that the FortiGate interface used to manage the AP must permit the Security Fabric Connection/CAPWAP management path.
The useful part of the project was not that everything worked immediately.
The original bridge/VLAN behavior did not match the expected tagging path through the switch.
For this implementation, using VLAN ID 0 for the bridged path allowed the traffic to leave the AP untagged and be placed into the intended native VLAN by the switching design.
Basic IP reachability alone was not enough for FortiAP discovery and control.
Security Fabric Connection was enabled on the relevant interface so the CAPWAP management tunnel could be established.
Local management troubleshooting was complicated by the AP's existing controller registration state.
After the prior management association was removed, local FortiGate adoption could proceed.
Three engineering lessons that carried beyond this project.
SSID mode, AP behavior, switch trunk configuration, native VLAN handling, and firewall interfaces all need to describe the same Layer-2 path. A mismatch at any point can look like a DHCP problem.
The observed throughput improvement in this project came from configuration, segmentation, band selection, channel planning, and cleanup of the existing design.
Interfaces, routing/SD-WAN constructs, DHCP, and policy objects should be established in a deliberate sequence so later firewall policies reference objects that already exist.
The implementation was tested before it was considered complete.
| Validation | Documented result |
|---|---|
| FortiGate internet connectivity | Passed |
| Wired clients across the switching environment | Passed |
| Corporate SSID on Cisco APs | Passed — observed 41.8 Mbps / 1 ms jitter |
| Corporate SSID on FortiAP 231F | Passed |
| Guest SSID on Cisco APs | Passed |
| Guest SSID on FortiAP 231F | Passed |
| Guest-to-corporate isolation | Passed |
| Eight Cisco APs reachable | Passed |
| NetBox documentation | Completed |
A configuration project can still be an infrastructure project.
This upgrade reinforced a point that is easy to miss in infrastructure work: replacing hardware is only one way to improve a network. In this case, the immediate gains came from understanding the existing environment, introducing segmentation, correcting the switching and wireless design, validating the traffic paths, and documenting the result.
Later infrastructure changes can build on this baseline. This article intentionally remains a record of the March 2026 implementation rather than being rewritten to pretend the environment never evolved.
Bikram Bhujel is an IT Infrastructure Specialist based in Nepal, writing about enterprise networking, server administration, and home lab setups at bikrambhujel.com.np