Konfigurace síťových zařízení pomocí protokolu NETCONF

Ladislav Lhotka 30. 4. 2012

Pod jednoduchým jménem NETCONF se skrývá celá sada otevřených standardů zaměřených na vzdálenou konfiguraci síťových prvků, serverů a služeb všeho druhu. Proti běžným konfiguračním rozhraním (řádkovým či webovým) je jeho výhodou nezávislost na výrobci konkrétního zařízení a široké možnosti automatizace.

Málokteré zařízení lze jen tak připojit do sítě, aniž bychom ho museli jakkoli konfigurovat. U těch nejsložitějších, jakými jsou třeba IP směrovače, je konfigurace často hotová věda. I s celkem primitivními krabičkami může být ovšem pěkná dřina, pokud jich máte z jednoho místa vzdáleně konfigurovat několik desítek, stovek či tisíců.

U tak velkých sítí je naprosto nezbytné celý proces automatizovat. Osvědčený postup vypadá tak, že se v centrální databázi vytvoří reprezentace celé sítě na poměrně vysoké úrovni abstrakce, vycházející jak z technických, tak i obchodních aspektů provozu sítě. Z této databáze se pak automaticky generují konkrétní konfigurace. Zbývá poslední drobný problém: Jak je bezpečně a spolehlivě dopravit na jednotlivé prvky sítě, aniž bychom při každé změně konfigurace způsobili výpadky spojení a služeb?

Odpovědí měl být Simple Network Management Protocol (SNMP). Pro mnoho čtenářů je jistě SNMP denním chlebem, ovšem – tipuji – především jako prostředek pro sběr statistik a jiných stavových dat. Jako konfigurační nástroj se SNMP vůbec neujal. Proč? Důvodů je více, hlavním je jeho velmi strohé, datově orientované rozhraní, které valná většina výrobců ocejchovala (asi právem) jako příliš složité, málo atraktivní a tudíž neprodejné. Vytvořili proto vlastní uživatelsky přívětivá konfigurační rozhraní, nejčastěji v podobě příkazové řádky (CLI). Někteří sice konfiguraci pomocí SNMP nadále podporovali či stále podporují, neměli ale dost motivace, aby ji dlouhodobě udržovali na stejné úrovni jako své řádkové rozhraní. Výsledkem je, že některé vlastnosti nejdou pomocí SNMP vůbec zkonfigurovat.

Operátoři velkých sítí tedy zjistili, že jim pro instalaci konfigurací nakonec nezbývá jiný kanál než hlavní konfigurační rozhraní, tj. SSH či telnet a za nimi příkazová řádka. Jali se proto vytvářet nejrůznější systémy, často založené na skriptovacím jazyku Expect, které umožňují konfigurace tímto kanálem posílat a aktivovat. Podobná řešení sice mohou fungovat, jsou ale nutně křehká, nereagují dobře na chybové stavy a špatně se udržují.

V květnu 2003 proto byla při IETF ustavena pracovní skupina NETCONF. Jako svůj cíl si stanovila vytvoření otevřeného a robustního protokolu pro vzdálenou konfiguraci síťových zařízení, jehož logika by zároveň měla blízko k rozhraní příkazové řádky.

Protokol NETCONF

Aktuální specifikaci protokolu NETCONF verze 1.1 najdeme v RFC 6241. Jeho jednotlivé funkce jsou rozděleny do čtyř vrstev:

  1. Transportní vrstva se stará o přenos protokolových zpráv mezi serverem (spravovaným zařízením) a klientem (manažerskou stanicí). NETCONF může pracovat s libovolným transportním protokolem, požadují se jen jisté základní vlastnosti – spolehlivý přenos dat ve správném pořadí a všestranné zabezpečení (autentizace klienta, šifrování a zajištění integrity dat). V praxi se momentálně používají dva transportní protokoly: SSH (RFC 6242) a TLS (RFC 5539). První z nich je přitom povinný, každá implementace ho tedy musí podporovat.
  2. Vrstva zpráv poskytuje jednoduchý mechanismus pro vzdálené volání procedur (RPC, remote procedure call) a notifikace o událostech, které server zasílá klientovi bez vyžádání.
  3. Vrstva operací určuje sadu operací, které server vykonává na žádost klienta. Tato sada je rozšiřitelná, takže k základním operacím definovaným v RFC 6241 můžeme podle potřeby přidávat další.
  4. Vrstva obsahu reprezentuje vlastní konfigurační data a informace o provozním stavu spravovaného zařízení. Těm se budeme věnovat v navazujícím článku.

Pro vrstvy 2 až 4 se používá kódování pomocí XML. Kompletní zpráva protokolu NETCONF tedy může vypadat třeba takto:

<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
  </get-config>
</rpc>

Touto zprávou klient žádá o zaslání aktivní (running) konfigurace. Server by ji měl obratem zaslat v odpovědi zabalené do elementu <rpc-reply>. Jak zde vidíme, operace – v tomto případě <get-config> – mohou mít i své parametry.

Na straně serveru se konfigurační data nacházejí v úložištích (repository). NETCONF nijak nepředepisuje, jak mají být úložiště interně implementována, zabývá se pouze XML reprezentací jejich obsahu ve zprávách. U existujících implementací serverů tak narazíme na řadu variant od prostého diskového souboru až po SQL databáze. Povinné úložiště jménem running, které jsme už letmo zmínili v předcházejícím příkladu, obsahuje „provozní” konfiguraci, již zařízení aktuálně používá. Sofistikovanější implementace serverů mohou nabízet i další typy úložišť. Příkladem je úložiště candidate, v němž je možné konfigurační data dopředu připravit a atomickou operací <commit> je pak instalovat coby aktuální konfiguraci.

Jak NETCONF funguje

Podívejme se nyní na to, jak vypadá seance (session) mezi klientem a serverem. Typickou posloupnost zpráv znázorňuje obrázek.

Na začátku seance pošle server i klient zprávu <hello>, v níž každá strana povinně oznamuje podporované verze protokolu NETCONF. Pokud server implementuje některé volitelné funkce nebo vlastnosti, pak je může ve zprávě <hello> formálně deklarovat, aby se o nich klient dozvěděl a mohl se podle toho zařídit. Příkladem takové volitelné vlastnosti je třeba přítomnost úložiště candidate.

Jakmile si server s klientem vymění svá <hello>, pokračuje seance podle jednoho z následujících scénářů, které lze samozřejmě opakovat:

  • Žádost a odpověď – iniciátorem je vždy klient, který ve své zprávě <rpc> specifikuje požadovanou operaci i s případnými parametry. Proběhne-li vše řádně, pošle server svou odpověď zabalenou do <rpc-reply>. Pokud server vyhodnotí žádost jako chybnou anebo nastane nějaký problém při provádění operace, pošle místo toho chybové hlášení <rpc-error>.
  • Notifikace (RFC 5277) – nejsou povinnou součástí protokolu NETCONF, server je může používat k oznamování různých událostí, překročení prahových hodnot apod.

Základní operace

Jádro protokolu NETCONF tvoří devět základních operací definovaných v RFC 6241:

<get-config>
Požaduje obsah konfiguračního úložiště anebo jeho část určenou filtry, které mohou být uvedeny v žádosti jako jeden z parametrů.
<get>
Požaduje obsah úložiště running spolu s daty o provozním stavu zařízení. Opět lze aplikovat filtry.
<edit-config>
Požaduje modifikace určeného úložiště podle dat obsažených v žádosti.
<copy-config>
Požaduje zkopírování kompletního úložiště. Parametrem žádosti může být buď jméno jiného úložiště anebo URL, kterým se určuje jiné lokální nebo vzdálené umístění kopie.
<delete-config>
Požaduje odstranění určeného úložiště (kromě running).
<lock>
Požaduje uzamčení určeného úložiště. Po uzamčení má k celému úložišti přístup pouze ta seance, která je uzamkla, až do té doby, než zámek uvolní.
<unlock>
Požaduje uvolnění zámku pro určené úložiště.
<close-session>
Požaduje řádné ukončení seance.
<kill-session>
Vynucuje okamžité ukončení seance.

V omezeném rozsahu tohoto článku se nemůžeme popisu operací podrobněji věnovat, čtenáře lačné detailů proto musíme odkázat na jejich specifikaci v RFC 6241. Naštěstí jde na rozdíl od mnoha jiných standardů o celkem čtivý text.

Implementace

Wiki stránka pracovní skupiny NETCONF obsahuje přehled všech známých implementací protokolu NETCONF. Z těch, které jsou open source, je v současné době asi nejpropracovanější Yuma, u níž najdeme i velmi pěknou dokumentaci.

Z pohledu lokálního patriota je potěšitelné, že jednou z aktivně vyvíjených open source implementací je také projekt Netopeer, o který pečují vývojáři sdružení CESNET.

Závěrem

NETCONF jako technologie je robustním prostředkem pro automatizovanou správu konfigurací síťových zařízení. Na rozdíl od jiných srovnatelných metod umožňuje pracovat s konfiguracemi na velmi detailní úrovni a efektivně reagovat na chyby, které zvláště u složitých systémů nejsou nic výjimečného.

V navazujícím článku se příští týden budeme věnovat nástrojům pro modelování a validaci konfiguračních dat.

Našli jste v článku chybu?
Měšec.cz: Cestujte bez starostí, získejte výhodné pojištění

Cestujte bez starostí, získejte výhodné pojištění

DigiZone.cz: Prima Max bude mít letní kino. Na střeše...

Prima Max bude mít letní kino. Na střeše...

120na80.cz: Aktivita klíšťat: stupeň 9

Aktivita klíšťat: stupeň 9

DigiZone.cz: Světlé zítřky gaučových sportovců

Světlé zítřky gaučových sportovců

Podnikatel.cz: Český podnikatel a #brexit. Co nastane?

Český podnikatel a #brexit. Co nastane?

DigiZone.cz: Pardubicko: Výrazně posílen Mux 3

Pardubicko: Výrazně posílen Mux 3

Vitalia.cz: Jíme přesolené potraviny. Zrovna tyhle

Jíme přesolené potraviny. Zrovna tyhle

Měšec.cz: Co s reklamací, když e-shop krachuje?

Co s reklamací, když e-shop krachuje?

DigiZone.cz: Skylink: Nova Sport volně

Skylink: Nova Sport volně

Lupa.cz: Text umírá, na webu zbude jen video

Text umírá, na webu zbude jen video

DigiZone.cz: Boj Markízy a Novy o federální trh vrcholí

Boj Markízy a Novy o federální trh vrcholí

Lupa.cz: Jaké IoT tarify nabízejí mobilní operátoři?

Jaké IoT tarify nabízejí mobilní operátoři?

120na80.cz: Krémy, nebo spreje na opalování?

Krémy, nebo spreje na opalování?

DigiZone.cz: Soud zakázal šíření TV Markíza v ČR

Soud zakázal šíření TV Markíza v ČR

Vitalia.cz: Epidemie: Klíšťová encefalitida po ovčím sýru

Epidemie: Klíšťová encefalitida po ovčím sýru

Měšec.cz: Ceny PHM v Evropě. Finty na úspory

Ceny PHM v Evropě. Finty na úspory

Vitalia.cz: Jelení farma produkuje kvalitní maso

Jelení farma produkuje kvalitní maso

Lupa.cz: Nej aplikace? Vodafone, Mozkovna, Záchranka

Nej aplikace? Vodafone, Mozkovna, Záchranka

DigiZone.cz: Roční bonus pro Dvořáka schválen

Roční bonus pro Dvořáka schválen

DigiZone.cz: Mobilní aplikace pro DVTV je tady

Mobilní aplikace pro DVTV je tady