Hlavní navigace

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

Ladislav Lhotka

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?

3. 5. 2012 14:02

Vuk (neregistrovaný)

S tím Juniperem to bohužel není tak jednoduché - oni s tím sice začali, to ovšem taky znamená, že se jim ne vždy chtělo přizpůsobit se standardu tam, kde se standard liší od jejich původní implementace. Nenarazil jsem sice na nic, co by se nedalo obejít, ale to obcházení leckdy bylo docela na dlouho.

30. 4. 2012 15:25

Na Netopeerovi má největší zásluhu Radek Krejčí, který udělal první verzi jako svoji bakalářku a dnes pracuje s několika kolegy na verzi nové. Můj tým už je to pouze bývalý.

Specialitkou Netopeera je použití DBusu, kterým může NETCONF agent signalizovat změny jiným démonům.

Yuma by určitě také fungovala.

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

Vitalia.cz: Vychytané vály a válečky na vánoční cukroví

Vychytané vály a válečky na vánoční cukroví

DigiZone.cz: ČRo rozšiřuje DAB do Berouna

ČRo rozšiřuje DAB do Berouna

120na80.cz: 5 nejčastějších mýtů o kondomech

5 nejčastějších mýtů o kondomech

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

Podnikatel.cz: Snížení DPH na 15 % se netýká všech

Snížení DPH na 15 % se netýká všech

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Měšec.cz: Stavební spoření: alternativa i pro seniory

Stavební spoření: alternativa i pro seniory

Měšec.cz: mBank cenzuruje, zrušila mFórum

mBank cenzuruje, zrušila mFórum

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla

Vitalia.cz: Když přijdete o oko, přijdete na rok o řidičák

Když přijdete o oko, přijdete na rok o řidičák

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Vitalia.cz: Potvrzeno: Pobyt v lese je skvělý na imunitu

Potvrzeno: Pobyt v lese je skvělý na imunitu

Vitalia.cz: Proč vás každý zubař posílá na dentální hygienu

Proč vás každý zubař posílá na dentální hygienu

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí