Sans fil : Contrôleurs de réseau local sans fil de la gamme Cisco 4400

Messages d'erreur et système du contrôleur de réseau local sans fil - Forum Aux Questions

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Questions


Introduction

Ce document fournit des informations sur les questions fréquemment posées (FAQ) à propos des messages d'erreur et des messages système pour les contrôleurs de réseau sans fil (WLAN) Cisco (WLC).

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

FAQ sur les messages d'erreur

Q. Nous avons commencé la conversion de plus de 200 Points d'accès (aps) de logiciel de ½ du ¿  de Cisco IOSï à AP léger Protocol (LWAPP) par Cisco 4404 WLC. Nous avons finalisé la conversion de 48 AP et nous recevons un message sur le WLC qui énonce : [[ERROR] spam_lrad.c 4212: AP cannot join because the maximum number of APs on interface 1 is reached. Pourquoi l'erreur se produit-elle ?

A. Vous devez créer des interfaces du gestionnaire AP supplémentaires afin de prendre en charge plus de 48 AP. Autrement, vous recevrez un message d'erreur tel que :

Wed Sep 28 12:26:41 2005 [ERROR] spam_lrad.c 4212: AP cannot join because 
the maximum number of APs on interface 1 is reached.

Configurez les interfaces multiples du gestionnaire AP et configurez les ports principaux/de secours que d'autres interfaces du gestionnaire AP n'utilisent pas. Vous devez créer une deuxième interface du gestionnaire AP afin de mettre en place d'autres AP. Mais assurez-vous que vos configurations de port principal et de port de secours pour chaque gestionnaire ne se superposent pas. En d'autres termes, si le gestionnaire AP 1 utilise le port 1 en tant que port principal et le port 2 comme port de secours, le gestionnaire AP 2 doit utiliser le port 3 en tant que port principal et le port 4 comme port de secours.

Q. J'ai un contrôleur de réseau local sans fil (WLC) 4402 et j'utilise les points d'accès léger (LAP) 1240. J'essaye d'activer le cryptage 128 bits sur le WLC. Quand je sélectionne le cryptage WEP 128 bits sur le WLC, je reçois un message d'erreur qui indique que le cryptage 128 bits n'est pas pris en charge sur les modèles 1240 : [[ERROR] spam_lrad.c 12839: Not creating SSID mde on CISCO AP xx: xx : xx : xx : xx : xx because WEP128 bit is not supported. Pourquoi est-ce que je reçois cette erreur ?

A. Les longueurs de clé montrées sur les WLC sont en fait le nombre de bits qui sont dans le secret partagé et n'incluent pas les 24 bits du vecteur d'initialisation (IV). Beaucoup de produits, dont les produits Aironet, l'appellent une clé WEP 128 bits. En réalité, c'est une clé de 104 bits avec 24 bits de l'IV. 104 bits est la taille de la clé que vous devez autoriser sur le WLC pour le cryptage WEP de 128 bits.

Si vous choisissez 128 bits comme taille de la clé sur le WLC, c'est en fait un cryptage de clé WEP de 152 bits (128 + 24 IV). Seuls les LAP de la gamme Cisco 1000 (AP1010, AP1020, AP1030) permettent l'utilisation des paramètres de la clé WEP de 128 bits WLC.

Q. Pourquoi est-ce que j'obtiens le message d'erreur WEP key size of 128 bits is not supported on 11xx, 12xx and 13xx model APs. Wlan will not be pushed to these Access Points. quand j'essaye de configurer le WEP sur un WLC ?

A. Sur un contrôleur de réseau local sans fil, quand vous choisissez le WEP statique comme méthode de sécurité de la couche 2, vous avez ces options ou la taille de clé WEP.

  • non défini

  • 40 bits

  • 104 bits

  • 128 bits

Ces valeurs de taille de clé n'incluent pas le vecteur d'initialisation (IV) 24 bits, qui est concaténé avec la clé WEP. Ainsi, pour un WEP de 64 bits, vous devez choisir 40 bits comme taille de clé WEP. Le contrôleur ajoute le vecteur d'initialisation (IV) de 24 bits afin de faire une clé WEP de 64 bits. De même, pour une clé WEP de 128 bits, choisissez 104 bits.

Les contrôleurs prennent également en charge les clés WEP de 152 bits (128 bits + IV de 24 bits). Cette configuration n'est pas prise en charge sur les modèles d'AP 11xx, 12xx et 13xx. Ainsi quand vous essayez de configurer le WEP avec 144 bits, le contrôleur donne un message indiquant que cette configuration WEP n'est pas applicable aux modèles d'AP 11xx, 12xx et 13xx.

Q. Les clients ne peuvent pas authentifier à un WLAN qui est configuré pour le WPA2 et le contrôleur affiche l'apf_80211.c:1923 APF-1-PROC_RSN_WARP_IE_FAILED : Could not process the RSN and WARP IE's. station not using RSN (WPA2) on WLAN requiring RSN.MobileStation:00:0c:f1:0c:51:22, SSID: <>. Pourquoi est-ce que je reçois cette erreur ?

A. Ceci se produit en grande partie en raison d'une incompatibilité du côté du client. Essayez de réaliser ces étapes afin de résoudre ce problème :

Q. Une fois que je redémarre le WLC, j'obtiens le message d'erreur Mon Jul 17 15:23:28 2006 MFP Anomaly Detected - 3023 Invalid MIC event found as violated by the radio 00:XX:XX:XX:XX and detected by the dot11 interface at slot 0 of AP 00:XX:XX:XX:XX in 300 seconds when observing Probe responses, Beacon Frames. Pourquoi cette erreur se produit-elle et comment est-ce que je me débarrasse d'elle ?

A. Ce message d'erreur apparaît quand des trames avec des valeurs MIC incorrectes sont détectées par les LAP activés par MFP. Consultez la section Exemple de configuration de Management Frame Protection (MFP) pour infrastructures avec WLC et LAP pour plus d'informations sur MFP. Réalisez une de ces quatre étapes :

  1. Vérifiez et supprimez tous les AP ou clients non autorisés ou non valides dans votre réseau, qui génèrent des trames non valides.

  2. Désactivez l'infrastructure MFP, si MFP n'est pas activé sur d'autres membres du groupe de mobilité car les LAP peuvent entendre les trames de gestion des LAP d'autres WLC dans le groupe qui n'ont pas MFP activé. Consultez la section FAQ sur les groupes de mobilité du contrôleur de réseau local sans fil (WLC) pour plus d'informations sur le groupe de mobilité.

  3. Le correctif pour ce message d'erreur est disponible dans les versions WLC 4.2.112.0 et 5.0.148.2. Mettez à jour les WLC avec l'une ou l'autre de ces versions.

  4. Comme dernière option, essayez de recharger le LAP qui génère ce message d'erreur.

Q. Le client AIR-PI21AG-E-K9 s'associe avec succès avec un Point d'accès (AP) utilisant l'authentification Protocol-flexible d'authentification extensible par l'intermédiaire du Tunnellisation sécurisé (EAP-FAST). Cependant, quand l'AP associé est éteint, le client ne se déplace pas à un autre AP. Ce message apparaît continuellement dans le journal des messages du contrôleur : ""Fri Jun 2 14:48:49 2006 [SECURITY] 1x_auth_pae.c 1922: Unable to allow user into the system - perhaps the user is already logged onto the system? Fri Jun 2 14:48:49 2006 [SECURITY] apf_ms.c 2557: Unable to delete username for mobile 00:40:96:ad:75:f4". Pourquoi ?

A. Quand la carte client doit faire de l'itinérance, elle envoie une demande d'authentification, mais elle ne prend pas correctement en charge les clés (n'informe pas AP/contrôleur, ne répond pas aux réauthentifications).

Ceci est documenté dans l'ID de bogue Cisco CSCsd02837 (clients enregistrés seulement). Ce bogue a été réparé avec l'Assistant d'installation 3.5 des adaptateurs client de Cisco Aironet 802.11a/b/g.

Généralement, le message Unable to delete username for mobile apparaît également en raison de :

  • Le nom d'utilisateur particulier est utilisé sur plus d'un périphérique client.

  • La méthode d'authentification utilisée pour ce WLAN a une identité anonyme externe. Par exemple, dans PEAP-GTC ou dans EAP-FAST, il est possible de définir un nom d'utilisateur générique en tant qu'identité (visible) externe, et le vrai nom d'utilisateur est masqué à l'intérieur du tunnel TLS entre le client et le serveur radius, ainsi le contrôleur ne peut pas le voir et l'utiliser. En pareil cas, ce message peut apparaître. Ce problème apparaît plus généralement avec des clients tiers et des clients de microprogramme ancien.

Q. Quand j'installe la nouvelle lame de Wireless Services Module (WiSM) dans les commutateurs 6509 et implémente Protected Extensible Authentication Protocol (PEAP) avec le serveur Microsoft IAS, je reçois cette erreur : **Mar 1 00:00:23.526: %LWAPP-5-CHANGED : LWAPP changed state to DISCOVERY *Mar 1 00:00:23.700: %SYS-5-RELOAD : Reload requested by LWAPP CLIENT.Reload Reason: FAILED CRYPTO INIT. **Mar 1 00:00:23.700: %LWAPP-5-CHANGED : LWAPP changed state to DOWN *Mar 1 00:00:23.528: %LWAPP-5-CHANGED : LWAPP changed state to DISCOVERY *Mar 1 00:00:23.557: LWAPP_CLIENT_ERROR_DEBUG: lwapp_crypto_init_ssc_keys_and_certs no certs in the SSC Private File *Mar 1 00:00:23.557: LWAPP_CLIENT_ERROR_DEBUG: **Mar 1 00:00:23.557: lwapp_crypto_init: PKI_StartSession failed *Mar 1 00:00:23.706: %SYS-5-RELOAD : Reload requested by LWAPP CLIENT. . Pourquoi ?

A. Le RAYON et le dot1x met au point l'exposition que le WLC envoie à une demande d'accès, mais il n'y a aucune réponse du serveur d'IAS. Suivez ces étapes afin de résoudre ce problème :

  1. Contrôlez et vérifiez la configuration du serveur IAS.
  2. Vérifiez le fichier journal.
  3. Installez un logiciel tel que Ethereal, qui peut vous fournir des détails sur l'authentification.
  4. Arrêtez et remettez en marche le service IAS.

Q. Les points d'accès léger (LAP) ne s'inscrivent pas auprès du contrôleur. Quel pourrait être le problème ? Je vois ces messages d'erreur sur le contrôleur : Thu Feb 3 03:20:47 2028: LWAPP Join-Request does not include valid certificate in CERTIFICATE_PAYLOAD from AP 00:0b:85:68:f4:f0. Thu Feb 3 03:20:47 2028: Unable to free public key for AP 00:0B:85:68:F4:F0.

A. Quand le point d'accès (AP) envoie la demande d'enregistrement du protocole Lightweight Access Point Protocol (LWAPP) au WLC, il inclut son certificat X.509 dans le message LWAPP. Il génère également une ID de session aléatoire qui est incluse dans la demande d'enregistrement LWAPP. Quand le WLC reçoit les demandes d'enregistrement LWAPP, il valide la signature du certificat X.509 en utilisant la clé publique des AP et vérifie que le certificat a été délivré par une autorité de certification de confiance. Il regarde également la date et l'heure de début pour l'intervalle de validité du certificat AP et les compare à ses propres date et heure.

Ce problème peut se poser en raison d'un paramétrage incorrect de l'horloge sur le WLC. Afin de régler l'horloge sur le WLC, lancez les commandes show time et config time.

Q. Un protocole Lightweight Access Point Protocol (LWAPP) AP ne peut pas se connecter à son contrôleur. Le journal du contrôleur de réseau local sans fil (WLC) affiche un message semblable à ceci : LWAPP Join-Request does not include valid certificate in CERTIFICATE_PAYLOAD from AP 00:0b:85:68:ab:01. Pourquoi ?

A. Vous pouvez recevoir ce message d'erreur si le tunnel LWAPP entre l'AP et le WLC traverse un chemin réseau avec une MTU inférieure à 1500 octets. Ceci entraîne la fragmentation des paquets LWAPP. C'est un bogue connu dans le contrôleur. Consultez l'ID de bogue Cisco CSCsd39911 (clients enregistrés seulement).

La solution est de mettre à jour le microprogramme du contrôleur à 4.0(155).

Q. J'essaye d'établir un tunnel invité entre mon contrôleur interne et le contrôleur d'ancrage virtuel sur la zone démilitarisée (DMZ). Cependant, quand un utilisateur tente de s'associer à un invité SSID, l'utilisateur n'arrive pas à recevoir l'adresse IP de la DMZ, comme prévu. Par conséquent, le trafic de l'utilisateur n'est pas relié par tunnel au contrôleur sur la DMZ. Le résultat de la commande debug mobile handoff affiche un message semblable à ceci : Security Policy Mismatch for WLAN <Wlan ID>. Anchor Export Request from Switch IP: <controller Ip address> Ignored. Quel est le problème ?

A. Le Tunnellisation d'invité fournit la Sécurité supplémentaire pour l'accès d'invité-utilisateur au réseau Sans fil entreprise. Ceci aide à s'assurer que les utilisateurs invités ne peuvent pas accéder au réseau de l'entreprise sans passer d'abord par le pare-feu de l'entreprise. Quand un utilisateur s'associe à un WLAN qui est indiqué comme WLAN invité, le trafic utilisateur est relié par tunnel au contrôleur WLAN qui se trouve sur la DMZ hors du pare-feu de l'entreprise.

Maintenant, compte tenu de ce scénario, il peut y avoir plusieurs raisons pour que ce tunnel invité ne fonctionne pas comme prévu. Comme l'implique la sortie de la commande debug, le problème pourrait être dû à la non correspondance entre les différentes politiques de sécurité configurées pour ce WLAN particulier dans l'interne aussi bien que dans les contrôleurs DMZ. Vérifiez si les politiques de sécurité ainsi que d'autres paramètres, tels que les paramètres de temps d'expiration de la session, correspondent.

Une autre raison courante pour ce problème est que le contrôleur DMZ n'est pas ancré à lui-même pour ce WLAN particulier. Pour qu'un tunnel invité fonctionne correctement et que la DMZ gère l'adresse IP de l'utilisateur (utilisateur qui appartient à un WLAN invité), il est essentiel que l'ancrage approprié soit fait pour ce WLAN particulier.

Q. Je vois beaucoup de messages "CPU Receive Multicast Queue is full on Controller" sur le contrôleur de réseau local sans fil 2006 mais pas sur les WLC 4400. Pourquoi ? J'ai désactivé le multicast sur les contrôleurs. Quelle est la différence dans la limite de file d'attente Multicast entre les plates-formes WLC 2006 et 4400 ?

A. Puisque le multicast est désactivé sur les contrôleurs, les messages qui entraînent cette alarme pourraient être des messages de Protocole de résolution d'adresse (ARP). Il n'y a aucune différence dans la profondeur de la file d'attente (512 paquets) entre les WLC 2000 et 4400. La différence est que le 4400 NPU filtre les paquets ARP tandis que tout est fait par logiciel sur le 2006. Ceci explique pourquoi le WLC 2006 voit les messages mais pas le WLC 4400. Un WLC 44xx traite les paquets multicast par l'intermédiaire du matériel (par CPU). Un WLC 2000 traite les paquets multicast par l'intermédiaire du logiciel. Le traitement par CPU est plus efficace que celui par logiciel. Par conséquent, la file d'attente du 4400 est plus rapidement effacée, tandis que le WLC 2006 a un peu de difficulté quand il voit beaucoup de ces messages.

Q. Je vois le message d'erreur "[SECURITY] apf_foreignap.c 763: STA [00:0A:E4:36:1F:9B] Received a packet on port 1 but no Foreign AP configured for this port." sur un de mes contrôleurs. Que signifie cette erreur et quelles étapes dois-je suivre pour résoudre ce problème ?

A. Ce message apparaît quand le contrôleur reçoit une requête DHCP pour une adresse MAC pour laquelle il n'a pas de machine d'état. Ceci apparaît souvent d'un pont ou d'un système qui exécute une machine virtuelle comme VMWare. Le contrôleur écoute les requêtes DHCP parce qu'il réalise une surveillance DHCP. Ainsi, il sait quelles adresses sont associées aux clients qui sont rattachés à ses points d'accès (AP). Tout le trafic pour les clients sans fil traverse le contrôleur. Quand la destination d'un paquet est un client sans fil, elle va au contrôleur et puis traverse le tunnel du protocole Lightweight Access Point Protocol (LWAPP) jusqu'à l'AP puis le client. Une chose qui peut être faite pour aider à diminuer l'apparition de ce message est d'autoriser seulement les VLAN qui sont utilisés sur le contrôleur sur la jonction réseau qui va au contrôleur avec la commande switchport vlan allow du commutateur.

Q. Pourquoi est-ce que je vois ce message d'erreur sur la console : Msg 'Set Default Gateway' of System Table failed, Id = 0x0050b986 error value = 0xfffffffc?

A. Ceci peut être dû à la charge élevée du CPU. Quand le contrôleur CPU est fortement chargé, comme quand il fait des copies de fichier ou d'autres tâches, il n'a pas le temps pour traiter tous les ACK que le NPU envoie en réponse aux messages de configuration. Quand ceci se produit, le CPU génère des messages d'erreur. Cependant, les messages d'erreur n'affectent pas le service ou la fonctionnalité.

Ceci est documenté dans la section Contrôleur CPU fortement chargé des notes de publication relatives aux Contrôleurs de réseau local sans fil Cisco et Points d'accès léger pour la version 3.2.116.21.

Q. Je reçois ces messages d'erreur de clé Wired Equivalent Privacy (WEP) sur mon système de contrôle sans fil (WCS) : The WEP Key configured at the station may be wrong. Station MAC Address is 'xx: xx : xx : xx : xx : xx', AP base radio MAC is 'xx: xx : xx : xx : xx : xx' and Slot ID is '1'. Cependant, je n'utilise pas le WEP comme paramètre de sécurité de mon réseau. J'utilise seulement le Wi-Fi Protected Access (WPA). Pourquoi est-ce que je reçois ces messages d'erreur WEP ?

A. Si toutes vos configurations liées à la sécurité sont parfaites, les messages que vous recevez en ce moment sont dus à des bogues. Il y a quelques bogues identifiés dans le contrôleur. Consultez les bogues Cisco CSCse17260 (clients enregistrés seulement) et CSCse11202 (clients enregistrés seulement), qui indiquent « La clé WEP configurée à la station peut être erronée avec des clients WPA et TKIP respectivement ». En fait, CSCse17260 est un doublon de CSCse11202. Le correctif pour CSCse11202 est déjà disponible avec la version WLC 3.2.171.5.

Remarque: Les dernières versions WLC ont un correctif pour ces bogues.

Q. Nous utilisons un serveur RADIUS externe pour authentifier les clients sans fil par le contrôleur. Le contrôleur envoie ce message d'erreur régulièrement : no radius servers are responding. Pourquoi voyons-nous ces messages d'erreur ?

A. Quand une requête sort du WLC pour aller au serveur RADIUS, chaque paquet a un numéro de séquence auquel le WLC attend une réponse. S'il n'y a aucune réponse, il y a un message qui indique radius-server not responding.

Le temps par défaut pour que le WLC ait une réponse du serveur RADIUS est de 2 secondes. Ceci est défini à partir de l'interface graphique utilisateur WLC dans la section Security > authentication-server. Le maximum est de 30 secondes. Par conséquent, il pourrait être utile de définir cette valeur de temps d'expiration à son maximum afin de résoudre ce problème.

Parfois, les serveurs RADIUS effectuent des « annulations silencieuses » du paquet de requête qui provient du WLC. Le serveur RADIUS peut rejeter ces paquets car le certificat ne correspond pas ou pour plusieurs autres raisons. C'est une action valide par le serveur. En outre, en pareil cas, le contrôleur signalera le serveur RADIUS comme ne répondant pas.

Afin de maîtriser les annulations silencieuses, désactivez la fonctionnalité basculement agressif dans le WLC.

Si la fonctionnalité basculement agressif est activée dans le WLC, le WLC est trop agressif pour signaler le serveur AAA comme ne répondant pas. Cependant, ceci ne devrait pas être fait car le serveur AAA peut ne pas répondre seulement à ce client particulier (en faisant une annulation silencieuse). Cela peut être une réponse à d'autres clients valides (avec des certificats valides). Cependant, il se peut que le WLC signale encore le serveur AAA comme ne répondant pas et comme étant non fonctionnel.

Afin de résoudre ce problème, désactivez la fonctionnalité de basculement agressif. Émettez la commande de débronchement d'agressif-Basculement de rayon de config du contrôleur CLI afin d'exécuter ceci. Si cela est désactivé, alors le contrôleur bascule seulement au prochain serveur AAA s'il y a 3 clients consécutifs qui ne reçoivent pas de réponse du serveur RADIUS.

Q. Plusieurs clients ne peuvent pas s'associer à un LWAPP et le contrôleur indique le message d'erreur IAPP-3-MSGTAG015: iappSocketTask : iappRecvPkt returned error. Que se passe-t-il ?

A. Ceci se produit en grande partie en raison d'un problème avec les adaptateurs Intel qui supportent CCX v4, mais qui exécutent une version du client antérieure à 10.5.1.0. Si vous mettez à jour le logiciel à 10.5.1.0 ou à une version postérieure, ceci répare le problème. Consultez l'ID de bogue Cisco CSCsi91347 (clients enregistrés seulement) pour plus d'informations sur ce message d'erreur.

Q. Je vois ce message d'erreur sur le contrôleur de réseau local sans fil (WLC) : Reached Max EAP-Identity Request retries (21) for STA 00:05:4e:42:ad:c5. Pourquoi ?

A. Ce message d'erreur apparaît quand l'utilisateur essaye de se connecter à un réseau WLAN protégé EAP et a dépassé le nombre de tentatives EAP possible. Quand l'utilisateur ne s'authentifie pas, le contrôleur exclut le client et le client ne peut pas se connecter au réseau jusqu'à ce que le temps d'exclusion expire ou soit manuellement remplacé par l'administrateur.

L'exclusion détecte les tentatives d'authentification faites par un seul dispositif. Quand ce périphérique dépasse un nombre maximal de pannes, on ne permet plus à cette adresse MAC de s'associer.

L'exclusion se produit :

  • Après 5 échecs d'authentification consécutifs pour des authentifications partagées (le 6ème essai est exclu)

  • Après 5 échecs d'association consécutifs pour l'authentification MAC (le 6ème essai est exclu)

  • Après 3 échecs d'authentification EAP/802.1X consécutifs (le 4ème essai est exclu)

  • Tout échec de politique externe du serveur (NAC)

  • Toute instance de duplication d'adresse IP

  • Après 3 échecs d'authentification web consécutifs (le 4ème essai est exclu)

Le compteur pour déterminer combien de temps un client est exclu peut être configuré et l'exclusion peut être activée ou désactivée au niveau du contrôleur ou du WLAN.

Q. Je vois ce message d'erreur sur le contrôleur de réseau local sans fil (WLC) : An Alert of Category Switch is generated with severity 1 by Switch WLCSCH01/10.0.16.5 The message of the alert is Controller '10.0.16.5'. RADIUS server(s) are not responding to authentication requests. Quel est le problème ?

A. Ceci peut être dû à l'ID de bogue Cisco CSCsc05495. En raison de ce bogue, le contrôleur injecte périodiquement une paire AV incorrecte (attribut 24, « état ») dans les messages de demande d'authentification qui violent un RADIUS RFP et posent des problèmes pour quelques serveurs d'authentification. Ce bogue est réparé dans 3.2.179.6.

Q. Je reçois un message d'échec Noise Profile sous Monitor > 802.11b/g Radios. Je veux comprendre pourquoi je vois ce message FAILED ?

A. L'état du Noise Profile ACCEPTÉ/REJETÉ est défini après le résultat de test fait par le WLC et en comparaison avec le seuil fixé actuellement. Par défaut, la valeur du bruit est définie à -70. L'état FAILED indique que la valeur du seuil pour ce paramètre ou point d'accès (AP) particulier a été dépassée. Vous pouvez régler les paramètres dans le profil, mais il est recommandé de modifier les paramètres après avoir clairement compris la conception du réseau et comment cela affectera la performance du réseau.

Les seuils PASSED/FAILED de la Gestion des ressources radio (RRM) sont globalement définis pour tous les AP dans les pages 802.11a Global Parameters > Auto RF et 802.11b/g Global Parameters > Auto RF. Les seuils ACCEPTÉ/REJETÉ de la RRM sont individuellement définis pour cet AP à la page 802.11 AP Interfaces > Performance Profile.

Q. Je ne peux pas définir le port 2 comme port de secours pour l'interface du gestionnaire AP. Le message d'erreur envoyé est Could not set port configuration. Je peux définir le port 2 comme port de secours pour l'interface de gestion. Le port actif actuellement pour les deux interfaces est le port 1. Pourquoi ?

A. Un gestionnaire AP n'a pas de port de secours. Il était pris en charge dans les versions antérieures. Depuis la version 4.0, le port de secours pour l'interface du gestionnaire AP n'est pas pris en charge. En règle générale, un gestionnaire AP unique devrait être configuré sur chaque port (pas de port de secours). Si vous utilisez l'Agrégation de lien (LAG), il y a un seul gestionnaire AP.

L'interface statique (ou constante) du gestionnaire AP doit être attribuée au port 1 du système de distribution et doit avoir une adresse IP unique. Elle ne peut pas être mise en correspondance avec un port de secours. Elle est habituellement configurée sur le même VLAN ou sous-réseau IP que l'interface de gestion, mais ce n'est pas une condition requise.

Q. Je vois ce message d'erreur : The AP '00:0b:85:67:6b:b0' received a WPA MIC error on protocol '1' from Station '00:13:02:8d:f6:41'. Counter measures have been activated and traffic has been suspended for 60 seconds. Pourquoi ?

A. Le Message Integrity Check (MIC) incorporé dans le Protocole WPA (Wi-Fi Protected Access) inclut un compteur de trame qui empêche une attaque homme-dans-le-moyenne. Cette erreur signifie que quelqu'un dans le réseau essaye de rejouer le message qui a été envoyé par le client initial, ou elle peut signifier que le client est défectueux.

Si un client échoue à plusieurs reprises le contrôle MIC, le contrôleur désactive le WLAN sur l'interface AP où les erreurs sont détectées pendant 60 secondes. La première panne MIC est consignée et un compteur est lancé afin d'activer l'application des contre-mesures. Si une nouvelle panne MIC se produit dans les 60 secondes suivant la panne la plus récente, alors un STA dont l'entité IEEE 802.1X a agi en tant que demandeur se désauthentifie lui-même ou désauthentifie tous les STA ayant une association de sécurité si son entité IEEE 802.1X a agi en tant qu'authentificateur.

En outre, le périphérique ne reçoit ou ne transmet aucune trame de données codée TKIP et ne reçoit ou ne transmet aucune trame de données décryptée autre que les messages IEEE 802.1X, de ou à tout homologue pendant une période d'au moins 60 secondes après qu'il détecte la deuxième panne. Si le périphérique est un AP, il rejette les nouvelles associations avec TKIP au cours de cette période de 60 secondes ; à la fin de la période de 60 secondes, l'AP reprend un fonctionnement normal et permet aux STA de se (ré)associer.

Ceci empêche une attaque possible sur la structure du cryptage. Ces erreurs MIC ne peuvent pas être désactivées dans les versions WLC antérieures à 4.1. Avec les versions 4.1 et ultérieures du contrôleur de réseau local sans fil, il y a une commande pour modifier le moment d'analyse des erreurs MIC. La commande est config wlan security tkip hold-down <0-60 seconds> <wlan id>. Utilisez la valeur 0 afin de désactiver la détection de panne MIC pour des contre-mesures.

Q. Je vois ce message d'erreur dans mes journaux du contrôleur : [[ERROR] dhcp_support.c 357: dhcp_bind(): servPort dhcpstate failed. Pourquoi ?

A. Ces messages d'erreur apparaissent en grande partie quand le port de service du contrôleur a le DHCP activé mais ne reçoit pas d'adresse IP d'un serveur DHCP.

Par défaut, l'interface du port de service physique a un client DHCP installé et recherche une adresse par l'intermédiaire du DHCP. Le WLC tente de demander une adresse DHCP pour le port de service. Si aucun serveur DHCP n'est disponible, alors une demande de DHCP pour le port de service échoue. Par conséquent, ceci génère les messages d'erreur.

La solution de contournement est de configurer une adresse IP statique au port de service (même si le port de service est déconnecté) ou d'avoir un serveur DHCP disponible pour attribuer une adresse IP au port de service. Puis, rechargez le contrôleur si nécessaire.

Le port de service est réellement réservé pour l'administration hors bande de la restauration du contrôleur et du système et pour la maintenance en cas d'une défaillance du réseau. C'est également le seul port qui est en activité quand le contrôleur est en mode démarrage. Le port de service ne peut pas porter des tags 802.1Q. Par conséquent, il doit être connecté à un port d'accès sur le commutateur voisin. L'utilisation du port de service est facultative.

L'interface du port de service contrôle les communications et est statiquement mise en correspondance par le système avec le port de service. Elle doit avoir une adresse IP sur un sous-réseau différent de la gestion, du gestionnaire AP et de toutes les interfaces dynamiques. En outre, elle ne peut pas être mise en correspondance avec un port de secours. Le port de service peut utiliser le DHCP afin d'obtenir une adresse IP, ou une adresse IP statique peut lui être attribuée, mais une passerelle par défaut ne peut pas être attribuée à l'interface du port de service. Les routes statiques peuvent être définis par le contrôleur pour avoir un accès réseau distant au port de service.

Q. Mes clients sans fil ne peuvent pas se connecter au réseau local sans fil (WLAN). Le WiSM auquel le point d'accès (AP) est connecté signale ce message : Big NAV Dos attack from AP with Base Radio MAC 00:0g:23:05:7d:d0, Slot ID 0 and Source MAC 00:00:00:00:00:00. Qu'est-ce que cela signifie ?

A. Comme condition pour accéder au support, la couche MAC vérifie la valeur de son vecteur d'allocation réseau (NAV). Le NAV est un compteur qui se trouve à chaque station et qui représente le temps nécessaire à la trame précédente pour envoyer sa trame. Le NAV doit être zéro avant qu'une station puisse essayer d'envoyer une trame. Avant la transmission d'une trame, une station calcule le temps nécessaire pour envoyer la trame en fonction de la longueur et du débit de données de la trame. La station place une valeur qui représente ce temps dans le champ de durée de l'en-tête de la trame. Quand les stations reçoivent la trame, elles examinent cette valeur du champ de durée et l'utilisent comme base pour définir leurs NAV correspondants. Ce processus réserve le support pour la station émettrice.

Un NAV élevé indique la présence d'une valeur exagérée de NAV (mécanisme de détection de porteuse virtuel pour 802.11). Si l'adresse MAC signalée est 00:00:00:00:00:00, elle est probablement usurpée (potentiellement une vraie attaque) et vous devez confirmer ceci avec une capture de paquets.

Q. Après avoir configuré le contrôleur et l'avoir redémarré, nous ne pouvons pas accéder au contrôleur en mode web sécurisé (https). Ce message d'erreur est reçu tout en essayant d'accéder au mode web sécurisé du contrôleur : Secure Web: Web Authentication Certificate not found (error). Quelle est la raison de ce problème ?

A. Il peut y avoir plusieurs raisons liées à ce problème. Une raison courante peut être liée à la configuration de l'interface virtuelle du contrôleur. Afin de résoudre ce problème, supprimez l'interface virtuelle et régénérez-la avec cette commande :

WLC>config interface address virtual 1.1.1.1

Puis, redémarrez le contrôleur. Après que le contrôleur a redémarré, régénérez localement le certificat webauth sur le contrôleur avec cette commande :

WLC>config certificate generate webauth

Dans le résultat de cette commande, vous devriez voir ce message : Web Authentication certificate has been generated.

Maintenant, vous devriez pouvoir accéder au mode web sécurisé du contrôleur lors du redémarrage.

Q. Les contrôleurs signalent parfois ce message d'alerte d'attaque de signature d'inondation de dissassociation d'ID contre les clients valides dans lesquels l'adresse MAC de l'attaquant est celle d'un Point d'accès (AP) joint à ce contrôleur : Alerte : IDS 'Disassoc flood' Signature attack detected on AP '<AP name>' protocol '802.11b/g' on Controller 'x.x.x.x'. The Signature description is 'Disassociation flood', with precedence 'x'. The attacker's mac address is 'hh: hh : hh : hh : hh : hh', channel number is 'x', and the number of detections is 'x'. Pourquoi est-ce que ceci se produit ?

A. C'est en raison de l'ID de bogue Cisco CSCsg81953 (clients enregistrés seulement).

Les attaques par désassociation flottante IDS contre les clients valides sont parfois signalées quand l'adresse MAC de l'attaquant est celle de l'AP connecté à ce contrôleur.

Quand un client est associé à un AP mais cesse de communiquer en raison de l'enlèvement de la carte, de l'itinérance hors de portée, etc. avec l'AP, l'AP attendra jusqu'au délai d'inactivité. Une fois que le délai d'inactivité est atteint, l'AP envoie une trame dissociée à ce client. Quand le client ne reconnaît pas la trame dissociée, l'AP retransmet la trame de nombreuses fois (environ 60 trames). Le sous-système IDS du contrôleur entend ces retransmissions et donne l'alerte avec ce message.

Ce bogue est résolu dans la version 4.0.217.0. Mettez à jour votre version du contrôleur avec cette version afin de maîtriser ce message d'alerte contre les clients valides et les AP.

Q. Je reçois ce message d'erreur dans le syslog du contrôleur : [[WARNING] apf_80211.c 2408: Received a message with an invalid supported rate from station <xx: xx : xx : xx : xx : xx : xx> [ERROR] apf_utils.c 198: Missing Supported Rate. Pourquoi ?

A. En fait, les messages Missing Supported Rate indiquent que le WLC est configuré pour certains débits de données requis sous les paramètres sans fil, mais la carte NIC n'a pas le débit requis.

Si vous avez des débits de données, tels que 1 et 2M, requis sur le contrôleur mais que la carte NIC ne communique pas sur ces débits de données, vous pouvez recevoir ce genre de message. C'est conduite incorrecte de la carte NIC. D'autre part, si votre contrôleur 802.11g est activé et que le client est une carte 802.11b(uniquement), ceci est un message légitime. Si ces messages ne posent aucun problème et que les cartes peuvent encore se connecter, ces messages peuvent être ignorés. Si les messages sont spécifique à la carte, alors assurez-vous que le pilote pour cette carte est à jour.

Q. Ce message d'erreur syslog AP:001f.ca26.bfb4: %LWAPP-3-CLIENTERRORLOG : Decode Msg: could not match WLAN ID <id> est diffusé sur notre réseau. Pourquoi est-ce que ceci se produit et comment l'arrêter ?

A. Ce message est diffusé par les LAP. Ceci apparaît quand vous avez configuré la fonctionnalité de priorité WLAN pour un WLAN et que ce WLAN particulier n'est pas annoncé.

Configurez config ap syslog host global 0.0.0.0 afin de l'arrêter ou vous pouvez mettre une adresse IP spécifique si vous avez un serveur syslog de sorte que le message soit diffusé au serveur seulement.

Q. Je reçois ce message d'erreur sur mon contrôleur de réseau local sans fil (WLC) : [[ERROR] File: apf_mm.c : Ligne : 581 : Announce collision for mobile 00:90:7a:05:56:8a, deleting. Pourquoi ?

A. Généralement, ce message d'erreur indique que le contrôleur a eu des collisions annoncées pour un client sans fil (c.-à-d. des AP distincts annoncent qu'ils ont le client), et le contrôleur n'a pas reçu d'assistance d'un AP à l'autre. Il n'y a aucun état de réseau à mettre à jour. Supprimez le client sans fil et faites de nouveau essayer le client. Si ce problème se pose fréquemment, il peut y avoir un problème avec la configuration de la mobilité. Autrement, cela peut être une anomalie qui est liée à un client ou état spécifique.

