Campus Gateway Design and Best Practice Guide

Hardware 

• Cisco Campus Gateway appliance (shares the same hardware platform as the CW9800H1 and CW9800L WLC) 

• Cloud-managed Cisco APs (MR and CW series) 

• Core/distribution switches (upstream from the Campus Gateway) 

• Access switches (for AP connectivity) 

Software/Firmware 

• Campus Gateway firmware:  
  • CW9800H1-MCG: MCG 31.2.X or later 
  • CW9800L-MCG: MCG 32.2.X or later 
• Access Point firmware:  
  • Tunneling to CW9800H1-MCG: MR 31.2.X or later 
  • Tunneling to CW9800L-MCG: MR 32.2.X or later 

Note: Campus Gateway and AP firmware versions must be identical (for example, if the Campus Gateway runs MCG31.2.5, APs must run MR31.2.5) 

Licensing requirements 

The Campus Gateway does not require a separate license, and technical support is included under active licensing for associated access points. 

For more information, refer to the “Licensing Requirements” section in the Campus Gateway Deployment Guide. 

Recommended design principles 

• Limit client VLANs to the core/distribution layer. Terminate client VLANs only on the connection between the Campus Gateway and the upstream switch to reduce broadcast domain size. 

• Ensure IP connectivity between APs and the Campus Gateway. This is the only requirement for the control plane and data plane tunnels to establish properly. 

• Deploy Campus Gateway for medium to large campus environments. For small to medium sized deployments, such as branch offices or single buildings with 300 APs or less, a traditional distributed deployment with local switching may be sufficient. For deployments with more than 300 APs, it is recommended to deploy a Campus Gateway for a centralized deployment. 

• Do not use MX as a wireless concentrator for large campus deployments. While MX is still available as an option in dashboard, it has various scale limitations and has not been tested for large wireless deployments. 

Why is a centralized deployment needed? 

Traditionally, Cisco cloud-managed wireless deployments use a distributed model where each AP locally switches client traffic via a Layer 2 (L2) trunk port to the access switch. Because of this, client VLANs must span across all access switches where seamless roaming is required. If the VLANs do not span, the client would need to obtain a new IP address when roaming, resulting in a broken session. This distributed method is completely sufficient for small to medium sized deployments, such as branch offices or individual buildings, where the same VLAN can be shared and spanned across all switches to create an L2 roaming domain. 

However, as cloud-managed wireless deployments grow to medium and large campus sizes (for example, university campuses), the limits of a distributed wireless design are reached: 

• Spanning L2 VLANs across all access switches creates a large broadcast domain. 

• The number of wireless clients begins to overwhelm the ARP and MAC address tables of the access switches. Every wireless client needs to be in the tables for every access switch where the L2 VLAN is defined. 

• When a client roams between APs, each switch must update its tables, which is a CPU-intensive task. 

• Spanning tree implications and BUM (Broadcast, Multicast, and Unknown Unicast) traffic become increasingly difficult to manage in a large L2 network. 

• When thousands of clients are roaming, the CPU utilization on every switch becomes extreme, potentially leading to switch failures. 

By centralizing wireless traffic at the Campus Gateway, client VLANs only need to exist on the connection between the Campus Gateway and the upstream switch. This upstream switch is typically the core or distribution switch, which has much greater scale and capacity compared to access switches. Limiting client VLANs to the upstream switch also contains the broadcast domain to a much smaller area. 

Additionally, the Campus Gateway deployment uses an overlay design. Rather than redesigning the underlay switching network to account for wireless traffic being switched via L2 trunks at the AP level, traffic is tunneled from the AP to the Campus Gateway. As long as the APs and Campus Gateway have IP connectivity, the control plane and data plane tunnels will form, meaning very few changes to the wired infrastructure are needed. 

Moving from a traditional customer-managed Catalyst wireless deployment should be as simple as migrating to cloud-managed APs and replacing the WLC with the Campus Gateway. 

How is Campus Gateway different from MX? 

Although MX is still available as an option in dashboard to serve as a wireless concentrator to tunnel wireless client traffic to a centralized box, it is not recommended for large campus deployments. MX as a concentrator has various scale limitations and has not been tested for large wireless deployments. 

The Campus Gateway architecture is fundamentally different, with different scalability and tunneling technologies. These are all implemented in hardware, making the Campus Gateway ideal for scaling to large campus requirements. 

Additionally, the Campus Gateway provides unique features that are not available in MX: 

• Centralized client database for seamless roaming 
• RADIUS proxy 
• mDNS gateway 

Security considerations and compliance 

• QUIC tunnels are encrypted using TLS with dashboard-provisioned keys or certificates, securing all control plane communication between the APs and the Campus Gateway. 
• RADIUS proxy functionality is built into the Campus Gateway, with RADIUS messages carried inside the VXLAN data plane tunnel. 
• Policy and security tags are carried in the VXLAN tunnel header, including DSCP and SGT (Security Group Tag) information, supporting end-to-end policy enforcement. 

