Привет, я работаю инженером в КРОК, где у нас есть своя SD-WAN-лаборатория. И когда заказчик приходит с вопросами вроде «А вот у меня в сети сейчас всё работает так, а как это будет работать, если я захочу перейти на SD-WAN? И будет ли работать вообще?» мы можем быстро собрать нужную схему, оттестировать и показать.
На днях мы добавили в наш стенд Cisco средство аналитики от компании-партнёра LiveAction, которое сейчас вовсю тестируем. Почему для SD-WAN вообще нужно какое-то особое средство аналитики? Во-первых, маршрутизация в такой сети устроена намного сложнее, чем в традиционной сети и администратору важно видеть, что происходит с трафиком с учётом всего многообразия настроек. Во-вторых, SD-WAN-сеть – это про обеспечение качества работы приложений, а значит необходимо иметь средства анализа качества работы этих приложений.
Расскажу, как эти решения работают в паре и как все настроить.
Работа SD-WAN-сети Cisco, напомню, определяется набором компонентов управления:
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 (Стандартный Internet OID, добавляется в SNMP-шаблон в vManage):
Настроили отправку cFlowd с помощью политики vManage:
И получаем в LiveAction информацию о сети, например, вот в таком представлении:
Стрелки означают потоки трафика конкретных приложений. На каждую из них можно кликнуть и увидеть подробности по потокам трафика,
а также, при необходимости, сгенерировать кастомизируемый отчёт, например, вот такой по трафику между двумя площадками:
По клику на потоке трафика на диаграмме система умеет подтягивать с vManage политики, влияющие на него, опять же через API:
Ну а для того, чтобы увидеть, что по факту происходило с трафиком того или иного приложения в конкретный момент времени есть вот такая диаграмма:
Из неё можно увидеть, что, например, трафик FTP-Data из VRF 2 передавался с меткой DSCP 0 через транспорт с названием Private1. В нижней части доступен бегунок, позволяющий определить интересующий нас промежуток времени и кнопка «Play», чтобы посмотреть, как менялось поведение маршрутизатора во времени. Таким образом можно не только убедиться в том, что трафик того или иного приложения передавался так, как мы этого хотели, но и расследовать какие-то инциденты в работе сетевого приложения, имевшие место в прошлом. Например, если три дня назад с 12:00 до 12:30 у нас плохо работала видеоконференцсвязь, можно увидеть, что мы почему-то передавали её трафик не через тот канал и без нужной метки DSCP.
Можно вывести список потоков трафика между двумя площадками в виде таблицы:
А потом зайти в конкретный поток и посмотреть путь его прохождения вместе, скажем, с загрузкой интерфейсов, CPU и памяти устройств, участвовавших в передаче данных:
Таким образом, можно установить, например, что в момент передачи данных был перегружен один из интерфейсов или CPU одного из устройств.
Помимо веб-интерфейса у LiveAction есть инженерная консоль. Она позволяет увидеть потоки трафика даже в пределах одного устройства. Вот так, к примеру, выглядит маршрутизатор Cisco CSR1000v:
Для каждого устройства можно смотреть так называемый Historical Playback – то, как менялись потоки трафика во времени:
Для текущего мониторинга SD-WAN-сети в LiveAction доступны преднастроенные и кастомизируемые с помощью виджетов дашборды. Доступно около 30 различных виджетов, можно создавать свои. Вот пример готового дашборда для отслеживания производительности туннелей SD-WAN:
Для любого дашборда можно сделать постоянную ссылку и вывести его в контрастном виде на плазменную панель в NOC:
Наш опыт работы с решением Cisco SD-WAN показывает, что для его успешного тестирования и внедрения особенно важно понимать, какой именно трафик гуляет по сети, какими маршрутами и в каких объёмах. Традиционные сети фокусировались на connectivity – «соединить площадки A, B, C с ЦОД». Максимум, что можно было сделать для обеспечения качества работы конкретных приложений – это шейпинг трафика и распределение его по очередям QoS.
Задачу connectivity, кстати, SD-WAN решает быстрее и проще традиционных сетей, но главная его фишка – адаптация под требования сетевых приложений. Real-Time трафик мы можем перебрасывать с одного канала на другой, измеряя задержку и джиттер. Вот как это работает. На трафик, критичный к потерям – применяем коррекцию ошибок или передаем его одновременно по двум каналам, а тяжёлый и некритичный трафик – сгружаем на дешёвые каналы. Система аналитики как раз позволяет увидеть какие приложения передают трафик по сети и отнести их к тому или иному классу. Причём сделать это можно не только после внедрения SD-WAN, но и до, на этапе тестирования:
Тем, кто уже внедрил у себя решение SD-WAN от Cisco, система аналитики поможет:
LiveAction – классное, продвинутое решение, которое позволит выжать максимум производительности сети и наибольшую отдачу от инвестирование в такое капитальное решение, как SD-WAN. При этом, конечно, должен быть выстроен процесс эксплуатации сети с точки зрения менеджмента – система заявок, расследования причин возникающих проблем, планирование развития. Если инженеры, эксплуатирующие сеть, работают «по звонку» и хаотично тушат пожары, не факт, что она им поможет.
На днях мы добавили в наш стенд Cisco средство аналитики от компании-партнёра LiveAction, которое сейчас вовсю тестируем. Почему для SD-WAN вообще нужно какое-то особое средство аналитики? Во-первых, маршрутизация в такой сети устроена намного сложнее, чем в традиционной сети и администратору важно видеть, что происходит с трафиком с учётом всего многообразия настроек. Во-вторых, SD-WAN-сеть – это про обеспечение качества работы приложений, а значит необходимо иметь средства анализа качества работы этих приложений.
Расскажу, как эти решения работают в паре и как все настроить.
Принцип работы аналитики в SD-WAN
Работа SD-WAN-сети Cisco, напомню, определяется набором компонентов управления:
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 (Стандартный Internet OID, добавляется в SNMP-шаблон в vManage):
Настроили отправку cFlowd с помощью политики vManage:
И получаем в LiveAction информацию о сети, например, вот в таком представлении:
Стрелки означают потоки трафика конкретных приложений. На каждую из них можно кликнуть и увидеть подробности по потокам трафика,
а также, при необходимости, сгенерировать кастомизируемый отчёт, например, вот такой по трафику между двумя площадками:
Заглянуть поглубже
По клику на потоке трафика на диаграмме система умеет подтягивать с vManage политики, влияющие на него, опять же через API:
Ну а для того, чтобы увидеть, что по факту происходило с трафиком того или иного приложения в конкретный момент времени есть вот такая диаграмма:
Из неё можно увидеть, что, например, трафик FTP-Data из VRF 2 передавался с меткой DSCP 0 через транспорт с названием Private1. В нижней части доступен бегунок, позволяющий определить интересующий нас промежуток времени и кнопка «Play», чтобы посмотреть, как менялось поведение маршрутизатора во времени. Таким образом можно не только убедиться в том, что трафик того или иного приложения передавался так, как мы этого хотели, но и расследовать какие-то инциденты в работе сетевого приложения, имевшие место в прошлом. Например, если три дня назад с 12:00 до 12:30 у нас плохо работала видеоконференцсвязь, можно увидеть, что мы почему-то передавали её трафик не через тот канал и без нужной метки DSCP.
Можно вывести список потоков трафика между двумя площадками в виде таблицы:
А потом зайти в конкретный поток и посмотреть путь его прохождения вместе, скажем, с загрузкой интерфейсов, CPU и памяти устройств, участвовавших в передаче данных:
Таким образом, можно установить, например, что в момент передачи данных был перегружен один из интерфейсов или CPU одного из устройств.
И ещё глубже
Помимо веб-интерфейса у LiveAction есть инженерная консоль. Она позволяет увидеть потоки трафика даже в пределах одного устройства. Вот так, к примеру, выглядит маршрутизатор Cisco CSR1000v:
Для каждого устройства можно смотреть так называемый Historical Playback – то, как менялись потоки трафика во времени:
Дашборды
Для текущего мониторинга SD-WAN-сети в LiveAction доступны преднастроенные и кастомизируемые с помощью виджетов дашборды. Доступно около 30 различных виджетов, можно создавать свои. Вот пример готового дашборда для отслеживания производительности туннелей SD-WAN:
Для любого дашборда можно сделать постоянную ссылку и вывести его в контрастном виде на плазменную панель в NOC:
Чем полезен LiveAction на этапе тестирования
Наш опыт работы с решением Cisco SD-WAN показывает, что для его успешного тестирования и внедрения особенно важно понимать, какой именно трафик гуляет по сети, какими маршрутами и в каких объёмах. Традиционные сети фокусировались на connectivity – «соединить площадки A, B, C с ЦОД». Максимум, что можно было сделать для обеспечения качества работы конкретных приложений – это шейпинг трафика и распределение его по очередям QoS.
Задачу connectivity, кстати, SD-WAN решает быстрее и проще традиционных сетей, но главная его фишка – адаптация под требования сетевых приложений. Real-Time трафик мы можем перебрасывать с одного канала на другой, измеряя задержку и джиттер. Вот как это работает. На трафик, критичный к потерям – применяем коррекцию ошибок или передаем его одновременно по двум каналам, а тяжёлый и некритичный трафик – сгружаем на дешёвые каналы. Система аналитики как раз позволяет увидеть какие приложения передают трафик по сети и отнести их к тому или иному классу. Причём сделать это можно не только после внедрения SD-WAN, но и до, на этапе тестирования:
- Поставить LiveAction и собрать первичные данные с сети
- Выбрать для тестирования SD-WAN площадки, паттерн трафика на которых наиболее репрезентативен для текущего состояния сети
- Сделать предположения о том, какие политики повысят качество передачи данных
- Установить SD-WAN-маршрутизаторы и настроить в тестовом SD-WAN-сегменте политики, согласно предположению
- С помощью LiveAction проанализировать результаты работы и скорректировать политики. Увидеть самим и продемонстрировать заинтересованным лицам повышения качества передачи данных
- Получить готовую к развёртыванию на всю сеть конфигурацию SD-WAN.
Резюме. Польза от аналитики на уже работающей SD-WAN-сети
Тем, кто уже внедрил у себя решение SD-WAN от Cisco, система аналитики поможет:
- Проследить за тем, как операторы связи соблюдают SLA и какое вообще качество выдают на своих каналах связи;
- Увидеть проблемы в работе критичных приложений до того, как их пользователи начнут жаловаться;
- Корректно подстраивать сеть под работу новых приложений, которые внедряются;
- Быстрее находить ошибки в настройках, допущенные специалистами по эксплуатации сети;
- Понять, насколько лучше стала использоваться доступная пропускная способность каналов связи, а значит и оценить эффективность миграции на SD-WAN в деньгах.
LiveAction – классное, продвинутое решение, которое позволит выжать максимум производительности сети и наибольшую отдачу от инвестирование в такое капитальное решение, как SD-WAN. При этом, конечно, должен быть выстроен процесс эксплуатации сети с точки зрения менеджмента – система заявок, расследования причин возникающих проблем, планирование развития. Если инженеры, эксплуатирующие сеть, работают «по звонку» и хаотично тушат пожары, не факт, что она им поможет.
