Cisco Workgroup Bridge (WGB) est un outil très utile pour la conception et le déploiement d'un réseau sans fil, car il permet aux périphériques non sans fil d'accéder à la mobilité. WGB fournit de nombreux détails sur l'itinérance, l'accès à la sécurité, etc., qui ont un impact sur les scénarios de déploiement selon vos besoins.
Dans les versions de code 12.4(25d)JA et ultérieures, Cisco a introduit un ensemble de commandes et de modifications afin d'optimiser l'utilisation de WGB sur les environnements d'itinérance à haut débit.
Ce document couvre différents aspects du fonctionnement d'un WGB, y compris les points de décision de l'algorithme d'itinérance, et comment le configurer pour le modèle d'utilisation prévu.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Solution LAN sans fil Cisco
Pont de groupe de travail Cisco
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Un WGB est essentiellement un point d'accès configuré pour agir en tant que client sans fil vers une infrastructure et pour fournir une connectivité de couche 2 aux périphériques connectés à son interface Ethernet.
Un déploiement WGB classique comporte les composants suivants :
Périphérique WGB, généralement équipé d'au moins une radio et d'une interface Ethernet
Une infrastructure sans fil, généralement appelée point d'accès racine, qui peut être autonome ou unifiée.
Un ou plusieurs périphériques client câblés connectés au WGB. Ce document ne couvre pas les scénarios de rôles mixtes (une radio comme WGB, une radio comme racine sur le même AP).
Il existe trois principaux types de WGB :
Cisco WGB : Cisco WGB est un point d'accès basé sur Cisco IOS® configuré comme WGB (1130, 1240, 1250, etc.). Ce mode utilise le protocole IAPP pour informer l'infrastructure réseau des périphériques que le WGB a appris sur son interface Ethernet. Dans ce cas, le contrôleur de réseau local sans fil (WLC) ou point d'accès racine a une visibilité de couche 2 des périphériques « suspendus » du WGB.
WGB non Cisco : Il s'agit d'un périphérique tiers agissant en tant que WGB, qui connecte un ou plusieurs périphériques câblés à l'infrastructure sans fil. Ils ne prennent pas en charge le protocole IAPP et ne permettent qu'un seul périphérique câblé, ou fournissent un mécanisme de traduction d'adresses MAC, masquant tous leurs clients câblés derrière une seule adresse MAC 802.11. Ces types de périphériques nécessitent une gestion spéciale sur les trames ARP (Address Resolution Protocol) et DHCP si l'infrastructure est un WLC en raison des contrôles de sécurité et de la gestion des trames effectués sur les contrôleurs.
Point d'accès Cisco configuré en tant que « WGB universel » : Il s'agit d'un mode qui supprime le mécanisme IAPP, de sorte que le WGB peut être utilisé vers une infrastructure Cisco ou des points d'accès racine tiers. Dans ce cas, le WGB prend l'adresse de son client Ethernet, limitant le nombre de périphériques derrière lui à un.
La section suivante porte sur le scénario d'un WGB Cisco utilisé soit pour une infrastructure autonome, soit pour une infrastructure WLC.
Exemples d'utilisation WGB types :
Connexion d'une imprimante câblée au réseau
Différents déploiements de fabrication, où il n'est ni possible ni pratique d'utiliser un câble vers le périphérique filaire
Déploiements dans les véhicules, où le WGB fournit la connectivité d'une voiture, d'un train de métro, etc., à un réseau sans fil extérieur
Caméras filaires
Chaque exemple a ses propres exigences en termes :
Bande passante nécessaire pour prendre en charge l'application qui s'exécutera au-dessus de l'infrastructure sans fil
Tolérance au délai d'itinérance : combien de temps faut-il au WGB pour passer du point d'accès actuel au point d'accès suivant pendant que le périphérique se déplace ?
Tolérance de temps de transfert : combien de trames sont perdues sur chaque itinérance ?
Une imprimante ne bouge pas beaucoup, les besoins en itinérance sont donc plus faibles. Par contre, un WGB monté sur train doit être ajusté sur le composant d'itinérance afin d'assurer un comportement correct pendant qu'il se déplace.
Un flux vidéo peut nécessiter une large bande passante, de sorte qu'il nécessite des débits de données sans fil élevés. Cependant, une application de télémétrie peut ne nécessiter que quelques trames de temps en temps.
Il est important que les exigences soient correctement définies dès le début, car elles affectent non seulement la configuration du WGB, mais également la manière dont l'infrastructure sans fil doit être conçue. Par exemple, le positionnement des points d'accès, la distance, les niveaux d'alimentation, les débits activés, etc., affectent toutes les caractéristiques d'itinérance. Par conséquent, tous sont un point crucial si l'itinérance à grande vitesse est nécessaire.
En règle générale, vous devez connaître ces détails :
Quelle est la bande passante requise pour l'application ?
Quelle est la tolérance de délai d’itinérance ?
L'application peut-elle gérer correctement les déconnexions réseau ? Existe-t-il un mécanisme de sauvegarde supplémentaire ?
L'application peut-elle gérer correctement la perte de paquets ? (Même dans la meilleure conception sans fil, vous devez vous attendre à un pourcentage de perte de paquets.)
Ce document ne traite pas des détails sur la conception d'un environnement RF pour l'itinérance/extérieur à grande vitesse. Reportez-vous au guide de déploiement du maillage extérieur.
Pour un périphérique sans fil, l'itinérance est un élément essentiel de ses fonctionnalités.
En fait, l'itinérance signifie la capacité de passer d'un point d'accès à un autre, tous deux appartenant à la même infrastructure sans fil.
Comme l'itinérance nécessite un changement du point d'accès actuel au suivant, il en résulte une déconnexion ou un temps sans service. Cette déconnexion peut être faible. Par exemple, moins de 200 ms sur les déploiements vocaux ou plus, voire plus, secondes, si la sécurité requise impose une authentification complète sur chaque événement de itinérance.
L'itinérance est nécessaire pour que le périphérique puisse trouver un nouveau parent avec un signal plus performant, et qu'il puisse continuer à accéder correctement à l'infrastructure réseau. Dans le même temps, trop d'itinérance peut provoquer plusieurs déconnexions ou un temps sans service, ce qui affecte l'accès. Il est important qu'un appareil mobile, tel qu'un WGB, dispose d'un bon algorithme d'itinérance avec suffisamment de fonctionnalités de configuration pour s'adapter aux différents environnements RF et aux différents besoins en données.
Déclencheurs : Chaque implémentation de client a un ou plusieurs déclencheurs ou événements qui, lorsqu'ils sont rencontrés, entraînent le déplacement du périphérique vers un autre AP parent. Exemples: perte de balise (le périphérique n'entend plus les balises normales du point d'accès), tentatives de paquets, niveau de signal, aucune donnée reçue, trame de déauthentification reçue, faible débit de données utilisé, etc. Les déclencheurs possibles peuvent être différents de la mise en oeuvre du client à un autre parce qu'ils ne sont pas entièrement normalisés. Les périphériques plus simples peuvent avoir un jeu de déclencheurs médiocre, ce qui entraîne des erreurs (clients rémanents) ou inutiles. Le WGB prend en charge tous les éléments précédents décrits précédemment.
Heure d'analyse : Le périphérique sans fil (WGB) passe un certain temps à rechercher des parents potentiels. Cela implique normalement de passer sur différents canaux, de faire une recherche active ou d'écouter passivement les points d'accès. Comme la radio doit analyser, cela signifie que le WGB passe du temps à faire autre chose que de transmettre des données. À partir de cette période d'analyse, le WGB peut créer un ensemble valide de parents auxquels il est possible de faire appel.
Sélection parent : Après l'analyse, le WGB peut vérifier les parents potentiels, sélectionner le meilleur et déclencher le processus d'association/authentification. Parfois, le point de décision peut être de rester sur le parent actuel s'il n'y a pas un avantage significatif d'un événement d'itinérance (rappelez-vous que trop d'itinérance peut être mauvais).
Association/Authentification : Le WGB procède à l'association au nouveau point d'accès, qui couvre normalement les deux phases d'authentification et d'association 802.11, ainsi que l'achèvement de la stratégie de sécurité configurée sur le SSID (WPA 2-PSK, CCKM, None, etc.).
Restauration du transfert du trafic : Le WGB met à jour l'infrastructure réseau de ses clients filaires connus par le biais de mises à jour IAPP après l'itinérance. Après ce point, le trafic entre les clients filaires et le réseau reprend.
L'un des aspects importants de l'itinérance sur les appareils mobiles est la politique de sécurité qui sera mise en oeuvre sur l'infrastructure. Il y a plusieurs options, chacune avec des points bons/mauvais. Voici les plus importantes :
Ouvrir : en gros, aucune sécurité. C'est la politique la plus rapide et la plus simple. Cela pose le problème principal de ne pas restreindre l'accès non autorisé à l'infrastructure et de ne pas protéger contre les attaques, ce qui limite son utilisation à des scénarios très spécifiques. Par exemple, les mines où aucune attaque externe n'est possible en raison de la nature même du déploiement.
Authentification d'adresse MAC - En gros, le même niveau de sécurité que les adresses ouvertes, car l'usurpation d'adresse MAC est une attaque banale. Non recommandé en raison du temps supplémentaire nécessaire à la validation MAC, ce qui ralentit l'itinérance.
WPA2-PSK - Offre un bon niveau de cryptage (AES-CCMP), mais la sécurité de l'authentification dépend de la qualité de la clé prépartagée. Pour les mesures de sécurité, un mot de passe de 12 caractères minimum et aléatoire est recommandé. Comme pour la méthode de clé pré-partagée, comme la clé est utilisée sur plusieurs périphériques, si la clé est compromise, le mot de passe doit être modifié sur tous les équipements. La vitesse d'itinérance est acceptable, car elle est effectuée dans 6 échanges de trames, et vous pouvez calculer quelles seront les limites de temps supérieur/inférieur pour qu'elle se termine parce qu'elle n'implique aucun équipement externe (pas de serveur RADIUS, etc). En règle générale, cette méthode est la méthode préférée après avoir équilibré les problèmes et les avantages.
WPA2 avec 802.1x : améliore la méthode précédente en utilisant des informations d'identification par périphérique/utilisateur, qui peuvent être modifiées individuellement. Le principal problème est que pour l'itinérance, cette méthode ne fonctionne pas correctement lorsque le périphérique se déplace rapidement, ou que des temps d'itinérance courts sont nécessaires. En général, ceci utilise les mêmes 6 trames plus l'échange EAP qui peut être compris entre 4 et plus. Cela dépend du type EAP sélectionné et de la taille des certificats. Normalement, cela prend entre 10 et 20 trames, plus le délai supplémentaire de traitement du serveur radius.
WPA2+CCKM - Ce mécanisme offre une bonne protection, utilise 802.1x pour créer l'authentification initiale, puis effectue un échange rapide de seulement 2 trames sur chaque événement de itinérance. Cela permet un temps d'itinérance très rapide. Le problème principal est que, en cas d'échec d'une itinérance, elle revient sur 802.1x. Ensuite, recommence à utiliser CCKM après son authentification. Si l'application située au-dessus du WGB peut tolérer un temps d'itinérance occasionnel long en cas de problème, elle peut être utilisée comme la meilleure option par rapport au PSK.
Ce document ne couvre pas les technologies non recommandées qui présentent des problèmes de sécurité tels que LEAP, WPA-TKIP, WEP, etc.
Sur le WGB, il est assez simple à configurer. Vous avez besoin de la définition SSID et du chiffrement approprié sur la radio.
dot11 ssid wgbpsk vlan 32 authentication open authentication key-management wpa version 2 wpa-psk ascii YourReallySecurePSK! no ids mfp client interface Dot11Radio0 ssid wgbpsk encryption mode ciphers aes-ccm station-role workgroup-bridge
Votre nom SSID et votre clé pré-partagée doivent correspondre à votre infrastructure réseau.
Il s'appuie essentiellement sur la configuration précédente, avec l'ajout de profils EAP et de la méthode d'authentification :
dot11 ssid wlan1 authentication open eap eap authentication network-eap eap authentication key-management wpa version 2 dot1x credentials wgb dot1x eap profile eapfast no ids mfp client eap profile eapfast !--- This covers the EAP method type used on your network. method fast ! ! dot1x credentials wgb !--- This is your WGB username/password. username cisco password 7 1511021F0725 interface Dot11Radio0 encryption mode ciphers aes-ccm ssid wlan1
Une seule étape sur le WPA2 avec une seule modification mineure : utilisation de l'indicateur CCKM sur la configuration SSID. Ceci suppose que le WLAN est configuré pour CCKM uniquement côté WLC :
dot11 ssid wlan1 authentication open eap eap authentication network-eap eap authentication key-management cckm dot1x credentials wgb dot1x eap profile eapfast no ids mfp client
Une vérification rapide du WGB peut rapporter le chiffrement et la gestion des clés utilisés, par exemple, dans CCKM :
wgb-1260#sh dot11 associations al Address : 0024.97f2.75a0 Name : lap1140-etsi-1 IP Address : 192.168.40.10 Interface : Dot11Radio 0 Device : LWAPP-Parent Software Version : NONE CCX Version : 5 Client MFP : Off State : EAP-Assoc Parent : - SSID : wlan1 VLAN : 0 Hops to Infra : 0 Association Id : 1 Tunnel Address : 0.0.0.0 Key Mgmt type : CCKM Encryption : AES-CCMP Current Rate : m7.- Capability : WMM ShortHdr ShortSlot Supported Rates : 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. Voice Rates : disabled Bandwidth : 20 MHz Signal Strength : -59 dBm Connected for : 72 seconds Signal to Noise : 41 dB Activity Timeout : 8 seconds Power-save : Off Last Activity : 7 seconds ago Apsd DE AC(s) : NONE Packets Input : 12064 Packets Output : 136 Bytes Input : 2892798 Bytes Output : 19514 Duplicates Rcvd : 87 Data Retries : 8 Decrypt Failed : 0 RTS Retries : 0 MIC Failed : 0 MIC Missing : 0 Packets Redirected: 0 Redirect Filtered: 0
Sur le WGB, vous pouvez modifier plusieurs paramètres qui affectent l'algorithme d'itinérance.
Par défaut, le WGB retransmet une trame 64 fois. S'il n'est pas correctement reconnu (ACK) par un parent, il suppose que le parent n'est plus valide et lance un processus d'analyse/itinérance. Voir celle-ci comme un déclencheur d'itinérance « asynchrone » car il peut être fait à tout moment qu'une transmission échoue.
La commande permettant de configurer ceci s'insère dans l'interface dot11 et prend les options suivantes :
packet retries NUM [drop]
Num : Est compris entre 1 et 128, avec une valeur par défaut de 64. Un bon nombre pour un déclencheur d'itinérance rapide est généralement 32. Il est déconseillé d'utiliser un nombre inférieur dans la plupart des environnements RF.
déposer : S'il n'est pas présent, le WGB démarre un événement d'itinérance lorsque le nombre maximal de tentatives est atteint. Lorsqu'il est présent, le WGB ne lance pas de nouvelle itinérance et utilise d'autres déclencheurs, tels que la perte de balise et le signal.
WGB peut mettre en oeuvre une analyse proactive des signaux pour le parent actuel et lancer un nouveau processus d’itinérance lorsque le signal tombe sous un niveau prévu.
Ce processus prend deux paramètres :
Un minuteur, qui réveille le processus de vérification toutes les X secondes
Niveau RSSI, utilisé pour démarrer un processus d’itinérance si le signal actuel est inférieur.
Exemple :
in d0 mobile station period 4 threshold 75
Le temps ne doit pas être inférieur à ce que le WGB prend pour terminer un processus d'authentification afin d'empêcher une « boucle de roaming » dans certaines conditions ou d'éviter un comportement d'itinérance trop agressif. En règle générale, il faut le tester pour voir quelles sont les adaptations nécessaires à la demande.
Pour PSK, il peut être inférieur à celui des méthodes basées sur EAP (généralement 2 et 4 pour les applications très agressives).
Le niveau RSSI est exprimé sous forme d'entier positif, bien qu'il s'agisse essentiellement d'un niveau normal -dBm mesuré. Vous devez utiliser un nombre légèrement supérieur au minimum requis pour que votre débit de données fonctionne correctement. Par exemple, si le débit minimal souhaité est de 6 mbits/s, un seuil RSSI de -87 doit être suffisant. Pour un débit de 48 Mbits/s, vous avez besoin de -70 dBm, etc.
Remarque : Cette commande peut également déclencher une modification du débit de données en itinérance, ce qui est trop agressif. Il doit être utilisé avec un taux minimum pour de bons résultats.
À partir de 12.4(25d)JA, Cisco a ajouté un paramètre configurable pour contrôler quand le WGB doit déclencher un nouvel événement d'itinérance, si le débit de données actuel pour le parent est inférieur à une valeur donnée.
Ceci est utile pour s'assurer qu'une limite de vitesse inférieure souhaitée est maintenue afin de prendre en charge les applications vidéo ou voix.
Avant que cette commande ne soit disponible, le WGB déclenchait fréquemment une itinérance lorsque le débit s'est avéré inférieur au temps précédent. Fondamentalement à l'heure X+1, si le débit était inférieur à l'heure X précédente, le WGB a commencé un processus d'itinérance. Dans les journaux, les messages suivants s'affichent :
*Mar 1 00:36:43.490: %DOT11-4-UPLINK_DOWN: Interface Dot11Radio1, parent lost: Had to lower data rate
C'est trop agressif, et normalement, la seule solution était de configurer un débit de données unique à la fois dans WGB et sur les AP parents.
Maintenant, la méthode recommandée est de toujours configurer cette commande, chaque fois qu'une commande période de station mobile est utilisée :
in d0 mobile station minimum-rate 2.0
Dans ce cas, le nouveau processus d'itinérance n'est déclenché que si le débit actuel est inférieur à la valeur configurée. Cela réduit les déplacements inutiles et permet de conserver une valeur de débit attendue.
Note : Le message « Devez réduire le débit de données » est attendu même avec cette configuration, juste que maintenant il ne doit être vu que si WGB était TX à une vitesse inférieure à celle configurée, lorsque le temps de vérification de la période de la station mobile a été déclenché.
Le WGB analyse tous les « canaux de pays » lors d'un événement itinérant. Cela signifie que, selon le domaine radio, vous pouvez scanner les canaux 1 à 11 sur une bande de 2,4 Ghz, ou 1 à 13.
Chaque canal numérisé prend un certain temps. Sur la norme 802.11bg, cela fait environ 10 à 13 ms. Sur la norme 802.11a, elle peut atteindre 150 ms si le canal est activé DFS (donc pas de recherche, il suffit de faire une analyse passive là-bas).
Une bonne optimisation consiste à limiter les canaux analysés à utiliser uniquement ceux en service par l'infrastructure. Ceci est particulièrement important sur la norme 802.11a, car la liste des canaux est volumineuse et le temps par canal peut être long si DFS est utilisé.
Trois points doivent être pris en compte lors de la conception d'un plan de canaux pour WGB/Roaming :
Pour la bande 2,4 GHz, essayez de rester sur 1/6/11 pour minimiser les interférences de canal latéral. Tout autre plan de canal avec 4, etc., tend à être difficile à concevoir correctement du point de vue RF, sans augmenter les interférences.
L'utilisation d'une configuration à canal unique pour tous les points d'accès est une bonne idée du point de vue de l'analyse. Cela n'a de sens que si le nombre total de clients à prendre en charge est très faible et qu'il n'y a pas de besoins élevés en bande passante. Cela élimine l'heure de changement radio de l'heure d'analyse. N'oubliez pas que peu d'environnements peuvent bénéficier de cette option, donc utilisez avec soin.
Pour la bande 5,0 GHz, si la réglementation locale le permet, l'utilisation de canaux internes non DFS(36 à 48) permet une analyse plus rapide, car WGB peut les sonder activement, au lieu de faire de l'écoute passive plus longtemps.
Le plan de canal utilisé pour votre déploiement peut nécessiter d'autres exigences. Utilisez les recommandations générales de conception RF.
Afin de configurer la liste des canaux d'analyse :
in d0 mobile station scan 1 6 11
Remarque : la station mobile apparaît uniquement lors de l'utilisation du rôle WGB sur la radio.
Remarque : assurez-vous que votre liste d'analyse WGB correspond à votre liste de canaux d'infrastructure. Si ce n'est pas le cas, le WGB ne trouvera pas vos points d'accès disponibles.
À partir de 12.4(25a)JA, il existe plusieurs nouvelles commandes pour optimiser le compteur de récupération lorsqu'un problème est détecté, qui ne sont disponibles que lorsque l'AP est en mode WGB.
wgb-1260(config)#workgroup-bridge timeouts ? assoc-response Association Response time-out value auth-response Authentication Response time-out value client-add client-add time-out value eap-timeout EAP Timeout value iapp-refresh IAPP Refresh time-out value
Dans le cas d'assoc-response, auth-response, client-add, ceux-ci indiquent combien de temps le WGB attendra que le point d'accès parent réponde, avant de considérer le point d'accès comme mort et d'essayer candidat suivant. Les valeurs par défaut sont de 5 secondes, ce qui est trop long pour certaines applications. Le compteur minimal est de 800 ms et est recommandé pour la plupart des applications mobiles.
Dans eap-timeout, le WGB définit un délai d'attente maximal, jusqu'à ce que le processus d'authentification EAP complet soit terminé. Cela fonctionne du point de vue du demandeur EAP afin de redémarrer le processus si l'authentificateur EAP ne répond pas. La valeur par défaut est de 60 secondes. Veillez à ne jamais configurer une valeur qui peut être inférieure au temps réel nécessaire pour terminer une authentification 802.1x complète. Normalement, la définition de 2 à 4 secondes est correcte pour la plupart des déploiements.
Pour l'actualisation des applications, le WGB génère par défaut une mise à jour en bloc IAPP au point d'accès parent après l'itinérance afin d'informer les clients filaires connus. Il y a une deuxième retransmission après association environ 10 secondes plus tard. Ce minuteur permet de faire une « tentative rapide » du bloc IAPP après l'association afin de surmonter la possibilité que la première mise à jour IAPP ait été perdue en raison de RF, ou des clés de chiffrement non encore installées sur le point d'accès parent. Pour les scénarios d'itinérance rapide, 100 ms peuvent être utilisés. Cependant, assurez-vous qu'un grand nombre de WGB est utilisé. Cela augmente considérablement le nombre total d'IAPP envoyés à l'infrastructure après chaque itinérance.
Exemple pour les valeurs agressives :
workgroup-bridge timeouts eap-timeout 4 workgroup-bridge timeouts iapp-refresh 100 workgroup-bridge timeouts auth-response 800 workgroup-bridge timeouts assoc-response 800 workgroup-bridge timeouts client-add 800
Ils ont été testés avec succès sur des scénarios de déploiement WGB mobiles.
D'autres modifications mineures doivent être prises en compte pour les scénarios de déploiement WGB :
Réduire les tentatives rts - les tentatives rts 32. Cela permet d'économiser du temps RF sur les scénarios agressifs. Normalement, cela n'est pas nécessaire.
Type d'antenne: Si vous utilisez une seule antenne (sans diversité), vous devez configurer la radio pour améliorer les performances générales :
antenna transmit right-a antenna receive right-a
La diversité des antennes est souhaitable, mais pas toujours possible lors de l'installation physique des antennes sur le véhicule. Une sélection adéquate de l'antenne est essentielle pour l'itinérance. Aussi peu que 2 dB peut être une énorme différence sur les temps d'itinérance généraux moyens.
Afin d'économiser quelques millisecondes, réduisez le niveau de journalisation de la console aux erreurs uniquement : consigner les erreurs de console. Ne le désactivez pas complètement car il peut affecter négativement les performances d'itinérance dans certaines conditions.
Idéalement, utilisez telnet ou ssh du côté Ethernet pour collecter les débogages ou les journaux. Cela a un impact beaucoup plus faible sur les performances que la journalisation des débogages sur la console : débogage de logging monitor.
La commande permettant de comprendre ce qui se passe pour le point de vue d'itinérance WGB est debug dot11 dot11 0 trace print uplink. Cela a un faible impact sur le CPU, mais n'activez pas d'autres options de débogage sauf instructions car chacune d'elles peut incrémenter le temps d'itinérance total.
Essayez d'utiliser SNTP lorsque c'est possible. Cela permet de synchroniser l'heure WGB, ce qui est extrêmement utile pour le dépannage.
Les MFP peuvent être utiles du point de vue de la sécurité. Cependant, un inconvénient est que dans les scénarios d'échec de l'itinérance, le WGB n'accepte pas les trames de désauthentification du parent de l'AP pour déclencher une nouvelle itinérance si la clé de chiffrement entre les deux a mal tourné pour une raison quelconque.
Dans ces rares scénarios de défaillance, le WGB peut prendre jusqu'à 5 secondes pour déclencher une nouvelle analyse, si le parent actuel peut être entendu avec un bon signal RF. Il existe un mécanisme de détection globale que WGB peut déclencher si aucune trame de données valide n'est reçue au cours de cette période.
Par défaut, le WGB tente d'utiliser la MFP du client si le SSID utilise WPA2 AES.
Il est recommandé de désactiver la MFP du client si des temps de récupération rapides sont nécessaires (WGB pour réagir aux trames de mort non protégées). Il s'agit d'un compromis entre les besoins de sécurité et les temps de récupération rapides. La décision dépend de ce qui est le plus important pour le scénario de déploiement.
dot11 ssid wgbpsk no ids mfp client
Reportez-vous à la section Synchroniser les horloges du demandeur IOS et le paramètre d'économie de temps sur la mémoire NVRAM des Notes de version pour les points d'accès et ponts Cisco Aironet pour Cisco IOS version 12.4(21a)JY.
N'oubliez pas que si vous utilisez uWGB, le uWGB n'aura peut-être jamais la chance d'effectuer une synchronisation sntp car il est généralement associé à l'adresse MAC jointe et le uWGB BVI n'a pas d'accès réseau. Par conséquent, dans le cas d'un uWGB, il est recommandé d'obtenir une bonne synchronisation d'horloge dans la mémoire NVRAM au minimum lors du déploiement. Si le périphérique connecté a la capacité d'être une source NTP (ainsi qu'un client mis à jour via sa connexion uWGB), il est alors possible d'envisager d'avoir la synchronisation uWGB sntp à partir de celle-ci comme point de réflexion NTP efficace.
no service pad service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname wgb-1260 ! logging rate-limit console 9 logging console errors ! clock timezone CET 1 no ip domain lookup ! ! dot11 syslog ! ! dot11 ssid wgbpsk vlan 32 authentication open authentication key-management wpa version 2 wpa-psk ascii 7 060506324F41584B56 no ids mfp client ! ! ! ! ! ! username Cisco password 7 13261E010803 ! ! bridge irb ! ! interface Dot11Radio0 no ip address no ip route-cache ! encryption mode ciphers aes-ccm ! ssid wgbpsk ! antenna transmit right-a antenna receive right-a packet retries 32 station-role workgroup-bridge rts retries 32 mobile station scan 2412 2437 2462 mobile station minimum-rate 6.0 mobile station period 3 threshold 70 bridge-group 1 ! interface GigabitEthernet0 no ip address no ip route-cache duplex auto speed auto no keepalive bridge-group 1 ! interface BVI1 ip address 192.168.32.67 255.255.255.0 no ip route-cache ! ip default-gateway 192.168.32.1 no ip http server no ip http secure-server bridge 1 route ip sntp server 192.168.32.1 clock save interval 1 workgroup-bridge timeouts eap-timeout 4 workgroup-bridge timeouts iapp-refresh 100 workgroup-bridge timeouts auth-response 800 workgroup-bridge timeouts assoc-response 800 workgroup-bridge timeouts client-add 800
En cas de problème, il est important de capturer la sortie de la commande debug dot11 dot11 0 trace print uplink comme première étape. Ceci fournit une bonne vue de ce qui se passe avec le processus d'itinérance.
Voici un exemple de parent actuel en tant que candidat :
Sep 27 11:42:38.797: %DOT11-4-UPLINK_DOWN: Interface Dot11Radio0, parent lost: Signal strength too low Sep 27 11:42:38.797: CDD051F1-0 Uplink: Lost AP, Signal strength too low
Ceci est le déclencheur pour le signal faible atteint. Cela dépend de la commande Y threshold X de la station mobile. Le premier message est toujours envoyé à la console, le second fait partie des traces de débogage de liaison ascendante. Ce n'est pas un problème, mais une partie du processus WGB normal.
Sep 27 11:42:38.798: CDD052C7-0 Uplink: Wait for driver to stop
Le processus de liaison ascendante force une purge de file d'attente radio avant de commencer une analyse de canal. Cette étape peut prendre de quelques millisecondes à plusieurs secondes selon l'utilisation du canal et la profondeur de la file d'attente. Les trames de données ne sont pas temporisées. Les trames vocales font l’objet d’une comparaison temporelle, et doivent donc être abandonnées plus rapidement. Un certain retard peut être observé dans les environnements bruyants.
Sep 27 11:42:38.798: CDD05371-0 Uplink: Enabling active scan Sep 27 11:42:38.799: CDD05386-0 Uplink: Scanning
Il s'agit de l'analyse de canal en cours. Il place la radio environ 10 à 13 ms par canal configuré.
Sep 27 11:42:38.802: CDD064CD-0 Uplink: Rcvd response from 0021.d835.ade0 channel 1 3695
Il s'agit de la liste des réponses de sonde reçues. Le premier numéro est le canal, le second est la microseconde prise pour le recevoir.
Sep 27 11:42:38.808: CDD078F1-0 Uplink: Compare1 0021.d835.ade0 - Rssi 58dBm, Hops 0, Count 0, load 0 Sep 27 11:42:38.809: CDD07929-0 Uplink: Compare2 0021.d835.cce0 - Rssi 46dBm, Hops 0, Count 0, load 0
Comparaison réelle effectuée dans ces détails :
Sep 27 11:42:38.809: CDD07BDB-0 Uplink: Same as previous, send null data packet
Sélection des parents
Sep 27 11:42:38.809: CDD07BF7-0 Uplink: Done Sep 27 11:42:38.808: %DOT11-4-UPLINK_ESTABLISHED: Interface Dot11Radio0, Associated To AP AP1 0021.d835.ade0 [None WPAv2 PSK]Roaming completed.
C'est le point où l'itinérance est « terminée ». Le trafic reprend dès que les trames IAPP sont traitées par le parent.
Informations de comparaison parente
Sep 27 14:16:47.590: F515B1FF-0 Uplink: Compare1 0021.d835.7620 - Rssi 60dBm, Hops 0, Count 0, load 3 Sep 27 14:16:47.591: F515B238-0 Uplink: Compare2 0021.d835.e8b0 - Rssi 58dBm, Hops 0, Count -1, load 0
La comparaison1 imprime le nombre d'associations réel -1 (WGB lui-même n'est pas pris dans le nombre) si le point d'accès ” actuel “ est toujours le seul WGB est associé, puis sauts réels et charge.
La comparaison2 imprime les différences. C'est pourquoi il est possible de voir un nombre négatif. Si le nombre de tests est supérieur au nombre actuel, vous obtenez un résultat négatif.
En fonction du nombre d'associations, de la charge, de la différence de signal, de la valeur du seuil mobile, le WGB peut sélectionner ou non un nouveau parent.
La comparaison se fait toujours entre deux points d'accès, avec le point d'accès sélectionné remplaçant le courant pour l'itération suivante. Par conséquent, certaines des décisions peuvent être dues à RSSI sur une boucle, ou à d'autres facteurs sur le prochain test.