본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
이 문서에서는 다양한 구축을 위한 컨트롤러 컨피그레이션 백업 및 복원을 포함하여 Cisco SD-WAN 패브릭을 재구축하는 방법에 대해 설명합니다.
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
vManage 구축
DR 옵션
참고: 재해 복구 유형에 대한 자세한 내용은 이 링크를 참조하십시오.
조합:
| # | vManage 설정 | DR 옵션 |
|---|---|---|
| 1 | 독립형(1노드) | DR 없음 |
| 2 | 독립형(1노드) | 단일 노드 DR |
| 3 | 클러스터(3노드 또는 6노드) | DR 없음 |
| 4 | 클러스터(3노드 또는 6노드) | 대기 DR 클러스터 |
이러한 단계는 모든 구축 조합에 공통적으로 적용됩니다. VM 인스턴스를 시작하고 기본 CLI 컨피그레이션을 적용하는 프로세스를 다룹니다. 각 조합 섹션에는 구축할 인스턴스 수와 완료할 추가 단계가 나와 있습니다.
참고: Cisco는 특정 용어를 변경했으므로 이 용어는 상호 교환 가능합니다. Cisco vManage = Cisco Catalyst Manager, Cisco vBond = Cisco Catalyst Validator, Cisco vSmart = Cisco Catalyst 컨트롤러
Cisco Software Download(Cisco 소프트웨어 다운로드) 페이지에서 SD-WAN 컨트롤러용 OVA 파일을 다운로드합니다.
참고: ESXi/클라우드 플랫폼에서 OVA 파일을 사용하여 vSmart, vBond 및 vManage 컨트롤러를 스핀업합니다. 연결된 문서를 참조하고 SD-WAN 구축 유형에 따라 모든 컨트롤러에 충분한 CPU, RAM 및 디스크가 할당되었는지 확인합니다. 추가 정보를 보려면 여기로 이동하십시오. 연결된 컴퓨팅 설명서의 Storage Size* 열에 설명된 대로 vManage 노드에 보조 디스크를 할당해야 합니다.
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.
예: COMPUTE_AND_DATA에 대해 1을 선택합니다.

다음과 같이 보조 디스크를 선택합니다.


예

참고: 여기에서 기존 vManage의 컨피그레이션을 참조하고 동일한 IP 주소 체계를 구성할 수 있습니다.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
예:

참고: 기존 vBond에서 컨피그레이션을 참조하고 여기서 동일한 컨피그레이션을 구성할 수 있습니다.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
commit
모든 컨트롤러에 대한 SSH 액세스 권한을 갖게 되면 각 컨트롤러에서 이러한 CLI 컨피그레이션을 구성합니다.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
참고: URL을 vBond 주소로 사용하는 경우 VPN 0 컨피그레이션에서 DNS 서버 IP 주소를 구성하거나 확인할 수 있는지 확인하십시오.
라우터 및 나머지 컨트롤러와의 제어 연결을 설정하는 데 사용되는 전송 인터페이스를 활성화하려면 모든 컨트롤러에서 이러한 컨피그레이션이 필요합니다.
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
참고: 기존 컨트롤러의 컨피그레이션을 참조할 수 있으며, 컨피그레이션이 있는 경우 이 컨피그레이션을 새 컨트롤러에 추가할 수 있습니다.
라우터가 TLS를 사용하여 vManage 노드와 보안 제어 연결을 설정해야 하는 경우에만 제어 프로토콜을 TLS로 구성합니다. 기본적으로 모든 컨트롤러와 라우터는 DTLS를 사용하여 제어 연결을 설정합니다. 이는 사용자의 요구 사항에 따라 vSmart 및 vManage 노드에서만 필요한 선택적 컨피그레이션입니다.
Conf t
security
control
protocol tls
Commit
활성 Cisco SD-WAN Manager 인스턴스의 수가 새로 설치된 Cisco SD-WAN Manager 인스턴스의 수와 동일한지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 동일한 소프트웨어 버전을 실행하는지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 Cisco SD-WAN Validator의 관리 IP 주소에 연결할 수 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스에 인증서가 설치되어 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스를 포함하여 모든 Cisco Catalyst SD-WAN 디바이스의 시계가 동기화되었는지 확인합니다.
새 시스템 IP 및 사이트 ID 집합이 활성 클러스터와 동일한 기본 구성과 함께 새로 설치된 Cisco SD-WAN Manager 인스턴스에 구성되어 있는지 확인합니다.




자체 CA인 Enterprise Certificate Authority를 사용하는 경우 Enterprise를 선택합니다.


20.15/20.18 vManage 노드의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Control Components(제어 구성 요소)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
참고: vBonor의 관리자 자격 증명 또는 netadmingroup의 사용자 부분이 필요합니다. vBond의 CLI에서 이를 확인할 수 있습니다. vBond에 대한 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다.
참고: vBond가 NAT 디바이스/방화벽 뒤에 있는 경우 vBond VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인합니다. vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스의 공용 IP 주소를 사용합니다.

20.12 vManage의 경우 vSmart 추가 또는 20.15/20.18 vManage의 경우 컨트롤러 추가를 클릭합니다.
팝업이 열리면 vManage에서 연결할 수 있는 vSmart의 VPN 0 전송 IP를 입력합니다.
vManage의 CLI에서 vSmart IP로 허용되는 경우 ping을 사용하여 연결 가능성을 확인합니다.
vSmart의 사용자 자격 증명을 입력하십시오. vSmart의 관리자 자격 증명 또는 netadmin 그룹의 사용자 부분을 사용해야 합니다.
vSmart의 CLI에서 이를 확인할 수 있습니다.
라우터에 TLS를 사용하여 vSmart와의 제어 연결을 설정하려면 프로토콜을 TLS로 설정합니다. vSmarts 및 vManage 노드의 CLI에서도 이 구성을 구성해야 합니다.
vSmart용 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다.
참고: vSmart가 NAT 장치/방화벽 뒤에 있는 경우 vSmart VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인하고, vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스 IP의 공용 IP 주소를 사용합니다.

모든 단계가 완료되면 Monitor>Dashboard에서 모든 제어 구성 요소에 연결할 수 있는지 확인합니다


