Contrôleur LAN sans fil CISCO et question de conception de l'AP

Il y a quelques questions sur la solution de conception.

1. Le tunnel CAPWAP est créé entre le contrôleur et les points d'accès. Les extrémités du tunnel sont l'interface "ap-gestion" du contrôleur et l'interface de gestion du point d'accès. J'ai découvert qu'avoir l'AP et le contrôleur dans différents domaines L2 est la meilleure pratique, mais en théorie, cela semble être une meilleure solution. Qui est correct?

2. L'un des réseaux sans fil sera le WI-FI invité. Un secrétaire créera des attributs d'accès. Est-il nécessaire de créer une interface supplémentaire (dans le réseau de l'entreprise) sur le contrôleur et de donner des informations d'identification à "Lobby Admin" pour mettre en œuvre un tel schéma?

1. Mettre les points d'accès et le contrôleur dans le même domaine L2 est la solution la plus simple car vous n'avez rien d'autre à faire pour qu'ils se trouvent. Si vous placez les AP sur un sous-réseau différent, vous devez soit configurer l'option DHCP 43 sur le sous-réseau des AP, soit insérer une entrée DNS pour cisco-capwap-controller.DOMAIN-APs-GET-FROM.DHC. Auparavant, c'était cisco-lwapp-controller.

2. Vous devrez donner au secrétaire un accès administrateur ou lobby administrateur au WLC afin qu'il puisse créer les connexions. Il n'a pas besoin d'une interface supplémentaire pour le wifi invité, mais vous pouvez en utiliser une et la brancher dans la DMZ pour une meilleure isolation.

Edit: Numéro d'option DHCP corrigé car @generalnetworkerror a souligné ma mémoire défectueuse.

1. Les points d'accès et le contrôleur se trouvant sur le même sous-réseau sont plutôt improbables. Vous auriez probablement un contrôleur centralisé quelque part dans votre organisation et les points d'accès seraient connectés à des ports dans différents placards IDF qui s'étendent sur plusieurs sous-réseaux. Lorsque les points d'accès démarrent, ils prennent le nom de domaine attribué via DHCP et essaient de résoudre CISCO-CAPWAP-CONTROLLER.domainname.com ou CISCO-LWAP-CONTROLLER.domainname.com et tunnelent leurs tunnels CAPWAP ou LWAP là-bas. Avoir le même VLAN L2 réparti autour de vos multiples commutateurs et lignes réseau est dangereux d'un point de vue STP. Je dirais donc qu'avoir des AP et des contrôleurs sur le même domaine L2 est une mauvaise pratique.
2. À moins que vous ne vouliez donner à votre secrétaire l'accès au contrôleur - regardez à l'aide du serveur Cisco Guest Access. http://www.cisco.com/en/US/products/ps10160/index.html

Cela permet au secrétaire de générer des noms d'utilisateur et des mots de passe pour les invités ainsi que de leur envoyer par e-mail les informations (ils peuvent les lire sur leur smartphone et se connecter) et spécifier la durée pendant laquelle le compte restera connecté. De cette façon, personne ne connaît le PSK ou la connexion générique à l'aide de l'authentification Web. Il est également recommandé de chiffrer les événements du réseau wifi ouvert / invité avec un mot de passe simple pour assurer la sécurité des utilisateurs.

1. Vous pourriez essayer de garder les points d'accès et l'interface de gestion du contrôleur dans le même domaine L2, mais cela ne vous apporterait rien d'autre qu'un mal de tête. L'architecture est conçue pour vous permettre de brancher et jouer des points d'accès sur l'ensemble de votre réseau, même au-delà des limites de la L3. Les points d'accès découvriront les contrôleurs de différentes manières. Nous utilisons la découverte DNS. (Ajouter un enregistrement A pour "CISCO-CAPWAP-CONTROLLER.yourdomain.com". Je pense qu'il y a un autre enregistrement A à ajouter, mais il m'échappe pour le moment)
2. Je ne suis pas sûr de comprendre à 100% cette partie de la question. Il semble qu'un secrétaire définira le PSK pour les invités. Dans ce cas, je recommanderais certainement d'avoir une interface différente qui ne permet pas d'accéder à l'espace d'adressage RFC 1918. Utilisez un serveur DNS externe. Ensuite, tout ce qui reste est de donner au secrétaire l'accès au WLC pour changer le PSK du SSID.

Il est possible d'avoir WLC et AP dans le même sous-réseau, mais peu probable car il est difficile à gérer en particulier dans les grands environnements ou lorsque vous déployez fréquemment de nouveaux points d'accès. D'après mon expérience: Sur les petits emplacements où vous avez 10-20 points d'accès et WLC sur site, il est plus facile de les mettre dans le même VLAN. Sur les grandes installations où vous avez un WLC centralisé (ou plus redondant) et beaucoup d'AP qui sont (géographiquement) dispersés, la solution facile à configurer et `` propre '' consiste à utiliser DNS pour le processus de découverte. Lorsque vous avez des réseaux plus complexes, soit en raison d'exigences spécifiques, soit d'une mauvaise conception, vous pouvez utiliser l'option DHCP 43 (ou la configuration statique).

L'utilisation de l'enregistrement DNS est une solution simple pour découvrir le contrôleur, surtout si vous n'en avez qu'un dans votre domaine ou que vous ne vous souciez pas du WLC auquel l'AP se joindra. J'aime utiliser les options spécifiques du fournisseur DHCP pour le processus de découverte car il est plus facile que de configurer manuellement lelwapp ap controller ip addressmais donne plus de contrôle particulièrement quand vous ne pouvez pas utiliser différents domaines pour une raison quelconque et voulez pouvoir envoyer différentes IP WLC aux AP. Vous pouvez créer une stratégie basée sur la portée qui a l'option DHCP 43 avec l'adresse IP du contrôleur pour les VCI (Vendor Class Identifiers) de vos points d'accès. VCI est envoyé dans l'option 60 par le client DHCP lors de la diffusion de découverte DHCP initiale et est utilisé pour identifier la classe spécifique de périphériques (d'où le nom). Pour les VCI correspondants, DHCP enverra l'option 43 avec 102 ou 241 suoptions que vous configurerez pour conserver les adresses IP de vos contrôleurs (et les autres clients ne les verront pas).