La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive come ricostruire una struttura Cisco SD-WAN, incluso il backup e il ripristino delle configurazioni dei controller per diverse implementazioni.
Cisco raccomanda la conoscenza dei seguenti argomenti:
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.
Distribuzione vManage
Opzioni DR
Nota: Per ulteriori dettagli sul tipo di ripristino di emergenza, fare riferimento a questo collegamento
Combinazioni:
| N. | Installazione di vManage | Opzione DR |
|---|---|---|
| 1 | Indipendente (1 nodo) | Nessun ripristino di emergenza |
| 2 | Indipendente (1 nodo) | DR. a nodo singolo |
| 3 | Cluster (a 3 o 6 nodi) | Nessun ripristino di emergenza |
| 4 | Cluster (a 3 o 6 nodi) | Cluster DR in standby |
Questi passaggi sono comuni a tutte le combinazioni di distribuzione. Coprono il processo di attivazione delle istanze di VM e di applicazione della configurazione CLI di base. In ogni sezione combinata viene indicato il numero di istanze da distribuire e i passaggi aggiuntivi da completare.
Nota: Cisco ha rinominato alcuni termini, quindi sono intercambiabili. Cisco vManage = Cisco Catalyst Manager, Cisco vBond = Cisco Catalyst Validator, Cisco vSmart = Cisco Catalyst Controller
Scaricare i file OVA per i controller SD-WAN dalla pagina di download del software Cisco qui:
Nota: Sulle piattaforme ESXi/cloud, eseguire lo spin up dei controller vSmart, vBond e vManage utilizzando il file OVA. Fare riferimento al documento collegato e assicurarsi che CPU, RAM e dischi siano allocati in misura sufficiente a tutti i controller a seconda del tipo di distribuzione SD-WAN. Fare clic qui per ulteriori informazioni. Assicurarsi di assegnare il disco secondario al nodo vManage come indicato nella colonna Dimensione memoria* nella guida al calcolo collegata.
For a standalone vManage, choose the persona as COMPUTE_AND_DATA.
For a 3 node cluster, on 3 vManage nodes, the persona is set to COMPUTE_AND_DATA.
For a 6 node cluster, on 3 vManage nodes the persona is COMPUTE_AND_DATA and on rest 3 vManage nodes persona DATA.
Esempio:scegliere 1 per COMPUTE_AND_DATA

Scegliere il disco secondario come illustrato:


Esempio

Nota: È possibile fare riferimento alla configurazione dal vManage esistente e configurare qui lo stesso schema di indirizzi IP.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Esempio:

Nota: È possibile fare riferimento alla configurazione dal vBond esistente e configurare qui le stesse configurazioni.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
commit
Una volta ottenuto l'accesso SSH a tutti i controller, configurare queste configurazioni CLI su ciascun controller.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Nota: se si utilizza URL come indirizzo vBond, verificare di configurare gli indirizzi IP dei server DNS nella configurazione VPN 0 o di risolverli.
Queste configurazioni sono necessarie su tutti i controller per abilitare l'interfaccia di trasporto utilizzata per stabilire le connessioni di controllo con i router e gli altri controller.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Nota: è possibile fare riferimento alle configurazioni del controller esistente e, se la configurazione è presente, è possibile aggiungerla ai nuovi controller.
Configurare il protocollo di controllo come TLS solo se è necessario che i router stabiliscano connessioni di controllo protette con i nodi vManage che utilizzano TLS. Per impostazione predefinita, tutti i controller e i router stabiliscono una connessione di controllo utilizzando DTLS. Si tratta di una configurazione opzionale richiesta solo sui nodi vSmart e vManage a seconda delle esigenze.
Conf t
security
control
protocol tls
Commit
Verificare che il numero delle istanze attive di Cisco SD-WAN Manager sia identico al numero delle nuove istanze di Cisco SD-WAN Manager installate.
Accertarsi che tutte le istanze Cisco SD-WAN Manager attive e nuove eseguano la stessa versione del software.
Verificare che tutte le istanze Cisco SD-WAN Manager nuove e attive siano in grado di raggiungere l'indirizzo IP di gestione di Cisco SD-WAN Validator.
Verificare che i certificati siano stati installati nelle istanze di Cisco SD-WAN Manager appena installate.
Verificare che gli orologi di tutti i dispositivi Cisco Catalyst SD-WAN, incluse le nuove istanze di Cisco SD-WAN Manager installate, siano sincronizzati.
Verificare che nelle istanze di Cisco SD-WAN Manager appena installate sia configurato un nuovo set di IP di sistema e ID di sito, insieme alla stessa configurazione di base del cluster attivo.




Nel caso in cui si utilizzi la propria CA, Autorità di certificazione dell'organizzazione (enterprise), scegliere Enterprise.


Passare a Configurazione > Dispositivi > Controllo componenti nel caso di nodi vManage 20.15/20.18. In caso di versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Nota: è necessario utilizzare le credenziali di amministratore di vBondor una parte utente di netadmingroup. È possibile verificare questa condizione nella CLI di vBond. Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vBond.
Nota: Se vBond è dietro un dispositivo/firewall NAT, verificare se l'IP dell'interfaccia VPN 0 di vBond è convertito in un IP pubblico. Se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, in questo passaggio utilizzare l'indirizzo IP pubblico dell'interfaccia VPN 0.

Fare clic su Add vSmart in caso di vManage 20.12 o Add Controller in caso di vManage 20.15/20.18.
Viene visualizzato un popup. Immettere l'IP di trasporto VPN 0 di vSmart raggiungibile da vManage.
Verificare la raggiungibilità usando il comando ping, se consentito dalla CLI di vManage a vSmart IP.
Immettere le credenziali utente di vSmart Note che è necessario utilizzare le credenziali di amministratore di vSmart o di un utente appartenente al gruppo netadmin.
È possibile verificare questa condizione nella CLI di vSmart.
Impostare il protocollo su TLS se si intende utilizzare TLS per i router per stabilire connessioni di controllo con vSmart. Questa configurazione deve essere configurata anche sulla CLI dei nodi vSmarts e vManage.
Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vSmart.
Nota: se vSmart è dietro un dispositivo/firewall NAT, verificare se l'indirizzo IP dell'interfaccia vSmart VPN 0 è convertito in un indirizzo IP pubblico e se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, utilizzare l'indirizzo IP pubblico dell'indirizzo IP dell'interfaccia VPN 0 in questo passaggio.

Una volta completati tutti i passaggi, verificare che tutti i componenti di controllo siano raggiungibili in Monitor>Dashboard


Verificare che configuration-db sia in esecuzione nel nodo vManage.
Per verificare lo stesso comportamento, usare il comando request nms configuration-db status su vManageCLI. L'output è il seguente
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
Utilizzare questo comando per raccogliere il backup del database di configurazione dal nodo vManage leader del database di configurazione identificato.
request nms configuration-db backup path /opt/data/backup/
L'output previsto è il seguente:
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiare il backup del database di configurazione nella directory /home/admin/ di vManage utilizzando SCP.
Output di esempio del comando scp:
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Per ripristinare il backup del database di configurazione, è necessario innanzitutto configurare le credenziali del database di configurazione. Se le credenziali del database di configurazione sono predefinite (neo4j/password), è possibile ignorare questo passaggio.
Per configurare le credenziali configuration-db, utilizzare il comando request nms configuration-db update-admin-user. Utilizzare il nome utente e la password desiderati.
Notare che il server applicazioni di vManage è stato riavviato. A causa della quale l'interfaccia utente di vManage diventa inaccessibile per un breve periodo.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Post in cui è possibile procedere al ripristino del backup del database di configurazione:
È possibile utilizzare il comando request nms configuration-db restore path /home/admin/< > per ripristinare configuration-db nel nuovo vManage:
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Una volta ripristinato il database di configurazione, verificare che l'interfaccia utente di vManage sia accessibile. Attendere circa 5 minuti e quindi tentare di accedere all'interfaccia utente.
Dopo aver eseguito correttamente il login all'interfaccia utente, verificare che l'elenco dei router perimetrali, il modello, i criteri e tutte le altre configurazioni presenti nell'interfaccia utente vManage precedente o esistente siano riflessi nella nuova interfaccia utente vManage.
Una volta ripristinato il database di configurazione, è necessario riautenticare tutti i nuovi controller (manage/vsmart/vbond) nel fabric.
Nota: nella produzione effettiva, se l'IP dell'interfaccia utilizzato per la riautenticazione è l'IP dell'interfaccia del tunnel, è necessario garantire che il servizio NETCONF sia consentito sull'interfaccia del tunnel di vManage, vSmart e vBond e anche sui firewall lungo il percorso. La porta firewall da aprire è la porta TCP 830 come regola bidirezionale dal cluster DR a tutti i vBonds e vSmarts.
Su gestisci interfaccia utente, fare clic su Configurazione > Dispositivi > Controller


