Campus Gateway Deployment Guide

Deployment goals 

• Centralize wireless traffic using VXLAN tunnels from APs to Campus Gateway 
• Enable seamless Layer 2 client roaming across all APs in the campus 
• Provide high availability and linear scalability through active-active clustering 
• Simplify RADIUS management by using Campus Gateway as a RADIUS proxy 
• Support Adaptive Policy, QoS, mDNS gateway, and WPN for tunneled SSIDs 

Hardware requirements 

• One or two Campus Gateway appliances per cluster 
• Compatible Cisco cloud-managed Access Points (MR and CW series) 
• Upstream switch with sufficient MAC and ARP table scale (refer to the Recommended upstream switches and topology section of the Campus Gateway Design and Best Practice Guide)  
• At least two physical uplink ports connected from each Campus Gateway to the upstream switch for link redundancy 
• Redundancy Port (RP) cabling for high availability clusters: 
• 1x 1G RJ45 copper port, or 
• 1x 1G/10G SFP/SFP+ fiber port 
• Use only ports of the same speed and type for uplink connections (either all 10GE or all 25GE) 
• Appropriate SFP/SFP+ modules for fiber connections (refer to the Supported SFP Modules section in product documentation) 

Software requirements 

The first software release version that supports Campus Gateway is MCG 31.2.X and the corresponding AP version will be MR 31.2.X.  

• Identical firmware versions: Use the same firmware versions for Campus Gateway and APs. For example, use MCG 31.2.5 and MR 31.2.5 for your devices. 
• Legacy APs: If APs cannot be upgraded to MR 31.2.X or later (for example, Wi-Fi 5 APs), the APs will stay on the latest supported code and will not be able to tunnel SSIDs to the Campus Gateway. 
• When to upgrade: The upgrade should be done after adding the Campus Gatewayto the network but before configuring the SSIDs to tunnel to Campus Gateway. Refer to steps in the Upgrade software section in this deployment guide. 
  • If upgrading MR 31.2.X / MCG 31.2.X, these options will not appear until the Campus Gateway is added to the network. MR 32.1.X and later will appear regardless of Campus Gateway being added to the network. 
  • Campus Gateway firmware will not appear until a Campus Gateway is added to the network. 

Licensing requirements 

Campus Gateway will not require a dedicated license, but it is required for the APs to have an Enterprise/Essentials or Advanced/Advantage tier license. Organizations are required to be using either co-termination Meraki subscription, or Cisco Networking subscription licensing. 

Support for the Campus Gateway is included as part of the active Access Point license within the organization. A valid license for the associated Access Points provides full entitlement to 24/7 technical support, firmware updates, and cloud management for the wireless infrastructure. 

Network requirements

• IP Addressing: IPv4 address (either DHCP or static IP assignment) for the Campus Gateway Management Interface; static IPv4 assignment for the AP Tunnel Interface 
  • IPv6 for Campus Gateway interfaces is not currently supported 
• VLANs:  
  • Management VLAN, AP Tunnel VLAN (if using dual L3 interface deployment), and client VLANs (any valid ID in range of 1-4094, excluding 1002-1005) 
• Firewall Rules: 
  • Allow outgoing connections on ports and IP addresses listed under Help > Firewall info in the Meraki dashboard 
  • Refer to Upstream Firewall Rules for Cloud Connectivity for the full list 
  • If a firewall exists between Campus Gateway and APs, open: 
    • UDP port 16674 for QUIC 
    • UDP port 16675 for VXLAN 
• DHCP: Active on at least one VLAN on the uplink switch, with a default gateway and DNS server, so the Campus Gateway can reach the Meraki dashboard 
• DNS: DNS servers must be provided via DHCP or static configuration so the Campus Gateway can reach the Meraki dashboard 
• Trunk Configuration: 802.1Q trunk on the upstream switch ports connected to Campus Gateway, with at least one active VLAN 
• RP Link Requirements (for HA clusters): 
  • Latency < 80 ms 
  • Bandwidth > 60 Mbps 
  • MTU >= 1500 bytes 
