本產品的文件集力求使用無偏見用語。針對本文件集的目的,無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言,或引用第三方產品的語言,因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。
思科已使用電腦和人工技術翻譯本文件,讓全世界的使用者能夠以自己的語言理解支援內容。請注意,即使是最佳機器翻譯,也不如專業譯者翻譯的內容準確。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 vManage = Cisco Catalyst Manager、Cisco vBond = Cisco Catalyst Validator、Cisco vSmart = Cisco Catalyst Controller
從思科軟體下載頁面下載SD-WAN控制器的OVA檔案:
附註:在ESXi/雲平台上使用OVA檔案啟動vSmart、vBond和vManage控制器。請參閱連結的文檔,並確保根據SD-WAN部署型別為所有控制器分配了足夠的CPU、RAM和磁碟。導航到此處以獲取其他資訊。請確保將輔助磁碟分配給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 Catalyst SD-WAN 裝置(包括新安裝的Cisco SD-WAN Manager例項)上的時鐘都同步。
確保在新安裝的Cisco SD-WAN Manager例項上配置一組新的系統IP和站點ID,並與活動群集配置相同的基本配置。




如果使用CA(企業證書頒發機構),請選擇Enterprise。


如果是20.15/20.18 vManage節點,請導航到Configuration > Devices > Control Components。在20.9/20.12版本的情況下,Configuration > Devices > Controllers
注意:我們需要使用vBondor的admin憑據作為netadmingroup的使用者部分。您可以在vBond的CLI中驗證這一點。如需安裝vBond的新憑證,請在「產生CSR」下拉式清單中選擇「是」。
附註:如果vBond位於NAT裝置/防火牆之後,請檢查vBond VPN 0介面IP是否已轉換為公共IP。如果無法從vManage訪問VPN 0介面IP,則在此步驟中使用VPN 0介面的公用IP地址。

在20.12 vManage的情況下按一下Add vSmart,在20.15/20.18 vManage的情況下按一下Add Controller。
系統開啟一個彈出視窗,輸入vSmart的VPN 0傳輸IP(可從vManage訪問)。
如果允許,請從vManage的CLI到vSmart IP使用ping檢查可達性。
輸入vSmart Note的使用者憑據,我們需要使用vSmart的管理員憑據或netadmin組的使用者部分。
您可以在vSmart的CLI中驗證這一點。
如果希望路由器使用TLS來建立與vSmart的控制連線,請將協定設定為TLS。此配置也需要在vSmarts和vManage節點的CLI上配置。
如需安裝vSmart的新憑證,請在「產生CSR」下拉式清單中選擇「是」。
註:如果vSmart位於NAT裝置/防火牆之後,請檢查vSmart VPN 0介面IP是否已轉換為公共IP,如果無法從vManage訪問VPN 0介面IP,請在此步驟中使用VPN 0介面IP的公共IP地址。

完成所有步驟後,驗證是否可以在Monitor>Dashboard中訪問所有控制元件


確認configuration-db正在vManage節點上運行。
您可以在vManageCLI上使用request nms configuration-db status命令進行驗證。輸出如下
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領導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 backup複製到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憑據。如果您的配置資料庫憑據是預設值(neo4j/password),則可以跳過此步驟。
要配置configuration-db憑據,請使用命令request 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#
可以繼續還原配置資料庫備份的開機自檢:
我們可以使用命令request nms configuration-db restore path /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後,請確保邊緣路由器清單、模板、策略以及以前或現有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驗證器同步:
https://vmanage-url/dataservice/certificate/syncvbond
在交換矩陣恢復後,交換矩陣中的所有邊緣和控制器的控制和bfd會話均已啟動,我們需要從UI使舊控制器(vmanage/vsmart/vbond)失效
附註:繼續使用此處顯示的「後檢查」部分,它對所有部署組合都是通用的。
確保活動的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 Catalyst SD-WAN 裝置(包括新安裝的Cisco SD-WAN Manager例項)上的時鐘都同步。
確保在新安裝的Cisco SD-WAN Manager例項上配置一組新的系統IP和站點ID,並與活動群集配置相同的基本配置。




如果使用CA(企業證書頒發機構),請選擇Enterprise。


如果是20.15/20.18 vManage節點,請導航到Configuration > Devices > Control Components。若為20.9/20.12版本,請輸入Configuration > Devices > Controllers
注意:我們需要使用vBondor的admin憑據作為netadmingroup的使用者部分。您可以在vBond的CLI中驗證這一點。如需安裝vBond的新憑證,請在「產生CSR」下拉式清單中選擇Yes
附註:如果vBond位於NAT裝置/防火牆之後,請檢查vBond VPN 0介面IP是否已轉換為公共IP。如果無法從vManage訪問VPN 0介面IP,則在此步驟中使用VPN 0介面的公用IP地址

在20.12 vManage的情況下按一下Add vSmart,在20.15/20.18 vManage的情況下按一下Add Controller。
系統開啟一個彈出視窗,輸入vSmart的VPN 0傳輸IP(可從vManage訪問)。
如果允許,請從vManage的CLI到vSmart IP使用ping檢查可達性。
輸入vSmart Note的使用者憑據,我們需要使用vSmart的管理員憑據或netadmin組的使用者部分。
您可以在vSmart的CLI中驗證這一點。
如果希望路由器使用TLS來建立與vSmart的控制連線,請將協定設定為TLS。此配置也需要在vSmarts和vManage節點的CLI上配置。
如需安裝vSmart的新憑證,請在「產生CSR」下拉式清單中選擇「是」。
註:如果vSmart位於NAT裝置/防火牆之後,請檢查vSmart VPN 0介面IP是否已轉換為公共IP,如果無法從vManage訪問VPN 0介面IP,請在此步驟中使用VPN 0介面IP的公共IP地址。

完成所有步驟後,驗證是否可以在Monitor>Dashboard中訪問所有控制元件


附註:從已啟用災難恢復的現有vManage節點收集配置資料庫備份時,請確保在該節點上的災難恢復暫停並刪除後收集該備份。
確認沒有正在進行的災難恢復複製。導航到管理>災難恢復和 確保狀態為「成功」,而不是處於「匯入掛起」、「匯出掛起」或「下載掛起」等暫時狀態。如果狀態不成功,請聯絡Cisco TAC並確保複製成功,然後繼續暫停災難恢復。
首先暫停災難恢復並確保任務完成。然後刪除災難恢復並確認任務已完成。

聯絡Cisco TAC,確保已成功清理災難恢復。
確認configuration-db正在vManage節點上運行。
您可以使用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領導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 backup複製到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憑據。如果您的配置資料庫憑據是預設值(neo4j/password),則可以跳過此步驟。
要配置configuration-db憑據,請使用request 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#
可以繼續還原配置資料庫備份的開機自檢:
我們可以使用命令request nms configuration-db restore path /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後,請確保邊緣路由器清單、模板、策略以及以前或現有vManage UI上存在的所有其餘配置都反映在新的vManage UI上。
請參閱步驟2:Combination 2:中的預檢查獨立式vManage +單節點災難恢復,並確保我們已經完成所有要求,然後我們開始啟用災難恢復。
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 512management介面以啟用對控制器的帶外管理訪問。
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
確保同一IP子網用於主vManage和DR vManage上的服務介面。
繼續執行Combination 2部分中提供的步驟:獨立vManage +單節點DR第3步:配置vManage UI、證書和板載控制器,以在災難恢復vManage上安裝該證書。

填寫完畢後,按一下「下一步」。
填寫vBond控制器的詳細資訊。
vBond控制器必須能夠通過Netconf以指定的IP地址訪問。
憑據必須是netadmin使用者(dradmin)的憑據,並且配置DR後不能更改這些憑據。
為此,建議在本地配置此dradmin使用者,或者可以使用admin使用者新增vBond。


在複製計畫中,設定「複製間隔」'。每次複製間隔時間,資料都會從主節點複製 vManagement到輔助vManage。最小可配置值為15分鐘。


請注意,vManage GUI在此過程中重新啟動。
完成後,必須看到Success狀態。

導覽至管理→ 災難恢復檢視災難恢復狀態以及上次複製資料的時間。

