Moderní síť je rychlá, automatizovaná a detekuje anomálie, znělo na CSNOG 2023

CSNOG byl vymyšlen v roce 2017 jako místo setkání českých a slovenských síťových operátorů. Podobná setkání se konají po celém světě a mívají neformální podobu. Cílem je výměna informací mezi lidmi, kteří zjednodušeně řešeno spravují internet, zahájil akci Ondřej Caletka. Akce by měla být spíše setkáním než klasickou konferencí, protože informace by měly téci všemi směry.

Přednášky jsou zaměřeny na technologie a ne na konkrétní produkty. Měli bychom se dozvědět, jak fungují konkrétní principy a jaké jsou trendy. O program se stará programový výbor, což je skupina dobrovolníků, kteří se osobně setkávají a vybírají přednášky na další setkání. Důležitým úkolem programového výboru je především sehnat obsah. Programový výbor by se měl obměňovat a je možné se zapojit a akci někam dále posunout.

Přestože CSNOG nemá žádnou právní subjektivitu, někdo musí platit faktury. Proto se do organizace zapojují organizace CZ.NIC, NIX.CZ a CESNET, které akci zajišťují po technické stránce. Nemají ale vliv na obsah, za ten je zodpovědný programový výbor.

Steve Jones: co uvážit před nasazením 400G přes DWDM

Technologie 400G se nasazuje především uvnitř datacenter, ale postupně se šíří také do větších propojovacích sítí. 800G se blíží, zatím je velký rozdíl mezi marketingem a realitou. Je dostupná, pokud jste správný zákazník. Každopádně 400G je běžně dostupná a její nasazení velmi rychle roste.

Rozdíl mezi jednotlivými transceivery, kromě různých konektorů, je především v jejich dosahu. Pohybují se od desítek metrů, přes desítky kilometrů až po 120 kilometrů a více. Je velmi málo single-lambda DWDM transceiverů. Budou určitě přibývat, ale zatím jsou poměrně vzácné. Trh ale rychle dospívá a situace se mění velmi rychle.

IP over DWDM umožňuje z cesty vyřadit transponder (Mux-ponder) a je možné pasivní DWDM připojit přímo k přepínači nebo směrovači. Záleží ale na tom, jakou máte síť a jaké služby chcete používat. Spousta současných transeiverů je kromě vyšších rychlostí schopna stále pracovat na 1G nebo 10G.

Nejjednodušší a nejlevnější způsob nasazení 400G je použití pasivního multiplexingu. Bude to stále fungovat s původními 10G a 100G tranceivery. Někteří výrobci pracují na 600G/64QAM, zatím je ale tato technologie mimo specifikace a kvůli chybovosti nepoužitelná v produkci.

Matěj Pavelka: detekce anomálií ve velkých Flow datasetech

Zákazníci často používají mix mnoha různých nástrojů, takže operátoři by měli být schopni používat třeba šest různých prostředí. To se samozřejmě neděje, obvykle jeden operátor umí dobře používat jeden systém. Je z toho cesta ven, dnešní cesta spočívá ve sloučení několika různých datových zdrojů do jednotného rozhraní. Jsou to například otevřené nástroje Grafana nebo Kibana.

Pro jakýkoliv analytický nástroj, který má být pravidelně používán, je podstatné, že dává okamžité odpovědi pro momentální dotazy. Nemám křišťálovou kouli a netuším, jaká data budu příště používat. Proto je nemůžu mít předpočítané dopředu. Naneštěstí to není jednoduchý úkol k řešení.

Většina otevřených nástrojů pro analýzu dat není pro rychlé dotazy vhodná, protože byly napsány před dvaceti lety a počítají s toky maximálně ve stovkách za sekundu. My jsme potřebovali zpracovat data s více než milionem toků za sekundu. Při použití běžných nástrojů pak analytik čekal třeba dvě a půl hodiny na konkrétní data. My dokážeme doručovat odpovědi za sekundy.

Neexistuje jeden perfektní software, ve kterém je možné pokrýt všechnu monitorovací činnost. V budoucnu to bude ještě důležitější. Neexistuje jeden prsten, který vládne všem. Podstatné je, aby spolu všechny „krabičky“ komunikovaly. To znamená, že musejí podporovat API, používat univerzální protokoly, nevyhýbat se různým standardům a neuzavřít se u jednoho poskytovatele.

Každý detekční systém časem degraduje. Admini se mění, odcházejí a po několika letech se ve firmě stále používají původní pravidla, která vytvořili. Systém se stává stále náročnějším, bobtná a vyhazuje stále více falešných poplachů. Pomáhá si rozdělit anomálie na různé skupiny.

Některé anomálie vyřeší jednoduché pravidlo, jinde je možné nastavit dynamické hranice pro nahlášení problémů. Nejproblematičtější jsou trendy a telemetrie, kde je mnoho metrik nebo více dimenzí. Metriky by pak měly skončit v jedné otevřené databázi, která může nabídnout i různé agregace.

Provoz v sítích neroste lineárně ani kvadraticky, ale roste exponenciálně. Za pár let pofrčíte mnohem vyšší rychlostí než dnes.

David Čermák, Josef Miegl: správa sítí nové generace

Při správě sítí se obvykle používají manuální postupy, které velmi rychle narazí na své limity. U nás se problémy objevovaly při komunikaci mezi týmy, kdy se tým síťařů neustále doptával na detaily. Změny v síti byly doménou pouze správců sítě, přičemž správců je výrazně více. Cílem je ale konfigurovat služby a ne samotnou síť.

Při snaze o přehlednost se začaly používat obrovské excelovské tabulky, ze kterých se exportovalo CSV, které pak bylo skriptem zpracováno do obrovských konfigurací. Tohle ale neškáluje a je to náchylné na chyby. Proto jsme se rozhodli přejít na plnou automatizaci.

Infrastruktura by měla být orientována na služby. Nechceme konfigurovat síťové prvky a porty, ale jednotlivé služby. Stejně tak monitoring by měl službám rozumět a lépe je pak monitorovat bez falešných poplachů. Vhodné řešení by mělo být plně automatické, nebýt závislé na jednom poskytovateli a být spravovatelné kýmkoliv z týmu. Je potřeba také sledovat všechny prováděné změny, abychom věděli, co se v systému děje a kdo tam co dělá.

Nástrojů existuje celá řada, ale obvykle dělají jen část dříve uvedených činností. Umějí třeba stáhnout konfiguraci, upravit a poté znovu nasadit. Vůbec nedělají síťovou automatizací. Existují i velká drahá komerční řešení, která ale obvykle neumožňují dělat si věci po svém, ale vyžadují jednu konkrétní cestu. Proto jsme se rozhodli pro své vlastní řešení postavené na Netboxu.

Netbox je systém pro správu datacentra, který umožňuje na jedno místo uložit informace o celé infrastruktuře. Má to velmi silnou síťovou konfiguraci, takže je možné tam vlastně přesunout celou síť. Netbox je navíc velmi přizpůsobitelný pomocí pluginů, takže je možné ho ohnout pro své účely.

Mezi nevýhody patří neintuitivní uživatelské rozhraní a neumí vracet provedené změny. Pokud někdo třeba odstraní port, vy to uvidíte v logu, ale neumíte změnu vrátit. Musíte všechno naklikat znovu. Netbox používá velká komunita, takže vývoj je velmi překotný. To je všeobecně dobrá věc, ale stává se, že se některé vlastnosti hodně mění, proto je potřeba intenzivně testovat.

Netbox není vhodným místem pro uložení dynamických dat jako jsou IRR, RPKI, IX peers, preferované cesty a podobně. Zkusili jsme to, ale velmi rychle jsme to zavrhli. Nakonec do Netboxu ukládáme jen statické věci, které se příliš nemění. Ty je potřeba ukládat někde jinde, konkrétně k tomu byly vytvořeny vlastní mikroslužby s API.

Centrálním bodem automatizace je Ansible, který používá šablony v Jinja. Používáme GitLab, což je současný standard a umožňuje nám zachovávat historický stav sítě, ke kterému se pak můžeme případně vrátit. Celý pracovní postup je pak implementován pomocí Pipelines, které dovolují určit, co se má provést a kdy. Společně s Ansible je to velmi silný nástroj.

Při přechodu na automatizaci narazíte na to, že zařízení různých výrobců mají různou konfigurační syntaxi a že je stále potřeba provádět manuální změny. Když máte problém, nechcete řešit pipeline a upravovat šablony. Potřebujete to opravit rychle ručně a pak se případně zabývat změnami v automatizačním systému.

S automatizací souvisí i monitoring, ke kterému se dá velmi dobře použít například Akvorado, ve kterém je možné klasifikovat jednotlivé typy provozu. Musíte ale zajistit, aby se vám konfigurace nerozešla se skutečným stavem. Konfigurace monitoringu tedy může být generována stejným automatizačním systémem.

Je lepší začít s malým řešením a postupně jej vylepšovat. Je to jednodušší než se snažit hned nasadit nějaký obrovský nástroj, který se snaží řešit všechno hned. Stejně tak u malých sítí nedává smysl importovat současný stav ze sítě do automatizačního systému. U obrovských sítí to asi smysl dává, u nás bylo jednodušší stav vložit ručně. Výhodou automatizace nakonec je, že do ní můžou koukat všichni a sítí se pak může zabývat mnohem víc lidí, než je v síťařském týmu.

Alexander Zubkov: Roleplay v BGP – co přináší nová RFC 9234

Poručení BGP je možné rozdělit na dvě skupiny: únik a únos. Při úniku cesta směruje k oprávněnému cíli, který má oprávnění hlásit daný prefix. V případě únosu ohlásí cestu nějaký jiný operátor a provoz pak směruje k němu. Zatímco úniky jsou způsobeny chybou v konfiguraci, únos je obvykle součástí protiprávního jednání.

Na internetu existuje ustálený model vztahu mezi sítěmi, který je hierarchický. Máme tu poskytovatele, odběratele, sousedy a route servery. K úniku pak může dojít například tak, že odběratel začne fungovat jako poskytovatel pro jiného poskytovatele. To obvykle nikdo nečeká a obvykle na to není odběratelská síť připravená, což způsobí ztrátu části provozu.

Řešení spočívají v kontrole komunit, ale každý operátor musí vymyslet vlastní metodu, vlastní komunitu a správně vše zabudovat do vlastních filtrů. Nesmíte udělat žádnou chybu. Ve kterémkoliv kroku můžete udělat chybu a dostat neočekávaný provoz. Můžete se pak stát hrdinou článků o tom, že zase někdo rozbil internet.

Nové řešení se snaží přinést RFC 9234, které vzniklo už v roce 2016 a teprve teď bylo vydáno. Funguje jen pro běžné BGP, nefunguje pro multicast, VPN ani konfederaci. Definuje nové role pro jednotlivé sítě, které pak mohou svou roli vysílat při zřizování BGP relace. Obě strany se pak vzájemně kontrolují a je možné vynutit přísný režim, kdy váš soused musí technologii podporovat a vysílat správnou roli.

RFC přidává také atribut OCT (only to customer), která také pomáhá kontrolovat správné nastavení směrování. Dobrá zpráva je, že to funguje automaticky a máme pak kontrolu z obou stran.

Mnoho svobodných implementací routerů už role podporuje, stejně tak například vývojové verze nástrojů tcpdump a WireShark. Samozřejmě je tu ještě spousta software, který ještě nové RFC neimplementuje. Změny v síťových prvcích obvykle také trvají velmi dlouho, výrobci čekají na více požadavků od zákazníků. Požádejte svého výrobce, aby tuto technologii podporoval.

Ondřej Vondrouš: FlowPing – nástroj pro aktivní měření komunikačních sítí

FlowPing je softwarový generátor datového provozu, jehož ovládání vypadá velmi podobného programu ping. To je první nástroj, který obvykle použijete, když chcete otestovat nějaké spojení. FlowPing umí vygenerovat konkrétní datový tok, ale umí ho i plynule snižovat či zvyšovat.

Je možné ho ovládat z příkazové řádky nebo je možné načíst konfigurační soubor, ve kterém je definován celý test. Můžeme definovat kompletní průběh, kdy bude jaký datový tok generován. Je možné také definovat asymetrické linky, pokud nechceme zatěžovat oba směry.

Program dokáže fungovat ve dvou režimech. Jednak může používat klasické systémové čekání a nezatěžovat operační systém. Je ale možné také využít aktivní režim, kdy je vytěžováno naplno minimálně jedno procesorové jádro. Máme pak sice vyšší výkon generování paketů, ale může se nám stát, že je systém někde začne zahazovat.

Výstupní data jsou k dispozici ve formátu JSON. My se buď díváme na každý jednotlivý paket nebo počítáme statistiky v daném časovém rozmezí. Je možné měřit zpoždění ve smyčce (RTT), jednosměrné zpoždění, jitter, ztrátovost, duplicitní pakety a podobně. Je možné provádět také penetrační testy, kdy si na nějakém UDP portu můžete zjistit, co vám konkrétní síť dovolí. Možná je také injektáž specifického provozu, například vysílání internetové televize.

FlowPing je vyvíjen už zhruba deset let, stáhnout je ho možné na GitHubu pod licencí GNU GPL 3.

Petr Hemerka: měřicí nástroje a služby systému MSEK

MSEK znamená Měřicí systém elektronických komunikací a by budován v letech 2018 až 2021. Jde o významný informační systém a jsou na něj kladeny zákonné povinnosti. Je provozován v Praze, co nejblíže peeringovým uzlům, a má vlastní ASN.

Veřejně dostupným nástrojem je ČTÚ – NetTest, což je speedtest umožňující měření rychlosti na webu či přes mobilní aplikaci pro Android. Připravujeme také verzi pro iOS, která ale nebude mít všechny funkce, jako verze pro Android. Nástroj je provozován od září 2021, od té doby bylo provedeno 1,5 milionů testů, denně přibude 3100 dalších. Dvě třetiny měření běží z webového prohlížeče, zbytek z mobilní aplikace.

Neveřejným nástrojem pro techniky ČTÚ je Exfo, který umožňuje měření kvalitativních parametrů služeb v pevném místě až do rychlosti 10 Gbps. Provádí se měřené pomocí přenosných terminálů.

Pro měření mobilních sítí se používá 4drive-box, který umožňuje měřit až čtyři operátory. Měříme tak dálnice, železniční koridory a jednotlivé obce. Využívá se pro měření rádiových a především datových parametrů. Je zabudován do měřicího vozidla, které objíždí české dálnice každý rok.

Měřicí servery jsou připojeny 10Gbps linkou do NIX.CZ a stejnou konektivitou do tranzitu. Zatím nám to stačí, ale už se objevují velké špičky kvůli navyšování počtu testů. Plánuje se proto navýšení kapacity do peeringového uzlu NIX.CZ.

Data je možné vidět na vPortálu ČTÚ, kde je možné si nechat zobrazit výsledky jednotlivých měření. Nedávno tam přibyla rozvojová kritéria a budou přibývat další informace.

Josef Grill: anycastová síť na všech kontinentech

Wedos se pravidelně setkává s velkými DDoS útoky, které jsou schopny ucpat i tři 100GE linky. Na jaře roku 2022 se objevil nejsilnější útok v dějinách českého internetu. Útok měl nejen výkon stovky gigabitů, ale také trval velmi dlouhou dobu. Začali jsme proto nakupovat hardware, posílat je různě po světě a stavět anycastovou síť.

První zahraniční lokalita byla ve Vídni, během jednoho roku se podařilo osadit 25 bodů po celém světě. Bez anycastové sítě dnes není možné se ubránit velkým útokům. Bylo potřeba rozeslat hardware za vyšší desítky milionů korun a živit ho stojí miliony korun měsíčně.

Wedos má vlastní autonomní systém AS208414, který je připojen k několika upstreamům: Cogent, Arelion, CDN77. Jsme připojeni také k lokálním IXP a jednáme s dalšími. Jednotlivé lokality spolu nejsou vzájemně propojené a výpadek jedné z nich neohrozí provoz celé sítě. Každý ze 45 serverů má 40 Gbps uplink a je připojení ke každému se switchů samostatnou 10GE linkou. Ve všech lokalitách je domluvená minimálně 80Gbps linka, ale v plánu je 120 až 160 Gbps.

Anycastová síť WEDOS Global využívá technologii BGP anycast a aktuálně má k dispozici přes 1500 fyzických serverů a konektivitu přes 2,5 Tbps. Máme tradiční ochranu na třetí a čtvrté síťové vrstvě a ochranu webů na sedmé vrstvě. Největší zdroje útoků jsou filtrovány hned na vstupu a provoz není vůbec puštěn do sítě. Na serverech běží především KnotDNS a Nginx jako reverzní proxy.

V březnu bylo v síti zaznamenáno celkem 1,9 miliardy požadavků z 8,7 milionů unikátních IP adres. Zablokováno bylo 10,8 milionů požadavků pomocí WAF. Nejvíce požadavků bylo odbaveno z Česka, USA a Slovenska.

Petr Špaček: kolísání latence na autoritativních DNS serverech

Jeden z uživatelů DNS serveru BIND provedl aktualizaci z verze 9.11 na 9.16 a pozoroval velké náhodné zpoždění části odpovědí. Autoritativní server se nikoho nedoptává, má informace u sebe a neměl by být důvod ke zpoždění. Klasické nástroje pro měřené latence byly k ničemu, protože dávají jen souhrnné informace o měření nebo nejsou určeny pro měření autoritativních serverů.

Nakonec se vývojáři rozhodli rozšířit nástroj dnsperf, který umožňuje zobrazovat detailní tabulku o výsledcích pro jednotlivé časové rozsahy. Tím jsme vyřešili problémy s měřením, ale nevěděli jsme, co znamenají. Je potřeba získat nějakou vizualizaci nebo jiný způsob zobrazení. Výsledkem byly skripty, které dovolovaly nakreslit grafy v nástroji  shotgun.

Dalším krokem bylo otestovat prostředí, které musí dávat smysl, aby nebylo měření ovlivněno třeba chybným nastavením nebo některým z prvků. Testování proběhlo v cloudu AWS, což vypadá jako šílený nápad. K našemu překvapení se ukázalo, že se taková sdílená síť chová velmi konzistentně a drží se tam, kde má.

Měření pak ukázalo, že zhruba dvě setiny procenta dotazů jsou nestabilní a vrací při každém měření jinak dlouhou odpověď. Co to znamená? Je to někde v síti? Je to vlastně problém? Graf typu boxplot pak ukázal, že jde o nějaký šum a nenaráží se například na rate limiting nebo nějaké buffery. Víme o tom a budeme se zaměřovat na zbytek.

Uživatel problémového serveru měl asi 100 tisíc zón a používal také katalogovou zónu. To je textový seznam zón, který vypadá jako standardní DNS zóna, sloužící jako konfigurace serveru. Po vytvoření stejného nastavení se ale vše chovalo normálně. Na nic jsme nepřišli a uživatel si pořád stěžoval. Něco nám tedy unikalo.

Uživatel agresivně upravoval katalogovou zónu pomocí skriptu. Jakmile jsme začali podobnou změnu dělat také a katalog upravovat, chyba se projevila. Nejdříve server normálně odpovídal a při změně katalogu rychle vyskočila latence. Ukázalo se, že za vše může překlep ve zdrojovém kódu a vytvářela se malá hašovací tabulka používaná při zpracování zónového souboru. Úprava pomohla vylepšit situaci o řád, ale problém úplně nevyřešila.

Problém byl nakonec v tom, že novější BIND zpracovává data ve více bufferech a jádro samo přiděluje pakety jednotlivým vláknům. Jádro ale neví, v jakém stavu se dané vlákno nachází a zda není třeba zaneprázdněno aktualizací katalogů. To byl architekturní problém, který bylo nutné vyřešit oddělením vláken pro zpracování katalogů.

BIND verze 9.11 už je rok nepodporovaná a je to jako parní stroj. Verze 9.16 bude končit za půl roku a už se v něm chyba opravovat nebude. Poučení z toho plynoucí je: testovat, testovat a testovat. Pokud měříte na síti, měli byste věnovat pozornost okrajovým hodnotám. Průměry lžou a co vypadá jako šum může být nakonec tím nejdůležitějším.

Maciej Andziński: hledání lokalit pro DNS servery domény .CZ

V současné době jsou DNS servery pro doménu .CZ umístěny v 13 státech na pěti kontinentech. Přidáváme neustále nové servery a ptáme se, jaká je nejlepší lokalita pro další server. Jedním z hledisek je snížení latence a tím zlepšení stavu pro koncové uživatele.

Typickým přístupem je měření zpoždění pomocí pingu, ale od roku 2019 se používá jiný přístup, který využívá pasivního měření odezvy na TCP handshake. To vidíme přímo na straně serverů a dává nám to dostatečně přesná data. Na základě dat je možné určit situaci pro každou zdrojovou IP adresu zvlášť.

Tato měření se prováděla opakovaně a vývojáři pak došli k tomu, že je potřeba vše automatizovat a získat tak jednoduchý seznam míst, kam by se vyplatilo přidat nový server. Musíme kombinovat dvoje data: čísla z měření a infrastrukturu internetu získanou z PeeringDB.

Výsledkem je jednoduchá tabulka, která ukazuje seznam států, kam se vyplatí přidat další server. Na nejnovější verzi této tabulky jsou Spojené státy, Indie a Hong Kong. Nedávno tu byla ještě jižní Afrika, ale už jsme tam spustili nový server, takže se nahoru dostaly jiné státy.

Latence je ovšem jen jednou z metod, ale pomáhá řešit situace, kde spojení trpí příliš dlouhou odezvou. Záleží ovšem také na dalších parametrech, jako například počet paketů obsloužených za sekundu.

Kryštof Šádek: Zprovoznění (dalšího) anycastového rozsahu pro DNS

Původní stav zahrnoval čtyři „písmenka“, která slouží pro odbavování provozu z TLD .CZ. Servery s písmenem D byly sdíleny s hostovanými doménami našich partnerů. To nebylo ideální, protože takto nebylo možné použít selektivní RTBH a horší práce s rozkládáním zátěže. Dále je tu bezpečnostní hledisko.

Při rozšiřování anycastu bylo potřeba doplnit informace v RIPE databázi o další záznamy. Pro anycast používáme dva ASN, takže bylo potřeba doplnit informace pro oba. Zároveň bylo potřeba vytvořit záznam pro reverzní záznamy. RIPE umožňuje nasazení DNSSEC i na reverzní zóny a doporučuji přidat NSEC záznamy i sem. Kromě toho bylo potřeba vytvořit ROA záznamy pro dané routy.

Následně už bylo možné nakonfigurovat DNS servery, což zahrnuje zhruba stovku serverů. Snažíme se provozovat infrastrukturu v diverzním nastavení od různých výrobců. Různé servery se liší konfigurací sítě, firewallem a použitím DNS serveru. To dává dohromady asi 18 různých způsobů, jakými konfigurujeme systémy. Zásadní je tu tedy automatizace, přičemž se konkrétně používá Ansible a Netbox.

Pokud je vše připraveno, je možné servery propagovat pomocí BGP, pro což se používají démoni BIRD a FRR. V současném stavu máme šest písmenek od A do F, přičemž první čtyři slouží výhradně pro doménu .CZ a ostatní pak navíc hostují další domény.

Ondřej Caletka: nasazování sítě IPv6-mostly

Stále jsme vlastně v přechodu na IPv6 a dlouho se říkalo, že nejlepším přechodovým mechanismem je dual-stack. Do stávající sítě přidáme vedle IPv4 také IPv6 a provozujeme obě zároveň. Zásadní problém je, že dual-stack neřeší nedostatek IPv4 adres, což je hlavní důvod pro nasazení IPv6.

Zásadní přechodový mechanismus NAT64 se snaží překládat prostor IPv4 do IPv6 tak, že koncové zařízení může mít pouze IPv6 konektivitu. Přesto se může domluvit s celým internetem, protože se mu zdá, že je celý internet dostupný po IPv6. Funguje to skvěle, až na pár drobných výjimek. Používám to tak několik let a funguje to výborně.

Situace je taková, že mobilní platformy jsou na takovou situaci připravené. Operátoři mají velkou sílu a mohou tlačit na to, jak u jednotlivých výrobců bude síť fungovat. Apple tak už například od roku 2016 nepustí žádnou aplikaci, která by na takové síti nefungovala. Okrajové případy pak řeší algoritmus Happy Eyeballs 2.0 a tetherning řeší překladač CLAT.

Android to řeší tak, že je nasazen CLAT a není potřeba nutit vývojáře ke změně aplikací. Přístup Androidu je jednodušší a méně zajímavý, protože tím je problém vyřešený. Aktuální mobilní telefon nebude mít problém pracovat na síti pouze s IPv6.

Na desktopu je situace výrazně horší, protože Happy Eyeballs 2.0 nefunguje jinde než u Apple. Stejně tak CLAT není k dispozici na Windows, Linuxu nebo ChromeOS. Pak tu jsou známé drobné problémy jako zastaralé aplikace, rozbité korporátní VPN a podobně.

Je možné takové sítě běžně už nasadit? Umožňuje to RFC 8925, které nabízí novou volbu DHCP číslo 108. Ta signalizuje, že zařízení podporuje běh na síti pouze s IPv6. V případě starého DHCP serveru se nic nemění, protože server volbu ignoruje a vše běží postaru. Pokud máme aktuální DHCP server na síti s IPv6, nedokončí se transakce a IPv4 adresa není přidělena. Zařízení ví, že síť ke svému provozu nevyžaduje přidělení IPv4.

Podpora je překvapivě široká, volbu 108 podporují aktuální verze operačních systémů Android, iOS a macOS. Během posledního RIPE meetingu v Bělehradě deklarovalo podporu 74 % připojených zařízení. Zvláštním případem je pak macOS, který od verze 13 aktivuje CLAT bez zvláštních požadavků.

Když chcete podobnou síť provozovat, není potřeba mít speciální podporu pro volbu 108. DHCP serveru je potřeba jen do konfigurace přidat položku pro odesílání této volby. Horší je to s volbou RA PREF64, který má velmi malou podporu jen v MikroTiku a démonu rad z OpenBSD. V ostatních implementacích se objevují patche, které by měly tuto volbu přidat.

Toto je nový způsob, jak provozovat síť, ve které každé zařízení nepotřebuje IPv4 adresu. Tu potřebujete jen pro zastaralá zařízení, která nepodporují IPv6. Je to ale nejkomplikovanější řešení, protože kombinujete vše z dual-stackové sítě a IPv6-only sítě. Stále navíc potřebujete IPv4 pro stará zařízení, je to tedy spíše pro běh na dlouhou trať. Problematika je také komunikace mezi zařízeními používajícími pouze IPv6 a dual-stack.

Marian Rychtecký: automatizované nasazení Cisco NXOS

Původní architektura dvojité hvězdy bylo snadné udržovat ručně, ale NIX.CZ se rozhodl expandovat, což bylo dále neudržitelné. Stavěli jsme kruhovou topologii, kterou není ideální řídit na úrovni L2. Další motivací bylo povýšení kapacity, přičemž dnes už je v síti 40 linek s kapacitou 400 GE.

Obvyklá řešení automatizace mají na výstupu sadu příkazů pro příkazovou řádku, které se předají síťovému prvku. To nás neoslnilo výkonem, problémy s výchozími hodnotami a spolehlivostí. Požadavkem ale byla velmi rychlá konfigurace prvků, snadná upravitelnost a dostupnost telemetrických dat.

Cisco nabízí DME, neboli Data management engine. To dovoluje jednak prvky nakonfigurovat, ale zároveň získat spoustu užitečných dat pro další zpracování. Můžete si to představit jako objektový strom, který se postupně rozpadá do menších větví, které reprezentují konfiguraci i provozní data. Principiálně je možné to připodobnit stromu SNMP. Systém pak interpretuje všechny volby do jednotlivých objektů a překládá vám je případně i do CLI.

Původně to vypadalo jako těžší složitější cesta, která by ale mohla mít nakonec smysl. Procházeli jsme svoje šablony a řádek po řádku jsme hledali odpovídající objekty. Výsledkem je vlastní pythonová knihovna, která obsahuje šablonu přeloženou do objektů v JSON. Je to složitější, ale dá se tím projít. Zabralo nám to zhruba měsíc.

V současné době je možné tím zapínat vlastnosti, QoS, TACACS;, syslog, snmp-server, NTP server, STP, CDP, ACL, sFlows, OSPF, BGP, VLAN, port-security a další. Na všechno tohle jsme nakonec přišli, ale zabralo to asi dva měsíce. Některé věci se takto dohledat nepodařilo a je potřeba je volat v příkazovém řádku: TCAM carving, výchozí rozhraní a uložit či načíst konfiguraci. Po vybalení nového prvku tak musíme zadat do konzole čtyři nebo pět příkazů, než ho pak začneme konfigurovat automatizovaně.

Výsledkem je opravdu rychlá konfigurace, přičemž konfigurace nového prvku trvá asi pět sekund. Individuální změny pak probíhají během stovek milisekund a dostanete na ně konkrétní zpětnou vazbu. Navíc získáte přesná telemetrická data jako počítadla, provozní údaje a podobně.

(Autorem fotografií je Jaromír Novák z NIX.CZ.)