Ровнов Павел...2019/12/20 · 4 Способы задать состояние сети •Задание конфигурации сети •Изменение рабочего

Некоторые вопросы автоматизации сетей

передачи данных

ООО «Солидекс»

Ровнов Павел

20 декабря 2019 года

2

Содержание

• Пролог

• Задание состояния сети

• Тестирование корректности конфигурационных файлов

• Поддержание сети в заданном состоянии

3

Вопросы, рассматриваемые в презентации

• Как создать нужную вам сеть

• Как поддерживать сеть в заданном состоянии

4

Способы задать состояние сети

• Задание конфигурации сети

• Изменение рабочего состояния: операционные команды,

например, «ifdown eth0», «reboot»

• Взаимодействие с Control Plane (например, BGP)

• Программирование RIB, FIB (например, OpenFlow)

5

• Задание конфигурации сети

– Интерактивный ввод команд в CLI, TCL, Expect

– Шаблоны конфигурационных файлов

– “Network as Сode”

• Изменение рабочего состояния: операционные команды,

например, «ifdown eth0», «reboot»

• …

Способы задать состояние сети

6

Модель жизненного цикла сети

Обследование

Формирование требований к

системе

Разработка ТЗ

Разработка технического

решения

Проверка решения (PoC)

Создание и загрузка конф.

файлов*

Проверка состояния сети

Проверка соответствия ТЗ

(ПиМ)

* См. Семинар-2018

Эксплуатация

7

Факторы усложнения сетей

• Число приложений, типы генерируемого трафика

• Увеличение количества устройств в сети

• Усложнение Control plane

• «Технический долг»

• Увеличение степени непредсказуемости поведения сети

как результат Configuration drift

• Требования безопасности

8

Модель жизненного цикла сети

Конфигурационные файлы Схемы, таблицы Функционирующая сеть



системе



решения



файлов*



(ПиМ)


9

Задачи разработки (Dev)

• Изучение и анализ текущего состояния сети

• Разработка технического решения: схем и таблиц

• Создание конфигурационных файлов из схем и таблиц

• Проверка состояния сети: синтаксис и семантика конфигов

Конфигурационные файлы Функционирующая сеть Схемы, таблицы

10

Задачи эксплуатации (Ops)

• Мониторинг заданного состояния

• Обнаружение, диагностика отказов, восстановление

работоспособности

Конфигурационные файлы Функционирующая сеть Схемы, таблицы

11

Риски Dev в условиях усложнения сетей

• Потеря уверенности в корректности изменений как

результат неудачных изменений

• Внесение изменений в согласованные «окна»

• Блокирование внесения изменений с целью обеспечить

работоспособность

12

Риски Ops в условиях усложнения сетей

• Непредвиденные перерывы в обслуживании

• Отсутствие понимания, что происходит в сети

• Увеличение времени диагностики и восстановления

работоспособности после отказов

13

• Разработка:

– Изменение состояния сети

– Придание сети свойств, которых изначально не было

• Эксплуатация:

– Поддержание заданного состояния

Dev+Ops

Эксплуатация Разработка

14

Dev+Ops vs. DevOps

Эксплуатация Разработка

Разработка+Эксплуатация

• Dev+Ops:

• DevOps:

15

Идеи

• Изменить подход связанный с поддержанием сети в

заданном состоянии с тем, чтобы была возможность

вносить изменения безопасным образом

• Снизить издержки и риски, связанные с потерями

работоспособности сети, автоматизировав диагностику и

восстановление после отказов

16


• Пролог


– Вопрос непротиворечивости и полноты информации о

сети

– Парадигмы задания конфигурации сети



17

Задача: перейти из состояния «А» в «Б»

Конфигурационные файлы Схемы, таблицы


А

А

А

А

Б

Б

Б

Б

18

Необходимые данные о состоянии «А»

• Имена устройств

• L1/L2 топология сети

• IP адреса интерфейсов

• Параметры протоколов маршрутизации

• Параметры сервисов DNS, NTP, Syslog

• ACL

• …

19

Критерии выбора источника информации

• Непротиворечивость данных

• Простота поддержания непротиворечивости данных

20

Конфигурационные файлы как источник данных

Б

Б

Б

Б


А

А

А

А

21

Пример одной организации

1.Выгрузка

2. Структурный

анализ 3. Создание новых

конфигураций

А

А

А

А

Б

Б

Б

Б

4. Загрузка

22

Оценка подхода

• Проблема установления взаимосвязи между параметрами

конфигураций и техническим решением

• Необходимость управления configuration drift вручную

