Даже в хорошей с точки зрения проектирования сети время от времени необходимо проводить работы по обновлению конфигураций тех или иных сущностей.
Среди наиболее веских и ожидаемых причин такой активности — миграции для гармонизации физического и логического планов, развитие сетей как часть процесса технологической эволюции, гармонизация архитектур связанных сегментов и решение проблем роста.
Фактически жизненный цикл сети практически всегда представляет собой изменения с тем или иным уровнем рисков и предсказуемым влиянием на сервис, при оценке которых нельзя игнорировать человеческий фактор.
Хотя было бы вполне уместно обобщить это описание на большинство областей человеческой деятельности, функционирование сетей связи имеет некоторые особенности, заслуживающие понимания или хотя бы внимания – элементы сетей связи тесно связаны, тесно взаимодействуют и имеют не только непосредственное, но и косвенное влияние друг на друга.
Поэтому грамотная стратегия проводимой работы станет более продуктивной только в том случае, если будет подкреплена механизмами, максимально снижающими вероятность человеческих ошибок.
В следующей статье серии «Зачем сетевым инженерам нужно программированиеЭ» Я расскажу о вариантах использования автоматизации в одной задаче такого рода.
Во многих «учебниках» по сетевой архитектуре термины «крупномасштабные сети» и «иерархические сети» используются почти как синонимы; Применительно к устройству IGP-домена указана простая и, на первый взгляд, понятная конструкция – фрагментация домена на области.
При этом порог насыщения – вещь сугубо индивидуальная; в некоторых случаях в одной зоне IGP нормально могут сосуществовать тысяча современных маршрутизаторов, в противном случае достаточно трех сотен, чтобы существенно снизить характеристики производительности.
По большей части этот порог определяется протоколами, наложенными на IGP, поэтому в условиях некоторой вариативности и неопределенности границ и масштаба будущей сети «зубры» индустрии находят более гибкий способ построения плоский домен с последующей миграцией его сформировавшихся частей на отдельные участки.
Другими словами, если вы не можете «заглядывать в завтрашний день сегодня», постройте плоскую сеть и разделите ее при появлении первых признаков ухудшения времени сходимости или чрезмерной сложности эксплуатации, ведь отсутствие иерархии все же лучше, чем неправильно выбранная.
в условиях неопределенности структуры [1, 2, 3].
Достаточно общие описания и абстрактные примеры, предположим, что мы имеем дело с разросшейся областью домена OSPFv2, топология физических волокон/каналов которого уже позволяет различить границы будущих областей в аморфной структуре.
Я не сторонник менять что-то по принципу «все или ничего»; может случиться так, что из-за непредвиденных обстоятельств пространство возможностей станет слишком узким, а ожидаемые риски станут слишком большими.
Изменение области OSPFv2 — деструктивная операция, поэтому наиболее простой процесс миграции, заключающийся в последовательном переносе маршрутизаторов в новую область по пути от будущей границы вниз, удобен во всех топологиях.
К счастью, некоторое время назад в рекомендациях по развитию OSPF была обозначена возможность построения связности в рамках нескольких направлений [4].
Используя эту возможность, мы можем разбить миграцию на три этапа:
- Строительство дополнительных (вторичных) коммуникаций на новом участке
- Перевод новой зоны в основной режим, а старой в дополнительный
- Удаление подключения в старой области
При сохранении конгруэнтности топологий старой и новой областей мы получим согласованную маршрутизацию между транслируемыми и нетранслируемыми узлами, а это, в свою очередь, позволяет разделить этапы на независимые подэтапы, на каждом из которых работают можно сделать с определенной частью узлов.
К выбору узлов для работы в рамках подэтапа целесообразно подходить с точки зрения фактического использования каналов в конкретной сети, таким образом, чтобы не допустить перезагрузки на границе старой и новой областей.
Несмотря на то, что статья посвящена программированию, думаю, не будет лишним сказать несколько слов о поведении протоколов, наложенных на IGP, в условиях меняющихся областей.
ЛДП ведет себя вполне предсказуемо; плавная трансляция достигается за счет обеспечения IP-связности между транспортным адресом целевого и интерфейсного сеансов.
В связи с тем, что BGP — очень гибкий протокол, на эту плоскость стоит обратить пристальное внимание.
Хорошо, если на передаваемых узлах BGP не вносит особых вольностей в выбор пути в виде несогласованных изменений Local Preferences между узлами или других критериев, определяющих решение по локальной маршрутизации.
Другими словами, поведение BGP также предсказуемо, если выбор маршрута внутри области не противоречит правилу следования пути IGP. Есть тонкий момент, связанный с работой RSVP в период сосуществования двух областей.
Тот факт, что таблица TED заполняется из двух источников с разной наглядностью, дает пищу для размышлений; например, вы вполне можете потерять механизмы FRR, пока работа не будет завершена.
Это может произойти, если маршрутизаторы с более высокой видимостью, находящиеся в двух областях, считают ERO через маршрутизатор с меньшей видимостью, т. е.
через транслируемый сегмент сети без топологической информации о другой области.
Это нельзя назвать катастрофой, так как путь в конце концов, конечно, наладится, но забывать об этом не стоит. Особого мастерства требует совмещение работы по реализации иерархий IGP с аналогичной работой в плоскости BGP, например, миграция полносвязной сети на отражатели маршрутов.
Иерархии в разных плоскостях лучше реализовывать последовательно, то же самое, на мой взгляд, касается всего, что скрывает информацию о маршрутизации; проще построить суммирование на устойчивом фундаменте иерархической ИГП, чем объединить эти этапы.
Итак, у нас есть общий план, и если вы еще не передумали, давайте подумаем о программной реализации в Pyez, примерно так.
Каждый красивый овал может представлять собой отдельный программный объект, то есть нечто, выполняющее работу и подготавливающее данные для следующего шага.
Под исходными данными мы подразумеваем информацию из сети, например, для подготовки конфигурации новой области OSPF необходимо получить имена активных интерфейсов, принадлежащих старой области, и их веса, а значит, нам потребуются навыки в работа с таблицами операций и представлениями.
Познакомиться с этими понятиями вы можете в предыдущей статье серии.
«Программирование для сетевых инженеров: первый случай» .
На первом этапе генератор сохраняет в файлы команды, необходимые для активации новой области, на втором – для удаления старой и перевода новой в основной режим, на третьем – команды для удаления старой области.
Забегая вперед, скажу, что для этой статьи я сознательно не использую шаблонные визуализаторы типа Jinja2. Чтобы не отвлекаться от целевой темы, код пишется максимально просто.
Если кого-то заинтересует документация, перейдите по ссылке.
Код генерации конфигурации этапа
Теги: #Сетевые технологии #программирование #миграция #ИТ-инфраструктура #Системное администрирование #автоматизация #ospf #juniper #juniper #сетевое проектирование #python pyezimport sys import yaml from jnpr.junos.factory.factory_loader import FactoryLoader from jnpr.junos import Device def getConnection(p_host, p_user):
-
Задачи Хорошего Системного Инженера
19 Oct, 24 -
Очередная Шутка От Google
19 Oct, 24 -
Веб-Оповещения В Загруженных Проектах
19 Oct, 24