Q. Mon contrôleur signale ce message d'alarme : Couverture threshold of '12' violated. Que signifie cette erreur et comment la résoudre ?

A. Ce message d'alarme s'affiche quand un rapport signal/bruit (SNR) de client chute au-dessous de la valeur du seuil SNR pour la radio particulière. 12 est la valeur par défaut du seuil SNR pour la détection d'absence de couverture.

L'algorithme de détection et de correction de l'absence de couverture détermine si une absence de couverture existe quand les niveaux SNR des clients passent sous un seuil SNR donné. Ce seuil SNR varie selon deux valeurs : Puissance de transmission AP et valeur du profil de couverture du contrôleur.

En détail, le seuil SNR du client est défini par la transmission de chaque puissance de transmission AP (représenté en dBm), moins la valeur constante de 17 dBm, moins la valeur du profil de couverture configurable de l'utilisateur (cette valeur est de 12 dB par défaut).

  • Valeur de coupure SNR du client (|dB|)) = [puissance de transmission AP (dBm) - Constante (17 dBm) - Profil de couverture (dB)]

Vous pouvez accéder à cette valeur du profil de couverture configurable de l'utilisateur manière :

  1. Dans l'interface graphique utilisateur WLC, allez sur le titre principal Wireless et sélectionnez Option Network pour le standard de choix WLAN sur la gauche (802.11a ou 802.11b/g). Puis sélectionnez Auto RF en haut à droite de la fenêtre.

  2. Sur la page de paramètres Auto RF Global, trouvez la section Profile Thresholds section. Dans cette section, vous trouverez la valeur de la couverture (3 à 50 dbm). Ceci valeur est la valeur du profil de couverture configurable de l'utilisateur.

  3. Cette valeur peut être modifiée pour influencer la valeur du seuil SNR du client. L'autre façon d'influencer ce seuil SNR est d'augmenter la puissance de transmission et de compenser la détection de l'absence de couverture.

