Hlavní navigace

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

30. 4. 2012
Doba čtení: 6 minut

Sdílet

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.

root_podpora

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.

Byl pro vás článek přínosný?

Autor článku

Ladislav Lhotka pracuje jako vedoucí Laboratoří CZ.NIC, výzkumného a vývojového centra správce české národní domény – sdružení CZ.NIC.