Sem fio/Mobilidade : LAN Wireless (WLAN)

Práticas Recomendadas de Configuração para o WLC (LAN Controller)

17 Julho 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (16 Novembro 2013) | Inglês (18 Outubro 2013) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Práticas Recomendadas
      Tecnologia Wireless/RF
      Conectividade de Rede
      Design de Rede
      Mobilidade
      Segurança
      Administração Geral
      Como Transferir o Arquivo de Travamento WLC da CLI do WLC para o Servidor TFTP
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Este documento oferece dicas rápidas de configuração que abordam vários problemas relacionados à infra-estrutura wireless unificada normalmente observados no TAC (Technical Assistance Center).

O objetivo é fornecer observações importantes que possam ser aplicadas à maioria das implementações de rede para minimizar possíveis problemas.

Nota: Como nem todas as redes são iguais, é possível que algumas dicas não se apliquem à sua instalação. Verifique-as sempre antes de fazer quaisquer alterações em uma rede ativa.

Pré-requisitos

Requisitos

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

  • Como configurar o WLC (Wireless LAN Controller) e o LAP (Lightweight Access Point) para operação básica

  • Conhecimento básico de LWAPP (Lightweight Access Point Protocol) e métodos de segurança wireless

Componentes Utilizados

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

  • Cisco 2000 / 2100 / 4400 Series WLC que executa o firmware 3.2 ou 4.0

  • Pontos de acesso baseados em LWAPP, séries 1230, 1240, 1130, 10x0 e 1500

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. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Convenções

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

Práticas Recomendadas

Tecnologia Wireless/RF

Estas são as práticas recomendadas relacionadas à tecnologia Wireless/RF (freqüência de rádio):

  • Para qualquer implementação wireless, execute sempre uma análise adequada do local a fim de garantir um serviço de boa qualidade para os clientes wireless. Os requisitos para implementações de voz ou local são mais restritos do que para serviços de dados. A RF automática poderá ser útil no gerenciamento das definições de canal e energia, mas não poderá corrigir um design inadequado de RF.

  • A análise do local deve ser executada com dispositivos que tenham o mesmo comportamento de propagação e energia dos que deverão ser usados na rede real. Por exemplo, não use um rádio 350 802.11B com uma antena omni para analisar a cobertura se a rede final usar rádios duais 1240 para 802.11A e G.

  • Nessa mesma linha de raciocínio, limite o número de SSIDs (service set identifiers) configurados no controlador. Com base no seu modelo de ponto de acesso, você poderá ter configurado 8 ou 16 SSIDs simultâneos, mas, como cada WLAN/SSID necessita de respostas de investigação separadas e beaconing, a poluição de RF aumentará à medida que mais SSIDs forem adicionados. Como resultado, algumas estações wireless menores, como PDAs, telefones WiFi e scanners de código de barras não são capazes de lidar com o alto volume de informações de SSID básico (BSSID). Isso resulta em bloqueios, recargas ou falhas de associação. Além disso, quanto maior for o número de SSIDs, maior será a necessidade de beaconing, portanto, haverá menos espaço de RF disponível para as transmissões de dados reais.

  • Para ambientes de RF que constituem espaços abertos, como fábricas onde há pontos de acesso em uma grande área sem paredes, poderá ser necessário ajustar o limite de potência de transmissão do valor padrão -65 dBm para um menor valor como -76 dBm. Isso permite reduzir a interferência co-canal (o número de BSSIDs ouvidos em um cliente wireless em determinado momento). O valor ideal depende das características ambientais de cada local; portanto, ele deve ser avaliado com cautela através de uma análise do local.

    Limite de potência de transmissão — Este valor, expresso em dBm, é o nível de corte de sinal no qual o algoritmo TPC (Transmit Power Control) ajusta os níveis de energia para baixo, de modo que esse valor indica a intensidade com a qual o terceiro vizinho mais forte de um ponto de acesso é ouvido.

  • Alguns softwares clientes 802.11 poderão encontrar dificuldades se ouvirem mais de determinado número fixo de BSSIDs (por exemplo, 24 ou 32 BSSIDs.) Ao reduzir o limite de potência de transmissão e, portanto, o nível médio de transmissão de ponto de acesso, você poderá reduzir o número de BSSIDs que esses clientes ouvem.

  • Não habilite o balanceamento de carga agressivo a menos que a rede tenha disponível uma alta densidade de pontos de acesso na área e nunca em caso de voz sobre wireless. Se você habilitar esse recurso com pontos de acesso muito distantes uns dos outros, isso poderá confundir o algoritmo de roaming de alguns clientes e ocasionar "furos" de cobertura em alguns casos. Nas versões mais recentes do software, esse recurso está desabilitado por padrão.