vManage 노드에서 configuration-db가 실행 중인지 확인합니다.
명령 요청 nms configuration-db status onvManageCLI를 사용하여 동일한 항목을 확인할 수 있습니다. 출력은 다음과 같습니다
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#
식별된 configuration-db leader vManage 노드에서 configuration-db 백업을 수집하려면 이 명령을 사용합니다.
request nms configuration-db backup path /opt/data/backup/
예상 출력은 다음과 같습니다.
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#
SCP를 사용하여 configuration-db 백업을 vManage의 /home/admin/ 디렉토리에 복사합니다.
샘플 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 -
configuration-db 백업을 복원하려면 먼저 configuration-db 자격 증명을 구성해야 합니다. configuration-db 자격 증명이 default(neo4j/password)인 경우 이 단계를 건너뛸 수 있습니다.
configuration-db 자격 증명을 구성하려면 nms configuration-db update-admin-user 명령을 사용합니다. 선택한 사용자 이름과 비밀번호를 사용합니다.
vManage의 애플리케이션 서버가 다시 시작됩니다. 따라서 vManage UI에 짧은 시간 동안 액세스할 수 없게 됩니다.
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#
구성 DB 백업을 복원하기 위해 진행할 수 있는 게시:
nms configuration-db 복원 경로 /home/admin/< > 명령을 사용하여 configuration-db를 새 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
configuration-db가 복원되면 vManage UI에 액세스할 수 있는지 확인합니다. 약 5분 정도 기다린 후 UI에 액세스를 시도합니다.
UI에 성공적으로 로그인했으면 Edge 라우터 목록, 템플릿, 정책 및 이전 또는 기존 vManage UI에 존재했던 나머지 모든 컨피그레이션이 새 vManage UI에 반영되었는지 확인합니다.
configuration-db가 복원되면 패브릭에서 모든 새 컨트롤러(vmanage/vsmart/vbond)를 다시 인증해야 합니다.
참고: 실제 프로덕션에서는 재인증에 사용되는 인터페이스 IP가 터널 인터페이스 IP인 경우 vManage, vSmart 및 vBond의 터널 인터페이스 및 경로에 따른 방화벽에서 NETCONF 서비스가 허용되는지 확인해야 합니다. 열 방화벽 포트는 DR 클러스터에서 모든 vBond 및 vSmarts로의 양방향 규칙인 TCP 포트 830입니다.
vmanage UI에서 Configuration > Devices > Controllers를 클릭합니다


모든 컨트롤러가 온보딩되면 다음 단계를 완료합니다.
새로 활성화된 클러스터의 Cisco SD-WAN Manager 서버에서 다음 작업을 수행합니다.
루트 인증서를 새로 활성화된 클러스터의 모든 Cisco Catalyst SD-WAN 디바이스와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Cisco SD-WAN Manager UUID를 Cisco SD-WAN Validator와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/certificate/syncvbond
패브릭이 복원되고 패브릭의 모든 에지와 컨트롤러에 대해 제어 및 bfd 세션이 작동되면 UI에서 이전 컨트롤러(vmanage/vsmart/vbond)를 무효화해야 합니다
참고: 여기에 표시된 모든 구축 조합에 공통적으로 적용되는 Post Checks(사후 검사) 섹션을 계속 진행합니다.
활성 Cisco SD-WAN Managerinstances의 수가 새로 설치된 Cisco SD-WAN Managerinstances의 수와 동일한지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 동일한 소프트웨어 버전을 실행하는지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 Cisco SD-WAN Validator의 관리 IP 주소에 연결할 수 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스에 인증서가 설치되어 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스를 포함하여 모든 Cisco Catalyst SD-WAN 디바이스의 시계가 동기화되었는지 확인합니다.
새 시스템 IP 및 사이트 ID 집합이 활성 클러스터와 동일한 기본 구성과 함께 새로 설치된 Cisco SD-WAN Manager 인스턴스에 구성되어 있는지 확인합니다.




자체 CA인 Enterprise Certificate Authority를 사용하는 경우 Enterprise를 선택합니다.


20.15/20.18 vManage 노드의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Control Components(제어 구성 요소)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
참고: vBonor의 관리자 자격 증명 또는 netadmingroup의 사용자 부분이 필요합니다. vBond의 CLI에서 이를 확인할 수 있습니다. vBond에 대한 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다
참고: vBond가 NAT 디바이스/방화벽 뒤에 있는 경우 vBond VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인합니다. vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스의 공용 IP 주소를 사용합니다

20.12 vManage의 경우 vSmart 추가 또는 20.15/20.18 vManage의 경우 컨트롤러 추가를 클릭합니다.
팝업이 열리면 vManage에서 연결할 수 있는 vSmart의 VPN 0 전송 IP를 입력합니다.
vManage의 CLI에서 vSmart IP로 허용되는 경우 ping을 사용하여 연결 가능성을 확인합니다.
vSmart의 사용자 자격 증명을 입력하십시오. vSmart의 관리자 자격 증명 또는 netadmin 그룹의 사용자 부분을 사용해야 합니다.
vSmart의 CLI에서 이를 확인할 수 있습니다.
라우터에 TLS를 사용하여 vSmart와의 제어 연결을 설정하려면 프로토콜을 TLS로 설정합니다. vSmarts 및 vManage 노드의 CLI에서도 이 구성을 구성해야 합니다.
vSmart용 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다.
참고: vSmart가 NAT 장치/방화벽 뒤에 있는 경우 vSmart VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인하고, vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스 IP의 공용 IP 주소를 사용합니다.

모든 단계가 완료되면 Monitor>Dashboard에서 모든 제어 구성 요소에 연결할 수 있는지 확인합니다


참고: 재해 복구가 활성화된 기존 vManage 노드에서 컨피그레이션 데이터베이스 백업을 수집하는 동안 해당 노드의 재해 복구가 일시 중지되고 삭제된 후에 수집되어야 합니다.
진행 중인 재해 복구 복제가 없는지 확인합니다. Administration(관리) > Disaster Recovery(재해 복구) 및 상태가 Success(성공)이고 Import Pending(가져오기 보류 중), Export Pending(내보내기 보류 중) 또는 Download Pending(다운로드 보류 중)과 같은 일시적인 상태가 아닌지 확인합니다. 상태가 성공적이지 않으면 Cisco TAC에 문의하여 복제가 성공적인지 확인한 후 재해 복구를 일시 중지합니다.
먼저 재해 복구를 일시 중지하고 작업이 완료되었는지 확인합니다. 그런 다음 재해 복구를 삭제하고 작업이 완료되었는지 확인합니다.

Cisco TAC에 문의하여 재해 복구가 성공적으로 정리되었는지 확인합니다.
vManage 노드에서 configuration-db가 실행 중인지 확인합니다.
commandrequest nms configuration-db statusonvManageCLI를 사용하여 이를 확인할 수 있습니다. 출력은 다음과 같습니다
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#
식별된 configuration-db leader vManage 노드에서 configuration-db 백업을 수집하려면 이 명령을 사용합니다.
request nms configuration-db backup path /opt/data/backup/
예상 출력은 다음과 같습니다.
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#
SCP를 사용하여 configuration-db 백업을 vManage의 /home/admin/ 디렉토리에 복사합니다.
샘플 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 -
configuration-db 백업을 복원하려면 먼저 configuration-db 자격 증명을 구성해야 합니다. configuration-db 자격 증명이 default(neo4j/password)인 경우 이 단계를 건너뛸 수 있습니다.
configuration-db 자격 증명을 구성하려면 nms configuration-db update-admin-user 명령을 사용합니다.선택한 사용자 이름과 비밀번호를 사용합니다.
vManage의 애플리케이션 서버가 다시 시작됩니다. 따라서 vManage UI에 짧은 시간 동안 액세스할 수 없게 됩니다.
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#
구성 DB 백업을 복원하기 위해 진행할 수 있는 게시:
nms configuration-db 복원 경로 /home/admin/< > 명령을 사용하여 configuration-db를 새 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
configuration-db가 복원되면 vManage UI에 액세스할 수 있는지 확인합니다. 약 5분 정도 기다린 후 UI에 액세스를 시도합니다.
UI에 성공적으로 로그인했으면 Edge 라우터 목록, 템플릿, 정책 및 이전 또는 기존 vManage UI에 존재했던 나머지 모든 컨피그레이션이 새 vManage UI에 반영되었는지 확인합니다.
2단계를 참조하십시오: 조합 2의 사전 검사: 독립형 vManage + 단일 노드 DR을 사용하고 재해 복구를 활성화하기 전에 모든 요구 사항을 완료했는지 확인합니다.
VPN 0의 대역 외 클러스터 인터페이스
vManage의 최소 구성은재해 복구 등록 전의 상태는 다음과 같습니다
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
참고: URL을 vBond 주소로 사용하는 경우 VPN 0 컨피그레이션에서 DNS 서버 IP 주소를 구성하거나 확인할 수 있는지 확인하십시오.
이러한 컨피그레이션은 라우터 및 나머지 컨트롤러와의 제어 연결을 설정하는 데 사용되는 전송 인터페이스를 활성화하는 데 필요합니다
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
컨트롤러에 대한 대역 외 관리 액세스를 활성화하도록 VPN 512 관리 인터페이스도 구성합니다.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
commit
vManage 노드에서 서비스 인터페이스를 구성합니다. 이 인터페이스는 DR 통신에 사용됩니다.
conf t
interface eth2
ip address
no shutdown
commit
기본 vManage 및 DR vManage의 서비스 인터페이스에 동일한 IP 서브넷이 사용되는지 확인합니다
섹션 조합 2에 제시된 단계를 진행합니다. 독립형 vManage + 단일 노드 DR 3단계: 재해 복구 vManage에 인증서를 설치하기 위해 vManage UI, 인증서 및 온보드 컨트롤러를 구성합니다.

