Guide Sans fil de déploiement de client d'IPv6 de RÉSEAU LOCAL

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é de client sans fil d'IPv6

Le positionnement de caractéristique d'IPv6 dans la version logicielle v7.2 de réseau sans fil unifié Cisco permet au réseau Sans fil pour prendre en charge des clients d'ipv4, de Double-pile, et IPv6-only sur le même réseau Sans fil. Le but global pour l'ajout du support de client d'IPv6 au RÉSEAU LOCAL de Cisco Unified Wireless était de mettre à jour la parité de caractéristique entre les clients d'ipv4 et d'IPv6 comprenant la mobilité, la Sécurité, l'accès invité, la qualité de service, et la visibilité de point final.

Jusqu'à huit adresses du client d'IPv6 peuvent être dépistées par périphérique. Ceci permet à des clients d'IPv6 pour avoir des lien-gens du pays, une adresse automatique de la configuration d'adresse sans état (SLAAC), un protocole DHCP pour l'adresse de l'IPv6 (DHCPv6), et même des adresses dans des préfixes alternatifs à être sur une interface unique. Les clients de la passerelle de groupe de travail (WGB) connectés à la liaison ascendante d'un point d'accès autonome (AP) en mode WGB peuvent également prendre en charge l'IPv6.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Gamme 2500 Sans fil, gamme 5500, ou WiSM2 de contrôleurs LAN

• Aps 1130, 1240, 1250, 1040, 1140, 1260, 3500, gamme 3600 aps, et gamme 1520 ou 1550 engrènent des aps

• Routeur IPv6-capable

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Préalables à la Connectivité Sans fil de client d'IPv6

Afin d'activer la Connectivité Sans fil de client d'IPv6, le réseau câblé sous-jacent doit prendre en charge l'acheminement d'IPv6 et un mécanisme d'affectation d'adresses tel que SLAAC ou DHCPv6. Le contrôleur LAN Sans fil doit avoir la contiguïté L2 au routeur d'IPv6, et le VLAN doit être étiqueté quand les paquets entrent dans le contrôleur. Les aps n'exigent pas la Connectivité sur un réseau d'IPv6, car tout le trafic est encapsulé à l'intérieur du tunnel de l'ipv4 CAPWAP entre AP et le contrôleur.

Affectation d'adresses SLAAC

La plupart de méthode classique pour l'affectation d'adresse du client d'IPv6 est SLAAC. SLAAC fournit la Connectivité prête à l'emploi simple où les clients auto-assignent une adresse basée sur le préfixe d'IPv6. Ce processus est réalisé quand le routeur d'IPv6 envoie les messages périodiques de publicité de routeur qui informent le client du préfixe d'IPv6 en service (les 64 premiers bits) et de la passerelle par défaut d'IPv6. De ce point, les clients peuvent générer les 64 bits demeurants de leur ipv6 addres basé sur deux algorithmes : EUI-64 qui est basé sur l'adresse MAC de l'interface, ou adresses privées qui sont aléatoirement générées. Le choix de l'algorithme incombe au client et est souvent configurable. La détection d'adresse en double est exécutée par des clients d'IPv6 afin de s'assurer que les adresses aléatoires qui sont sélectionnées ne vous heurtez pas d'autres clients. L'adresse du routeur envoyant des annonces est utilisée comme passerelle par défaut pour le client.

Ces commandes de configuration de Cisco IOS® d'un routeur Cisco-capable d'IPv6 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

Affectation d'adresses DHCPv6

L'utilisation de DHCPv6 n'est pas exigée pour la Connectivité de client d'IPv6 si SLAAC est déjà déployé. Il y a deux modes de fonctionnement pour Stateless et avec état appelés par DHCPv6.

Le mode DHCPv6 sans état est utilisé pour fournir à des clients l'information réseau supplémentaire non disponible dans la publicité de routeur, mais pas un ipv6 addres en tant que ceci n'est déjà fourni par SLAAC. Ces informations peuvent inclure les serveurs de DN nom de domaine, de DN, et d'autres options de constructeur-particularité DHCP. Cette configuration d'interface est pour un routeur d'IPv6 de Cisco IOS mettant en application 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 de l'avec état DHCPv6, également connue sous le nom de mode géré, fonctionne pareillement à DHCPv4 parce qu'elle assigne 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 pour un avec état DHCPv6 de routeur d'IPv6 de Cisco IOS met en application 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

Configurer le réseau câblé pour la Connectivité de la taille du campus d'IPv6 complet utilisant la double-pile ou le perçage d'un tunnel des méthodes de Connectivité est hors de portée de ce document. Le pour en savoir plus se rapportent au guide de déploiement validé par Cisco déployant l'IPv6 dans les réseaux campus.

Mobilité de client d'IPv6

Afin d'avoir affaire avec des clients d'IPv6 d'itinérance à travers des contrôleurs, les messages d'ICMPv6 tels que la sollicitation voisine (NS), la publicité voisine (NA), la publicité de routeur (RA), et le routeur que la sollicitation (RS) doit être traitée particulièrement afin d'assurer un client demeure sur le même réseau de la couche 3. La configuration pour la mobilité d'IPv6 est identique que pour la mobilité d'ipv4 et n'exige d'aucun logiciel distinct sur le côté client de réaliser l'itinérance sans couture. La seule configuration exigée est que les contrôleurs doivent faire partie du même groupe de mobilité/domaine.

Voici le processus pour la mobilité de client d'IPv6 à travers des contrôleurs :

1. Si les deux contrôleurs ont accès au même VLAN le client était initialement en fonction, l'errer est simplement un événement errant de la couche 2 où l'enregistrement de client est copié sur le nouveau contrôleur et aucun trafic n'est percé un tunnel de nouveau au contrôleur d'ancre.

2. Si le deuxième contrôleur n'a pas accès à l'original VLAN le client était en ligne, un événement errant de la couche 3 se produira, signifiant que tout le trafic du client doit être percé un tunnel par l'intermédiaire du tunnel de mobilité (Ethernet au-dessus d'IP) au contrôleur d'ancre.

   1. Afin d'assurer le client retient son ipv6 addres d'origine, le RAs de l'original VLAN sont envoyés par le contrôleur d'ancre au contrôleur étranger où ils sont livrés au client utilisant l'unicast L2 d'AP.

   2. Quand le client d'itinérance va renouveler son adresse par l'intermédiaire de DHCPv6 ou générer une nouvelle adresse par l'intermédiaire de SLAAC, des paquets RS, NA, et NS continuez à être percé un tunnel à l'original VLAN ainsi le client recevra un ipv6 addres qui s'applique à ce VLAN.

Remarque: La mobilité pour des clients IPv6-only est basée sur les informations VLAN. Ceci signifie que la mobilité de client IPv6-only n'est pas prise en charge sur des VLAN non balisés.

Soutien du VLAN choisi (groupes d'interface)

La caractéristique de groupes d'interface permet à une organisation pour avoir un WLAN simple avec des VLAN multiples configurés sur le contrôleur afin de permettre l'Équilibrage de charge des clients sans fil à travers ces VLAN. Cette caractéristique est utilisée généralement pour maintenir des tailles de sous-réseau d'ipv4 petites tout en permettant à un WLAN de mesurer aux milliers d'utilisateurs à travers des VLAN multiples dans le groupe. Afin de prendre en charge des clients d'IPv6 avec des groupes d'interface, aucune configuration supplémentaire n'est exigée pendant que le système envoie automatiquement le RA correct aux clients corrects par l'intermédiaire de l'unicast de la radio L2. Par unicasting le RA, les clients sur le même WLAN, mais un VLAN différent, ne reçoivent pas le RA incorrect.

D'abord Sécurité de saut pour des clients d'IPv6

Protection de publicité de routeur

La caractéristique de protection de RA augmente la Sécurité du réseau d'IPv6 en relâchant RAs provenant des clients sans fil. Sans clients misconfigured ou malveillants de cette caractéristique, d'IPv6 pourrait s'annoncer en tant que routeur pour le réseau, souvent avec une haute priorité qui pourrait avoir la priorité au-dessus des Routeurs légitimes d'IPv6.

Par défaut, la protection de RA est activée à AP (mais peut être désactivé à AP) et est toujours activée sur le contrôleur. RAs de baisse à AP est préféré car c'est plus de solution évolutive et fournit les compteurs améliorés de baisse de RA de par-client. Dans des tous les cas, le RA d'IPv6 sera lâché à un certain point, protégeant d'autres clients sans fil et réseau câblé en amont contre les clients malveillants ou misconfigured d'IPv6.

Protection du serveur DHCPv6

La caractéristique de protection du serveur DHCPv6 empêche des clients sans fil des adresses de distribution d'IPv6 à d'autres clients sans fil ou clients câblés en amont. Afin d'empêcher les adresses DHCPv6 d'être distribuée, n'importe quels DHCPv6 annoncent des paquets des clients sans fil sont relâchés. Cette caractéristique traite le contrôleur, n'exige aucune configuration et est activée automatiquement.

Protection de source d'IPv6

La caractéristique de protection de source d'IPv6 empêche un client sans fil charriant un ipv6 addres d'un autre client. Cette caractéristique est analogue à la protection de source d'ipv4. La protection de source d'IPv6 est activée par défaut mais peut être désactivée par l'intermédiaire du CLI.

Comptabilité d'ipv6 addres

Pour l'authentification et la comptabilité de RADIUS, le contrôleur renvoie une adresse IP utilisant l'attribut de « Encadrer-IP-adresse ». L'ipv4 addres est utilisé dans ce cas.

L'attribut de « calling-station-id » emploie cet algorithme afin de renvoyer une adresse IP quand « le type d'ID de station d'appel » sur le contrôleur est configuré à la « adresse IP » :

1. Ipv4 addres

2. Ipv6 addres global d'Unicast

3. Ipv6 addres de gens du pays de lien

Puisque les adresses d'IPv6 de client peuvent changer souvent (des adresses provisoires ou privées), il est important de les dépister au fil du temps. Cisco NCS enregistre toutes les adresses d'IPv6 en service par chaque client et se connecte historiquement les chaque fois que le client erre ou établit une nouvelle session. Ces enregistrements peuvent être configurés à NCS à tenir pendant jusqu'à une année.

Remarque: La valeur par défaut pour « le type d'ID de station d'appel » sur le contrôleur a été changée à la « adresse MAC de système » dans la version 7.2. En améliorant, ceci devrait être changé pour permettre le seul cheminement des clients par l'adresse MAC pendant que les adresses d'IPv6 peuvent changer la mid-session et entraîner des questions en comptabilité si le calling-station-id est placé à l'adresse IP.

Listes de contrôle d'accès d'IPv6

Afin de limiter l'accès aux ressources de câble certain par en amont ou bloquer certaines applications, le Listes de contrôle d'accès (ACL) d'IPv6 peut être utilisé pour identifier le trafic et pour le permettre ou refuser. Support d'ACLs d'IPv6 les mêmes options que l'ipv4 ACLs comprenant la source, la destination, le port de source, et la destination port (des plages de port sont également prises en charge). la Pré-authentification ACLs sont également prises en charge pour prendre en charge l'authentification d'invité d'IPv6 utilisant un web server externe. Le contrôleur sans-fil prend en charge jusqu'à 64 seuls IPv6 ACLs avec 64 seules règles dans chacun. Le contrôleur sans-fil continue à prendre en charge des 64 seuls ipv4 supplémentaire ACLs avec 64 seules règles dans chacun pour un total de 128 ACLs pour un client de double-pile.

Dépassement d'AAA pour l'IPv6 ACLs

Afin de prendre en charge a centralisé le contrôle d'accès par un serveur centralisé d'AAA tel que le Logiciel Cisco Identity Services Engine (ISE) ou ACS, l'ACL d'IPv6 peut provisioned sur une base de par-client utilisant des attributs de priorité d'AAA. Afin d'utiliser cette caractéristique, l'ACL d'IPv6 doit être configuré sur le contrôleur et le WLAN doit être configuré avec la fonction activée de priorité d'AAA. L'aaa attribute Désigné réel pour un ACL d'IPv6 est Airespace-IPv6-ACL-Name semblables à l'attribut d'Airespace-ACL-nom utilisé pour le ravitaillement un ACL IPv4-based. Le contenu retourné par aaa attribute devrait être une chaîne égale au nom de l'ACL d'IPv6 comme configuré sur le contrôleur.

Optimisation de paquet pour des clients d'IPv6

Mise en cache voisine de détection

Le protocole de détection d'ipv6 neighbor (NDP) utilise des paquets NA et NS au lieu du Protocole ARP (Address Resolution Protocol) afin de permettre à des clients d'IPv6 pour résoudre l'adresse MAC d'autres clients sur le réseau. Le processus NDP peut être très bavard pendant qu'il emploie au commencement des adresses de multidiffusion pour exécuter l'address resolution ; ceci peut consommer l'importante diffusion Sans fil pendant que les paquets de multidiffusion sont envoyés à tous les clients sur le segment de réseau.

Afin d'augmenter l'efficacité du processus NDP, la mise en cache voisine de détection permet au contrôleur pour agir en tant que proxy et pour répondre de nouveau aux requêtes NS qu'il peut résoudre. La mise en cache voisine de détection est rendue possible par la table de corrélation voisine sous-jacente actuelle dans le contrôleur. La table de corrélation voisine maintient chaque ipv6 addres et son adresse MAC associée. Quand des tentatives d'un client d'IPv6 de résoudre l'adresse de couche liaison d'un autre client, le paquet NS est interceptées par le contrôleur qui répond de retour avec un paquet NA.

Étranglement de publicité de routeur

Le routeur que l'étranglement de publicité permet au contrôleur pour imposer la limitation de débit de RAs s'est dirigé vers le réseau Sans fil. En activant le RA étranglant, des Routeurs qui sont configurés pour envoyer RAs très souvent (par exemple, toutes les trois secondes) peuvent être équilibrés de nouveau à une fréquence minimum qui mettra à jour toujours la Connectivité de client d'IPv6. Ceci permet la diffusion à optimiser en réduisant le nombre de paquets de multidiffusion qui doivent être envoyés. Dans des tous les cas, si un client envoie un RS, puis on permettra un RA par le contrôleur et l'unicast au client de demande. C'est de s'assurer que de nouveaux clients ou clients d'itinérance ne sont pas négativement affectés par l'étranglement de RA.

Accès invité d'IPv6

La radio et les caractéristiques de câble d'invité actuelles pour des clients d'ipv4 fonctionnent de la même manière pour la double-pile et les clients IPv6-only. Une fois que l'utilisateur d'invité s'associe, ils sont placés dans un état de passage « WEB_AUTH_REQ » jusqu'à ce que le client soit authentifié par l'intermédiaire du portail captif d'ipv4 ou d'IPv6. Le contrôleur interceptera le trafic d'ipv4 et d'IPv6 HTTP/HTTPS dans cet état et le réorientera à l'adresse IP virtuelle du contrôleur. Une fois que l'utilisateur est authentifié par l'intermédiaire du portail captif, leur adresse MAC est déplacée à l'état de passage et le trafic d'ipv4 et d'IPv6 est permis pour passer. Pour l'authentification de Web externe, l'ACL de pré-authentification permet un web server externe à utiliser.

Afin de prendre en charge la redirection des clients IPv6-only, le contrôleur crée automatiquement une adresse virtuelle d'IPv6 basée hors fonction de l'ipv4 virtual addres configuré sur le contrôleur. L'ipv6 addres virtuel suit la convention de [: : ffff : Address> <virtual d'ipv4]. Par exemple, une adresse IP virtuelle de 1.1.1.1 se traduirait à [::ffff:1.1.1.1].

