Campus Gateway Deployment Guide

How is Campus Gateway different from MX?

Although MX is still an option in Dashboard as a wireless concentrator to tunnel wireless client traffic to a centralized box, it is not a recommended deployment for a Large Campus deployment. MX as a concentrator has various scale limitations and has not been tested for large wireless deployments. Campus Gateway architecture is different with different scalability and tunneling technologies. These are all implemented in hardware, making it ideal to scale to Large Campus requirements. Additionally, CG provides unique features like a centralized client database for seamless roaming, RADIUS proxy, mDNS gateway, etc., which are not available in MX.

Management Plane

Like existing cloud-managed devices, Campus Gateway and APs will each be managed directly and natively by Dashboard. This is the same as the MR, MS, MX, and other cloud-managed Cisco devices today. Each device will have its own Meraki Tunnel connection to the cloud.  The CG does not serve any management function as it is an overlay L3 tunnel solution for bridging client traffic into the network core.

Control Plane

The control plane (CP) tunnel between Campus Gateway and APs will leverage the QUIC protocol. The CP tunnel will be used to carry messages like AP registration, client anchoring, etc. Also, it will be utilized to carry packets for high availability messages and inter-CG traffic.

The QUIC protocol is a UDP-based transport protocol developed to be as reliable as TCP without suffering from the overhead associated with TCP. TCP suffers from head-of-line blocking where the messages sent are a single byte stream, so if one large packet needs to be retried, all subsequent packets in the stream are blocked until the packet is successfully sent. For QUIC, traffic is sent in multiple streams. If one packet is lost, only the stream which the packet is a part of is affected while the rest will continue to operate as normal.

The QUIC tunnels are secured via TLS encryption with Dashboard-provisioned keys or certificates. Each AP will establish a QUIC tunnel to each CG in the cluster with regular keepalives being sent to check the status of the Primary and Backup CG in the cluster.

Data Plane

The data plane (DP) tunnel between Campus Gateway and APs will leverage the Virtual eXtensible Local Area Network (VXLAN) protocol. These will be stateless and transient tunnels, relying on per-packet encapsulation. The encapsulation used will be the standard VXLAN encapsulation. The tunnel will be used to carry client data packets which are then bridged onto the client VLANs at the CG. The tunnel header will carry the QoS and policy information (e.g., DSCP, SGT, VRF) while RADIUS messages will also be carried inside the tunnel.

There is the possibility for two flows between the AP and CG to have vastly different network paths. To identify which connections belong to which AP. To combat this, there is a monitoring check implemented on the VXLAN connection. This uses the bidirectional forwarding detection (BFD) mechanism for VXLAN (for more information, see RFC8971).

Built-In SFP and SFP+ Ports

Supported SFP Modules

Upstream Switch Connection

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

It is always recommended to connect at least two physical ports on Campus Gateway to provide 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.

Recommended Upstream Switches

Recommended Switch Topology 

There are two supported upstream switch topologies. For both, a switch deployment where multiple switches will act as a single logical switch (ex. VSS, SVL, vPC) or in HSRP. If there will be multiple Campus Gateways deployed (at FCS this will be a max of two), the uplink switch will have a unique port-channel configured for each Campus Gateway.

Uplink connection default Behavior

For the initial boot and for Dashboard registration, it’s critical to connect the Campus Gateway to a switch via at least one port configured with a 802.1Q trunk connection that has at least one active VLAN. The VLAN needs to provide an IPv4 DHCP address to CG with related DNS servers so that it can automatically reach Dashboard. This VLAN with active DHCP can be a 802.1Q tagged VLAN or the native VLAN on the trunk port. Once the CG is configured via the cluster onboarding flow, the user can change the CG’s IP address to a static IP in the same or different VLAN. It is recommended to use a 802.1Q tagged VLAN to carry the management and client traffic.

By default, when the Campus Gateway boots up, all ports (4x25G and 8x10G) will be configured to be in a single port-channel. This means that before wiring up the CG to the rest of the network, the ports on the upstream switch will need to be configured in a port-channel to allow the CG to come up. At least 2 ports are recommended for CG to upstream switch connections.

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

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

