Este documento descreve como reconstruir uma estrutura Cisco SD-WAN, incluindo backup e restauração de configurações do controlador para várias implantações.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Implantação do vManage
Opções de DR
Note: Para obter mais detalhes sobre o tipo de recuperação de desastres, consulte este link
Combinações:
| # | Configuração do vManage | Opção DR |
|---|---|---|
| 1 | Autônomo (1 nó) | Sem DR |
| 2 | Autônomo (1 nó) | DR de nó único |
| 3 | Cluster (3 ou 6 nós) | Sem DR |
| 4 | Cluster (3 ou 6 nós) | Cluster de DR em standby |
Essas etapas são comuns a todas as combinações de implantação. Eles abordam o processo de ativar instâncias de VM e aplicar a configuração CLI básica. Cada seção de combinação informa quantas instâncias devem ser implantadas e quais etapas adicionais devem ser concluídas.
Note: A Cisco renomeou determinados termos, de modo que esses termos são intercambiáveis. Cisco vManage = Cisco Catalyst Manager, Cisco vBond = Cisco Catalyst Validator, Cisco vSmart = Cisco Catalyst Controller
Faça o download dos arquivos OVA para controladores SD-WAN da página de download do software Cisco aqui:
Note: Nas plataformas ESXi/cloud, ative os controladores vSmart, vBond e vManage usando o arquivo OVA. Consulte o documento vinculado e certifique-se de que CPU, RAM e discos suficientes estejam alocados para todos os controladores, dependendo do tipo de implantação da SD-WAN. Navegue aqui para obter informações adicionais. Certifique-se de atribuir um disco secundário ao nó vManage conforme mencionado na coluna Tamanho de armazenamento* no guia de computação vinculado.
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.
Exemplo:Escolha 1 para COMPUTE_AND_DATA

Escolha o disco secundário conforme mostrado:


Exemplo
Note: Você pode consultar a configuração do vManage existente e configurar o mesmo esquema de endereço IP aqui.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address <IP-address/mask>
no shutdown
!
ip route 0.0.0.0/0 <default-gateway IP>
!
Exemplo:
Note: Você pode consultar a configuração do vBond existente e configurar as mesmas configurações aqui.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address <IP-address/mask>
no shutdown
!
ip route 0.0.0.0/0 <default-gateway IP>
!
commit
Quando você tiver acesso SSH a todos os controladores, configure essas configurações CLI em cada controlador.
config t
system
host-name <hostname>
system-ip <unique system-IP>
site-id <site-id>
organization-name <organization name>
vbond <IP address/URL of vBond>
commit
Observação: se estamos usando URL como endereço vBond, certifique-se de configurar os endereços IP do servidor DNS na configuração VPN 0 ou de garantir que eles possam ser resolvidos.
Essas configurações são necessárias em todos os controladores para ativar a interface de transporte usada para estabelecer conexões de controle com os roteadores e o restante dos controladores.
config t
vpn 0
dns <IP-address> primary
dns <IP-address> secondary
interface eth1
ip address <IP-address/mask>
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 <default-gateway IP>
commit
Observação: você pode consultar as configurações da sua controladora existente e, se a configuração estiver presente, poderá adicioná-la às novas controladoras.
Configure o protocolo de controle como TLS somente se houver um requisito para que os roteadores estabeleçam conexões de controle seguras com os nós do vManage usando TLS. Por padrão, todos os controladores e roteadores estabelecem conexões de controle usando DTLS. Essa é uma configuração opcional necessária apenas nos nós vSmart e vManage, dependendo de sua necessidade.
Conf t
security
control
protocol tls
Commit
Certifique-se de que o número de instâncias ativas do Cisco SD-WAN Manager seja idêntico ao número de instâncias recém-instaladas do Cisco SD-WAN Manager .
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager executem a mesma versão de software.
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager possam acessar o endereço IP de gerenciamento do Cisco SD-WAN Validator.
Verifique se os certificados foram instalados nas instâncias recém-instaladas do Cisco SD-WAN Manager.
Certifique-se de que os relógios em todos os dispositivos Cisco Catalyst SD-WAN, incluindo as instâncias recém-instaladas do Cisco SD-WAN Manager, estejam sincronizados.
Verifique se um novo conjunto de IPs do sistema e IDs do local está configurado nas instâncias do Cisco SD-WAN Manager recém-instalado, juntamente com a mesma configuração básica do cluster ativo.



Caso estejamos usando nossa própria CA, autoridade de certificação empresarial, escolha Empresa.

Navegue para Configuration > Devices > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Observação: precisamos usar credenciais de administrador do vBond ou uma parte do usuário do netadmin grupo. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para o vBond.
Note: Se o vBond estiver por trás de um dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vBond está traduzido para um IP público. Se o IP da interface VPN 0 não estiver acessível no vManage, use o endereço IP público da interface VPN 0 nesta etapa.
Clique em Add vSmart no caso do vManage 20.12 ou Add Controller no caso do vManage 20.15/20.18.
Um pop-up é aberto, insira o IP de transporte VPN 0 do vSmart que pode ser acessado no vManage.
Verifique a acessibilidade usando ping se permitido do CLI do vManage para o vSmart IP.
Insira as credenciais de usuário do vSmart. Observe que precisamos usar credenciais de administrador do vSmart ou uma parte do usuário do grupo netadmin.
Você pode verificar isso na CLI do vSmart.
Defina o protocolo como TLS, se pretendemos usar TLS para roteadores para estabelecer conexões de controle com vSmart. Essa configuração também precisa ser configurada na CLI dos nós vSmarts e vManage.
Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para vSmart.
Observação: se o vSmart estiver por trás do dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vSmart está convertido em um IP público e se o IP da interface VPN 0 não pode ser acessado do vManage, use o endereço IP público do IP da interface VPN 0 nesta etapa.
Após concluir todas as etapas, verifique se todos os componentes de controle estão acessíveis no Monitor > Painel

Você pode verificar o mesmo usando o comando request nms configuration-db status na CLI vManage. A saída é a mostrada
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#
Use esse comando para coletar o backup configuration-db do nó vManage líder configuration-db identificado.
request nms configuration-db backup path /opt/data/backup/<filename>
A saída esperada é a seguinte:
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#
Copie o backup do configuration-db para o diretório /home/admin/ do vManage usando SCP.
Exemplo de saída do 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 -
Para restaurar o backup do configuration-db, primeiro precisamos configurar as credenciais do configuration-db. Se suas credenciais de configuração-db forem default (neo4j/password), podemos pular esta etapa.
Para configurar as credenciais do configuration-db, use o comando request nms configuration-db update-admin-user. Use o nome de usuário e a senha de sua escolha.
Observe que o servidor de aplicativos do vManage é reiniciado. Devido ao qual a interface do usuário do vManage fica inacessível por um curto período.
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 que podemos continuar para restaurar o backup do configuration-db:
Podemos usar o comando request nms configuration-db restore path /home/admin/< > para restaurar o configuration-db para o novo 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
Depois que o configuration-db for restaurado, verifique se a interface do usuário do vManage está acessível. Aguarde cerca de 5 minutos e tente acessar a interface do usuário.
Depois de fazer logon na interface do usuário com êxito, verifique se a lista de roteadores de borda, o modelo, as políticas e todas as configurações presentes na interface do usuário do vManage anterior ou existente estão refletidas na nova interface do usuário do vManage.
Caution: O configuration-db restaurado ainda contém o(s) gerenciador(es) de SD-WAN do(s) qual(is) o backup foi retirado. Eles estão listados como entradas do gerente em Configuração > Certificados > Componentes de controle (20.9/20.12: Configuration > Certificates > Controllers), mas não são membros de Administration > Cluster Management. Até que sejam removidos na Etapa 4:
Não execute nenhuma operação de certificado do controlador ou Enviar para o validador neste vManage até que a Etapa 4 seja concluída. Se a instalação de um certificado falhar, não instale o mesmo certificado da CLI; Entre em contato com o Cisco TAC.
Depois que o configuration-db for restaurado, precisamos autenticar novamente todos os novos controladores (vmanage/vsmart/vbond) na malha.
Observação: na produção real, se o IP da interface usado para reautenticar for o IP da interface do túnel, será necessário garantir que o serviço NETCONF seja permitido na interface do túnel do vManage, vSmart e vBond e também nos firewalls ao longo do caminho. A porta de firewall a ser aberta é a porta TCP 830 como regra bidirecional do cluster DR para todos os vBonds e vSmarts.
Na interface do usuário do vmanage, clique em Configuration > Devices > Controllers


