Cloud-Managed Switching Warm Spare (VRRP) Overview
Overview
Cloud-managed switches configured for layer 3 routing can also be configured with a warm spare for gateway redundancy. This allows two identical switches to be configured as redundant gateways for a given subnet, thus increasing network reliability for users.
Supported Models and Firmware Requirements
| Models | Firmware Requirement |
| MS42, MS250, MS300 and MS400 series | MS5+ |
| Catalyst C9200/L/CX, C9300/L/X/LM, MS390, and C9500H | Cloud Management with IOS XE 17.18.2+ |
Enabling Warm Spare on MS and CS Switches
When using Warm Spare on an MS switch it cannot be part of a switch stack or enable OSPF functionality.
- Layer 3 switching must be initialized on the primary switch before configuring warm spare. To enable L3 switching, follow the instructions in the Layer 3 Switching Overview.
- To enable warm spare, navigate to Switch > Switches in the Meraki Dashboard.
- Select the switch you would like to hold the primary position in the warm spare configuration
- Scroll to the "Warm Spare" section of the page and select "Add a new warm spare".
- Select to Enable the warm spare functionality
-
Select the switch you would like to hold the spare position
All active L3 interfaces and routing functions on the "Spare" switch will be over-written with the L3 configuration of the selected primary switch.
-
Once you have selected the desired spare, press "Update".
Enabling VRRP on IOS XE Cloud Managed Catalyst Switches
- Layer 3 switching must be initialized on the primary switch before configuring VRRP. To enable L3 switching, follow the instructions in the Layer 3 Switching Overview.
- To enable warm spare, navigate to Switching > Routing & DHCP in the Meraki Dashboard.
- Select the interface you would like to configure VRRP and use the pencil button to edit the interface.
- Scroll to the "High Availability (VRRP)" section on the Edit Interfaces page and select the checkbox "Enabled".
- Configure the Virtual IP, Priority, and Group ID fields with the appropriate configuration for VRRP, then hit "Save changes".
The VRRP MAC address is automatically generated based on the VRRP group ID. The virtual MAC address follows the IEEE 802 format 00-00-5E-00-01-xx, where "xx" is the last two hexadecimal digits of the MAC address are the decimal value of the VRRP group ID. (e.g., group 121 is 0000.5E00.0179).
Priority and Selection: The switch with the highest priority becomes the primary. The switch with the next highest priority becomes the backup. If two or more switches have the same highest priority, the switch with the highest IP address is chosen as primary.
Preemption is enabled by default which means that if a switch comes online with a higher priority than the current primary, then that switch will take over as primary.
**Object tracking and authentication are not currently supported.**
Using Cloud CLI to Verify VRRP Configuration on the Switch
The Cloud CLI terminal can be useful when troubleshooting VRRP issues. We can leverage Cloud CLI to confirm if the switch is in a master or backup role, the Virtual MAC address, the Priority, and specific VRRP intervals like advertisement, etc.
- Navigate to Switch > Switches in the Meraki Dashboard.
- Select the switch you would like to monitor via Cloud CLI.
- Click on the Cloud CLI tab.
- In the CLI terminal section, click on Launch Terminal.
Warm Spare is built on VRRP to provide clients with a consistent gateway. The switch pair will share a virtual MAC address and IP address for each layer 3 interface. The virtual MAC address will always begin with 88-15-44, and the IP address will always be the configured interface IP address on the primary. Clients will always use this virtual IP and MAC address to communicate with their gateway.
When configured, the primary switch will send out VRRP advertisements on each layer 3 (L3) interface every 0.3 seconds to the destination address of 224.0.0.18. These advertisements will include the L3 switch's priority and configured addresses, and are used to ensure the spare/backup remains aware that the primary is online. When operating normally, the spare will act only as a layer 2 switch, and not perform any routing. All routing functionality will be performed by the primary.
In the event of a failure, such as the primary losing power, the spare will wait for 3 missed advertisements before it assumes the role of primary. When this occurs, the spare will assume ownership of the virtual IP/MAC addresses and begin performing routing functions. Thus there may about 1 second of downtime before the spare is able to take over for a failed primary. Clients will continue to send traffic to the same IP address, and virtual MAC address, as both of these will be shifted from the primary to the spare.
Once the primary comes back online, it will assume control again, and the spare will return to its previous state.
Important Notes
While the setup and operation of Warm Spare is generally simple and seamless, there are some pieces of information that become important when troubleshooting or planning.
Timers
On Cisco Meraki cloud managed switches, the following VRRP timers apply:
- Advertisement/hello timer - 0.3 seconds
- Hold timer - 0.9 seconds (3 missed advertisements)
- Preempt delay - Preempt will occur once the configured primary is fully initialized
Priority
The primary will use a priority of 255, and the spare/backup will use a priority of 100.
Interoperability
At this time Cisco Meraki cloud-managed switches can only be configured in pairs from the same family when using VRRP/Warm Spare. Integration with other vendors or platforms is currently not supported.
Ex. An MS250 can only be paired with another MS250.
Settings When Adding a Spare
When adding a warm spare, any previously configured layer 3 settings for the spare will be lost, and the configuration from the primary will be assumed. If this switch is later removed from the pair, it will not regain its original settings. If a primary switch is removed, the spare will not inherit the settings of the primary. In order to pass these settings, the spare and primary status can be swapped before removal and the spare will be configured with the settings for the primary switch once elected and updated.
Management IP
When configuring VRRP/warm spare, the management IP address on the primary cannot also be assigned to a layer 3 interface. This is due to the interface IP address being shifted to the spare in the event of a failover. Thus both the primary and spare must have unique management IP addresses for communication with Dashboard, that does not conflict with the layer 3 interface IP addresses.
Root Bridge Priority
When configuring a warm spare and if this warm spare will be the Root Bridge, make sure the primary switch has higher priority than the spare switch.
L3 Configuration Change on Switch Pairs
Any changes made to L3 interfaces of MS Switches in Warm Spare may cause VRRP Transitions for a brief period of time. This might result in a temporary suspension in the routing functionality of the switch for a few seconds. We recommend making any changes to L3 interfaces during a change window to minimize the impact of potential downtime.
Licensing on switching VRRP
When deploying switching VRRP each switch requires a license, unlike MX VRRP which only needs one.