Назад | Перейти на главную страницу

Какие переменные SNMP для диагностики / характеристики перегрузки Wi-Fi?

Я готовлюсь к нагрузочному тесту системы Wi-Fi в классе. Все ученики включают свои ноутбуки в начале урока, который запускает веб-браузер, а затем они начинают урок, который включает загрузку урока на основе флэш-памяти (с сервера в школе), обычно от половины до 2 МБ загрузки.

В некоторых случаях время загрузки растягивается до 5 или 10 минут. Поэтому я хочу отслеживать все части системы, чтобы с уверенностью сказать, где находятся узкие места и сколько клиентов могут разумно использовать одну точку доступа Wi-Fi. Итак, мы планируем провести тесты с количеством клиентов до 50 и посмотреть, что произойдет (я знаю, что большинство людей рекомендуют 20-25 клиентов на точку доступа, но клиент хочет это проверить - и я хочу получить хорошие данные, чтобы показать клиенту так или иначе).

Я уже знаю, как следить за сервером. Точка доступа Wi-Fi поддерживает SNMP и, кажется, предоставляет довольно много переменных, но я не хочу слишком много продираться.

Итак, вопрос в том, какие связанные с Wi-Fi переменные являются ключевыми для отслеживания, чтобы характеризовать, когда система перегружается, клиенты ждут, происходят конфликты и т. Д.?

Я счастлив, что мне сказали общие названия того, что должно быть там, и я сам просматривал файлы, но если вы хотите / вам нужно увидеть детали, то точка доступа, которую мы используем, - это Вездесущая наностанция 2. Файлы MIB для продуктов Ubiquity связаны в нижней части их страница SNMP. Хотя я также обнаружил, что они, похоже, поддерживают по крайней мере часть Микротик МИБ.

Если все, что вы пытаетесь сделать, это доказать клиенту, что он перегружает точку доступа, вы можете использовать OID dot11RetryCount и dot11MultipleRetryCount.

dot11RetryCount - 1.2.840.10036.2.2.1.4

dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5

Это даст вам приблизительную оценку того, насколько переполнен воздух. Как только счетчик повторных попыток достигнет более 10% от dot11TransmittedFrameCount, вы начнете видеть замедление.

Вот обходчик объектов MIB Cisco - он должен помочь, если вам нужно выяснить другие OID для изучения.

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

Простым подходом было бы просто контролировать IF-MIB::ifInOctets.<ifIndex> / IF-MIB::ifOutOctets.<ifIndex> OID периодически и сверяется с доступной пропускной способностью. Из вашей связанной MikroTik MIB вы можете узнать текущие установленные ставки, прочитав mtxrWlStatTxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex> и mtxrWlStatRxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>. Это, конечно, не будет принимать во внимание особенности беспроводной связи, но сможет дать вам приблизительное представление о том, является ли общая доступная пропускная способность вашего интерфейса узким местом (вероятно, если вы увидите использование почти полной пропускной способности канала).

В общем, если ваши станции или антенны не расположены плохо, а эфир чистый на частоте выбранного канала, вы можете ожидать пропускную способность примерно 2-3 МБ / с от одного G-канала (54 МБ / с, 2,4 ГГц).

Если вам нужна более конкретная информация о повторных попытках и ошибках со стороны точки доступа, вы можете прочитать dot11Counters таблица MIB IEEE802dot11, в частности dot11RetryCount, dot11MultipleRetryCount и dot11FailedCount значения соответствующего экземпляра.

802.11 не имеет никаких коллизий, кроме физического контроля несущей и опционально Рукопожатие RTS / CTS перед передачей кадров. Мониторинг dot11RTSFailureCount даст вам приблизительное представление о том, как часто на запрос RTS не отвечает CTS, тем самым не предоставляя канал отправляющей станции.

Обратите внимание, что вы можете увидеть относительно небольшое количество повторных попыток и сбоев RTS, если именно ваша точка доступа генерирует подавляющую часть трафика (т.е. станции в основном получают данные). Вы можете взглянуть на IF-MIB::ifOutDiscards.<ifIndex> через беспроводной интерфейс или IF-MIB::ifInDiscards.<ifIndex> на проводном интерфейсе, а также эти числа будут увеличиваться всякий раз, когда буфер заполнен и не может принимать никаких дополнительных кадров (то есть AP отправляет с полной скоростью, но кадры на интерфейсе Ethernet продолжают поступать с большей скоростью).