排查並驗證SD-Access無線初始設定

下載選項

  • PDF     (1.0 MB)
    在多種裝置上使用 Adobe Reader 檢視
  • ePub     (600.7 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
  • Mobi (Kindle)     (584.5 KB)
    在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視
已更新: 2019 年 10 月 17 日
文件 ID:214977

無偏見用語

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

關於此翻譯

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

    簡介

    本文描述用於確定SD-Access無線設定中的基本連線問題的基本故障排除步驟。本章將介紹用於檢查以找出與無線相關解決方案中的問題的專案和命令。

    必要條件

    需求

    瞭解SD-Access解決方案

    已設定SD訪問拓撲

    採用元件

    本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。SD訪問無線支援其他型別的裝置，但本文重點介紹本節中介紹的裝置。命令可能因平台和軟體版本而異。

    8.5.151無線控制器

    16.9.3 9300交換機作為邊緣節點

    拓撲

    螢幕截圖2019-10-17(21.20.32)

    排查和隔離

    快速驗證

    在SD訪問方案中有一系列要求通常是錯誤源，因此請首先驗證這些要求是否滿足：

    • 確保您具有指向LISP控制平面節點上的WLC的特定路由（並且不使用預設路由）
    • 使用全局路由表確保您的AP位於基礎設施VN中
    • 透過從AP本身ping WLC，確保AP可以連線到WLC
    • 確保WLC上控制平面的交換矩陣狀態為up
    • 確保AP處於交換矩陣啟用狀態

    案例 1.驗證WLC向LISP/MAP伺服器控制平面的註冊

     當您將WLC增加到DNA Center中的交換矩陣時，命令會被推送到控制器以建立與DNA-C中定義為控制平面的節點的連線。第一步是確保註冊成功。如果控制平面上的LISP配置以某種方式損壞，此註冊可能會失敗。

    螢幕截圖2017-11-24(22.37.52)

    如果此狀態顯示為down，則在WLC和控制平面之間運行調試或資料包捕獲可能會很有用。4342上的註冊包括TCP和UDP。如果控制平面沒有取得正確的組態，它可能會以TCP RST回覆WLC傳送的TCP SYN。

    相同的狀態可以透過命令列中的show fabric map-server summary進行驗證。該進程使用WLC CLI上的debug fabric lisp map-server all進行調試。若要引發重新連線嘗試，您可以前往DNA Center，選擇從光纖中移除WLC並再次加入。

    可能的原因是控制平面中缺少配置線。以下是工作組態範例（僅最重要的部分）：

    rtr-cp-mer-172_16_200_4#show run | s WLC
 locator-set WLC
  10.241.0.41       
  exit-locator-set
 map-server session passive-open WLC

    如果WLC ip丟失（此處為10.241.0.41）或缺少passive-open命令，CP將拒絕WLC連線。

    要運行的調試是： 

    • 'debug capwap events enable’
    • 'debug capwap errors enable'
    • '啟用調試結構ap加入事件'
    • 'debug fabric ap-join detail enable'
    • 'debug fabric lisp map-server all enable'

    以下範例顯示控制層面沒有回應WLC

    *msfMsgQueueTask: May 07 14:08:10.080: Sent map-request to MS 10.32.47.128 for AP 10.32.58.36 VNID 4097
*msfMsgQueueTask: May 07 14:08:10.080: No messages are present in the Client list for Local UDP socket
*msfMsgQueueTask: May 07 14:08:10.080: msfSendLocalUDPSocketMessage:637 Message get for UDP file socket list with path /tmp/msif_local_udp_socket_file failed
*osapiBsnTimer: May 07 14:08:15.179: Map-reply timer for MS IP 10.32.47.128 expired for AP IP 10.32.58.36 and VNID 4097 
*msfMsgQueueTask: May 07 14:08:15.179: msfQueue: recieved LISP_MAP_SERVER_TIMEOUT_QUEUE_MSG
*msfMsgQueueTask: May 07 14:08:15.179: Found entry AP 10.32.58.36 vnid 4097
*msfMsgQueueTask: May 07 14:08:15.179: Added AP 10.32.58.36 VNID 4097 for long retry map-request
*msfMsgQueueTask: May 07 14:08:15.179: Found entry AP 10.32.58.36 vnid 4097
*msfMsgQueueTask: May 07 14:08:15.179: No messages are present in the Client list for Local UDP socket
*msfMsgQueueTask: May 07 14:08:15.179: msfSendLocalUDPSocketMessage:637 Message get for UDP file socket list with path /tmp/msif_local_udp_socket_file failed
*spamApTask0: May 07 14:08:16.084: 00:fc:ba:15:95:00 WTP Event Request from 10.32.58.36:5248 epoch 1525694896
*spamApTask0: May 07 14:08:16.084: 00:fc:ba:15:95:00 WTP Event Response sent to 10.32.58.36:5248
*osapiBsnTimer: May 07 14:08:17.839: NAK Timer expiry callback
*msfMsgQueueTask: May 07 14:08:17.839: msfQueue: recieved LISP_MAP_SERVER_NAK_TIMEOUT_QUEUE_MSG
*msfMsgQueueTask: May 07 14:08:17.839: Started periodic NAK processing timer
*msfMsgQueueTask: May 07 14:08:17.839: Process list of AP (1) for which RLOC is not received

    以下示例說明由於交換矩陣控制平面缺少到WLC的特定路由而加入交換矩陣停用狀態的AP的WLC調試

    (POD3-WLC1) >*emWeb: Oct 16 08:54:21.593: Fabric is supported for apType 54

*emWeb: Oct 16 08:54:21.593: Fabric is supported for apType 54

*emWeb: Oct 16 08:55:26.295: ip c0a82700,subnet ffffff00,l2vnid 8191,l3vnid 1001
*emWeb: Oct 16 08:55:26.295: Vnid Mapping added at index 2 with entries 192_168_39_0-INFRA_VN,8191,4097,c0a82700,ffffff00.Count 3

*emWeb: Oct 16 08:55:26.295:
                             Log to TACACS server(if online): fabric vnid create name 192_168_39_0-INFRA_VN l2-vnid 8191 ip 192.168.39.0 subnet 255.255.255.0 l3-vnid 4097

*spamReceiveTask: Oct 16 08:55:26.295: Fabric is supported for AP f4:db:e6:61:24:a0 (Pod3-AP4800). apType 54

*spamReceiveTask: Oct 16 08:55:26.295: spamProcessFabricVnidMappingAddRequest: Fabric Adding vnid mapping for AP Pod3-AP4800 f4:db:e6:61:24:a0,lradIp 192.168.39.100,AP l2_vnid 0, AP l3_vnid 0
*spamReceiveTask: Oct 16 08:55:26.295: Vnid Mapping return from index 2 with entries name 192_168_39_0-INFRA_VN,l2vnid 8191,l3vnid 4097,ip c0a82700,mask ffffff00.Count 3

*spamReceiveTask: Oct 16 08:55:26.295: spamSendFabricMapServerRequest: MS request from AP Pod3-AP4800 f4:db:e6:61:24:a0,l3vnid 4097,PMS 192.168.30.55,SMS 0.0.0.0,mwarIp 192.168.31.59,lradIp 192.168.39.100
*emWeb: Oct 16 08:55:29.944:
                             Log to TACACS server(if online): save


(POD3-WLC1) >*spamApTask6: Oct 16 08:56:49.243: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.

*spamApTask6: Oct 16 08:56:51.949: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.

*spamApTask6: Oct 16 08:56:51.953: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.

*spamApTask6: Oct 16 08:56:51.953: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.

*spamApTask6: Oct 16 08:56:51.953: spamSendFabricMapServerRequest: MS request from AP Pod3-AP3800 f4:db:e6:64:02:a0 can not be sent ,AP vnid mapping does not exist

    有趣的是，您會注意到，如果您的交換矩陣網路中有兩個控制平面，WLC將始終聯絡這兩個平面進行註冊或查詢。預計兩個控制平面都會在註冊時給出肯定應答，因此，如果兩個控制平面中的一個控制平面由於任何原因拒絕了AP，WLC將無法註冊交換矩陣中的AP。但是，可接受一個控制平面未應答，將使用其餘的控制平面。

    AP透過全局路由表連線到WLC，但LISP仍用於解析WLC。AP傳送到WLC的流量是純CAPWAP控制（不涉及vxlan），但是WLC傳送到AP的返回流量將在重疊上透過Vxlan傳輸。您將無法測試從邊緣的AP網關SVI到WLC的連線，因為它是任播網關，邊界節點上也存在相同的IP。要測試連線，最好的方法是從AP本身執行ping操作。

    案例 2.存取點未取得IP位址

    存取點應從DNA中心中定義的基礎設施VNl中的AP Po獲取IP地址。如果沒有出現這種情況，通常意味著AP所連線的交換機埠沒有移動到正確的vlan。當檢測到（透過CDP）連線的存取點時，交換機將應用一個交換機埠宏，該宏將在AP池的DNA-C定義的vlan中設定switchport。如果問題交換機埠確實沒有使用宏進行配置，您可以手動設定配置（使AP獲得ip、加入WLC並可能升級其代碼並可能解決任何CDP錯誤）或排除CDP連線過程故障。您可以選擇配置主機自註冊，以靜態定義DNA-Center上的埠來託管AP，從而為其調配正確的配置。

    如果交換機未配置至少一個AP，則Smartport宏不會自動啟動，您可以驗證AP宏是否配置了正確的VLAN（而不是預設VLAN 1）

    Pod3-Edge1#show macro auto device 
Device:lightweight-ap
Default Macro:CISCO_LWAP_AUTO_SMARTPORT
Current Macro:CISCO_LWAP_AUTO_SMARTPORT
Configurable Parameters:ACCESS_VLAN
Defaults Parameters:ACCESS_VLAN=1
Current Parameters:ACCESS_VLAN=2045

    Cisco DNA-C用於設定此值的命令是

    macro auto execute CISCO_WIRELESS_LIGHTWEIGHT_AP_EVENT builtin CISCO_LWAP_AUTO_SMARTPORT ACCESS_VLAN=2045
macro auto global processing

    案例 3.存取點沒有針對其網狀架構邊緣節點建立的vxlan通道

    一旦AP加入WLC，WLC（如果AP支援交換矩陣）將在控制平面上將AP註冊為特殊型別的客戶端。然後，控制平面將請求連線AP的交換矩陣邊緣節點建立通向AP的vxlan隧道。

    AP將僅使用vxlan封裝來傳送使用者端流量（且僅適用於處於RUN狀態的使用者端），因此，在光纖使用者端連線之前，在AP上看不到任何vxlan資訊是很正常的。

    在AP上，客戶端連線後，命令show ip tunnel fabric將顯示vxlan隧道資訊。

    AP4001.7A03.5736#show ip tunnel fabric
Fabric GWs Information:
Tunnel-Id           GW-IP            GW-MAC        Adj-Status Encap-Type Packet-In Bytes-In Packet-Out Bytes-out
        1    172.16.2.253 00:00:0C:9F:F4:5E           Forward      VXLAN     39731  4209554      16345   2087073
AP4001.7A03.5736#

    在交換矩陣邊緣節點上，命令show access-tunnel summary將顯示為存取點構建的vxlan隧道。當AP加入時，一旦控制平面下令建立隧道，這些隧道就會顯示出來。

    edge01#show access-tunnel summ

Access Tunnels General Statistics:
  Number of AccessTunnel Data Tunnels       = 2


Name   SrcIP           SrcPort DestIP          DstPort VrfId
------ --------------- ------- --------------- ------- ----
Ac1    172.16.2.253    N/A     192.168.102.130 4789    2
Ac0    172.16.2.253    N/A     192.168.102.131 4789    2


Name   IfId            Uptime
------ ---------- --------------------
Ac1    0x0000003B 1 days, 22:53:48
Ac0    0x0000003A 0 days, 22:47:06

    您可以在WLC的access point頁面上檢查與該AP對應的L2 LISP例項ID，然後在連線的交換矩陣邊緣上檢查該例項的統計資訊。

    螢幕截圖2017-11-24(23.16.45)

    SDA-D-6880-1#show lisp instance-id 8188 ethernet statistics
LISP EID Statistics for instance ID 8188 - last cleared: never
Control Packets:
  Map-Requests in/out:                      0/0
    Encapsulated Map-Requests in/out:       0/0
    RLOC-probe Map-Requests in/out:         0/0
    SMR-based Map-Requests in/out:          0/0
    Map-Requests expired on-queue/no-reply  0/0
    Map-Resolver Map-Requests forwarded:    0
    Map-Server Map-Requests forwarded:      0
  Map-Reply records in/out:                 0/0
    Authoritative records in/out:           0/0
    Non-authoritative records in/out:       0/0
    Negative records in/out:                0/0
    RLOC-probe records in/out:              0/0
    Map-Server Proxy-Reply records out:     0
  Map-Register records in/out:              24/0
    Map-Server AF disabled:                 0
    Authentication failures:                0
  Map-Notify records in/out:                0/0
    Authentication failures:                0
  Deferred packet transmission:             0/0
    DDT referral deferred/dropped:          0/0
    DDT request deferred/dropped:           0/0

    方案4.一段時間後訪問隧道條目丟失

    當透過Cisco DNA-C調配WLC並增加到交換矩陣時，可能第一次成功建立接入隧道，但在重新調配無線配置（如WLAN配置）時，會發現AP的接入隧道條目缺失，導致無線客戶端無法成功獲取IP。

    拓撲是9500(CP) —> 9300 （邊緣） —> AP —>無線客戶端。

    在邊緣節點上的show access-tunnel summary中正確觀察了條目：

    edge_2#show access-tunnel summary

Access Tunnels General Statistics:
Number of AccessTunnel Data Tunnels = 1


Name SrcIP SrcPort DestIP DstPort VrfId
------ --------------- ------- --------------- ------- ----
Ac0 172.16.3.98 N/A 172.16.3.131 4789 0


Name IfId Uptime
------ ---------- --------------------
Ac0 0x0000003C 5 days, 18:19:37



    但當檢查show platform software fed switch active ifm interfaces access-tunnel時，此示例的硬體中缺少AP條目或無法對其進行程式設計。 

    edge_2#show platform software fed switch active ifm interfaces access-tunnel
Interface IF_ID State
----------------------------------------------------------------
Ac0 0x0000003c FAILED

    更多輸出：

    edge_2#sh platform software access-tunnel switch active F0
Name SrcIp DstIp DstPort VrfId Iif_id Obj_id Status
--------------------------------------------------------------------------------------------
Ac0 98.3.16.172 131.3.16.172 0x12b5 0x000 0x00003c 0x00585f Done


edge_2#sh platform software access-tunnel switch active R0
Name SrcIp DstIp DstPort VrfId Iif_id
---------------------------------------------------------------------
Ac0 172.16.3.98 172.16.3.131 0x12b5 0x0000 0x00003c


    您需要比較不同的輸出，並且show access-tunnel summary顯示的每個隧道必須存在。

    場景5.無線客戶端無法獲取IP地址

    如果vxlan隧道存在，並且所有看起來都正常，但是無線客戶端系統性地無法獲取IP地址，則您可能會遇到選項82問題。由於客戶端的DHCP DISCOVER由邊緣節點上的任播網關轉發，因此在返回時將有問題透過邊界將DHCP伺服器OFFER傳送到右邊緣節點。這就是為什麼轉發DHCP DISCOVER的交換矩陣邊緣會在DHCP DISCOVER中附加選項82欄位，該欄位包含邊緣節點的實際交換矩陣RLOC （環回IP）以及其他資訊。這意味著您的DHCP伺服器必須支援選項82。

    要排除DHCP過程故障，請在交換矩陣節點（尤其是客戶端邊緣節點）上捕獲資訊，以驗證交換矩陣邊緣是否正在增加選項82欄位。

    案例 6.訪客交換矩陣/Web身份驗證不起作用/無法重定向客戶端

    訪客交換矩陣方案與Flexconnect存取點上的中央Web身份驗證(CWA)極其相似，並且工作方式完全相同（即使交換矩陣AP未處於flexconnect模式）。

    重定向ACL和URL必須由ISE在第一個MAC身份驗證結果中返回。驗證ISE日誌中的日誌以及WLC上的客戶端詳細資訊頁面。

    重定向ACL必須作為WLC上的Flex ACL顯示，並且必須包含對埠8443上的ISE IP地址的「permit」語句（至少）。

    在WLC上的使用者端詳細資訊頁面中，使用者端應處於「CENTRAL_WEBAUTH_REQ」狀態。客戶端將無法ping通其預設網關，這是正常的。如果未重定向，您可以嘗試在客戶端Web瀏覽器中手動鍵入IP地址（以排除DNS，但無論如何都必須解析ISE主機名）。您應該能夠在客戶端瀏覽器中輸入埠8443上的ISE IP並檢視門戶頁面，因為此流不會重定向。如果沒有發生這種情況，您可能會面臨ACL問題或路由問題。沿途收集資料包捕獲，檢視HTTP資料包的停止位置。

    瞭解

    無線客戶端如何獲得交換矩陣架構中的IP地址捕獲邊框01 DHCP客戶端

    資料包捕獲在交換矩陣AP和交換矩陣邊緣之間進行。資料包重複，因為已傳送兩個DHCP發現資料包。流量僅在交換矩陣邊緣輸入和捕獲。 

    始終有兩個DHCP資料包。由CAPWAP直接傳送到控制器以保持其更新。另一個由VXLAN傳送到控制節點。例如，當AP透過DHCP伺服器收到包含VXLAN的DHCP服務時，它會使用CAPWAP將副本傳送到控制器。

    捕獲VXLAN請求
    要檢視資料包的傳送位置，您需要在Wireshark上按一下它。此處我們可以看到源地址是我們的存取點172.16.3.131，資料包已傳送到交換矩陣邊緣172.16.3.98。交換矩陣邊緣將其轉發到控制節點。

    瞭解交換矩陣方案中的Web重定向流

    WLC上的重新導向ACL會定義在相符的deny陳述式上重新導向/攔截哪些流量（結尾有隱含的deny）。要重定向的資料流將被傳送到WLC的CAPWAP封裝內，以供WLC重定向。當匹配permit語句時，它不會重定向該流量並讓它透過交換矩陣並在交換矩陣上轉發該流量（向ISE的流量進入此類別）。

    以交換矩陣啟用狀態加入WLC的AP的日誌

    一旦存取點註冊到WLC，控制器就會在SDA控制節點（LISP對映伺服器）中註冊其IP和MAC地址。 

    只有在WLC收到LISP RLOC資料包時，AP才會以交換矩陣啟用模式加入WLC。傳送此資料包是為了確保AP已連線到交換矩陣邊緣。

    以下示例在WLC上使用的調試是：

    • 'debug capwap events enable’
    • 'debug capwap errors enable'
    • '啟用調試結構ap加入事件'
    • 'debug fabric ap-join detail enable'
    • 'debug fabric lisp map-server all enable'

    在測試中，AP重新啟動：

    *spamApTask0: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for Aggregated Payload 3 sent to 172.16.3.131:5256
*msfMsgQueueTask: May 07 13:00:18.804: NAK list count becoming 0
*msfMsgQueueTask: May 07 13:00:18.804: NAK list count becoming 0
*msfMsgQueueTask: May 07 13:00:18.804: Cleaned up AP RLOC NAK entry for AP 172.16.3.131 vnid 4097 for BOTH MS
*msfMsgQueueTask: May 07 13:00:18.804: Inserted entry for AP IP 172.16.3.131 and VNID 4097, db idx 12
*msfMsgQueueTask: May 07 13:00:18.804: Map-reply timer started for AP IP 172.16.3.131 and VNiD 4097
*msfMsgQueueTask: May 07 13:00:18.804: Creating new timer for AP IP 172.16.3.131 and VNID 4097
*msfMsgQueueTask: May 07 13:00:18.804: Map-reply Timer Started Successfully for AP IP 172.16.3.131 and VNID 4097
*msfMsgQueueTask: May 07 13:00:18.804: Not able to find nonce 0x3cd13556-0x81864b7b avl entry
*msfMsgQueueTask: May 07 13:00:18.804: FAIL: not able to find avl entry
*msfMsgQueueTask: May 07 13:00:18.804: Nonce 0x3cd13556-0x81864b7b inserted into nonce aVL tree for AP IP 172.16.3.131 VNID 4097 for MS 172.16.3.254
*msfMsgQueueTask: May 07 13:00:18.804: Set nonce 0x3cd13556-0x81864b7b for AP 172.16.3.131 and VNID 4097
*msfMsgQueueTask: May 07 13:00:18.804: Nonce 0x3cd13556-0x81864b7b is updated for AP IP 172.16.3.131, VNID 4097 and MS IP 172.16.3.254, db idx 12
*spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for PHY payload sent to 172:16:3:131
*msfMsgQueueTask: May 07 13:00:18.804: Build and send map-request for AP IP 172.16.3.131 and VNID 4097 to MS IP 172.16.3.254
*spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:3:131
*spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:3:131
*msfMsgQueueTask: May 07 13:00:18.804: nonce = 3cd13556-81864b7b lisp_map_request_build allocating nonce
*spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for RrmNeighbourCtrl payload sent to 172.16.3.131
*spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for CcxRmMeas payload sent to 172.16.3.131
*msfMsgQueueTask: May 07 13:00:18.804: Sending map-request for AP 172.16.3.131 VNID 4097 to MS 172.16.3.254
*spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for AP ext-logging AP ext-logging message sent to 172.16.3.131:5256
*spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update for Delba sent to 172.16.3.131:5256
*msfMsgQueueTask: May 07 13:00:18.804: Map-request for AP IP 172.16.3.131 VNID 4097 to MS 172.16.3.254 is sent
*msfMsgQueueTask: May 07 13:00:18.804: Sent map-request to MS 172.16.3.254 for AP 172.16.3.131 VNID 4097
*msfMsgQueueTask: May 07 13:00:18.804: Invalid secondary MS IP 0.0.0.0 for map-request for AP IP 172.16.3.131
*msfMsgQueueTask: May 07 13:00:18.804: No messages are present in the Client list for Local UDP socket
*msfTcpTask: May 07 13:00:18.807: Sending the UDP control packet to queue task
*msfMsgQueueTask: May 07 13:00:18.807: msfQueue: recieved LISP_MAP_SERVER_UDP_PACKET_QUEUE_MSG
*msfMsgQueueTask: May 07 13:00:18.807: Mapping Record has locators and actions
*msfMsgQueueTask: May 07 13:00:18.807: Mapping record address 172.16.3.98 EID address 172.16.3.98
*msfMsgQueueTask: May 07 13:00:18.807: Got AVL entry for nonce 0x3cd13556-0x81864b7b in map-reply for AP IP 172.16.3.131
*msfMsgQueueTask: May 07 13:00:18.807: Sent received RLOC IP 172.16.3.98 for AP 172.16.3.131 and VNID 4097 in map-reply to spam task
*msfMsgQueueTask: May 07 13:00:18.807: Added RLOC 172.16.3.98 for AP IP 172.16.3.131
*spamReceiveTask: May 07 13:00:18.807: Recieved Fabric rloc response from msip 172.16.3.254 with apvnid 4097,fabricRLoc 172.16.3.98 apip 172.16.3.131 apRadMac 70:70:8b:20:29:00

    修訂記錄

    修訂 發佈日期 意見
    1.0
    17-Oct-2019
    初始版本
    TAC Authored

    由思科工程師貢獻

    • Nicolas Darchis
      Cisco TAC

    這份文件是否有所幫助？

    Feedback意見

    讓思科協助您

    本文件適用於這些產品