Q. J'utilise ACS v 4.1 et un contrôleur de réseau local sans fil (WLC) 4402. Quand le WLC essaye d'authentifier par MAC un client sans fil à ACS 4.1, l'ACS ne répond pas et affiche ce message d'erreur : " Internal error has occurred ". Toutes mes configurations sont correctes. Pourquoi cette erreur interne produisez-vous ?

A. Il y a un bogue Cisco relatif à l'authentification dont l'ID est CSCsh62641 ( clients enregistrés seulement) dans l'ACS 4.1, où l'ACS affiche le message d'erreur : Internal error has occured.

Ce bogue peut être le problème. Il y a un correctif disponible pour ce bogue Téléchargements ACS 4.1 ( clients enregistrés seulement) page qui devrait résoudre le problème.

Q. Le contrôleur de réseau local sans fil (WLC) de la gamme Cisco 4400 ne démarre pas. Ceci message d'erreur apparaît sur le contrôleur : **** Unable to use ide 0:4 for fatload ** Error (no IRQ) dev 0 blk 0: status 0x51 Error reg: 10 ** Can't read from device 0. Pourquoi ?

A. La raison pour cette erreur peut être un problème matériel. Ouvrez un dossier auprès du TAC pour dépanner ce problème. Afin d'ouvrir un dossier auprès du TAC, vous avez besoin d'un contrat valide avec Cisco. Consultez l'assistance technique afin de contacter le TAC de Cisco.

