Balanceamento de carga e fallback de AP em redes sem fio unificadas

Introdução

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 anterior a 3.2.171.5. Versões posteriores do firmware da controladora não se comportam dessa maneira. Na versão mais recente do firmware, o AP volta para a controladora primária sempre que 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.

Pré-requisitos

Requisitos

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

• Configuração de APs leves e WLCs da Cisco

• 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 com firmware 3.2.78.0

• Servidor DHCP Microsoft Windows Server 2003 Enterprise

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Produtos Relacionados

Essa configuração também pode ser usada com qualquer outra 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 Exemplo de Configuração de Failover de Controladora WLAN para Pontos de Acesso Lightweight para obter informações sobre como configurar a WLC e o AP lightweight para failover.

Balanceamento de carga do AP

Você pode executar o balanceamento de carga do 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 receber. Na resposta de descoberta LWAPP da WLC, 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 unidos à WLC no momento

• A capacidade do AP

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

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

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 para o AP. A principal resposta de descoberta 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 de Fallback do AP habilitado, o AP pode decidir mudar para uma WLC menos carregada.

Quando o AP é inicializado ou redefinido, ele só sabe os endereços IP de gerenciamento da controladora do DNS (Cisco-lwapp-controller@local_domain.com) (20 máx), DHCP opção 43 (20 máx), OTAP, 255.255.255.255 e a controladora anteriormente unida. As controladoras no grupo de mobilidade da controladora anteriormente unida não são mantidas nas reinicializações.

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

Observação: quando um AP entra em uma controladora, ele só sai da controladora atualmente unida por um número limitado de motivos. Uma razão para que o AP não saia da controladora atualmente unida é se os APs não tiverem exatamente balanceamento de carga em todas as controladoras. 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 primário para cada AP.

Essas regras são melhor descritas com alguns exemplos:

• O AP é novo, pronto para uso e nunca unido a 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 do controlador durante a inicialização via OTAP, DNS (com todos os 3 endereços IP de gerenciamento definidos), 255.255.255.255 e DHCP Opção 43 (com todos os 3 endereços IP de gerenciamento incluídos) para o balanceamento de carga. O AP envia uma solicitação de detecção a todas as controladoras conhecidas e se une à controladora com a maior capacidade de AP em excesso. Se apenas 1 controlador for definido na opção de DHCP 43/DNS, os novos APs sempre se unirão a esse controlador.

• Se houver 1 controlador definido na opção de DHCP 43/DNS e houver 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 depois que ele se unir à controladora na opção de DHCP 43?

  Não. Se o AP for reinicializado ou redefinido, ele sempre se junta à controladora na opção de DHCP 43/DNS ou na última controladora unida. No entanto, se o AP perder a pulsação para o controlador atual, ele não reinicializará. Em vez disso, o AP entra diretamente no modo de descoberta. Como ele 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 detecção.

• Para que o AP usa membros de mobilidade?

  Fallback de AP (controlador não configurado para controlador configurado [primário/secundário/terciário]) e aprendizado de outros endereços IP do controlador depois que ele ingressa em um controlador caso perca o contato com o controlador atual. Lembre-se de que o AP esquece os membros de mobilidade nas reinicializações.

  Observação: pode haver uma condição de corrida neste algoritmo. Entre o momento em que o controlador responde à solicitação de detecção 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 unidos ao gerenciador de AP pode ter mudado se houver um grande número de APs que se unem ao controlador simultaneamente. Por exemplo, se houver uma queda de energia e a energia nos APs voltar simultaneamente, os APs podem não ter balanceamento de carga uniforme entre os controladores.

Fallback de AP

Diferentemente do standby Hot Standby Router Protocol (HSRP), o fallback do AP interrompe o serviço sem fio enquanto o AP faz failover e depois retorna ao controlador configurado. Lembre-se de que uma vez que um AP se une a uma controladora, o AP só é programado para sair dessa controladora se:

• O AP perde respostas de seus keepalives para a controladora.

• O cliente reinicia o AP por meio da controladora.

• O AP recebe 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 que o AP está atualmente unido a um controlador não configurado com fallback de AP habilitado.

É importante observar que o AP executa apenas o fallback do AP de um controlador não configurado para um controlador configurado (primário/secundário/terciário). O AP não voltará de um controlador secundário para o controlador primário se estiver atualmente unido ao controlador secundário. Isso ocorre porque o controlador secundário é um controlador configurado.

Quando o AP é unido a um controlador não configurado e é notificado de que um controlador configurado está ativo e disponível através dos membros do grupo de mobilidade, ele imediatamente deixa o controlador atual e se junta ao controlador configurado.

Observação: o comportamento explicado nesta seção sobre fallback de AP é aplicável a controladoras 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 volta para a controladora primária sempre que 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.

Note:  Quando um AP1242 LWAPP totalmente novo se conecta primeiro a um WLC2006 ou WLC4400 que executa o firmware 2.3.116.21, o nome do controlador secundário (ou seja, "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 de software 4.0.

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 802.11g global entre as controladoras não coincidir (habilitar vs. desabilitar), isso pode causar problemas de junção de AP quando ocorrer um evento de failover. Certifique-se de que todas as configurações de WLC sejam idênticas entre as WLCs primária/secundária/terciária.

Recomendações

Para o balanceamento de carga aleatório, nenhum dos controladores primário/secundário/terciário precisa ser configurado. No entanto, todos os controladores nos 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 todas as vezes, a Cisco recomenda que você configure manualmente o controlador primário no AP e deixe os outros dois controladores em branco. Desde que a controladora primária esteja ativa e funcional e o grupo de mobilidade seja definido através de qualquer controladora à qual o AP possa se unir, o AP tentará se unir à controladora primária sempre que ela estiver ativa e operacional.

Se você quiser que o AP retorne para um controlador secundário no local remoto antes de tentar outro controlador na WAN, todos os 3 controladores precisam ser definidos na opção de DHCP 43 ou DNS. No entanto, defina apenas 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ó fará failover para ele se o controlador de WAN estiver no grupo de mobilidade do controlador atualmente associado e se os controladores locais forem desativados. Se o AP for reinicializado, ele não se juntará ao controlador de WAN, exceto se o último controlador ao qual ele se juntou foi o controlador de WAN, até que uma das controladoras DHCP 43 ou DNS esteja disponível para informar o AP sobre os membros do grupo de mobilidade.

Observação: o nome da controladora na configuração do AP diferencia maiúsculas de minúsculas. Portanto, certifique-se de configurar o nome exato do sistema na configuração do AP. Se isso não for feito, o fallback do AP não funcionará.

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 da controladora.

• Antes das versões 5.0.148.0 da WLC, somente os nomes do sistema do controlador podiam 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 da associação do grupo de mobilidade. Use o comando show mobility summary para exibir 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á nenhum 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