Quando il Default Gateway diventa instabile, tutto il subnet lo avverte immediatamente: le sessioni si interrompono, le voci ARP‑saltano e il troubleshooting diventa un compito permanente. Per HA per i router core VRRP (Virtual Router Redundancy Protocol), HSRP (Hot Standby Router Protocol) e GLBP (Gateway Load Balancing Protocol) sono gli strumenti usuali. Questo articolo spiega in modo pratico come progettare, configurare e gestire questi protocolli, in modo da evitare scenari di split‑brain – cioè situazioni in cui più router credono contemporaneamente di essere attivi.
HA per i router core: ruolo di VRRP, HSRP e GLBP
VRRP, HSRP e GLBP forniscono un Default Gateway virtuale (VIP). Un router risponde per questo indirizzo e inoltra il traffico, un altro resta in standby. Nota importante: FHRP (First Hop Redundancy Protocol) garantisce solo il primo hop; la ridondanza di routing nel backbone, percorsi L2 stabili e policy di control‑plane pulite sono prerequisiti necessari.
Quando quale protocollo?
- VRRP è standardizzato (RFC) ed è spesso la prima scelta in ambienti multi‑vendor.
- HSRP è proprietario Cisco e offre integrazione stretta con i meccanismi di tracking/monitoring Cisco.
- GLBP distribuisce il carico del gateway tramite più MAC virtuali, aumentando però la complessità (comportamento ARP, integrazione con la security).
Di cosa si tratta veramente nello split‑brain e come si manifesta
Lo split‑brain in FHRP non è di norma una pura anomalia di protocollo, ma il risultato di segnalazione deviata, partizioni L2 o timing inadeguati. Sintomi in esercizio:
- ARP/MAC‑flapping: MAC virtuali che saltano tra le porte.
- Routing asimmetrico: i pacchetti escono ma ritornano tramite un percorso diverso.
- Perdita intermittente di pacchetti o tempi lunghi di stabilimento delle connessioni dopo un failover.
Cause tipiche
- I pacchetti di controllo vengono bloccati da ACL, Storm‑Control o limiti multicast.
- Partizioni L2 o configurazioni trunk/VLAN inconsistenti.
- Preemption senza ritardo durante la convergenza del routing.
- Tracking che verifica solo Link‑Up/Down ma non riconosce il reale forwarding (blackholing).
Prerequisiti topologici: base per un failover stabile
Prima di regolare finemente timer e priorità, consolidate le fondamenta:
- I partecipanti FHRP devono trovarsi nello stesso VLAN/subnet (SVI/L3‑Interface).
- Trunk/Port‑Channel coerenti e VLAN‑Allowed‑Lists tra Core e Access.
- Piano STP‑Root: configurare consapevolmente Root Bridge e porte Edge (PortFast/Edge per dispositivi endpoint).
- Percorso separato di management/keepalive come canale di liveness secondario, se possibile.
Principi di configurazione: priorità, preemption, timer, tracking
La stabilità nasce da regole chiare. Tre elementi chiave:
1. Priorità univoche
Evitare la parità. Per VLAN definire un master preferito e assegnare al backup una priorità nettamente inferiore. Questo riduce le condizioni di competizione.
2. Preemption con ritardo
La preemption (il router migliore riprende il ruolo al ritorno) è utile, ma solo con delay. Altrimenti si rischiano flap al riavvio, finché routing/Port‑Channels non sono convergenti. Un preempt‑delay concede al sistema il tempo per stabilizzare adiacenze IGP, BGP e LACP.
3. Tracking della raggiungibilità reale
Interface‑Tracking è la base; estendete con Route‑Tracking (Default‑Route/IGP‑Neighbor) e IP SLA (misurazione attiva) verso un Next‑Hop stabile. Importante: gli obiettivi di tracking non devono dipendere essi stessi dall’FHRP sottoposto a verifica – altrimenti si crea una retroazione e un potenziale trigger di Split‑Brain.
Esempi di configurazione pratici (orientativi)
I comandi dipendono dal vendor; qui esempi strutturati in sintassi Cisco che mostrano come combinare Preempt Delay, Priority e Tracking.
VRRP – Preempt‑Delay e Tracking (esempio)
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 30HSRP – Active/Standby con IP SLA‑Tracking (esempio)
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 30GLBP – solo se necessario per il bilanciamento del carico dei gateway
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 30IP SLA, BFD e accelerazione del failover
I timer FHRP da soli spesso non sono la leva corretta per un failover rapido e sicuro. Due meccanismi complementari risultano molto efficaci in pratica:
IP SLA (verifica attiva di raggiungibilità)
IP SLA esegue misurazioni attive (ICMP/TCP/UDP) verso un host target stabile. Usate IP SLA come oggetto di track per l’FHRP: in questo modo la decisione non dipende da un semplice Link‑Down, ma dalla reale raggiungibilità upstream. Fate attenzione alla scelta del target: utilizzate un Next‑Hop nella rete del carrier o un cloud‑peer che non passi attraverso il gateway che state testando.
BFD (Bidirectional Forwarding Detection)
BFD è un meccanismo di liveness molto veloce, che funziona tra peer di routing o su tunnel. BFD rileva guasti di forwarding in millisecondi e può risolvere le adiacenze IGP più rapidamente; di conseguenza l’FHRP dovrebbe includere nel tracking lo stato Route/IGP, e non solo lo stato dell’interfaccia.
! 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 3FHRP su VPN, MPLS o sedi remote
L’uso di FHRP su reti WAN/provider è una causa frequente di problemi. FHRP è pensato per la ridondanza a livello di segmento LAN; su reti L3 è facile imbattersi in situazioni di Split‑Brain, perché i pacchetti di control‑plane e i percorsi dati possono divergere.
Linee guida per ambienti multi‑sito
- Applicare FHRP solo a livello locale; per la ridondanza tra sedi utilizzare routing (BGP/OSPF) e Anycast.
- Se FHRP è implementato su un L2 condiviso (p.es. L2‑MPLS), assicurarsi che i pacchetti di control‑plane seguano lo stesso percorso del traffico client.
- Per IPsec/GRE‑tunnel: evitare che gli IP‑SLA targets o gli obiettivi di tracking transitino attraverso il gateway soggetto al monitoraggio.
Pratica di diagnostica: ordine delle verifiche in caso di guasti
Una procedura di verifica consolidata evita perdite di tempo. Obiettivo: accertare innanzitutto se FHRP è causa o sintomo. A complemento dei controlli di base della versione standard, qui sono riportati controlli estesi ed esempi di packet‑capture.
Passo 1 – Verificare lo stato FHRP
show vrrp brief
show standby brief
show glbp brief
show logging | include VRRP|HSRP|GLBP|STATE|TRACKPasso 2 – Vista MAC/ARP
show mac address-table vlan 10 | include 0000.5e00
show mac address-table move update
show ip arp | include 10.10.10.1Passo 3 – Verificare il traffico di controllo e le ACL
show interface Vlan10 counters
show ip igmp snooping groups vlan 10
show access-lists | include 112|HSRP|GLBPAssicurarsi che i pacchetti di controllo FHRP non vengano scartati da ACL, QoS o Storm‑Control. Per VRRP viene utilizzato il protocollo IP 112; tcpdump può aiutare a visualizzare i pacchetti di controllo.
# Beispiel: VRRP‑Pakete mit tcpdump auffangen
tcpdump -nni eth0 'ip[9] == 112' -vvPasso 4 – Verificare instradamento/forwarding
show ip route 0.0.0.0/0
show ip ospf neighbor
show bgp summary
ping <upstream-next-hop> source <SVI-IP>Un master può riportare lo stato Up ma avere blackholing a monte: questo indica che il tracking è insufficiente.
Passo 5 – Prospettiva del client
Sul client verificare la voce ARP, il traceroute (primo hop) e il mantenimento delle sessioni. Firewall e uRPF possono interrompere le connessioni in presenza di routing asimmetrico.
Casi di test per cambi controllati
Eseguire test di failover in passi controllati e documentare comportamento e metriche. Casi di test consigliati:
- Simulazione di caduta uplink sul master (link‑down sull’uplink).
- Interface shutdown sul master (verifica la risposta del tracking).
- Preemption‑reinserimento: riavviare il master e osservare se il preempt‑delay previene flapping.
- IP SLA target non raggiungibile: verificare se l’oggetto di tracking innesca l’FHRP.
- Stress test MAC‑flap: ripetuti up/down sulle porte di accesso e osservazione del tasso di flap.
- VPN failover: utilizzo del carrier con BGP failover e verifica di percorsi asimmetrici.
Operational Runbook – Lista di controllo rapida
- Il VLAN FHRP è coerente su tutti gli switch coinvolti?
- Chi è il master previsto per ciascuna VLAN (documentazione delle priorità)?
- Gli IP SLA target sono indipendenti e raggiungibili?
- I pacchetti di control‑plane (es. VRRP) sono consentiti nelle ACL?
- Sono presenti alert per MAC‑flap, cambi di stato FHRP e perdite di IP SLA?
Aspetti di sicurezza specifici
Strumenti di sicurezza come Dynamic ARP Inspection (DAI), IP Source Guard o RA Guard possono interferire con il failover se i trust‑port non sono configurati correttamente. Verificare che gli switch di accesso consentano i GARP/NA/Gratuitous‑ARP dei gateway e che le ACL non filtrino il traffico di controllo.
Conclusioni e raccomandazioni
L’HA per i router core è meno una questione di singola configurazione e più di progettazione di sistema: percorsi L2 chiari, regole di master prioritarie, preemption con ritardo, tracking basato su raggiungibilità reale e monitoring significativo prevengono la maggior parte dei casi di split‑brain. Testare scenari di failover controllati, documentare le dipendenze (VLAN, trunk, tracking‑targets) e predisporre opzioni di fallback semplici. In scenari multi‑site o VPN, preferire istanze FHRP locali e basarsi su routing/anycast per la ridondanza di sito. In questo modo la ridondanza del gateway risulta robusta e prevedibile in esercizio.
Ulteriori verifiche e osservazioni
Se incontrate problemi persistenti, è consigliabile un isolamento sequenziale: prima validare completamente L2, poi FHRP‑Control, successivamente il routing e infine i sintomi a livello applicazione. Una documentazione strutturata di tutti i test di failover e delle baseline accettate riduce gli interventi in „war‑room“ e accelera la risoluzione degli incidenti.
Gestione, monitoring e misure di emergenza per HA dei Core‑Router
Oltre alla configurazione, l’operatività quotidiana è determinante: monitoraggio, backup dei dati, controllo delle modifiche e misure di emergenza chiaramente definite riducono significativamente i tempi di inattività. Questa sezione fornisce indicazioni pratiche su quali metriche raccogliere, come avviare contromisure rapide e come l’automazione migliori l’affidabilità.
Quali metriche contano davvero
- FHRP‑State‑Changes per minuto: aumenti improvvisi indicano flapping o problemi di preempt.
- Flap della MAC‑Table e numero di porte diverse per MAC virtuale: indicatore precoce di partizioni L2.
- Perdite di raggiungibilità IP SLA e reset di sessioni BFD: indicano reali interruzioni del forwarding.
- Control‑Plane‑Drops (ACL/QoS/CP‑Policing): se il router è sotto carico CPU, i pacchetti di segnalazione vengono persi.
Regole di monitoring e alert (consigliate)
- Allarme se FHRP‑State‑Changes > 3 in 5 minuti.
- Avviso per MAC‑Flap‑Rate > X per minuto (valore dipendente dall’ambiente).
- Critico se IP SLA‑Loss > 5% per 1 minuto o BFD‑Down.
Misure rapide d’emergenza (estratto runbook)
- Isolare: assegnare i trunk VLAN interessati e, se necessario, impostare temporaneamente le porte in „errdisable“ per fermare il flapping.
- Stabilizzare: disabilitare temporaneamente la preemption o aumentare il Preempt‑Delay, finché non si stabiliscono le adiacenze upstream.
- ARP‑Refresh: consentire gratuitous ARP sugli edge‑switch e, se necessario, svuotare la ARP‑cache dei client.
- Fallback: impostare manualmente la priorità del master (con rollback documentato) se il failover automatico non funziona in modo affidabile.
Esempi di comandi rapidi per operatori:
# 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 allAutomazione e change management
Mantenete le configurazioni FHRP in un repository Git, verificate le modifiche tramite CI (linting, validazione sintattica dei template) e eseguite test pianificati in un emulatore di laboratorio (GNS3、EVE‑NG). Backup versionati consentono rollback rapido dopo modifiche errate.
Misure a lungo termine
Eseguite test di caos regolari (Link‑Down controllati, IP‑SLA‑Targets unreachability) e documentate le metriche e le baseline accettabili. In questo modo riconoscete degradazioni progressive prima che gli utenti siano impattati. Documentazione, backup automatizzati e un chiaro percorso di emergenza rendono l’HA per i Core‑Router realmente solida in esercizio.
Per questo argomento sono importanti anche la configurazione di VRRP e la configurazione di HSRP. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.