• Inter-DC Requirements (if deploying across data centers): Layer 2 connectivity is required so that Management VLANs, client VLANs, and RP VLAN can be shared (refer to the Recommended cluster deployment topologies section in the Campus Gateway Design and Best Practice Guide) 

Check and configure upstream firewall settings 

If a firewall is in place, it must allow outgoing connections on specific ports to specific IP addresses. Follow these steps: 

1. Log in to the Meraki dashboard. 
2. Navigate to Help → Firewall info (the Help button is in the top-right corner of any dashboard page) to find the most current list of outbound ports and IP addresses for your organization. 
3. Configure your upstream firewall to allow these outbound connections. 
4. If there is a firewall between the Campus Gateway and APs, ensure that the following ports are open: 
   1. UDP port 16674 — for QUIC 
   2. UDP port 16675 — for VXLAN 
5. For more information, refer to the Upstream Firewall Rules for Cloud Connectivity documentation. 

Port-channel configuration 

The Campus Gateway comes by default with all the data ports placed into a single port-channel with LACP mode active configured. An example configuration of the CW9800H1-MCG is shown below. By default, all VLANs are allowed on the ports with a native VLAN ID of 1.   

port-channel load-balance src-dst-mixed-ip-port  
!
interface TwentyFiveGigE0/1/0
 switchport mode trunk
 channel-group 1 mode active
interface TwentyFiveGigE0/1/1
 switchport mode trunk
 channel-group 1 mode active
interface Port-channel1
 switchport mode trunk
end

The load balancing algorithm used by Campus Gateway is src-dst-mixed-ip-port. It is recommended to match this on the upstream switch side. If non-Cisco switches are used, consult the vendor documentation to confirm this load balancing algorithm is supported. 

Example port-channel configuration for a customer-managed Cisco switch (either on-prem managed or cloud-managed device configuration)

port-channel load-balance src-dst-mixed-ip-port  
!
interface TwentyFiveGigE 1/0/19
  channel-group 1 mode active
  switchport mode trunk
  switchport trunk allowed vlan 2,3-10
interface TwentyFiveGigE 1/0/20
  channel-group 1 mode active
  switchport mode trunk
  switchport trunk allowed vlan 2,3-10
interface PortChannel 1
  switchport mode trunk
  switchport trunk allowed vlan 2,3-10
  

If connecting to a Cisco switch in cloud-managed cloud configuration or a Meraki MS switch, use dashboard to configure a port-channel on the ports connected to the Campus Gateway. 

For detailed instructions on configuring port-channel on cloud-managed Cisco switches, see: Link Aggregation and Load Balancing 

What if you connect Campus Gateway with only one link? 

This is not recommended in production but may occur in a lab during testing. Even if only one port on Campus Gateway is connected, you must create a port-channel with one port on the switch side. If you do not, the Campus Gateway port will not come UP and will not pass traffic because it fails to negotiate LACP packets. 

To configure a port-channel with one physical port: 

• In IOS-XE: Create the port-channel interface as shown in the example above and add the channel-group command on the connected physical port. 

• In dashboard (for MS or cloud-managed Catalyst switch): You need to select at least two ports to aggregate them in a port-channel. Select the connected port and another port that is not connected, then click on the Aggregate tab. 

Onboarding the Campus Gateway 

The Campus Gateway is a one-armed concentrator with a single logical link to the upstream network. This link consists of multiple physical links operating in a single port-channel with LACP and operates as a Layer 2 trunk. All traffic (management, control, and data) uses this link and is separated using VLANs. 

It is always recommended to connect at least two physical ports on Campus Gateway for link redundancy. Even if only one port is connected, it is mandatory to configure the upstream switch with an EtherChannel with one port to allow LACP negotiation. 

Adding Campus Gateway to a network 

Adding Campus Gateways to a network using the Meraki app is currently not supported. 

Campus Gateway and access points must be in the same Meraki Network. Tunneling across networks is not currently supported. 

Onboarding flow 

After connecting the Campus Gateway(s) to the upstream switch, power on the Campus Gateway(s) and wait for the device to boot and connect to dashboard. 

Once the onboarding flow is completed, it takes about 5 minutes for the new configurations to be applied, assuming the Campus Gateway is already connected to dashboard (indicated by LED indicators on the front of the device). 

If the Campus Gateway fails to connect to dashboard, check the Local Status Page for connectivity or initial port configuration issues (see Section 7.1). 

Step 1: In either Network-wide > Configure > Add Devices or Organization > Configure > Inventory, select either a single Campus Gateway or both Campus Gateways and select Add to network. This can be a new network or an existing network.

Step 2: Adding a Campus Gateway to a Meraki Network triggers the onboarding flow to add the Campus Gateway to a cluster. The Campus Gateway must be added to an existing network or a new network. 

• Existing Network: Select the existing network name. 

• New Network: Input the new network name and select the network configuration to use if needed. 

Step 3: Configure the Management and AP Tunnel Interfaces. These are the only two L3 interfaces that can be configured on Campus Gateway. 

• Management Interface: Used for communication with Meraki dashboard and building the Meraki Tunnel. Can be assigned an IP via DHCP or static. 
• AP Tunnel Interface: Used to terminate VXLAN tunnels from APs and to source traffic to network services (such as RADIUS, syslog). Must be assigned a static IP, as this is the tunnel termination point and cannot change dynamically without causing network disruption. 

These can be deployed as: 

• Single L3 Interface Deployment: Both the Management and AP Tunnel Interfaces share the same VLAN and IP address. The IP address must be static. This is simpler to deploy as only one VLAN and subnet needs to be configured. 
• Dual L3 Interface Deployment: The Management and AP Tunnel Interfaces are separate interfaces on different VLANs and subnets. The Management Interface IP can be static or DHCP. The AP Tunnel Interface must be static. This has the benefit of separating internet/dashboard traffic from internal traffic. 

 

Configure the Management Interface using DHCP or static assignment. If the AP Tunnel Interface will share the same L3 interface, leave Manually configure AP tunnel interface for this cluster untoggled. 

If the AP Tunnel Interface will be a different L3 interface, toggle this option and specify a different VLAN/subnet. 

Step 4: Configure the settings for the Campus Gateway cluster. 

• Cluster name: Used when referring to and selecting the Campus Gateway cluster to tunnel SSIDs to. 
• Uplink port native VLAN: Should match the upstream switch configuration. Untagged received traffic belongs to this VLAN. Traffic sent on this VLAN is sent untagged (without an 802.1Q tag). Accepts one VLAN number. Default is VLAN 1 if left blank. Range: 1-4094, excluding 1002-1005. 
• Uplink port client VLANs: Defines the list of VLANs that clients will be assigned and that are allowed on the trunk interface to the upstream switch. Client traffic on VLANs not defined here will be dropped. Accepts multiple VLAN numbers and ranges. Range: 1-4094, excluding 1002-1005. 

Step 5: Review the configurations and click Finish to deploy the Campus Gateway to the network. 

Step 6: The Campus Gateway Clusters page displays a list of all Campus Gateways added to the cluster along with the cluster configurations. Once SSIDs are configured to tunnel to the cluster, they will appear in the SSID section. 

Step 7: To change the cluster settings, click the Edit button. 

A slide-out menu will appear where you can edit: 

• Management VLAN and Interface for each Campus Gateway 
• AP Tunnel Interface for each Campus Gateway 
• Uplink port native VLAN 
• Uplink port client VLANs 

Access point to Campus Gateway assignment 

When APs are configured to tunnel to Campus Gateway clusters, they receive a list of Campus Gateways from dashboard. 

• APs that belong to the same subnet are assigned to the same Campus Gateway. 
• Depending on the number of subnets and APs in those subnets, load balancing may not be split evenly between the two Campus Gateways in the cluster. 
• APs maintain tunnels to both the primary and backup Campus Gateway. 
• For APs in different subnets, the primary and backup Campus Gateway will be different. For example, CG1 is primary and CG2 is backup for AP1, and vice versa for AP2. 

If the second Campus Gateway in the cluster is added after the initial deployment (traffic is already being tunneled), the Campus Gateways will form the cluster but will not load balance the APs immediately. APs continue tunneling to the first Campus Gateway until the maintenance window (the same window used for firmware upgrades, defined in Network-wide > General). 

How do I monitor which Campus Gateway an AP is tunneling to? 

