СДСМ свърши, но неудържимото желание за писане остава.

В продължение на много години нашият брат страдаше от рутинна работа, стискаше палци, преди да се ангажира и нямаше сън поради нощни връщания назад.
Но мрачните времена са към своя край.

С тази статия ще започна поредица за това как ми вижда се автоматизация.
По пътя ще разберем етапите на автоматизация, съхраняване на променливи, формализиране на дизайна, RestAPI, NETCONF, YANG, YDK и ще направим много програмиране.
Ми означава, че а) не е обективна истина, б) не е безусловно най-добрият подход, в) мнението ми, дори по време на движението от първата към последната статия, може да се промени - честно казано, от етапа на чернова до публикация, пренаписах всичко напълно два пъти.

Съдържание

1. цели
   1. Мрежата е като единен организъм
   2. Тестване на конфигурацията
   3. Версиониране
   4. Мониторинг и самолечение на услугите

2. Средства
   1. Система за инвентаризация
   2. Система за управление на IP пространство
   3. Система за описание на мрежови услуги
   4. Механизъм за инициализация на устройството
   5. Модел на конфигурация, независим от доставчика
   6. Специфичен за производителя интерфейс на драйвера
   7. Механизъм за доставяне на конфигурация към устройството
   8. CI / CD
   9. Механизъм за архивиране и търсене на отклонения
   10. Система за наблюдение

3. Заключение

Ще се опитам да проведа ADSM във формат, малко по-различен от SDSM. Ще продължат да излизат големи, подробни, номерирани статии, а между тях ще публикувам малки бележки от ежедневния опит. Ще се опитам да се боря с перфекционизма тук и няма да оближа всеки един от тях.

Колко смешно е, че втори път трябва да минеш по същия път.

Първоначално трябваше сам да пиша статии за мрежите поради факта, че те не бяха достъпни в RuNet.

Сега не можах да намеря изчерпателен документ, който да систематизира подходите за автоматизация и да анализира горните технологии, използвайки прости практически примери.

Може да греша, така че моля, дайте връзки към полезни ресурси. Това обаче няма да промени решимостта ми да пиша, защото основната цел е аз да науча нещо, а да улеснявам живота на другите е приятен бонус, който гали гена за споделяне на опит.

Ще се опитаме да вземем среден по размер LAN DC център за данни и да разработим цялата схема за автоматизация.
С вас ще правя някои неща почти за първи път.

Няма да бъда оригинален в описаните тук идеи и инструменти. Дмитрий Фигол има отличен канал с потоци по тази тема.
Статиите ще се припокриват с тях в много аспекти.

LAN DC има 4 DC, около 250 комутатора, половин дузина рутери и няколко защитни стени.
Не Facebook, но достатъчно, за да ви накара да се замислите дълбоко за автоматизацията.
Има обаче мнение, че ако имате повече от 1 устройство, автоматизацията вече е необходима.
Всъщност е трудно да си представим, че сега някой може да живее без поне пакет скриптове за коляно.
Въпреки че чух, че има офиси, където IP адресите се съхраняват в Excel и всяко от хилядите мрежови устройства се конфигурира ръчно и има своя уникална конфигурация. Това, разбира се, може да се приеме за модерно изкуство, но чувствата на инженера определено ще бъдат обидени.

цели

Сега ще поставим най-абстрактните цели:

• Мрежата е като единен организъм
• Тестване на конфигурацията
• Версиране на състоянието на мрежата
• Мониторинг и самолечение на услугите

По-нататък в тази статия ще разгледаме какви средства ще използваме, а в следващите ще разгледаме подробно целите и средствата.

Мрежата е като единен организъм

Определящата фраза на поредицата, въпреки че на пръв поглед може да не изглежда толкова значима: ние ще конфигурираме мрежата, а не отделни устройства.
През последните години наблюдаваме изместване на акцента към третирането на мрежата като единно цяло, следователно Софтуерно дефинирани мрежи, Мрежи, управлявани от намерение и Автономни мрежи.
В крайна сметка, от какво се нуждаят приложенията глобално от мрежата: свързаност между точки A и B (е, понякога +B-Z) и изолация от други приложения и потребители.

И така, нашата задача в тази серия е изгради система, запазвайки текущата конфигурация цялата мрежа, който вече е декомпозиран в действителната конфигурация на всяко устройство в съответствие с неговата роля и местоположение.
Система управлението на мрежата предполага, че за извършване на промени ние се свързваме с него, а той от своя страна изчислява желаното състояние за всяко устройство и го конфигурира.
По този начин минимизираме ръчния достъп до CLI до почти нула - всички промени в настройките на устройството или мрежовия дизайн трябва да бъдат формализирани и документирани - и едва след това да бъдат разгърнати до необходимите мрежови елементи.

Това е, например, ако решим, че отсега нататък комутаторите за стелажи в Казан трябва да обявяват две мрежи вместо една, ние

1. Първо документираме промените в системите
2. Генериране на целевата конфигурация на всички мрежови устройства
3. Стартираме програмата за актуализиране на мрежовата конфигурация, която изчислява какво трябва да се премахне на всеки възел, какво да се добави и привежда възлите в желаното състояние.

В същото време ние правим промени ръчно само в първата стъпка.

Тестване на конфигурацията

Известно ече 80% от проблемите възникват при промени в конфигурацията - косвено доказателство за това е, че по време на новогодишните празници всичко обикновено е спокойно.
Лично съм бил свидетел на десетки глобални прекъсвания поради човешка грешка: грешна команда, конфигурацията е изпълнена в грешен клон, общността е забравила, MPLS е разрушен глобално на рутера, пет хардуерни части са конфигурирани, но грешката не е забелязано на шестия, стари промени, направени от друго лице, са извършени. Има много сценарии.

Автоматизацията ще ни позволи да правим по-малко грешки, но в по-голям мащаб. По този начин можете да блокирате не само едно устройство, а цялата мрежа наведнъж.

От незапомнени времена нашите дядовци са проверявали правилността на направените промени с набито око, стоманени топки и функционалността на мрежата след пускането им.
Тези дядовци, чиято работа е довела до прекъсване и катастрофални загуби, са оставили по-малко потомство и трябва да изчезнат с времето, но еволюцията е бавен процес и следователно не всеки все още тества промените първо в лабораторията.
Но в челните редици на напредъка са тези, които са автоматизирали процеса на тестване на конфигурацията и нейното по-нататъшно приложение в мрежата. С други думи, взех назаем процедурата CI/CD (Непрекъсната интеграция, непрекъснато внедряване) от разработчиците.
В една от частите ще разгледаме как да приложим това с помощта на система за контрол на версиите, вероятно Github.

След като свикнете с идеята за мрежови CI/CD, за една нощ методът за проверка на конфигурация чрез прилагането й към производствена мрежа ще изглежда като ранно средновековно невежество. Нещо като удряне на бойна глава с чук.

Органично продължение на идеите за система управлението на мрежата и CI/CD става пълна версия на конфигурацията.

Версиониране

Ще приемем, че с всякакви промени, колкото и малки да са, дори на едно незабележимо устройство, цялата мрежа преминава от едно състояние в друго.
И винаги не изпълняваме команда на устройството, а променяме състоянието на мрежата.
Така че нека наречем тези състояния версии?

Да приемем, че текущата версия е 1.0.0.
Променен ли е IP адресът на Loopback интерфейса на едно от ToRs? Това е второстепенна версия и ще бъде номерирана 1.0.1.
Ревизирахме политиките за импортиране на маршрути в BGP - малко по-сериозно - вече 1.1.0
Решихме да се отървем от IGP и да преминем само към BGP - това вече е радикална промяна в дизайна - 2.0.0.

В същото време различните DC могат да имат различни версии - мрежата се развива, инсталира се ново оборудване, някъде се добавят нови нива на шипове, а не в други и т.н.

Около семантична версия ще говорим в отделна статия.

Повтарям - всяка промяна (с изключение на командите за отстраняване на грешки) е актуализация на версията. Администраторите трябва да бъдат уведомени за всякакви отклонения от текущата версия.

Същото важи и за връщане назад на промените - това не е анулиране на последните команди, това не е връщане назад с помощта на операционната система на устройството - това е привеждане на цялата мрежа към нова (стара) версия.

Мониторинг и самолечение на услугите

Тази самоочевидна задача достигна ново ниво в съвременните мрежи.
Често големите доставчици на услуги възприемат подхода, че една неуспешна услуга трябва да бъде поправена много бързо и да бъде създадена нова, вместо да разберат какво се е случило.
„Много“ означава, че трябва да бъдете щедро покрити от всички страни с мониторинг, който за секунди ще открие и най-малките отклонения от нормата.
И тук обичайните показатели, като зареждане на интерфейса или наличност на възел, вече не са достатъчни. Не е достатъчно и ръчното им наблюдение от дежурния.
За много неща трябва да има Самолечение — контролните светлини светнаха червени и ние отидохме и сами наложихме живовляка там, където ни болеше.

И тук също наблюдаваме не само отделни устройства, но и здравето на цялата мрежа, както whitebox, което е относително разбираемо, така и blackbox, което е по-сложно.

Какво ще ни е необходимо, за да реализираме толкова амбициозни планове?

• Имате списък с всички устройства в мрежата, тяхното местоположение, роли, модели, версии на софтуера.
  kazan-leaf-1.lmu.net, Казан, лист, Juniper QFX 5120, R18.3.
• Имате система за описание на мрежовите услуги.
  IGP, BGP, L2/3VPN, Политика, ACL, NTP, SSH.
• Да може да инициализира устройството.
  Име на хост, Mgmt IP, Mgmt Route, потребители, RSA-ключове, LLDP, NETCONF
• Конфигурирайте устройството и пренесете конфигурацията до желаната (включително стара) версия.
• Тестова конфигурация
• Периодично проверявайте състоянието на всички устройства за отклонения от текущите и докладвайте на кого трябва.
  През нощта някой тихо добави правило към ACL.
• Наблюдавайте производителността.

Средства

Звучи достатъчно сложно, за да започнете да разлагате проекта на компоненти.

И ще има десет от тях:

1. Система за инвентаризация
2. Система за управление на IP пространство
3. Система за описание на мрежови услуги
4. Механизъм за инициализация на устройството
5. Модел на конфигурация, независим от доставчика
6. Специфичен за производителя интерфейс на драйвера
7. Механизъм за доставяне на конфигурация към устройството
8. CI / CD
9. Механизъм за архивиране и търсене на отклонения
10. Система за наблюдение

Това, между другото, е пример за това как се промени мнението за целите на цикъла - в проекта имаше 4 компонента.

На илюстрацията изобразих всички компоненти и самото устройство.
Пресичащите се компоненти взаимодействат един с друг.
Колкото по-голям е блокът, толкова повече внимание трябва да се обърне на този компонент.

Компонент 1: Система за инвентаризация

Очевидно искаме да знаем какво оборудване къде се намира, към какво е свързано.
Системата за инвентаризация е неразделна част от всяко предприятие.
Най-често едно предприятие има отделна система за инвентаризация на мрежови устройства, която решава по-специфични проблеми.
Като част от тази поредица от статии, ние ще го наречем DCIM - Data Center Infrastructure Management. Въпреки че самият термин DCIM, строго погледнато, включва много повече.

За нашите цели ще съхраняваме следната информация за устройството в него:

• Инвентарен номер
• Заглавие/Описание
• Модел (Huawei CE12800, Juniper QFX5120 и др.)
• Характерни параметри (платки, интерфейси и др.)
• Роля (Leaf, Spine, Border Router и др.)
• местоположение (регион, град, център за данни, шкаф, единица)
• Връзки между устройства
• Мрежова топология

Съвършено ясно е, че ние самите искаме да знаем всичко това.
Но това ще помогне ли за целите на автоматизацията?
Разбира се.
Например, ние знаем, че в даден център за данни на комутатори Leaf, ако е Huawei, ACL за филтриране на определен трафик трябва да се прилагат към VLAN, а ако е Juniper, тогава към модул 0 на физическия интерфейс.
Или трябва да пуснете нов Syslog сървър до всички граници в региона.

В него ще съхраняваме виртуални мрежови устройства, например виртуални рутери или коренни рефлектори. Можем да добавим DNS сървъри, NTP, Syslog и изобщо всичко, което по един или друг начин е свързано с мрежата.

Компонент 2: Система за управление на IP пространство

Да, и в днешно време има екипи от хора, които следят префиксите и IP адресите в Excel файл. Но съвременният подход все още е база данни с преден край на nginx/apache, API и обширни функции за запис на IP адреси и мрежи, разделени на VRF.
IPAM - Управление на IP адреси.

За нашите цели ние ще съхраняваме следната информация в него:

• VLAN
• VRF разширение
• Мрежи/подмрежи
• IP адреси
• Свързване на адреси към устройства, мрежи към местоположения и VLAN номера

Отново е ясно, че искаме да сме сигурни, че когато разпределяме нов IP адрес за ToR loopback, няма да се натъкнем на факта, че той вече е бил присвоен на някого. Или че сме използвали един и същ префикс два пъти в различни краища на мрежата.
Но как това помага за автоматизацията?
Това е лесно.
Искаме префикс в системата с роля Loopbacks, който съдържа IP адреси, достъпни за разпределение - ако бъде намерен, ние разпределяме адреса, ако не, изискваме създаване на нов префикс.
Или когато създаваме конфигурация на устройство, можем да разберем от същата система в кой VRF трябва да се намира интерфейсът.
И когато стартирате нов сървър, скриптът влиза в системата, открива в кой суич е сървърът, кой порт и коя подмрежа е присвоена на интерфейса - и ще разпредели адреса на сървъра от него.

Това предполага желание за комбиниране на DCIM и IPAM в една система, за да не се дублират функции и да не се обслужват два подобни обекта.
Това ще направим.

Компонент 3. Система за описание на мрежови услуги

Ако първите две системи съхраняват променливи, които все още трябва да се използват по някакъв начин, тогава третата описва за всяка роля на устройство как трябва да бъде конфигурирана.
Струва си да се разграничат два различни вида мрежови услуги:

• Инфраструктура
• Клиент.

Първите са предназначени да осигурят основна свързаност и контрол на устройството. Те включват VTY, SNMP, NTP, Syslog, AAA, протоколи за маршрутизиране, CoPP и др.
Последните организират услугата за клиента: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP и др.
Разбира се, има и гранични случаи - къде да включа MPLS LDP, BGP? Да, и протоколите за маршрутизиране могат да се използват за клиенти. Но това не е важно.

И двата типа услуги се разлагат на конфигурационни примитиви:

• физически и логически интерфейси (tag/anteg, 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: Механизъм за инициализация на устройството

Под това заглавие комбинирам много от действията, които трябва да се случат, за да може дадено устройство да се появи на радара и да бъде достъпно от разстояние.

1. Въведете устройството в системата за инвентаризация.
2. Изберете IP адрес за управление.
3. Настройте основен достъп до него:
   Име на хост, IP адрес за управление, маршрут до мрежата за управление, потребители, SSH ключове, протоколи - telnet/SSH/NETCONF

Има три подхода:

• Всичко е изцяло ръчно. Устройството се довежда до щанда, където обикновен органичен човек ще го въведе в системите, ще се свърже с конзолата и ще го конфигурира. Може да работи в малки статични мрежи.
• ZTP - Zero Touch Provisioning. Хардуерът пристигна, изправи се, получи адрес през DHCP, отиде на специален сървър и се конфигурира.
• Инфраструктурата на конзолните сървъри, където първоначалната конфигурация се извършва през конзолния порт в автоматичен режим.

Ще говорим и за трите в отделна статия.

Компонент 5: Модел на конфигурация, независим от доставчика

Досега всички системи бяха различни пачове, които предоставят променливи и декларативно описание на това, което бихме искали да видим в мрежата. Но рано или късно ще трябва да се справите със спецификата.
На този етап за всяко конкретно устройство примитивите, услугите и променливите се комбинират в конфигурационен модел, който всъщност описва пълната конфигурация на конкретно устройство, само по неутрален от доставчика начин.
Какво прави тази стъпка? Защо не създадете веднага конфигурация на устройство, която можете просто да качите?
Всъщност това решава три проблема:

1. Не се адаптирайте към конкретен интерфейс за взаимодействие с устройството. Независимо дали става въпрос за CLI, NETCONF, RESTCONF, SNMP - моделът ще бъде същият.
2. Не пазете броя на шаблоните/скриптовете според броя на доставчиците в мрежата и ако дизайнът се промени, променете едно и също нещо на няколко места.
3. Заредете конфигурацията от устройството (резервно копие), поставете я в точно същия модел и директно сравнете целевата конфигурация със съществуващата, за да изчислите делта и да подготвите конфигурационна корекция, която ще промени само онези части, които са необходими, или за идентифициране на отклонения.

В резултат на този етап получаваме независима от доставчика конфигурация.

Компонент 6. Специфичен за производителя интерфейс на драйвера

Не трябва да се ласкаете с надежди, че един ден ще бъде възможно да конфигурирате ciska по абсолютно същия начин като Juniper, просто като изпратите точно същите обаждания до тях. Въпреки нарастващата популярност на whiteboxes и появата на поддръжка за 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 със своята богата библиотека от мрежови модули.
• Сол с оскъдната си работа с мрежата и връзката с Napalm.
• Всъщност Napalm, който познава няколко продавача и това е, сбогом.
• Nornir е друго животно, което ще направим дисекция в бъдеще.

Тук фаворитът все още не е избран - ще търсим.

Какво друго е важно тук? Последици от прилагането на конфигурацията.
Успешно или не. Има ли все още достъп до хардуера или не?
Изглежда, че commit ще помогне тук с потвърждение и валидиране на това, което е изтеглено на устройството.
Това, съчетано с правилното внедряване на NETCONF, значително стеснява кръга от подходящи устройства - не много производители поддържат нормални ангажименти. Но това е само една от предпоставките в RFP. В крайна сметка никой не се притеснява, че нито един руски доставчик няма да изпълни условието за интерфейс 32*100GE. Или е притеснен?

Компонент 8. CI/CD

На този етап вече имаме готова конфигурация за всички мрежови устройства.
Пиша „за всичко“, защото говорим за версия на състоянието на мрежата. И дори ако трябва да промените настройките само на един комутатор, промените се изчисляват за цялата мрежа. Очевидно те могат да бъдат нула за повечето възли.

Но, както вече беше казано по-горе, ние не сме някакви варвари, които искат да пуснат всичко направо в производство.
Генерираната конфигурация трябва първо да премине през Pipeline CI/CD.

CI/CD означава непрекъсната интеграция, непрекъснато внедряване. Това е подход, при който екипът не само пуска ново основно издание на всеки шест месеца, като напълно заменя старото, но редовно постепенно внедрява (внедряване) нова функционалност на малки порции, всяка от които е изчерпателно тествана за съвместимост, сигурност и производителност (Интеграция).

За да направим това, имаме система за контрол на версиите, която следи промените в конфигурацията, лаборатория, която проверява дали клиентската услуга е повредена, система за мониторинг, която проверява този факт, и последната стъпка е въвеждането на промени в производствената мрежа.

С изключение на командите за отстраняване на грешки, абсолютно всички промени в мрежата трябва да преминат през CI/CD Pipeline - това е нашата гаранция за спокоен живот и дълга, щастлива кариера.

Компонент 9. Система за архивиране и откриване на аномалии

Е, няма нужда да говорим отново за резервни копия.
Ние просто ще ги поставим в git според короната или при факта на промяна на конфигурацията.

Но втората част е по-интересна - някой трябва да следи тези резервни копия. И в някои случаи този някой трябва да отиде и да обърне всичко както си е било, а в други да мяука на някого, че нещо не е наред.
Например, ако се появи нов потребител, който не е регистриран в променливите, трябва да го премахнете от хака. И ако е по-добре да не докосвате ново правило на защитната стена, може би някой току-що е включил отстраняването на грешки или може би новата услуга, неразбирател, не е регистрирана според разпоредбите, но хората вече са се присъединили към нея.

Все още няма да избягаме от някаква малка делта в мащаба на цялата мрежа, въпреки всички системи за автоматизация и стоманената ръка на управлението. За отстраняване на грешки, така или иначе никой няма да добави конфигурация към системите. Освен това те може дори да не са включени в конфигурационния модел.

Например, правило на защитната стена за преброяване на броя на пакетите за конкретен IP за локализиране на проблем е напълно обикновена временна конфигурация.

Компонент 10. Система за мониторинг

Първоначално нямах намерение да засягам темата за мониторинга – все пак това е обемна, противоречива и сложна тема. Но с напредването на нещата се оказа, че това е неразделна част от автоматизацията. И е невъзможно да го заобиколите, дори без практика.

Развиващата се мисъл е органична част от процеса на CI/CD. След като пуснем конфигурацията в мрежата, трябва да можем да определим дали всичко е наред с нея сега.
И говорим не само и не толкова за графици за използване на интерфейса или наличност на възли, а за по-фини неща - наличие на необходимите маршрути, атрибути върху тях, брой BGP сесии, OSPF съседи, End-to-End производителност на надлежащите услуги.
Системните журнали към външния сървър спряха ли да се събират, или агентът SFlow се повреди, или спадовете в опашките започнаха да растат, или връзката между някои двойки префикси се развали?

Ще разсъждаваме върху това в отделна статия.

Заключение

Като основа избрах един от съвременните мрежови проекти на центрове за данни - L3 Clos Fabric с BGP като протокол за маршрутизиране.
Този път ще изградим мрежата на Juniper, защото сега интерфейсът на JunOs е много важен.

Нека направим живота си по-труден, като използваме само инструменти с отворен код и мрежа от множество доставчици - така че в допълнение към Juniper, ще избера още един късметлия по пътя.

Планът за предстоящите публикации е нещо подобно:
Първо ще говоря за виртуалните мрежи. Първо, защото искам, и второ, защото без това проектът на инфраструктурната мрежа няма да е много ясен.
След това за самия дизайн на мрежата: топология, маршрутизиране, политики.
Да сглобим лабораторен стенд.
Нека помислим за това и може би да практикуваме инициализиране на устройството в мрежата.
И след това за всеки компонент в интимни подробности.

И да, не обещавам да завърша грациозно този цикъл с готово решение. 🙂

Полезни връзки

• Преди да се задълбочите в поредицата, струва си да прочетете книгата на Наташа Самойленко Python за мрежови инженери. И може би ще мине курс.
• Ще бъде полезно и за четене RFC за дизайна на фабрики за центрове за данни от Facebook от Петър Лапухов.
• Архитектурната документация ще ви даде представа как работи Overlay SDN. Волфрамова тъкан (по-рано Open Contrail).

Благодаря

Римско дефиле. За коментари и редакции.
Артьом Чернобай. За KDPV.

Източник: www.habr.com