Depois que todos os controladores estiverem integrados, conclua esta etapa:
Em qualquer servidor Cisco SD-WAN Manager no cluster recém-ativo, execute estas ações:
Digite este comando para sincronizar o certificado raiz com todos os dispositivos Cisco Catalyst SD-WAN no cluster recém-ativo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Digite este comando para sincronizar o UUID do Cisco SD-WAN Manager com o Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Faça isso logo após a sincronização da cadeia de certificados raiz e antes de qualquer operação de certificado do controlador ou Enviar para o validador.
Invalidating Root Certificate Autority of vManage-<uuid>
Sending serial number of vManage-<uuid> as invalid to all controllers
Failed to push serial list to vManage-<uuid> - retry in 30 seconds; Failed to find Vmanage Cluster node for uuid <uuid> (x3)
Updated serial list will be sent to vManage-<uuid> when it is reachable
Clearing certificate on vManage-<uuid>
Successfully invalidated vManage-<uuid>
A entrada agora mostra Nenhum certificado instalado. O número de série e a CA raiz do SD-WAN Manager anterior são removidos dos validadores.
Quando a estrutura for restaurada e as sessões de controle e BFD estiverem ativas para todas as bordas e controladores na estrutura, invalide as entradas vBond/Validator e vSmart/Controller antigas da interface do usuário:
Note: Continue com a seção Post Checks mostrada aqui, que é comum a todas as combinações de implantação.
Certifique-se de que o número de instâncias ativas do Cisco SD-WAN Manager seja idêntico ao número de instâncias recém-instaladas do Cisco SD-WAN Manager .
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager executem a mesma versão de software.
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager possam acessar o endereço IP de gerenciamento do Cisco SD-WAN Validator.
Verifique se os certificados foram instalados nas instâncias recém-instaladas do Cisco SD-WAN Manager.
Certifique-se de que os relógios em todos os dispositivos Cisco Catalyst SD-WAN, incluindo as instâncias recém-instaladas do Cisco SD-WAN Manager, estejam sincronizados.
Verifique se um novo conjunto de IPs do sistema e IDs do local está configurado nas instâncias do Cisco SD-WAN Manager recém-instalado, juntamente com a mesma configuração básica do cluster ativo.

Caso estejamos usando nossa própria CA, autoridade de certificação empresarial, escolha Empresa.
Navegue para Configuration > Devices > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Observação: precisamos usar credenciais de administrador do vBond ou uma parte do usuário do netadmin grupo. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para o vBond
Note: Se o vBond estiver por trás de um dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vBond está traduzido para um IP público. Se o IP da interface VPN 0 não estiver acessível no vManage, use o endereço IP público da interface VPN 0 nesta etapa
Clique em Add vSmart no caso do vManage 20.12 ou Add Controller no caso do vManage 20.15/20.18.
Um pop-up é aberto, insira o IP de transporte VPN 0 do vSmart que pode ser acessado no vManage.
Verifique a acessibilidade usando ping se permitido do CLI do vManage para o vSmart IP.
Insira as credenciais de usuário do vSmart. Observe que precisamos usar credenciais de administrador do vSmart ou uma parte do usuário do grupo netadmin.
Você pode verificar isso na CLI do vSmart.
Defina o protocolo como TLS, se pretendemos usar TLS para roteadores para estabelecer conexões de controle com vSmart. Essa configuração também precisa ser configurada na CLI dos nós vSmarts e vManage.
Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para vSmart.
Observação: se o vSmart estiver por trás do dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vSmart está convertido em um IP público e se o IP da interface VPN 0 não pode ser acessado do vManage, use o endereço IP público do IP da interface VPN 0 nesta etapa.
Após concluir todas as etapas, verifique se todos os componentes de controle estão acessíveis no Monitor > Painel
Note: Ao coletar o backup do banco de dados de configuração do nó vManage existente que tem a recuperação de desastres ativada, certifique-se de que ele seja coletado após a recuperação de desastres nesse nó ser pausada e excluída.
Confirme se não há replicação de recuperação de desastres em andamento. Navegue até Administração > Recuperação de desastres e verifique o status Sucesso e não em um estado transitório, como Importação pendente, Exportação pendente ou Download pendente. Se o status não for sucesso, entre em contato com o Cisco TAC e certifique-se de que a replicação seja bem-sucedida antes de continuar a pausar a recuperação de desastres.
Primeiro, pause a recuperação de desastres e certifique-se de que a tarefa esteja concluída. Em seguida, exclua a recuperação de desastre e confirme se a tarefa foi concluída.

