konpare: программа, проверяющая корректность конфигурационных файлов коммутаторов D-Link

[Вторник]

У меня в хозяйстве есть несколько сотен свитчей D-Link. Настраивались эти свитчи в разное время людьми с разной квалификацией. Что получилось в итоге? Думаю, вы догадываетесь.

 

Я "напрягся" и написал программу, которая получает на вход конфигурационные файлы и на выходе выдает список найденных в этих файлах проблем. Сейчас я умею обнаруживать:

 

• port-based loopdetect
  
• SNMP read community не соответствует образцу
  
• SNMP write community не соответствует образцу
  
• абонент и магистраль в одном порту
  
• абонентские порты без filter dhcp_server
  
• абонентские порты без loopdetect
  
• абонентские порты без port_security
  
• абонентские порты с lldp
  
• включен dhcp_local_relay
  
• выключен address_binding trap_log`
  
• выключен filter dhcp_server trap_log/filter dhcp_server log
  
• выключен lldp
  
• выключен loopdetect
  
• выключен loopdetect log
  
• выключен password_encryption
  
• выключен port_security trap_log/port_security log
  
• выключен snmp
  
• выключен sntp
  
• выключен syslog
  
• магистральные порты без lldp
  
• магистральные порты с dhcp_relay
  
• магистральные порты с filter dhcp_server
  
• магистральные порты с loopdetect
  
• название VLAN не соответствует образцу
  
• не указан правильный SNTP-сервер
  
• не указан правильный syslog-сервер
  
• порты с flow_control
  
• порты со значениями tx_rate или rx_rate не по умолчанию
  
• указаны неправильные SNTP-серверы
  
• указаны неправильные syslog-серверы
  

 

Программа бесплатная, исходники открыты, живет на ГитХабе по адресу https://github.com/alexanderfefelov/konpare. Пользуйтесь на здоровье.

 

Замечания и предложения пишите на ГитХаб. Впрочем, если с ГитХабом не справитесь, пишите сюда.

 

Настало время навести порядок!

[rdc]

а где сама программа-то?

[EShirokiy]

rdc, на гитхабе же)

[rdc]

В архиве только исходники.

konpare.jar нету.

или я ослеп?

[pppoetest]

А манул кто читать будет? Там же русским по белому написано - собирать надоть.

[vlad11]

 

Я "напрягся" и написал программу, которая получает на вход конфигурационные файлы и на выходе выдает список найденных в этих файлах проблем. Сейчас я умею обнаруживать:

...

Настало время навести порядок!

 

При таком количестве коммутаторов, вы пробовали использовать NOC project?

[Вторник]

В архиве только исходники.

konpare.jar нету.

или я ослеп?

 

Да, всё верно. JAR не выложен. Сейчас программа часто меняется, и я не вижу смысла после каждого изменения выкладывать его, так как каждый может сбилдить его самостоятельно. Будет релиз - будет JAR на ГитХабе. Пока до релиза далеко, даже требования к программе не сформулированы полностью.

[Вторник]

При таком количестве коммутаторов, вы пробовали использовать NOC project?

 

Год назад NOC был одним из кандидатов при выборе системы мониторинга. Но не был выбран.

[vlad11]

А может, сначала собрать с коммутаторов конфиги в централизованное хранилище, наладить контроль версий и пушить изменения.

А идеально, с нуля сгенерировать правильные конфиги.

 

Хранилище резервных копий и систему резервного копирования, я так понял, вы уже сделали.

[Вторник]

А может, сначала собрать с коммутаторов конфиги в централизованное хранилище

 

Я так и делаю. А вышеописанная программа будет забирать конфиги из этого хранилища и анализировать их.

 

А идеально, с нуля сгенерировать правильные конфиги.

 

Да, есть такая идея. К сожалению, синтаксис у D-Link кривой. Не получится просто решить эту задачу. Кроме того, нужна будет какая-то база свитчей, в которой будет инфо о модели, количестве портов, версии hw и fw. И еще, у меня много свитчей настроены не типовым образом (типа 25-28 - магистрали, всё остальное - абоненты). Значит в эту базу нужно и исключения вносить. К этой базе нужен интерфейс пользователя какой-то. Ну и самое главное - чтобы люди не забывали через этот интерфейс фиксировать изменения в сети.

 

Хранилище резервных копий и систему резервного копирования, я так понял, вы уже сделали.

 

Да. У меня и контроль версий предусмотрен.

[darkagent]

Да, есть такая идея. К сожалению, синтаксис у D-Link кривой. Не получится просто решить эту задачу. Кроме того, нужна будет какая-то база свитчей, в которой будет инфо о модели, количестве портов, версии hw и fw. И еще, у меня много свитчей настроены не типовым образом (типа 25-28 - магистрали, всё остальное - абоненты). Значит в эту базу нужно и исключения вносить. К этой базе нужен интерфейс пользователя какой-то. Ну и самое главное - чтобы люди не забывали через этот интерфейс фиксировать изменения в сети.

Нормально там все, в рамках одной ревизии все гладко, если приводить версии прошивок к общему знаменателю. Универсальные шаблоны (с подстановкой портов и прочего) готовятся без проблем. Интерфейс рисуется на коленке в довольно короткие сроки. У себя такое дело давно организовали - очень и очень удобно.

[pppoetest]

Нормально там все, в рамках одной ревизии все гладко, если приводить версии прошивок к общему знаменателю. Универсальные шаблоны (с подстановкой портов и прочего) готовятся без проблем. Интерфейс рисуется на коленке в довольно короткие сроки. У себя такое дело давно организовали - очень и очень удобно.

+1

[xcme]

Да, есть такая идея. К сожалению, синтаксис у D-Link кривой. Не получится просто решить эту задачу.

Уже получилось. =)

А база нужна, да. Но она не только для этого нужна.

 

p.s. Недавно пробовал обновлять всю сеть, это ~3300 коммутаторов. С моими настройками заняло 100 минут ровно в автоматическом режиме. Это с сейвом, бекапом, обновлением и равномерной нагрузкой.

[Negator]

У нас все коммутаторы в биллинге забиты, там же проставлены аплинки, даунлинки, юзеры привязаны к портам. Для каждого коммутатора по шаблону генерится конфиг с учетом каждого абонента и заливается на свич одной кнопкой. Для каждой модели(изредка ревизии) свой шаблон. Далее заббикс проверяет контрольные точки конфигов каждого свича, если кто то, сделал что то ручками и не поправил базу перкзаливаем правильный конфиг и ищем виновного. Проблем нет уже несколько лет.

[Negator]

Кроме этого храним все конфиги ежедневно за последние пару лет на всякий случай. Централизовано заливаем прошивки(это я через биллинг не автоматизировал, делаю ручками, скриптом сразу для всех свичей)Также есть скрипт,который из голого свича воткнутого в нужную розетку в офисе генерит нужный свич с правильным конфигом и прошивкой, если кому интересно- задавайте вопросы. Коммутаторов у нас примерно 1500

[xcme]

если кому интересно- задавайте вопросы. Коммутаторов у нас примерно 1500

Как проверяете актуальность конфигов, уже залитых на коммутаторы? Как показывает опыт, довольно часто после обновления что-то успевает ребутнуться либо же было недоступно в момент обновления (отключение эл-ва, например). Как убедиться, что вот тут конфиг вчерашний, а вот тут - позавчерашний? Я сейчас просто вставляю дату модификации конфига в system name. (Туда же, кстати, добавляю IP адрес и обслуживаемую сеть. System name видно в lldp remote ports и так можно удобно идентифицировать соседа.)

[Вторник]

если кому интересно- задавайте вопросы

 

Мне интересно. Дайте пример правильного с вашей точки зрения конфига. Заранее благодарю.

[Вторник]

У нас все коммутаторы в биллинге забиты, там же проставлены аплинки, даунлинки, юзеры привязаны к портам. Для каждого коммутатора по шаблону генерится конфиг с учетом каждого абонента

 

Что делаете в нестандартной ситуации? Предположим, отделение полиции, которое не является объектом в вашем биллинге, решило "прокинуть" свою видеокамеру через вашу сеть.

[darkagent]

решило "прокинуть" свою видеокамеру через вашу сеть.

Услуга l2vpn, у которой есть точка(и) входа и точка(и) выхода; если инвентаризация ведется в расширенном режиме, никто не мешает отмечать конфигурацию порта в точке предоставления услуги соответствующим образом (vlanid/ id X/tagged; qinq/s-vlan X/cvid100-150) и т.д. В дальнейшем такая детализация позволит значительно экономить время при обслуживании оборудования или изменениях условий предоставления услуги (вкл/выкл нажатием одной кнопки, и т.п.). Первое время могут возникать трудности с формированием заливаемого конфига, но если на стенде поиграться - за пару дней можно перебрать все возможные вариации и полностью автоматизировать процесс. P.s. заливка конфига естественно через штатные средства коммутатора (download config...), т.е. итоговый конфиг не добивает пачку команд, а полностью заменяет действующий - так надежней.

[pppoetest]

У нас все коммутаторы в биллинге забиты, там же проставлены аплинки, даунлинки, юзеры привязаны к портам. Для каждого коммутатора по шаблону генерится конфиг с учетом каждого абонента и заливается на свич одной кнопкой. Для каждой модели(изредка ревизии) свой шаблон.

Вот прям 1 в 1.

[Вторник]

Вот прям 1 в 1.

 

Отлично. У меня к вам те же вопросы:

 

Дайте пример правильного с вашей точки зрения конфига.

 

Что делаете в нестандартной ситуации?

 

darkagent, спасибо за мнение. Но мои вопросы были обращены к Negator. По-прежнему хочу услышать его ответы.

[Diman_xxxx]

Круто тут у всех:-) Может ТС скомпелированный файлик alfa 1.0 выложит, может даже для винды?

[pppoetest]

У меня к вам те же вопросы:

Дайте пример правильного с вашей точки зрения конфига.

Кмк, вопрос некорректен, нет "правильного" конфига, у нас он генерится под структуру сети.

[Butch3r]

Дайте пример правильного с вашей точки зрения конфига.

Действительно, что тут может быть правильного. У каждого своё правильно - свой sntp сервер, своя адресация, свои вланы. У кого-то есть ISM влан, у кого-то нет.

[Diman_xxxx]

У нас все коммутаторы в биллинге забиты, там же проставлены аплинки, даунлинки, юзеры привязаны к портам. Для каждого коммутатора по шаблону генерится конфиг с учетом каждого абонента и заливается на свич одной кнопкой. Для каждой модели(изредка ревизии) свой шаблон.

Вот прям 1 в 1.

А Вас случаем не ланбиллинг ?