입력을 마쳤으면 'Next(다음)'를 클릭합니다.
vBond 컨트롤러의 세부사항을 입력합니다.
vBond 컨트롤러는 지정된 IP 주소에서 Netconf를 통해 연결할 수 있어야 합니다.
자격 증명은 netadmin 사용자(dradmin)의 자격 증명이어야 하며 DR이 구성된 후에는 변경할 수 없습니다.
이를 위해서는 vBond에서 이 dradmin 사용자를 로컬로 구성하거나 admin 사용자를 사용하여 vBond를 추가할 수 있습니다.


Replication Schedule(복제 일정)에서 'Replication Interval(복제 간격)'을 설정합니다'.복제 간격 시간마다 데이터는 운영 시스템에서 복제됩니다. vManagto 보조 vManage. 최소 구성 가능 값은 15분입니다.


이 프로세스 중에 vManage GUI가 다시 시작됩니다.
작업을 마치면 성공 상태가 표시되어야 합니다.

Administration(관리) → Disaster Recovery(재해 복구)로 이동합니다.재해 복구 상태 및 마지막으로 데이터가 복제된 시간을 확인합니다.

configuration-db가 복원되면 패브릭에서 모든 새 컨트롤러(vmanage/vsmart/vbond)를 재인증해야 합니다
참고: 실제 프로덕션에서는 재인증에 사용되는 인터페이스 IP가 터널 인터페이스 IP인 경우 vManage, vSmart 및 vBond의 터널 인터페이스 및 경로에 따른 방화벽에서 NETCONF 서비스가 허용되는지 확인해야 합니다. 열 방화벽 포트는 DR 클러스터에서 모든 vBonds 및 vSmarts로의 양방향 규칙인 TCP 포트 830입니다.
vmanage UI에서 Configuration > Devices > Controllers를 클릭합니다

모든 컨트롤러가 온보딩되면 다음 단계를 완료합니다.
새로 활성화된 클러스터의 Cisco SD-WAN Manager 서버에서 다음 작업을 수행합니다.
루트 인증서를 새로 활성화된 클러스터의 모든 Cisco Catalyst SD-WAN 디바이스와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Cisco SD-WAN Manager UUID를 Cisco SD-WAN Validator와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/certificate/syncvbond
패브릭이 복원되고 패브릭의 모든 에지와 컨트롤러에 대해 제어 및 bfd 세션이 작동되면 UI에서 이전 컨트롤러(vmanage/vsmart/vbond)를 무효화해야 합니다
참고: 여기에 표시된 모든 구축 조합에 공통적으로 적용되는 Post Checks(사후 검사) 섹션을 계속 진행합니다.
필요한 인스턴스:
단계:
활성 Cisco SD-WAN Managerinstances의 수가 새로 설치된 Cisco SD-WAN Managerinstances의 수와 동일한지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 동일한 소프트웨어 버전을 실행하는지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 Cisco SD-WAN Validator의 관리 IP 주소에 연결할 수 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스에 인증서가 설치되어 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스를 포함하여 모든 Cisco Catalyst SD-WAN 디바이스의 시계가 동기화되었는지 확인합니다.
새 시스템 IP 및 사이트 ID 집합이 활성 클러스터와 동일한 기본 구성과 함께 새로 설치된 Cisco SD-WAN Manager 인스턴스에 구성되어 있는지 확인합니다.




자체 CA인 Enterprise Certificate Authority를 사용하는 경우 Enterprise를 선택합니다.


20.15/20.18 vManage 노드의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Control Components(제어 구성 요소)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
참고: vBonor의 관리자 자격 증명 또는 netadmingroup의 사용자 부분이 필요합니다. vBond의 CLI에서 이를 확인할 수 있습니다. vBond에 대한 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다
참고: vBond가 NAT 디바이스/방화벽 뒤에 있는 경우 vBond VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인합니다. vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스의 공용 IP 주소를 사용합니다

20.12 vManage의 경우 vSmart 추가 또는 20.15/20.18 vManage의 경우 컨트롤러 추가를 클릭합니다.
팝업이 열리면 vManage에서 연결할 수 있는 vSmart의 VPN 0 전송 IP를 입력합니다.
vManage의 CLI에서 vSmart IP로 허용되는 경우 ping을 사용하여 연결 가능성을 확인합니다.
vSmart의 사용자 자격 증명을 입력하십시오. vSmart의 관리자 자격 증명 또는 netadmin 그룹의 사용자 부분을 사용해야 합니다.
vSmart의 CLI에서 이를 확인할 수 있습니다.
라우터에 TLS를 사용하여 vSmart와의 제어 연결을 설정하려면 프로토콜을 TLS로 설정합니다. vSmarts 및 vManage 노드의 CLI에서도 이 구성을 구성해야 합니다.
vSmart용 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다.
참고: vSmart가 NAT 장치/방화벽 뒤에 있는 경우 vSmart VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인하고, vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스 IP의 공용 IP 주소를 사용합니다.

모든 단계가 완료되면 Monitor>Dashboard에서 모든 제어 구성 요소에 연결할 수 있는지 확인합니다


