лично я проверял только на IPSec. IPsec не должен сообщать о себе информации, независимо от реализации и конфигурирования, это его поведение по умолчание, его назначение. Относительно других тоннелирующих протоколов, то читал на форумах разных вендоров, что никакие точка-точка тоннели не возвращают ICMP. Но, насколько помню, микротик-роутер возвращал через gre, l2tp и pptp. Может быть есть еще зависимость от конкртеного продукта, например, фаерволы могут действовать иначе, все-таки они специфичные устройства, но это так... лирика, точно я не скажу, уж извините.
Может и займет, почему нет.. Ведь если нет никаких программных ограничений (полисеров) в скрипте, то логично, что такое может произойти. Особенно, если OPS будет отрабатывать не только свои задачи по умолчанию, но и те, что пользователь прописал сам. А у вас был такой инцидент?
Да, я поддерживаю ваш взгляд на стандартизацию и с точки зрения управления проектами в длительной перспективе они решают может быть недостаток квалифицированных кадров. Netmiko в данном случае это скорее, да, индивидуальное решение, которое может помочь сетевому инженеру начать автоматизировать сеть самому и начать понимать и чувствовать логику этого процесса. Насчет Ansible, да, модули прописываются в playbook и их можно указать несколько, но дело в том, что одни модули работают только с netconf, а другие только с network_cli. Например, недавно я настраивал роутер, и вот для настройки интерфейсов модуль был для Netconf, а вот для настройки DHCP его уже не было и пришлось делать через network_cli. Ну а для того, чтобы поменять протокол нужно лезть в host файл. Отсюда и следует негибкость. Конечно, эта ограниченность связана только с отсутствием описанных моделей, но работа в этом направлении ведётся...
Я про такие особенности и различия как, например, необходимость указывать в конце команду return при работе с Huawei и конфигурационным файлом, в то время как на Cisco такой дополнительной команды указывать не надо. А ведь на такие детали и мелочи и уходит больше всего времени траблшутинга: вроде бы ничего концептуально различного нет, но конфиг без этой небольшой команды не запустится. Спасибо, что подсказали посмотреть в сторону napalm, Nornir. Они решают такие проблемы в том числе? Я так понимаю, что такие решения зависят от того описана модель данных под конкретную задачу или нет?..
Да, для Cisco, конечно, нет проблем найти информацию по настройке. Другое дело Huawei... этот гайд, что вы привели (и спасибо Вам за наводку) это официальная документация, которая имеет свои особенности и свой взгляд, она может хорошо подходить для сдачи экзамена, но не совсем подходить для реальной производственной практике. А ведь именно осмысленных и протестированных самими пользователями материалов и не хватает для Huawei. Опять же методичка Натальи писалась для Cisco и просто так на Huawei ее не перенести: все же логика Huawei от Cisco отличается. Этого может быть не видно на первый взгляд, но тот, кто покопался, знает, что многие вещи отличаются. Поэтому я бы не сравнивал два этих вендоров с точки зрения взаимоиспользования методичек, несмотря на то, что речь идёт об использовании стандартизированных протоколов.
Я работал с Ansible и пришел к выводу, что он очень не гибкий. Во-первых, потому что модели YANG/Netconf пишутся только для Cloud Engine коммутаторов Huawei, а для стареньких моделей S приходится использовать cli. И разные операции в одну задачу не запихаешь: для включения интерфейса используется один модуль, а для ACL, например, другой, и для каждой задачи нужно делать свой накат. Поэтому, здесь Python+cli выигрывают: в один скрипт можно сразу много чего включить.
Действительно, это только у маркетинга все хорошо и просто. А на деле, если продукт есть и есть документация под него, то ещё не факт, что все заработает. Это надо сидеть и колупаться. Restconf и netconf далеко не волшебные палочки. У Huawei, например, надо их ещё активировать на устройствах и SSL сертификат загрузить, а это та ещё задачка.
Пока мои изыская в отношении RESTful на Postman или curl ни к чему не привели: просто нет документации даже, например к CloudEngine ничего не нашел. Если есть у вас опыт, то буду благодарен за инструкцию
А, спасибо, что поправили - как я и говорил, я в этих нюансах не разбираюсь. Моя задача была помочь таким же, как и я, парням из деревни начать автоматизировать, а не производить революции в индустрии, или выдавать эти безусловные основы за открытие. Но для многих людей (я тому пример) эти основы, действительно, открытия.
Не сомневаюсь, что рекомендованные Вами проекты достойны самого пристального внимания и изучения, и может быть ряд читатетелей захотят на них взглянуть. Лично я хотел бы остаться в рамках netmiko пока его возможности не будут полностью для меня исчерпаны.
Вы точно заметили, что этот конфиг не годится для всех устройств! Как вы могли также заметить, это третий пост про netmiko, и в каждом новом посте скрипт улучшается. Как раз в следующем 4-ом посте я хочу рассказать как для разных видов устройств применять разную конфигурацию в рамках одного скрипта - netmiko это может. А также есть решение и по увеличению скорости работы netmiko - ведь все говорят, что он медленный.
Здравствуйте, для меня (не разбирающегося в программировании) это было открытием, и, как я вижу в целом в интернете, информации для Huawei мало, и со всем приходится разбираться самому.
Спасибо за направление в адрес Kirk Byers. Надеюсь, что после освоения netmiko смогу на него взглянуть.
Да, конфиг одинаковый для всех устройств и я понимаю, что этим вопросом вы пытаетесь подставить под сомнение целесообразность автоматизации. "Day0 deployment" в данном случае ограничивается только сетевой доступность, которую приходится настраивать в ручном режиме на каждом устройстве. А вот сервисные настройки (например, клиентские VLAN), которые появляются каждый день, их удобнее и быстрее накатывать скриптом. Особенно в топологии кольца (а, как вы могли заметить, именно такая топология здесь представлена). А что если потребуется прописать ACL на всех устройствах, или сменить адрес NTP сервера, и так далее... Что тоже заходить на каждую железку? Думаю, нет
"Ansible с костыльком может автоматизировать сеть и non-CloudEngine коммутаторов Huawei, как недавно было доказано на нашем Enterprise форуме. Однако в сети, в которой работают разные модели коммутаторов, Ansible не представляется эффективным инструментом на данный момент."
Да, это избыточная строка. Как я подчеркивал в прошлом посте, я человек, который не разбирается в программировании, и потому нашел важным сохранить скрипт максимально последовательным (be consistent), не смотря на его сокращение.
По-моему, воля вообще мало что решает и работает только где-то в области физической выносливости. Здесь же и по всем остальном, что касается души и интеллекта, уместнее говорить о силе духа.
Думаю, что скрипт можно масшабировать на неопределенное число хостов, ведь накат происходит не на все устройства сети одновременно, а по очереди, циклично.
Да, можно импортировать два файла, следующий пост как раз хочу посвятить этому! При этом постараюсь загрузить так много устройств в эмулятор, насколько потянет процессор.
В конце есть ссылка "Немного подробнее про FEC": статейка специально написана для этого кейса и выделена отдельно, чтобы не нагружать кейс.
лично я проверял только на IPSec. IPsec не должен сообщать о себе информации, независимо от реализации и конфигурирования, это его поведение по умолчание, его назначение. Относительно других тоннелирующих протоколов, то читал на форумах разных вендоров, что никакие точка-точка тоннели не возвращают ICMP. Но, насколько помню, микротик-роутер возвращал через gre, l2tp и pptp. Может быть есть еще зависимость от конкртеного продукта, например, фаерволы могут действовать иначе, все-таки они специфичные устройства, но это так... лирика, точно я не скажу, уж извините.
Может и займет, почему нет.. Ведь если нет никаких программных ограничений (полисеров) в скрипте, то логично, что такое может произойти. Особенно, если OPS будет отрабатывать не только свои задачи по умолчанию, но и те, что пользователь прописал сам. А у вас был такой инцидент?
Диаг файл этой команды не собрал. Уже после ивента, когда просили клиента отправить эту команду, вывод показал 0, чего не должно было быть..
<XX>dis user
Total 0,0 printed
Да, я поддерживаю ваш взгляд на стандартизацию и с точки зрения управления проектами в длительной перспективе они решают может быть недостаток квалифицированных кадров. Netmiko в данном случае это скорее, да, индивидуальное решение, которое может помочь сетевому инженеру начать автоматизировать сеть самому и начать понимать и чувствовать логику этого процесса. Насчет Ansible, да, модули прописываются в playbook и их можно указать несколько, но дело в том, что одни модули работают только с netconf, а другие только с network_cli. Например, недавно я настраивал роутер, и вот для настройки интерфейсов модуль был для Netconf, а вот для настройки DHCP его уже не было и пришлось делать через network_cli. Ну а для того, чтобы поменять протокол нужно лезть в host файл. Отсюда и следует негибкость. Конечно, эта ограниченность связана только с отсутствием описанных моделей, но работа в этом направлении ведётся...
Я про такие особенности и различия как, например, необходимость указывать в конце команду return при работе с Huawei и конфигурационным файлом, в то время как на Cisco такой дополнительной команды указывать не надо. А ведь на такие детали и мелочи и уходит больше всего времени траблшутинга: вроде бы ничего концептуально различного нет, но конфиг без этой небольшой команды не запустится. Спасибо, что подсказали посмотреть в сторону napalm, Nornir. Они решают такие проблемы в том числе? Я так понимаю, что такие решения зависят от того описана модель данных под конкретную задачу или нет?..
Да, для Cisco, конечно, нет проблем найти информацию по настройке. Другое дело Huawei... этот гайд, что вы привели (и спасибо Вам за наводку) это официальная документация, которая имеет свои особенности и свой взгляд, она может хорошо подходить для сдачи экзамена, но не совсем подходить для реальной производственной практике. А ведь именно осмысленных и протестированных самими пользователями материалов и не хватает для Huawei. Опять же методичка Натальи писалась для Cisco и просто так на Huawei ее не перенести: все же логика Huawei от Cisco отличается. Этого может быть не видно на первый взгляд, но тот, кто покопался, знает, что многие вещи отличаются. Поэтому я бы не сравнивал два этих вендоров с точки зрения взаимоиспользования методичек, несмотря на то, что речь идёт об использовании стандартизированных протоколов.
Я работал с Ansible и пришел к выводу, что он очень не гибкий. Во-первых, потому что модели YANG/Netconf пишутся только для Cloud Engine коммутаторов Huawei, а для стареньких моделей S приходится использовать cli. И разные операции в одну задачу не запихаешь: для включения интерфейса используется один модуль, а для ACL, например, другой, и для каждой задачи нужно делать свой накат. Поэтому, здесь Python+cli выигрывают: в один скрипт можно сразу много чего включить.
Действительно, это только у маркетинга все хорошо и просто. А на деле, если продукт есть и есть документация под него, то ещё не факт, что все заработает. Это надо сидеть и колупаться. Restconf и netconf далеко не волшебные палочки. У Huawei, например, надо их ещё активировать на устройствах и SSL сертификат загрузить, а это та ещё задачка.
Пока мои изыская в отношении RESTful на Postman или curl ни к чему не привели: просто нет документации даже, например к CloudEngine ничего не нашел. Если есть у вас опыт, то буду благодарен за инструкцию
А, спасибо, что поправили - как я и говорил, я в этих нюансах не разбираюсь. Моя задача была помочь таким же, как и я, парням из деревни начать автоматизировать, а не производить революции в индустрии, или выдавать эти безусловные основы за открытие. Но для многих людей (я тому пример) эти основы, действительно, открытия.
Не сомневаюсь, что рекомендованные Вами проекты достойны самого пристального внимания и изучения, и может быть ряд читатетелей захотят на них взглянуть. Лично я хотел бы остаться в рамках netmiko пока его возможности не будут полностью для меня исчерпаны.
Вы точно заметили, что этот конфиг не годится для всех устройств! Как вы могли также заметить, это третий пост про netmiko, и в каждом новом посте скрипт улучшается. Как раз в следующем 4-ом посте я хочу рассказать как для разных видов устройств применять разную конфигурацию в рамках одного скрипта - netmiko это может. А также есть решение и по увеличению скорости работы netmiko - ведь все говорят, что он медленный.
Здравствуйте, для меня (не разбирающегося в программировании) это было открытием, и, как я вижу в целом в интернете, информации для Huawei мало, и со всем приходится разбираться самому.
Спасибо за направление в адрес Kirk Byers. Надеюсь, что после освоения netmiko смогу на него взглянуть.
Да, конфиг одинаковый для всех устройств и я понимаю, что этим вопросом вы пытаетесь подставить под сомнение целесообразность автоматизации. "Day0 deployment" в данном случае ограничивается только сетевой доступность, которую приходится настраивать в ручном режиме на каждом устройстве. А вот сервисные настройки (например, клиентские VLAN), которые появляются каждый день, их удобнее и быстрее накатывать скриптом. Особенно в топологии кольца (а, как вы могли заметить, именно такая топология здесь представлена). А что если потребуется прописать ACL на всех устройствах, или сменить адрес NTP сервера, и так далее... Что тоже заходить на каждую железку? Думаю, нет
Это какой-то тип низкого вопроса, который должен кого-то здесь задеть?
Другие команды так же запускаются?
В интернете вообще есть успешные примеры запуска netmiko модуля для mikrotik_routeros?
Здравствуйте, покажите как вы запускали скрипт и результат в одном окне. То, что вы приложили это ведь терминал тика
Из вступления к "Мой друг Netmiko":
"Ansible с костыльком может автоматизировать сеть и non-CloudEngine коммутаторов Huawei, как недавно было доказано на нашем Enterprise форуме. Однако в сети, в которой работают разные модели коммутаторов, Ansible не представляется эффективным инструментом на данный момент."
Стараемся)
Да, это избыточная строка. Как я подчеркивал в прошлом посте, я человек, который не разбирается в программировании, и потому нашел важным сохранить скрипт максимально последовательным (be consistent), не смотря на его сокращение.
По-моему, воля вообще мало что решает и работает только где-то в области физической выносливости. Здесь же и по всем остальном, что касается души и интеллекта, уместнее говорить о силе духа.
Думаю, что скрипт можно масшабировать на неопределенное число хостов, ведь накат происходит не на все устройства сети одновременно, а по очереди, циклично.
Да, можно импортировать два файла, следующий пост как раз хочу посвятить этому! При этом постараюсь загрузить так много устройств в эмулятор, насколько потянет процессор.