Q. Le contrôleur de réseau local sans fil (WLC) rencontre des problèmes de mémoire tampon. Une fois que les mémoires tampon sont pleines, le contrôleur tombe en panne et doit être redémarré pour le rapporter en ligne. Ces messages d'erreur apparaissent dans le journal des messages : Mon Apr 9 10:41:03 2007 [ERROR] dtl_net.c 506: Out of System buffers Mon Apr 9 10:41:03 2007 [ERROR] sysapi_if_net.c 537: Cannot allocate new Mbuf. Mon Apr 9 10:41:03 2007 [ERROR] sysapi_if_net.c 219: MbufGet : no free Mbufs. Pourquoi ?

A. Ceci est dû à l'ID de bogue Cisco CSCsh93980 ( clients enregistrés seulement) . Ce bogue a été résolu dans WLC version 4.1.185.0. Mettez à jour votre contrôleur à cette version ou une ultérieure du logiciel afin de maîtriser ce message.

Q. Nous avons effectué la mise à jour de notre contrôleur de réseau local sans fil (WLC) 4400s au code 4.1 et notre syslog a été bombardé par des messages de ce type : May 03 03:55:49.591 dtl_net.c:1191 DTL-1-ARP_POISON_DETECTED: STA [00:17:f2:43:26:93, 0.0.0.0] ARP (op 1) received with invalid SPA 192.168.1.233/TPA 192.168.1.233. Qu'est-ce que ces messages indiquez ?

