Balanceamento de carga de AP e reversão de AP em redes sem fio unificadas

Introduction

Este documento discute como o balanceamento de carga do ponto de acesso (AP) e o fallback do AP funcionam na solução Cisco Unified Wireless. Este documento também explica como configurar múltiplos controladores de LAN Wireless (WLC) para uma condição de failover. Uma condição de failover ocorre quando um controlador principal fica inativo ou falha por alguma razão. Então, um segundo controlador assume a operação. O failover é chamado também de redundância de controlador.

Observação: o fallback de AP discutido neste documento está relacionado apenas à versão do firmware da controladora antes de 3.2.171.5. Versões posteriores do firmware da controladora não se comportam dessa forma. Na versão mais recente do firmware, o AP retorna ao controlador principal sempre que ele fica on-line. Se você tiver um problema de fallback de AP, leia este documento ou atualize o firmware do controlador para o código disponível mais recente.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Configuração de APs leves e Cisco WLCs

• Lightweight AP Protocol (LWAPP)

• Configuração de um servidor DHCP externo

• Servidor DNS

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• AP leve Cisco Aironet 1000 Series

• Duas WLCs Cisco 2000 Series que executam o firmware 3.2.78.0

• Servidor DHCP Microsoft Windows Server 2003 Enterprise

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.

Produtos Relacionados

Essa configuração também pode ser usada com qualquer outro Cisco WLC e qualquer AP leve.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Configurar

Consulte o Exemplo de Configuração de Failover da Controladora WLAN para Pontos de Acesso Lightweight para obter informações sobre como configurar o WLC e o AP lightweight para failover.

Balanceamento de carga do AP

Você pode executar o balanceamento de carga de AP em duas (ou mais) WLCs se configurar grupos de mobilidade corretamente. O LWAPP permite redundância dinâmica e balanceamento de carga. Por exemplo, se você especificar mais de um endereço IP para a opção 43, um AP enviará solicitações de descoberta LWAPP para cada um dos endereços IP que o AP recebe. Na resposta de descoberta WLC LWAPP, a WLC incorpora estas informações:

• Informações sobre a carga atual do AP, que é definida como o número de APs que estão associados à WLC no momento

• A capacidade do AP

• O número de clientes sem fio conectados à WLC

Em seguida, o AP tenta ingressar na WLC menos carregada, que é a WLC com a maior capacidade de AP disponível. Depois que um AP se une a uma WLC, o AP aprende os endereços IP das outras WLCs no grupo de mobilidade de sua WLC unida.

Subsequentemente, o AP envia solicitações de descoberta primária do LWAPP para cada uma das WLCs no grupo de mobilidade. As WLCs respondem com uma resposta de descoberta primária ao AP. A resposta de descoberta principal inclui informações sobre o tipo de WLC, a capacidade total e a carga atual do AP. Desde que a WLC tenha o parâmetro AP Fallback ativado, o AP pode decidir mudar para uma WLC menos carregada.

Quando o AP é inicializado ou redefinido, ele conhece somente os endereços IP de gerenciamento do controlador do DNS (Cisco-lwapp-controller@local_domain.com) (20 máx.), a opção de DHCP 43 (20 máx.), OTAP, 255.255.255.255 e o controlador associado anteriormente. Os controladores no grupo de mobilidade do controlador associado anteriormente não são retidos durante as reinicializações.

No entanto, se o AP perder a conectividade com o controlador, ele não será reinicializado. Ele se move diretamente para o modo de descoberta e se lembra dos membros do grupo de mobilidade. Em seguida, ele pode enviar uma solicitação de descoberta para todos os membros do grupo de mobilidade.

Observação: uma vez que um AP ingressa em um controlador, ele só deixa o controlador atualmente ingressado por um número limitado de razões. Um motivo pelo qual o AP não sai do controlador atualmente associado é se os APs não estão exatamente balanceados de carga em todos os controladores. Por esse motivo, esse algoritmo de balanceamento de carga é apenas um algoritmo de balanceamento de carga aproximado, a menos que você defina manualmente um controlador principal para cada AP.