Conectividade de Rede

Estas são as práticas recomendadas relacionadas à conectividade de rede:

  • Não use uma árvore de abrangência em controladores.

    Na maioria das topologias, o STP (Spanning Tree Protocol) executado no controlador não é necessário. O STP está desabilitado por padrão

    Para switches que não sejam da Cisco, também é recomendável desabilitar o STP em cada porta.

    Use este comando para verificar isso:

    Cisco Controller) >show spanningtree switch
    
    STP Specification...................... IEEE 802.1D
    STP Base MAC Address................... 00:18:B9:EA:5E:60
    Spanning Tree Algorithm................ Disable
    STP Bridge Priority.................... 32768
    STP Bridge Max. Age (seconds).......... 20
    STP Bridge Hello Time (seconds)........ 2
    STP Bridge Forward Delay (seconds)..... 15
    
    (Cisco Controller) >
    
  • Embora a maior parte da configuração dos controladores seja aplicada de forma instantânea, é aconselhável recarregar os controladores após você alterar as seguintes definições:

    • Endereço de gerenciamento

    • Configuração do SNMP — Isso será muito importante se você usar um software mais antigo.

  • Para todas as portas do tronco que se conectam aos controladores, filtre as VLANs que não estejam em uso.

    Por exemplo, nos switches Cisco IOS®, se a interface de gerenciamento estiver na VLAN 20, e as VLANs 40 e 50 forem usadas para duas WLANs diferentes, use este comando de configuração no switch:

    switchport trunk allowed vlans 20,40,50
    
  • Não configure a porta de serviço com uma sub-rede sobreposta para a interface de gerenciamento.

  • Não deixe uma interface com o endereço 0.0.0.0, por exemplo, uma porta de serviço não configurada. Isso poderá afetar a manipulação de DHCP no controlador.

    Veja como verificar:

    (Cisco Controller) >show interface summary
    Interface Name        Port  Vlan Id   IP Address       Type     Ap Mgr
    --------------------  ----  --------  ---------------  -------  ------
    ap-manager            LAG   15        192.168.15.66    Static   Yes
    example               LAG   30        0.0.0.0          Dynamic  No
    management            LAG   15        192.168.15.65    Static   No
    service-port          N/A   N/A       10.48.76.65      Static   No
    test                  LAG   50        192.168.50.65    Dynamic  No
    virtual               N/A   N/A       1.1.1.1          Static   No
    
  • Não use o LAG a menos que todas as portas do controlador tenham a mesma configuração de Camada 2 no lado do switch. Por exemplo, evite filtrar algumas VLANs em uma porta, e não nas outras.

  • Quando você usa o LAG, o controlador depende do switch para tomar decisões de balanceamento de carga relacionadas ao tráfego proveniente da rede. Ele espera que o tráfego pertencente a um ponto de acesso (LWAPP ou rede para usuário wireless) sempre entre pela mesma porta. Use somente as opções de balanceamento de carga ip-src ou ip-src ip-dst na configuração EtherChannel do switch. Como alguns modelos de switch podem usar mecanismos de balanceamento de carga sem suporte por padrão, é importante fazer essa verificação.

    Veja como verificar o mecanismo de balanceamento de carga EtherChannel:

    switch#show etherchannel load-balance
    EtherChannel Load-Balancing Configuration:
    src-dst-ip
    
    EtherChannel Load-Balancing Addresses Used Per-Protocol:
    Non-IP: Source XOR Destination MAC address
    IPv4: Source XOR Destination IP address
    IPv6: Source XOR Destination IP address
    

    Veja como alterar a configuração do switch (IOS):

    switch(config)#port-channel load-balance src-dst-ip
    
  • Não configure uma conexão LAG que abranja vários switches. Ao usar o LAG, utilize-o com todas as portas pertencentes ao mesmo EtherChannel que vai para o mesmo switch físico. É possível contornar essa limitação usando cenários específicos somente com a funcionalidade EtherChannel cross-stack dos Catalyst 3750 Switches.

  • Caso não use uma topologia LAG, você deverá sempre criar um gerenciador de pontos de acesso por porta física, para fins de redundância e escalabilidade.

  • Nunca configure uma porta alternativa para uma interface do gerenciador de pontos de acesso, mesmo que isso seja possível em versões mais antigas do software. A redundância é fornecida pelas diversas interfaces do gerenciador de pontos de acesso, conforme mencionado anteriormente neste documento.