Performance, scalability, and reliability guidelines 

Architecture of a Campus Gateway Deployment 

While the Campus Gateway serves the same purpose in terms of client traffic aggregation as a WLC and shares the same hardware as the CW9800H1 WLC, it is not a cloud-managed WLC. It is a purpose-built appliance for data plane aggregation and real-time control plane services for wireless traffic. 

To meet large-scale roaming requirements, certain aspects of the wireless network need to be brought back to a centralized on-premises appliance while keeping the rest on Dashboard and APs. 

The following list includes a breakdown of these functions: 

1. Meraki dashboard 
   1. Management plane 
      • Configuration management 
      • Monitoring and troubleshooting 
      • Software management 
      • Licensing 
      • Serviceability/debugging 
   2. Non-real-time control plane 
      • RRM (AI-RRM) 
      • Air Marshal 
      • Rogues 
2. Campus Gateway 
   1. Data plane 
      • Data plane termination 
      • VLAN termination 
   2. Real-time control plane 
      • AAA Proxy 
      • Roaming – key management 
      • Dstore (client DB) 
      • mDNS Gateway 
3. MR AP 
   1. Data plane 
      • Bridge local SSIDs 
      • Tunnel central SSIDs 
      • QoS 
      • Rate Limit 
      • Adaptive policy tagging 
   2. Real-time control plane 
      • Client authentication 
      • Client state machine 
      • Telemetry 

How do the devices communicate with each other and the dashboard? 

Recommended upstream switches and topology 

The Campus Gateway supports up to 50,000 clients. To take advantage of full scale, the upstream switch must have MAC and ARP tables that exceed this capacity. 

Full scale: 

Partial Scale: 

If only partial scale is needed, a lower-capacity switch can be used. However, as scale increases, the MAC and ARP table limits of those switches will be reached. 

Recommended uplink topology 

Two supported upstream switch topologies are available. For both, use a switch deployment where multiple switches act as a single logical switch (for example, VSS, SVL, vPC) or in HSRP. If multiple Campus Gateways are deployed (maximum of two in a cluster), the uplink switch will have a unique port-channel configured for each Campus Gateway. 

Recommended cluster deployment topologies 

Two Campus Gateway Cluster in One DC 

• Cross-connect the uplinks to a single logical distribution switch (vPC, VSL, etc.) to prioritize redundancy while maintaining adequate throughput during switch failure 
  • If maximum throughput is required, connect each Campus Gateway's uplinks to unique switches in the stack (for example, CG1 to SW1 and CG2 to SW2) 
• RP ports can be directly connected or connected through the upstream switch with L2 VLANs 
• On the upstream switch, configure two unique EtherChannels (one for each Campus Gateway) using LACP with trunking enabled and the corresponding list of allowed VLANs 

Two Campus Gateway Cluster Across DCs 

• Recommended when increased redundancy is needed (for example, the cluster is split between different buildings, areas of the data center on different power distributions, or different data centers) 
• Inter-DC connections must be Layer 2 to allow Management VLANs, client VLANs, and RP VLAN to be shared 
• If distance allows, the two Campus Gateways' RP link can be directly connected 

Quality of Service (QoS)  

Control Plane (CP) QoS 
QUIC Tunnel traffic is marked with DSCP = CS6. 

Data Plane (DP) QoS 
For client traffic, Network Based Application Recognition (NBAR) runs on the AP, recognizing and classifying traffic at the AP level. Any client QoS policy is implemented at the AP. 

Campus Gateway supports the "DSCP trust" QoS model: 

• Upstream (at the AP): The DSCP value is copied to the outer header of the VXLAN packet. 

• Downstream (at the Campus Gateway): The Campus Gateway does not enforce any QoS policy, as it trusts the client DSCP. The policy is applied only at the AP. 

If a policy is in place (for example, rate limiting or DSCP remarking), the AP applies the policy. The Campus Gateway passes the DSCP value unchanged (assuming no additional QoS policies are applied). 

For Wireless QoS configuration, refer to: Wireless QoS and Fast Lane 

Broadcast and multicast traffic suppression 

Broadcast Traffic: When deployed, Campus Gateway will block all broadcast traffic going downstream destined to wireless clients (wired to wireless) with the exception of few packet types: 

• ARP 
• DHCP/DCHPv6 
• IPv6 NS/NA 

When forwarding the allowed packets, the traffic will only be sent to the AP where the client is connected to. 

Multicast Traffic: When Campus Gateway is deployed, all multcast traffic will be dropped with the exception of active mDNS queries and mDNS service advertisements when mDNS Gateway is configured.