Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

З серпня 2017 року, коли компанія Cisco придбала компанію Viptela, основною пропонованою технологією організації розподілених корпоративних мереж стала Cisco SD-WAN. За минулі 3 роки SD-WAN технологія пройшла безліч змін як якісного, так і кількісного характеру. Так значно розширилися функціональні можливості та з'явилася підтримка на класичних маршрутизаторах серій. Cisco ISR 1000, ISR 4000, ASR 1000 та віртуального CSR 1000v. У той же час багато замовників і партнерів Cisco продовжують задаватися питанням - у чому полягають відмінності Cisco SD-WAN від звичних підходів на базі таких технологій, як Cisco DMVPN и Cisco Performance Routing і наскільки ці відмінності є важливими?

Тут відразу слід застерігати, що до появи SD-WAN в портфоліо Cisco, DMVPN спільно з PfR складали ключову частину в архітектурі Cisco IWAN (Intelligent WAN), Яка у свою чергу являла собою попередника повноважної SD-WAN технології. За загальної подібності, як самих розв'язуваних завдань, і способів їх вирішення, IWAN не отримав необхідного для SD-WAN рівня автоматизації, гнучкості і масштабованості і поступово розвиток IWAN значно знизився. У той же час, самі технології-складові IWAN нікуди не поділися, і багато замовників продовжують їх успішно використовувати в тому числі на сучасному обладнанні. У результаті склалася цікава ситуація – те саме обладнання Cisco дозволяє вибрати найбільш підходящу технологію побудови WAN (класичну, DMVPN+PfR або SD-WAN) відповідно до вимог і очікувань замовників.

Стаття не передбачає детально розбирати всі особливості технологій Cisco SD-WAN і DMVPN (разом або без Performance Routing) - для цього є безліч доступних документів і матеріалів. Основне завдання – постаратися оцінити ключові відмінності цих технологій. Але все ж таки перш, ніж перейти до обговорення цих відмінностей, коротко нагадаємо про самі технології.

Що таке Cisco DMVPN і навіщо він потрібний?

Cisco DMVPN вирішує завдання динамічного (=масштабованого) підключення мережі віддаленої філії до мережі центрального офісу підприємства при використанні довільних типів каналів зв'язку, зокрема Інтернет (= з шифруванням каналу зв'язку). Технічно це реалізується створенням віртуалізованої мережі мережі класу L3 VPN в режимі крапка — багато точок (point-to-multipoint) з логічною топологією типу «Зірка» (Hub-n-Spoke). Для цього DMVPN використовує комбінацію таких технологій:

  • IP маршрутизація
  • Multipoint GRE тунелі (mGRE)
  • Протокол вирішення наступного переходу (NHRP)
  • IPSec Crypto профілі

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Які основні переваги Cisco DMVPN у порівнянні з класичною маршрутизацією з використанням MPLS VPN каналів?

  • Для створення міжфіліальної мережі можливо використовувати будь-які канали зв'язку - підходить все, що здатне забезпечити IP-зв'язок між філією, при цьому трафік буде шифруватися (де треба) і балансуватися (де можливо)
  • Автоматично формується повно зв'язкова топологія між філіями. При цьому між центральною та віддаленою філією – статичні тунелі, а між віддаленими філіями – динамічні тунелі на вимогу (за наявності трафіку)
  • На маршрутизаторах центральної та віддаленої філії одноманітна конфігурація з точністю до IP-адрес інтерфейсів. За рахунок використання mGRE немає потреби в індивідуальному налаштуванні десятків, сотень або навіть тисяч тунелів. Як наслідок, гідна масштабованість при правильному дизайні.

Що таке Cisco Performance Routing та навіщо він потрібен?

При використанні DMVPN на міжфіліальній мережі залишається невирішеним одне вкрай важливе питання – як динамічно оцінити стан кожного з DMVPN тунелів щодо відповідності вимогам критичного для нашої організації трафіку і знову ж таки на основі такої оцінки динамічно приймати рішення про перемаршрутизацію? Справа в тому, що DMVPN у цій частині трохи відрізняється від класичної маршрутизації – найкраще, що можна зробити, це налаштувати механізми QoS, які дозволять пріоритезувати трафік у вихідному напрямку, але ніяк не здатні враховувати стан всього шляху в той чи інший момент часу.

І що робити, якщо канал деградує частково, а не повністю – як це виявити та оцінити? DMVPN сам собою цього не вміє. Враховуючи, що канали, що зв'язують філії, можуть проходити через абсолютно різних операторів зв'язку, використовуючи різні технології, то це завдання стає вкрай нетривіальним. І тут на допомогу приходить технологія Cisco Performance Routing, яка на той час вже пройшла кілька стадій розвитку.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Завдання Cisco Performance Routing (далі PfR) зводиться до вимірювання стану шляхів (тунелів) проходження трафіку на основі ключових метрик, важливих для мережевих додатків. затримка, варіація затримки (джиттер) та втрати пакетів (у відсотках). Додатково може вимірюватися смуга пропускання, що використовується. Ці вимірювання відбуваються максимально близько до реального часу (наскільки це можливо і виправдано) і результат цих вимірювань дозволяє маршрутизатору, що використовує PfR, динамічно приймати рішення щодо необхідності зміни маршрутизації того чи іншого виду трафіку.

Таким чином, задачу комбінації DMVPN/PfR можна коротко охарактеризувати наступним чином:

  • Дозволити замовнику використовувати на WAN мережі будь-які канали зв'язку
  • Забезпечити максимально можливу якість важливих програм на цих каналах

Що таке Cisco SD-WAN?

Cisco SD-WAN – це технологія, яка використовує підхід SDN для створення та експлуатації WAN мережі організації. Це зокрема означає використання так званих контролерів (програмних елементів), які забезпечують централізовану оркестрацію та автоматизоване налаштування всіх компонентів рішення. На відміну від канонічного SDN (в стилі Clean Slate) у Cisco SD-WAN використовується відразу кілька типів контролерів, кожен з яких виконує свою роль – це зроблено навмисно з метою забезпечити кращу масштабованість та георезервування.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

У разі SD-WAN завдання використання будь-яких типів каналів та забезпечення роботи бізнес-додатків зберігається, але при цьому розширюються вимоги до автоматизації, масштабування, безпеки та гнучкості такої мережі.

Обговорення відмінностей

Якщо тепер почати аналізувати відмінності цих технологій, то вони потраплятимуть до однієї з категорій:

  • Архітектурні відмінності – як розподілені функції за різними компонентами рішення, як організовано взаємодію таких компонентів і як це впливає на можливості та гнучкість технології?
  • Функціональні можливості – що такого може одна технологія, що не може інша? І чи це так важливо?

У чому полягає архітектурна різниця і чи так вони важливі?

У кожній із зазначених технологій є безліч «рухомих частин», у яких відрізняється не тільки роль, а й принципи взаємодії один з одним. Від того, наскільки продумані ці принципи, і загальна механіка рішення безпосередньо залежить його масштабованість, стійкість до відмов і загальна ефективність.

Розглянемо різні аспекти архітектури докладніше:

Data-plane - Частина рішення, що відповідає за передачу трафіку користувача між джерелом і одержувачем. У DMVPN і SD-WAN реалізується в цілому однаково на маршрутизаторах на базі Multipoint GRE тунелів. Різниця в тому, за рахунок чого формується необхідний набір параметрів цих тунелів:

  • в DMVPN/PfR – це виключно дворівнева ієрархія вузлів із топологією типу «Зірка» або Hub-n-Spoke. Обов'язковим є статична настройка Hub і статична прив'язка Spoke до Hub, а також взаємодія по протоколу NHRP для формування data-plane зв'язності. Як наслідок, значно утруднені зміни на Hub, пов'язані, наприклад, зі зміною/підключенням нових WAN-каналів або зміни параметрів існуючих.
  • в SD WAN - це повністю динамічна модель виявлення параметрів тунелів з опорою на control-plane (протокол OMP) і orchestration-plane (взаємодія з контролером vBond для завдань виявлення контролерів і NAT traversal). У цьому накладені топології можуть будь-які, зокрема ієрархічні. В рамках встановленої накладеної топології тунелів можливе гнучке налаштування логічної топології в кожному окремому VPN(VRF).

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Control-plane – функції обміну, фільтрації та модифікації маршрутної та іншої інформації між компонентами рішення.

  • в DMVPN/PfR – здійснюється лише між маршрутизаторами Hub та Spoke. Прямий обмін маршрутною інформацією між Spoke неможливий. Як наслідок, без діючого Hub неможливе функціонування control-plane та data-plane, що накладає на Hub додаткові вимоги щодо високої доступності, які не завжди можуть бути виконані.
  • в SD WAN – control-plane ніколи не здійснюється безпосередньо між маршрутизаторами – взаємодія відбувається на основі протоколу OMP і обов'язково здійснюється через окремий спеціалізований тип контролера vSmart, що забезпечує можливість балансування, георезервування та централізованого керування сигнальним навантаженням. Іншою особливістю протоколу OMP є його значна стійкість до втрат і незалежність від швидкості каналу зв'язку з контролерами (в розумних межах, звичайно). Що однаково успішно дозволяє розміщувати контролери SD-WAN у публічних чи приватних хмарах із доступом через Інтернет.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Policy-plane – частина рішення, що відповідає за визначення, поширення та застосування політик управління трафіком на розподіленій мережі.

  • DMVPN – фактично обмежено політиками якості обслуговування (QoS), які налаштовуються індивідуально на кожному маршрутизаторі через CLI або шаблони Prime Infrastructure.
  • DMVPN/PfR – політики PfR формуються на централізованому маршрутизаторі Master Controller (MC) через CLI і надалі автоматично поширюються на філіальні MC. При цьому використовуються самі шляхи передачі політик, що і для data-plane. Можливості рознести обмін політиками, маршрутною інформацією та даними користувача немає. Поширення політик передбачає обов'язкову наявність IP-зв'язку між Hub та Spoke. При цьому функція MC може бути при потребі суміщена з маршрутизатором DMVPN. Можливе (але не потрібне) використання шаблонів Prime Infrastructure для централізованого формування політик. Важлива особливість - політика формується глобально по всій мережі однаково - індивідуальні політики для окремих сегментів не підтримуються.
  • SD WAN – політики керування трафіком та якістю обслуговування визначаються централізовано через графічний інтерфейс Cisco vManage, доступний навіть через Інтернет (за потреби). Поширюються сигнальними каналами безпосередньо або опосередковано через контролери vSmart (залежить від типу політики). Не залежить від data-plane зв'язків між маршрутизаторами, т.к. використовують усі доступні шляхи передачі трафіку між контролером та маршрутизатором.

    Для різних сегментів мережі можливе гнучке формування різних політик – сфера застосування політики визначається безліччю унікальних ідентифікаторів, передбачених у рішенні – номер філії, тип програми, напрямок руху трафіку тощо.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Orchestration-plane – механізми, що дозволяють компонентам динамічно виявити один одного, налаштувати та координувати подальшу взаємодію.

  • в DMVPN/PfR Взаємне виявлення маршрутизаторами ґрунтується на статичній конфігурації Hub пристроїв та відповідному налаштуванні Spoke пристроїв. Динамічне виявлення відбувається тільки для Spoke, який повідомляє про свої параметри з'єднання Hub пристрою, який у свою чергу заздалегідь внесений до конфігурації Spoke. Без IP-зв'язку Spoke з хоча б одним Hub неможливо сформувати ні data-plane, ні control-plane.
  • в SD WAN оркестрація компонентів рішення відбувається з використанням контролера vBond, з яким кожному компоненту (маршрутизаторам та контролерам vManage/vSmart) необхідно попередньо встановити IP-зв'язок.

    Спочатку компоненти не знають про параметри підключення один одного – для цього їм потрібний посередник-оркестратор vBond. Загальний принцип наступний – кожен компонент у початковій фазі дізнається (автоматично або статично) тільки про параметри підключення до vBond, далі vBond повідомляє маршрутизатора про контролерів vManage та vSmart (виявлених раніше), що уможливлює автоматичне встановлення всіх необхідних сигнальних зв'язків.

    Наступним кроком новий маршрутизатор дізнається про інших маршрутизаторів у мережі через OMP-обмін із контролером vSmart. Таким чином маршрутизатор, не знаючи спочатку про параметри мережі взагалі нічого, здатний повністю автоматично виявити і підключитися до контролерів і потім автоматично виявити і сформувати зв'язність з іншими маршрутизаторами. При цьому параметри підключення всіх компонентів спочатку невідомі і можуть змінюватися в процесі експлуатації.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Management-plane - Частина рішення, що забезпечує централізоване управління та моніторинг.

  • DMVPN/PfR – спеціалізованого management-plane рішення не передбачено. Для базової автоматизації та моніторингу можливе використання таких продуктів, як Cisco Prime Infrastructure. Кожен маршрутизатор має можливість керувати через командний рядок CLI. Інтеграції із зовнішніми системами через API не передбачено.
  • SD WAN – вся штатна взаємодія та моніторинг здійснюється централізовано через графічний інтерфейс контролера vManage. Всі можливості рішення без винятку доступні для налаштування через vManage, а також через повністю документовану бібліотеку програмного інтерфейсу REST API.

    Усі налаштування SD-WAN мережі в vManage зводяться до двох основних конструктів – формування шаблонів пристроїв (Device Template) та формування політики, яка визначає логіку роботи мережі та обробки трафіку. При цьому vManage, транслюючи сформовану адміністратором політику, автоматично вибирає які зміни і на яких індивідуальних пристроях/контролерах необхідно зробити, що значно підвищує ефективність та масштабованість рішення.

    Через інтерфейс vManage доступне не лише налаштування рішення Cisco SD-WAN, а й повноцінний моніторинг стану всіх компонентів рішення аж до поточного стану метрик окремих тунелів та статистики використання різних програм на основі DPI аналізу.

    Незважаючи на централізацію взаємодії, всі компоненти (контролери та маршрутизатори) мають також повнофункціональний командний рядок CLI, який необхідний на етапі впровадження або у разі нештатної ситуації для локальної діагностики. У штатному режимі (за наявності сигнального каналу між компонентами) на маршрутизаторах командний рядок доступний лише для діагностики та недоступний для внесення локальних змін, що гарантує і локальну безпеку та єдине джерело змін у такій мережі – vManage.

Інтегрована безпека – тут мова повинна йти не тільки про захист даних користувача при передачі по відкритих каналах, а й про загальну захищеність WAN-мережі на базі обраної технології.

  • в DMVPN/PfR передбачена можливість шифрування даних і сигнальних протоколів. При використанні певних моделей маршрутизаторів додаткові функції міжмережевого екранування з інспекцією трафіку, IPS/IDS. Є можливість сегментації мереж філій з використанням VRF. Є можливість аутентифікації (однофакторної) контрольних протоколів.

    У цьому віддалений маршрутизатор за замовчуванням вважається довіреним елементом мережі – тобто. не передбачаються та не враховуються випадки фізичної компрометації окремих пристроїв та можливість несанкціонованого до них доступу; немає двофакторної автентифікації компонентів рішення, що у разі географічно розподіленої мережі може мати серйозні додаткові ризики.

  • в SD WAN за аналогією з DMVPN передбачена можливість шифрування даних користувача, але зі значно розширеними функціями мережевої безпеки та L3/VRF сегментації (МСЕ, IPS/IDS, URL-фільтрація, DNS-фільтрація, AMP/TG, SASE, TLS/SSL proxy і т.д. д.). При цьому обмін ключами шифрування здійснюється більш ефективно через vSmart контролери (а не безпосередньо), заздалегідь встановленими сигнальними каналами, захищеними DTLS/TLS шифруванням на основі сертифікатів безпеки. Що в свою чергу гарантує безпеку такого обміну і забезпечує кращу масштабованість рішення до десятків тисяч пристроїв в одній мережі.

    Всі сигнальні з'єднання (контролер-контролер, маршрутизатор контролер) також захищені на основі DTLS/TLS. Маршрутизатори оснащуються сертифікатами безпеки під час виробництва з можливістю заміни/продовження. Двофакторна аутентифікація досягається за рахунок обов'язкового та одночасного виконання двох умов для можливості функціонування маршрутизатора/контролера в SD-WAN мережі:

    • Чинний сертифікат безпеки
    • Явне та усвідомлене внесення адміністратором кожного компонента до «білого» списку дозволених пристроїв.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Функціональні відмінності SD-WAN та DMVPN/PfR

Переходячи до обговорення функціональних відмінностей, слід зазначити, що багато з них є продовженням архітектурних — не секрет, що при формуванні архітектури рішення розробники відштовхуються від можливостей, які хочуть отримати в результаті. Розглянемо найбільші відмінності двох технологій.

AppQ (Application Quality) – функції забезпечення якості передачі трафіку бізнес-додатків

Ключові функції розглянутих технологій спрямовані на те, щоб наскільки це можливо покращити досвід користувача при використанні бізнес-критичних додатків у розподіленій мережі. Це особливо важливо в умовах, коли частина інфраструктури не контролюється IT або навіть гарантує успішну передачу даних.

DMVPN самостійно не надає таких механізмів. Найкраще, що можна зробити в класичній DMVPN мережі, це класифікувати вихідний трафік за програмами та пріоритезувати його при передачі у напрямку WAN-каналу. Вибір DMVPN тунелю обумовлений у разі лише його доступністю і результатом роботи протоколів маршрутизації. При цьому ніяк не враховується наскрізний стан колії/тунелю та його можлива часткова деградація з точки зору ключових метрик, значимих для мережних додатків – затримка, варіація затримки (джиттер) та втрати (%). У зв'язку з цим безпосередньо порівнювати класичний DMVPN c SD-WAN у частині рішення AppQ задач втрачає будь-який сенс – DMVPN не може вирішити це завдання. При додаванні до цього контексту технології Cisco Performance Routing (PfR) ситуація змінюється і порівняння з Cisco SD-WAN стає доцільнішим.

Перш ніж перейти до обговорення відмінностей, коротко про те, в чому технології схожі. Отже, обидві технології:

  • мають механізм, який дозволяє динамічно оцінити стан кожного встановленого тунелю в розрізі певних метрик – як мінімум, затримка, варіація затримки та втрати пакетів (%)
  • використовують певний набір інструментів для формування, поширення та застосування правил (політик) управління трафіком з урахуванням результату вимірювання стану ключових метрик тунелів.
  • класифікують трафік додатків на рівнях L3-L4 (DSCP) моделі OSI або за L7 сигнатурами додатків на основі вбудованих у маршрутизатор DPI механізмів
  • дозволяють для значних додатків визначити допустимі граничні значення метрик, правила передачі трафіку за замовчуванням, правила перемаршрутизації трафіку при перевищенні граничних значень.
  • при інкапсуляції трафіку в GRE/IPSec використовують механізм перенесення внутрішньої DSCP маркування в зовнішній GRE/IPSEC заголовок пакета, що вже усталена в індустрії, що дозволяє синхронізувати політики QoS організації та оператора зв'язку (за наявності відповідного SLA).

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Як відрізняються механізми оцінки наскрізних метрик SD-WAN та DMVPN/PfR?

DMVPN/PfR

  • Для оцінки стандартних метрик стану тунелю використовують як активні, і пасивні програмні сенсори (Probes). Активні — на основі трафіку користувача, пасивні емулюють такий трафік (за його відсутності).
  • Тонка настройка таймерів та умов виявлення деградації відсутня – алгоритм фіксований.
  • Додатково доступний вимірювання смуги пропускання, що використовується у вихідному напрямку. Що додає DMVPN/PfR додаткову гнучкість керування трафіком.
  • При цьому деякі механізми PfR при перевищенні метрик покладаються на зворотний сигнальний зв'язок у вигляді спеціальних TCA (Threshold Crossing Alert) повідомлень, які повинні виходити від отримувача трафіку у бік джерела, що в свою чергу припускає, що стану каналів, що вимірюються, повинно бути як мінімум достатньо для передачі таких TCA-повідомлень. Що в більшості випадків не є проблемою, але, очевидно, не може бути гарантовано.