Una volta caricati tutti i controller, attenersi a questa procedura:
Su qualsiasi server Cisco SD-WAN Manager nel cluster appena attivo, eseguire le seguenti azioni:
Immettere questo comando per sincronizzare il certificato radice con tutti i dispositivi Cisco Catalyst SD-WAN nel cluster appena attivo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Immettere questo comando per sincronizzare l'UUID di Cisco SD-WAN Manager con Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Una volta ripristinata la struttura e attivate le sessioni bfd e di controllo per tutti i bordi e i controller della struttura, è necessario invalidare i vecchi controller (vmanage/vsmart/vbond) dall'interfaccia utente
Nota: Continuare con la sezione Controlli successivi mostrata qui, che è comune a tutte le combinazioni di distribuzione.
Verificare che il numero delle istanze attive di Cisco SD-WAN Manager sia identico al numero delle nuove istanze di Cisco SD-WAN Manager installate.
Accertarsi che tutte le istanze Cisco SD-WAN Manager attive e nuove eseguano la stessa versione del software.
Verificare che tutte le istanze Cisco SD-WAN Manager nuove e attive siano in grado di raggiungere l'indirizzo IP di gestione di Cisco SD-WAN Validator.
Verificare che i certificati siano stati installati nelle istanze di Cisco SD-WAN Manager appena installate.
Verificare che gli orologi di tutti i dispositivi Cisco Catalyst SD-WAN, incluse le nuove istanze di Cisco SD-WAN Manager installate, siano sincronizzati.
Verificare che nelle istanze di Cisco SD-WAN Manager appena installate sia configurato un nuovo set di IP di sistema e ID di sito, insieme alla stessa configurazione di base del cluster attivo.




Nel caso in cui si utilizzi la propria CA, Autorità di certificazione dell'organizzazione (enterprise), scegliere Enterprise.


Passare a Configurazione > Dispositivi > Controllo componenti nel caso di nodi vManage 20.15/20.18. Nel caso delle versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Nota: è necessario utilizzare le credenziali di amministratore di vBondor una parte utente di netadmingroup. È possibile verificare questa condizione nella CLI di vBond. Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vBond
Nota: Se vBond è dietro un dispositivo/firewall NAT, verificare se l'IP dell'interfaccia VPN 0 di vBond è convertito in un IP pubblico. Se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, in questo passaggio utilizzare l'indirizzo IP pubblico dell'interfaccia VPN 0

Fare clic su Add vSmart in caso di vManage 20.12 o Add Controller in caso di vManage 20.15/20.18.
Viene visualizzato un popup. Immettere l'IP di trasporto VPN 0 di vSmart raggiungibile da vManage.
Verificare la raggiungibilità usando il comando ping, se consentito dalla CLI di vManage a vSmart IP.
Immettere le credenziali utente di vSmart Note che è necessario utilizzare le credenziali di amministratore di vSmart o di un utente appartenente al gruppo netadmin.
È possibile verificare questa condizione nella CLI di vSmart.
Impostare il protocollo su TLS se si intende utilizzare TLS per i router per stabilire connessioni di controllo con vSmart. Questa configurazione deve essere configurata anche sulla CLI dei nodi vSmarts e vManage.
Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vSmart.
Nota: se vSmart è dietro un dispositivo/firewall NAT, verificare se l'indirizzo IP dell'interfaccia vSmart VPN 0 è convertito in un indirizzo IP pubblico e se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, utilizzare l'indirizzo IP pubblico dell'indirizzo IP dell'interfaccia VPN 0 in questo passaggio.

Una volta completati tutti i passaggi, verificare che tutti i componenti di controllo siano raggiungibili in Monitor>Dashboard


Nota: Durante la raccolta del backup del database di configurazione dal nodo vManage esistente in cui è abilitato il ripristino di emergenza, assicurarsi che venga raccolto dopo che il ripristino di emergenza su tale nodo è stato sospeso ed eliminato.
Confermare che non è in corso la replica per il disaster recovery. Selezionare Amministrazione > Disaster Recovery e verificare che lo stato sia Operazione riuscita e non in uno stato transitorio, ad esempio Importazione in sospeso, Esportazione in sospeso o Download in sospeso. Se lo stato non ha esito positivo, contattare Cisco TAC e verificare la corretta replica prima di sospendere il ripristino di emergenza.
Sospendere innanzitutto il ripristino di emergenza e assicurarsi che l'attività sia completata. Eliminare quindi il ripristino di emergenza e verificare che l'attività sia stata completata.

Contattare Cisco TAC per garantire la corretta pulizia del dispositivo di ripristino di emergenza.
Verificare che configuration-db sia in esecuzione nel nodo vManage.
È possibile verificare la stessa condizione utilizzando il comando request nms configuration-db statusonvManageCLI. L'output è il seguente
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
Utilizzare questo comando per raccogliere il backup del database di configurazione dal nodo vManage leader del database di configurazione identificato.
request nms configuration-db backup path /opt/data/backup/
L'output previsto è il seguente:
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiare il backup del database di configurazione nella directory /home/admin/ di vManage utilizzando SCP.
Output di esempio del comando scp:
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Per ripristinare il backup del database di configurazione, è necessario innanzitutto configurare le credenziali del database di configurazione. Se le credenziali del database di configurazione sono predefinite (neo4j/password), è possibile ignorare questo passaggio.
Per configurare le credenziali configuration-db, utilizzare il comando request nms configuration-db update-admin-user.Utilizzare il nome utente e la password desiderati.
Notare che il server applicazioni di vManage è stato riavviato. A causa della quale l'interfaccia utente di vManage diventa inaccessibile per un breve periodo.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Post in cui è possibile procedere al ripristino del backup del database di configurazione:
È possibile utilizzare il comando request nms configuration-db restore path /home/admin/< > per ripristinare configuration-db nel nuovo vManage:
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Una volta ripristinato il database di configurazione, verificare che l'interfaccia utente di vManage sia accessibile. Attendere circa 5 minuti e quindi tentare di accedere all'interfaccia utente.
Dopo aver eseguito correttamente il login all'interfaccia utente, verificare che l'elenco dei router perimetrali, il modello, i criteri e tutte le altre configurazioni presenti nell'interfaccia utente vManage precedente o esistente siano riflessi nella nuova interfaccia utente vManage.
Fare riferimento al passaggio 2: Controlli preliminari nella combinazione 2: vManage standalone + ripristino di emergenza a nodo singolo e verifica di aver completato tutti i requisiti prima di procedere con l'abilitazione del ripristino di emergenza.
Interfaccia cluster fuori banda nella VPN 0
Configurazione minima bare per vManageprima della registrazione del ripristino di emergenza è come mostrato
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Nota: se si utilizza URL come indirizzo vBond, verificare di configurare gli indirizzi IP dei server DNS nella configurazione VPN 0 o di risolverli.
Queste configurazioni sono necessarie per abilitare l'interfaccia di trasporto utilizzata per stabilire le connessioni di controllo con i router e gli altri controller
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurare inoltre l'interfaccia di gestione VPN 512 per consentire l'accesso di gestione fuori banda al controller.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
commit
Configurare l'interfaccia di servizio nel nodo vManage. Questa interfaccia viene utilizzata per la comunicazione DR,
conf t
interface eth2
ip address
no shutdown
commit
Verificare che per l'interfaccia di servizio sul server vManage principale e sul server vManage primario venga utilizzata la stessa subnet IP
Procedere come indicato nella sezione Combinazione 2: vManage standalone + DR a nodo singolo Fase 3: Configurare l'interfaccia utente, i certificati e i controller integrati di vManage per installare il certificato in vManage di Disaster Recovery.

Una volta compilato, fai clic su "Successivo".
Specificare i dettagli dei controller vBond.
I controller vBond devono essere raggiungibili nell'indirizzo IP specificato tramite Netconf.
Le credenziali devono essere quelle di un utente netadmin (dradmin) e non devono essere modificate una volta configurato il ripristino di emergenza.
Per questo motivo, è consigliabile che vBond disponga di questo utente dradmin configurato localmente oppure è possibile utilizzare l'utente admin per aggiungere il vBond.


Nella pianificazione della replica, impostare l'intervallo di replica".Ogni intervallo di replica, i dati vengono replicati dal database primario vManageto vManage secondario. Il valore minimo configurabile è 15 minuti.


Si noti che l'interfaccia utente grafica di vManage viene riavviata durante questo processo.
Al termine, è necessario visualizzare lo stato Operazione completata.

Passare a Amministrazione → Disaster Recoveryper verificare lo stato del ripristino di emergenza e la data dell'ultima replica dei dati.

Una volta ripristinato il database di configurazione, è necessario riautenticare tutti i nuovi controller (manage/vsmart/vbond) nel fabric
Nota: nella produzione effettiva, se l'IP dell'interfaccia utilizzato per la riautenticazione è l'IP dell'interfaccia del tunnel, è necessario garantire che il servizio NETCONF sia consentito sull'interfaccia del tunnel di vManage, vSmart e vBond e anche sui firewall lungo il percorso. La porta firewall da aprire è la porta TCP 830 come regola bidirezionale dal cluster DR a tutti i vBonds e vSmarts.
Su vmanage UI, fare clic su Configurazione > Dispositivi > Controller

Una volta caricati tutti i controller, attenersi a questa procedura:
Su qualsiasi server Cisco SD-WAN Manager nel cluster appena attivo, eseguire le seguenti azioni:
Immettere questo comando per sincronizzare il certificato radice con tutti i dispositivi Cisco Catalyst SD-WAN nel cluster appena attivo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Immettere questo comando per sincronizzare l'UUID di Cisco SD-WAN Manager con Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Una volta ripristinata la struttura e attivate le sessioni bfd e di controllo per tutti i bordi e i controller della struttura, è necessario invalidare i vecchi controller (vmanage/vsmart/vbond) dall'interfaccia utente
Nota: Continuare con la sezione Controlli successivi mostrata qui, che è comune a tutte le combinazioni di distribuzione.
Istanze necessarie:
Passaggi:
Verificare che il numero delle istanze attive di Cisco SD-WAN Manager sia identico al numero delle nuove istanze di Cisco SD-WAN Manager installate.
Accertarsi che tutte le istanze Cisco SD-WAN Manager attive e nuove eseguano la stessa versione del software.
Verificare che tutte le istanze Cisco SD-WAN Manager nuove e attive siano in grado di raggiungere l'indirizzo IP di gestione di Cisco SD-WAN Validator.
Verificare che i certificati siano stati installati nelle istanze di Cisco SD-WAN Manager appena installate.
Verificare che gli orologi di tutti i dispositivi Cisco Catalyst SD-WAN, incluse le nuove istanze di Cisco SD-WAN Manager installate, siano sincronizzati.
Verificare che nelle istanze di Cisco SD-WAN Manager appena installate sia configurato un nuovo set di IP di sistema e ID di sito, insieme alla stessa configurazione di base del cluster attivo.




Nel caso in cui si utilizzi la propria CA, Autorità di certificazione dell'organizzazione (enterprise), scegliere Enterprise.


Passare a Configurazione > Dispositivi > Controllo componenti nel caso di nodi vManage 20.15/20.18. Nel caso delle versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Nota: è necessario utilizzare le credenziali di amministratore di vBondor una parte utente di netadmingroup. È possibile verificare questa condizione nella CLI di vBond. Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vBond
Nota: Se vBond è dietro un dispositivo/firewall NAT, verificare se l'IP dell'interfaccia VPN 0 di vBond è convertito in un IP pubblico. Se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, in questo passaggio utilizzare l'indirizzo IP pubblico dell'interfaccia VPN 0

Fare clic su Add vSmart in caso di vManage 20.12 o Add Controller in caso di vManage 20.15/20.18.
Viene visualizzato un popup. Immettere l'IP di trasporto VPN 0 di vSmart raggiungibile da vManage.
Verificare la raggiungibilità usando il comando ping, se consentito dalla CLI di vManage a vSmart IP.
Immettere le credenziali utente di vSmart Note che è necessario utilizzare le credenziali di amministratore di vSmart o di un utente appartenente al gruppo netadmin.
È possibile verificare questa condizione nella CLI di vSmart.
Impostare il protocollo su TLS se si intende utilizzare TLS per i router per stabilire connessioni di controllo con vSmart. Questa configurazione deve essere configurata anche sulla CLI dei nodi vSmarts e vManage.
Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vSmart.
Nota: se vSmart è dietro un dispositivo/firewall NAT, verificare se l'indirizzo IP dell'interfaccia vSmart VPN 0 è convertito in un indirizzo IP pubblico e se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, utilizzare l'indirizzo IP pubblico dell'indirizzo IP dell'interfaccia VPN 0 in questo passaggio.

Una volta completati tutti i passaggi, verificare che tutti i componenti di controllo siano raggiungibili in Monitor>Dashboard


Nota: il cluster vManage può essere configurato con 3 nodi vManage o 6 nodi vManage a seconda del numero di siti collegati all'infrastruttura SD-WAN. Fare riferimento al cluster vManage esistente e scegliere il numero di nodi in base allo stesso.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Nota: se si utilizza URL come indirizzo vBond, verificare di configurare gli indirizzi IP dei server DNS nella configurazione VPN 0 o di risolverli.
Queste configurazioni sono necessarie per abilitare l'interfaccia di trasporto utilizzata per stabilire le connessioni di controllo con i router e gli altri controller.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurare inoltre l'interfaccia di gestione VPN 512 per consentire l'accesso di gestione fuori banda al controller.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configurazione facoltativa:
Conf t
security
control
protocol tls
commit
Configurare l'interfaccia del servizio su tutti i vManagenodes, incluso vManage-1 che è già stato caricato. Questa interfaccia viene utilizzata per la comunicazione del cluster, ovvero la comunicazione tra i vManagenodes nel cluster.
conf t
interface eth2
ip address
no shutdown
commit
Verificare che per l'interfaccia di servizio in tutti i nodi del cluster vManagement venga utilizzata la stessa subnet IP.
È possibile utilizzare le stesse credenziali di amministrazione dei nodi vManage per configurare il cluster vManage. In caso contrario, è possibile configurare una nuova credenziale utente che faccia parte di netadmingroup. Le configurazioni per la configurazione delle nuove credenziali utente sono le seguenti
conf t
system
aaa
user
password
group netadmin
commit
Assicurarsi di configurare le stesse credenziali utente in tutti gli vManagenodesche fanno parte del cluster.Se si decide di utilizzare le credenziali di amministratore, è necessario che siano lo stesso nome utente/password in tutti gli vManagenodes.
Passare a Configurazione > Certificati > Controlla componenti nel caso di nodi vManage 20.15/20.18. Nel caso delle versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Fare clic su ... per Manager/vManage e fare clic su Generate CSR.

Una volta generato il CSR, è possibile scaricarlo e firmarlo in base all'autorità di certificazione scelta per i controller. È possibile verificare questa configurazione in Amministrazione > Impostazioni > Autorizzazione certificato controller. Se si sceglie Cisco (scelta consigliata), il CSR viene caricato automaticamente nel portale PNP da vManage e, una volta firmato, il certificato viene installato automaticamente in vManage.
Se si sceglie Manuale, firmare manualmente il CSR utilizzando il portale PNP di Cisco passando allo smart account e all'account virtuale della relativa sovrapposizione SD-WAN. La stessa procedura è applicabile se si utilizza il certificato radice Digicert ed Enterprise.
Una volta che il certificato è disponibile dal portale PNP, fare clic su installa certificato nella stessa sezione di vManage, quindi caricare il certificato e installarlo.
Completare questo passaggio in tutti i nodi vManage che fanno parte del cluster.
Nota: Per un cluster a 3 nodi, tutti e 3 i nodi vManage vengono visualizzati con compute+data come persona.

Nota: Fare riferimento a questa configurazione nel cluster esistente per abilitare SDAVC. Deve essere verificata solo se è richiesta ed è necessaria solo su un nodo vManage del cluster.
Fare clic su Aggiorna.




