un contrôleur LAN sans-fil Enregistrement d'un AP léger sur un contrôleur LAN sans-fil (WLC) ccnp_cch ccnp_cch

Sommaire • Introduction - Prérequis - Composants utilisés • Rappel • Enregistrement d'un AP léger (LAP) avec le WLC - Algorithme LWAPP de couche 2 de découverte du WLC - Algorithme LWAPP de couche 3 de découverte du WLC - Processus de sélection du WLC • Résolution de problèmes - Secours d'AP entre différents groupes de mobilité ccnp_cch

Introduction Rappel ccnp_cch Dans une architecture sans-fil unifiée Cisco, les points d'accès (AP) sont dits "légers". Cela signifie qu'ils ne peuvent pas fonctionner sans un contrôleur LAN Sans-fil (WLC). Les points d'accès légers (LAP) doivent d'abord découvrir les WLCs et s'enregistrer avec eux avant que les LAPs servent les clients sans-fil. Ce document explique les différentes méthodes que les LAPs utilisent pour découvrir les WLCs. Ce document explique aussi le processus d'enregistrement qui se produit entre le LAP et le WLC après la phase de découverte. Prérequis Assurez-vous d'avoir les prérequis suivants avant de tenter cette configuration:  Connaissance de LWAPP (Lightweight Access Point Protocol)  Connaissance de la configuration des paramètres de base du WLC. Si vous êtes un nouvel utilisateur et que vous n'avez pas configuré un WLC pour un fonctionnement de base, référez-vous à "Configuration Wizard on the CLI Section of Cisco Wireless LAN Controller Configuration Guide Release 4.1".  Connaissance de la configuration d'un serveur DHCP Windows 2000/2003 et d'un serveur DNS (Domain Name System). Composants utilisés Les informations présentées dans ce document sont basées sur les configurations lo- gicielles et matérielles suivantes:  Cisco 4400 Series WLC qui opèrent avec un firmware 4.0.217.0  Cisco 1000 Series LAPs  Windows 2000 DHCP Server  Windows 2000 DNS Server Rappel Les WLCs et les LAPs font partie de l'architecture Cisco Unified Wireless Network. L'ar- chitecture Cisco Unified Wireless Network centralise la configuration et le contrôle de WLAN sur le WLC. Les LAPs ne peuvent pas opérer indépendamment des WLCs. Le WLC gère les configurations et le firmware des LAPs. Les LAPS n'ont pas besoin de con- figuration individuelle. Pour que le WLC soit capable de gérer le LAP, le LAP doit découvrir le contrôleur et s'enregistrer avec le WLC. Après que le LAP se soit enregistré avec le WLC, les messages LWAPP sont échangés et l'AP initie le téléchargement d'un firmware à partir du WLC (s'il y a une différence de version entre l'AP et le WLC). Si le firmware présent dans l'AP n'est pas le même que celui du WLC, l'AP télécharge le firmware pour rester en synchro- nisme avec le WLC. Le mécanisme de téléchargement du firmware utilise LWAPP. Le WLC ensuite provisionne le LAP avec les configurations qui sont spécifiques aux WLANs pour que le LAP puisse accepter les associations des clients. Ces configurations spéci- fiques WLAN comprennent:  Service Set Identifier - SSID ccnp_cch

Enregistrement d'un AP léger (LAP) avec le WLC  Paramètres de sécurité  Paramètres 802.11 tels que: - Débit des données - Canaux radio - Niveaux de puissance Il y a différentes méthodes utilisées par un LAP pour découvrir le WLC. Ce document traite les différentes méthodes que le LAP peut utiliser pour s'enregistrer avec le WLC. Mais ce document traite d'abord la séquence d'événements qui se produisent quand un LAP s'enregistre avec le WLC. Note: L'interface "Management" est l'interface par défaut pour une administration dans la bande du WLC et de la connectivité avec des services d'entreprise tels que les ser- veurs AAA. L'interface d'administration est également utilisée pour des communications de couche 2 entre le WLC et les points d'accès. L'interface d'administration est la seule adresse IP d'interface dans la bande réellement accessible sur le WLC. Note: Un WLC a plusieurs interfaces AP Manager qui sont utilisées pour toutes les com- munications de couche 3 entre le WLC et les points d'accès légers après que le point d'accès ait découvert le contrôleur. L'adresse IP de LAP Manager est utilisée comme source du tunnel des paquets LWAPP du WLC vers les points d'accès et comme desti- nataire pour les paquets LWAPP des points d'accès vers le WLC. L'AP Manager doit avoir une adresse IP unique. Usuellement celle-ci est configurée sur le même réseau que l'interface d'administration, mais ce n'est pas une exigence. Une adresse AP Mana- ger n'est pas accessible depuis l'extérieur du WLC. Référez-vous à "Configuring Ports and Interface Section of Wireless LAN Controller Configuration Guide" pour plus d'in- formations. Enregistrement d'un AP léger (LAP) avec le WLC Cette séquence d'événements doit se produire pour qu'un LAP s'enregistre sur un WLC. 1. Le LAP génère une requête de découverte de DHCP pour obtenir une adresse IP sauf si celui-ci avait une adresse IP statique déjà configurée. 2. Le LAP transmet des messages de requête de découverte LWAPP vers les WLCs. 3. Tout WLC qui reçoit une requête de découverte LWAPP répond avec un message de réponse de découverte LWAPP. 4. A partir du message de réponse de découverte LWAPP que le LAP reçoit, le LAP sé- lectionne un WLC à joindre. 5. Le LAP transmet ensuite une requête LWAPP "Join" vers le WLC et attend une réponse LWAPP "Join". 6. Le WLC valide le LAP et transmet la réponse LWAPP "Join" au LAP. 7. Le LAP valide le WLC ce qui termine le processus 'Discovery" et "Join". Le processus LWAPP "Join" comprend une authentification mutuelle et la dérivation de la clé de cryptage qui est utilisée pour sécuriser le processus "Join" et les futurs messages de contrôle LWAPP. 8. Le LAP s'enregistre avec le contrôleur. ccnp_cch

