FAQ sur les messages d'erreur et les messages système du contrôleur LAN sans fil (WLC)

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 à celui-ci : LWAPP Join-Request does not include valid certificate in CERTIFICATE_PAYLOAD from AP 00:0b:85:68:ab:01. Pourquoi ?

R.Vous pouvez recevoir ce message d'erreur si le tunnel LWAPP entre le point d'accès et le WLC traverse un chemin de réseau avec un MTU inférieur à 1500 octets. Ceci entraîne la fragmentation des paquets LWAPP. C'est un bogue connu dans le contrôleur. Référez-vous au bogue Cisco IDCSCsd39911.

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

Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations et aux outils internes relatifs aux bogues Cisco.

Q. Je souhaite établir une tunnellisation 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>. Requête d'exportation d'ancrage à partir de l'adresse IP du commutateur : <adresse IP du contrôleur> ignorée. Quel est le problème ?

A.La transmission tunnel invité offre une sécurité supplémentaire pour l'accès invité-utilisateur au réseau sans fil de l'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 le résultat de la commande debugcommand l'indique, le problème peut être lié à la non-concordance dans n'importe laquelle des politiques de sécurité configurées pour ce WLAN particulier dans les contrôleurs internes ainsi 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 commune à 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 ?

R. Étant donné que la multidiffusion est désactivée sur les contrôleurs, les messages à l'origine de cette alarme peuvent être des messages ARP (Address Resolution Protocol). 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." dans l'un de mes contrôleurs. Que signifie cette erreur et quelles mesures dois-je prendre pour la résoudre ?

A.Ce message s'affiche lorsque 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 à atténuer ce message est d'autoriser seulement les VLAN qui sont utilisés sur le contrôleur sur l'agrégation qui va au contrôleur avec la commande switchport vlan allow sur le commutateur.

Q. Pourquoi ce message d'erreur s'affiche-t-il sur la console : Échec de la commande Msg 'Set Default Gateway' de la table système, ID = 0x0050b986 valeur d'erreur = 0xfffffffc ?

R. Cela peut être dû à une charge CPU élevée. 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é.

Pour plus d'informations, référez-vous à Contrôleurs LAN sans fil Cisco.

Q. Je reçois ces messages d'erreur de clé WEP (Wired Equivalent Privacy) sur mon système de contrôle sans fil (WCS) : la clé WEP configurée sur la station peut être incorrecte. L'adresse MAC de la station est « xx:xx:xx:xx:xx:xx », l'adresse MAC de la radio de base du point d'accès est « xx:xx:xx:xx:xx » et l'ID de logement est « 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 ?

R.Si toutes vos configurations liées à la sécurité sont parfaites, les messages que vous recevez maintenant sont à cause de bogues. Il y a quelques bogues identifiés dans le contrôleur. Référez-vous au bogue Cisco IDCSCse17260 et Cisco mais ID CSCse1202, qui indique « La clé WEP configurée sur la station peut être incorrecte avec les clients WPA et TKIP respectivement ». En fait, l'ID de bogue Cisco CSCse17260 est un doublon de l'ID de bogue Cisco CSCse1202. Le correctif pour Cisco, mais l'ID CSCse1202est déjà disponible avec la version 3.2.171.5 du WLC.

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

Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.

Q. J'utilise un serveur RADIUS externe pour authentifier les clients sans fil via le contrôleur. Le contrôleur envoie régulièrement ce message d'erreur : aucun serveur RADIUS ne répond. Pourquoi ces messages d'erreur s'affichent-ils ?

R. Lorsqu’une requête sort du WLC vers le serveur RADIUS, chaque paquet a un numéro de séquence auquel le WLC attend une réponse. En l'absence de réponse, un message indique que radius-server ne répond pas.

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 du WLC sous Security > authentication-server. Le maximum est de 30 secondes. Par conséquent, il peut être utile de définir cette valeur de temporisation à son maximum afin de résoudre ce problème.

