Привет, я работаю инженером в КРОК, где у нас есть собственная лаборатория SD-WAN. А когда заказчик приходит с вопросами типа «А ведь в моей сети сейчас все работает так, а как она будет работать, если я захочу перейти на SD-WANЭ» И будет ли оно вообще работать? мы можем быстро собрать нужную схему, протестировать и показать.
На днях мы добавили на наш стенд Cisco инструмент аналитики от партнерской компании LiveAction, который сейчас вовсю тестируем.
Зачем SD-WAN вообще нужна специальная аналитика? Во-первых, маршрутизация в такой сети гораздо сложнее, чем в традиционной сети, и администратору важно видеть, что происходит с трафиком, учитывая все многообразие настроек.
Во-вторых, сеть SD-WAN — это обеспечение качества работы приложений, а значит, необходимо иметь инструменты для анализа качества работы этих приложений.
Расскажу, как эти решения работают в паре и как все настроить.
Как работает аналитика в SD-WAN
Напомню, что работа сети Cisco SD-WAN определяется набором компонентов управления: vManage управляет конфигурациями и собирает данные для мониторинга сети.vSmart распространяет информацию о маршрутизации и политики управления трафиком.
vBond связывает все компоненты решения вместе 
Маршрутизаторы SD-WAN получают информацию о маршрутизации, используя собственный протокол OMP. В традиционной сети маршрут всегда выглядит так: «сеть 192.168.4.0/24 доступна через шлюз X».
В случае с OMP все несколько необычно, например так: 
По сути, приведенный выше вывод означает, что «сеть 192.168.4.0/24 доступна через маршрутизатор с идентификатором 1.1.255.21, через два типа транспорта (MPLS и Private1), и передаваемый туда трафик должен быть упакован в IPSEC. Все эти навороты необходимы для обеспечения функциональности SD-WAN.
Помимо маршрутов существуют еще политики, определяющие выбор режима транспорта, например «Передавать голосовой трафик через MPLS; если MPLS не обеспечивает требуемого качества — переходите на LTE».
Так: 
Становится сложно понять, куда будет идти трафик конкретного приложения в конкретный момент времени.
Проверить, что именно мы настроили, можно с помощью инструмента Simulate Flows в vManage. 
Но кроме этого хотелось бы понять, как перемещался трафик этого приложения по сети за последнюю, скажем, неделю, с учетом того, что иногда падало качество каналов и менялись объемы трафика.
Стоило ли вообще отправлять этот трафик именно по этому пути или стоит пересмотреть политику? Именно здесь помогает такой инструмент аналитики, как LiveAction. LiveAction устанавливается как сервер или кластер серверов, интегрируется с vManage через API, получает оттуда список маршрутизаторов и данные их конфигурации, а затем опрашивает их по SNMP и получает данные через cFlowd (аналог NetFlow).
Интеграция
Связался с vManage через API:
Мы получили список устройств:
Разрешен доступ к ним по SNMP (Стандартный Интернет OID, добавленный в шаблон SNMP в vManage):
Настроил отправку cFlowd с использованием политики vManage:
И получаем информацию о сети в LiveAction, например, в таком виде:
Стрелки обозначают потоки трафика для конкретных приложений.
Вы можете нажать на каждый из них и просмотреть подробную информацию о транспортных потоках, 
а также, при необходимости, сформировать собственный отчет, например, по трафику между двумя сайтами: 
Смотри глубже
Нажав на поток трафика на диаграмме, система может получить влияющие на него политики из vManage, опять же через API:
Ну а для того, чтобы увидеть, что на самом деле произошло с трафиком конкретного приложения в конкретный момент времени, есть такая диаграмма:
Из него видно, что, например, трафик FTP-Data от VRF 2 передавался с меткой DSCP 0 через транспорт под названием Private1. Внизу есть ползунок, позволяющий определить интересующий нас период времени и кнопка «Играть», чтобы увидеть, как менялось поведение роутера с течением времени.
Таким образом, мы можем не только убедиться, что трафик конкретного приложения передавался так, как мы этого хотели, но и расследовать любые инциденты в работе сетевого приложения, произошедшие в прошлом.
Например, если три дня назад с 12:00 до 12:30 у нас плохо работала видеоконференция, то вы можете видеть, что по каким-то причинам мы передавали ее трафик не по тому каналу и без необходимого тега DSCP.
Вы можете отобразить список потоков трафика между двумя сайтами в виде таблицы: 
А затем зайти в конкретный поток и посмотреть, какой путь он проходит вместе, скажем, с загрузкой интерфейсов, ЦП и памяти устройств, участвующих в передаче данных: 
Таким образом можно установить, например, что в момент передачи данных был перегружен один из интерфейсов или процессор одного из устройств.
И еще глубже
Помимо веб-интерфейса, LiveAction имеет инженерную консоль.Это позволяет видеть потоки трафика даже внутри одного устройства.
Например, так выглядит маршрутизатор Cisco CSR1000v: 
Для каждого устройства можно просмотреть так называемое историческое воспроизведение — как менялись потоки трафика с течением времени: 
Панели мониторинга
Для постоянного мониторинга сети SD-WAN LiveAction предлагает предварительно настроенные информационные панели, которые можно настроить с помощью виджетов.Доступно около 30 различных виджетов, вы можете создавать свои собственные.
Вот пример готового дашборда для мониторинга работоспособности SD-WAN-туннелей: 
Для любого дашборда можно сделать постоянную ссылку и отображать ее на контрасте на плазменной панели в НОК: 
Чем LiveAction полезен на этапе тестирования
Наш опыт работы с решением Cisco SD-WAN показывает, что для его успешного тестирования и внедрения особенно важно понимать, какой трафик проходит через сеть, по каким маршрутам и в каких объемах.Традиционные сети ориентированы на возможность подключения – «соединение площадок A, B, C с центром обработки данных».
Максимум, что можно сделать для обеспечения качества работы конкретных приложений — это формирование трафика и распределение его по QoS-очередям.
Кстати, SD-WAN решает задачу подключения быстрее и проще, чем традиционные сети, но главная ее особенность — адаптация к требованиям сетевых приложений.
Мы можем передавать трафик в реальном времени с одного канала на другой, измеряя задержку и джиттер.
Вот как это работает. Для критичного к потерям трафика мы используем коррекцию ошибок или передаем его одновременно по двум каналам, а тяжелый и некритичный трафик выгружаем на дешевые каналы.
Система аналитики позволяет увидеть, какие приложения передают трафик по сети, и отнести их к тому или иному классу.
Причем сделать это можно не только после внедрения SD-WAN, но и до, на этапе тестирования:
- Установите LiveAction и соберите первичные данные из сети
- Выберите площадки для тестирования SD-WAN, структура трафика которых наиболее соответствует текущему состоянию сети.
- Сделайте предположения о том, какие политики улучшат качество передачи данных.
- Установите маршрутизаторы SD-WAN и настройте их в тестовом сегменте политики SD-WAN в соответствии с предположением.
- Используя LiveAction, анализируйте результаты работы и корректируйте политики.
Убедитесь сами и продемонстрируйте заинтересованным лицам, как улучшить качество передачи данных.
- Подготовьте конфигурацию SD-WAN для развертывания во всей сети.
Краткое содержание.
Воспользуйтесь преимуществами аналитики в уже работающей сети SD-WAN. Тем, кто уже внедрил решение SD-WAN от Cisco, система аналитики поможет:
- Контролировать, как операторы связи соблюдают SLA и какое качество они вообще обеспечивают на своих каналах связи;
- Увидеть проблемы в критических приложениях до того, как их пользователи начнут жаловаться;
- Корректно настроить сеть на работу внедряемых новых приложений;
- Быстро находить ошибки в настройках, допущенные специалистами по эксплуатации сети;
- Понять, насколько лучше используется доступная пропускная способность каналов связи, а значит, оценить эффективность перехода на SD-WAN в деньгах.
Если инженеры, эксплуатирующие сеть, работают «по вызову» и хаотично тушат пожары, не факт, что им это поможет. Теги: #информационная безопасность #Сетевые технологии #сетевое оборудование #it-инфраструктура #sd-wan #анализ трафика #мониторинг сети
-
Как Программисту Переехать В Нидерланды?
19 Oct, 24 -
Легче, Чем Кажется. Глава 12
19 Oct, 24 -
Бак Будет Работать Даже Зимой
19 Oct, 24