En utilisant un certificat ssl de confiance pour l'authentification d'accès invité, assurez-vous que l'adresse virtuelle d'ipv4 et d'IPv6 du contrôleur est définie dans des DN pour apparier l'adresse Internet de Certificats SSL. Ceci s'assure que les clients ne reçoivent pas une alerte de sécurité déclarant que le certificat n'apparie pas l'adresse Internet du périphérique.

Remarque: Le certificat ssl automatique-généré du contrôleur ne contient pas l'adresse virtuelle d'IPv6. Ceci peut faire présenter quelques navigateurs Web une alerte de sécurité. Utilisant un certificat ssl de confiance pour l'accès invité est recommandé.

IPv6 VideoStream

VideoStream active la livraison visuelle de Multidiffusion Sans fil fiable et extensible, envoyant à chaque client le flot dans un format d'unicast. La Multidiffusion réelle à la conversion d'unicast (de L2) se produit à AP fournissant une solution évolutive. Le contrôleur envoie à l'IPv6 le trafic visuel à l'intérieur d'un tunnel de Multidiffusion de l'ipv4 CAPWAP qui permet la distribution du réseau efficace à AP.

Qualité de service d'IPv6

Les paquets d'IPv6 utilisent un marquage semblable à l'utilisation IPv4 des valeurs DSCP prenant en charge jusqu'à 64 classes différentes du trafic (0-63). Pour les paquets en aval du réseau câblé, la valeur de classe du trafic d'IPv6 est copiée sur l'en-tête du tunnel CAPWAP afin de s'assurer que QoS est de bout en bout préservé. Dans la direction en amont, le même se produit car le trafic de client marqué à la couche 3 avec la classe du trafic d'IPv6 sera honoré en marquant les paquets CAPWAP destinés pour le contrôleur.

IPv6 et FlexConnect

FlexConnect – Commutation locale WLAN

FlexConnect en mode de commutation locale prend en charge des clients d'IPv6 en jetant un pont sur le trafic aux gens du pays VLAN, semblables à l'exécution d'ipv4. La mobilité de client est prise en charge pour la couche 2 errant à travers le groupe de FlexConnect.

Ces caractéristiques IPv6-specific sont prises en charge en mode de commutation locale de FlexConnect :

• Protection de RA d'IPv6

• Transition d'IPv6

• Authentification d'invité d'IPv6 (contrôleur-hébergée)

Ces caractéristiques IPv6-specific ne sont pas prises en charge en mode de commutation locale de FlexConnect :

• Mobilité de la couche 3

• IPv6 VideoStream

• Listes de contrôle d'accès d'IPv6

• Protection de source d'IPv6

• Protection du serveur DHCPv6

• Mise en cache voisine de détection

• Étranglement de publicité de routeur

FlexConnect – WLAN de changement centraux

Pour des aps en mode de FlexConnect utilisant la commutation centrale (le trafic de Tunnellisation de nouveau au contrôleur), le contrôleur doit être placé à la « Multidiffusion - mode d'Unicast » pour « le mode de Multidiffusion AP ». Puisque FlexConnect aps ne joignent pas le groupe de multidiffusion CAPWAP du contrôleur, des paquets de multidiffusion doivent être répliqués au contrôleur et à l'unicast vers chaque AP individuellement. Cette méthode est moins efficace que la « Multidiffusion - mode de Multidiffusion » et chargement supplémentaire d'endroits sur le contrôleur.

Cette caractéristique IPv6-specific n'est pas prise en charge en mode central de commutation de FlexConnect :

• IPv6 VideoStream

Remarque: L'IPv6 courant centralement commuté WLAN ne sont pas pris en charge sur le contrôleur de gamme 7500 de flexible.

Visibilité de clients d'IPv6 avec NCS

Avec la release de NCS v1.1, beaucoup de capacités spécifiques d'IPv6 supplémentaire sont ajoutées pour surveiller et gérer un réseau des clients d'IPv6 sur les réseaux de câble et Sans fil.

Éléments de tableau de bord d'IPv6

Afin de visualiser quels types de clients sont présents sur le réseau, un « Dashlet » dans NCS est disponible afin de fournir la vue dans des statistiques spécifiques d'IPv6 et offrir la capacité pour effectuer un zoom avant dans l'IPv6 des clients.

Type Dashlet d'adresse IP - Affiche les types de clients IP sur le réseau :

Compte de client par le type d'adresse IP - Affiche le type de client IP au fil du temps :

Le trafic de client par le type d'adresse IP - Affiche le trafic de chaque type de client. Les clients dans la catégorie de double-pile incluent le trafic d'ipv4 et d'IPv6 :