Le premier problème auquel le LAP doit faire face est comment déterminer où transmet- tre les requêtes LWAPP "discovery" (Etape 2). Le LAP utilise une procédure de recherche et un algorithme de découverte pour déterminer la liste des WLCs vers lesquels le LAP peut transmettre les messages de requête de découverte. Cette procédure décrit le processus de recherche: 1. Le LAP génère une requête de découverte de DHCP pour obtenir une adresse IP sauf si celui-ci avait une adresse IP statique déjà configurée. 2. Si le mode LWAPP couche 2 est supporté sur le LAP, le LAP diffuse un message LWAPP "discovery" dans une trame LWAPP couche 2. Tout WLC qui est connecté au réseau et qui est configuré pour le mode LWAPP couche répond avec une message de réponse "discovery" de couche 2. S le LAP ne supporte pas le mode LWAPP couche 2 ou si le WLC ou le LAP ne reçoit pas un message de réponse LWAPP "discovery" au message de diffusion LWAPP "discovery" de couche 2, le LAP passe à l'étape 3. 3. Si l'étape 1 échoue ou si le LAP ou le WLC ne supporte pas le mode LWAPP couche 2, le LAP tente une découverte LWAPP de couche 3 du WLC. Voir Algorithme de découverte LWAPP de couche 3 de WLC dans ce document. 4. Si l'étape 3 échoue, le LAP se réinitialise et passe à l'étape 1. Note: Si le LAP a une adresse IP statique affectée et ne peut pas joindre le WLC, celui-ci repasse en mode DHCP. Algorithme LWAPP de couche 2 de découverte du WLC La communication LWAPP entre le LAP et le WLC peut être faite nativement avec des trames Ethernet de couche 2. Cela est connu comme le mode LWAPP de couche 2. Bien que défini dans un RFC draft, le mode LWAPP de couche 2 est considéré comme déprécié dans l'implémentation Cisco. Seuls les LAPs Cisco Série 1000 supportent le mode LWAPP de couche 2. Le mode LWAPP couche 2 n'est également pas supporté sur les WLCs série 2000. Ces WLCs supportent uniquement le mode LWAPP couche 3. C'est la première méthode qu'un LAP utilise pour découvrir un WLC. Les LAPs qui sup- portent le mode LWAPP couche 2 diffusent un message de requête de découverte LWAPP dans une trame LWAPP couche 2. S'il y a un WLC dans le réseau configuré pour le mode LWAPP couche 2, le contrôleur répond avec un message de réponse de découverte? Le LAP passe ensuite en phase "Join" (voir étape 5 dans la section Enre- gistrement d'un AP léger avec le WLC) La sortie de la commande debug lwapp events enable montre la séquence d'événè- ments qui se produit quand un LAP utilisant le mode LWAPP couche 2 s'enregistre avec le WLC. Thu Sep 27 00:24:25 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:51:5a:e0 to ff:ff:ff:ff:ff:ff on port '2' Thu Sep 27 00:24:25 2007: 00:0b:85:51:5a:e0 Successful transmission of LWAPP Discovery−Response to AP 00:0b:85:51:5a:e0 on Port 2 Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Received LWAPP JOIN REQUEST from AP 00:0b:85:51:5a:e0 to 00:0b:85:48:53:c0 on port '2' Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 AP ap:51:5a:e0: txNonce 00:0B:85:48:53:C0 rxNonce 00:0B:85:51:5A:E0 ccnp_cch

Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 LWAPP Join−Request MTU path from AP 00:0b:85:51:5a:e0 is 1500, remote debug mode is 0 Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Successfully added NPU Entry for AP 00:0b:85:51:5a:e0 (index 48)Switch IP: 0.0.0.0, Switch Port: 0, intIfNum 2, vlanId 0AP IP: 0.0.0.0, AP Port: 0, next hop MAC: 00:0b:85:51:5a:e0 Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Successfully transmission of LWAPP Join−Reply to AP 00:0b:85:51:5a:e0 Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Register LWAPP event for AP 00:0b:85:51:5a:e0 slot 0 AP 00:0b:85:51:5a:e0 slot 1 Algorithme LWAPP de couche 3 de découverte du WLC Les LAPs utilisent l'algorithme de découverte de couche 3 si la méthode de découverte de couche 2 n'est pas supportée ou si la méthode de découverte de couche 2 échoue. L'algorithme de découverte de couche 3 utilise différentes options pour tenter de dé- couvrir les WLCs. L'algorithme de découverte de WLC LWAPP de couche 3 est utilisé pour construire une liste de contrôleurs. Une fois que la liste de contrôleurs a été construite, l'AP sélectionne un WLC et tente de joindre le WLC. L'algorithme de découverte de WLC LWAPP de couche 3 boucle jusqu'à ce qu'au moins un WLC soit trouvé et joint. Note: Pendant la découverte WLC LWAPP de couche 3, l'AP exécute toutes les étapes 1 à 5 de cette section pour établir une liste de WLCs candidats. Après que l'AP ait termi- né les étapes de découverte WLC LWAPP de couche 3, l'AP sélectionne un WLC dans la liste des WLCs candidats sur la base de certains critères et ensuite transmet une requête LWAPP "Join" à ce WLC. Les exemples de scénario expliqués dans cette section sont indépendants les uns des autres et sont fournis uniquement pour permettre une compréhension du fonctionne- ment de chaque étape du processus de découverte. Le LAP utilise toutes les étapes de découverte pour trouver une liste de WLCs candidats avant de sélectionner un WLC à joindre. Cette procédure décrit les étapes exécutées par l'algorithme de découverte de couche 3 pour tenter de découvrir les WLCs. 1. Après que le LAP ait obtenu une adresse IP du serveur DHCP, le LAP commence son processus de découverte. a. Le LAP diffuse un message de découverte de WLC LWAPP de couche 3 sur le sous-réseau IP local. Tout WLC qui est configuré pour le mode LWAPP de couche 3 et qui est connecté au même sous-réseau local reçoit le message de découverte LWAPP de couche 3. b. Chaque WLC qui reçoit le message de découverte LWAPP de couche 3 répond avec un message unicast de réponse de découverte LWAPP vers le LAP. ccnp_cch

