Dépannage et vérification de la configuration initiale de SD-Access sans fil
Contenu
Introduction
Cet article décrit les étapes de dépannage de base permettant d'identifier les problèmes de connectivité de base dans les configurations sans fil SD-Access. Il décrit les éléments et les commandes à vérifier pour isoler les problèmes de la solution relatifs au sans fil.
Conditions préalables
Conditions requises
Connaissance de la solution SD-Access
Une topologie d'accès SD déjà configurée
Composants utilisés
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes. Il existe d'autres types de périphériques pris en charge pour l'accès sans fil SD, mais cet article se concentre sur les périphériques décrits dans cette section. Les commandes peuvent varier en fonction de la plate-forme et de la version du logiciel.
Contrôleur sans fil 8.5.151
16.9.3 Commutateur 9300 en tant que noeud de périphérie
Topologie
Dépanner et isoler
Vérifications rapides
Il existe une série de conditions requises dans les scénarios d'accès SD qui sont souvent une source d'erreurs, donc vérifiez d'abord que ces conditions sont remplies :
- Assurez-vous que vous disposez d'une route spécifique (sans utiliser la route par défaut) pointant vers le WLC sur le noeud du plan de contrôle LISP
- Assurez-vous que vos points d'accès se trouvent dans le VLAN Infra, à l'aide de la table de routage globale
- Assurez-vous que les points d'accès ont une connectivité au WLC en envoyant une requête ping au WLC à partir du point d'accès lui-même
- Assurez-vous que l'état du fabric du plan de contrôle sur le WLC est actif
- Assurez-vous que les points d'accès sont à l'état Fabric
Scénario 1. Vérifier l'enregistrement du WLC avec le plan de contrôle du serveur LISP/MAP
Lorsque vous ajoutez le WLC au fabric dans DNA Center, les commandes sont envoyées au contrôleur pour établir une connexion au noeud défini comme plan de contrôle dans DNA-C. La première étape consiste à s'assurer que cet enregistrement est réussi. Si la configuration LISP sur le plan de contrôle est corrompue d'une manière ou d'une autre, cet enregistrement peut échouer.
Si cet état est désactivé, il peut être intéressant d'exécuter des débogages ou une capture de paquets entre le WLC et le plan de contrôle. L'enregistrement implique à la fois TCP et UDP sur 4342. Si le plan de contrôle n'a pas obtenu la configuration appropriée, il peut répondre avec une RST TCP au SYN TCP envoyé par le WLC.
Le même état peut être vérifié avec show fabric map-server summary sur la ligne de commande. Le processus est débogué avec debug fabric lisp map-server all sur l'interface de ligne de commande du WLC. Pour provoquer une tentative de reconnexion, vous pouvez aller à DNA Center et choisir de supprimer le WLC du fabric et de l'ajouter à nouveau.
Les raisons possibles sont l'absence de lignes de configuration dans le plan de contrôle. Voici un exemple de configuration de fonctionnement (la partie la plus importante uniquement) :
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'adresse IP du WLC est manquante (10.241.0.41 ici) ou si la commande passive-open est manquante, le PC refusera la connexion du WLC.
Les débogages à exécuter sont les suivants :
- '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'
Voici un exemple du plan 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'un point d'accès se joignant à l'état Fabric désactivé parce que le plan de contrôle de fabric manquait une route spécifique vers le 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 plans de contrôle dans votre réseau de fabric, le WLC tentera toujours de contacter à la fois pour l'enregistrement ou les requêtes. Il est prévu que les deux plans de contrôle donnent des réponses positives sur les enregistrements, de sorte que le WLC ne pourra pas enregistrer les AP dans le fabric si l'un des deux plans de contrôle le rejette pour une raison quelconque. Toutefois, un plan de contrôle ne répondant pas est acceptable et le plan de contrôle restant sera utilisé.
Les points d'accès atteignent le WLC via la table de routage globale, mais le protocole LISP est toujours utilisé pour résoudre le WLC. Le trafic envoyé par les points d'accès au WLC est un contrôle CAPWAP pur (sans vxlan impliqué), mais le trafic de retour envoyé par le WLC au point d'accès sera transporté sur Vxlan sur la superposition. Vous ne pourrez pas tester la connectivité à partir de l'interface SVI de la passerelle AP sur la périphérie vers le WLC car comme il s'agit d'une passerelle Anycast, la même adresse IP existe également sur le noeud de frontière. Afin de tester la connectivité, le mieux est d’envoyer une requête ping à partir du point d’accès lui-même.
scénario 2. Les points d'accès n'obtiennent pas d'adresse IP
Les points d'accès doivent obtenir une adresse IP du point d'accès, dans le VLAN Infra défini dans DNA Center. Si cela ne se produit pas, cela signifie généralement que le port de commutation où le point d'accès est connecté n'est pas passé au vlan de droite. Lors de la détection (via CDP) d'un point d'accès connecté, le commutateur appliquera une macro switchport qui définira le port de commutation dans le VLAN défini par DNA-C pour le pool d'AP. Si le port de commutation problématique n'est en effet pas configuré avec la macro, vous pouvez soit définir la configuration manuellement (de sorte que l'AP obtienne une adresse ip, rejoint le WLC et probablement met à niveau son code et éventuellement résoudre tout bogue CDP) ou dépanner le processus de connexion CDP. Vous pouvez éventuellement configurer l'intégration de l'hôte pour définir de manière statique le port sur DNA-Center pour héberger un point d'accès de sorte qu'il soit provisionné avec la bonne configuration.
Les macros Smartport ne démarrent pas automatiquement si le commutateur n'a pas été provisionné avec un point d'accès au moins, vous pouvez vérifier si la macro AP a été provisionnée avec le vlan droit (au lieu du vlan 1 par défaut)
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 Cisco DNA-C utilise pour définir ceci sont les suivantes :
macro auto execute CISCO_WIRELESS_LIGHTWEIGHT_AP_EVENT builtin CISCO_LWAP_AUTO_SMARTPORT ACCESS_VLAN=2045 macro auto global processing
scénario 3. Les points d'accès ne disposent pas d'un tunnel vxlan construit vers leur noeud Fabric Edge
Une fois qu'un point d'accès rejoint le WLC, le WLC (si le point d'accès est compatible avec le fabric) enregistre le point d'accès sur le plan de contrôle comme type spécial de client. Le plan de contrôle demandera ensuite le noeud de périphérie de fabric où le point d'accès est branché pour construire un tunnel vxlan vers le point d'accès.
Le point d'accès utilise uniquement l'encapsulation vxlan pour envoyer le trafic client (et uniquement pour les clients en état RUN). Il est donc normal de ne pas voir d'informations vxlan sur le point d'accès tant qu'un client de fabric ne se connecte pas.
Sur l'AP, la commande show ip tunnel fabric affiche les informations du tunnel vxlan 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 Périphérie de fabric, la commande show access-tunnel summary affiche les tunnels vxlan construits vers les points d'accès. Les tunnels s'affichent dès que le plan de contrôle a ordonné leur création lorsque l'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 sur le WLC, sur la page du point d'accès, l'ID d'instance LISP de couche 2 correspondant à ce point d'accès, puis vérifier les statistiques de cette instance sur la périphérie de fabric où elle est connectée.
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
scénario 4 . Les entrées du tunnel d'accès sont manquantes après un certain temps
Il est possible que les tunnels d'accès soient créés avec succès la première fois que le WLC est provisionné via Cisco DNA-C et ajouté au fabric, mais lors du réapprovisionnement de la configuration sans fil (telle que la configuration WLAN), il est observé que les entrées de tunnel d'accès pour les AP sont manquantes et que les clients sans fil ne parviennent pas à obtenir l'IP.
La topologie est 9500(CP) —> 9300 (Edge) —> AP —> Client sans fil.
Les entrées sont correctement observées dans show access-tunnel summary 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 lors de la vérification de show platform software fed switch active ifm interfaces access-tunnel, l'entrée de l'AP est manquante ou n'a pas pu ê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 de résultats :
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érents résultats et chaque tunnel affiché par le résumé show access-tunnel doit être présent dans chacun d'eux.
scénario 5. clients sans fil ne pouvant pas obtenir d'adresse IP
Si le tunnel vxlan est présent et que tout semble correct mais que les clients sans fil sont systématiquement incapables d'obtenir une adresse IP, vous êtes peut-être confronté à un problème d'option 82. Puisque la DÉCOUVERTE DHCP du client est transmise par la passerelle Anycast sur le noeud de périphérie, le serveur DHCP OFFER pourrait rencontrer des problèmes pour être envoyé au noeud de périphérie droit par la bordure du chemin de retour. C'est la raison pour laquelle la périphérie de fabric qui transfère DHCP DISCOVER ajoute un champ d'option 82 à DHCP DISCOVER qui contient le RLOC de fabric réel (ip de bouclage) du noeud de périphérie codé avec d'autres informations. Cela signifie que votre serveur DHCP doit prendre en charge l'option 82.
Pour dépanner le processus DHCP, effectuez des captures sur les noeuds de fabric (en particulier sur le noeud de périphérie client) pour vérifier que la périphérie de fabric ajoute le champ option 82.
scénario 6. L'authentification du fabric invité/Web ne fonctionne pas/ne redirige pas les clients
Le scénario de fabric invité est extrêmement similaire à l'authentification Web centrale (CWA) sur les points d'accès Flexconnect et fonctionne exactement de la même manière (même si les points d'accès de fabric ne sont pas en mode flexconnect).
La liste de contrôle d'accès et l'URL de redirection doivent être renvoyées par ISE dans le premier résultat d'authentification mac. Vérifiez ceux-ci dans les journaux ISE ainsi que la page de détails du client sur le WLC.
La liste de contrôle d'accès de redirection doit être présente en tant que liste de contrôle d'accès flexible sur le WLC et doit contenir des instructions « permit » vers l'adresse IP ISE sur le port 8443 (au moins).
Le client doit être à l'état « CENTRAL_WEBAUTH_REQ » dans la page de détails du client sur le WLC. Le client ne pourra pas envoyer de requête ping à sa passerelle par défaut, ce qui est attendu. Si vous n'êtes pas redirigé, vous pouvez essayer de taper manuellement une adresse IP dans le navigateur Web du client (pour exclure DNS, mais le nom d'hôte ISE devra quand même être résolu). Vous devez être en mesure d'entrer l'IP ISE sur le port 8443 dans le navigateur du client et de voir la page du portail, car ce flux ne sera pas redirigé. Si cela ne se produit pas, vous êtes confronté à un problème de liste de contrôle d’accès ou de routage vers. Collectez des captures de paquets le long du chemin pour voir où les paquets HTTP sont arrêtés.
Comprendre
Comment un client sans fil obtient-il une adresse IP dans l'architecture de fabric
La capture de paquets est effectuée entre le point d'accès du fabric et la périphérie du fabric. Les paquets sont dupliqués car deux paquets de détection DHCP ont été envoyés. Le trafic n'était en entrée et capturé que sur la périphérie du fabric.
Il y a toujours deux paquets DHCP. Un envoi par CAPWAP directement au contrôleur pour le tenir à jour. L'autre envoyé par VXLAN au noeud de contrôle. Lorsque le point d'accès reçoit 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 cliquer dessus sur Wireshark. Ici, nous pouvons voir la source est notre AP 172.16.3.131 et le paquet a été envoyé à la périphérie de fabric 172.16.3.98. Le périphérique de fabric l'a transféré au noeud de contrôle.
Comprendre le flux de redirection Web dans un scénario de fabric
La liste de contrôle d'accès de redirection sur le WLC définit le trafic qui est redirigé/intercepté sur les instructions de refus correspondantes (il y a un refus implicite à la fin). Ce trafic à rediriger sera envoyé au WLC dans l'encapsulation CAPWAP pour que le WLC le redirige. Lors de la correspondance d'une instruction permit, il ne redirige pas ce trafic et le laisse passer et le transfère sur le fabric (le trafic vers ISE entre dans cette catégorie).
Journaux du point d'accès joignant le WLC dans l'état Fabric-enabled
Dès que le point d'accès s'enregistre auprès du WLC, le contrôleur enregistre son adresse IP et MAC dans le noeud de contrôle SDA (serveur LISP Map).
L'AP rejoint le WLC en mode de matrice uniquement si le WLC reçoit le paquet RLOC LISP. Ce paquet est envoyé pour s'assurer que le point d'accès est connecté à une périphérie de fabric.
Les débogages utilisés sur le WLC pour cet exemple sont :
- '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'
Pour le test, le point d'accès 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
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)