Design de Rede

Estas são as práticas recomendadas relacionadas ao design da rede:

  • Limite o número de pontos de acesso por VLAN. O número adequado é cerca de 30 a 60 e depende das características da rede. Isso ajudará a minimizar problemas de reassociação em caso de falha da rede.

  • Em relação à primeira dica, não coloque mais de 20 pontos de acesso na mesma VLAN com a interface de gerenciamento do controlador. É possível que, devido ao grande número de mensagens de broadcast geradas pelos pontos de acesso, algumas mensagens de descoberta sejam descartadas, o que poderá resultar na entrada de um ponto de acesso mais lento nos processos.

  • Em cada design, a maior parte do tráfego iniciado na CPU é enviada do endereço de gerenciamento no controlador. Por exemplo, interceptações SNMP, pedidos de autenticação RADIUS e assim por diante.

    A exceção a essa regra é o tráfego relacionado a DHCP, que é enviado da interface relativa às definições de WLAN, no caso do software de controlador versão 4.0 e posterior. Por exemplo, se uma WLAN usar uma interface dinâmica, o pedido DHCP será encaminhado usando este endereço da Camada 3.

    É importante levar isso em consideração quando você configura políticas de firewall ou cria a topologia da rede. É importante evitar a configuração de uma interface dinâmica na mesma sub-rede de um servidor que precise ser acessado pela CPU do controlador (por exemplo, um servidor RADIUS), pois isso poderá ocasionar problemas de roteamento assimétrico.

Mobilidade