Serveur DHCP Réseau 172.16.1.0/24 Contrôleur WLAN Reqête de découverte LWAPP de couche 3 Réponse de découverte WLAPP de couche 3 vers le LAP LAP (Light weight AP) Voici un exemple. Supposons que vous avez un WLC et un LAP dans le même réseau (172.16.1.0/24). Vous avez également un serveur DHCP dans ce sous-réseau. Quand le LAP est mis sous-tension celui-ci transmet une requête DHCP avec l'espoir qu'un serveur DHCP va lui fournir une adresse IP. Après que le LAP ait obtenu une adresse IP du serveur DHCP, le LAP diffuse un message de découverte WLC LWAPP de couche 3 sur le réseau local. Comme le WLC est sur le même réseau local, celui-ci reçoit la re- quête de découverte LWAPP venant du LAP et répond avec une réponse de découverte LWAPP de couche 3. Cet exemple est une sortie de la commande debug lwapp events enable qui montre ce processus de découverte. (Cisco Controller) >debug lwapp events enable Mon May 22 12:00:21 2006: Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:5b:fb:d0 to ff:ff:ff:ff:ff:ff on port '1' Mon May 22 12:00:21 2006: Successful transmission of LWAPP Discovery−Response to AP 00:0b:85:5b:fb:d0 on Port 1 La sortie de la commande debug lwapp packet enable pour la diffusion de découverte sur le réseau ressemble à cela: (Cisco Controller) >debug lwapp packet enable Tue May 23 12:37:50 2006: Start of Packet Tue May 23 12:37:50 2006: Ethernet Source MAC (LRAD): 00:0B:85:51:5A:E0 Tue May 23 12:37:50 2006: Msg Type : Tue May 23 12:37:50 2006: DISCOVERY_REQUEST Tue May 23 12:37:50 2006: Msg Length : 31 Tue May 23 12:37:50 2006: Msg SeqNum : 0 Tue May 23 12:37:50 2006: IE : UNKNOWN IE 58 Tue May 23 12:37:50 2006: IE Length : 1 Tue May 23 12:37:50 2006: Decode routine not available, Printing Hex Dump Tue May 23 12:37:50 2006: 00000000: 00 ccnp_cch