How does Campus Gateway reach out to Dashboard initially?

After initial boot up, Campus Gateway will leverage the Meraki auto-uplink logic to determine one active VLAN which it can use to connect to Dashboard. The CG will detect the available VLANs which are on the trunk port and choose one with internet connectivity. Campus Gateway leverages DHCP on the selected VLAN to get and IP address and automatically connect to Dashboard

In order for Campus Gateway and the auto-uplink to work, the user needs to make sure:

1. The uplink switch is configured accordingly (port-channel and trunk)
2. DHCP is active on at least one VLAN and with a default gateway and DNS server provider
3. Connectivity to dashboard is allowed on the active VLAN

Once Campus Gateway is connected to Dashboard and configured with the required connectivity information, Campus Gateway fetches the onboarding configuration and will use the IP address information pushed from Dashboard to connect to Dashboard from now on. For more information regarding the onboarding, please see the Adding Campus Gateway to a Network.

High Availability with Campus Gateway Clusters

When adding Campus Gateway to a network, Campus Gateway will be added as part of a cluster. A cluster represents a group of CGs with connectivity to a common set of client VLANs.

At FCS, a cluster will consist of a single Campus Gateway in a standalone deployment or two Campus Gateways in a high availability deployment.

A cluster of two Campus Gateways will be a high availability group which will provide both linear scalability and fault tolerance for Campus Gateway networks. The Campus Gateway clusters will operate in an Active-Active deployment with APs load balanced between the CGs in the cluster. The tunnel discovery and load distribution of the APs will be initiated by Dashboard.

This means that every CG will be used to terminate the data plane tunnels and switch the client VLANs to the upstream switch. This allows the throughput to increase to up to 200 Gbps since each CG is capable of up to 100 Gbps of throughput.

Active-Active clustering will be automatically configured by Dashboard whenever there are two Campus Gateways in to cluster. The members of a cluster will also be configured as mobility peers, so clients will be able to roam across APs tunneling to different primary Campus Gateways in the cluster seamlessly.

Onboarding Flow

Adding Campus Gateway to a network will trigger a new onboarding flow. This flow will have the user configure the necessary cluster settings. Users can add a single Campus Gateway at a time or both Campus Gateway units at the same time. The onboarding flow will be the same regardless.

After connecting the Campus Gateway(s) to the upstream switch, power on the CG(s) and wait for the box to power on and connect to Dashboard.

Once the onboarding flow is completed, it will take about 5 minutes for the new configurations to be applied to the CG, given the CG is already connected to Dashboard, which is indicated by the LED indicators on the front of the box.

If the CG fails to connect to Dashboard, check the Local Status Page for connectivity or initial port configuration issues. The steps for this can be found in the Local Status Page section.

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

Step 2: Adding a Campus Gateway to a Meraki Network will trigger the onboarding flow to add the CG to a cluster. First, the CG will need to either be added to an existing network or a new network.

a. Existing Network: Select the existing network name.

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

Step 3: Once the network is assigned, the Management and AP Tunnel Interfaces need to be configured. These will be the only two L3 interfaces that can be configured on Campus Gateway.

• Management Interface: This is the interface to the external network that is used to talk to Meraki Dashboard and build the Meraki Tunnel.This interface can be assigned an IP via DHCP or static
• AP Tunnel Interface: This is the interface to the internal network that is used to terminate the VXLAN tunnels from the APs as well as to source traffic to network services, like RADIUS, syslog, etc. This interface must be assigned an IP statically. This is needed as the AP tunnel interface is the tunnel termination point for the APs and cannot change dynamically without creating a network disruption.

These can be deployed as a single L3 interface (share the same IP address) or as dual L3 interfaces:

• Single L3 Interface Deployment: Both the Management and AP Tunnel are the same L3 interface, meaning that they share the same VLAN and IP address. This requires the IP address assignment to be static. This is easier to deploy as only one VLAN and subnet needs to be configured on the box.
• Dual L3 Interface Deployment: The Management and AP Tunnel Interfaces are separate interfaces on different VLANs and subnets. The Management Interface’s IP address can either be assigned statically or via DHCP. The AP Tunnel Interface must have an IP address assigned statically. This model has the benefit of keeping internet and Dashboard traffic separated from internal traffic.

