Cloud-managed wireless has transformed how organisations deploy and operate networks. Platforms like Cisco Meraki make it simple to deploy fast, reliable connectivity. No heavy infrastructure required.
But success at a smaller scale doesn’t always translate to the campus. As environments grow to thousands of users across multiple buildings, you start running into real limitations. Connections drop when people move around, switches get overwhelmed, and what was once simple starts to feel complex.
Cisco Campus Gateway solves these problems by acting as a central hub for your wireless traffic. It gives you enterprise-scale performance without sacrificing the simplicity of the Meraki dashboard your team is familiar with. It’s the missing piece that allows Meraki networks to scale from single sites to full campus deployments.
This blog explores what Campus Gateway does, which problems it addresses, what you need to know before committing, and how to determine if it’s the right fit for your organisation.
In a standard Meraki setup, each access point handles wireless traffic directly and places it onto the wired network. This is efficient and simple at small-mid sized scale but introduces four specific challenges as your campus grows.
Access switches are the devices where all your access points connect. In a standard setup, every access switch must maintain a list of all the wireless clients connected across the campus, not just the ones nearby. At campus scale, this means thousands of entries per switch, consuming far more memory than those switches were originally sized for. The result is slower performance, and in the worst cases, switches running out of capacity entirely and causing connectivity failures.
Imagine a student uploading an assignment while walking between rooms, levels or buildings. When users move between floors or buildings, they’re often forced to pick up new network addresses. This interruption breaks active sessions; file uploads fail, video calls drop and cloud apps disconnect mid-use.
For campuses with high user mobility like universities, hospitals and large corporate sites, this translates directly into service desk calls and frustrated users.
Extending wireless access across an entire campus to support roaming creates oversized network segments. The resulting background traffic (devices constantly announcing themselves, looking for services, and checking in) consumes bandwidth and processing power at every switch in the network. It’s a design trade-off that gets increasingly expensive as the campus footprint grows.
Some organisations have used MX appliances, routers and firewalls to centralise their wireless traffic through VPN tunnels. However, these devices create individual tunnels for each combination of wireless network and access point. A campus with two wireless networks across 1,000 access points generates 2,000 tunnels, which is well beyond the 1,500-tunnel limit of most platforms. The maths simply does not work for large campuses.
Campus Gateway sits at the centre of your campus network as a single aggregation point for all wireless traffic. Instead of each access point placing traffic directly onto the wired network, traffic is tunnelled back to the Gateway using an overlay. This changes the game in four key ways:
| The challenge | How Campus Gateway fixes it |
| 1. Switches getting overwhelmed | Only the core switch connected to the Gateway needs to track all wireless clients. Your access switches stay lean and only carry tunnel traffic. No more memory overload. |
| 2. Connections dropping when people move | The Gateway keeps a central record of every connected user, so they keep their network address as they move anywhere on campus. No more dropped calls, failed uploads or disconnected apps. |
| 3. Too much network chatter | Wireless network segments terminate at the Gateway, not across the entire campus. Background traffic is contained to a much smaller area instead of flooding every switch. |
| 4. Infrastructure redesign | The tunnel overlay rides over your existing wired network. No re-addressing, no redesign, and no changes to your access switches required. |
Campus Gateway sits at the centre of your campus network as a single aggregation point for all wireless traffic. Instead of each access point placing traffic directly onto the wired network, traffic is tunnelled back to the Gateway using an overlay. This changes the game in four key ways:
Before Campus Gateway: Scaling a Meraki wireless campus typically meant either accepting the limitations or migrating to a completely different controller-based platform.
With Campus Gateway: You keep the Meraki dashboard and operational workflows your team already knows, while gaining the ability to support up to 5,000 access points and 50,000 users. The scale ceiling is removed without changing platforms.
| Capability | Specification |
| Maximum access points | 5,000 |
| Maximum wireless users | 50,000 |
| Throughput | 100 Gbps (200 Gbps with two-unit cluster) |
| Roaming speed | Up to 1,000 roams per second |
| High availability | Active-Active clustering with sub-2-second failover |
| Management | Cisco Meraki Dashboard (same platform, nothing new to learn) |
| Gateway licensing | None required (your existing AP licensing applies) |
A phased deployment reduces risk and gives you validation checkpoints along the way.
Campus Gateway solves specific problems at scale. Understanding its requirements and boundaries upfront ensures you make a well-informed decision.
| Area | What this means |
| Access Point Compatibility | Only Wi-Fi 6, 6E, and 7 access points are supported. Older models will keep working as they do today but can’t take advantage of the Gateway. |
| Core Switch Sizing | Your core switches need to handle 50,000-plus device entries. Catalyst 9500 or 9600 are recommended. Catalyst 9300 tops out at 35,000, which is not enough at full scale. |
| Separate Platform to 9800 Controllers | Campus Gateway and Catalyst 9800 wireless controllers are completely separate platforms for different management models. Campus Gateway is part of the Meraki cloud-managed stack, while 9800 controllers are part of the on-premises Catalyst stack. They don’t run side by side managing the same access points. If you currently run 9800 controllers, adopting Campus Gateway means migrating your access points to Meraki cloud-managed mode. That’s a platform change, not an add-on. |
| Connectivity Requirements | The Gateway requires a port-channel connection to your core switches, even for lab testing with a single link. |
| Network Scope | Currently, all access points and the Gateway must sit in the same Meraki Network. Multi-network support is expected in future updates. |
| Licensing | The Gateway itself doesn’t need a licence. Your access points need Enterprise/Essentials or Advanced/Advantage tier licensing. |
Cisco Campus Gateway is designed for a specific kind of environment: large, mobile, and growing fast. If that sounds like you, it can be a game-changer.
Campus Gateway fills a specific gap: organisations that love Meraki’s simplicity but have outgrown what a distributed wireless setup can deliver.
If your campus wireless is struggling with scale, roaming or network congestion, Campus Gateway gives you an upgrade path that doesn’t require ripping out your existing infrastructure or retraining your team on a completely new platform.
If it works, don’t touch it. If your current setup is working well, there’s no reason to add complexity. The best infrastructure is the one that solves your actual problems.
Data#3 can support you at every stage, from initial assessment through pilot deployment and full campus rollout. Contact your account team to get started.
Information provided within this form will be handled in accordance with our privacy statement.