Комментарии 13
Пора, оставить netmiko (paramiko) и автоматизацию через CLI, в 2022 году надо использовать специальные интерфейсы для работы с сетевым оборудованием NETCONF, RESTCONF, REST. у Huawei есть хорошая дока Datacom-Network Automation Developer .
Современные коробки от Cisco, Huawei имеют на борту даже интерпретатор Python, а некоторые даже умеют и контейнеры с гостевыми OS.
Пока мои изыская в отношении RESTful на Postman или curl ни к чему не привели: просто нет документации даже, например к CloudEngine ничего не нашел. Если есть у вас опыт, то буду благодарен за инструкцию
Могу порекомендовать книг Натальи Самойленко Питон для сетевых инженеров и что то там про Ansible
У Huawei в разделе обучения есть специализация Network Automation Developer, закладка Learning, искать
Training materials: HCIP-Datacom-Network Automation Developer V1.0 Training material.pdf
Lab Guide: HCIP-Datacom-Network Automation Developer V1.0 Lab Guide.pdf
у Cisco есть тоже свое направление DevNET тут не подскажу, где брать.
Да, для Cisco, конечно, нет проблем найти информацию по настройке. Другое дело Huawei... этот гайд, что вы привели (и спасибо Вам за наводку) это официальная документация, которая имеет свои особенности и свой взгляд, она может хорошо подходить для сдачи экзамена, но не совсем подходить для реальной производственной практике. А ведь именно осмысленных и протестированных самими пользователями материалов и не хватает для Huawei. Опять же методичка Натальи писалась для Cisco и просто так на Huawei ее не перенести: все же логика Huawei от Cisco отличается. Этого может быть не видно на первый взгляд, но тот, кто покопался, знает, что многие вещи отличаются. Поэтому я бы не сравнивал два этих вендоров с точки зрения взаимоиспользования методичек, несмотря на то, что речь идёт об использовании стандартизированных протоколов.
Не соглашусь с вами что логика работы с Huawei сильно отключается от работы с Cisco, различаться команды и их вывод, сам подход к настройке каких либо фич. но это особенности OS, а вот сам порядок работы с CLI он один везде, отправили команду , ждем (и вот тут пробема как отловить конец ответа, к примеру netmiko запоминает промт, и ждем пока не появиться это приглашение, пример из мей практики после команды на смену контекста на Cisco ASA меняется, приглашение и netmmiko на этом валиться не получив ожидаемое приглашение,это решаеться путем доп. настройки что мы ждем перед отправкой комманд.) и парсим ответ.
вот тут и становятся полезны всякого рода высокоуровневые интерфейсы по типу napalm, Nornir. Они позволяют сосредоточиться на задаче и спрятать особенности OS под капотом. тот же Cisco NSO оперирует абстракциями, а работа с железом вынесена на драйверы.
Я про такие особенности и различия как, например, необходимость указывать в конце команду return при работе с Huawei и конфигурационным файлом, в то время как на Cisco такой дополнительной команды указывать не надо. А ведь на такие детали и мелочи и уходит больше всего времени траблшутинга: вроде бы ничего концептуально различного нет, но конфиг без этой небольшой команды не запустится. Спасибо, что подсказали посмотреть в сторону napalm, Nornir. Они решают такие проблемы в том числе? Я так понимаю, что такие решения зависят от того описана модель данных под конкретную задачу или нет?..
еще бы посоветовал, максимально использовать SNMP чтоб вычитывать версии софта, модели железа, имена устройств и прочее что стандартизировано, поможет избежать лишний парсинг ответа CLI и уменьшить вероятность ошибок. Тот же eSight максимально конфигурирует железо Huawei через SNMP.
А работать приходится не с самым современным оборудованием, а с тем, какое есть. И активно появляться это начало совсем недавно и не везде - например, в энтерпрайз-сети на оборудовании Cisco, построенной всего пару лет назад никаких этих нетконфов нет и в помине.
Действительно, это только у маркетинга все хорошо и просто. А на деле, если продукт есть и есть документация под него, то ещё не факт, что все заработает. Это надо сидеть и колупаться. Restconf и netconf далеко не волшебные палочки. У Huawei, например, надо их ещё активировать на устройствах и SSL сертификат загрузить, а это та ещё задачка.
Соглашусь, что хватает морально устаревшего железа, но я за то чтоб современные задачи решать современными инструментами. я за Ansible, Napalm, pyATS.
из личного опыта Cisco вся линейка 9000 имеет API, ISG второго поколения умеют ASA имеет на борту REST API, NExus - там python основной язык конфигурации, Cisco свичи 3850 на борту есть python. Arista - REST api, Mikrotik - есть API.
В свое время сам съел пуд соли со всякими netmiko при автоматизации конфигурации Cisco ASA если там есть контексты то это пытка с их переключением и вводом команд, и нет 100% гарантированного результата. в итоге активировал REST API.
Я работал с Ansible и пришел к выводу, что он очень не гибкий. Во-первых, потому что модели YANG/Netconf пишутся только для Cloud Engine коммутаторов Huawei, а для стареньких моделей S приходится использовать cli. И разные операции в одну задачу не запихаешь: для включения интерфейса используется один модуль, а для ACL, например, другой, и для каждой задачи нужно делать свой накат. Поэтому, здесь Python+cli выигрывают: в один скрипт можно сразу много чего включить.
Хорошо кода вы сами писали и сами эксплуатируете скрипт, а вот придет другой специалист на ваше место и ему читать ваш код, он не разберётся и будет плодить свои скрипты. Ansible в этом плен удобней он описан есть сообщество, а то что каждая задача свой таск это я считаю за плюс. изменения в части одного таска гарантированно не затронет другие задачи. И разве при использовании playbook в каждом таске мы не указываем модуль который будем использовать ?
Да, я поддерживаю ваш взгляд на стандартизацию и с точки зрения управления проектами в длительной перспективе они решают может быть недостаток квалифицированных кадров. Netmiko в данном случае это скорее, да, индивидуальное решение, которое может помочь сетевому инженеру начать автоматизировать сеть самому и начать понимать и чувствовать логику этого процесса. Насчет Ansible, да, модули прописываются в playbook и их можно указать несколько, но дело в том, что одни модули работают только с netconf, а другие только с network_cli. Например, недавно я настраивал роутер, и вот для настройки интерфейсов модуль был для Netconf, а вот для настройки DHCP его уже не было и пришлось делать через network_cli. Ну а для того, чтобы поменять протокол нужно лезть в host файл. Отсюда и следует негибкость. Конечно, эта ограниченность связана только с отсутствием описанных моделей, но работа в этом направлении ведётся...
Мой друг Netmiko. Часть 3: один скрипт для разных устройств Huawei