Entre em contato com o Cisco TAC para garantir que a recuperação de desastres seja limpa com êxito.
Você pode verificar o mesmo usando o comando request nms configuration-db status na CLI vManage . A saída é a mostrada
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#
Use esse comando para coletar o backup configuration-db do nó vManage líder configuration-db identificado.
request nms configuration-db backup path /opt/data/backup/<filename>
A saída esperada é a seguinte:
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#
Copie o backup do configuration-db para o diretório /home/admin/ do vManage usando SCP.
Exemplo de saída do 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 -
Para restaurar o backup do configuration-db, primeiro precisamos configurar as credenciais do configuration-db. Se suas credenciais de configuração-db forem default (neo4j/password), podemos pular esta etapa.
Para configurar as credenciais do configuration-db, use o comando request nms configuration-db update-admin-user. Use o nome de usuário e a senha de sua escolha.
Observe que o servidor de aplicativos do vManage é reiniciado. Devido ao qual a interface do usuário do vManage fica inacessível por um curto período.
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 que podemos continuar para restaurar o backup do configuration-db:
Podemos usar o comando request nms configuration-db restore path /home/admin/< > para restaurar o configuration-db para o novo 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
Depois que o configuration-db for restaurado, verifique se a interface do usuário do vManage está acessível. Aguarde cerca de 5 minutos e tente acessar a interface do usuário.
Depois de fazer logon na interface do usuário com êxito, verifique se a lista de roteadores de borda, o modelo, as políticas e todas as configurações presentes na interface do usuário do vManage anterior ou existente estão refletidas na nova interface do usuário do vManage.
Caution: O configuration-db restaurado ainda contém o(s) gerenciador(es) de SD-WAN do(s) qual(is) o backup foi retirado. Eles estão listados como entradas do gerente em Configuração > Certificados > Componentes de controle (20.9/20.12: Configuration > Certificates > Controllers), mas não são membros de Administration > Cluster Management. Até que sejam removidos na Etapa 5:
Não execute nenhuma operação de certificado do controlador ou Enviar para o validador neste vManage até que a Etapa 5 seja concluída. Se a instalação de um certificado falhar, não instale o mesmo certificado da CLI; Entre em contato com o Cisco TAC.
Consulte a Etapa 2: Pré-verificações na Combinação 2: vManage autônomo + DR de nó único e certifique-se de que cumprimos todos os requisitos antes de continuar a habilitar a recuperação de desastres.
Interface de cluster fora de banda na VPN 0
A configuração mínima básica do vManage antes do registro da Recuperação de desastres é como mostrado
config t
system
host-name <hostname>
system-ip <unique system-ip>
site-id <site-id>
organization-name <organization name>
vbond <IP address/URL of vBond>
commit
Observação: se estamos usando URL como endereço vBond, certifique-se de configurar os endereços IP do servidor DNS na configuração VPN 0 ou de garantir que eles possam ser resolvidos.
Essas configurações são necessárias para ativar a interface de transporte usada para estabelecer conexões de controle com os roteadores e o restante dos controladores
config t
vpn 0
dns <IP-address> primary
dns <IP-address> secondary
interface eth1
ip address <IP-address/mask>
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 <default-gateway IP>
commit
Configure também a interface de gerenciamento do VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address <IP-address/mask>
no shutdown
!
ip route 0.0.0.0/0 <default-gateway IP>
!
commit
Configure a interface de serviço no nó do vManage. Essa interface é usada para comunicação DR,
conf t
interface eth2
ip address <IP-address/mask>
no shutdown
commit
Certifique-se de que a mesma sub-rede IP seja usada para a interface de serviço no vManage primário e no DR vManage
Continue com os passos dados na seção Combinação 2: vManage independente + DR de nó único Etapa 2: Configure a interface do usuário do vManage, certificados e controladores integrados para instalar o certificado no vManage de recuperação de desastres.
Depois de preenchido, clique em "Avançar".
Preencha os detalhes dos controladores vBond.
Os controladores vBond devem estar acessíveis no endereço IP especificado via Netconf.
As credenciais devem ser as de um usuário do netadmin (dradmin) e não devem ser alteradas após a configuração do DR.
Para isso, recomenda-se que o vBond tenha esse usuário dradmin configurado localmente ou você pode usar o usuário admin para adicionar o vBond.

Na Programação de Replicação, defina o ‘Intervalo de Replicação’. A cada intervalo de replicação, os dados são replicados do vManage primário para o vManage secundário. O valor mínimo configurável é de 15 minutos.

Observe que a GUI do vManage é reiniciada durante esse processo.
Uma vez concluído, o status Success deve ser visto.

Navegue até Administração → Recuperação de desastres para ver o status da Recuperação de desastres e quando os dados foram replicados pela última vez.

Depois que o configuration-db for restaurado, precisamos autenticar novamente todos os novos controladores (vmanage/vsmart/vbond) na malha
Observação: na produção real, se o IP da interface usado para reautenticar for o IP da interface do túnel, será necessário garantir que o serviço NETCONF seja permitido na interface do túnel do vManage, vSmart e vBond e também nos firewalls ao longo do caminho. A porta de firewall a ser aberta é a porta TCP 830 como regra bidirecional do cluster DR para todos os vBonds e vSmarts .
Na interface de usuário do vmanage,vclique em Configuration > Devices > Controllers

Depois que todos os controladores estiverem integrados, conclua esta etapa:
Em qualquer servidor Cisco SD-WAN Manager no cluster recém-ativo, execute estas ações:
Digite este comando para sincronizar o certificado raiz com todos os dispositivos Cisco Catalyst SD-WAN no cluster recém-ativo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Digite este comando para sincronizar o UUID do Cisco SD-WAN Manager com o Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Faça isso logo após a sincronização da cadeia de certificados raiz e antes de qualquer operação de certificado do controlador ou Enviar para o validador.
Invalidating Root Certificate Autority of vManage-<uuid>
Sending serial number of vManage-<uuid> as invalid to all controllers
Failed to push serial list to vManage-<uuid> - retry in 30 seconds; Failed to find Vmanage Cluster node for uuid <uuid> (x3)
Updated serial list will be sent to vManage-<uuid> when it is reachable
Clearing certificate on vManage-<uuid>
Successfully invalidated vManage-<uuid>
A entrada agora mostra Nenhum certificado instalado. O número de série e a CA raiz do SD-WAN Manager anterior são removidos dos validadores.
Quando a estrutura for restaurada e as sessões de controle e BFD estiverem ativas para todas as bordas e controladores na estrutura, invalide as entradas vBond/Validator e vSmart/Controller antigas da interface do usuário:
Note: Continue com a seção Post Checks mostrada aqui, que é comum a todas as combinações de implantação.
Instâncias necessárias:
Etapas:
Certifique-se de que o número de instâncias ativas do Cisco SD-WAN Manager seja idêntico ao número de instâncias recém-instaladas do Cisco SD-WAN Manager .
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager executem a mesma versão de software.
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager possam acessar o endereço IP de gerenciamento do Cisco SD-WAN Validator.
Verifique se os certificados foram instalados nas instâncias recém-instaladas do Cisco SD-WAN Manager.
Certifique-se de que os relógios em todos os dispositivos Cisco Catalyst SD-WAN, incluindo as instâncias recém-instaladas do Cisco SD-WAN Manager, estejam sincronizados.
Verifique se um novo conjunto de IPs do sistema e IDs do local está configurado nas instâncias do Cisco SD-WAN Manager recém-instalado, juntamente com a mesma configuração básica do cluster ativo.

Caso estejamos usando nossa própria CA, autoridade de certificação empresarial, escolha Empresa.

Navegue para Configuration > Devices > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Observação: precisamos usar credenciais de administrador do vBond ou uma parte do usuário do netadmin grupo. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para o vBond
Note: Se o vBond estiver por trás de um dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vBond está traduzido para um IP público. Se o IP da interface VPN 0 não estiver acessível no vManage, use o endereço IP público da interface VPN 0 nesta etapa
Clique em Add vSmart no caso do vManage 20.12 ou Add Controller no caso do vManage 20.15/20.18.
Um pop-up é aberto, insira o IP de transporte VPN 0 do vSmart que pode ser acessado no vManage.
Verifique a acessibilidade usando ping se permitido do CLI do vManage para o vSmart IP.
Insira as credenciais de usuário do vSmart. Observe que precisamos usar credenciais de administrador do vSmart ou uma parte do usuário do grupo netadmin.
Você pode verificar isso na CLI do vSmart.
Defina o protocolo como TLS, se pretendemos usar TLS para roteadores para estabelecer conexões de controle com vSmart. Essa configuração também precisa ser configurada na CLI dos nós vSmarts e vManage.
Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para vSmart.
Observação: se o vSmart estiver por trás do dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vSmart está convertido em um IP público e se o IP da interface VPN 0 não pode ser acessado do vManage, use o endereço IP público do IP da interface VPN 0 nesta etapa.
Após concluir todas as etapas, verifique se todos os componentes de controle estão acessíveis no Monitor > Painel


Observação: o vManage Cluster pode ser configurado com 3 nós do vManage ou 6 nós do vManage, dependendo do número de locais integrados à malha SD-WAN. Consulte seu cluster vManage existente e escolha o número de nós de acordo com o mesmo.
config t
system
host-name <hostname>
system-ip <unique system-ip>
site-id <site-id>
organization-name <organization name>
vbond <IP address/URL of vBond>
commit
Observação: se estamos usando URL como endereço vBond, certifique-se de configurar os endereços IP do servidor DNS na configuração VPN 0 ou de garantir que eles possam ser resolvidos.
Essas configurações são necessárias para ativar a interface de transporte usada para estabelecer conexões de controle com os roteadores e o restante dos controladores.
config t
vpn 0
dns <IP-address> primary
dns <IP-address> secondary
interface eth1
ip address <IP-address/mask>
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 <default-gateway IP>
commit
Configure também a interface de gerenciamento do VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address <IP-address/mask>
no shutdown
!
ip route 0.0.0.0/0 <default-gateway IP>
!
Commit
Configuração opcional:
Conf t
security
control
protocol tls
commit
Configure a interface de serviço em todos os nós do vManage, incluindo o vManage-1, que já foi integrado. Essa interface é usada para comunicação de cluster, o que significa comunicação entre os nós vManage no cluster.
conf t
interface eth2
ip address <IP-address/mask>
no shutdown
commit
Certifique-se de que a mesma sub-rede IP seja usada para a interface de serviço em todos os nós no cluster vManage.
Podemos usar as mesmas credenciais de administrador dos nós vManage para configurar o cluster vManage. Caso contrário, podemos configurar uma nova credencial de usuário que faça parte do grupo netadmin. As configurações para configurar a credencial do novo usuário são as mostradas
conf t
system
aaa
user <username>
password <password>
group netadmin
commit
Certifique-se de configurar as mesmas credenciais de usuário em todos os nós do vManage que fazem parte do cluster. Se decidirmos usar credenciais de administrador, ele deverá ser o mesmo nome de usuário/senha em todos os nós do vManage .
Navegue para Configuration > Certificates > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Clique em ... para Gerente/vManage e clique em Gerar CSR.

Depois que o CSR for gerado, você poderá fazer o download do CSR e obtê-lo assinado com base na autoridade de certificado escolhida para os controladores. Você pode verificar essa configuração em Administration > Settings > Controller Certificate Authorization. Se Cisco (recomendado) for escolhido, o CSR será automaticamente carregado no portal PNP pelo vManage e, uma vez assinado o certificado, ele será instalado no vManage automaticamente.
Se Manual for escolhido, assine manualmente o CSR usando o portal PNP da Cisco navegando até a Smart Account e a Virtual Account da respectiva sobreposição SD-WAN. O mesmo procedimento será aplicável se estivermos usando Digicert e Enterprise Root Certificate.
Quando o certificado estiver disponível no portal PNP, clique em instalar certificado na mesma seção do vManage, carregue o certificado e instale-o.
Conclua esta etapa em todos os nós do vManage que fazem parte do cluster.
Note: Para um cluster de 3 nós, todos os 3 nós do vManage são ativados com computação+dados como persona.

Note: Consulte essa configuração no cluster existente para Habilitar SDAVC - Só precisa ser verificado se for necessário e só é necessário em um nó vManage do cluster.
Clique em Atualizar.




Esses pontos precisam ser levados em consideração antes de adicionar o próximo nó ao cluster:
Verifique esses pontos em todas as IUs dos nós do vManage que foram adicionados ao cluster até o momento:
Depois que todos os controladores estiverem integrados, conclua esta etapa:
Note: Ao coletar o backup do banco de dados de configuração do cluster vManage existente que tem a recuperação de desastres ativada, certifique-se de que ele seja coletado após a recuperação de desastres nesse nó ser pausada e excluída.
Confirme se não há replicação de recuperação de desastres em andamento. Navegue até Administração > Recuperação de desastres e verifique o status Sucesso e não em um estado transitório, como Importação pendente, Exportação pendente ou Download pendente. Se o status não for sucesso, entre em contato com o Cisco TAC e certifique-se de que a replicação seja bem-sucedida antes de continuar a pausar a recuperação de desastres.
Primeiro, pause a recuperação de desastres e certifique-se de que a tarefa esteja concluída. Em seguida, exclua a recuperação de desastre e confirme se a tarefa foi concluída.

Entre em contato com o Cisco TAC para garantir que a recuperação de desastres seja limpa com êxito.
Você pode verificar o mesmo usando o comando request nms configuration-db status no vManage CLI. A saída é a mostrada
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 .
Use esse comando para coletar o backup configuration-db do nó vManage líder configuration-db identificado.
request nms configuration-db backup path /opt/data/backup/<filename>
A saída esperada é a seguinte:
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#
Copie o backup do configuration-db para o diretório /home/admin/ do vManage usando SCP.
Exemplo de saída do 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 -
Para restaurar o backup do configuration-db, primeiro precisamos configurar as credenciais do configuration-db. Se suas credenciais de configuração-db forem default (neo4j/password), podemos pular esta etapa.
Para configurar as credenciais do configuration-db, use o comando request nms configuration-db update-admin-user. Use o nome de usuário e a senha de sua escolha.
Observe que o servidor de aplicativos do vManage é reiniciado. Devido ao qual a interface do usuário do vManage fica inacessível por um curto período.
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 que podemos continuar para restaurar o backup do configuration-db:
Podemos usar o comando request nms configuration-db restore path /home/admin/< > para restaurar o configuration-db para o novo 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
Depois que o configuration-db for restaurado, verifique se a interface do usuário do vManage está acessível. Aguarde cerca de 5 minutos e tente acessar a interface do usuário.
Depois de fazer logon na interface do usuário com êxito, verifique se a lista de roteadores de borda, o modelo, as políticas e todas as configurações presentes na interface do usuário do vManage anterior ou existente estão refletidas na nova interface do usuário do vManage.
Caution: O configuration-db restaurado ainda contém o(s) gerenciador(es) de SD-WAN do(s) qual(is) o backup foi retirado. Eles estão listados como entradas do gerente em Configuração > Certificados > Componentes de controle (20.9/20.12: Configuration > Certificates > Controllers), mas não são membros de Administration > Cluster Management. Até que sejam removidos na Etapa 5:
Não execute nenhuma operação de certificado do controlador ou Enviar para o validador neste vManage até que a Etapa 5 seja concluída. Se a instalação de um certificado falhar, não instale o mesmo certificado da CLI; Entre em contato com o Cisco TAC.
Depois que o configuration-db for restaurado, precisamos autenticar novamente todos os novos controladores (vmanage/vsmart/vbond) na malha
Observação: na produção real, se o IP da interface usado para reautenticar for o IP da interface do túnel, será necessário garantir que o serviço NETCONF seja permitido na interface do túnel do vManage, vSmart e vBond e também nos firewalls ao longo do caminho. A porta de firewall a ser aberta é a porta TCP 830 como regra bidirecional do cluster DR para todos os vBonds e vSmarts .
Na interface do usuário do vmanage, clique em Configuration > Devices > Controllers