Regardless of the deployment type chosen, the Management Interface will need to be configured, using DHCP or static assignment (if using a single L3 interface). Below is an example of a Static IP configuration.

If the AP Tunnel Interface will share the same L3 interface as the Management Interface, leave Manually configure AP tunnel interface for this cluster untoggled.

If the AP Tunnel Interface will be a different L3 interface, toggle Manually configure AP tunnel interface for this cluster. In this case, specify a different VLAN/subnet for this interface. An example configuration is shown below.

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

a. Cluster name: This will be used when referring to and selecting the CG cluster to tunnel SSIDs to.

b. Uplink port native VLAN: This should match what is configured on the uplink switch. Any untagged received traffic will be considered belonging to this VLAN. Any traffic sent on this VLAN will be sent untagged, without a 802.1Q tag. 

This field accepts only one VLAN number. If left blank, the default value will be VLAN 1. The VLAN used can be in the range 1-4094, excluding 1002-1005.

c. Uplink port client VLAN: This defines the list of VLANs which clients will be assigned and that will be allowed on the trunk interface to the upstream switch. If a client VLAN is not defined here, the client traffic will be dropped.

This field accepts multiple VLAN numbers and ranges. The VLANs used can be in the 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 CGs 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 on the Edit button. 

Slide-out menu to edit will pop-up:

a. Management VLAN and Interface for each CG

b. AP Tunnel Interface for each CG

c. Uplink port native VLAN

d. Uplink port client VLANs

Access Point to Campus Gateway Assignment

When APs are configured to tunnel to the Campus Gateway clusters, the APs will get a list of Campus Gateways from Dashboard. At FCS, APs that belong to the same subnet are assigned to the same CG. Depending on the number of subnets and APs in those subnets, the load balance may not be split evenly between the two CG in the cluster. The APs will maintain tunnels to the primary and backup CG. For APs in different subnets, the primary and backup CG will be different. For example, CG1 will be primary and CG2 will be backup for AP1 and vice versa for AP2.

In the event that the second CG in the cluster is added after the initial deployment of the first CG and APs (traffic is already being tunneled), the CGs will form the cluster but not load balance the APs. The APs will continue to tunnel traffic to first CG until the maintenance window. This will be the same window used for firmware upgrades defined in Network-wide > General.

Redundancy Port

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

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

Either port can be used for HA. Please see the Supported SFP Modules section for the modules supported.

The RP link can be connected in one of two methods:

1. Back-to-Back: In this way, the RP port on both CGs are directly connected back-to-back with no intermediate switches in between. This is the recommended method as this is also the simplest method as well. By directly connecting the CGs, the causes of the failover will either be either of the CG chassis failing or the RP link between the CGs failing. However, this will have the downside of limiting how far apart the CGs can be away from each other as the max distance will be based on the distance supported by the SFP/SFP+ modules.

2. Dedicated L2 VLAN with Intermediate Switches: In this method, the RP port on each CG will be connected to a dedicated port on their respective upstream switch. The connections must also share their own dedicated L2 VLAN for connectivity. 

If the CGs are in separate data centers, the VLAN must be spanned across the data centers. This method has the advantage of no longer being restricted to the max distance supported by the SFP/SFP+ modules. However, this will add more complexity into the deployment. Not only will the deployment have to consider how to configure and span the necessary VLANs, but also, in the event of a failover, the intermediate switches and their respective connections will now also have to be considered along with the status of the CGs.

Regardless of how the RP link is deployed, the link between the two Campus Gateways must meet the following requirements:

1. RP Link Latency < 80 ms
2. Bandwidth > 60 Mbps
3. MTU ≥ 1500B

Campus Gateway Cluster Failure Detection Behavior

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

Campus Gateway Cluster High Availability Behavior

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

Recommended Cluster Deployment Topology

Connecting to the Local Status Page

Health Summary

On the home page of the LSP, the user gets an overview of the status of the key Campus Gateway components. 

