O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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
no shutdown
!
ip route 0.0.0.0/0
!
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
no shutdown
!
ip route 0.0.0.0/0
!
commit
Quando você tiver acesso SSH a todos os controladores, configure essas configurações CLI em cada controlador.
config t
system
host-name
system-ip
site-id
organization-name
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 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
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 deVoBondor ou uma parte do usuário de netadmingroup. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de"Gerar CSR" se precisarmos instalar um novo certificado para 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 em Monitor>Dashboard


Confirme se o configuration-db está sendo executado no nó vManage.
Você pode verificar o mesmo usando o comando request nms configuration-db status onvManageCLI. 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/
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.
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
Depois que a estrutura for restaurada e as sessões de controle e bfd estiverem ativas para todas as bordas e controladores na estrutura, precisamos invalidar os controladores antigos (vmanage/vsmart/vbond) 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 deVoBondor ou uma parte do usuário de netadmingroup. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de"Gerar CSR" se precisarmos instalar um novo certificado para 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 em Monitor>Dashboard


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.
Confirme se o configuration-db está sendo executado no nó vManage.
Você pode verificar o mesmo usando o comando request nms configuration-db statusonvManageCLI. 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/
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.
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 vManageantes do registro do Disaster Recovery é como mostrado
config t
system
host-name
system-ip
site-id
organization-name
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 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
Configure também a interface de gerenciamento VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
commit
Configure a interface de serviço no nó do vManage. Essa interface é usada para comunicação DR,
conf t
interface eth2
ip address
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 3: 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 a opção ‘Intervalo de Replicação’.A cada intervalo de replicação, os dados são replicados do principal vManage 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 desastrespara 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
Depois que a estrutura for restaurada e as sessões de controle e bfd estiverem ativas para todas as bordas e controladores na estrutura, precisamos invalidar os controladores antigos (vmanage/vsmart/vbond) 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 deVoBondor ou uma parte do usuário de netadmingroup. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de"Gerar CSR" se precisarmos instalar um novo certificado para 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 em Monitor>Dashboard


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
system-ip
site-id
organization-name
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 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
Configure também a interface de gerenciamento VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configuração opcional:
Conf t
security
control
protocol tls
commit
Configure a interface de serviço em todos os vManageEnodes, incluindo o vManage-1, que já foi integrado. Essa interface é usada para comunicação de cluster, o que significa comunicação entre os vManagenodes no cluster.
conf t
interface eth2
ip address
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 vManagern.
Podemos usar as mesmas credenciais de administrador dos modosv para configurar o cluster do gerenciamento. Caso contrário, podemos configurar uma nova credencial de usuário que faz parte denetadmingroup. As configurações para configurar a credencial do novo usuário são as mostradas
conf t
system
aaa
user
password
group netadmin
commit
Certifique-se de configurar as mesmas credenciais de usuário em todos os vManagenodes que fazem parte do cluster.Se decidirmos usar credenciais de administrador, ele deverá ser o mesmo nome de usuário/senha em todos os vManagenodes.
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 requestnmsconfiguration-dbstatus no vManageCLI. 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/
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.
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
Depois que a estrutura for restaurada e as sessões de controle e bfd estiverem ativas para todas as bordas e controladores na estrutura, precisamos invalidar os controladores antigos (vmanage/vsmart/vbond) 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.
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 das instâncias do gerenciador Cisco SD-WAN ativas seja idêntico ao número das instâncias do gerenciador recém-instaladas do Cisco SD-WAN .
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 deVoBondor ou uma parte do usuário de netadmingroup. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de"Gerar CSR" se precisarmos instalar um novo certificado para 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 em Monitor>Dashboard


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
system-ip
site-id
organization-name
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 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
Configure também a interface de gerenciamento VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configuração opcional:
Conf t
security
control
protocol tls
commit
Configure a interface de serviço em todos os vManageEnodes, incluindo o vManage-1, que já foi integrado. Essa interface é usada para comunicação de cluster, o que significa comunicação entre os vManagenodes no cluster.
conf t
interface eth2
ip address
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 vManagern.
Podemos usar as mesmas credenciais de administrador dos modosv para configurar o cluster do gerenciamento. Caso contrário, podemos configurar uma nova credencial de usuário que faz parte denetadmingroup. As configurações para configurar a credencial do novo usuário são as mostradas
conf t
system
aaa
user
password
group netadmin
commit
Certifique-se de configurar as mesmas credenciais de usuário em todos os nós vManagenedesque fazem parte do cluster.Se decidirmos usar credenciais de administrador, ele deverá ter o mesmo nome de usuário/senha em todos os nós vManagenodes.
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 4: Construir cluster vManage. Postagem que conclua as etapas descritas na Etapa 6: 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 requestnmsconfiguration-dbstatus no vManageCLI. 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/
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.
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
Depois que a estrutura for restaurada e as sessões de controle e bfd estiverem ativas para todas as bordas e controladores na estrutura, precisamos invalidar os controladores antigos (vmanage/vsmart/vbond) 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 das instâncias do gerenciador Cisco SD-WAN ativas seja idêntico ao número das instâncias do gerenciador recém-instaladas do Cisco SD-WAN .
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 deVoBondor ou uma parte do usuário de netadmingroup. Você pode verificar isso no CLI do vBond. Escolha Sim no menu suspenso de"Gerar CSR" se precisarmos instalar um novo certificado para 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 em Monitor>Dashboard


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
system-ip
site-id
organization-name
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 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
Configure também a interface de gerenciamento VPN 512 para permitir o acesso de gerenciamento fora de banda ao controlador.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configuração opcional:
Conf t
security
control
protocol tls
commit
Configure a interface de serviço em todos os vManageEnodes, incluindo o vManage-1, que já foi integrado. Essa interface é usada para comunicação de cluster, o que significa comunicação entre os vManagenodes no cluster.
conf t
interface eth2
ip address
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 vManagern.
Podemos usar as mesmas credenciais de administrador dos modosv para configurar o cluster do gerenciamento. Caso contrário, podemos configurar uma nova credencial de usuário que faz parte denetadmingroup. As configurações para configurar a credencial do novo usuário são as mostradas
conf t
system
aaa
user
password
group netadmin
commit
Certifique-se de configurar as mesmas credenciais de usuário em todos os nós vManagenedesque fazem parte do cluster.Se decidirmos usar credenciais de administrador, ele deverá ter o mesmo nome de usuário/senha em todos os nós vManagenodes.
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 requestnmsconfiguration-dbstatus no vManageCLI. 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/
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.
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
Depois que a estrutura for restaurada e as sessões de controle e bfd estiverem ativas para todas as bordas e controladores na estrutura, precisamos invalidar os controladores antigos (vmanage/vsmart/vbond) 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 token
Verifique se os itens aparecem como esperado:
Modelos
Políticas
Página Dispositivo (ambas as guias)Lista de WAN vEdgeControladores
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 : -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 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@
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.
Se forem vistas entradas adicionais para o UUID/número de série que não estão atualmente integrados à estrutura, devemos excluí-los. Você pode entrar em contato com o TAC da Cisco para o mesmo.
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
25-Feb-2026
|
Versão inicial |
Feedback