HA pour routeurs cœur : configurer en toute sécurité VRRP, HSRP et GLBP

Quand la passerelle par défaut devient instable, tout le sous‑réseau le ressent immédiatement : les sessions se rompent, les entrées ARP basculent et le dépannage devient une tâche permanente. Pour HA pour les routeurs cœur, VRRP (Virtual Router Redundancy Protocol), HSRP (Hot Standby Router Protocol) et GLBP (Gateway Load Balancing Protocol) sont les outils habituels. Cet article explique de manière pragmatique comment concevoir, configurer et exploiter ces protocoles afin d’éviter les scénarios de split‑brain — c’est‑à‑dire les situations où plusieurs routeurs pensent simultanément être actifs.

HA pour les routeurs cœur : rôle de VRRP, HSRP et GLBP

VRRP, HSRP et GLBP fournissent une passerelle par défaut virtuelle (VIP). Un routeur répond pour cette adresse et relaie le trafic, un autre est en attente. Remarque importante : FHRP (First Hop Redundancy Protocol) gère uniquement le premier saut ; la redondance de routage dans le backbone, des chemins L2 stables et des politiques propres du plan de contrôle sont des prérequis nécessaires.

Quand quel protocole ?

• VRRP est standardisé (RFC) et souvent le premier choix dans les environnements multi‑fournisseurs.
• HSRP est propriétaire Cisco, offrant une intégration étroite avec le tracking/monitoring Cisco.
• GLBP répartit la charge de la passerelle via plusieurs adresses MAC virtuelles, mais augmente la complexité (comportement ARP, intégration sécurité).

En quoi consiste réellement le split‑brain et comment il se manifeste

Le split‑brain dans les FHRP n’est généralement pas une anomalie pure du protocole, mais le résultat d’une signalisation erronée, de partitions L2 ou de minutages inappropriés. Symptômes en exploitation :

• ARP/MAC‑flapping : les adresses MAC virtuelles basculent entre les ports.
• Routage asymétrique : les paquets sortent mais reviennent par un autre chemin.
• Perte de paquets intermittente ou temps d’établissement de connexion prolongés après un failover.

Causes typiques

• Les paquets de contrôle sont bloqués par des ACL, le storm‑control ou des limites de multicast.
• Partitions L2 ou configurations Trunk/VLAN inconsistantes.
• Preemption sans délai pendant la convergence du routage.
• Un tracking qui ne vérifie que le Link‑Up/Down sans détecter le véritable forwarding (blackholing).

Exigences topologiques : base pour un basculement stable

Avant d’affiner timers et priorités, sécurisez les fondations :

• Les participants FHRP doivent se trouver dans le même VLAN/sous‑réseau (SVI/interface L3).
• Trunks/Port‑Channels cohérents et listes d’autorisation VLAN entre le core et l’access.
• Plan STP root : définir consciemment les Root Bridges et les ports Edge (PortFast/Edge pour les terminaux).
• Chemin de management/keepalive séparé comme canal secondaire de liveness, si possible.

Principes de configuration : priorité, preemption, timers, tracking

La stabilité naît de règles claires. Trois éléments clés :

1. Priorités univoques

Évitez l’égalité de priorité. Définissez pour chaque VLAN un master privilégié et assignez au backup une priorité sensiblement inférieure. Cela réduit les situations de course.

2. Preemption avec délai

La preemption (le routeur le plus apte reprend la main après son retour) est utile, mais uniquement avec un délai. Sinon des flaps peuvent survenir au redémarrage tant que le routage/les Port‑Channels ne sont pas convergés. Un preempt‑delay donne au système le temps de stabiliser les adjacences IGP, BGP et LACP.

3. Tracking de la réelle atteignabilité

Le suivi d’interface est la base ; étendez-le avec le suivi de route (Default‑Route/IGP‑Neighbor) et IP SLA (mesure active) vers un Next‑Hop stable. Important : les cibles de suivi ne doivent pas dépendre elles‑mêmes du FHRP examiné – sinon une rétroaction et un déclencheur possible de split‑brain peuvent se produire.

Exemples de configuration pratiques (à titre indicatif)

Les commandes dépendent du fournisseur ; voici des exemples structurés en syntaxe Cisco, montrant comment combiner Preempt Delay, Priority et Tracking.

VRRP – Preempt‑Delay et Tracking (exemple)

interface Vlan10
 ip address 10.10.10.2 255.255.255.0
 vrrp 10 ip 10.10.10.1
 vrrp 10 priority 120
 vrrp 10 preempt delay minimum 60
 vrrp 10 track interface Port-Channel1 decrement 40
 vrrp 10 track route 0.0.0.0/0 decrement 30

HSRP – Active/Standby avec suivi IP SLA (exemple)

ip sla 10
 icmp-echo 8.8.8.8 source-ip 10.10.10.2
 frequency 10
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability

interface Vlan10
 ip address 10.10.10.3 255.255.255.0
 standby 10 ip 10.10.10.1
 standby 10 priority 110
 standby 10 preempt delay minimum 60
 standby 10 track 10 decrement 30

GLBP – uniquement si la répartition de charge entre passerelles est requise

