hledat:

4   Programovatelný hardware

Aktivita Programovatelný hardware se zabývá vývojem prototypů specializovaných síťových zařízení, která využívají programovatelná hradlová pole (FPGA, Field-Programmable Gate Array). Ve druhé polovině roku 2007, po úspěšném ukončení dlouhého a komplikovaného procesu předání výsledků výzkumu do praxe, stáli řešitelé aktivity před úkolem vytipovat nové perspektivní směry výzkumu a vývoje a vybrat z nich vhodný a ne příliš rozsáhlý soubor témat, jimž se může řešitelský tým v současném složení efektivně věnovat.

Přirozeným požadavkem bylo zaměřit se na zpracování provozu z linek o přenosových rychlostech vyšších než 10 Gb/s. Karty původní rodiny COMBO ale již pro tento účel nebylo možné použít, a proto jsme ještě v roce 2007 navrhli architekturu nové rodiny karet COMBOv2. Zohlednili jsme samozřejmě několikaleté zkušenosti s výrobou a provozem karet COMBO, které nás vedly především směrem k jednoduššímu návrhu a minimalizaci počtu součástek. I přes některé nevýhody jsme nakonec zůstali u modelu dvou vzájemně propojených karet - mateřské karty a karty rozhraní. Toto uspořádaní je totiž podstatně pružnější a pro účely vývoje prototypů vhodnější.

V roce 2008 byly vyrobeny a oživeny první karty rodiny COMBOv2, především tedy mateřská karta COMBO-LXT a dále dvě karty rozhraní COMBOI-1G4 (4×1 Gb/s) a COMBOI-10G2 (2×10 Gb/s). V roce 2009 k nim ještě přibude čtyřportová desetigigabitová karta COMBOI-10G4, hlavně ale budeme pracovat na návrhu a vývoji špičkové karty rozhraní pro rychlosti 40 Gb/s nebo vyšší. Další informace o kartách rodiny COMBOv2 obsahuje část.

Klíčovým strategickým rozhodnutím předchozích let byla zásadní restrukturace firmwaru, spočívající ve vytvoření nové firmwarové platformy zvané NetCOPE. Jejím hlavním cílem je vytvořit vhodnou úroveň abstrakce pro aplikace, odstínit je od konkrétního hardwaru a tím výrazně urychlit jejich vývoj. Důležitým výsledkem roku 2008 je úspěšné portování firmwaru NetCOPE na karty COMBOv2. Architekturu NetCOPE a aktuální stav této firmwarové platformy popisuje část.

Hlavní hardwarově akcelerovanou aplikací aktivity zůstává sonda FlowMon. Jejím úkolem je agregovat síťový provoz do podoby tzv. IP datových toků (IP data flows), které se pro řadu účelů ukazují jako nejvhodnější úroveň rozlišení. V současné době se vývoj zaměřuje na zcela nový firmwarový design, který nazýváme Flexible FlowMon. Ten má v co nejširší míře využít možností nových protokolů pro export dat o tocích (NetFlow verze 9 a IPFIX) a především je dát do rukou uživatelů, kteří budou mít možnost konfigurovat měřicí proces i v hardwaru, například nastavit, která hlavičková pole se budou sledovat a exportovat nebo provádět přímo v hardwaru některé jednoduché operace. Popis sondy Flexible FlowMon najdete v části.

Staronovou aplikací je NIFIC, což je v obecné poloze hardwarově akcelerovaná klasifikace paketů na základě uspořádané množiny pravidel. S řešením tohoto problému jsme se potýkali vlastně od samých začátků této aktivity - nejprve v souvislosti s vývojem směrovače IPv4/IPv6 - teprve nyní se však zřejmě podařilo nalézt uspokojivé řešení, které je nejen dostatečně rychlé, ale umožňuje pracovat i s relativně velkými soubory pravidel. Popisu této aplikace se dále věnuje část.

Dokončili jsme také vývoj základních funkcí aplikace Netopeer, která slouží ke vzdálené konfiguraci síťových zařízení. Tato aplikace je implementací protokolu NETCONF [RFC4741] a používá transport přes SSH. Tento systém je využit ke konfiguraci obou našich hlavních aplikací - sondy FlowMon a paketového filtru NIFIC. Aplikace Netopeer je popsána v části.

Navázali jsme spolupráci s High-Performance Networking Group na Stanfordově univerzitě, především v rámci projektu NetFPGA. V září se v Brně konal úspěšný tutorial NetFPGA Europe. Jednáme také o využití karet COMBOv2 pro desetigigabitovou verzi NetFPGA.

Snažíme se podporovat praktické využití sondy FlowMon vlastním výzkumem v oblasti anotace datových toků a detekce anomálií. Na těchto otázkách spolupracujeme jak v rámci projektu GÉANT2, tak i bilaterálně s univerzitou v Cambridge (UK).

Značný zájem o systémy pro bezpečnostní monitoring vysokorychlostních sítí projevuje armáda. V dubnu jsme naše výsledky prezentovali na zasedání panelu NATO IST v Praze a na základě této prezentace jsme pak získali možnost vystoupit na sympoziu NATO Information Assurance for Emerging and Future Military Systems ve Slovinsku.

Jako velmi prospěšné se ukázalo navázání těsnější spolupráce s firmou Xilinx, výrobcem námi používaných hradlových polí. Tato spolupráce nám usnadňuje přístup k novým čipům a informacím. Firma Xilinx se v poslední době soustřeďuje na oblast datových sítí a má proto zájem i o naše výsledky. V únoru 2008 jsme prezentovali naši novou platformu COMBOv2 na Xilinx Academic Forum v USA a vystavovali naše karty na stánku Xilinx během konference FPGA 2008. Prostřednictvím firmy Xilinx jsme také získali kontakty na stanfordskou skupinu HPNG.

4.1   Řešitelský tým

Na výsledcích aktivity Programovatelný hardware se podílí zhruba šedesátičlenný řešitelský tým. Jeho velikost i struktura se v posledních letech prakticky nemění, snažíme se pouze nahrazovat přirozené úbytky.

Velmi se osvědčuje rozdělení týmu do projektových skupin, v nichž jsou zastoupeni jak vývojáři firmwaru a softwaru, tak i verifikátoři a testeři. Na konci roku 2008 jsou aktivní tyto tři projektové skupiny:

1. NetCOPE - vedoucím je Viktor Puš (CESNET),
2. FlowMon - vedoucím je Lukáš Soĺanka (VUT Brno),
3. NIFIC - vedoucím je Tomáš Dedek (CESNET).

Po letitých problémech se nám podařilo stabilizovat a efektivně zapojit skupinu testerů, kteří jsou přiřazeni k jednotlivým projektům a jejich úkolem je příprava a realizace výkonnostních i funkčních testů vyvíjených zařízení. Tato skupina pod vedením Jana Vykopala (MU Brno) má nyní deset členů, vesměs bakalářských studentů Masarykovy univerzity. Velký důraz je kladen na jejich vzdělávaní, které zahrnuje jak obecné metodiky a standardy testování, tak i základní pravidla a know-how vývoje hardwaru a softwaru v naší aktivitě. Vzhledem k rozšiřující se rodině karet COMBO a novým prototypům skupina připravila nákup nových hardwarových testovacích zařízení (nejprve Spirent TestCenter 2000 a pak také Agilent N2X), které pak v průběhu roku nasadila k testování prototypů.

Významnou součástí činnosti aktivity je systematická práce se studenty, kteří dnes tvoří v řešitelském týmu většinu. Zejména v oblasti vývoje firmwaru se ukázalo nezbytným podchycení nadějných studentů hned v začátcích jejich studia. Sledováním práce projektových skupin a řešením stále složitějších úkolů se tito studenti během jednoho roku připraví na plné zapojení do projektů (část z nich ovšem odpadne). Nejlepší ze studentů se pak stávají i vedoucími projektových skupin.

Pozitivním vedlejším efektem zapojení studentů je i vysoká kvalita jejich bakalářských, diplomových i doktorských prací. Dvě z nich získaly v roce 2008 významná národní i mezinárodní ocenění: Petr Kobierský (VUT Brno) byl oceněn za svou diplomovou práci Hardwarová akcelerace identifikace protokolů první cenou ve dvou celostátních studentských soutěžích IT diplomka roku a Diplomová práce roku, navíc získal ještě mezinárodní ocenění Special Recognition na Junior Scientist Conference ve Vídni. Viktor Puš získal za svou diplomovou práci Klasifikace paketů s využitím FPGA cenu Josefa Hlávky a dále obsadil 2. místo v již zmíněné soutěži Diplomová práce roku a rovněž 2. místo v ACM Student Research Competition.

Novým prvkem v organizaci práce aktivity byl letní "hackfest", při němž byli projektoví vývojáři po dobu dvou týdnů soustředěni na jednom místě a intenzivně pracovali na prioritních úkolech. Výsledky tohoto pokusu předčily původní očekávání, kromě zjevného pokroku vývojových prací měl i velmi dobrý vliv na zlepšení komunikace v projektových skupinách. Předpokládáme proto, že takové akce zopakujeme i v příštích letech.

4.2   Rodina karet COMBO

V roce 2007 jsme uzavřeli vývoj karet rodiny COMBO kartou COMBO-2XFP2 s rozhraním 2×10 Gb. V letošním roce jsme se věnovali vývoji nové rodiny karet COMBOv2, která je navržena pro zpracování dat rychlostí 40-100 Gb/s. Nejdůležitějším rysem rodiny COMBOv2 je nový systém konektorů, optimalizovaný pro přenos dat velmi vysokými rychlostmi.

Základní karta nové generace - COMBO-LXT (obrázek) - obsahuje dva vysokorychlostní konektory s propustností 30 Gb/s v obou směrech při použití obvodů LXT a 50 Gb/s při použití obvodů FXT. Tyto konektory jsou určeny pro připojení karet rozhraní. Dále je karta vybavena čtyřmi konektory LSC pro připojení "pomalých" periferií s rychlostí do 10 Gb/s. COMBO-LXT je osazeno obvodem FPGA VIRTEX5 XC5V110LXT, dvěma rychlými pamětmi QDRAM a konektorem pro dynamickou paměť SODIMM. Připojení do hostitelského počítače je realizováno rozhraním PCI Express ×8 s teoretickou propustností 16 Gb/s. Vzhledem k připojení FPGA obvodu na sběrnici PCI Express jsme navrhli unikátní způsob nahrávání firmware bez nutnosti resetu počítače, který je nezbytný u stávajících karet s přímým připojením na sběrnici.

Pro rodinu karet COMBOv2 jsme vyvinuli karty rozhraní COMBOI-1G4 (obrázek) s rozhraními 4×1 Gb/s a COMBOI-10G2 (obrázek) s rozhraními 2×10 Gb/s. Dále je ve stádiu návrhu testovací karta COMBO-TEST určená pro rychlý test všech konektorů na základní kartě.

V současné době jsou karty COMBO-LXT, COMBOI-1G4 a COMBOI-10G2 oživeny a probíhají úpravy softwarových ovladačů a obslužných programů. Zároveň pracujeme na přenosu platformy NetCOPE a aplikací NIFIC a NetFlow na tyto karty. Úspěšným oživením karet rodiny COMBOv2 jsme zahájili přechod na novou generaci určenou pro zpracování náročných algoritmů v síťovém prostředí při vysokých rychlostech. Karta COMBO-LXT byla vystavena spolu s výukovou kartou NetFPGA Stanfordské univerzity na stánku firmy Xilinx na konferenci FPL 2008 v Heidelbergu, kde se setkala s velkým zájmem účastníků.

4.3   Firmwarová vrstva NetCOPE

Základním cílem projektu NetCOPE je vytvoření konfigurovatelné platformy pro usnadnění a urychlení vývoje síťových aplikací akcelerovaných pomocí FPGA čipů. Využíváme k tomu abstraktní vrstvu na FPGA, která odstíní nízkoúrovňové hardwarově závislé vlastnosti dané karty s FPGA čipem a poskytne snadný přístup k jejím zdrojům (síťové rozhraní, připojení k hostitelskému počítači, kontroléry pamětí aj.).

Tato vrstva uživateli umožní koncentrovat se primárně na vývoj vlastní aplikace a ušetřit tak významné množství prostředků, které by jinak bylo nutné věnovat implementaci jednotek pro obsluhu periferií karty. Další výhodou platformy NetCOPE je snadná integrace uživatelské aplikace na různé karty od různých výrobců. Karty se mohou lišit počtem a rychlostí síťových rozhraní, typem systémové sběrnice, ke které je karta připojena, nebo dalšími periferiemi ovládanými z FPGA. Vlastní aplikace se pro různé karty nemusí vůbec měnit, změní se pouze použitá vrstva NetCOPE.

Ke spojení se softwarovou částí síťové aplikace lze použít připravené ovladače a softwarové nástroje pro obsluhu karty. Rozhraní dodržuje definovanou strukturu a síťové aplikace se tak nemusí měnit ani při použití jiných hardwarových karet a jiných aplikačních jader. V hardwarové části platformy NetCOPE je integrován flexibilní propojovací systém na čipu, který umožňuje rychlé DMA přenosy z karty do hostitelského PC. Zadávání transakcí jak mezi jednotlivými komponentami v FPGA, tak mezi jednotkou a softwarovou aplikací je také podstatně snazší.

Výhod platformy NetCOPE mohou využít různé síťově orientované aplikace, například v následujících oblastech:

• síťová karta s hardwarovou filtrací,
• aktivní/pasivní síťový monitoring,
• IPv4/IPv6 směrovač,
• kryptografie,
• zakódování/dekódování videa,
• generování paketů,
• firewall.

4.3.1   Základní struktura platformy NetCOPE

• Hardwarová karta: nejnižší vrstvou aplikace je vlastní karta s integrovaným čipem FPGA, který ovládá další čipy na kartě nebo rozhraní připojená přímo k FPGA.
• Aplikační jádro: tato vrstva je implementována samotným uživatelem platformy a obsahuje akcelerovanou část uživatelské aplikace. Rozhraní mezi jádrem a NetCOPE je dostatečně abstraktní, takže nezávislé na použité technologii a nízkoúrovňových detailech dané hardwarové karty. Příkladem aplikačního jádra může být filtrace vstupních paketů na základě hlaviček paketu, která přepošle vyšším vrstvám jen ty pakety, které jsou pro softwarovou aplikaci důležité.
• Ovladač a rozhraní směrem k softwarovým aplikacím: softwarová část uživatelské aplikace může s akcelerovaným aplikačním jádrem komunikovat prostřednictvím standardních síťových rozhraní v jádru operačního systému, nebo pomocí aplikačně-specifického rozhraní. Nízkoúrovňovou obsluhu karty na základě podnětů od softwarové aplikace má na starost právě tato vrstva.
• Softwarová vrstva: v této vrstvě uživatel implementuje softwarovou část aplikace, která komunikuje s aplikačním jádrem v FPGA. Díky spolupráci softwaru s hardwarem a umístění výpočetně náročných částí aplikace do akcelerované části je možné připravit výrazně výkonnější řešení, než při použití klasických síťových karet a samostatné softwarové aplikace.

4.3.2   Architektura hardware

Mezi hlavní hardwarové bloky, které využívá aplikace NetCOPE, patří síťové rozhraní, blok pro komunikaci s hostitelským PC a softwarové buffery pro snadné odesílání a přijímání dat ze softwaru. Jejich rozmístění vzhledem k jádru platformy je znázorněno na obrázku.

Síťové rozhraní

Komunikace se síťovým rozhraním karty je uskutečněna pomocí síťových bloků, které podporují jak 1G, tak 10G síťové rozhraní. Pakety jsou do aplikace přenášeny pomocí sběrnice protokolem FrameLink, který je modifikací zavedeného protokolu LocalLink firmy Xilinx. Připojená sběrnice má volitelnou propustnost takovou, aby byla schopna přenést všechny pakety při plné propustnosti síťového rozhraní, včetně případných uživatelských metadat připojených k paketu.

Bloky vstupního síťového rozhraní implementují příjem a vysílání paketů z daného síťového rozhraní na úrovni linkové vrstvy podle standardu IEEE 802.3. Každý z bloků je možné samostatně nastavit i za běhu aplikace. Příkladem takového nastavení je vymezení maximální a minimální přípustné délky paketů, zastavení příjmu paketů, nebo změna linkové rychlosti síťového rozhraní. Všechny tyto parametry lze nastavovat za běhu aplikace pomocí softwarových nástrojů dostupných k platformě.

K příchozím paketům lze připojit libovolná uživatelská metadata. Příkladem uživatelských metadat může být číslo síťového rozhraní, ze kterého byl paket přijat, délka paketu nebo přesná časová značka, kdy byl paket přijat.

Komunikace s hostitelským počítačem

Blok komunikace s hostitelským počítačem, připojený na systémovou sběrnici PCI nebo PCI Express, zajišťuje příjem a vysílání datových transakcí mezi aplikačním jádrem a softwarem na hostitelském PC. V bloku je integrován flexibilní propojovací systém pro FPGA (ICS - interconnection system) a softwarové buffery s rychlým spojením do softwaru. Uživateli jsou poskytnuty způsoby komunikace se softwarem s různými vlastnostmi: vysokorychlostní interní sběrnice a pomalejší lokální sběrnice pro spojení volitelného počtu komponent se software a FrameLink rozhraní k softwarovým bufferům. Buffery slouží jako prostředník rychlého a snadno přístupného vysílání a příjmu dat ze software.

Propojovací systém je jedním z nejdůležitějších bloků NetCOPE. Je možné ho chápat jako abstraktní rozhraní pro připojení aplikačního jádra ke sběrnici PCI, PCI-X nebo PCI Express. Uživatel se tak nemusí zabývat technickými rozdíly jednotlivých sběrnic a využít jednotného rozhraní. Propojovací systém podporuje jak datové přenosy mezi komponentami v FPGA a hostitelskou pamětí RAM, tak interně přímo mezi jednotlivými komponentami.

Interní sběrnice: Interní sběrnice má stromovou strukturu, kde kořenem je blok komunikace s hostitelským počítačem a listy jsou připojené komponenty v FPGA. Uzly slouží pouze pro propojení kořene a jednotlivých listů stromu. Komunikace mezi uzly je založena na zasílání paketů, podobně jako tomu je ve velmi rozšířené systémové sběrnici PCI Express. Komunikační protokol podporuje jednoduché i blokové čtecí a zápisové transakce.

Lokální sběrnice: Za účelem ušetření zdrojů na FPGA je možné komponenty, u nichž není vyžadováno vysokorychlostní spojení, připojit k lokální sběrnici. To je výhodné zejména pro konfigurační nebo ladicí rozhraní komponent.

Softwarové buffery

Softwarové buffery poskytují snadno přístupné a rychlé spojení z/do softwaru. Ke kontroléru sběrnice jsou připojeny pomocí rychlé interní sběrnice pro dosažení co nejvyšší propustnosti do softwaru. Skládají se ze dvou částí, RX a TX, z nichž první slouží pro příjem paketů do softwaru a druhá pak pro odesílání paketů ze softwaru do uživatelské aplikace na FPGA.

Buffery jsou s uživatelskou aplikací spojeny rozhraním FrameLink. Odeslání paketu do softwaru je jednoduché - stačí pouze odeslat paket přes rozhraní FrameLink do RX části. Podobně snadné je odeslání paketu ze softwaru do FPGA, jehož výsledkem je vytvoření nového datového paketu na FrameLink rozhraní TX části. Buffery jsou volně nastavitelné, je možné nezávisle na sobě nastavit počet RX a TX částí nebo velikost jejich interních pamětí.

Rozhraní aplikačního jádra

