+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Предложение по функционалу (а ещё и сообщество, пожалуйста, скажите, нужно ли это).

Предложение по функционалу (а ещё и сообщество, пожалуйста, скажите, нужно ли это)., RouterOS

nuclearcat

Guest

11.12.2007 23:43:00

1) У нас недавно возникла странная проблема с сетью — 3 карты в ПК, одна из карт повредилась (это нигде не отображалось, карта была видна). Все карты умерли (я могу менять настройки, но карты ничего не видят в воздухе), причиной послужили “неожиданные ответы драйверу” от поврежденной карты, блокирующие драйвер Atheros. Это было видно только на экране, как сообщения ядра Linux. Так вопрос — возможно ли сделать опцию, чтобы отправлять сообщения ядра с ошибками драйвера Atheros в лог?

2) Счётчики ошибок Ethernet. В случае несовпадения скорости, поврежденного кабеля, перегрузки ядра — будет очень полезно видеть счётчики ошибок ввода/вывода (как в ifconfig).

roc-noc.com

Guest

03.01.2008 14:02:00

Да, это действительно необходимо. Добавь мой голос. Сейчас я пытаюсь решить проблему с Ethernet у клиента. Было бы неплохо, если бы я не был слеп с Routerboard-а. Давай, Mikrotik. ifconfig не может быть таким сложным для добавления. Том.

stephenpatrick

Guest

03.01.2008 15:55:00

Это спрашивали раньше — и да, это очень нужно, особенно для роутеров для улицы/на крыше. Поспорю, эта функция уже есть в драйверах в ядре. Большинство приличных драйверов сетевых карт Windows (особенно Intel) уже имеют эту функцию. Обязательно проголосуйте за это на Wiki. В целом, чувствую, что ребята из MikroTik, скорее всего, вкладываются на полную катушку, чтобы выпустить стабильную версию 3.0.0, то есть отлаживают. И любые новые функции придётся немного подождать после этого. С уважением.

nuclearcat Guest	#4 0 04.01.2008 16:37:00 По-моему, включать это в вики – слишком банально. Mikrotik и так берёт информацию о счётчиках из /proc или откуда-то ещё, так что это просто несколько строчек кода больше. Не так уж сложно, как другие вещи в WIKI.

normis Guest	#5 0 08.01.2008 08:49:00 Не так просто, как тебе кажется. Эта информация различается у каждого водителя, и нам пришлось бы прорабатывать каждого водителя, чтобы эта информация стала доступна.

cmit Guest	#6 0 08.01.2008 08:55:00 Окей, но думаю, что это будет стоить усилий. Я считаю эту информацию очень ценной для диагностики, и на самом деле считаю ее просто необходимой…

stephenpatrick

Guest

08.01.2008 09:53:00

А, спасибо, Normis! Это оказывается "настоящая" проблема: поддержка множества драйверов для “извлечения статистики”. Предлагаю: интересно, возможно ли извлекать эти данные из драйвера в какой-то простой, общий формат (строки? флаги?) и, может быть, просто предоставлять их в CLI (а не в WinBox), чтобы не усложнять? Так пользователи хотя бы смогут “вывести” расширенную статистику портов, которая может быть более или менее “полной” в зависимости от драйвера. У каких-то (необычных) драйверов она может быть “отсутствовать”, а с более распространенными будет проще. Поддержка самых распространенных типов будет отличным стартом. Ещё одно замечание: как мне кажется, большинство RB (и несколько других производителей плат) используют схожие чипы, например, Via, Realtek. Это специфический подмножество всех поддерживаемых. Многие PC и PCI-типа плат используют Intel чипсеты, их тоже было бы хорошо поддерживать. Я склоняюсь к мнению CMIT, что для оборудования уровня оператора и уж тем более для “крышных” роутеров (которые могут работать на длинном POE, с другими источниками шумов, вроде GSM, радио, микроволновых передатчиков) это "необходимо", а не "желательно". С уважением.

nuclearcat

Guest

08.01.2008 10:15:00

Я не согласен насчет конкретных драйверов. Для меня реализация интерфейса заняла около 30 минут, и есть разные способы это сделать (через netlink или прямое чтение файла /proc/net/dev). Просто посмотрите на /proc/net/dev. У большинства драйверов есть что-то вроде "tp->stats.tx_errors++;" и подобные вещи. Пример: мой "самодельный" роутер на Linux /proc/net/dev:

