Comments 22
"Им приходится глазами искать кабель в стойке, а потом просить инженеров проверить VLAN. Хотелось как-то упростить процесс."
Когда-то у кого-то из вендоров можно было помигать портами насквозь по пути линка.
Идея вроде как хороша. Но по реализации много вопросов. 1) есть же dot1x для этих вещей, коммутатор сам поставит нужный vlan после авторизации. 2) хардкодить логин пароль, список устройств в скрипт обернутый в exe не очень хорошая идея, как минимум из-за необходимости постоянно его перекомпилировать в случаях добавления/удаления устройств, как максимум безопасность. Возможно стоило бы сделать web страницу на которую могли ваши техники заходить и проверять. Там же можно было бы и базу прикрутить, и поиск происходил бы в разы быстрее.
Про dot1x и такую функцию не знал, почитаю конечно. Но коммутаторы у нас старые, они все равно таких букв не знают.
Удаление\добавление устройств происходит в внешнем файле с списком их IP. Так что тут без проблем. А насчет пароля, ну да, есть небольшое неудобство.
А насчет веб страницы идея хорошая, надо обдумать.
Не ясно, что делать, когда MAC адрес одинаковый на нескольких конечных устройствах (такое бывает и нередко).
а так скрипт отличный.
P.S. Ну и dot1x это наше все конечно.
Найдет первое вхождение, т.к. после этого завершает работу. Дальше разбираться вручную и много думать. ))
Вот прям удивили - МАС адрес должен быть уникальным. И нормальный коммутатор начинает немного нервничать если с разных портов у него одинаковые маки прилетают ( мы не рассматриваем ситуацию с дублированием маков всякими роутерами - она то как раз и была разработана из-за уникальности маков.
Точно нередко? Я такое встретил один раз за лет 20. И то из-за того что монтажники заливали бездумно готовый конфиг в специфические устройства. Конфигурация перетирала родной мак и в сети оказалось с десяток одинаковых маков.
Я такое встречал на некоторых станках, куда производитель тупо прошивает одну и ту же прошивку с одинаковым МАС. И если у вас такой станок один, то ничего страшного. Если несколько, то начинаются приколы.
уж больше 15 лет прошло, а задачи теже, когда то я писал скрипт на перле, который прохдил по десяткам свичей домовой сети. А суть задачи была следующая, предыдущий администратор наставил свичей в разных домах и уволился, а доокументации не оставил, где что не понятно. Мне предложили обойти эти дома и найти свичи, определить их адрес и связать с их IP. Я походил походил, а потом написал скрипт, который обходя свичи, списывал с них МАК адреса, потом шёл в NAS, и смотрел подключённых по PPPoE клиентах, затем обращался в биллинг, по которому идентифицировал клиентов с их адресами, и для каждого свича с его IP набиралась данные с адресами клиентов. Таким образом мне удалось геолоцировать все свичи, составить схему соединений сети. Перл рулит.
Как же хорошо, когда есть добрый самаритянин.
Ещё неплохо, когда оборудование - не зоопарк, а из линейки одного производителя.
И у него есть симулятор всего этого счастья.
И в нём кем-то добрым нарисована вся реальная сеть, и пакетики шаволятся.
И можно сначала встраивать новые шелезяки, настраивать их, рушить сеть, поднимать, перенастраивать и опять. И всё в эмуляторе.
А потом взять готовые скрипты и разослать по заинтересованным шелезякам.
Но бывает и наоборот.
Как альтернатива - можно выполнить поиск порта при помощи SNMP. Скорость работы с ним даже в однопотоке заметно выше. А если задать под скрипт snmp community с RO-правами, то безопасность скрипта значительно увеличится, так как техники, узнав его, не смогут изменить ни каких настроек.
Сдаётся, что не на все возможные коммутаторы легко найти .mib файлы. Хотя, если много свободного времени, можно, конечно, выгрузить всё, что коммутатор отдаёт по snmp, и сидеть это ручками разбирать, но это такое... Не быстрое...
Ну почему не быстрое, когда есть Grep.
К тому-же есть RFC MIB, которые, как правило, одинаковые для всех однотипных устройств. Например для описанной автором задачи половину данных можно взять из RFC'шного ifMib'a, остается только найти OID'ы таблицы MAC-адресов, которые обычно проприетарные.
Касательно D-Link - у них есть MIB файлы практически для всех коммутаторов, даже довольно старых.
Займитесь документированием вашего оборудования в netbox и жить станет проще.
Ходить телнетом каждый раз на все коммутаторы, передавая в открытом виде учетные данные — сомнительное удовольствие. Таблицы коммутации всех коммутаторов (а также таблица ARP маршрутизатора) собираются с определенной периодичностью по SNMP, записываются в БД с отметками времени, и в любой момент через фронтенд в виде веб-интерфейса по любому из параметров и временному фильтру ищется хоть текущий порт подключения, хоть история переключений конкретного клиента.
Во-первых, зачем это все если есть ансибл? Во-вторых, учетка в скрипте? В третьих, телнет?Серьезно?
А все потому, что сначала надо было продумать архитектуру, а потом ее собирать.
Ищем порт на коммутаторах D-Link