Affectation d'ipv6 addres - Affiche la méthode d'affectation d'adresses pour chaque client en tant qu'une de ces quatre catégories :

• DHCPv6 - Pour des clients avec des adresses assignées par un serveur central. Le client peut également avoir une adresse SLAAC aussi bien.

• SLAAC ou charge statique - Pour des clients utilisant l'affectation automatique d'adresse sans état ou utilisant des adresses statiquement configurées.

• Inconnu - Dans certains cas, l'affectation d'ipv6 addres ne peut pas être découverte.

  • Cette condition se produit seulement sur des clients câblés dans NCS car quelques Commutateurs ne pillent pas les informations d'affectation d'ipv6 addres.

• Avec auto-assignation - Pour des clients avec seulement une adresse locale à la liaison qui est entièrement avec auto-assignation.

  • Les clients dans cette catégorie peuvent avoir des problèmes de connectivité d'IPv6 puisqu'ils manquent d'une seule ou locale adresse unique globale.

Chacune des sections du graphique à secteurs est clickable, qui permet à l'administrateur pour effectuer un zoom avant à une liste de clients.

Surveillez les clients d'IPv6

Afin de surveiller et gérer les informations de client d'IPv6, ces colonnes ont été ajoutées à la page de clients et d'utilisateurs :

• Type IP - Le type de client basé sur quelles adresses IP ont été vues du client. Les choix possibles sont ipv4, IPv6, ou Double-pile qui signifie un client avec les deux adresses d'ipv4 et d'IPv6.

• Type d'affectation d'IPv6 - La méthode d'affectation d'adresses est détectée par NCS en tant qu'ou SLAAC ou statique, DHCPv6, avec auto-assignation, ou inconnu.

• Seuls globaux - L'adresse globale d'IPv6 la plus récente utilisée par le client. A souris-au-dessus de sur contenu de colonne indique toutes les adresses uniques globales d'IPv6 supplémentaire utilisées par le client.

• Gens du pays seuls - L'adresse unique locale de l'IPv6 le plus récent utilisée par le client. Une souris plus de sur le contenu de colonne indique toutes les adresses uniques globales d'IPv6 supplémentaire utilisées par le client.

• Gens du pays de lien - L'ipv6 addres du client qui est avec auto-assignation et utilisé pour la transmission avant que tout autre ipv6 addres soit assigné.

• Annonces de routeur lâchées - Le nombre d'annonces de routeur envoyées par le client et relâchées à AP. Cette colonne peut être utilisée pour dépister les clients qui peuvent misconfigured ou avec malveillance configurés pour agir comme un routeur d'IPv6. Cette colonne est classable, qui permet les clients offensants à identifier facilement.