참고: SD-WAN 패브릭에 온보딩된 사이트의 수에 따라 vManage 클러스터를 3개의 vManage 노드 또는 6개의 vManage 노드로 구성할 수 있습니다. 기존 vManage 클러스터를 참조하고 동일한 노드 수를 선택하십시오.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
참고: URL을 vBond 주소로 사용하는 경우 VPN 0 컨피그레이션에서 DNS 서버 IP 주소를 구성하거나 확인할 수 있는지 확인하십시오.
이러한 컨피그레이션은 라우터 및 나머지 컨트롤러와의 제어 연결을 설정하는 데 사용되는 전송 인터페이스를 활성화하는 데 필요합니다.
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
컨트롤러에 대한 대역 외 관리 액세스를 활성화하도록 VPN 512 관리 인터페이스도 구성합니다.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
선택적 구성:
Conf t
security
control
protocol tls
commit
이미 온보딩된 vManage-1을 포함하여 모든 vManagenodes에서 서비스 인터페이스를 구성합니다. 이 인터페이스는 클러스터 통신에 사용됩니다. 즉, 클러스터에서 vManagenodes 간의 통신을 의미합니다.
conf t
interface eth2
ip address
no shutdown
commit
vManagecluster의 모든 노드에서 서비스 인터페이스에 동일한 IP 서브넷이 사용되는지 확인합니다.
vManagenodes의 동일한 관리자 자격 증명을 사용하여 vManagecluster를 구성할 수 있습니다. 그렇지 않으면 netadmingroup의 일부인 새 사용자 자격 증명을 구성할 수 있습니다. 새 사용자 자격 증명을 구성하기 위한 컨피그레이션은 다음과 같습니다
conf t
system
aaa
user
password
group netadmin
commit
클러스터의 일부인 모든 vManagenodessi에서 동일한 사용자 자격 증명을 구성해야 합니다.관리자 자격 증명을 사용하려면 모든 vManagenodes에서 동일한 사용자 이름/비밀번호여야 합니다.
Configuration(컨피그레이션) > Certificates(인증서) > Control Components(제어 구성 요소)(20.15/20.18 vManage 노드의 경우)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
Manager/vManage(관리자/vManage)에서 ...을 클릭하고 Generate CSR(CSR 생성)을 클릭합니다.

CSR이 생성되면 CSR을 다운로드하고 컨트롤러에 대해 선택한 인증 기관에 따라 CSR에 서명을 받을 수 있습니다. Administration > Settings > Controller Certificate Authorization에서 이 컨피그레이션을 확인할 수 있습니다. Cisco(권장)를 선택한 경우 vManage에서 CSR을 PNP 포털에 자동으로 업로드하고 인증서가 서명되면 vManage에 자동으로 설치됩니다.
Manual(수동)을 선택한 경우 해당 SD-WAN 오버레이의 Smart Account 및 Virtual Account로 이동하여 Cisco PNP 포털을 사용하여 CSR에 수동으로 서명합니다. Digicert 및 Enterprise Root Certificate를 사용하는 경우에도 동일한 절차를 적용할 수 있습니다.
PNP 포털에서 인증서를 사용할 수 있게 되면 vManage의 동일한 섹션에서 install certificate(인증서 설치)를 클릭하고 인증서를 업로드한 다음 인증서를 설치합니다.
클러스터의 일부인 모든 vManage 노드에서 이 단계를 완료합니다.
참고: 3노드 클러스터의 경우 3개의 vManage 노드 모두 컴퓨팅+데이터가 페르소나로 표시됩니다.

참고: SDAVC 활성화 - SDAVC가 필요하고 클러스터의 vManage 노드 하나에서만 필요한 경우에만 이 컨피그레이션을 기존 클러스터에서 참조하십시오.
Update(업데이트)를 클릭합니다.




클러스터에 다음 노드를 추가하기 전에 이러한 점을 고려해야 합니다.
지금까지 클러스터에 추가된 vManage 노드의 모든 UI에서 다음 사항을 확인하십시오.
모든 컨트롤러가 온보딩되면 다음 단계를 완료합니다.
참고: 재해 복구가 활성화된 기존 vManage 클러스터에서 컨피그레이션 데이터베이스 백업을 수집하는 동안 해당 노드의 재해 복구가 일시 중지되고 삭제된 후에 수집되어야 합니다.
진행 중인 재해 복구 복제가 없는지 확인합니다. Administration(관리) > Disaster Recovery(재해 복구) 및 상태가 Success(성공)이고 Import Pending(가져오기 보류 중), Export Pending(내보내기 보류 중) 또는 Download Pending(다운로드 보류 중)과 같은 일시적인 상태가 아닌지 확인합니다. 상태가 성공적이지 않으면 Cisco TAC에 문의하여 복제가 성공적인지 확인한 후 재해 복구를 일시 중지합니다.
먼저 재해 복구를 일시 중지하고 작업이 완료되었는지 확인합니다. 그런 다음 재해 복구를 삭제하고 작업이 완료되었는지 확인합니다.

Cisco TAC에 문의하여 재해 복구가 성공적으로 정리되었는지 확인합니다.
vManageCLI에서 requestnmsconfiguration-dbstatus 명령을 사용하여 동일한 사항을 확인할 수 있습니다. 출력은 다음과 같습니다
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 .
식별된 configuration-db leader vManage 노드에서 configuration-db 백업을 수집하려면 이 명령을 사용합니다.
request nms configuration-db backup path /opt/data/backup/
예상 출력은 다음과 같습니다.
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#
SCP를 사용하여 configuration-db 백업을 vManage의 /home/admin/ 디렉토리에 복사합니다.
샘플 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 -
configuration-db 백업을 복원하려면 먼저 configuration-db 자격 증명을 구성해야 합니다. configuration-db 자격 증명이 default(neo4j/password)인 경우 이 단계를 건너뛸 수 있습니다.
configuration-db 자격 증명을 구성하려면 nms configuration-db update-admin-user 명령을 사용합니다.선택한 사용자 이름과 비밀번호를 사용합니다.
vManage의 애플리케이션 서버가 다시 시작됩니다. 따라서 vManage UI에 짧은 시간 동안 액세스할 수 없게 됩니다.
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#
구성 DB 백업을 복원하기 위해 진행할 수 있는 게시:
nms configuration-db 복원 경로 /home/admin/< > 명령을 사용하여 configuration-db를 새 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
configuration-db가 복원되면 vManage UI에 액세스할 수 있는지 확인합니다. 약 5분 정도 기다린 후 UI에 액세스를 시도합니다.
UI에 성공적으로 로그인했으면 Edge 라우터 목록, 템플릿, 정책 및 이전 또는 기존 vManage UI에 존재했던 나머지 모든 컨피그레이션이 새 vManage UI에 반영되었는지 확인합니다.
configuration-db가 복원되면 패브릭에서 모든 새 컨트롤러(vmanage/vsmart/vbond)를 재인증해야 합니다
참고: 실제 프로덕션에서는 재인증에 사용되는 인터페이스 IP가 터널 인터페이스 IP인 경우 vManage, vSmart 및 vBond의 터널 인터페이스 및 경로에 따른 방화벽에서 NETCONF 서비스가 허용되는지 확인해야 합니다. 열 방화벽 포트는 DR 클러스터에서 모든 vBonds 및 vSmarts로의 양방향 규칙인 TCP 포트 830입니다.
vmanage UI에서 Configuration > Devices > Controllers를 클릭합니다

