Похожие статьи по автоматизации сети, которыми я поделился, можно найти в каталоге «NetDevOps с нуля».
В последние годы, благодаря постоянному развитию глобальной области облачных вычислений и постоянному росту бизнеса, сетевые технологии также продолжали развиваться, и появилась технология SDN. От исходной основной идеи разделения пересылки и управления на основе Openflow люди продолжают расширяться. В расширении SDN люди в настоящее время могут прийти к консенсусу, что Openflow больше не является необходимым условием (но разделение пересылки и управления по-прежнему является основным условием), а программируемость сети постепенно стала одним из важных критериев измерения архитектуры SDN.
Программируемые операции традиционного сетевого оборудования обычно основаны на протоколах CLI и SNMP. Будь то сценарии или программное обеспечение для управления сетью, все они разрабатываются на этой основе для достижения широкого диапазона возможностей сетевого программирования, о которых мы собираемся поговорить сегодня. возможности, тем самым реализуя автоматизацию многих сценариев. Некоторые устройства поддерживают настройку некоторых веб-интерфейсов и замену общей конфигурации через xml. Они очень редки и не будут подробно описаны в этой статье.
интерфейс командной строки
CLI (Интерфейс командной строки) реализует взаимодействие человека и компьютера через командную строку. Это необходимый навык для сетевых работников. Люди каждый день открывают программное обеспечение SSH или Telnet на устройстве, затем вставляют конфигурацию, сохраняют ее и вступают в силу. Однажды люди устали от такого рода повторений и использовали программу для автоматического создания сценариев конфигурации, пакетного входа в устройство и выдачи конфигураций для вступления в силу, реализуя автоматизацию. Это программируемый по сети метод. Давайте поговорим о преимуществах, которые очень соответствуют мышлению, идеям и существующим техническим системам людей. Но в конечном итоге этот подход отдает предпочтение людям, а не сетевым устройствам. Он имеет следующие недостатки:
-Существуют огромные различия в наборах команд между производителями. Не только производители, но и разные версии программного обеспечения одной и той же модели могут иметь очень разные различия.
-Разработчики должны быть знакомы с набором команд и уметь его использовать. На уровне конфигурации существуют риски безопасности. Например, легким движением руки порт, который я хотел открыть, превратился в закрытый порт…
-Отсутствуют обязательные требования к протоколам передачи (SSH и Telnet), есть риски безопасности производства.
-Процесс разбора и генерации конфигураций чрезвычайно сложен. Во многих случаях написанные обычные правила могут быть лишь бесконечно близкими к «истине», но не всей «истиной».
— Транзакционность отсутствует, и конфигурация может частично вступить в силу, а часть — не вступить в силу.
- Автоматизированного механизма проверки нет, и он полностью зависит от людей. Например, я хочу проверить, корректен ли сгенерированный скрипт. Способ есть, но он очень сложен и часто его сложно легко реализовать.
-Нет представления о моделировании данных
CLI — это всегда способ взаимодействия человека и компьютера. Он может дать сети определенные возможности программирования с помощью программ, но, в конце концов, это не тот метод, который по своей сути является программируемым в сети. В условиях нынешней волны облачных вычислений и SDN он не подходит для крупномасштабного автоматического развертывания в сети, а его программируемость ограничена. Посторонним трудно понять сложность разработки.
SNMP
SNMP (SNMP, Simple Network Management Protocol), этот протокол может поддерживать системы управления сетью, чтобы отслеживать, есть ли на устройствах, подключенных к сети, какие-либо ситуации, вызывающие внимание руководства. Он состоит из набора стандартов управления сетью, включая протокол прикладного уровня, схему базы данных и набор объектов данных.
Для части контента в Википедии мы выделяем управление сетью, мониторинг и объекты данных. Он используется для управления сетью, может быть настроен и собран и в основном используется для мониторинга. Он имеет моделирование данных для структурирования некоторых модулей, характеристик и данных о состоянии сетевого оборудования. В основном используется для систем управления сетью (в основном мониторинга). Тогда поговорим о его недостатках:
-Плохая читаемость. Он предпочитает «машину» в человеке-машине. Он не читается при использовании, и данные моделирования также не читаются. Он использует расширенный набор ASN.1.
- Безопасность ограничена. Существует три версии: v1, v2c и v3, безопасность которых последовательно улучшается. Однако наиболее распространенным является v2c, который имеет ограниченную безопасность. Версия v3 очень безопасна по своей конструкции, но не универсальна. . .
-Не существует механизма резервного копирования, восстановления или отката. У нас также есть show run и другие методы для резервного копирования командной строки, но snmp. . .
- Очень немногие пишут. Много читаю, мало пишу, в основном использую для мониторинга.
-Элементы данных, которые могут быть собраны, ограничены, и невозможно получить конфигурацию всего устройства. Часто мы обнаруживаем, что можем использовать cli для его сбора, но не можем использовать для его сбора snmp.
-Существует узкое место в производительности. Верхний предел собираемых данных — 64 КБ, а степень детализации сбора слишком велика. В больших и сложных сетях это может занять несколько минут или больше. Это также подчеркивает важный момент. Наши требования к детализации также очень строгие. Часто мы надеемся собирать трафик порта каждые несколько секунд. Я думаю, что в больших сетях традиционное программное обеспечение для управления сетью… Если расширить еще одно предложение, текущий метод — это телеметрия (например, gRPC), которая может достигать микросекундного уровня, а некоторые требуют комбинации программного и аппаратного обеспечения. Это пока не популярно, но в будущем это должно стать тенденцией. Что касается того, когда это произойдет в будущем…
-С момента своего появления SNMP широко использовался в сфере сетевого мониторинга для получения данных для мониторинга. Отсутствие и сложность возможностей настройки привели к тому, что их мало использовали при настройке сети. Сетевое программирование только для чтения.
Протокол Netconf и модель YANG
Какие протоколы управления сетями нам нужны, чтобы лучше реализовать программируемость сети и повысить уровень автоматизации?
IETF предложил следующие идеи в RFC3535 в 2002 году (на самом деле их 33. Основываясь на онлайн-информации и знаниях автора, я написал следующие идеи):
1. Имеется программируемый интерфейс для настройки сети.
2. Одна и та же конфигурация может использоваться разными производителями и моделями.
3. Необходимость унификации языка моделирования с хорошей читаемостью.
4. Полная проверка ошибок и функции восстановления.
5. Транзакционный
Если у вас есть идея, просто реализуйте ее. В 2006 году IETF предложил протокол Netconf, который решил проблемы, поднятые RFC3535. Первоначальная версия Netconf оговаривала только базовую структуру и операции протокола, а также определяла решения, учитывающие некоторые проблемы RFC3535. Он не предусматривал единого языка моделирования. Таким образом, оборудование некоторых ранних производителей поддерживало только некоторые базовые операции Netconf и не использовало унифицированный нижний уровень. Язык моделирования данных.
RFC6020 был выпущен в 2010 году и предлагал язык моделирования YANG Model и метод его объединения с NETCONF. Одно определение — это язык моделирования данных, который объединяет базовую логику ресурсов между производителями, а другое определение — это унифицированный набор команд для операций каждого производителя над данными конфигурации и данными о состоянии. Экземпляры данных, созданные моделью YANG, обертываются протоколом Netconf. Transmission, они объединяются друг с другом, чтобы создать новый набор универсальных сетевых программируемых интерфейсов новой эпохи, основанный на модели YANG и управляемый протоколом Netconf.
После 2016 года протокол Netconf был тесно интегрирован с моделью YANG и стал популярным. До сих пор, когда мы смотрели на некоторые аспекты программного обеспечения архитектуры SDN, мы более или менее слышали эти два термина.
YANG и Netconf, один статический, а другой динамический, точно так же, как инь и янь. Эти двое создали сетевой программируемый мир следующей эпохи. (Когда мы посмотрим на склад YANG на github, мы также обнаружим, что его значок — Tai Chi, а связь между его названием и «Yang» в некоторой степени раскрывает дизайнерские идеи оригинального дизайнера).
Далее мы кратко поговорим о модели YANG и протоколе Netconf. Давайте сначала поговорим о языке моделирования данных YANG, чтобы увидеть, как он описывает цифрового двойника этого сетевого мира.
Модель ЯН
В документе RFC6020 в первой главе четко указано: YANG, язык моделирования данных для протокола конфигурации сети. Это аббревиатура языка моделирования данных еще одного следующего поколения (Ян). Это язык моделирования, используемый для описания сетевых концепций.
Поддерживает определение списков, словарей и даже более сложных структур данных, поддерживает ограничения, перечисления, импорт ссылок, управление версиями и пространства имен. Ввиду нехватки места дадим краткое пояснение. Для получения подробной информации вы можете обратиться к:
Он может очень просто описать это сетевое устройство на структурированном языке. Например, для определения порта:
Как профессиональный персонал по эксплуатации и техническому обслуживанию, обладающий небольшими знаниями в области сетевых технологий и основами программирования, вы можете относительно четко понять определение порта. Это структура списка, и их может быть несколько. Одним из его атрибутов является имя интерфейса (также ключ). , уникальный, неповторяемый), а также атрибут скорости и атрибут дуплекса, оба из которых являются строками.
Многие атрибуты сетевого устройства описываются моделью YANG, включая состояние конфигурации и рабочее состояние.
Таким образом, модель YANG описывает онлайн-мир, используя структурированный язык. Если вам интересно, вы можете прочитать приведенную выше публикацию в блоге в Интернете, в которой есть очень подробное описание.
Его можно очень хорошо преобразовать в данные XML и обернуть для передачи протоколом Netconf (мы объясним это позже):
При этом, чтобы нивелировать различия между вендорами, Openconfig во главе с Google стандартизировала модель данных. На официальном сайте мы видим слоган «Независимое от поставщиков, управляемое моделями управление сетью, разработанное пользователями», разработанное пользователями и кроссплатформенное. Общее для поставщиков сетевое программирование на основе моделей (сначала переведем это так). Проще говоря, это сделать моделирование между различными производителями одинаковым, чтобы при настройке определенных данных вам не приходилось просматривать частную модель ян каждого производителя по отдельности. Но в Интернете всегда есть частные протоколы, и разные производители всегда будут создавать новые и лучшие частные протоколы для «лучшего пользовательского опыта» и «лучшей бизнес-стратегии» (это действительно первородный грех производителей сетей). На рисунке показаны некоторые из наиболее часто используемых реализаций модели openconfig yang.
Судя по картинке, думаю, их довольно много, а часто используемые конфигурации относительно полные. Но на практике это зависит от того, поддерживает ли производитель и эти янские модели. В основном поддерживаются некоторые устройства более высоких версий определенной тематики. Отечественные пока не присматривался.
Сети не могут быть абсолютно одинаковыми. Для инженера, который занимается разработкой и обслуживанием сетей, иметь возможность достичь той же цели – это счастье!
openconfig можно найти по адресу https://github.com/openconfig/public/tree/master/release/models.
Частных моделей Ян можно найти на различных официальных сайтах.
Протокол Netconf
Поговорив о модели Ян, давайте поговорим о протоколе Netconf. Модель Ян определяет цифровое описание сетевого мира, а Netconf определяет сбор (получение) и корректировку (конфигурацию) данных.
Netconf инкапсулирует данные мира, описываемого моделью Ян, для реализации управления сетевым миром.
Данные Yang инкапсулируются в XML, а затем управляются через протокол Netconf. Это протокол с отличной многоуровневой идеей, описывающей некоторые детали протокола в иерархическом порядке. Давайте посмотрим на картинку выше.
-Передача: Netconf передается по протоколу SSH, ориентирован на соединение и имеет гарантии безопасности.
-Сообщение: выполните удаленный вызов к сетевому устройству через RPC, сетевой менеджер выдает запрос RPC, и сетевое устройство возобновляет ответ rpc.
-Операция: это душа Netconf. Он поддерживает get (данные конфигурации и запуска), get-config (получение данных конфигурации, устройство может иметь несколько данных конфигурации: один работающий, один запуск, несколько кандидатов-кандидатов), edit -config (настройка параметров сетевого устройства, поддержка добавления, удаление и изменение), delete-config, copy-config (копирование конфигурации в место назначения, местом назначения может быть ftp, файл или работающая конфигурация и т. д.), lock\unlock (заблокировать конфигурацию для предотвращения конфликтов конфигурации или сбоев, вызванных многопроцессные операции) и так далее.
-Данные: данные — это данные Ян, завернутые в XML. Как и порт, который мы описали выше, структурированные данные легко программировать. Используется для описания данных, которые необходимо настроить, удалить или получить.
Это четыре уровня Netconf. Управляющая сторона и сетевое устройство взаимодействуют через Netconf, через традиционный протокол ssh, используя подсистему Netconf, а порт по умолчанию — 830. Как показано ниже:
На этом рисунке показано взаимодействие с использованием сырого ssh, но на самом деле мы реализуем этот процесс посредством программирования. Метод реализации программирования я продемонстрирую вам позже.
Netconf настраивает сетевые устройства. Процесс взаимодействия примерно следующий:
Эта картинка такая низкая, что вы также можете видеть, что ее нарисовал я… Мое понимание Netconf такое же, как указано выше. Я думаю, что в Интернете много неправильных изображений и многие действия серверного агента неправильны. Это то, что я интуитивно чувствую, когда захожу в устройство, и конечно это соответствует один в один с официальной документацией.
Мы можем посмотреть некоторые примеры Netconf:
Здравствуйте, дайте ссылку.
Мы увидели несколько ключевых слов: версию Netconf, поддерживаемую модель YANG, идентификатор сеанса. При этом hello указывает, в каком пространстве имен мы работаем. В данном случае это соответствующая версия Netconf.
Получить конфигурацию
Одним из параметров get-cofig является источник, откуда получаются данные конфигурации (работа, запуск и т. д.). Еще одним параметром является фильтр, то есть какие данные получаются из модели данных, описываемой какой моделью Ян. Это соответствует возможностям, первоначально отправленным сетевым устройством. В случае успеха будут возвращены соответствующие данные конфигурации.
Получить конфигурацию или рабочие данные
Аналогично get-config, но в результате получается запуск конфигурации (личное понимание) или запуск данных. Фильтр можно указать.
Копировать конфигурацию
Операция копирования имеет два параметра: источник и место назначения. Успешный ответ отмечается тегом ОК.
Изменить конфигурацию
При редактировании конфигурации укажите редактируемый элемент данных, пространство имен возможности и соответствующую метку. Например, это настройка DHCP, которая описывается моделью Ян http://tail-f.com/ns/example/dhcp.
Закройте сессию корректно
Именно такого рода сообщения передаются туда и обратно по ssh. Мы просто извлекаем часть сообщения, чтобы облегчить всеобщее понимание.
Затем просто добавьте некоторый контент для справки.
-Netconf основан на сеансе, и каждый успех будет иметь идентификатор сеанса.
-Каждый запрос имеет идентификатор сообщения, при условии, что он постепенно увеличивается.
-Конфигурация данных может быть заблокирована, эксклюзивна и управляться через блокировку.
-Netconf является транзакционным, и операции выполняются либо полностью, либо ни одного. При этом, согласно официальной документации сайта, данная транзакционность предназначена для настройки N сетевых устройств, то есть однократный полиморфизм конфигурации может поддерживать транзакционность. Но я еще этого не сделал…
-Netconf поддерживает подписку. По производительности устройства порядок составляет около 5 сеансов. Я могу подписаться на определенный элемент данных, и устройство уведомит меня, когда он изменится.
-Возможности, вот как я это понимаю. Сетевое устройство отправляет версию Netconf и модели YANG, а терминал управления отправляет версию Netconf. Только когда версия Netconf совпадает с этими двумя, мы можем продолжить. Это мое интуитивное ощущение. Любые советы приветствуются.
-Операции, такие как получение редактирования, будут указывать данные, которые необходимо изменить, которые можно отфильтровать с помощью фильтра.
-copy-config поддерживает копирование полного набора конфигураций откуда-то куда-то. Где-то может быть FTP-файл, работающие, запускаемые и возможные конфигурации на устройстве.
-Netconf также поддерживает проверку конфигурации с помощью операции проверки.
Эта статья все же надеется на популяризацию науки, и я не буду вдаваться в подробности. Вы можете прочитать соответствующие протоколы RFC, которые на самом деле не очень длинные.
На практике, основываясь на некотором программном обеспечении с открытым исходным кодом, таком как ncclient Python, мы можем легко автоматически настраивать сетевые устройства и достигать программируемости сети. Это миссия Netconf и YANG Model.
Сетевой персонал читает хорошо отформатированные определения модели YANG и использует соответствующие языки программирования для выполнения программируемых операций на сетевых устройствах на основе операций, определенных Netconf. Таким образом, прокладывается путь к программируемости сети.
Давайте расширим и представим, что Модель YANG определила структуру данных сетевого устройства. Мы можем управлять им через Netconf. Может ли он также работать через другие протоколы?
Ответ: да. Фактически, многие другие протоколы произошли от Netconf, например RESTConf. Как показано ниже,
Модель YANG (публичная и собственная) определяет структуру данных, над которой находятся новые протоколы управления сетью, Netconf, RESTCon, gRPC и т. д. Таким образом, мы можем управлять сетевыми устройствами через RESTConf на основе HTTP RESTful API, мы также можем управлять сетью. устройства через Netconf на основе SSH или мы можем управлять сетевыми устройствами через gRPC на основе HTTP2.0. Все они основаны на YANG с хорошей структурой данных. Смоделируйте, напишите соответствующие данные, инкапсулируйте их в xml или json для программирования сетевых устройств. Это будущее сетевого программирования. Если быть точным, это Model Driven Program, сетевое программирование на основе модели. Сетевые инженеры постепенно сосредотачиваются на параметрах устройства, а не на наборе команд, и настраивают параметры сети, считывая соответствующую модель данных.
В конце пишу, зачем мне открывать этот паблик аккаунт. Когда я учился в школе, я изучал информатику и технологии. После выхода на рабочее место я занимался эксплуатацией и обслуживанием сети. Если подумать, то причина, по которой меня разделили на команды, может заключаться в том, что я был аспирантом НИИ сетевых технологий (руководство смешное). С самого начала я занимался сетевой деятельностью. На более позднем этапе эксплуатации и обслуживания использовались инструменты для упрощения работы и повышения эффективности на основе CLI. Позже эти инструменты постепенно превратились в веб-приложения со структурой BS. Они постоянно знакомились с новыми технологиями и продолжали расширять новые функции.
К счастью, они догнали развитие технологий с открытым исходным кодом и SDN, и постепенно я перешел на работу в NetDevOps и использовал свои навыки программирования для улучшения возможностей команды по эксплуатации и обслуживанию. Мне также понравилось писать эту строку кода. По ходу написания постепенно обнаруживается, что NetDevOps должен быть навыком, которым должен обладать каждый сетевой инженер в будущем (каждый подливает масла в огонь), чтобы он мог достичь как высокого уровня планирования, так и быстрой реализации. Если честно, оглядываясь назад на некоторую информацию в Интернете, я понимаю, что в Китае ее очень мало, и внутренняя атмосфера не очень сильна. Многие отечественные программы основаны на старых CLI и snmp, и все до сих пор используют для работы текстовые инструменты и SSH-инструменты. Поэтому я надеюсь, что ямогу научить других ловить рыбу, поделиться своим опытом (ямы) и навыками с большим количеством инженеров по эксплуатации и техническому обслуживанию сети., и сделаю все возможное. Сяо Чу сказал, что вы можете чему-то научиться, чтобы уменьшить свою рабочую нагрузку, и, сосредоточив внимание на отдаленном будущем, эксплуатация и обслуживание домашних сетей могут действительно развиваться в сторону автоматизации.
В будущем я запишу несколько видео и напишу несколько статей. Написание документа кажется действительно утомительным. Приглашаем вас подписаться, собирать коллекцию, ставить лайки и смотреть.
приложение: общие операции Netconf
Проектирование решения DWDM OTN и ценовое предложение, пожалуйста, свяжитесь со мной, Тейлор Хуанг
