Multi-Site & Campus Networking
Multi-site networking is not a project to create one flat network across every office, campus, warehouse, or branch. We begin by defining the exact communications each site and system requires: application sessions, identity and management traffic, voice paths, monitoring, file access, and approved operational data. Routing and firewall policy permit those flows deliberately. Everything else is denied or protected by default, so adding a tunnel does not silently extend trust from one location to the entire organization.
Failure behavior matters more than standardization. A site can lose its WAN while local systems remain online. The design states whether cameras continue recording locally, whether phones have backup routing, which DNS, DHCP, authentication, printing, or operational services remain available, and what becomes unavailable by design. We use repeatable Meraki, Fortinet, or UniFi patterns where appropriate, document site-specific exceptions, and test the dependencies rather than treating a dashboard icon as proof of resilience.
Or call (888) 597-GGIS — we respond within 30 minutes during business hours.
What we deliver
- Site-by-site inventory of circuits, edge devices, switching, wireless, addressing, local services, critical applications, and support constraints
- Explicit inter-site flow matrix defining source, destination, protocol, business purpose, owner, and default-deny treatment
- Routed VPN or SD-WAN topology selected around required paths and security boundaries rather than broad network adjacency
- Consistent employee, guest, voice, camera, IoT, point-of-sale, management, and operational segments with controlled exceptions
- WAN-loss plan covering local camera recording, phone backup routes, DNS, DHCP, authentication, printing, and essential on-site applications
- Central templates for firewall rules, SSIDs, switching, quality-of-service intent, logging, firmware, naming, and administrative roles
- Campus and branch path review identifying shared conduits, oversubscription, carrier dependencies, incompatible optics, and recovery access
- Observed failover tests for permitted traffic, blocked paths, local-service continuity, alerting, restoration, and stable return to primary service
How we approach it
Discovery produces both a traffic matrix and a dependency register. We identify local, cloud, and inter-site services; required sources and destinations; circuit handoffs; overlapping addresses; and the impact of losing each WAN path. The topology defines routing ownership, tunnel membership, security zones, management access, logging, and explicit deny boundaries. Continuity requirements state whether cameras record locally, phones reroute, and essential on-site services function without headquarters or cloud access. Campus designs also trace physical paths so two logical uplinks do not depend on one conduit.
We construct reusable configurations in the selected Meraki, Fortinet, or UniFi management plane, with controlled variables for addresses, circuits, local services, and approved deviations. Firewall objects and rules reflect the flow matrix; VPN membership never substitutes for policy. VLANs, SSIDs, path preferences, quality-of-service intent, logging, alerts, and administrator roles use consistent names. Each template is reviewed for unintended branch-to-branch reachability and staged to a limited site set first, with configuration backups and rollback instructions retained before broader release.
Cutover plans identify circuit ports, device identities, local dependencies, change order, remote contacts, and a recovery path if centralized management becomes unreachable. Where parallel operation is practical, existing service remains until required traffic and local functions work through the replacement edge. Equipment, circuit, and patching labels are reconciled with the central inventory at each site.
Testing starts from both sides of the policy boundary. We verify permitted inter-site applications and confirm that unapproved branch, guest, camera, IoT, and management paths remain blocked. During an approved window, primary WAN service is interrupted and we observe tunnel recovery, cloud access, phone backup routing, local camera recording, DNS, DHCP, authentication dependencies, monitoring, and the services designated to remain local. Restoration and stable failback are timed and recorded. Dashboard state is compared with actual endpoint behavior, and every exception is assigned an owner.
Frequently asked questions
Should all sites behave as one large network?
No. Sites should exchange only the traffic required for documented business and operational functions. A routed tunnel provides reachability, but it should not create unrestricted trust between employee, guest, voice, camera, IoT, management, or production segments. We build a flow matrix, permit exact source-to-destination services, and deny or further protect everything else by default. This limits the effect of a compromised device or configuration error at one location and makes troubleshooting more specific.
What should keep working when a branch loses its WAN?
That depends on the site's operating requirements and device capabilities, so it must be decided rather than assumed. Local cameras may continue recording to an on-site recorder even when remote viewing fails. Phones may require a secondary carrier, cellular route, or defined emergency behavior. DNS, DHCP, authentication, printing, access, and line-of-business systems may be local or remotely dependent. We document each dependency, configure supported continuity options, and test the site while its primary WAN is actually unavailable.
How is WAN failover tested without creating an uncontrolled outage?
We first verify the backup circuit independently and confirm that required routes, DNS, VPN, voice, and security policies can use it. During an approved window, the primary handoff is disconnected or administratively disabled while named applications and local services are observed. We record transition time, degraded functions, alerts, and endpoint behavior, then restore the preferred path and verify stable failback. A rollback and local recovery contact are established before the test begins.
READY TO GET STARTED?
Two ways to begin.
Schedule a Site Walk
Walk the space with one of our engineers. We document existing infrastructure, identify scope, and follow up with a project memo within 5 business days.
Schedule a Site WalkRequest a Proposal
Already have drawings or an RFP? Send them over. We'll respond with a scoped proposal, line-item BOM, and project schedule within 7 business days.
Request a ProposalOr call (888) 597-GGIS — we respond within 30 minutes during business hours.