SDSM skončilo, ale neovladatelná touha psát zůstává.

Po mnoho let náš bratr trpěl rutinní prací, překračoval si prsty, než se zavázal, a nespal kvůli nočním návratům.
Ale temné časy se chýlí ke konci.

Tímto článkem začnu sérii o tom, jak na to mě je vidět automatizace.
Po cestě pochopíme fáze automatizace, ukládání proměnných, formalizaci designu, RestAPI, NETCONF, YANG, YDK a budeme dělat spoustu programování.
Mě znamená, že a) nejde o objektivní pravdu, b) nejde o bezpodmínečně nejlepší přístup, c) můj názor se i během přesunu od prvního k poslednímu článku může změnit - upřímně řečeno od fáze návrhu k publikaci jsem vše přepsal úplně dvakrát.

Obsah

1. Cíle
   1. Síť je jako jediný organismus
   2. Testování konfigurace
   3. Verzování
   4. Monitoring a self-healing služeb

2. Fondy
   1. Systém zásob
   2. Systém správy IP prostoru
   3. Systém popisu síťových služeb
   4. Mechanismus inicializace zařízení
   5. Konfigurační model bez ohledu na dodavatele
   6. Rozhraní ovladače specifické pro dodavatele
   7. Mechanismus pro dodání konfigurace do zařízení
   8. CI / CD
   9. Mechanismus zálohování a vyhledávání odchylek
   10. Monitorovací systém

3. Závěr

Pokusím se provést ADSM ve formátu mírně odlišném od SDSM. Nadále se budou objevovat velké, podrobné, číslované články a mezi nimi budu uveřejňovat drobné poznámky z každodenní zkušenosti. Pokusím se zde bojovat s perfekcionismem a nelízat každého z nich.

Jak vtipné je, že podruhé musíte projít stejnou cestou.

Nejprve jsem musel články o sítích psát sám, protože nebyly na RuNetu.

Nyní jsem nenašel ucelený dokument, který by systematizoval přístupy k automatizaci a analyzoval výše uvedené technologie na jednoduchých praktických příkladech.

Možná se mýlím, proto prosím uveďte odkazy na užitečné zdroje. Na mém odhodlání psát to však nic nezmění, protože hlavním cílem je sám se něco naučit a ulehčit život ostatním je příjemný bonus, který pohladí gen pro sdílení zkušeností.

Pokusíme se vzít středně velké datové centrum LAN DC a vypracovat celé schéma automatizace.
Některé věci s vámi budu dělat téměř poprvé.

Nebudu originální ve zde popsaných nápadech a nástrojích. Dmitrij Figol má vynikající kanál se streamy na toto téma.
Články se s nimi budou v mnoha ohledech překrývat.

LAN DC má 4 DC, asi 250 přepínačů, půl tuctu routerů a pár firewallů.
Ne Facebook, ale dost na to, abyste se nad automatizací hluboce zamysleli.
Existuje však názor, že pokud máte více než 1 zařízení, automatizace je již nutná.
Ve skutečnosti je těžké si představit, že někdo nyní může žít bez alespoň balíku skriptů pro kolena.
I když jsem slyšel, že existují kanceláře, kde jsou IP adresy vedeny v Excelu a každé z tisíců síťových zařízení je konfigurováno ručně a má svou jedinečnou konfiguraci. To lze samozřejmě vydávat za moderní umění, ale inženýrovy pocity budou rozhodně uraženy.

Cíle

Nyní si stanovíme ty nejabstraktnější cíle:

• Síť je jako jediný organismus
• Testování konfigurace
• Verze stavu sítě
• Monitoring a self-healing služeb

Později v tomto článku se podíváme na to, jaké prostředky použijeme, a v následujícím se podrobně podíváme na cíle a prostředky.

Síť je jako jediný organismus