Estas são as práticas recomendadas relacionadas à mobilidade:

  • Todos os controladores em um grupo de mobilidade devem ter o mesmo endereço IP para uma interface virtual, por exemplo, 1.1.1.1. Isso é importante para roaming.

    Veja como verificar:

    (Cisco Controller) >show interface summary
    
    Interface Name      Port   Vlan Id   IP Address       Type     Ap Mgr
    -----------------   -----  --------  ---------------  -------  ------
    ap-manager           LAG   15        192.168.15.66    Static   Yes
    management           LAG   15        192.168.15.65    Static   No
    service-port         N/A   N/A       10.48.76.65      Static   No
    test                 LAG   50        192.168.50.65    Dynamic  No
    virtual              N/A   N/A       1.1.1.1          Static   No
    
  • O endereço do gateway virtual deve ser "não roteável" na infra-estrutura de rede. Ele só poderá ser acessado por um cliente wireless quando conectado a um controlador, e nunca a partir de uma conexão com fio.

  • Não crie grupos de mobilidade desnecessariamente grandes. Um grupo de mobilidade deve ter somente todos os controladores que possuem pontos de acesso na área onde um cliente pode fazer roaming fisicamente; por exemplo, todos os controladores com pontos de acesso em um edifício. Em uma situação em que haja vários edifícios separados, eles devem ser divididos em vários grupos de mobilidade. Isso economizará memória e CPU, uma vez que os controladores não precisarão manter listas grandes de pontos de acesso, invasores e clientes válidos no grupo, os quais não interagiriam de forma alguma.

    Lembre-se de que a redundância de WLCs é obtida através dos grupos de mobilidade. Portanto, em algumas situações, talvez seja necessário aumentar o tamanho desses grupos, incluindo controladores adicionais para fins de redundância (topologia N+1, por exemplo).

  • Nos cenários em que há mais de um controlador em um grupo de mobilidade, é normal ver alguns alertas de pontos de acesso invasores sobre nossos próprios pontos de acesso na rede após a recarga de um controlador. Isso acontece devido ao tempo necessário para atualizar as listas de pontos de acesso, clientes e invasores entre os membros do grupo de mobilidade.

  • A opção DHCP Required nas definições da WLAN permite forçar os clientes a fazer um pedido/renovação de endereços DHCP toda vez que eles se associam à WLAN, antes de poderem enviar ou receber outro tráfego na rede. Do ponto de vista da segurança, isso possibilita um controle mais rígido dos endereços IP em uso, mas também poderá afetar o tempo total de roaming até que o tráfego seja permitido novamente.

    Além disso, isso poderá afetar algumas implementações de clientes que não fazem uma renovação de DHCP até que o tempo de concessão expire. Por exemplo, os telefones Cisco 7920 ou 7921 podem apresentar problemas de voz durante o roaming se essa opção estiver habilitada, pois o controlador não permite que haja tráfego de voz ou sinalização até que a fase DHCP seja concluída. Alguns servidores de impressão de terceiros também podem ser afetados. Em geral, é aconselhável não usar essa opção se a WLAN possuir clientes não-Windows. O motivo disso é que os controles mais rígidos podem ocasionar problemas de conectividade com base no modo como o cliente DHCP é implementado. Veja como verificar:

    (Cisco Controller) >show wlan 1
    
    
    WLAN Identifier.................................. 1
    Profile Name..................................... 4400
    Network Name (SSID).............................. 4400
    Status........................................... Enabled
    MAC Filtering.................................... Disabled
    Broadcast SSID................................... Enabled
    AAA Policy Override.............................. Disabled
    Number of Active Clients......................... 0
    Exclusionlist Timeout............................ 60 seconds
    Session Timeout.................................. 1800 seconds
    Interface........................................ management
    WLAN ACL......................................... unconfigured
    DHCP Server...................................... Default
    DHCP Address Assignment Required................. Disabled
    Quality of Service............................... Silver (best effort)
    WMM.............................................. Disabled
    CCX - AironetIe Support.......................... Enabled
    CCX - Gratuitous ProbeResponse (GPR)............. Disabled
    Dot11-Phone Mode (7920).......................... Disabled
    Wired Protocol................................... None
    

Segurança