Rozhraní platformy NetCOPE k uživatelskému jádru je dostatečně abstraktní, aby bylo použitelné pro široké spektrum hardwarových karet a aplikací. Pro přenos dat je využito protokolu FrameLink. Jeho propustnost (objem přenesených dat za jednotku času) lze navíc snadno přizpůsobit požadavkům datového spoje.

V rozhraní jsou povinně vyvedeny následující signály (další zavedené signály se mohou lišit v závislosti na hardwarové kartě):

• N×FrameLink rozhraní pro vstupní síťové buffery, kde N je počet síťových rozhraní karty.
• N×rozhraní pro uživatelské generování metadat k příchozím paketům (např. přesné časové značky).
• N×FrameLink rozhraní pro výstupní síťové buffery.
• FrameLink rozhraní k softwarovým bufferům, přičemž lze zvolit počet RX a TX částí, tedy i počet FrameLink rozhraní.
• Přípojný uzel lokální sběrnice.
• Přípojný uzel interní sběrnice.

4.3.3   Řízení DMA přenosů

Síťová aplikace je složena nejen z akceleračního jádra umístěného v hardware, ale také z části pracující na úrovni programového vybavení. Komunikační kanál, realizující efektivní přenosy dat mezi oběma vrstvami, je pak jednou z klíčových součástí platformy. Pro síťové aplikace je charakteristický přenos dat ve formě paketů. Akcelerační jádro shromažďuje pakety pro softwarovou aplikaci v softwarových bufferech. Na druhé straně, aplikace pakety zpracovává přímo v paměti RAM. O efektivní přenosy dat mezi interními buffery akcelerační karty a pamětí RAM se stará řadič DMA přenosů, který je součástí akcelerační karty.

Přenášené pakety mohou mít obecně různou velikost. Aby nedocházelo k neefektivnímu využívání paměti RAM, pracuje jádro operačního systému s pakety tak, že je skládá z menších bloků (segmentů) provázaných do lineárního seznamu. Přenosy do RAM pak neprobíhají po paketech, ale po větších blocích, čímž se snižuje režie spojená se zahajováním přenosů. Způsob provázání jednotlivých částí paketu do lineárního seznamu se provádí pomocí datových struktur, které se nazývají deskriptory (viz obrázek).

Architektura DMA řadiče

K dosažení maximální rychlosti aplikace jsou i DMA přenosy mezi kartou a operační pamětí počítače řízeny z FPGA, firmware pro jejich řízení je součástí platformy NetCOPE. Při přenosech z FPGA do RAM se kontroluje stav RX DMA bufferů a je-li v nich dostatek dat, je zahájen přenos. Po skončení přenosu jsou data z bufferu uvolněna, protože už byla předána ke zpracování do software. Při přenosech z RAM do FPGA je princip opačný. Je-li v TX DMA bufferu dostatek místa, je zahájen přenos dat a po jeho skončení je místo v RAM označeno jako volné. Strukturu DMA řadičů znázorňuje obrázek.

DMA řadič je úzce propojen se softwarovými buffery, aby si mohl rychle vyměňovat informace o nově příchozích paketech nebo naopak zadávat požadavky na odeslání paketu z bufferu směrem k aplikačnímu jádru nebo uvolňovat již odeslané pakety. Samotné DMA přenosy řadič inicializuje prostřednictvím komponenty Endpoint, která dokáže vyčíst data z interního prostoru bufferů a odeslat je Interní sběrnicí do paměti RAM. Podobně i opačným směrem je schopna vyslat požadavek o čtení dat z paměti RAM a výsledná data uložit do interního prostoru bufferů.

Reálná implementace DMA řadičů a bufferů dosahuje propustnosti zhruba 1,4 Gb/s při nejkratších paketech pro sběrnici PCI-X. S využitím schopnosti agregace paketů do větších bloků (viz kapitolu) a na rychlejší sběrnici PCI Express lze dosáhnout praktické propustnosti mnohem vyšší.

4.3.4   Softwarové rozhraní

Akcelerační karta nabízí směrem k aplikaci obecné rozhraní pro přenos datových bloků. Komunikace probíhá přímo mezi ovladačem a aplikací bez nutnosti průchodu stackem TCP/IP. Formát uložených dat není omezen jádrem operačního systému a může tak obsahovat např. agregované pakety doplněné o kontrolní informace, časové značky apod. Kromě dat paketů lze přenášet libovolná data, např. NetFlow záznamy, informace extrahované z hlaviček paketů a další. Pro účely monitorovacích aplikací vytvořených nad rozhraním PCAP je zde možnost modifikovat aktuální implementaci knihovny PCAP tak, aby komunikovala přímo s ovladačem, mimo jádro operačního systému. Tento přístup je používán i komerčními firmami jako jsou Endace, Napatech, atd. Hlavní výhodou tohoto modelu je jeho propustnost získaná agregací menších paketů do větších bloků, jež snižuje režii DMA přenosů.

4.3.5   Aplikačně specifické rozhraní

V rámci aplikačně specifického rozhraní nazvaného szedata2 se používá kruhový buffer pro ukládání dat, implementovaný jako zřetězený seznam. Zřetězení se provádí pomocí deskriptorů, jak bylo popsáno výše. Kruhový seznam má dvě důležitá místa:

• Ukazatel na začátek - od tohoto místa se začíná číst.
• Ukazatel na konec - na toto místo se začíná zapisovat.

Oba tyto ukazatele slouží k vytvoření fronty typu FIFO (First In First Out). Při zápisu do bufferu se zvětšuje ukazatel na konec, při čtení se naopak zvyšuje hodnota ukazatele na začátek. Tyto ukazatele určují množství dat uložených v bufferu.

Data v bufferu mohou mít obecně libovolný formát, v současnosti existuje pouze jediné omezení - každý logický blok dat (paket nebo jiná jednotka) musí mít na svém začátku číslo určující jeho velikost. Tak je zajištěno správné rozdělení dat do bloků a jejich správné použití v aplikaci.

4.4   Sonda FlowMon

Sonda FlowMon je dedikované zařízení pro sběr statistických dat o síťovém provozu. Její vývoj jsme zahájili v roce 2004 v rámci aktivity JRA2 (Bezpečnost) evropského projektu GN2. V průběhu tří let jsme architekturu sondy dále rozšiřovali s cílem zvýšit její propustnost a schopnosti a v roce 2007 navrhli novou koncepci architektury na základě znalostí získaných z předchozích let. Nová architektura umožní měřit linky s rychlostí deseti gigabitů a vyšší. V průběhu roku 2008 jsme dokončili implementaci této architektury a proběhly první testy v hardwaru.