Depois que todos os controladores estiverem integrados, conclua esta etapa:
Em qualquer servidor Cisco SD-WAN Manager no cluster recém-ativo, execute estas ações:
Digite este comando para sincronizar o certificado raiz com todos os dispositivos Cisco Catalyst SD-WAN no cluster recém-ativo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Digite este comando para sincronizar o UUID do Cisco SD-WAN Manager com o Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Faça isso logo após a sincronização da cadeia de certificados raiz e antes de qualquer operação de certificado do controlador ou Enviar para o validador.
Invalidating Root Certificate Autority of vManage-<uuid>
Sending serial number of vManage-<uuid> as invalid to all controllers
Failed to push serial list to vManage-<uuid> - retry in 30 seconds; Failed to find Vmanage Cluster node for uuid <uuid> (x3)
Updated serial list will be sent to vManage-<uuid> when it is reachable
Clearing certificate on vManage-<uuid>
Successfully invalidated vManage-<uuid>
A entrada agora mostra Nenhum certificado instalado. O número de série e a CA raiz do SD-WAN Manager anterior são removidos dos validadores.
Quando a estrutura for restaurada e as sessões de controle e BFD estiverem ativas para todas as bordas e controladores na estrutura, invalide as entradas vBond/Validator e vSmart/Controller antigas da interface do usuário:
Note: Continue com a seção Post Checks mostrada aqui, que é comum a todas as combinações de implantação.
O que é DR em espera manual/a frio? O servidor de backup do SD-WAN Manager ou o cluster do SD-WAN Manager é mantido desligado no estado de espera a frio.
Ele também pode ser mantido ligado com a interface de transporte VPN 0 desligada. Em ambos os casos, o standby deve permanecer isolado da estrutura até que seja ativado, e o vManage/cluster ativo deve ser isolado antes que a interface de transporte do standby seja ativada.
São feitos backups regulares do banco de dados ativo e, se o cluster principal do SD-WAN Manager ou do SD-WAN Manager for desativado, o cluster do SD-WAN Manager ou do SD-WAN Manager em standby será ativado manualmente e o banco de dados de backup será restaurado nele.
Instâncias necessárias:
Etapas:
Certifique-se de que o número de instâncias ativas do Cisco SD-WAN Manager seja idêntico ao número de instâncias recém-instaladas do Cisco SD-WAN Manager .
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager executem a mesma versão de software.
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager possam acessar o endereço IP de gerenciamento do Cisco SD-WAN Validator.
Verifique se os certificados foram instalados nas instâncias recém-instaladas do Cisco SD-WAN Manager.
Certifique-se de que os relógios em todos os dispositivos Cisco Catalyst SD-WAN, incluindo as instâncias recém-instaladas do Cisco SD-WAN Manager, estejam sincronizados.
Verifique se um novo conjunto de IPs do sistema e IDs do local está configurado nas instâncias do Cisco SD-WAN Manager recém-instalado, juntamente com a mesma configuração básica do cluster ativo.

Caso estejamos usando nossa própria CA, autoridade de certificação empresarial, escolha Empresa.

Navegue para Configuration > Devices > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Observação: precisamos usar credenciais de administrador do vBond ou uma parte do usuário do netadmin grupo. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para o vBond
Note: Se o vBond estiver por trás de um dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vBond está traduzido para um IP público. Se o IP da interface VPN 0 não estiver acessível no vManage, use o endereço IP público da interface VPN 0 nesta etapa
Clique em Add vSmart no caso do vManage 20.12 ou Add Controller no caso do vManage 20.15/20.18.
Um pop-up é aberto, insira o IP de transporte VPN 0 do vSmart que pode ser acessado no vManage.
Verifique a acessibilidade usando ping se permitido do CLI do vManage para o vSmart IP.
Insira as credenciais de usuário do vSmart. Observe que precisamos usar credenciais de administrador do vSmart ou uma parte do usuário do grupo netadmin.
Você pode verificar isso na CLI do vSmart.
Defina o protocolo como TLS, se pretendemos usar TLS para roteadores para estabelecer conexões de controle com vSmart. Essa configuração também precisa ser configurada na CLI dos nós vSmarts e vManage.
Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para vSmart.
Observação: se o vSmart estiver por trás do dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vSmart está convertido em um IP público e se o IP da interface VPN 0 não pode ser acessado do vManage, use o endereço IP público do IP da interface VPN 0 nesta etapa.
Após concluir todas as etapas, verifique se todos os componentes de controle estão acessíveis no Monitor > Painel


Observação: o vManage Cluster pode ser configurado com 3 nós do vManage ou 6 nós do vManage, dependendo do número de locais integrados à malha SD-WAN
Continue com as etapas compartilhadas em "Controladores SD-WAN integrados com um único nó vManage na sobreposição SD-WAN" para ativar primeiro a estrutura SD-WAN com um nó vManage e integrar todos os Validadores (vBond) e Controladores (vSmart) necessários.
config t
system
host-name <hostname>
system-ip <unique system-ip>
site-id <site-id>
organization-name <organization name>
vbond <IP address/URL of vBond>
commit
Observação: se estamos usando URL como endereço vBond, certifique-se de configurar os endereços IP do servidor DNS na configuração VPN 0 ou de garantir que eles possam ser resolvidos.
Essas configurações são necessárias para ativar a interface de transporte usada para estabelecer conexões de controle com os roteadores e o restante dos controladores.
config t
vpn 0
dns <IP-address> primary
dns <IP-address> secondary
interface eth1
ip address <IP-address/mask>
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 <default-gateway IP>
commit
Configure também a interface de gerenciamento do VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address <IP-address/mask>
no shutdown
!
ip route 0.0.0.0/0 <default-gateway IP>
!
Commit
Configuração opcional:
Conf t
security
control
protocol tls
commit
Configure a interface de serviço em todos os nós do vManage, incluindo o vManage-1, que já foi integrado. Essa interface é usada para comunicação de cluster, o que significa comunicação entre os nós vManage no cluster.
conf t
interface eth2
ip address <IP-address/mask>
no shutdown
commit
Certifique-se de que a mesma sub-rede IP seja usada para a interface de serviço em todos os nós no cluster vManage.
Podemos usar as mesmas credenciais de administrador dos nós vManage para configurar o cluster vManage. Caso contrário, podemos configurar uma nova credencial de usuário que faça parte do grupo netadmin. As configurações para configurar a credencial do novo usuário são as mostradas
conf t
system
aaa
user <username>
password <password>
group netadmin
commit
Certifique-se de configurar as mesmas credenciais de usuário em todos os nós do vManage que fazem parte do cluster. Se decidirmos usar credenciais de administrador, ele deverá ser o mesmo nome de usuário/senha em todos os nós do vManage .
Navegue para Configuration > Certificates > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Clique em ... para Gerente/vManage e clique em Gerar CSR.

Depois que o CSR for gerado, você poderá fazer o download do CSR e obtê-lo assinado com base na autoridade de certificado escolhida para os controladores. Você pode verificar essa configuração em Administration > Settings > Controller Certificate Authorization. Se Cisco (recomendado) for escolhido, o CSR será automaticamente carregado no portal PNP pelo vManage e, uma vez assinado o certificado, ele será instalado no vManage automaticamente.
Se Manual for escolhido, assine manualmente o CSR usando o portal PNP da Cisco navegando até a Smart Account e a Virtual Account da respectiva sobreposição SD-WAN.
Quando o certificado estiver disponível no portal PNP, clique em instalar certificado na mesma seção do vManage, carregue o certificado e instale-o.
O mesmo procedimento é aplicável se estivermos usando Digicert e Enterprise Root Certificate.
Conclua esta etapa em todos os nós do vManage que fazem parte do cluster.
Note: Para um cluster de 3 nós, todos os 3 nós do vManage são ativados com computação+dados como persona.
Configuração opcional:
Consulte essa configuração no cluster existente para Habilitar SDAVC - Só precisa ser verificado se for necessário e só é necessário em um nó vManage do cluster.
Clique em Atualizar.



