Campus Floor Connectivity Design

Design Context

The scenario was a building-to-building campus connectivity design. Building 1 handled the WAN handoff: ISP service links land on the Cisco C9300 StackWise block, the SD-WAN zone connects into the FortiGate 600-series HA firewall pair, and the C9300 feeds the Building 1 OM3 fiber rack. Building 2 hosted the campus core on Floor 1 using two Cisco C9500 switches in StackWise Virtual, with an OM3 fiber rack extending toward Floor 5 access zones and a local Floor 1 extension area.

I remember putting a lot of care into this design because it was not just about "connecting switches." The real work was defining the physical fiber path, the security handoff, the campus core role, the Floor 5 access distribution model, and the operational documentation that would make troubleshooting easier later.

Hardware Inventory and Roles

This section is only the logical role view. It maps each layer to its platform and operational responsibility without trying to behave like a procurement list or a cable schedule. The goal is to make the architecture readable before getting into exact part numbers.

Detailed Material Reference

This section is intentionally closer to a BOM/procurement view. It documents specific part numbers, licensing families, optics, network modules, and future capacity items without re-explaining the full architecture.

Switch Port and Uplink Plan

A design document should make it clear which ports are access-facing, which ports are uplinks, which links are handoffs, and where demarcation happens. This section is about port roles and operational boundaries, not platform selection or optic inventory.

Specific Uplink and Optic Notes

This section stays focused on media, modules, and distance assumptions. I would keep these optics documented directly in the design notes so implementation and procurement do not have to infer the physical layer from the topology diagram.

Design Requirements

Connectivity Options

This section is about alternatives and trade-offs, not the final topology. The main decision was how much separation to keep between WAN handoff, firewall policy, distribution, and building-to-building fiber.

The final flow is explained later in the proposed architecture. Here, the useful part is showing why each option was attractive and what operational cost it introduced.

Proposed Architecture

This is the final integrated view of the design. After separating roles, procurement details, port demarcation, optics, and options, this section ties the actual traffic and physical flow together.

The architecture starts in Building 1, where ISP/WAN service handoffs land on the Cisco C9300 StackWise block. The FortiGate 600-series HA pair connects to that aggregation layer to provide firewall, SD-WAN, and security policy. The same C9300 block feeds the Building 1 OM3 fiber rack, and from there the inter-building fiber path reaches Building 2 Floor 1.

From the Building 2 Floor 1 core, OM3 multimode fiber runs through a Floor 1 OM3 fiber rack toward the Floor 5 OM3 fiber rack. Floor 5 is divided into three Cisco C9300 access zones: D1, D2, and D3. Each zone contains 8 access switches, split into two 4-switch StackWise groups. A separate Floor 1 extension also uses OM3 multimode fiber and terminates into a 4-switch Cisco C9300 StackWise block.

Transceiver and Media Plan

This section is not a second BOM. It captures physical media assumptions: fiber type, distance validation, patching path, and the module family that should be confirmed before implementation.

Resiliency Decisions

• Use FortiGate 600-series HA inside the SD-WAN zone for firewall and policy control.
• Use Cisco C9300 StackWise in Building 1 for ISP, FortiGate, and fiber-rack aggregation.
• Use two Cisco C9500 switches in StackWise Virtual as the Building 2 Floor 1 core.
• Use a clean OM3 fiber handoff between Building 2 Floor 1 and Floor 5 racks.
• Split Floor 5 Cisco C9300 zones into two 4-switch StackWise groups per zone for operational clarity.
• Document fiber endpoints clearly so troubleshooting starts with facts, not guessing.

Security and Layer 2 Controls

The original design included security controls that are still important in enterprise access networks: 802.1X for access control, VLAN segmentation, ACLs for traffic filtering, storm control, PortFast, and BPDU Guard. These are not flashy features, but they protect the network from common access-layer problems.

• 802.1X for authenticated access.
• VLAN segmentation for user, voice, management, cameras, and access systems.
• Storm control for broadcast protection.
• PortFast for endpoint access ports.
• BPDU Guard to protect the spanning-tree edge.
• ACLs for controlled inter-segment access.

Growth Planning

One of the strongest parts of this design is that it was not only built for the day-one requirement. It considered future users, wireless expansion, security cameras, access control systems, and additional structured cabling needs. A floor expansion should not be designed only for the first wave of endpoints; it should be designed for the next operational cycle.

Design Improvement I Would Apply Today

Looking at this design with more experience, I would prefer to land the ISP handoffs on a dedicated switch stack first, then connect that stack toward the distribution layer. That would keep the WAN side cleaner, allow the ISP circuits to be carried with tagged VLANs, and give the firewall a more deterministic handoff model.

In that model, each FortiGate would receive redundant LACP trunks from the distribution switches. I would separate the Port-Channels by function: one Port-Channel for WAN-side VLANs and another Port-Channel for LAN-side/internal VLANs. The VLAN IDs on the firewall would match the VLANs created on the Cisco distribution layer, keeping the relationship between firewall zones and switch segmentation easy to operate.

For example, I would reserve multiple physical links per firewall, such as 8 ports to the first FortiGate and 8 ports to the second FortiGate, bundled with LACP. The goal is not only bandwidth; it is operational redundancy, predictable failure behavior, and a clean separation between WAN and LAN roles.

interface range TenGigabitEthernet1/0/1-8
 description FortigateFW-601-E-to-WAN
 switchport mode trunk
 channel-protocol lacp
 channel-group 101 mode active

interface Port-channel101
 description FortigateFW-601-E-to-WAN
 switchport mode trunk
 switchport trunk allowed vlan <wan-vlan-list>