Dépannez et vérifiez la première installation de radio d'Écart-type-Access

Introduction

Cet article décrit les étapes de dépannage de base pour identifier les problèmes de connectivité de base en configurations sans fil d'Écart-type-Access. Il décrira les éléments et les commandes de vérifier pour isoler des problèmes dans la solution concernant la radio.

Conditions préalables

Exigences

La connaissance de la solution d'Écart-type-Access

Déjà une topologie d'Écart-type-Access d'installation

Composants utilisés

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes. Il y a d'autres types de périphériques pris en charge pour la radio d'Écart-type-Access, mais foyers de cet article sur les périphériques décrits dans cette section. Les commandes peuvent varier selon la plate-forme et la version de logiciel.

8.5.151 Contrôleur sans-fil

commutateur 16.9.3 9300 comme noeud de périphérie

Topologie

Dépannez et isolez

Vérifications rapides

Il y a une gamme de conditions requises dans des scénarios d'Écart-type-Access qui est souvent une source des erreurs, satisfont ainsi vérifient d'abord que ces exigences sont répondues :

• Assurez-vous que vous avez une artère spécifique (et pas utilisant la par défaut) indiquant le WLC sur le noeud d'avion de contrôle LISP
• Assurez-vous que vos aps sont dans infra la navigation verticale, utilisant la table de routage globale
• Assurez-vous que les aps ont la Connectivité au WLC en cinglant le WLC d'AP lui-même
• Assurez-vous que le statut de matrice de l'avion de contrôle sur le WLC est en hausse
• Assurez-vous que les aps sont dans l'état matrice-activé

le scénario 1. vérifient l'enregistrement WLC avec l'avion de contrôle de serveur LISP/MAP

 Quand vous ajoutez le WLC à la matrice au centre DNA, des commandes sont poussées au contrôleur d'établir une connexion au noeud défini comme avion de contrôle dans DNA-C. La première étape est de s'assurer que cet enregistrement est réussi. Si la configuration LISP sur l'avion de contrôle obtient corrompu d'une certaine façon, cet enregistrement pourrait échouer.

Si cet état affiche en tant que vers le bas, il peut être intéressant d'exécuter des débogages ou une capture de paquet entre le WLC et l'avion de contrôle. L'enregistrement implique les deux le TCP et UDP sur 4342. Si l'avion de contrôle n'obtenait pas la configuration correcte, il pourrait répondre avec un TCP RST à la synchronisation de TCP envoyée par le WLC.

Le même état peut être vérifié avec le résumé de MAP-serveur de show fabric sur la ligne de commande. Le processus est débogué avec le MAP-serveur tout de lisp de matrice de débogage sur le WLC CLI. Pour provoquer une tentative de reconnexion, vous pouvez aller au centre DNA et avez choisi de retirer le WLC de la matrice et de l'ajouter de nouveau.

Les possibles raison manquent des lignes de config dans l'avion de contrôle. Voici un exemple fonctionnant le config (la plupart de partie importante seulement) :

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 l'IP WLC manque (10.241.0.41 ici) ou si la commande passif-ouverte manque, le CP refusera la connexion WLC.

Les débogages à s'exécuter sont : 

• « enable d'événements de capwap de débogage »
• « enable d'erreurs de capwap de débogage »
• la « matrice de débogage AP-joignent l'enable d'événements »
• la « matrice de débogage AP-joignent l'enable de détail »
• « le MAP-serveur tout de lisp de matrice de débogage activent »

Voici un exemple de l'avion de contrôle ne répondant pas au 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

Voici un exemple des débogages WLC d'AP se joignant dans l'état désactivé par matrice parce que l'avion de contrôle de matrice manquait une artère spécifique au 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

Il est intéressant de noter que s'il y a deux avions de contrôle dans votre réseau de matrice, le WLC atteindra toujours à chacun des deux pour l'enregistrement ou les requêtes. On s'attend à ce que les deux l'avion de contrôle donnent des réponses positives sur des enregistrements, ainsi le WLC n'enregistrera pas des aps dans la matrice si une du contrôle deux plat le rejette pour une raison quelconque. Une réponse plate de contrôle est acceptable cependant et l'avion restant de contrôle sera utilisé.