Esses pontos precisam ser levados em consideração antes de adicionar o próximo nó ao cluster:
Verifique esses pontos em todas as IUs dos nós do vManage que foram adicionados ao cluster até o momento:
Você pode ativar um ou mais clusters do vManage usando as etapas descritas na Etapa 3: Construir cluster vManage. Postagem que conclua as etapas descritas na Etapa 5: Backup/Restauração do Config-db para restaurar o backup do config-db no cluster em standby.
Você pode verificar o mesmo usando o comando request nms configuration-db status no vManage CLI. A saída é a mostrada
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 .
Use esse comando para coletar o backup configuration-db do nó vManage líder configuration-db identificado.
request nms configuration-db backup path /opt/data/backup/<filename>
A saída esperada é a seguinte:
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#
Copie o backup do configuration-db para o diretório /home/admin/ do vManage usando SCP.
Exemplo de saída do 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 -
Para restaurar o backup do configuration-db, primeiro precisamos configurar as credenciais do configuration-db. Se suas credenciais de configuração-db forem default (neo4j/password), podemos pular esta etapa.
Para configurar as credenciais do configuration-db, use o comando request nms configuration-db update-admin-user. Use o nome de usuário e a senha de sua escolha.
Observe que o servidor de aplicativos do vManage é reiniciado. Devido ao qual a interface do usuário do vManage fica inacessível por um curto período.
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 que podemos continuar para restaurar o backup do configuration-db:
Podemos usar o comando request nms configuration-db restore path /home/admin/< > para restaurar o configuration-db para o novo 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
Depois que o configuration-db for restaurado, verifique se a interface do usuário do vManage está acessível. Aguarde cerca de 5 minutos e tente acessar a interface do usuário.
Depois de fazer logon na interface do usuário com êxito, verifique se a lista de roteadores de borda, o modelo, as políticas e todas as configurações presentes na interface do usuário do vManage anterior ou existente estão refletidas na nova interface do usuário do vManage.
Caution: O configuration-db restaurado ainda contém o(s) gerenciador(es) de SD-WAN do(s) qual(is) o backup foi retirado. Eles estão listados como entradas do gerente em Configuração > Certificados > Componentes de controle (20.9/20.12: Configuration > Certificates > Controllers), mas não são membros de Administration > Cluster Management. Até que sejam removidos na Etapa 6:
Não execute nenhuma operação de certificado do controlador ou Enviar para o validador neste vManage até que a Etapa 6 seja concluída. Se a instalação de um certificado falhar, não instale o mesmo certificado da CLI; Entre em contato com o Cisco TAC.
Depois que o configuration-db for restaurado, precisamos autenticar novamente todos os novos controladores (vmanage/vsmart/vbond) na malha
Observação: na produção real, se o IP da interface usado para reautenticar for o IP da interface do túnel, será necessário garantir que o serviço NETCONF seja permitido na interface do túnel do vManage, vSmart e vBond e também nos firewalls ao longo do caminho. A porta de firewall a ser aberta é a porta TCP 830 como regra bidirecional do cluster DR para todos os vBonds e vSmarts .
Na interface do usuário do vmanage, clique em Configuration > Devices > Controllers

Depois que todos os controladores estiverem integrados, conclua esta etapa:
Em qualquer servidor Cisco SD-WAN Manager no cluster recém-ativo, execute estas ações:
Digite este comando para sincronizar o certificado raiz com todos os dispositivos Cisco Catalyst SD-WAN no cluster recém-ativo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Digite este comando para sincronizar o UUID do Cisco SD-WAN Manager com o Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Faça isso logo após a sincronização da cadeia de certificados raiz e antes de qualquer operação de certificado do controlador ou Enviar para o validador.
Invalidating Root Certificate Autority of vManage-<uuid>
Sending serial number of vManage-<uuid> as invalid to all controllers
Failed to push serial list to vManage-<uuid> - retry in 30 seconds; Failed to find Vmanage Cluster node for uuid <uuid> (x3)
Updated serial list will be sent to vManage-<uuid> when it is reachable
Clearing certificate on vManage-<uuid>
Successfully invalidated vManage-<uuid>
A entrada agora mostra Nenhum certificado instalado. O número de série e a CA raiz do SD-WAN Manager anterior são removidos dos validadores.
Quando a estrutura for restaurada e as sessões de controle e BFD estiverem ativas para todas as bordas e controladores na estrutura, invalide as entradas vBond/Validator e vSmart/Controller antigas da interface do usuário:
Conclua esta etapa sempre que o standby se tornar ativo e novamente na direção oposta no failback.
Note: Continue com a seção Post Checks mostrada aqui, que é comum a todas as combinações de implantação.
Instâncias necessárias:
Etapas:
Certifique-se de que o número de instâncias ativas do Cisco SD-WAN Manager seja idêntico ao número de instâncias recém-instaladas do Cisco SD-WAN Manager .
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager executem a mesma versão de software.
Certifique-se de que todas as instâncias novas e ativas do Cisco SD-WAN Manager possam acessar o endereço IP de gerenciamento do Cisco SD-WAN Validator.
Verifique se os certificados foram instalados nas instâncias recém-instaladas do Cisco SD-WAN Manager.
Certifique-se de que os relógios em todos os dispositivos Cisco Catalyst SD-WAN, incluindo as instâncias recém-instaladas do Cisco SD-WAN Manager, estejam sincronizados.
Verifique se um novo conjunto de IPs do sistema e IDs do local está configurado nas instâncias do Cisco SD-WAN Manager recém-instalado, juntamente com a mesma configuração básica do cluster ativo.

Caso estejamos usando nossa própria CA, autoridade de certificação empresarial, escolha Empresa.

Navegue para Configuration > Devices > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Observação: precisamos usar credenciais de administrador do vBond ou uma parte do usuário do netadmin grupo. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para o vBond
Note: Se o vBond estiver por trás de um dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vBond está traduzido para um IP público. Se o IP da interface VPN 0 não estiver acessível no vManage, use o endereço IP público da interface VPN 0 nesta etapa
Clique em Add vSmart no caso do vManage 20.12 ou Add Controller no caso do vManage 20.15/20.18.
Um pop-up é aberto, insira o IP de transporte VPN 0 do vSmart que pode ser acessado no vManage.
Verifique a acessibilidade usando ping se permitido do CLI do vManage para o vSmart IP.
Insira as credenciais de usuário do vSmart. Observe que precisamos usar credenciais de administrador do vSmart ou uma parte do usuário do grupo netadmin.
Você pode verificar isso na CLI do vSmart.
Defina o protocolo como TLS, se pretendemos usar TLS para roteadores para estabelecer conexões de controle com vSmart. Essa configuração também precisa ser configurada na CLI dos nós vSmarts e vManage.
Escolha Sim no menu suspenso de "Gerar CSR" se precisarmos instalar um novo certificado para vSmart.
Observação: se o vSmart estiver por trás do dispositivo NAT/Firewall, verifique se o IP da interface VPN 0 do vSmart está convertido em um IP público e se o IP da interface VPN 0 não pode ser acessado do vManage, use o endereço IP público do IP da interface VPN 0 nesta etapa.
Após concluir todas as etapas, verifique se todos os componentes de controle estão acessíveis no Monitor > Painel


