Интересно обменяться мнениями и опытом применения языков программирования в решении задач сетевого инженера, если вы используете какие-то методы и подходы автоматизации, напишите об этом в комментариях, а я расскажу о некоторых своих наработках в этом направлении.
Не так давно я был участником проекта по изменению схемы IGP взаимодействия, в рамках проекта необходимо было произвести миграцию в живой сети. Учитывая масштаб проекта работы разбили на несколько независимых этапов, и разработали прекрасный, с точки зрения сетевого дизайна, план миграции чтобы бесшовно переходить на следующий этап и откатывать конфигурацию маршрутизаторов на предыдущий если тесты показывали поведение отличное от ожидаемого. При планировании конфигурации мы разбили этапы на группы со сложным и простым набором изменений, для подготовки конфигурации этапов, которые мы отнесли к сложной группе, был написан генератор и среда актуальных исходных данных, которая обновляется после успешного проведения этапа и служит отправной точкой при подготовке конфигурации следующего.
На предпоследнем этапе, когда требовалось только зачистить часть старой конфигурации, мы столкнулись с незапланированным перерывом сервиса буквально из-за нескольких «детских» ошибок синтаксического характера в наборе исполняемых команд, которые под этот этап писали вручную. Мы быстро исправили ошибки, так что даже уложились в отведенное окно проведения работ, и извлекли для себя, как мне кажется, полезный вывод — если вы можете автоматизировать наполнение тех или иных блоков конфигурации применяя шаблоны, делайте это как можно чаще. В больших задачах это снижает вероятность ошибки, а в рутинных операциях позволяет экономить время. На выходе вы получите унифицированную конфигурацию, которую легко эксплуатировать, с минимальными затратами своего времени.
В идеальном мире я не смог бы придумать причин, по которым сетевым инженерам полезен опыт программирования, однако реальный мир и наши представления о нем часто не совпадают. Многим сетевым инженерам может показаться знакомой ситуация, когда что-то на сети должно было быть настроено определенным образом, но, по каким-то причинам, или по ошибке настроено по-иному – на клиентском интерфейсе не прописан STP фильтр или подавление широковещательного трафика, отсутствуют какие-то секции в CoPP фильтре, несоответствие типа BGP префикса присвоенным community, пропущенный MTU на backbone интерфейсе, и так далее. Список боли можно продолжать очень долго, поэтому конфигурацию сервисов и компонентов живой сети нужно периодически валидировать на предмет соответствия установленным шаблонам и требуемым наборам параметров. Перед валидацией вам придется произвести типизацию элементов конфигурации, это уже само по себе большая и полезная работа. Разложите элементы конфигурации на множества, а множества на подмножества, присвоив каждому из них требуемый шаблон и требуемый набор свойств. Например, порт коммутатора может принадлежать множеству клиентских портов или, в случае использоваться ERPS, быть транзитным в рамках одного или множества колец. Для типизации я обычно применяю поле description, у портов, например, оно может иметь следующий вид: id/type/speed/phb/mon_s/mon_b/remote,
- Id – например client1
- type может приниматься следующие значения: CUST2 – клиенты с услугой второго уровня, CUST3 – клиенты с услугой третьего уровня, BB – магистральные MPLS порты третьего уровня, AG – MPLS порты к устройствам агрегации, AC — MPLS порты к устройствам доступа, BR – магистральные порты второго уровня, TR – транзитные порты третьего уровня и т.д.
- speed – фактическая или контрактная полосы.
- php – тип классификации, перекраски и обработки QOS PHB.
- mon_s – тип реакции на аварийную индикацию смены NOC или системы мониторинга.
- mon_b — тип локальной реакции устройства на аварийную ситуацию.
- remote – идентификатор ответного оборудования и порта.
Если же вы типизируете BGP группы хорошим началом может послужить наполнение, которое определяет принадлежность группы к одному из множеств: UP – для вышестоящих операторов, DN – для клиентов, PR – для точек обмена или PPR – для приватных стыков, IAS – для Inter-AS стыков. Каждую из этих групп в свою очередь можно типизировать по требуемому набору передаваемых или получаемых префиксов.
Для эксплуатации полезно типизировать также:
- RSVP пути – резервируемый/нет, сигнализация/данные, основной/резервный, с полосой или без, внутри или меж областной.
- псевдопровода — Ethernet/TDM, со SLA или без, широко или узко полостные, с резервом или без.
- экземпляры VPLS или VPN – служебные или клиентские, со SLA или без, широко или узко полостные.
Как я уже писал типизацию нужно рассматривать не только как необходимое условие для проведения валидации, но и как отдельный процесс получения формального описания объектов вашей сети, который будет полезен для планирования выполняемых работ, оценки рисков и определения уровня важности того или иного события. Приятно, когда смена NOC, обнаружив в пол четвертого утра аварийную индикацию на RSVP пути с резервированием, присваивает этому инциденту соответствующий уровень реакции, вместо того чтобы будить сетевых инженеров второго уровня поддержки.
В зависимости от задач список и правила типизации могут меняться в очень широких пределах, отнеситесь к этому процессу со всей серьезностью чтобы на этапе валидации конфигураций ваши правила проверки были простыми, а шаблоны – лишены избыточности и пересечений между собой. Я рекомендую не оставлять белых пятен или исключений из правил типизации, в данном случае лучше работать по правилу «все или ничего». Если находятся исключения, сделайте из них правила, так чтобы можно было разбить множество объектов с индивидуальными особенностями на несколько множеств элементов с унифицированными характеристиками. Например, если стыки с CE у вас на сети могут быть как Active-Active, так и Active-Backup, отразите это в виде отдельных типов.
Написание процедур валидации очень сильно связанно с синтаксисом представления конфигурационных блоков производителей эксплуатируемого оборудования. Если операционная система вашего оборудования позволяет представать конфигурацию в виде XML или JSON, дальше говорить особенно не о чем, так как проверять поля этих форматов одно удовольствие. Но даже если конфигурационные блоки вашего производителя имеют чуть менее формальный вид не спешите отказывать от этой затеи. Хорошим подспорьем в этой работе служит CLI References и Command Guide, в которых обозначены не только обязательные или опциональные параметры конфигурационных блоков, но и точная последовательность и взаимосвязь используемых лексем. Например, следующая команда для маршрутизаторов Huawei
mpls rsvp-te timer retransmission { increment-value increment | retransmit-value interval } *
соответствует шаблону { x | y |… }*, который подразумевает один или несколько опциональных аргументов. Я советую не полагаться на память, когда вы пишете код валидатора, просто держите открытой страницу с описанием нужной команды для актуальной версии программного обеспечения вашего оборудования.
Для себя я обозначил два подхода к разбору конфигурационных файлов, в простых случаях логично использовать регулярные выражения в сочетании со словарем лексем производителя. Это не очень гибкий подход с почти нулевой переносимостью, зато такие виды проверок реализуются довольно просто. Для более глубокого анализа или для задач переноса конфигурации на оборудование другого производителя, я предлагаю рассмотреть конфигурационный файл как дерево, элементы которого связаны отношением родитель-ребенок, в такой структуре данных можно довольно легко организовывать поиск и выборки по различным условиям.
Полезно если процедура типизации будет не только сообщать об ошибках, пропущенных или лишних командах, но и обозначать места конфигурации, тип которых не удалось распознать. Это поможет через несколько циклов работы избавиться от белых пятен и привести конфигурацию сетевого оборудования к унифицированному виду. Не спешите устранять найденные ошибки прямо из валидатора, как показывает мой опыт внедрения систем проверки конфигурации, необходимо некоторое время поддерживать обратную связь между результатами работы валидатора и классификацией объектов сети. Неточности возможны, поэтому до определенного момента я советую внимательно следить за результатами работы и вносить соответствующие коррективы. Я также советую уделить особенное внимание сценариям автоматической правки конфигурации по итогам найденных ошибок, внимательно следите за последовательностью сгенерированных команд, чтобы эта последовательность не зависела от порядка выполнения процедур проверки, это особенно актуально в многопоточных средах. Тривиальным примером подобной несогласованности является добавление недостающего номера VLAN на порт до его объявления в глобальной таблице. По-хорошему, после выполнения каждой команды необходимо проверять ответ интерпретатора, такая практика минимизирует вероятность применения половинчатой конфигурации, наподобие объявления BGP соседа с отсутствующей политикой экспорта префиксов и тому подобное.
Но не конфигурацией единой занят сетевой инженер, иногда необходимо взглянуть на сеть, что называется, сверху. Хорошим подспорьем в этом деле послужит теория графов и алгоритмы на них. Начальные знания в этой области позволяют находить замкнутые и разомкнутые кольца в вашей сети, оценить меру связности кластеров или групп устройств, прогнозировать сценарии частичных сбоев, определять границы доменов отказа и риска, а также решать другие задачи аналитические и творческие задачи.
Автор: Андрей Анреев