Notez les lignes en caractères gras Notez les lignes en caractères gras. La valeur du paramètre IE 58 indique le type de message de découverte. 0 − broadcast 1 − configured 2 − OTAP 3 − dhcp server 4 − dns Comme c'est une diffusion sur le réseau local, le paramètre IE 58 a la valeur 0 dans cette sortie de la commande debug lwapp packet enable. 2. Les LAPs utilisent également la fonctionnalité OTAP (Over-The-Air Provisionning) pour découvrir le WLC. La fonctionnalité OTAP est désactivée par défaut dans les versions 4.2.39.13, 5.0.68.0 et dans les versions suivantes de WLC. OTAP est validé par défaut dans les versions antérieures à 4.2.39.13. Voici le processus de décou- verte quand OTAP est activé. a. Les LAPS qui sont déjà enregistrés avec le WLC peuvent annoncer l'adresse IP du WLC aux LAPs ( dans la tentative pour trouver un WLC) avec l'utilisation de messages de voisins transmis par radio. b. Les nouveaux LAPS qui tentent de découvrir les WLCs entendent ces messages et ensuite transmettent en unicast des messages de requête de découverte vers les WLCs. c. Les WLCs qui reçoivent les messages LWAPP de découverte répondent avec un message unicast de réponse LWAPP de découverte vers le LAP. Vous devez avoir OTAP validé uniquement pendant les intervalles de provisionne- ment d'AP. Une fois que les APs sont déployées, désactiver OTAP est une bonne pratique de déploiement. Aussi les LAPs Cisco Aironet 1130 AG, 1200 et 1240 AG) sont livrés d'usine avec une version Cisco IOS Software appelée LWAPP Recovery Cisco IOS Image. OTAP n'est pas supporté sur ces APs qui opèrent avec LWAPP Cisco IOS software. Quand vous mettez à niveau les APs Cisco Aironet à partir du logiciel IOS Cisco autonome vers le mode AP Léger, l'image IOS Cisco LWAPP Reco- very est le logiciel qui est chargé. L'image IOS Cisco LWAPP Recovery ne supporte pas OTAP. Pour supporter OTAP, les APs Aironet doivent d'abord joindre un WLC pour télécharger une complète de l'IOS Cisco LWAPP. ccnp_cch

Messages de voisinage échangés par radio Réseau 172.16.1.0/24 Réseau 192.168.1.0/24 WLC Serveur DHCP LAP déjà enregistré Messages de voisinage échangés par radio Nouveau LAP Utilisation de OTAP Voici un exemple. Supposons que dans le réseau 172.16.1.0/24 vous un LAP qui est déjà enregistré avec le WLC et OTAP est activé sur le WLC. Quand le nouveau LAP dans le réseau 192.168.1.0/24 devient actif, le LAP recherche un serveur DHCP et obtient une adresse IP (si aucune affectation statique d'adresse IP n'avait été faite auparavant). Le LAP transmet une requête de découverte dur le réseau local. Comme dans ce scénario il n'y a pas de WLC sur le réseau local, le LAP tente d'utiliser OTAP pour découvrir les WLCs. Le LAP écoute les messages des voisins qui sont transmis par radio par les LAPS (dans le réseau 172.16.1.0/24) qui sont déjà enregistrés et recherche l'adresse IP du WLC. A partir de la liste des adresses IP de WLC que le nouvel AP a appris dans les messages des voisins, celui-ci transmet une requête de découverte LWAPP de couche 3 vers les WLCs. Le WLC qui reçoit cette requête de découverte répond avec une réponse de découverte LWAPP de couche 3. La sortie de la commande debug lwapp events enable illustre la séquence des messages que le WLC transmet. Tue May 23 14:37:10 2006: Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port '1' Tue May 23 14:37:10 2006: Successful transmission of LWAPP Discovery−Response to AP 00:0b:85:5b:fb:d0 on Port 1 Note: Comme le LAP connaît l'adresse IP du WLC grâce aux messages des voisins, le LAP transmet une requête de découverte unicast vers le WLC. D'une certaine façon, cette étape est contraire à la méthode de l'étape 1 de cette procédure dans laquelle le LAP transmet un broadcast sur le réseau local. Note: La valeur du paramètre IE 58 dans la sortie de la commande debug lwapp packet enable montre que le LAP utilise OTAP comme méthode de découverte. ccnp_cch

Tue May 23 14:21:55 2006: Start of Packet Tue May 23 14:21:55 2006: Ethernet Source MAC (LRAD): 00:D0:58:AD:AE:CB Tue May 23 14:21:55 2006: Msg Type : Tue May 23 14:21:55 2006: DISCOVERY_REQUEST Tue May 23 14:21:55 2006: Msg Length : 31 Tue May 23 14:21:55 2006: Msg SeqNum : 0 Tue May 23 14:21:55 2006: IE : UNKNOWN IE 58 Tue May 23 14:21:55 2006: IE Length : 1 Tue May 23 14:21:55 2006: Decode routine not available, Printing Hex Dump Tue May 23 14:21:55 2006: 00000000: 02 Tue May 23 14:21:55 2006: 3. Si le LAP a été enregistré avec un WLC dans un déploiement précédent, le LAP maintient des adresse IP de WLC localement en NVRAM. Les adresses IP des WLC comprennent toutes les adresses de WLCs qui ont été précédemment joints dans des "groupes de mobilité" WLC. C'est le processus de découverte. a. Les LAPs transmettent un message de requête de découverte LWAPP de couche 3 unicast vers chacune des adresses IP de WLC que le LAP a dans la NVRAM. b. Les WLCs qui reçoivent le message de découverte LWAPP répondent avec un message unicast de réponse de découverte LWAPP vers le LAP. Voici une exemple de sortie de la commande debug lwapp events enable et de la commande debug lwapp packet enable pour cette méthode de découverte de WLC. Note: Si vous utilisez la commande clear ap-config ap-name pour réinitialiser l'AP avec ses paramètres usine par défaut, toutes les configurations du LAP sont réini- tialisées. Les configurations qui sont réinitialisées comprennent les adresses IP des WLCs qui sont stockées en NVRAM. Dans ce cas, le LAP doit utiliser d'autres mé- thodes pour découvrir les WLCs. (Cisco Controller) >debug lwapp events enable Tue May 23 14:37:10 2006: Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port '1' Tue May 23 14:37:10 2006: Successful transmission of LWAPP Discovery−Response to AP 00:0b:85:5b:fb:d0 on Port 1 (Cisco Controller) >debug lwapp packet enable Tue May 23 14:45:36 2006: Start of Packet Tue May 23 14:45:36 2006: Ethernet Source MAC (LRAD): 00:D0:58:AD:AE:CB Tue May 23 14:45:36 2006: Msg Type : Tue May 23 14:45:36 2006: DISCOVERY_REQUEST Tue May 23 14:45:36 2006: Msg Length : 31 Tue May 23 14:45:36 2006: Msg SeqNum : 0 Tue May 23 14:45:36 2006: IE : UNKNOWN IE 58 Tue May 23 14:45:36 2006: IE Length : 1 Tue May 23 14:45:36 2006: Decode routine not available, Printing Hex Dump Tue May 23 14:45:36 2006: 00000000: 01 Tue May 23 14:45:36 2006: ccnp_cch