En plus d'afficher les colonnes spécifiques d'IPv6, la colonne d'adresse IP affichera que l'adresse IP actuelle du client avec une priorité affichait l'ipv4 addres d'abord (dans le cas d'un client de Double-pile) ou l'adresse unique globale d'IPv6 dans le cas d'un client IPv6-only.

Configuration pour le support Sans fil de client d'IPv6

Mode de distribution de Multidiffusion aux aps

Le réseau sans fil unifié Cisco prend en charge deux méthodes de distribution de Multidiffusion aux aps associés au contrôleur. En les deux modes, le paquet de multidiffusion d'origine du réseau câblé est encapsulé à l'intérieur d'un paquet de la couche 3 CAPWAP envoyé par l'intermédiaire de CAPWAP Unicast ou de Multidiffusion à AP. Puisque le trafic est CAPWAP encapsulé, les aps ne doivent pas être sur le même VLAN que le trafic de client. Les deux méthodes de distribution de Multidiffusion sont comparées ici :

	Mode Multicast-unicast	Mode de Multidiffusion-Multidiffusion
Mécanisme de mise en oeuvre	Le contrôleur réplique le paquet de multidiffusion et l'envoie à chaque AP dans un tunnel d'Unicast CAPWAP	Le contrôleur envoie une copie du paquet de multidiffusion
Modes pris en charge AP	FlexConnect et gens du pays	Mode local seulement
Exige le routage de la Multidiffusion L3 sur le réseau câblé	Non	Oui
Chargement de contrôleur	Haute	Bas
Chargement de réseau câblé	Haute	Bas

Configurez le mode de distribution de Multidiffusion-Multidiffusion

le mode de Multidiffusion-Multidiffusion est l'option recommandée pour l'évolutivité et a câblé des raisons d'efficacité de bande passante.

Remarque: Cette étape seulement est absolument exigée pour le contrôleur Sans fil de gamme 2500, mais elle active une transmission plus efficace de Multidiffusion et est recommandée pour toutes les Plateformes de contrôleur.

Allez à l'onglet de « contrôleur » sous la page « générale » 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 d'ipv4 et est recommandée d'être dans la plage 239.X.X.X-239.255.255.255, qui scoped pour des applications privées de Multidiffusion.

Remarque: N'utilisez pas le 224.X.X.X, 239.0.0.X, ou les plages d'adresses 239.128.0.X pour l'adresse de groupe de multidiffusion. Les adresses dans ces plages superposent avec les adresses MAC locales de lien et inondent tous les ports de commutateur, même avec la surveillance IGMP activée.

Configurez le mode de distribution de Multidiffusion-Unicast

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 de FlexConnect, et des aps seront utilisés pour des WLAN centralement commutés prenant en charge l'IPv6, alors le mode d'unicast est exigé.

1. Allez à l'onglet de contrôleur sous la page générale, et assurez-vous que le mode de Multidiffusion AP est configuré pour utiliser le mode d'Unicast.

   

2. Connectez un client capable d'IPv6 au RÉSEAU LOCAL Sans fil. Validez que le client reçoit un ipv6 addres en naviguant vers l'onglet de moniteur et puis le menu de clients.

   

Configurez la mobilité d'IPv6

Il n'y a aucune configuration spécifique pour la mobilité d'IPv6 excepté pour placer des contrôleurs au même groupe de mobilité ou dans le même domaine de mobilité. Ceci permet à jusqu'à 72 contrôleurs totaux pour participer à un domaine de mobilité fournissant la mobilité sans couture pour même le plus grand des campus.

Allez à l'onglet > aux Groupes de mobilité de contrôleur, et ajoutez chaque contrôleur par l'adresse MAC et l'adresse IP dans le groupe. Ceci doit être fait sur tous les contrôleurs au groupe de mobilité.

Configurez la Multidiffusion IPv6

Le contrôleur prend en charge MLDv1 pillant pour la Multidiffusion IPv6 qui lui permet intelligemment pour maintenir et fournir des écoulements de Multidiffusion aux clients qui les demandent.

Remarque: À la différence des versions préalables des releases, le support du trafic unicast d'IPv6 ne l'exige pas que « le mode global de Multidiffusion » soit activé sur le contrôleur. Le support du trafic unicast d'IPv6 est activé automatiquement.

1. Allez à l'onglet > à la page et à l'enable MLD de contrôleur de Multidiffusion pillant afin de prendre en charge le trafic d'IPv6 de Multidiffusion. Pour que la Multidiffusion IPv6 soit activée, le mode global de Multidiffusion du contrôleur doit être aussi bien activé.

   

   Remarque: Piller global de mode, IGMP, et MLD de Multidiffusion devrait être activé si des applications peer-to-peer de détection telles que Bonjour d'Apple sont exigées.

2. Afin de vérifier que le trafic de Multidiffusion IPv6 est pillé, allez à l'onglet de moniteur et à la page de Multidiffusion. Notez que des groupes de multidiffusion de l'ipv4 (IGMP) et de l'IPv6 (MLD) sont répertoriés. Cliquez sur le MGID afin de visualiser les clients sans fil joints à cette adresse de groupe.

   

Configurez la protection de RA d'IPv6

Naviguez vers l'onglet de contrôleur et puis l'IPv6 > la protection de RA sur le menu gauche. Protection de RA d'IPv6 d'enable sur AP. La protection de RA sur le contrôleur ne peut pas être désactivée. En plus de la configuration de protection de RA, cette page présente également tous les clients qui ont été identifiés en tant qu'envoi de RAs.

Configurez les listes de contrôle d'accès d'IPv6

1. Allez à l'onglet Sécurité, ouvrez les listes de contrôle d'accès, et cliquez sur New.

   

2. Écrivez un nom unique pour l'ACL, changez le type d'ACL à l'IPv6, et cliquez sur Apply.

   

3. Cliquez sur en fonction le nouvel ACL qui a été créé dans les étapes ci-dessus.

   

4. Cliquez sur Add la nouvelle règle, entrez les paramètres désirés pour la règle, et cliquez sur Apply. Laissez le blanc de numéro de séquence afin de placer la règle à la fin de la liste. L'option de « direction » de « d'arrivée » est utilisée pour le trafic provenant le réseau Sans fil, et « sortant » pour le trafic destiné pour des clients sans fil. Souvenez-vous, la dernière règle dans un ACL est un refuser-tout implicite. Employez une longueur de préfixe de 64 afin d'apparier un sous-réseau entier d'IPv6, et une longueur de préfixe de 128 pour limiter seulement l'accès à une adresse individuelle.

   

5. L'IPv6 ACLs sont appliqués sur une base per-WLAN/SSID et peuvent être utilisés sur le multiple WLAN simultanément. Naviguez vers l'onglet WLAN et cliquez sur l'ID de WLAN du SSID en question afin d'appliquer l'ACL d'IPv6. Cliquez sur l'onglet Avancé et changez l'ACL d'interface de priorité pour l'IPv6 au nom d'ACL.

   

Configurez l'accès invité d'IPv6 pour l'authentification de Web externe

1. ACL configurez d'ipv4 et d'IPv6 pré-authentification pour le web server. Ceci permet le trafic à et du serveur externe avant que le client soit entièrement authentifié.

   

   Pour plus d'informations sur l'exécution de l'accès de Web externe, référez-vous à l'authentification de Web externe avec l'exemple Sans fil de configuration de contrôleurs LAN.

2. Configurez l'invité WLAN par le furetage à l'onglet WLAN au dessus. Créez l'invité SSID et utilisez une stratégie de Web de la couche 3. La pré-authentification ACLs défini dans l'étape 1 sont sélectionnées pour l'ipv4 et l'IPv6. Cochez la section de configuration globale de priorité et l'externe choisi de la liste déroulante authentique de type de Web. Écrivez l'URL du web server. Le nom d'hôte du serveur externe devrait être résoluble dans des DN d'ipv4 et d'IPv6.

   

Configurez l'étranglement de RA d'IPv6

1. Naviguez vers le menu supérieur de contrôleur et cliquez sur l'option de stratégie d'IPv6 > de commande de puissance de RA du côté gauche. RA d'enable étranglant en cliquant sur la case à cocher.

   

   Remarque: Quand l'étranglement de RA se produit, seulement le routeur capable du premier IPv6 est permis. Pour des réseaux avec de plusieurs préfixes d'IPv6 servi par différents Routeurs, l'étranglement de RA devrait être désactivé.

2. Ajustez la période de commande de puissance et d'autres options seulement sous la considération du TAC. Cependant, le par défaut est recommandé pour la plupart des déploiements. Les diverses options de configuration de la stratégie de étranglement de RA devraient être ajustées à cet effet :

   • Les valeurs numériques de « laissent au moins » devraient être moins que « laissez tout au plus » qui devraient être moins que « traversants maximum ».

   • La stratégie de commande de puissance de RA ne devrait pas utiliser une période de commande de puissance qui est plus de 1800 secondes car c'est la vie par défaut de la plupart de RAs.

Chaque option de étranglement de RA est décrite ci-dessous :

• Période de commande de puissance - La période que l'étranglement a lieu. L'étranglement de RA le prend effet seulement après que » la limite traversante « maximum est atteinte pour le VLAN.

• Traversants maximum - C'est le nombre maximal de RAs par VLAN avant l'étranglement donne un coup de pied dedans. L'option de « aucune limite » laisse une quantité illimitée de RAs sans l'étranglement.

• Option d'intervalle - L'option d'intervalle permet au contrôleur pour agir différemment basée sur la valeur RFC 3775 réglée dans le RA d'IPv6.

  • Fonction émulation - Cette valeur permet n'importe quel RAs avec une option de l'intervalle RFC3775 d'intervenir sans étranglement.

  • Ignorez - Cette valeur fera traiter le throttler de RA des paquets avec l'option d'intervalle comme RA régulier et sujet à l'étranglement si en effet.

  • Commande de puissance - Cette valeur entraînera le RAs avec l'option d'intervalle d'être sujet toujours à la limitation de débit.

• Laissez au moins - Le nombre minimal de RAs par routeur qui sera envoyé comme Multidiffusion.

• Laissez tout au plus - Le nombre maximal de RAs par routeur qui sera envoyé comme Multidiffusion avant l'étranglement le prend effet. L'option de « aucune limite » laissera un nombre illimité de RAs pour ce routeur.

Configurez la table de corrélation d'ipv6 neighbor

1. Allez au menu supérieur de contrôleur et cliquez sur l'IPv6 > les temporisateurs obligatoires voisins sur le menu gauche.

   

2. Ajustez en bas de la vie, de la vie accessible, et de la vie éventée comme nécessaire. Pour des déploiements avec les clients qui sont fortement mobiles, les temporisateurs pour un temporisateur éventé d'adresse devraient être tordus. Les valeurs recommandées sont :

   • Vers le bas vie - 30 secondes

   • Vie accessible - 300 secondes

   • Vie d'état - 86400 secondes

   Chaque temporisateur de vie se réfère au déclarer qu'un ipv6 addres peut être dans :

   • Vers le bas vie - Vers le bas le temporisateur spécifie combien de temps le cache entries d'IPv6 devrait être gardé si l'interface avec liaison ascendante du contrôleur descend.

   • Vie accessible - Ce temporisateur spécifie combien de temps un ipv6 addres sera un en activité marqué qui signifie que le trafic a été reçu de cette adresse récemment. Une fois que ce temporisateur expire, l'adresse est déplacée à l'état « éventé ».

   • Vie éventée - Ce temporisateur spécifie combien de temps maintenir les adresses d'IPv6 dans le cache qui n'ont pas été vues dans « la vie accessible ». Après cette vie, l'adresse est retirée de la table de corrélation.

Configurez l'IPv6 VideoStream

1. Assurez que des caractéristiques globales de VideoStream sont activées sur le contrôleur. Référez-vous à la solution de réseau sans fil unifié Cisco : Guide de déploiement de VideoStream pour les informations sur activer VideoStream sur le réseau 802.11a/g/n aussi bien que le WLAN SSID.

2. Allez à l'onglet sans fil sur le contrôleur, et sur le menu gauche, choisissent le flux multimédia > les flots. Cliquez sur Add nouveau afin de créer un nouveau flot.

   

3. Nommez le flot et introduisez les adresses d'IPv6 de début et de fin. En utilisant seulement un flot simple, le début et les adresses de fin sont égaux. Après avoir ajouté les adresses, cliquez sur Apply afin de créer le flot.

   

Dépannez la Connectivité de client d'IPv6

Certains clients ne peuvent pas passer le trafic d'IPv6

Quelques réalisations de pile de réseau d'IPv6 de client ne s'annoncent pas correctement en étant livré sur le réseau et donc leur adresse n'est pas pillée convenablement par le contrôleur pour le placement dans la table de corrélation voisine. En adresse pas le présent dans la table de corrélation voisine est bloqué selon la caractéristique de protection de source d'IPv6. Afin de permettre à ces clients pour passer le trafic, ces options doivent être configurées :

1. Désactivez la configuration de protection de source d'IPv6 par le CLI :

   config network ip-mac-binding disable
   

2. Expédition voisin de sollicitation de Multidiffusion d'enable par le CLI :

   config ipv6 ns-mcast-fwd enable
   

Vérifiez la couche réussie 3 errant pour un client d'IPv6 :

Émettez ces commandes de débogage sur l'ancre et le contrôleur étranger :

debug client <mac address>

debug mobility handoff enable

debug mobility packet enable

Résultats de débogage sur le contrôleur d'ancre :

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 de 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 utiles CLI d'IPv6 :

Show ipv6 neighbor-binding summary

Debug ipv6 neighbor-binding filter client <Client MAC> enable

Debug ipv6 neighbor-binding filter errors enable

Forum aux questions

Q : Que la limite optimale de taille de préfixe d'IPv6 est-elle le domaine d'émission ?

A : Bien qu'un sous-réseau d'IPv6 puisse être subdivisé au-dessous d'un /64, cette configuration interrompra SLAAC et entraînera des questions avec la Connectivité de client. Si la segmentation est nécessaire afin de réduire le nombre d'hôtes, la caractéristique de groupes d'interface peut être utilisée pour équilibrer la charge des clients parmi la partie postérieure différente VLAN, chacun utilisant un préfixe différent d'IPv6.

Q : Y a-t-il des limites d'évolutivité quand il s'agit de prendre en charge des clients d'IPv6 ?

A : La principale limite d'évolutivité pour le support de client d'IPv6 est la table de corrélation voisine qui maintient toutes les adresses d'IPv6 de client sans fil. Cette table est mesurée par plate-forme de contrôleur afin de prendre en charge le nombre maximal de clients multipliés par huit (le nombre maximal d'adresses par client). L'ajout de la table de corrélation d'IPv6 peut soulever l'utilisation de mémoire du contrôleur approximativement 10-15% sous la pleine charge, selon la plate-forme.

