Comments 27
Всегда думал, что SNMP будет работать быстрее, чем telnet.
надо провести сравнительное тестирование.
и да. DES-2108 у меня вроде как снимает FDB по SNMP.
надо провести сравнительное тестирование.
и да. DES-2108 у меня вроде как снимает FDB по SNMP.
DES-2108 отдает FDB только VLAN default
http://dlink.ru/ru/faq/59/262.html
«В серии DES-21XX считать FDB во всех VLAN-ах по SNMP невозможно.»
http://dlink.ru/ru/faq/59/262.html
Спасибо, интересная статья, жду продолжение.
По поводу скорости SNMP — видимо запросы синхронные?
По поводу скорости SNMP — видимо запросы синхронные?
Номер влана в комьюнити — это пять!
У того же DES-3028 точно все несколько хитрее, так с одного OIU бралась FDB для дефлтного VLAN-а, а с другого — куда более обширная таблица, один из индексов в OID которой и было номером VLAN-а, и содержавшая FDB по всех VLAN-ам.
Навскидку нагуглил этоу доку: www.dlink.ru/ru/faq/59/262.html. Она повествует, что по 1.3.6.1.2.1.17.7.1.2.2 живет таблица на все VLAN-ы, по 1.3.6.1.2.1.17.4.3 — на дефолтный. Первый — логичнее использовать, но не у всех железок он есть.
А уж скорость опроса — это тема больная. Тупо перечитывать некисло напрягает железку (а если два чтения параллельно запустить, то и 100% проца скушать можно запросто, вплоть до полной неотзывчивости коммутатора, притом проходит она (забывчивость) не скоро, когда оба процесса дойдут до конца). Есть, как вариант, решение не постоянно дергать SNMP, а дергать его редко, и полагаться на SNMP Trap-ы по подключению/отключению портов.
Правда, неприятным моментом будет не сильная освещенность такого рода вопросов в документации на многие устройства, даже и умеющие что-то подобное делать. Брать саппорт вендора и вперед ))
Навскидку нагуглил этоу доку: www.dlink.ru/ru/faq/59/262.html. Она повествует, что по 1.3.6.1.2.1.17.7.1.2.2 живет таблица на все VLAN-ы, по 1.3.6.1.2.1.17.4.3 — на дефолтный. Первый — логичнее использовать, но не у всех железок он есть.
А уж скорость опроса — это тема больная. Тупо перечитывать некисло напрягает железку (а если два чтения параллельно запустить, то и 100% проца скушать можно запросто, вплоть до полной неотзывчивости коммутатора, притом проходит она (забывчивость) не скоро, когда оба процесса дойдут до конца). Есть, как вариант, решение не постоянно дергать SNMP, а дергать его редко, и полагаться на SNMP Trap-ы по подключению/отключению портов.
Правда, неприятным моментом будет не сильная освещенность такого рода вопросов в документации на многие устройства, даже и умеющие что-то подобное делать. Брать саппорт вендора и вперед ))
Трапы портов — далеко не выход. Что если на порту висит какой-нибудь хаб, за которым 5 абонентов? Получается порт поднят всегда, а маки то появляются, то пропадают. А вдруг порт флапает, будете собирать таблицу постоянно и уроните свич. И даже если брать трапы не на дерганье порта, а на появление маков (mac-tracking, mac-notifucation), редко какие железки такое могут. Если брать L2 dlink'и, то почти никто и не умеет.
И да, верно подмечено, с трапами работать будет сложнее, и сервер нужно будет писать асинхронный.
И да, верно подмечено, с трапами работать будет сложнее, и сервер нужно будет писать асинхронный.
Увы, да.
Вот и получаем странную ситуацию: опрос свича занимает много времени, за это время таблица может мало что оказаться неактуальной, но и просто измениться (это уж от железки зависит, что она отдаст — старый «слепок» таблицы или актуальные данные), опрос этот чреват риском свич вообще завалить, а процессор тратится на преобразование из внутреннеого представления FDB в красивый (и требующий парсинга) формат OID-ов. В то же время, точно, telnet отдает то же быстрее и с меньшим напрягом. Грубо — ищем путь сбора на каждом свиче FDB максимально быстрым способом )
Вот и получаем странную ситуацию: опрос свича занимает много времени, за это время таблица может мало что оказаться неактуальной, но и просто измениться (это уж от железки зависит, что она отдаст — старый «слепок» таблицы или актуальные данные), опрос этот чреват риском свич вообще завалить, а процессор тратится на преобразование из внутреннеого представления FDB в красивый (и требующий парсинга) формат OID-ов. В то же время, точно, telnet отдает то же быстрее и с меньшим напрягом. Грубо — ищем путь сбора на каждом свиче FDB максимально быстрым способом )
Это хорошо, когда железка отдает по снмп «слепок», а не в реальном времени, проблема только в том, что приходится считывать сразу весь слепок. Но чтобы не напрягать сильно свитч, я считывал таблицы по полям с небольшим интервалом времени, а не всю сразу. В результате сталкиваемся с проблемой синхронизации полей: пока считываем первое-второе поле таблицы, в нее добавляется строка, и когда доходим до скажем пятого-седьмого поля, в них уже новые записи. Приходилось после этого таблицу склеивать самостоятельно, вычеркивая битые записи.
Имхо: SNMP хорош только с точки зрения универсальности, ибо не только серверы, но и свичи могут общаться на одном языке. Но как все-таки там все ущербно, эти таблицы скучные с неудобными индексами. Как все-таки не хватает SELECT `mac` WHERE `port`=1 или наоборот. В снмп-таблицах все строго и однобоко.
Имхо: SNMP хорош только с точки зрения универсальности, ибо не только серверы, но и свичи могут общаться на одном языке. Но как все-таки там все ущербно, эти таблицы скучные с неудобными индексами. Как все-таки не хватает SELECT `mac` WHERE `port`=1 или наоборот. В снмп-таблицах все строго и однобоко.
У меня точно те же ощущения: пока прочтешь одним проходом одно поле, второе «убегает». Тут, конечно, идеально бы было трап получать при изменении FDB, но далее «область драконов» — либо по трапу мы перечитываем опять ее всю, либо из трапа инфу берем, и в нашей копии FDB вносим изменения. И то, и то свои моменты имеет.
Так что да, telnet (если есть) и радуемся.
Так что да, telnet (если есть) и радуемся.
Поэтому не надо использовать snmp. Telnet универсальнее и может решить все задачи, даже те, для которых не написали MIB'ов.
Правда очень печалит что в telnet нет flow control. Окончание вывода свитча можно узнать только по промпту, а это нетривиально.
Правда очень печалит что в telnet нет flow control. Окончание вывода свитча можно узнать только по промпту, а это нетривиально.
Тельнет был бы универсальным, если бы во всех железяках была одна и та же CLI, а тут вы напляшетесь с парсингом и написанием «языка» для каждого вендора/прошивки. Прошивку обновили, добавилась функция, добавилось поле/пробел/разделитель, к черту весь порядок парсинга под эту прошивку. Одно только command promt чего стоит, везде разное. Либо будете ждать по таймауту, что тоже криво.
Не везде есть Telnet. И как сказано ниже — при изменениях прошивок — иногда SNMP остаётся последней возможность хоть что-то получить.
Неужто это такая малораспространённая информация?
Нормальные люди просто по snmp в fdb не лазят, нет такой задачи.
А как нормальные люди лазят в fdb? Когда нужно делать статистику или управление авторизацией по маку/порту.
dot1x, для статистики сами значения не нужны, достаточно общего количества.
Для сбора больших массивов данных по SNMP, попробуйте snmpbulk.
Разница примерна в 10 раз (в лучшую сторону).
Разница примерна в 10 раз (в лучшую сторону).
Разумеется это удобнее, но упираемся в то, что она реализована на уровне системы и из-под того же PHP вызывать через SHELL прийдется.
И SNMP v1 она не поддерживает.
И SNMP v1 она не поддерживает.
Булк — отличное решение в плане снижения пиковых нагрузок на железку в момент сбора. Но остается проблема синхронизации полей, о которой я писал выше
Раз уж говорите о цисках — mac notification разве не лучший вариант? Поллить такого рода информацию действительно несколько странно.
Ну про логические интерфейсы все понятно — а у кого такого дается лишь номер VLAN?
Это МОЖЕТ быть порт, а может быть – номер VLAN или прочий логический объект.
Ну про логические интерфейсы все понятно — а у кого такого дается лишь номер VLAN?
Sign up to leave a comment.
FDB-таблицы коммутаторов. Приключения в зоопарке. Часть 1 — SNMP