hledat:

4   Programovatelný hardware

Aktivita Programovatelný hardware se zabývá vývojem hardwarově akcelerovaných síťových zařízení, především pro účely monitorování a zabezpečení vysokorychlostních sítí. V roce 2009 jsme se zaměřili na dvě taková zařízení:

1. NIFIC – hardwarový filtr IP paketů,
2. Flexible FlowMon – sonda pro monitorování IP datových toků s pokročilými funkcemi.

I když nadále udržujeme omezený počet různých firmwarů vyvinutých pro starší karty, obě výše uvedené hardwarově akcelerované aplikace jsou primárně určeny pro nové karty COMBO verze 2 a firmwarovou platformu NetCOPE.

V roce 2009 jsme rodinu karet COMBOv2 doplnili o dosud nejvýkonnější kartu rozhraní COMBOI-10G4TXT se čtyřmi porty desetigigabitového Ethernetu. Tuto kartu využijeme v roce 2010 pro počáteční testy datových přenosů s rychlostí 40 Gb/s.

Druhým přírůstkem rodiny COMBOv2 je karta COMBOL-GPS, která je je osazena přesným krystalem a obvody rozhraní pro příjem časových značek z externího přijímače GPS.

Návrh unikátního bootování karty COMBO-LXT byl přijat jako užitný vzor, v běhu je nyní patentové řízení.

Ve vývoji firmwarové platformy NetCOPE jsme se zaměřili kromě odstraňování nalezených chyb a ladění propustnosti všech subsystémů také na vývoj firmwaru pro standardní síťovou kartu (NIC). Tento firmware, jenž je ve své základní podobě bez hardwarové akcelerace, slouží dvojímu účelu:

• jako etalon pro vývojáře, s jehož pomocí lze ověřit, zda provedené změny nenarušily některé funkce platformy NetCOPE,
• doplněním konkrétního aplikačního jádra lze firmware síťové karty doplnit o hardwarově akcelerované funkce – jednoduchým příkladem může být například výpočet kontrolního součtu CRC.

V oblasti vývoje softwaru se dlouhodobě potýkáme s nedostatkem kvalitních systémových programátorů, a proto se musíme zaměřovat poměrně úzce na podporu základních funkcí vyvíjených síťových aplikací, tedy na vývoj ovladače pro operační systém Linux a uživatelských programů pro konfiguraci aplikací a zpracování příchozích dat.

Nejvýznamnějším výsledkem softwarového vývoje je implementace podpory protokolu IPFIX [Cla08] v programech NFDUMP/NfSen, což je osvědčený a námi několik let používaný software pro sběr a analýzu dat o IP tocích. Protokol IPFIX umožní plně využít potenciálu sondy Flexible FlowMon a exportovat například statistická data o časových mezerách mezi pakety v rámci jednoho toku.

Začátkem roku 2009 jsme publikovali upravenou verzi systému pro vzdálenou konfiguraci síťových zařízení nazvaného Netopeer. Zdrojový kód programu Netopeer je dostupný on-line. Obsahuje jádro implementující protokol NETCONF a uživatelské rozhraní na straně klienta. Konfigurační démon na straně serveru (konfigurovaného zařízení) byl však nahrazen obecným démonem, který slouží jako základ pro implementaci specifických postupů konfigurace konkrétního zařízení. Ucelenější informace o tomto systému obsahuje článek [Kre08].

Řešitelé aktivity se aktivně zúčastnili práce v organizačním a programovém výboru konference FPL 2009 v Praze. Připravili společný stánek sdružení CESNET a univerzit, které se v ČR významně zabývají vývojem technologie FPGA (VUT, MU a ČVUT). Na stánku byly vystaveny karty COMBO a COMBOv2 a prezentovány monitorovací aplikace. Své výsledky na stánku představila také aktivita Sledování a optimalizace výkonnostních charakteristik (viz kapitolu 6).

V rámci přidruženého programu konference FPL 2009 připravili řešitelé aktivity dva workshopy: NetFPGA Tutorial vedený prof. Johnem Lockwoodem ze Stanfordovy univerzity a Embedded Linux in FPGA Chips vedený Parimalem Patelem z firmy XILINX. Oba workshopy se konaly na VUT v Brně.

Důležitou součástí činnosti aktivity Programovatelný hardware je také systematická práce se studenty. Ta nám jednak pomáhá průběžně doplňovat vývojový tým, je ale také velkým přínosem pro samotné studenty, což dokumentují opakovaná ocenění v národních i mezinárodních soutěžích. V roce 2009 dosáhli naši studenti těchto úspěchů:

• V rámci česko-slovenského semináře PAD 2009 pro doktorandy všech vysokých škol z ČR a SR zabývajících se počítačovými architekturami nebo diagnostikou získali Cenu prof. Ing. Jana Hlavičky, DrSc. za vynikající výsledky v doktorském studiu Viktor Puš (1. místo) a Jan Kaštil (3. místo), oba z FIT VUT v Brně.
• Cenu Zdeny Rábové za vynikající studijní výsledky a tvůrčí aktivity získali Marcela Šimková a Ondřej Lengál (oba FIT VUT).
• Diplomová práce Andreje Hanka (FIT VUT) byla mezi deseti nejlepšími ve finálovém kole soutěže IT diplomka roku.

V následujících oddílech jsou všechny hlavní výsledky aktivity podrobněji popsány.

4.1   Rodina karet COMBO