Observação: o vManage Cluster pode ser configurado com 3 nós do vManage ou 6 nós do vManage, dependendo do número de locais integrados à malha SD-WAN
Continue com as etapas compartilhadas em "Controladores SD-WAN integrados com um único nó vManage na sobreposição SD-WAN" para ativar primeiro a estrutura SD-WAN com um nó vManage e integrar todos os Validadores (vBond) e Controladores (vSmart) necessários.
config t
system
host-name <hostname>
system-ip <unique system-ip>
site-id <site-id>
organization-name <organization name>
vbond <IP address/URL of vBond>
commit
Observação: se estamos usando URL como endereço vBond, certifique-se de configurar os endereços IP do servidor DNS na configuração VPN 0 ou de garantir que eles possam ser resolvidos.
Essas configurações são necessárias para ativar a interface de transporte usada para estabelecer conexões de controle com os roteadores e o restante dos controladores.
config t
vpn 0
dns <IP-address> primary
dns <IP-address> secondary
interface eth1
ip address <IP-address/mask>
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 <default-gateway IP>
commit
Configure também a interface de gerenciamento do VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address <IP-address/mask>
no shutdown
!
ip route 0.0.0.0/0 <default-gateway IP>
!
Commit
Configuração opcional:
Conf t
security
control
protocol tls
commit
Configure a interface de serviço em todos os nós do vManage, incluindo o vManage-1, que já foi integrado. Essa interface é usada para comunicação de cluster, o que significa comunicação entre os nós vManage no cluster.
conf t
interface eth2
ip address <IP-address/mask>
no shutdown
commit
Certifique-se de que a mesma sub-rede IP seja usada para a interface de serviço em todos os nós no cluster vManage.
Podemos usar as mesmas credenciais de administrador dos nós vManage para configurar o cluster vManage. Caso contrário, podemos configurar uma nova credencial de usuário que faça parte do grupo netadmin. As configurações para configurar a credencial do novo usuário são as mostradas
conf t
system
aaa
user <username>
password <password>
group netadmin
commit
Certifique-se de configurar as mesmas credenciais de usuário em todos os nós do vManage que fazem parte do cluster. Se decidirmos usar credenciais de administrador, ele deverá ser o mesmo nome de usuário/senha em todos os nós do vManage .
Navegue para Configuration > Certificates > Control Components no caso de nós 20.15/20.18 vManage. No caso das versões 20.9/20.12, Configuração > Dispositivos > Controladores
Clique em ... para Gerente/vManage e clique em Gerar CSR.

Depois que o CSR for gerado, você poderá fazer o download do CSR e obtê-lo assinado com base na autoridade de certificado escolhida para os controladores. Você pode verificar essa configuração em Administration > Settings > Controller Certificate Authorization. Se Cisco (recomendado) for escolhido, o CSR será automaticamente carregado no portal PNP pelo vManage e, uma vez assinado o certificado, ele será instalado no vManage automaticamente.
Se Manual for escolhido, assine manualmente o CSR usando o portal PNP da Cisco navegando até a Smart Account e a Virtual Account da respectiva sobreposição SD-WAN.
Quando o certificado estiver disponível no portal PNP, clique em instalar certificado na mesma seção do vManage, carregue o certificado e instale-o.
O mesmo procedimento é aplicável se estivermos usando Digicert e Enterprise Root Certificate.
Conclua esta etapa em todos os nós do vManage que fazem parte do cluster.
Note: Para um cluster de 3 nós, todos os 3 nós do vManage são ativados com computação+dados como persona. Para um cluster de 6 nós, 3 nós do vManage são ativados com computação+dados como o persona e 3 nós do vManage são ativados com dados como o persona.

Configuração opcional:
Consulte essa configuração no cluster existente para Habilitar SDAVC - Só precisa ser verificado se for necessário e só é necessário em um nó vManage do cluster.
Clique em Atualizar.



Esses pontos precisam ser levados em consideração antes de adicionar o próximo nó ao cluster:
Verifique esses pontos em todas as IUs dos nós do vManage que foram adicionados ao cluster até o momento:
Note: Ao coletar o backup do banco de dados de configuração do cluster vManage existente que tem a recuperação de desastres ativada, certifique-se de que ele seja coletado após a recuperação de desastres nesse nó ser pausada e excluída.
Confirme se não há replicação de recuperação de desastres em andamento. Navegue até Administração > Recuperação de desastres e verifique o status Sucesso e não em um estado transitório, como Importação pendente, Exportação pendente ou Download pendente. Se o status não for sucesso, entre em contato com o Cisco TAC e certifique-se de que a replicação seja bem-sucedida antes de continuar a pausar a recuperação de desastres.
Primeiro, pause a recuperação de desastres e certifique-se de que a tarefa esteja concluída. Em seguida, exclua a recuperação de desastre e confirme se a tarefa foi concluída.

Entre em contato com o Cisco TAC para garantir que a recuperação de desastres seja limpa com êxito.
Você pode verificar o mesmo usando o comando request nms configuration-db status no vManage CLI. A saída é a mostrada
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 .
Use esse comando para coletar o backup configuration-db do nó vManage líder configuration-db identificado.
request nms configuration-db backup path /opt/data/backup/<filename>
A saída esperada é a seguinte:
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#
Copie o backup do configuration-db para o diretório /home/admin/ do vManage usando SCP.
Exemplo de saída do 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 -
Para restaurar o backup do configuration-db, primeiro precisamos configurar as credenciais do configuration-db. Se suas credenciais de configuração-db forem default (neo4j/password), podemos pular esta etapa.
Para configurar as credenciais do configuration-db, use o comando request nms configuration-db update-admin-user. Use o nome de usuário e a senha de sua escolha.
Observe que o servidor de aplicativos do vManage é reiniciado. Devido ao qual a interface do usuário do vManage fica inacessível por um curto período.
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 que podemos continuar para restaurar o backup do configuration-db:
Podemos usar o comando request nms configuration-db restore path /home/admin/< > para restaurar o configuration-db para o novo 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
Depois que o configuration-db for restaurado, verifique se a interface do usuário do vManage está acessível. Aguarde cerca de 5 minutos e tente acessar a interface do usuário.
Depois de fazer logon na interface do usuário com êxito, verifique se a lista de roteadores de borda, o modelo, as políticas e todas as configurações presentes na interface do usuário do vManage anterior ou existente estão refletidas na nova interface do usuário do vManage.
Caution: O configuration-db restaurado ainda contém o(s) gerenciador(es) de SD-WAN do(s) qual(is) o backup foi retirado. Eles estão listados como entradas do gerente em Configuração > Certificados > Componentes de controle (20.9/20.12: Configuration > Certificates > Controllers), mas não são membros de Administration > Cluster Management. Até que sejam removidos na Etapa 6:
Não execute nenhuma operação de certificado do controlador ou Enviar para o validador neste vManage até que a Etapa 6 seja concluída. Se a instalação de um certificado falhar, não instale o mesmo certificado da CLI; Entre em contato com o Cisco TAC.
Pré-verificações importantes
Dois clusters de três nós do vManage separados devem ser configurados e estar operacionais para prosseguir com a recuperação de desastres. No cluster ativo, você deve ter validadores e controladores integrados. Caso você tenha o validador e os controladores no local do DR, eles também devem ser integrados no cluster ativo e não no cluster do DR vManage.
A Cisco recomenda que, antes de registrar a recuperação de desastres, estes requisitos devem ser atendidos:
Configurações
Para obter mais informações sobre o vManage Disaster Recovery, consulte este link.
Os dois clusters de 3 nós separados já foram criados, supondo que cada gerenciador de SD-WAN tenha uma configuração mínima e que a parte de certificação esteja concluída.
Navegue para Administração > Gerenciamento de cluster em ambos os clusters e verifique se todos os nós estão no estado pronto.
DC vManage

DR vmanage

Navegue até Administração>Recuperação de desastres do vManage Cluster principal. Clique em Manage Disaster Recovery.

Na janela pop-up, preencha os detalhes do vManage principal e secundário.
Os endereços IP a serem indicados são os endereços IP das interfaces de cluster fora da banda. De preferência, use o endereço IP da interface de serviço VPN 0 do vManage-1 em cada um dos clusters.
As credenciais devem ser as de um usuário netadmin e não devem ser alteradas após a configuração do DR, a menos que ele seja excluído. Uma credencial de usuário local do vManage separada para recuperação de desastres pode ser usada. Precisamos verificar se o usuário local do vManage faz parte do grupo netadmin. Até mesmo as credenciais de administrador podem ser usadas aqui.

Depois de preenchido, clique em Avançar.
Os controladores vBond devem estar acessíveis no endereço IP especificado via Netconf.

Depois de preenchido, clique em Avançar.


Defina o valor e clique em Salvar.

Verificação
Navegue até Administração>Recuperação de desastres para ver o status da Recuperação de desastres e quando os dados foram replicados pela última vez.

Note: A replicação pode levar várias horas, dependendo do tamanho do banco de dados. Além disso, pode exigir alguns ciclos para obter uma replicação bem-sucedida.
Depois que o configuration-db for restaurado, precisamos autenticar novamente todos os novos controladores (vmanage/vsmart/vbond) na malha
Observação: na produção real, se o IP da interface usado para reautenticar for o IP da interface do túnel, será necessário garantir que o serviço NETCONF seja permitido na interface do túnel do vManage, vSmart e vBond e também nos firewalls ao longo do caminho. A porta de firewall a ser aberta é a porta TCP 830 como regra bidirecional do cluster DR para todos os vBonds e vSmarts .
Na interface do usuário do vmanage, clique em Configuration > Devices > Controllers

Depois que todos os controladores estiverem integrados, conclua esta etapa:
Em qualquer servidor Cisco SD-WAN Manager no cluster recém-ativo, execute estas ações:
Digite este comando para sincronizar o certificado raiz com todos os dispositivos Cisco Catalyst SD-WAN no cluster recém-ativo:
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Digite este comando para sincronizar o UUID do Cisco SD-WAN Manager com o Cisco SD-WAN Validator:
https://vmanage-url/dataservice/certificate/syncvbond
Faça isso logo após a sincronização da cadeia de certificados raiz e antes de qualquer operação de certificado do controlador ou Enviar para o validador.
Invalidating Root Certificate Autority of vManage-<uuid>
Sending serial number of vManage-<uuid> as invalid to all controllers
Failed to push serial list to vManage-<uuid> - retry in 30 seconds; Failed to find Vmanage Cluster node for uuid <uuid> (x3)
Updated serial list will be sent to vManage-<uuid> when it is reachable
Clearing certificate on vManage-<uuid>
Successfully invalidated vManage-<uuid>
A entrada agora mostra Nenhum certificado instalado. O número de série e a CA raiz do SD-WAN Manager anterior são removidos dos validadores.
Quando a estrutura for restaurada e as sessões de controle e BFD estiverem ativas para todas as bordas e controladores na estrutura, invalide as entradas vBond/Validator e vSmart/Controller antigas da interface do usuário:
Essas pós-verificações se aplicam a todas as combinações de implantação.
request platform software sdwan vedge_cloud activate chassis-number <chassis-number > token <token number>
Verifique se os itens aparecem como esperado:
Modelos
Políticas
Página Dispositivo (ambas as abas) Lista de vEdge de WAN e Controladores
Aplicável para nós vManage:
Verificações de Configuration-DB(Neo4j):
Execute o comando "request nms configuration-db diagnostics" em todos os nós do vManage:
1. Verificar o status do Nó on-line e de Liderança:(não disponível para todas as versões)
"Neo4j" deve mostrar 3 nós online e 1 líder e 2 seguidores. "system" também deve mostrar 3 nós on-line e 1 líder e 2 seguidores, no entanto, como este não é o Db padrão, o sinalizador padrão é false. Se houver menos de 3 entradas em cada neo4j e o sistema significa que o nó caiu do cluster. Entre em contato com o TAC da Cisco para solucionar o mesmo problema.
2. Verifique se algum nó está em "quarentena".

Nenhum dos nós deve estar em estado de quarentena.
3. A validação do esquema deve ser "bem-sucedida".

4. Colete um backup configuration-db usando o comando "request nms configuration-db diagnostics" e certifique-se de que ele seja bem-sucedido.

Se houver qualquer inconsistência ou erro, entre em contato com o TAC da Cisco para solucionar problemas.
Como alternativa, podemos executar essas chamadas de API para confirmar o status do nó vmanage de um cluster (para todos os nós COMPUTE+DATA) - funciona somente na versão 20.12 e posterior
go to vshell of the vmanage node ( to be done on all vmanages)
===============================================================
curl -u <config-db username>:<config-db password> -H "Content-Type: application/json" -d '{"statements":[{"statement":"call dbms.cluster.overview"}]}' http://<cluster OOB ip>:7474/db/neo4j/tx/commit | jq -r
curl -u <config-db username>:<config-db password> -H "Content-Type: application/json" -d '{"statements":[{"statement":"show databases"}]}' http://<cluster OOB ip>:7474/db/neo4j/tx/commit | jq -r
Certifique-se de que em um cluster tenha apenas um líder para o neo4j e o sistema e resto como seguidores .Certifique-se de que todos os nós estão on-line .Se você tem cluster de 3 nós ( todos os três são COMPUTE+DATA),deve haver apenas um líder para o neo4j e o sistema .Qualquer desvio, você deve entrar em contato com o TAC
5. Verifique se há erros de disco, memória e E/S em /var/log/kern.log. Isso precisa ser verificado em todos os nós do vManage.
6. Verifique a etapa ao formar um cluster novo para vmanage que não tem CC entre cada nó
Execute ssh como vmanage-admin do nó 1 para o ip do cluster de outros nós e vice-versa, para verificar se a chave pública é trocada e a senha menos ssh está funcionando [O token de consentimento é necessário para as etapas mostradas aqui]
DR-vManage-1:~# ssh -i /etc/viptela/.ssh/id_dsa -p 830 vmanage-admin@<ClusterIP>
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:
Caso a saída solicite a inserção da senha, entre em contato com o TAC
Aplicável a todos os controladores SD-WAN (vBond, vManage, vSmart):
Execute os comandos em todos os controladores na sobreposição e confirme se o vManage UUID e os números de série vistos são válidos para a estrutura atual:
Comandos vBond:
show orchestrator valid-vsmarts
show orchestrator valid-vmanage-id
Comandos vManage/vSmart:
show control valid-vsmarts
show control valid-manage-id
Observe que a saída de show control valid-vsmarts inclui os números de série dos nós vSmarts e vManage.
Compare-o com os vistos na interface do usuário do vManage. Navegue até a seção Configuração > Certificados > Controladores.
Confirme também:
Se outras entradas adicionais forem vistas para o UUID/número de série que não estão atualmente integrados à estrutura, entre em contato com o TAC da Cisco.
| Revisão | Data de publicação | Comentários |
|---|---|---|
2.0 |
04-Nov-2026
|
Orientação para invalidar as entradas vmanage antigas adicionadas |
1.0 |
25-Feb-2026
|
Versão inicial |