SD-Access 무선 초기 설정 문제 해결 및 확인

소개

이 문서에서는 SD-Access 무선 설정에서 기본 연결 문제를 식별하는 기본 문제 해결 단계에 대해 설명합니다.무선 관련 솔루션에서 문제를 격리하기 위해 확인할 항목 및 명령에 대해 설명합니다.

사전 요구 사항

요구 사항

SD-Access 솔루션에 대한 지식

이미 SD 액세스 토폴로지를 설정했습니다.

사용된 구성 요소

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 이해해야 합니다.SD 액세스 무선에 대해 지원되는 다른 유형의 장치도 있지만, 이 문서에서는 이 섹션에 설명된 장치에 대해 중점적으로 설명합니다.명령은 플랫폼 및 소프트웨어 버전에 따라 다를 수 있습니다.

8.5.151 무선 컨트롤러

16.9.3 9300 스위치(에지 노드)

토폴로지

문제 해결 및 격리

빠른 확인

SD 액세스 시나리오에는 종종 실수의 원인이 되는 일련의 요구 사항이 있으므로 먼저 이러한 요구 사항이 충족되었는지 확인하십시오.

• LISP 컨트롤 플레인 노드의 WLC를 가리키는 특정 경로(기본 경로를 사용하지 않음)가 있는지 확인합니다.
• 전역 라우팅 테이블을 사용하여 AP가 Infra VN에 있는지 확인합니다.
• AP 자체에서 WLC를 ping하여 AP가 WLC에 연결되었는지 확인합니다.
• WLC의 컨트롤 플레인의 패브릭 상태가 작동 중인지 확인합니다.
• 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에서 디버그 패브릭 목록 맵 서버로 디버깅됩니다.재연결을 시도하려면 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 이벤트 사용'
• '디버그 capwap 오류 사용'
• '디버그 패브릭 ap-join 이벤트 활성화'
• '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는 항상 등록 또는 쿼리를 위해 양쪽 모두에 도달합니다.두 컨트롤 플레인 모두 등록 시 긍정적인 응답을 제공할 것으로 예상되므로 두 컨트롤 플레인 중 하나가 어떤 이유로든 이를 거부하면 WLC가 패브릭에서 AP를 등록하지 못합니다.그러나 응답이 없는 컨트롤 플레인 하나가 허용되며 나머지 컨트롤 플레인이 사용됩니다.

AP는 글로벌 라우팅 테이블을 통해 WLC에 연결되지만 LISP는 WLC를 확인하는 데 계속 사용됩니다.AP가 WLC로 보낸 트래픽은 순수 CAPWAP 제어(vxlan은 포함되지 않음)이지만 WLC에서 AP로 보낸 반환 트래픽은 오버레이에서 Vxlan을 통해 전달됩니다.에지의 AP 게이트웨이 SVI에서 WLC로의 연결을 테스트할 수 없습니다. Anycast 게이트웨이이기 때문에 동일한 IP가 보더 노드에도 있기 때문입니다.연결을 테스트하려면 AP 자체에서 ping하는 것이 가장 좋습니다.

시나리오 2. 액세스 포인트에서 IP 주소를 가져오지 않습니다.

액세스 포인트는 DNA Center에 정의된 Infra VNl의 AP Po에서 IP 주소를 가져와야 합니다.이러한 문제가 발생하지 않으면 일반적으로 AP가 연결된 스위치 포트가 올바른 VLAN으로 이동하지 않았음을 의미합니다.CDP를 통해 연결 중인 액세스 포인트를 탐지할 경우 스위치는 AP 풀에 대해 DNA-C가 정의한 VLAN에서 스위치 포트를 설정하는 switchport 매크로를 적용합니다.문제가 있는 스위치 포트가 매크로로 구성되지 않은 경우 AP가 IP를 가져오고 WLC에 가입하며 코드를 업그레이드하고 CDP 버그를 해결할 수 있도록 수동으로 컨피그레이션을 설정하거나 CDP 연결 프로세스를 해결할 수 있습니다.선택적으로 호스트 온보딩을 구성하여 AP를 호스팅하도록 DNA-Center의 포트를 정적으로 정의하여 올바른 컨피그레이션으로 프로비저닝할 수 있습니다.

스위치가 하나 이상의 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는 클라이언트 트래픽(RUN 상태의 클라이언트에만 해당)을 전송하기 위해 vxlan 캡슐화만 사용하므로 패브릭 클라이언트가 연결될 때까지 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#

Fabric Edge 노드에서 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(Edge) —> AP —> Wireless Client입니다.