A. Ceci peut se produire quand le WLAN est marqué comme requérant DHCP. En pareil cas, seules les stations qui reçoivent une adresse IP par DHCP peuvent s'associer. Les clients statiques n'ont pas l'autorisation de s'associer à ce WLAN. WLC agit en tant qu'agent relai DHCP et enregistre l'adresse IP de toutes les stations. Ce message d'erreur est généré quand le WLC reçoit la demande ARP d'une station avant que le WLC n'ait reçu les paquets DHCP de la station et enregistré son adresse IP.

Q. Quand vous utilisez PoE (Power over Ethernet) sur le contrôleur de réseau sans fil Cisco 2106, les radios AP ne sont pas activées. Le message d'erreur AP is unable to verify sufficient in-line power. Radio slot disabled. erreur apparaît. Comment est-ce que je peux résoudre cela ?

A. Ce message d'erreur se produit quand le commutateur, qui alimente le point d'accès, est un commutateur pré-standard mais que l'AP ne prend pas en charge le mode pré-standard de la puissance d'entrée.

Un commutateur pré-standard Cisco ne prend pas en charge la gestion de l'alimentation intelligente (IPM) mais a l'alimentation suffisante pour un accès standard point.

Vous devez activer le mode d'alimentation Pre-Standard sur l'AP qui est soumis à ce message d'erreur. Ceci peut être fait du contrôleur CLI avec la commande config ap power pre-standard {enable | disable} {all | Cisco_AP}.