Estas são as práticas recomendadas relacionadas à segurança:

  • É recomendável alterar o timeout do RADIUS para 5 segundos. O padrão de 2 segundos é aceitável para um rápido failover do RADIUS, mas provavelmente não será suficiente para autenticação EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) ou se o servidor RADIUS precisar contatar bancos de dados externos (Active Directory, NAC, SQL etc.).

    Veja como verificar:

    (Cisco Controller) >show radius summary
    Vendor Id Backward Compatibility............ Disabled
    Credentials Caching......................... Disabled
    Call Station Id Type........................ IP Address
    Administrative Authentication via RADIUS.... Enabled
    Aggressive Failover......................... Disabled
    Keywrap..................................... DisabledAuthentication Servers
    
    
    !--- Esta parte do código foi quebrada em várias linhas devido a restrições
    !--- de espaço.
    
    Idx  Type  Server Address    Port    State    Tout RFC3576
    ---  ----  ----------------  ------  --------  ----  -------
    1    N     10.48.76.50       1812    Enabled   2    Enabled
    
    IPSec -AuthMode/Phase1/Group/Lifetime/Auth/Encr
    ------------------------------------------------
    Disabled - none/unknown/group-0/0 none/none
    

    Veja como fazer a configuração:

    config radius auth retransmit-timeout 1 5
    
  • Verifique o usuário padrão SNMPv3. Por padrão, o controlador vem com um nome de usuário que deve ser desabilitado ou alterado.

    Veja como verificar:

    (Cisco Controller) >show snmpv3user
    
    SNMP v3 User SNMP v3 User Name AccessMode Authentication Encryption
    -------------------- ----------- -------------- ----------
    default Read/Write HMAC-MD5 CBC-DES
    

    Veja como fazer a configuração:

    config snmp v3user delete default
    config snmp v3user create nondefault rw hmacsha des authkey encrkey
    

    Lembre-se de que as definições de SNMP devem ser as mesmas no controlador e no WCS (Wireless Control System). Além disso, utilize chaves de hash e criptografia que estejam de acordo com as suas políticas de segurança.

  • Quando executar a autenticação na Web com uma página de autenticação externa, não use um servidor que tenha um servidor web e um servidor proxy ao mesmo tempo para hospedar a página de login. O controlador permite o tráfego HTTP do cliente wireless para o servidor até que a autenticação seja concluída. Dessa maneira, o cliente pode navegar usando o serviço de proxy presente no servidor.

  • Nos controladores, o timeout padrão do pedido de Identidade EAP é 1 segundo, o que não é suficiente em algumas situações, como senhas de utilização única ou implementações de cartões inteligentes, em que o usuário é solicitado a gravar um PIN ou uma senha para que o cliente wireless possa atender ao pedido de identidade. Nos pontos de acesso autônomos, o padrão é 30 segundos; portanto, isso deve ser considerado ao migrar de redes autônomas para redes wireless de infra-estrutura.

    Veja como fazer a alteração:

    config advanced eap identity-request-timeout 30
    
  • Em ambientes agressivos, um recurso útil é habilitar a autenticação de pontos de acesso com um limite igual a 2. Isso permite detectar possíveis representações e minimizar detecções de falsos positivos.

    Veja como fazer a configuração:

    config wps ap-authentication enable
    config wps ap-authentication threshold 2
    
  • Em relação à dica anterior, o MFP (Management Frame Protection) também pode ser usado para autenticar todo o tráfego de gerenciamento 802.11 detectado entre os pontos de acesso próximos na infra-estrutura wireless. Lembre-se de que algumas placas wireless comuns de terceiros apresentam problemas na implementação de seus drivers, os quais não tratam corretamente os elementos de informação extras adicionados pelo MFP. Utilize os drivers mais recentes do fabricante da placa antes de testar e usar o MFP.

  • O NTP é muito importante para vários recursos. É obrigatório usar a sincronização NTP nos controladores se você utilizar quaisquer destes recursos: Autenticação de ponto de acesso, SNMPv3, local ou MFP.

    Veja como fazer a configuração:

    config time ntp server 1 10.1.1.1
    

    Para verificar, procure entradas semelhantes a esta em seu log de interceptação:

    30 Tue Feb 6 08:12:03 2007 Controller time base status -
    Controller is in sync with the central timebase.
    
  • Ao usar o PEAP-MSCHAPv2 (Protected EAP-Microsoft Challenge Handshake Authentication Protocol versão 2) com o Microsoft XP SP2, e se a placa wireless for gerenciada pelo Microsoft WZC (Wireless Zero Configuration), você deverá aplicar o hotfix da Microsoft KB885453 leavingcisco.com. Isso evitará vários problemas de autenticação relacionados ao reinício rápido do PEAP.

  • Caso, por motivos de segurança, os clientes wireless devam ser separados em várias sub-redes, cada uma delas com políticas de segurança diferentes, é aconselhável usar uma ou duas WLANs (por exemplo, cada uma com uma política de criptografia de Camada 2 diferente), com o recurso de anulação de AAA. Esse recurso permite que você atribua definições a cada usuário. Por exemplo, você poderá mover o usuário para uma interface dinâmica específica em uma VLAN separada ou aplicar uma lista de controle de acesso a cada usuário.

  • Embora o controlador e os pontos de acesso ofereçam suporte a WLAN com SSID usando o WPA (Wi-Fi Protected Access) e o WPA2 simultaneamente, é muito comum que alguns drivers de clientes wireless não sejam capazes de tratar definições de SSID complexas. Em geral, é recomendável manter políticas de segurança simples para todos os SSIDs, por exemplo, usando uma WLAN/SSID com WPA e TKIP (Temporal Key Integrity Protocol), além de outra separada com WPA2 e EAS (Advanced Encryption Standard).