Les aps accèdent au WLC par la table de routage globale, mais le LISP est encore utilisé pour résoudre le WLC. Le trafic envoyé par des aps au WLC est contrôle pur CAPWAP (impliqué pas vxlan), mais le trafic de retour envoyé par le WLC à AP sera Vxlan reporté sur le recouvrement. Vous ne pourrez pas tester la Connectivité de la passerelle SVI AP sur la périphérie vers le WLC parce que car c'est une passerelle de cantonade, le même IP existe également sur le noeud périphérique. Afin de tester la Connectivité, le meilleur est de cingler d'AP lui-même.

le scénario 2. Points d'accès n'obtiennent pas un IP address

On s'attend à ce que des Points d'accès obtiennent un IP address d'AP Poo, dans infra le VNl défini au centre DNA. Si ceci ne se produit pas, il signifie typiquement que le switchport où AP est connecté ne s'est pas déplacé au VLAN droit. Le commutateur, quand détecter (par le CDP) des acess dirigent être connecté, appliquera une macro-instruction de switchport qui placera le switchport dans le VLAN défini par DNA-C pour le groupe AP. Si le switchport problématique n'est pas en effet configuré avec la macro-instruction, vous pouvez placer la configuration manuellement (de sorte qu'AP obtient un IP, joint le WLC et améliore probablement son code et résout probablement n'importe quelle bogue de CDP) ou dépanner la procédure de connexion de CDP. Vous pouvez sur option configurer l'hôte onboarding pour définir statiquement le port au DNA-centre pour héberger AP de sorte qu'il provisioned avec la bonne configuration.

Les macros-instructions de Smartport ne donnent pas un coup de pied dedans automatiquement si le commutateur pas provisioned avec un AP au moins, vous peuvent vérifier si la macro-instruction AP provisioned avec le VLAN droit (au lieu du VLAN par défaut 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

Les commandes que les poussers de Cisco DNA-C de placer ceci sont

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

le scénario 3. Points d'accès n'ont pas un tunnel vxlan construit vers leur noeud de périphérie de matrice

Une fois qu'AP joint le WLC, le WLC (si AP est matrice capable) enregistrera AP sur l'avion de contrôle comme type particulier de client. L'avion de contrôle demandera alors le noeud de périphérie de matrice où AP est branché pour construire un tunnel vxlan vers AP.

AP emploiera seulement l'encapsulation vxlan pour envoyer le trafic de client (et seulement pour des clients dans l'état de PASSAGE), donc il est normal de ne pas voir n'importe quelles informations vxlan sur AP jusqu'à ce qu'un client de matrice se connecte.

Sur AP, la matrice de tunnel de show ip de commande affichera les informations vxlan de tunnel une fois qu'un client s'est connecté.

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#

Sur le noeud de périphérie de matrice, le résumé d'Access-tunnel d'exposition de commande affichera les tunnels vxlan construits vers les Points d'accès. Les tunnels afficheront dès que l'avion de contrôle a commandé leur création quand AP se joint.

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

Vous pouvez vérifier le WLC, à la page de Point d'accès, à l'id d'exemple LISP L2 correspondant à cet AP et puis vérifier les statistiques de cet exemple sur la périphérie de matrice où elles sont connectées.

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

entrées de tunnel d'accès du scénario 4. manquant après un certain temps

Il est possible que les tunnels d'accès soient avec succès créés la première fois quand WLC provisioned par Cisco DNA-C et est ajouté à la matrice mais quand la configuration Sans fil de re-ravitaillement (comme la configuration WLAN) il est observée que les entrées de tunnel d'accès pour des aps manquent les clients sans fil en résultant ne peuvent pas obtenir avec succès l'IP.

La topologie est 9500(CP) --> 9300 (périphérie) --> AP --> client sans fil.

On observe correctement des entrées en résumé d'Access-tunnel d'exposition sur le noeud de périphérie :

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

Mais quand vérifier le logiciel de show platform a alimenté le commutateur l'ifm qu'actif relie l'Access-tunnel, l'entrée pour AP est manquante ou pour être programmée dans le matériel dans cet exemple.

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

Pour plus d'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

Vous devez comparer les différentes sorties et chaque tunnel affiché par le résumé d'Access-tunnel d'exposition doit être présent dans chacun d'eux.

clients sans fil du scénario 5. non capables obtenir une adresse IP