Parfois, les serveurs RADIUS effectuent des 'rejets silencieux' 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, dans de tels cas, le contrôleur peut marquer le serveur RADIUS comme ne répondant pas

Afin de surmonter le problème des rejets silencieux, désactivez la fonctionnalité de basculement agressif dans le WLC.

Si la fonctionnalité de basculement agressif est activée dans le WLC, le WLC est trop agressif pour marquer le serveur AAA comme ne répondant pas. Cependant, cela ne doit pas être fait parce que le serveur AAA ne peut pas répondre seulement à ce client particulier (il ne supprime pas silencieusement). Cela peut être une réponse à d'autres clients valides (avec des certificats valides). Cependant, le WLC peut toujours marquer le serveur AAA comme ne répondant pas et ne fonctionnant pas.

Pour remédier à ce problème, désactivez la fonction de basculement agressif. Émettez la commande config radius agressif-failover disable à partir de l'interface de ligne de commande du contrôleur afin d'effectuer 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 enregistre le message d'erreur IAPP-3-MSGTAG015 : iappSocketTask : iappRecvPkt renvoyé. Que se passe-t-il ?

R.Cela se produit principalement en raison d'un problème avec les cartes Intel qui prennent en charge CCX v4, mais qui exécutent une version du bundle 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. Référez-vous au bogue Cisco IDCSCsi91347 pour plus d'informations sur ce message d'erreur.

Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.

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

R.Ce message d'erreur se produit lorsque l'utilisateur tente de se connecter à un réseau WLAN protégé par EAP et a échoué au nombre préconfiguré de tentatives EAP. Lorsque l'utilisateur ne parvient pas à s'authentifier, le contrôleur exclut le client et le client ne peut pas se connecter au réseau tant que le compteur d'exclusion n'expire pas ou n'est pas remplacé manuellement 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) : Une alerte de commutateur de catégorie 1 est générée avec la gravité 1 par le commutateur WLCSCH01/10.0.16.5 Le message de l'alerte est le contrôleur « 10.0.16.5 ». RADIUS server(s) are not responding to authentication requests. Quel est le problème ?

R. Cela 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.

Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.

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 ?

R.L'état du profil de bruit ÉCHEC/RÉUSSI est défini après le résultat du test effectué par le WLC et en comparaison avec le seuil actuellement défini. 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 ajuster les paramètres dans le profil, mais il est recommandé de modifier les paramètres après avoir bien compris la conception du réseau et comment elle peut affecter les performances du réseau.

Les seuils PASSED/FAILED de la gestion des ressources radio (RRM) sont globalement définis pour tous les points d'accès sur les pages 802.11a Global Parameters > Auto RF et 802.11b/g Global Parameters > Auto RF. Les seuils PASSED/FAILED RRM sont définis individuellement pour ce point d'accès sur la page 802.11 AP Interfaces > Performance Profilepage.

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 ?

R.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 seul gestionnaire AP doit être configuré sur chaque port (pas de sauvegarde). 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 : L'AP '00:0b:85:67:6b:b0' a reçu une erreur WPA MIC sur le protocole '1' de la station '00:13:02:8d:f6:41'. Counter measures have been activated and traffic has been suspended for 60 seconds. Pourquoi ?

A.Message Integrity Check (MIC) incorporé dans Wi-Fi Protected Access (WPA) inclut un compteur de trames qui empêche une attaque man-in-the-middle. Cette erreur signifie qu'une personne du réseau souhaite relire le message envoyé par le client d'origine ou 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 défaillance MIC ultérieure se produit dans les 60 secondes qui suivent la défaillance précédente la plus récente, alors un STA dont l'entité IEEE 802.1X a agi en tant que demandeur doit s'invalider lui-même ou invalider tous les STA avec 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 ni ne transmet aucune trame de données cryptée TKIP et ne reçoit ni ne transmet aucune trame de données non cryptée autre que les messages IEEE 802.1X, en provenance ou à destination d'un homologue pendant une période d'au moins 60 secondes après avoir détecté la seconde défaillance. Si le périphérique est un point d'accès, il interdit les nouvelles associations avec TKIP pendant cette période de 60 secondes ; à la fin de la période de 60 secondes, le point d'accès reprend le fonctionnement normal et permet aux STA de (re)s'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 isconfig 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.

*Invalidé : fin de l'authentification.

Q. Ce message d'erreur s'affiche dans les journaux de mon contrôleur : [ERROR] dhcp_support.c 357 : dhcp_bind() : servPort dhcpstate failed. Pourquoi ?

R.Ces messages d'erreur apparaissent surtout lorsque le port de service du contrôleur a 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 : attaque de Dos NAV importante du point d'accès avec l'adresse MAC radio de base 00:0g:23:05:7d:d0, l'ID de logement 0 et l'adresse MAC source 00:00:00:00:00:00. Qu'est-ce que cela signifie ?

R. 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 la durée nécessaire à l’envoi de la trame en fonction de la longueur de trame et du débit de données. 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 (ce qui peut constituer une véritable attaque) et vous devez la confirmer par une capture de paquets.

Q. Une fois que j'ai configuré le contrôleur et que je l'ai redémarré, je ne peux pas accéder au contrôleur en mode Web sécurisé (https). Ce message d'erreur est reçu alors que j'essaie d'accéder au mode web sécurisé du contrôleur : Web sécurisé : Certificat d'authentification Web introuvable (erreur). Quelle est la raison de ce problème ?

R. Plusieurs raisons peuvent être associé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 pouvez voir le message suivant : Le certificat d'authentification Web a été généré.

Vous pouvez maintenant 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 dissociation IDS contre des clients valides dans lesquels l'adresse MAC de l'attaquant est celle d'un point d'accès (AP) joint à ce contrôleur : Alerte : Attaque de signature d'inondation de dissociation IDS détectée sur le protocole AP « <nom AP> » « 802.11b/g » sur le contrôleur « x.x.x.x ». The Signature description is 'Disassociation flood', with precedence 'x'. L'adresse MAC du pirate est « hh:hh:hh:hh:hh:hh », le numéro de canal est « x » et le nombre de détections est « x ». Pourquoi est-ce que ceci se produit ?

R.Ceci est dû au bogue Cisco IDCSCsg81953 .   

Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.

Les attaques par inondation de dissociation IDS contre des clients valides sont parfois signalées lorsque l'adresse MAC de l'attaquant est celle d'un point d'accès joint à ce contrôleur.

Lorsqu'un client est associé au point d'accès mais arrête les communications en raison du retrait de la carte, il se déplace hors de portée, et ainsi de suite, vers le point d'accès, le point d'accès attend 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> [ERROR] apf_utils.c 198 : Missing Supported Rate. Pourquoi ?

R. En fait, les messages Missing Supported Rate indiquent que le WLC est configuré pour certains débits de données requis dans les paramètres sans fil, mais que la carte réseau ne dispose pas du 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 ?

R. Ce message est diffusé par les LAP. Cela se produit lorsque vous avez configuré une fonction de remplacement de WLAN pour un WLAN et que ce WLAN particulier n'est pas annoncé.

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

Q. Je reçois ce message d'erreur sur mon contrôleur LAN sans fil (WLC) : [ERROR] Fichier : apf_mm.c : Line: 581 : Announce collision for mobile 00:90:7a:05:56:8a, delete. Pourquoi ?

R.Généralement, ce message d'erreur indique que le contrôleur avait annoncé des collisions pour un client sans fil (c'est-à-dire que des points d'accès distincts annoncent qu'ils ont le client), et le contrôleur n'a pas reçu de transfert d'un point d'accès au suivant. Il n'y a aucun état de réseau à mettre à jour. Supprimez le client sans fil et demandez au client de réessayer. Si ce problème se produit fréquemment, il peut y avoir un problème avec la configuration de la mobilité. Sinon, il peut s'agir d'une anomalie liée à un client ou à une condition spécifique.

