Contents Show
IntroductionEste documento fornece informações sobre a teoria da operação e da configuração para a solução Cisco Unified Wireless LAN, enquanto se refere a suporte de clientes IPv6. Conectividade de cliente sem fio IPv6
 O conjunto de recursos IPv6 no software Cisco Unified Wireless Network versão v7.2 permite que a rede sem fio suporte clientes IPv4, Dual-Stack e IPv6 somente na mesma rede sem fio. O objetivo geral para a adição do suporte ao cliente IPv6 à Cisco Unified Wireless LAN era manter a paridade de recursos entre clientes IPv4 e IPv6, incluindo mobilidade, segurança, acesso para convidados, qualidade de serviço e visibilidade de endpoint. Até oito endereços de cliente IPv6 podem ser rastreados por dispositivo. Isso permite que os clientes IPv6 tenham um endereço de configuração automática de endereço stateless (SLAAC) de link local, um endereço de protocolo de configuração dinâmica de host para IPv6 (DHCPv6) e até mesmo endereços em prefixos alternativos em uma única interface. Os clientes da ligação de grupo de trabalho (WGB) ligados ao uplink de um ponto de acesso autônomo (AP) no modo WGB também podem suportar IPv6. PrerequisitesRequirementsNão existem requisitos específicos para este documento. Componentes UtilizadosAs informações neste documento são baseadas nestas versões de software e hardware:
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. ConventionsConsulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos. Pré-requisitos para conectividade de cliente IPv6 sem fioPara habilitar a conectividade do cliente IPv6 sem fio, a rede com fio subjacente deve suportar o roteamento IPv6 e um mecanismo de atribuição de endereço, como SLAAC ou DHCPv6. O controlador de LAN sem fio deve ter adjacência L2 com o roteador IPv6, e a VLAN precisa ser marcada quando os pacotes entram no controlador. Os APs não exigem conectividade em uma rede IPv6, pois todo o tráfego é encapsulado dentro do túnel CAPWAP IPv4 entre o AP e o controlador. Atribuição de endereço SLAAC
O método mais comum para atribuição de endereço de cliente IPv6 é SLAAC. O SLAAC fornece conectividade simples plug-and-play, na qual os clientes autoatribuem um endereço com base no prefixo IPv6. Esse processo é realizado quando o roteador IPv6 envia mensagens periódicas de anúncio do roteador que informam o cliente do prefixo IPv6 em uso (os primeiros 64 bits) e do gateway padrão IPv6. A partir desse ponto, os clientes podem gerar os 64 bits restantes de seu endereço IPv6 com base em dois algoritmos: EUI-64, que é baseado no endereço MAC da interface, ou endereços privados que são gerados aleatoriamente. A escolha do algoritmo depende do cliente e geralmente é configurável. A detecção de endereço duplicado é executada por clientes IPv6 para garantir que os endereços aleatórios selecionados não colidam com outros clientes. O endereço do roteador que envia anúncios é usado como gateway padrão para o cliente. Esses comandos de configuração do Cisco IOS® de um roteador IPv6 compatível com Cisco são usados para ativar o endereçamento SLAAC e os anúncios do roteador: 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 Atribuição de endereço DHCPv6
O uso do DHCPv6 não é necessário para a conectividade do cliente IPv6 se o SLAAC já estiver implantado. Há dois modos de operação para DHCPv6 chamados Stateless e Stateful. O modo DHCPv6 Stateless é usado para fornecer aos clientes informações de rede adicionais não disponíveis no anúncio do roteador, mas não um endereço IPv6, pois isso já é fornecido pelo SLAAC. Essas informações podem incluir o nome de domínio DNS, os servidores DNS e outras opções específicas do fornecedor de DHCP. Esta configuração de interface é para um roteador Cisco IOS IPv6 implementando DHCPv6 stateless com SLAAC ativado: 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 A opção Stateful DHCPv6, também conhecida como modo gerenciado, opera de forma semelhante ao DHCPv4, na medida em que atribui endereços exclusivos a cada cliente, em vez do cliente que gera os últimos 64 bits do endereço como em SLAAC. Esta configuração de interface é para um roteador IPv6 do Cisco IOS que implementa DHCPv6 stateful com SLAAC desabilitado: 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 InformationA configuração da rede com fio para conectividade completa em todo o campus IPv6 usando métodos de conectividade de pilha dupla ou tunelamento está fora do escopo deste documento. Para obter mais informações, consulte o guia de implantação validado da Cisco Implantando IPv6 em redes de campus. Mobilidade de cliente IPv6
Para lidar com clientes IPv6 em roaming através de controladores, as mensagens ICMPv6, como Solicitação de Vizinho (NS), Anúncio de Vizinho (NA), Anúncio de Roteador (RA) e Solicitação de Roteador (RS) devem ser tratadas especialmente para garantir que um cliente permaneça na mesma rede de Camada 3. A configuração para a mobilidade IPv6 é a mesma que para a mobilidade IPv4 e não requer software separado no lado do cliente para obter roaming transparente. A única configuração necessária é que os controladores devem fazer parte do mesmo grupo/domínio de mobilidade. Este é o processo para mobilidade de clientes IPv6 entre controladores:
Observação: a mobilidade para clientes somente IPv6 é baseada em informações de VLAN. Isso significa que a mobilidade de cliente somente IPv6 não é suportada em VLANs não marcadas. Suporte para seleção de VLAN (grupos de interface)
O recurso de grupos de interface permite que uma organização tenha uma única WLAN com várias VLANs configuradas no controlador para permitir o balanceamento de carga de clientes sem fio através dessas VLANs. Esse recurso é comumente usado para manter os tamanhos de sub-rede IPv4 pequenos enquanto permite que uma WLAN seja escalada para milhares de usuários em várias VLANs do grupo. Para suportar clientes IPv6 com grupos de interface, nenhuma configuração adicional é necessária, pois o sistema envia automaticamente o RA correto aos clientes corretos via unicast sem fio L2. Ao unicast do RA, os clientes na mesma WLAN, mas em uma VLAN diferente, não recebem o RA incorreto. Segurança de primeiro salto para clientes IPv6Router Advertisement Guard
O recurso RA Guard aumenta a segurança da rede IPv6 ao descartar RAs provenientes de clientes sem fio. Sem esse recurso, os clientes IPv6 mal configurados ou mal-intencionados poderiam anunciar-se como um roteador para a rede, geralmente com uma alta prioridade que poderia ter precedência sobre os roteadores IPv6 legítimos. Por padrão, o protetor do RA é ativado no AP (mas pode ser desabilitado no AP) e sempre é habilitado no controlador. A queda de RAs no AP é preferida, pois é uma solução mais escalável e fornece contadores avançados de descarte de RA por cliente. Em todos os casos, o RA IPv6 será descartado em algum momento, protegendo outros clientes sem fio e a rede com fio upstream de clientes IPv6 mal-intencionados ou mal configurados. Proteção de servidor DHCPv6O recurso DHCPv6 Server Guard impede que os clientes sem fio distribuam endereços IPv6 para outros clientes sem fio ou clientes com fio upstream. Para evitar que os endereços DHCPv6 sejam distribuídos, todos os pacotes de anúncio DHCPv6 de clientes sem fio são descartados. Esse recurso opera no controlador, não requer configuração e é ativado automaticamente. Protetor de origem IPv6O recurso Proteção de Origem IPv6 impede que um cliente sem fio falsifique um endereço IPv6 de outro cliente. Esse recurso é análogo ao IPv4 Source Guard. O Protetor de Origem IPv6 está ativado por padrão, mas pode ser desativado via CLI. Contabilidade de endereços IPv6Para autenticação e tarifação RADIUS, o controlador envia de volta um endereço IP usando o atributo "Framed-IP-address". O endereço IPv4 é usado nesse caso. O atributo "Calling-Station-ID" usa esse algoritmo para enviar de volta um endereço IP quando o "Tipo de ID da estação de chamada" no controlador está configurado para "Endereço IP":
Como os endereços IPv6 do cliente podem ser alterados com frequência (endereços temporários ou privados), é importante rastreá-los ao longo do tempo. O Cisco NCS registra todos os endereços IPv6 em uso por cada cliente e os registra historicamente cada vez que o cliente faz roaming ou estabelece uma nova sessão. Esses registros podem ser configurados no NCS para serem mantidos por até um ano. Observação: o valor padrão do "Tipo de ID da estação de chamada" no controlador foi alterado para "Endereço MAC do sistema" na versão 7.2. Ao atualizar, isso deve ser alterado para permitir o rastreamento exclusivo de clientes por endereço MAC, já que os endereços IPv6 podem alterar a meia-sessão e causar problemas na contabilidade se a Calling-Station-ID estiver definida como endereço IP. Listas de controle de acesso IPv6Para restringir o acesso a determinados recursos cabeados upstream ou bloquear determinados aplicativos, as ACLs (Access Control Lists, listas de controle de acesso) IPv6 podem ser usadas para identificar o tráfego e permitir ou negá-lo. As ACLs IPv6 suportam as mesmas opções das ACLs IPv4, incluindo origem, destino, porta origem e porta destino (os intervalos de portas também são suportados). As ACLs de pré-autenticação também são suportadas para suportar a autenticação de convidado IPv6 usando um servidor Web externo. O controlador sem fio suporta até 64 ACLs IPv6 exclusivas com 64 regras exclusivas em cada uma. O controlador sem fio continua a suportar 64 ACLs IPv4 exclusivas adicionais com 64 regras exclusivas em cada uma para um total de 128 ACLs para um cliente de pilha dupla. Substituição de AAA para ACLs IPv6Para suportar controle de acesso centralizado por meio de um servidor AAA centralizado, como o Cisco Identity Services Engine (ISE) ou ACS, a ACL IPv6 pode ser provisionada por cliente usando atributos de substituição AAA. Para usar esse recurso, a ACL IPv6 deve ser configurada no controlador e a WLAN deve ser configurada com o recurso de substituição de AAA habilitado. O atributo AAA real nomeado para uma ACL IPv6 é Airespace-IPv6-ACL-Name semelhante ao atributo Airespace-ACL-Name usado para provisionar uma ACL baseada em IPv4. O atributo AAA retornado conteúdo deve ser uma string igual ao nome da ACL IPv6 conforme configurado no controlador. Otimização de pacotes para clientes IPv6Cache de descoberta de vizinhos
O protocolo de descoberta de vizinhos (NDP - neighbor Discovery Protocol) IPv6 utiliza pacotes NA e NS no lugar do protocolo de resolução de endereços (ARP - Address Resolution Protocol) para permitir que os clientes IPv6 resolvam o endereço MAC de outros clientes na rede. O processo de NDP pode ser muito chato, pois ele inicialmente usa endereços multicast para executar a resolução de endereços; isso pode consumir um tempo de transmissão sem fio valioso à medida que os pacotes multicast são enviados a todos os clientes no segmento de rede. Para aumentar a eficiência do processo NDP, o cache de descoberta de vizinhos permite que o controlador atue como um proxy e responda às consultas NS que ele pode resolver. O cache de descoberta de vizinhos é possibilitado pela tabela de vinculação de vizinhos subjacente presente no controlador. A tabela de vinculação de vizinhos controla cada endereço IPv6 e seu endereço MAC associado. Quando um cliente IPv6 tenta resolver o endereço da camada de link de outro cliente, o pacote NS é interceptado pelo controlador que responde com um pacote NA. Limitação de anúncio de roteadorO Router Advertisement Throttling permite que o controlador aplique a limitação de taxa de RAs direcionados para a rede sem fio. Ao habilitar a limitação de RA, os roteadores configurados para enviar RAs com muita frequência (por exemplo, a cada três segundos) podem ser reduzidos para uma frequência mínima que ainda manterá a conectividade do cliente IPv6. Isso permite otimizar o tempo de transmissão reduzindo o número de pacotes multicast que devem ser enviados. Em todos os casos, se um cliente envia um RS, um RA será permitido através do controlador e unicast ao cliente solicitante. Isso garante que novos clientes ou clientes em roaming não sejam afetados negativamente pelo controle de RA. Acesso de convidado IPv6Os recursos sem fio e de convidado com fio presentes para clientes IPv4 funcionam da mesma maneira para clientes de pilha dupla e somente IPv6. Quando o usuário convidado se associa, eles são colocados em um estado de execução "WEB_AUTH_REQ" até que o cliente seja autenticado através do portal cativo IPv4 ou IPv6. O controlador interceptará o tráfego HTTP/HTTPS IPv4 e IPv6 nesse estado e o redirecionará para o endereço IP virtual do controlador. Quando o usuário é autenticado através do portal cativo, seu endereço MAC é movido para o estado de execução e o tráfego IPv4 e IPv6 pode passar. Para autenticação da Web externa, a ACL de pré-autenticação permite que um servidor Web externo seja usado. Para suportar o redirecionamento de clientes somente IPv6, o controlador cria automaticamente um endereço virtual IPv6 com base no endereço virtual IPv4 configurado no controlador. O endereço IPv6 virtual segue a convenção de [::ffff:<endereço IPv4 virtual>]. Por exemplo, um endereço IP virtual 1.1.1.1 traduziria para [::ffff:1.1.1]. Ao usar um certificado SSL confiável para autenticação de acesso de convidado, verifique se o endereço virtual IPv4 e IPv6 do controlador está definido no DNS para corresponder ao nome de host dos certificados SSL. Isso garante que os clientes não recebam um aviso de segurança declarando que o certificado não corresponde ao nome de host do dispositivo. Observação: o certificado SSL gerado automaticamente pelo controlador não contém o endereço virtual IPv6. Isso pode fazer com que alguns navegadores da Web apresentem um aviso de segurança. É recomendável usar um certificado SSL confiável para acesso de convidado. VideoStream IPv6
O VideoStream permite a entrega de vídeo multicast sem fio confiável e escalável, enviando a cada cliente o fluxo em um formato unicast. A conversão real de multicast para unicast (de L2) ocorre no AP, fornecendo uma solução escalável. O controlador envia o tráfego de vídeo IPv6 dentro de um túnel multicast CAPWAP IPv4 que permite distribuição de rede eficiente para o AP. Qualidade de serviço IPv6
Os pacotes IPv6 usam uma marcação semelhante ao uso de valores de DSCP do IPv4 com suporte para até 64 classes de tráfego diferentes (0-63). Para pacotes downstream da rede com fio, o valor da classe de tráfego IPv6 é copiado para o cabeçalho do túnel CAPWAP para garantir que a QoS seja preservada fim-a-fim. Na direção upstream, o mesmo ocorre quando o tráfego do cliente marcado na Camada 3 com classe de tráfego IPv6 será honrado marcando os pacotes CAPWAP destinados ao controlador. IPv6 e FlexConnect
FlexConnect - WLANs de switching localO FlexConnect no modo de comutação local suporta clientes IPv6 ao ligar o tráfego à VLAN local, semelhante à operação IPv4. A mobilidade do cliente é suportada para roaming de Camada 2 no grupo FlexConnect. Esses recursos específicos do IPv6 são suportados no modo de comutação local FlexConnect:
Esses recursos específicos do IPv6 não são suportados no modo de comutação local FlexConnect:
FlexConnect - WLANs de switching centralPara APs no modo FlexConnect usando comutação central (tunelamento de tráfego de volta para o controlador), o controlador deve ser definido como "Multicast - Unicast Mode" para o "AP Multicast Mode". Como os APs FlexConnect não participam do grupo de multicast CAPWAP do controlador, os pacotes multicast devem ser replicados no controlador e unicast para cada AP individualmente. Esse método é menos eficiente que o "Multicast - Multicast Mode" e coloca carga adicional no controlador. Este recurso específico do IPv6 não é suportado no modo de comutação central FlexConnect:
Observação: as WLANs comutadas centralmente executando IPv6 não são suportadas no Flex 7500 Series Controller. Visibilidade de clientes IPv6 com NCSCom o lançamento do NCS v1.1, muitos recursos adicionais específicos do IPv6 são adicionados para monitorar e gerenciar uma rede de clientes IPv6 em redes com e sem fio. Itens do painel IPv6Para visualizar que tipos de clientes estão presentes na rede, um "Dashlet" no NCS está disponível para fornecer informações sobre estatísticas específicas do IPv6 e oferecer a capacidade de detalhamento em clientes IPv6. IP Address Type Dashlet - Exibe os tipos de clientes IP na rede:
Contagem de Clientes por Tipo de Endereço IP - Exibe o tipo de cliente IP ao longo do tempo:
Tráfego do cliente por tipo de endereço IP - Exibe o tráfego de cada tipo de cliente. Os clientes na categoria de pilha dupla incluem tráfego IPv4 e IPv6:
Atribuição de endereço IPv6 - Exibe o método de atribuição de endereço para cada cliente como uma destas quatro categorias:
Cada uma das seções do gráfico de pizza pode ser clicada, o que permite que o administrador faça drill-down em uma lista de clientes.
Monitorar clientes IPv6
Para monitorar e gerenciar as informações do cliente IPv6, essas colunas foram adicionadas à página Clientes e usuários:
Além de exibir colunas específicas do IPv6, a coluna Endereço IP mostrará o endereço IP atual do cliente com uma prioridade para exibir o endereço IPv4 primeiro (no caso de um cliente de pilha dupla) ou o endereço IPv6 exclusivo global no caso de um cliente somente IPv6. Configuração para suporte ao cliente IPv6 sem fioModo de distribuição multicast para APsA Cisco Unified Wireless Network suporta dois métodos de distribuição multicast para APs associados ao controlador. Em ambos os modos, o pacote multicast original da rede com fio é encapsulado dentro de um pacote CAPWAP de Camada 3 enviado via Unicast ou Multicast CAPWAP para o AP. Como o tráfego é encapsulado em CAPWAP, os APs não precisam estar na mesma VLAN que o tráfego do cliente. Os dois métodos de distribuição Multicast são comparados aqui:
Configurar o modo de distribuição multicast-multicastO modo multicast-multicast é a opção recomendada para escalabilidade e eficiência da largura de banda com fio. Observação: essa etapa é necessária apenas para o 2500 Series Wireless Controller, mas permite uma transmissão multicast mais eficiente e é recomendada para todas as plataformas de controlador. Vá para a guia "Controller" (Controlador) na página "General" (Geral) e verifique se o AP Multicast Mode (Modo Multicast AP) está configurado para usar o modo Multicast e se um endereço de grupo válido está configurado. O endereço do grupo é um grupo multicast IPv4 e é recomendado estar no intervalo 239.X.X.X-239.255.255.255, que é escoado para aplicativos multicast privados.
Observação: não use os intervalos de endereço 224.X.X.X, 239.0.0.X ou 239.128.0.X para o endereço do grupo multicast. Os endereços nesses intervalos se sobrepõem aos endereços MAC locais do link e inundam todas as portas do switch, mesmo com o rastreamento IGMP ativado. Configurar o modo de distribuição multicast-unicastSe a rede com fio não estiver configurada corretamente para fornecer o multicast CAPWAP entre o controlador e o modo AP ou FlexConnect, e os APs serão usados para WLANs com comutação central que suportam IPv6, o modo unicast será necessário.
Configurar a mobilidade IPv6Não há configuração específica para mobilidade IPv6, exceto para colocar controladores no mesmo grupo de mobilidade ou no mesmo domínio de mobilidade. Isso permite que até 72 controladores participem de um domínio de mobilidade, proporcionando mobilidade perfeita até mesmo para o maior dos campus. Vá até a guia Controller > Mobility Groups e adicione cada controlador por MAC Address e IP address ao grupo. Isso deve ser feito em todos os controladores do grupo de mobilidade.
Configurar multicast IPv6O controlador oferece suporte a rastreamento MLDv1 para multicast IPv6, o que permite que ele rastreie e forneça fluxos multicast de forma inteligente aos clientes que os solicitam. Observação: diferentemente das versões anteriores das versões, o suporte ao tráfego unicast IPv6 não exige que o "Modo Multicast Global" seja ativado no controlador. O suporte ao tráfego unicast IPv6 é ativado automaticamente.
Configurar o protetor RA IPv6Navegue até a guia Controller (Controlador) e, em seguida, IPv6 > RA Guard no menu à esquerda. Ative o IPv6 RA Guard no AP. O protetor do RA no controlador não pode ser desativado. Além da configuração do RA Guard, esta página também mostra todos os clientes que foram identificados como RAs de envio.
Configurar listas de controle de acesso IPv6
Configurar o acesso de convidado IPv6 para autenticação da Web externa
Configurar a limitação de RA IPv6
Cada opção de limitação de RA é descrita abaixo:
Configurar a Tabela de Associação de Vizinhos IPv6
Configurar VideoStream IPv6
Solucionar problemas de conectividade de cliente IPv6Determinados clientes não podem passar o tráfego IPv6Algumas implementações da pilha de rede IPv6 do cliente não anunciam corretamente quando entram na rede e, portanto, seu endereço não é rastreado apropriadamente pelo controlador para colocação na tabela de vinculação de vizinhos. Os endereços não presentes na tabela de associação de vizinhos são bloqueados de acordo com o recurso de proteção de origem IPv6. Para permitir que esses clientes passem tráfego, essas opções precisam ser configuradas:
Verifique o roaming bem-sucedido da camada 3 para um cliente IPv6:Emita estes comandos debug no âncora e no controlador externo: debug mobility handoff enable debug mobility packet enable Resultados de depuração no controlador de âncora: 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 Resultados de depuração em controlador externo: 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 Comandos IPv6 CLI úteis:Show ipv6 neighbor-binding summary Debug ipv6 neighbor-binding filter errors enable Perguntas mais freqüentesP: Qual é o tamanho ideal do prefixo IPv6 para limitar o domínio de broadcast? R: Embora uma sub-rede IPv6 possa ser subdividida abaixo de uma /64, essa configuração quebrará a SLAAC e causará problemas com a conectividade do cliente. Se a segmentação for necessária para reduzir o número de hosts, o recurso Grupos de interface pode ser usado para balancear a carga de clientes entre diferentes VLANs back-end, cada uma usando um prefixo IPv6 diferente. P: Há alguma limitação de escalabilidade quando se trata de suportar clientes IPv6? R: A principal limitação de escalabilidade para suporte ao cliente IPv6 é a tabela de vinculação de vizinhos que controla todos os endereços IPv6 de clientes sem fio. Esta tabela é dimensionada por plataforma de controlador para suportar o número máximo de clientes multiplicado por oito (o número máximo de endereços por cliente). A adição da tabela de vinculação IPv6 pode aumentar o uso da memória do controlador em aproximadamente 10-15% com carga total, dependendo da plataforma.
P: Qual é o impacto dos recursos IPv6 na CPU e na memória do controlador? R: O impacto é mínimo, pois a CPU tem vários núcleos para processar o plano de controle. Quando testado com o máximo de clientes suportados, cada um com 8 endereços IPv6, o uso da CPU estava abaixo de 30% e o uso da memória estava abaixo de 75%. P: O suporte ao cliente IPv6 pode ser desabilitado? R: Para clientes que desejam habilitar somente o IPv4 em sua rede e bloquear o IPv6, uma ACL IPv6 de tráfego deny-all pode ser usada e aplicada por WLAN. P: É possível ter uma WLAN para IPv4 e outra para IPv6? R: Não é possível ter o mesmo nome SSID e tipo de segurança para duas WLANs diferentes operando no mesmo AP. Para segmentação de clientes IPv4 de clientes IPv6, duas WLANs devem ser criadas. Cada WLAN deve ser configurada com uma ACL que bloqueie todo o tráfego IPv4 ou IPv6, respectivamente. P: Por que é importante suportar vários endereços IPv6 por cliente? R: Os clientes podem ter vários endereços IPv6 por interface, que podem ser estáticos, SLAAC ou DHCPv6 atribuídos além de sempre ter um endereço Link-Local atribuído. Os clientes também podem ter endereços adicionais usando prefixos IPv6 diferentes. P: O que são endereços privados IPv6 e por que eles são importantes para rastrear? R: Os endereços privados (também conhecidos como temporários) são gerados aleatoriamente pelo cliente quando a atribuição de endereço SLAAC está em uso. Geralmente, esses endereços são girados em uma frequência de um dia ou mais, para evitar o rastreamento do host que viria do uso do mesmo postfix do host (últimos 64 bits) o tempo todo. É importante rastrear esses endereços privados para fins de auditoria, como rastreamento de violação de direitos autorais. O Cisco NCS registra todos os endereços IPv6 em uso por cada cliente e os registra historicamente cada vez que o cliente faz roaming ou estabelece uma nova sessão. Esses registros podem ser configurados no NCS para serem mantidos por até um ano. Informações Relacionadas
Quais as mensagens ICMPv6 são usadas no Slaac?SLAAC usa mensagens ICMPv6 RA para fornecer endereçamento e outras informações de configuração que normalmente seriam fornecidas por um servidor DHCP. Um host configura seu endereço IPv6 com base nas informações enviadas no RA. As mensagens RA são enviadas por um roteador IPv6 a cada 200 segundos.
Qual a mensagem que o cliente envia para pedir as informações de configuração como endereço IPv6 para o servidor DHCPv6?Os clientes e servidores DHCPv6 trocam mensagens por UDP. O cliente usa a porta 546 para enviar e receber mensagens DHCPv6, e o servidor usa a porta 547.
Qual a mensagem utilizada para pedir a um roteador por informações sobre a rede?A mensagem Router Advertisement é enviada periodicamente ou em resposta à mensagem Router Solicitation por um roteador para anunciar sua presença no enlace. Sua importância provém do caráter informativo dessa mensagem.
Quais são as duas características do método Slaac para configuração de endereço IPv6 escolha dois?O processo de autoconfiguração dos endereços em redes baseadas no IPv6 consiste basicamente em duas etapas: (i) configuração do prefixo e (ii) configuração do sufixo de host.
|
Qual a mensagem utilizada para anunciar os prefixos ipv6 na técnica de configuração slaac?
Postagens relacionadas
direito autoral © 2024 pauex Inc.