모든 컨트롤러가 온보딩되면 다음 단계를 완료합니다.
새로 활성화된 클러스터의 Cisco SD-WAN Manager 서버에서 다음 작업을 수행합니다.
루트 인증서를 새로 활성화된 클러스터의 모든 Cisco Catalyst SD-WAN 디바이스와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Cisco SD-WAN Manager UUID를 Cisco SD-WAN Validator와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/certificate/syncvbond
패브릭이 복원되고 패브릭의 모든 에지와 컨트롤러에 대해 제어 및 bfd 세션이 작동되면 UI에서 이전 컨트롤러(vmanage/vsmart/vbond)를 무효화해야 합니다
참고: 여기에 표시된 모든 구축 조합에 공통적으로 적용되는 Post Checks(사후 검사) 섹션을 계속 진행합니다.
수동/콜드 스탠바이 DR이란? 백업 SD-WAN 관리자 서버 또는 SD-WAN 관리자 클러스터는 콜드 스탠바이 상태로 종료됩니다.
활성 데이터베이스의 정기적인 백업이 수행되며 기본 SD-WAN 관리자 또는 SD-WAN 관리자 클러스터가 다운되면 대기 SD-WAN 관리자 또는 SD-WAN 관리자 클러스터가 수동으로 시작되고 백업 데이터베이스가 복원됩니다.
필요한 인스턴스:
단계:
활성 Cisco SD-WAN Manager 인스턴스의 수가 새로 설치된 Cisco SD-WAN Manager 인스턴스의 수와 동일한지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 동일한 소프트웨어 버전을 실행하는지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 Cisco SD-WAN Validator의 관리 IP 주소에 연결할 수 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스에 인증서가 설치되어 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스를 포함하여 모든 Cisco Catalyst SD-WAN 디바이스의 시계가 동기화되었는지 확인합니다.
새 시스템 IP 및 사이트 ID 집합이 활성 클러스터와 동일한 기본 구성과 함께 새로 설치된 Cisco SD-WAN Manager 인스턴스에 구성되어 있는지 확인합니다.




자체 CA인 Enterprise Certificate Authority를 사용하는 경우 Enterprise를 선택합니다.


20.15/20.18 vManage 노드의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Control Components(제어 구성 요소)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
참고: vBonor의 관리자 자격 증명 또는 netadmingroup의 사용자 부분이 필요합니다. vBond의 CLI에서 이를 확인할 수 있습니다. vBond에 대한 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다
참고: vBond가 NAT 디바이스/방화벽 뒤에 있는 경우 vBond VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인합니다. vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스의 공용 IP 주소를 사용합니다

20.12 vManage의 경우 vSmart 추가 또는 20.15/20.18 vManage의 경우 컨트롤러 추가를 클릭합니다.
팝업이 열리면 vManage에서 연결할 수 있는 vSmart의 VPN 0 전송 IP를 입력합니다.
vManage의 CLI에서 vSmart IP로 허용되는 경우 ping을 사용하여 연결 가능성을 확인합니다.
vSmart의 사용자 자격 증명을 입력하십시오. vSmart의 관리자 자격 증명 또는 netadmin 그룹의 사용자 부분을 사용해야 합니다.
vSmart의 CLI에서 이를 확인할 수 있습니다.
라우터에 TLS를 사용하여 vSmart와의 제어 연결을 설정하려면 프로토콜을 TLS로 설정합니다. vSmarts 및 vManage 노드의 CLI에서도 이 구성을 구성해야 합니다.
vSmart용 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다.
참고: vSmart가 NAT 장치/방화벽 뒤에 있는 경우 vSmart VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인하고, vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스 IP의 공용 IP 주소를 사용합니다.

모든 단계가 완료되면 Monitor>Dashboard에서 모든 제어 구성 요소에 연결할 수 있는지 확인합니다


참고: SD-WAN 패브릭에 온보딩된 사이트의 수에 따라 vManage 클러스터를 3개의 vManage 노드 또는 6개의 vManage 노드로 구성할 수 있습니다
"SD-WAN 오버레이에 단일 노드 vManage를 사용하여 SD-WAN 컨트롤러 온보드"에서 공유하는 단계를 진행하여 먼저 하나의 vManage 노드를 사용하여 SD-WAN 패브릭을 시작하고 필요한 모든 Validator(vBond) 및 컨트롤러(vSmart)를 온보딩합니다.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
참고: URL을 vBond 주소로 사용하는 경우 VPN 0 컨피그레이션에서 DNS 서버 IP 주소를 구성하거나 확인할 수 있는지 확인하십시오.
이러한 컨피그레이션은 라우터 및 나머지 컨트롤러와의 제어 연결을 설정하는 데 사용되는 전송 인터페이스를 활성화하는 데 필요합니다.
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
컨트롤러에 대한 대역 외 관리 액세스를 활성화하도록 VPN 512 관리 인터페이스도 구성합니다.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
선택적 구성:
Conf t
security
control
protocol tls
commit
이미 온보딩된 vManage-1을 포함하여 모든 vManagenodes에서 서비스 인터페이스를 구성합니다. 이 인터페이스는 클러스터 통신에 사용됩니다. 즉, 클러스터에서 vManagenodes 간의 통신을 의미합니다.
conf t
interface eth2
ip address
no shutdown
commit
vManagecluster의 모든 노드에서 서비스 인터페이스에 동일한 IP 서브넷이 사용되는지 확인합니다.
vManagenodes의 동일한 관리자 자격 증명을 사용하여 vManagecluster를 구성할 수 있습니다. 그렇지 않으면 netadmingroup의 일부인 새 사용자 자격 증명을 구성할 수 있습니다. 새 사용자 자격 증명을 구성하기 위한 컨피그레이션은 다음과 같습니다
conf t
system
aaa
user
password
group netadmin
commit
클러스터에 속하는 모든 vManagenodesisc에서 동일한 사용자 자격 증명을 구성해야 합니다.관리자 자격 증명을 사용하려면 모든 vManagenodes에서 동일한 사용자 이름/비밀번호여야 합니다.
Configuration(컨피그레이션) > Certificates(인증서) > Control Components(제어 구성 요소)(20.15/20.18 vManage 노드의 경우)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
Manager/vManage(관리자/vManage)에서 ...을 클릭하고 Generate CSR(CSR 생성)을 클릭합니다.

CSR이 생성되면 CSR을 다운로드하고 컨트롤러에 대해 선택한 인증 기관에 따라 CSR에 서명을 받을 수 있습니다. Administration > Settings > Controller Certificate Authorization에서 이 컨피그레이션을 확인할 수 있습니다. Cisco(권장)를 선택한 경우 vManage에서 CSR을 PNP 포털에 자동으로 업로드하고 인증서가 서명되면 vManage에 자동으로 설치됩니다.
Manual(수동)을 선택한 경우 해당 SD-WAN 오버레이의 Smart Account 및 Virtual Account로 이동하여 Cisco PNP 포털을 사용하여 CSR에 수동으로 서명합니다.
PNP 포털에서 인증서를 사용할 수 있게 되면 vManage의 동일한 섹션에서 install certificate(인증서 설치)를 클릭하고 인증서를 업로드한 다음 인증서를 설치합니다.
Digicert 및 Enterprise Root Certificate를 사용하는 경우에도 동일한 절차를 적용할 수 있습니다.
클러스터의 일부인 모든 vManage 노드에서 이 단계를 완료합니다.
참고: 3노드 클러스터의 경우 3개의 vManage 노드 모두 컴퓨팅+데이터가 페르소나로 표시됩니다.
선택적 구성:
SDAVC를 활성화하려면 기존 클러스터의 이 컨피그레이션을 참조하시기 바랍니다. SDAVC가 필요하고 클러스터의 한 vManage 노드에서만 필요한 경우에만 이 컨피그레이션을 확인해야 합니다.
Update(업데이트)를 클릭합니다.



