Validar o rendimento do Wi-Fi: Guia de teste e monitoramento

Introdução

Este documento descreve como monitorar e solucionar problemas de throughput em grandes redes Wi-Fi.

Contexto

Nas redes Wi-Fi, não há muitos tipos de problemas percebidos pelos usuários finais.

Os problemas relatados podem variar entre:

• clientes que não conseguem se conectar;
• clientes que se desligam repentinamente ou;
• a velocidade percebida do aplicativo no dispositivo do usuário não é satisfatória.

Por trás desses sintomas simples podem estar centenas de tipos de problemas, a maioria não envolvendo as redes Wi-Fi reais, como problemas de DNS, problemas de conexão com a Internet e assim por diante.

Os servidores de gerenciamento como o Cisco Catalyst Center ajudam o administrador a solucionar problemas específicos e este artigo não aborda detalhadamente esses vários tipos de problemas diários que podem ser facilmente vistos e corrigidos pelo Catalyst Center. Em vez disso, este documento concentra-se no feedback mais vago dos usuários finais de que a rede é lenta.

Como testar isso? Como validar o throughput real em toda a sua rede? Como fazer a triagem dos problemas relacionados à velocidade em itens acionáveis para melhorar a experiência geral do usuário final?

Estas são todas as perguntas que este documento tenta responder.

Definição do throughput máximo esperado

A primeira pergunta em cada rede é: qual é a velocidade máxima que poderia ser atingida potencial e realisticamente?

Como o Wi-Fi é um meio compartilhado, a velocidade depende diretamente do número de clientes e dispositivos que usam o Wi-Fi ao mesmo tempo no mesmo canal. Portanto, essa questão da velocidade máxima real que pode ser alcançada diretamente implica ter um único dispositivo cliente e um único ponto de acesso em um local isolado e silencioso onde ninguém está usando o mesmo canal Wi-Fi. Nestas condições, os fatores para determinar a velocidade máxima resumem-se a:

• O protocolo Wi-Fi usado (Wi-Fi 5, Wi-Fi 6, ...)
• As capacidades de hardware do cliente e do ponto de acesso (número de antenas, número de fluxos espaciais, conexão Ethernet do ponto de acesso, ...)
• A configuração (largura do canal, ...)

Conhecer esses fatores permite que você tenha uma estimativa de qual seria o throughput máximo da vida real que você poderia alcançar em condições de laboratório.

Para ter uma ideia rápida, verifique em que taxa de dados o cliente relata estar conectado ao ponto de acesso. Essa taxa de dados não é a taxa de transferência real que você pode comprovar em seus testes. Isso ocorre porque o Wi-Fi é um meio half-duplex que tem alguma sobrecarga de gerenciamento (os quadros precisam ser reconhecidos, os beacons precisam ser transmitidos) e também silêncios curtos entre os quadros para uma melhor recepção e decodificação. Isso significa que, quando os dados são enviados, eles são enviados na taxa de dados documentada, mas os dados nem sempre são enviados. Os quadros de gerenciamento e controle são enviados a uma taxa de dados muito menor para garantir a recepção. Uma estimativa é que você pode considerar atingir 65 a 70% da taxa de dados usada em um teste de throughput real. Por exemplo, se o cliente relatar estar conectado e enviar dados a 866 Mbps, os testes reais devem relatar uma velocidade de transferência em torno de 600 Mbps.

Se você souber os parâmetros de configuração em uso, bem como as capacidades de hardware dos dispositivos envolvidos, também poderá descobrir qual taxa de dados máxima (e, portanto, throughput, usando o cálculo de porcentagem documentado nesta seção) deve ser atingível.

Se houver uma incompatibilidade entre a taxa de dados relatada e a taxa que você esperava atingir, inicie o processo de solução de problemas pela configuração e verifique os vários parâmetros para entender onde está a lacuna.

Um exemplo: se você tiver um Access Point modelo C9120 transmitindo em uma largura de canal de 20 Mhz na banda de 5 Ghz e um típico cliente Wi-Fi 6 de 2 fluxos espaciais, poderá calcular que, em um ambiente de RF (Radiofreqüência) perfeitamente limpo, com um único cliente, você poderia alcançar de 160 a 200 Mbps em uma única transferência de arquivo.

Mais informações sobre validação e teste de rendimento estão documentadas aqui: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.html.

Estabelecer a experiência básica

É importante saber o que se pode esperar em seu local em circunstâncias típicas. Geralmente, um técnico visita o local vazio antes da implantação, executa testes de velocidade e documenta os números esperados.

