¿Qué variables SNMP para diagnosticar/caracterizar la congestión wifi?

¿Qué variables SNMP para diagnosticar/caracterizar la congestión wifi?

Me estoy preparando para una prueba de carga de un sistema wifi en un aula. Todos los alumnos encienden sus computadoras portátiles al comienzo de la lección, lo que inicia el navegador web y luego comienzan la lección, lo que implica descargar una lección basada en flash (desde un servidor dentro de la escuela), generalmente de media a 2 MB de descarga.

En algunos casos, el tiempo de carga se extiende a 5 o 10 minutos. Por eso quiero monitorear todas las partes del sistema para decir con confianza dónde están los cuellos de botella y cuántos clientes pueden usar un único punto de acceso wifi de manera razonable. Por lo tanto, estamos planeando ejecutar pruebas con hasta 50 clientes y ver qué sucede (sé que la mayoría de las personas recomiendan entre 20 y 25 clientes por punto de acceso, pero el cliente quiere probar esto y quiero obtener buenos datos para mostrarle al cliente). De una manera u otra).

Ya sé cómo monitorear el servidor. El punto de acceso wifi admite SNMP y parece proporcionar muchas variables, pero no quiero tener que analizar demasiado.

Entonces la pregunta es, ¿qué variables relacionadas con wifi son las claves a monitorear para caracterizar cuándo el sistema se está sobrecargando, los clientes están esperando, se están produciendo colisiones, etc.?

Me alegra que me digan los nombres genéricos de lo que debería estar allí y que busque los archivos yo mismo, pero si desea o necesita ver los detalles, entonces el punto de acceso que estamos usando es elNanoestación ubicuidad 2. Los archivos MIB para productos Ubiquity están vinculados desde la parte inferior desu página SNMP. Aunque también descubrí que parecen apoyar al menos parte de laMicrotik MIB.

Respuesta1

El enfoque simple sería simplemente monitorear los IF-MIB::ifInOctets.<ifIndex>OID IF-MIB::ifOutOctets.<ifIndex>periódicamente y verificar el ancho de banda disponible. Desde su MIB MikroTik vinculado puede descubrir las tasas establecidas actualmente leyendo mtxrWlStatTxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex>y mtxrWlStatRxRate 1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>:. Por supuesto, esto no tomará en cuenta los detalles inalámbricos, pero podrá darle una idea aproximada si el ancho de banda total disponible en su interfaz es el cuello de botella (probablemente lo sea si ve usos cercanos a la capacidad total del canal).

En general, a menos que sus estaciones o antenas estén mal ubicadas y el éter esté limpio en la frecuencia del canal elegido, puede esperar un rendimiento de aproximadamente 2-3 MB/s desde un solo canal G (54 MBps 2,4 GHz).

Si necesita información más específica sobre reintentos y errores del lado AP, puede leer la dot11Counterstabla de la MIB IEEE802dot11, específicamente los dot11RetryCountvalores dot11MultipleRetryCounty dot11FailedCountde la instancia apropiada.

802.11 no tiene colisiones, pero sí detección física de portadores y, opcionalmente, unApretón de manos RTS/CTSantes de la transmisión de tramas. Monitorear dot11RTSFailureCountle dará una idea aproximada de la frecuencia con la que un CTS no responde a una solicitud RTS, por lo que no se otorga el canal a la estación emisora.

Tenga en cuenta que puede ver una cantidad relativamente baja de reintentos y fallas de RTS si es su punto de acceso el que genera la gran mayoría del tráfico (es decir, las estaciones reciben principalmente datos). Es posible que desee echar un vistazo a IF-MIB::ifOutDiscards.<ifIndex>la interfaz inalámbrica o IF-MIB::ifInDiscards.<ifIndex>a la interfaz cableada, ya que estos números se incrementarán cada vez que el búfer esté lleno y no pueda recibir tramas adicionales (es decir, el AP envía a velocidad completa pero las tramas en la interfaz Ethernet seguir llegando a un ritmo más rápido).

Respuesta2

Si todo lo que intenta hacer es demostrarle al cliente que está sobrecargando el AP, puede usar los OID dot11RetryCount y dot11MultipleRetryCount.

dot11RetryCount - 1.2.840.10036.2.2.1.4

dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5

Esto le dará una estimación aproximada de qué tan congestionado está el aire. Una vez que el recuento de reintentos alcance más del 10 % aproximadamente del dot11TransmittedFrameCount, comenzará a ver desaceleraciones.

Aquí está el caminante de objetos MIB de Cisco, que debería ayudarle si necesita descubrir otros OID para examinar.

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.2.840.10036.2.2.1.13#oidContent

información relacionada