Průzkum standardu NetConf (RFC4741-4) pro konfiguraci síťových prvků a možností praktického užití s platformou Cisco IOS Jiří Vjater (vja006) a Rostislav Žídek (zid092) Abstrakt: Úkolem tohoto projektu bylo prozkoumat standard IETF pro konfiguraci sítových prvků NetConf, porozumět jeho principům, zvážit jeho možnosti a výhody nebo nevýhody. Dále se pak zaměřit na existující implementace tohoto standardu a vyzkoušet jej reálně nasadit. Klíčová slova: NetConf, RPC, Cisco ED-I, Yenca, Netopeer 1 Úvod...2 2 IETF NetConf ( RFC4741-4)...2 2.1 Základní princip...2 2.2 Schopnosti (Capabilites)...2 2.3 Rozdělení konfigurace a stavových dat...3 2.4 Požadavky na transportní vrstvu...3 2.5 Autentizace, Integrita a Důvěryhodnost...3 2.6 Formát obsahu...3 2.7 Definované operace...5 2.7.1 <get-config>...5 2.7.2 <edit-config>...5 2.7.3 <copy-config>...6 2.7.4 <delete-config>...6 2.7.5 <lock>...7 2.7.6 <unlock>...7 2.7.7 <get>...7 2.7.8 <close-session>...7 2.7.9 <kill-session>...8 2.8 Navázání spojení...8 2.9 Filtrování odpovědí...8 3 Implementace NetConfigu...11 3.1 Cisco ED-I...11 3.2 Yenca...12 3.3 YencaP...12 3.4 Netopeer...12 4 Praktické nasazení...12 4.1 Cisco ED-I...12 4.2 Yenca...14 4.3 Netopeer...15 4.4 Zoufalé pokusy...15 5 Závěr...17 6 Použitá literatura...18 listopad 2009 1/26
1 Úvod Hlavním úkolem protokolu NetConf je nadefinování jednoduchého mechanismu, pomocí kterého by mohly být konfigurovány síťová zařízení různých výrobců. Zároveň však NetConf umožňuje konfigurování i výrobcem specifických rysů. Aby toho bylo možné dosáhnout, pracuje NetConf na architektuře klient-server. Pomocí protokolu tak lze vystavit celé API konfigurovaného zařízení. A to takovým způsobem aby mohly aplikace určené pro konfiguraci pomocí NetConfu (klienti) rozpoznávat, jaké operace vlastně zařízení podporuje a jakým způsobem je konfigurovat. Aplikace pak mohou díky možnosti získání schopností konfigurovaného zařízení získávat a zasílat úplné, nebo jen částečné (inkrementální) konfigurace. 2 IETF NetConf ( RFC4741-4) 2.1 Základní princip NetConf využívá pro komunikaci paradigma RPC (Remote Procedure Call). Jde o komunikaci klientserver, kde se vyměňují zprávy dotaz (RPC a odpověď (RPC-reply). Uvnitř volaní RPC je pak obsažen XML dokument obsahující buďto příkaz pro vykonání na serverové straně nebo požadavek na data či aktuální konfiguraci). Odpovědí je pak RPC-reply, která obsahuje požadované informace, celou nebo částečnou konfiguraci a nebo jen odpověď OK, pokud byl příkaz bezchybně vykonán. V případě chyby je pak server (konfigurované zařízení, nebo jej zastupující agent) povinen ohlásit chybu, z pevně definované množiny chyb. Množina může být rozšířena o další, platformě závislé chyby, na základě dohodnutých schopností zařízení(capabilities) na obou stranách účastnících se dialogu. Struktura dokumentu XML (příkazu/odpovědi) se může lišit dle výrobce, nebo verze OS bežící na daném zařízení. Proto není struktura dokumentu XML pro výměnu dat definována přesně. Je definována pouze základní XSD šablona (struktura XML dokumentu = XML Schema), kterou musí splňovat každé zařízení podporující protokol NetConf komunikující v základním režimu. O rozšíření, nebo nahrazení této šablony se případně dohodnou klient a server na základě svých schopností (Capabilities). Komunikace pomocí protokolu NetConf, jak již bylo zmíněno, je založena na voláních RPC a dá se rozdělit do čtyřech vrstev: 4. obsah (konfigurace, vlastni data, výpisy) 3. operace (<get-config> <edit-config>) 2. RPC (<rpc> <rpc-reply>) 1. transportní protokol (ssh, ssl, console, beep) Transportní vrstva se stará o navázání komunikace mezi klientem a serverem. NetConf může využít jakýkoli transportní protokol, který splňuje sadu základních požadavků (bezpečnost, autorizaci, autentizaci...) na transportní protokol. Vrstva RPC zajišťuje jednoduchý, transportně nezávislý mechanismus pro výměnu zpráv. Operační vrstva definuje sadu základních operací, volané jako RPC metody s parametry ve tvaru XML dokumentu. Vrstva obsahu nebude diskutována v tomto dokumentu, protože se jedná o platformě velmi závislou věc a nezávisí na implementaci protokolu NetConf. Předpokládá se, že o formátu obsahu se informují zařízení mez sebou pomocí svých schopností (Capabilities) a obě komunikující strany daný formát znají (jinak nemohou propagovat danou schopnost). Jednotlivé zprávy RPC ze strany klienta mohou být odesílaný i dříve, než je doručena odpovídající RPC-reply ze strany serveru. Zařízení v roli server zodpovídá za zasílání RPC-reply ve stejném pořadí, v jakým byly doručeny RPC požadavky. Vlastní konfigurace probíhá prostřednictvím zasílání požadavků na vykonání operací nadefinovaných na třetí vrstvě obsahující data v dohodnutém XML formátu. 2.1 Schopnosti (Capabilities) V kontextu protokolu NetConf se schopností (Capability) rozumí množina funkcionalit. Každá z těchto množin je identifikována jednoznačným URI (uniform resource identifier). Každé zařízení splňující standard musí podporovat alespoň základní množinu schopností (výměna zpráv hello, pro dohodnutí podporovaných schopností zařízení, zaobalování/rozebírání operací do/z zpráv RPC, základní operace, základní XSD strukturu, chování při chybě a další... hrubě ji vystihuje tento dokument, úplná specifikace základních schopností listopad 2009 2/26
je pak popsána v [1]). Tato základní množina schopností zařízení znamená umím NetConf a propaguje se jako urn:ietf:params:netconf:base:1.0. Tato schopnost musí být uvedena ve zprávě hello povinně. Pokud zařízení umí cokoli navíc, může tyto schopnosti rovněž nabídnout prostřednictvím hello zprávy, kde budou tyto schopnosti nabízeny svým jednoznačným URI. Takže se mohou oba zařízení dohodnout na co nejširší sadě operací, které oba zařízení vzájemně zvládají. Rozšiřující schopnosti mohou být libovolně rozšiřovány různými výrobci, ale ti jsou zavázání dodržovat konvence pro pojmenování pomocí URI, aby byly jména schopností vždy jednoznačné. Výměna schopností mezi komunikujícími zařízeními probíhá ve fázi navázaní spojení pomocí zprávy hello. Protože vypisování celých jmen URI vytváří nepěkné zalamování řádků, zavedeme si zde naši soukromou konvenci zkracování URI. Pokud budu dále v tomto dokumentu hovořit o schopnostech zařízení, budu vynechávat urn:ietf:params:netconf ze jména schopnosti. Takže například urn:ietf:params:netconf:base:1.0 bude jen :base:1.0. Pokud by dvojtečce předcházelo něco jiného, uvedu jméno schopnosti celým jménem. 2.2 Rozdělení konfigurace a stavových dat Informace, které mohou být prostřednictvím NetConfu ze zařízení získány se dělí do dvou tříd. Konfigurace a stavová data. Konfigurace jsou data, která svým zapsáním transformují systém z jeho výchozího stavu do stavu, ve kterém operuje. Stavová data mohou být například různé ladící hlášení nebo statistiky provozu zařízení. Pokud by stavová data byly obsahem konfigurace, mohly by vyvstat různé problémy. Porovnání konfigurací by bylo silně ovlivněno nepodstatnými věcmi, jako jsou statistiky provozu jednotlivých rozhraní Mohlo by docházet k sestavení nesmyslných příkazů, jako zápis dat jen ke čtení Konfigurace by mohly nabývat obrovských velikostí Archivované konfigurace by mohly obsahovat data ke čtení z již dávno neexistujícího stavu 2.1 Požadavky na transportní vrstvu NetConf používá výměnu zpráv založenou na modelu RPC. Klient posílá sérii RPC zpráv, což vyvolává odpovědi RPC-reply ze strany serveru. NetConf není vázán jen na jeden transportní protokol, právě naopak může operovat na jakémkoli transportním protokolu, který splňuje určité základní požadavky. NetConf je spojově orientován. Požaduje tedy perzistentní spojení mezi peery. Spojení musí být spolehlivé a nesmí docházet k zpřeházení. Spojení NetConfu trvají dlouho (déle než jednotlivá operace), čímž je klientovi umožněno změnit stav spojení, který potrvá po dobu celého spojení. Například přihlašovací informace se pošle pouze jednou a musí být udržena až do doby, kdy je spojení ukončeno. Zdroje asociované se spojením musí být automaticky uvolněny při rozpadu spojení. (zámky na konfiguraci musí být uvolněny...) 2.2 Autentizace, integrita a důvěryhodnost NetConf se v těchto oblastech spoléhá na transportní protokol. Jednotlivá zařízení předpokládají, že byl uživatel správně ověřen a že identita je prokázána. Proces autentizace by tedy měl být završen tak, aby přístupová práva byly oběma zařízením známa. Tyto práva musí být udržena po celou dobu spojení. Každá implementace Netconfu musí podporovat alespoň SSH transportní protokol. 2.3 Formát obsahu Jako formát pro výměnu obsahu byl zvolen jazyk XML. Umožňuje totiž vyjádřit složitou hierarchickou strukturu dat v textovém formátu, je snadno uložitelný (s ohledem na serializaci). A existují nástroje pro manipulaci s daty jak na úrovni textových nástrojů, tak i programátorských API pro manipulaci s XML. Také lze transformovat konfigurace různých výrobců, nebo nebo release OS na základě XSL transformací. Aby byl nadefinován jednoznačně základní formát, je tento formát definován normou. Všechny povinné (základní) elementy protokolu NetConf jsou definovány jako schopnosti (Capabilities) v namespace :base:1.0. Všechny ostatní schopnosti musí být rovněž nadefinovány pomocí XSD a pojmenovány pomocí URI. Definování vlastních struktur dokumentů uvnitř obsahu je ZAKÁZANO. Základním elementem všech zpráv je <rpc> nebo <rpc-reply>. <rpc> element povinně obsahuje atribut message-id, který je identifikátorem RPC požadavku. Zpravidla je toto číslo náhodně generováno. Toto číslo listopad 2009 3/26
se dále nijak neinterpretuje, jde jen o identifikátor pro zprávu RPC-reply na jehož základě se pak zprávy párují. Odpověď RPC-reply na každou RPC zprávu musí nést message-id původní zprávy. Pokud je ve zprávě RPC libovolný další atribut, musí být vrácen i v RPC-reply. A namespace, který říká podle kterého je zpráva RPC sestavena (protože zařízení může zvládat více druhů RPC zpráv, a také base:1.0 může být později rozšířeno řekněme na base:1.1 atd... Nebylo by pak jednoznačné, podle kterého XSD se má příchozí zpráva validovat a rozebírat...). Struktura zprávy RPC definované podle :base:1.0 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ex="http://example.net/content/1.0"ex:user-id="fred"> </rpc> <get/> Struktura možné korespondující odpovědi RPC-reply: <rpc-reply message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ex="http://example.net/content/1.0" ex:user-id="fred"> <data> <!-- contents here... --> </data> </rpc-reply> Nebo pokud je obsahem RPC operace, která nevrací žádná data, vyřízena na serveru bez chyb, je vrácen pouze element <ok>. <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> Pokud dojde při zpracování RPC požadavku k chybě, pak je obsahem RPC-reply element <rpc-error>. Každé zařízení musí ohlásit alespoň první chybu. Nicméně se předpokládá, že by mohly detekovat chyby všechny. Pak je v těle <rpc-reply> elementů <rpc-error> více. Zprávy error jsou jednoznačné. Zpráva error obsahuje následující informace: error-type (definuje vrstvu, na kterou chyba patří transport, rpc, protocol, application) error-tag (závažnost chyby error, warning) error-app-tag (obsahuje řetězec informujici o data-model-specifických chybách, není povinný) error-path (obsahuje absolutni Xpath výraz, identifikující místo chyby) error-message (řetězec pro lidské porozumění chybě) error-info (další přidružená data k chybě, toto je dále definováno standardem viz [1] příloha A) Ukázka chyby - <rpc> element, který server dostal od klienta, neobsahoval povinný atribut message-id. Mimochodem tato ukázka je zajimavá tím, že jde o jediný případ, kdy nemusí být v odpovědi <rpc-reply> uvedeno message-id. (Odkud by se vzalo že?) <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> </get-config> </rpc> listopad 2009 4/26
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>rpc</error-type> <error-tag>missing-attribute</error-tag> <error-severity>error</error-severity> <error-info> <bad-attribute>message-id</bad-attribute> <bad-element>rpc</bad-element> </error-info> </rpc-error> </rpc-reply> 2.4 Definované operace NetConf v základními schopnostmi poskytuje malou sadu nízkoúrovňových operací pro správu a pro výběr stavové informace ze zařízení. Základní operace jsou čtení, přidání, zkopírování a smazaní konfigurace ze zařízení. Tyto operace jsou provádět nad virtuálními konfiguracemi, podporuje-li to zařízení. Tím se rozumí, že jedno zařízení může mít více instancí své konfigurace... (running, startup, candidate a tak různě) Rozšíření instrukční sady se provede na základě schopností, které si zařízení vzájemně vymění. Základní operace jsou: get get-config edit-config copy-config delete-config lock unlock close-session kill-session Operace definovány standardem NetConf však mohou selhat z několika důvodů, včetně operace není podporována. Takže by zadavatel příkazů měl brát na zřetel, že ne vždy zadaná operace uspěje. Návratové hodnoty RPC-reply by proto měly být kontrolovány na chybová hlášení. Základní XSD (XML schéma) pro operace jsou definovány standardem. [1] příloha B. Parametry jednotlivých operací jsou interpretovány jako pod-element vnořený v elementu operace. 2.4.1 <get-config> Požádá zařízení o úplnou nebo částečnou konfiguraci (záleží na filtru) parametry: source jméno virtuální konfigurace (<running/>) filter filtrovací element identifikuje části konfigurace, které opravdu chceme. Pokud je tento element prázdný, vrací se celá konfigurace. Filtrování se budeme věnovat později pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <data> ve kterém jsou výsledky dotazu reprezentována v dohodnutém XML schematu negativní odpověď: Do zprávy <rpc-reply> je vrácen jeden nebo více elementů <rpc-error>. Jednotlivé elementy <rpc-error> obsahují data potřebná pro vyhodnocení příčin chyb 2.4.2 <edit-config> Nahraje celou nebo část specifikované konfigurace do cílové konfigurace. Tato operace umožňuje, aby byla nová konfigurace vyjádřena několika způsoby. Jako například soubor nebo jako inline. Pokud cílistopad 2009 5/26
lová konfigurace neexistuje, bude založena. Tento příkaz může být rozšířen schopností :url capability [1]. Takže je možné zadávat cílové konfigurace i soubory v síti. Nejde však o pouhé přehrání konfigurace. Konfigurace jak zdrojová tak cílová je nejprve analyzována a pak jsou provedeny na základě elementu operation a XSD modelu konfigurace požadované inkrementální změny. Atributy: operation Element v podstromu <config> může obsahovat atribut operation. Tento atribut pak dává návod jakým způsobem se má upravovaná konfigurace modifikovat. Pokud není atribut operation specifikován, pak se použije implicitní chování merge (řádek se přidá do konfigurace) parametrem elementu operation může být: merge (implicitní chování) konfigurační část označená merge se přidá do konfigurace replace konfigurační část označená replace přepíše původní odpovídající část konfigurace create konfigurační část označená create je vytvořena a přidána do konfigurace, ovšem jen a pouze tehdy, pokud ještě zařízení danou část konfigurace nemá nastavenu delete konfigurační část označená elementem jsou odstraněna z konfigurace Parametry: target: jméno konfigurace k editování (<running/>, <startup/>) default-operation: vybere implicitní operaci pro atribut operation. Tento parametr je volitelný, když chybí, použije se operace merge. Parametry jsou: merge replace none parametr none se hodí pro testování, zda je konfigurace v pořádku. Přestože s tímto paramet rem nedojde ke změně konfigurace, budou při chybě v ověřování proti XSD šabloně gene rovány zprávy <rpc-error> error-option: co se má dělat, pokud se narazí v průběhu konfigurování na chybu stop-on-error contionue-on-error rollback-on-error pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <ok>. negativní odpověď: Do zprávy <rpc-reply> je vrácen jeden, nebo více elementů <rpc-error>. Jednotlivé elementy <rpc-error> obsahují data potřebná pro vyhodnocení příčin chyb 2.4.1 <copy-config> Vytvoří nebo přepíše celou virtuální konfiguraci obsahem zdrojové konfigurace. Pokud zařízení podporuje schopnost :url [1] příloha A, můžou být cílová a zdrojová konfigurace síťový zdroj. Parametry: target, source cílová a zdrojová instance konfigurace (může jít o virtuální konfiguraci, či soubor) pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <ok>. negativní odpověď: listopad 2009 6/26
Do zprávy <rpc-reply> je vrácen jeden nebo více elementů <rpc-error>. Jednotlivé elementy <rpc-error> obsahují data potřebná pro vyhodnocení příčin chyb 2.4.1 <delete-config> Smaže virtuální konfiguraci. Instance <running/> nemůže být smazána. Parametry: target konfigurace, kterou chcete smazat. pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <ok>. negativní odpověď: Do zprávy <rpc-reply> je vrácen jeden nebo více elementů <rpc-error>. Jednotlivé elementy <rpc-error> obsahují data potřebná pro vyhodnocení příčin chyb 2.4.1 <lock> Operace lock umožňuje klientovi zamknout konfiguraci, s kterou právě pracuje. Zámek má být jakási náhrada za vynechání transakčního řízení a je to tedy nástroj jak předejít interakci s jinými klienty Netconfu, SNMP, CLI skriptů nebo jiných správců. Při ukončení spojení jsou zámky automaticky zrušeny. Parameters: target jméno konfigurace, kterou chceme zarezervovat pro sebe pozitivní odpověd: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <ok>. negativní odpověd: Do zprávy <rpc-reply> je vrácen<rpc-error>. Pokud je příčinou selhání této operace již existující zámek, bude obsahem tagu <error-info> <session-id> vlastníka zámku (jiný NetConf klient). Pokud nejde o zámek jiného klienta NetConf, pak je session-id rovno 0. Zámky jsou globální na celou virtuální konfiguraci. 2.4.1 <unlock> Operace unlock je párovou operací k operaci <lock>, slouží k odstranění vlastního zámku. Operace unlock selže, pokud žádný zámek neexistuje, nebo pokud se snažíme odstranit cizí zámek. Parametry: target jméno konfigurace, kterou chceme odemknout pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <ok>. negativní odpověď: Do zprávy <rpc-reply> je vrácen<rpc-error>. 2.4.1 <get> Požádá zařízení o konfiguraci <running/> a stavovou informaci. Parametry: filter: pomocí filtru lze vybrat, které části konfigurace a stavových dat chceme. Pokud je ponechán prázdný, vybíráme všechna data. pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <data> ve kterém jsou výsledky dotazu reprezentována v dohodnutém XML schematu listopad 2009 7/26
negativní odpověď: Do zprávy <rpc-reply> je vrácen jeden, nebo více elementů <rpc-error>. Jednotlivé elementy <rpc-error> obsahují data potřebná pro vyhodnocení příčin chyb 2.4.2 <close-session> Počká na zpracování všech RPC zpráv doručených před operací <close-session> a uzavře komunikaci mezi serverem a klientem. Také odstraní všechny případně zanechané zámky. pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <ok>. negativní odpověď: Do zprávy <rpc-reply> je vrácen <rpc-error> obsahují data potřebná pro vyhodnocení příčin chyby. 2.4.3 <kill-session> Uzavření komunikace mezi serverem a klientem násilně. Tedy bez ohledu na momentálně probíhající akce. Také odstraní všechny případně zanechané zámky. Tato operace má parametr session-id, který identifikuje číslo spojení, které požadujete násilně ukončit. Lze tak uzavřít i spojení jiného klienta (nebo nesprávně uzavřeného spojení). A zmocnit se tak jeho zamčené konfigurace ;-) pozitivní odpověď: Pokud dokáže zařízení uspokojit požadavek, pošle <rpc-reply> obsahující element <ok>. negativní odpověď: Do zprávy <rpc-reply> je vrácen <rpc-error> obsahují data potřebná pro vyhodnocení příčin chyby. 2.5 Navázání spojení Primárním úkolem, který se musí vyřešit, než bude navázáno spojení je autentizace, autorizace a dohoda schopnosti jednotlivých zařízení. Tvůrci protokolu NetConf delegovali otázky autentizace a autorizace na transportní protokol, takže nám při navazování spojení zbývá vyřešit schopnosti jednotlivých zařízení. Schopnosti(Capabilities) jednotlivých zařízení jsou vyměněny pomocí zpráv hello, které oba účastníci komunikace musí odeslat. Když se tedy otevře spojení (bezpečné, s potvrzenou identitou a přístupovými právy (ve standardu povinně implementováno SSH) musí oba zařízení poslat element <hello> obsahující seznam svých schopností. Minimálně musí obě strany zaslat schopnost: :base:1.0. Zpráva <hello> ze strany serveru musí obsahovat <session-id> element s číslem zřízovaného spojení, pod kterým bude zaregistrováno v NetConfu. Klient naopak ve své zprávě <hello> mít <session-id> nesmí. Pokud server obdrží zprávu hello s elementem <session-id> je povinen spojení ukončit. Ukázkové hello od serveru: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> <capability> urn:ietf:params:netconf:capability:startup:1.0 </capability> </capabilities> <session-id>4</session-id> </hello> listopad 2009 8/26
Ukázkové hello od klienta: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> Tito dva partneři se pak dohodnou pouze na :base schopnostech. A server bude očekávat RPC zprávu s definovaným obsahem. Obsahem může být operace definovaná v :base. Viz kapitola 2.7, nebo [1] 2.6 Filtrování odpovědí Zajímavou možností protokolu NetConf je filtrování odpovědí. Konceptuálně jde o upřesnění příkazu <get>, nebo <get-config>. Filtruje se pouze datová část odpovědi a to na základě sestaveného filtru. Filtr je parametrem volání <get> nebo <get-config>. Filtrování se provádí na straně serveru (zařízení). Pokud element <filter> ve volání <get> nebo <get-config> neuvedeme, není odpověď filtrována, vrátí se tedy kompletní konfigurace. Sestavování filtru se provádí inkrementálně. Tedy cokoli z odpovědi chceme dostat, musíme si o to říci. Z toho plyne jednoduchá vlastnost. Vložíme-li do těla operace <get> nebo <get-config> pouze prázdný element <filter/> bude odpověď postrádat datovou část. Filtr lze sestavit s použitím pěti základních komponent. Výběr namespacem (Namespace selection) Výběr shodou hodnoty atributu (Attribute match selection) Obalující uzly (Containment nodes) Výběrové uzly (Selection nodes) Výběr shodou hodnoty elementu potomka (Content match nodes) Výběr namespacem (Namespace selection) Pokud použijeme výběr namespacem, pak jsou ve výpise zahrnuty pouze elementy z vybraného namespace. Protože namespace je však hodnota atributu, nelze se na něj dotazovat samostatně. Je potřeba vždy jednoznačně říct, ke kterému elementu se namespace váže. Z daného elementu pak budou vypsány jen ty atributy a podelementy, které jsou definovány ve zvoleném namespace. <filter type="subtree"> </filter> <top xmlns="http://example.com/schema/1.2/config"/> Výběr shodou hodnoty atributu (Attribute match expressions) Každý atribut, který se objeví v podstromu filtru, je považovaný jako výběr shodou hodnoty atributu. Jde o upřesnění které podstromy od zvolených elementů chceme vybrat. Do výpisu budou zahrnuty jen podstromy těch elementů, které mají i definovaný výběrový atribut a jehož hodnota vyhovuje výrazu použitém v definici filtru. <filter type="subtree"> <t:top xmlns:t="http://example.com/schema/1.2/config"> </t:top> </filter> <t:interfaces> <t:interface t:ifname="eth0"/> </t:interfaces> listopad 2009 9/26
V příkladu filtru jsou elementy <top>, <interfaces> a <interface> obalujícími elementy a ifname je Výběr shodou hodnoty attributu. Pouze <interface> uzly, definované v namespace http://example.com/schema... jako pra-potomci uzlu top a potomci uzlu interfaces, které mají attribut ifname = eth0 budou zahrnuty do výpisu. Obalující uzly Uzly, které mají POTOMKY v podstromu filtru, jsou nazývány obalujícími uzly. Každý potomek může být libovolným typem uzlu (včetně obalujícího uzlu to tehdy, mají-li další potomky). Pro každý obalující uzel, který je použit v podstromu filtru, jsou zahrnuty do výpisu všechny jeho výskyty, které se shodují v namespace, v definované hierarchii vnoření a také všemi definovanými hodnotami atributů. Výběrové uzly Každý prázdný list, je v elementu <filter> interpretován jako výběrový uzel a znamená explicitní výběr. Tedy definuje kořeny podstromů, který chceme vypsat. Samozřejmě budou vypsány jen ty podstromy, které také splní i další filtrovací podmínky. Jako hierarchie vnoření tohoto uzlu, namespace a parametry atributů. <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users/> </top> </filter> V tomto příkladě jsou vybrány všichni useři, kteří jsou v definovaném namespace, a jejich rodič je uzel <top>. <users> je výběrovým uzlem, <top> je obalujícím uzlem a zároveň je na něj aplikován výběr namespacem. Výběr shodou hodnoty elementu potomka List který má obsah (= jednoduchý text (kdyby byl obsahem jiný element nejde o list, ale o uzel)) je v podstromu <filter> považován za parametr výběru shodou hodnoty elementu. Ovlivňuje svého rodiče. Jde o jakési zpřesnění výběrového uzlu. Konkrétně to znamená, že budou vybrány z podstromu výběrového uzlu jen ti ze všech sourozenců (elementy stejného typu se stejným rodičem), které mají ve svém těle list s definovanou hodnotu. Vícenásobné uvedení různých listů ve stromu <filter> je interpretováno jako dvě podmínky na rodičovský uzel(logicky AND). Bílé znaky na začátku a na konci obsahu listu jsou odmazány. Pokud jsou obsahem listu pouze bílé znaky, je interpretován jako výběrový uzel a nikoli jako výběr shodou hodnoty elementů. Shrnutí Pokusím-li se celé filtrování shrnout. Filtr se vytváří tak, že zvolíme kořen stromu, tento bude výběrovým uzlem. Kořen volíme o jednu úroveň výše v hierarchii XML dokumentu, než prvky, které chceme skutečně vypsat. Pomocí výběru shody hodnoty elementu potomka nadefinujeme vlastnosti jednotlivých elementů o které se zajímáme. Výběrový uzel, reprezentující vrchol vypisovaného stromu obalíme do obalujících uzlů tak, aby odpovídaly hierarchii výběrového uzlu v celém dokumentu XML. A obalující uzel, který je kořenem filtru obohatíme o výběr namespacem. Výběr shodou hodnoty atributů provádíme jen v případě, že nás zajímá jen konkrétní větev v hierarchii XML dokumentu. Na paměti mějme, že tento způsob konstrukce filtru nedokáže vytvářet nesouvislé lesy z XML dokumentu konfigurace. Proto máme možnost do filtru nadefinovat hned několik výběrových stromů. Takto můžeme dospět k uspokojivé flexibilitě filtrování. Na závěr bych rád dodal, že však existují i takové požadavky na filtrování, které tímto základním modelem filtrování nelze uspokojit a to i přestože v XML existují prostředky pro tvorbu takovýchto podstromů. Proto byl NetConf obohacen i o filtrování jiné a to filtrování na základě Xpath. Jde však o volitelnou část implementace a není obsažena v základních schopnostech (:base:1.0). Aby zařízení podporovalo filtrování pomocí Xpath, musí se dohodnout na schopnosti (:Xpath). Pokud je mi známo, žádný prvek Cisco však tuto schopnost nepodporuje. listopad 2009 10/26
3 Implementace NetConfu V této části dokumentu rozebereme implementace NetConfu, na které jsme narazili. 3.1 Cisco ED-I Cisco Enhanced Device Interface v2.2. Naše první kroky vedly kromě samotného standardu NetConf a webové prezentace IETF právě na stránky společnosti Cisco, která nabízí podporu protokolu NetConf na drtivé většině svých zařízení. Zde je to pochopitelné, protože Cisco své zařízení vybavuje robustním operačními systémy IOS,CatOS... Ve většině těchto systémů je od verzí kolem 12.2 zabudován také NetConf. Přesnou tabulku pak naleznete na [2]. Pro širší implementaci a bohatější podporu schopností však doporučujeme sáhnout na nejnovější dostupné verze. Cisco ED-I není zdaleka jen pouhý NetConf. Jde o balík umožnující seskupovat různé typy zařízení do skupin. V jednotlivých skupinách mohou být zařízení, které se více, či méně liší a podle toho mohou být také hromadně konfigurovány. Co se hromadné správy týče, kromě konfigurace pomocí RPC operací definovaných v NetConf, nabízí Cisco ED-I také varianty některých těchto operací ekvivalentní příkazy CLI. Aby bylo možné vystavět balík s tak impozantními schopnostmi, rozhodlo se Cisco při implementaci ED-I celou záležitost malinko zkomplikovat. Původně zamýšlená architektura NetConfu klient-server, byla přepracována na klient-agent-server. A to protože podle standardu NetConf se propojení klient-klient, a server-server automaticky rozpojí. Balík ED-I se z pohledu na NetConf skládá ze tří částí. Fyzického zařízení vybaveného OS IOS či CatOS, které podporuje NetConf, softwarového agenta ED-I a klienta pro správu konfiguraci na ED-I prostřednictvím XML-PI. (XML-PI je API k Cisco implementaci NetConfu, popsáno v [4], kapitola 7.) Myšlenka je následující. Komunikace server-klient (kde server je fyzické zařízení a klient je uživatel za nějakým GUI, nebo příkazovou řádkou) neumožňuje hromadnou správu několika prvku najednou. A navíc celý protokol NetConf je zbytečně robustní, aby běžel na routerech či směrovačích. Proto se rozhodli se programátoři od Cisca do cesty postavit ještě jednu komponentu zmiňovaného agenta, ED-I server. Uživatel se pak pomocí hezkého uživatelsky příjemného grafického klienta pro ED-I (pracující přes XML-PI, takže ho nelze nahradit obyčejným NetConf klientem třetí strany) napojí na ED-I server, který mu sdělí, jaké zařízení jsou k ED-I serveru připojeny, jaké mají schopnosti a umožní mu je všemožně seskupovat do skupin a podskupin. Podle šířky spektra zařízení v jednotlivých skupinách jsou pak omezovány možnosti konfigurace tak, aby je server ED-I byl schopen automaticky transformovat na všechny členy skupiny. Uživatel tak může pomocí standardu NetConf nakonfigurovat nejen jeden stroj, ED-I server si totiž zajistí pomocí XSL transformací překopání konfigurace tak, aby je mohl přeposlat na více konfigurovaných fyzických zařízení bez ohledu na to, že na nich běží různé verze IOS. Nebo se malinko liší třeba pojmenováním portů. Při konfigurování více zařízení najednou totiž máte k dispozici jen nejužší soubor příkazů, které zvládají všechna zařízení (které chcete konfigurovat paralelně). Tyto vlastnosti jednotlivá zařízení nezávisle na sobě serveru ED-I nabídnula. Přes ED-I server lze konfigurovat i pomocí příkazové řádky, kde se vnitřně příkazy transformují na NetConf. Samozřejmě lze konfigurovat zařízení i 1:1 (nebo skupinu zařízení stejného typu), to pak máte k dispozici všechny příkazy daného zařízení. Kromě grafického klienta pro tvorbu příkazů základní konfigurace 1:1 (přístup k ED-I přes XML-PI) se k Cisco ED-I přidává hromada jiných klientských aplikací pro různé oblasti správy a konfigurace Cisco zařízení. Zajímavý je například Configuration Manager, který který umožňuje seskupování do skupin a transformace příkazů. Command Analyzátor, kde můžete porovnávat účinky různých konfiguračních skriptů. V závislosti na poslední známé konfigurace zařízení, nebo konfigurace, kterou mu dodáte, dokáže spolu s vašim skriptem sestavit výslednou konfiguraci, která vznikne. Je tak možné odhalit chyby v konfiguračním skriptu jak syntaktické tak i např. nevhodné merge, nebo chyby, které mohou nastat při vykonávání skriptu, protože kvůli aktuální konfiguraci mohou být skriptem konfigurované části zamčeny atp. V balíku ED-I jsou také nástroje pro tvorbu maker z předpřipravených příkazů. Cisco ED-I by si svým rozsahem zasluhovalo samostatný projekt. Díky této architektuře může být centralizovanost správy celé sítě o mnoho jednodušší. Avšak samotní grafičtí klienti, většinou postaveni na platformě Eclipse, bývají velmi odlehčení a bez ED-I serveru nepoužitelní. Po prostudování dokumentace jsem se na nasazení Cisco ED-I těšil, nabízené možnosti vypadaly lákavě. Brzy se však začaly objevovat problémy... listopad 2009 11/26
Na webu společnosti Cisco nabízejí softwarové distribuce pro Windows i Linux, ke stažení jen samostatnou dokumentaci a nebo jen klientské aplikace (Můžete následovat zdroj [5]). Zjistíte, že jediná věc, která je volně ke stažení je linuxová distribuce. Volně přes [6] a možná, pokud máte možnost přístupu ke komerčním produktům společnosti Cisco, tak ji naleznete na [7]. Nutno podotknout, že linuxová distribuce neobsahuje grafického klienta pro konfiguraci NetConfem přes ED-I (přístup k ED-I přes XML PI). Takto se dostáváme do problémů, protože tato část je pro vyzkoušení funkcionalit protokolu NetConf velmi žádoucí a hlavně nenahraditelná produktem třetí strany. Co však vyzkoušet můžeme, je spojení Cisco ED-I s fyzickými prvky a možnosti konfigurace přes CLI. Tyto příkazy by měly být agentem stejně přeloženy do XML dokumentu protože ED-I by mělo komunikovat s jednotlivými prvky sítově infrastruktury podle NetConf. 3.2 Yenca Yenca je vyvíjena v rámci licence GPL GNU a je dostupná ke stažení na sourceforge.net [12]. Architektura Yenca byla rozložena podobně jako u Cisca, na dvě softwarové části (klient Yenca Manager pro vlastní sestavování příkazů (XML editor) a Agenta, který by měl komunikovat se samotným zařízením) a hardwarový prvek podporující standard NetConf. Podle dokumentace [11] nenabízí Yenca žádné sofistikované schopnosti jako hromadnou správu více zařízení, transformace konfiguraci podle XSD šablon apod. Možná s tím vývojáři počítají do budoucna, netuším. V opačném případě mohl být klient a agent jediná aplikace. Samotný klient je totiž ke komunikaci se zařízením bez agenta stejně jako klient od Cisco ED-I nepoužitelný. Ilustrace 2: Architektura Yenca Ilustrace 1: Architektura Yenca 3.3 YencaP Dále se nám podařilo stáhnout platformu YencaP. To P na konci názvu softwarového balíku znamená Python. Celá distribuce je postavena na tomto skriptovacím jazyce, nicméně to je vše co se nám podařilo zjistit. Prakticky žádná dokumentace :-( A bohužel ani funkčnost. 3.4 Netopeer Stejně jako u předchozích projektů je i Netopeer složen ze dvou základních částí. Strany klienta - Netopeer (GUI aplikace) a strany serveru - nc_agent (dále jen agent). Protože klient Netopeer komunikuje s agentem dle specifikace standardu NetConf, je teoreticky jedno (do doby, dokud implementace odpovídá standardu NetConf), jaký agent je na straně serveru. listopad 2009 12/26
Ilustrace 3: Architektura Netopeer Agent podle standardu předpokládá, že data se kterými pracuje, jsou v XML podobě, což pravděpodobně ne vždy, lze z výkonnostních nebo historických důvodů dodržet. Pokud se jedná o konfigurace softwarových serverů, není tato podmínka nijak zvlášť omezující. V případě převážně hardwarových záležitostí (routery), si tato struktura bohužel vyžádá další mezistupeň, který bude vytvářet tyto XML soubory, se kterým bude agent pracovat. Cestu k XML souborům je pak třeba nastavit v konfiguračním souboru. Na rozdíl od předchozích implementací, je Netopeer hodně jednodušší softwarové dílo. Činnost klienta spočívá v zaobalování požadavků do RPC protokolu, generování hello zpráv a na základě jednoduchých příkazů GUI vytváření jednotlivých požadavků. K některým požadavkům je třeba si dopředu připravit XML soubor s jeho obsahem (daty). Ten pak Netopeer vloží na příslušné místo. Příchozí zprávy jsou vybaleny z RPC protokolu (podle namespace definovaného ve zprávě, se rozhodne jak...) a vypsány. Více o činnosti se lze dozvědět následováním [9]. listopad 2009 13/26
4 Praktické nasazení Praktické nasazení všech stažených softwarových balíků si nevyžaduje nijak komplexní síťovou topologii a proto jsme se rozhodli si nekomplikovat život. A spojili pouze počítač provozující klientské i serverové aplikace napřímo s routerem RJ. Ilustrace 4: Topologie sítě 4.1 Cisco ED-I Pro naše experimenty jsme si zvolili jeden router Cisco 2801 s IOS ve verzi 12.4T. Podle přístupné dokumentace je NetConf implementován na platformě 2800 od IOS verze 12.2. Cisco ED-I server pak byl ve verzi 2.2, Linuxová distribuce. Konfigurace připojení jednotlivých Cisco zařízení k serveru ED-I spočívá v povolení NetConfu u koncových zařízení, vytvoření uživatelských účtů pro účely autentizace transportní protokolu. A nakonfigurování jednoho z nich. Zde Cisco nabízí SSH2 a BEEP. NetConf už bezpečnost neřeší, předpokládá, že připojena bude jen osoba pověřena správou sítě. Pro nás jako základní nástřel pro konfiguraci sloužil návod pro SSH2 (pro naši verzi IOS jej naleznete následováním [8]). Jméno klíčů jsme pojmenovali přímo ip adresou rozhraní, přes které se budeme připojovat. Pro ssh2 je nutné mít modulo nastaveno minimálně na 768. Pozor, Cisco prvky mají občas tendenci sklouzávat ke komunikaci v ssh1.99, které není definováno žádným standardem. Proto jsme pripojili příkaz ip ssh version 2, který si vynutí použití ssh verzi 2. Enable conf t hostname RJ crypto key generate rsa usage-keys label 10.0.0.1 modulous 768 ip ssh rsa keypair-name 10.0.0.1 ip ssh version 2 Nyní vytvoříme uživatele, který bude mít práva spravovat RJ. Aaa new-model username admin password admin Ještě nám zbývá nakonfigurovat vlastní připojené rozhraní interface fastethernet 0/0 ip address 10.0.0.1 255.255.255.0 no shut exit listopad 2009 14/26
A finálně spustíme instanci NetConfu, k tomu ale musíme access-listem nadefinovat, odkud se může na NetConf správce s využitím SSH připojit. Takže pro naše laboratorní podmínky bude postačovat access-list typu pusť vše. Lock-time nastavuje max. časovou platnost zámků. Pokud je zámek stále třeba, je znovu vytvořen. Parametr je čas ve vteřinách. Access-list 10 permit any netconf ssh acl 10 netconf lock-time 60 netconf max_sessions 5 Tímto je konfigurace routeru hotová. Je čas rozjet ED-I server. Po nainstalování do implicitního adresáře se v /opt/ciscosystems/cisco-edi/bin nachází skript start.sh. Po jeho zavolání by měl server naběhnout. Při prvním spuštění je předpřipraven uživatelský účet admin s heslem admin. Pro konfiguraci spustíme telnet a připojíme se na port 2323, kde server poslouchá a očekává uživatele, kteří chtějí konfigurovat server pomocí příkazové řádky (dále jen CLI). K ED-I serveru je pak potřeba jednotlivá síťová zařízení připojit ke skupině spravovaných prvků (managed devices), o které se tento ED-I server stará a to buďto ručně (naklepáním ip adres peerů), nebo na základě CDP (příkaz discover). Pouze k těmto prvkům se pak dostaneme pomoci GUI aplikace klienta (kdyby byl součástí linuxové distribuce, pochopitelně). Připojeny budou (ať už ručně, nebo automaticky přes CDP) jen zařízení, kterým běží aktivní instance NetConfu a které jsou připraveny přijmout SSH2 nebo BEEP s našim uživatelským jménem a heslem. Pokud neběží na prvcích instance NetConfu, nebo se nepodaří navázat spojení SSH, je zařízení přidáno jen na list objevených zařízení (discovered devices), ale nejsou spravovatelná. V manuálech k Cisco ED-I [3] a [4] byla uvedena i možnost spolupráce s SNMP, pro tvorbu seznamu spravovaných zařízení. Zatím jsme nevyzkoušeli. CLI cisco ED-I vypadá velmi podobně jako u IOS. Tabulátor doplňuje příkazy, otazník nabízí možné příkazy v dané podkategorii. Fungují šipky i backspace, avšak nelze mazat pomocí delete. Navíc je prompt obohacen o výraz v hranatých závorkách, kde je uveden aktuální kontext zařízení, s kterým pracujeme. Na kompletní přehled o možnostech ED-I CLI se můžete podívat do [3]. První pokus bylo využít CDP protokolu k objevení našeho routeru RJ a přidat ho mezi spravované zařízení. [SVR:/server]# conf t [SVR:/server](config)#discovery [SVR:/server](config-dis)#hopcount 3 (parametr 1 10) poté... [SVR:/server]#import devices from-discovered-list [SVR:/server]#sh devices Bohužel jsme nenašli nic... Takže budeme muset přitlačit na pilu a říct CDP, které zařízení přímo hledat. [SVR:/server]#discover cdp 10.0.0.1 Bez úspěchu, a to jsme ještě explicitně zapnuli CDP protokol na RJ, a zkoušeli i advertise_v2 pro CDP. Rozhodli jsme se tedy zařízení připojit ručně. Potřebujeme jen přepnout server do módu autentizace a autorizace session-based (v implicitním stavu se pokouší cisco ED-I připojovat jménem a heslem aktuálního uživatele, přes SSH2, v session-based se autorizační údaje a způsob připojení konfigurují pro každé zařízení). Protože tento mód nám umožňuje ručně přidávat zařízení. Prakticky však můžete použít jeden set s autorizačními údaji pro více routerů (ovšem jen jsou-li stejně nastaveny hesla a transportní protokol na jejich straně). Je tedy potřeba vytvořit credential-set aby se při pokusu o spojení s zařízením používal správný transportní protokol (SSH2), posílaly správné přihlašovací data (admin/admin) a pak přidat router RJ mezi spravované zařízení. listopad 2009 15/26
[SVR:/server]#conf t [SVR:/server](config)#device-auth session-based [SVR:/server](config)#credential-set rj_admin [SVR:/server](conf-credential-set)#transport ssh2!zde by mohly být další příkazy pro změnu použitého šifrovaní, atd... [SVR:/server](conf-credential-set)#login 0 admin [SVR:/server](conf-credential-set)#password 0 admin [SVR:/server](conf-credential-set)#exit [SVR:/server](config)#manage device 10.0.0.1 rj_admin Nyní by už měl být RJ mezi nalezenými zařízeními. Takže se podíváme. admin@cnap-desktop[srv:/]# show devices Number of devices in network-restricted: 1 * Devices marked with * are not supported by E-DI (No matching Device Package could be found). Device Name Type Status - --------------- -------------------- -------------------- -------- * 10.0.0.1 10.0.0.1 Unknown offline Manuální záznam přibyl, nicméně zařízení se vůbec ke spolupráci s ED-I nemá...?? Ani korektně neproběhne rozpoznání typu zařízení... údajně je vypnuto. Celkově nasazení ED-I hodnotím jako krach. Nejen, že nebyl v distribuci dodán klient pro tvorbu příkazů ve formátu XML, ale server ED-I není schopen detekovat jiné (údajně podporované) zařízení na úrovni CDP. Jako kdyby mezi nimi nebyl drát... Ping prošel oboustranně. Pokus o navázání SSH relace ze stanice, kde provozujeme ED-I byl úspěšný. Jiný router se s RJ na úrovni CDP našel bez problémů. Proto považujeme za selhávající článek buďto naši neschopnost, správně nakonfigurovat server ED-I, nebo jde o chybu implementace na straně Cisco ED-I serveru. Každopádně jsme při konfigurování obou prvků postupovali dle návodu dodávaných společností Cisco přímo k naší distribucím. [3] pro ED-I a [8] pro router RJ. 4.2 Yenca Zkompilování klienta proběhlo podle dokumentace, problém nastal při kompilování agenta. Podle dokumentace potřebujete dvě knihovny, libxml2 a libdl (verze podle [11]). Ale musím se přiznat, že pouze s nimi se mi Yencu zkompilovat nepodařilo. Celé jedno odpoledne mě bavilo sledovat chyby kompiléru, googlovat a stahovat knihovny, které chyběly. Když jsem dospěl k prvnímu přeloženému výsledku, nešel ani spustit. Tímto jsem s Yencou skončil. 4.3 Netopeer Instalace si vyžádala několik dodatečných knihoven, především OpenSSH, d-bus a xml2. Kompletní seznam je v přiložen v README, které je součástí distribuce. Program obsahuje i simulační server, s jehož pomocí lze testovat NetConf a jeho požadavky, pokud známe XML schémata simulovaného zařízení, přímo na PC. Protože jsme neměli k dispozici šablony Cisca, použili jsme pro úvodní test už přednastavené šablony. Po spuštění a připojení k PC si klient a server úspěšně vyměnili hello zprávy. Stejně tak příkaz get-config a editconfig fungovaly bez problémů. Samotný program obsahuje nápovědu k jednotlivým příkazům. Možné řešení některých problémů s konfigurací jednotlivých částí netopeera pak můžete najít na [13]. listopad 2009 16/26
Spuštění serveru (jako su) a spuštění netopeera:./netopeer-daemon.fake system org.liberouter.netopeer./netopeer windman@localhost Výměna hello: <?xml version="1.0"?> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability> <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability> <capability>urn:ietf:params:netconf:capability:startup:1.0</capability> <capability>urn:liberouter:params:netconf:capability:power-control:1.0</capability> </capabilities> </hello> <?xml version="1.0"?> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability> <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability> <capability>urn:ietf:params:netconf:capability:startup:1.0</capability> <capability>urn:liberouter:params:netconf:capability:power-control:1.0</capability> </capabilities> <session-id>5603</session-id> </hello> Získání konfigurace (get-config): <?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <get-config><startup/><get/config> </rpc> Odpověď: <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <data> <flowmon-config xmlns="http://www.liberouter.org/ns/netopeer/flowmon/1.0"> <probe> <active-timeout>30</active-timeout> <inactive-timeout>10</inactive-timeout> <sampling> <sampling-rate>1</sampling-rate> <sample-and-hold-rate>1</sample-and-hold-rate> </sampling> </probe> <collectors/> </flowmon-config> </data> </rpc-reply> listopad 2009 17/26
Změna konfigurace: <?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3"> <edit-config> <target><startup/></target> <config> <flowmon-config> <probe> <active-timeout>20</active-timeout> <inactive-timeout>10</inactive-timeout> <sampling> <sampling-rate>5</sampling-rate> <sample-and-hold-rate>1</sample-and-hold-rate> </sampling> </probe> <collectors/> </flowmon-config> </config> </edit-config> </rpc> Ze serveru pak příjde jen velmi strohá odpověď: <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3"> <ok/> </rpc-reply> Ale to je dobře, znamená, že úprava konfigurace proběhla bez obtíží. Čas uzavřít spojení s fiktivním serverem a pustit se na skutečný router Cisco. Ukončení spojení: <?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> </rpc> <close-session/> Odpověď: <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <ok/> </rpc-reply> listopad 2009 18/26
Připojení k Ciscu se ukázalo jako poněkud problematičtější. Nebyl totiž povolen port 830, který je definován ve standartu NetConf kvůli firewallům. Tento problém se dal obejít přesměrováním Netopeera na jiný port (použili jsme port 22). Konfigurace na straně routeru RJ - podle dokuemntace [8]. Stejná jako pro ostatní implementace NetConfu:!parametry pro shh RJ(config)# aaa new-model RJ(config)# username windman password 0 DesireDeLeene RJ(config)# ip ssh rsa keypair-name 10.0.0.1 RJ(config)# crypto key generate rsa usage-keys label 10.0.0.1 modulus 768 RJ(config)# ip ssh timeout 120 RJ(config)# ip ssh version 2!rozhraní RJ(config)# interface FastEthernet0/0 RJ(config-if)# ip address 10.0.0.1 255.255.255.0 RJ(config-if)# no shutdown RJ(config-if)# exit!netconf RJ(config)# access-list 10 permit any RJ(config)# netconf max-sessions 5 RJ(config)# netconf lock-time 60 RJ(config)# netconf ssh acl 10 Připojení k cisco 2801 na adrese 10.0.0.1 na port 830:./netopeer windman@10.0.0.1 Problém, spojení zamítnuto ze strany routeru, na portu nikdo neposlouchá, nebo není povolen. Chvilku jsme otazníkovali možné příkazy za SSH, a jediný nalezený příkaz (ssh port <2000-9999) nás bohužel neuspokojil, takže jsme museli zkusit přesvědčit Netopeera../netopeer windman@10.0.0.1 -p 22 Nyní se nám sice povedlo připojit, ale netopeer vyhodnotil hello zprávu od Cisca jako neodpovídající a spojení okamžitě přerušil. Příchozí zpráva na první pohled vypadala jako platná, ale při bližším zkoumání jsme zjistili, že zpráva neobsahuje namespace. Odeslané hello (generováno Netopeerem): <?xml version="1.0"?> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability> <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability> <capability>urn:ietf:params:netconf:capability:startup:1.0</capability> <capability>urn:liberouter:params:netconf:capability:power-control:1.0</capability> </capabilities> </hello> Přijaté hello (generováno C2801): <?xml version="1.0" encoding="utf-8"?> <hello> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> <capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability> <capability>urn:ietf:params:netconf:capability:startup:1.0</capability> <capability>urn:ietf:params:netconf:capability:url:1.0</capability> <capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability> listopad 2009 19/26
<capability>urn:cisco:params:netconf:capability:notification:1.0</capability> </capabilities> <session-id>1745631364</session-id> </hello> Jediná cesta, jak tohoto clienta zprovoznit pro Cisco platformu, je pravděpodobně přeprogramování některých kontrolních podmínek v klientovi. Takže nám nezbylo, než Netopeera opustit a vrhnout se na... 4.4 Zoufalé pokusy V obou případech našich praktických hrátek selhali klientské aplikace. U Cisca pro jistotu nebyla klientská aplikace zahrnuta vůbec. A protože Netopeer se drží na poměry Cisco zařízení standardů IETF až moc (kdy zamítnul vzájemnou komunikaci s routerem na základě chybějícího namespace), rozhodli jsme se zkusit posílat ručně psané příkazy NetConfu přímo přes SSH2. Klientů pro SSH2 je hromada. Ovšem jak chcete konfigurovat zařízení pomocí příkazů vyžadujících znalost struktury dat, pokud ji neznáte? Popis XSD implementovaných v zařízeních Cisco se nám nepodařilo najít. Přišel tedy na řadu selský rozum. Připojil jsme se k RJ. ssh -2 -p 22 admin@10.0.0.1 -s netconf A počkali na zprávu hello, která přijde od RJ. S domněnkou, že stačí zprávu tupě zkopírovat a tak si zajistit podporu stejných schopností. Tak jsme tedy učinili a nestačili se divit. Konzola routeru RJ se zasypala výpisy chyb a výjimek a dříve než jsem stihl výpis zkopírovat do clipboardu, už se rebootovalo. Zdá se, že jsme nalezli nový, výkonný DOS útok ;-) Samozřejmě, že nyní už víme, kde byla chyba. Hello z naší strany nemělo obsahovat také session-id, protože v tomto případě je povinnost ukončit spojení. Ovšem otočit router? To jsme nečekali. Protože jsme neměli uloženou konfiguraci jako start-up, tak jsme si konfiguraci RJ zopakovali. Zpráva hello, už s odstraněným session-id. (tedy, zpráva od klienta pro server) <?xml version="1.0" encoding=\"utf-8\"?> <hello> <capabilities> </capabilities> </hello> ]]>]]> <capability>u?rn:ietf:params:netconf:base:1.0</capability> <capability> urn:ietf:params:netconf:capability:writeable:running:1.0 </capability> <capability> urn:ietf:params:netconf:capability:roll-back-on-error:1.0 </capability> <capability> urn:ietf:params:netconf:capability:startup:1.0 </capability> <capability> urn:ietf:params:netconf:capability:url:1.0 </capability> <capability> urn:cisco:params:netconf:capability:pi-data-model:1.0 </capability> listopad 2009 20/26