SD WAN

  • Для наскрізної оцінки стандартних метрик стану тунелю використовується протокол BFD в режимі echo. При цьому спеціального зворотного зв'язку у вигляді TCA або подібних повідомлень не потрібно – дотримується ізольованість доменів відмови. Також не потрібна присутність трафіку користувача для оцінки стану тунелю.
  • Є можливість тонкого настроювання таймерів BFD для регулювання швидкості спрацьовування та чутливості алгоритму до деградацій каналу зв'язку від кількох секунд до хвилин.

    Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

  • На момент написання статті у кожному з тунелів передбачено лише одну BFD сесію. Потенційно це створює меншу гранулярність під час аналізу стану тунелю. Насправді це може стати обмеженням тільки у разі використання WAN-підключення на базі MPLS L2/L3 VPN з узгодженим QoS SLA — якщо DSCP-маркування BFD трафіку (після інкапсуляції в IPSec/GRE) співпадатиме з високопріоритетною чергою в мережі оператора зв'язку, то це може вплинути на точність та швидкість виявлення деградації для низькопріоритетного трафіку. При цьому є можливість зміни маркування BFD за замовчуванням для зниження ризику подібних ситуацій. У наступних версіях програмного забезпечення Cisco SD-WAN очікується поява більш тонкого налаштування BFD, а також можливість запуску кількох BFD сесій в рамках одного тунелю з індивідуальними значеннями DSCP (для різних додатків).
  • BFD додатково дозволяє оцінити максимальний розмір пакета, який можна передати по тому чи іншому тунелю без фрагментації. Це дозволяє SD-WAN динамічно налаштовувати такі параметри як MTU і TCP MSS Adjust, щоб максимально ефективно використовувати доступну смугу пропускання на кожному каналі.
  • У SD-WAN також доступна опція синхронізації QoS з операторів зв'язку не тільки на основі L3 DSCP поля, але й на основі L2 CoS значень, які можуть автоматично формуватися у мережі мережі спеціалізованими пристроями — наприклад, IP-телефонами

Як відрізняються можливості, способи визначення та застосування AppQ політик?

Політики DMVPN/PfR:

  • Визначаються на маршрутизаторі центральної філії (ЦФ) через командний рядок CLI або CLI-шаблони конфігурацій. Формування CLI-шаблонів вимагає підготовки та знання синтаксису політик.

    Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

  • Визначаються глобально без можливості індивідуального налаштування/зміни під вимоги окремих сегментів мережі.
  • Інтерактивне формування політик у графічному інтерфейсі не передбачено.
  • Відстеження змін, наслідування, створення кількох версій політик для швидкого перемикання не передбачено.
  • Розповсюджуються автоматично на маршрутизатори віддалених філій. При цьому використовуються ті ж канали зв'язку, що і для передачі даних користувача. За відсутності каналу зв'язку між центральною та віддаленою філією поширення/зміна політик неможливе.
  • Застосовуються кожному маршрутизаторі і за необхідності модифікують результат стандартних протоколів маршрутизації, маючи вищий пріоритет.
  • Для випадків, коли всі WAN-канали філії зазнають значних втрат трафіку, механізмів компенсації не передбачено.

Політики SD-WAN:

  • Визначаються у графічному інтерфейсі vManage через інтерактивний майстер шаблонів.
  • Підтримують створення кількох політик, копіювання, успадкування, перемикання між політиками у реальному режимі часу.
  • Підтримують індивідуальне настроювання політики під різні сегменти (філії) мережі
  • Поширюються, використовуючи будь-який доступний сигнальний канал між контролером та маршрутизатором та/або vSmart – не залежать безпосередньо від data-plane зв'язків між маршрутизаторами. При цьому звичайно потрібна IP-зв'язок між самим маршрутизатором та контролерами.

    Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

  • Для випадків, коли всі доступні канали філії зазнають значних втрат даних, що перевищують допустимі граничні значення для критичних додатків, можливе використання додаткових механізмів, що підвищують надійність передачі:
    • FEC (пряме виправлення помилок) - Використовує спеціальний алгоритм надлишкового кодування. При передачі критичного трафіку каналами зі значним відсотком втрат, FEC може бути автоматично активований і дозволяє при необхідності відновити втрачену частину даних. При цьому незначно підвищується смуга передачі, що використовується, але значно підвищується надійність.

      Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

    • Публікація потоків даних – додатково до FEC політика може передбачати автоматичне дублювання трафіку вибраних додатків у разі ще більшого рівня втрат, які не вдається компенсувати за допомогою FEC. У цьому випадку обрані дані будуть передаватися по всіх тунелях у бік філії-отримувача з подальшою де-публікацією (відкидання зайвих копій пакетів). Механізм помітно збільшує утилізацію каналів, але також значно підвищує надійність передачі.

