Управление Cisco программно; Telnet vs SNMP? [закрытый]
недавно ко мне подошел сетевой инженер, сотрудник, который хотел бы разгрузить свои второстепенные обязанности сетевого администратора до младшего уровня helpdesk tech. Конкретное место, нуждающееся в Управлении, действует как интернет-провайдер для арендаторов на его одноместной собственности, поэтому ежедневно вносится множество небольших корректировок.
Я думаю, что было бы полезно написать ему приложение winform для управления 32 устройствами Cisco на месте. Я хотел бы изначально предоставить функциональность что может изменить списки управления доступом, назначения VLAN портов и ограничения пропускной способности на VLAN... добавляя больше в список, как его считают ценным.
моей первоначальной мыслью было эмулировать сеанс telnet с сетевым устройством; используя знакомство моего сетевого инженера с взаимодействием командной строки / IOS. Минимальное время потребуется, чтобы узнать соглашения Cisco IOS, себя.
хотя при поиске решений, похоже, что большинство людей предпочитают SNMP. это, или, их конкретные обстоятельства подтолкнули их в направлении SNMP.
Я хотел знать, упустил ли я очевидное преимущество SNMP. должен ли я использовать SNMP? Почему или почему нет?
9 ответов
SNMP отлично подходит для получения информации out устройства Cisco, но не очень полезно управлять устройством. (хотя технически, ты can нажмите новую конфигурацию к устройству Cisco IOS, используя комбинацию SNMP и TFTP. Но отправка совершенно новой конфигурации-довольно тупой инструмент для управления вашим маршрутизатором или коммутатором).
один из других комментаторов упомянул Cisco IOS XR XML API. Важно отметить, что IOS XR XML API является доступно только на устройствах под управлением IOS XR. IOS XR используется только на нескольких устройствах класса высокого класса Cisco, поэтому для 99% всех маршрутизаторов и коммутаторов Cisco API XR XML IOS не является опцией.
другие возможности SSH или HTTP (многие маршрутизаторы Cisco, коммутаторы, AP и т. д. есть дополнительный веб-интерфейс). Но я бы не рекомендовал ни то, ни другое. Насколько мне известно, веб-интерфейс не очень согласован между устройствами, и довольно удивительное количество устройств Cisco не поддержка SSH или, по крайней мере, не поддерживает его в базовой лицензии.
Telnet действительно единственный способ пойти, если вы не нацелены только на небольшой диапазон моделей устройств. Чтобы дать вам что-то для сравнения, собственное программное обеспечение управления сетью Ciscoworks Cisco использует Telnet для подключения к управляемым устройствам.
Я бы не использовал SNMP, вместо этого посмотрите на маленький язык под названием "expect". это делает очень хороший процессор ожидания/ответа для этих маршрутизаторов.
Я сделал разумное количество реального программирования SNMP с коммутаторами Cisco и нашел Python поверх Net-SNMP вполне разумным. Вот пример, через Google Книги, загрузки новой конфигурации Cisco через Net-SNMP и Python: загрузка коммутатора Cisco через Net-SNMP и Python. Я должен раскрыть, что я был соавтором книги, на которую ссылается ссылка.
milage каждого может варьироваться, но мне лично не нравится использовать expect, и предпочитают используйте SNMP, потому что он был фактически разработан как "простой протокол сетевого управления". В крайнем случае, ожидать нормально, но это не будет моим первым выбором. Одна из причин, по которой некоторые компании используют expect, заключается в том, что разработчик просто привыкает использовать expect. Я бы не обязательно чокнулся в обход SNMP только потому, что есть пример кого-то, кто автоматизирует telnet или ssh. Сначала попробуйте для себя.
могут быть некоторые действительно ужасные вещи, которые происходят с expect, которые могут не быть это тоже очевидно. Поскольку expect ожидает ввода, при правильных условиях возникают очень тонкие проблемы, которые трудно отладить. Это не означает, что очень опытный разработчик не может разработать надежный код с expect, но это тоже нужно знать.
одна из других вещей, которую вы можете посмотреть,-это пример использования модуля многопроцессорной обработки для записи неблокирующего кода SNMP. Поскольку это мой первый пост в stackoverflow, я не могу опубликовать более одной ссылки, но если вы google для него, вы можете найти его или другой, используя IPython и Net-SNMP.
одна вещь, которую следует иметь в виду при написании кода SNMP, заключается в том, что он включает в себя чтение большого количества документации и проб и ошибок. В случае Cisco документация довольно хороша.
SNMP не плохо, но он не может быть в состоянии сделать все, что вам нужно. В зависимости от используемой библиотеки и того, как она скрывает детали взаимодействия с SNMP, вам может быть трудно найти правильные части MIB для изменения и даже знать, что или как их изменить, чтобы сделать то, что вы хотите.
одной из причин не использовать SNMP является то, что вы можете сделать всю необходимую конфигурацию с помощью IOS XR XML API. Было бы намного проще собрать команды, которые вы хотите отправить на устройства, используя это, чем взаимодействовать с SNMP.
Я нашел SNMP, чтобы быть болью для руководства. Если вам просто нужно захватить немного данных, это здорово; если вам нужно что-то изменить или использовать, если это может занять много времени. В моем случае мне удобно с CLI, поэтому подход Telnet работает хорошо. Я написал несколько скриптов Python для выполнения административных задач на различных частях сетевого оборудования, используя Telnetlib
SNMP имеет довольно значительный хит процессора на рассматриваемых устройствах по сравнению с telnet; я бы рекомендовал telnet везде, где это возможно. (Как указано в предыдущем ответе, IOS XR XML API был бы хорошим, но, насколько я знаю, IOS XR развертывается только на маршрутизаторах высокого класса несущей).
с точки зрения существующих систем управления конфигурациями двумя коммерческими игроками являются HP Opsware и EMC Voyence. Оба, вероятно, сделают то, что вам нужно. Я не знаю многих решений с открытым исходным кодом, которые фактически поддерживает развертывание изменений. (прогорклый, например, только мониторинг конфигурации, а не предварительная постановка и развертывание изменений конфигурации).
Если вы собираетесь свернуть свое собственное решение, я бы рекомендовал сесть с вашим сетевым администратором и придумать наилучшую модель развертывания для предоставляемой им службы (например, стандартизированный ACL, очередь QoS и имена VLAN; аналогичные записи в ACL, которые имеют одинаковую функцию для разных клиентов, так далее.). Убедитесь, что вся существующая развернутая конфигурация соответствует этому BP перед началом разработки, это сделает проблему гораздо более управляемой. Удачи.
Sidenote: прежде чем изобретать колесо, пишущее другую систему предоставления услуг/систему управления сетью, попробуйте найти существующие. Я знаю довольно много коммерческих решений различной степени гибкости / функциональности, но я уверен,что есть довольно много открытых источников.
Cisco включила параметры меню для приложений helpdesk. В основном вы telnet в поле, и он представляет собой хорошее чистое меню (нажмите 1, 2, 3). Для получения дополнительной информации, проверьте эту ссылку:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/command/reference/frf001.html#wp1050026
еще один голос за expect.
кроме того, вы не хотите разрешать настройку брандмауэров через telnet или SNMP - ssh-единственный способ пойти. Причина в том, что ssh шифрует свою полезную нагрузку и не будет предоставлять привилегированные учетные данные управления для потенциального перехвата.
Если по какой-то причине вы не можете использовать ssh напрямую, подумайте о подключении последовательного консольного сервера с поддержкой ssh к консольному порту брандмауэра и настройке его таким образом.