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

はじめに

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

前提条件

要件

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

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

使用するコンポーネント

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

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

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

トポロジ

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

迅速な検証

SDアクセスのシナリオには、多くの場合エラーの原因となる一連の要件があります。まずこれらの要件が満たされていることを確認してください（次のセクションを参照）。

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

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

 WLCをDNA Centerのファブリックに追加すると、コマンドがコントローラにプッシュされ、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 Pooから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が接続されているファブリックエッジノードを要求して、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のアクセスポイントページで、その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を転送するファブリックエッジは、DHCP DISCOVERにオプション82フィールドを追加します。このフィールドには、符号化されたエッジノードの実際のファブリックRLOC（ループバックIP）とその他の情報が含まれています。これは、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