Cette commande devrait déjà être configurée, s'il y a lieu, si vous vous mettez à jour une version de logiciel précédente avec la version 4.1. Mais, il est possible que vous deviez sélectionner cette commande pour de nouvelles installations, ou si vous réinitialisez l'AP aux valeurs par défaut.

Les commutateurs 15 watt pré-standard Cisco suivants sont disponibles :

Q. Le contrôleur génère un message syslog similaire à ceci : dtl_arp.c:2003 DTL-3-NPUARP_ADD_FAILED : Unable to add an ARP entry for xx: xx.-xxx.x to the network processor. entry does not exist. . . Qu'est-ce que ce message syslog signifie ?

A. Tandis qu'un client sans fil envoie une réponse ARP, l'unité processeur réseau (NPU) a besoin de connaître cette réponse. Ainsi la réponse ARP est transférée au NPU mais le logiciel WLC ne devrait pas essayer d'ajouter cette entrée au processeur réseau. S'il fait ainsi, ces messages sont générés. Il n'y a aucune incidence de fonctionnalité sur WLC dû à ceci mais le WLC génère ce message syslog.

Q. J'ai installé et configuré un nouveau WLC 2106 Cisco. Le WLC indique que la sonde de température ne marche plus. Lorsque vous vous connectez à l'interface web sous "controller summary," il indique "sensor failed" à côté de la température interne. Tout le reste fonctionne normalement.

A. La panne de la sonde de température interne est cosmétique et peut être résolue en mettant à jour la version 4.2.61.0 de WLC.

Les WLC 2106 et WLC 526 built on or after 07/01/2007 peuvent utilisez la puce de sonde de température d'un autre fournisseur. Cette nouvelle sonde fonctionne bien, mais n'est pas compatible avec les logiciels postérieurs à la version 4.2. Par conséquent, un logiciel plus ancien ne peut pas relever la température et affiche cette erreur. Tous les autres fonctionnalités du contrôleur ne sont pas affectées par ce défaut.

Il y a un bogue connu Cisco dont l'ID est CSCsk97299 ( clients enregistrés seulement) associé à ce problème. Ce bogue est mentionné dans les notes de publication relatives au WLC version 4.2.

Q. J'obtiens le message radius_db.c:1823 AAA-5-RADSERVER_NOT_FOUND: Could not find appropriate RADIUS server for WLAN <WLAN ID> - unable to find a default server" pour TOUS les SSID. Ce message apparaît même pour les SSID qui n'utilisent pas les serveurs AAA.

A. Ce message d'erreur signifie que le contrôleur n'a pas pu contacter le serveur radius par défaut ou que ce dernier n'a pas été défini.

Une cause possible pour ce comportement est le bogue Cisco dont l'ID est CSCsk08181 ( clients enregistrés seulement) , qui a été résolu dans la version 4.2. Mettez à jour votre contrôleur à la version 4.2.

Q. Le message d'erreur : Jul 10 17:55:00.725 sim.c:1061 SIM-3-MACADDR_GET_FAIL : Interface 1 source MAC address is not trouvé. apparaît sur le contrôleur de réseau local sans fil (WLC). Qu'est-ce que cela indique?

