Meraki MX Warm Spare permet de monter une paire haute disponibilité entre deux appliances MX afin de réduire ou d’éliminer l’indisponibilité lors d’une panne matérielle.
Derrière ce nom, il faut surtout comprendre trois choses :
- le mécanisme de bascule repose sur VRRP
- l’architecture physique conditionne largement le résultat
- le choix entre IP physiques et IP virtuelles a un impact direct sur la continuité des sessions.
Ce qu’il faut retenir
- Une paire Warm Spare MX utilise VRRP pour basculer automatiquement d’un boîtier primaire vers un spare en cas de panne ou de perte complète d’uplinks sur le primaire.
- Le spare doit être exactement du même modèle que le primaire. Meraki ne supporte ni deux modèles différents, ni certaines variantes territoriales différentes d’un même modèle.
- En mode routeur, la qualité de la connectivité LAN entre les deux MX est critique. Si les heartbeats VRRP ne circulent pas correctement, vous pouvez provoquer un état dual active.
- Le choix “Use MX uplink IPs” simplifie l’adressage public, mais rend le failover plus disruptif. Le choix “Use virtual uplink IPs” demande une IP publique supplémentaire par uplink, mais limite la rupture des sessions.
- La topologie recommandée par Meraki est une architecture pleinement redondante via un ou plusieurs switches en aval, avec STP actif et un maximum d’un saut supplémentaire entre les deux MX (source : Cisco Meraki Documentation).
Comment fonctionne le Warm Spare sur un MX
Meraki distingue les rôles statiques et les rôles dynamiques.
Le primary est le MX principal défini dans la configuration.
Le spare est l’équipement secondaire.
En revanche, les états active et passive changent selon la situation réelle sur le réseau. Tant que tout va bien, le primaire est actif et le spare reste passif. Si le spare ne reçoit plus les heartbeats du primaire, il devient actif.
Deux points de gouvernance importants:
- D’abord, une seule licence est nécessaire pour la paire HA : le spare ne demande pas de licence séparée.
- Ensuite, le bouton swap du dashboard ne doit pas être utilisé comme test de bascule.Pour tester correctement le failover, Meraki demande de déconnecter complètement l’uplink du primaire. C’est un détail qui évite de fausser vos tests et de tirer de mauvaises conclusions sur le comportement réel de l’infrastructure.
Si DDNS est activée et que le secondaire doit rester actif pendant une période prolongée, Meraki recommande en plus de permuter les rôles pour faire du secondaire le primary.
L’objectif est d’éviter des problèmes de mise à jour DDNS pendant l’absence du primaire.
Ce que la paire HA surveille réellement
VRRP heartbeats
Le mécanisme de détection principal repose sur des paquets VRRP envoyés par le primaire vers le spare sur tous les VLAN configurés.
Si le secondaire cesse de les recevoir pendant 3 secondes, il considère le primaire indisponible et passe actif. C’est court, mais cela suppose que les deux boîtiers puissent vraiment se voir au niveau attendu.
En mode routeur, les heartbeats ne transitent pas sur le WAN : ils passent côté LAN.
Connection monitoring
Le basculement n’est pas déclenché uniquement par une panne matérielle. Le moteur de connection monitoring surveille aussi l’état des uplinks WAN.
Si tous les uplinks du primaire sont considérés en échec, le primaire cesse d’envoyer les heartbeats VRRP, ce qui provoque le failover.
À l’inverse, dès qu’au moins un uplink redevient opérationnel, le primaire reprend l’émission des heartbeats et le secondaire rend le rôle actif.
Synchronisation DHCP
Meraki synchronise régulièrement la table de baux DHCP entre les deux MX sur le port UDP 3483. C’est un point très concret : sans cette synchronisation, un failover pourrait conduire à des attributions d’adresses incohérentes après bascule.
Deux modes de déploiement à ne pas confondre
| Mode | Usage principal | Point clé |
|---|---|---|
| Passthrough / VPN Concentrator | Tête de pont Auto VPN | Topologie one-armed uniquement, connexion via les ports Internet |
| Routed mode | Passerelle de sécurité et sortie Internet | Redondance des uplinks, services d’appliance et VIP WAN possibles |
En VPN concentrator warm spare, les deux MX partagent une VIP pour le trafic non management, mais chaque boîtier conserve sa propre IP pour communiquer avec le cloud Meraki.
On insiste sur le caractère one-armed de cette architecture : les deux boîtiers se connectent au réseau uniquement par leurs ports Internet et ne doivent pas être reliés directement par leurs ports LAN. Le temps cumulé de détection de panne, de bascule et de reprise du traitement des paquets VPN est généralement inférieur à 30 secondes.
En routed warm spare, l’objectif est plus large : assurer la redondance de la connectivité Internet et des services de l’appliance.
Les VIP WAN sont alors centrales si vous voulez conserver la même IP visible pendant le failover et limiter les perturbations pour les flux en cours.
Configurer la paire dans le dashboard sans se piéger
La configuration se fait depuis Security & SD-WAN > Monitor > Appliance status, puis Configure warm spare. Il faut activer la fonctionnalité, saisir le numéro de série du secondaire, puis choisir la stratégie d’adressage WAN.
C’est là que plusieurs effets de bord méritent d’être anticipés :
- l’ajout ou le remplacement d’un spare peut provoquer une courte perte de connectivité sur le primaire pendant l’initialisation HA ;
- l’activation du Warm Spare fait perdre la possibilité d’utiliser les VLAN objects ; les règles L3 existantes qui s’appuient dessus sont supprimées ;
- une paire MX en HA ne peut pas dépasser 255 VLANs ;
- Meraki recommande de configurer le secondaire dans le dashboard avant de le connecter physiquement au réseau.
En pratique, la bonne séquence est simple : préconfigurer l’IP WAN statique du spare si nécessaire, le laisser éteint, raccorder le câblage selon la topologie retenue, puis l’allumer seulement après la configuration logique.
Faut-il choisir les IP d’uplink physiques ou des VIP ?
C’est un arbitrage de design, pas un simple détail cosmétique.
Avec Use MX uplink IPs, chaque MX sort vers Internet avec sa propre IP.
Avantage : vous n’avez pas besoin d’IP publique supplémentaire.
Inconvénient : lors d’un failover, l’IP source des flux change, ce qui oblige souvent les clients à rétablir les sessions applicatives en cours.
Avec Use virtual uplink IPs, les deux MX partagent une VIP par uplink. Il faut alors une IP supplémentaire par uplink, dans le même sous-réseau que les IP WAN des deux boîtiers, et différente de chacune d’elles. En contrepartie, le failover est bien plus transparent puisque l’IP vue vers l’extérieur ne change pas.
Pour toutes les fonctions comme le NAT ou le port forwarding, il est explicitement recommandé de pointer les services vers la VIP, et non vers les IP physiques des appliances.
Deux alertes supplémentaires sont utiles:
- Modifier une liaison WAN pour lui affecter une VIP peut provoquer jusqu’à 2 minutes de coupure sur les deux uplinks Internet ; faites-le en fenêtre de maintenance
- Et si vous utilisez DDNS avec des VIP, l’IP de l’uplink primaire et la VIP doivent résoudre vers la même IP publique upstream.
Bonnes pratiques d’architecture et d’exploitation
Le point le plus important en mode route est la fiabilité du chemin LAN entre les deux MX. Meraki recommande de faire transiter les heartbeats via un switch en aval, ou idéalement via plusieurs switches, sans liaison directe LAN à LAN entre les appliances.
Il ne doit pas y avoir plus d’un saut supplémentaire entre elles, et elles doivent communiquer sur tous les VLANs concernés. Comme cette topologie crée une boucle, STP doit être activé sur l’infrastructure de switching.
Côté topologies, Meraki met en avant deux schémas solides :
- une architecture complètement redondante avec deux switches
- une architecture via switch stack.
Si vous avez plus de deux uplinks physiques WAN, des liens supplémentaires peuvent être câblés sur le MX secondaire pour servir de failover tertiaire.
Sur la partie exploitation, trois sujets reviennent souvent :
- Dual active : si le primaire reste en ligne mais que le spare ne voit plus les heartbeats, les deux MX peuvent se déclarer actifs. C’est le symptôme classique d’un problème de LAN, de VLAN, de câblage ou de domaine de broadcast.
- Virtual MAC : avec des VIP WAN, les interfaces utilisent des MAC virtuelles spécifiques. Le bouton swap modifie ces MAC partagées, ce qui peut perturber la production ; Meraki déconseille son usage en heures ouvrées.
- Cellular failover : le support HA cellulaire est encadré. Il est limité aux MX67C et MX68CW avec modem cellulaire intégré, et demande des versions de firmware minimales explicites dans la documentation. Les autres modèles appuyés par dongle USB ne sont pas officiellement supportés dans ce scénario.
Enfin, Meraki précise que les upgrades firmware d’une paire HA suivent une séquence automatisée pour viser le zero downtime : bascule vers le secondaire, reboot du primaire, retour du primaire, puis upgrade différé du secondaire environ 15 minutes plus tard.
Plan d’action recommandé
- Valider que les deux appliances sont strictement compatibles : même modèle MX et même désignation territoriale.
- Choisir dès maintenant si l’objectif est la simplicité d’adressage public ou la continuité maximale des sessions, car cela détermine le choix IP physiques versus VIP.
- Dessiner la topologie LAN/WAN avant configuration : switches aval, STP, domaines de broadcast, positionnement des uplinks et des éventuelles VIP.
- Configurer le spare dans le dashboard avant son raccordement physique, puis vérifier la remontée cloud de chaque MX avec sa propre IP d’uplink.
- Tester le failover en condition réelle en coupant l’uplink du primaire, pas en utilisant le bouton swap.
- Prévoir un plan de dépannage dual active : vérification des VLANs, captures LAN, contrôle du câblage et des domaines de broadcast sur chaque paire d’uplinks.
Sources et références
FAQ
Faut-il une deuxième licence pour le MX spare ?
Non.. Une seule licence est requise pour une paire HA Warm Spare.
Peut-on faire une paire HA avec deux modèles MX différents ?
Non. Le spare doit être du même modèle que le primaire, et Meraki ne supporte pas non plus certaines variantes territoriales différentes d’un même modèle.
Quand faut-il utiliser des virtual uplink IPs ?
Quand vous voulez limiter la rupture des sessions lors du failover. En contrepartie, il faut une IP supplémentaire par uplink et respecter le même sous-réseau pour les trois adresses concernées.
Quel est le principal risque de design en Warm Spare route ?
Le scénario dual active, généralement causé par une mauvaise circulation des heartbeats VRRP entre les deux MX sur le LAN, à cause du câblage, des VLANs ou du domaine de broadcast.
Aller plus loin
Besoin d’aide ?
Besoin d’aide pour votre informatique ? Contactez-nous.