Původní návrh sondy z roku 2004 jsme implementovali a úspěšně otestovali v říjnu 2005. Tuto verzi také otestovali naši partneři v projektu GN2. Přestože její propustnost a schopnosti měly jistá omezení, bez problémů překonala běžná softwarová řešení. Za účelem dalších rozšíření jsme původní architekturu přesunuli na výkonnější typ karet COMBO6X + SFPRO. To nám umožnilo měřit plně zatíženou gigabitovou linku. Podrobný popis této verze je možné najít v naší technické zprávě [Čel06]. Díky této sondě jsme získali kvalitní data o síti a mnoho zkušeností s reálným měřením. Využitím karty XFP jsme v roce 2007 získali i první desetigigabitové řešení a po přenesení architektury na kartu XFP2 jsme začátkem roku 2008 vytvořili kompletní a stabilní řešení pro měření desetigigabitových sítí. Následně jsme v roce 2008 věnovali hlavní úsilí dokončení implementace nové architektury a snaze o její uvedení do provozu. Paralelně s prací na nové architektuře probíhalo odstraňování chyb ve stávající monitorovací sondě a vylepšování některých prvků její softwarové části. To se týkalo zejména webového frontendu.

4.4.1   Flexible FlowMon

Stejně jako se vyvíjela sonda, vyvíjela se i oblast monitorování na základě toků. Původní a nejvíce rozšířený protokol NetFlow v5 byl rozšířen o verzi NetFlow v9. NetFlow v5 má fixní strukturu informací (záznam), které monitoruje ke každému síťovému toku (posloupnosti paketů mající stejnou zdrojovou a cílovou IP adresu, zdrojový a cílový port a protokol). Sleduje se především doba trvání toku, přenesený počet bajtů a paketů. NetFlow v9 dává možnost záznam změnit, přidávat nové položky či ubírat staré. Podrobnější popis je možné nalézt v [RFC3954]. Sjednocením všech požadavků na monitorování toků vznikl protokol IPFIX. Dnes nové protokoly získávají na významu a postupně se objevují nástroje pro jejich podporu.

Právě plná podpora nových protokolů byla původní motivací pro návrh nové koncepce sondy nazvané Flexible FlowMon v roce 2007. Dalším studiem oblasti monitorování provozu na základě toků se ukázalo, že Flexible FlowMon může mít daleko širší uplatnění, než jsme původně předpokládali. Rešerší odborných prací zaměřených na oblast monitorování sítí jsme zjistili, že kromě původního využití pro odhalovaní chyb v konfiguraci sítě, plánování sítě a dokazování bezpečnostních incidentů, je možné například automaticky odhalovat škodlivý provoz [Gu05], [Li06], charakterizovat provoz na úrovni aplikací [Mo05] či protokolů nebo použít data o tocích pro zjišťování kvality linky. Navíc v mnoha článcích jsou metody implementovány softwarově, kdy jejich výkon není dostatečný pro zpracování provozu na stávajících linkách s propustností větší než 1 Gb/s. Publikované metody jsou často založeny na vzorcích paketů, přestože by jim stačila agregovaná informace o toku. Z toho usuzujeme, že mnohdy chybí zdroj, který by umožnil zpracování provozu na úrovni toků a zároveň poskytl dostatečnou flexibilitu a výkon.

Na základě zjištěných skutečností jsme se rozhodli navrhnout konfigurovatelný firmware Flexible FlowMon a schéma, které by umožnilo uživateli sondy definovat a přizpůsobit parametry monitorovacího procesu, a to především:

• které položky se mají z paketu extrahovat,
• které položky tvoří identifikátor toku,
• strukturu záznamu o toku,
• přiřadit agregační operaci každé položce záznamu.

Pro popis monitorovacího procesu jsme zvolili jazyk XML. Jeho hlavní výhody jsou mimo jiné snadná možnost rozšíření, přehlednost, strukturovaný zápis a existence softwarových knihoven pro jeho zpracování. Celá definice tvoří strom, kdy jedna část definuje strukturu záznamu extrahovanou z paketu (<uhrecord>) a strukturu záznamu o toku (<flowrecord>). Druhá část pak obsahuje definici agregačních operací (<flowoperation>), například sčítání délek paketů a kontrolních operací (<controloperation>), jako je třeba přetečení čítače paketů. Tento popis je obecný a lze jej použít pro definici monitorovacího procesu implementovaného ve firmware či software. Proprietární konfigurace (např. hlavičkových souborů) jsou generovány až následně na základě XML souboru.

Nově zavedená definice flexibilního záznamu o toku by nutně potřebovala úpravy ve stávající architektuře sondy FlowMon. Ukázalo se, že bude výhodnější stávající architekturu opustit, neboť její propustnost není dostatečná pro plně vytížené linky s přenosovou rychlostí deset gigabitů a vyšší. To je způsobeno složitostí monitorovacího procesu ve firmware, jehož části jsou implementovány algoritmy vhodnými spíše pro softwarové řešení. Na základě měření jsme dále došli k závěru, že architektura příliš málo využívá výpočetní výkon procesoru v počítači, který je vytížen jen z několika procent. Klíčovou myšlenkou bylo tedy zjednodušit firmware a veškeré problémy, které tím vzniknou, dořešit softwarově.

Sonda je stále založena na akceleračních kartách rodiny COMBO a hostitelském počítači, změna je v rozložení zátěže mezi kartu a počítač. Navržená architektura obsahuje dva monitorovací procesy (viz obrázek). První proces na kartě agreguje pakety do záznamů o tocích, není však schopen udržet záznam v paměti dostatečně dlouho a dochází k předčasné expiraci záznamu dříve než síťový tok skončí. To je způsobeno přímou adresací záznamů (dochází ke kolizím). Díky alespoň částečné agregaci se vstupní datový tok dostatečně zmenší a záznamy je již možné přenést do paměti počítače, kde jsou dále agregovány a exportovány na kolektor.

Pro rychlý vývoj aplikačního firmware byl využit projekt NetCOPE [Ma06], viz též část, který poskytuje jednotné rozhraní pro práci s periferiemi na kartě (paměti, síťová rozhraní, PCI rozhraní). Pro správu záznamů o tocích jsme využili projekt FlowContext [KK07], který dokáže distribuovat záznamy mezi několik paralelně pracujících jednotek. Aplikační firmware se pak skládá z několika za sebou zřetězených jednotek (viz obrázek).

První z nich je množina jednotek HFE (Header Field Extractor). Jejich úkolem je přijmout paket z rozhraní NetCOPE a extrahovat informace pro monitorovací proces. Dosud jsme vytvořili několik verzí těchto komponent. Původní HFE byly implementovány ve VHDL jako procesory, na nichž běžel tzv. nanoprogram. Naproti tomu nová HFE, napsaná v jazyku Handel-C (HFE-C), nevykonává žádný program. Její funkce jsou přímo zabudovány ve firmware a v době běhu je není možné měnit. Tento přístup je efektivnější a umožňuje jedné jednotce zpracovat více než jeden gigabit datového toku. Předpokládáme použití osmi HFE pro zpracování všech paketů při rychlosti deset gigabitů. Nové HFE umožňuje z paketu zjistit řadu různých parametrů. Na základě konfiguračního XML souboru se tato množina zúží jen na vyžadované položky.