A. Ceci signifie que le contrôleur a eu une erreur tandis qu'il envoyait un paquet de source paquet.

Q. Ces messages d'erreur apparaissent sur le contrôleur de réseau local sans fil (WLC) :
  • Jul 10 14:52:21.902 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Failed to read configuration file « cliWebInitParms.cfg »

  • Jul 10 14:52:21.624 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Failed to read configuration file « rfidInitParms.cfg »

  • Jul 10 14:52:21.610 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Failed to read configuration file « dhcpParms.cfg »

  • Jul 10 14:52:21.287 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Failed to read configuration file « bcastInitParms.cfg »

  • Mar 18 16:05:56.753 osapi_file.c:274 OSAPI-5-FILE_DEL_FAILED : Failed to delete the file : sshpmInitParms.cfg. file removal failed. - Processus : Nom : fp_main_task, Id:11ca7618

  • Mar 18 16:05:56.753 osapi_file.c:274 OSAPI-5-FILE_DEL_FAILED : Failed to delete the file : bcastInitParms.cfg. file removal failed. - Processus : Nom : fp_main_task, Id:11ca7618

Qu'est-ce que ces messages d'erreur indiquent ?

A. Ces messages sont des messages d'information et font partie de la procédure de démarrage normale. Ces messages apparaissent en raison d'un échec à la lecture ou à la suppression de plusieurs fichiers de configuration différents. Quand des fichiers de configuration particuliers ne sont pas trouvés ou si le fichier de configuration ne peut pas être lu, l'ordre de configuration de chaque processus envoie ce message, par exemple, pas de configuration de serveur DHCP, pas de configuration de tags (RF ID) et ainsi de suite. Ce sont des messages de faible gravité qui peuvent être ignorés sans risque. Ces messages n'interrompent pas l'opération du contrôleur.

Q. HE6-WLC01,local0,alert,2008-07-25,12:48:18,apf_rogue.c:740 APF-1-UNABLE_TO_KEEP_ROUGE_CONTAIN : Unable to keep rogue 00:14:XX:02:XX:XX in contained state - no available AP to contain. apparaît. Qu'est-ce que cela indique?

A. Ceci signifie que l'AP qui a rempli la fonction de maîtrise des serveurs non autorisés n'est plus disponible, et que le contrôleur ne peut pas trouver d'AP approprié pour maîtriser les serveurs non-autorisés.

Q. Le message système DTL-1-ARP_POISON_DETECTED: STA [00:01:02:0e:54:c4, 0.0.0.0] ARP (op 1) received with invalid SPA 192.168.1.152/TPA 192.168.0.206 apparaît sur le contrôleur de réseau local sans fil. Ce qui qu'implique ce message ?

A. Il est possible que le système ait détecté un spoofing ou empoisonnement de l'ARP. Mais, ce message n'implique pas nécessairement que tout spoofing malveillant de l'ARP s'est produit. Le message apparaît quand ces conditions sont vraies :

Q. Les LAP n'utilisent pas Power over Ethernet (POE) pour se mettre sous tension. Je vois les messages sur le contrôleur de réseau local sans fil :
AP's Interface:1(802.11a) Operation State Down: Base Radio MAC:XX:1X:XX:AA:VV:CD Cause=Low in-line power
Quel est le problème ?

A. Ceci peut se produire si les paramètres de Power over Ethernet (POE) ne sont pas configurés correctement. Quand un point d'accès qui a été converti au mode léger, par exemple, un AP1131 ou un AP1242, ou un point d'accès de la gamme 1250 est mis en marche par un injecteur de courant qui est connecté à un commutateur de gestion de l'alimentation pré-intelligent (pre-IPM) Cisco, vous devez configurer la Power over Ethernet (PoE), également connu sous le nom d'alimentation incorporée.

Reportez-vous à: Configurer Power over Ethernet pour plus d'informations sur la façon de configurer Power over Ethernet (POE).

Q. Vous voyez ce message sur le contrôleur de réseau local sans fil (WLC) :
*Mar 05 10:45:21.778: %LWAPP-3-DISC_MAX_AP2: capwap_ac_sm.c:1924 Dropping primary discovery request from AP XX:1X:XX:AA:VV:CD - maximum APs joined 6/6
Qu'est-ce que cela indique?

A. Les points d'accès léger suivent un certain algorithme pour trouver un contrôleur. La procédure de détection et d'association est expliquée en détail dans la partie Léger d'AP léger (LAP) à un contrôleur de réseau local sans fil (WLC)

Ce message d'erreur s'affiche sur le WLC quand il reçoit une demande de détection avoir atteint son maximum de capacité AP.

Si le contrôleur principal pour un LAP n'est pas configuré ou si c'est un nouveau , il envoie des demandes de détection LWAPP à tous les contrôleurs contrôleurs. Si la demande de détection atteint un contrôleur qui fonctionne à sa pleine capacité AP, le WLC obtient les demandes et se rend compte qu'il est à sa capacité AP maximale et ne réagit pas à la demande et affiche cette erreur.

Q. Où puis-je trouver plus d'informations sur les messages système messages ?

A. Reportez-vous à: Cisco sur les messages système du contrôleur de réseau local sans fil, 4.2 pour plus d'informations sur les messages système LWAPP.

Q. L'erreur extrayant le webauth classe l'erreur le message apparaît sur le contrôleur LAN Sans fil (WLC). Ce qui fait ceci indiquez ?

A. WLC ne charge pas un paquet fait sur commande d'authentification Web/fonction émulation si un des fichiers empaquetés a plus considérablement que 30 caractères dans le nom du fichier, qui inclut l'extension de fichier. Le paquet authentique personnalisé de Web a une limite de à 30 caractères pour des noms du fichier. Assurez-vous qu'aucun nom du fichier dans le paquet n'est plus considérablement que 30 caractères.

Q. Contrôleurs LAN Sans fil (WLCs), exécutant le code 5.2 ou 6.0 avec un grand le nombre de groupes AP, GUI de Web peut ne pas afficher tous les groupes configurés AP. Ce qui est la question ?

A. Les groupes des disparus AP peuvent être vus si vous utilisez l'exposition CLI ordre wlan d'AP-groupes.

Essayez d'ajouter un groupe supplémentaire AP à la liste. Par exemple, 51 AP Les groupes déployés, et le cinquante-et-unième manque (page 3). Ajoutez le cinquante-deuxième groupe, et le paginez 3 devraient apparaître dans le GUI de Web.

Afin de résoudre ce problème, mise à jour à la version WLC 7.0.220.0.


Informations connexes


Document ID: 91505