СДСМ приключи, но неконтролируемото желание за писане остана.

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

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

Съдържание

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

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

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

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

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

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

Цели

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

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

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

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

Определящата фраза на цикъла, макар на пръв поглед да изглежда незначителна: ще настройваме мрежата, а не отделни устройства.
През последните години наблюдаваме изменение на акцентите към това да се отнасяме към мрежата като към единна същност, оттук и идващите в живота ни Software Defined Networking, Intent Driven Networks и Autonomous Networks.
В крайна сметка, какво глобално е нужно на приложенията от мрежата: свързаност между точки А и Б (понякога +В-Я) и изолация от други приложения и потребители.

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

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

Първо документираме промените в системите

Генерираме целевата конфигурация на всичките устройства в мрежата

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

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

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

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

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

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

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

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

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

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

Различните ЦОД могат да имат различни версии - мрежата се развива, поставя се ново оборудване, на някои места се добавят нови нива спайнове, на други - не и т.н.

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

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

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

Мониторинг и самовъзстановяване на услугите

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

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

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

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

Средства

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

И те ще са десет:

Инвентарна система
Система за управление на IP пространството
Система за описание на мрежовите услуги
Механизъм за инициализация на устройства
Вендор-агностична конфигурационна модел
Вендор-интерфейс специфичен драйвер
Механизъм за доставка на конфигурацията на устройството
CI/CD
Механизъм за резервно копиране и откритие на отклонения
Система за мониторинг

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

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

Компонент 1. Инвентарна система

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

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

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

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

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

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

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

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

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 и др.
От своя страна спайновете поддържат сесии с всички свързани листа, действат като root рефлектори и приемат от тях само маршрути с определена дължина и с определена общност.

Компонент 4. Механизъм за инициализация на устройството

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

Да регистрираме устройството в инвентарната система.
Да зададете IP адрес за управление.
Да настроите базов достъп до него:
Hostname, IP адрес за управление, маршрут до мрежата за управление, потребители, SSH ключове, протоколи — telnet/SSH/NETCONF

Тук съществуват три подхода:

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

За трите ще поговорим в отделна статия.

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

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

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

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

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

Не трябва да се самозаблуждавате с надежди, че в бъдеще настройването на Cisco може да се прави по същия начин, както при Juniper, просто изпращайки абсолютно идентични команди. Независимо от нарастващата популярност на 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.

Наистина, както вече разбра читателят, с интерфейса вече сме се определили – резултатът от предишната стъпка е представен в формата на избрания интерфейс.

, MLFQ се опитва, а с какви инструменти ще го направим?
Тук изборът също е голям:

Собствен скрипт или платформа. Да се снабдим с ncclient и asyncIO и сами да направим всичко. Какво ни пречи да изградим системата за деплоймънт от нулата?
Ansible с богатата си библиотека от мрежови модули.
Salt с ограничените си възможности за работа с мрежата и връзката с Napalm.
Собственно Napalm, който познава само няколко доставчици и това е. Сбогом.
Nornir – още едно животно, което ще анализираме в бъдеще.

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

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

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

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

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

CI/CD означава Continuous Integration, Continuous Deployment. Това е подход, при който екипът не публикува нова основна версия на всеки шест месеца, изцяло заменяйки старата, а редовно внедрява нова функционалност на малки порции, всяка от които се тества изцяло за съвместимост, безопасност и работоспособност.

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

С изключение на отстраняващите грешки команди, абсолютно всички промени в мрежата трябва да преминат през 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, документацията по архитектурата Tungsten Fabric (преди Open Contrail) ще ви даде представа.