Definující fráze série, i když se na první pohled nemusí zdát tak významná: budeme konfigurovat síť, ne jednotlivá zařízení.
V posledních letech jsme byli svědky posunu v důrazu na zacházení se sítí jako s jedinou entitou, a proto Softwarově definované sítě, Sítě řízené záměrem и Autonomní sítě.
Ostatně, co aplikace globálně od sítě potřebují: konektivitu mezi body A a B (no, někdy +B-Z) a izolaci od ostatních aplikací a uživatelů.

A tak zní náš úkol v této sérii vybudovat systém, zachování aktuální konfigurace celou síť, který je již na každém zařízení rozložen do skutečné konfigurace v souladu s jeho rolí a umístěním.
systém správa sítě znamená, že abychom provedli změny, kontaktujeme ji a ona zase vypočítá požadovaný stav pro každé zařízení a nakonfiguruje je.
Tímto způsobem minimalizujeme manuální přístup do CLI téměř na nulu – jakékoli změny v nastavení zařízení nebo návrhu sítě je nutné formalizovat a zdokumentovat – a teprve poté zavést na potřebné síťové prvky.

Tedy pokud bychom se například rozhodli, že od nynějška by rackové přepínače v Kazani měly oznamovat dvě sítě místo jedné, my

1. Nejprve dokumentujeme změny v systémech
2. Generování cílové konfigurace všech síťových zařízení
3. Spustíme program aktualizace konfigurace sítě, který vypočítá, co je potřeba na každém uzlu odebrat, co přidat a uzly uvést do požadovaného stavu.

Změny přitom provádíme ručně pouze v prvním kroku.

Testování konfigurace

Je známože 80% problémů se vyskytuje při změnách konfigurace - nepřímým důkazem toho je, že během novoročních svátků je obvykle vše v klidu.
Osobně jsem byl svědkem desítek globálních výpadků kvůli lidské chybě: špatný příkaz, konfigurace byla provedena ve špatné větvi, komunita zapomněla, MPLS bylo globálně zničeno na routeru, bylo nakonfigurováno pět kusů hardwaru, ale chyba nebyla zaznamenali šestého, byly spáchány staré změny provedené jinou osobou. Scénářů je tuna.

Automatizace nám umožní dělat méně chyb, ale ve větším měřítku. Tímto způsobem můžete cihlovat nejen jedno zařízení, ale celou síť najednou.

Od nepaměti naši dědové kontrolovali správnost provedených změn bystrým okem, ocelové koule a funkčnost sítě po jejich vyvalení.
Ti dědové, jejichž práce vedla k prostojům a katastrofálním ztrátám, zanechali méně potomků a měli by časem vymřít, ale evoluce je pomalý proces, a proto ne každý stále testuje změny nejprve v laboratoři.
V čele pokroku však stojí ti, kteří zautomatizovali proces testování konfigurace a její další aplikace do sítě. Jinými slovy, vypůjčil jsem si postup CI/CD (Průběžná integrace, průběžné nasazování) od vývojářů.
V jednom z dílů se podíváme na to, jak to implementovat pomocí systému správy verzí, pravděpodobně Github.

Jakmile si zvyknete na myšlenku síťového CI/CD, bude vám metoda kontroly konfigurace její aplikací na produkční síť přes noc připadat jako raně středověká ignorance. Něco jako udeřit kladivem do hlavice.

Organické pokračování myšlenek o Systém správa sítě a CI/CD se stávají plnou verzí konfigurace.

Verzování

Budeme předpokládat, že při jakýchkoli změnách, i těch nejmenších, i na jednom nepostřehnutelném zařízení, se celá síť přesune z jednoho stavu do druhého.
A vždy neprovádíme příkaz na zařízení, ale měníme stav sítě.
Nazvěme tedy tyto stavy verzemi?

Řekněme, že aktuální verze je 1.0.0.
Změnila se IP adresa rozhraní Loopback na jednom z ToR? Toto je vedlejší verze a bude mít číslo 1.0.1.
Revidovali jsme zásady pro import tras do BGP – trochu vážněji – již ve verzi 1.1.0
Rozhodli jsme se zbavit IGP a přejít pouze na BGP – to už je radikální změna designu – 2.0.0.

Současně mohou mít různé DC různé verze - síť se vyvíjí, instaluje se nové zařízení, někde se přidávají nové úrovně páteře, v jiných ne atd.

O sémantické verzování si povíme v samostatném článku.

Opakuji - jakákoliv změna (kromě ladicích příkazů) je aktualizací verze. Administrátoři musí být upozorněni na jakékoli odchylky od aktuální verze.

Totéž platí pro vrácení změn zpět - nejedná se o zrušení posledních příkazů, nejedná se o vrácení zpět pomocí operačního systému zařízení - jde o uvedení celé sítě do nové (staré) verze.

Monitoring a self-healing služeb

Tento samozřejmý úkol dosáhl v moderních sítích nové úrovně.
Velcí poskytovatelé služeb často volí přístup, že neúspěšnou službu je třeba velmi rychle opravit a vytvořit novou, místo aby zjišťovali, co se stalo.
„Velmi“ znamená, že musíte být ze všech stran velkoryse pokryti monitorováním, které během několika sekund odhalí sebemenší odchylky od normy.
A zde již obvyklé metriky, jako je načítání rozhraní nebo dostupnost uzlů, nestačí. Nestačí ani jejich ruční sledování ze strany služebního úředníka.
Pro mnoho věcí by tam mělo být Samoléčení – monitorovací světla zčervenala a my jsme šli a sami si aplikovali jitrocel tam, kde to bolelo.

A zde také sledujeme nejen jednotlivá zařízení, ale i zdraví celé sítě, jak whitebox, což je poměrně pochopitelné, tak blackbox, který je složitější.

Co budeme potřebovat k realizaci tak ambiciózních plánů?

• Mějte seznam všech zařízení v síti, jejich umístění, role, modely, verze softwaru.
  kazan-leaf-1.lmu.net, Kazan, list, Juniper QFX 5120, R18.3.
• Mít systém pro popis síťových služeb.
  IGP, BGP, L2/3VPN, Zásady, ACL, NTP, SSH.
• Umět inicializovat zařízení.
  Název hostitele, Mgmt IP, Mgmt Route, uživatelé, RSA-Keys, LLDP, NETCONF
• Nakonfigurujte zařízení a převeďte konfiguraci na požadovanou (včetně staré) verze.
• Testovací konfigurace
• Pravidelně kontrolujte stav všech zařízení, zda nevykazují odchylky od aktuálních a hlásíte, komu by to mělo být.
  Přes noc někdo v tichosti přidal pravidlo do ACL.
• Sledujte výkon.

Fondy

Zní to dost složitě na to, abyste začali projekt rozkládat na komponenty.

A bude jich deset:

1. Systém zásob
2. Systém správy IP prostoru
3. Systém popisu síťových služeb
4. Mechanismus inicializace zařízení
5. Konfigurační model bez ohledu na dodavatele
6. Rozhraní ovladače specifické pro dodavatele
7. Mechanismus pro dodání konfigurace do zařízení
8. CI / CD
9. Mechanismus zálohování a vyhledávání odchylek
10. Monitorovací systém

To je mimochodem ukázka toho, jak se změnil pohled na cíle cyklu – v draftu byly 4 komponenty.

Na obrázku jsem znázornil všechny komponenty a samotné zařízení.
Protínající se komponenty se vzájemně ovlivňují.
Čím větší blok, tím větší pozornost je třeba věnovat této komponentě.

Komponenta 1: Systém zásob

Samozřejmě chceme vědět, jaké zařízení se kde nachází, k čemu je připojeno.
Inventární systém je nedílnou součástí každého podniku.
Podnik má nejčastěji samostatný inventární systém pro síťová zařízení, který řeší specifičtější problémy.
V rámci této série článků to nazveme DCIM – Data Center Infrastructure Management. I když samotný pojem DCIM, přísně vzato, zahrnuje mnohem více.

Pro naše účely v něm uložíme následující informace o zařízení:

• Číslo inventáře
• Název/Popis
• Modelka (Huawei CE12800, Juniper QFX5120 atd.)
• Charakteristické parametry (desky, rozhraní atd.)
• Role (List, páteř, hraniční směrovač atd.)
• Místo (region, město, datové centrum, stojan, jednotka)
• Propojení mezi zařízeními
• Topologie sítě

Je naprosto jasné, že tohle všechno chceme vědět i my sami.
Ale pomůže to pro účely automatizace?
Jistě.
Například víme, že v daném datovém centru na přepínačích Leaf, pokud je to Huawei, by měly být ACL pro filtrování určitého provozu aplikovány na VLAN, a pokud je to Juniper, pak na jednotce 0 fyzického rozhraní.
Nebo potřebujete zavést nový server Syslog na všechny hranice v regionu.

V něm budeme ukládat virtuální síťová zařízení, například virtuální routery nebo kořenové reflektory. Můžeme přidat DNS servery, NTP, Syslog a obecně vše, co se tak či onak týká sítě.

Komponenta 2: Systém správy IP prostoru

Ano, a v dnešní době existují týmy lidí, kteří sledují prefixy a IP adresy v souboru aplikace Excel. Moderní přístup je ale stále databáze, s front-endem na nginx/apache, API a rozsáhlými funkcemi pro záznam IP adres a sítí rozdělených do VRF.
IPAM - Správa IP adres.

Pro naše účely v něm uložíme následující informace:

• VLAN
• VRF
• Sítě/podsítě
• IP adresy
• Vazba adres na zařízení, sítě na umístění a čísla VLAN

Opět je jasné, že se chceme ujistit, že když přidělujeme novou IP adresu pro smyčku ToR, nezakopneme o to, že už byla někomu přidělena. Nebo že jsme použili stejnou předponu dvakrát na různých koncích sítě.
Ale jak to pomůže s automatizací?
Je to snadné.
V systému požadujeme prefix s rolí Loopbacks, který obsahuje dostupné IP adresy pro přidělení - pokud je nalezen, přidělujeme adresu, pokud ne, požadujeme vytvoření nového prefixu.
Nebo při vytváření konfigurace zařízení můžeme ze stejného systému zjistit, v jakém VRF má být rozhraní umístěno.
A při spouštění nového serveru se skript přihlásí do systému, zjistí, na kterém přepínači se server nachází, jaký port a která podsíť je přiřazena k rozhraní - a z toho přidělí adresu serveru.

To naznačuje přání zkombinovat DCIM a IPAM do jednoho systému, aby nedocházelo k duplikaci funkcí a nesloužily dvěma podobným entitám.
To je to, co uděláme.

Komponenta 3. Systém pro popis síťových služeb

Pokud první dva systémy ukládají proměnné, které je třeba ještě nějak použít, pak třetí popisuje pro každou roli zařízení, jak by měla být nakonfigurována.
Stojí za to rozlišovat dva různé typy síťových služeb:

• Infrastruktura
• Klient.

První jmenované jsou navrženy tak, aby poskytovaly základní konektivitu a ovládání zařízení. Patří mezi ně VTY, SNMP, NTP, Syslog, AAA, směrovací protokoly, CoPP atd.
Ten organizuje službu pro klienta: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP atd.
Samozřejmě existují i ​​hraniční případy – kam zařadit MPLS LDP, BGP? Ano a pro klienty lze použít směrovací protokoly. Ale to není důležité.

Oba typy služeb jsou rozloženy do konfiguračních primitiv:

• fyzická a logická rozhraní (tag/anteg, mtu)
• IP adresy a VRF (IP, IPv6, VRF)
• ACL a zásady zpracování provozu
• Protokoly (IGP, BGP, MPLS)
• Zásady směrování (seznamy prefixů, komunity, filtry ASN).
• Utility služby (SSH, NTP, LLDP, Syslog...)
• Atd.

Jak přesně to uděláme, zatím netuším. Na to se podíváme v samostatném článku.

Pokud trochu blíž k životu, pak bychom to mohli popsat
Přepínač Leaf musí mít relace BGP se všemi připojenými přepínači Spine, importovat připojené sítě do procesu a přijímat z přepínačů Spine pouze sítě od určité předpony. Omezte CoPP IPv6 ND na 10 stran za sekundu atd.
Na druhé straně páteře konají sezení se všemi připojenými vodiči, fungují jako kořenové reflektory a přijímají z nich pouze trasy určité délky a s určitou komunitou.

Komponenta 4: Mechanismus inicializace zařízení

Pod tímto nadpisem kombinuji mnoho akcí, které musí nastat, aby se zařízení objevilo na radaru a bylo k němu vzdálený přístup.

1. Zadejte zařízení do inventárního systému.
2. Vyberte adresu IP pro správu.
3. Nastavte si k němu základní přístup:
   Název hostitele, IP adresa správy, cesta do sítě pro správu, uživatelé, klíče SSH, protokoly - telnet/SSH/NETCONF

Existují tři přístupy:

• Vše je kompletně manuální. Zařízení se přiveze na stojan, kde jej běžný organický člověk zadá do systémů, připojí se ke konzoli a nakonfiguruje. Může pracovat na malých statických sítích.
• ZTP - Zero Touch Provisioning. Hardware dorazil, postavil se, obdržel adresu přes DHCP, přešel na speciální server a nakonfiguroval se.
• Infrastruktura konzolových serverů, kde počáteční konfigurace probíhá přes konzolový port v automatickém režimu.

O všech třech si povíme v samostatném článku.

Komponenta 5: Model konfigurace bez ohledu na dodavatele

Až dosud byly všechny systémy nesourodými záplatami, které poskytují proměnné a deklarativní popis toho, co bychom chtěli v síti vidět. Ale dříve nebo později se budete muset vypořádat se specifiky.
V této fázi se pro každé konkrétní zařízení kombinují primitiva, služby a proměnné do konfiguračního modelu, který ve skutečnosti popisuje kompletní konfiguraci konkrétního zařízení, pouze způsobem neutrálním vůči dodavateli.
Co tento krok dělá? Proč rovnou nevytvořit konfiguraci zařízení, kterou můžete jednoduše nahrát?
Ve skutečnosti to řeší tři problémy:

1. Nepřizpůsobujte se specifickému rozhraní pro interakci se zařízením. Ať už jde o CLI, NETCONF, RESTCONF, SNMP - model bude stejný.
2. Počet šablon/scriptů nedodržujte podle počtu prodejců v síti a pokud se změní design, změňte to samé na více místech.
3. Načtěte konfiguraci ze zařízení (zálohu), vložte ji do přesně stejného modelu a přímo porovnejte cílovou konfiguraci se stávající, abyste vypočítali deltu a připravili konfigurační patch, který změní pouze ty části, které jsou nezbytné nebo identifikuje odchylky.

V důsledku této fáze získáme konfiguraci nezávislou na dodavateli.

Komponenta 6. Rozhraní ovladače specifické pro dodavatele

Neměli byste si lichotit nadějemi, že jednoho dne bude možné nakonfigurovat ciska úplně stejným způsobem jako Juniper, jednoduše tím, že jim pošlete přesně stejné hovory. Navzdory rostoucí oblibě whiteboxů a vzniku podpory pro NETCONF, RESTCONF, OpenConfig se konkrétní obsah, který tyto protokoly dodávají, liší od dodavatele k dodavateli, a to je jeden z jejich konkurenčních rozdílů, kterých se jen tak snadno nevzdají.
To je zhruba totéž, co OpenContrail a OpenStack, které mají jako rozhraní NorthBound RestAPI, očekávají úplně jiná volání.

V pátém kroku tedy model nezávislý na prodejci musí nabýt podoby, v jaké půjde do hardwaru.
A zde jsou všechny prostředky dobré (ne): CLI, NETCONF, RESTCONF, SNMP jednoduše.

Budeme tedy potřebovat ovladač, který přenese výsledek předchozího kroku do požadovaného formátu konkrétního dodavatele: sadu příkazů CLI, strukturu XML.

Komponenta 7. Mechanismus pro dodání konfigurace do zařízení

Vygenerovali jsme konfiguraci, ale stále je třeba ji dodat do zařízení – a samozřejmě ne ručně.
Za prvé, stojíme před otázkou, jakou dopravu využijeme? A dnes už výběr není malý:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (ačkoli je to odlehlé, protože je to způsob, jak dodat FIB, ne nastavení)

Dejme to t. CLI je dědictví. SNMP... kašel kašel.
RESTCONF je zatím neznámé zvíře, REST API nepodporuje téměř nikdo. Proto se v seriálu zaměříme na NETCONF.

Ve skutečnosti, jak již čtenář pochopil, v tomto okamžiku jsme se již rozhodli pro rozhraní - výsledek předchozího kroku je již prezentován ve formátu rozhraní, který byl zvolen.

Za druhéa jakými nástroji to uděláme?
I zde je velký výběr:

• Vlastní skript nebo platforma. Vyzbrojme se ncclient a asyncIO a dělejme vše sami. Kolik nás stojí vybudování systému nasazení od nuly?
• Ansible se svou bohatou knihovnou síťových modulů.
• Sůl se svou skrovnou prací se sítí a spojením s Napalmem.
• Vlastně Napalm, který zná pár prodejců a to je vše, sbohem.
• Nornir je další zvíře, které budeme v budoucnu pitvat.

Zde favorit ještě nebyl vybrán - budeme hledat.

Co je zde ještě důležité? Důsledky použití konfigurace.
Úspěšné nebo ne. Je stále přístup k hardwaru nebo ne?
Zdá se, že commit zde pomůže s potvrzením a validací toho, co bylo staženo do zařízení.
To v kombinaci se správnou implementací NETCONF výrazně zužuje rozsah vhodných zařízení – jen málo výrobců podporuje normální commity. Ale to je jen jeden z předpokladů RFP. Nikdo se nakonec neobává, že ani jeden ruský prodejce nesplní podmínku rozhraní 32*100GE. Nebo má obavy?

Komponenta 8. CI/CD

V tuto chvíli již máme připravenou konfiguraci pro všechna síťová zařízení.
Píšu „pro všechno“, protože mluvíme o verzování stavu sítě. A i když potřebujete změnit nastavení pouze jednoho přepínače, změny se počítají pro celou síť. Je zřejmé, že pro většinu uzlů mohou být nulové.

Ale, jak již bylo řečeno výše, nejsme nějací barbaři, kteří by chtěli vše převálcovat rovnou do výroby.
Vygenerovaná konfigurace musí nejprve projít Pipeline CI/CD.

CI/CD znamená Continuous Integration, Continuous Deployment. Jedná se o přístup, při kterém tým nejen vydává každých šest měsíců novou hlavní verzi, která zcela nahradí starou, ale pravidelně postupně implementuje (Deployment) nové funkce po malých částech, z nichž každá je komplexně testována na kompatibilitu, bezpečnost a výkon (Integrace).

K tomu máme systém pro správu verzí, který sleduje změny konfigurace, laboratoř, která kontroluje, zda je klientská služba nefunkční, monitorovací systém, který tuto skutečnost kontroluje, a posledním krokem je zavádění změn do produkční sítě.

S výjimkou ladicích příkazů musí naprosto všechny změny v síti projít CI/CD Pipeline – to je naše záruka klidného života a dlouhé, šťastné kariéry.

Komponenta 9. Systém zálohování a detekce anomálií

No, není třeba znovu mluvit o zálohách.
Jednoduše je vložíme do git podle koruny nebo na základě změny konfigurace.

Druhá část je ale zajímavější – někdo by měl tyto zálohy hlídat. A v některých případech musí někdo jít a všechno otočit tak, jak to bylo, a v jiných na někoho mňoukat, že něco není v pořádku.
Pokud se například objevil nový uživatel, který není registrován v proměnných, musíte ho odstranit z hacku. A pokud je lepší nedotýkat se nového pravidla brány firewall, možná někdo právě zapnul ladění, nebo možná nová služba, bungler, nebyla zaregistrována podle předpisů, ale lidé se k ní již připojili.

Stále neunikneme nějaké malé deltě v měřítku celé sítě, navzdory všem automatizačním systémům a ocelové ruce managementu. K odladění problémů stejně nikdo do systémů nepřidá konfiguraci. Navíc nemusí být ani zahrnuty do konfiguračního modelu.

Například pravidlo brány firewall pro počítání počtu paketů na konkrétní IP za účelem lokalizace problému je zcela běžná dočasná konfigurace.

Komponenta 10. Monitorovací systém

Zpočátku jsem se nehodlal zabývat tématem monitorování – je to stále objemné, kontroverzní a komplexní téma. Ale jak věci postupovaly, ukázalo se, že je to nedílná součást automatizace. A není možné to obejít ani bez praxe.

Evolving Thought je organickou součástí procesu CI/CD. Po zavedení konfigurace do sítě musíme být schopni zjistit, zda je s ní nyní vše v pořádku.
A nemluvíme jen a ne tolik o plánech používání rozhraní nebo dostupnosti uzlů, ale o jemnějších věcech - přítomnost nezbytných tras, atributů na nich, počtu relací BGP, sousedů OSPF, výkonu End-to-End nadřazených služeb.
Přestaly se sčítat syslogy k externímu serveru, nebo se porouchal agent SFlow, nebo začaly narůstat poklesy ve frontách, nebo se rozpadla konektivita mezi některým párem prefixů?

Tomu se budeme věnovat v samostatném článku.

Závěr

Jako základ jsem zvolil jeden z moderních návrhů sítě datových center - L3 Clos Fabric s BGP jako směrovacím protokolem.
Tentokrát síť postavíme na Juniperu, protože rozhraní JunOs je nyní vanlove.

Pojďme si zkomplikovat život používáním pouze Open Source nástrojů a sítě více dodavatelů – takže kromě Juniperu vyberu na cestě ještě jednoho šťastlivce.

Plán pro nadcházející publikace je asi tento:
Nejprve budu mluvit o virtuálních sítích. Za prvé proto, že chci, a za druhé proto, že bez toho nebude návrh sítě infrastruktury příliš jasný.
Pak o samotném návrhu sítě: topologie, směrování, zásady.
Sestavíme laboratorní stojan.
Pojďme se nad tím zamyslet a třeba si procvičit inicializaci zařízení v síti.
A pak o každé složce v intimním detailu.

A ano, neslibuji, že tento cyklus s grácií ukončím hotovým řešením. 🙂

Užitečné odkazy

• Než se ponoříte do série, stojí za to si přečíst knihu Natashy Samoilenko Python pro síťové inženýry. A možná projít kurs.
• Bude také užitečné číst RFC o návrhu továren datových center z Facebooku od Petera Lapukhova.
• Dokumentace architektury vám poskytne představu o tom, jak funguje Overlay SDN. Wolframová tkanina (dříve Open Contrail).

dík

Římská soutěska. Pro komentáře a úpravy.
Arťom Černobay. Pro KDPV.

Zdroj: www.habr.com