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

Нашиот брат долги години страдаше од рутинска работа, прекрстувајќи ги прстите пред да се обврзе и не спиеше поради ноќните превртувања.
Но, на црните времиња им доаѓа крајот.

Со оваа статија ќе започнам серија за тоа како ме се гледа автоматизација.
Попатно, ќе ги разбереме фазите на автоматизација, складирање на променливи, формализирање на дизајнот, RestAPI, NETCONF, YANG, YDK и ќе направиме многу програмирање.
Мене значи дека а) не е објективна вистина, б) не е безусловно најдобриот пристап, в) моето мислење, дури и за време на движењето од првиот до последниот член, може да се промени - да бидам искрен, од фазата на нацрт до објавување, јас пренапишав сè целосно двапати.

содржина

1. Цели
   1. Мрежата е како единствен организам
   2. Конфигурациско тестирање
   3. Верзија
   4. Следење и самозаздравување на услугите

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

3. Заклучок

Ќе се обидам да го водам АДСМ во формат малку поинаков од СДСМ. Ќе продолжат да се појавуваат големи, детални, нумерирани написи, а меѓу нив ќе објавувам мали белешки од секојдневното искуство. Ќе се обидам да се борам со перфекционизмот овде и да не го лижам секој од нив.

Колку е смешно што по втор пат треба да поминеш низ истиот пат.

Отпрвин морав сам да пишувам статии за мрежите поради фактот што тие не беа на RuNet.

Сега не можев да најдам сеопфатен документ кој ќе ги систематизира пристапите кон автоматизација и ќе ги анализира горенаведените технологии користејќи едноставни практични примери.

Можеби грешам, затоа ве молиме дајте линкови до корисни ресурси. Сепак, ова нема да ја промени мојата решеност да пишувам, бидејќи главната цел е да научам нешто самиот, а олеснувањето на животот на другите е пријатен бонус кој го гали генот за споделување искуство.

Ќе се обидеме да земеме центар за податоци на LAN DC со средна големина и да ја разработиме целата шема за автоматизација.
Речиси првпат ќе правам некои работи со тебе.

Нема да бидам оригинален во идеите и алатките опишани овде. Дмитриј Фигол има одличен канал со стримови на оваа тема.
Статиите ќе се преклопуваат со нив во многу аспекти.

LAN DC има 4 DC, околу 250 прекинувачи, половина дузина рутери и неколку заштитни ѕидови.
Не Фејсбук, но доволно за да ве натера да размислите длабоко за автоматизацијата.
Сепак, постои мислење дека ако имате повеќе од 1 уред, веќе е потребна автоматизација.
Всушност, тешко е да се замисли дека некој сега може да живее без барем пакет скрипти за колена.
Иако слушнав дека има канцеларии каде што се чуваат IP адресите во Excel, а секој од илјадниците мрежни уреди е рачно конфигуриран и има своја единствена конфигурација. Ова, се разбира, може да се пренесе како модерна уметност, но чувствата на инженерот дефинитивно ќе бидат навредени.

Цели

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

• Мрежата е како единствен организам
• Конфигурациско тестирање
• Верзија на мрежна состојба
• Следење и самозаздравување на услугите

Подоцна во оваа статија ќе погледнеме кои средства ќе ги користиме, а во продолжение детално ќе ги разгледаме целите и средствата.

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

Дефинитивната фраза на серијата, иако на прв поглед можеби не изгледа толку значајна: ќе ја конфигурираме мрежата, а не поединечни уреди.
Во последниве години, видовме промена во акцентот кон третирање на мрежата како единствен ентитет, па оттука и Вмрежување дефинирано со софтвер, Мрежи водени од намери и Автономни мрежи.
На крајот на краиштата, што им треба глобално на апликациите од мрежата: поврзување помеѓу точките A и B (добро, понекогаш + B-Z) и изолација од други апликации и корисници.

И така нашата задача во оваа серија е изгради систем, одржување на тековната конфигурација целата мрежа, кој е веќе распаднат во вистинската конфигурација на секој уред во согласност со неговата улога и локација.
Систем управувањето со мрежата подразбира дека за да направиме промени, го контактираме, а тој, пак, ја пресметува саканата состојба за секој уред и го конфигурира.
На овој начин, го минимизираме рачниот пристап до CLI на речиси нула - сите промени во поставките на уредот или мрежниот дизајн мора да се формализираат и документираат - и дури потоа да се пренесат на потребните мрежни елементи.

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

1. Прво ги документираме промените во системите
2. Генерирање на целната конфигурација на сите мрежни уреди
3. Ја стартуваме програмата за ажурирање на конфигурацијата на мрежата, која пресметува што треба да се отстрани од секој јазол, што да се додаде и ги доведува јазлите во саканата состојба.

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

Конфигурациско тестирање

Познато едека 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.

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

на семантичка верзија ќе зборуваме во посебна статија.

Повторувам - секоја промена (освен за команди за дебагирање) е ажурирање на верзијата. Администраторите мора да бидат известени за какви било отстапувања од тековната верзија.

Истото важи и за враќање на промените - ова не е откажување на последните команди, ова не е враќање со користење на оперативниот систем на уредот - ова ја доведува целата мрежа до нова (стара) верзија.

Следење и самозаздравување на услугите

Оваа самоочигледна задача достигна ново ниво во современите мрежи.
Честопати, големите даватели на услуги заземаат пристап дека неуспешната услуга треба да се поправи многу брзо и да се подигне нова, наместо да сфатат што се случило.
„Многу“ значи дека треба да бидете великодушно обложени од сите страни со мониторинг, кој во рок од неколку секунди ќе открие и најмали отстапувања од нормата.
И тука вообичаените метрики, како што се вчитувањето на интерфејсот или достапноста на јазлите, веќе не се доволни. Не е доволно ниту рачно следење на нив од страна на дежурниот.
За многу работи треба да има Само-лекување — светлата за мониторинг станаа црвени и отидовме и самите ја нанесовме хлебните каде што болеше.

И тука, исто така, ги следиме не само поединечните уреди, туку и здравјето на целата мрежа, и whitebox, што е релативно разбирливо, и blackbox, што е покомплицирано.

Што ќе ни треба за спроведување на вакви амбициозни планови?

• Имајте список на сите уреди на мрежата, нивната локација, улоги, модели, верзии на софтвер.
  kazan-leaf-1.lmu.net, Kazan, лист, Juniper QFX 5120, R18.3.
• Имајте систем за опишување мрежни услуги.
  IGP, BGP, L2/3VPN, политика, ACL, NTP, SSH.
• Бидете во можност да го иницијализирате уредот.
  Име на домаќин, Mgmt IP, Mgmt рута, корисници, RSA-Keys, LLDP, NETCONF
• Конфигурирајте го уредот и доведете ја конфигурацијата до саканата (вклучувајќи ја и старата) верзија.
• Тест конфигурација
• Периодично проверувајте го статусот на сите уреди за отстапувања од сегашните и известувајте кому треба да биде.
  Преку ноќ, некој тивко додаде правило на ACL.
• Следете ги перформансите.

Средства

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

И ќе има десет од нив:

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

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

На илустрацијата ги прикажав сите компоненти и самиот уред.
Пресечните компоненти комуницираат едни со други.
Колку е поголем блокот, толку повеќе внимание треба да се посвети на оваа компонента.

Компонента 1: Систем за залихи

Очигледно, сакаме да знаеме која опрема каде се наоѓа, со што е поврзано.
Системот за попис е составен дел на секое претпријатие.
Најчесто, претпријатието има посебен систем за залихи на мрежни уреди, кој решава поспецифични проблеми.
Како дел од оваа серија написи, ќе го наречеме DCIM - Управување со инфраструктурата на центарот за податоци. Иако самиот термин DCIM, строго кажано, вклучува многу повеќе.

За наши цели, ќе ги складираме следните информации за уредот во него:

• Инвентар број
• Наслов/Опис
• Модел (Huawei CE12800, Juniper QFX5120, итн.)
• Карактеристични параметри (табли, интерфејси итн.)
• Улога (Лист, 'рбет, граничен рутер итн.)
• Локација (регион, град, центар за податоци, багажник, единица)
• Меѓусебни врски помеѓу уредите
• Топологија на мрежата

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

Во него ќе складираме виртуелни мрежни уреди, на пример виртуелни рутери или root рефлектори. Можеме да додадеме 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? Да, и протоколите за рутирање може да се користат за клиенти. Но, ова не е важно.

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

• физички и логички интерфејси (ознака/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 клучеви, протоколи - телнет/SSH/NETCONF

Постојат три пристапи:

• Сè е целосно рачно. Уредот се носи на штандот, каде што обичен органски човек ќе го внесе во системите, ќе се поврзе со конзолата и ќе го конфигурира. Може да работи на мали статични мрежи.
• ZTP - Обезбедување со нула допир. Хардверот пристигна, стана, доби адреса преку DHCP, отиде на посебен сервер и се конфигурираше.
• Инфраструктурата на серверите на конзолата, каде што почетната конфигурација се случува преку пристаништето на конзолата во автоматски режим.

Ќе зборуваме за сите три во посебна статија.

Компонента 5: Добавувач-агностички конфигурациски модел

Досега, сите системи беа различни закрпи кои обезбедуваат променливи и декларативен опис на она што би сакале да го видиме на мрежата. Но, порано или подоцна, ќе треба да се справите со спецификите.
Во оваа фаза, за секој специфичен уред, примитивите, услугите и променливите се комбинираат во конфигурациски модел кој всушност ја опишува целосната конфигурација на одреден уред, само на начин неутрален за продавачот.
Што прави овој чекор? Зошто веднаш да не креирате конфигурација на уредот што едноставно можете да ја поставите?
Всушност, ова решава три проблеми:

1. Не се прилагодувајте на специфичен интерфејс за интеракција со уредот. Било да е CLI, NETCONF, RESTCONF, SNMP - моделот ќе биде ист.
2. Не чувајте го бројот на шаблони/скрипти според бројот на продавачи на мрежата и доколку се промени дизајнот, менувајте го истото на неколку места.
3. Вчитајте ја конфигурацијата од уредот (резервна копија), ставете ја во истиот модел и директно споредете ја целната конфигурација со постоечката за да се пресмета делта и да се подготви конфигурациска лепенка што ќе ги промени само оние делови што се неопходни или ќе ги идентификува отстапувањата.

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

Компонента 6. Интерфејс за возачот специфичен за продавачот

Не треба да се додворувате со надежи дека еден ден ќе биде можно да конфигурирате циска на ист начин како Juniper, едноставно со испраќање на истите повици до нив. И покрај зголемената популарност на whiteboxes и појавата на поддршка за NETCONF, RESTCONF, OpenConfig, специфичната содржина што ја испорачуваат овие протоколи се разликува од продавач до продавач и ова е една од нивните конкурентни разлики од која нема да се откажат така лесно.
Ова е приближно исто како OpenContrail и OpenStack, кои имаат RestAPI како NorthBound интерфејс, очекуваат сосема различни повици.

Значи, во петтиот чекор, моделот независен од продавачот мора да ја има формата во која ќе оди на хардвер.
И тука сите средства се добри (не): CLI, NETCONF, RESTCONF, SNMP едноставно.

Затоа, ќе ни треба драјвер кој ќе го пренесе резултатот од претходниот чекор во потребниот формат на одреден продавач: збир на команди CLI, структура XML.

Компонента 7. Механизам за доставување на конфигурација на уредот

Ја генериравме конфигурацијата, но сепак треба да се достави до уредите - и, очигледно, не рачно.
Прво, соочени сме со прашањето каков превоз ќе користиме? И денес изборот веќе не е мал:

• CLI (телнет, ssh)
• SNMP
• NETCONF
• RESTCONF
• ОСТАНАТОТО API
• OpenFlow (иако тоа е необично бидејќи е начин да се испорача FIB, а не поставки)

Ајде да ставиме точка на t е тука. CLI е наследство. SNMP... кашлица кашлица.
RESTCONF е сè уште непознато животно; REST API е поддржан од речиси никој. Затоа, ќе се фокусираме на NETCONF во серијата.

Всушност, како што читателот веќе разбра, до овој момент веќе одлучивме за интерфејсот - резултатот од претходниот чекор е веќе претставен во форматот на интерфејсот што беше избран.

Второ, и со какви алатки ќе го направиме ова?
Тука има и голем избор:

• Самонапишано сценарио или платформа. Да се ​​вооружиме со ncclient и asyncIO и да направиме сè сами. Што не чини да изградиме систем за распоредување од нула?
• Ansible со својата богата библиотека на мрежни модули.
• Солта со својата скудна работа со мрежата и поврзаноста со Напалм.
• Всушност Напалм, кој познава неколку продавачи и тоа е тоа, збогум.
• Норнир е уште едно животно што ќе го сецираме во иднина.

Овде фаворит се уште не е избран - ќе бараме.

Што друго е важно овде? Последици од примена на конфигурацијата.
Успешно или не. Дали сè уште има пристап до хардверот или не?
Се чини дека commit ќе помогне овде со потврда и валидација на преземеното на уредот.
Ова, во комбинација со правилната имплементација на NETCONF, значително го стеснува опсегот на соодветни уреди - не многу производители поддржуваат нормални обврски. Но, ова е само еден од предусловите во RFP. На крајот, никој не е загрижен дека ниту еден руски продавач нема да се усогласи со условот за интерфејс 32*100GE. Или е загрижен?

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

Во овој момент, веќе ја имаме подготвената конфигурација за сите мрежни уреди.
Пишувам „за сè“ затоа што зборуваме за верзија на состојбата на мрежата. И дури и ако треба да ги промените поставките на само еден прекинувач, промените се пресметуваат за целата мрежа. Очигледно, тие можат да бидат нула за повеќето јазли.

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

CI/CD е кратенка за континуирана интеграција, континуирано распоредување. Ова е пристап во кој тимот не само што објавува ново големо издание на секои шест месеци, целосно заменувајќи го старото, туку редовно постепено имплементира (Делокација) нова функционалност во мали делови, од кои секоја е сеопфатно тестирана за компатибилност, безбедност и перформанси (Интеграција).

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

Со исклучок на командите за дебагирање, апсолутно сите промени на мрежата мора да поминат низ CI/CD Pipeline - ова е нашата гаранција за мирен живот и долга, среќна кариера.

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

Па, нема потреба повторно да зборуваме за резервни копии.
Едноставно ќе ги додадеме на круната или по фактот за промена на конфигурацијата во git.

Но, вториот дел е поинтересен - некој треба да внимава на овие резервни копии. А во некои случаи овој мора да оди и да сврти сè како што било, а во други да мјаука некому дека нешто не е во ред.
На пример, ако се појави нов корисник кој не е регистриран во променливите, треба да го отстраните од хакирањето. И ако е подобро да не допирате ново правило за заштитен ѕид, можеби некој штотуку вклучил дебагирање, или можеби новата услуга, бунглер, не била регистрирана според прописите, но луѓето веќе се приклучиле.

Сè уште нема да избегаме од мала делта на обемот на целата мрежа, и покрај сите системи за автоматизација и челичната рака на управување. За да се дебагира проблемите, никој и онака нема да додаде конфигурација на системите. Покрај тоа, тие можеби дури и не се вклучени во моделот за конфигурација.

На пример, правилото на заштитен ѕид за броење на бројот на пакети по одредена IP адреса за локализирање на проблемот е сосема обична привремена конфигурација.

Компонента 10. Систем за следење

Отпрвин немав да ја покривам темата за мониторинг - тоа е сепак обемна, контроверзна и сложена тема. Но, како што напредуваа работите, се покажа дека ова е составен дел од автоматизацијата. И тоа е невозможно да се заобиколи, дури и без пракса.

Развојната мисла е органски дел од процесот на CI/CD. Откако ќе ја вклучиме конфигурацијата на мрежата, треба да можеме да утврдиме дали сè е во ред со неа сега.
И не зборуваме само и не толку за распоредите за користење интерфејс или достапноста на јазлите, туку за посуптилните работи - присуството на потребните правци, атрибутите на нив, бројот на BGP сесии, соседите на OSPF, перформансите од крај до крај. на надредените услуги.
Дали системските логови на надворешниот сервер престанаа да се собираат, или агентот SFlow се расипа, или капките во редиците почнаа да растат или се прекина поврзувањето помеѓу некои пар префикси?

Ќе размислиме за ова во посебна статија.

Заклучок

Како основа, избрав еден од модерните дизајни на мрежи на центри за податоци - L3 Clos Fabric со BGP како протокол за рутирање.
Овој пат ќе ја изградиме мрежата на Juniper, бидејќи сега JunOs интерфејсот е vanlove.

Да ни го направиме животот потежок користејќи само алатки со отворен код и мрежа со повеќе продавачи - па покрај Juniper, ќе изберам уште една среќна личност на патот.

Планот за претстојните публикации е отприлика вака:
Прво ќе зборувам за виртуелните мрежи. Прво, затоа што сакам, и второ, затоа што без ова, дизајнот на инфраструктурната мрежа нема да биде многу јасен.
Потоа за самиот дизајн на мрежата: топологија, рутирање, политики.
Ајде да собереме лабораториски штанд.
Ајде да размислиме и можеби да вежбаме иницијализирање на уредот на мрежата.
А потоа за секоја компонента во интимни детали.

И да, не ветувам дека грациозно ќе го завршам овој циклус со готово решение. 🙂

Корисни линкови

• Пред да навлеземе во серијата, вреди да се прочита книгата на Наташа Самоиленко Пајтон за мрежни инженери. И можеби ќе помине се разбира.
• Исто така, ќе биде корисно да се прочита RFC за дизајнот на фабриките за центри за податоци од Фејсбук од Питер Лапухов.
• Документацијата за архитектура ќе ви даде идеја за тоа како работи Overlay SDN. Волфрамска ткаенина (порано Open Contrail).

Ви благодарам

Римската клисура. За коментари и уредувања.
Артјом Чернобај. За KDPV.

Извор: www.habr.com