클러스터에 다음 노드를 추가하기 전에 이러한 점을 고려해야 합니다.
지금까지 클러스터에 추가된 vManage 노드의 모든 UI에서 다음 사항을 확인하십시오.
4단계에 설명된 단계를 사용하여 vManage 클러스터를 하나 이상 시작할 수 있습니다. vManage 클러스터 구축 6단계에 설명된 단계를 완료하는 게시물: Config-db Backup/Restore - 대기 클러스터에서 config-db 백업을 복원합니다.
vManageCLI에서 requestnmsconfiguration-dbstatus 명령을 사용하여 동일한 사항을 확인할 수 있습니다. 출력은 다음과 같습니다
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 .
식별된 configuration-db leader vManage 노드에서 configuration-db 백업을 수집하려면 이 명령을 사용합니다.
request nms configuration-db backup path /opt/data/backup/
예상 출력은 다음과 같습니다.
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#
SCP를 사용하여 configuration-db 백업을 vManage의 /home/admin/ 디렉토리에 복사합니다.
샘플 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 -
configuration-db 백업을 복원하려면 먼저 configuration-db 자격 증명을 구성해야 합니다. configuration-db 자격 증명이 default(neo4j/password)인 경우 이 단계를 건너뛸 수 있습니다.
configuration-db 자격 증명을 구성하려면 nms configuration-db update-admin-user 명령을 사용합니다.선택한 사용자 이름과 비밀번호를 사용합니다.
vManage의 애플리케이션 서버가 다시 시작됩니다. 따라서 vManage UI에 짧은 시간 동안 액세스할 수 없게 됩니다.
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#
구성 DB 백업을 복원하기 위해 진행할 수 있는 게시:
nms configuration-db 복원 경로 /home/admin/< > 명령을 사용하여 configuration-db를 새 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
configuration-db가 복원되면 vManage UI에 액세스할 수 있는지 확인합니다. 약 5분 정도 기다린 후 UI에 액세스를 시도합니다.
UI에 성공적으로 로그인했으면 Edge 라우터 목록, 템플릿, 정책 및 이전 또는 기존 vManage UI에 존재했던 나머지 모든 컨피그레이션이 새 vManage UI에 반영되었는지 확인합니다.
configuration-db가 복원되면 패브릭에서 모든 새 컨트롤러(vmanage/vsmart/vbond)를 재인증해야 합니다
참고: 실제 프로덕션에서는 재인증에 사용되는 인터페이스 IP가 터널 인터페이스 IP인 경우 vManage, vSmart 및 vBond의 터널 인터페이스 및 경로에 따른 방화벽에서 NETCONF 서비스가 허용되는지 확인해야 합니다. 열 방화벽 포트는 DR 클러스터에서 모든 vBonds 및 vSmarts로의 양방향 규칙인 TCP 포트 830입니다.
vmanage UI에서 Configuration > Devices > Controllers를 클릭합니다

모든 컨트롤러가 온보딩되면 다음 단계를 완료합니다.
새로 활성화된 클러스터의 Cisco SD-WAN Manager 서버에서 다음 작업을 수행합니다.
루트 인증서를 새로 활성화된 클러스터의 모든 Cisco Catalyst SD-WAN 디바이스와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Cisco SD-WAN Manager UUID를 Cisco SD-WAN Validator와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/certificate/syncvbond
패브릭이 복원되고 패브릭의 모든 에지와 컨트롤러에 대해 제어 및 bfd 세션이 작동되면 UI에서 이전 컨트롤러(vmanage/vsmart/vbond)를 무효화해야 합니다
참고: 여기에 표시된 모든 구축 조합에 공통적으로 적용되는 Post Checks(사후 검사) 섹션을 계속 진행합니다.
필요한 인스턴스:
단계:
활성 Cisco SD-WAN Manager 인스턴스의 수가 새로 설치된 Cisco SD-WAN Manager 인스턴스의 수와 동일한지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 동일한 소프트웨어 버전을 실행하는지 확인합니다.
모든 활성 및 새로운 Cisco SD-WAN Manager 인스턴스가 Cisco SD-WAN Validator의 관리 IP 주소에 연결할 수 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스에 인증서가 설치되어 있는지 확인합니다.
새로 설치된 Cisco SD-WAN Manager 인스턴스를 포함하여 모든 Cisco Catalyst SD-WAN 디바이스의 시계가 동기화되었는지 확인합니다.
새 시스템 IP 및 사이트 ID 집합이 활성 클러스터와 동일한 기본 구성과 함께 새로 설치된 Cisco SD-WAN Manager 인스턴스에 구성되어 있는지 확인합니다.




자체 CA인 Enterprise Certificate Authority를 사용하는 경우 Enterprise를 선택합니다.


20.15/20.18 vManage 노드의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Control Components(제어 구성 요소)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
참고: vBonor의 관리자 자격 증명 또는 netadmingroup의 사용자 부분이 필요합니다. vBond의 CLI에서 이를 확인할 수 있습니다. vBond에 대한 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다
참고: vBond가 NAT 디바이스/방화벽 뒤에 있는 경우 vBond VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인합니다. vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스의 공용 IP 주소를 사용합니다

20.12 vManage의 경우 vSmart 추가 또는 20.15/20.18 vManage의 경우 컨트롤러 추가를 클릭합니다.
팝업이 열리면 vManage에서 연결할 수 있는 vSmart의 VPN 0 전송 IP를 입력합니다.
vManage의 CLI에서 vSmart IP로 허용되는 경우 ping을 사용하여 연결 가능성을 확인합니다.
vSmart의 사용자 자격 증명을 입력하십시오. vSmart의 관리자 자격 증명 또는 netadmin 그룹의 사용자 부분을 사용해야 합니다.
vSmart의 CLI에서 이를 확인할 수 있습니다.
라우터에 TLS를 사용하여 vSmart와의 제어 연결을 설정하려면 프로토콜을 TLS로 설정합니다. vSmarts 및 vManage 노드의 CLI에서도 이 구성을 구성해야 합니다.
vSmart용 새 인증서를 설치해야 하는 경우 "Generate CSR(CSR 생성)" 드롭다운에서 Yes(예)를 선택합니다.
참고: vSmart가 NAT 장치/방화벽 뒤에 있는 경우 vSmart VPN 0 인터페이스 IP가 공용 IP로 변환되었는지 확인하고, vManage에서 VPN 0 인터페이스 IP에 연결할 수 없는 경우 이 단계에서 VPN 0 인터페이스 IP의 공용 IP 주소를 사용합니다.

모든 단계가 완료되면 Monitor>Dashboard에서 모든 제어 구성 요소에 연결할 수 있는지 확인합니다


참고: SD-WAN 패브릭에 온보딩된 사이트의 수에 따라 vManage 클러스터를 3개의 vManage 노드 또는 6개의 vManage 노드로 구성할 수 있습니다
"SD-WAN 오버레이에 단일 노드 vManage를 사용하여 SD-WAN 컨트롤러 온보드"에서 공유하는 단계를 진행하여 먼저 하나의 vManage 노드를 사용하여 SD-WAN 패브릭을 시작하고 필요한 모든 Validator(vBond) 및 컨트롤러(vSmart)를 온보딩합니다.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
참고: URL을 vBond 주소로 사용하는 경우 VPN 0 컨피그레이션에서 DNS 서버 IP 주소를 구성하거나 확인할 수 있는지 확인하십시오.
이러한 컨피그레이션은 라우터 및 나머지 컨트롤러와의 제어 연결을 설정하는 데 사용되는 전송 인터페이스를 활성화하는 데 필요합니다.
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
컨트롤러에 대한 대역 외 관리 액세스를 활성화하도록 VPN 512 관리 인터페이스도 구성합니다.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
선택적 구성:
Conf t
security
control
protocol tls
commit
이미 온보딩된 vManage-1을 포함하여 모든 vManagenodes에서 서비스 인터페이스를 구성합니다. 이 인터페이스는 클러스터 통신에 사용됩니다. 즉, 클러스터에서 vManagenodes 간의 통신을 의미합니다.
conf t
interface eth2
ip address
no shutdown
commit
vManagecluster의 모든 노드에서 서비스 인터페이스에 동일한 IP 서브넷이 사용되는지 확인합니다.
vManagenodes의 동일한 관리자 자격 증명을 사용하여 vManagecluster를 구성할 수 있습니다. 그렇지 않으면 netadmingroup의 일부인 새 사용자 자격 증명을 구성할 수 있습니다. 새 사용자 자격 증명을 구성하기 위한 컨피그레이션은 다음과 같습니다
conf t
system
aaa
user
password
group netadmin
commit
클러스터에 속하는 모든 vManagenodesisc에서 동일한 사용자 자격 증명을 구성해야 합니다.관리자 자격 증명을 사용하려면 모든 vManagenodes에서 동일한 사용자 이름/비밀번호여야 합니다.
Configuration(컨피그레이션) > Certificates(인증서) > Control Components(제어 구성 요소)(20.15/20.18 vManage 노드의 경우)로 이동합니다. 20.9/20.12 버전의 경우 Configuration(컨피그레이션) > Devices(디바이스) > Controllers(컨트롤러)
Manager/vManage(관리자/vManage)에서 ...을 클릭하고 Generate CSR(CSR 생성)을 클릭합니다.

CSR이 생성되면 CSR을 다운로드하고 컨트롤러에 대해 선택한 인증 기관에 따라 CSR에 서명을 받을 수 있습니다. Administration > Settings > Controller Certificate Authorization에서 이 컨피그레이션을 확인할 수 있습니다. Cisco(권장)를 선택한 경우 vManage에서 CSR을 PNP 포털에 자동으로 업로드하고 인증서가 서명되면 vManage에 자동으로 설치됩니다.
Manual(수동)을 선택한 경우 해당 SD-WAN 오버레이의 Smart Account 및 Virtual Account로 이동하여 Cisco PNP 포털을 사용하여 CSR에 수동으로 서명합니다.
PNP 포털에서 인증서를 사용할 수 있게 되면 vManage의 동일한 섹션에서 install certificate(인증서 설치)를 클릭하고 인증서를 업로드한 다음 인증서를 설치합니다.
Digicert 및 Enterprise Root Certificate를 사용하는 경우에도 동일한 절차를 적용할 수 있습니다.
클러스터의 일부인 모든 vManage 노드에서 이 단계를 완료합니다.
참고: 3노드 클러스터의 경우 3개의 vManage 노드 모두 컴퓨팅+데이터가 페르소나로 표시됩니다. 6노드 클러스터의 경우 3개의 vManage 노드가 compute+data를 페르소나로, 3개의 vManage 노드가 data를 페르소나로 가져옵니다.

선택적 구성:
SDAVC를 활성화하려면 기존 클러스터의 이 컨피그레이션을 참조하시기 바랍니다. SDAVC가 필요하고 클러스터의 한 vManage 노드에서만 필요한 경우에만 이 컨피그레이션을 확인해야 합니다.
Update(업데이트)를 클릭합니다.



클러스터에 다음 노드를 추가하기 전에 이러한 점을 고려해야 합니다.
지금까지 클러스터에 추가된 vManage 노드의 모든 UI에서 다음 사항을 확인하십시오.
참고: 재해 복구가 활성화된 기존 vManage 클러스터에서 컨피그레이션 데이터베이스 백업을 수집하는 동안 해당 노드의 재해 복구가 일시 중지되고 삭제된 후에 수집되어야 합니다.
진행 중인 재해 복구 복제가 없는지 확인합니다. Administration(관리) > Disaster Recovery(재해 복구) 및 상태가 Success(성공)이고 Import Pending(가져오기 보류 중), Export Pending(내보내기 보류 중) 또는 Download Pending(다운로드 보류 중)과 같은 일시적인 상태가 아닌지 확인합니다. 상태가 성공적이지 않으면 Cisco TAC에 문의하여 복제가 성공적인지 확인한 후 재해 복구를 일시 중지합니다.
먼저 재해 복구를 일시 중지하고 작업이 완료되었는지 확인합니다. 그런 다음 재해 복구를 삭제하고 작업이 완료되었는지 확인합니다.

Cisco TAC에 문의하여 재해 복구가 성공적으로 정리되었는지 확인합니다.
vManageCLI에서 requestnmsconfiguration-dbstatus 명령을 사용하여 동일한 사항을 확인할 수 있습니다. 출력은 다음과 같습니다
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 .
식별된 configuration-db leader vManage 노드에서 configuration-db 백업을 수집하려면 이 명령을 사용합니다.
request nms configuration-db backup path /opt/data/backup/
예상 출력은 다음과 같습니다.
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#
SCP를 사용하여 configuration-db 백업을 vManage의 /home/admin/ 디렉토리에 복사합니다.
샘플 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 -
configuration-db 백업을 복원하려면 먼저 configuration-db 자격 증명을 구성해야 합니다. configuration-db 자격 증명이 default(neo4j/password)인 경우 이 단계를 건너뛸 수 있습니다.
configuration-db 자격 증명을 구성하려면 nms configuration-db update-admin-user 명령을 사용합니다.선택한 사용자 이름과 비밀번호를 사용합니다.
vManage의 애플리케이션 서버가 다시 시작됩니다. 따라서 vManage UI에 짧은 시간 동안 액세스할 수 없게 됩니다.
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#
구성 DB 백업을 복원하기 위해 진행할 수 있는 게시:
nms configuration-db 복원 경로 /home/admin/< > 명령을 사용하여 configuration-db를 새 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
configuration-db가 복원되면 vManage UI에 액세스할 수 있는지 확인합니다. 약 5분 정도 기다린 후 UI에 액세스를 시도합니다.
UI에 성공적으로 로그인했으면 Edge 라우터 목록, 템플릿, 정책 및 이전 또는 기존 vManage UI에 존재했던 나머지 모든 컨피그레이션이 새 vManage UI에 반영되었는지 확인합니다.
중요 사전 점검
재해 복구를 진행하려면 두 개의 별도의 vManage 3노드 클러스터를 구성하고 작동해야 합니다. 활성 클러스터에는 검증자 및 컨트롤러가 온보딩되어야 합니다. DR 사이트에 검증기와 컨트롤러가 있는 경우, DR vManage 클러스터가 아니라 활성 클러스터에서도 온보딩해야 합니다.
Cisco에서는 재해 복구를 등록하기 전에 다음 요구 사항을 충족해야 한다고 권장합니다.
설정
vManage 재해 복구에 대한 자세한 내용은 이 링크를 참조하십시오.
각 SD-WAN 관리자에 최소 컨피그레이션이 있고 인증 부분이 완료되었다고 가정할 때 두 개의 개별 3-노드 클러스터가 이미 생성됩니다.
두 클러스터에서 Administration(관리) > Cluster Management(클러스터 관리)로 이동하고 모든 노드가 준비 상태인지 확인합니다.
DC vManage

