Monitoring, vizualizace a automatizace sítí, hlavní témata z CSNOG 2025

Komunitní setkání Czech and Slovak Network Operation Group (CSNOG) má za cíl spojit odborníky a profesionály z oblasti správy a provozu sítí v České a Slovenské republice. Toto setkání slouží jako platforma pro výměnu znalostí, sdílení osvědčených postupů a diskusi o aktuálních výzvách a trendech v oblasti síťových technologií. Komunitní setkání CSNOG organizují společně sdružení CESNET, CZ.NIC a NIX.CZ.

Karel Hynek: Monitorování sítí pomocí ipfixprobe

Monitorovací infrastruktura Flox sbírá data agregovaná do informací o jednotlivých tocích. Nad těmito daty je pak možné provádět analytiku síťového provozu. Nástroj ipfixprobe je modulární exportér síťových toků, který dokáže sbírat data z různých zdrojů jako PCAP, NDP, DPDK nebo raw socket. NDP slouží pro akcelerační FPGA karty, raw socket umožňuje vyčítat data z linuxového jádra.

Výstupem ipfixprobe je obousměrné flow, ale lze jej přesvědčit k exportu jednosměrné flow. K dispozici jsou klasické informace z NetFloxV5 jako IP adresy, MAC adresy, porty, počet bajtů a paketů. Začali jsme exportovat data i pro strojové učení, jako je sekvence paketových délek a časů pro prvních třicet paketů a histogramy paketových délek a časů.

Dokumentace je k dispozici v gitovském repozitáři a zdrojové kódy jsou na GitHubu. K dispozici jsou balíky pro EPEL8 a EPEL9, ale balíčky jsou dostupné také v mnoha různých distribucích.

V praxi je nástroj nasazený na osmi peeringových linkách sítě CESNET, které mají propustnost více než 100 Gbps. Používáme standardní servery Dell se dvěma procesory a vlastními kartami SmartNIC. Každý tento server je schopen monitorovat více linek, bezeztrátová propustnost sondy dosahuje v nejhorším případě 175 Gbps. Sonda je nasazená také na Drážďanské univerzitě, v páteřní sítě kraje Vysočina a testování probíhá také v síti Seznam.cz.

V posledním roce se podařilo významné vylepšení DPDK pluginu, který může běžet jako sekundární vyčítač dat. Byla také rozšířena podpora běžných karet typu SmartNIC, vyzkoušeny jsou karty Nvidia Mellanox ConnectX-6 a Broadcom N1400GD se 400GE portem. Zatím nezvládneme monitorovat plných 400 gigabitů kvůli omezením na PCI Express. Díky úpravě bufferování se podařila asi tisíckrát vylepšit ztrátovost při plné saturaci.

Sonda také umí zpracovávat pakety určené pro sestavení spojení protokolem QUIC nebo HTTP/3. Úvodní pakety jsou obfuskovány pomocí známého klíče, ale musíme z nich extrahovat informace a to nás zdržuje. Současná verze dokáže bezeztrátově zvládnout 40Gbps peering s Googlem.

Pracuje se na podpoře monitorování 400GE sítí, ale problém je už v tom, jak dostat data z karty do CPU. PCI Express dokáže v páté generaci přenést až 500 Gbps, ale při obousměrném přenosu nám to nestačí. Šestá generace přenese až 900 Gbps, ale serverů je zatím dostupných velmi málo. Je proto potřeba zajistit offload flow záznamů v NIC FPGA firmware. Více než 70 % dat je přeneseno v 10 % toků. Sonda pak může dostávat vše, nebo dostat jen ořezané hlavičky, případně může dostávat jen agregované flow info. Vše je ve fázi interního testování, k dispozici by podpora měla být během léta.

Pro zjednodušení tvorby a orchestrace monitorovací infrastruktury slouží webové rozhraní Panda, které vás vším provede. Infrastruktury mohou být velmi složité, může být k dispozici řada sond, několik kolektorů a serverů pro analytiku a Panda vše umožní nastavit a řídit. Panda bude k dispozici pod svobodnou licencí během léta.

Blažej Krajňák: Nástroj pro vizualizaci sFlow

Protokol sFlow sbírá hlavičky paketů a přidává k nim řadu metainformací, jako jsou údaje o portech nebo o routování. Tato data tečou do GoFlow2 a poté do databáze ClickHouse, která ukládá data orientovaná podle sloupců. Obvykle nepotřebujete o každém paketu vypsat všechny informace, můžete si vybrat jen určité sloupce. Navíc se databáze komprimuje a je možné do ní uložit patnáctkrát až dvacetkrát více dat.

ClickHouse dokáže dynamicky obohatit data z dalších zdrojů a dokáže držet malé tabulky v RAM a tím zvýšit svůj výkon. Užitečný je datový typ ALIAS, který dokáže zadanou logikou vypočítat sloupec, který ve skutečnosti v databázi uložený není. Například hodnota DSCP se počítá posunem ToS o dva bity, není pro to potřeba ukládat další data.

Při analýze je důležité mít přístup k datům v reálném čase, což by při zpracování velkých dat trvalo velmi dlouho. Můžeme tedy na začátku vytvořit nad tabulkami rozumný sampling, který vybere jen vzorek dat a tím pak šetří čas při zpracování.

Výstup je pak zajištěn pomocí dashboardu, kde je možné použít uživatelsky příjemnou filtraci s napovídačem, je možné si vybrat jednotlivé pakety, případně zadat SQL dotaz manuálně. Čím delší časovou plochu výstupu si vyberete, tím větší bude sampling, ale můžete jej ovlivnit manuálně nebo jej úplně vypnout. O vizualizaci se pak stará Grafana.

Patrick Prangl: Nárůst významu merchant siliconů

Merchant silicon jsou čipy, které velkoobchodní dodavatel vyrábí ve velkých sériích a prodává je výrobcům síťových prvků. Může jít o FPGA nebo ASIC, druhý jmenovaný je statický a tím je jednodušší a má nižší spotřebu, ale pro mnoho nasazení stačí. Slouží ke zpracování paketů, kterým se pak nemusí zabývat univerzální CPU. Prodáváme 100GE a 400GE varianty, máme k dispozici 800GE a připravujeme se na 1600GE.

Výkon těchto řešení omezuje rychlost propojení řídicích čipů se switch čipem. Rychlost postupně roste od 10GE přes 50GE až ke 100GE a později snad ještě dále. Zásadní je tu role bufferů, do kterých ukládáme v případě snahy komunikace mnoha zdrojů s několika málo cíli nebo v případě potřeby změnit po trase rychlost linek.

S těmito merchant čipy se můžeme setkat od roku 2008, kdy se používaly nejprve pro switchování na okraji sítě, zhruba od roku 2016 jsou k dispozici čipy použitelné ve všech částech rozsáhlých sítí. Pokrok v technologii umožnil v posledních letech používat 3nm technologii i zde, čímž roste výkon čipů a zároveň klesá spotřeba.

Všichni výrobci čipů mají přístup ke stejným technologiím a výrobním procesům. Rozdíl je v designu pro různá nasazení. Od jednotlivých čipů jako Tofino, přes výkonnější Tomakawk či Trident až po Jericho určený pro výkonný routing. Tofino je mrtvý projekt, ještě si jej můžete koupit, ale pravděpodobně nebude probíhat další vývoj.

Tomahawk 5 byl původně určen pro AI sítě, jeho propustnost je až 51,2 Tbps. Trident je určen do kampusových sítí, má větší buffery a mnohem více funkcí. Nejnovější generace má až o 40 % nižší příkon na bit a dodává se v menším pouzdře. Jericho se zaměřuje na velkou kapacitu bufferů a hodí se například pro poskytovatele služeb vyžadující komplexní sadu funkcí.

Lukáš Šišmiš: Překonání stereotypu IDS

Suricata produkuje bezpečnostní upozornění týkající se provozu na síti. Typicky se v routeru či switchi odbočí linka do Suricaty, která se stará o přípravu bezpečnostních dat. Je možné ji nasadit jako IDS nebo IPS, kdy má pravidla rozhodující o zahození určitého provozu. Obvykle se přehlíží možnost použití Suricaty pouze na čistý export metadat o provozu ve formátu JSON.

Suricata může sloužit jako sonda pro Flow a se správným hardwarem zvládne i 400 Gbps. Je třeba ale vědět, že data jsou exportována až při ukončení toku. Připravovaná Suricata 8 bude umět i průběžný export, měla by vyjít během podzimu.

Export dat je možné dostat na vyšší úroveň a použít Suricatu jako Network Security Monitor, kdy se budou exportovat záznamy o jednotlivých aplikačních protokolech jako DNS, HTTP, TLS, SMTP a podobně. Je možné získávat informace o jednotlivých souborech, které se vám pohybují po síti. Na základě těchto dat je možné získat přesné informace pro audit.

Suricatu je možné použít také pro detekci špatně nakonfigurovaných zařízení v síti. Na switchi se není možné podívat na obsah konkrétní komunikace, ale můžete k tomu použít Suricatu. Se základními pravidly dostupnými při instalaci je možné sledovat různé události: poškozený HTTP provoz, chyby v DNS, asymetrické routování, vypršení TTL a podobně. Tato pravidla je vhodné zapínat na detekci anomálií na začátku nasazení Suricaty, protože to produkuje opravdu hodně dat a bezpečnostní události by se mezi nimi mohly ztratit.

Suricata ale dokáže fungovat také jako firewall, což používá Amazon ve svých cloudových službách. Na rozdíl od klasického firewallu je výchozím stavem propouštění provozu a blokuje se jen vybraný provoz na vyšších vrstvách podle zadaných pravidel. Můžeme tomu říkat next generation firewall, pokud chceme používat nějaký marketingový pojem.

Se Suricatou 8 bude k dispozici také knihovna, která umožní integrovat Suricatu do vlastní aplikace. Vaše aplikace pak nemusí sama parsovat provoz a předávat ho do Suricaty, ale knihovnou můžete zefektivnít chod aplikace.

Michal Hažlinský: SDN na L0 s otevřeným hardwarem

Aby bylo v optické síti možné realizovat komunikaci, je potřeba mít k dispozici řadu zařízení, zejména v sítích využívající DWDM. Těmto prvkům říkáme nultá síťová vrstva, obvykle to je multiplexor/demultiplexor a optický zesilovač. Ty umožňují zpracovávat optický signál, aniž by bylo potřeba jej převést na elektrický signál a ten pak znovu odvysílat. CESNET vyvíjí a provozuje vlastní optické prvky nazvané CzechLight.

Optickou síť je možné řídit otevřeným způsobem pomocí SDN, tedy Software Defined Network. Srdcem je ROADM, nebo-li rekonfigurovatelný multiplexer. Ten mi umožňuje přepínat jednotlivé optické kanály, případně je ukončit v místním zařízení. Je možné to připodobnit k VLAN v běžném switchi, jen tu vstupuje do hry optický signál.

Cílem konfigurace je nastavit všechna zařízení po cestě tak, aby se signál dostal ze vstupního zařízení celou infrastrukturou až do výstupního zařízení. V racku jsou pak umístěny jednotlivé 1U boxy, které nabízejí až osm portů. Kromě toho tam mohou být také optické zesilovače a to vše je možné konfigurovat pomocí API.

Ke konfiguraci se používají standardní protokoly jako YANG, Netconf a další. Protože používáme tyto běžné protokoly, můžeme použít dostupné moderní nástroje. Klasickým DevOps přístupem je využití Ansible a uložení konfigurace v Gitu. Celá operace přepnutí kanálu se pak skládá z přidání a odebrání konfigurace portů v jednotlivých prvcích.

Otevřenost optické vrstvy pak může sloužit i pro další služby, nejen k přenosu dat. V síti CESNET se například pracuje s distribucí přesného čas a v určitých bodech jsou dostupné zdroje času. Pro vysokou přesnost potřebujeme použít pro oba směry stejné vlákno, asymetrie by vnesla do přenosu příliš velkou chybu. Do sítě je pak potřeba přidávat zesilovače, konkrétní signál si odfiltrovat, zesílit a vrátit do sítě. Tady potřebujeme celou soustavu nějak řídit a můžeme použít naši softwarovou architekturu.

Vladimír Bureš: Evoluce k SRv6

Před rokem 2000 vznikl protokol MPLS, který do provozu přidává labely. Informace o nich se pak šíří pomocí speciálního protokolu LDP, který musí spolupracovat s místním routovacím protokolem. Vypadalo to jako dobrý nápad, protože je možné použít libovolný routovací protokol. Mezi hlavičkou druhé a třetí vrstvy se může nacházet takzvaný label stack, ve kterém je uložen seznam labelů používaných pro směrování.

Toto řešení bylo poplatné své době a časem se objevily jeho nevýhody. Zejména musíme v síti udržovat další protokol, který běží paralelně s běžným routovacím protokolem. Musíme řešit synchronizaci mezi LDP a IGP a v případě problému dojde u zákazníka k delšímu výpadku. Protože prvky konvergují v různém čase, může dojít ke smyčkám. Může to trvat pár desítek milisekund, dnes ale chceme garantovat zotavení do padesáti milisekund.

Dalším krokem je segment routing, který má nabídnout zjednodušení a cílem je odstranit protokoly s duplicitní funkcí. Je to také výhodnější z hlediska škálovatelnosti, protože prvek nemusí držet labely. Síť pak nedrží žádnou stavovou informaci, protože se využívá source routing. Síť se ke každému paketu chová nezávisle a nepoužívá žádnou předem sestavenou trubku, kterou pakety tečou.

Z hlediska použití segment routingu můžeme použít dva různé data plane. Buď můžeme použít MPLS, nebo můžeme využít nativně IPv6. Pak je segment ve formě IPv6 adresy, mám k dispozici 128 bitů a seznam segmentů můžeme uložit do rozšířené hlavičky. U MPLS se labely umístí na začátek paketu a poté se spotřebovávají a postupně po cestě odebírají.

V SRv6 se jednotlivé položky fyzicky z hlavičky neodebírají, ale je v ní uložen ukazatel na aktuální label. V hlavičce je uložena adresa cíle a položka next-header, který říká, co následuje. Může tam být TCP nebo UDP, může tam být další IPv4 paket nebo ethernetový rámec. Může tam být zabaleno prakticky cokoliv. Routování se pak provádí přes klasický IPv6 routing. Není potřeba, aby všechny uzly po cestě rozuměly SRv6, protože jde o běžné směrování.

Radim Roška, Vojtěch Šetina: Automatizace konfigurace datových center ČRA

Pro automatizaci sítě je klíčový SOT (Source of Truth), tedy informace o tom, jak se má který síťový prvek chovat. Síť je možné virtualizovat například pomocí nástroje CINTAINERlab, ve kterém je možné vše nasimulovat a otestovat ještě před nasazením samotného nástroje. To vše je první fáze, kterou je možné postupně nasadit jako náhradu původního ručního řešení.

Pro automatizaci je možné použít šablony AVD přímo od společnosti Arista, které obsahují připravené konfigurace pro většinu běžných situací. Konfigurace se pak definuje pomocí proměnných, stačí upravit dva řádky a dojde ke změně desítek voleb v různých prvcích. Výstup se pak dostane do konfiguračního nástroje CloudVision, který pak změny nasadí.

Ve druhé fázi byly přidány další nástroje napsané v Pythonu, které umožňují celou správu zjednodušit. Například pomocný skript Editor dovoluje připravit pro uživatele šablony a zařídit jejich verzování v Gitu. Pokud chci vytvořit novou službu, spustím Editor, který vytvoří změnovou větev a poté se vše pushne do hlavní větve. Předtím se ještě provede automatická validace a poté se naopak datový model přeloží a vytvoří se nové konfigurace. Posledním krokem je Deploy, který vše umožní odeslat do prvků.

Jde vlastně o stejný DevOps přístup, který je dnes přirozenou součástí vývoje software. Postupně se to přelívá do konfigurace síťových prvků. Výsledkem je vyšší efektivita, snížení rizika chyb a možnost konfigurovat síť bez detailních znalostí. K dispozici je také plná historie změn a možnost vrátit se k předchozímu stavu.

Marian Rychtecký: Jak (ne)počítat statistiky

Klasickým nástrojem pro vykreslování časových řad do grafu je MRTG, který se používá desítky let. Nevýhodou je malá pružnost, pevná časová okna a závislost na SNMP. Je to ale velmi jednoduché a výstupem jsou statické obrázky. Kvůli průměrování dat v pevném intervalu někdy z grafu zmizí krátkodobé špičky.

NIX.CZ chtěl pro zákazníky připravit novou verzi portálu s lepším grafováním. Po vyzkoušení několika řešení se vývojáři rozhodli pro vlastní řešení. Data ze sítě se do databáze ukládají už připravená a obohacená o další data z Netboxu. Data spojíme a přes API uložíme do InfluxDB. Data se získávala každých 30 sekund a ukládají se v různých podobách pro různá okna. Ukládají se tři hodnoty: minimální, maximální a průměr.

Pro přesnější data se vzorkování posunulo na 20 sekund a poté se každou minutu zprůměrují tři hodnoty všech hodnot: maximum, minimum i průměr. Nové grafy více odpovídají realitě a jsou vyhlazenější. Data bylo potřeba obohatit ještě o stavová data a časové intervaly týkající se dostupnosti jednotlivých portů, což se dá udělat rovnou v InfluxDB.

Data se pak počítají v kaskádě, kdy se delší intervaly přepočítávají z nadřazených datových sad. Sumarizaci do ročního grafu je lepší dělat z měsíčních dat než znovu ze syrového vstupu.

Zdeněk Brůna: Automatická správa DNSSEC

DNSSEC je bezpečnostní rozšíření DNS, které využívá principu asymetrické kryptografie k podepisování záznamů. Vyžaduje to podporu od registru domén, technického správce a poskytovatele připojení. Podpora v registru .CZ je přítomna od roku 2008, v té době však nebyla běžně dostupná podpora na straně resolverů. Proto jsme spustili službu otevřených resolverů ODVR, dnes běžíme na vlastním Knot Resolveru. Registrátoři byli motivováni lepším hodnocením a zařazením do certifikačního programu.

Míra podpory v doméně .CZ vyrostla postupně přibližně na 60 %, ale už delší dobu toto číslo stagnuje. Můžete tím pomocí vhodným výběrem registrátora, pokud si vyberete správně, nemusíte pro nasazení DNSSEC obvykle už nic dělat. Rozdíly mezi registrátory jsou veliké, ti největší obvykle nemají žádný problém.

V případě resolverů je podpora na vysoké úrovni, ale kolísá mezi 70 a 90 procenty. Můžete se podívat, jak to vypadá u vás a zda ve vaší síti něco nezlobí.

DNSSEC je možné pro menší počet domén zavést ručně, kdy se vygeneruje klíč, podepíší se záznamy v místní zóně a pak se přes registrátora publikují DS záznamy v nadřazené zóně. Druhou variantou je jít přes registrátora domén, který připraví a podepíše zónu za vás. Třetí možností je vygenerování jednoho záznamu CDNSKEY, o zbytek se postará registr. Vše se dá zautomatizovat, podporuje to většina autoritativních serverů.

Automatická správa DNSSEC byla zavedená v RFC 7344 a 8078, které umožní zavedení DNSSEC bez spolupráce s držitelem domény, což bývá někdy koordinačně velmi složité. Podporujeme to od roku 2017 v systému FRED a Knot DNS to umí od verze 2.5.0. Registr skenuje domény a hledá v nich záznamy typu CDNSKEY, na jejichž základě pak zavede DNSSEC.

Podpora této automatické správy je pořád brána jako nejvyšší úroveň zavedení DNSSEC a podporuje ji jen sedm ccTLD. Spolu s doménou .cz jsou to domény .sk, .ch, .li, .se .nu a .cr. Kostarika používá náš systém FRED a mohla tedy podporu snadno zavést.

Původně se o výsledcích skenů posílaly automatizované e-maily technickým správcům, což je ale velmi obtěžující. Nyní se informace o skenech objevují ve WHOIS, kde je možné celý proces sledovat.

Do budoucna je možné systém vylepšit skenováním z více lokalit, průběžném vyhodnocování skenů během dne a vyladění zobrazení informací ve whois. V tuhle chvíli je to určeno pro techniky, ale chtěli bychom to udělat příjemnější. Uvažuje se o možnosti nasazení RFC 9615, kdy se CDNSKEY záznam může vložit do jiné již podepsané zóny DNS operátora.

(Autorem fotografií je Petr Krčmář.)