V roce 2009 byly plně oživeny všechny systémy stávajících karet rodiny COMBOv2, tedy COMBO-LXT, COMBO-1G4 a COMBO-10G2 včetně portace klíčových firmwarů. Úspěšně jsme vyzkoušeli osazení karty COMBO-LXT obvody XC5VFX100T pro dosažení rychlosti přenosu 40 Gb/s po sériových linkách mezi mateřskou kartou a kartou rozhraní.

Dále jsme pokračovali vývojem několika nových karet rodiny COMBOv2, zaměřených na příjem přesných časových značek, testování konektorů a zvýšení počtu portů 10 Gb/s.

Karta COMBO-FXT (obrázek 4.1) je odvozena od karty COMBO-LXT. Využívá pinové kompatibility obvodů Virtex-5 LXT a Virtex-5 FXT. Hlavní výhodou této karty je dvojnásobná rychlost obvodů sériového rozhraní RIO (Rocket I/O). Karta COMBO-FXT má také dva konektory IFC s rychlostí přenosu dat až 50 Gb/s.

Pro příjem a zpracování přesných časových značek jsme vyvinuli kartu COMBOL-GPS (obrázek 4.2), která je osazena přesným krystalem a rozhraním RS-422 pro příjem přesných časových značek z externího GPS přijímače.

Karta COMBO-TEST (obrázek 4.3) je určena pro rychlé automatizované testy konektorového systému karty COMBO-LXT.

Karta COMBOL-10G4TXT (obrázek 4.4) obsahuje rozhraní 4×10 Gb/s a rozšiřující konektor IFCs (IFC short) pro připojení dalších (4×1 Gb/s nebo 1×10 Gb/s) rozhraní. V roce 2010 chceme kartu COMBOL-10G4TXT použít pro pilotní testy rozhraní Ethernet 40 Gb/s.

Karty rodiny COMBOv2 tak v současné době představují ucelenou stavebnici pro hardwarovou akceleraci monitorovacích a bezpečnostních aplikací ve vysokorychlostních počítačových sítích.

4.2   Firmwarová vrstva NetCOPE

Základním smyslem konfigurovatelné platformy NetCOPE je 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 umožňuje uživateli koncentrovat se primárně na vývoj vlastní aplikace namísto vcelku rutinní implementace 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 dvě 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 a naopak. 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í,
• síťová karta s distribucí zátěže mezi více procesorů,
• aktivní/pasivní síťový monitoring,
• IPv4/IPv6 směrovač,
• kryptografie,
• zakódování/dekódování videa,
• generování paketů,
• firewall.

NetCOPE je vydáván ve formě RPM balíčků pro operační systém CentOS Linux. Balíčky podporují karty rodiny COMBOv2 a obsahují:

• moduly linuxového jádra,
• knihovny,
• ovládací a diagnostické aplikace,
• příklady použití softwarových rozhraní platformy,
• bloky potřebné k sestavení firmwaru celého FPGA,
• příklad použití firmwaru k sestavení síťové karty,
• dokumentaci.

Pro překlad firmwaru je nutný komerční překladový software firmy Xilinx.

4.2.1   Základní struktura platformy NetCOPE

Firmwarová platforma NetCOPE se skládá z těchto vrstev (viz též obrázek 4.5):

• 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.
• Vrstva firmware NetCOPE: Tato vrstva poskytuje základní možnosti práce s hardwarovou kartou. Jsou k dispozici např. bloky pro příjem a odesílání paketů po Ethernetu, blok komunikace se sběrnicí PCI Express, nebo bloky pro stavbu propojovacího systému na čipu.
• Aplikační jádro: Tuto vrstvu implementuje uživatel platformy a obsahuje vlastní akcelerovanou část uživatelské aplikace. Rozhraní mezi jádrem a NetCOPE je dostatečně abstraktní, takže není zá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í vysokorychlostního aplikačně specifického rozhraní SZE2. Firmware v kartě podporuje vždy jeden z těchto typů přenosu. 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.2.2   Hardwarová architektura

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 na obrázku 4.6.

Síťové rozhraní

Komunikace se síťovým rozhraním karty se děje pomocí síťových bloků, které podporují síťová rozhraní 1G i 10G. Počet rozhraní přitom závisí na možnostech použité karty. 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 je možné 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živatel má k dispozici několik způsobů 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 softwarem 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 softwaru.

Propojovací systém je jeden 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 může využít jednotného rozhraní. Propojovací systém podporuje datové přenosy jak 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: Kvůli ušetření zdrojů na FPGA je možné komponenty, u kterých není vyžadováno vysokorychlostní spojení, připojit k lokální sběrnici. K této sběrnici je výhodné připojovat zejména 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. Z pohledu softwaru poskytují softwarové buffery dvě možná rozhraní. Prvním z nich je rozhraní SZE2, které realizuje vysokorychlostní přenosy fungující na principu kruhového bufferu. Toto rozhraní může sloužit k přenosu libovolných dat, nejen síťových paketů. Druhou možností je standardní rozhraní síťové karty. Toto rozhraní je určeno pro přenos síťových paketů způsobem, který je běžný pro existující operační systémy.

Buffery jsou s uživatelskou aplikací spojeny rozhraním FrameLink. Odeslání paketu do softwaru je jednoduché – stačí pouze odeslat paket rozhraním 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.

Vysokorychlostní řízení DMA přenosů – SZE2

Síťová aplikace je složena nejen z akceleračního jádra umístěného v hardwaru, ale také ze softwarové části. 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, aplikace potom 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 4.7).

