Introduzione
In questo documento viene descritto come risolvere i problemi di split-brain in Cisco Adaptive Security Appliance failover o Firepower Threat Defense High Availability Pairs.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza del funzionamento della coppia di alta disponibilità (failover) ASA/FTD - Informazioni sul failover.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware e si applica a tutte le implementazioni ASA/FTD supportate nel failover.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Che cos'è Split-Brain?
Lo split-brain è uno scenario in cui le unità di un'HA ASA/FTD non sono in grado di rilevarsi a vicenda sulla rete e quindi assumono entrambe il ruolo attivo. In questo modo, entrambe le unità avranno lo stesso indirizzo IP e lo stesso indirizzo MAC dell'interfaccia e possono causare gravi incoerenze nella rete con conseguente perdita dei servizi.
Per verificare se l'elevata disponibilità è in modalità split-brain, eseguire il comando show failover state su entrambe le unità e verificare se entrambe le caselle sono attive.
Esempio di cervello diviso
Unità principale:
ciscoasa1/act/pri# show failover state
State Last Failure Reason Date/Time
This host - Primary
Active None
Other host - Secondary
Failed Comm Failure 02:39:43 UTC Jan 10 2022
====Configuration State===
Sync Done - STANDBY
====Communication State==
Unità secondaria:
ciscoasa2/act/sec# show failover state
State Last Failure Reason Date/Time
This host - Secondary
Active None
Other host - Primary
Failed Comm Failure 02:39:40 UTC Jan 10 2022
====Configuration State===
Sync Done
Sync Done - STANDBY
====Communication State==
La separazione del cervello può causare un'interruzione se l'indirizzo MAC appreso per gli indirizzi IP attivi sui dispositivi collegati non è lo stesso per tutte le unità. Si consideri, ad esempio, la topologia di rete:
Topologia lab
I VMAC sono stati assegnati all'interfaccia come mostrato. In questo modo la tabella degli indirizzi MAC è di facile comprensione:
Inside (G0/2) : Active MAC - 00c1.1000.aaaa
Standby MAC - 00c1.1000.bbbb
Outside (G0/4) : Active MAC - 00c1.2000.aaaa
Standby MAC - 00c1.2000.bbbb
Nota: se i VMAC non sono configurati, il dispositivo attivo utilizza sempre il MAC dell'interfaccia dell'unità primaria e il dispositivo standby utilizza il MAC secondario.
Tabella indirizzi MAC sullo switch quando HA è integro:
Switch#show mac address-table
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
100 00c1.1000.aaaa DYNAMIC Gi1/0/5
100 00c1.1000.bbbb DYNAMIC Gi1/0/1
300 00c1.64bc.c508 DYNAMIC Gi1/0/4
300 00d7.8f38.8424 DYNAMIC Gi1/0/8
200 00c1.2000.aaaa DYNAMIC Gi1/0/7
200 00c1.2000.bbbb DYNAMIC Gi1/0/3
Se il collegamento di failover si interrompe, l'unità attiva rimane attiva e la modalità standby rimane attiva. Quando un'unità non riceve tre messaggi HELLO consecutivi sul collegamento di failover, invia messaggi LANTEST su ogni interfaccia dati, incluso il collegamento di failover, per verificare se il peer risponde o meno. L'azione che l'ASA esegue dipende dalla risposta dell'altra unità.
Le azioni possibili sono:
- Se l'ASA riceve una risposta sul collegamento di failover, non esegue il failover.
- Se l'ASA non riceve una risposta sul collegamento di failover, ma riceve una risposta sull'interfaccia dati, l'unità non esegue il failover. Il collegamento di failover è contrassegnato come non riuscito. È possibile ripristinare il collegamento di failover il prima possibile perché l'unità non può eseguire il failover in modalità standby mentre il collegamento di failover è inattivo.
- Se l'ASA non riceve una risposta su nessuna interfaccia, l'unità di standby passa alla modalità attiva e classifica l'altra unità come guasta. Questo porta ad uno scenario di separazione dei cervelli.
In questa fase, tutte le interfacce dati su entrambi i firewall funzionano come se fossero l'unità attiva. Pertanto, le interfacce sul firewall attivo e in standby utilizzano lo stesso indirizzo IP e MAC. Ciò causa un'incoerenza nella tabella degli indirizzi MAC a causa di una voce arp non elaborabile e quindi può causare un'interruzione delle attività.
Nota: il collegamento di failover è responsabile della comunicazione di questi dati tra la coppia di failover: stato unità (attivo/standby), messaggi Hello, stato collegamento di rete, scambio di indirizzi MAC, replica configurazione e sincronizzazione.
Come prepararsi in modo proattivo ai problemi di failover
Per prepararsi in modo proattivo contro una condizione di separazione del cervello:
- Essere nella release d'oro consigliata da Cisco - In alcune condizioni, la separazione del cervello può anche essere causata da problemi come una perdita di memoria. Le versioni consigliate da Cisco riducono significativamente l'esposizione a tali situazioni.
- Topologia di rete: si consiglia che le interfacce dati e i collegamenti di failover abbiano percorsi diversi per ridurre la possibilità che si verifichino errori di tutte le interfacce contemporaneamente.
- Utilizzare un'interfaccia del canale della porta per l'interfaccia di failover: se sul firewall sono presenti interfacce inutilizzate, associarle in modo da formare un canale della porta e utilizzarlo come collegamento di failover, in modo da aumentare l'affidabilità del collegamento e rimuovere un Single Point of Failure (SPOF).
- Assicurarsi che l'interfaccia di failover non abbia una latenza eccessiva - Come indicato nella guida alla configurazione dell'ASA "Per prestazioni ottimali quando si utilizza il failover su lunga distanza, la latenza per il collegamento di stato può essere inferiore a 10 millisecondi e non superiore a 250 millisecondi. Se la latenza è superiore a 10 millisecondi, si verificherà un calo delle prestazioni dovuto alla ritrasmissione dei messaggi di failover."
- Regolare i valori di Timer polling/Timer di attesa in base all'implementazione. Non esiste un approccio unico per tutti i timer di failover. In generale, un timer ridotto può causare failover non necessari (soprattutto se si verifica una certa latenza) e un valore troppo alto può causare un aumento del tempo necessario per il failover. Questo porta a notevoli failover. Il valore del timer di attesa deve essere 5x valore del timer di polling.
- Configurazione di un indirizzo MAC virtuale per le interfacce - In una condizione in cui "l'unità secondaria si avvia senza rilevare l'unità primaria, l'unità secondaria diventa l'unità attiva e utilizza i propri indirizzi MAC perché non conosce gli indirizzi MAC dell'unità primaria. Quando l'unità primaria diventa disponibile, l'unità secondaria (attiva) cambia gli indirizzi MAC in quelli dell'unità primaria, causando un'interruzione nel traffico di rete. Allo stesso modo, se si cambia l'unità principale con il nuovo hardware, viene utilizzato un nuovo indirizzo MAC."
Gli indirizzi MAC virtuali proteggono da queste interruzioni, in quanto gli indirizzi MAC attivi sono noti all'unità secondaria all'avvio e rimangono gli stessi nel caso di nuovo hardware dell'unità primaria. Se non si configurano indirizzi MAC virtuali, è necessario cancellare le tabelle ARP sui router connessi per ripristinare il flusso del traffico". Per ulteriori informazioni, vedere - Indirizzi MAC e indirizzi IP in Failover.
- Inviare i log ASA/FTD di entrambe le unità a un server Syslog esterno. Questo passaggio è più adatto alla manutenzione dei problemi.
Possibili motivi per la separazione del cervello
Come già accennato, lo split-brain si verifica quando la comunicazione tra le interfacce del collegamento di failover è inattiva (in modo unidirezionale o bidirezionale). I motivi più comuni sono:
- Problemi L1 - Cavo/SFP/Interfaccia guasto
- Problema su un dispositivo intermedio
- Mancanza di memoria o di risorse CPU sull'appliance ASA/FTD
Nota: il motore ASA/Lina usa 1550 byte di blocchi di memoria per memorizzare i pacchetti per l'elaborazione. Se il numero di blocchi liberi di queste dimensioni esaurisce l'ASA/FTD, itl non è più in grado di elaborare i pacchetti di failover. Eseguire il comando show block per verificare se il blocco è stato svuotato.
Procedura di risoluzione dei problemi - Diagramma di flusso
Per risolvere i problemi relativi a uno Scenario a cervello diviso, utilizzare questo diagramma di flusso partendo dalla casella contrassegnata come Main (Principale). Ci sono alcuni problemi che non sono risolvibili qui. In questi casi, vengono forniti collegamenti al supporto tecnico Cisco. Per aprire una richiesta di assistenza, è necessario disporre di un contratto di assistenza valido.
Nota: nelle distribuzioni FTD, seguire i passi descritti in questo grafico da "system support diagnostics-cli".
Diagramma di flusso per la risoluzione dei problemi
Ripristino di emergenza da split-brain
Per ripristinare la rete da una suddivisione del cervello, è necessario assicurarsi che il traffico colpisca solo uno dei due firewall, ovvero che gli indirizzi MAC appresi per gli IP attivi puntino tutti a una singola unità. A tale scopo, è possibile disabilitare il failover sull'unità o interromperne completamente la connessione alla rete.
- Disabilitare il failover sull'unità che non trasmette il traffico:
- Sulla piattaforma ASA, dalla CLI, passare al terminale di configurazione e immettere il comando no failover.
- Su Piattaforma FTD, in modalità Clish, immettere il comando configure high-availability suspend.
- Per l'appliance ASA, chiudere le interfacce dati. Per FTD, chiudere le interfacce sul dispositivo collegato. In alternativa, è possibile disconnettere fisicamente le interfacce. È inoltre possibile spegnere il dispositivo, ma in questo modo non è possibile gestirlo. Per ulteriori informazioni, consultare la guida alla configurazione del dispositivo.
Nota: se si verificano problemi di connettività anche dopo aver eseguito le operazioni descritte, è probabile che i dispositivi collegati dispongano di voci arp non aggiornate. Controllare le voci arp sui dispositivi upstream e downstream. Per risolvere il problema, è possibile scaricarli o forzare l'ASA/FTD a inviare un pacchetto garp per l'IP dell'interfaccia con il problema. A tale scopo, eseguire il comando in modalità abilitazione (per FTD in Sistema supporta diagnostics-cli) - debug menu ipaddrutl 6 <indirizzo ip interfaccia>.
Attenzione: se si apre una richiesta di assistenza con TAC per problemi relativi alla separazione dei cervelli, è necessario condividere le informazioni indicate nella sezione Dati da raccogliere per la richiesta di assistenza TAC in questo documento.
Dati da condividere con TAC
Condividere i dati menzionati se è necessario aprire una richiesta di assistenza TAC.
- Diagramma topologico che mostra l'ASA/FTD-HA e le sue connessioni fisiche con i dispositivi adiacenti (incluse le interfacce di failover).
- Output per mostrare il supporto tecnico su ASA o il file sulla risoluzione dei problemi su piattaforme con FTD.
- Registri di sistema con indicazione dell'ora per +/- 5 minuti quando si è verificato il problema.
- File di risoluzione dei problemi FXOS, se l'hardware è un accessorio FPR.
Per generare i file di risoluzione dei problemi per FTD o FXOS, consultare il documento sulla risoluzione dei problemi relativi alle procedure di generazione dei file di Firepower. Aprire TAC SR.