Программное управление Cisco;Telnet против SNMP?[закрыто]

Question

Недавно ко мне обратился сетевой инженер, мой коллега, который хотел бы передать свои мелкие обязанности сетевого администратора младшему специалисту службы поддержки.Конкретное место, нуждающееся в управлении, выступает в качестве интернет-провайдера для арендаторов на его территории, состоящей из одного объекта, поэтому ежедневно вносится множество небольших корректировок.

Я думаю, было бы полезно написать ему приложение winform для управления 32 устройствами Cisco на месте.Я хотел бы изначально предоставить функциональные возможности, которые могли бы изменять списки управления доступом, назначения портов VLAN и ограничения пропускной способности для каждой VLAN...добавление большего в список, поскольку оно считается ценным.

Моя первоначальная мысль заключалась в том, чтобы эмулировать сеанс telnet. с сетевым устройством;используя знания моего сетевого инженера о взаимодействии командной строки и IOS.Самому изучению соглашений Cisco IOS потребуется минимальное время.

Хотя при поиске решений оказывается, что большинство людей отдают предпочтение SNMP. Это или их конкретные обстоятельства подтолкнули их в сторону SNMP.

Я хотел знать, не упустил ли я очевидное преимущество SNMP. Должен ли я использовать SNMP?Почему или почему нет?

Answer 1

SNMP отлично подходит для получения информации об устройстве Cisco, но не очень полезен для управления устройством. (хотя технически вы можете передать новую конфигурацию на устройство Cisco IOS, используя комбинацию SNMP и TFTP. Но отправка всей новой конфигурации довольно тупой инструмент для управления вашим маршрутизатором или коммутатором).

Один из других комментаторов упомянул XML IOS XR XML API. Важно отметить, что API-интерфейс IOS XR XML доступен только на устройствах, работающих под управлением IOS XR. IOS XR используется только на нескольких устройствах Cisco высшего класса операторского класса, поэтому для 99% всех маршрутизаторов и коммутаторов Cisco IOS XR XML API не подходит.

Другие возможности: SSH или HTTP (многие маршрутизаторы Cisco, коммутаторы, точки доступа и т. д. имеют дополнительный веб-интерфейс). Но я бы рекомендовал против любого из них. Насколько мне известно, веб-интерфейс не очень согласован между устройствами, и довольно удивительное количество устройств Cisco не поддерживают SSH или, по крайней мере, не поддерживают его в базовой лицензии.

Telnet - действительно единственный путь, если только вы не ориентируетесь на небольшой диапазон моделей устройств. Для сравнения, собственное ПО Cisco для сетевого управления CiscoWorks использует Telnet для подключения к управляемым устройствам.

Answer 2

Я бы не стал использовать SNMP, а взглянул бы на маленький язык под названием «ожидаем». это обеспечивает очень хороший процессор ожидания / ответа для этих маршрутизаторов.

Answer 3

Я выполнил достаточное количество реального SNMP-программирования с коммутаторами Cisco и считаю Python поверх Net-SNMP вполне разумным. Вот пример, через книги Google, загрузки новой конфигурации Cisco через Net-SNMP и Python: Загрузка коммутатора Cisco через Net-SNMP и Python . Я должен сообщить, что я был соавтором книги, на которую есть ссылка.

Общий доход каждого может отличаться, но лично мне не нравится использовать ожидаемо , и я предпочитаю использовать SNMP, потому что он на самом деле был разработан как «Простой протокол управления сетью». В крайнем случае, ожидать это нормально, но это не будет моим первым выбором. Одна из причин, по которой некоторые компании используют ожидание, заключается в том, что разработчик просто привык к использованию ожидания. Я бы не стал отказываться от обхода SNMP только потому, что есть пример кого-то, кто автоматизирует telnet или ssh. Попробуйте сами.