Kvůli dosažení maximální rychlosti aplikace jsou DMA přenosy mezi kartou a operační pamětí počítače řízeny z FPGA. Firmware pro řízení DMA přenosů 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 softwaru. 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é. Struktura DMA řadičů je na obrázku 4.8.

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 žádosti o 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 pomocí komponenty Endpoint schopné 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ů.

Standardní řízení DMA přenosů

Pro zachování kompatibility s existujícím softwarem jsme vyvinuli jiný typ DMA řadiče, který odpovídá standardní implementaci přenosu dat mezi síťovou kartou a operačním systému Linux. V tomto případě se operační systém mnohem více podílí na přenosu paketů. Při příjmu je pro každý paket určeno místo kam se má paket přenést, a pakety jsou tedy přenášeny jednotlivě. Naopak při odesílání software určí pro každý paket jeho umístění v paměti (paket se dokonce musí často složit z několika míst v paměti). Tento postup nevyužívá sběrnice příliš efektivně.

4.2.3   Softwarové rozhraní SZE2

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 tak může obsahovat například agregované pakety doplněné o kontrolní informace, časové značky apod. Kromě dat paketů lze přenášet libovolná data, jako například záznamy o tocích nebo přímo informace extrahované z hlaviček paketů. Hlavní výhodou tohoto modelu je jeho propustnost, protože umožňuje agregovat menší pakety do větších bloků a snížit tak režii související s přenosy DMA.

Aplikace využívající rozhraní PCAP mohou použít implementaci knihovny PCAP modifikované tak, aby komunikovala s rozhraním SZE2 a mohla využívat vysokorychlostní přenosy.

Pro zachování kompatibility s dalším existujícím programovým vybavením umožňuje ovladač také napojení na standardní linuxový TCP/IP stack. Rychlost je potom snížena průchodem paketů jádrem Linuxu, hlavním přínosem tohoto přístupu je však možnost použití všech běžných síťových aplikací.

V rámci aplikačně specifického rozhraní SZE2 se používá kruhový buffer pro ukládání dat. Tento buffer je implementován jako seznam zřetězený 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 ukazatele tvoří frontu typu FIFO (First In First Out). Při zápisu do bufferu se zvětšuje ukazatel na začátek, při čtení se naopak zvyšuje hodnota ukazatele na konec. Tyto ukazatele určují množství dat uložených v bufferu.

Data v bufferu mohou mít obecně libovolný formát s jediným omezením: 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.2.4   Standardní softwarové rozhraní

Použije-li se firmware podporující standardní přenosy, je k dispozici pouze toto rozhraní. Běžnou součástí operačního systému je potom možnost využít rozhraní PCAP, v tomto případě není třeba žádných úprav v knihovně PCAP.

4.2.5   Přesné časové značky

Díky kartě COMBOL-GPS je možné získávat informace o přesném čase ze systému GPS. NetCOPE poskytuje rozhraní, kterým lze tyto informace využít v aplikaci. Jednotka TSU (TimeStamp Unit) udržuje informaci o přesném času, a prezentuje ji uživateli jako signál šířky 64 bitů. Horních 32 bitů určuje počet sekund od 1. 1. 1970, spodních 32 bitů pak reprezentuje zlomky sekundy. Signál v tomto formátu může aplikace využít libovolně, například pro výpočet časových statistik o síťových tocích.

Protože připojená GPS poskytuje přesnou časovou informaci pouze jednou za sekundu formou pulzu, jednotka TSU aproximuje čítačem čas mezi jednotlivými pulzy. Aby byla aproximace přesná, běží v softwaru regulační smyčka, která podle předchozí odchylky od přesného času nastavuje rychlost čítání formou změny hodnoty inkrementační konstanty.

4.2.6   Aplikace síťová karta

Síťová karta je základní a nejjednodušší aplikací nad platformou NetCOPE. Z pohledu firmwaru je aplikační jádro vlastně nevyplněno. Při příjmu se pakety ze síťových rozhraní posílají rovnou do bufferů pro přenos do softwaru. Naopak při odesílání putují pakety ze softwarových bufferů přímo do síťových rozhraní.

Tato aplikace běží až na frekvenci 198 MHz a dosahuje propustnosti (stanovené podle [BM99]) okolo 10 Gb/s, v závislosti na délce paketů. Hrubá propustnost FRMOL (Frame Rate at Maximum Offered Load) podle [Man98] je vždy nad 10 Gb/s.

4.3   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 jsme na základě získaných zkušeností navrhli novou koncepci této sondy umožňující měřit linky s rychlostí 10 Gb/s a vyšší. V průběhu roku 2008 jsme dokončili implementaci této architektury a realizovali i první testy v hardwaru. V první polovině roku 2009 byly pak odladěny zbývající chyby a zahájili jsme práce na převedení sondy na novou generaci akceleračních karet rodiny COMBO.

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 technické zprávě [Cel06]. 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í sondu pro desetigigabitové linky a po přenesení architektury na kartu XFP2 jsme začátkem roku 2008 vytvořili kompletní a stabilní nástroj 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. V průběhu první poloviny roku 2009 pak byla sonda s novou architekturou laděna a testována při zapojení v živé síti.

4.3.1   Flexible FlowMon

Sonda Flexible FlowMon je založena na akceleračních kartách rodiny COMBO a hostitelském počítači. Jednotlivé úlohy jsou v ní rozděleny mezi firmware a software: zatímco úkolem akcelerační karty je příjem paketů ze sítě, extrakce jejich hlaviček a vytváření záznamů o tocích, hostitelský počítač se stará o export vytvořených záznamů pomocí zvoleného protokolu (NetFlow v5, NetFlow v9, IPFIX).