• Необходимость структурного анализа конфигурационных

файлов

23

Подход SSoT (Single Source of Truth)



А

А

А

А

Б

Б

Б

Б

SSoT

SSoT

24

Подход SSoT (Single Source of Truth)



А

А

А

А

Б

Б

Б

Б

SSoT

SSoT

Python

Python

Ш

Шаблон

25

Критерии выбора источника информации

• Непротиворечивость данных

• Простота поддержания непротиворечивости данных

Дополнительное требование:

• Пригодность к автоматизации

26

Варианты реализации SSoT

• Файлы YAML (пример: Ansible)

• Инструменты DCIM, IPAM

DCIM = Data Center Infrastructure Management

IPAM = IP Address Management

27

DCIM/PAM

• Инструменты:

– Netbox (github.com/netbox-community/netbox)

– NSoT (github.com/dropbox/nsot)



28

SSoT: Getting started

• Упростить конфигурацию сети

• Стандартизовать конфигурационные файлы

• Отделить ключевые параметры (информация SSoT) от

представления (шаблон конфигурационного файла)

• Автоматизировать создание конфигурационных файлов

Конфигурационные

файлы Б

Б

Б

Б

SSoT

Ш

Шаблон

Python

29

Бонусы SSoT

• Упрощается отслеживание изменений

• Документирование сети

• Возможность идентификации изменений, внесенных

вручную

• Упрощается проверка конфигураций устройств сети на

предмет соответствия стандартам



30

Демо

• Задача: настройка коммутаторов 10G для

лаборатории

• Netbox:

– Имена устройств и их management IP

– Роли: “leaf”, “spine”

– BGP router id, ASN

• Создание и загрузка конфигураций: Ansible

(inventory plugin: netbox)

31


• Пролог


– Вопрос непротиворечивости и полноты информации о

сети

– Парадигмы задания конфигурации сети



32

Требования к способу задания конфиг. файлов

• Поддержка SSoT в качестве источника информации о сети

• Ограничить, где это возможно, участие оператора

33

Парадигмы задания конфигурационных файлов

• Интерактивный ввод команд в CLI, TCL, Expect

• Шаблоны конфигурационных файлов

• “Network as Сode”

34

Парадигма шаблонов конфигурационных файлов

• Синтаксис конфигурационных файлов на выходе – CLI

• Роль шаблона: подстановка информации SSoT в конфиг,

выполнение простейшей логики (прим.: ветвление, циклы)

• Пример: Jinja2

Конфигурационные

файлы

Б

Б

Б

Б

SSoT

Ш

Шаблон

Python

35

Пример решения

• Задача: ввод в действие 150 площадок сети

• Создание конфигов:

– SSoT: YAML

– Шаблоны Jinja2

• Загрузка конфигов:

– Ansible/NAPALM

36

Использование шаблона Jinja2 на примере

37

Оценка решения

• Взаимодействие с устройством через терминал как

следствие использования синтаксиса CLI:

– Проблема порядка команд

– Проблема сверки текущего и загружаемого

набора команд

• Свой набор шаблонов для каждой сетевой ОС

38

Парадигма «Network as Code»

• Использование API для программирования устройств, что

предполагает формирование и обмен структурированными

данными (например, JSON, XML)

• Использование SSoT

• Git как система контроля версий

39

Модели YANG

• YANG – язык моделирования конфигураций и

состояния сетевых элементов (RFC 6020, RFC 7950)

• YANG модель – описание сетевого элемента

40

Источник: https://medium.com/@k.okasha/yang-and-road-to-a-model-driven-network-

e9e52d47148d

Сравнение подходов: CLI vs. YANG

CLI

YANG

41

Пример: сетевой интерфейс (YANG/OC*/XML)

<interfaces xmlns="http://openconfig.net/yang/interfaces">

<interface>

<name>ge-0/0/2</name>

<subinterfaces>

<subinterface>

<index>0</index>

<config>

<description>Primary public IP address</description>

</config>

<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">

<addresses>

<address>

<ip>192.168.12.1</ip>

<config>

<ip>192.168.12.1</ip>

<prefix-length>24</prefix-length>

</config>

</address>

</addresses>

</ipv4>

</subinterface>

</subinterfaces>

</interface>

</interfaces> * OpenConfig

42

Источники YANG-моделей

• Организации стандартизации:

– IETF

– IEEE

• Рабочие группы, например:

OpenConfig

• Производители оборудования

43

Модели данных OpenConfig

44

Демо

• Задача: обеспечение связности

между маршрутизаторами

(настройка IP интерфейсов)

