Guide de déploiement du client IPv6 LAN sans fil
Contenu
Introduction
Ce document fournit des informations sur le fonctionnement théorique et sur la configuration de la solution de réseau local sans fil unifié de Cisco en ce qui concerne la prise en charge des clients IPv6.
Connectivité du client sans fil IPv6
L'ensemble de fonctionnalités IPv6 du logiciel Cisco Unified Wireless Network v7.2 permet au réseau sans fil de prendre en charge les clients IPv4, Dual-Stack et IPv6 uniquement sur le même réseau sans fil. L'objectif global de l'ajout de la prise en charge des clients IPv6 au LAN sans fil unifié de Cisco était de maintenir la parité des fonctionnalités entre les clients IPv4 et IPv6, notamment en termes de mobilité, de sécurité, d'accès invité, de qualité de service et de visibilité sur les terminaux.
Jusqu'à huit adresses client IPv6 peuvent être suivies par périphérique. Cela permet aux clients IPv6 de disposer d'une adresse de configuration automatique d'adresse sans état (SLAAC) link-local, du protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6) et même d'adresses dans d'autres préfixes pour être sur une interface unique. Les clients WGB (Work Group Bridge) connectés à la liaison ascendante d'un point d'accès autonome (AP) en mode WGB peuvent également prendre en charge IPv6.
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
-
Contrôleurs LAN sans fil, série 2500, série 5500 ou WiSM2
-
AP 1130, 1240, 1250, 1040, 1140, 1260, 3500, 3600 et 1520 ou 1550 points d'accès maillés
-
Routeur compatible IPv6
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.
Conventions
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Conditions requises pour la connectivité client IPv6 sans fil
Afin d'activer la connectivité client IPv6 sans fil, le réseau câblé sous-jacent doit prendre en charge le routage IPv6 et un mécanisme d'attribution d'adresse tel que SLAAC ou DHCPv6. Le contrôleur LAN sans fil doit avoir une contiguïté de couche 2 avec le routeur IPv6 et le VLAN doit être étiqueté lorsque les paquets entrent dans le contrôleur. Les points d'accès ne nécessitent pas de connectivité sur un réseau IPv6, car tout le trafic est encapsulé dans le tunnel CAPWAP IPv4 entre le point d'accès et le contrôleur.
Attribution d'adresse SLAAC
La méthode la plus courante pour l'attribution d'adresse de client IPv6 est SLAAC. SLAAC fournit une connectivité plug-and-play simple où les clients assignent eux-mêmes une adresse en fonction du préfixe IPv6. Ce processus est réalisé lorsque le routeur IPv6 envoie des messages périodiques d'annonce de routeur qui informent le client du préfixe IPv6 utilisé (les 64 premiers bits) et de la passerelle par défaut IPv6. À partir de ce point, les clients peuvent générer les 64 bits restants de leur adresse IPv6 en fonction de deux algorithmes : EUI-64 qui est basé sur l'adresse MAC de l'interface, ou les adresses privées qui sont générées de manière aléatoire. Le choix de l'algorithme dépend du client et est souvent configurable. La détection des adresses dupliquées est effectuée par les clients IPv6 afin de s'assurer que les adresses choisies au hasard ne entrent pas en collision avec d'autres clients. L’adresse des annonces envoyées par le routeur est utilisée comme passerelle par défaut pour le client.
Ces commandes de configuration Cisco IOS® d'un routeur IPv6 compatible Cisco sont utilisées pour activer l'adressage SLAAC et les annonces de routeur :
ipv6 unicast-routing interface Vlan20 description IPv6-SLAAC ip address 192.168.20.1 255.255.255.0 ipv6 address 2001:DB8:0:20::1/64 ipv6 enable end
Attribution d'adresse DHCPv6
L'utilisation de DHCPv6 n'est pas requise pour la connectivité du client IPv6 si SLAAC est déjà déployé. Il existe deux modes de fonctionnement pour DHCPv6 appelés sans état et avec état.
Le mode sans état DHCPv6 est utilisé pour fournir aux clients des informations réseau supplémentaires non disponibles dans l'annonce du routeur, mais pas une adresse IPv6 car elle est déjà fournie par SLAAC. Ces informations peuvent inclure le nom de domaine DNS, les serveurs DNS et d'autres options spécifiques au fournisseur DHCP. Cette configuration d'interface s'applique à un routeur IPv6 Cisco IOS mettant en oeuvre DHCPv6 sans état avec SLAAC activé :
ipv6 unicast-routing interface Vlan20 description IPv6-DHCP-Stateless ip address 192.168.20.1 255.255.255.0 ipv6 enable ipv6 address 2001:DB8:0:20::1/64 ipv6 nd other-config-flag ipv6 dhcp relay destination 2001:DB8:0:10::100 end
L'option DHCPv6 Stateful, également appelée mode géré, fonctionne de la même manière que DHCPv4 en ce qu'elle attribue des adresses uniques à chaque client au lieu du client générant les 64 derniers bits de l'adresse comme dans SLAAC. Cette configuration d'interface s'applique à un routeur IPv6 Cisco IOS mettant en oeuvre DHCPv6 avec état avec SLAAC désactivé :
ipv6 unicast-routing interface Vlan20 description IPv6-DHCP-Stateful ip address 192.168.20.1 255.255.255.0 ipv6 enable ipv6 address 2001:DB8:0:20::1/64 ipv6 nd prefix 2001:DB8:0:20::/64 no-advertise ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 dhcp relay destination 2001:DB8:0:10::100 end
Additional Information
La configuration du réseau câblé pour une connectivité complète à l'échelle du campus IPv6 à l'aide de méthodes de connectivité à double pile ou à tunnellisation n'entre pas dans le cadre de ce document. Pour plus d'informations, reportez-vous au guide de déploiement validé de Cisco Déploiement d'IPv6 dans les réseaux de campus.
Mobilité des clients IPv6
Afin de traiter les clients IPv6 itinérants entre les contrôleurs, les messages ICMPv6 tels que la sollicitation de voisin (NS), l'annonce de voisin (NA), l'annonce de routeur (RA) et la sollicitation de routeur (RS) doivent être traités spécialement afin de s'assurer qu'un client reste sur le même réseau de couche 3. La configuration de la mobilité IPv6 est identique à celle de la mobilité IPv4 et ne nécessite aucun logiciel distinct côté client pour assurer une itinérance transparente. La seule configuration requise est que les contrôleurs doivent faire partie du même groupe/domaine de mobilité.
Voici le processus de mobilité des clients IPv6 entre les contrôleurs :
-
Si les deux contrôleurs ont accès au même VLAN sur lequel le client était à l'origine, la route est simplement un événement d'itinérance de couche 2 où l'enregistrement du client est copié sur le nouveau contrôleur et aucun trafic n'est réacheminé vers le contrôleur d'ancrage.
-
Si le deuxième contrôleur n'a pas accès au VLAN d'origine sur lequel le client était connecté, un événement d'itinérance de couche 3 se produira, ce qui signifie que tout le trafic du client doit être tunnelisé via le tunnel de mobilité (Ethernet sur IP) vers le contrôleur d'ancrage.
-
Afin de s'assurer que le client conserve son adresse IPv6 d'origine, les RA du VLAN d'origine sont envoyés par le contrôleur d'ancrage au contrôleur étranger où ils sont livrés au client à l'aide de la monodiffusion L2 à partir de l'AP.
-
Lorsque le client itinérant va renouveler son adresse via DHCPv6 ou générer une nouvelle adresse via SLAAC, les paquets RS, NA et NS continuent à être tunnellisés vers le VLAN d'origine, de sorte que le client recevra une adresse IPv6 applicable à ce VLAN.
-
Remarque : la mobilité pour les clients IPv6 uniquement est basée sur les informations VLAN. Cela signifie que la mobilité des clients IPv6 uniquement n'est pas prise en charge sur les VLAN non balisés.
Prise en charge de la sélection VLAN (groupes d'interfaces)
La fonctionnalité de groupes d'interfaces permet à une organisation d'avoir un seul WLAN avec plusieurs VLAN configurés sur le contrôleur afin de permettre l'équilibrage de charge des clients sans fil sur ces VLAN. Cette fonctionnalité est couramment utilisée pour maintenir des tailles de sous-réseaux IPv4 réduites tout en permettant à un réseau local sans fil de s'adapter à des milliers d'utilisateurs sur plusieurs VLAN du groupe. Afin de prendre en charge les clients IPv6 avec des groupes d'interfaces, aucune configuration supplémentaire n'est requise car le système envoie automatiquement l'annonce de routeur correcte aux clients corrects via la monodiffusion sans fil L2. En unissant l'annonce de routeur, les clients du même WLAN, mais d'un autre VLAN, ne reçoivent pas l'annonce de routeur incorrecte.
Sécurité du premier saut pour les clients IPv6
Protection de l'annonce du routeur
La fonctionnalité RA Guard augmente la sécurité du réseau IPv6 en supprimant les RA provenant de clients sans fil. Sans cette fonctionnalité, les clients IPv6 mal configurés ou malveillants pourraient se présenter comme un routeur pour le réseau, souvent avec une priorité élevée qui pourrait primer sur les routeurs IPv6 légitimes.
Par défaut, RA Guard est activé sur l'AP (mais peut être désactivé sur l'AP) et est toujours activé sur le contrôleur. Il est préférable de supprimer des RA au niveau de l'AP car il s'agit d'une solution plus évolutive et fournit des compteurs de perte d'RA améliorés par client. Dans tous les cas, l'annonce de routeur IPv6 sera supprimée à un moment donné, protégeant ainsi les autres clients sans fil et le réseau câblé en amont des clients IPv6 malveillants ou mal configurés.
Protection du serveur DHCPv6
La fonctionnalité de protection du serveur DHCPv6 empêche les clients sans fil de transmettre des adresses IPv6 à d'autres clients sans fil ou clients câblés en amont. Afin d'empêcher la distribution des adresses DHCPv6, tout DHCPv6 annonce des paquets de clients sans fil est abandonné. Cette fonctionnalité fonctionne sur le contrôleur, ne nécessite aucune configuration et est activée automatiquement.
Protection de source IPv6
La fonction de protection de la source IPv6 empêche un client sans fil d'usurper une adresse IPv6 d'un autre client. Cette fonctionnalité est analogue à la protection de source IPv4. La protection de la source IPv6 est activée par défaut mais peut être désactivée via l'interface de ligne de commande.
Gestion des adresses IPv6
Pour l'authentification et la comptabilité RADIUS, le contrôleur renvoie une adresse IP à l'aide de l'attribut ” d'adresse IP tramée “. L'adresse IPv4 est utilisée dans ce cas.
L'attribut “ Calling-Station-ID ” utilise cet algorithme afin de renvoyer une adresse IP lorsque le “ Call Station ID Type ” sur le contrôleur est configuré pour “ IP Address ” :
-
Adresse IPv4
-
Adresse IPv6 de monodiffusion globale
-
Adresse IPv6 locale de liaison
Puisque les adresses IPv6 des clients peuvent changer souvent (adresses temporaires ou privées), il est important de les suivre au fil du temps. Cisco NCS enregistre toutes les adresses IPv6 utilisées par chaque client et les consigne historiquement chaque fois que le client se déplace ou établit une nouvelle session. Ces enregistrements peuvent être configurés sur NCS pour être conservés pendant un an maximum.
Remarque : La valeur par défaut du ” Type de station d'appel “ sur le contrôleur a été modifiée pour “ System MAC Address ” dans la version 7.2. Lors de la mise à niveau, cette option doit être modifiée pour permettre un suivi unique des clients par adresse MAC, car les adresses IPv6 peuvent changer en cours de session et provoquer des problèmes de comptabilité si l'ID de station appelante est défini sur adresse IP.
Listes de contrôle d'accès IPv6
Afin de restreindre l'accès à certaines ressources câblées en amont ou de bloquer certaines applications, les listes de contrôle d'accès (ACL) IPv6 peuvent être utilisées pour identifier le trafic et l'autoriser ou le refuser. Les listes de contrôle d'accès IPv6 prennent en charge les mêmes options que les listes de contrôle d'accès IPv4, notamment les ports source, de destination, source et de destination (les plages de ports sont également prises en charge). Les listes de contrôle d'accès pré-authentification sont également prises en charge pour prendre en charge l'authentification invité IPv6 à l'aide d'un serveur Web externe. Le contrôleur sans fil prend en charge jusqu'à 64 listes de contrôle d'accès IPv6 uniques avec 64 règles uniques dans chacune. Le contrôleur sans fil continue à prendre en charge 64 listes de contrôle d'accès IPv4 uniques supplémentaires, chacune comportant 64 règles uniques, pour un total de 128 listes de contrôle d'accès pour un client à double pile.
Remplacement AAA pour les listes de contrôle d'accès IPv6
Afin de prendre en charge le contrôle d'accès centralisé via un serveur AAA centralisé tel que Cisco Identity Services Engine (ISE) ou ACS, la liste de contrôle d'accès IPv6 peut être provisionnée par client à l'aide des attributs de remplacement AAA. Afin d'utiliser cette fonctionnalité, la liste de contrôle d'accès IPv6 doit être configurée sur le contrôleur et le WLAN doit être configuré avec la fonction de remplacement AAA activée. L'attribut AAA nommé réel pour une liste de contrôle d'accès IPv6 est Airespace-IPv6-ACL-Name similaire à l'attribut Airespace-ACL-Name utilisé pour provisionner une liste de contrôle d'accès IPv4. L'attribut AAA renvoyé le contenu doit être une chaîne égale au nom de la liste de contrôle d'accès IPv6 telle que configurée sur le contrôleur.
Optimisation des paquets pour les clients IPv6
Mise en cache de découverte de voisin
Le protocole de découverte de voisins IPv6 utilise des paquets NA et NS à la place du protocole ARP (Address Resolution Protocol) afin de permettre aux clients IPv6 de résoudre l'adresse MAC d'autres clients sur le réseau. Le processus NPD peut être très chatté car il utilise initialement des adresses de multidiffusion pour résoudre les adresses ; cela peut consommer un temps d'antenne sans fil précieux lorsque les paquets de multidiffusion sont envoyés à tous les clients du segment de réseau.
Afin d'accroître l'efficacité du processus NPD, la mise en cache de découverte de voisins permet au contrôleur d'agir comme un proxy et de répondre aux requêtes NS qu'il peut résoudre. La mise en cache de découverte de voisin est rendue possible par la table de liaison de voisin sous-jacente présente dans le contrôleur. La table de liaison de voisinage suit chaque adresse IPv6 et son adresse MAC associée. Lorsqu'un client IPv6 tente de résoudre l'adresse de couche liaison d'un autre client, le paquet NS est intercepté par le contrôleur qui répond avec un paquet NA.
Limitation des annonces de routeur
La limitation de l'annonce de routeur permet au contrôleur d'appliquer la limitation de débit des RA se dirigeant vers le réseau sans fil. En activant la limitation des RA, les routeurs configurés pour envoyer des RA très souvent (par exemple, toutes les trois secondes) peuvent être ramenés à une fréquence minimale qui maintiendra toujours la connectivité du client IPv6. Cela permet d'optimiser le temps d'antenne en réduisant le nombre de paquets de multidiffusion qui doivent être envoyés. Dans tous les cas, si un client envoie une RS, une RA est autorisée par le contrôleur et la monodiffusion au client demandeur. Il s'agit de s'assurer que les nouveaux clients ou les clients itinérants ne sont pas affectés négativement par la limitation de l'AR.
Accès invité IPv6
Les fonctionnalités d'invité sans fil et filaire présentes pour les clients IPv4 fonctionnent de la même manière pour les clients à double pile et IPv6 uniquement. Une fois que l'utilisateur invité s'associe, ils sont placés dans un état d'exécution ” WEB_AUTH_REQ “ jusqu'à ce que le client soit authentifié via le portail captif IPv4 ou IPv6. Le contrôleur intercepte le trafic HTTP/HTTPS IPv4 et IPv6 dans cet état et le redirige vers l'adresse IP virtuelle du contrôleur. Une fois que l'utilisateur est authentifié via le portail captif, son adresse MAC est déplacée à l'état d'exécution et le trafic IPv4 et IPv6 est autorisé à passer. Pour l'authentification Web externe, la liste de contrôle d'accès pré-authentification permet l'utilisation d'un serveur Web externe.
Afin de prendre en charge la redirection des clients IPv6 uniquement, le contrôleur crée automatiquement une adresse virtuelle IPv6 basée sur l'adresse virtuelle IPv4 configurée sur le contrôleur. L'adresse IPv6 virtuelle suit la convention de [::ffff:<adresse IPv4 virtuelle>]. Par exemple, une adresse IP virtuelle de 1.1.1.1 se traduirait par [::ffff:1.1.1.1].
Lorsque vous utilisez un certificat SSL approuvé pour l'authentification d'accès invité, assurez-vous que l'adresse virtuelle IPv4 et IPv6 du contrôleur est définie dans DNS pour correspondre au nom d'hôte des certificats SSL. Cela garantit que les clients ne reçoivent pas d'avertissement de sécurité indiquant que le certificat ne correspond pas au nom d'hôte du périphérique.
Remarque : le certificat SSL généré automatiquement par le contrôleur ne contient pas l'adresse virtuelle IPv6. Cela peut entraîner la présentation d'un avertissement de sécurité par certains navigateurs Web. Il est recommandé d'utiliser un certificat SSL approuvé pour l'accès invité.
VidéoStream IPv6
VideoStream permet une diffusion vidéo multidiffusion sans fil fiable et évolutive, en envoyant le flux à chaque client au format monodiffusion. La conversion de multidiffusion en monodiffusion réelle (de L2) se produit au niveau de l'AP fournissant une solution évolutive. Le contrôleur envoie le trafic vidéo IPv6 à l'intérieur d'un tunnel de multidiffusion CAPWAP IPv4, ce qui permet une distribution réseau efficace au point d'accès.
Qualité de service IPv6
Les paquets IPv6 utilisent un marquage similaire à l'utilisation par IPv4 de valeurs DSCP prenant en charge jusqu'à 64 classes de trafic différentes (0-63). Pour les paquets en aval du réseau câblé, la valeur de classe de trafic IPv6 est copiée dans l'en-tête du tunnel CAPWAP afin de s'assurer que la QoS est préservée de bout en bout. Dans la direction amont, la même chose se produit lorsque le trafic client marqué au niveau de la couche 3 avec la classe de trafic IPv6 sera honoré en marquant les paquets CAPWAP destinés au contrôleur.
IPv6 et FlexConnect
FlexConnect - WLAN de commutation locale
FlexConnect en mode de commutation locale prend en charge les clients IPv6 en pontant le trafic vers le VLAN local, comme le fonctionnement d'IPv4. La mobilité des clients est prise en charge pour l'itinérance de couche 2 sur le groupe FlexConnect.
Ces fonctionnalités spécifiques à IPv6 sont prises en charge en mode de commutation locale FlexConnect :
-
Protection RA IPv6
-
Pontage IPv6
-
Authentification invité IPv6 (hébergée par contrôleur)
Ces fonctionnalités spécifiques à IPv6 ne sont pas prises en charge en mode de commutation locale FlexConnect :
-
Mobilité de couche 3
-
VidéoStream IPv6
-
Listes de contrôle d'accès IPv6
-
Protection de source IPv6
-
Protection du serveur DHCPv6
-
Mise en cache de découverte de voisin
-
Limitation des annonces de routeur
FlexConnect - WLAN de commutation centrale
Pour les points d'accès en mode FlexConnect utilisant la commutation centrale (trafic de tunnellisation vers le contrôleur), le contrôleur doit être défini sur “ Multicast - Unicast Mode ” pour le ” du mode de multidiffusion “ AP. Puisque les points d'accès FlexConnect ne rejoignent pas le groupe de multidiffusion CAPWAP du contrôleur, les paquets de multidiffusion doivent être répliqués au niveau du contrôleur et de monodiffusion à chaque point d'accès individuellement. Cette méthode est moins efficace que “ Multicast - Multicast Mode ” et place une charge supplémentaire sur le contrôleur.
Cette fonctionnalité spécifique à IPv6 n'est pas prise en charge en mode de commutation centrale FlexConnect :
-
VidéoStream IPv6
Remarque : Les WLAN commutés de manière centralisée exécutant IPv6 ne sont pas pris en charge sur le contrôleur Flex 7500.
Visibilité des clients IPv6 avec NCS
Avec la version NCS v1.1, de nombreuses fonctionnalités supplémentaires spécifiques à IPv6 sont ajoutées pour surveiller et gérer un réseau de clients IPv6 sur les réseaux filaires et sans fil.
Éléments du tableau de bord IPv6
Afin de voir quels types de clients sont présents sur le réseau, un “ Dashlet ” dans NCS est disponible afin de fournir des informations sur les statistiques spécifiques à IPv6 et d'offrir la possibilité d'analyser en détail les clients IPv6.
IP Address Type Dashlet - Affiche les types de clients IP sur le réseau :
Client Count by IP Address Type - Affiche le type de client IP au fil du temps :
Trafic client par type d'adresse IP - Affiche le trafic de chaque type de client. Les clients de la catégorie double pile incluent le trafic IPv4 et IPv6 :
Attribution d'adresse IPv6 - Affiche la méthode d'attribution d'adresse pour chaque client dans l'une des quatre catégories suivantes :
-
DHCPv6 : pour les clients dont les adresses sont attribuées par un serveur central. Le client peut également avoir une adresse SLAAC.
-
SLAAC ou Statique : pour les clients qui utilisent l'affectation automatique d'adresses sans état ou qui utilisent des adresses configurées de manière statique.
-
Inconnu - Dans certains cas, l'affectation d'adresse IPv6 ne peut pas être découverte.
-
Cette condition se produit uniquement sur les clients filaires dans NCS, car certains commutateurs ne vérifient pas les informations d'affectation d'adresse IPv6.
-
-
Autoassigné - Pour les clients dont l'adresse link-local est entièrement auto-assignée.
-
Les clients de cette catégorie peuvent rencontrer des problèmes de connectivité IPv6 car ils ne disposent pas d'adresse unique globale ou locale.
-
Chacune des sections du graphique à secteurs est cliquable, ce qui permet à l'administrateur d'accéder à une liste de clients.
Surveiller les clients IPv6
Afin de surveiller et de gérer les informations client IPv6, ces colonnes ont été ajoutées à la page Clients et utilisateurs :
-
Type IP : type de client basé sur les adresses IP vues du client. Les options possibles sont IPv4, IPv6 ou Dual-Stack, ce qui signifie qu'un client a des adresses IPv4 et IPv6.
-
Type d'affectation IPv6 : la méthode d'affectation d'adresse est détectée par NCS en tant que SLAAC ou Statique, DHCPv6, Self-Assigned ou Unknown.
-
Global Unique : adresse globale IPv6 la plus récente utilisée par le client. Une souris sur le contenu des colonnes indique toute adresse IPv6 globale unique supplémentaire utilisée par le client.
-
Local Unique : adresse unique locale IPv6 la plus récente utilisée par le client. Une souris sur le contenu de la colonne indique toute adresse IPv6 globale unique supplémentaire utilisée par le client.
-
Link Local : adresse IPv6 du client qui est auto-attribuée et utilisée pour la communication avant toute autre adresse IPv6.
-
Annonces de routeur abandonnées : nombre d'annonces de routeur envoyées par le client et abandonnées sur le point d'accès. Cette colonne peut être utilisée pour identifier les clients qui peuvent être mal configurés ou configurés de manière malveillante pour agir comme un routeur IPv6. Cette colonne est triable, ce qui permet d'identifier facilement les clients délinquants.
En plus d'afficher des colonnes spécifiques à IPv6, la colonne IP Address affiche l'adresse IP actuelle du client avec une priorité pour afficher d'abord l'adresse IPv4 (dans le cas d'un client à double pile) ou l'adresse IPv6 unique globale dans le cas d'un client IPv6 uniquement.
Configuration pour la prise en charge des clients IPv6 sans fil
Mode de distribution multidiffusion vers les points d’accès
Le réseau sans fil unifié Cisco prend en charge deux méthodes de distribution multidiffusion aux points d'accès associés au contrôleur. Dans les deux modes, le paquet de multidiffusion d'origine provenant du réseau câblé est encapsulé dans un paquet CAPWAP de couche 3 envoyé via la monodiffusion CAPWAP ou la multidiffusion au point d'accès. Puisque le trafic est encapsulé CAPWAP, les AP ne doivent pas nécessairement se trouver sur le même VLAN que le trafic client. Les deux méthodes de distribution multidiffusion sont comparées ici :
| Mode Multicast-unicast | Multicast-Multicast Mode | |
|---|---|---|
| Mécanisme de livraison | Le contrôleur réplique le paquet de multidiffusion et l'envoie à chaque point d'accès dans un tunnel CAPWAP de monodiffusion | Le contrôleur envoie une copie du paquet de multidiffusion |
| Modes AP pris en charge | FlexConnect et local | Mode local uniquement |
| Nécessite le routage multicast de couche 3 sur un réseau câblé | Non | Oui |
| Chargement du contrôleur | Élevé | Faible |
| Chargement du réseau câblé | Élevé | Faible |
Configuration du mode de distribution multidiffusion
Le mode multidiffusion est recommandé pour des raisons d'évolutivité et d'efficacité de la bande passante filaire.
Remarque : Cette étape n'est absolument requise que pour le contrôleur sans fil de la gamme 2500, mais elle permet une transmission multicast plus efficace et est recommandée pour toutes les plates-formes de contrôleur.
Accédez à l'onglet “ Controller ” sous la page “ General ” et assurez-vous que le mode de multidiffusion AP est configuré pour utiliser le mode de multidiffusion et qu'une adresse de groupe valide est configurée. L'adresse de groupe est un groupe de multidiffusion IPv4 et il est recommandé de se trouver dans la plage 239.X.X.X-239.255.255.255, qui est étendue pour les applications de multidiffusion privées.
Remarque : N'utilisez pas les plages d'adresses 224.X.X.X, 239.0.0.X ou 239.128.0.X pour l'adresse du groupe de multidiffusion. Les adresses de ces plages se chevauchent avec les adresses MAC locales de liaison et inondent tous les ports du commutateur, même si la surveillance IGMP est activée.
Configurer le mode de distribution multidiffusion monodiffusion
Si le réseau câblé n'est pas correctement configuré pour fournir la multidiffusion CAPWAP entre le contrôleur et le mode AP ou FlexConnect, et que les AP seront utilisés pour les WLAN commutés centralement prenant en charge IPv6, alors le mode monodiffusion est requis.
-
Accédez à l'onglet Contrôleur sous la page Général, et vérifiez que le mode de multidiffusion AP est configuré pour utiliser le mode monodiffusion.
-
Connectez un client compatible IPv6 au réseau local sans fil. Vérifiez que le client reçoit une adresse IPv6 en accédant à l'onglet Monitor, puis au menu Clients.
Configurer la mobilité IPv6
Il n'existe aucune configuration spécifique pour la mobilité IPv6, sauf pour placer les contrôleurs dans le même groupe de mobilité ou dans le même domaine de mobilité. Cela permet à 72 contrôleurs au total de participer à un domaine de mobilité offrant une mobilité transparente pour les campus les plus importants.
Accédez à l'onglet Controller > Mobility Groups, et ajoutez chaque contrôleur par adresse MAC et adresse IP dans le groupe. Ceci doit être fait sur tous les contrôleurs du groupe de mobilité.
Configuration de la multidiffusion IPv6
Le contrôleur prend en charge la surveillance MLDv1 pour la multidiffusion IPv6, ce qui lui permet de suivre et de livrer intelligemment les flux de multidiffusion aux clients qui les demandent.
Remarque : Contrairement aux versions précédentes des versions, la prise en charge du trafic de monodiffusion IPv6 n'exige pas que “ mode de multidiffusion globale ” être activé sur le contrôleur. La prise en charge du trafic de monodiffusion IPv6 est activée automatiquement.
-
Accédez à la page Controller > Multicast et Enable MLD Snooping afin de prendre en charge le trafic IPv6 multicast. Pour que la multidiffusion IPv6 soit activée, le mode de multidiffusion globale du contrôleur doit également être activé.
Remarque : le mode de multidiffusion globale, IGMP et la surveillance MLD doivent être activés si des applications de découverte peer-to-peer telles que le Bonjour d'Apple sont requises.
-
Afin de vérifier que le trafic de multidiffusion IPv6 est en cours de surveillance, accédez à l'onglet Monitor et à la page Multicast. Notez que les groupes de multidiffusion IPv4 (IGMP) et IPv6 (MLD) sont répertoriés. Cliquez sur le MGID afin d'afficher les clients sans fil joints à cette adresse de groupe.
Configurer la protection RA IPv6
Accédez à l'onglet Controller, puis IPv6 > RA Guard dans le menu de gauche. Activez la protection RA IPv6 sur AP. La protection RA du contrôleur ne peut pas être désactivée. En plus de la configuration de RA Guard, cette page présente également tous les clients identifiés comme ayant envoyé des RA.
Configuration des listes de contrôle d'accès IPv6
-
Accédez à l'onglet Sécurité, ouvrez Listes de contrôle d'accès, puis cliquez sur Nouveau.
-
Entrez un nom unique pour la liste de contrôle d'accès, modifiez le type de liste de contrôle d'accès en IPv6, puis cliquez sur Apply.
-
Cliquez sur la nouvelle liste de contrôle d’accès créée au cours des étapes ci-dessus.
-
Cliquez sur Add New Rule, saisissez les paramètres souhaités pour la règle, puis cliquez sur Apply. Laissez le numéro de séquence vide afin de placer la règle à la fin de la liste. L'option “ Direction ” de “ Inbound ” est utilisée pour le trafic provenant du réseau sans fil et “ Outbound ” pour le trafic destiné aux clients sans fil. N’oubliez pas que la dernière règle d’une liste de contrôle d’accès est un refus total implicite. Utilisez une longueur de préfixe de 64 afin de correspondre à un sous-réseau IPv6 entier, et une longueur de préfixe de 128 pour limiter de manière unique l'accès à une adresse individuelle.
-
Les listes de contrôle d'accès IPv6 sont appliquées par WLAN/SSID et peuvent être utilisées simultanément sur plusieurs WLAN. Accédez à l'onglet WLAN et cliquez sur l'ID WLAN du SSID en question afin d'appliquer la liste de contrôle d'accès IPv6. Cliquez sur l'onglet Avancé et remplacez la liste de contrôle d'accès Override Interface pour IPv6 par le nom de la liste de contrôle d'accès.
Configurer l'accès invité IPv6 pour l'authentification Web externe
-
Configurez la liste de contrôle d'accès de pré-authentification IPv4 et IPv6 pour le serveur Web. Cela autorise le trafic en provenance et à destination du serveur externe avant que le client ne soit entièrement authentifié.
Pour plus d'informations sur le fonctionnement de l'accès Web externe, référez-vous à Exemple de configuration de l'authentification Web externe avec des contrôleurs de réseau local sans fil.
-
Configurez le WLAN invité en accédant à l'onglet WLAN en haut. Créez le SSID invité et utilisez une stratégie Web de couche 3. Les listes de contrôle d'accès pré-authentification définies à l'étape 1 sont sélectionnées pour IPv4 et IPv6. Cochez la section Configuration globale de remplacement et sélectionnez Externe dans la liste déroulante Type d'authentification Web. Saisissez l'URL du serveur Web. Le nom d'hôte du serveur externe doit pouvoir être résolu dans le DNS IPv4 et IPv6.
Configuration de la limitation de RA IPv6
-
Accédez au menu de niveau supérieur du contrôleur et cliquez sur l'option IPv6 > Stratégie d'accélération RA sur le côté gauche. Activez la limitation RA en cochant la case correspondante.
Remarque : lorsque la limitation RA se produit, seul le premier routeur compatible IPv6 est autorisé à passer. Pour les réseaux dont plusieurs préfixes IPv6 sont desservis par différents routeurs, la limitation de RA doit être désactivée.
-
Ajuster la période de régulation et les autres options uniquement en fonction du TAC. Cependant, la valeur par défaut est recommandée pour la plupart des déploiements. Les différentes options de configuration de la politique de limitation RA doivent être ajustées en gardant à l'esprit :
-
Les valeurs numériques de “ Autoriser au moins ” doivent être inférieures à “ Autoriser au plus ” qui doit être inférieur à “ Max Via ”.
-
La politique de limitation de RA ne doit pas utiliser une période de limitation supérieure à 1 800 secondes, car il s'agit de la durée de vie par défaut de la plupart des RA.
-
Chaque option de limitation de distance est décrite ci-dessous :
-
Période de régulation - Période de régulation. La limitation RA prend effet uniquement après que la limite de ” Max Through “ est atteinte pour le VLAN.
-
Max Through : nombre maximal d'adresses d'accès par VLAN avant que la limitation ne démarre. L'option “ No Limit ” permet un nombre illimité d'AR à travers sans limitation.
-
Option d'intervalle : l'option d'intervalle permet au contrôleur d'agir différemment en fonction de la valeur RFC 3775 définie dans l'annonce de routeur IPv6.
-
Passthrough (Passthrough) : cette valeur permet à tous les RA dotés d'une option d'intervalle RFC3775 de passer sans limitation.
-
Ignorer - Cette valeur entraînera le traitement des paquets avec l'option d'intervalle comme RA normal et sujette à limitation si elle est effective.
-
Throttle : cette valeur fera que les RA avec l'option interval seront toujours soumis à la limitation de débit.
-
-
Allow Au moins : nombre minimal d'adresses de routeur qui seront envoyées en multidiffusion.
-
Allow At-most (Autoriser au maximum) : nombre maximal d'RA par routeur qui seront envoyés en multidiffusion avant que la limitation ne prenne effet. L'option “ No Limit ” autorise un nombre illimité d'appels d'offres via pour ce routeur.
Configurer la table de liaison de voisinage IPv6
-
Accédez au menu de niveau supérieur du contrôleur et cliquez sur IPv6 > Minuteurs de liaison de voisinage dans le menu de gauche.
-
Ajustez la durée de vie, la durée de vie accessible et la durée de vie stable selon les besoins. Pour les déploiements avec des clients hautement mobiles, les temporisateurs d'un compteur d'adresses obsolètes doivent être modifiés. Les valeurs recommandées sont les suivantes :
-
Durée de vie inactive - 30 secondes
-
Durée de vie atteignable - 300 secondes
-
Durée de vie de l'état - 86 400 secondes
Chaque compteur de durée de vie fait référence à l'état dans lequel une adresse IPv6 peut se trouver :
-
Down Lifetime - Le minuteur down indique la durée de conservation des entrées de cache IPv6 en cas de panne de l'interface de liaison ascendante du contrôleur.
-
Durée de vie accessible - Ce compteur indique la durée pendant laquelle une adresse IPv6 sera marquée comme active, ce qui signifie que le trafic a été reçu récemment de cette adresse. Une fois que ce compteur expire, l'adresse est déplacée vers l'état “ Stale ”.
-
Stale Lifetime - Ce compteur indique la durée de conservation des adresses IPv6 dans le cache qui n'ont pas été vues dans le ” de durée de vie “ accessible. Après cette durée de vie, l'adresse est supprimée de la table de liaison.
-
Configuration du flux vidéo IPv6
-
Assurez-vous que les fonctionnalités Global VideoStream sont activées sur le contrôleur. Reportez-vous à Solution de réseau sans fil unifié Cisco : Guide de déploiement de VideoStream pour plus d'informations sur l'activation de VideoStream sur le réseau 802.11a/g/n ainsi que sur le SSID WLAN.
-
Accédez à l'onglet Sans fil du contrôleur et dans le menu de gauche, sélectionnez Flux multimédia > Flux. Cliquez sur Add New afin de créer un nouveau flux.
-
Nommez le flux et entrez les adresses IPv6 de début et de fin. Lorsque vous utilisez un seul flux, les adresses de début et de fin sont égales. Après avoir ajouté les adresses, cliquez sur Apply afin de créer le flux.
Dépannage de la connectivité du client IPv6
Certains clients ne peuvent pas transmettre le trafic IPv6
Certaines mises en oeuvre de la pile réseau IPv6 du client ne s'annoncent pas correctement lorsqu'elles arrivent sur le réseau et, par conséquent, leur adresse n'est pas correctement vérifiée par le contrôleur pour être placée dans la table de liaison de voisin. Toutes les adresses qui ne figurent pas dans la table de liaison de voisinage sont bloquées conformément à la fonctionnalité de protection de la source IPv6. Afin de permettre à ces clients de transmettre le trafic, ces options doivent être configurées :
-
Désactivez la fonction de protection de source IPv6 via l'interface de ligne de commande :
config network ip-mac-binding disable
-
Activez le transfert de sollicitation de voisin multidiffusion via l'interface de ligne de commande :
config ipv6 ns-mcast-fwd enable
Vérification de l'itinérance de couche 3 réussie pour un client IPv6 :
Émettez ces commandes de débogage sur le contrôleur d'ancrage et le contrôleur étranger :
debug client
debug mobility handoff enable
debug mobility packet enable
Résultats du débogage sur le contrôleur d'ancrage :
00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) State Update from Mobility-Complete to Mobility-Incomplete 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Setting handles to 0x00000000 00:21:6a:a7:4f:ee pemApfDeleteMobileStation2: APF_MS_PEM_WAIT_L2_AUTH_COMPLETE = 0. 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Deleted mobile LWAPP rule on AP [04:fe:7f:49:03:30] 00:21:6a:a7:4f:ee Updated location for station old AP 04:fe:7f:49:03:30-1, new AP 00:00:00:00:00:00-0 00:21:6a:a7:4f:ee Stopping deletion of Mobile Station: (callerId: 42) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Anchor, client state=APF_MS_STATE_ASSOCIATED 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Reached PLUMBFASTPATH: from line 4968 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Adding Fast Path rule type = Airespace AP Client on AP 00:00:00:00:00:00, slot 0, interface = 13, QOS = 0 IPv4 ACL ID = 255, IPv6 ACL ID = 255, 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 20, Local Bridging intf id = 13 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee 0.0.0.0 Removed NPU entry. 00:21:6a:a7:4f:ee Set symmetric mobility tunnel for 00:21:6a:a7:4f:ee as in Anchor role 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 1, dtlFlags 0x1 00:21:6a:a7:4f:ee Pushing IPv6: fe80:0000:0000:0000: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee Pushing IPv6: 2001:0db8:0000:0020: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee 0.0.0.0, VLAN Id 20 Not sending gratuitous ARP 00:21:6a:a7:4f:ee Copy AP LOCP - mode:0 slotId:0, apMac 0x0:0:0:0:0:0 00:21:6a:a7:4f:ee Copy WLAN LOCP EssIndex:3 aid:0 ssid: Roam 00:21:6a:a7:4f:ee Copy Security LOCP ecypher:0x0 ptype:0x2, p:0x0, eaptype:0x6 w:0x1 aalg:0x0, PMState: RUN 00:21:6a:a7:4f:ee Copy 802.11 LOCP a:0x0 b:0x0 c:0x0 d:0x0 e:0x0 protocol2:0x5 statuscode 0, reasoncode 99, status 3 00:21:6a:a7:4f:ee Copy CCX LOCP 4 00:21:6a:a7:4f:ee Copy e2e LOCP 0x1 00:21:6a:a7:4f:ee Copy MobilityData LOCP status:2, anchorip:0xac14e2c6 00:21:6a:a7:4f:ee Copy IPv6 LOCP: fe80::3057:534d:587d:73ae
Résultats du débogage sur le contrôleur étranger :
00:21:6a:a7:4f:ee Adding mobile on LWAPP AP f0:25:72:3c:0f:20(1) 00:21:6a:a7:4f:ee Reassociation received from mobile on AP f0:25:72:3c:0f:20 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:1697) 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:1864) 00:21:6a:a7:4f:ee Applying site-specific Local Bridging override for station 00:21:6a:a7:4f:ee - vapId 3, site 'default-group', interface 'client-b1' 00:21:6a:a7:4f:ee Applying Local Bridging Interface Policy for station 00:21:6a:a7:4f:ee - vlan 25, interface id 12, interface 'client-b1' 00:21:6a:a7:4f:ee processSsidIE statusCode is 0 and status is 0 00:21:6a:a7:4f:ee processSsidIE ssid_done_flag is 0 finish_flag is 0 00:21:6a:a7:4f:ee STA - rates (8): 140 18 152 36 176 72 96 108 0 0 0 0 0 0 0 0 *apfMsConnTask_4: Jan 22 20:37:45.370: 00:21:6a:a7:4f:ee suppRates statusCode is 0 and gotSuppRatesElement is 1 00:21:6a:a7:4f:ee Processing RSN IE type 48, length 22 for mobile 00:21:6a:a7:4f:ee 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Initializing policy 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state AUTHCHECK (2) 00:21:6a:a7:4f:ee 0.0.0.0 AUTHCHECK (2) Change state to 8021X_REQD (3) last state 8021X_REQD (3) 00:21:6a:a7:4f:ee 0.0.0.0 8021X_REQD (3) DHCP Not required on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3for this client 00:21:6a:a7:4f:ee Not Using WMM Compliance code qosCap 00 00:21:6a:a7:4f:ee 0.0.0.0 8021X_REQD (3) Plumbed mobile LWAPP rule on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3 00:21:6a:a7:4f:ee apfMsAssoStateInc 00:21:6a:a7:4f:ee apfPemAddUser2 (apf_policy.c:268) Changing state for mobile 00:21:6a:a7:4f:ee on AP f0:25:72:3c:0f:20 from Idle to Associated 00:21:6a:a7:4f:ee Scheduling deletion of Mobile Station: (callerId: 49) in 1800 seconds 00:21:6a:a7:4f:ee Sending Assoc Response to station on BSSID f0:25:72:3c:0f:20 (status 0) ApVapId 3 Slot 1 00:21:6a:a7:4f:ee apfProcessAssocReq (apf_80211.c:6290) Changing state for mobile 00:21:6a:a7:4f:ee on AP f0:25:72:3c:0f:20 from Associated to Associated <…SNIP…> 00:21:6a:a7:4f:ee 0.0.0.0 8021X_REQD (3) Change state to L2AUTHCOMPLETE (4) last state L2AUTHCOMPLETE (4) 00:21:6a:a7:4f:ee 0.0.0.0 L2AUTHCOMPLETE (4) DHCP Not required on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3for this client 00:21:6a:a7:4f:ee Not Using WMM Compliance code qosCap 00 00:21:6a:a7:4f:ee 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3 00:21:6a:a7:4f:ee 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state DHCP_REQD (7) 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 5253, Adding TMP rule 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule type = Airespace AP - Learn IP address on AP f0:25:72:3c:0f:20, slot 1, interface = 13, QOS = 0 IPv4 ACL ID = 255, IP 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 25, Local Bridging intf id = 12 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee Stopping retransmission timer for mobile 00:21:6a:a7:4f:ee 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0 00:21:6a:a7:4f:ee Sent an XID frame 00:21:6a:a7:4f:ee Username entry () already exists in name table, length = 253 00:21:6a:a7:4f:ee Username entry () created in mscb for mobile, length = 253 00:21:6a:a7:4f:ee Applying post-handoff policy for station 00:21:6a:a7:4f:ee - valid mask 0x1000 00:21:6a:a7:4f:ee QOS Level: -1, DSCP: -1, dot1p: -1, Data Avg: -1, realtime Avg: -1, Data Burst -1, Realtime Burst -1 00:21:6a:a7:4f:ee Session: -1, User session: -1, User elapsed -1 Interface: N/A, IPv4 ACL: N/A, IPv6 ACL: 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Change state to DHCP_REQD (7) last state DHCP_REQD (7) 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) pemCreateMobilityState 6370, Adding TMP rule 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Replacing Fast Path rule type = Airespace AP - Learn IP address on AP f0:25:72:3c:0f:20, slot 1, interface = 13, QOS = 0 IPv4 ACL ID = 255, 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 25, Local Bridging intf id = 12 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee Scheduling deletion of Mobile Station: (callerId: 55) in 1800 seconds 00:21:6a:a7:4f:ee Pushing IPv6: fe80:0000:0000:0000: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee apfMsRunStateInc 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Reached PLUMBFASTPATH: from line 5776 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee Pushing IPv6: 2001:0db8:0000:0020: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Foreign, client state=APF_MS_STATE_ASSOCIATED 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Reached PLUMBFASTPATH: from line 4968 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Replacing Fast Path rule type = Airespace AP Client on AP f0:25:72:3c:0f:20, slot 1, interface = 13, QOS = 0 IPv4 ACL ID = 255, IPv6 ACL ID = 25 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 25, Local Bridging intf id = 12 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0 00:21:6a:a7:4f:ee Set symmetric mobility tunnel for 00:21:6a:a7:4f:ee as in Foreign role 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 1, dtlFlags 0x1 00:21:6a:a7:4f:ee Pushing IPv6: fe80:0000:0000:0000: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee Pushing IPv6: 2001:0db8:0000:0020: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee Copy AP LOCP - mode:0 slotId:1, apMac 0xf0:25:72:3c:f:20 00:21:6a:a7:4f:ee Copy WLAN LOCP EssIndex:3 aid:1 ssid: Roam 00:21:6a:a7:4f:ee Copy Security LOCP ecypher:0x0 ptype:0x2, p:0x0, eaptype:0x6 w:0x1 aalg:0x0, PMState: RUN 00:21:6a:a7:4f:ee Copy 802.11 LOCP a:0x0 b:0x0 c:0x0 d:0x0 e:0x0 protocol2:0x7 statuscode 0, reasoncode 99, status 3 00:21:6a:a7:4f:ee Copy CCX LOCP 4 00:21:6a:a7:4f:ee Copy e2e LOCP 0x1 00:21:6a:a7:4f:ee Copy MobilityData LOCP status:3, anchorip:0xac14e2c5 00:21:6a:a7:4f:ee Copy IPv6 LOCP: fe80::3057:534d:587d:73ae 00:21:6a:a7:4f:ee Copy IPv6 LOCP: 2001:db8:0:20:3057:534d:587d:73ae
Commandes de CLI IPv6 utiles :
Show ipv6 neighbor-binding summary
Debug ipv6 neighbor-binding filter client
Debug ipv6 neighbor-binding filter errors enable
Forum aux questions
Q : Quelle est la taille de préfixe IPv6 optimale afin de limiter le domaine de diffusion ?
A : Bien qu'un sous-réseau IPv6 puisse être subdivisé en dessous d'un /64, cette configuration va rompre SLAAC et provoquer des problèmes de connectivité client. Si la segmentation est nécessaire pour réduire le nombre d'hôtes, la fonctionnalité Groupes d'interfaces peut être utilisée pour équilibrer la charge des clients entre différents VLAN back-end, chacun utilisant un préfixe IPv6 différent.
Q : Existe-t-il des limitations d'évolutivité en ce qui concerne la prise en charge des clients IPv6 ?
A : La principale limite d'évolutivité pour la prise en charge des clients IPv6 est la table de liaison de voisin qui assure le suivi de toutes les adresses IPv6 des clients sans fil. Cette table est mise à l'échelle par plate-forme de contrôleur afin de prendre en charge le nombre maximal de clients multiplié par huit (le nombre maximal d'adresses par client). L'ajout de la table de liaison IPv6 peut augmenter l'utilisation de la mémoire du contrôleur d'environ 10 à 15 % sous charge totale, selon la plate-forme.
| Contrôleur sans fil | Nombre maximal de clients | Taille de table de liaison de voisinage IPv6 |
|---|---|---|
| 2500 | 500 | 4,000 |
| 5500 | 7,000 | 56,000 |
| WiSM2 | 15,000 | 120,000 |
Q : Quel est l'impact des fonctionnalités IPv6 sur le processeur et la mémoire du contrôleur ?
A : L'impact est minime car le processeur a plusieurs coeurs pour le traitement du plan de contrôle. Lors d'un test avec le maximum de clients pris en charge, chacun avec 8 adresses IPv6, l'utilisation du CPU était inférieure à 30 % et l'utilisation de la mémoire inférieure à 75 %.
Q : La prise en charge du client IPv6 peut-elle être désactivée ?
A : Pour les clients qui souhaitent activer uniquement IPv4 dans leur réseau et bloquer IPv6, une liste de contrôle d'accès IPv6 de refuser tout le trafic peut être utilisée et appliquée sur la base de chaque WLAN.
Q : Est-il possible d'avoir un WLAN pour IPv4 et un autre pour IPv6 ?
A : Il n'est pas possible d'avoir le même nom SSID et le même type de sécurité pour deux WLAN différents fonctionnant sur le même AP. Pour la segmentation des clients IPv4 des clients IPv6, deux WLAN doivent être créés. Chaque WLAN doit être configuré avec une liste de contrôle d'accès qui bloque tout le trafic IPv4 ou IPv6 respectivement.
Q : Pourquoi est-il important de prendre en charge plusieurs adresses IPv6 par client ?
A : Les clients peuvent avoir plusieurs adresses IPv6 par interface qui peuvent être statiques, SLAAC ou DHCPv6 attribuées en plus d'avoir toujours une adresse link-local auto-attribuée. Les clients peuvent également disposer d'adresses supplémentaires à l'aide de préfixes IPv6 différents.
Q : Que sont les adresses privées IPv6 et pourquoi sont-elles importantes à suivre ?
A : Les adresses privées (également appelées temporaires) sont générées aléatoirement par le client lorsque l'affectation d'adresses SLAAC est utilisée. Ces adresses sont souvent tournées à une fréquence d’un jour ou plus, afin d’empêcher la traçabilité de l’hôte qui proviendrait de l’utilisation du même postfix hôte (les 64 derniers bits) à tout moment. Il est important de suivre ces adresses privées à des fins d'audit, telles que le suivi des violations de droits d'auteur. Cisco NCS enregistre toutes les adresses IPv6 utilisées par chaque client et les consigne historiquement chaque fois que le client se déplace ou établit une nouvelle session. Ces enregistrements peuvent être configurés sur NCS pour être conservés pendant un an maximum.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)