Sonda používá dva monitorovací procesy (viz obrázek 4.12). 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ů a množstvím toků v síti (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 firmwaru byl využit projekt NetCOPE [MT06], viz též část 4.2, 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 jednotku 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 4.13).

První v řetězci je sada paralelně zapojených jednotek Header Field Extractor (HFE), jejichž úkolem je extrakce požadovaných hlaviček ze síťových paketů. Následuje jednotka Hash Generator, která z klíčových položek (obvykle IP adres, portů a protokolu) vypočítává hodnotu rozptylovací funkce (hash). Správu záznamů (rozhodnutí o expiraci záznamu z důvodu příliš dlouhého intervalu od příchodu posledního paketu toku) zajišťuje Flow State Manager ve vyhrazené paměti. FlowContext 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: zakládají, aktualizují, či uvolňují záznamy o tocích.

4.3.2   Portování sondy Flexible FlowMon na COMBOv2

V průběhu dokončování sondy Flexible FlowMon započaly práce na portování firmwaru na karty rodiny COMBOv2. Použití platformy NetCOPE do značné míry tento krok zjednodušilo, bylo však nutné vyrovnat se s rozdíly v konstrukci karet. Zatímco karty COMBO6X používaly dva FPGA čipy rodiny Virtex-II Pro a bylo nutné zajistit mezi těmito čipy bezpečný přenos dat, v nové generaci karet je použit jen jeden (větší) čip Virtex-5, což mírně zjednodušuje návrh. Větší problém však způsobil počet paměťových čipů na kartě. Zatímco na kartě COMBO6X byly tyto čipy tři, z čehož dva byly využity jako cache pro záznamy o tocích a zbylý sloužil pro správu aktivity toků jako paměť jednotky Flow State Manager, na kartě COMBOv2 jsou jen dvě paměti, přičemž obě bylo potřeba použít pro cache záznamů. Chybějící paměť pro správu aktivity toků musela být nahrazena blokovými pamětmi na čipu. Z důvodu jejich značně omezeného počtu bylo třeba provést optimalizaci některých jednotek, které je také používají. Dalším z požadavků při přesunu na kartu COMBOv2 bylo monitorování obou vstupních portů. Toto bylo vyřešeno zapojením jednotky spojující pakety ze dvou vstupních rozhraní do jednoho datového toku. Spolu s integrovaným opakovačem lze pak sondu použít jako zařízení typu TAP monitorující obě vstupní rozhraní. Schéma zapojení je na obrázku 4.14.

Čipy Virtex-5 nám díky své konstrukci umožnily zvýšení taktovací frekvence firmwaru o 25 %. Nárůst výkonu pamětí QDR oproti pamětem SRAM použitým na COMBO6X umožnil zvýšit rychlost agregační části. Díky větší ploše čipu lze také zapojit více agregačních jednotek. Ve výsledku jsme dosáhli oproti kartě COMBO6X zrychlení převyšující 70 %.

4.3.3   Optimalizovaná architektura sondy FlowMon s podporou rozšiřujících modulů

Karta COMBOv2 má výrazně vyšší potenciál ve výkonnosti FPGA i kapacitě a rychlosti pamětí než dříve používaná karta COMBO6X. Použité FPGA Virtex-5 spolu s dvojicí QDR pamětí s propustností 16 Gb/s pro čtení a zápis umožňují vytvořit vysoce výkonnou sondu pro monitorování síťových toků. Abychom využili plný potenciál karet COMBOv2 a poskytli prostor pro vytvoření rozšiřujících modulů pro detekci aplikačních protokolů a měření časových značek, navrhli jsme novou, výkonnější architekturu monitorovací sondy. Nová architektura je postavena na platformě NetCOPE, která značně usnadňuje příjem paketů ze sítě a přenos dat přes sběrnici hostitelského počítače. Využili jsme také nově vyvinutou technologii pro analýzu hlaviček paketů [KKP09], zakomponovali nový modul pro přesné měření časových značek a pro podporu detekce aplikačních protokolů jsme využili dosavadních zkušeností s dříve publikovanými přístupy pro hledání regulárních výrazů [KK07a], [KKL09].

Optimalizovaná architektura sondy je zachycena na obrázku 4.15. Celý systém je rozdělen do dvou částí podle možných úrovní hardwarové akcelerace. V první úrovni je akcelerováno pouze zpracování paketů, v druhé úrovni je na kartě prováděna agregace záznamů prostřednictvím primární cache. Implementace systému byla rozdělena do dvou navazujících fází, které kopírují uvedené rozdělení architektury.

Zpracování paketů začíná analýzou paketů v jednotce HFE-X, která extrahuje důležité položky z hlaviček paketů a vkládá je do jednotné struktury tzv. unifikované hlavičky (UH). Současně identifikuje začátek dat paketů, který spolu s UH předává do jednotky pro hledání regulárních výrazů (PTRN MATCH). Jednotka hledá v datech paketu zadanou množinu regulárních výrazů a poskytuje binární vektor o velikosti 32 bitů, kde každý bit odpovídá jednomu výrazu a signalizuje zda byl (1) nebo nebyl (0) nalezen. Binární vektor je vložen do UH a předán do jednotky Hash Generator, která má za úkol spočítat z identifikátoru toku hodnotu hash pro určení pozice toku v paměti.