• Модель:

– Источник: OpenConfig

– Кодирование: XML

• Механизм создания: Jinja2 (Ansible) Cisco

CSR1000V

Juniper vMX

45

Создание конфигураций на Python

• Примеры YANG

DevKit:

– pyangbind

– ydk-py

46

Задание конфигурации интерфейса (ydk-py)

47

Демо

• Задача: обеспечение связности

между маршрутизаторами

(настройка IP интерфейсов)

• Модель:

– Источник: OpenConfig

– Кодирование: XML

• Механизм создания: ydk-py Cisco

CSR1000V

Juniper vMX

48

Создание OC/XML без написания кода

• yaml_to_ydk (https://github.com/networkop/yang)

YAML

Python,

yaml_to_ydk

Python,

ydk

OC/XML

Python

49

Нюансы YANG

• Поддержка источников и типов моделей со стороны

производителя

• Различия в версиях одной и той же YANG модели

• Функции и их реализации, к примеру настройка IP

интерфейса:

– Routed interface: interface > subinterface > IP

– BVI/SVI: vlan > routed vlan > IP

BVI = Bridge Group Virtual Interface

SVI = Switch VLAN Interface

50

Перспективы использования YANG

• Модели сервисов

51


• Пролог




52

Тестирование после ввода в действие

Конфигурационные файлы Схемы, таблицы Функционирующая сеть



системе



решения



файлов



(ПиМ)


53

Пример тестирования (1)

• Проект: ввод в действие Security Gateway

• Перечень проверок:

– Настройки IP интерфейсов

– Доступность next-hop устройств

– BGP: установление соседства, получение префиксов

54


• Перечень проверок:

– IP связность с точки зрения тестового клиента

– ААА и динамическое назначение сервисов

– Административный доступ: учетные записи и ACL

– Регистрация сообщений об установленных соединениях

и отправка сообщений в Syslog-сервер

– …другие проверки

55


• Инструмент: Ansible (мод. fortiosconfig, napalm_get_facts)

56

Тестирование до ввода в действие

Цели:

• Проверка синтаксиса: выявить ошибки, опечатки

• Проверка семантики: работоспособности конфигурации,

влияния изменений на существующие сервисы



системе



решения



файлов



(ПиМ)


57

Что можно протестировать?

• Сервисы по отдельности (unit-тесты)

– Пример: проверка что интерфейс добавлен в процесс

OSPF, OSPF-соседство установлено

• Функциональное тестирование (end-to-end)

– Пример: проверка доступности веб-сервера с точки

зрения пользователя

• Поведение сети при введении возмущений: сценарии

“если …, то …”

58

Способы тестирования

• Текстовый анализ

• Эмуляция

• Моделирование

59

Текстовый анализ

• Проверка синтаксиса

• Проверка наличия и значения параметра в

конфигурационном файле

hostname egde-rtr1

!

!

ip name-server 192.168.1.100

60

Эмуляция

• Создание копии сети в виртуальной среде

• Выполнение тестов:

– Состояние конфигурационного файла в устройстве

– Unit-тесты

– Функциональное тестирование

– Введение отказов и проверка состояния сети

61

Моделирование

• Создание математической копии сети, например, по

конфигурационным файлам

• Выполнение тестов (в зависимости от возможностей среды

моделирования):

– Непротиворечивость конфигурационных файлов

– IP связность, пути прохождения трафика

– Проверка корректности ACL, политик FW

– Моделирование отказов

Batfish

62

Сравнение способов тестирования

• Текстовый анализ

• Эмуляция


Источник: https://www.intentionet.com/blog/the-what-when-and-how-of-network-validation/

63

Тестирование до ввода в действие

• Процедуры:

– Тестирование состояния сети при изменениях (CI)

– Загрузка конфигурационных файлов (CD/CD)


– Git

– GitLab

– VirtualBox, Vagrant

– Ansible

– Behave

64

Continuous Integration

• Автоматическое поднятие тестовой среды при

обнаружении изменений (git)

• Выполнение тестов

• Подготовка к переносу кода в рабочую среду

65

Continuous Delivery

• Публикация нового состояния сети:

– Исходных данных для настройки (SSoT)

– Кода, шаблонов для создания конф. файлов устройств

– Сценариев управления состоянием сети

66

Continuous Deployment

• Загрузить новые конфигурационные файлы в устройства

67

Инструменты CI*

* Один из вариантов

68

Git

• Хранение конфигурационных файлов

• Контроль версий

• Управление ветками (пример: test, dev-ipv6, prod)

• Документирование изменений

69

GitLab

• Запуск тестов удаленно: GitLab Runner

• Выполнение тестов: проверка синтаксиса (yamllint)

• GUI

• Оповещение о событиях (email)

70

VirtualBox, Vagrant

• VirtualBox: гипервизор

• Vagrant: оркестровка среды тестирования

– Создание, запуск, разрушение VM

– Построение L1/L2 сетевой топологии

71

Ansible

• Загрузка конфигурационных файлов в устройства

• Получение данных о состоянии конфигурационных

файлов, рабочем состоянии устройств для целей тестов

72

Behave

Выполнение сценариев проверки:

• Описание сценариев

• Запуск

• Контроль результатов

73

Демо

• Задача: добавление нового сервера в

лабораторию


74

Усиление тестов с Batfish

Batfish

Факторы:

• Полнота тестов

• Ресурсы, требуемые для выполнения тестов

• Скорость выполнения тестов

75

Демо

• Задача: построение BGP фабрики ЦОД


Batfish

76

Другие инструменты

• Среда для эмуляции:

– EveNG

– vrnetlab

– OpenStack

• CI

– Drone CI

• Управление сценариями

проверок:

– Robot framework

• Тестирование :

– pytest

– pyATS

77

Вопрос топологии (предстоит рассмотреть)

Создание файла сетевой топологии для целей тестов:

• Эмуляция:

– Netbox → vagrant_net* →Vagrantfile

– Netbox → ? → Dot → Cumulus Topology Converter →

Vagrantfile

• Моделирование:

– Netbox → ? → Batfish layer1-topology.json

* github.com/malbertus/vagrant_net

78


• Пролог




79

Задачи

• Мониторинг состояния сети, обнаружение отказов,

диагностика, восстановление работоспособности

• Управление трафиком (traffic engineering)

• Планирование: определение доступной емкости

• Задачи безопасности (напр., Anti-DDoS)

80

Источники сведений о состоянии сети

• Метрики:

– SNMP query

– SSH, выполнение команд на устройстве

• События: SNMP trap

• Лог сообщения: Syslog

• Потоки: Netflow/Sflow

81

SNMP: время оповещения о событии

Факторы:

• SNMP trap: ненадежность доставки

• SNMP query/SSH exec

– Какой интервал опроса устройства?

– Как быстро устройство сможет отдать

информацию?

82

SNMP: точность информации

Источник: https://pc.nanog.org/static/published/meetings/NANOG73/1677/

20180625_Shakir_Snmp_Is_Dead_v1.pdf

83

Streaming Telemetry

• Данные о состоянии, примеры: загрузка CPU, счетчики

интерфейсов Tx/Rx, LLDP соседи, состояние таблицы RIB

• Отправка по интервалу или при изменении состояния

• Структурированные, нормализованные данные,

например, YANG/OpenConfig

84

Streaming Telemetry vs. SNMP

• Посекундная отправка данных

• Человекочитаемые схемы

данных

• Задействует меньше ресурсов

устройства

• Надежная доставка, если TCP-

транспорт

85

Структура протоколов ST


данных

• Кодирование

• Транспорт

GPB = Google Protocol Buffers

gRPC = Google RPC

Native

• YANG/?

• JSON, GPB,

XML

• UDP

gRPC

• YANG/

OpenConfig

• GPB

• UDP

sFlow

• sFlow

struct.

• XDR

RFC4506

• UDP

Альтернативный

вариант

86

gNMI

• gNMI – gRPC Network Management Interface

• Решаемые задачи:

– Конфигурирование (альтернатива NETCONF/RESTCONF)

– Сбор телеметрии

– Управление рабочим состоянием устройства: команды

ping, reboot, clear ip bgp, …

87

Структура решения OpenConfig

88

Инструменты

• Сбор сведений: Telegraf

• Хранение: InfluxDB

• Аналитика (выявление отказов): Kapacitor

• Формирование реакции: StackStorm

• Управление устройствами: Ansible

• Уведомление: Slack

89

Демо

• Задача: обнаружение отказов и

восстановление требуемого

состояния сетевого интерфейса без

участия оператора

• Сценарий восстановления:

– Проверка состояния

– Перезапуск

– Проверка состояния

– Уведомление оператора

90

Перспективы

• Предсказание отказов:

– На основе правил, созданных оператором

– На основе алгоритмов машинного обучения

(инструменты: Kapacitor+LoudML)

Вопросы?

Documents

Ровнов Павел...2019/12/20 · 4 Способы задать состояние сети •Задание конфигурации сети •Изменение рабочего