Проверка рабочего состояния сети (Часть 2)

В предыдущей части блога мы рассмотрели подход, который позволяет быстро и точно задавать конфигурационное состояние сети. Но, как отмечено в конце статьи, конфигурационное состояние определяет лишь желаемое состояние сети, и корректное задание конфигурационного состояния не является достаточным условием для достижения желаемого состояния. Пример: конфигурация протокола маршрутизации задана верно, но соседство не устанавливается из-за состояния «link down» сетевого интерфейса. Как проверить, что сеть находится в требуемом состоянии? Рассмотрим вопрос в этой статье.

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

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

• Легко допустить недосмотр при проверке
• Если проверяемых устройств много, проверка может ограничиваться некой выборкой в предположении, что все устройства настроены и функционируют однотипно
• Проверка производится единожды (непосредственно после настройки), хотя при вводе в действие новых сервисов в будущем проверку стоило бы повторить, чтобы убедиться, что новые сервисы «не поломали» уже настроенные

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

После определения условий, процедура тестирования рабочего состояния может выглядеть так: рабочее состояние при помощи сценария запрашивается из устройств, полученная информация пропускается через набор условий, после чего генерируется отчет о том, выполнены условия или нет. Для проверки рабочего состояния протокола BGP можно, например, выполнить такой набор тестов:

• статус соседств «up»?
• количество полученных префиксов от соседа > 0?
• установлены ли маршруты, полученные по BGP в таблицу маршрутизации?
• есть ли для каждого маршрута, полученного по BGP, избыточный в таблице маршрутизации?

Данную идею мы реализовали для нужд одного из наших проектов средствами Ansible. На выходе, если все в порядке, сценарий выводил:

Или, если есть проблемы (в данном случае маршрут к 0.0.0.0/0 в таблице маршрутизации всего один, избыточности нет):

Этот и другие сценарии тестирования смотрите в нашем GitHub.

Стоит отметить, что автоматизированное выполнение тестов позволяет не только быстро и точно контролировать рабочее состояние сети, но открывает дополнительные возможности для внесения изменений в сеть:

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

Мы затронули лишь один вопрос процесса управления сетью. Возможно, внимания заслуживают какие-то другие этапы процесса изменения состояния сети, как, например, проверки дизайна решения до ввода решения в действие? Оставляйте ваши комментарии.