I když HFE-C poskytují znatelně vyšší výkon oproti původnímu RISC procesoru, jejich hlavní nevýhodou je malá šířka sběrnice a tím nutnost instancovat několik jednotek paralelně. To přidává do implementace značnou režii, nutnou pro rozdělování a spojování datových toků. Navíc se musí zabránit prohození pořadí paketů jednoho toku, aby nedocházelo k prohození jejich časových značek. Abychom zvýšili propustnost pro extrakci položek z hlaviček paketů, vytvořili jsme návrh a implementaci generické a dedikované komponenty, která poskytuje propustnost až deset gigabitů. Tuto komponentu plánujeme v budoucnu využít pro další zvýšení propustnosti sondy při použití na platformě COMBOv2.

Extrahovaná data jsou přenesena z karty rozhraní na základní kartu, kde je z klíčových položek (obvykle IP adres, portů a protokolu) vypočítána hodnota rozptylovací funkce (hash). Klíčové položky je možné určit pomocí XML definice monitorovacího procesu.

Správu záznamů (rozhodnutí o expiraci záznamu) zajišťuje flow state manager ve vyhrazené paměti. Původní implementace založená na řazení záznamů podle stáří v dvousměrně vázaném seznamu byla nahrazena jednodušší variantou. Její princip spočívá v ukládání časové značky posledního paketu daného toku a postupném kontrolování všech platných značek. Tato varianta umožňuje jednodušší paralelizaci a škálovatelnost systému a tím i zvyšování propustnosti.

FlowContext [KK07] nakonec distribuuje extrahovaná data z paketů a k nim příslušné záznamy mezi několik procesních jednotek (Flow Processing Units). Právě procesní jednotky tvoří jádro monitorovacího procesu. Vygenerování instance procesní jednotky vyžaduje zpracovat flexibilní definici XML, tj. přiřadit operacím konkrétní implementaci ve VHDL, tyto operace namapovat na položky záznamu o toku a záznamu extrahovaného z paketu. Procesní jednotka je pak připravena založit, aktualizovat, či uvolnit záznam o toku.

Popsanou architekturu firmware jsme v roce 2007 navrhli a implementovali. V průběhu roku 2008 jsme dokončili implementaci všech firmwarových komponent systému a jejich integraci do celku. V simulacích jsme odladili nejzávažnější funkční chyby a otestovali základní funkčnost celé zřetězené architektury. Nyní se firmwarová část nachází ve fázi prototypu, na kterém odstraňujeme chyby, jež nebylo možné zjistit v simulačním prostředí. Aplikační firmware je postaven nad platformou NetCOPE, což znamená, že je do značné míry nezávislý na typu karty. V dnešní době je firmware vystavěn nad kartami COMBO6X a COMBO-2XFP2, do budoucna předpokládáme jeho využití na kartách COMBOv2. Simulace provedené v software ukazují, že při použití vhodných typů pamětí (QDR SSRAM) bude sonda schopna zpracovat plně vytíženou desetigigabitovou linku.

Při ověřování funkčnosti jednotlivých komponent architektury jsme s výhodou využili verifikační prostředí jazyka SystemVerilog. Toto prostředí umožňuje na vysoké úrovni popsat chování testované komponenty, stimulovat její vstupy a ověřovat správnost vstupně-výstupního komunikačního protokolu. Podrobné informace je možné získat v technické zprávě [Ko07]. V současnosti je verifikován systém FlowContext a flow state manager a pracujeme na implementaci verifikačního prostředí pro další podstatné komponenty firmwaru. Ověřování funkčnosti použitím SystemVerilogu se nám už několikrát osvědčilo a i v případě FlowContextu bylo odhaleno několik závažných chyb již ve fázi simulací.

Součástí sondy je také její programové vybavení, které zabezpečuje správnou inicializaci a konfiguraci sondy a také uživatelské rozhraní. Je nutná podpora práce s XML schematem, tak aby uživatel mohl pohodlně definovat, které položky chce sledovat a přitom strukturu XML nemusel vůbec znát. Tento úkol bude plnit webový frontend, který po zadání všech požadavků provede optimalizace a vygeneruje příslušný firmware.

Jednou z částí programového vybavení sondy je tzv. generační část, viz obrázek. Ta zapouzdřuje činnosti nutné před samotným spuštěním sondy. Uživatel specifikuje své požadavky na monitorovací proces přímo do XML souboru, nebo pomocí uživatelského rozhraní. Z konfiguračního souboru se vygenerují všechny konfigurovatelné firmwarové jednotky a spustí se proces překladu architektury. Výsledkem je konfigurační soubor pro FPGA na akcelerační kartě.

Nedílnou součástí sondy je monitorovací část, která je použita za normálního běhu. Její architekturu ukazuje obrázek. Je založena na struktuře několika vzájemně relativně nezávislých vrstev. Nejnižší část tvoří ovladač jádra operačního systému. Ovladač je součástí projektu NetCOPE a poskytuje aplikaci unifikované rozhraní pro přenos dat mezi akcelerační kartou a aplikací Flexible FlowMon. Na ovladač přímo navazuje aplikační knihovna, která zabezpečuje základní funkce pro sběr a vyhodnocování flow záznamů z karty a také konfigurační rozhraní sondy pro vyšší vrstvy. Aplikační knihovna poskytuje rozhraní pro sekundární monitorovací proces nebo přímo pro exportér (v případě, že druhý monitorovací proces není použit). Data mohou být ze sondy exportována v několika formátech (NetFlow v5, v9, IPFIX).

Na sondě bude instalováno další programové vybavení, například skripty zajišťující nahrání firmware do karty, inicializaci celé sondy a konfiguraci jejích parametrů. Konfigurace může probíhat lokálně či vzdáleně. Konfigurační část zůstává stejná jako u předchozích FlowMon sond, používá se tedy protokol NETCONF.

V průběhu roku 2008 jsme dokončili návrh tohoto programového vybavení a implementovali generační, inicializační a konfigurační část sondy. Zároveň se předpokládá převzetí již implementovaných a odzkoušených celků z původního řešení FlowMon sondy,jako je vzdálená konfigurace, exportéry, apod. Tyto prvky však budou rozšířeny o možnost zpracovávat flexibilní záznam o toku. V první verzi se také nepředpokládá použití druhého monitorovacího procesu. Aplikační část je však na to připravena a implementace a zařazení sekundárního monitorovacího procesu nebude vyžadovat zásahy do stávající architektury.

