СДСМ закінчився, а безконтрольне бажання писати залишилося.
Довгі роки наш брат страждав від виконання рутинної роботи, схрещував пальці перед коммітом і недосипав через нічні ролбеки.
Але темним часом приходить кінець.
Цією статтею я почну серію про те, як мені бачиться автоматизація.
По ходу справи розберемося з етапами автоматизації, зберіганням змінних, формалізацією дизайну, з RestAPI, NETCONF, YANG, YDK і дуже багато програмуватимемо.
Мені означає, що а) це не об'єктивна істина; б) не беззастережно кращий підхід;
Зміст
- Цілі
- Мережа як єдиний організм
- Тестування конфігурації
- Версіонування
- Моніторинг та самовідновлення сервісів
- Засоби
- Інвентарна система
- Система управління IP-простором
- Система опису мережевих сервісів
- Механізм ініціалізації пристроїв
- Вендор-агност конфігураційна модель
- Вендор-інтерфейс специфічний драйвер
- Механізм доставки конфігурації на пристрій
- CI/CD
- Механізм резервного копіювання та пошуку відхилень
- Система моніторингу
- Висновок
АДСМ я спробую вести у форматі, трохи відмінному від СДСМ. Як і раніше будуть з'являтися великі ґрунтовні номерні статті, а між ними я публікуватиму невеликі нотатки з повсякденного досвіду. Намагатимуся тут боротися з перфекціонізмом і не вилизувати кожну з них.
Як це смішно, що вдруге доводиться проходити той самий шлях.
Спочатку довелося писати самому статті про мережі через те, що їх не було у рунеті.
Тепер я не зміг знайти всебічного документа, який би систематизував підходи до автоматизації і на простих практичних прикладах розбирав вищезазначені технології.
Можливо, я помиляюся, тому кидайте посилання на придатні ресурси. Втім, це не змінить моєї рішучості писати, тому що основна мета - це все-таки навчитися чогось самого, а полегшити життя ближньому - це приємний бонус, який пестить ген поширення досвіду.
Ми спробуємо взяти середніх розмірів дата-центр LAN DC та опрацювати всю схему автоматизації.
Робити деякі речі я практично вперше разом з вами.
У описуваних тут ідеях та інструментах я буду не оригінальний. У Дмитра Фіголя є чудовий .
Статті у багатьох аспектах з ними перетинатимуться.
У LAN DC 4 ДЦ, близько 250 комутаторів, півдюжини маршрутизаторів та пара файрволів.
Чи не фейсбук, але достатньо для того, щоб глибоко задуматися про автоматизацію.
Існує, втім, думка, що якщо у вас більше 1 пристрою, вже потрібна автоматизація.
Насправді важко уявити, що хтось зараз може жити без хоч би пачки наколінних скриптів.
Хоча я чув, що є такі контори, де облік IP-адрес ведеться в екселі, а кожен із тисяч мережевих пристроїв налаштовується вручну і має свою неповторну конфігурацію. Це, звичайно, можна видати за сучасне мистецтво, але почуття інженера точно ображаються.
Цілі
Зараз ми поставимо максимально абстрактні цілі:
- Мережа як єдиний організм
- Тестування конфігурації
- Версіонування стану мережі
- Моніторинг та самовідновлення сервісів
Пізніше в цій статті розберемо які використовуватимемо кошти, а в наступних і цілі та кошти в подробицях.
Мережа як єдиний організм
Визначальна фраза циклу, хоча на перший погляд вона може здатися не такою вже значною: ми будемо налаштовувати мережу, а не окремі пристрої.
Всі останні роки ми спостерігаємо зсув акцентів до того, щоб поводитися з мережею, як з єдиною сутністю, що звідси і приходять у наше життя Програмне забезпечення, визначене мережею, Intent Driven Networks и Autonomous Networks.
Адже що глобально потрібно додаткам від мережі: зв'язків між точками А і Б (ну іноді +В-Я) та ізоляції від інших додатків та користувачів.
І таким чином наше завдання в цій серії. вибудувати систему, що підтримує актуальну конфігурацію всієї мережі, яка вже декомпозується на актуальну конфігурацію на кожному пристрої відповідно до його ролі та місця розташування.
Система управління мережею має на увазі, що для внесення змін ми звертаємося до неї, а вона вже у свою чергу обчислює необхідний стан для кожного пристрою та налаштовує його.
Таким чином, ми мінімізуємо майже до нуля ходіння в CLI руками — будь-які зміни в налаштуваннях пристроїв або дизайні мережі повинні бути формалізовані та документовані — і лише потім викочуватися на потрібні елементи мережі.
Тобто, наприклад, якщо ми вирішили, що з цього моменту стійкові комутатори в Казані повинні анонсувати дві мережі замість однієї, ми
- Спочатку документуємо зміни у системах
- Генеруємо цільову конфігурацію всіх пристроїв мережі
- Запускаємо програму оновлення конфігурації мережі, яка обчислює, що потрібно видалити кожному вузлі, що додати, і призводить вузли до потрібного стану.
При цьому руками ми вносимо зміни лише на першому кроці.
Тестування конфігурації
, Що 80% проблем трапляються під час зміни конфігурації - непряме свідчення тому, що в період новорічних канікул зазвичай все спокійно.
Я особисто був свідком десятків глобальних даунтаймів через помилку людини: неправильна команда, не в тій галузі конфігурації виконали, забули ком'юніті, знесли MPLS глобально на маршрутизаторі, налаштували п'ять залізниць, а на шосту помилку не помітили, закоммітували старі зміни, зроблені іншою людиною . Сценаріїв темрява темрява.
Автоматика нам дозволить робити менше помилок, але у більшому масштабі. Так можна описати не один пристрій, а всю мережу разом.
Споконвіку наші діди перевіряли правильність змін, що вносяться гострим оком, сталевими яйцями і працездатністю мережі після їх викочування.
Ті діди, чиї роботи призводили до простих і катастрофічних збитків, залишали менше потомства і повинні згодом вимерти, але еволюція процес повільний, і тому досі не всі попередньо перевіряють зміни в лабораторії.
Однак на вістрі прогресу ті, хто автоматизував процес тестування конфігурації, та подальшого її застосування на мережу. Іншими словами - запозичив процедуру CI/CD () у розробників.
В одній із частин ми розглянемо, як реалізувати це за допомогою системи контролю версій, ймовірно, гітхабу.
Як тільки ви звикнетеся з думкою про мережеве CI/CD, одночасно спосіб перевірки зміни шляхом її використання на робочу мережу здасться вам ранньосередньовічних невіглаством. Приблизно як стукати молотком по боєголовку.
Органічним продовженням ідей про системі управління мережею та CI/CD стає повноцінне версіонування конфігурації.
Версіонування
Ми вважатимемо, що з будь-яких змінах, навіть самих незначних, навіть у одному непомітному пристрої, вся мережа перетворюється з одного стану на інший.
І ми завжди не виконуємо команду на пристрої, змінюємо стан мережі.
Ось давайте ці стани і називатимемо версіями?
Допустимо, поточна версія - 1.0.0.
Змінилася IP-адреса Loopback-інтерфейсу на одному з ToR'ів? Це мінорна версія – отримає номер 1.0.1.
Переглянули політики імпорту маршрутів до BGP – трохи серйозніші – вже 1.1.0
Вирішили позбутися IGP і перейти тільки на BGP – це вже радикальна зміна дизайну – 2.0.0.
При цьому різні ДЦ можуть мати різні версії — мережа розвивається, ставиться нове обладнання, десь додаються нові рівні спайнів, десь ні, ітд.
Про ми поговоримо у окремій статті.
Повторюся — будь-яка зміна (крім команд налагодження) — це оновлення версії. Про будь-які відхилення від актуальної версії повинні повідомлятися адміністратори.
Те саме стосується відкату змін - це не скасування останніх команд, це не rollback силами операційної системи пристрою - це приведення всієї мережі до нової (старої) версії.
Моніторинг та самовідновлення сервісів
Це самоочевидне завдання у сучасних мережах виходить на новий рівень.
Найчастіше у великих сервіс-провайдерів практикується підхід, що сервіс, що впав, треба дуже швидко добити і підняти новий, замість того, щоб розбиратися, що сталося.
"Дуже" означає, що з усіх боків потрібно рясно обмазатися моніторингами, які протягом секунд виявлять найменші відхилення від норми.
І тут вже мало звичних метрик, як завантаження інтерфейсу або доступності вузла. Недостатньо і ручного стеження чергового за ними.
Для багатьох речей взагалі має бути — моніторинги спалахнули червоним і пішли самі подорожник доклали, де болить.
І тут ми теж моніторимо не лише окремі пристрої, а й здоров'я мережі цілком, причому як вайтбокс, що порівняно зрозуміло, так і блекбокс, що складніше.
Що нам знадобиться для реалізації таких амбітних планів?
- Мати список всіх пристроїв у мережі, їх розташування, ролі, моделі, версії програмного забезпечення.
kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3. - Мати систему опису мережевих сервісів.
IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH. - Вміти ініціалізувати пристрій.
Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF - Налаштувати пристрій і конфігурувати до потрібної (в тому числі старої) версії.
- Тестувати конфігурацію
- Періодично перевіряти стан всіх пристроїв щодо відходження від актуального і повідомляти кому слід.
Вночі хтось тихенько додав правило до ACL. - Стежити за працездатністю.
Засоби
Звучить досить складно, щоб почати декомпозувати проект на компоненти.
І буде їх десять:
- Інвентарна система
- Система управління IP-простором
- Система опису мережевих сервісів
- Механізм ініціалізації пристроїв
- Вендор-агност конфігураційна модель
- Вендор-інтерфейс специфічний драйвер
- Механізм доставки конфігурації на пристрій
- CI/CD
- Механізм резервного копіювання та пошуку відхилень
- Система моніторингу
Це, до речі, приклад того, як змінювався погляд на цілі циклу – у чернетці компонентів було 4.
На ілюстрації я зобразив усі компоненти та власне пристрій.
Пересічні компоненти взаємодіють один з одним.
Чим більше блок, тим більше уваги потрібно приділити цьому компоненту.
Компонент 1. Інвентарна система
Очевидно, ми хочемо знати, яке обладнання де стоїть, до чого підключено.
Інвентарна система – невід'ємна частина будь-якого підприємства.
Найчастіше для мережевих пристроїв підприємство має окрему інвентарну систему, яка вирішує більш специфічні завдання.
У рамках циклу статей ми називатимемо це DCIM — Data Center Infrastructure Management. Хоча сам термін DCIM, строго кажучи, включає набагато більше.
Для наших завдань у ній ми зберігатимемо наступну інформацію про пристрій:
- Інвентарний номер
- Назва/опис
- Модель (Huawei CE12800, Juniper QFX5120 ітд)
- Характерні параметри (плати, інтерфейси тощо)
- Роль (Leaf, Spine, Border Router ітд)
- Локацію (регіон, місто, дата-центр, стійка, юніт)
- Інтерконнекти між пристроями
- Топологію мережі
Чудово зрозуміло, що нам самим хочеться знати це все.
Але чи це допоможе з метою автоматизації?
Безумовно.
Наприклад, ми знаємо, що в даному центрі на Leaf-комутаторах, якщо це Huawei, ACL для фільтрації певного трафіку повинні застосовуватися на VLAN, а якщо це Juniper — то на unit 0 фізичного інтерфейсу.
Або потрібно розкотити новий Syslog-сервер на всі бордери регіону.
У ній ми зберігатимемо віртуальні мережеві пристрої, наприклад віртуальні маршрутизатори чи рут-рефлектори. Можемо додати DNS-сервера, NTP, Syslog і взагалі все, що так чи інакше стосується мережі.
Компонент 2. Система управління IP-простором
Так, і в наш час знаходяться колективи людей, які ведуть облік префіксів та IP-адрес в Excel-файлі. Але сучасний підхід — це база даних, з фронтендом на nginx/apache, API і широкими функціями з урахуванням IP-адрес і мереж з поділом на VRF.
IPAM - IP Address Management.
Для наших завдань у ній ми зберігатимемо наступну інформацію:
- VLAN
- Розширення VRF
- Мережі/Підмережі
- IP-адреси
- Прив'язка адрес до пристроїв, мереж до локацій та номерів VLAN
Знову ж таки зрозуміло, що ми хочемо бути впевнені, що, виділяючи нову IP-адресу для лупбека ToR'а, ми не спіткнемося про те, що вона вже була комусь призначена. Або що той самий префікс ми використовували двічі в різних кінцях мережі.
Але як це допоможе автоматизації?
Легко.
Запитуємо в системі префікс за участю Loopbacks, у якому є доступні виділення IP-адреси — якщо він знаходиться, виділяємо адресу, якщо ні, запитуємо створення нового префікса.
Або при створенні конфігурації пристрою ми з цієї системи можемо дізнатися, в якому VRF повинен знаходитися інтерфейс.
А при запуску нового сервера скрипт сходить в систему, дізнається в якому сервері світчі, в якому порту і яка підмережа призначена на інтерфейс - з нього і виділятиме адресу сервера.
Напрошується бажання DCIM та IPAM об'єднати в одну систему, щоб не дублювати функції та не обслуговувати дві схожі сутності.
Так ми зробимо.
Компонент 3. Система опису мережевих сервісів
Якщо перші дві системи зберігають змінні, які потрібно якось використовувати, то третя описує кожної ролі пристрою, як і має бути налаштовано.
Варто виділити два різні типи мережевих сервісів:
- Інфраструктурні
- Клієнтські.
Перші покликані забезпечити базову зв'язність та керування пристроєм. Сюди можна зарахувати VTY, SNMP, NTP, Syslog, AAA, протоколи маршрутизації, CoPP ітд.
Другі організують послугу клієнта: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP тощо.
Зрозуміло, є й прикордонні випадки, куди віднести MPLS LDP, BGP? Та й протоколи маршрутизації можуть використовуватись для клієнтів. Але це важливо.
Обидва типи сервісів розкладаються на конфігураційні примітиви:
- фізичні та логічні інтерфейси (тег/антег, mtu)
- IP-адреси та VRF (IP, IPv6, VRF)
- ACL та політики обробки трафіку
- Протоколи (IGP, BGP, MPLS)
- Політики маршрутизації (префікс-листи, ком'юніті, ASN-фільтри).
- Службові послуги (SSH, NTP, LLDP, Syslog ...)
- І т.д.
Як саме ми це робитимемо, я поки що розуму не докладу. Розберемося в окремій статті.
Якщо трохи ближче до життя, ми могли б описати, що
Leaf-комутатор повинен мати BGP-сесії з усіма підключеними Spine-комутаторами, імпортувати в процес підключені мережі, приймати від Spine-комутаторів тільки мережі з певного префікса. Обмежувати CoPP IPv6 ND до 10 pps і т.д.
У свою чергу спайни тримають сесії з усіма підключеними ліфами, виступаючи як рут-рефлектори, і приймають від них тільки маршрути певної довжини і з певним комуніті.
Компонент 4. Механізм ініціалізації пристрою
Під цим заголовком я об'єдную безліч дій, які мають статися, щоб пристрій з'явився на радарах і на нього можна було потрапити віддалено.
- Завести пристрій у інвентарній системі.
- Виділити IP-адресу керування.
- Налаштувати базовий доступ до нього:
Hostname, IP-адреса управління, маршрут у мережу управління, користувачі, SSH-ключі, протоколи - telnet/SSH/NETCONF
Тут є три підходи:
- Повністю все вручну. Пристрій привозять на стенд, де звичайна органічна людина, заведе його до системи, підключиться консоллю та налаштує. Може спрацювати на невеликих статичних мережах.
- ZTP - Zero Touch Provisioning. Залізо приїхало, встало, по DHCP отримало адресу, сходило на спеціальний сервер, самонастроилося.
- Інфраструктура консольних серверів, де первинне налаштування відбувається через консольний порт у автоматичному режимі.
Про всі три поговоримо в окремій статті.
Компонент 5. Вендор-агностик конфігураційна модель
Досі всі системи були розрізненими клаптями, що давали змінні та декларативний опис того, що ми хотіли б бачити на мережі. Але рано чи пізно доведеться мати справу з конкретикою.
На цьому етапі для кожного конкретного пристрою примітиви, послуги та змінні комбінуються в конфігураційну модель, що фактично описує повну конфігурацію конкретного пристрою, тільки в вендронезалежній манері.
Що дає цей крок? Чому б одразу не формувати конфігурацію пристрою, яку можна просто залити?
Насправді це дозволяє вирішити три завдання:
- Не підлаштовуватись під конкретний інтерфейс взаємодії з пристроєм. Будь то CLI, NETCONF, RESTCONF, SNMP – модель буде однаковою.
- Не тримати кількість шаблонів/скриптів за кількістю вендорів в мережі, і в разі зміни дизайну, змінювати те саме в декількох місцях.
- Завантажувати конфігурацію з пристрою (бекапу), розкладати її в таку саму модель і безпосередньо порівнювати між собою цільову конфігурацію і наявну для обчислення дельти і підготовки конфігураційного патча, який змінить ті частини, які необхідно або для виявлення відхилень.
В результаті цього етапу ми отримуємо вендоронезалежну конфігурацію.
Компонент 6. Вендор-інтерфейс специфічний драйвер
Не варто тішити себе надіями на те, що колись налаштовувати циску можна буде так само, як джуніпер, просто відправивши на них абсолютно однакові виклики. Незважаючи на whitebox'и, що набирають популярність, і на появу підтримки NETCONF, RESTCONF, OpenConfig, конкретний контент, який цими протоколами доставляється, відрізняється від вендора до вендора, і це одна з їх конкурентних відмінностей, яку вони так просто не здадуть.
Це приблизно так само, як OpenContrail і OpenStack, що мають RestAPI в якості свого NorthBound-інтерфейсу, очікують різні виклики.
Отже, на п'ятому кроці вендоронезалежна модель має прийняти ту форму, в якій вона поїде на залізо.
І тут всі засоби хороші (ні): CLI, NETCONF, RESTCONF, SNMP про простий спад.
Тому нам знадобиться драйвер, який результат попереднього кроку перекладе у потрібний формат конкретного вендора: набір CLI команд, структуру XML.
Компонент 7. Механізм доставки конфігурації на пристрій
Конфігурацію ми згенерували, але її ще потрібно доставити на пристрої - і, очевидно, не руками.
По-перше, Перед нами тут постає питання, який транспорт будемо використовувати? А вибір на сьогодні вже не маленький:
- CLI (telnet, ssh)
- SNMP
- NETCONF
- RESTCONF
- REST API
- OpenFlow (хоча він зі списку і вибивається, оскільки це спосіб доставити FIB, а не налаштування)
Давайте тут розставимо крапки над ним. CLI - це легаси. SNMP… кхе-кхе.
RESTCONF - ще поки невідоме звірятко, REST API підтримується майже ніким. Тому ми у циклі зосередимося на NETCONF.
Насправді, як уже зрозумів читач, з інтерфейсом ми на цей момент вже визначилися — результат попереднього кроку вже представлено у форматі того інтерфейсу, який було обрано.
По-друге, а якими інструментами ми це робитимемо?
Тут вибір також великий:
- Самописний скрипт чи платформа. Озброїмося ncclient та asyncIO і самі все зробимо. Що нам варте, систему деплойменту з нуля побудувати?
- Ansible з його багатою бібліотекою мережевих модулів.
- Salt з його мізерною роботою з мережею та зв'язкою з Napalm.
- Власне Napalm, який знає пару вендорів і все до побачення.
- Nornir — ще одне звірятко, яке ми препаруємо в майбутньому.
Тут ще фаворит не обраний – шупатимемо.
Що тут ще важливе? Наслідки застосування конфігурації.
Успішно чи ні. Залишився доступ на залізницю чи ні.
Здається, тут допоможе commit з підтвердженням і валідацією того, що пристрій завантажили.
Це разом із правильною реалізацією NETCONF значно звужує коло відповідних пристроїв - нормальні коміти підтримують не так багато виробників. Але це просто одна з обов'язкових умов у . Зрештою ніхто не переживає, що жоден російський вендор не пройде за умови 32*100GE інтерфейсу. Чи переживає?
Компонент 8. CI/CD
До цього моменту ми вже готова конфігурація на всі пристрої мережі.
Я пишу «на все», тому що ми говоримо про версію стану мережі. І навіть якщо потрібно змінити налаштування всього лише одного світчу, прораховуються зміни для всієї мережі. Очевидно, вони можуть бути при цьому нульовими для більшості вузлів.
Але, як уже було сказано, вище, ми ж не варвари якісь, щоб котити все одразу в прод.
Згенерована конфігурація має спочатку пройти через Pipeline CI/CD.
CI/CD означає Continuous Integration, Continuous Deployment. Це підхід, за якого команда не раз на півроку викладає новий мажорний реліз, повністю замінюючи старий, а регулярно інкрементально впроваджує (Deployment) нову функціональність невеликими порціями, кожну з яких всебічно тестує на сумісність, безпеку та працездатність (Integration).
Для цього у нас є система контролю версій, яка стежить за змінами конфігурації, лабораторія, на якій перевіряється, чи не ламається клієнтський сервіс, система моніторингу, яка перевіряє цей факт, і останній крок — викочування змін до робочої мережі.
За винятком налагоджувальних команд, абсолютно всі зміни на мережі повинні пройти через CI/CD Pipeline – це наша запорука спокійного життя та довгої кар'єри.
Компонент 9. Система резервного копіювання та пошуку відхилень
Ну про бекапи вкотре говорити не доводиться.
Будемо просто їх за кроном або за фактом зміни конфігурації в гіт складати.
А ось друга частина цікавіша — за цими бекапами хтось має доглядати. І в одних випадках цей хтось повинен піти і повертати все, як було, а в інших, м'якнути комусь, про те, що непорядок.
Наприклад, якщо з'явився якийсь новий користувач, який не прописаний у змінних, потрібно від хака його видалити. А якщо нове файрвільне правило — краще не чіпати, можливо, хтось просто налагодження включив, а може новий сервіс, розтяпа, не за регламентом прописав, а в нього вже люди пішли.
Від якоїсь невеликої дельти в масштабах всієї мережі ми все одно не втечемо, незважаючи на будь-які системи автоматизації та сталеву руку керівництва. Для налагодження проблем все одно ніхто конфігурацію не вноситиме в системи. Тим більше що їх може навіть не передбачати модель конфігурації.
Наприклад, файрвільне правило для підрахунку числа пакетів на певний IP, для локалізації проблеми — звичайна тимчасова конфігурація.
Компонент 10. Система моніторингу
Спочатку я не збирався висвітлювати тему моніторингу — все ж таки об'ємна, спірна і складна тема. Але під час справи виявилося, що це невід'ємна частина автоматизації. І оминути її стороною хоча б навіть без практики не можна.
Розвиваючи думку – це органічна частина процесу CI/CD. Після викочування конфігурації на мережу, нам потрібно вміти визначити, а чи все з нею тепер гаразд.
І мова не тільки і не стільки про графіки використання інтерфейсів або доступність вузлів, скільки про більш тонкі речі — наявність потрібних маршрутів, атрибутів на них, кількість BGP-сесій, OSPF-сусідів, End-to-End працездатності сервісів.
А чи не перестали складатися сислоги на зовнішній сервер, а чи не зламався чи SFlow-агент, а чи не почали рости дропи в чергах, а чи не порушилася зв'язність між якоюсь парою префіксів?
В окремій статті ми поміркуємо над цим.
Висновок
Як основу я вибрав один із сучасних дизайнів датацентрової мережі — L3 Clos Fabric з BGP як протокол маршрутизації.
Будувати мережу ми цього разу на Juniper, тому що тепер інтерфейс JunOs - це ванлав.
Ускладнимо собі життя використанням тільки Open Source інструментів та мультивендорною мережею — тому крім джуніпер по ходу справи виберу ще одного щасливчика.
План найближчих публікацій приблизно такий:
Спочатку я розповім про віртуальні мережі. Насамперед, тому що мені хочеться, а по-друге, тому що без цього дизайн інфраструктурної мережі буде не дуже зрозумілий.
Потім саме про дизайн мережі: топологію, маршрутизацію, політики.
Зберемо лабораторний стенд.
Поміркуємо і може попрактикуємося в ініціалізації пристрою в мережі.
А далі про кожен компонент в інтимних подробицях.
І так, я не обіцяю витончено закінчити цей цикл готовим рішенням. 🙂
Корисні посилання
- Перед тим, як заглиблюватись у серію, варто почитати книгу Наташі Самойленко . А можливо, і пройти .
- Корисним буде також почитати про дизайн датацентрових фабрик від Фейсбуку за авторством Петра Лапухова
- Про те, як працює Overlay'ний SDN вам дасть представлення документація з архітектури (Раніше Open Contrail).
Дякую
Роман Горга. За коментарі та редагування.
Артем Чорнобай. За КДПВ.
Джерело: habr.com