In the Campus Gateway Clusters page, select the Tunneled APs tab. If both the Tunnel status is up (meaning both QUIC and VXLAN tunnels are up between the AP and current Campus Gateway), the Campus Gateway field will show which Campus Gateway the AP is tunneling to. 

Redundancy Port 

The Redundancy Port (RP) is a dedicated port on the Campus Gateway chassis for syncing client states between chassis. The Campus Gateway has two RP port options: 

• 1x 1G RJ45 copper port 
• 1x 1G/10G SFP/SFP+ fiber port 

Either port can be used for HA. Refer to the Supported SFP Modules section for supported modules. 

If the RP link is connected between the Primary and Backup Campus Gateways, they will sync client states over the RP link. Fast keepalives are sent every 100 ms. Keeping the Campus Gateways in sync allows the data path to remain hot with backup tunnels kept alive, enabling failover times of 1-2 seconds if one Campus Gateway fails. Without the RP link, failover time may increase. 

RP Link Connection Methods: 

1. Back-to-Back: The RP port on both Campus Gateways is directly connected with no intermediate switches. This is the recommended method because it is the simplest. The causes of failover would be either a Campus Gateway chassis failure or the RP link failure. The downside is that the maximum distance between Campus Gateways is limited by the SFP/SFP+ module specifications. 
2. Dedicated L2 VLAN with Intermediate Switches: The RP port on each Campus Gateway is connected to a dedicated port on its respective upstream switch. The connections must share a dedicated L2 VLAN. If the Campus Gateways are in separate data centers, the VLAN must be spanned across the data centers. This method removes the distance limitation but adds deployment complexity. 

RP Link Requirements: 

Parameter	Requirement
Latency	< 80 ms
Bandwidth	> 60 Mbps
MTU	>= 1500 bytes

Upgrade software 

The first software release version that supports Campus Gateway is MCG 31.2.X and the corresponding AP version will be MR 31.2.X.  

• Identical firmware versions: It is mandatory to use the same firmware versions. For example, if the Campus Gateway is updated to MCG 31.2.5, the APs will need to run MR 31.2.5 as well. 
• Legacy APs: APs in the same Meraki Network that cannot be upgraded to MR 31.2.X or later (for example, Wi-Fi 5 APs and earlier) will stay on the latest supported code. These APs will not be able to tunnel SSIDs to Campus Gateway. 

Upgrade firmware in the Meraki dashboard:  

• Where to upgrade: The Campus Gateway and corresponding AP image firmware will be available in the Firmware Upgrades page. Choosing the Campus Gateway image will automatically select the AP image to be upgraded as well. 
• Upgrade order: The dashboard will upgrade the Campus Gateway first followed by the AP. 

Both options, Minimize upgrade time and Minimize client downtime, are supported for firmware upgrades.  

For more information refer to the Managing Firmware Upgrades and Access Point Firmware Upgrade Strategy documentation. 

SSID creation 

Tunneling to a Campus Gateway Cluster is a per-SSID configuration. For a campus greenfield Meraki deployment, it is expected that all SSIDs will be centrally tunneled. Each AP forms a VXLAN tunnel to the Campus Gateway, which all SSIDs tunneling to a cluster share. This creates an L2 overlay that allows clients to roam seamlessly across all APs in the campus. APs can broadcast both centrally tunneled and locally bridged SSIDs concurrently. 

When clients associate to the tunneled SSID, they are mapped to a VLAN defined centrally at the Campus Gateway. The client VLAN is carried to the distribution or core switch, which acts as the default gateway. Because the client VLAN only exists between the Campus Gateway and uplink switch, it can be made as large as needed (for example, /21) since the broadcast domain is confined. 

Tunneling supports all SSID configurations: 

• Passphrase (WPA2 PSK, WPA3 SAE, and iPSK without RADIUS) 
• RADIUS-based (802.1X, MAB, iPSK with RADIUS) 
• Open / OWE 
• WPN 
• Splash Page 

Configuring Tunneling for SSIDs: 

Step 1: Go to Wireless > Configure > Access Policy and select the SSID to be tunneled.

 

Step 2: In the Client IP and VLAN section, select External DHCP server assigned and the Tunneled option. Select Tunnel mode with Campus Gateway (MCG) and choose the Campus Gateway cluster created. 

If required, enable mDNS gateway here. Refer to the Configure mDNS Gateway Mode section in this guide. Also refer to the Broadcast and multicast traffic suppression section in the Campus Gateway Design and Best Practice Guide for supported mDNS modes and example diagrams.  

Step 3: Set the client VLAN in the VLAN tagging section. This can be either the VLAN ID or a Named VLAN. The VLAN configured must be in the list of Uplink port client VLANs configured on the Campus Gateway cluster. 

For more information on configuring Named VLANs and VLAN profiles, refer to VLAN Profiles documentation. 

For the following cases, client traffic will be sent out of the Campus Gateway untagged and tagged with the native VLAN configured on the uplink switch port: 

• VLAN tagging is disabled (no VLAN assigned) 
• VLAN ID is set to 0 
• VLAN is set to the Native VLAN of Campus Gateway 

Configuring Adaptive Policy 

Adaptive Policy is configured per Meraki Network and applied at the AP. Dashboard pushes the configurations for Security Group Tags (SGTs) and Security Group Access Control Lists (SGACLs) to the APs. The APs learn the local clients' SGT via the RADIUS Access-Accept response during client authentication or via static configuration through dashboard. 

Upstream (at the AP level): The AP inserts the SGT in the segment ID (SID or policy) in the VXLAN header. The Campus Gateway uses this when bridging the traffic by inserting the received SGT into the CMD header of the 802.1Q packet. The policy is then applied at the destination device (switch or AP). 

Downstream (at Campus Gateway): The Campus Gateway reads the SGT from the CMD header and copies it into the SID in the VXLAN header. The policy is applied at the AP. The source SGT is received in the VXLAN header while the destination SGT is known because it belongs to the locally managed client. From there, the SGACL policy is applied. 

Enabling Adaptive Policy on Campus Gateway occurs in the following scenarios: 

• Campus Gateway is added to a network with Adaptive Policy already enabled 
• Adaptive Policy is enabled on a network with Campus Gateway already added 

Configure mDNS Gateway Mode 

Refer to the Broadcast and multicast traffic suppression section in the Campus Gateway Design and Best Practice Guide for supported mDNS modes and example diagrams.  

Step 1: Go to Wireless > Configure > Access Policy and select the SSID to be tunneled. 

Step 2: In Client IP and VLAN > External DHCP server assigned > Tunneled > Tunnel mode with Campus Gateway (MCG), toggle mDNS gateway to enable. 

Step 3: Select all the necessary mDNS services that clients should be able to discover across VLANs. 

Monitoring AP tunnel status 

In the Campus Gateway Clusters page, select the Tunneled APs tab. If both QUIC and VXLAN tunnels are up between the AP and the current Campus Gateway, the Campus Gateway field will be populated with the Campus Gateway the AP is tunneling to. 

Campus Gateway cluster failure detection behavior 

Based on the failure type, the amount of downtime will vary. 

Campus Gateway cluster high availability behavior 

The table below captures the behavior for various scenarios in a cluster deployment. 