interface Vlan10
 ip address 10.10.10.4 255.255.255.0
 glbp 10 ip 10.10.10.1
 glbp 10 priority 120
 glbp 10 preempt delay minimum 60
 glbp 10 load-balancing round-robin
 glbp 10 track Port-Channel1 decrement 30

IP SLA, BFD et accélération du basculement

Les timers FHRP seuls ne sont souvent pas le levier adéquat pour des basculements rapides et sûrs. Deux mécanismes complémentaires sont très efficaces en pratique :

IP SLA (vérification active de l’atteignabilité)

IP SLA effectue des mesures actives (ICMP/TCP/UDP) vers un hôte cible stable. Utilisez IP SLA comme objet de suivi pour FHRP : la décision ne repose pas sur un Link‑Down, mais sur la réelle atteignabilité en amont. Faites attention au choix de la cible : utilisez un Next‑Hop dans le réseau du carrier ou un cloud‑peer qui n’emprunte pas la passerelle testée.

BFD (Bidirectional Forwarding Detection)

BFD est un mécanisme de liveness très rapide, fonctionnant entre pairs de routage ou sur des tunnels. BFD détecte les défaillances de forwarding en millisecondes et peut résoudre plus rapidement les adjacences IGP ; par conséquent, le suivi FHRP devrait inclure l’état Route/IGP plutôt que le seul statut d’interface.

! Beispiel für einfache BFD Template und Interface‑Aktivierung
bfd-template single-hop BFD_FAST
 interval 50 min_rx 50 multiplier 3
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 bfd interval 50 min_rx 50 multiplier 3

FHRP sur VPNs, MPLS ou sites distants

L’utilisation de FHRP sur des WAN/ réseaux fournisseurs est une source fréquente d’erreurs. FHRP est conçu pour la redondance de segments LAN ; sur des réseaux L3, des situations de split‑brain surviennent facilement, car les paquets du plan de contrôle et les chemins de données peuvent diverger.

Bonnes pratiques pour les environnements multi‑site

• Appliquer FHRP uniquement localement ; pour la redondance de site, utiliser du routage (BGP/OSPF) et Anycast.
• Si FHRP est déployé sur un L2 partagé (p. ex. L2‑MPLS), assurez‑vous que les paquets de contrôle empruntent le même chemin que le trafic client.
• Pour les tunnels IPsec/GRE : évitez que les cibles IP SLA ou les objectifs de suivi ne transitent elles‑mêmes par la passerelle suivie.

Pratique de diagnostic : ordre des vérifications en cas de panne

Une chaîne de vérification définie évite les pertes de temps. Objectif : clarifier d’abord si FHRP est la cause ou le symptôme. En complément des vérifications de base de la version standard, voici des contrôles étendus et des exemples de captures de paquets.

Étape 1 – Vérifier le statut FHRP

show vrrp brief
show standby brief
show glbp brief
show logging | include VRRP|HSRP|GLBP|STATE|TRACK

Étape 2 – Vue MAC/ARP

show mac address-table vlan 10 | include 0000.5e00
show mac address-table move update
show ip arp | include 10.10.10.1

Étape 3 – Vérifier le trafic de contrôle et les ACL

show interface Vlan10 counters
show ip igmp snooping groups vlan 10
show access-lists | include 112|HSRP|GLBP

Assurez-vous que les paquets de contrôle FHRP ne sont pas rejetés par des ACL, le QoS ou le Storm‑Control. Pour VRRP, le protocole IP 112 est utilisé ; tcpdump peut aider à visualiser les paquets de contrôle.

# Beispiel: VRRP‑Pakete mit tcpdump auffangen
tcpdump -nni eth0 'ip[9] == 112' -vv

Étape 4 – Vérifier le routage/acheminement

show ip route 0.0.0.0/0
show ip ospf neighbor
show bgp summary
ping <upstream-next-hop> source <SVI-IP>

Un Master peut indiquer un état Up, mais subir un blackholing en amont — cela montre que le tracking est insuffisant.

Étape 5 – Perspective client

Vérifiez sur les clients l’entrée ARP, le traceroute (premier saut) et le maintien des sessions. Les firewalls et uRPF peuvent interrompre les connexions en cas de routage asymétrique.

Scénarios de test pour modifications contrôlées

Effectuez des tests de basculement par étapes contrôlées et documentez le comportement et les métriques. Cas de test recommandés :

1. Simuler une panne d’uplink sur le Master (Link‑Down de l’uplink).
2. Shutdown d’interface sur le Master (vérifie la réaction du tracking).
3. Réinsertion via préemption : redémarrer le Master et observer si le Preempt‑Delay empêche le flapping.
4. IP SLA Target unreachable : vérifier si l’objet Track déclenche le FHRP.
5. Test de stress MAC‑flap : basculements répétés sur les ports d’accès et observation du taux de flap.
6. Failover VPN : basculement opérateur avec BGP‑Failover et vérification de chemins asymétriques.

Runbook opérationnel – liste de contrôle rapide