Druhá část zpracování je zaměřena na správu flow cache umístěné přímo na kartě. Celá flow cache je umístěna ve dvou externích QDR SRAM, které jsou spojeny do jednoho paměťového prostoru o kapacitě 16 MB. Čtení a zápis záznamů z flow cache zajišťuje opět jednotka Context Manager. Aby byla dosažena maximální propustnost, byla jednotka replikována pro každé vstupní rozhraní. Přístup do externích pamětí QDR SRAM je přepínán v přesně definovaných časových okamžicích. O správu záznamů se stará Flow State Manager. Uchování stavu toků je stejně jako v předchozí verzi řešeno pamětí na čipu složenou z BlockRAM. Výrazného urychlení dosáhla jednotka pro aktualizaci záznamu (Flow Processing Unit – FPU). V současné architektuře již není potřeba mít několik paralelních jednotek a řešit problémy spojené s distribucí dat. Pro zpracování 10 Gb/s toku paketů nyní stačí pouze jediná jednotka. Urychlení jsme dosáhli zejména proudovým zpracováním záznamů a použitím širší vyrovnávací paměti na záznamy, ale také zřetězením operace detekce kolizí s aktualizací záznamů.

Největších změn v architektuře pro COMBOv2 doznala vstupní část, která se zabývá zpracováním paketů. Využili jsme nový způsob analýzy hlaviček paketů [KKP09], který je založen na generování obvodu podle specifikace protokolů popsaných v jazyku XML. Uvedeným konceptem je možné snadno generovat moduly pro zpracování různých datových šířek vstupu a při generování optimalizovat architekturu pro konkrétní datovou šířku. Podobný systém jsme zvolili i pro hledání regulárních výrazů v jednotce pattern match. Zde jsme využili zkušeností získaných z dříve řešeného projektu IDS. Díky variabilitě datové šířky vstupu u obou jednotek jsme mohli analyzovat vliv datové šířky a počtu paralelních jednotek na spotřebované hardwarové zdroje. Na základě provedených experimentů bylo zjištěno, že pro zajištění propustnosti 10 Gb/s je vhodné použít zpracování dat po 32 bitech ve třech paralelních jednotkách, jak je zachyceno na obrázku 4.16. V architektuře byla urychlena i jednotka pro generování hash (HGEN). Místo výpočtu CRC používá Jankinsonovu rozptylovací funkci, kterou je možné implementovat s výrazně menšími nároky na hardwarové zdroje a jednoduše zřetězit pro dosažení vysoké frekvence. I přes výrazné optimalizace a redukce hardwarových nároků se podařilo nakonec umístit na FPGA čip pouze systém s propustností 10 Gb/s. Další hardwarové zdroje by bylo možné uvolnit pouze za cenu snížení obecnosti jednotky FlowContext, která zajišťuje fungování primární cache.

4.3.4   Rozšiřující FlowMon moduly a jejich využití

Vývoj a rozšiřování funkcí sondy FlowMon umožňuje její inovativní využití v nových aplikacích. Přestože aktuální standard měření síťových toků – IPFIX – poskytuje širokou nabídku měřitelných charakteristik, jejich podpora na straně sond je velmi řídká. Naproti tomu sonda Flexible FlowMon umožňuje libovolně definovat měřené charakteristiky pomocí tzv. flexibilního záznamu. Flexible FlowMon tedy dosáhl plné podpory standardu IPFIX a navíc byl rozšířen o další moduly za účelem získání nezkreslených či nových dat. Zkreslená data o toku mohou vzniknout například nepřesným měřením jeho časových charakteristik. K obnovení ztracené informace je nezbytná znalost aplikace, která tok vygenerovala. Právě tyto dva nedostatky vedly k implementaci dvou přídavných modulů určených pro identifikaci aplikace a pro přesné měření časových charakteristik.

Prvním z nich je tzv. L7 dekodér, jehož úkolem je vyhledávat v protokolu aplikační vrstvy známé vzory a pomocí nich identifikovat komunikující aplikaci. Toto rozšíření umožňuje určit aplikaci v síťovém toku, pokud to není možné přímo z čísla portu. Taková situace nastává v těchto případech:

• Některé aplikace využívají libovolné porty mimo rozsah definovaný organizací IANA.
• Aplikace může záměrně přenášet provoz na portu vyhrazeném pro jinou aplikaci, například aby obešla ochranu pomocí firewallu.

L7 dekodér je založen na vyhledávání řetězce v datech paketu podle regulárního výrazu. Zkušenosti z minulých let s akcelerací IDS (Snort), který také vyhledává škodlivé vzory v sítovém provozu, nám pomohly navrhnout architekturu L7 dekodéru schopného vyhledávat aplikační vzory při rychlostech 10 Gb/s. Jádrem L7 dekodéru je deterministický stavový automat, který je syntetizován z množiny vzorů převzatých z otevřeného projektu L7-filter. Sonda Flexible FlowMon tak může určit konkrétní aplikaci, která každý tok vygenerovala. Toho lze využít k odhalení, které aplikace jsou tunelovány porty přiřazenými jiným aplikacím, a dále pro detekci aplikací na portech využívaných dynamicky. Z předběžných výsledků získaných z desetigigabitové linky sítě CESNET2 je vidět, že typickými představiteli aplikací s dynamickým přidělováním portů jsou dnes velmi rozšířené peer-to-peer služby. Na obrázku 4.17 lze vidět, že na základě portu byla rozpoznána jen mizivá část BitTorrent provozu, zatímco na základě vzoru byl identifikován BitTorrent i na portech z dynamického rozsahu.

