Как задавать и проверять конфигурационное состояние сети (часть 1)

09.09.2019 | Ровнов Павел
Want create site? Find Free WordPress Themes and plugins.

Я думаю, каждый, кто хоть раз вносил изменения в сеть, согласится, что большую часть времени отнимают не сами изменения, а поиск и устранение допущенных во время изменения ошибок конфигурации. В отдельных случаях работы по внесению изменений не удается завершить в назначенный срок и приходится откатываться в состояние до начала работ, после чего планировать новые работы и пытаться применять изменения вновь. Как можно быстро и точно вносить изменения в сеть? Как убедиться, что конфигурационные файлы сетевых элементов находятся в требуемом состоянии? Эти вопросы мы и обсудим в данной статье.

Сети, про которые пойдет речь, как правило, имеют две характерные черты:

  • Источником любых изменений в сети является оператор
  • Конфигурационные файлы формируются устройство за устройством через CLI или, альтернативно, графический интерфейс

Поскольку все этапы внесения изменений возложены на человека, неудивительно, что в процессе изменений допускаются ошибки, например, при создании набора команд или при «заталкивании» команд в устройство. И, что плохо, отдельные ошибки проявляют себя только лишь спустя время как это как-то раз и произошло.

Ситуация состояла в том, что конфигурация BGP для маршрутизаторов была выполнена частично. Сеть 10.1.1.0/24, в которой находились виртуальные машины, анонсировалась только маршрутизатором «А», но не маршрутизатором «Б».

В момент обновления ПО маршрутизаторов и перезагрузки маршрутизатора «А» сеть 10.1.1.0/24 прекращала анонсироваться, и с VM терялась связность.

В сетях, которые мы рассматриваем, есть две проблемы, для которых стоило бы поискать решение:

  • Возможность управления каждым из устройств по-отдельности провоцирует бессистемные изменения, и нет механизмов, которые позволяли бы такие изменения вычислить и устранить
  • Требуемое состояние конфигурационных файлов формально никак не выражено, из-за чего сверить текущее состояние конфигурации устройств (running config) с требуемым состоянием конфигурационных файлов невозможно

 

Идея альтернативного подхода к внесению изменений в сеть заключается в создании конфигурационных файлов устройств из файла-шаблона, который в свою очередь строится на основе модели сетевого устройства, включающей такие параметры как интерфейсы, адреса, протоколы маршрутизации, сервисы.

Рассмотрим реализацию подхода на примере сети, в которой требуется настроить протокол OSPF (требуемые команды приведены ниже).

На первом шаге упрощаем конфигурацию. В нашем случае можно без ущерба для логики конфигурационных файлов указать в качестве сетей, в которых запускается OSPF, общую сеть 10.0.0.0/8 вместо более специфичных сетей 10.0.ХХ.0/24.

На следующем шаге определим ключевые параметры конфигурационных файлов устройств, которые в дальнейшем будут использоваться как входные данные для файла-шаблона с тем, чтобы получить конфигурационный файл конкретного сетевого элемента. Общее правило выделения ключевых параметров состоит в следующем: чем больше параметров мы посчитаем ключевыми, тем больше гибкость решения, чем меньше, тем решение проще.

В нашем примере на вход файла-шаблона требуется подать лишь один параметр – Router ID (на рис. – id). Все другие параметры конфигурационных файлов сетевых элементов или вычисляются из этого параметра, или статически задаются в шаблоне конфигурационного файла сетевого элемента. Для записи ключевых параметров используется формат YAML. Для задания конфигурационных файлов оборудования используем шаблон Jinja2, который, важно, является единым для R1, R2 и R3.

На последнем шаге генерирование конфигурационных файлов устройств выполняется путем подстановки параметров из файла YAML в шаблон (например, средствами модуля template платформы Ansible).

Созданные конфигурационные файлы могут быть загружены в устройства, например, средствами модулей Ansible.

Что в итоге? Хотелось бы подчеркнуть основные результаты:

  • Задание шаблонов конфигурационных файлов позволяет существенно уменьшить тот набор параметров, на которые влияет оператор, тем самым снижая вероятность возникновения ошибок
  • Программное создание конфигурационных файлов устройств с одной стороны позволяет избежать ошибок, с другой стороны сократить время на создание конфигурационных файлов
  • В силу того, что конфигурационные файлы теперь создаются программно на основе шаблона, проверить, есть ли в текущем конфигурационном состоянии устройств какие-либо отклонения от требуемого состояния, не составит труда: достаточно выгрузить текущую конфигурацию устройства (running config) и сравнить ее с требуемым конфигурационным файлом, сгенерированным программно.

 

Мы рассмотрели один из шагов внесения изменений в сеть – задание конфигурационного состояния сети. Стоит отметить, что конфигурационное состояние определяет только лишь желаемое состояние сети, которое может и не достигаться. Приведу такой пример: конфигурация OSPF задана без ошибок, но OSPF соседство не устанавливается из-за сетевого интерфейса в состоянии «link down». При этом поведение сети, очевидно, будет отличаться от требуемого, хотя с точки зрения конфигурационного состояния проблем нет. О том, как проверить фактическое состояние сети и как парировать отклонения рабочего состояния от требуемого, мы обсудим в следующей статье.

Did you find apk for android? You can find new Free Android Games and apps.
Метки по теме:
NetOps Автоматизация
Комментариев пока нет
Добавить комментарий