Можливості Cisco SD-WAN, без прямих аналогів у DMVPN/PfR

Архітектура рішення Cisco SD-WAN у деяких випадках дозволяє отримати можливості, реалізація яких у рамках DMVPN/PfR або вкрай утруднена, або недоцільна через необхідні трудові витрати, або взагалі неможлива. Розглянемо найцікавіші з них:

Traffic-Engineering (TE)

TE включає механізми, які дозволяють відганяти трафік від стандартного шляху, сформованого протоколами маршрутизації. TE часто використовується для забезпечення високої доступності мережевих сервісів, за рахунок здатності швидко і/або заздалегідь перевести важливий трафік на альтернативний шлях передачі, що не перетинається, з метою забезпечення кращої якості сервісу або швидкості його відновлення в разі збою на основному шляху.

Складність реалізації TE полягає у необхідності заздалегідь обчислити та зарезервувати (перевірити) альтернативний шлях. У мережах MPLS операторів зв'язку це завдання вирішують, використовуючи такі технології, як MPLS Traffic-Engineering з розширеннями IGP протоколів і RSVP протоколу. Також останнім часом все більшої популярності набирає технологія Segment Routing, яка більш оптимізована для централізованого налаштування та оркестрації. У класичних WAN мережах ці технології, як правило, не представлені або зведені до використання hop-by-hop механізмів типу Policy-Based Routing (PBR), які здатні відгалужити трафік, але реалізують це на кожному маршрутизаторі окремо – без урахування загального стану мережі або результату PBR на попередньому чи наступних кроках. Підсумок застосування цих варіантів TE невтішний – MPLS TE через складність налаштування та експлуатації використовують, як правило, тільки в самій критичній частині мережі (ядро), а PBR використовують на окремих маршрутизаторах без можливості сформувати якусь єдину PBR політику по всій мережі. Очевидно, це стосується мереж на базі DMVPN.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

SD-WAN у цьому плані пропонує набагато елегантніше рішення, яке не тільки легко налаштовується, але й значно краще масштабується. Це є результатом використовуваних архітектур control-plane та policy-plane. Реалізація policy-plane у SD-WAN дозволяє централізовано визначити політику TE – який трафік цікавить? для яких VPN? через які вузли/тунелі необхідно чи навпаки заборонено формувати альтернативний маршрут? У свою чергу централізація управління control-plane на базі vSmart контролерів дозволяє модифікувати результати маршрутизації, не вдаючись до налаштувань окремих пристроїв – маршрутизатори вже бачать лише результат тієї логіки, яка була сформована в інтерфейсі vManage та передана для застосування на vSmart.

Service-chaining (Сервісні ланцюжки)

Формування сервісних ланцюжків є ще більш трудомістким завданням у класичній маршрутизації, ніж вже описаний механізм Traffic-Engineering. Адже в цьому випадку необхідно не тільки сформувати якийсь спеціальний маршрут для певного мережевого додатка, але й забезпечити можливість виведення трафіку з мережі на певних (або на всіх) вузлах SD-WAN мережі для обробки спеціальним додатком або сервісом (МСЕ, Балансування, Кешування, Інспекція трафіку тощо). При цьому необхідно мати можливість контролювати стан цих зовнішніх сервісів, щоб не допускати ситуацій black-holing, а також потрібні механізми, що дозволяють розміщувати такі однотипні зовнішні сервіси в різних геолокаціях з можливістю мережі автоматично вибирати найбільш оптимальний сервісний вузол для обробки трафіку тієї чи іншої філії . У випадку Cisco SD-WAN це досить легко досягти, створивши відповідну централізовану політику, яка «склеїть» всі аспекти цільового сервісного ланцюжка в єдине ціле та автоматично змінить логіку data-plane та control-plane тільки там, де це необхідно.

Чи відпиляє Cisco SD-WAN сук, на якому сидить DMVPN?

Здатність сформувати георозподілену обробку трафіку обраних видів додатків у певній послідовності на спеціалізованому (але не має відношення до самої мережі SD-WAN) обладнанні – це, мабуть, найбільш наочна демонстрація переваг Cisco SD-WAN над класичними технологіями і навіть деякими альтернативними рішеннями SD -WAN інших виробників.

Що в підсумку?

Очевидно, що і DMVPN (спільно або без Performance Routing) та Cisco SD-WAN вирішують зрештою дуже схожі завдання по відношенню до розподіленої WAN мережі організації. При цьому суттєві архітектурні та функціональні відмінності технології Cisco SD-WAN виводять процес вирішення цих завдань на інший якісний рівень. Резюмуючи, можна відзначити такі значні відмінності технологій SD-WAN та DMVPN/PfR:

  • DMVPN/PfR загалом використовують перевірені часом технології побудови накладених VPN мереж і в частині data-plane схожі з більш сучасною SD-WAN технологією, при цьому є низка обмежень в особі обов'язкової статичної конфігурації маршрутизаторів та вибір топологій обмежений Hub-n-Spoke. З іншого боку, DMVPN/PfR має деякі функціональні можливості, які поки недоступні в рамках SD-WAN (мова про per-application BFD).
  • У рамках control-plane технології відрізняються принципово. З урахуванням централізованої обробки сигнальних протоколів SD-WAN дозволяє, зокрема, значно звузити домени відмови і «розв'язати» процес передачі трафіку користувача від сигнальної взаємодії – тимчасова недоступність контролерів не впливає на можливість передачі трафіку користувача. У той же час тимчасова недоступність будь-якої філії (у тому числі центральної) ніяк не впливає на можливість інших філій взаємодіяти один з одним і контролерами.
  • Архітектура формування та застосування політик управління трафіком у випадку SD-WAN також перевершує таку в DMVPN/PfR – значно краще реалізовано георезервування, немає прив'язки до Hub, більше можливостей щодо тонкого настроювання політик, список реалізованих сценаріїв управління трафіком також значно більший.
  • Процес оркестрації рішення також значно відрізняється. DMVPN передбачає наявність заздалегідь відомих параметрів, які мають бути якимось чином відображені у конфігурації, що дещо обмежує гнучкість рішення та можливість динамічних змін. У свою чергу SD-WAN виходить з парадигми, що в початковий момент підключення маршрутизатор «не знає нічого» про своїх контролерів, але знає «у кого можна запитати» – цього достатньо не тільки для автоматичного встановлення зв'язку з контролерами, але і для автоматичного формування повно зв'язкової data-plane топології, яку потім можна гнучко налаштувати/змінити за допомогою політик.
  • У частині централізованого управління, автоматизації та моніторингу SD-WAN очікувано перевершує можливості DMVPN/PfR, які стали результатом розвитку класичних технологій і більшою мірою покладаються на командний рядок CLI та застосування систем NMS на основі шаблонів.
  • У SD-WAN у порівнянні з DMVPN вимоги безпеки вийшли на інший якісний рівень. Головні принципи – нульова довіра, масштабованість та двофакторна автентифікація.

З цих нескладних висновків може скластися помилкове враження, що створення мережі на базі DMVPN/PfR втратило сьогодні будь-яку актуальність. Це, звісно, ​​не зовсім так. Наприклад, у випадках, коли на мережі використовується безліч застарілого обладнання і немає можливості його замінити, DMVPN може дозволити об'єднати "старі" та "нові" пристрої в єдину георозподілену мережу з великою кількістю описаних вище переваг.

З іншого боку, слід пам'ятати, що всі актуальні корпоративні маршрутизатори Cisco на базі IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) сьогодні підтримують будь-який режим роботи - і класичну маршрутизацію і DMVPN і SD-WAN - Вибір визначається поточними потребами та розумінням, що у будь-який момент на тому самому устаткуванні можна почати рухатися у бік більш просунутої технології.

Джерело: habr.com

Додати коментар або відгук