瞭解Catalyst 9800 WLC的AP加入流程

已更新: 2023 年 10 月 6 日

文件 ID:221056

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本檔案將詳細介紹使用Cisco Catalyst 9800 WLC的AP加入程式。

必要條件

需求

思科建議您瞭解以下主題：

基本瞭解控制和調配無線接入點(CAPWAP)
基本瞭解無線Lan控制器(WLC)的使用

採用元件

本文中的資訊係根據以下軟體和硬體版本：

Catalyst 9800-L WLC、Cisco IOS® XE Cupertino 17.9.3
Catalyst 9120AXE存取點

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

CAPWAP會話建立

控制和設定無線接入點(CAPWAP)是提供接入點(AP)和無線LAN控制器(WLC)使用的傳輸機制的協定，用於通過安全通訊隧道(用於CAPWAP控制)交換控制和資料平面資訊。

為了詳述AP加入流程，請務必瞭解控制和調配無線接入點(CAPWAP)會話建立流程。

請記住，AP在能夠啟動CAPWAP進程之前需要有一個IP地址。如果AP沒有IP地址，它不會啟動CAPWAP會話建立過程。

接入點傳送一個發現請求。有關此問題的詳細資訊，請參閱WLC發現方法部分
WLC傳送探索回應
DTLS會話建立。此後，此步驟之後的所有郵件都會經過加密，並在任何資料包分析工具中顯示為DTLS應用程式資料包。
接入點傳送加入請求
WLC傳送加入回應
AP執行映像檢查。如果它的映像版本與WLC相同，則它將繼續進行下一步。如果沒有，則會從WLC下載映像並重新啟動以載入新映像。在這種情況下，它重複步驟1中的過程。
接入點傳送配置狀態請求。
WLC傳送組態狀態回應
接入點進入RUN狀態
在RUN狀態期間，會通過兩種方式執行CAPWAP隧道維護:
1. 交換Keepalive以維護CAPWAP資料通道
2. AP將回應要求傳送到WLC,WLC必須透過其各自的回應要求來應答。這是為了維護CAPWAP控制隧道。

CAPWAP Session Establishment Process CAPWAP會話建立過程

註：根據RFC 5415,CAPWAP使用UDP埠5246（用於CAPWAP控制）和5247（用於CAPWAP資料）。

DTLS會話建立

一旦接入點收到來自WLC的有效發現響應，就會在它們之間建立DTLS隧道，以通過安全隧道傳輸所有後續資料包。這是建立DTLS會話的過程：

AP發送客戶端Hello消息
WLC傳送一則HelloVerifyRequest訊息，其中包含用於驗證的cookie。
AP發送包含用於驗證的cookie的ClientHello消息。
WLC會按以下順序傳送這些封包：
1. ServerHello
2. 憑證
3. 伺服器金鑰交換
4. 證書請求
5. ServerHelloDone
AP按以下順序傳送這些封包：
1. 憑證
2. ClientKeyExchange
3. 證書驗證
4. ChangeCipherSpec
WLC使用自己的ChangedCipherSpec對AP的ChangeCipherSpec作出響應:
1. ChangeCipherSpec

在WLC傳送最後一個ChangedCipherSpec訊息後，安全通道已建立，且兩個方向傳送的所有流量現在均已加密。

無線LAN控制器探索方法

有幾種方法可讓存取點知道網路中有一個WLC的存在：

DHCP選項43:此選項為AP提供要加入的WLC的IPv4地址。對於AP和WLC位於不同站點的大型部署，此過程非常方便。
DHCP選項52：此選項為AP提供WLC的IPv6地址以加入。在與DHCP選項43相同的場景中，其使用是方便的。
DNS發現:AP查詢域名CISCO-CAPWAP-CONTROLLER.localdomain。您必須將DNS伺服器配置為解析要加入的WLC的IPv4或IPv6地址。對於將WLC與AP儲存在同一站點的部署，此選項非常方便。
第3層廣播：AP自動向255.255.255.255傳送廣播消息。與AP位於同一子網中的任何WLC都應響應此發現請求。
靜態配置：您可以使用 capwap ap primary-base <wlc-hostname> <wlc-IP-address>命令，為AP中的WLC配置靜態條目。
移動發現：如果AP之前已加入屬於移動組的WLC，則AP還會儲存該移動組中存在的WLC的記錄。

註：列出的WLC發現方法沒有優先順序。