Si le tunnel vxlan est présent et tout semble bon mais les clients sans fil ne peuvent pas systématiquement obtenir une adresse IP que vous faites face peut-être à un problème de l'option 82. Puisque le DHCP LES DÉCOUVRENT du client est expédié par la passerelle de cantonade sur le noeud de périphérie, là serait problème pour que l'OFFRE de serveur DHCP soit renvoyée au bon noeud de périphérie par le cadre sur le chemin. C'est pourquoi la périphérie de matrice qu'en avant le DHCP DÉCOUVRENT ajoute un champ de l'option 82 au DHCP LES DÉCOUVRENT qui contient la matrice réelle RLOC (IP de bouclage) du noeud de périphérie encodé avec d'autres informations. Ceci signifie que votre serveur DHCP doit l'option du support 82.

Pour dépanner le processus DHCP, captures de prise sur les Noeuds de matrice (particulièrement le noeud de périphérie de client) pour vérifier que la périphérie de matrice ajoute le champ de l'option 82.

matrice d'invité du scénario 6./ne pas fonctionner d'authentification Web/ne réorientant pas des clients

Le scénario de matrice d'invité est extrêmement semblable à l'authentification Web centrale (CWA) sur les Points d'accès et le travail de Flexconnect exactement la même manière (même si la matrice aps ne sont pas en mode de flexconnect).

L'ACL de redirection et l'URL doivent être retournés par ISE dans le premier résultat d'authentification de MAC. Vérifiez ceux dans les logs ISE aussi bien que la page de petit groupe de client sur le WLC.

L'ACL de réorientation doit être présent comme ACL de flexible sur le WLC et doit contenir des déclarations de « autorisation » vers l'adresse IP ISE sur le port 8443 (au moins).

Le client devrait être dans l'état « CENTRAL_WEBAUTH_REQ » dans la page de petits groupes de client sur le WLC. Le client ne pourra pas cingler sa passerelle par défaut et ceci est prévu. Si vous n'êtes pas réorienté vous pouvez essayer de taper manuellement un IP address dans le navigateur Web de client (éliminer l'adresse Internet de DN, mais ISE devra être résolu de toute façon). Vous devriez pouvoir écrire l'IP ISE sur le port 8443 dans le navigateur de client et voir la page du portail car cet écoulement ne sera pas réorienté. Si ceci ne se produit pas, vous faites face à une question d'ACL ou à une question de routage vers. Collectez les captures de paquet le long de la route pour voir où les paquets de HTTP sont arrêtés.

Comprenez

Comment fait un client sans fil obtenez une adresse IP en architecture de matrice

La capture de paquet est prise entre la matrice AP et la périphérie de matrice. Le paquet sont reproduits parce que deux que le DHCP découvrent des paquets ont été envoyés. Le trafic était seulement d'entrée et capturé sur la périphérie de matrice. 

Il y a toujours deux paquets DHCP. Un envoyé par CAPWAP directement au contrôleur pour le maintenir mis à jour. L'autre envoyé par VXLAN au noeud de contrôle. Quand AP reçoivent par exemple une offre DHCP avec VXLAN par le serveur DHCP, il envoie une copie au contrôleur avec CAPWAP.

Pour voir où le paquet a été envoyé, vous devez le cliquer sur en fonction sur Wireshark. Ici nous pouvons voir que la source est notre AP 172.16.3.131 et le paquet a été envoyé à la périphérie 172.16.3.98 de matrice. La périphérie de matrice l'a expédié au noeud de contrôle.

Comprenez l'écoulement de redirection de Web dans un scénario de matrice

L'ACL de réorientation sur le WLC définit quel trafic est réorienté/intercepté sur des instructions de refus assorties (il y a un implicite refusent à l'extrémité). Que le trafic à réorienter sera envoyé au WLC à l'intérieur de l'encapsulation CAPWAP pour que le WLC réoriente. En appariant une déclaration d'autorisation, il ne réoriente pas ce trafic et le permet et en avant il sur la matrice (le trafic vers ISE écrit cette catégorie).

Logs d'AP joignant le WLC dans l'état matrice-activé

Dès que le registre d'access-point à WLC, contrôleur enregistrera son IP et adresse MAC dans le noeud de contrôle SDA (serveur de carte LISP). 

AP joint le WLC en mode matrice-activé seulement si les WLC reçoivent le paquet LISP RLOC. Ce paquet est envoyé pour être sûr qu'AP est connecté à une périphérie de matrice.

Les débogages utilisés sur le WLC pour cet exemple sont :

• « enable d'événements de capwap de débogage »
• « enable d'erreurs de capwap de débogage »
• la « matrice de débogage AP-joignent l'enable d'événements »
• la « matrice de débogage AP-joignent l'enable de détail »
• « le MAP-serveur tout de lisp de matrice de débogage activent »

Pour le test, AP est redémarré :

*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