Depois, funcionários ou clientes entram, o site fica ocupado e a experiência real é muito diferente.

Depois que uma implantação entra em operação, é uma ideia inteligente enviar técnicos para medir a experiência real em cada área e anotar como é a rede em um dia bom comum.

Isso inclui a quantidade média de clientes por rádio quando a rede está operando em um nível satisfatório, bem como o throughput médio obtido com um teste de velocidade.

Procure desvios da experiência

Ao operar sua rede, monitorar alertas importantes ou dispositivos que repentinamente ficam inativos é fácil. Este documento concentra-se na parte difícil: como identificar uma rede sem fio que ainda funciona, mas fornece uma experiência de usuário final inferior.

Localizar evidência de um problema (teste passivo)

Você mesmo testou sua rede; você sabe que ela funciona bem e que está monitorando seus sistemas de gerenciamento e painéis. Nada é relatado como inativo: você pode dar um passo para trás e relaxar. Ou você pode?

Se você esperar por ecos dos usuários finais reclamando sobre a experiência ruim, é possível que você esteja atrasado demais. Quando os usuários finais reclamam, o problema está ocorrendo há muito tempo e você só ouve dos poucos usuários que falaram o suficiente para você ouvir.

Inúmeros usuários já se sentiram frustrados, não disseram nada a você ou ao seu suporte, mas deram má reputação à sua rede.

Então, a questão é: como você pode identificar ocorrências de experiência ruim assim que elas ocorrem?

1. O painel de garantia do cliente no Cisco Catalyst Center

No painel de garantia do Cisco Catalyst Center, você tem um gráfico geral da integridade de seus clientes.

Sempre há alguns clientes que não conseguem se conectar porque alguém digitou a chave errada, ou o dispositivo está no limite da sua cobertura, então não espere atingir 100% dos clientes íntegros, mas familiarize-se com o que é uma boa porcentagem de clientes íntegros para seu ambiente.

Estar na faixa dos anos 90 é normalmente uma boa notícia.

Você pode ver rapidamente o que está acontecendo com os clientes que não estão íntegros:

• Eles estão longe do AP (pontos de acesso)?
• É um problema de autenticação?

Você pode ver facilmente neste gráfico a proporção de cada categoria.

Na mesma gama de ideias, você pode rolar para o final dessa página e filtrar para exibir os dispositivos clientes que são relatados como tendo uma saúde ruim. Você pode tentar detectar se há algum padrão:

• Possivelmente, todos estão conectados na faixa de 2,4 GHz (que é conhecida por fornecer uma experiência pior em muitos casos);
• Todos eles são potencialmente relatados em uma baixa intensidade de sinal;
• Eles estão potencialmente todos na mesma área fisicamente.

2. O painel e o dispositivo de garantia de rede 360 no Cisco Catalyst Center

Uma métrica particularmente boa para identificar uma área de problemas em potencial específica é acessar a página Network Assurance do Cisco Catalyst Center. Você tem um widget mostrando os principais pontos de acesso por contagem de clientes:

Se o ponto de acesso superior da rede tiver 40 clientes conectados, você estará bem. Isso implica que todos os outros APs (pontos de acesso) têm uma contagem de clientes mais baixa.

Por outro lado, se você encontrar o(s) AP(s) superior(es) com um número excepcionalmente alto de clientes, você pode adivinhar que a experiência do cliente é particularmente ruim (a menos que a maioria dos clientes esteja dormindo e não ativo na rede).

Você pode então passar para uma investigação "por AP" onde você amplia os APs superiores específicos relatados neste widget para entender sua integridade atual.

Outro método de examinar a contagem de clientes é ir para os mapas na página Hierarquia de rede do Catalyst Center. Na página de visualização do andar, clique em "View Options" e, na seção Access Points, altere a exibição para "Assoc. Clientes" para exibir a contagem de clientes por AP:

A vantagem da técnica de mapa é que você pode identificar onde está o AP com alta contagem de clientes e avaliar se a alta contagem pode ser justificada (pode haver uma boa razão para uma multidão se reunir naquele local naquele determinado momento).

Você também pode observar os APs vizinhos: se eles compartilharem parte da carga, tudo ficará bem. Se um AP tiver uma contagem de clientes anormalmente alta enquanto os APs vizinhos não tiverem nenhum cliente, a situação fica mais suspeita.

Pode haver um problema com os APs vizinhos (se a contagem de seus clientes for zero) ou o design de RF pode fazer com que o AP problemático atraia todos os clientes em comparação com seus vizinhos (por exemplo, devido a uma potência de TX muito mais alta e/ou antenas diferentes).

