Skip to main content

 

Cisco Meraki Documentation

Secondary MX Concentrator for MR Teleworker VPN

Overview

SSIDs configured in tunneled mode (VPN tunnel data to concentrator) allow you to specify both a primary and a secondary MX for failover.  If you enable a secondary concentrator, there are a few additional parameters to configure for tunnel monitoring to ensure tunnel status can be detected and have failover occur.

The additional options to configure include:

  • Tunnel Health Check IP
  • Tunnel Heartbeat Interval (seconds)
  • Tunnel Idle Timeout (seconds)

Screenshot from dashboard, Wireless -> Access control page, showing the options under Client IP and DHCP.Tunnel Monitoring

When there are clients connected to the AP, it will passively monitor all traffic and as long as there is traffic still coming through the tunnel from the remote end, the AP will mark the tunnel as up without actively sending DHCP monitoring probes.  If there are clients connected but no traffic seen through the tunnel for a period of time, the AP will switch to active monitoring by sending the DHCP request probes.  Details about this active monitoring configuration can be seen below.

Screenshot from the Dashboard showing all available fields, including 'Concentrator', 'Secondary concentrator', 'Tunnel health check IP', 'Tunnel Heartbeat interval (seconds)', 'Tunnel idle timeout (seconds)' and 'Disassociate clients on tuennel failover'.

Tunnel Health Check IP

The auto-VPN tunnels from an MR to an MX are L2 tunnels instead of L3 like traditional MX to MX tunnels.  Clients connecting to a tunneled SSID obtain their IP from DHCP servers located across the VPN tunnel on the MX side.  In order to monitor the tunnel and ensure we can failover accordingly, we need to specify an IP that the MR can probe on the concentrator side.  The MR uses DHCP requests as its probing mechanism.  It will send DHCP requests to the specified IP and expects any DHCP response (ACK/NACK) in order to determine the tunnel is still alive.

As such, it is recommended to set a DHCP reservation on your DHCP server for the IP entered here to ensure other clients do not use the IP and an ACK/NACK is always sent back.  Alternatively you could specify the MX LAN IP or DHCP server IP here as well which would also trigger a NACK if the MR sends a DHCP request for it.

Note: If no Tunnel Health Check IP is specified, the MR will send a DHCP Request probe to 0.0.0.0. Please ensure a DHCP server will be able to respond with an ACK or NAK packet to keep the tunnel alive.

Tunnel Heartbeat Interval

The heartbeat interval is how often the MR will retry the DHCP probe in case it does not get a response for a given probe.  As an example, if this is set to 10 seconds, if the MR does not get a DHCP response for a give probe, it will retry that probe every 10 seconds.  It will stop trying and fail over to the secondary tunnel once the idle timeout value below has been reached.

Tunnel Idle Timeout

The tunnel idle timeout specifies the max amount of time the MR will attempt to retry probes before marking the tunnel as down and failing over to the secondary tunnel.  As an example, if this is set to 30 seconds and the tunnel heartbeat interval is set to 10 seconds, if the MR does not receive a response to a given probe, it will keep retrying those probes every 10 seconds until the 30 second timeout is reached.  If the MR receives a response to any probe during that 30 second period, the timer will be reset to 0 and will only start incrementing towards 30 again if no response is seen.  If 30s is reached, then the MR will mark the tunnel as down and fail over to the secondary tunnel.

Tunnel Failback

If an MR fails over to the secondary tunnel, it will continue to actively monitor the primary tunnel.  Once the connection to the primary MX reestablishes, it will redirect client traffic back to the primary concentrator.

 

  • Was this article helpful?