#	RP Link State	AP Tunnel Interface Link	Gateway State at Primary Campus Gateway	Gateway State at Preferred Backup Campus Gateway	Action
1	UP	UP	UP	UP	AP joins the primary and preferred backup Campus Gateway. Clients are anchored on the primary. Client records are replicated to the preferred backup. Client state is plumbed to the data plane in the preferred backup and data plane is hot.
2	UP	UP	UP	DOWN	AP joins the primary Campus Gateway. Clients are anchored on the primary. Client records are replicated to the preferred backup. Client states are not plumbed to the data plane in the preferred backup as the AP has not joined it.
3	UP	UP	DOWN	UP	When gateway reachability is lost at the primary Campus Gateway, the preferred backup Campus Gateway notifies the AP. The AP unblocks the VXLAN tunnel with the preferred backup Campus Gateway and GARPs are sent out for the plumbed clients. The AP re-anchors clients to the preferred backup, and clients become active. Gateway reachability failure detection should happen faster than the AP detecting loss of connectivity to the primary Campus Gateway.
4	UP	UP	DOWN	DOWN	AP cannot join the primary or the preferred backup. No client records in either Campus Gateway.
5	UP	DOWN	UP	UP	AP joins the primary and preferred backup Campus Gateway. Clients are anchored on the primary. Client records are replicated to the preferred backup. Client state is plumbed to the data plane in the preferred backup and data plane is hot. Note: Since the AP Tunnel Interface link is down, Dual Master Detection (DMD) is not possible at this time if the RP link goes down.
6	UP	DOWN	UP	DOWN	AP joins the primary Campus Gateway. Clients are anchored on the primary. Client records are replicated to the preferred backup. Client state is not plumbed to the data plane in the preferred backup as the AP has not joined it. Note: Since the AP Tunnel Interface link is down, Dual Primary Detection is not possible at this time if the RP link goes down.
7	UP	DOWN	DOWN	UP	When gateway reachability is lost at the primary Campus Gateway, the preferred backup Campus Gateway notifies the AP. The AP unblocks the VXLAN tunnel with the preferred backup Campus Gateway and GARPs are sent out for plumbed clients. The AP re-anchors clients to the preferred backup and clients become active. Gateway reachability failure detection should happen faster than the AP detecting loss of connectivity to the primary Campus Gateway. Note: Since the AP Tunnel Interface link is down, Dual Primary Detection is not possible at this time if the RP link goes down.
8	UP	DOWN	DOWN	DOWN	AP cannot join the primary or the preferred backup. No client records in either Campus Gateway.
9	DOWN	UP	UP	UP	AP joins the primary and preferred backup Campus Gateway. Clients are anchored on the primary. Client records are not replicated to the preferred backup since the RP link is down.
10	DOWN	UP	UP	DOWN	AP joins the primary Campus Gateway. Clients are anchored on the primary. Client records are not replicated to the preferred backup since the RP link is down.
11	DOWN	UP	DOWN	UP	When gateway reachability is lost at the primary Campus Gateway, the preferred backup Campus Gateway notifies the AP. The AP unblocks the VXLAN tunnel with the preferred backup Campus Gateway. The AP re-anchors clients to the preferred backup and client state is created and plumbed to the data plane (similar to the client joining fresh).
12	DOWN	UP	DOWN	DOWN	AP cannot join the primary or the preferred backup. No client records in either Campus Gateway.
13	DOWN	DOWN	UP	UP	Double fault. Since the Campus Gateways cannot communicate with each other, each node assumes the other is down. But the AP will be able to connect to the primary as well as the preferred backup. The AP may anchor the clients on the primary, but there will be no replication of records to the preferred backup. Note: When both the RP and AP Tunnel Interface links go down, the Campus Gateway will send a Peer Node Down event to the AP. The AP may see a conflict (Peer Node Down event, yet its QUIC tunnel with the primary is UP).
14	DOWN	DOWN	UP	DOWN	Double fault. Since the Campus Gateways cannot communicate with each other, each node assumes the other is down. But the AP will be able to connect to the primary. The AP anchors the clients on the primary, but there will be no replication of records to the preferred backup.
15	DOWN	DOWN	DOWN	UP	Double fault. Since the Campus Gateways cannot communicate with each other, each node assumes the other is down. But the AP will be able to connect to the preferred backup. The AP anchors the clients on the preferred backup. Note: When both the RP and AP Tunnel Interface links go down, the Campus Gateway will send a Peer Node Down event to the AP.
16	DOWN	DOWN	DOWN	DOWN	AP cannot join the primary or the preferred backup. No client records in either Campus Gateway.

Connecting to the Local Status Page 

If connectivity between Campus Gateway and dashboard is lost or cannot be established, the Local Status Page (LSP) can be used to manually configure parameters such as the uplink port VLAN, IP address, or DNS settings to restore connectivity. 

Common reasons for connectivity issues: 

• DHCP is not available on the active VLAN 
• Information provided by DHCP is incorrect (missing DNS, wrong default gateway, etc.) 
• Connectivity to Meraki dashboard is not available 

There is no console access on Campus Gateway, so the LSP is the primary tool for out-of-band uplink configuration and overall system health checks.

Local Status Page features