SD-Accessワイヤレスの初期設定のトラブルシューティングと確認

はじめに

この記事では、SD-Accessワイヤレス設定の基本的な接続の問題を特定するための基本的なトラブルシューティング手順について説明します。ワイヤレスに関連するソリューションの問題を切り分けるためにチェックする項目とコマンドについて説明します。

前提条件

要件

SD-Accessソリューションの知識

すでにセットアップされているSDアクセストポロジ

使用するコンポーネント

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。SDアクセスワイヤレスでサポートされるデバイスは他のタイプもありますが、この記事では、このセクションで説明するデバイスを中心に説明します。コマンドは、プラットフォームとソフトウェアのバージョンによって異なります。

8.5.151ワイヤレスコントローラ

16.9.3エッジノードとしての9300スイッチ

トポロジ

トラブルシューティングと切り分け

迅速な検証

SDアクセスのシナリオには、ミスの原因となる要件が複数存在するため、まずこれらの要件が満たされていることを確認してください（SDアクセスの要件はSDカードのサイズによって異なります）。

• LISPコントロールプレーンノードのWLCを指す特定のルート（デフォルトのルートを使用していないルート）があることを確認します
• グローバルルーティングテーブルを使用して、APがInfra VNにあることを確認します
• AP自体からWLCにPINGを実行して、APがWLCに接続できることを確認します
• WLC上のコントロールプレーンのファブリックステータスが「up」であることを確認します
• APがファブリック対応状態であることを確認します

シナリオ 1.LISP/MAPサーバのコントロールプレーンを使用したWLCの登録の確認

 DNA CenterでファブリックにWLCを追加すると、コマンドがコントローラにプッシュされ、DNA-Cでコントロールプレーンとして定義されているノードへの接続が確立されます。最初のステップは、この登録が正常に行われたことを確認することです。コントロールプレーン上のLISP設定が何らかの理由で破損した場合、この登録は失敗する可能性があります。

このステータスがdownと表示される場合は、WLCとコントロールプレーンの間でデバッグまたはパケットキャプチャを実行するのが興味深い場合があります。4342での登録には、TCPとUDPの両方が含まれます。コントロールプレーンが適切な設定を取得しなかった場合、コントロールプレーンはWLCによって送信されたTCP SYNにTCP RSTで応答する場合があります。

同じステータスが、コマンドラインで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’
• 「debug fabric ap-join events enable」
• 「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

次に、ファブリックが無効な状態で参加しているAPのWLCデバッグの例を示します。これは、ファブリックのコントロールプレーンで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

興味深いことに、ファブリックネットワークに2つのコントロールプレーンがある場合、WLCは登録またはクエリのために常に両方に到達します。両方のコントロールプレーンが登録に対して肯定応答を返すことが想定されるため、2つのコントロールプレーンのどちらかが何らかの理由で拒否した場合、WLCはファブリックへのAPの登録に失敗します。1つのコントロールプレーンが応答しないことは許容されますが、残りのコントロールプレーンが使用されます。

APはグローバルルーティングテーブルを介してWLCに到達しますが、WLCの解決には引き続きLISPが使用されます。APからWLCに送信されるトラフィックは純粋なCAPWAP制御ですが（vxlanは含まれません）、WLCからAPに送信されるリターントラフィックは、オーバーレイ上のVxlanを介して伝送されます。エニーキャストゲートウェイであるため、同じIPが境界ノードにも存在するため、エッジ上のAPゲートウェイSVIからWLCへの接続をテストできません。接続をテストする最善の方法は、AP自体からpingを実行することです。

シナリオ 2.アクセスポイントがIPアドレスを取得していない