DR vmanage

Administration(관리) >Disaster Recovery of Primary vManage Cluster(기본 vManage 클러스터의 재해 복구)로 이동합니다. Manage Disaster Recovery를 클릭합니다.

팝업 창에서 기본 및 보조 vManage의 세부사항을 모두 입력합니다.
표시할 IP 주소는 OOB(Out of Band) 클러스터 인터페이스 IP 주소입니다. 각 클러스터에서 vManage-1의 VPN 0 서비스 인터페이스의 IP 주소를 사용하는 것이 좋습니다.
자격 증명은 netadmin 사용자의 자격 증명이어야 하며 DR이 구성된 후에는 삭제되지 않는 한 변경할 수 없습니다. 재해 복구를 위한 별도의 vManage 로컬 사용자 자격 증명을 사용할 수 있습니다. vManage 로컬 사용자가 netadmin 그룹의 일부인지 확인해야 합니다. 관리자 자격 증명도 여기에서 사용할 수 있습니다.

입력을 마쳤으면 다음을 클릭합니다.
vBond 컨트롤러는 지정된 IP 주소에서 Netconf를 통해 연결할 수 있어야 합니다.

입력을 마쳤으면 다음을 클릭합니다.


값을 설정하고 저장을 클릭합니다.

확인
Administration(관리)>Disaster Recovery(재해 복구)로 이동하여 재해 복구 상태 및 마지막으로 데이터가 복제된 시기를 확인합니다.

참고: 복제는 데이터베이스 크기에 따라 몇 시간이 걸릴 수 있습니다. 또한 성공적인 복제를 위해서는 몇 번의 사이클이 필요할 수 있습니다.
configuration-db가 복원되면 패브릭에서 모든 새 컨트롤러(vmanage/vsmart/vbond)를 재인증해야 합니다
참고: 실제 프로덕션에서는 재인증에 사용되는 인터페이스 IP가 터널 인터페이스 IP인 경우 vManage, vSmart 및 vBond의 터널 인터페이스 및 경로에 따른 방화벽에서 NETCONF 서비스가 허용되는지 확인해야 합니다. 열 방화벽 포트는 DR 클러스터에서 모든 vBonds 및 vSmarts로의 양방향 규칙인 TCP 포트 830입니다.
vmanage UI에서 Configuration > Devices > Controllers를 클릭합니다

모든 컨트롤러가 온보딩되면 다음 단계를 완료합니다.
새로 활성화된 클러스터의 Cisco SD-WAN Manager 서버에서 다음 작업을 수행합니다.
루트 인증서를 새로 활성화된 클러스터의 모든 Cisco Catalyst SD-WAN 디바이스와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Cisco SD-WAN Manager UUID를 Cisco SD-WAN Validator와 동기화하려면 다음 명령을 입력합니다.
https://vmanage-url/dataservice/certificate/syncvbond
패브릭이 복원되고 패브릭의 모든 에지와 컨트롤러에 대해 제어 및 bfd 세션이 작동되면 UI에서 이전 컨트롤러(vmanage/vsmart/vbond)를 무효화해야 합니다
이러한 사후 검사는 모든 구축 조합에 적용됩니다.
request platform software sdwan vedge_cloud activate chassis-number token
항목이 예상대로 표시되는지 확인합니다.
템플릿
정책
디바이스 페이지(두 탭 모두)WAN vEdge ListControllers
vManage 노드에 적용 가능:
Configuration-DB(Neo4j) 검사:
모든 vManage 노드에서 "request nms configuration-db diagnostics" 명령을 실행합니다.
1. Node online 및 Leadership 상태 확인: (일부 버전에서는 사용할 수 없음)
"Neo4j"는 온라인으로 3개의 노드와 1개의 리더 및 2개의 팔로워를 표시해야 합니다. "system"은 또한 3개의 노드를 온라인으로 표시하고 1개의 지시자와 2개의 팔로워를 표시해야 합니다. 그러나 기본 Db가 아니므로 기본 플래그는 false입니다. 각 neo4j에 3개 미만의 항목이 있고 시스템은 노드가 클러스터에서 떨어진 것을 의미합니다. 동일한 문제를 해결하려면 Cisco TAC에 문의하십시오.
2. 노드가 "quarantine"인지 확인합니다.

노드가 격리 상태에 있어서는 안 됩니다.
3. 스키마 유효성 검사는 "성공"해야 합니다.

4. "nms configuration-db 진단 요청" 명령을 사용하여 configuration-db 백업을 수집하고 성공했는지 확인합니다.

불일치나 오류가 발견되면 Cisco TAC에 문의하여 문제를 해결하십시오.
또는 이러한 API 호출을 실행하여 클러스터에 대한 vmanage 노드 상태(모든 COMPUTE+DATA 노드에 대해)를 확인할 수 있습니다. 이 작업은 버전 20.12 이상에서만 작동합니다
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 클러스터에 neo4j와 system 모두에 대해 하나의 지시자만 있고 나머지는 추종자로 유지되는지 확인합니다. 모든 노드가 온라인 상태인지 확인합니다. 노드가 3개인 경우(모두 COMPUTE+DATA) neo4j와 system 모두에 대해 하나의 지시자만 있어야 합니다. 편차가 있으면 TAC에 문의해야 합니다.
5. 디스크, 메모리, IO 오류에 대해서는 /var/log/kern.log을 참조하십시오. 모든 vManage 노드에서 이를 확인해야 합니다.
6. 각 노드 사이에 CC가 없는 vmanage에 대한 새 클러스터를 구성할 때 단계를 확인합니다
노드 1에서 다른 노드 클러스터 ip로 vmanage-admin으로 ssh를 수행하고 그 반대로 공개 키가 교환되고 비밀번호에서 ssh가 덜 작동하는지 확인합니다. [다음 단계에 동의함 토큰이 필요함]
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:
출력에서 비밀번호를 입력하도록 요청하는 경우 TAC에 문의하십시오.
모든 SD-WAN 컨트롤러에 적용 가능(vBond, vManage, vSmart):
오버레이의 모든 컨트롤러에서 명령을 실행하고 vManage UUID 및 일련 번호가 현재 패브릭에 대해 유효한지 확인합니다.
vBond 명령:
show orchestrator valid-vsmarts
show orchestrator valid-vmanage-id
vManage/vSmart 명령:
show control valid-vsmarts
show control valid-vmanage-id
show control valid-vsmarts의 출력에는 vSmarts 및 vManage 노드의 일련 번호가 모두 포함됩니다.
vManage UI에 표시된 것과 비교합니다. Configuration(컨피그레이션) > Certificates(인증서) > Controllers(컨트롤러) 섹션으로 이동합니다.
현재 패브릭에 온보딩되지 않은 UUID/일련 번호에 대한 추가 항목이 있으면 해당 항목을 삭제해야 합니다. Cisco TAC에 문의할 수도 있습니다.
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
25-Feb-2026
|
최초 릴리스 |
피드백