Q. Mon contrôleur déclenche ce message d'alarme : le seuil de couverture de '12' a été violé. Quelle est cette erreur et comment peut-elle être résolue ?

A.Ce message d'alarme est déclenché lorsqu'un rapport signal/bruit (SNR) client tombe à une valeur inférieure à la valeur de seuil SNR pour la radio particulière. 12 est la valeur de seuil SNR par défaut pour la détection des trous de couverture.

L'algorithme de détection et de correction des trous de couverture détermine s'il existe un trou de couverture lorsque les niveaux SNR des clients sont inférieurs à un seuil SNR donné. Ce seuil SNR varie en fonction de deux valeurs : la puissance de transmission du point d'accès et la valeur du profil de couverture du contrôleur.

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

• Valeur de coupure SNR du client (|dB|) = [Puissance d'émission AP (dBm) - Constante (17 dBm) - Profil de couverture (dB)]

Cette valeur de profil de couverture configurable par l'utilisateur est accessible de la manière suivante :

1. Dans l'interface graphique utilisateur du WLC, allez à l'en-tête principal de Wireless et sélectionnez l'option Network pour la norme WLAN de choix sur le côté gauche (802.11a ou 802.11b/g). Sélectionnez ensuite Auto RF dans le coin supérieur droit de la fenêtre.

2. Dans la page Paramètres généraux RF automatiques, recherchez la section Seuils de profil. Dans cette section, vous trouverez la valeur de la couverture (3 à 50 dbm). Cette valeur est la valeur du profil de couverture configurable par 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 trou de couverture.

Q. J'utilise ACS v 4.1 et un contrôleur LAN sans fil (WLC) 4402. Lorsque le WLC tente d'authentifier MAC un client sans fil auprès d'ACS 4.1, l'ACS ne répond pas avec l'ACS et signale ce message d'erreur : " Une erreur interne s'est produite ". Toutes mes configurations sont correctes. Pourquoi cette erreur interne se produit-elle ?

R.Il y a un bogue Cisco IDCSCsh62641 lié à l'authentification dans ACS 4.1, où ACS donne le message d'erreur Internal error has occrederror.

Ce bogue peut être le problème. Il y a un correctif disponible pour ce bogue sur le site de téléchargements d'ACS 4.1 qui peut résoudre le problème.

Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.

Q. Le contrôleur LAN sans fil (WLC) de la gamme Cisco 4400 ne peut pas démarrer. Ce message d'erreur est reçu sur le contrôleur : ** Unable to use ide 0:4 for fatload ** Error (no IRQ) dev 0 blk 0 : status 0x51 Error reg : 10 ** Cannot read from device 0. Pourquoi ?

R. La raison de cette erreur peut être un problème matériel. Ouvrez un dossier TAC pour résoudre ce problème. Pour ouvrir un dossier TAC, vous devez disposer d'un contrat valide avec Cisco. Reportez-vous au support technique pour contacter le centre d'assistance technique 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 tampons sont pleines, le contrôleur tombe en panne et doit être redémarré pour le remettre en ligne. Ces messages d'erreur sont affichés 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. Lun Apr 9 10:41:03 2007 [ERREUR] sysapi_if_net.c 2019 : MbufGet : no free Mbufs. Pourquoi ?

R. Cela est dû au bogue Cisco IDCSCsh93980. Ce bogue a été résolu dans WLC version 4.1.185.0. Mettez à niveau votre contrôleur vers cette version du logiciel ou une version ultérieure afin de surmonter ce message.

Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.

Q. J'ai effectué la mise à niveau de notre contrôleur LAN sans fil (WLC) 4400 vers le code 4.1 et notre Syslog a été bombardé par des messages, tels que : May03 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) reçu avec le SPA 192.168.1.233/TPA 192.168.1.233. Qu'indiquent ces messages ?