アクセスポイントは、DNA Centerで定義されているInfra VNl内のAPプールからIPアドレスを取得することが想定されています。これが発生しない場合、通常はAPが接続されているスイッチポートが正しいVLANに移動していないことを意味します。スイッチは、接続されているアクセスポイントを（CDPを介して）検出すると、APプールのDNA-Cで定義されているVLANにスイッチポートを設定するswitchportマクロを適用します。問題のあるスイッチポートが実際にマクロを使用して設定されていない場合は、設定を手動で設定するか（APがIPを取得し、WLCに加入して、おそらくコードをアップグレードし、場合によってはCDPの不具合を解決する）、CDP接続プロセスをトラブルシューティングします。APをホストするDNA-Center上のポートを静的に定義して、正しい設定でプロビジョニングされるように、ホストオンボーディングをオプションで設定できます。

スイッチが少なくとも1つのAPでプロビジョニングされていない場合、SmartPortマクロは自動的には起動しません。APマクロが（デフォルトのvlan 1ではなく）正しいvlanでプロビジョニングされているかどうかを確認できます

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に向けてvxlanトンネルを構築するために、APが接続されているファブリックエッジノードを要求します。

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のアクセスポイントページで、そのAPに対応するL2 LISPインスタンスIDを確認し、接続先のファブリックエッジでそのインスタンスの統計情報を確認できます。

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：しばらくするとアクセストンネルエントリが消失する

WLCがCisco DNA-Cを通じてプロビジョニングされ、ファブリックに追加されたときに、最初にアクセストンネルが正常に作成される可能性がありますが、ワイヤレス設定（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を転送するファブリックエッジは、エッジノードの実際のファブリックRLOC（ループバックIP）とその他の情報を含むDHCP DISCOVERにオプション82フィールドを追加します。これは、DHCPサーバがオプション82をサポートする必要があることを意味します。

DHCPプロセスのトラブルシューティングを行うには、ファブリックノード（特にクライアントエッジノード）のキャプチャを取得して、ファブリックエッジがオプション82フィールドに追加されていることを確認します。

シナリオ 6.ゲストファブリック/Web認証が機能しない/クライアントをリダイレクトしない

ゲストファブリックのシナリオは、Flexconnectアクセスポイントの中央Web認証(CWA)に非常によく似ており、ファブリックAPがFlexConnectモードでない場合でも、まったく同じように動作します。

リダイレクトACLとURLは、最初のMAC認証結果でISEから返される必要があります。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アドレスを取得する方法

パケットキャプチャは、ファブリックAPとファブリックエッジの間で行われます。2つのDHCP Discoverパケットが送信されたため、パケットが重複しています。トラフィックは入力のみで、ファブリックエッジでキャプチャされました。 

常に2つのDHCPパケットがあります。1つはCAPWAPによってコントローラに直接送信され、最新の状態に保たれます。もう1つはVXLANからコントロールノードに送信されるパケットです。APは、たとえばVXLANを使用するDHCPオファーをDHCPサーバで受信すると、CAPWAPを使用してコピーをコントローラに送信します。

パケットの送信先を確認するには、Wiresharkでパケットをクリックする必要があります。ここに、送信元がAP 172.16.3.131であり、パケットがファブリックエッジ172.16.3.98に送信されたことが分かります。ファブリックエッジはそれをコントロールノードに転送しました。

ファブリックシナリオでのWebリダイレクションフローの理解

WLCのリダイレクトACLは、一致するdeny文でリダイレクト/インターセプトされるトラフィックを定義します（最後に暗黙のdenyがあります）。リダイレクトされるトラフィックは、リダイレクトするWLCのCAPWAPカプセル化の内側のWLCに送信されます。permit文に一致する場合、そのトラフィックはリダイレクトされず、ファブリックを通過して転送されます（ISEへのトラフィックがこのカテゴリに入ります）。

ファブリック対応状態でWLCに参加しているAPのログ

アクセスポイントがWLCに登録されるとすぐに、コントローラはそのIPアドレスとMACアドレスをSDAコントロールノード（LISPマップサーバ）に登録します。 

APは、WLCがLISP RLOCパケットを受信する場合にのみ、ファブリック対応モードでWLCに加入します。このパケットは、APがファブリックエッジに接続されていることを確認するために送信されます。

この例のWLCで使用されているデバッグは次のとおりです。

• 'debug capwap events enable’
• 'debug capwap errors enable’
• 「debug fabric ap-join events enable」
• 「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