Druhým rozšířením je jednotka přiřazující přesnou časovou informaci (značku) každému příchozímu paketu. Přesnost časového údaje v kontextu měření síťového provozu je obecně závislá na vyřešení následujících problémů:

• kompenzace nepřesnosti krystalu,
• synchronizace hodin s přesným atomovým časem,
• zpoždění přiřazení značky při příchodu rámce na síťové rozhraní.

Flexibilní FlowMon s TimeStamp Unit (TSU) umožňuje přiřazovat časovou značku příchozímu paketu na síťové rozhraní s absolutní přesností ±2,5 μs a rozlišením na úrovni nanosekund. Velmi malá odchylka od absolutní přesnosti je zaručena díky synchronizaci pomocí GPS a zároveň přesný krystal v kombinaci v hardwarovou interpolací času mezi jednotlivými synchronizačními pulzy umožňuje generovat přesnou značku s vysokým rozlišením. Přesnost této značky dovoluje nasadit Flexible FlowMon na přesné měření časových charakteristik toků, které lze následně využít pro měření kvality přenosové služby či vlastností cílové aplikace.

Jedním z využití zaznamenaných dat může být například měření jednosměrného zpoždění a jeho kolísání při průchodu toku mezi dvěma měřicími body, kdy je možné sbírat statistické momenty prvního řádu, stejně tak i konkrétní časové značky jednotlivých paketů ke každému toku a v každém uzlu. Tyto informace lze následně využít pro nastavení priority, bufferů, směrování konkrétního provozu a zaručit tak kvalitu služby pro daný typ aplikace.

Dalším z řady využití přesných časových charakteristik toků je sledování odezvy aplikací, tj. měření doby mezi dotazem a odpovědí aplikačního serveru. Například v datových centrech by bylo možné takovým měřením odhalit přetížení či pád aplikace sledováním požadavků a doby jejich vyřízení a lépe distribuovat zátěž mezi dostupné zdroje.

Přesné měření časových charakteristik lze uplatnit i v oblasti bezpečnosti, například k detekci tzv. stepping stones – napadené stanice, které útočník využívá k tunelování provozu přes několik různých sítí, čímž se snaží znesnadnit své odhalení. Pro odhalení tohoto provozu se využívá porovnání toků co do shody jejich charakteristik, především časových, ale i dalších (například délek paketů). Měření těchto toků umožňuje odhalit, který tok předcházel jinému a dále významně zpřesní vstupní data vstupující do detekčního mechanismu, čímž se zvýší jeho spolehlivost.

Souhrnně, Flexible FlowMon umožňuje dlouhodobé sledování a měření síťového provozu, jež je nepostradatelným zdrojem informací pro správu, plánování a ochranu počítačové sítě. Dnešní sítě mají složitou a rozsáhlou topologii (fyzickou i logickou), ve které je optimalizace nastavení síťových prvků nebo řešení anomálií jako je zvýšení chybovosti linky, špatné směrování, útoků a dalších patologií, bez sledovací infrastruktury jen obtížně proveditelné. Počítačovou síť navíc využívá široké spektrum aplikací, každá s různými nároky na kvalitu poskytované služby. Některé aplikace například vyžadují, aby síť byla bezeztrátová, s co nejmenším zpožděním, jiné naopak tolerují nižší kvalitu na úkor šířky přenosového pásma. Jako vhodný zdroj dat pro vyčíslení požadavků aplikací a následnou implementaci či optimalizaci se jeví sonda Flexible FlowMon, jež měří provoz a akumuluje statistiky všech probíhajících síťových toků a umožňuje tak sledovat chování jednotlivých aplikací v interakci s jinými, tedy z globálního pohledu. Na základě analýzy naměřených výsledků lze například odvodit ztrátovost spojení, zpoždění a následně tyto parametry optimalizovat.

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