• Dashboard Connectivity: Quickly view the connection status to Dashboard

• CG Details: Get key information about the CG, such as Meraki Network, CG chassis name, and MAC Address.

• Client Connection: IP address of the client used to access the LSP

• Device Summary: The total number of APs tunneling to the CG and the number of clients connected

• System Resources: View the CPU and Memory utilization of the CG as well as the temperature of the chassis. The status of each power supply will also be shown.

Configuration

Switchport Details

The Admin and Operational status of all the ports as well as their VLAN configurations are shown. This can be used to verify the pushed configuration from Meraki Dashboard if any issues appear.

Access Points Page

The list of all the APs tunneling to the Campus Gateway will be shown as well as their respective MAC and IP addresses.

Clients Page

The list of all the clients that connect to the centralized SSIDs as well as which SSIDs and VLANs the clients are connected to. Anything other than the Run state for client state will indicate an issue in client connectivity.

Support Bundle Creation

In the event of any issues on the Campus Gateway, Meraki Support may ask for a support bundle to be generated on the CG for debugging purposes.

Step 1: Click Generate to begin the Support Bundle creation process. This will take a few minutes to complete.

Step 2: Once completed, click Download to get the generated tar.gz file and share this with Meraki Support.

Reset and Reload Campus Gateway

Campus Gateway can quickly be reloaded or completely factory reset using the LSP. Click on the respective button to do so.

RADIUS-based SSID and Campus Gateway as a RADIUS Proxy

For the case of RADIUS-based SSIDs, Campus Gateway will act as a RADIUS Proxy, further optimizing the scale and manageability of large scale wireless deployments.

In a distributed Cisco cloud-managed deployment, all the APs had to be added as a Network Access Server (NAS) to the RADIUS server. This resulted in having to potentially add hundreds, if not thousands, of devices to the RADIUS server, leading to complex management of the RADIUS server.

By making the CG act as a RADIUS proxy, only the IP of the CG now needs to be added as a NAS, drastically simplifying RADIUS management. The APs will still serve as the authenticator and manage the clients’ AAA sessions, but now the APs will send all RADIUS traffic to the CG. The CG will send the traffic to the RADIUS server and relay the RADIUS response to the AP. All the RADIUS messages will be sent to the CG via the VXLAN tunnels. RADIUS servers specified for each SSID will be used in order of priority when configured. CG acts as Radius Proxy only for the tunneled SSIDs. For locally bridged SSIDs, the AP talks to AAA server directly, as today.

Change of Authorization (CoA) is supported as well as being deployed together with fast and secure roaming (802.11r/OKC).

SSID Switching Type Co-Existence

For brownfield Cisco cloud-managed wireless deployments, there will be existing SSIDs that are locally switched at the APs. It is not expected that all these SSIDs will now be centralized at Campus Gateway all at once. Migration will happen in phases. Thus, the coexistence of locally bridged and centrally tunneled SSIDs will be supported on the same APs. Clients can connect to locally bridged SSIDs while other clients can connect to the centrally tunneled SSIDs at the same time.

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

When Campus Gateway is added to a network which already has Adaptive Policy already enabled, it will not have the necessary configurations which enable the infrastructure Adaptive Policy. Specifically, the configs to enable the inline SGTs on the CG and set the uplink ports to tagged with SGT 2 (the standard infrastructure to infrastructure tag) will not be present by default.

If the uplink switch ports are configured for infrastructure Adaptive Policy, the CG will not have connectivity to the network as these configs are not present. 

To provide connectivity and enable Adaptive Policy, either the upstream switch can be modified to temporarily disable infrastructure Adaptive Policy on the switch ports connected to CG or the Local Status Page of the CG can be used to enable Adaptive Policy on the uplink ports.

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

For more information on how to enable Adaptive Policy for a network, please see the guide here: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Adaptive_Policy_Configuration_Guide 

1.  Enable Adaptive Policy for the network. For steps on how to enable, please see the guide here: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Adaptive_Policy_Configuration_Guide 

2.  After enabling Adaptive Policy, the CG will receive the configuration to enable infrastructure Adaptive Policy on its uplink ports.