• Le VLAN FHRP est‑il cohérent sur tous les switches impliqués ?
• Quel est le Master planifié par VLAN (documentation des priorités) ?
• Les IP SLA Targets sont‑ils indépendants et joignables ?
• Les paquets du plan de contrôle (p. ex. VRRP) sont‑ils autorisés dans les ACL ?
• Existe‑t‑il des alertes pour les MAC‑flaps, les changements d’état FHRP et les pertes IP SLA ?

Aspects de sécurité spécifiques

Des outils de sécurité tels que Dynamic ARP Inspection (DAI), IP Source Guard ou RA Guard peuvent perturber les basculements si les ports de confiance ne sont pas correctement configurés. Assurez‑vous que les switches d’accès autorisent les GARP/NA/Gratuitous‑ARP des passerelles et que les ACL ne filtrent pas le trafic de contrôle.

Conclusion et recommandations

La HA pour les routeurs cœur est moins une simple configuration qu’un design système : chemins L2 clairs, règles Master priorisées, préemption avec délai, tracking basé sur une réelle atteignabilité et monitoring pertinent préviennent la plupart des cas de split‑brain. Testez des scénarios de basculement contrôlés, documentez les dépendances (VLAN, trunk, Tracking‑Targets) et prévoyez des options de retour simples. Dans des scénarios multi‑site ou VPN, privilégiez des instances FHRP locales et misez sur le routage/Anycast pour la redondance de site. Ainsi, la redondance de gateway devient robuste et prévisible en exploitation.

Vérifications complémentaires et remarques

Si vous rencontrez des problèmes persistants, une isolation séquentielle est recommandée : valider d’abord complètement le L2, puis le contrôle FHRP, ensuite le routage et enfin les symptômes au niveau applicatif. Une documentation structurée de tous les tests de basculement et des baselines acceptées réduit les interventions en « War‑Room » et accélère la résolution des incidents.

Exploitation, supervision et mesures d’urgence pour la HA des routeurs cœur

Outre la configuration, l’exploitation quotidienne est déterminante : supervision, sauvegarde des données, contrôle des changements et mesures d’urgence clairement définies réduisent significativement les temps d’arrêt. Cette section fournit des indications pratiques sur les métriques à collecter, la manière d’engager des contre‑mesures rapides et l’apport de l’automatisation pour renforcer la fiabilité.

Indicateurs réellement pertinents

• FHRP‑State‑Changes par minute : des augmentations soudaines indiquent du flapping ou des problèmes de préemption.
• MAC‑Table‑Flaps et nombre de ports différents par MAC virtuelle : indicateur précoce de partitions L2.
• Pertes d’accessibilité IP SLA et resets de sessions BFD : indiquent de réelles défaillances d’acheminement.
• Control‑Plane‑Drops (ACL/QoS/CP‑Policing) : lorsque le routeur est fortement sollicité CPU, les paquets de signalisation se perdent.

Règles de supervision et d’alerte (recommandées)

• Alarme si FHRP‑State‑Changes > 3 en 5 minutes.
• Avertissement si taux de MAC‑Flap > X par minute (valeur dépendant de l’environnement).
• Critique si IP SLA‑Loss > 5% sur 1 minute ou BFD‑Down.

Mesures d’urgence rapides (extrait du runbook)

1. Isoler : associer les trunks VLAN concernés et, si nécessaire, placer temporairement les ports en « errdisable » pour arrêter le flapping.
2. Stabiliser : désactiver temporairement la préemption ou augmenter le Preempt‑Delay jusqu’à ce que les adjacences amont soient établies.
3. ARP‑Refresh : autoriser le gratuitous ARP sur les commutateurs d’edge et vider le cache ARP des clients si besoin.
4. Fallback : définir manuellement la priorité du Master (avec réinitialisation documentée) si le basculement automatique n’est pas fiable.

Exemples de commandes rapides pour l’opérateur :

# Konfigurationssicherung vom Router (via SCP/SSH)
scp admin@10.0.0.1:/running-config ./backup/10.0.0.1.cfg

# Syslog filtern nach FHRP‑Events
ssh syslogserver 'grep -E "VRRP|HSRP|GLBP|STATE|TRACK" /var/log/syslog | tail -n 200'

# Client‑ARP auf Linux leeren
sudo ip neigh flush all

Automatisation et gestion des changements

Conservez les configurations FHRP dans un dépôt Git, vérifiez les changements via CI (linting, validation syntaxique des templates) et effectuez des tests planifiés dans un émulateur de laboratoire (GNS3、EVE‑NG). Des sauvegardes versionnées permettent un rollback rapide après des changements erronés.

Mesures à long terme

Effectuez régulièrement des tests de chaos (coupures de lien contrôlées, inaccessibilité des cibles IP‑SLA) et documentez les métriques ainsi que les baselines acceptables. Vous détecterez ainsi les dégradations progressives avant qu’elles n’affectent les utilisateurs. La documentation, les sauvegardes automatisées et une procédure d’urgence claire rendent la HA des routeurs cœur réellement robuste en exploitation.

Pour ce sujet, les rubriques Vrrp Konfigurieren et Hsrp Konfigurieren sont également importantes. L’article replace ces aspects de façon compréhensible et montre ce qui compte au quotidien.