Contrôleur sans-fil	Nombre maximal de clients	Taille de table de corrélation d'ipv6 neighbor
2500	500	4,000
5500	7,000	56,000
WiSM2	15,000	120,000

Q : Quelle est l'incidence des caractéristiques d'IPv6 sur la CPU et mémoire du contrôleur ?

A : L'incidence est minimale car la CPU a de plusieurs noyaux pour traiter l'avion de contrôle. Une fois testé avec le maximum a pris en charge des clients, chacun avec 8 adresses d'IPv6, l'utilisation du CPU était en-dessous de 30%, et l'utilisation de mémoire était en-dessous de 75%.

Q : Le support de client d'IPv6 peut-il être désactivé ?

A : Pour les clients qui veulent activer seulement l'ipv4 dans leur réseau et bloquer l'IPv6, un ACL d'IPv6 de refuser-tout trafic peut être utilisé et appliqué sur une base par-WLAN.

Q : Est-il possible d'avoir un WLAN pour l'ipv4 et un autre pour l'IPv6 ?

A : Il n'est pas possible d'avoir le mêmes nom SSID et type de Sécurité pour deux WLAN différents fonctionnant sur même AP. Pour la segmentation des clients d'ipv4 des clients d'IPv6, deux WLAN doivent être créés. Chaque WLAN doit être configuré avec un ACL qui bloque tout le trafic d'ipv4 ou d'IPv6 respectivement.