4. Vous pouvez également programmer les serveurs DHCP pour qu'ils retournent les adresses IP des WLCs dans "option 43" spécifique constructeur dans l'offre DHCP vers les LAPS. Voici la procédure de découverte. a. Quand un LAP obtient une adresse IP d'un serveur DHCP, le LAP recherche l'adresse IP du WLC dans le champ "Option 43" de l'offre DHCP. b. Le LAP transmet une requête de découverte LWAPP de couche 3 vers chacun des WLCs qui sont listés dans l'option DHCP 43. c. Les WLCs qui reçoivent le message de requête de découverte LWAPP répondent avec un message de réponse de découverte LWAPP unicast vers le LAP. Note: Vous pouvez utiliser l'option DHCP 43 quand les LAPs et les WLCs sont dans différents sous-réseaux. Réseau 172.16.1.0/24 Réseau 192.168.1.0/24 WLC Routeur Serveur DHCP avec Option 43 LAP Utilisation de DHCP Option 43 pour la découverte de WLC Voici un exemple. Supposons que vous avez un WLC dans un réseau ( 172.16.1.0/24 par exemple) et que les LAPs et le serveur DHCP sont dans un autre réseau (comme par exemple 192.168.1.0/24). Le routage est activé entre les deux réseaux. Vous pou- vez configurer le serveur DHCP pour qu'il retourne les adresses IP des WLC dans le message DHCP Offer. Vous pouvez utiliser tout DHCP qui supporte l'option 43. Note: Pour des informations sur comment configurer le serveur DHCP Windows 2003 pour l'option 43, référez-vous à Appendix A: Configuring DHCP Option 43 for Light- weight Cisco Aironet Access Points on Windows 2003 Enterprise DHCP Server du document "Upgrading Autonomous Cisco Aironet Access Point to Lightweight Mode". Ainsi dès que le LAP est mis sous tension, celui-ci recherche un serveur DHCP pour obtenir une adresse IP. Le serveur DHCP fournit une adresse IP au LAP mais égale- ment la liste des adresses IP des WLCs en utilisant l'option DHCP 43. Le LAP transmet ccnp_cch