Síťová karta s hardwarovou filtrací paketů – paketový filtr (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, inteligentní rozbočovač atp.

Paketový filtr NIFIC byl navržen pro rodinu karet COMBOv2. Architektura plně využívá potenciál výkonných FPGA osazených na kartách COMBOv2 a je navržena pro filtraci nejenom gigabitové, ale hlavně desigigabitové a výhledově čtyřicetigigabitové linky bez ztráty paketu. Aktuální implementace podporuje až 2000 pravidel a umožňuje jejich přepnutí za běhu bez ztráty paketu. Paket může být klasifikován podle následujících položek ze své hlavičky:

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

4.4.1   Klasifikační algoritmus

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í [PK09]. 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 (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 zobrazí na stejné číslo. Výstupem funkce je pak číslo pravidla.
4. Rozptylovací funkce vrací číslo pravidla, i když paket nevyhovuje žádnému pravidlu. Je proto potřeba zkontrolovat, zda hlavička paketu odpovídá danému pravidlu. Tímto je pro daný paket vybráno správné pravidlo a paketový filtr NIFIC může realizovat odpovídající akci.

4.4.2   Podporovaný hardware

Na konci roku 2008 jsme připravili první firmware NIFIC pro kartu COMBO-LXT100T s kartou rozhraní COMBO-1G4 pro filtraci 2×1 Gb/s. Po dodání karty COMBO-10G2 jsme připravili firmware pro 2×10 Gb/s, kde jsme ale byli nuceni použít kartu COMBO-LXT155T s větším FPGA čipem. Paketový filtr NIFIC lze tedy plnohodnotně provozovat na těchto kombinacích karet:

• COMBO-LXT110T + COMBO-1G4 pro filtraci 2×1 Gb/s
• COMBO-LXT155T + COMBO-10G2 pro filtraci 2×10 Gb/s

4.4.3   Architektura firmwaru

Hardwarová architektura je založena na platformě NetCOPE popsané v části 4.2, která poskytuje jednotné rozhraní pro práci s periferiemi. Kompletní funkce paketového filtru NIFIC jsou implementovány do aplikačního jádra NetCOPE, kde rozhraní tvoří protokol FrameLink. Aktuální architektura pro zpracování provozu max. 2×10 Gb/s obsahuje dvě vstupní a dvě výstupní rozhraní typu Ethernet, jedno fyzické a až 14 virtuálních vstupních rozhraní a konečně jedno výstupní rozhraní do softwaru hostitelského PC.

Datový tok šířky 128 b ze vstupních rozhraní vstupuje do tří jednotek pro analýzu 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í paměti QDR-II. Pro nalezené číslo pravidla je pak ve výstupní části klasifikace vybrána odpovídající akce (ve formě bitmapy výstupních rozhraní) a ta 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 ke zvýšení propustnosti oříznut na žádanou velikost v jednotce trimming unit.

Jelikož jsme od začátku čelili problémům s nedostatkem hardwarových zdrojů na čipu a nízkou maximální frekvencí, bylo nutné udělat do původního návrhu architektury několik změn, abychom ve výsledku dosáhli plné propustnosti linky 2×10 Gb/s:

• Použití 32b HFE jednotky pro vstup ze softwaru.
• Úpravy klasifikace, aby i při snížené frekvenci firmwaru zůstala zachována plná propustnost linky.

Kromě výše zmíněné změny jsme již žádné další zásahy do architektury neprováděli a soustředili jsme se na stabilizaci a odladění všech chyb (nefunkční QDR-II, bezztrátové přepnutí pravidel, propustnost atd.). Nakonec se povedlo všechny zásadní problémy vyřešit a současný firmware lze považovat za stabilní.

4.4.4   Softwarová architektura

Softwarové vybavení pro paketový filtr NIFIC je navrženo pro dva základní případy 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.

Původní konfigurační softwarový démon byl výrazně přepracován a vznikly také skripty pro jednoduché spuštění paketového filtru, ať už s lokální nebo vzdálenou konfigurací. V obou případech je nejnižší softwarovou vrstvou NIFIC konfigurační démon nificsd, který obstarává jak přímo práci s hardwarem, tak i zpracování pravidel a komunikaci se vzdáleným monitorovacím centrem. Při použití lokálního softwarového rozhraní stojí nad nificsd pouze nific-config, který ve spolupráci s nificsd zpracovává a nahrává pravidla ze vstupního souboru.

Výrazným přínosem pro praktické použití paketového filtru je implementace standardního síťového rozhraní. Vzhledem k faktu, že firmware NIFIC podporuje až 14 virtuálních softwarových rozhraní, je možné vytvořit až 14 standardních síťových rozhraní, která lze využít jak pro příjem, tak i pro odesílání stejným způsobem jako u běžné síťové karty. Nepříjemnou vlastností současné implementace je omezená propustnost (cca 1 Gb/s pro všechna rozhraní). Při použití lokální konfigurace jsou tedy na výběr následující možnosti pro příjem a odesílání paketů ze softwaru hostitelského počítače:

• knihovna libsze2,
• knihovna libpcap (pouze příjem),
• standardní síťové rozhraní (omezená propustnost).

V případě vzdáleného softwarového rozhraní nový démon nificsd integruje původní funkce démona nificged a nificd. NIFIC démon nificsd přímo komunikuje s monitorovacím centrem pomocí systému Netopeer. Pakety přicházející do hostitelského počítače 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. V rámci našeho vývoje jsme implementovali jednoduché monitorovací centrum nificmon. Nificmon slouží nejen pro vizualizaci přijatých paketů, ale také implementuje standardní síťové rozhraní pro přeposílané pakety na vzdáleném počítači.

4.4.5   Testy paketového filtru NIFIC

Paketový filtr NIFIC byl a je testován následujícími testy:

• Propustnost dle [BM99]. Test propustnosti ukázal, že paketový filtr NIFIC má plnou propustnost linky pro oba ethernetové porty (20 Gb/s) a propustnost cca 5 Gb/s při přenosu dat do softwaru hostitelského počítače.
• Správnost klasifikace. Automatizovaný test, který pro danou komplexní sadu pravidel generuje testovací pakety, ukázal, že paketový filtr NIFIC správně klasifikuje podle všech podporovaných položek z hlavičky paketu.
• Specifické testy, které ověřily bezztrátové přepínání pravidel, správnost klasifikace ne-IPv4 paketů, testy instalace balíčku atd.

4.4.6   RPM balíčky

Paketový filtr NIFIC je vydáván ve formě RPM balíčků pro operační systém CentOS Linux. Podporované karty jsou popsány v části 4.4.2. Tyto balíčky obsahují:

• firmware (pro 2×1 Gb/s a 2×10 Gb/s),
• moduly Linuxového jádra,
• knihovny (libsze2, libpcap,...),
• konfigurační software,
• dokumentaci – NIFIC handbook.

Součástí dokumentace je také soubor připravených příkladů použití s ukázkovými aplikacemi paketového filtru NIFIC, jako je VoIP analyzátor, nástroj pro logování HTTP provozu nebo nástroj na ochranu sítě.

4.5   Rozšíření kolektoru NfSen

Vývoj protokolů pro export informací o tocích vedl v posledních letech k větší flexibilitě těchto protokolů. Původní statický formát velmi rozšířeného protokolu NetFlow v5 byl v protokolu NetFlow v9 nahrazen flexibilním formátem založeným na používání šablon. Šablony umožňují vybírat položky, které jsou exportovány sondou a zpracovávány kolektorem. Tím se umožňuje operátorům sledovat právě ty informace, které jsou pro ně významné. Na druhé straně však tento přístup klade zvýšené nároky jak na exportér, tak i na kolektor.

Významným pokrokem ve vývoji protokolů pro export informací o tocích bylo vytvoření protokolu IPFIX (IP Flow Information Export). Ten přímo vychází z protokolu NetFlow v9, přebírá z něho mimo jiné i princip použití šablon, ale ve flexibilitě protokolu jde ještě dále: NetFlow v9 umožňuje pouze výběr předem definovaných informačních položek, zatímco IPFIX navíc umožňuje pomocí šablon i definici nových informačních položek, což dále zvyšuje nároky na schopnosti exportéru i kolektoru. Podrobnější popis protokolu IPFIX lze nalézt v [Cla08].

Vývoj v oblasti protokolů pro export informací o tocích se projevil i v dalším vývoji sondy FlowMon. Její nová generace, Flexible FlowMon, už umožňuje změnu formátu exportovaných záznamů. Úpravami samozřejmě prošlo i programové vybavení sondy, které tyto možnosti podporuje implementací flexibilních protokolů NetFlow v9 a IPFIX. Podrobnější popis sondy Flexible FlowMon a se nachází v části 4.3.1.

Pro potřeby testování a dalšího používání sondy bylo však také nutno mít vhodný kolektor, který je schopný data odeslaná ze sondy zpracovat. Osvědčenou aplikací pro tyto účely je kolektor NfSen/NFDUMP. Proces zpracování dat tímto kolektorem je zobrazen na obrázku 4.22.

Kolektor NfSen/NFDUMP podporuje příjem dat ve formátech sFlow, NetFlow v5 a nově poskytuje i vylepšenou podporu protokolu NetFlow v9. Ve výčtu podporovaných protokolů tedy chybí IPFIX. Pro účely maximálního využití a demonstrace schopností sondy Flexible FlowMon jsme nejdříve hledali jiný kolektor podporující protokol IPFIX. Bohužel žádné z testovaných řešení (Aurora, ntop či SiLK) nevyhovovalo našim požadavkům. Proto jsme se rozhodli přímo rozšířit open-source kolektor NfSen/NFDUMP o modul pro zpracování dat ve formátu IPFIX. Architektura kolektoru vyžaduje pro tento typ změny pouze přidání modulu pro příjem dat ve formátu IPFIX. Formát přijatých dat je poté transformován do souborového formátu společného všem modulům pro sběr dat. Uložená data mohou být dále zpracována jednotným způsobem nezávisle na protokolu použitém pro export dat ze sondy.

Kritickým bodem je formát ukládaných dat. Vzhledem k flexibilitě protokolů NetFlow v9 a IPFIX musí být i formát ukládaných dat dostatečně pružný, aby bylo možné uložit data ze všech informačních položek obsažených v příchozích záznamech. Toto je možné až díky souborovému formátu dostupnému v sadě nástrojů NFDUMP 1.6. Na rozdíl od předchozích verzí umožňuje tento formát relativně snadno přidávat vlastní rozšíření a jimi definovat způsob zpracování a hlavně ukládání specifických informačních položek v souborech sady nástrojů NFDUMP. Stále se však jedná o rozšíření v podobě úpravy zdrojového kódu kolektoru. Proto není možné zpracovávat a ukládat specifické informační položky, pro které není nejdříve připraveno rozšíření formátu.

Výsledkem naší práce bylo vytvoření dvou backend modulů pro kolektor NfSen/NFDUMP. Modul ipfixcapd přijímá a zpracovává data ve formátu IPFIX, která dále ukládá do formátu nástrojů NFDUMP. Pro účely tohoto modulu jsme také přidali podporu příjmu dat s využitím transportních protokolů TCP a SCTP. Původní kolektor umožňoval příjem dat pouze pomocí protokolu UDP. Druhý modul je určen pro zpracování dat přímo ze sondy (Flexible) FlowMon. Dříve totiž i v situaci, kdy sonda i kolektor byly nasazeny na stejném stroji, převáděl exportér data ze sondy do formátu exportního protokolu a odeslal je interním rozhraním zpětné smyčky (loopback) kolektoru, jenž je zase zpět převedl do svého formátu dat. Tento postup zbytečně zvyšoval zátěž stroje. Vytvořený modul flowmon_nfdump tento postup zjednodušuje: Nahrazuje exportér tím, že přímo vyčítá záznamy o tocích ze sondy (Flexible) FlowMon a ukládá je na disk ve formátu NFDUMP.

Implementovali jsme také rozšíření souborového formátu NFDUMP o podporu zpracování a ukládání přesných časových značek až do přesnosti v nanosekundách.

Vzhledem k tomu, že vývoj popsaných rozšíření probíhal v raných fázích vývoje nástrojů NFDUMP verze 1.6, bude nyní třeba provést začlenění našich rozšíření do finální verze sady nástrojů NFDUMP 1.6. Ta by měla být dokončena začátkem roku 2010. Poté bychom chtěli naše rozšíření kolektoru NfSen/NFDUMP zveřejnit pod open source licencí.

předchozí

obsah

následující