Interface | Receive | Transmit
lo:833645974 2248850 0 0 0 0 0 0 833645974 2248850 0 0 0 0 0 0
eth0:689731851 208780975 0 0 0 0 0 241 3318003266 163815713 0 0 0 0 0 0
eth1:2390171464 174492174 0 0 0 0 0 603 2296370884 214921519 0 0 0 0 0 0
teql0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
eth1.10: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
eth1.11:3547648499 30456087 0 0 0 0 0 96 2549967840 38667836 0 0 0 0 0 0
eth1.12:3463167444 57065011 0 0 0 0 0 179 2028042674 71285724 0 0 0 0 0 0
eth1.13:502234657 32030859 0 0 0 0 0 103 2752216307 37425224 0 0 0 0 0 0
eth1.14:1862571411 12730849 0 0 0 0 0 81 3409601235 15766866 0 0 0 0 0 0
eth1.15:1826968872 13221641 0 0 0 0 0 75 3438064953 16323743 0 0 0 0 0 0
eth1.16:233191655 28983223 0 0 0 0 0 67 3366357061 35452379 0 0 0 0 0 0

Хотите бросить серьезный вызов разработчикам Mikrotik, чтобы они разобрались с этим файлом?

butche

Guest

08.01.2008 18:22:00

К слову, эту информацию можно получить с помощью SNMP. Не идеальный способ, но вполне рабочий. [admin@ButchEvans] > /interface print oid
Flags: X - disabled, D - dynamic, R - running
0 R name=.1.3.6.1.2.1.2.2.1.2.1 mtu=.1.3.6.1.2.1.2.2.1.4.1
mac-address=.1.3.6.1.2.1.2.2.1.6.1 admin-status=.1.3.6.1.2.1.2.2.1.7.1
oper-status=.1.3.6.1.2.1.2.2.1.8.1 bytes-in=.1.3.6.1.2.1.2.2.1.10.1
packets-in=.1.3.6.1.2.1.2.2.1.11.1 discards-in=.1.3.6.1.2.1.2.2.1.13.1
errors-in=.1.3.6.1.2.1.2.2.1.14.1 bytes-out=.1.3.6.1.2.1.2.2.1.16.1
packets-out=.1.3.6.1.2.1.2.2.1.17.1
discards-out=.1.3.6.1.2.1.2.2.1.19.1 errors-out=.1.3.6.1.2.1.2.2.1.20.1
Вы можете видеть, что ошибки, сбросы и подобное доступны через SNMP, так что:
butchhomeunix:~$ snmpwalk -v 1 -c public 192.168.5.1 1.3.6.1.2.1.2.2.1.14
IF-MIB::ifInErrors.1 = Counter32: 0
IF-MIB::ifInErrors.2 = Counter32: 0
IF-MIB::ifInErrors.3 = Counter32: 0
IF-MIB::ifInErrors.4 = Counter32: 0
Опять же, это не идеальное решение при поиске неисправностей, но наличие чего-то вроде snmpwalk может быть полезным. Согласен, что это должно быть видно напрямую в WinBox или CLI (лично я предпочитаю CLI), но пока что это рабочий метод.

nuclearcat

Guest

#10

08.01.2008 20:06:00

Бутче, спасибо большое, на время это может помочь в самых сложных ситуациях. Скорее всего, я напишу какой-нибудь инструмент на Perl, чтобы получать только конкретные значения интерфейса по имени (сначала получая по одному имена из индексов, а потом, когда найду требуемый номер, буду брать статистику с него). Нет смысла постоянно выкачивать все данные через snmpwalk.

butche

Guest

#11

08.01.2008 20:15:00

Без проблем, nuclearcat. Чтобы узнать, какой конкретный oid относится к каждому интерфейсу, выполни команду: `/interface print`. В результате выполнения этой команды ты получишь что-то вроде этого:

[admin@ButchEvans] interface> print

Flags: X - отключен, D - динамический, R - работает
# NAME TYPE RX-RATE TX-RATE MTU
0 R lan ether 0 0 1500
1 R nonused ether 0 0 1500
2 R newcablemodem ether 0 0 1500

