Quais variáveis SNMP para diagnosticar / caracterizar o congestionamento de wi-fi?

Question

Estou me preparando para um teste de carga de um sistema wifi de sala de aula. Todos os alunos ligam seus laptops no início da aula, que inicia o navegador da Web e iniciam a lição - o que envolve o download de uma lição baseada em flash (de um servidor dentro da escola), geralmente de metade a 2 MB de download. / p>

Em alguns casos, o tempo de carregamento é de 5 ou 10 minutos. Por isso, quero monitorar todas as partes do sistema para dizer com confiança onde estão os gargalos e quantos clientes podem usar um único ponto de acesso wifi razoavelmente. Por isso, estamos planejando executar testes com até 50 clientes e ver o que acontece (eu sei que a maioria das pessoas recomenda 20-25 clientes por ponto de acesso, mas o cliente quer testar isso - e eu quero obter bons dados para mostrar ao cliente de uma forma ou outra).

Eu já sei como monitorar o servidor. O ponto de acesso Wi-Fi suporta SNMP, e parece fornecer muitas variáveis, mas eu não quero ter que percorrer muito.

Então a questão é: quais variáveis relacionadas ao wifi são as principais para monitorar quando o sistema está ficando sobrecarregado, os clientes estão esperando, as colisões estão acontecendo, etc?

Fico feliz em receber os nomes genéricos do que deveria estar lá e vasculhar os arquivos por conta própria, mas se você quiser / precisar ver os detalhes, o ponto de acesso que estamos usando é o Ubiquity Nanostation 2 . Os arquivos MIB para produtos Ubiquity estão vinculados na parte inferior de sua página SNMP . Embora eu também tenha descoberto que eles parecem apoiar pelo menos parte da MIB do Mikrotik .

    

Answer 1

A abordagem simples seria apenas monitorar periodicamente os IF-MIB::ifInOctets.<ifIndex> / IF-MIB::ifOutOctets.<ifIndex> OIDs e verificar a largura de banda disponível. A partir do MikriTik MIB vinculado, você pode descobrir as taxas atualmente definidas lendo o mtxrWlStatTxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex> e mtxrWlStatRxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex> . Isso, é claro, não levaria em conta os detalhes sem fio, mas seria capaz de lhe dar uma ideia aproximada se a largura de banda total disponível em sua interface é o gargalo (é provável que você veja usos próximos à capacidade total do canal).

Em geral, a menos que suas estações ou antenas estejam mal localizadas e o éter esteja limpo na freqüência do canal escolhido, você pode esperar um throughput de aproximadamente 2-3 MB / s de um único canal G (54 MBps 2,4 GHz).

Se você precisar de informações mais específicas sobre novas tentativas e erros do lado do AP, leia a tabela dot11Counters da MIB IEEE802dot11 - especificamente os valores dot11RetryCount , dot11MultipleRetryCount e dot11FailedCount da instância apropriada.

O 802.11 não tem nenhuma colisão, mas sim a detecção física da portadora e, opcionalmente, um handshake RTS / CTS antes de transmissão de quadros. Monitorar o dot11RTSFailureCount lhe dará uma idéia aproximada da frequência com que uma solicitação RTS não é respondida por um CTS, portanto, não concedendo o canal para a estação de envio.

Observe que você poderá ver uma quantidade relativamente baixa de tentativas e falhas de RTS se for o seu ponto de acesso que gera a grande maioria do tráfego (ou seja, as estações recebem principalmente dados). Talvez você queira dar uma olhada em IF-MIB::ifOutDiscards.<ifIndex> na interface sem fio ou IF-MIB::ifInDiscards.<ifIndex> na interface com fio, bem como esses números aumentariam sempre que o buffer estivesse cheio e não pudessem receber quadros adicionais (ou seja, o AP está enviando a taxa máxima mas os quadros na interface Ethernet continuam chegando a um ritmo mais rápido).

    

Answer 2

Se tudo o que você está tentando fazer é provar ao cliente que eles estão sobrecarregando o AP, você pode usar o dot11RetryCount e o dot11MultipleRetryCount OID.

dot11RetryCount - 1.2.840.10036.2.2.1.4

dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5

Isso lhe dará uma estimativa aproximada de quão congestionado é o ar. Quando a contagem de novas tentativas atingir mais de 10% do dot11TransmittedFrameCount, você começará a ver lentidão.

Aqui está o walker de objetos MIB da Cisco - isso deve ajudar se você precisar descobrir outros OIDs para examinar.

link