Resuelva problemas y verifique la configuración inicial de la Tecnología inalámbrica del SD-acceso

Introducción

Este artículo describe los pasos básicos para Troubleshooting para identificar los aspectos básicos de conectividad en configuraciones de la Tecnología inalámbrica del SD-acceso. Describirá los elementos y los comandos de marcar para aislar los problemas en la solución referente a la Tecnología inalámbrica.

Prerrequisitos

Requisitos

Conocimiento de la solución del SD-acceso

Ya una topología del SD-acceso de la configuración

Componentes usados

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando. Hay otros tipos de dispositivos soportados para la Tecnología inalámbrica del SD-acceso, pero focos de este artículo en los dispositivos descritos en esta sección. Los comandos pueden variar dependiendo de la plataforma y de la versión de software.

8.5.151 Regulador inalámbrico

9300 Switch 16.9.3 como nodo del borde

Topología

Troubleshooting y aislante

Verificaciones rápidas

Hay las series de requisitos en los escenarios del SD-acceso que son a menudo una fuente de errores, satisface tan verifica primero que estos requisitos estén cumplidos:

• Aseegurese que usted tiene una ruta específica (y no usando la predeterminada) que señala al WLC en el nodo del avión del control lisp
• Aseegurese que sus AP están en infra el VN, usando la tabla de Global Routing
• Aseegurese que los AP tienen Conectividad al WLC haciendo ping el WLC del AP sí mismo
• Aseegurese que el estatus de la tela del avión del control en el WLC está para arriba
• Aseegurese que los AP están en el estado de la tela enabled

el escenario 1. verifica el registro del WLC con el avión del control de servidor LISP/MAP

 Cuando usted agrega el WLC a la tela en el centro DNA, los comandos se avanzan al regulador de establecer una conexión al nodo definido como avión del control en DNA-C. El primer paso es asegurarse que este registro es acertado. Si la configuración lisp en el avión del control consiguió corrompida de cierta manera, este registro podría fallar.

Si este estatus muestra como abajo, puede ser interesante funcionar con los debugs o a una captura de paquetes entre el WLC y el avión del control. El registro implica el TCP y el UDP en 4342. Si el avión del control no consiguió la configuración adecuada, puede ser que conteste con un TCP RST al TCP SYN enviado por el WLC.

El mismo estatus se puede verificar con el resumen del mapa-servidor de la tela de la demostración en la línea de comando. El proceso se hace el debug de con el mapa-servidor todo del lisp de la tela del debug en el WLC CLI. Para provocar una tentativa de la reconexión, usted puede ir al centro DNA y eligió quitar el WLC de la tela y agregarlo otra vez.

Las razones posibles son líneas que falta de los config en el avión del control. Aquí es un config el trabajo del ejemplo (la mayoría de la parte importante solamente):

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

Si el IP del WLC falta (10.241.0.41 aquí) o si el comando pasivo-abierto falta, el CP rechaza la conexión del WLC.

Los debugs a ejecutarse son: 

• “permiso de los eventos del capwap del debug”
• “permiso de los errores del capwap del debug”
• la “tela del debug ap-se une al permiso de los eventos”
• la “tela del debug ap-se une al permiso del detalle”
• “el mapa-servidor todo del lisp de la tela del debug habilita”

Aquí está un ejemplo del avión del control que no contesta al 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

Aquí está un ejemplo de los debugs del WLC de un AP que se une a en el estado inhabilitado de la tela porque el avión del control de la tela faltaba una ruta específica al 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

Es interesante observar que si hay dos aviones del control en su red de la tela, el WLC alcanzará siempre hacia fuera a ambos para el registro o las interrogaciones. Se espera que ambo el avión del control dé las respuestas positivas en los registros, así que el WLC no podrá registrar los AP en la tela si una del control dos plano lo rechaza por cualquier motivo. Una contestación plana del control es aceptable sin embargo y el avión restante del control será utilizado.

Los AP alcanzan hacia fuera al WLC a través de la tabla de Global Routing, pero el lisp todavía se utiliza para resolver el WLC. El tráfico enviado por los AP al WLC es control puro CAPWAP (implicado no vxlan), pero el tráfico de retorno enviado por el WLC al AP será Vxlan transportado en el recubrimiento. Usted no podrá probar la Conectividad del gateway SVI AP en el borde hacia el WLC porque como es un gateway del Anycast, el mismo IP existe también en el nodo de borde. Para probar la Conectividad, el mejor es hacer ping del AP sí mismo.

el escenario 2. Puntos de acceso no está consiguiendo un IP Address

Se espera que los Puntos de acceso consigan un IP Address del AP Poo, en infra el VNl definido en el centro DNA. Si no sucede esto, significa típicamente que el switchport donde el AP está conectado no se movió a la derecha vlan. El Switch, cuando la detección (con el CDP) los acess señala la conexión, aplicará una macro del switchport que fije el switchport en el vlan definida por DNA-C para el pool AP. Si el switchport problemático no se configura de hecho con la macro, usted puede fijar la configuración manualmente (de modo que el AP consiga un IP, se une al WLC y actualiza probablemente su código y resuelve posiblemente cualquier bug CDP) o resolver problemas el proceso de la conexión CDP. Usted puede configurar opcionalmente el host onboarding para definir estáticamente el puerto en el DNA-centro para recibir un AP de modo que sea aprovisionado con la configuración correcta.

Las macros de Smartport no golpean con el pie adentro automáticamente si el Switch no era aprovisionado con un AP por lo menos, usted pueden verificar si la macro AP era aprovisionado con el vlan derecho (en vez del 1) vlan predeterminado

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

Los comandos que Cisco DNA-C avanza para fijar esto son

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

el escenario 3. Puntos de acceso no tiene un túnel vxlan construido hacia su nodo del borde de la tela

Una vez que un AP se une al WLC, el WLC (si el AP es tela capaz) registrará el AP en el avión del control como tipo especial de cliente. El avión del control entonces pedirá el nodo del borde de la tela donde el AP está conectado para construir un túnel vxlan hacia el AP.

El AP utilizará solamente la encapsulación vxlan para enviar el tráfico del cliente (y solamente para los clientes en el estado de FUNCIONAMIENTO), por lo tanto es normal no ver ninguna información vxlan sobre el AP hasta que un cliente de la tela conecte.

En el AP, la tela del túnel del comando show ip mostrará la información del túnel vxlan una vez que un cliente ha conectado.

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#

En el nodo del borde de la tela, el resumen del acceso-túnel del comando show mostrará los túneles vxlan construidos hacia los Puntos de acceso. Los túneles mostrarán tan pronto como el avión del control pidiera su creación cuando el AP se une a.

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

Usted puede comprobar el WLC, en la página del Punto de acceso, la identificación del caso lisp L2 correspondiente a ese AP y entonces marcar las estadísticas de ese caso en la tela afilan donde está conectada.

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

entradas del túnel del acceso del escenario 4. que faltan un poco después

Es posible que los túneles del acceso están creados con éxito la primera vez cuando el WLC es aprovisionado con Cisco DNA-C y agregado a la tela pero cuando se observa la configuración de red inalámbrica del re-aprovisionamiento (como la configuración de la red inalámbrica (WLAN)) él que las entradas del túnel del acceso para los AP están faltando los clientes de red inalámbrica resultantes no pueden conseguir con éxito el IP.

La topología es 9500(CP) --> 9300 (borde) --> AP --> cliente de red inalámbrica.

Las entradas se observan correctamente en el resumen del acceso-túnel de la demostración en el nodo del borde:

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

Pero cuando marcar el software de plataforma de la demostración alimentó el Switch que el ifm activo interconecta el acceso-túnel, la entrada para el AP es que falta o no podida ser programado en el hardware en este ejemplo.

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

Para más ouputs:

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

Usted necesita comparar las diversas salidas y cada túnel mostrado por el resumen del acceso-túnel de la demostración debe estar presente en cada uno de ellas.

clientes de red inalámbrica del escenario 5. no capaces de obtener una dirección IP