Затем выполни команду: `/interface print oid`. Вывод будет выглядеть примерно так:

[admin@ButchEvans] interface> print oid

Flags: X - отключен, D - динамический, R - работает

0 R name=.1.3.6.1.2.1.2.2.1.2.1 mtu=.1.3.6.1.2.1.2.2.1.4.1
mac-address=.1.3.6.1.2.1.2.2.1.6.1 admin-status=.1.3.6.1.2.1.2.2.1.7.1
oper-status=.1.3.6.1.2.1.2.2.1.8.1 bytes-in=.1.3.6.1.2.1.2.2.1.10.1
packets-in=.1.3.6.1.2.1.2.2.1.11.1 discards-in=.1.3.6.1.2.1.2.2.1.13.1
errors-in=.1.3.6.1.2.1.2.2.1.14.1 bytes-out=.1.3.6.1.2.1.2.2.1.16.1
packets-out=.1.3.6.1.2.1.2.2.1.17.1 discards-out=.1.3.6.1.2.1.2.2.1.19.1
errors-out=.1.3.6.1.2.1.2.2.1.20.1

1 R name=.1.3.6.1.2.1.2.2.1.2.2 mtu=.1.3.6.1.2.1.2.2.1.4.2
mac-address=.1.3.6.1.2.1.2.2.1.6.2 admin-status=.1.3.6.1.2.1.2.2.1.7.2
oper-status=.1.3.6.1.2.1.2.2.1.8.2 bytes-in=.1.3.6.1.2.1.2.2.1.10.2
packets-in=.1.3.6.1.2.1.2.2.1.11.2 discards-in=.1.3.6.1.2.1.2.2.1.13.2
errors-in=.1.3.6.1.2.1.2.2.1.14.2 bytes-out=.1.3.6.1.2.1.2.2.1.16.2
packets-out=.1.3.6.1.2.1.2.2.1.17.2 discards-out=.1.3.6.1.2.1.2.2.1.19.2
errors-out=.1.3.6.1.2.1.2.2.1.20.2

Элемент 0 в обоих командах – это один и тот же интерфейс, как и элемент 1, и так далее…

nuclearcat

Guest

#12

09.01.2008 06:25:00

Не нужно лезть внутрь Mikrotik. Я могу получить все имена интерфейсов, "проходясь" по ним (это можно сделать с помощью perl кода или даже используя libnetsnmp, а не запускать snmpwalk напрямую). Это просто стандартный MIB. IF-MIB::ifDescr.1 = STRING: ether1 IF-MIB::ifDescr.2 = STRING: ether2 IF-MIB::ifDescr.3 = STRING: ether3 IF-MIB::ifDescr.10 = STRING: wlan2 IF-MIB::ifDescr.17 = STRING: vlan2 IF-MIB::ifDescr.19 = STRING: bridge1 IF-MIB::ifDescr.100 = STRING: И сразу видно проблему, которая была скрыта: IF-MIB::ifInDiscards.1 = Counter32: 7 IF-MIB::ifOutDiscards.1 = Counter32: 31786

butche

Guest

#13

09.01.2008 06:33:00

Да, знаю… и теперь, с твоими и моими предыдущими высказываниями, все видят обе возможности. Спасибо, что вернул этот ответ. IF-MIB::ifDescr.1 = STRING: ether1 И сразу я вижу скрытую ранее проблему:
IF-MIB::ifInDiscards.1 = Counter32: 7
IF-MIB::ifOutDiscards.1 = Counter32: 31786 Для тех, кто не в курсе, это показывает, что на маршрутизаторе есть потери пакетов (дискарды) на ether1. Именно такая информация и послужила причиной начала этой темы с просьбой к MT показывать эти данные прямо в WINBOX или CLI. Знаю, большинство из вас поймут, о чем речь, просто решил написать это пояснение для тех, кто не в теме.

BrianHiggins Guest	#14 0 07.05.2008 17:15:00 Есть какие-нибудь мысли, когда это включат в CLI или WinBox? SNMP – это в лучшем случае временное решение, когда пытаешься отладить систему на месте... а в худшем он вообще может быть недоступен.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры