Nahradí SNMP Netconf?

Kolem přelomu století se pracovní skupina IETF (Internet Engineering Task Force), která se zabývá SNMP (Simple Network Management Protocol), začala tak trochu cítit jako onen Miloušem Jakešem proslavený „cool v plotě“. Reálný život ukázal, že SNMP se daleko častěji používá k dohledu a vyhodnocování provozu síťových zařízení, než k jejich skutečné správě. Kromě toho MIB (Management Information Base) soustavně zaostávají za vývojem. Proto se IETF rozhodlo iniciovat vznik nového protokolu, který by danému účelu vyhovoval lépe.

Výsledkem je vznik pracovní skupiny Netconf, která se věnuje vývoji stejnojmenného protokolu. Věc je zatím dost syrová, na světě jsou teprve první návrhy klíčových dokumentů, nicméně právě teď skupina shání názory a zpětnou vazbu, zejména ze strany reálných správců sítí.

Z čeho protokol Netconf vychází? Hlavním cílem jeho vývoje bylo, aby poskytl komplexnější služby než stávající SNMP. Tím je míněno například získávání či změny komplexních konfigurací (nebo jejich částí), snadná integrace s různými databázemi, možnost ukládat a srovnávat různé verze konfigurací, poskytnout rozhraní pro programovací jazyky (API) a umožnit integraci s různými stávajícími systémy.

Jistě vás nepřekvapí, že Netconf – stejně jako prakticky všechny internetové protokoly – přenáší informace v textové podobě. A textová informace v současnosti automaticky znamená formát XML. To zároveň umožňuje opracovávat Netconf data univerzálními XML nástroji a využít například XSLT (nástroj pro změnu struktury XML souborů) pro jejich úpravy. Aby byla interpretace jednodušší, omezuje Netconf sortiment XML konstrukcí, které využívá (například nepovoluje smíšený obsah, kdy prvek může obsahovat jak data, tak jiné prvky).

Základní koncepce je podobná SNMP. Ve spravovaném zařízení bydlí Netconf server a očekává požadavky od klienta, kterým je program pro správu sítě. Na rozdíl od SNMP však Netconf důsledně odděluje konfigurační data od stavových. Přenáší celkem tři typy informací:

• konfigurační data, která popisují nastavení jednotlivých parametrů zařízení (například IP adresy jednotlivých rozhraní),
• stavová data popisující aktuální stav zařízení, sem spadají třeba veškeré statistiky provozu,
• asynchronní zprávy, kterými může zařízení informovat o výskytu významné události (například o ztrátě spojení na některém rozhraní).

Architektura Netconf je navržena jako čtyřvrstvá. Spodní vrstvou je aplikační protokol, který není pevně určen. Netconf pouze specifikuje požadavky, které na něj má: musí být spojovaný se spolehlivým přenosem dat a musí nabídnout obvyklé bezpečnostní služby. Zatím se připravuje přenos po SSH (ten mají rádi správci sítí), SOAP (který milují vývojáři) a BEEP (oblíbenec designérů protokolů).

Nad aplikačním protokolem leží vrstva RPC (Remote Procedure Call), která představuje jednoduchý mechanismus pro kódování RPC požadavků a odpovědí, samozřejmě nezávislý na transportu. Jejím ztělesněním jsou především prvky <rpc> a <rpc-reply> obalující požadavek a odpověď na něj. Kromě nich zde najdete ještě <rpc-error> pro ohlášení chyby a <ok> signalizující úspěch.

Třetí vrstvou je vrstva operací, která definuje jednotlivé činnosti protokolu Netconf. Stručný přehled základních operací uvádí následující tabulka:

Prvek, kterého se operace týká, je identifikován prvky v jejím těle podle určeného schématu. Například požadavek na zaslání seznamu uživatelů určitého zařízení může vypadat následovně:

<rpc message-id="105" xmlns="http://ietf.org/netconf/base/1.0">
  <get-config>
    <source>
      <running/>
    </source>
    <config xmlns="http://example.com/schema/1.2/config">
      <users/>
    </config>
    <format>xml</format>
  </get-config>
</rpc>

Oslovené zařízení pak odpoví třeba takto:

<rpc-reply message-id="105" xmlns="http://ietf.org/netconf/base/1.0">
  <config xmlns="http://example.com/schema/1.2/config">
    <users>
      <user>
        <name>root</name>
        <type>superuser&lt;/type>
        <full-name>Charlie Root</full-name>
      </user>
      <user>
        <name>fred</name>
        <type>admin</type>
        <full-name>Fred Flintstone</full-name>
      </user>
      <user>
        <name>barney</name>
        <type>admin</type>
        <full-name>Barney Rubble</full-name>
      </user>
    </users>
  </config>
</rpc-reply>

A konečně nejvyšší vrstvou je obsah, kde se definuje struktura a význam konfiguračních dat. Tato vrstva zůstává stranou základních dokumentů Netconf. Její obsah vymezí výrobce zařízení a případné další standardizační sna­hy.

Důležitým pojmem Netconfu je úložiště konfigurace. Jedná se vlastně o místo, kde je uložena kompletní konfigurace daného zařízení. Jako základní a povinné je do Netconfu zařazeno úložiště <running>, které představuje aktuální stav a konfiguraci zařízení. Kromě něj ale mohou být podporována i další.

Tím se dostáváme k obecnému problému konfiguračních nástrojů: existence všelijakých rozšíření a nadstandardů, které si vymysleli výrobci jednotlivých zařízení. Netconf na ně reaguje zavedením takzvaných schopností (capabilites). Schopnost je sada určitých funkcí rozšiřujících základní NETCONF – může například oznamovat existenci dalších úložišť či rozšiřovat sortiment operací, které je zařízení schopno provádět. Při zahájení komunikace si oba účastníci sdělí své schopnosti a dohodnou podle nich sadu, kterou budou používat.

Schopnosti si může definovat podle svého každý výrobce zařízení podporujících Netconf. Jsou identifikovány prostřednictvím URI, které má povinný tvar:

http://autori­ta/protokol/ka­tegorie/verze#jmé­no

Schopnosti definované přímo v návrhu NETCONF používají URI

http://ietf.or­g/netconf/base/1­.0#jméno

Návrh Netconfu definuje sedm základních schopností, kterými si partneři mohou například sdělit, kdo chce řídit a kdo chce být řízen, nebo že mají k dispozici další úložiště (konkrétně <candidate> pro kandidáta na běžící konfiguraci, kterého lze dodatkovými operacemi upravovat a následně potvrdit přesun jeho obsahu do <running>, a <startup> pro konfiguraci, která bude použita po startu zařízení).

Ambice Netconfu jsou nemalé. Mluví se například o databázích síťových konfigurací, na jejichž základě budou prostřednictvím Netconfu řízeny všechny aktivní prvky v síti. Mluví se o jazycích (na bázi XML, jak jinak) popisujících topologii sítě, která pak povede k sestavení konfigurací pro její prvky. Ovšem jak to doopravdy dopadne, ukáže teprve čas.