Les points d'accès légers (LAP) peuvent détecter l'adresse IP de gestion du contrôleur par le biais de la technique OTAP (Over-the-Air Provisioning). Cette fonctionnalité est prise en charge par les contrôleurs des gammes Cisco 5500 et 4400. Ce document explique certains détails de ce processus.
Cisco recommande que vous ayez des connaissances de base sur LWAPP/CAPWAP.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Au cours du processus de démarrage du LAP, le LAP utilise différents mécanismes afin de découvrir les contrôleurs qu'il peut joindre. Le LAP conserve chaque contrôleur qui adresse IP qu'il a appris à travers les différentes méthodes dans différentes listes afin de refléter comment le LAP a appris à leur sujet. Par exemple, le LAP peut apprendre les adresses IP de gestion de plusieurs contrôleurs via l'entrée DNS pour CISCO-LWAPP-CONTROLLER.localdomain, option DHCP 43, via des diffusions sur le sous-réseau local, la découverte d'adresses IP de contrôleur stocké localement et via OTAP. Une fois que le point d'accès a terminé les étapes de détection de WLC LWAPP, il choisit un WLC dans la liste des WLC candidats et envoie à ce WLC une demande de jointure LWAPP.
L'enregistrement d'un point d'accès léger (LAP) à un contrôleur de réseau local sans fil (WLC) discute des différentes méthodes que le LAP utilise pour détecter les contrôleurs.
Ce document fournit des informations sur le processus OTAP.
La fonctionnalité OTAP est activée sur l'interface graphique du contrôleur à partir de la page General du contrôleur ou via l'interface de ligne de commande avec la commande config network otap-mode {enable | disable}.
Remarque : cette fonctionnalité est désactivée par défaut et doit le rester lorsque tous les points d'accès sont installés.
Le processus OTAP commence lorsque le LAP active momentanément les interfaces radio avant la phase de découverte et analyse les différents canaux RF qui écoutent les paquets voisins RRM. Il est possible que le LAP reçoive ou ne reçoive pas un paquet voisin RRM au premier démarrage. Cela dépend de :
Combien de LAP se trouvent dans la zone (plus le nombre de LAP dans la zone est élevé, plus le LAP risque de recevoir un paquet voisin RRM)
Combien de canaux sont utilisés par Auto-RF (plus il y a de canaux, moins le LAP est susceptible de recevoir un paquet voisin RRM)
La durée pendant laquelle le LAP analyse les canaux RF pendant le processus OTAP (les temps d'analyse typiques avant que le point d'accès ne passe en phase de découverte sont de 18 à 35 secondes pour tous les canaux)
Lorsque le LAP passe à la phase de détection, il envoie des requêtes de détection via son interface principale à chacun des contrôleurs des listes en fonction de la manière dont il en a été informé. Pour les contrôleurs qui sont appris via OTAP, le LAP envoie au contrôleur un paquet de requête de détection avec le bit OTAP défini. Cela indique au contrôleur que le point d'accès a appris son adresse IP de gestion via OTAP. Les autres méthodes de détection, telles que DNS ou DHCP option 43, ne sont pas différenciées dans le paquet de requête de détection car elles sont apprises via des connexions câblées.
Ce contrôleur peut rejeter les demandes de détection pour les raisons suivantes :
Le bit OTAP est défini dans le paquet de demande de détection et OTAP est désactivé sur le contrôleur.
Le paquet de demande de détection est trop volumineux.
Le paquet de demande de détection n'est pas reçu sur l'interface de gestion.
Les LAP prennent en charge le protocole OTAP uniquement lorsqu'ils disposent d'une image Cisco IOS LWAPP complète. OTAP n'est pas pris en charge par l'image Cisco IOS de récupération LWAPP. L'image de récupération LWAPP est livrée en usine et chargée par l'outil de mise à niveau. Les images de récupération (cXXXX-rcvk9w8-mx), livrées avec de nouveaux LAP prêts à l'emploi, ne contiennent aucun micrologiciel radio et n'activent aucune interface radio pendant le processus de démarrage. Par conséquent, l'OTAP ne fonctionne pas avec les LAP prêts à l'emploi. Les exceptions sont les points d'accès 1510 et 1520 prêts à l'emploi, qui ont une image complète installée en mémoire flash.
Remarque : OTAP activé sur le contrôleur indique au contrôleur s'il doit répondre ou non aux demandes de détection avec le bit OTAP défini. Il n'empêche pas les LAP déjà joints au contrôleur de la transmission de l'adresse IP de gestion du contrôleur dans le clear dans les paquets voisins RRM. Ainsi, si vous désactivez le protocole OTAP sur le contrôleur, cela ne le désactive pas sur le point d'accès. Impossible de désactiver le protocole OTAP sur le point d'accès.
Le protocole OTAP utilise des paquets voisins RRM. Cette section fournit un bref aperçu des paquets voisins RRM. Les LAP déjà connectés à un contrôleur transmettent des paquets voisins RRM à l'adresse de multidiffusion RRM 01:0b:85:00:00:00. Chaque LAP doit transmettre un paquet de détection de voisin toutes les 60 secondes sur chacun des canaux RF automatiques configurés pour 802.11b/g et 802.11a. Les paquets voisins RRM sont transmis sans cryptage similaire aux autres paquets de gestion RF, tels que les requêtes et les réponses de sonde. Les paquets voisins RRM contiennent des messages de contrôle de voisinage. Consultez la section Paquet voisin RRM pour 802.11a pour plus d'informations. Chaque message de contrôle de voisin se compose des éléments suivants :
ID radio
ID groupe
Adresse IP de gestion (du contrôleur)
Nombre de canaux
Modèle d'antenne (omnidirectionnel, gauche, diversité, droite)
Intervalle De Mesure
Key (Clé)
Canaux
Alimentation
Les LAP encapsulent et transfèrent au contrôleur tous les paquets voisins RRM qu'ils reçoivent. Cela permet au contrôleur de former des groupes RF pour le réglage de la puissance et des canaux parmi les LAP qui peuvent se voir. Les LAP qui démarrent peuvent utiliser ces paquets voisins RRM afin de découvrir le contrôleur auquel les LAP voisins sont déjà joints.
Voici un exemple de paquet voisin RRM pour 802.11a :
No. Time Source Destination 8313 23:39:20.169855117 00:14:1b:5a:40:10 01:0b:85:00:00:00 Protocol Info LLC U, func=UI; SNAP, OUI 0x000B85 (Unknown), PID 0xCCCD Frame 8313 (80 bytes on wire, 80 bytes captured) [Protocols in frame: wlan:llc:data] IEEE 802.11 Data Rate: 6.0 Mb/s Channel: 60 Signal Strength: 0% Type/Subtype: Data (32) Frame Control: 0x0308 (Normal) Version: 0 Type: Data frame (2) Subtype: 0 Flags: 0x3 DS status: Frame part of WDS from one AP to another AP (To DS: 1 From DS: 1) (0x03) .... .0.. = More Fragments: This is the last fragment .... 0... = Retry: Frame is not being retransmitted ...0 .... = PWR MGT: STA will stay up ..0. .... = More Data: No data buffered .0.. .... = Protected flag: Data is not protected 0... .... = Order flag: Not strictly ordered Duration: 0 Receiver address: 01:0b:85:00:00:00 (01:0b:85:00:00:00) Transmitter address: 00:14:1b:5a:40:1f (00:14:1b:5a:40:1f) Destination address: 01:0b:85:00:00:00 (01:0b:85:00:00:00) Fragment number: 0 Sequence number: 487 Source address: 00:14:1b:5a:40:10 (00:14:1b:5a:40:10) Frame check sequence: 0x84bab9b3 [correct] Logical-Link Control DSAP: SNAP (0xaa) SSAP: SNAP (0xaa) Control field: U, func=UI (0x03) 000. 00.. = Command: Unnumbered Information (0x00) .... ..11 = Frame type: Unnumbered frame (0x03) Organization Code: Airespace (0x000b85) Protocol ID: 0xcccd Data (38 bytes) 0000 08 03 00 00 01 0b 85 00 00 00 00 14 1b 5a 40 1f .............Z@. 0010 01 0b 85 00 00 00 70 1e 00 14 1b 5a 40 10 aa aa ......p....Z@... 0020 03 00 0b 85 cc cd 01 1b 00 1a 6c 91 80 80 00 04 ..........l..... 0030 0a 01 00 0f 3c 01 01 3c 04 ff ff 00 4e 40 fd ec ....<..<....N@.. 0040 a7 4a f4 c4 d3 7b 19 be 10 92 50 91 84 ba b9 b3 .J...{....P.....
L'adresse de multidiffusion du voisin RRM et l'adresse IP de gestion du contrôleur sont mises en surbrillance.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
14-Jan-2008 |
Première publication |