Q : Pourquoi est-il important de prendre en charge de plusieurs adresses d'IPv6 par client ?

A : Les clients peuvent avoir de plusieurs adresses d'IPv6 par interface qui peut être statique, SLAAC ou DHCPv6 assigné en plus toujours de avoir une adresse locale à la liaison avec auto-assignation. Les clients peuvent également avoir des adresses supplémentaires utilisant différents préfixes d'IPv6.

Q : Il est des adresses privées d'IPv6 et pourquoi sont elles importants dépister quelles ?

A : (Également connu en tant que provisoire) des adresses privées sont aléatoirement générées par le client quand l'affectation d'adresses SLAAC est en service. Ces adresses sont souvent tournées à une fréquence d'un jour ou ainsi, quant à empêchez la traçabilité d'hôte qui proviendrait utilisant le même suffixe d'hôte (64 derniers bits) à tout moment. Il est important de dépister ces adresses privées pour auditer des buts tels que la violation des droits d'auteur de suivi. Cisco NCS enregistre toutes les adresses d'IPv6 en service par chaque client et se connecte historiquement les chaque fois que le client erre ou établit une nouvelle session. Ces enregistrements peuvent être configurés à NCS à tenir pendant jusqu'à une année.

Informations connexes

• Support et documentation techniques - Cisco Systems