無線LAN控制器選擇

AP使用任一WLC探索方法從任何WLC收到探索回應後，會選擇其中一個控制器加入此條件：

主控制器(使用capwap ap primary-base <wlc-hostname> <wlc-IP-address> 命令配置)
輔助控制器(使用capwap ap secondary-base <wlc-hostname> <wlc-IP-address> 指令設定)
第三控制器(使用capwap ap tertiary-base <wlc-hostname> <wlc-IP-address> 命令配置)
如果之前未配置任何主WLC、輔助或第三WLC，則AP會嘗試將響應發現請求的第一WLC與具有最大可用AP容量的發現響應(即，在給定時間可支援最APs的WLC)加入。

CAPWAP狀態機

在AP控制檯中，您可以跟蹤CAPWAP狀態機，它跨越了CAPWAP會話建立一節中描述的步驟。

CAPWAP狀態：發現

在這裡，您可以看到Discovery Requests和Responses。觀察AP如何通過DHCP（選項43）接收WLC IP，以及如何將探索請求傳送到先前已知的WLC:

[*09/14/2023 04:12:09.7740] CAPWAP State: Init
[*09/14/2023 04:12:09.7770] 
[*09/14/2023 04:12:09.7770] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7790] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Got WLC address 172.16.5.11 from DHCP.
[*09/14/2023 04:12:09.7820] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7830] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7840] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
[*09/14/2023 04:12:09.7850] 
[*09/14/2023 04:12:09.7850] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7850] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8030] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169

除了從靜態配置的WLC(172.16.0.20)和通過DHCP選項43(172.16.5.11)指示的WLC接收發現響應外，此AP還從同一子網中的另一個WLC(172.16.5.169)接收了發現響應，因為它收到了廣播發現消息。

CAPWAP狀態：DTLS設定。

在這裡，AP和WLC之間的DTLS會話將交換。

[*09/27/2023 21:50:41.0000] CAPWAP State: DTLS Setup
[*09/27/2023 21:50:41.7140] sudi99_request_check_and_load: Use HARSA SUDI certificat

CAPWAP狀態：加入

建立DTLS作業階段後，現在會透過安全作業階段傳送到WLC的加入請求。觀察此請求如何通過WLC的加入響應立即得到響應

[*09/27/2023 21:50:41.9880] CAPWAP State: Join
[*09/27/2023 21:50:41.9910] Sending Join request to 172.16.5.11 through port 5270
[*09/27/2023 21:50:41.9950] Join Response from 172.16.5.11 
[*09/27/2023 21:50:41.9950] AC accepted join request with result code: 0
[*09/27/2023 21:50:41.9990] Received wlcType 0, timer 30
[*09/27/2023 21:50:41.9990] TLV ID 2216 not found
[*09/27/2023 21:50:41.9990] TLV-DEC-ERR-1: No proc for 2216

CAPWAP狀態：影象資料

AP將其映像與WLC的映像進行比較。在這種情況下，AP的活動分割槽及其備份分割槽與WLC具有不同的映像，因此它會呼叫upgrade.sh指令碼，該指令碼指示AP向WLC請求足夠的映像，並將其下載到其當前的非活動分割槽。

[*09/27/2023 21:50:42.0430] CAPWAP State: Image Data
[*09/27/2023 21:50:42.0430] AP image version 8.10.185.0 backup 8.10.105.0, Controller 17.9.3.50
[*09/27/2023 21:50:42.0430] Version does not match.
[*09/27/2023 21:50:42.0680] upgrade.sh: Script called with args:[PRECHECK]
[*09/27/2023 21:50:42.1060] do PRECHECK, part2 is active part
[*09/27/2023 21:50:42.1240] upgrade.sh: /tmp space: OK available 101476, required 40000 
[*09/27/2023 21:50:42.1250] wtpImgFileReadRequest: request ap1g7, local /tmp/part.tar
[*09/27/2023 21:50:42.1310] Image Data Request sent to 172.16.5.11, fileName [ap1g7], slaveStatus 0
[*09/27/2023 21:50:42.1340] Image Data Response from 172.16.5.11
[*09/27/2023 21:50:42.1340] AC accepted join request with result code: 0
[*09/27/2023 21:50:42.1450] <..................................................
[*09/27/2023 21:50:55.4980] ..................................................
[*09/27/2023 21:51:11.6290] ...............................Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Image Data(10).
[*09/27/2023 21:51:19.7220] ...................
[*09/27/2023 21:51:24.6880] ..................................................
[*09/27/2023 21:51:37.7790] ..................................................
[*09/27/2023 21:51:50.9440] ...................................> 76738560 bytes, 57055 msgs, 930 last
[*09/27/2023 21:51:59.9160] Last block stored, IsPre 0, WriteTaskId 0
[*09/27/2023 21:51:59.9160] Image transfer completed from WLC, last 1

映像傳輸完成後，AP會啟動映像簽名驗證過程以驗證它。執行此操作後，upgrade.sh指令碼會將映像安裝到當前的非活動分割槽中，並交換啟動時所在的分割槽。最後，AP重新載入自身，並從開始重複該過程(CAPWAP狀態：發現)。

[*09/27/2023 21:52:01.1280] Image signing verify success.
[*09/27/2023 21:52:01.1440] 
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Shadow is now in-synced with master
[*09/27/2023 21:52:01.1440] 
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Verifying against bundle image btldr.img...
[*09/27/2023 21:52:01.1570] upgrade.sh: part to upgrade is part1
[*09/27/2023 21:52:01.1780] upgrade.sh: AP version1: part1 8.10.105.0, img 17.9.3.50
[*09/27/2023 21:52:01.1960] upgrade.sh: Extracting and verifying image in part1...
[*09/27/2023 21:52:01.2080] upgrade.sh: BOARD generic case execute
[*09/27/2023 21:52:01.5280] upgrade.sh: Untar /tmp/part.tar to /bootpart/part1...
[*09/27/2023 21:52:01.7890] upgrade.sh: Sync image to disk...
[*09/27/2023 21:52:31.4970] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:32.5270] upgrade.sh: AP version2: part1 17.9.3.50, img 17.9.3.50
[*09/27/2023 21:52:32.5540] upgrade.sh: AP backup version: 17.9.3.50
[*09/27/2023 21:52:32.5700] upgrade.sh: Finished upgrade task.
[*09/27/2023 21:52:32.5840] upgrade.sh: Cleanup for do_upgrade...
[*09/27/2023 21:52:32.5970] upgrade.sh: /tmp/upgrade_in_progress cleaned
[*09/27/2023 21:52:32.6090] upgrade.sh: Cleanup tmp files ...
[*09/27/2023 21:52:32.6720] upgrade.sh: Script called with args:[ACTIVATE]
[*09/27/2023 21:52:32.7100] do ACTIVATE, part2 is active part
[*09/27/2023 21:52:32.7640] upgrade.sh: Verifying image signature in part1
[*09/27/2023 21:52:33.7730] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:33.7850] upgrade.sh: activate part1, set BOOT to part1
[*09/27/2023 21:52:34.2940] upgrade.sh: AP primary version after reload: 17.9.3.50
[*09/27/2023 21:52:34.3070] upgrade.sh: AP backup version after reload: 8.10.185.0
[*09/27/2023 21:52:34.3190] upgrade.sh: Create after-upgrade.log
[*09/27/2023 21:52:37.3520] AP Rebooting: Reset Reason - Image Upgrade

警告：由於證書過期，Wave 1接入點可能無法下載新影象。如需詳細資訊，請參閱現場通知72524，並仔細閱讀2022年12月4日以後由於映像簽名證書過期而引起的IOS AP映像下載失敗(CSCwd80290)支援檔案，以瞭解其影響和解決方案。

一旦AP重新載入並再次進入CAPWAP Discover和Join狀態，在Image Data狀態期間，它會檢測到它現在具有足夠的映像。

[*09/27/2023 21:56:13.7640] CAPWAP State: Image Data
[*09/27/2023 21:56:13.7650] AP image version 17.9.3.50 backup 8.10.185.0, Controller 17.9.3.50
[*09/27/2023 21:56:13.7650] Version is the same, do not need update.
[*09/27/2023 21:56:13.7650] status 'upgrade.sh: Script called with args:[NO_UPGRADE]'
[*09/27/2023 21:56:13.7850] do NO_UPGRADE, part1 is active part

CAPWAP狀態：配置

AP驗證其與WLC的版本相同後，會將其當前配置通知給WLC。一般情況下，這表示AP會要求保留其組態（如果它們在WLC中可用）。

[*09/27/2023 21:56:14.8680] CAPWAP State: Configure
[*09/27/2023 21:56:15.8890] Telnet is not supported by AP, should not encode this payload
[*09/27/2023 21:56:15.8890] Radio [1] Administrative state DISABLED change to ENABLED 
[*09/27/2023 21:56:16.0650] Radio [0] Administrative state DISABLED change to ENABLED 
[*09/27/2023 21:56:16.0750] DOT11_CFG[1]: Starting radio 1
[*09/27/2023 21:56:16.1150] DOT11_DRV[1]: Start Radio1
[*09/27/2023 21:56:16.1160] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:16.4380] Started Radio 1
[*09/27/2023 21:56:16.4880] DOT11_CFG[0]: Starting radio 0
[*09/27/2023 21:56:17.5220] DOT11_DRV[0]: Start Radio0
[*09/27/2023 21:56:16.5650] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:16.5650] Started Radio 0
[*09/27/2023 21:56:16.5890] sensord psage_base init: RHB Sage base ptr a1030000

CAPWAP狀態：運行

此時，AP已成功加入控制器。在此狀態期間，WLC會觸發一種機制以覆寫AP要求的設定。您可以看到AP被推送了Radio和Credentials配置，而且由於WLC以前對此AP不瞭解，因此它還被分配給default policy tag。

[*09/27/2023 21:56:17.4870] CAPWAP State: Run
[*09/27/2023 21:56:17.4870] AP has joined controller uwu-9800
[*09/27/2023 21:56:17.4940] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.5440] sensord split_glue psage_base: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6010] sensord split_glue sage_addr: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6230] ptr a1030000
[*09/27/2023 21:56:17.6420] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.8120] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:17.9350] Previous AP mode is 0, change to 0
[*09/27/2023 21:56:18.0160] Current session mode: ssh, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1220] Current session mode: telnet, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1310] Current session mode: console, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1340] chpasswd: password for user changed
[*09/27/2023 21:56:18.1350] chpasswd: password for user changed
[*09/27/2023 21:56:18.1520] systemd[1]: Starting Cisco rsyslog client watcher...
[*09/27/2023 21:56:18.1610] Same LSC mode, no action needed
[*09/27/2023 21:56:18.1640] CLSM[00:00:00:00:00:00]: U3 Client RSSI Stats feature is deprecated; can no longer be enabled
[*09/27/2023 21:56:18.1720] systemd[1]: Stopping rsyslog client...
[*09/27/2023 21:56:18.2120] systemd[1]: Starting Cisco syslog service...
[*09/27/2023 21:56:18.2230] systemd[1]: Started Cisco syslog service.
[*09/27/2023 21:56:18.2410] systemd[1]: Started rsyslog client.
[*09/27/2023 21:56:18.2440] AP is in good condition, BLE is off
[*09/27/2023 21:56:18.2510] SET_SYS_COND_INTF: allow_usb state: 1 (up) condition 
[*09/27/2023 21:56:18.2530] systemd[1]: Starting dhcpv6 client watcher...
[*09/27/2023 21:56:18.2530] systemd[1]: Stopping DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Starting DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Started DHCPv6 client.
[*09/27/2023 21:56:18.2530] systemd[1]: Started dhcpv6 client watcher.
[*09/27/2023 21:56:18.2560] Set radio 0 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Set radio 1 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Got WSA Server config TLVs
[*09/27/2023 21:56:18.2720] AP tag change to default-policy-tag
[*09/27/2023 21:56:18.2780] Chip flash OK

設定

靜態WLC選擇

在GUI中，您可以轉到Configuration > Wireless > Access Points，選擇一個AP並指示到High Availability頁籤。在這裡，您可以設定主要、次要和第三WLC，如本檔案的無線LAN控制器選擇一節所述。此配置按接入點執行。

Primary, Secondary and Tertiary WLCs for an AP. AP的主要、輔助和第三WLC。

注意：從Cisco IOS XE 17.9.2開始，您可以使用啟動配置檔案為一組與正規表示式(regex)匹配的AP或單個AP配置主、輔助和三級控制器。請參閱配置指南的AP Fallback to Controllers Configured Under AP Prime Profile部分瞭解詳細資訊。

請注意，在AP High Availability頁籤中配置的主、輔助和三級控制器與可以在CAPWAP > High Availability頁籤下的Backup Primary和Secondary WLC不同，後者可以根據AP加入配置檔案進行配置。主要、次要和第三控制器被視為分別具有優先順序1、2和3的WLC，而備份主要和輔助被視為具有優先順序4和5的WLC。

