Как посмотреть загрузку процессора роутера
У нас в организации доступ в интернет обеспечивается D-Link DIR-300, версия прошивки 1.0.20. К нему подключены две точки доступа (D-Link DWL-2100AP и D-Link DAP-1360) из двух зданий, которые раздают локалку и интернет. Роутер раздаёт адреса по DHCP, но на некоторых машинах адреса прописаны вручную.
Так получается что иногда отрубается вай-фай. Причём даже в тот момент, когда находишься с точкой доступа совсем рядом. Подключается вай-фай на клиентах раза с пятого-десятого. А может и с первого подключиться. Происходит такое у всех, поэтому делаю вывод, что проблема не в точках доступа а в роутере.
Уже планируем переход на более профессиональное оборудование, но руководство таки поставило задачу разобраться с проблемой, почему так происходит, ибо раньше подобных проблем не было при таком же оборудовании.
Пока грешу на чрезмерную нагрузку на роутер. И хотелось бы узнать, как это посмотреть (в веб-интерфейсе такого не нашёл)?
Если есть какие-то другие соображения по поводу решения такой проблемы - тоже интересно было бы услышать.
P.S. Руководству привет - хватит уже нищебродские решения в офисах применять. Не будет это нормально работать - этот роутер домашнего класса, не более.
И курить самостоятельно Вы запаритесь, придётся играться с альтернативными прошивками, дампами-трафика (которые на Dir-300 не снять, ибо нет tcpdump), логами. И Самостоятельно пытаться понять что происходит. Тут решения два - или не скупиться на админа, который будет всё сам курить и платить ему 100000+ зп или ставить дорогое железо, лучше сразу и то и другое. Вас вряд ли нанимали на то, чтобы заставлять копеечное железо нормально работать в агрессивных условиях.
Последний раз редактировалось Mihail821 Чт окт 10, 2013 08:46, всего редактировалось 1 раз.
По какому порту телнетить?
23 стандартный, включить в вебморде надо, если можно. Вы же даже не сказали какая у Вас аппаратная ревизия 300 - их уже более 10 моделей.
Не очень силён. Но подозреваю, что сильной нагрузки на роутер не идёт.
Вообще, никакой загрузки нет - так что причина не в этом. Ищите источник проблемы, снимайте дампы на всех железках, сопоставляйте их с моментами возникновения проблем, логи курите - может новая железка недавно появилась в сети (не важно по проводу или без, которая что-то срёт). В общем, реально, с наскока не решите. Я бы попробовал воткнуть альтернативную прошивку, а потом послал руководство нафиг, ибо курить проблемы за копейки не админское дело.
P.S. К точкам доступа без проблем все клиенты подключатся (локальное соединение влёт устанавливается - только интернет не ходит)? Значит, копайте Dir-300 и что на него прилетает по сети, от кого, что может проблему создавать.
P.P.S. Обновите прошивку на Dir-300 до самой актуальной (со сбросом настроек), не поможет - влейте туда альтернативную прошивку, если найдёте (под свою аппаратную ревизию). Может ситуация изменится в лучшую сторону - решение быстрое в том плане, что не надо курить логи, а можно методом тыка попробовать и сравнить.
Руководству привет - хватит уже нищебродские решения в офисах применять. Не будет это нормально работать - этот роутер домашнего класса, не более.
Оно с этим не спорит. Поэтому и заказываем новое железо. При этом оно интересуется, почему не работает старое. Объяснения "оно домашнее, оно дешёвое - потому работать не будет" - они, увы, не канают. Хотелось бы какой-то конкретики, чем именно аргументировать.
По поводу проблемы. Я так понимаю, тут проблема комплексная, поскольку и сам вай-фай слетает иногда, и при включенном вай-фае проблемы бывают. В общем, если тут дело касается уже перепрошивки, то копаться смысла нет - ибо это отнимет столько же времени и сил (надо либо всех выгонять из сети, либо оставаться в нерабочее время, перепрошивать, а потом ещё и есть вероятность, что нужно будет пройтись по всем рабочим станциям), сколько настройка нового оборудования.
Но тем не менее, хочется запастись парой аргументов против старого оборудования.
Руководству привет - хватит уже нищебродские решения в офисах применять. Не будет это нормально работать - этот роутер домашнего класса, не более.
Оно с этим не спорит. Поэтому и заказываем новое железо. При этом оно интересуется, почему не работает старое. Объяснения "оно домашнее, оно дешёвое - потому работать не будет" - они, увы, не канают. Хотелось бы какой-то конкретики, чем именно аргументировать.
По поводу проблемы. Я так понимаю, тут проблема комплексная, поскольку и сам вай-фай слетает иногда, и при включенном вай-фае проблемы бывают. В общем, если тут дело касается уже перепрошивки, то копаться смысла нет - ибо это отнимет столько же времени и сил (надо либо всех выгонять из сети, либо оставаться в нерабочее время, перепрошивать, а потом ещё и есть вероятность, что нужно будет пройтись по всем рабочим станциям), сколько настройка нового оборудования.
Но тем не менее, хочется запастись парой аргументов против старого оборудования.
Если Вы не готовы перепрошивать и отрубать клиентов, чтобы устанавливать причину, перепрошивку, то ничем помочь не могу - это стандартное решение. Когда есть проблемы народ разгоняется и проблема решается столько сколько надо, для этого создаются резервные каналы, на которых клиенты пересаживаются (в общем, создавайте несколько независимых решений, на разных брэндах). Для стабильности.
Аргумент простой - нет возможности тонкой диагностики, нет возможностей расширенного администрирования у таких роутеров. Они домашнего класса + производительность слабая.
Обычно попытка исправления подразумевает:
— обход членов семьи (ну да, я качаю новый сезон «Доктор Хаус». А кому это может мешать?)
— перезагрузить роутер (ну завис я, завис — сутками всякую дрянь качаете..)
— не качаются ли обновления (приятная новость — новый Acrobat Reader. )
— нет ли у нас блошек (нашему ботнету сегодня дали большое домашнее задание)
— звонок провайдеру (наш канал работает как часы с самого основания компании)
— эм. может еще раз роутер?
…
Все получится, если ваш роутер поддерживает протокол SNMP — специальный протокол для телеметрии сетевых устройств и приложений. Разбираемся по инструкции к роутеру или веб-интерфейсу, есть ли у вас поддержка SNMP. В некоторых случаях появляется при установке неофициальных прошивок. Ищем его в веб интерфейсе, включаем. Запоминаем, как называется community name — это пароль, по которому показания SNMP вашего роутера доступны в сети (по умолчанию обычно public).
Рис. 1. Здесь все просто. Или поддержка SNMP есть, или ее нет.
Чтобы не потерять много времени впустую, давайте сделаем экспресс-проверку. Скачиваем библиотеку NET-SNMP. Из директории bin выполняем команду:
public — пароль для доступа к SNMP (community name)
192.168.1.1 — ip адрес роутера
Устанавливаем MRTG. На сайте подробное руководство по установке для UNIX и Windows. Для работы под Windows требуется PERL. Наиболее распространенный бесплатный дистрибутив PERL для Windows — это ActivePerl. Отдельной инструкции для Mac не сайте видел, однако поскольку MRTG — это не более чем программа на PERL, тоже должно работать.
Короткий путь начать мониторить траффик на сетевых интерфейсах роутера — это создать конфигурационный файл MRTG командой cfgmaker. Например, мой роутер ASUS WL-500g premium имеет 8 сетевых интерфейсов, и это позволяет видеть траффик со стороны провайдера, со стороны WiFi устройств (телефон и ноутбук), со стороны рабочей станции через Ethernet
Рис. 2. Из сопоставления графиков на разных интерфейсах видно, откуда идет траффик.
Чуть сложнее мониторить нагрузку и использование памяти. Нужно иметь MIB спецификацию устройста. Если SNMP поддерживается официально, то она, скорее всего, есть на сайте производителя. Если это неофициальная прошивка, то, возможно, уже есть наработки у сообщества, которое сделало прошивку. Например, спецификация для ASUS WL-500g здесь. В моем случае OID для средней за 5 минут нагрузки на CPU .1.3.6.1.4.1.2021.10.1.5.2, используемая RAM .1.3.6.1.4.1.2021.4.6.0. При описании показаний нагрузки CPU и использования памяти в конфиге MRTG нужно с помощью опции gauge указать, что это текущие показания, а не интегральная величина, как для траффика, когда SNMP передает количество байт прошедшее через интерфейс с момента включения устройства (ну или обнуления счетчика, если долго работаем)
Рис. 3. Обычно нагрузка процессора на нуле. Она растет, когда качают несколько процессов на большой скорости. Используемая память меняется слабо.
Разумеется запускать mrtg вручную каждые 5 минут не нужно, а нужно создать задачу cron (Unix) пример:
*/5 * * * * root LANG=C LC_ALL=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache-file /var/lib/mrtg/mrtg.ok
Возможно, возможности вашего роутера значительно шире, и вы можете получать значительно больше информации — МАС адреса клиентов, траффик по MAC адресам, и так далее. Да поможет вам Google!
P.S. Данная заметка, разумеется, не ориентирована на специалистов по сетевой инфраструктуре. Просто я совершенно случайно открыл для себя букавы SNMP и уверен, что не одинок в этом. Возможно, кому-то это поможет при выборе нового роутера.
В комментариях открыл для себя суперпрошивку DD-WRT. Теперь вот думаю…
Мониторинг — это один из столпов обеспечения высокой доступности ИТ-систем.
Как правило, системные администраторы при установке системы мониторинга в первую очередь настраивают ее на проверку параметров серверов и обнаружение недоступности сервисов, запущенных на этих серверах. Безусловно это приоритетная задача, но не стоит забывать и о другом оборудовании: ИБП, системах кондиционирования, сетевом оборудовании.
В этом топике я покажу как решить за полчаса задачу мониторинга активного сетевого оборудования (т.е. свитчей, роутеров и т.п.) в системе Zabbix с помощью пары полезных инструментов. В результате вы сможете получить полную картину происходящего в сети.
Включаем мониторинг
Думаю, я не ошибусь, если скажу, что большинству системных администраторов приходится работать с унаследованным «зоопарком» оборудования различных моделей и вендоров. К счастью, большинство моделей поддерживает открытый протокол SNMP. Именно по нему мы и будем получать информацию о состоянии сетевых интерфейсов.
- включить поддержку SNMP на сетевом устройстве (команды зависят от производителя)
- добавить соответствующие item в Zabbix — по одному на каждый параметр; для этого нужно указать используемую версию SNMP, корректный идентификатор параметра SNMP OID и SNMP community (что-то типа имени пользователя)
- добавить триггеры для отслеживания нежелательных значений item
Для облегчения задачи необходимо использовать шаблоны (templates). Шаблон содержит в себе все необходимые item'ы, триггеры и графики — остается только завести хост и подключить к нему шаблон.
Для Zabbix уже есть много готовых шаблонов, которые можно или нагуглить или посмотреть в мануале.
Если вы не нашли нужный шаблон, не расстраивайтесь: как правило, производители используют стандартные OID'ы из RFC1213 и RFC2233:
sysName.0 | имя узла | |
.1.3.6.1.2.1.1.3.0 | uptime | |
.1.3.6.1.2.1.2.2.1.8.X | статус порта: 1(up) / 2(down) | X — номер порта; у Cisco номер порта пятизначный: 100XX для 100 Мбитных портов, 101XX для 1 Гбит/c |
.1.3.6.1.2.1.2.2.1.16.X | отправлено байт | |
.1.3.6.1.2.1.2.2.1.10.X | принято байт | |
.1.3.6.1.2.1.31.1.1.1.5.X | отправлено broadcast пакетов | |
.1.3.6.1.2.1.31.1.1.1.3.X | принято broadcast пакетов | |
.1.3.6.1.2.1.31.1.1.1.4.X | отправлено multicast пакетов | |
.1.3.6.1.2.1.31.1.1.1.2.X | принято multicast пакетов | |
.1.3.6.1.2.1.2.2.1.17.X | отправлено unicast пакетов | |
.1.3.6.1.2.1.2.2.1.11.X | принято unicast пакетов | |
.1.3.6.1.2.1.2.2.1.20.X | ошибок при отправке | |
.1.3.6.1.2.1.2.2.1.14.X | ошибок при получении |
Cisco Catalyst, как правило, поддерживают дополнительно:
.1.3.6.1.4.1.9.9.109.1.1.1.1.5.1 — процент загрузки CPU
.1.3.6.1.4.1.9.9.48.1.1.1.5.1 — занятая память (в байтах)
.1.3.6.1.4.1.9.5.1.2.13.0 — статус температуры (1 — нормальная, 2 — повышенная, 3 — критическая)
Производительность
Нельзя не упомянуть о возможной проблеме с производительностью zabbix-сервера. Предположим, что вы раз в минуту получаете информацию об 11 параметрах каждого порта 50-ти 24-портовых свитчей. На базу данных zabbix-сервера ляжет нагрузка в среднем 220 записей в секунду. Для слабой машины она может оказаться непосильной. Поэтому рекомендуется ограничивать количество item'ов или увеличивать интервал проверки. Мы считаем достаточным запрашивать статус порта, трафик, количество ошибок и широковещательных пакетов раз в 60 секунд.
Пожалуйста, расскажите почему?
Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!
Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.
Высокая загрузка CPU в устройствах Mikrotik зачастую есть результат ответственности Микротика к dns-запросам.
Однако, большая часть запросов прилетает извне локалки, и отвечать на них не нужно.
Открываем Winbox, переходим System → Resources и смотрим загрузку процессора:
Уточняем службу, нагружающую CPU, идем Tools → Profile:
В нашем случае — это точно служба DNS.
По умолчанию, внешним интерфейсом назначают ether1. Проверим, какое количество пакетов прилетает на 53 порт — идем Tools → Torch:
Вариант 1.
Идем IP → Firewall → Filter Rules, добавляем два правила:
1. Все IP – адреса на интерфейсе ether1, пакеты с которых приходят на 53 порт помещаем адресный лист с именем dns- spoofing на 1 час. Во вкладке General указываем следующие параметры:
- Chain = input — обрабатываем приходящие пакеты
- Protocol = UDP — нас интересуют пакеты, у которых в качестве транспорта используется UDP
- Dst. Port = 53 — портом назначения должен быть 53 порт, то есть DNS служба
- In. Interface = ether1 — проверка подвергаются все пакеты, которые приходят на интерфейс ether1, который смотрит в публичную сеть.
Переходим во вкладку Action:
- Action = add src to address list — в качестве действия, мы будем добавлять IP – адрес источника в специальный лист
- Address List = dns spoofing — указываем имя листа, в который добавляем IP
- Timeout = 01:00:00 — добавляем на 1 час.
2. Каждый IP – адрес на интерфейсе ether1, с которого будет поступать запрос на 53 порт, будет проверяться на предмет нахождения в списке dns spoofing . Если он там есть, мы будем считать, что это DNS – спуфинг с частотой реже чем раз в час и будем дропать данный пакет.
General идентичны первому правилу:
- Chain = input — обрабатываем приходящие пакеты
- Protocol = UDP — нас интересуют пакеты, у которых в качестве транспорта используется UDP
- Dst. Port = 53 — портом назначения должен быть 53 порт, то есть DNS служба
- In. Interface = ether1 — проверка подвергаются все пакеты, которые приходят на интерфейс ether1, который смотрит в публичную сеть.
- Src. Address List= dns spoofing — указываем производить проверку приходящего пакета на предмет нахождения в указанном листе.
- Action = drop — если IP – адрес пакета есть в указанном списке, то дропаем этот пакет.
Перемещаем правила повыше, проверяем на вкладке IP → Firewall → Address Lists наличие адресов в адресном листе, Проверяем загрузку CPU.
Вариант 2.
Идем IP → Firewall → Filter Rules, добавляем одно правило:
1. Все IP – адреса на интерфейсе ether1, пакеты с которых приходят на 53 порт, дропаем. Во вкладке General указываем следующие параметры:
- Chain = input — обрабатываем приходящие пакеты
- Protocol = UDP — нас интересуют пакеты, у которых в качестве транспорта используется UDP
- Dst. Port = 53 — портом назначения должен быть 53 порт, то есть DNS служба
- In. Interface = ether1 — проверка подвергаются все пакеты, которые приходят на интерфейс ether1, который смотрит в публичную сеть.
Переходим во вкладку Action:
- Action = drop — указываем, что дропаем этот пакет.
Перемещаем правила повыше, проверяем на вкладке IP → Firewall → Address Lists наличие адресов в адресном листе, Проверяем загрузку CPU.
Метки: mikrotik
Copyright 2019. All rights reserved.
Всем привет! Имею более 5 установленных SOHO роутеров микротик, в разных местах от разных провов, и с разной пропускной скоростью. И начал замечать, что время от времени загрузка роутеров приближается где-то к 100%, на других вываливается связь из-за малой пропускной способности инет-канала. Как выяснилось, причиной всего это во всех случаях какая-то нездоровая активность на DNS сервер Микротика которая либо забивает канал, либо если канал широкий съедает все cpu. Причем на всех установленных роутерах — внешние айпи адреса.
Настраивал все по мануалам, в фаерволле никаких правил не добавлял. Убрал только доступ к микротику, оставив WinBox.
Подскажите, как правильнее закрыть 53 порт? Что бы внутри ничего не нарушить 🙂
- Вопрос задан более трёх лет назад
- 16003 просмотра
заблокировано файрволом все что можно — не помогает
в winbox’e
IP — DNS — Static — выделяешь свой роутер и жмешь disable — нагрузка сразу упадет
То же самое было около года назад. Решилось закрытием 53 порта.
chain input; Dst Adress @твой IP
Protocol 6 (tcp)
Dst port 53.
action drop
(или при желании добавлять эти адреса флудеры в список и банить тот список на определенное время)
И еще 1 правило такое же правило для UDP
Protocol 17 (udp)
What’s new in 6.22 (2014-Nov-11 14:46):
*) ovpn — added support for null crypto;
*) files — allow to remove empty disk folders;
*) sntp — fix problems with dns name resolving failures that were triggering
system watchdog timeout;
*) eoip/eoipv6/gre/gre6/ipip/ipipv6/6to4 tunnels have new features:
tunnels go down when no route to destination;
tunnels go down for 1 minute when transmit loop detected, warning gets logged;
new keepalive-retries setting;
keepalives enabled by default for new tunnels (10sec interval, 10 retries);
*) improved connection-state matcher in firewall — can match multiple states in one rule, supports negation;
*) added connection-nat-state matcher — can match connections that are srcnatted,dstnatted or both;
*) 100% CPU load caused by DNS service fixed;
*) 100% CPU load caused by unclassified services fixed;
*) 6to4 tunnel fixed;
*) new RouterBOOT firmware for Metal 2SHPn to improve wireless stability;
Генератор шаблонов
- отслеживать параметры интерфейсов (см. таблицу выше) и выводить их на графике;
- устанавливать триггер на падение порта;
- устанавливать триггер на превышение скорости прироста ошибок на порте;
- отслеживать загрузку процессора, памяти и температуры для Cisco.
В результате вы получите симпатичные графики:
Мониторинг состояния портов
К сожалению, в Zabbix нет удобного инструмента для просмотра состояния отдельных портов устройств, поэтому его пришлось написать. Информация импортируется из Zabbix и выводится администратору в удобном виде:
Серый цвет порта обозначает, то что он находится в down. Цвет от зеленого до красного меняется в зависимости от загрузки порта. Гигабитные порты выделены рамочкой.
Минус скрипта в том, что он писался «для себя», поэтому установка достаточно корявая (-:. Скачайте исходники и прочитайте readme. UPD 13.03.13 (Версия для Zabbix 2.0)
Карта сети
Также в свойствах Link вы можете настроить отображении линии красным в случае падения порта в down.
Отладка
Если прошло несколько минут после добавления к устройству шаблона, а данные от SNMP так и не появились, необходимо проверить, может ли сервер Zabbix считать данные с устройства. Делается это утилитой snmpget:
snmpget -v версия_протокола -c комьюнити адрес_устройства OID
Например, получим число отправленных байт на первом гигабитном порту для Cisco:
snmpget -v 2c -c qwerty 192.168.1.1 .1.3.6.1.2.1.2.2.1.16.10101
IF-MIB::ifOutOctets.10101 = Counter32: 2044250092
Для не-Cisco железки:
snmpget -v 2c -c qwerty 192.168.1.2 .1.3.6.1.2.1.2.2.1.16.1
IF-MIB::ifOutOctets.1 = Counter32: 1691279168
Чтобы прочитать полный список параметров с устройства выполните:
snmpwalk -v версия_протокола -c комьюнити адрес_устройства
Любители GUI для чтения SNMP-данных с устройства могут воспользоваться программами типа MIB Browser.
Настройка Firewall в Mikrotik
Первым делом давайте проверим службу, которая больше всего «отъедает» ресурсов процессор. Для этого, перейдем в раздел Tools → Profile:
Как видно из скриншота, львиную долю ресурсов нашего процессора занимает служба DNS. Давайте посмотрим, что происходит на уровне обмена пакетами на основном интерфейс ether1. Для этого воспользуемся утилитой Tools → Torch:
Мы видим большое количество пакетов с различных IP – адресов на 53 порт. Наш Mikrotik отвечает на каждый из таких запросов, тем самым, нерационально используя ресурсы процессора и повышая температуру.
Эту проблему надо решать. Судя по снятому дампу, пакеты приходят с частотой 10-20 секунд с одного IP – адреса. Добавим в наш Firewall два правила:
- Все IP – адреса, пакеты с которых приходят на 53 порт нашего Микротика будут помещаться в специальный лист с названием dns spoofing на 1 час.
- Каждый IP – адрес, с которого будет поступать запрос на 53 порт будет проверяться на предмет нахождения в списке dns spoofing . Если он там есть, мы будем считать, что это DNS – спуфинг с частотой реже чем раз в час и будем дропать данный пакет.
Переходим к настройке. В разделе IP → Firewall → Filter Rules создаем первое правило нажав на значок «+». Во кладке General указываем следующие параметры:
- Chain = input — обрабатываем приходящие пакеты
- Protocol = UDP — нас интересуют пакеты, у которых в качестве транспорта используется UDP
- Dst. Port = 53 — портом назначения должен быть 53 порт, то есть DNS служба
- In. Interface = ether1 — проверка подвергаются все пакеты, которые приходят на интерфейс ether1, который смотрит в публичную сеть.
Переходим во вкладку Action:
- Action = add src to address list — в качестве действия, мы будем добавлять IP – адрес источника в специальный лист
- Address List = dns spoofing — указываем имя листа, в который добавляем IP
- Timeout = 01:00:00 — добавляем на 1 час
Нажимаем Apply и OK. Настроим второе правило, так же нажав на «+»:
Как видно, настройки во вкладке General в данной вкладке идентичны первому правилу. Нажимаем на вкладку Advanced:
- Src. Address List= dns spoofing — указываем Микротику, производить проверку приходящего пакета на предмет нахождения в указанном листе
Переходим во вкладку Action:
- Action = drop — если IP – адрес пакета есть в указанном списке, то дропаем этот пакет.
После того, как оба правила стали активны переходи во вкладку IP → Firewall → Address Lists:
Как видно, адреса стали добавляться в список на 1 час. Теперь давайте проверим загрузку процессора:
Теперь загрузка процессора в пределах нормы. Проблема решена.
Планы
В следующей версии генератора шаблонов хотелось бы добавить возможность получения остальных параметров интерфейсов, выбор цветов линий для графиков, возможность указания скорости портов для не-Cisco устройств. Предложения приветствуются.
Mikrotik Router OS включает в себя замечательную функцию мониторинга и диагностики нагрузки с помощью графиков. Маршрутизатор может показывать графики нагрузки ресурсов (HDD, RAM, CPU), трафика на интерфейсах, очередей в Simple Queues. Ниже мануальчик по настройке.
Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс содержит все темы, которые изучаются на официальном курсе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
Заходим Tools -> Graphing.
Вкладка Interface Rules. Здесь настраиваются графики трафика на интерфейсах.
Interface -- интерфейсы с которых собирается статистика.
Allow Adresses -- ip-адреса с которых доступна статистика.
Store on Disk -- сохранять статистику в постоянную память.
Кнопка Graphing Settings -- определяет частоту сбора статистики (варианты: 5 мин. / 1 час / сутки)
Вкладка Queues Rules. Здесь настраиваются графики очередей в Simple Queues.
Queues -- очереди с которых собирается статистика.
Allow Adresses -- ip-адреса с которых доступна статистика.
Store on Disk -- сохранять статистику в постоянную память.
Allow Tatget -- разрешать ли доступ к графикам от queue’s target-address.
Вкладка Resurses Rules. Здесь настраиваются графики загруженности ресурсов.
Allow Adresses -- ip-адреса с которых доступна статистика.
Store on Disk -- сохранять статистику в постоянную память.
Вкладки Graphs просто показывают статистику для настройки не используются.
Освоить MikroTik Вы можете с помощью онлайн-куса «Настройка оборудования MikroTik». Курс содержит все темы, которые изучаются на официальном курсе MTCNA. Автор курса – официальный тренер MikroTik. Подходит и тем, кто уже давно работает с микротиками, и тем, кто еще их не держал в руках. В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
Сетевое оборудование вендора Mikrotik является весьма любопытным и привлекательным продуктом в сегменте SOHO (Small office/home office). Соотношение цены, качества, функционала и стабильности обеспечивает все большее распространение небольших белых коробочек в офисах небольших компаний.
Но спустя какое-то время беззаботного пользования, пользователи начинают жаловаться. Администратор, открыв Winbox, переходит в раздел System → Resources и видит, что загрузка процессора 100%:
Не стоит волноваться. У нас есть решение. Все настройки и «траблшутинг» будем осуществлять с помощью Winbox.
Читайте также: