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

Хотим оставить подобные истории на уровне баек из курилки, поэтому стали перебирать решения и пришли к идее, что пора осваивать программно-определяемые сети (SD-WAN). Для этого мы обратились к оборудованию, которое хорошо знаем по другим проектам: взяли сетевые экраны Fortinet c поддержкой SD-WAN и протестировали на них несколько популярных запросов от клиентов. Посмотрели, как можно разворачивать распределенную сеть и управлять ею через общий веб-интерфейс, и расписали результаты тестов и наше мнение о возможностях этого оборудования.

Зачем вообще нужна программно-определяемая сеть

Концепция SD-WAN началась с идеи сделать контроль удалённых сетей проще и получить возможность управлять (в т. ч. автоматически) передачей данных в любой точке планеты. Идея подразумевает также удалённую настройку сетевых устройств через облачную среду или управляющее устройство: вместо десяти умных и мощных роутеров используем десять slave-устройств, управляемых из единого центра.
Такая идея красиво и просто звучит на уровне буклетов, но мы работаем сразу с несколькими производителями (Cisco, Fortinet, Huawei, Versa Networks, VMware) и видим, что концепцию SD-WAN каждый бренд трактует и реализует по-своему. Из-за этого нельзя объединять оборудование разных производителей, а у каждой реализации есть свои особенности, о которых нужно знать до того, как придётся всё исправлять.
В последнее время основное требование у наших клиентов 一 это безопасность. В таких случаях мы часто используем FortiGate'ы. Их фишка — отслеживание несанкционированной активности внутри сети, управление трафиком отдельных приложений и гибкое создание правил, за что его и любят безопасники. Добавим сюда сетевые правила SD-WAN (это будет выглядеть максимально естественно) и получим очень любопытное решение.

Собираем стенд для SD-WAN