Si el túnel vxlan es presente y todo parece bueno pero los clientes de red inalámbrica no pueden sistemáticamente obtener una dirección IP que usted está haciendo frente quizá a un problema de la opción 82. Puesto que el DHCP DISCOVER del cliente es remitido por el gateway del Anycast en el nodo del borde, habría problema para que la OFERTA del servidor DHCP sea enviada al nodo del borde derecho por la frontera en la manera detrás. Esta es la razón por la cual el borde de la tela que adelante el DHCP DISCOVER añade un campo de la opción al final del fichero 82 al DHCP DISCOVER que contenga la tela real RLOC (IP del loopback) del nodo del borde codificado junto con otras informaciones. Esto significa que su servidor DHCP debe soportar la opción 82.

Para resolver problemas el proceso DHCP, la toma captura en los Nodos de la tela (especialmente el nodo del borde del cliente) para verificar que el borde de la tela está añadiendo el campo de la opción al final del fichero 82.

tela del invitado del escenario 6./trabajo/de la autenticación Web que no reorienta a los clientes

El escenario de la tela del invitado es extremadamente similar a la autenticación Web central (CWA) en los Puntos de acceso y el trabajo de Flexconnect exactamente la misma manera (incluso si la tela AP no está en el modo del flexconnect).

El cambio de dirección ACL y URL se debe volver por el ISE en el primer resultado de la autenticación del mac. Verifique ésos en los registros ISE así como la página del detalle del cliente en el WLC.

La reorientación ACL debe ser presente como flexión ACL en el WLC y debe contener las declaraciones del “permiso” hacia la dirección IP ISE en el puerto 8443 (por lo menos).

El cliente debe estar en el estado “CENTRAL_WEBAUTH_REQ” en la página de los detalles del cliente en el WLC. El cliente no podrá hacer ping su default gateway y se espera esto. Si le no reorientan usted puede intentar teclear manualmente un IP Address en el buscador Web del cliente (eliminar el nombre de host DNS, pero ISE tendrá que ser resuelta de todos modos). Usted debe poder ingresar el IP ISE en el puerto 8443 en el buscador del cliente y ver la página porta pues este flujo no será reorientado. Si no sucede esto, usted está haciendo frente a un problema ACL o a un problema de ruteo hacia. Recoja a las capturas de paquetes a lo largo del camino para ver donde se paran los paquetes HTTP.

Entienda

Cómo hace a un cliente de red inalámbrica consiga una dirección IP en arquitectura de la tela

Toman la captura de paquetes entre la tela AP y el borde de la tela. Se duplica el paquete porque dos DHCP descubren que los paquetes fueron enviados. El tráfico era solamente ingreso y capturado en el borde de la tela. 

Hay siempre dos paquetes DHCP. Uno enviado por CAPWAP directamente al regulador para mantenerlo puesto al día. El otro enviado por VXLAN al nodo del control. Cuando el AP recibe por ejemplo una oferta de DHCP con VXLAN del servidor DHCP, envía una copia al regulador con CAPWAP.

Para ver adonde el paquete fue enviado, usted necesita hacerlo clic en Wireshark. Aquí podemos ver que la fuente es nuestro AP 172.16.3.131 y el paquete fue enviado al borde 172.16.3.98 de la tela. El borde de la tela lo remitió al nodo del control.

Entienda el flujo del cambio de dirección de la red en un escenario de la tela

La reorientación ACL en el WLC define qué tráfico se reorienta/se intercepta en los enunciados de negación que corresponden con (hay un implícito niega en el extremo). Que el tráfico que se reorientará será enviado al WLC dentro de la encapsulación CAPWAP para que el WLC reoriente. Al corresponder con una declaración del permiso, no reorienta ese tráfico y lo deja a través y adelante él en la tela (el tráfico hacia el ISE ingresa esta categoría).

Registros del AP que se une al WLC en el estado de la tela enabled

Tan pronto como el registro de la Acceso-punta al WLC, regulador registre su IP y dirección MAC en el nodo del control SDA (servidor del mapa lisp). 

El AP se une al WLC en el modo de la tela enabled solamente si el WLC recibe el paquete lisp RLOC. Este paquete se envía para estar seguro que el AP está conectado con un borde de la tela.

Los debugs usados en el WLC para este ejemplo son:

• “permiso de los eventos del capwap del debug”
• “permiso de los errores del capwap del debug”
• la “tela del debug ap-se une al permiso de los eventos”
• la “tela del debug ap-se une al permiso del detalle”
• “el mapa-servidor todo del lisp de la tela del debug habilita”

Para la prueba, se reinicia el 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