Flexible FlowMon spolu s kolektory podporujícími plně NetFlow v9 či IPFIX mohou poskytovat o síti daleko více informací než stávající technologie. Flexibilita umožní uživateli testování různých konfigurací sondy a záznamu samotného. Naměřené výsledky mohou sloužit jak pro ověřování metod například pro detekci útoků, tak pro vývoj metod nových.

V roce 2009 plánujeme dokončit implementaci softwarové architektury, verifikovat jak všechny podstatné firmwarové jednotky, tak systém jako celek a následně otestovat sondu v živé síti. V reálné síti bychom chtěli vyzkoušet různé definice záznamu o toku a použít tyto výsledky pro ověření či návrh metod pro detekci škodlivého provozu, charakterizaci provozu, či měření kvality. V delší časové perspektivě pak chceme nadále zvyšovat výkon sondy, například přechodem na nové karty COMBOv2.

4.4.2   Původní sonda FlowMon

Navzdory tomu, že jsme v roce 2007 ukončili aktivní vývoj původní sondy, její firmware a software doznal některých vylepšení. Po zprovoznění nové karty síťového rozhraní COMBO-2XFP2 jsme na ni úspěšně portovali firmware původní sondy. Karta oproti COMBO-2XFP poskytuje stabilnější hardware, výkonnější FPGA a statické paměti s vyšší kapacitou. Prvním rozšířením bylo zvýšení propustnosti desetigigabitového řešení zdvojnásobením počtu HFE procesorů s použitím výše uvedené karty rozhraní. V původním řešení byly čtyři HFE procesory poskytující propustnost celkově 5 Gb/s. Zdvojnásobením jejich počtu je možné při obvyklém rozdělení délek paketů vstupujících do systému dosáhnout plné propustnosti jedné linky. Jedním z dalších rozšíření na kartě COMBO-2XFP2 je zavedení repeateru na XFP rozhraních. To umožňuje zapojit desetigigabitovou variantu přímo do linky jako repeater, což doposud nebylo možné. V průběhu roku jsme také odhalili několik skrytých chyb ve firmware sondy, z nichž nejzávažnější bylo míchání TCP a UDP datagramů do jednoho toku. Tato chyba byla způsobena několika chybnými konstrukcemi v implementaci firmware a byla urychleně odstraněna. Výsledkem oprav a rozšíření je plnohodnotné řešení umožňující monitorovat linky s rychlostí 10 Mb/s, 100 Mb/s, 1 Gb/s a 10 Gb/s.

V softwarové části jsme především odstranili některá omezení sondy, jakým například bylo dlouhé zadržování toků v paměti počítače před exportem na vzdálené kolektory při velmi malém vytížení monitorované sítě. Zaměřili jsme se také na tvorbu zcela nového webového frontendu pro ovládání a konfiguraci sondy, aby jím bylo možné sondu kompletně, snadno a intuitivně ovládat. S tím samozřejmě také souvisela řada změn a úprav v nižších softwarových vrstvách. Díky tomu je nyní možné z jediného webového serveru ovládat libovolný počet sond, aniž by bylo nutné používat jakýkoliv jiný nástroj pro konfiguraci.

Balíček projektu FlowMon lze nainstalovat na běžný počítač s OS Linux a podporovanými COMBO kartami a spustit sondu. Tím považujeme tuto verzi sondy za definitivně dokončenou a dále se budeme věnovat pouze odstraňování případných chyb. Naše budoucí práce bude směřovat k dokončení a rozšiřování sondy Flexible FlowMon, jejímu testování a použití v reálné síti.

4.5   Síťová karta s hardwarovou filtrací paketů

Síťová karta s hardwarovou filtrací paketů (NIFIC) slouží ke zpracování síťových toků plnou rychlostí linky bez ztráty paketu. Architekturu paketového filtru NIFIC lze využít například jako bezstavový firewall, nástroj pro sledování vybraného datového toku fungující přímo rychlostí linky, inteligentní rozbočovač a podobně.

Nová generace karet COMBOv2 již neobsahuje asociativní paměť (CAM), museli jsme tedy celkově přepracovat starší architekturu NIFIC, jež byla založena právě na využití asociativní paměti. Vývoj architektury založené na CAM pro karty COMBO6X + SFPRO jsme zastavili a od května 2008 se již věnujeme pouze nové architektuře. Nově navržená architektura plně využívá potenciál výkonnějších FPGA osazených na kartách COMBOv2 a umožňuje tak hardwarovou filtraci nejen na gigabitové ale i na desetigigabitové a výhledově i čtyřicetigigabitové lince bez ztráty paketu. V první fázi implementace počítáme s podporou do 1000 pravidel a klasifikací podle následujících položek:

• zdrojová a cílová MAC adresa,
• zdrojová a cílová IP adresa,
• zdrojový a cílový port,
• IP Protokol,
• příznaky TCP (flags),
• číslo vstupního rozhraní.

Hardwarová architektura je v první verzi navržena pro zpracování 2×10 Gb provozu na kartě COMBO-LXT, nicméně v době implementace nebyla ještě karta COMBO-LXT k dispozici. Proto jsme implementovali redukovanou testovací verzi na kartě COMBO6X, která ověřila základní funkčnost paketového filtru NIFIC. Po dodání COMBO-LXT jsme implementovali plný design nejprve ve verzi 2×1 Gb, pak i 2×10 Gb. V současnosti je paketový filtr NIFIC ve stavu finálního ladění a testovaní.

Nová architektura paketového filtru NIFIC vychází z klasifikačního algoritmu založeného na dekompozici problému a na softwarovém předzpracování. Klasifikační algoritmus pracuje v následujících krocích:

1. Extrakce důležitých položek z hlavičky paketu.
2. Paralelní zpracování jednotlivých položek hlavičky paketu (Longest Prefix Match), které vede ke snížení datové šířky. Pro různé položky hlavičky jsou použity různé metody jako treebitmap algoritmus, CAM paměť na čipu, RAM paměť na čipu atd.
3. Vzniklé datové slovo vstupuje do perfektní rozptylovací funkce. Tato funkce je zkonstruována tak, aby záměrnými kolizemi eliminovala vznikající pseudopravidla tím, že pseudopravidla odpovídající jednomu pravidlu namapuje na stejné číslo. Výstupem této funkce je pak číslo pravidla.
4. Rozptylovací funkce vrací číslo pravidla, i když paket nevyhovuje žádnému pravidlu. Je proto třeba zkontrolovat, zda hlavička paketu odpovídá danému pravidlu. Tím je pro paket vybráno správné pravidlo a paketový filtr NIFIC může realizovat příslušnou akci.

