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

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

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

Съдържание

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

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

Откакто света съществува, дядовците ни проверяваха правилността на направените промени с остро око, стоманени нерви и работоспособността на мрежата след дейността им.
Тези дядовци, чиято работа водеше до принудителни паузи и катастрофични загуби, оставяха по-малко потомство и с времето трябваше да изчезнат, но еволюцията е бавен процес и затова все още не всички предварително проверяват промените в лаборатория.
Обаче на преден план са тези, които автоматизираха процеса на тестване на конфигурацията и последващото ѝ прилагане в мрежата. С други думи — прилагат процедура CI/CD (Непрекъсната интеграция, Непрекъснато внедряване) от разработчиците.
В една от частите ще разгледаме как да го реализираме с помощта на система за контрол на версиите, вероятно 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, Потребители, 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-сервер на всички бордери на региона.

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

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

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

Да регистрираме устройството в инвентарната система.
Да отделим IP адрес за управление.
Да настроим основен достъп до него:
Име на хост, 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.

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

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

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

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

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

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

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

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

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

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

С изключение на отладъчните команди, абсолютно всички промени в мрежата трябва да преминат през 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).