Работа с любым вендором начинается со стенда: во-первых, это интересно, во-вторых — позволяет избежать ситуации, когда посреди казахских степей обнаруживается, что какая-то важная функция не работает.
Для теста мы взяли:
И к ним виртуальные машины
    • FortiManager, FMG-VM-Base.
    • FortiGate (виртуальные), FG-VM02.
    И стали собирать. На выходе у нас получилась такая схема:
    Мы смоделировали сеть, связывающую головной офис и два удалённых филиала. Они соединены через два виртуальных ISP, характеристики подключения которых мы можем менять. Одна линия эмулирует подключение филиала к публичному интернету, а другая — к каналу VPN. Это означает, что у нас две разные WAN-среды подключения к двум разным провайдерам (ISP). А где есть разделение на две сети в одной подсети — там и разделение на две разных политики работы.

    [Кейс 1] Запускаем сеть без предварительной настройки оборудования

    Представьте, что далеко в горах в полузаброшенном отеле «Оверлук» вам нужно развернуть сеть, на которой будут работать видеонаблюдение, телефония, несколько кассовых аппаратов и много чего ещё. Сеть нужна «ещё вчера», а таких точек много. Всё осложняется тем, что разумной жизни (хотя бы уровня CCNA) рядом нет.
    Тут важны скорость и удобство развёртывания, поэтому нас будет интересовать, как у Fortinet реализуется функция ZTP (Zero Touch Provisioning). Она позволяет добавить оборудование в систему и настроить по серийному номеру, а созданная конфигурация автоматически загрузится при первом подключении к сети. Устройство само найдёт сервер управления, подключится и скачает настройки.
    Оборудование готово к дальнейшим настройкам: централизованному обновлению ПО, установке политик безопасности и шаблонов конфигураций. Альтернативой ZTP является использование для загрузки стартовой конфигурации USB-флешек, — это не так удобно, как ZTP, но подойдёт в случаях, когда со стороны провайдеров нет поддержки автоматической конфигурации внешних интерфейсов. В любом случае это удобнее, чем ехать на объект и настраивать всё руками.

    [Кейс 2] Включаем защиту от потерь данных

    Продолжаем наш штурм гор: объект доступен, теперь нужно минимизировать потерю данных между ним и центральным офисом. У Fortinet для таких случаев есть механизм FEC (Forward Error Correction), позволяющий добавлять к передаваемым пакетам некоторое количество избыточных, что даёт возможность восстановить на принимающей стороне потерянные. Альтернативный вариант: механизм DUP, при котором трафик передаётся по основному каналу и дублируется по одному или сразу нескольким резервным.
    В качестве тестовой передачи запустим (и примем) трансляцию видеоролика с использованием VLC media player. Транслировать будем с тестовой рабочей станции в центральном офисе в сторону удалённого офиса. Трафик будет отправляться в режиме unicast по протоколу UDP. Потери на канале будем вносить с использованием ПО WANem.
    В этот раз:
    • Посмотрим эффект от FEC. Тест будем считать пройденным, если получим приемлемое качество работы при нестабильном канале. Параллельно проверим, появился ли адаптивный FEC (мечтать не вредно), какой максимальный процент потерь (и джиттер) может скорректировать FEC.
    • Проверим, как отображается картинка ролика. Изучим размер избыточности трафика, который при этом возникает, а также узнаем, соответствуют ли теоретические расчёты результатам на практике.
    • Рассчитаем нагрузку на CPU/ASIC оборудования, проведём тест на DUP (дупликацию), проверим возможность нормальной работы на двух плохих каналах.
    Ну и в конце сравним, что выгоднее использовать — FEC или DUP.
    Очевидный минус этой функции — пропускная способность канала, которой мы будем с FEC стабильно жертвовать ради передачи избыточных пакетов. Попытка найти настройки адаптивного FEC в интерфейсе провалилась, но это неудивительно. Увидеть реализацию такой функциональности на практике нам пока не доводилось.
    В целом можно подбирать параметры (fec-base, fec-redundant) в зависимости от значения текущих потерь на канале и целевых, т. е. тех, которые нас устроят. Существуют готовые скрипты для расчётов (требуется знание китайского). В нашем случае использовались параметры fec-base=20, fec-redundant=6 и до 1% исходных потерь на канале. При такой конфигурации мы получаем менее 0,0001% целевых потерь при избыточной загрузке канала от 30 до 40%.
    Механизм дупликации пакетов DUP в каком-то смысле может быть альтернативой FEC. При его настройке не требуется переустановление туннелей, т. к. данные настройки выполняются в конфигурации SD-WAN:
    Снова включаем потери в размере 1% на канале. И после включения DUP картинка в VLC на приёме не восстанавливается. Возможно, это связано с работой механизма дедупликации на принимающей стороне, т. е. при удалении дубликатов пакетов или с изменением порядка следования пакетов после дедупликации при приёме их на рабочей станции. В общем, не взлетело.
    В целом по этому тесту видно, что при сравнении FEC vs DUP однозначно выигрывает FEС — даже ценой более высокой нагрузки каналов. Возможно, это следствие того, что Fortinet использует собственные ASIC-чипы и аппаратное ускорение сетевых функций SD-WAN и контентной фильтрации. Это даёт плюс к общей скорости, что бывает критично в точках развёртывания, где сложно спрогнозировать качество связи (выставки, демозоны и тому подобное).

    [Кейс 3] Распределяем трафик по разным каналами

    Часто наполеоновские планы по развертыванию масштабных сетей на несколько сотен офисов разбиваются о суровую реальность: операторы связи на местах подключают точки слабыми каналами, которых по отдельности не хватает на весь конечный трафик. В итоге нам необходимо использовать их одновременно в режиме балансировки.
    Для генерации тестового трафика используем ПО iPerf. Клиент будет располагаться на рабочей станции в удалённом офисе, сервер — на рабочей станции в головном. Будем генерировать поток из 50 UDP-сессий общей пропускной способностью 50 Мбит/с и проверять, распределяются ли они по обоим каналам. В качестве алгоритма балансировки используется Round Robin.
    В этом тесте мы зададим правила для удалённого оборудования и будем ждать равномерного распределения трафика по каналам, т. е. примерно 25 Мбит/с на канал.
    В итоге мы быстро развернули правило SD-WAN на удалённых устройствах и теперь, в случае проблем одного из каналов, оборудование отследит это и перебросит трафик на резервный канал. Это позволяет экономить на трафике, перебрасывая второстепенные приложения и сервисы на более дешёвые каналы. Поговаривают, что 30−40% затрат на связь можно сэкономить. Дополнительно Fortinet позволяет автоматически настраивать тоннели между филиалами и снижать задержку по сравнению с маршрутизацией через центр.

    [Кейс 3*] Распределяем приложения по каналам

    Предположим, у нас есть критичный трафик, например телеметрия, которая обрабатывается в режиме реального времени. Нам нужно часть важного для бизнеса трафика вывести на стабильный канал, а более дешёвый оставить под всё остальное.
    Мы посмотрим, как SD-WAN в версии от Fortinet позволяет настроить роутинг определённого трафика на конкретный VPN. Для этого создадим правило, согласно которому весь трафик пойдёт на один канал, а всё важное (например, телеметрия газопровода или Telegram вашего начальника) остаётся на втором.
    Таким образом, мы успешно проверили возможность выведения какого-то важного нам трафика на отдельный канал. Главное, не забывать, что Fortigate — это прежде всего файрволы. Поэтому для корректной работы наших SD-WAN Rules сначала потребуется создать аналогичные правила в политике безопасности. Мы проверили только часть возможностей: дополнительно приложения, чувствительные к задержкам или занимающие весь канал, можно балансировать благодаря разным стратегиям, но это уже за рамками данного теста.

    [Кейс 4] Удерживаем гарантированное качество при DDoS-атаке

    Давайте посмотрим, как наше оборудование справится с внешней атакой, — при этом мы по-прежнему будем управлять всем удалённо. От нас требуется хладнокровие и внимательность, а оборудование должно:
    1. Обнаруживать паразитную загрузку канала (используются тестовые пакеты HealthCheck);
    2. Переключаться на резервный канал на период DDoS;
    3. Возвращаться обратно после окончания DDoS.
    Как видно из кейса, функциональность SD-WAN позволяет без дополнительных настроек минимизировать эффект DDoS-атак, затрагивающих каналы связи (в сравнении с классическими сетями, где пришлось бы добавлять SLA).

    Что мы получили в итоге

    Нам удалось проверить пользовательские сценарии, но к самому SD-WAN есть комментарии.
    Как и говорилось вначале, у Fortinet концепция реализована дополнительной функциональностью поверх основной: SD-WAN встроен в операционную систему FortiOS и является частью межсетевого экрана. Management Plane не вынесен в явном виде (управляющий менеджер можно и не ставить), Control plane продолжает вертеться на удалённом SD-WAN-роутере — т. е. устройства так и остаются во многом standalone сетевыми экранами с роутингом, ведь на них вынесено больше функций, чем это предусматривает оригинальная концепция SD-WAN.
    И что же в результате? Поможет ли SD-WAN on Fortinet настроить вашу сеть? Да. Предоставит ли механизмы управления ею? Конечно. Но иногда придётся опуститься на землю и использовать консоль для тонкой настройки конфигурации. Это даже удобно: консоль у вас никто не отбирает, оборудованием можно управлять и из неё. Впрочем, релиз за релизом в FortiOS таких ситуаций становится всё меньше. А если у вас всё-таки возникнут проблемы или вопросы, то всегда можно открыть тикет в техподдержке. По опыту своих проектов мы знаем, что Fortinet здесь работает как надо.
    Ну и напоследок: SD-WAN у Fortinet не требует активации лицензий — его можно развернуть на имеющемся оборудовании и съесть за раз двух «рыбов»: одним комплектом оборудования и обеспечить безопасность, и получить централизованное управление сетью. Это очень удобно для случаев, когда одновременно требуют защищенность и хотят попробовать SD-WAN без создания зоопарка устройств.
    Да, мы могли пропустить какие-то интересные моменты или сложные случаи, и если у вас есть свои интересные кейсы или вы на практике сталкивались с вопросами, которые хотелось бы проверить на уровне стенда, — пишите в комментариях. Мы протестируем это дело в нашей демолаборатории и, если это целесообразно, сделаем отдельную статью. Ну или пришлите нам весточку на почту: мы поможем найти правильное железо, настроим его и обеспечим поддержку.
    Как можно попасть на Камчатку и полюбоваться Тихим океаном, попробовать краба и посмотреть вулканы? Можно несколько месяцев планировать отпуск, подобрать удобный рейс, гостиницу под свой вкус, а можно и за два дня 一 если получить недовольный звонок клиента, у которого от сети отваливаются филиалы на Дальнем Востоке. Проблема плавающая, причина непонятная 一 поэтому, говорят, приезжайте, посмотрите нашу природу, попробуете местные деликатесы. Если останутся время и силы.

    Хотим оставить подобные истории на уровне баек из курилки, поэтому стали перебирать решения и пришли к идее, что пора осваивать программно-определяемые сети (SD-WAN). Для этого мы обратились к оборудованию, которое хорошо знаем по другим проектам: взяли сетевые экраны Fortinet c поддержкой SD-WAN и протестировали на них несколько популярных запросов от клиентов. Посмотрели, как можно разворачивать распределенную сеть и управлять ею через общий веб-интерфейс, и расписали результаты тестов и наше мнение о возможностях этого оборудования.

    Зачем вообще нужна программно-определяемая сеть

    Концепция SD-WAN началась с идеи сделать контроль удалённых сетей проще и получить возможность управлять (в т. ч. автоматически) передачей данных в любой точке планеты. Идея подразумевает также удалённую настройку сетевых устройств через облачную среду или управляющее устройство: вместо десяти умных и мощных роутеров используем десять slave-устройств, управляемых из единого центра.
    Такая идея красиво и просто звучит на уровне буклетов, но мы работаем сразу с несколькими производителями (Cisco, Fortinet, Huawei, Versa Networks, VMware) и видим, что концепцию SD-WAN каждый бренд трактует и реализует по-своему. Из-за этого нельзя объединять оборудование разных производителей, а у каждой реализации есть свои особенности, о которых нужно знать до того, как придётся всё исправлять.
    В последнее время основное требование у наших клиентов 一 это безопасность. В таких случаях мы часто используем FortiGate'ы. Их фишка — отслеживание несанкционированной активности внутри сети, управление трафиком отдельных приложений и гибкое создание правил, за что его и любят безопасники. Добавим сюда сетевые правила SD-WAN (это будет выглядеть максимально естественно) и получим очень любопытное решение.

    Собираем стенд для SD-WAN

    Работа с любым вендором начинается со стенда: во-первых, это интересно, во-вторых — позволяет избежать ситуации, когда посреди казахских степей обнаруживается, что какая-то важная функция не работает.
    Для теста мы взяли:
    И к ним виртуальные машины
      • FortiManager, FMG-VM-Base.
      • FortiGate (виртуальные), FG-VM02.
      И стали собирать. На выходе у нас получилась такая схема:
      Мы смоделировали сеть, связывающую головной офис и два удалённых филиала. Они соединены через два виртуальных ISP, характеристики подключения которых мы можем менять. Одна линия эмулирует подключение филиала к публичному интернету, а другая — к каналу VPN. Это означает, что у нас две разные WAN-среды подключения к двум разным провайдерам (ISP). А где есть разделение на две сети в одной подсети — там и разделение на две разных политики работы.

      [Кейс 1] Запускаем сеть без предварительной настройки оборудования

      Представьте, что далеко в горах в полузаброшенном отеле «Оверлук» вам нужно развернуть сеть, на которой будут работать видеонаблюдение, телефония, несколько кассовых аппаратов и много чего ещё. Сеть нужна «ещё вчера», а таких точек много. Всё осложняется тем, что разумной жизни (хотя бы уровня CCNA) рядом нет.
      Тут важны скорость и удобство развёртывания, поэтому нас будет интересовать, как у Fortinet реализуется функция ZTP (Zero Touch Provisioning). Она позволяет добавить оборудование в систему и настроить по серийному номеру, а созданная конфигурация автоматически загрузится при первом подключении к сети. Устройство само найдёт сервер управления, подключится и скачает настройки.
      Оборудование готово к дальнейшим настройкам: централизованному обновлению ПО, установке политик безопасности и шаблонов конфигураций. Альтернативой ZTP является использование для загрузки стартовой конфигурации USB-флешек, — это не так удобно, как ZTP, но подойдёт в случаях, когда со стороны провайдеров нет поддержки автоматической конфигурации внешних интерфейсов. В любом случае это удобнее, чем ехать на объект и настраивать всё руками.

      [Кейс 2] Включаем защиту от потерь данных

      Продолжаем наш штурм гор: объект доступен, теперь нужно минимизировать потерю данных между ним и центральным офисом. У Fortinet для таких случаев есть механизм FEC (Forward Error Correction), позволяющий добавлять к передаваемым пакетам некоторое количество избыточных, что даёт возможность восстановить на принимающей стороне потерянные. Альтернативный вариант: механизм DUP, при котором трафик передаётся по основному каналу и дублируется по одному или сразу нескольким резервным.
      В качестве тестовой передачи запустим (и примем) трансляцию видеоролика с использованием VLC media player. Транслировать будем с тестовой рабочей станции в центральном офисе в сторону удалённого офиса. Трафик будет отправляться в режиме unicast по протоколу UDP. Потери на канале будем вносить с использованием ПО WANem.
      В этот раз:
      • Посмотрим эффект от FEC. Тест будем считать пройденным, если получим приемлемое качество работы при нестабильном канале. Параллельно проверим, появился ли адаптивный FEC (мечтать не вредно), какой максимальный процент потерь (и джиттер) может скорректировать FEC.
      • Проверим, как отображается картинка ролика. Изучим размер избыточности трафика, который при этом возникает, а также узнаем, соответствуют ли теоретические расчёты результатам на практике.
      • Рассчитаем нагрузку на CPU/ASIC оборудования, проведём тест на DUP (дупликацию), проверим возможность нормальной работы на двух плохих каналах.
      Ну и в конце сравним, что выгоднее использовать — FEC или DUP.
      Очевидный минус этой функции — пропускная способность канала, которой мы будем с FEC стабильно жертвовать ради передачи избыточных пакетов. Попытка найти настройки адаптивного FEC в интерфейсе провалилась, но это неудивительно. Увидеть реализацию такой функциональности на практике нам пока не доводилось.
      В целом можно подбирать параметры (fec-base, fec-redundant) в зависимости от значения текущих потерь на канале и целевых, т. е. тех, которые нас устроят. Существуют готовые скрипты для расчётов (требуется знание китайского). В нашем случае использовались параметры fec-base=20, fec-redundant=6 и до 1% исходных потерь на канале. При такой конфигурации мы получаем менее 0,0001% целевых потерь при избыточной загрузке канала от 30 до 40%.
      Механизм дупликации пакетов DUP в каком-то смысле может быть альтернативой FEC. При его настройке не требуется переустановление туннелей, т. к. данные настройки выполняются в конфигурации SD-WAN:
      Снова включаем потери в размере 1% на канале. И после включения DUP картинка в VLC на приёме не восстанавливается. Возможно, это связано с работой механизма дедупликации на принимающей стороне, т. е. при удалении дубликатов пакетов или с изменением порядка следования пакетов после дедупликации при приёме их на рабочей станции. В общем, не взлетело.
      В целом по этому тесту видно, что при сравнении FEC vs DUP однозначно выигрывает FEС — даже ценой более высокой нагрузки каналов. Возможно, это следствие того, что Fortinet использует собственные ASIC-чипы и аппаратное ускорение сетевых функций SD-WAN и контентной фильтрации. Это даёт плюс к общей скорости, что бывает критично в точках развёртывания, где сложно спрогнозировать качество связи (выставки, демозоны и тому подобное).

      [Кейс 3] Распределяем трафик по разным каналами

      Часто наполеоновские планы по развертыванию масштабных сетей на несколько сотен офисов разбиваются о суровую реальность: операторы связи на местах подключают точки слабыми каналами, которых по отдельности не хватает на весь конечный трафик. В итоге нам необходимо использовать их одновременно в режиме балансировки.
      Для генерации тестового трафика используем ПО iPerf. Клиент будет располагаться на рабочей станции в удалённом офисе, сервер — на рабочей станции в головном. Будем генерировать поток из 50 UDP-сессий общей пропускной способностью 50 Мбит/с и проверять, распределяются ли они по обоим каналам. В качестве алгоритма балансировки используется Round Robin.
      В этом тесте мы зададим правила для удалённого оборудования и будем ждать равномерного распределения трафика по каналам, т. е. примерно 25 Мбит/с на канал.
      В итоге мы быстро развернули правило SD-WAN на удалённых устройствах и теперь, в случае проблем одного из каналов, оборудование отследит это и перебросит трафик на резервный канал. Это позволяет экономить на трафике, перебрасывая второстепенные приложения и сервисы на более дешёвые каналы. Поговаривают, что 30−40% затрат на связь можно сэкономить. Дополнительно Fortinet позволяет автоматически настраивать тоннели между филиалами и снижать задержку по сравнению с маршрутизацией через центр.

      [Кейс 3*] Распределяем приложения по каналам

      Предположим, у нас есть критичный трафик, например телеметрия, которая обрабатывается в режиме реального времени. Нам нужно часть важного для бизнеса трафика вывести на стабильный канал, а более дешёвый оставить под всё остальное.
      Мы посмотрим, как SD-WAN в версии от Fortinet позволяет настроить роутинг определённого трафика на конкретный VPN. Для этого создадим правило, согласно которому весь трафик пойдёт на один канал, а всё важное (например, телеметрия газопровода или Telegram вашего начальника) остаётся на втором.
      Таким образом, мы успешно проверили возможность выведения какого-то важного нам трафика на отдельный канал. Главное, не забывать, что Fortigate — это прежде всего файрволы. Поэтому для корректной работы наших SD-WAN Rules сначала потребуется создать аналогичные правила в политике безопасности. Мы проверили только часть возможностей: дополнительно приложения, чувствительные к задержкам или занимающие весь канал, можно балансировать благодаря разным стратегиям, но это уже за рамками данного теста.

      [Кейс 4] Удерживаем гарантированное качество при DDoS-атаке

      Давайте посмотрим, как наше оборудование справится с внешней атакой, — при этом мы по-прежнему будем управлять всем удалённо. От нас требуется хладнокровие и внимательность, а оборудование должно:
      1. Обнаруживать паразитную загрузку канала (используются тестовые пакеты HealthCheck);
      2. Переключаться на резервный канал на период DDoS;
      3. Возвращаться обратно после окончания DDoS.
      Как видно из кейса, функциональность SD-WAN позволяет без дополнительных настроек минимизировать эффект DDoS-атак, затрагивающих каналы связи (в сравнении с классическими сетями, где пришлось бы добавлять SLA).

      Что мы получили в итоге

      Нам удалось проверить пользовательские сценарии, но к самому SD-WAN есть комментарии.
      Как и говорилось вначале, у Fortinet концепция реализована дополнительной функциональностью поверх основной: SD-WAN встроен в операционную систему FortiOS и является частью межсетевого экрана. Management Plane не вынесен в явном виде (управляющий менеджер можно и не ставить), Control plane продолжает вертеться на удалённом SD-WAN-роутере — т. е. устройства так и остаются во многом standalone сетевыми экранами с роутингом, ведь на них вынесено больше функций, чем это предусматривает оригинальная концепция SD-WAN.
      И что же в результате? Поможет ли SD-WAN on Fortinet настроить вашу сеть? Да. Предоставит ли механизмы управления ею? Конечно. Но иногда придётся опуститься на землю и использовать консоль для тонкой настройки конфигурации. Это даже удобно: консоль у вас никто не отбирает, оборудованием можно управлять и из неё. Впрочем, релиз за релизом в FortiOS таких ситуаций становится всё меньше. А если у вас всё-таки возникнут проблемы или вопросы, то всегда можно открыть тикет в техподдержке. По опыту своих проектов мы знаем, что Fortinet здесь работает как надо.
      Ну и напоследок: SD-WAN у Fortinet не требует активации лицензий — его можно развернуть на имеющемся оборудовании и съесть за раз двух «рыбов»: одним комплектом оборудования и обеспечить безопасность, и получить централизованное управление сетью. Это очень удобно для случаев, когда одновременно требуют защищенность и хотят попробовать SD-WAN без создания зоопарка устройств.
      Да, мы могли пропустить какие-то интересные моменты или сложные случаи, и если у вас есть свои интересные кейсы или вы на практике сталкивались с вопросами, которые хотелось бы проверить на уровне стенда, — пишите в комментариях. Мы протестируем это дело в нашей демолаборатории и, если это целесообразно, сделаем отдельную статью. Ну или пришлите нам весточку на почту: мы поможем найти правильное железо, настроим его и обеспечим поддержку.

      Комментарии (11)


      1. ColdSUN
        24.09.2021 15:06
        +2

        Как это SD-WAN не требует лицензий? Распределение приложений по каналам без подписки не работает. Дополнительной лицензии никакой докупать не надо, это так, но обычную лицензию на UTM всё же придётся купить и продлять её.


        1. JetHabr
          29.09.2021 17:40

          В целом Вы правы, но дьявол кроется в деталях.

          Устройства Fortigate в базе несут на борту функционал Application Control. Его достаточно для «чистого» SD-WAN (т.е. для использования типа приложения в качестве критерия применения SD-WAN правил). Но для получения обновлений сигнатур приложений потребуется как минимум подписка FortiCare (обновление FortiOS, сервис ТП и пр.).

          Если же требуется Secure SD-WAN, т.е. совмещение функций SD-WAN и безопасности профильного NGFW, в таком случае безусловно требуется полноценный бандл (UTP и выше): https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/FortiGuard_Security_Services.pdf https://www.fortinet.com/content/dam/fortinet/assets/brochures/Brochure-FortiGuard-Security-Services.pdf

          Fortinet лицензионно не ограничивает ни полосу пропускания, ни количество подключений, ничего. Здесь все упирается только в производительность самого устройства Fortigate - cколько МСЭ через себя трафика сможет пропихнуть, столько и будет.

          Подскажите, с какими девайсами Fortigate (с какой подпиской) и версией FortiOS Вы работали?


          1. ColdSUN
            29.09.2021 18:17
            +1

            FGT 100d/e/f, 200d/e/f, 500e, 1100e etc. 5.6.x, 6.0.x, 6.2.x, 6.4.x

            Сейчас дома стоит FortiWifi 40f 3G4G прошивка 6.4.7 и два FortiAP 221e. С лицензией на UTM функции.

            FortiCare для обновления сигнатур не достаточно. Нужна именно подписка на UTM. Что-то вроде 360 Protection или UTP. Можно Advanced Threat Protection, если не нужен Web Filter.


            1. JetHabr
              06.10.2021 11:05

              Добрый день! Мы на всякий случай связались с Fortinet и уточнили этот вопрос. С версии FortiOS 6.2 обновления Application Control входят в базовый FortiCare. По другим сервисам (кроме базового функционала) – да, для обновлений действительно требуется подписка. Но тут можем отметить, что если забыть продлить соответствующую подписку, то сервисы останутся в рабочем состоянии на момент окончания подписки. Они не откатятся к базовых настройкам, не превратят межсетевой экран в коробку с режимом "только для чтения".


              1. ColdSUN
                06.10.2021 11:25
                +2

                Вы абсолютно правы. Сейчас открыл список лицензий и что в них входит, и обнаружил, что в обычный FortiCare 24x7 входит Application Control. И да, в отличии от того же Cisco Meraki окончание подписки не превращает железку в тыкву.


      1. redneko
        28.09.2021 17:15
        +1

        Для передачи ТВ-потоков всё же лучше использовать более специализированные железки (от тех же AppearTV, Nevion, и иже с ними), поскольку если еще для MPEG2TS можно жить с увеличенным джиттером, то какой-нибудь SMPTE 2022-6 уже будет неработоспособен. И VLC тут тоже не показатель - он спокойно ест VBR поток не рассыпаясь, а Ericsson 8200 не хочет ни в какую (но это уже больше особая придирчивость ресивера играет роль). К тому же благодаря SRT можно с приемлемым качеством и задержкой гонять MPEG2TS через публичные сети. Хотя и у реализаций SRT нет-нет, да и находятся баги, проект до сих пор пилится активно.


        1. JetHabr
          01.10.2021 18:33
          +1

          Спасибо за комментарий! В статье мы попытались раскрыть, как выглядит работа с наиболее популярными запросами, которые мы получаем от заказчиков. К сожалению, работы с ТВ-потоками среди них не было. VLC мы использовали как лекгодоступный подручный инструмент проверки функционала и гипотез по работе с Fortigate. В будущих тестах попробуем добавить больше вариативности по используемому продуктивному трафику.


      1. kazaros
        30.09.2021 11:49
        +1

        Не повысилось ли задержки при включении FEC?


        1. JetHabr
          01.10.2021 18:34

          К сожалению, не замеряли этот показатель. По логике работы FEC задержка должна быть. Но мы не замеряли избыточность (она легко определяется по коэффициенту избыточности FEC, у нас 1:6) и задержки в явном виде. Попробуем при случае проверить.


      1. sHaggY_caT
        09.10.2021 19:33
        +1

        Как мы перестали бояться и полюбили программно-определяемые сети

        пользуясь случаем, побояню: