Z IETF 84: SNMP data pod křídla NETCONFu?

Můj druhý postřeh z meetingu IETF 84 se také týká protokolů a nástrojů pro síťový management. Zatímco minulý příspěvek byl věnován konfiguračním datům, dnes bych se rád zmínil o jedné diskusi týkající se stavových dat, která jsou pro efektivní správu síťových zařízení také velmi důležitá. Čím se liší od těch konfiguračních? Rozdíl můžeme ukázat na jednoduchém příkladu IP adresy. Ta může být pro dané rozhraní buď statická, a pak je zapsána někde v konfiguračních datech, anebo se získává pomocí DHCP a její aktuální hodnotu může správce zjistit ze stavových dat. Za stavová data se obvykle považují i různé statistické čítače, kupříkladu počty bajtů přijatých a odeslaných přes dané rozhraní.

Pro práci s oběma typy dat jsou k dispozici dva konkurenční protokoly: SNMP a jeho mladší bratranec NETCONF. Pokud jde o konfigurační data, hovoří vše celkem jasně pro NETCONF, SNMP se v této oblasti neosvědčil a dnes se prakticky nepoužívá. U stavových dat je ale situace do velké míry opačná a SNMP tu zatím jednoznačně vládne. Síťovým operátorům už se ovšem dosti zajídá spravovat sítě pomocí dvou různých protokolů – a začínají se hlasitě ozývat.

Diskuse na toto téma propukla na IETF 84 poněkud nečekaně během jednání pracovní skupiny OPSAWG, když byl na programu Internet draft draft-schoenw-opsawg-vm-mib-01, který definuje část databáze SNMP MIB se stavovými daty pro virtuální počítače s hypervizorem. Rozbuškou však nebyl tento celkem nevinný dokument, ale osoba přednášejícího: byl jím Jürgen Schönwälder, který je jednou z vůdčích figur stojících za návrhem protokolu NETCONF. Dotaz z pléna zněl zhruba takto: „Jestli to s NETCONFem myslíte vážně, proč nás pořád zásobujete novými daty pro SNMP a neimplementujete raději stejná data v NETCONFu?“ Většina diskutujících se pak skutečně přiklonila k názoru, že by bylo velmi prospěšné toto schizma postupně odstranit a mít všechna stavová data k dispozici prostřednictvím NETCONFu.

To se snadno řekne, ale hůře udělá. Převod všech definic objektů z databáze MIB (zapsaných v jazyku SMIv2) na datový model pro NETCONF (v jazyku YANG) je sice možný, vzhledem k vysokému počtu MIB objektů je to ale práce pro vraha, a tak se do ní nikomu nechce. Druhou alternativou, která se již také testovala, je proto automatický převod. Pro tento účel dokonce existuje specifikace v RFC 6643, jehož autorem je shodou okolností rovněž Jürgen Schönwälder.

Jenže, jak víme i z jiných případů, výsledky strojového překladu nebývají zrovna ideální. V daném případě se naráží jednak na některé nekompatibility mezi jazyky SMIv2 a YANG (příkladem je rozdílný způsob indexace objektů v databázi), ale také na problém převodu důležitých informací zapsaných v MIB modulech volným textem – doplňujících popisů a implementačních instrukcí.

Momentálně tedy převládá názor, že automatický převod lze použít ad hoc v případě akutní potřeby přístupu k MIB datům pomocí protokolu NETCONF. Z dlouhodobého hlediska bude ale asi nezbytné podstoupit martyrium spojené s ruční konverzí. Vypadá to tedy, že internetová komunita má v této oblasti o práci postaráno na řadu příštích let.

Ladislav Lhotka

Z IETF 84: standardizace konfiguračních dat

Během posledního meetingu IETF, který měl pořadové číslo 84 a konal se v kanadském Vancouveru, se výsledky mých „kmenových” pracovních skupin NETCONF a NETMOD objevily v zajímavé diskusi na širších fórech, konkrétně v mailing listu ietf@ietf.org, při jednání pracovní skupiny OPSAREA (Operations and Management Area), jakož i v kuloárních debatách.

Diskusi zahájil svým příspěvkem polský kolega Robert Raszuk. Pozastavil se nad tím, že ve specifikacích nových protokolů chybí schéma konfiguračních dat, a navrhl, aby všechna RFC povinně obsahovala oddíl s takovým schématem, protože bez něho si každá implementace vytváří svůj vlastní způsob konfigurace, který nemusí být s ostatními zrovna kompatibilní. Problém je to reálný, kdo by tomu nevěřil, ať si zkusí mezi sebou převést netriviální konfigurace směrovačů různých výrobců (včetně našeho BIRDa).

Navrhované řešení, tedy zavést toto jako povinnost, se ovšem setkalo s jednoznačným odporem. Robertovi se též dostalo doporučení, aby se seznámil s výsledky pracovní skupiny NETMOD, kde se již datové modely pro některé základní protokoly a subsystémy vyvíjejí.

V této souvislosti se ale ukázalo, že datové modely NETMOD tak docela nenaplňují vizi unifikace konfiguračních schémat. Jsou totiž poměrně pružné a umožňují definovat schémata v různých podobách, od odlišností v pojmenování objektů (klasickým příkladem jsou třeba jména síťových rozhraní) až po menší či větší rozdíly v logice a uspořádání konfiguračních dat. Důvody jsou nasnadě: Nelze očekávat, že přední výrobci směrovačů a jiných zařízení po zveřejnění datových modelů srazí paty a překopou svá konfigurační rozhraní, která si po léta hýčkají a školí na nich své zákazníky. Jistá míra pružnosti proto dává naději, že by se konkrétní implementace datových modelů mohly naopak přizpůsobit existujícím konfiguračním rozhraním. Lze pak ovšem očekávat, že nebude možné jednoduše vzít konfiguraci jednoho boxu a instalovat ji beze změn na obdobném zařízení jiného výrobce.

Toto je docela složité dilema, uvidíme, jak se věci vyvinou. Rozhodně by ale bylo dobré, kdyby se specifikace konfiguračního schématu staly součástí standardů aspoň pro nové protokoly – byť třeba nepovinně.

Ladislav Lhotka

OpenFlow s otazníky

Abych řekl pravdu, dosud jsem si myslel, že OpenFlow je záležitost povýtce akademická a nemá  valného praktického významu. Přispěla k tomu jistě i prezentace „Software Defined Networking“ na IETF 82, která ve mně i řadě dalších posluchačů zanechala dojem ryzího slidewaru.

Krátká přednáška Todda Underwooda (Google) na nedávném RIPE 64 mě ale přivedla k úvahám, zda bych neměl svůj postoj k OpenFlow a SDN přehodnotit. Google totiž používá OpenFlow switche ve dvou svých produkčních páteřních sítích, které propojují lokality na třech kontinentech. OpenFlow jim umožňuje pojímat tyto sítě jako systém pro transport dat a ne pouze jako soubor jednotlivých switchů a linek.

OpenFlow je postaven na myšlence oddělení forwardovací logiky (data plane) od směrovacích, filtrovacích a jiných algoritmů (control plane). Zatímco data plane zůstává „zadrátovaná“ ve switchi, control plane se přesouvá na samostatný počítač (controller), který může řídit jeden nebo více switchů. Jádrem OpenFlow je protokol a API umožňující kontroléru konfigurovat zacházení s pakety ve switchi.

OpenFlow předpokládá, že data plane je ve switchi implementována ve formě tabulky toků s využitím hardwarové asociativní paměti (TCAM). V tom ovšem vidím jistý problém: špičkové TCAM čipy mají kapacitu jednotek až desítek tisíc položek, takže se do nich rozhodně nevejde kompletní směrovací tabulka BGP. Mohli bychom sice zvolit alternativní strategii – plnit tabulku na základě toků, které switch skutečně přenáší – ale ani s tou se moc daleko nedostaneme, protože typické počty aktivních toků v páteřních internetových směrovačích kapacitu TCAM rovněž vysoko překračují. Zdá se tedy, že kombinace OpenFlow switche a směrovacího démona není v roli obecného BGP routeru příliš použitelná.

Myslím si ale, že i tak bychom se v Laboratořích CZ.NIC mohli OpenFlow trochu podívat na zoubek. Minimálně by stálo za to demonstrovat, že OpenFlow switch může fungovat i s BIRDem v pozici kontroléru (Google používá Quaggu). Je docela možné, že takový hardwarově akcelerovaný směrovač by se mohl v některých situacích dobře uplatnit.

Za pozornost stojí také standard OF-CONFIG 1.0, který se zabývá konfigurací a správou „provozního kontextu“ OpenFlow switche, tedy de facto všeho kromě tabulky toků. Standard pro tento účel používá protokol NETCONF a datové modely zapsané v jazyku YANG. Jde zřejmě o dosud největší otevřeně dostupnou aplikaci technologií NETCONF/YANG.

Ladislav Lhotka