如果已啟用AP Fallback，則AP在加入其他WLC時會主動查詢主控制器。只有發生CAPWAP Down事件且沒有可用的備份主控制器和輔助控制器時，AP才會查詢優先順序為4和5的WLC。

High Availability Options in the AP Join Profile AP加入配置檔案中的高可用性選項

注意：在AP加入配置檔案中配置備份主WLC和備份輔助WLC不會填充接入點的High Availability頁籤中的Static Primary和Secondary條目。

啟用對AP的Telnet/SSH訪問

轉至Configuration > Tags & Profiles > AP Join > Management > Device，然後選擇SSH和/或Telnet。

Enable Telnet/SSH Access on the AP Join Profile 在AP加入配置檔案中啟用Telnet/SSH訪問

要配置SSH/Telnet憑證，請導航到同一視窗中的User頁籤，並設定Username、Password和Secret以訪問AP。

SSH and Telnet Credentials for the AP AP的SSH和Telnet憑證

資料連結加密

如果您需要對任何需要對AP流量進行資料包捕獲的客戶端問題進行故障排除，請確保Configuration > Tags & Profiles > AP Join > CAPWAP > Advanced下未啟用Data Link Encryption。否則，您的流量會進行加密。

Data Link Encryption 資料連結加密

注意：資料加密僅加密CAPWAP資料流量。CAPWAP控制流量已經通過DTLS加密。

驗證

除了在AP控制檯中跟蹤CAPWAP狀態機外，您還可以在WLC中進行Embedded Packet Capture以分析AP加入過程：

AP Join Process seen in an Embedded Packet Capture in the WLC 在WLC中的嵌入式封包擷取中看到的AP加入程式

注意Chance Cipher Spec資料包（資料包1182）之後的所有流量如何僅顯示為DTLSv1.2上的應用數據。這是DTLS會話建立後所有加密的資料。

疑難排解

已知的問題

請參閱可能阻止您的AP加入WLC的已知問題。

升級之前，請始終參閱每個版本的發行說明的升級路徑部分。

註：從Cisco IOS XE Cupertino 17.7.1開始，如果智慧許可未連線且未啟用，Cisco Catalyst 9800-CL無線控制器接受的AP不會超過50個。

WLC GUI檢查

在WLC上，前往Monitoring > Wireless > AP Statistics > Join Statistics 您可以看到任何AP報告的Last Reboot Reason和WLC註冊的Last Disconnect Reason。

AP Join Statistics page on the WLC WLC上的「AP加入統計資訊」頁

您可以按一下任何AP並檢查AP加入統計資訊詳細資訊。在此，您可以看到更多詳細資訊，例如AP上次加入並嘗試發現WLC的時間和日期。

General AP Join Statistics 常規AP加入統計資訊

有關詳細資訊，請轉至同一視窗的「統計資訊」頁籤。在這裡，您可以比較傳送的加入響應數量與接收的加入請求數量，以及傳送的配置響應與接收的配置請求。

Detailed AP Join Statistics 詳細的AP加入統計資訊

指令

以下命令可用於排除AP加入問題：

在WLC上

show ap summary
debug capwap error
debug capwap packet

來自Wave 2和Catalyst 11ax AP

偵錯 capwap 用戶端事件
debug capwap client error
debug dtls client error（調試dtls客戶端錯誤）
debug dtls client event
debug capwap client keepalive
test capwap restart
capwap ap erase all

來自Wave 1 AP

debug capwap console cli
debug capwap client no-reload
show dtls stats
clear cawap ap ap all-config

注意：通過Telnet/SSH連線到AP進行故障排除時，在啟用AP上的調試後重現問題時，請始終發出terminal monitor命令。否則，您將看不到調試中的任何輸出。

放射性痕跡

排除AP連線問題的一個良好起點是獲取存在連線問題的AP的無線電和乙太網MAC地址的輻射跟蹤。有關生成這些日誌的詳細資訊，請參閱Catalyst 9800 WLC上的調試和日誌收集。

修訂記錄

修訂	發佈日期	意見
2.0	06-Oct-2023	初始版本
1.0	06-Oct-2023	初始版本

由思科工程師貢獻

Execatl Moreno Avila
Technical Consulting Engineer