Hardwarová architektura je založena na platformě NetCOPE [Ma06], viz též část, která poskytuje jednotné rozhraní pro práci s periferiemi. Kompletní funkce paketového filtru NIFIC jsou tak implementovány do aplikačního jádra NetCOPE, kde rozhraní tvoří protokol FrameLink. Aktuální architektura pro zpracování provozu 10 Gb/s obsahuje dvě vstupní a dvě výstupní rozhraní typu Ethernet a dále jedno (až 12 virtuálních) vstupní a výstupní rozhraní do software hostitelského PC.

Datový tok šířky 128 b ze vstupních rozhraní vstupuje do tří jednotek pro parsování hlaviček paketů (HFE). Tyto jednotky jsou speciálně navrženy pro maximální propustnost a jsou schopny v každém taktu zpracovat jedno slovo široké 128 bitů. Výstupem HFE jednotek jsou vybrané položky z hlavičky paketu jako MAC adresa, IP adresa, porty atd. Celý paket je také přeposlán do paketového bufferu, kde čeká na výsledek klasifikace.

Vstupem do klasifikace jsou vybrané položky z hlavičky paketu. Nad vstupními daty proběhne klasifikační algoritmus popsaný výše. Data pro perfektní rozptylovací funkci jsou uložena v externí QDR-II paměti. Pro nalezené číslo pravidla je pak ve výstupní části klasifikace vybrána odpovídající akce (ve formě bitmapy výstupních rozhraní), jež je spolu s číslem pravidla vystavena na výstup.

Jednotka Header Insert vloží do hlavičky rámce FrameLink čekajícího v paketovém bufferu výsledky klasifikace: číslo pravidla a bitmapu výstupních rozhraní. Klasifikované pakety pak vstupují do jednotky crossbar, která podle bitmapy výstupních rozhraní paket přepošle na jedno či více rozhraní, případně ho zahodí. Z crossbaru pak pakety odcházejí na výstupní rozhraní. Při výstupu na softwarové rozhraní může být paket pro zvýšení propustnosti oříznut na žádanou velikost v jednotce trimming unit (TU).

Spolu s novou hardwarovou architekturou se muselo výrazně změnit i softwarové rozhraní, především směrem k pohodlnějšímu nahrání designu i pravidel filtru. Softwarové vybavení pro paketový filtr NIFIC vyvíjíme pro dva rozdílné způsoby použití:

• Lokální softwarové rozhraní, kde se souborem obsahujícím pravidla ve formátu odvozeném od OpenBSD Packet Filter (BPF) přímo konfiguruje paketový filtr NIFIC.
• Vzdálené softwarové rozhraní, paketový filtr NIFIC je kompletně konfigurován ze vzdáleného počítače - monitorovacího centra.

V obou případech je nejnižší softwarovou vrstvou NIFIC konfigurační démon nificgend, který obstarává jak nahrávání a inicializaci designu, tak i nahrání pravidel přímo do designu. Při použití lokálního softwarového rozhraní stojí nad nificgend pouze nific-config, který ve spolupráci s nificgend zpracovává a nahrává pravidla ze vstupního souboru.

V případě vzdáleného softwarového rozhraní je situace složitější. Nad nificgend stojí NIFIC démon nificd zajišťující jak konfiguraci filtru NIFIC, tak i komunikaci s monitorovacím centrem pomocí systému Netopeer, viz část. Pakety přicházející do hostitelského PC z paketového filtru NIFIC jsou pomocí NIFIC exportéru (nificexp) vyčítány a přeposílány do vzdáleného monitorovacího centra. Poslední částí systému vzdáleného softwarového rozhraní je vlastní monitorovací centrum, které je uživatelským rozhraním paketového filtru NIFIC.

Důležitou součástí vývoje nového paketového filtru NIFIC byla kompletní verifikace klasifikačního jádra v SystemVerilog [Ma06]. Pomohla odhalit velké množství chyb a podstatně tak zkrátila dobu nutnou pro odladění celého systému.

4.6   Konfigurační systém Netopeer

Firmware i software síťových zařízení vyvíjených aktivitou Programovatelný hardware je obvykle vysoce konfigurovatelný. V průběhu vývoje jsou konfigurační parametry zadávány různými více či méně kryptickými způsoby, které nemají jednotnou formu. Má-li však takové zařízení být efektivně ovladatelné běžnými uživateli, je nutno je vybavit přívětivějším a konzistentním uživatelským rozhraním. V minulých dvou letech jsme se proto intenzivněji věnovali dokončení konfiguračního programu Netopeer, který se nyní používá ke konfiguraci obou hlavních aplikací aktivity - FlowMon i NIFIC.

Jedná se o implementaci konfiguračního protokolu NETCONF se všemi povinnými vlastnostmi podle [RFC4741]. Pro zabezpečený obousměrný transport konfiguračních a stavových dat používá Netopeer protokol SSH, který je pro implementace NETCONF rovněž povinný [RFC4742]. K tomuto základnímu rámci protokolu NETCONF jsme doplnili dvě komponenty, které tvoří rozhraní s uživatelem na jedné straně (webový frontend) a s konfigurovaným zařízením na straně druhé.

Architektura systému Netopeer je naznačena na obrázku. Skládá se z těchto částí:

Konfigurační démon

běží na straně NETCONF serveru (tj. konfigurovaného zařízení) a aplikuje požadované změny konfigurace.

NETCONF Agent

je serverovou částí komunikačního subsystému NETCONF. Agent přijímá relací SSH od manažera požadavky ve formě RPC zpráv, prostřednictvím páru rour (pipe, FIFO) je předává konfiguračnímu démonu a přijímá od něj výsledky operací, které formátuje do RPC odpovědi a posílá zpět manažerovi.

NETCONF Manager

přijímá data od uživatele, kontroluje jejich správnost a odesílá je ve formě RPC dotazů SSH kanálem agentovi.

Konfigurační frontend

je webové rozhraní formulářového typu, které uživateli umožňuje zadat všechny potřebné parametry a zobrazuje také stav konfigurovaného zařízení. Obrázek obsahuje ukázku jedné stránky této webové aplikace.

V současné verzi musí být obě periferní komponenty - konfigurační démon a webový frontend - napsány specificky pro dané zařízení a strukturu konfiguračních a stavových parametrů. V budoucnu proto chceme tyto dvě komponenty zobecnit tak, aby mohly pracovat prakticky v nezměněné podobě s různými zařízeními a datovými modely. Aktivně se proto účastníme práce skupiny NETMOD při IETF, která vyvíjí prostředky pro specifikaci a validaci datových modelů určených pro NETCONF.

Dalším potřebným rozšířením, které plánujeme implementovat již v roce 2009, jsou notifikace, jimiž může zařízení posílat asynchronní zprávy o změnách stavu, provozních závadách apod.

předchozí

obsah

následující