O mapa oferece uma boa visão geral dos clientes associados em cada AP

Depois de identificar APs potencialmente problemáticos onde a contagem de clientes é extremamente alta, você pode procurar o nome desse AP e abrir a página do dispositivo 360.

O gráfico de integridade oferece uma visão geral se a integridade desse AP está ruim no momento ou se ele foi constantemente ruim no último dia ou mais.

Na mesma página, você tem uma lista de problemas relacionados a esse AP. Nesse caso, está claro que ambos os rádios estão com alta utilização.

O visualizador de eventos pode dar uma ideia se houve eventos específicos relacionados a esse AP.

Um exemplo poderia ser um algoritmo RRM definido para ser executado com muita frequência e causando alterações frequentes nos canais que afetam os clientes conectados, ou um rádio que se reinicia constantemente devido a vários problemas ou interferências.

No final da página do dispositivo 360, você pode definir a visualização para "RF", selecionar o rádio específico e você tem informações interessantes que permitem avaliar a origem do problema.

Ter muitos clientes não é necessariamente um problema: tudo depende de quão ativos eles são.

Às vezes, mesmo com alguns clientes, o AP pode estar com as mãos ocupadas e oferecer uma experiência ruim. O indicador real é a utilização do canal.

Quando a utilização do canal se aproxima de 100% (mesmo começando em 70%), os clientes começam a disputar muito pelo acesso ao meio, experimentam latência e colisões.

Os gráficos permitem comparar a utilização total do canal e essa parte do AP de responsabilidade.

Por exemplo, se a utilização do canal for de 80%, isso significa que 80% do tempo haverá "alguém" transmitindo pelo canal. Se o AP mostrar 40% de utilização de Rx e 40% de utilização de Tx, você saberá que apenas esse AP é responsável por manter o canal ocupado (isto é, nenhum outro AP está transmitindo) e que ele está bem balanceado entre o recebimento e a transmissão. Se o AP combinado com a utilização Rx e Tx estiver longe da utilização do canal, isso implica que outro AP (invasor ou gerenciado) está usando o mesmo canal e causando a mesma interferência do canal.

Esta captura de tela representa um AP em que o canal está extremamente ocupado (91%):

O gráfico mostra que apenas 7% dessa utilização é devido a outros APs e fontes não WiFi e que o AP está ocupado transmitindo por 82% do tempo e recebendo por apenas 2%.

O número de clientes e a taxa de transferência total indicariam que um ou mais clientes provavelmente estão baixando arquivos grandes.

O gráfico de interferência permite determinar se o canal é mantido ocupado por transmissões Wi-Fi ou interferências reais (não-Wi-Fi):

Como conclusão, e como regra geral, você precisa cuidar dos APs com a maior contagem de clientes e utilização de canal. Em seguida, é necessário avaliar se essa carga é justificada ou não e se causa uma experiência ruim para os usuários finais nessa área.

3. Análise da IA

A análise de IA oferece monitoramento mais inteligente. A monitoração não se baseia mais em limites fixos, mas se adapta ao uso da linha de base.

O mapa de calor da rede apresenta uma evolução da contagem de clientes, para identificar os APs com a maior contagem de clientes na semana. Você também pode identificar facilmente APs que constantemente não conectam clientes: o problema oposto também é um problema.

Pode haver um problema físico com esses APs (problema de montagem, problema com as antenas e assim por diante) ou um problema de software se o rádio estiver congelado (e se uma reinicialização desse AP corrigi-lo).

A página Tendências e percepções fornece uma lista de APs que mostram regularmente a utilização de alto canal ou a atividade do cliente para que você possa verificar facilmente se isso corresponde às suas áreas de maior atividade ou se há algo anormal a isso:

Testes ativos da infraestrutura

Quando os usuários relatam uma experiência ruim em uma área específica, você deseja testá-la ativamente para confirmar seu feedback. É importante entender que os testes típicos variam muito do tráfego real de clientes.

Os usuários normalmente tentam usar seu aplicativo favorito e ficam felizes se isso funcionar. Eles raramente transferem arquivos grandes. Seu aplicativo favorito pode ter comportamentos diferentes:

• Vídeo sob demanda: isso pode consumir qualquer quantidade de largura de banda (depende se o vídeo tiver 720p ou 4K, por exemplo).
  • É muito tolerante ao jitter, pois armazena alguns segundos ou minutos de vídeo com antecedência. O padrão se parece com uma transferência de arquivo grande por um breve período e, em seguida, silencia enquanto o vídeo é reproduzido a partir do buffer até que o próximo pré-carregamento ocorra.
• Chamada de voz: consome uma quantidade insignificante de largura de banda, mas é extremamente sensível à latência e ao jitter.
  • Isso pode potencialmente usar a marcação de QoS (Qualidade de Serviço) e, portanto, enfrentar uma experiência diferente (priorizada) do tráfego de melhor esforço.
• Dados: um aplicativo de mídia social baixa dados por rajadas.
  • A quantidade varia com base no conteúdo e na velocidade de rolagem do usuário.

Uma aplicação típica de teste de throughput maximiza o protocolo para alcançar a maior velocidade de transferência possível: ela tenta reservar o meio e enviar o máximo de quadros de dados concatenados possível. Isso não representa o mesmo tipo de uso que os aplicativos reais (exceto transferências de arquivos), que são muito intermitentes por natureza.

O teste de aplicativos reais imita o comportamento do usuário, mas impossibilita a comparação entre métricas e números reais. Você só terá uma sensação subjetiva se a rede for tranquila ou não.

Para o teste de rendimento, muitos sites são populares e fornecem uma imagem decente da experiência do usuário final enquanto testam toda a largura de banda entre o cliente e a Internet. No entanto, se você quiser validar sua rede sem fio separadamente da conexão com a Internet e de problemas de roteamento e firewall, é recomendável usar uma ferramenta de teste de taxa de transferência dedicada, como Iperf: https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047.

Essa ferramenta permite testes específicos entre um cliente e um servidor que você coloca na rede. Isso permite mover o servidor para locais específicos na rede e testar o throughput em seções de rede cada vez mais longas para validar cada seção. Comece por colocar o servidor Iperf no mesmo switch que o AP onde o seu cliente sem fio está no caso de switching local ou sem fio habilitado para matriz ou no mesmo switch que o WLC (Wireless LAN Controller) (e na VLAN do cliente, se possível) no caso de switching central.

Se estiver usando uma WLC âncora, você deve colocar o servidor Iperf no mesmo switch que a WLC âncora, pois é aí que o tráfego é encerrado. Às vezes, pode ser interessante criar uma WLAN (Wireless LAN) não ancorada para ver se os resultados de throughput potencialmente decepcionantes são causados pela própria ancoragem versus uma WLAN não ancorada.

Não faz sentido usar vários clientes para fazer testes de throughput ao mesmo tempo. Durante o teste de throughput, espera-se que esse único cliente use a totalidade do tempo de transmissão do canal disponível. Portanto, se dois clientes fizerem um teste de rendimento ao mesmo tempo, cada um verá um resultado dividido pelo menos pela metade. Se mais clientes forem usados, as colisões começarão a ocorrer em números e os resultados não serão mais representativos.

Há várias ferramentas de ^terceiros para automatizar o teste de rede. Esteja ciente de que, enquanto você está testando o throughput em uma área, você está usando efetivamente todo o tempo de transmissão durante o teste, e então é uma má ideia testar a rede com muita frequência, pois ela causa interrupções para outros clientes.

Solução de um problema de throughput

Quando você identifica um problema de throughput, várias coisas podem ser observadas para isolar o problema:

• Isole se, antes de iniciar o teste, o ambiente de RF já está ocupado. Quanto maior for a utilização do canal (fora do teste), menor será o resultado do teste de throughput. Se um problema de utilização de canal for identificado, verifique se outros APs estão presentes na mesma área no mesmo canal e reconsidere seu projeto de RF. Reduzir a largura do canal, eliminar invasores, usar diferentes antenas com cobertura mais focada são boas opções. Adicionar mais APs nem sempre é a melhor ideia.
• Obtenha uma captura pelo ar do teste de rendimento e veja se há muitas novas tentativas de dados em uma camada 802.11 (em porcentagem de todos os quadros de dados). Um número alto de tentativas significa que o ambiente de RF é potencialmente o problema. Verifique também quais taxas de dados estão sendo usadas, protocolo potencialmente abaixo do ideal ou número de fluxos espaciais. Uma transferência de dados grande é muito característica em uma captura over-the-air, você vê dezenas de quadros de dados com a mesma origem e destino e com um intervalo delta extremamente pequeno entre eles seguido por um bloco ACK. Se a transferência é caracterizada por um ACK regular após cada quadro de dados, ou um monte de requisição para enviar/claro para enviar, o baixo throughput pode ser facilmente explicado.
• Verifique se o problema de throughput ocorre com todos os tipos de segurança na WLAN. Às vezes, uma incompatibilidade de segurança específica entre o cliente e o AP pode levar a um throughput ruim.