항목은 에지 노드의 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가 에지 노드의 Anycast 게이트웨이에서 전달되므로, DHCP 서버 OFFER가 돌아오는 도중에 테두리로 오른쪽 에지 노드로 전송될 경우 문제가 있습니다.따라서 DHCP DISCOVER를 전달하는 패브릭 에지는 옵션 82 필드를 다른 정보와 함께 인코딩된 에지 노드의 실제 패브릭 RLOC(루프백 IP)가 포함된 DHCP DISCOVER에 추가합니다.즉, DHCP 서버가 옵션 82를 지원해야 합니다.

DHCP 프로세스를 트러블슈팅하려면 패브릭 노드(특히 클라이언트 에지 노드)에서 캡처를 수행하여 패브릭 에지에 옵션 82 필드가 추가되었는지 확인합니다.

시나리오 6. 게스트 패브릭/웹 인증이 작동하지 않거나 클라이언트를 리디렉션하지 않음

게스트 패브릭 시나리오는 Flexconnect 액세스 포인트의 CWA(Central Web Authentication)와 매우 유사하며 패브릭 AP가 flexconnect 모드가 아닌 경우에도 정확히 동일한 방식으로 작동합니다.

리디렉션 ACL 및 URL은 첫 번째 mac 인증 결과에서 ISE에 의해 반환되어야 합니다.WLC의 클라이언트 세부 정보 페이지와 ISE 로그에 있는 것을 확인합니다.

리디렉션 ACL은 WLC에서 Flex ACL로 있어야 하며 포트 8443(최소)의 ISE IP 주소에 대한 "permit" 문을 포함해야 합니다.

클라이언트는 WLC의 클라이언트 세부사항 페이지에서 "CENTRAL_WEBAUTH_REQ" 상태여야 합니다.클라이언트가 기본 게이트웨이를 ping할 수 없으며 이는 필수입니다.리디렉션되지 않은 경우 클라이언트 웹 브라우저에 IP 주소를 수동으로 입력하도록 시도할 수 있습니다(DNS를 제외하려면 하지만 ISE 호스트 이름은 확인되어야 함). 클라이언트 브라우저에서 포트 8443에 ISE IP를 입력하고 이 흐름이 리디렉션되지 않으므로 포털 페이지를 볼 수 있어야 합니다.이러한 문제가 발생하지 않으면 ACL 문제 또는 라우팅 문제가 발생할 수 있습니다.HTTP 패킷이 중지된 위치를 확인하기 위해 패킷 캡처를 수집합니다.

이해

패브릭 아키텍처에서 무선 클라이언트가 IP 주소를 얻는 방법

패브릭 AP와 패브릭 에지 간에 패킷 캡처가 수행됩니다.두 개의 DHCP Discover 패킷이 전송되었기 때문에 패킷이 복제됩니다.트래픽은 인그레스(ingress)에서만 처리되었으며 패브릭 에지에서 캡처되었습니다. 

항상 두 개의 DHCP 패킷이 있습니다.CAPWAP에서 컨트롤러에 직접 전송하여 업데이트된 상태로 유지합니다.VXLAN에서 제어 노드로 전송하는 다른 것입니다.DHCP 서버에서 VXLAN을 사용하는 DHCP 오퍼와 같은 AP를 받으면 CAPWAP를 사용하여 컨트롤러에 사본을 보냅니다.

패킷이 전송된 위치를 확인하려면 Wireshark에서 패킷을 클릭해야 합니다.여기에서는 소스가 AP 172.16.3.131이고 패킷이 패브릭 에지 172.16.3.98으로 전송되었음을 확인할 수 있습니다. 패브릭 에지가 이를 제어 노드로 전달했습니다.

패브릭 시나리오의 웹 리디렉션 흐름 이해

WLC의 리디렉션 ACL은 일치하는 거부 명령문에서 리디렉션/가로채기되는 트래픽을 정의합니다(끝에는 암시적 거부가 있음). 리디렉션될 트래픽은 WLC가 리디렉션할 CAPWAP 캡슐화 내의 WLC로 전송됩니다.허용 명령문을 매칭할 때, 해당 트래픽을 리디렉션하지 않고 패브릭에서 트래픽을 통과하여 전달할 수 있습니다(ISE로 향하는 트래픽은 이 카테고리로 진입).

패브릭 활성화 상태에서 WLC에 조인하는 AP의 로그

액세스 포인트가 WLC에 등록되는 즉시 컨트롤러는 SDA 제어 노드(LISP 맵 서버)에 IP 및 MAC 주소를 등록합니다. 

WLC가 LISP RLOC 패킷을 수신하는 경우에만 AP가 패브릭 활성화 모드에서 WLC에 조인합니다.이 패킷은 AP가 패브릭 에지에 연결되어 있는지 확인하기 위해 전송됩니다.

이 예제의 WLC에서 사용되는 디버그는 다음과 같습니다.

• 'debug capwap 이벤트 사용'
• '디버그 capwap 오류 사용'
• '디버그 패브릭 ap-join 이벤트 활성화'
• '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