Essas regras são melhor descritas com alguns exemplos:

• O AP é novo, pronto para uso e nunca entrou em uma controladora. Esse AP faz o balanceamento de carga em 3 controladores em um grupo de mobilidade?

  Não. O AP deve descobrir todos os 3 endereços IP de gerenciamento de controlador durante a inicialização via OTAP, DNS (com todos os 3 endereços ip de gerenciamento definidos), 255.255.255 e DHCP Option 43 (com todos os 3 endereços ip de gerenciamento incluídos) para balanceamento de carga. O AP envia uma solicitação de descoberta a todos os controladores conhecidos e une-se ao controlador com a capacidade de AP mais excessiva. Se apenas 1 controlador estiver definido na opção de DHCP 43/DNS, os novos APs sempre se juntarão a essa controladora.

• Se houver 1 controlador definido na opção de DHCP 43/DNS e 3 controladores no grupo de mobilidade, ele faz o balanceamento de carga entre os 3 controladores em um grupo de mobilidade se você reinicializar o AP após ele ingressar na controladora na opção de DHCP 43?

  Não. Se o AP for reinicializado ou redefinido, ele sempre ingressará no controlador na opção de DHCP 43/DNS ou no último controlador associado. No entanto, se o AP perder a pulsação do controlador atual, ele não será reinicializado. Em vez disso, o AP entra diretamente no modo de descoberta. Como não foi reinicializado, o AP ainda tem os membros de mobilidade e envia a cada controlador no grupo de mobilidade uma solicitação de descoberta.

• Para que o AP usa os membros de mobilidade?

  Retorno de AP (controlador não configurado para controlador configurado [principal/secundário/terciário]) e aprendendo outros endereços IP de controlador após ingressar em um controlador caso ele perca o contato com o controlador atual. Lembre-se de que o AP esquece os membros de mobilidade durante as reinicializações.

  Observação: pode haver uma condição de corrida neste algoritmo. Entre o momento em que o controlador responde à solicitação de descoberta do AP e o momento em que o AP envia uma solicitação de junção ao gerenciador de AP, o número de APs associados ao gerenciador de AP pode ter sido alterado se houver um grande número de APs que se juntam ao controlador simultaneamente. Por exemplo, se houver uma queda de energia e a energia nos APs voltar simultaneamente, os APs podem não balancear a carga uniformemente nos controladores.

Fallback de AP

Ao contrário do standby Hot Standby Router Protocol (HSRP), o fallback do AP interrompe o serviço sem fio enquanto o AP falha e, em seguida, volta para o controlador configurado. Lembre-se de que, uma vez que um AP se une a um controlador, o AP só é programado para deixar esse controlador se:

• O AP perde respostas de seus keepalives para o controlador.

• O cliente redefine o AP através do controlador.

• O AP recebe uma notificação, através da atualização dos membros do grupo de mobilidade do controlador atual, de que um controlador configurado (Primário/Secundário/Terciário) está ativo, e o AP está atualmente associado a um controlador não configurado com fallback de AP ativado.

É importante observar que o AP executa somente o fallback de AP de um controlador não configurado para um controlador configurado (Primário/Secundário/Terciário). O AP não recuará de um controlador secundário para o controlador principal se estiver atualmente associado ao controlador secundário. Isso ocorre porque o controlador secundário é um controlador configurado.

Quando o AP é associado a um controlador não configurado e é notificado que um controlador configurado está ativo e disponível através dos membros do grupo de mobilidade, ele sai imediatamente do controlador atual e ingressa no controlador configurado.

Observação: o comportamento explicado nesta seção sobre fallback de AP é aplicável a controladores que executam a versão 3.2.171.5 ou anterior. Versões posteriores do firmware do controlador não apresentam esses problemas. Na versão mais recente do firmware, o AP retorna ao controlador principal sempre que ele fica on-line. Se você tiver um problema de fallback de AP, atualize o firmware do controlador para o código disponível mais recente.