Le LAP transmet une requête de découverte unicast vers chacun des WLCs Le LAP transmet une requête de découverte unicast vers chacun des WLCs. Les WLCs qui reçoivent ce message répondent avec une réponse de découverte laquelle initie le processus d'enregistrement. Cette sortie de la commande debug lwapp events enable montre la séquence des messages LWAPP. Tue May 23 14:43:42 2006: Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port '1' Tue May 23 14:43:42 2006: Successful transmission of LWAPP Discovery−Response to AP 00:0b:85:5b:fb:d0 on Port 1 Ceci est la sortie de la commande debug lwapp packet enable qui indique que l'option DHCP 43 a été utilisée comme méthode pour la découverte des adresses IP des WLCs. Tue May 23 16:14:32 2006: Start of Packet Tue May 23 16:14:32 2006: Ethernet Source MAC (LRAD): 00:D0:58:AD:AE:CB Tue May 23 16:14:32 2006: Msg Type : Tue May 23 16:14:32 2006: DISCOVERY_REQUEST Tue May 23 16:14:32 2006: Msg Length : 31 Tue May 23 16:14:32 2006: Msg SeqNum : 0 Tue May 23 16:14:32 2006: IE : UNKNOWN IE 58 Tue May 23 16:14:32 2006: IE Length : 1 Tue May 23 16:14:32 2006: Decode routine not available, Printing Hex Dump Tue May 23 16:14:32 2006: 00000000: 03 Tue May 23 16:14:32 2006: 5. Finalement vous pouvez aussi utiliser le serveur DNS pour retourner les adresses IP des WLCs au LAP. Ceci est le processus de découverte: a. Le LAP transmet le nom "CISCO-LWAPP-CONTROLLER.localdomain" vers un serveur DNS. Note: Dans la syntaxe du nom DNS, localdomain fait référence au nom de do- maine qui doit être résolu. Par exemple si le domaine est cisco.com alors le nom DNS est CISCO-LWAPP-CONTROLLER.cisco.com. L'AP doit être informé du nom de domaine devant être résolu pour l'AP puisse transmettre la requête au serveur DNS qui doit faire la résolution de nom pour ce domaine. L'AP est informé du nom de domaine par l'option DHCP 15. L'option DHCP 15 spécifie le nom de domaine que l'AP doit utiliser pour la résolution DNS. Par conséquent il est né- cessaire que l'option DHCP 15 soit configurée avec l'information de nom de do- maine. ceci autorise le serveur DHCP qui transmet l'adresse IP du serveur DNS de transmettre également l'information option DHCP 15 (nom de domaine devant être utilisé par l'AP). b. Quand le LAP est capable de résoudre ce nom vers une ou plusieurs adresses IP de WLC, le LAP transmet une requête LWAPP unicast de découverte de couche 3 vers chacun des WLCs. ccnp_cch

c. Les WLCs qui reçoivent le message LWAPP de découverte répondent avec un message de réponse de découverte LWAPP unicast de couche 3 vers le l'AP. Cet exemple utilise la même configuration que celle utilisée pour l'option DHCP 43 (étape 3). Toutefois dans cet exemple, le serveur DHCP n'utilise pas l'option 43. Au lieu de cela, le serveur DHCP fournit l'adresse IP au LAP et fournit également l'adres- se IP du serveur DNS et le nom de domaine dans l'offre DHCP. Après que le LAP ait obtenu l'adresse IP du serveur DNS et le nom de domaine, le LAP transmet une re- quête DNS pour le nom "CISCO-LWAPP-CONTROLLER.localdomain". Le serveur DNS doit être configuré de telle façon qu'il retourne les adresses IP des WLCs pour cette requête. Quand le LAP a obtenu les adresses IP des WLCs, celui-ci débute le proces- sus d'enregistrement avec le WLC. Réseau 172.16.1.0/24 Réseau 192.168.1.0/24 WLC Routeur Serveur DNS LAP Serveur DHCP Utilisation du DNS pour la découverte de WLC Cette sortie de la commande debug lwapp packet enable montre que le mode de découverte est DNS. Tue May 23 16:14:32 2006: Start of Packet Tue May 23 16:14:32 2006: Ethernet Source MAC (LRAD): 00:D0:58:AD:AE:CB Tue May 23 16:14:32 2006: Msg Type : Tue May 23 16:14:32 2006: DISCOVERY_REQUEST Tue May 23 16:14:32 2006: Msg Length : 31 Tue May 23 16:14:32 2006: Msg SeqNum : 0 Tue May 23 16:14:32 2006: IE : UNKNOWN IE 58 Tue May 23 16:14:32 2006: IE Length : 1 Tue May 23 16:14:32 2006: Decode routine not available, Printing Hex Dump Tue May 23 16:14:32 2006: 00000000: 04 Tue May 23 16:14:32 2006: ccnp_cch

Note: Si après avoir terminé les étapes 1 à 5, le LAP ne reçoit pas de réponse de dé- couverte LWAPP, le LAP se réinitialise et recommence les algorithmes de recherche. 6. Utiliser ip helper address sur le routeur Bien que cela ne fait pas partie de l'algorithme de découverte de couche 3, c'est une méthode très simple qui peut être utilisée quand le WLC et les LAPs ne sont pas dans les mêmes réseaux. Après que le LAP ait obtenu une adresse IP du ser- veur DHCP, le LAP diffuse un message de découverte LWAPP de couche 3 sur son réseau local. L'adresse IP du WLC est configurée comme une ip-helper address sur le routeur. Le routeur achemine ces diffusions vers les adresses IP configurées avec la commande ip-helper sur l'interface sur laquelle les "broadcasts" sont reçus. Quand vous utilisez la commande ip-helper address, pour les broadcasts dirigés comme pour les unicasts, huit ports UDP différents sont automatiquement ache- minés. Ces ports sont TFTP (Trivial File Transfer Protocol) port 69, DNS (Domain Name System) port 53, Time Service (port 37), NBNS (NetBios Name Service) port 137, NBDS (NetBios Data Service) port 138, BOOTP (Boostrap Protocol) Client et Serveur ports 67 et 68, TACACS service (Port 49). Comme LWAPP utilise le port 12223, celui-ci doit être explicitement acheminé sur le routeur. Ceci est un exem- ple de scénario. Supposons que vous avez un WLC dans un réseau tel que 172.16.1.0/24 et que les LAPs et le serveur DHCP sont dans le réseau 192.18.1.0/ 24. Le routage est activé entre les deux réseaux . Cet exemple montre la configu- ration du routeur. Router(config)#interface Fastethernet 0/1 Router(config−if)#ip helper−address 172.16.1.1 !−−− Adresse IP du WLC Router(config−if)#exit Router(config)ip forward−protocol udp 12223 Processus de sélection du WLC Après que le LAP ait terminé les étapes 1 à 5 de l'algorithme de découverte LWAPP de couche 3, le LAP sélectionne un WLC à partir de la liste de WLCs candidats et trans- met une requête LWAPP "Join" au WLC sélectionné. Les WLCs insèrent ces informations importantes dans les réponses LWAPP de décou- verte:  SysName du contrôleur  Type de contrôleur  Capacité du contrôleur en APs et charge courante en APs  Indicateur de "Master Controller"  Adresse IP de AP-Manager ccnp_cch

Les LAPs utilisent ces informations pour faire la sélection d'un contrôleur en utilisant ces règles de précédence: 1. Si le LAP a déjà été configuré avec un primaire, secondaire et/ou tertiaire, le LAP examine le champ sysName de contrôleur (dans les messages de réponse LWAPP) pour tenter de trouver le WLC qui est configuré comme primaire. SI le LAP trouve une correspondance avec sysName pour le contrôleur primaire, le LAP transmet une requête LWAPP "Join" vers ce WLC. Si le LAP ne peut pas trouver de contrôleur primaire ou si le message LWAPP "Join" échoue, le LAP tente de trouver le contrô- leur secondaire sysName dans les réponses LWAPP de découverte. Si le LAP trouve une correspondance, celui-ci transmet un message LWAPP "Join" au contrôleur secondaire. Si le WLC secondaire ne peut pas être trouvé ou si le message LWAPP "Join" échoue, le LAP répète le processus pour le WLC tertiaire. 2. Le LAP regarde l'indicateur Master Controller dans les messages LWAPP de réponse de découverte dans la liste des WLCs candidats si un de ces critères est vrai:  Aucun contrôleur primaire, secondaire ou tertiaire n'a été configuré pour un AP.  Ces contrôleurs n'ont pas été trouvés dans la liste de candidats.  Les messages LWAPP "Join" vers ces contrôleurs ont échoué. Si un WLC est configuré comme Master Controller, Le LAP sélectionne ce WLC et lui transmet une requête LWAPP "Join". 3. Si le LAP ne peut pas joindre un contrôleur sur la base des critères 1 et 2, le LAP tente de joindre le WLC qui a la plus grande capacité libre. Après que le LAP ait sélectionné un WLC, le LAP transmet une requête LWAPP "Join" vers ce WLC. Dans la requête LWAPP "Join", le LAP inclut un certificat X.509 signé numériquement . Quand le certificat est validé, le WLC transmet une réponse LWAPP "Join" pour indiquer au LAP qu'il a joint le contrôleur avec succès. Le WLC inclut son propre certificat X.509 signé numériquement dans la réponse LWAPP "Join" que le LAP doit valider. Après que le LAP ait validé le certificat du WLC, le processus LWAPP Join est terminé. Le LAP et le WLC (Wireless LAN Controller) gère la fragmentation et le réassemblage pour le tunnel LWAPP. Ils opèrent avec la supposition d'un MTU de 1500 octets. Ce n'est pas un paramètre configurable. Sur l'AP ou le WLC, si le MTU est supérieur à 1500 octets, celui-ci fragmente le paquet et le transmet. Le système gère jusqu'à 4 frag- ments à partir de la version 3.2. Les versions plus anciennes supportent seulement 2 fragments. Résolution de problèmes Le contrôleur a un firmware version 3.2.78.0. Quand vous entrez la commande debug lwapp events, cette sortie est affichée. Sun Sep 3 21:49:51 2006 [ERROR] spam_lrad.c 2544: Security processing of Image Data failed from AP 00:17:59:67:76:80 Ce message d'erreur signifie que l'image 3.2.78.0 ne supporte pas le LAP. En résumé le contrôleur ne peut pas trouver d'image pour le LAP dans sa liste d'images. Par con- séquent le LAP ne peut pas télécharger son image à partir du WLC. Pour résoudre ce ccnp_cch

ce problème, mettez à niveau le contrôleur avec la version 3. 2. 116 ce problème, mettez à niveau le contrôleur avec la version 3.2.116.0 ou suivantes. Ceci résout le problème et le LAP peut joindre le contrôleur et télécharger son image à partir du contrôleur. Quelquefois vous pouvez rencontrer ce message d'erreur sur votre contrôleur. Received a Discovery Request with subnet broadcast with wrong AP IP address (source address). Ce message d'erreur signifie que le contrôleur a reçu une requête de découverte avec une adresse IP de diffusion qui a une adresse IP source (donnée) qui n'est située dans aucun des sous-réseaux configurés sur le contrôleur. Cela signifie aussi que le contrô- leur a éliminé le paquet. Cela se produit typiquement quand le client a mis tous les VLANs dans un trunk au lieu de les restreindre aux VLANs sans-fil. Vous pouvez aussi rencontrer ce message d'erreur. Received a Discovery−Request from <source MAC address> for someone else (IP address). Ce message signifie que le contrôleur a reçu une requête de découverte avec une adresse IP de destination (donnée) qui n'est pas une adresse IP d'administration. Cela signifie également que le contrôleur a éliminé le paquet. L'AP bascule entre différents Groupes de Mobilité Considérez ce scénario. Le groupe de mobilité MG1 contient deux contrôleurs C1 et C2. Ces contrôleurs sont déployés dans un bâtiment avec des charges de LAP équilibrées entre ces deux contrôleurs. Le site distant de la société déploie un troisième contrôleur C3 et configure son groupe de mobilité MG2. Les LAPs de ce contrôleur (C3) ne bascu- lent pas vers un des deux autres contrôleurs mais un jour lorsque le contrôleur C3 a redémarré, les LAPs qui étaient à l'origine enregistrées avec C3 s'enregistrent mainte- nant avec C1 dans le groupe de mobilité MG1. Bien que le contrôleur primaire de LAP soit C3 et qu'il n'y a pas de contrôleur secon- daire ou tertiaire, les LAPS se sont enregistrés sur C1; un redémarrage des LAPs ne les fait pas revenir sur C3. Quel est le problème? La raison dans tout cela est que dans le déploiement initial, la société a crée un des deux scénarios:  Une entrée DNS pour CISCO-LWAPP-Controller.localdomain pointe sur C1 ou C2.  L'ajout de l'option DHCP 43 pour pointer sur C1 ou C2 pour faciliter l'installation initiale. Une fois que l'installation pour le premier bâtiment a été faite, ces entrées n'ont pas été retirées. Note: L'AP peut découvrir les contrôleurs C1 et C2 par toute autre méthode de décou- verte, telle que la diffusion de couche 3 ou OTAP, aussi assurez-vous que des précau- tions ont été prises pour l'AP découvre les contrôleurs d'un groupe de mobilité au moyen de toutes les méthodes. ccnp_cch

Quand le contrôleur C3 s'arrête, les LAPs qui étaient connectés à celui-ci redémarrent. Ils exécutent leur processus de découverte comme cela a déjà été décrit. Ils ne trans- mettent pas uniquement des requêtes de découverte à ces contrôleurs présents dans la configuration en NVRAM mais aussi aux adresses IP apprises par le DHCP et le DNS qui donnent C1 et C2 comme résultat. Comme C3 était arrêté au moment de la découverte, les LAPs n'ont pas obtenu de réponse de découverte aussi ils n'ont pas pu joindre leur contrôleur primaire configuré et doivent joindre le contrôleur qu'ils ont appris par DHCP ou DNS. Une fois que les LAP ont joint CA ou C2, ils téléchargent la nouvelle liste de groupe de mobilité laquelle comprend les adresses IP de C1 et C2 aussi ces LAPs sont redémarrés, ils n'ont aucun moyen pour apprendre l'adresse IP de C3 vers lequel ils doivent trans- mettre les requêtes de découverte; Ils ne peuvent pas joindre ce contrôleur. Le seul moyen pour que les LAPs reviennent vers C3 et d'ajouter C3 dans la liste de mobilité de C1 et C2 ou de changer l'option DHCP 43 ou l'entrée DNS. Il y a plusieurs moyens pour éviter de tels problèmes:  Il est suggéré que les options DNS et DHCP soient utilisées uniquement pour un déploiement initial et soient retirées une fois que le réseau est configuré. De cette manière les APs du réseau n'ont pas d'autres possibilités pour appendre leur groupe de mobilité.  Séparez les étendues DHCP ou les domaines DNS. Prenez une étendue pour le bâti- ment 1 et une autre étendue pour le bâtiment 2 dans le serveur DHCP d'entreprise; L'administrateur peut configurer des adresses IP différentes pour l'option DHCP 43 dans chacune des étendues. La même solution s'applique aux domaines DNS avec building1.companyname.com pour un bâtiment et building2.companyname.com pour l'autre. Vous pouvez avoir différentes options avec CISCO-LWAPP-CONTROLLER pour chaque sous-domaine.  Vous pouvez également utiliser des fonctions dans le WLC pour contrôler certains comportements. ▪ Dans la cas d'APs avec des certificats auto-signés (SSC), ajoutez uniquement les SSCs aux contrôleurs que vous voulez que l'AP joigne. ▪ Dans le cas d'AP avec Certificat de constructeur installé (MIC), utilisez "Authorize APs against AAA function" sur le WLC (avec la commande config auth-list ap-policy authorize-ap enable) pour indiquer au contrôleur s'il doit accepter l'AP. Pour autoriser l'AP à joindre le contrôleur, utilisez une de ces options:  Ajoutez les à la liste d'autorisation du WLC; utilisez la commande config auth-list add mic <MAC-ADDRESS>.  Ajoutez les comme clients de serveurs RADIUS. Called-Station-ID est l'adresse MAC du contrôleur. Si vous placez les APs dans des groupes différents, vous pouvez créer des stratégies pour définir quels APs s'authentifient avec le Called-Station-ID. ccnp_cch

Pour qu'un LAP joigne un contrôleur qui ne fait pas partie du groupe de mobilité du contrôleur courant joint, vous devez être sur que le nom du contrôleur primaire est bien celui auquel vous voulez rattacher l'AP. Quand cela est fait, tout ce que vous avez à faire et de donner au LAP un moyen pour découvrir le contrôleur. Cela peut être fait au travers des différentes méthodes décrites dans l'algorithme de découverte du WLC de ce document. ccnp_cch