Могут быть некоторые действительно ужасные вещи, которые случаются с ожиданием, но это также может быть неочевидным. Поскольку ожидайте ввода, при правильных условиях возникают очень тонкие проблемы, которые трудно отладить. Это не означает, что очень опытный разработчик не может разработать надежный код с ожидаемым результатом, но это также необходимо знать.

Еще одна вещь, на которую вы можете обратить внимание, это пример использования многопроцессорного модуля для написания неблокирующего кода SNMP. Поскольку это моя первая публикация в stackoverflow, я не могу опубликовать более одной ссылки, но если вы найдёте ее в Google, вы можете найти ее или другую, используя IPython и Net-SNMP.

При написании SNMP-кода следует помнить о том, что при этом нужно читать много документации и проб и ошибок. В случае с Cisco документация довольно хорошая, хотя.

Answer 4

SNMP неплох, но он не может делать все, что вам нужно. В зависимости от используемой вами библиотеки и того, как она скрывает детали взаимодействия с SNMP, вам может быть трудно найти нужные части MIB для изменения и даже не зная, что или как их изменить, чтобы делать то, что вы хотите.

Одной из причин не использовать SNMP является то, что вы можете выполнить всю необходимую настройку, используя API IOS XR XML . Может быть намного проще объединить команды, которые вы хотите отправить на устройства, использующие это, чем взаимодействовать с SNMP.

Answer 5

Я обнаружил, что SNMP - это боль для менеджмента. Если вам просто нужно собрать немного данных, это здорово; если вам нужно что-то изменить или использовать, если это тяжело, это может занять очень много времени. В моем случае я чувствую себя комфортно с CLI, поэтому подход Telnet работает хорошо. Я написал несколько скриптов Python для выполнения административных задач в различных частях сетевого оборудования, используя Telnetlib

Answer 6

SNMP имеет довольно значительную нагрузку на процессор на рассматриваемых устройствах по сравнению с telnet; Я бы порекомендовал телнет везде, где это возможно. (Как указывалось в предыдущем ответе, IOS XR XML API был бы хорош, но, насколько я знаю, IOS XR развернут только на высокопроизводительных маршрутизаторах операторского класса).

С точки зрения существующих систем управления конфигурациями, двумя коммерческими игроками являются HP Opsware и EMC Voyence. Оба, вероятно, сделают то, что вам нужно. Я не знаю многих решений с открытым исходным кодом, которые фактически поддерживают развертывание изменений. ( RANCID , например, только осуществляет мониторинг конфигурации, а не предварительную подготовку и развертывание изменений конфигурации).

Если вы собираетесь развернуть свое собственное решение, я бы порекомендовал вам пообщаться с вашим сетевым администратором и разработать оптимальную модель развертывания для предоставляемой им услуги (например, стандартизированный ACL, очередь QoS и VLAN). имена; похожие записи в списках ACL, которые имеют одинаковую функцию для разных клиентов и т. д.). Убедитесь, что все существующие развернутые конфигурации соответствуют этому BP, прежде чем вы начнете проектировать, это сделает проблему намного более управляемой. Желаем удачи.

Answer 7

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

Answer 8

Cisco включила пункты меню для приложений службы поддержки. По сути, вы подключаетесь к коробке, и она показывает хорошее чистое меню (нажмите 1, 2, 3). Для получения дополнительной информации проверьте эту ссылку:

http: / /www.cisco.com/en/US/docs/ios/12_2/configfun/command/reference/frf001.html#wp1050026

Answer 9

Еще один голос за ожидание.

Кроме того, вы не хотите разрешать настройку ваших брандмауэров через telnet или SNMP: единственный способ — ssh.Причина в том, что ssh шифрует свою полезную нагрузку и не подвергает учетные данные привилегированного управления потенциальному перехвату.

Если по какой-то причине вы не можете использовать ssh напрямую, рассмотрите возможность подключения последовательного консольного сервера с поддержкой ssh ​​к консольному порту брандмауэра и его настройку соответствующим образом.