恢復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驗證器同步:
https://vmanage-url/dataservice/certificate/syncvbond
在交換矩陣恢復後,交換矩陣中的所有邊緣和控制器的控制和bfd會話均已啟動,我們需要從UI使舊控制器(vmanage/vsmart/vbond)失效
附註:繼續使用此處顯示的「後檢查」部分,它對所有部署組合都是通用的。
所需例項:
步驟:
確保活動的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 Catalyst SD-WAN 裝置(包括新安裝的Cisco SD-WAN Manager例項)上的時鐘都同步。
確保在新安裝的Cisco SD-WAN Manager例項上配置一組新的系統IP和站點ID,並與活動群集配置相同的基本配置。




如果使用CA(企業證書頒發機構),請選擇Enterprise。


如果是20.15/20.18 vManage節點,請導航到Configuration > Devices > Control Components。若為20.9/20.12版本,請輸入Configuration > Devices > Controllers
注意:我們需要使用vBondor的admin憑據作為netadmingroup的使用者部分。您可以在vBond的CLI中驗證這一點。如需安裝vBond的新憑證,請在「產生CSR」下拉式清單中選擇Yes
附註:如果vBond位於NAT裝置/防火牆之後,請檢查vBond VPN 0介面IP是否已轉換為公共IP。如果無法從vManage訪問VPN 0介面IP,則在此步驟中使用VPN 0介面的公用IP地址

在20.12 vManage的情況下按一下Add vSmart,在20.15/20.18 vManage的情況下按一下Add Controller。
系統開啟一個彈出視窗,輸入vSmart的VPN 0傳輸IP(可從vManage訪問)。
如果允許,請從vManage的CLI到vSmart IP使用ping檢查可達性。
輸入vSmart Note的使用者憑據,我們需要使用vSmart的管理員憑據或netadmin組的使用者部分。
您可以在vSmart的CLI中驗證這一點。
如果希望路由器使用TLS來建立與vSmart的控制連線,請將協定設定為TLS。此配置也需要在vSmarts和vManage節點的CLI上配置。
如需安裝vSmart的新憑證,請在「產生CSR」下拉式清單中選擇「是」。
註:如果vSmart位於NAT裝置/防火牆之後,請檢查vSmart VPN 0介面IP是否已轉換為公共IP,如果無法從vManage訪問VPN 0介面IP,請在此步驟中使用VPN 0介面IP的公共IP地址。

完成所有步驟後,驗證是否可以在Monitor>Dashboard中訪問所有控制元件


注意:vManage集群可以配置3個vManage節點或6個vManage節點,具體取決於註冊到SD-WAN交換矩陣的站點數量。請參考現有的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 512management介面以啟用對控制器的帶外管理訪問。
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
在已登入的所有vManagenodes(包括vManage-1)上配置服務介面。此介面用於集群通訊,表示集群中vManagenodes之間的通訊。
conf t
interface eth2
ip address
no shutdown
commit
確保同一IP子網用於vManagecluster中所有節點上的服務介面。
我們可以使用vManagenodes的相同管理憑據來配置vManagecluster。否則,我們可以配置作為netadmingroup一部分的新使用者憑據。配置新使用者憑據的配置如下所示
conf t
system
aaa
user
password
group netadmin
commit
確保在屬於群集的所有vManagenode上配置相同的使用者憑據。如果我們決定使用管理員憑據,則必須在所有vManagenode上配置相同的使用者名稱/密碼。
如果是20.15/20.18 vManage節點,請導航到Configuration > Certificates > Control Components。若為20.9/20.12版本,請輸入Configuration > Devices > Controllers
按一下Manager/vManage的……並按一下Generate CSR。

產生CSR後,您可以下載CSR,並根據為控制器選擇的憑證授權進行簽名。您可以在管理>設定>控制器憑證授權中驗證此組態。如果選擇Cisco(建議),則vManage會自動將CSR上傳到PNP門戶,並且證書簽署後,會自動將其安裝在vManage上。
如果選擇「手動」,請導航到相應SD-WAN重疊的智慧帳戶和虛擬帳戶,以使用思科PNP門戶手動簽署CSR。如果使用Digicert和企業根證書,則適用相同的程式。
證書從PNP門戶可用後,在vManage的同一部分中按一下安裝證書,然後上傳證書並安裝證書。
跨屬於群集的所有vManage節點完成此步驟。
附註:對於一個3節點群集,所有3個vManage節點都以compute+data作為角色。