Observação: quando um LWAPP AP1242 novo se conecta pela primeira vez a um WLC2006 ou WLC4400 que executa o firmware 2.3.116.21, o nome do controlador secundário (por exemplo: "WIRELESS"->"Detail") na GUI não está em branco. O comando show AP config general também mostra que o nome do controlador secundário não está em branco. Isso foi relatado no bug da Cisco ID CSCse30514 . Embora não haja uma solução alternativa, esse comportamento não está presente na versão 4.0 do software.

Observação: quando você executa o código 5.2 ou posterior em WLCs e configura a alta disponibilidade do AP, se a configuração global 802.11g entre os controladores não corresponder (habilitar vs. desabilitado), isso pode causar problemas de união do AP quando ocorre um evento de failover. Verifique se todas as configurações de WLC são idênticas entre WLCs primárias/secundárias/terciárias.

Recomendações

Para balanceamento de carga aleatório, nenhum dos controladores primário/secundário/terciário precisa ser configurado. No entanto, todos os controladores pelos quais você deseja que o AP faça o balanceamento de carga devem ser definidos na opção de DHCP 43 ou DNS.

Se você quiser garantir o balanceamento de carga perfeito toda vez, a Cisco recomenda que você configure manualmente o controlador principal no AP e deixe os outros dois controladores em branco. Enquanto o controlador principal estiver ativo e funcional, e o grupo de mobilidade estiver definido em qualquer controlador ao qual o AP possa se unir, o AP tentará se unir ao controlador principal sempre que estiver ativo e operacional.

Se você quiser que o AP volte para um controlador secundário no local remoto antes de tentar outro controlador na WAN, todos os três controladores precisam ser definidos na opção de DHCP 43 ou DNS. No entanto, defina somente os controladores primário e secundário nos APs no local remoto.

Se o controlador de WAN não estiver definido na opção de DHCP 43 ou DNS, o AP só falhará se o controlador de WAN estiver no grupo de mobilidade do controlador associado atualmente e se os controladores locais estiverem desativados. Se o AP for reinicializado, ele não ingressará no controlador de WAN, exceto se o último controlador que ele ingressou for o controlador de WAN, até que um dos controladores DHCP 43 ou DNS esteja disponível para informar o AP sobre os membros do grupo de mobilidade.

Observação: o nome do controlador na configuração do AP diferencia maiúsculas de minúsculas. Portanto, configure o nome exato do sistema na configuração do AP. Se isso não for feito, o fallback do AP não estará funcionando.

Verifique se estes parâmetros de configuração estão configurados corretamente:

• O fallback de AP deve ser Habilitado em todas as WLCs. Você pode verificar isso na página da GUI do controlador.

• Antes das versões 5.0.148.0 da WLC, somente os nomes dos sistemas de controladores poderiam ser inseridos nos campos de nome do controlador primário/secundário/terciário do AP. Agora, os endereços IP da interface de gerenciamento do controlador também podem ser usados.

• O failover e o fallback de AP exigem que os controladores sejam configurados no mesmo grupo de mobilidade.

  Use o comando CLI mping para verificar a comunicação de associação de grupo de mobilidade. Use o comando show mobility summary para exibir as informações de configuração do grupo de mobilidade de um controlador.

  Controllers configured in the Mobility Group
   MAC Address        IP Address       Group Name    Status
   00:0b:85:44:36:e0    192.168.240.10   Wireless     Up
   00:1f:9e:9b:08:20    192.168.251.250  Wireless     Control Path Down

  Se você vir o status como Control Path Down, verifique se não há firewall entre as WLCs ou certifique-se de permitir esses protocolos/portas.

Informações Relacionadas

• Configurar grupos de mobilidade para as WLCs
• Perguntas Frequentes de Troubleshooting de Controladoras Wireless LAN (WLC)
• Controladores de LAN sem fio da Cisco
• Guia de Configuração da Cisco Wireless LAN Controller Release 4.0
• Guia de Configuração da Cisco Wireless LAN Controller Release 3.2
• Suporte Técnico e Documentação - Cisco Systems