Administração Geral

Estas são as práticas recomendadas relacionadas à administração geral:

  • Em geral, antes de qualquer atualização, é recomendável realizar um backup binário da configuração. Os WLCs oferecem suporte à conversão das informações de configuração mais antigas em novas versões, mas não há suporte para o processo inverso. Isso se aplica a alterações importantes ou menos relevantes de versões.

  • O uso de uma configuração mais nova em uma release antiga poderá resultar em definições ausentes (listas de acesso, interfaces etc.) ou no funcionamento incorreto de recursos. Se precisar fazer downgrade de um controlador, é aconselhável, após esse procedimento, limpar a configuração, configurar novamente o endereço da interface de gerenciamento e carregar o arquivo de backup binário por meio do TFTP.

Como Transferir o Arquivo de Travamento WLC da CLI do WLC para o Servidor TFTP

Execute estes comandos para transferir o arquivo de travamento WLC do WLC CLI para o servidor TFTP.

transfer upload datatype crashfile
transfer upload serverip <IP address of the TFTP Server>

transfer upload path <Enter directory path>

transfer upload filename <Name of the Crash File>

transfer upload start<yes>

Nota: Quando você insere o caminho de diretório, "/" geralmente indica o diretório-raiz padrão no servidor TFTP.

Aqui está um exemplo:

(Cisco Controller) >debug transfer tftp enable

(Cisco Controller) >debug transfer trace enable

(Cisco Controller) >transfer upload datatype crashfile

(Cisco Controller) >transfer upload filename aire2cra.txt

(Cisco Controller) >transfer upload path /

(Cisco Controller) >transfer upload serverip X.Y.Z.A

(Cisco Controller) >transfer upload start

Mode............................................. TFTP TFTP Server
IP................................... X.Y.Z.A TFTP
Path........................................ / TFTP
Filename.................................... aire2cra.txt Data
Type........................................ Crash File

Are you sure you want to start? (y/N) yes
Thu Dec 29 10:13:17 2005: RESULT_STRING: TFTP Crash File transfer starting.
Thu Dec 29 10:13:17 2005: RESULT_CODE:1

TFTP Crash File transfer starting.
Thu Dec 29 10:13:21 2005: Locking tftp semaphore, pHost=X.Y.Z.A
pFilename=/aire2cra.txt Thu Dec 29 10:13:22 2005:
Semaphore locked, now unlocking,
pHost=X.Y.Z.A pFilename=/aire2cra.txt Thu Dec 29 10:13:22 2005:
Semaphore successfully unlocked,
pHost=X.Y.Z.A pFilename=/aire2cra.txt Thu Dec 29 10:13:22 2005:
tftp rc=0, pHost=X.Y.Z.A pFilename=/aire2cra.txt


pLocalFilename=/mnt/application/bigcrash
Thu Dec 29 10:13:22 2005: RESULT_STRING: File transfer operation
completed successfully.
Thu Dec 29 10:13:22 2005: RESULT_CODE:11 File transfer operation
completed successfully.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 82463