Avez-vous un compte?
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.
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.
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.
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.
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 :
Vérifiez si le client est certifié Wi-Fi pour le WPA2 et vérifiez la configuration du client pour le WPA2.
Vérifiez la fiche technique afin de voir si l'utilitaire client prend en charge le WPA2. Installez n'importe quel correctif sorti par le fournisseur pour prendre en charge le WPA2. Si vous utilisez l'utilitaire Windows, assurez-vous que vous avez installé le correctif WPA2 de Microsoft afin de prendre en charge le WPA2.
![]()
Mettez à jour le pilote et le microprogramme du client.
Désactivez les extensions Aironet sur le WLAN.
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 :
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.
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é.
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.
Comme dernière option, essayez de recharger le LAP qui génère ce message d'erreur.
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.
A. RADIUS et les débogages de dot1x prouvent 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 :
- Contrôlez et vérifiez la configuration du serveur IAS.
- Vérifiez le fichier journal.
- Installez un logiciel tel que Ethereal, qui peut vous fournir des détails sur l'authentification.
- Arrêtez et remettez en marche le service IAS.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 webauthDans 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.
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.
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.
A. Ce message est diffusé par les LAP. Ceci est vu quand vous avez configuré la caractéristique de priorité WLAN pour un WLAN et ce WLAN particulier n'est pas annoncé.
Configurez le 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 de Syslog de sorte que le message soit émission seul au serveur.
A. Généralement, ce message d'erreur indique que le contrôleur avait annoncé des collisions pour un client sans fil (c.-à-d. les aps distincts annoncent qu'ils ont le client), et le contrôleur n'a pas reçu un transfert d'un AP au prochain. Il n'y a aucun état de réseau à mettre à jour. Supprimez le client sans fil et ayez l'essai de client de nouveau. Si ce problème se pose fréquemment, il peut y a un problème avec la configuration de mobilité. Autrement, ce pourrait être une anomalie qui est liée à un client ou à un état spécifique.
A. Ce message d'alarme est augmenté quand un rapport signal/bruit de client (SNR) tombe au-dessous de la valeur de seuil SNR pour la radio particulière. 12 est la valeur par défaut de seuil SNR pour la détection de trou de couverture.
L'algorithme de détection et de correction de trou de couverture déterminent si un trou de couverture existe quand les niveaux SNR des clients passent au-dessous d'un seuil SNR indiqué. Ce seuil SNR varie selon deux valeurs : La puissance de transmission AP et la couverture de contrôleur profilent la valeur.
En détail, le seuil SNR de client est défini par la puissance de transmission de chaque AP (représentée dans le dBm), sans la valeur constante de 17dBm, sans la valeur configurable de profil de couverture d'utilisateur (cette valeur est transférée sur 12 dB).
Valeur de coupure SNR du client (|dB|) = [puissance de transmission AP (dBm) – constante (dBm 17) – profil de couverture (dB)]
Cette valeur configurable de profil de couverture d'utilisateur peut être accédée à de cette façon :
Dans le GUI WLC, allez au titre principal de la radio et sélectionnez l'option Network pour la norme WLAN du choix du côté gauche (802.11a ou 802.11b/g). Puis, Auto RF choisie dans le juste de stimulant de la fenêtre.
Dans l'Auto RF Global les paramètres paginent, trouvent la section de seuils de profil. Dans cette section, vous trouverez la valeur de la couverture (3 à 50 dbm). Cette valeur est la valeur configurable de profil de couverture d'utilisateur.
Cette valeur peut être modifiée pour influencer la valeur du seuil SNR du client. L'autre manière d'influencer ce seuil SNR est d'augmenter la puissance de transmission et de compenser la détection de trou de couverture.
A. Il y a un ID de bogue Cisco associé par authentification CSCsh62641 (clients enregistrés seulement) dans l'ACS 4.1, où l'ACS donne l'erreur interne a le message d'erreur produit.
Ce bogue peut être le problème. Il y a un correctif disponible pour cette bogue à la page de téléchargements ACS 4.1 (clients enregistrés seulement) qui devrait réparer le problème.
A. La raison pour cette erreur peut être un problème matériel. Ouvrez une valise TAC pour dépanner plus loin ce problème. Afin d'ouvrir une valise TAC, vous devez avoir un contrat valide avec Cisco. Référez-vous au Soutien technique afin de contacter Cisco TAC.
A. C'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. Améliorez votre contrôleur afin de surmonter à cette version de logiciel ou à plus tard ce message.
A. Ceci peut se produire quand le WLAN est marqué comme requérant DHCP. En pareil cas, on permet seulement aux des stations qui reçoivent une adresse IP par le DHCP pour s'associer. Les clients statiques n'ont pas l'autorisation de s'associer à ce WLAN. WLC agit en tant qu'agent de relais DHCP et enregistre l'adresse IP de toutes les stations. Ce message d'erreur est généré quand WLC reçoit la demande d'ARP d'une station avant que le WLC ait reçu des paquets DHCP de la station et ait enregistré son adresse IP.
A. Ce message d'erreur se produit quand le commutateur, qui met le Point d'accès sous tension, est un commutateur pré-standard mais AP ne prend en charge pas le mode Pré-standard de la puissance d'entrée.
Un commutateur pré-standard de Cisco est un qui ne prend en charge pas la gestion de l'alimentation intelligente (IPM) mais a l'alimentation suffisante pour un point d'accès standard.
Vous devez activer le mode Pré-standard de mettez sous tension AP qui est soumis à ce message d'erreur. Ceci peut être fait du contrôleur CLI avec le 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 améliorez à la version de logiciel 4.1 d'une version précédente. Mais, il est possible que vous deviez sélectionner cette commande pour de nouvelles installations, ou si vous remettez à l'état initial AP à Factory Defaults.
Les commutateurs 15 watt pré-standard Cisco suivants sont disponibles :
AIR-WLC2106-K9
WS-C3550, WS-C3560, WS-C3750
C1880
2600, 2610, 2611, 2621, 2650, 2651
2610XM, 2611XM, 2621XM, 2650XM, 2651XM, 2691
3631-telco, 3620, 3640, 3660
3725, 3745
A. Tandis qu'un certain client sans fil envoie une réponse d'ARP, les besoins de l'unité de processeur de réseau (NPU) de connaître cette réponse. Ainsi la réponse d'ARP est expédiée au logiciel NPU mais WLC ne devrait pas essayer d'ajouter cette entrée au processeur de réseau. S'il fait ainsi, ces messages sont générés. Il n'y a aucune incidence de fonctionnalité sur le WLC dû à ceci mais le WLC génère ce message de Syslog.
A. La panne interne de capteur de température est cosmétique et peut être résolue avec une mise à jour à la version 4.2.61.0 WLC.
WLC 2106 et WLC 526 construit sur ou après 07/01/2007 peuvent utiliser la puce de capteur de température d'un autre constructeur. Ce nouveau capteur fonctionne bien, mais n'est pas compatible avec le logiciel plus tard que la release 4.2. Par conséquent, un logiciel plus ancien ne peut pas relever la température et affiche cette erreur. Toutes autres fonctionnalités de contrôleur ne sont pas affectées par ce défaut.
Il y a un ID de bogue Cisco connu CSCsk97299 (clients enregistrés seulement) lié à cette question. Cette bogue est mentionnée dans la note en version de la version 4.2 WLC.
A. Ce message d'erreur signifie que le contrôleur ne pouvait pas contacter le serveur par défaut de rayon ou qu'on n'a pas été défini.
Un possible raison pour ce comportement est l'ID de bogue Cisco CSCsk08181 (clients enregistrés seulement), qui a été résolu dans la version 4.2. Mettez à jour votre contrôleur à la version 4.2.
A. Ceci signifie que le contrôleur a eu une erreur tandis qu'il envoyait à une CPU le paquet originaire.
10 juillet 14:52:21.902 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Pour lire le fichier de configuration « cliWebInitParms.cfg »
10 juillet 14:52:21.624 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Pour lire le fichier de configuration « rfidInitParms.cfg »
10 juillet 14:52:21.610 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Pour lire le fichier de configuration « dhcpParms.cfg »
10 juillet 14:52:21.287 nvstore.c:304 SYSTEM-3-FILE_READ_FAIL : Pour lire le fichier de configuration « bcastInitParms.cfg »
18 mars 16:05:56.753 osapi_file.c:274 OSAPI-5-FILE_DEL_FAILED : Failed to delete the file : la suppression de fichier sshpmInitParms.cfg a manqué. - Processus : Nom : fp_main_task, Id:11ca7618
18 mars 16:05:56.753 osapi_file.c:274 OSAPI-5-FILE_DEL_FAILED : Failed to delete the file : la suppression de fichier bcastInitParms.cfg a manqué. - Processus : Nom : fp_main_task, Id:11ca7618
A. Ces messages sont des messages d'information et font partie de la procédure normale de démarrage. Ces messages apparaissent en raison d'un manque de lire ou supprimer plusieurs différents fichiers de configuration. Quand des fichiers de configuration particuliers ne sont pas trouvés ou si le fichier de configuration ne peut pas être indiqué, l'ordre de config pour chaque processus envoie ce message, par exemple, aucun config de serveur DHCP, aucun config de balises (ID rf), et ainsi de suite. Ce sont des messages de bas-sévérité qui peuvent sans risque être ignorés. Ces messages n'interrompent pas le fonctionnement du contrôleur.
A. Ceci signifie qu'AP qui a rempli la fonction escroc de retenue n'est plus disponible, et le contrôleur ne peut trouver aucun AP approprié pour exécuter la retenue escroc.
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 n'importe quelle mystification malveillante d'ARP s'est produite. Le message apparaît quand ces conditions sont vraies :
Un WLAN est configuré avec le DHCP exigé, et un périphérique de client, après avoir associé sur ce WLAN, transmet un message d'ARP sans le premier DHCP se terminant. Ceci peut être comportement normal ; il peut se produire, par exemple, quand le client est statiquement adressé, ou quand le client tient un bail valide DHCP d'une association antérieure. Le message d'erreur peut ressembler à cet exemple :
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.206L'effet de cette condition est que le client ne peut pas envoyer ou recevoir n'importe quel trafic de données, jusqu'à ce qu'il DHCPs par le WLC.
Référez-vous à la section de messages DTL de pour en savoir plus Sans fil de guide des messages système de contrôleur LAN de Cisco.
Quel est le problème ?AP's Interface:1(802.11a) Operation State Down: Base Radio MAC:XX:1X:XX:AA:VV:CD Cause=Low in-line power
A. Ceci peut se produire si l'alimentation au-dessus des configurations des Ethernets (POE) ne sont pas configurées correctement. Quand un Point d'accès qui a été converti en mode léger, par exemple, un AP1131 ou un AP1242, ou un Point d'accès de gamme 1250 est actionné par un injecteur de courant qui est connecté à un commutateur pré-intelligent de la Gestion d'alimentation de Cisco (pré-IPM), vous devez configurer l'alimentation au-dessus des Ethernets (PoE), également connus sous le nom d'alimentation en ligne.
Référez-vous à configurer l'alimentation au-dessus des Ethernets pour plus d'informations sur la façon configurer l'alimentation au-dessus des Ethernets (POE).
Qu'est-ce que cela indique?*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
A. Le Point d'accès léger suit un certain algorithme pour trouver un contrôleur. La détection et le processus de jonction est expliquée en détail dans l'enregistrement léger AP (RECOUVREMENT) à un contrôleur LAN Sans fil (WLC)
Ce message d'erreur est vu sur le WLC, quand il reçoit une demande de détection après qu'il ait atteint sa capacité du maximum AP.
Si le contrôleur primaire pour un RECOUVREMENT n'est pas configuré ou si son un nouveau hors du RECOUVREMENT de case, il envoie des demandes de LWAPP discovery à tous les contrôleurs accessibles. Si les demandes de détection atteint un contrôleur qui fonctionne à sa pleine capacité AP, WLC obtient les demandes et se rend compte qu'il est à sa capacité du maximum AP, et ne répond pas à la demande et donne cette erreur.
A. Référez-vous au guide des messages système Sans fil de contrôleur LAN de Cisco, 4.2 pour plus d'informations sur les messages système LWAPP.
A. WLC ne charge pas un paquet fait sur commande d'authentification Web/fonction émulation si des n'importe quels des fichiers empaquetés ont 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 jusqu'à 30 caractères pour des noms du fichier. Assurez-vous qu'aucun nom du fichier dans le paquet n'est plus grand que 30 caractères.
A. Les groupes des disparus AP peuvent être vus si vous utilisez les AP-groupes de show wlan CLI commandez.
Essayez d'ajouter un groupe supplémentaire AP à la liste. Par exemple, 51 groupes AP déployés, et le cinquante-et-unième manque (page 3). Ajoutez le cinquante-deuxième groupe, et la page 3 devrait paraître dans le GUI de Web.
Afin de résoudre ce problème, mise à jour à la version 7.0.220.0 WLC.