Prima di aggiungere il nodo successivo al cluster, è necessario prendere in considerazione i seguenti punti:
Verificare questi punti in tutte le interfacce utente dei nodi vManage aggiunti al cluster:
Una volta caricati tutti i controller, attenersi a questa procedura:
Nota: Durante la raccolta del backup del database di configurazione dal cluster vManage esistente in cui è abilitato il ripristino di emergenza, assicurarsi che venga raccolto dopo che il ripristino di emergenza in tale nodo è stato sospeso ed eliminato.
Confermare che non è in corso la replica per il disaster recovery. Selezionare Amministrazione > Disaster Recovery e verificare che lo stato sia Operazione riuscita e non in uno stato transitorio, ad esempio Importazione in sospeso, Esportazione in sospeso o Download in sospeso. Se lo stato non ha esito positivo, contattare Cisco TAC e verificare la corretta replica prima di sospendere il ripristino di emergenza.
Sospendere innanzitutto il ripristino di emergenza e assicurarsi che l'attività sia completata. Eliminare quindi il ripristino di emergenza e verificare che l'attività sia stata completata.

Contattare Cisco TAC per garantire la corretta pulizia del dispositivo di ripristino di emergenza.
È possibile verificare la stessa condizione utilizzando il comando requestnmsconfiguration-dbstatus in vManageCLI. L'output è il seguente
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
vManage-3# request nms configuration-db diagnostics
NMS configuration database
Checking cluster connectivity for ports 7687,7474 ...
Pinging vManage node 0 on 169.254.1.5:7687,7474...
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2026-02-18 12:41 UTC
SENT (0.0013s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (0.0022s) Handshake with 169.254.1.5:7474 completed
SENT (1.0024s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (1.0028s) Handshake with 169.254.1.5:7687 completed
SENT (2.0044s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (2.0050s) Handshake with 169.254.1.5:7474 completed
SENT (3.0064s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (3.0072s) Handshake with 169.254.1.5:7687 completed
SENT (4.0083s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (4.0091s) Handshake with 169.254.1.5:7474 completed
SENT (5.0106s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (5.0115s) Handshake with 169.254.1.5:7687 completed
Max rtt: 0.906ms | Min rtt: 0.392ms | Avg rtt: 0.724ms
TCP connection attempts: 6 | Successful connections: 6 | Failed: 0 (0.00%)
Nping done: 1 IP address pinged in 5.01 seconds
Pinging vManage node 1 on 169.254.2.5:7687,7474...
========== SNIP ==========
Connecting to 10.10.10.3...
+------------------------------------------------------------------------------------+
| type | row | attributes[row]["value"] |
+------------------------------------------------------------------------------------+
| "StoreSizes" | "TotalStoreSize" | 85828934 |
| "PageCache" | "Flush" | 4268666 |
| "PageCache" | "EvictionExceptions" | 0 |
| "PageCache" | "UsageRatio" | 0.09724264705882353 |
| "PageCache" | "Eviction" | 2068 |
| "PageCache" | "HitRatio" | 1.0 |
| "ID Allocations" | "NumberOfRelationshipIdsInUse" | 2068 |
| "ID Allocations" | "NumberOfPropertyIdsInUse" | 56151 |
| "ID Allocations" | "NumberOfNodeIdsInUse" | 7561 |
| "ID Allocations" | "NumberOfRelationshipTypeIdsInUse" | 31 |
| "Transactions" | "LastCommittedTxId" | 214273 |
| "Transactions" | "NumberOfOpenTransactions" | 1 |
| "Transactions" | "NumberOfOpenedTransactions" | 441742 |
| "Transactions" | "PeakNumberOfConcurrentTransactions" | 11 |
| "Transactions" | "NumberOfCommittedTransactions" | 414568 |
| "Causal Cluster" | "IsLeader" | 1 >>>>>>>>> |
| "Causal Cluster" | "MsgProcessDelay" | 0 |
| "Causal Cluster" | "InFlightCacheTotalBytes" | 0 |
+------------------------------------------------------------------------------------+
18 rows
ready to start consuming query after 388 ms, results consumed after another 13 ms
Completed
Connecting to 10.10.10.3...
Displaying the Neo4j Cluster Status
+---------------------------------------------------------------------------------------------------------------------------------+
| name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
+---------------------------------------------------------------------------------------------------------------------------------+
| "neo4j" | [] | "read-write" | "169.254.3.5:7687" | "leader" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.1.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "system" | [] | "read-write" | "169.254.3.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.1.5:7687" | "leader" | "online" | "online" | "" | FALSE | FALSE |
+---------------------------------------------------------------------------------------------------------------------------------+
6 rows
ready to start consuming query after 256 ms, results consumed after another 3 ms
Completed
Total disk space used by configuration-db:
60M .
Utilizzare questo comando per raccogliere il backup del database di configurazione dal nodo vManage leader del database di configurazione identificato.
request nms configuration-db backup path /opt/data/backup/
L'output previsto è il seguente:
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiare il backup del database di configurazione nella directory /home/admin/ di vManage utilizzando SCP.
Output di esempio del comando scp:
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Per ripristinare il backup del database di configurazione, è necessario innanzitutto configurare le credenziali del database di configurazione. Se le credenziali del database di configurazione sono predefinite (neo4j/password), è possibile ignorare questo passaggio.
Per configurare le credenziali configuration-db, utilizzare il comando request nms configuration-db update-admin-user.Utilizzare il nome utente e la password desiderati.
Notare che il server applicazioni di vManage è stato riavviato. A causa della quale l'interfaccia utente di vManage diventa inaccessibile per un breve periodo.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Post in cui è possibile procedere al ripristino del backup del database di configurazione:
È possibile utilizzare il comando request nms configuration-db restore path /home/admin/< > per ripristinare configuration-db nel nuovo vManage:
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Una volta ripristinato il database di configurazione, verificare che l'interfaccia utente di vManage sia accessibile. Attendere circa 5 minuti e quindi tentare di accedere all'interfaccia utente.
Dopo aver eseguito correttamente il login all'interfaccia utente, verificare che l'elenco dei router perimetrali, il modello, i criteri e tutte le altre configurazioni presenti nell'interfaccia utente vManage precedente o esistente siano riflessi nella nuova interfaccia utente vManage.
Una volta ripristinato il database di configurazione, è necessario riautenticare tutti i nuovi controller (manage/vsmart/vbond) nel fabric
Nota: nella produzione effettiva, se l'IP dell'interfaccia utilizzato per la riautenticazione è l'IP dell'interfaccia del tunnel, è necessario garantire che il servizio NETCONF sia consentito sull'interfaccia del tunnel di vManage, vSmart e vBond e anche sui firewall lungo il percorso. La porta firewall da aprire è la porta TCP 830 come regola bidirezionale dal cluster DR a tutti i vBonds e vSmarts.
Su gestisci interfaccia utente, fare clic su Configurazione > Dispositivi > Controller

Una volta caricati tutti i controller, attenersi a questa procedura:
Su qualsiasi server Cisco SD-WAN Manager nel cluster appena attivo, eseguire le seguenti azioni:
Immettere questo comando per sincronizzare il certificato radice con tutti i dispositivi Cisco Catalyst SD-WAN nel cluster appena attivo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Immettere questo comando per sincronizzare l'UUID di Cisco SD-WAN Manager con Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Una volta ripristinata la struttura e attivate le sessioni bfd e di controllo per tutti i bordi e i controller della struttura, è necessario invalidare i vecchi controller (vmanage/vsmart/vbond) dall'interfaccia utente
Nota: Continuare con la sezione Controlli successivi mostrata qui, che è comune a tutte le combinazioni di distribuzione.
Cos'è il ripristino di emergenza in standby manuale/a freddo? Il server di backup SD-WAN Manager o il cluster SD-WAN Manager viene mantenuto in stato di standby a freddo.
Vengono eseguiti backup regolari del database attivo e se il cluster primario SD-WAN Manager o SD-WAN Manager non funziona, il cluster in standby SD-WAN Manager o SD-WAN Manager viene attivato manualmente e il database di backup viene ripristinato.
Istanze necessarie:
Passaggi:
Verificare che il numero delle istanze attive di Cisco SD-WAN Manager sia identico al numero delle nuove istanze di Cisco SD-WAN Manager.
Accertarsi che tutte le istanze Cisco SD-WAN Manager attive e nuove eseguano la stessa versione del software.
Verificare che tutte le istanze Cisco SD-WAN Manager nuove e attive siano in grado di raggiungere l'indirizzo IP di gestione di Cisco SD-WAN Validator.
Verificare che i certificati siano stati installati nelle istanze di Cisco SD-WAN Manager appena installate.
Verificare che gli orologi di tutti i dispositivi Cisco Catalyst SD-WAN, incluse le nuove istanze di Cisco SD-WAN Manager installate, siano sincronizzati.
Verificare che nelle istanze di Cisco SD-WAN Manager appena installate sia configurato un nuovo set di IP di sistema e ID di sito, insieme alla stessa configurazione di base del cluster attivo.




Nel caso in cui si utilizzi la propria CA, Autorità di certificazione dell'organizzazione (enterprise), scegliere Enterprise.


Passare a Configurazione > Dispositivi > Controllo componenti nel caso di nodi vManage 20.15/20.18. Nel caso delle versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Nota: è necessario utilizzare le credenziali di amministratore di vBondor una parte utente di netadmingroup. È possibile verificare questa condizione nella CLI di vBond. Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vBond
Nota: Se vBond è dietro un dispositivo/firewall NAT, verificare se l'IP dell'interfaccia VPN 0 di vBond è convertito in un IP pubblico. Se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, in questo passaggio utilizzare l'indirizzo IP pubblico dell'interfaccia VPN 0

Fare clic su Add vSmart in caso di vManage 20.12 o Add Controller in caso di vManage 20.15/20.18.
Viene visualizzato un popup. Immettere l'IP di trasporto VPN 0 di vSmart raggiungibile da vManage.
Verificare la raggiungibilità usando il comando ping, se consentito dalla CLI di vManage a vSmart IP.
Immettere le credenziali utente di vSmart Note che è necessario utilizzare le credenziali di amministratore di vSmart o di un utente appartenente al gruppo netadmin.
È possibile verificare questa condizione nella CLI di vSmart.
Impostare il protocollo su TLS se si intende utilizzare TLS per i router per stabilire connessioni di controllo con vSmart. Questa configurazione deve essere configurata anche sulla CLI dei nodi vSmarts e vManage.
Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vSmart.
Nota: se vSmart è dietro un dispositivo/firewall NAT, verificare se l'indirizzo IP dell'interfaccia vSmart VPN 0 è convertito in un indirizzo IP pubblico e se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, utilizzare l'indirizzo IP pubblico dell'indirizzo IP dell'interfaccia VPN 0 in questo passaggio.

Una volta completati tutti i passaggi, verificare che tutti i componenti di controllo siano raggiungibili in Monitor>Dashboard


Nota: il cluster vManage può essere configurato con 3 nodi vManage o 6 nodi vManage a seconda del numero di siti collegati all'infrastruttura SD-WAN
Procedere con i passaggi condivisi in "Controller SD-WAN integrati con un singolo nodo vManage nella sovrapposizione SD-WAN" per avviare prima il fabric SD-WAN con un nodo vManage e incorporare tutti i validatori (vBond) e i controller (vSmart) richiesti.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Nota: se si utilizza URL come indirizzo vBond, verificare di configurare gli indirizzi IP dei server DNS nella configurazione VPN 0 o di risolverli.
Queste configurazioni sono necessarie per abilitare l'interfaccia di trasporto utilizzata per stabilire le connessioni di controllo con i router e gli altri controller.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurare inoltre l'interfaccia di gestione VPN 512 per consentire l'accesso di gestione fuori banda al controller.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configurazione facoltativa:
Conf t
security
control
protocol tls
commit
Configurare l'interfaccia del servizio su tutti i vManagenodes, incluso vManage-1 che è già stato caricato. Questa interfaccia viene utilizzata per la comunicazione del cluster, ovvero la comunicazione tra i vManagenodes nel cluster.
conf t
interface eth2
ip address
no shutdown
commit
Verificare che per l'interfaccia di servizio in tutti i nodi del cluster vManagement venga utilizzata la stessa subnet IP.
È possibile utilizzare le stesse credenziali di amministrazione dei nodi vManage per configurare il cluster vManage. In caso contrario, è possibile configurare una nuova credenziale utente che faccia parte di netadmingroup. Le configurazioni per la configurazione delle nuove credenziali utente sono le seguenti
conf t
system
aaa
user
password
group netadmin
commit
Assicurarsi di configurare le stesse credenziali utente in tutti gli vManagenodeche fanno parte del cluster.Se si decide di utilizzare le credenziali di amministratore, è necessario che siano lo stesso nome utente/password in tutti gli vManagenodes.
Passare a Configurazione > Certificati > Controlla componenti nel caso di nodi vManage 20.15/20.18. Nel caso delle versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Fare clic su ... per Manager/vManage e fare clic su Generate CSR.

Una volta generato il CSR, è possibile scaricarlo e firmarlo in base all'autorità di certificazione scelta per i controller. È possibile verificare questa configurazione in Amministrazione > Impostazioni > Autorizzazione certificato controller. Se si sceglie Cisco (scelta consigliata), il CSR viene caricato automaticamente nel portale PNP da vManage e, una volta firmato, il certificato viene installato automaticamente in vManage.
Se si sceglie Manuale, firmare manualmente il CSR utilizzando il portale PNP di Cisco passando allo smart account e all'account virtuale della rispettiva sovrapposizione SD-WAN.
Una volta che il certificato è disponibile dal portale PNP, fare clic su installa certificato nella stessa sezione di vManage, quindi caricare il certificato e installarlo.
La stessa procedura è applicabile se si utilizza un certificato radice Digicert ed Enterprise.
Completare questo passaggio in tutti i nodi vManage che fanno parte del cluster.
Nota: Per un cluster a 3 nodi, tutti e 3 i nodi vManage vengono visualizzati con compute+data come persona.
Configurazione facoltativa:
Fare riferimento a questa configurazione nel cluster esistente per Abilitare SDAVC: deve essere verificata solo se è necessaria ed è necessaria solo su un nodo vManage del cluster.
Fare clic su Aggiorna.



Prima di aggiungere il nodo successivo al cluster, è necessario prendere in considerazione i seguenti punti:
Verificare questi punti in tutte le interfacce utente dei nodi vManage aggiunti al cluster:
È possibile attivare un altro cluster vManage eseguendo la procedura descritta nel passo 4: Creare un cluster vManage. Post che completano i passaggi descritti nel Passaggio 6: Backup/Ripristino config-db per ripristinare il backup config-db nel cluster in standby.
È possibile verificare la stessa condizione utilizzando il comando requestnmsconfiguration-dbstatus in vManageCLI. L'output è il seguente
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
vManage-3# request nms configuration-db diagnostics
NMS configuration database
Checking cluster connectivity for ports 7687,7474 ...
Pinging vManage node 0 on 169.254.1.5:7687,7474...
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2026-02-18 12:41 UTC
SENT (0.0013s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (0.0022s) Handshake with 169.254.1.5:7474 completed
SENT (1.0024s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (1.0028s) Handshake with 169.254.1.5:7687 completed
SENT (2.0044s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (2.0050s) Handshake with 169.254.1.5:7474 completed
SENT (3.0064s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (3.0072s) Handshake with 169.254.1.5:7687 completed
SENT (4.0083s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (4.0091s) Handshake with 169.254.1.5:7474 completed
SENT (5.0106s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (5.0115s) Handshake with 169.254.1.5:7687 completed
Max rtt: 0.906ms | Min rtt: 0.392ms | Avg rtt: 0.724ms
TCP connection attempts: 6 | Successful connections: 6 | Failed: 0 (0.00%)
Nping done: 1 IP address pinged in 5.01 seconds
Pinging vManage node 1 on 169.254.2.5:7687,7474...
========== SNIP ==========
Connecting to 10.10.10.3...
+------------------------------------------------------------------------------------+
| type | row | attributes[row]["value"] |
+------------------------------------------------------------------------------------+
| "StoreSizes" | "TotalStoreSize" | 85828934 |
| "PageCache" | "Flush" | 4268666 |
| "PageCache" | "EvictionExceptions" | 0 |
| "PageCache" | "UsageRatio" | 0.09724264705882353 |
| "PageCache" | "Eviction" | 2068 |
| "PageCache" | "HitRatio" | 1.0 |
| "ID Allocations" | "NumberOfRelationshipIdsInUse" | 2068 |
| "ID Allocations" | "NumberOfPropertyIdsInUse" | 56151 |
| "ID Allocations" | "NumberOfNodeIdsInUse" | 7561 |
| "ID Allocations" | "NumberOfRelationshipTypeIdsInUse" | 31 |
| "Transactions" | "LastCommittedTxId" | 214273 |
| "Transactions" | "NumberOfOpenTransactions" | 1 |
| "Transactions" | "NumberOfOpenedTransactions" | 441742 |
| "Transactions" | "PeakNumberOfConcurrentTransactions" | 11 |
| "Transactions" | "NumberOfCommittedTransactions" | 414568 |
| "Causal Cluster" | "IsLeader" | 1 >>>>>>>>> |
| "Causal Cluster" | "MsgProcessDelay" | 0 |
| "Causal Cluster" | "InFlightCacheTotalBytes" | 0 |
+------------------------------------------------------------------------------------+
18 rows
ready to start consuming query after 388 ms, results consumed after another 13 ms
Completed
Connecting to 10.10.10.3...
Displaying the Neo4j Cluster Status
+---------------------------------------------------------------------------------------------------------------------------------+
| name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
+---------------------------------------------------------------------------------------------------------------------------------+
| "neo4j" | [] | "read-write" | "169.254.3.5:7687" | "leader" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.1.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "system" | [] | "read-write" | "169.254.3.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.1.5:7687" | "leader" | "online" | "online" | "" | FALSE | FALSE |
+---------------------------------------------------------------------------------------------------------------------------------+
6 rows
ready to start consuming query after 256 ms, results consumed after another 3 ms
Completed
Total disk space used by configuration-db:
60M .
Utilizzare questo comando per raccogliere il backup del database di configurazione dal nodo vManage leader del database di configurazione identificato.
request nms configuration-db backup path /opt/data/backup/
L'output previsto è il seguente:
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiare il backup del database di configurazione nella directory /home/admin/ di vManage utilizzando SCP.
Output di esempio del comando scp:
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Per ripristinare il backup del database di configurazione, è necessario innanzitutto configurare le credenziali del database di configurazione. Se le credenziali del database di configurazione sono predefinite (neo4j/password), è possibile ignorare questo passaggio.
Per configurare le credenziali configuration-db, utilizzare il comando request nms configuration-db update-admin-user.Utilizzare il nome utente e la password desiderati.
Notare che il server applicazioni di vManage è stato riavviato. A causa della quale l'interfaccia utente di vManage diventa inaccessibile per un breve periodo.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Post in cui è possibile procedere al ripristino del backup del database di configurazione:
È possibile utilizzare il comando request nms configuration-db restore path /home/admin/< > per ripristinare configuration-db nel nuovo vManage:
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Una volta ripristinato il database di configurazione, verificare che l'interfaccia utente di vManage sia accessibile. Attendere circa 5 minuti e quindi tentare di accedere all'interfaccia utente.
Dopo aver eseguito correttamente il login all'interfaccia utente, verificare che l'elenco dei router perimetrali, il modello, i criteri e tutte le altre configurazioni presenti nell'interfaccia utente vManage precedente o esistente siano riflessi nella nuova interfaccia utente vManage.
Una volta ripristinato il database di configurazione, è necessario riautenticare tutti i nuovi controller (manage/vsmart/vbond) nel fabric
Nota: nella produzione effettiva, se l'IP dell'interfaccia utilizzato per la riautenticazione è l'IP dell'interfaccia del tunnel, è necessario garantire che il servizio NETCONF sia consentito sull'interfaccia del tunnel di vManage, vSmart e vBond e anche sui firewall lungo il percorso. La porta firewall da aprire è la porta TCP 830 come regola bidirezionale dal cluster DR a tutti i vBonds e vSmarts.
Su gestisci interfaccia utente, fare clic su Configurazione > Dispositivi > Controller

Una volta caricati tutti i controller, attenersi a questa procedura:
Su qualsiasi server Cisco SD-WAN Manager nel cluster appena attivo, eseguire le seguenti azioni:
Immettere questo comando per sincronizzare il certificato radice con tutti i dispositivi Cisco Catalyst SD-WAN nel cluster appena attivo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Immettere questo comando per sincronizzare l'UUID di Cisco SD-WAN Manager con Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Una volta ripristinata la struttura e attivate le sessioni bfd e di controllo per tutti i bordi e i controller della struttura, è necessario invalidare i vecchi controller (vmanage/vsmart/vbond) dall'interfaccia utente
Nota: Continuare con la sezione Controlli successivi mostrata qui, che è comune a tutte le combinazioni di distribuzione.
Istanze necessarie:
Passaggi:
Verificare che il numero delle istanze attive di Cisco SD-WAN Manager sia identico al numero delle nuove istanze di Cisco SD-WAN Manager.
Accertarsi che tutte le istanze Cisco SD-WAN Manager attive e nuove eseguano la stessa versione del software.
Verificare che tutte le istanze Cisco SD-WAN Manager nuove e attive siano in grado di raggiungere l'indirizzo IP di gestione di Cisco SD-WAN Validator.
Verificare che i certificati siano stati installati nelle istanze di Cisco SD-WAN Manager appena installate.
Verificare che gli orologi di tutti i dispositivi Cisco Catalyst SD-WAN, incluse le nuove istanze di Cisco SD-WAN Manager installate, siano sincronizzati.
Verificare che nelle istanze di Cisco SD-WAN Manager appena installate sia configurato un nuovo set di IP di sistema e ID di sito, insieme alla stessa configurazione di base del cluster attivo.




Nel caso in cui si utilizzi la propria CA, Autorità di certificazione dell'organizzazione (enterprise), scegliere Enterprise.


Passare a Configurazione > Dispositivi > Controllo componenti nel caso di nodi vManage 20.15/20.18. Nel caso delle versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Nota: è necessario utilizzare le credenziali di amministratore di vBondor una parte utente di netadmingroup. È possibile verificare questa condizione nella CLI di vBond. Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vBond
Nota: Se vBond è dietro un dispositivo/firewall NAT, verificare se l'IP dell'interfaccia VPN 0 di vBond è convertito in un IP pubblico. Se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, in questo passaggio utilizzare l'indirizzo IP pubblico dell'interfaccia VPN 0

Fare clic su Add vSmart in caso di vManage 20.12 o Add Controller in caso di vManage 20.15/20.18.
Viene visualizzato un popup. Immettere l'IP di trasporto VPN 0 di vSmart raggiungibile da vManage.
Verificare la raggiungibilità usando il comando ping, se consentito dalla CLI di vManage a vSmart IP.
Immettere le credenziali utente di vSmart Note che è necessario utilizzare le credenziali di amministratore di vSmart o di un utente appartenente al gruppo netadmin.
È possibile verificare questa condizione nella CLI di vSmart.
Impostare il protocollo su TLS se si intende utilizzare TLS per i router per stabilire connessioni di controllo con vSmart. Questa configurazione deve essere configurata anche sulla CLI dei nodi vSmarts e vManage.
Scegliere Sì nell'elenco a discesa "Generate CSR" se è necessario installare un nuovo certificato per vSmart.
Nota: se vSmart è dietro un dispositivo/firewall NAT, verificare se l'indirizzo IP dell'interfaccia vSmart VPN 0 è convertito in un indirizzo IP pubblico e se l'indirizzo IP dell'interfaccia VPN 0 non è raggiungibile da vManage, utilizzare l'indirizzo IP pubblico dell'indirizzo IP dell'interfaccia VPN 0 in questo passaggio.

Una volta completati tutti i passaggi, verificare che tutti i componenti di controllo siano raggiungibili in Monitor>Dashboard


Nota: il cluster vManage può essere configurato con 3 nodi vManage o 6 nodi vManage a seconda del numero di siti collegati all'infrastruttura SD-WAN
Procedere con i passaggi condivisi in "Controller SD-WAN integrati con un singolo nodo vManage nella sovrapposizione SD-WAN" per avviare prima il fabric SD-WAN con un nodo vManage e incorporare tutti i validatori (vBond) e i controller (vSmart) richiesti.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Nota: se si utilizza URL come indirizzo vBond, verificare di configurare gli indirizzi IP dei server DNS nella configurazione VPN 0 o di risolverli.
Queste configurazioni sono necessarie per abilitare l'interfaccia di trasporto utilizzata per stabilire le connessioni di controllo con i router e gli altri controller.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurare inoltre l'interfaccia di gestione VPN 512 per consentire l'accesso di gestione fuori banda al controller.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configurazione facoltativa:
Conf t
security
control
protocol tls
commit
Configurare l'interfaccia del servizio su tutti i vManagenodes, incluso vManage-1 che è già stato caricato. Questa interfaccia viene utilizzata per la comunicazione del cluster, ovvero la comunicazione tra i vManagenodes nel cluster.
conf t
interface eth2
ip address
no shutdown
commit
Verificare che per l'interfaccia di servizio in tutti i nodi del cluster vManagement venga utilizzata la stessa subnet IP.
È possibile utilizzare le stesse credenziali di amministrazione dei nodi vManage per configurare il cluster vManage. In caso contrario, è possibile configurare una nuova credenziale utente che faccia parte di netadmingroup. Le configurazioni per la configurazione delle nuove credenziali utente sono le seguenti
conf t
system
aaa
user
password
group netadmin
commit
Assicurarsi di configurare le stesse credenziali utente in tutti gli vManagenodeche fanno parte del cluster.Se si decide di utilizzare le credenziali di amministratore, è necessario che siano lo stesso nome utente/password in tutti gli vManagenodes.
Passare a Configurazione > Certificati > Controlla componenti nel caso di nodi vManage 20.15/20.18. Nel caso delle versioni 20.9/20.12, Configurazione > Dispositivi > Controller
Fare clic su ... per Manager/vManage e fare clic su Generate CSR.

Una volta generato il CSR, è possibile scaricarlo e firmarlo in base all'autorità di certificazione scelta per i controller. È possibile verificare questa configurazione in Amministrazione > Impostazioni > Autorizzazione certificato controller. Se si sceglie Cisco (scelta consigliata), il CSR viene caricato automaticamente nel portale PNP da vManage e, una volta firmato, il certificato viene installato automaticamente in vManage.
Se si sceglie Manuale, firmare manualmente il CSR utilizzando il portale PNP di Cisco passando allo smart account e all'account virtuale della rispettiva sovrapposizione SD-WAN.
Una volta che il certificato è disponibile dal portale PNP, fare clic su installa certificato nella stessa sezione di vManage, quindi caricare il certificato e installarlo.
La stessa procedura è applicabile se si utilizza un certificato radice Digicert ed Enterprise.
Completare questo passaggio in tutti i nodi vManage che fanno parte del cluster.
Nota: Per un cluster a 3 nodi, tutti e 3 i nodi vManage vengono visualizzati con compute+data come persona. Per un cluster a 6 nodi, vengono visualizzati 3 nodi vManage con dati di tipo compute+data come utente e 3 nodi vManage come utente.

Configurazione facoltativa:
Fare riferimento a questa configurazione nel cluster esistente per Abilitare SDAVC: deve essere verificata solo se è necessaria ed è necessaria solo su un nodo vManage del cluster.
Fare clic su Aggiorna.



Prima di aggiungere il nodo successivo al cluster, è necessario prendere in considerazione i seguenti punti:
Verificare questi punti in tutte le interfacce utente dei nodi vManage aggiunti al cluster:
Nota: Durante la raccolta del backup del database di configurazione dal cluster vManage esistente in cui è abilitato il ripristino di emergenza, assicurarsi che venga raccolto dopo che il ripristino di emergenza in tale nodo è stato sospeso ed eliminato.
Confermare che non è in corso la replica per il disaster recovery. Selezionare Amministrazione > Disaster Recovery e verificare che lo stato sia Operazione riuscita e non in uno stato transitorio, ad esempio Importazione in sospeso, Esportazione in sospeso o Download in sospeso. Se lo stato non ha esito positivo, contattare Cisco TAC e verificare la corretta replica prima di sospendere il ripristino di emergenza.
Sospendere innanzitutto il ripristino di emergenza e assicurarsi che l'attività sia completata. Eliminare quindi il ripristino di emergenza e verificare che l'attività sia stata completata.

Contattare Cisco TAC per garantire la corretta pulizia del dispositivo di ripristino di emergenza.
È possibile verificare la stessa condizione utilizzando il comando requestnmsconfiguration-dbstatus in vManageCLI. L'output è il seguente
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
vManage-3# request nms configuration-db diagnostics
NMS configuration database
Checking cluster connectivity for ports 7687,7474 ...
Pinging vManage node 0 on 169.254.1.5:7687,7474...
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2026-02-18 12:41 UTC
SENT (0.0013s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (0.0022s) Handshake with 169.254.1.5:7474 completed
SENT (1.0024s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (1.0028s) Handshake with 169.254.1.5:7687 completed
SENT (2.0044s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (2.0050s) Handshake with 169.254.1.5:7474 completed
SENT (3.0064s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (3.0072s) Handshake with 169.254.1.5:7687 completed
SENT (4.0083s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (4.0091s) Handshake with 169.254.1.5:7474 completed
SENT (5.0106s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (5.0115s) Handshake with 169.254.1.5:7687 completed
Max rtt: 0.906ms | Min rtt: 0.392ms | Avg rtt: 0.724ms
TCP connection attempts: 6 | Successful connections: 6 | Failed: 0 (0.00%)
Nping done: 1 IP address pinged in 5.01 seconds
Pinging vManage node 1 on 169.254.2.5:7687,7474...
========== SNIP ==========
Connecting to 10.10.10.3...
+------------------------------------------------------------------------------------+
| type | row | attributes[row]["value"] |
+------------------------------------------------------------------------------------+
| "StoreSizes" | "TotalStoreSize" | 85828934 |
| "PageCache" | "Flush" | 4268666 |
| "PageCache" | "EvictionExceptions" | 0 |
| "PageCache" | "UsageRatio" | 0.09724264705882353 |
| "PageCache" | "Eviction" | 2068 |
| "PageCache" | "HitRatio" | 1.0 |
| "ID Allocations" | "NumberOfRelationshipIdsInUse" | 2068 |
| "ID Allocations" | "NumberOfPropertyIdsInUse" | 56151 |
| "ID Allocations" | "NumberOfNodeIdsInUse" | 7561 |
| "ID Allocations" | "NumberOfRelationshipTypeIdsInUse" | 31 |
| "Transactions" | "LastCommittedTxId" | 214273 |
| "Transactions" | "NumberOfOpenTransactions" | 1 |
| "Transactions" | "NumberOfOpenedTransactions" | 441742 |
| "Transactions" | "PeakNumberOfConcurrentTransactions" | 11 |
| "Transactions" | "NumberOfCommittedTransactions" | 414568 |
| "Causal Cluster" | "IsLeader" | 1 >>>>>>>>> |
| "Causal Cluster" | "MsgProcessDelay" | 0 |
| "Causal Cluster" | "InFlightCacheTotalBytes" | 0 |
+------------------------------------------------------------------------------------+
18 rows
ready to start consuming query after 388 ms, results consumed after another 13 ms
Completed
Connecting to 10.10.10.3...
Displaying the Neo4j Cluster Status
+---------------------------------------------------------------------------------------------------------------------------------+
| name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
+---------------------------------------------------------------------------------------------------------------------------------+
| "neo4j" | [] | "read-write" | "169.254.3.5:7687" | "leader" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.1.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "system" | [] | "read-write" | "169.254.3.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.1.5:7687" | "leader" | "online" | "online" | "" | FALSE | FALSE |
+---------------------------------------------------------------------------------------------------------------------------------+
6 rows
ready to start consuming query after 256 ms, results consumed after another 3 ms
Completed
Total disk space used by configuration-db:
60M .
Utilizzare questo comando per raccogliere il backup del database di configurazione dal nodo vManage leader del database di configurazione identificato.
request nms configuration-db backup path /opt/data/backup/
L'output previsto è il seguente:
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiare il backup del database di configurazione nella directory /home/admin/ di vManage utilizzando SCP.
Output di esempio del comando scp:
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Per ripristinare il backup del database di configurazione, è necessario innanzitutto configurare le credenziali del database di configurazione. Se le credenziali del database di configurazione sono predefinite (neo4j/password), è possibile ignorare questo passaggio.
Per configurare le credenziali configuration-db, utilizzare il comando request nms configuration-db update-admin-user.Utilizzare il nome utente e la password desiderati.
Notare che il server applicazioni di vManage è stato riavviato. A causa della quale l'interfaccia utente di vManage diventa inaccessibile per un breve periodo.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Post in cui è possibile procedere al ripristino del backup del database di configurazione:
È possibile utilizzare il comando request nms configuration-db restore path /home/admin/< > per ripristinare configuration-db nel nuovo vManage:
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Una volta ripristinato il database di configurazione, verificare che l'interfaccia utente di vManage sia accessibile. Attendere circa 5 minuti e quindi tentare di accedere all'interfaccia utente.
Dopo aver eseguito correttamente il login all'interfaccia utente, verificare che l'elenco dei router perimetrali, il modello, i criteri e tutte le altre configurazioni presenti nell'interfaccia utente vManage precedente o esistente siano riflessi nella nuova interfaccia utente vManage.
Controlli preliminari importanti
Per procedere con il ripristino di emergenza, è necessario configurare e utilizzare due cluster vManage a 3 nodi separati. Nel cluster attivo è necessario che le convalide e i controller siano integrati. Nel caso in cui si disponga di validator e controller sul sito DR, è necessario che questi siano installati anche sul cluster attivo e non sul cluster DR vManage.
Cisco consiglia di soddisfare i seguenti requisiti prima di registrare il disaster recovery:
Configurazioni
Per ulteriori informazioni su vManage Disaster Recovery, fare riferimento a questo collegamento.
I due cluster a 3 nodi separati sono già stati creati, presupponendo che ciascun gestore SD-WAN disponga della configurazione minima e che la parte di certificazione sia stata completata.
Passare a Amministrazione > Gestione cluster in entrambi i cluster e verificare che tutti i nodi siano in stato Pronto.
DC vManage

DR Manage

Passare a Amministrazione>Ripristino di emergenza del cluster vManage principale. Fare clic su Gestione ripristino di emergenza.

Nella finestra popup, immettere i dettagli per vManage principale e secondario.
Gli indirizzi IP da indicare sono gli indirizzi IP delle interfacce cluster fuori banda. È preferibile utilizzare l'indirizzo IP dell'interfaccia di servizio VPN 0 di vManage-1 in ogni cluster.
Le credenziali devono essere quelle di un utente netadmin e non devono essere modificate una volta configurato il DR, a meno che non venga eliminato. È possibile utilizzare una credenziale utente locale vManage separata per il ripristino di emergenza. È necessario verificare che l'utente locale vManage faccia parte del gruppo netadmin. È possibile utilizzare anche le credenziali di amministratore.

Una volta completate le impostazioni, fare clic su Avanti.
I controller vBond devono essere raggiungibili nell'indirizzo IP specificato tramite Netconf.

Una volta completate le impostazioni, fare clic su Avanti.


Impostare il valore e fare clic su Salva.

Verifica
Passare a Amministrazione>Disaster Recovery per verificare lo stato di Disaster Recovery e la data dell'ultima replica dei dati.

Nota: La replica può richiedere diverse ore a seconda delle dimensioni del database. Inoltre, può richiedere alcuni cicli per ottenere una replica corretta.
Una volta ripristinato il database di configurazione, è necessario riautenticare tutti i nuovi controller (manage/vsmart/vbond) nel fabric
Nota: nella produzione effettiva, se l'IP dell'interfaccia utilizzato per la riautenticazione è l'IP dell'interfaccia del tunnel, è necessario garantire che il servizio NETCONF sia consentito sull'interfaccia del tunnel di vManage, vSmart e vBond e anche sui firewall lungo il percorso. La porta firewall da aprire è la porta TCP 830 come regola bidirezionale dal cluster DR a tutti i vBonds e vSmarts.
Su gestisci interfaccia utente, fare clic su Configurazione > Dispositivi > Controller

Una volta caricati tutti i controller, attenersi a questa procedura:
Su qualsiasi server Cisco SD-WAN Manager nel cluster appena attivo, eseguire le seguenti azioni:
Immettere questo comando per sincronizzare il certificato radice con tutti i dispositivi Cisco Catalyst SD-WAN nel cluster appena attivo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Immettere questo comando per sincronizzare l'UUID di Cisco SD-WAN Manager con Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Una volta ripristinata la struttura e attivate le sessioni bfd e di controllo per tutti i bordi e i controller della struttura, è necessario invalidare i vecchi controller (vmanage/vsmart/vbond) dall'interfaccia utente
Questi controlli successivi si applicano a tutte le combinazioni di distribuzione.
request platform software sdwan vedge_cloud activate chassis-number token
Verificare che gli elementi vengano visualizzati come previsto:
Modelli
Politiche
Pagina Dispositivo (entrambe le schede)WAN vEdge ListandController
Applicabile per i nodi vManage:
Controlli di Configuration-DB(Neo4j):
Eseguire il comando "request nms configuration-db diagnostics" su tutti i nodi vManage:
1. Verificare lo stato online e di leadership del nodo (non disponibile per tutte le versioni):
"Neo4j" deve mostrare 3 nodi online e 1 leader e 2 follower. "system" deve anche mostrare 3 nodi online e 1 leader e 2 follower, tuttavia, poiché questo non è il Db predefinito, il flag predefinito è false. Se in ogni neo4j sono presenti meno di 3 voci e il sistema significa che il nodo è stato disattivato dal cluster. Per risolvere lo stesso problema, contattare Cisco TAC.
2. Verificare se un nodo è in "quarantena".

Nessuno dei nodi deve essere in stato di quarantena.
3. La convalida dello schema deve avere esito positivo.

4. Raccogliere un backup di configuration-db utilizzando il comando "request nms configuration-db diagnostics" e assicurarsi che abbia esito positivo.

In caso di incoerenze o errori, rivolgersi a Cisco TAC per la risoluzione dei problemi.
In alternativa, è possibile eseguire queste chiamate API per confermare lo stato di gestione del nodo per un cluster (per tutti i nodi COMPUTE+DATA). Funziona solo nella versione 20.12 e successive
go to vshell of the vmanage node ( to be done on all vmanages)
===============================================================
curl -u : -H "Content-Type: application/json" -d '{"statements":[{"statement":"call dbms.cluster.overview"}]}' http://:7474/db/neo4j/tx/commit | jq -r
curl -u : -H "Content-Type: application/json" -d '{"statements":[{"statement":"show databases"}]}' http://:7474/db/neo4j/tx/commit | jq -r Assicurarsi che in un cluster sia presente un solo leader sia per neo4j che per system e rest come follower. Assicurarsi che tutti i nodi siano online. Se si dispone di un cluster a 3 nodi (tutti e tre sono COMPUTE+DATA), deve esistere un solo leader sia per neo4j che per system. Qualsiasi deviazione, è necessario contattare TAC
5. Verificare se in /var/log/kern.log si sono verificati errori di I/O, Mem e del disco. È necessario controllare questa impostazione su tutti i nodi vManage.
6.Controllare la fase quando si crea un nuovo cluster per vmanage che non dispone di CC tra ciascun nodo
Eseguire ssh come manage-admin dal nodo 1 agli altri nodi IP del cluster e viceversa, per verificare se la chiave pubblica è stata scambiata e se il protocollo ssh senza password funziona [il token di consenso è richiesto per i passaggi illustrati]
DR-vManage-1:~# ssh -i /etc/viptela/.ssh/id_dsa -p 830 vmanage-admin@
The authenticity of host '[192.168.50.5]:830 ([192.168.50.5]:830)' can't be established.
ECDSA key fingerprint is SHA256:rSpscoYCVC+yifUMHVTlxtjqmyrZSFg93msFdoSUieQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[192.168.50.5]:830' (ECDSA) to the list of known hosts.
viptela 20.9.3.0.31
Password:
Se il risultato chiede di immettere la password, contattare TAC
Applicabile a tutti i controller SD-WAN (vBond, vManage, vSmart):
Eseguire i comandi su tutti i controller nella sovrapposizione e verificare che l'UUID vManage e i numeri di serie rilevati siano validi per l'infrastruttura corrente:
Comandi vBond:
show orchestrator valid-vsmarts
show orchestrator valid-manage-id
Comandi vManage/vSmart:
show control valid-vsmarts
show control valid-manage-id
Si noti l'output di show control valid-vsmarts include i numeri di serie dei nodi vSmarts e vManage.
Confrontare questo valore con quelli visualizzati nell'interfaccia utente di vManage. Passare alla sezione Configurazione > Certificati > Controller.
Se vengono rilevate voci aggiuntive per l'UUID o il numero di serie che non sono attualmente presenti nell'infrastruttura, è necessario eliminarle. A tal fine, è possibile contattare Cisco TAC.
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
25-Feb-2026
|
Versione iniziale |
Feedback