附註:請參考現有群集中的此配置以啟用SDAVC — 僅當需要並且僅需要在群集的一個vManage節點上時,才需要選中。
按一下「更新」。




將下一個節點新增到群集之前,需要考慮以下幾點:
請在已新增到群集的所有vManage節點的UI上驗證這些點:
載入所有控制器後,完成以下步驟:
附註:從已啟用災難恢復的現有vManage群集收集配置資料庫備份時,請確保在該節點上的災難恢復暫停並刪除後收集該備份。
確認沒有正在進行的災難恢復複製。導航到管理>災難恢復和 確保狀態為「成功」,而不是處於「匯入掛起」、「匯出掛起」或「下載掛起」等暫時狀態。如果狀態不成功,請聯絡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領導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 backup複製到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憑據。如果您的配置資料庫憑據是預設值(neo4j/password),則可以跳過此步驟。
要配置configuration-db憑據,請使用request 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#
可以繼續還原配置資料庫備份的開機自檢:
我們可以使用命令request nms configuration-db restore path /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後,請確保邊緣路由器清單、模板、策略以及以前或現有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驗證器同步:
https://vmanage-url/dataservice/certificate/syncvbond
在交換矩陣恢復後,交換矩陣中的所有邊緣和控制器的控制和bfd會話均已啟動,我們需要從UI使舊控制器(vmanage/vsmart/vbond)失效
附註:繼續使用此處顯示的「後檢查」部分,它對所有部署組合都是通用的。
什麼是手動/冷備份DR — 備份SD-WAN Manager伺服器或SD-WAN Manager群集在冷備份狀態下保持關閉。
對活動資料庫進行常規備份,如果主SD-WAN Manager或SD-WAN Manager群集關閉,則手動啟動備用SD-WAN Manager或SD-WAN Manager群集,並在其上恢復備份資料庫。
所需例項:
步驟:
確保活動的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 Catalyst SD-WAN 裝置(包括新安裝的Cisco SD-WAN Manager例項)上的時鐘都同步。
確保在新安裝的Cisco SD-WAN Manager例項上配置一組新的系統IP和站點ID,並與活動群集配置相同的基本配置。




如果使用CA(企業證書頒發機構),請選擇Enterprise。


如果是20.15/20.18 vManage節點,請導航到Configuration > Devices > Control Components。若為20.9/20.12版本,請輸入Configuration > Devices > Controllers
注意:我們需要使用vBondor的admin憑據作為netadmingroup的使用者部分。您可以在vBond的CLI中驗證這一點。如需安裝vBond的新憑證,請在「產生CSR」下拉式清單中選擇Yes
附註:如果vBond位於NAT裝置/防火牆之後,請檢查vBond VPN 0介面IP是否已轉換為公共IP。如果無法從vManage訪問VPN 0介面IP,則在此步驟中使用VPN 0介面的公用IP地址

在20.12 vManage的情況下按一下Add vSmart,在20.15/20.18 vManage的情況下按一下Add Controller。
系統開啟一個彈出視窗,輸入vSmart的VPN 0傳輸IP(可從vManage訪問)。
如果允許,請從vManage的CLI到vSmart IP使用ping檢查可達性。
輸入vSmart Note的使用者憑據,我們需要使用vSmart的管理員憑據或netadmin組的使用者部分。
您可以在vSmart的CLI中驗證這一點。
如果希望路由器使用TLS來建立與vSmart的控制連線,請將協定設定為TLS。此配置也需要在vSmarts和vManage節點的CLI上配置。
如需安裝vSmart的新憑證,請在「產生CSR」下拉式清單中選擇「是」。
註:如果vSmart位於NAT裝置/防火牆之後,請檢查vSmart VPN 0介面IP是否已轉換為公共IP,如果無法從vManage訪問VPN 0介面IP,請在此步驟中使用VPN 0介面IP的公共IP地址。

完成所有步驟後,驗證是否可以在Monitor>Dashboard中訪問所有控制元件


注意:vManage集群可以配置3個vManage節點或6個vManage節點,具體取決於註冊到SD-WAN交換矩陣的站點數量
繼續執行「在SD-WAN重疊中帶單節點vManage的板載SD-WAN控制器」中共用的步驟,首先啟用帶一個vManage節點的SD-WAN交換矩陣,並加入所有必需的驗證器(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 512management介面以啟用對控制器的帶外管理訪問。
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
在已登入的所有vManagenodes(包括vManage-1)上配置服務介面。此介面用於集群通訊,表示集群中vManagenodes之間的通訊。
conf t
interface eth2
ip address
no shutdown
commit
確保同一IP子網用於vManagecluster中所有節點上的服務介面。
我們可以使用vManagenodes的相同管理憑據來配置vManagecluster。否則,我們可以配置作為netadmingroup一部分的新使用者憑據。配置新使用者憑據的配置如下所示
conf t
system
aaa
user
password
group netadmin
commit
確保在屬於群集的所有vManagenode上配置相同的使用者憑據。如果我們決定使用管理員憑據,則必須在所有vManagenode上配置相同的使用者名稱/密碼。
如果是20.15/20.18 vManage節點,請導航到Configuration > Certificates > Control Components。若為20.9/20.12版本,請輸入Configuration > Devices > Controllers
按一下Manager/vManage的……並按一下Generate CSR。

產生CSR後,您可以下載CSR,並根據為控制器選擇的憑證授權進行簽名。您可以在管理>設定>控制器憑證授權中驗證此組態。如果選擇Cisco(建議),則vManage會自動將CSR上傳到PNP門戶,並且證書簽署後,會自動將其安裝在vManage上。
如果選擇「手動」,請通過導航到相應SD-WAN重疊的智慧帳戶和虛擬帳戶,使用思科PNP門戶手動簽署CSR。
證書從PNP門戶可用後,在vManage的同一部分中按一下安裝證書,然後上傳證書並安裝證書。
如果我們使用Digicert和Enterprise Root Certificate ,則適用相同的步驟。
跨屬於群集的所有vManage節點完成此步驟。
附註:對於一個3節點群集,所有3個vManage節點都以compute+data作為角色。
可選配置:
請參考現有群集中的此配置,以啟用SDAVC — 僅當需要且僅在群集的一個vManage節點上需要時,才需要選中。
按一下「更新」。



將下一個節點新增到群集之前,需要考慮以下幾點:
請在已新增到群集的所有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領導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 backup複製到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憑據。如果您的配置資料庫憑據是預設值(neo4j/password),則可以跳過此步驟。
要配置configuration-db憑據,請使用request 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#
可以繼續還原配置資料庫備份的開機自檢:
我們可以使用命令request nms configuration-db restore path /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後,請確保邊緣路由器清單、模板、策略以及以前或現有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驗證器同步:
https://vmanage-url/dataservice/certificate/syncvbond
在交換矩陣恢復後,交換矩陣中的所有邊緣和控制器的控制和bfd會話均已啟動,我們需要從UI使舊控制器(vmanage/vsmart/vbond)失效
附註:繼續使用此處顯示的「後檢查」部分,它對所有部署組合都是通用的。
所需例項:
步驟:
確保活動的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 Catalyst SD-WAN 裝置(包括新安裝的Cisco SD-WAN Manager例項)上的時鐘都同步。
確保在新安裝的Cisco SD-WAN Manager例項上配置一組新的系統IP和站點ID,並與活動群集配置相同的基本配置。




如果使用CA(企業證書頒發機構),請選擇Enterprise。


如果是20.15/20.18 vManage節點,請導航到Configuration > Devices > Control Components。若為20.9/20.12版本,請輸入Configuration > Devices > Controllers
注意:我們需要使用vBondor的admin憑據作為netadmingroup的使用者部分。您可以在vBond的CLI中驗證這一點。如需安裝vBond的新憑證,請在「產生CSR」下拉式清單中選擇Yes
附註:如果vBond位於NAT裝置/防火牆之後,請檢查vBond VPN 0介面IP是否已轉換為公共IP。如果無法從vManage訪問VPN 0介面IP,則在此步驟中使用VPN 0介面的公用IP地址

在20.12 vManage的情況下按一下Add vSmart,在20.15/20.18 vManage的情況下按一下Add Controller。
系統開啟一個彈出視窗,輸入vSmart的VPN 0傳輸IP(可從vManage訪問)。
如果允許,請從vManage的CLI到vSmart IP使用ping檢查可達性。
輸入vSmart Note的使用者憑據,我們需要使用vSmart的管理員憑據或netadmin組的使用者部分。
您可以在vSmart的CLI中驗證這一點。
如果希望路由器使用TLS來建立與vSmart的控制連線,請將協定設定為TLS。此配置也需要在vSmarts和vManage節點的CLI上配置。
如需安裝vSmart的新憑證,請在「產生CSR」下拉式清單中選擇「是」。
註:如果vSmart位於NAT裝置/防火牆之後,請檢查vSmart VPN 0介面IP是否已轉換為公共IP,如果無法從vManage訪問VPN 0介面IP,請在此步驟中使用VPN 0介面IP的公共IP地址。

完成所有步驟後,驗證是否可以在Monitor>Dashboard中訪問所有控制元件


注意:vManage集群可以配置3個vManage節點或6個vManage節點,具體取決於註冊到SD-WAN交換矩陣的站點數量
繼續執行「在SD-WAN重疊中帶單節點vManage的板載SD-WAN控制器」中共用的步驟,首先啟用帶一個vManage節點的SD-WAN交換矩陣,並加入所有必需的驗證器(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 512management介面以啟用對控制器的帶外管理訪問。
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
在已登入的所有vManagenodes(包括vManage-1)上配置服務介面。此介面用於集群通訊,表示集群中vManagenodes之間的通訊。
conf t
interface eth2
ip address
no shutdown
commit
確保同一IP子網用於vManagecluster中所有節點上的服務介面。
我們可以使用vManagenodes的相同管理憑據來配置vManagecluster。否則,我們可以配置作為netadmingroup一部分的新使用者憑據。配置新使用者憑據的配置如下所示
conf t
system
aaa
user
password
group netadmin
commit
確保在屬於群集的所有vManagenode上配置相同的使用者憑據。如果我們決定使用管理員憑據,則必須在所有vManagenode上配置相同的使用者名稱/密碼。
如果是20.15/20.18 vManage節點,請導航到Configuration > Certificates > Control Components。若為20.9/20.12版本,請輸入Configuration > Devices > Controllers
按一下Manager/vManage的……並按一下Generate CSR。

產生CSR後,您可以下載CSR,並根據為控制器選擇的憑證授權進行簽名。您可以在管理>設定>控制器憑證授權中驗證此組態。如果選擇Cisco(建議),則vManage會自動將CSR上傳到PNP門戶,並且證書簽署後,會自動將其安裝在vManage上。
如果選擇「手動」,請通過導航到相應SD-WAN重疊的智慧帳戶和虛擬帳戶,使用思科PNP門戶手動簽署CSR。
證書從PNP門戶可用後,在vManage的同一部分中按一下安裝證書,然後上傳證書並安裝證書。
如果我們使用Digicert和Enterprise Root Certificate ,則適用相同的步驟。
跨屬於群集的所有vManage節點完成此步驟。
附註:對於一個3節點群集,所有3個vManage節點都以compute+data作為角色。對於6節點群集,3個vManage節點將compute+data作為角色建立,3個vManage節點將資料作為角色建立。

可選配置:
請參考現有群集中的此配置,以啟用SDAVC — 僅當需要且僅在群集的一個vManage節點上需要時,才需要選中。
按一下「更新」。



將下一個節點新增到群集之前,需要考慮以下幾點:
請在已新增到群集的所有vManage節點的UI上驗證這些點:
附註:從已啟用災難恢復的現有vManage群集收集配置資料庫備份時,請確保在該節點上的災難恢復暫停並刪除後收集該備份。
確認沒有正在進行的災難恢復複製。導航到管理>災難恢復和 確保狀態為「成功」,而不是處於「匯入掛起」、「匯出掛起」或「下載掛起」等暫時狀態。如果狀態不成功,請聯絡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領導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 backup複製到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憑據。如果您的配置資料庫憑據是預設值(neo4j/password),則可以跳過此步驟。
要配置configuration-db憑據,請使用request 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#
可以繼續還原配置資料庫備份的開機自檢:
我們可以使用命令request nms configuration-db restore path /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後,請確保邊緣路由器清單、模板、策略以及以前或現有vManage UI上存在的所有其餘配置都反映在新的vManage UI上。
重要預檢查
必須配置兩個獨立的vManage 3節點群集並使其正常運行,才能繼續進行災難恢復。在活動群集上,必須安裝驗證器和控制器。如果您在DR站點上有驗證器和控制器,則這些控制器也必須在活動群集上而不是在DR vManage群集上被登入。
思科建議在註冊災難恢復之前,必須滿足以下要求:
組態
有關vManage Disaster Recovery的詳細資訊,請參閱此鏈接。
假設每個SD-WAN管理器具有最低配置且認證部分已完成,則已經建立了兩個單獨的3節點群集。
在兩個群集上導航到Administration > Cluster Management,並驗證所有節點是否處於就緒狀態。
DC vManage

DR vmanage

導航到Administration>Disaster Recovery of Primary vManage Cluster。按一下Manage Disaster Recovery。

在彈出視窗中,填寫主要和輔助vManage的詳細資訊。
要指示的IP地址是帶外群集介面的IP地址。 最好在每個集群中使用vManage-1的VPN 0服務介面的IP地址。
憑據必須是netadmin使用者的憑據,並且配置DR後不能更改這些憑據,除非將其刪除。 可以使用單獨的vManage本地使用者憑據進行災難恢復。我們需要確保vManage本地使用者是netadmin組的一部分。此處也可以使用管理員憑據。

填寫完畢後,按一下下一步。
vBond控制器必須能夠通過Netconf以指定的IP地址訪問。

填寫完畢後,按一下下一步。


設定值,然後按一下Save。

驗證
導航到管理>災難恢復,以檢視災難恢復狀態以及上次複製資料的時間。

附註:複製可能需要幾個小時,具體取決於資料庫大小。此外,它可能需要幾個週期才能成功完成複製。
恢復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驗證器同步:
https://vmanage-url/dataservice/certificate/syncvbond
在交換矩陣恢復後,交換矩陣中的所有邊緣和控制器的控制和bfd會話均已啟動,我們需要從UI使舊控制器(vmanage/vsmart/vbond)失效
這些後期檢查適用於所有部署組合。
request platform software sdwan vedge_cloud activate chassis-number token
驗證專案是否按預期顯示:
模板
政策
裝置頁面(兩個頁籤)WAN vEdge機架控制器
適用於vManage節點:
Configuration-DB(Neo4j)檢查:
在所有vManage節點上執行「request nms configuration-db diagnostics」命令:
1.檢查節點聯機狀態和Leadership狀態:(不適用於所有版本)
「Neo4j」必須線上顯示3個節點、1個領導者和2個追隨者。「system」也必須顯示3個節點聯機,1個引導節點和2個跟隨者,但由於這不是預設的資料庫,因此預設標誌為false。如果每個neo4j中的條目少於3個,則系統表示節點從群集中脫落。請與Cisco TAC聯絡,進行相同疑難排解。
2.檢查是否有任何節點為「隔離」。

所有節點均不能處於隔離狀態。
3.架構驗證必須是「成功」。

4.使用「request nms configuration-db diagnostics」命令收集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和系統的領導,並作為跟隨者駐留。確保所有節點都處於聯機狀態。如果有3個節點集群(所有三個節點都是COMPUTE+DATA),則對於neo4j和系統,必須只有一個領導。任何偏差,您必須聯絡TAC
5.在/var/log/kern.log中檢查所有磁碟、記憶體、IO錯誤。需要在所有vManage節點上檢查此項。
6.為在每個節點之間沒有CC的vmanage建立一個新群集時,請檢查該步驟
從節點1到其他節點cluster 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/序列號有任何附加條目,我們必須將其刪除。您可以聯絡思科TAC取得相同結果。
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
25-Feb-2026
|
初始版本 |
意見