hledat:

4   Programovatelný hardware

V pátém roce své existence pokračovala aktivita Programovatelný hardware bez větších výkyvů v kursu, který byl nastoupen v předchozích letech. Hlavním objektem zájmu jsou především hardwarově akcelerované sondy pro monitorování provozu ve vysokorychlostních sítích. Tyto projekty se rozvíjejí velmi slibně a mají evidentní praktické využití. Další oddíly této kapitoly se jim budou podrobně věnovat.

V roce 2006 jsme zahájili poměrně rozsáhlou reorganizaci struktury firmwarových modulů, jejímž cílem je usnadnit v podstatě libovolné skládání těchto modulů do celků realizujících požadované funkce. Firmwarové moduly ve formě zdrojových programů v jazyce VHDL byly samozřejmě i dříve podle možnosti opakovaně využívány, každý projekt však muset po integraci modulu udržovat svou vlastní verzi, což se ukázalo jako neefektivní.

Nová firmwarová architektura nesoucí název NetCOPE vytváří potřebnou infrastrukturu a definuje rozhraní pro komunikaci mezi moduly, takže v budoucnu bude zdrojový kód každého modulu udržován v jediné instanci. Základem systému NetCOPE bude tlustá roura ze síťového rozhraní do softwaru, která bude schopna předávat síťová data operačnímu systému podstatně rychleji než jak to umožňují komerčně dostupné ethernetové adaptéry. K tomuto základnímu modulu bude možno stavebnicovým způsobem připojovat další firmwarové moduly, například pro filtrování paketů, klasifikaci IP toků nebo vyhledávání řetězců v datovém obsahu datagramů. Všechny stávající firmwarové designy by měly být postupně převedeny na platformu NetCOPE. Její detailní popis obsahuje část 4.3.

Událostí hodnou zaznamenání je kompletní dokončení firmwaru směrovače IPv4/IPv6 v podstatě podle původního návrhu z roku 2002. Projekt směrovače byl pod názvem Liberouter vlajkovou lodí aktivity v prvních letech její existence a dodnes je tímto jménem často označována celá aktivita. Průběh vývoje tohoto firmwaru však stále jasněji naznačoval, že celý poměrně komplikovaný návrh stojí a padá s modulem LUP (Look-Up Processor), jehož úkolem je klasifikovat každý přijatý paket a rozhodnout o tom, jak se s ním naloží. Podle původní představy měl LUP k tomuto účelu využívat jediný klasifikační strom kombinující směrovací tabulku s pravidly paketového filtru (firewallu). Ukázalo se, že tento ambiciózní záměr neobstojí v prostředí běžného Internetu: složitost klasifikačního stromu totiž roste přibližně úměrně se součinem počtu záznamů ve směrovací tabulce a paketovém filtru, což při téměř dvou stech tisících záznamech v globální směrovací tabulce BGP a typicky několika desítkách filtrovacích pravidel překračuje limity použitého hardwaru. Směrovač Liberouter proto může stěží konkurovat komerčním směrovačům na straně jedné a levným softwarovým směrovačům na straně druhé.

Relativní neúspěch projektu Liberouter ale v žádném případě neznamená, že prostředky investované do jeho vývoje přišly nazmar. Naprostá většina jeho hardwarových, firmwarových i softwarových komponent jednak byla či bude využita v jiných projektech, ale tím hlavním jsou krušně nabyté zkušenosti, které pomohou vyvarovat se podobných chyb v budoucnu. Hlavní poučení vidíme ve dvou rovinách:

• Datový provoz na vysokorychlostních linkách současného Internetu představuje svým objemem i různorodostí opravdu velké sousto. Je proto nezbytné přísně dodržovat osvědčené inženýrské postupy při návrhu složitých systémů, především tedy princip "rozděl a panuj": rozumně oddělitelné funkce realizovat v samostatných subsystémech.
• Riziko spojené s originálním vývojem specializovaného hardwaru a firmwaru je možné účinně snížit důsledným uplatněním metody "hardwarově-softwarového kodesignu". Výchozím bodem je fungující softwarové řešení, jehož vhodně vybrané funkce se postupně v malých krocích převádějí do hardwaru. Důležité přitom je, aby výsledná kombinace v každé fázi a ve všech aspektech fungovala alespoň tak dobře nebo lépe než výchozí software.

Velké úsilí jsme také v průběhu celého roku 2006 věnovali přípravám na předání svých výzkumných a vývojových výsledků k dalšímu průmyslovému využití. Kvůli malým zkušenostem v této oblasti a také objektivním legislativním překážkám se bohužel zatím tento proces nepodařilo dovést do zdárného konce.

4.1   Řešitelský tým

Na výsledcích aktivity se v současné době podílí dva kmenoví zaměstnanci CESNETu, 26 externích zaměstnanců a několik desítek studentů VUT v Brně, Masarykovy univerzity a ČVUT v Praze. V tomto velkém a proměnlivém počtu studentů je řada nováčků, které je potřeba nejprve odborně připravit na zapojení do projektových týmů.

Zdrojové programy a dokumentace ke všem výsledkům aktivity se ukládají do úložiště CVS. To pak mimo jiné poskytuje zajímavé orientační indikátory aktivity jednotlivců i celého týmu. Obrázek ukazuje vývoj počtu programových řádků v CVS v průběhu roku 2006.

Výzkumné a vývojové aktivity jsme po dobrých zkušenostech z roku 2005 nadále řídili ve dvou liniích. První linií jsou tématicky orientované skupiny: VHDL, systémový software, formální verifikace+simulace a testování. Jejich úkolem je zajistit výměnu informací a zkušeností mezi specialisty, koordinovat účast členů skupin v projektech a připravovat nováčky.

Velký pokrok zaznamenala především skupina systémového softwaru, která se pod vedením Pavla Čeledy (MU Brno) rozšířila a zkonsolidovala. Vývoj softwaru nyní pokrývá široké spektrum od ovladačů do jádra Linuxu a NetBSD přes podpůrné vývojové nástroje a systémové knihovny až po aplikační programy. Kromě toho zajišťuje softwarová skupina přípravu distribučních balíků, které jsou spolu s kartami COMBO dodávány externím uživatelům.

Vzhledem k dlouhodobě neuspokojivé situaci v testovací skupině jsme koncem roku 2006 přikročili k výměně jejího vedoucího. Novým vedoucím se stal Jan Vykopal (MU Brno), který díky velmi aktivnímu náboru získal pro práci ve své skupině celkem 10 nových členů, vesměs studentů Masarykovy univerzity v Brně, kteří se zatím zapracovávají. Očekáváme, že testovací skupina i přes očekávaný částečný úbytek studentů pomůže především zlepšit kvalitu prototypů, které poskytujeme spolupracujícím institucím a projektovým partnerům.

Veškeré podpůrné činnosti, jako je správa hardwaru a softwaru, webové a poštovní servery, administrativní aplikace apod. má na starosti skupina systémové podpory.

Druhou linií řízení týmu jsou pak projekty, které mají přesněji stanovený harmonogram prací a očekávané výstupy. Projektové týmy se skládají podle potřeby a obvykle v nich mají zastoupení všechny vývojové skupiny. V průběhu roku 2006 jsme se věnovali následujícím pěti projektů:

1. NetCOPE - vývoj univerzální firmwarové platformy. Vedoucím projektu je Tomáš Martínek (VUT Brno).
2. FlowMon - vývoj sondy pro monitorování IP toků (NetFlow a IPFIX). Vedoucím projektu je Martin Žádník (VUT Brno). Tento projekt je spolufinancován mezinárodním projektem GN2.
3. IDS - vývoj sondy pro vyhledávání řetězců v datovém obsahu paketů, vedoucím projektu je Petr Kobierský (VUT Brno).
4. Liberouter - dokončení vývoje směrovače IPv6/IPv4. Vedoucím projektu je Jiří Tobola (VUT Brno).
5. NIFIC - vývoj síťové karty s hardwarovou filtrací paketů, tj. bezstavového firewallu. Vedoucím projektu je Jiří Tobola (VUT Brno).

Všem těmto projektům se budeme podrobněji věnovat v následujících oddílech.

4.2   Rodina karet COMBO

V roce 2006 se rodina karet COMBO rozšířila o další členy a u některých karet jsme podle získaných zkušeností upravili jejich návrh. Mezi nejvýznamnější změny patří:

1. Redesign karty COMBO6X spočívající především v úpravě komunikace FPGA s dynamickou pamětí. Úspěšně jsme otestovali paměti 256 MB, 512 MB a 1 GB a provedli komplexní testy všech komponent karty, které prokázaly správnou činnost všech subsystémů. Karta COMBO6X je tak v současné době plně funkční a mimo laboratorní použití probíhá i příprava nasazení do testovacího provozu na živé síti.
2. Probíhá postupné oživování karty COMBO6E, kde v současné době odlaďujeme její komunikaci se sběrnicí PCI-Express.
3. Karty rozhraní COMBO-4SFPRO jsou společně s kartami COMBO6X připraveny k nasazení do testovacího provozu v reálném provozu.
4. Návrh nové karty rozhraní 10GE - COMBO-2XFP4 - byl komplikován tím, že výrobce použitých FPGA Virtex-4 odvolal podporu funkčnosti 10GE u těchto obvodů v době, kdy jsme již měli hotové podrobné schéma karty. Proto jsme byli nuceni návrh změnit a použít standardní phytery firmy Vitesse. Karta COMBO-2XFP4 je v současné době ve stavu návrhu plošného spoje.
5. Dokončili jsme návrh architektury nové rodiny karet COMBO-v2 a vypracovali schéma prototypu základní karty. Realizaci této karty předpokládáme v roce 2007, kdy se očekává dostupnost nových FPGA obvodů rodiny Virtex-5, které obsahují PCI-Express endpoint. To nám umožní konstrukci karty, která nebude závislá na IP Core pro PCI-Express.

4.3   Architektura NetCOPE

Hlavní motivací pro vznik projektu NetCOPE (Network COMBO Pipe) bylo vytvoření infrastruktury uvnitř FPGA čipu, která by umožnila rychlý vývoj síťových aplikací. Tato obecná infrastruktura v sobě zahrnuje několik základních prvků a vlastností:

1. Vstupně/výstupní bloky pro příjem resp. odeslání paketů přes síťové rozhraní s podporou gigabitového nebo desetigigabitového Ethernetu.
2. Systém sběrnic na čipu s vysokou propustností pro rychlý přenos dat mezi mezi komponentami v FPGA a systémovou pamětí RAM.
3. Snadné připojení systému ke sběrnici typu PCI, PCI-X a PCI-Express.
4. Programovatelný DMA řadič s využitím vestavěného procesoru PowerPC pro řízení DMA operací mezi pamětí RAM a adaptérem. Programovatelnost je jednou z důležitých vlastností, neboť různé síťové aplikace požadují od DMA operací různé vlastnosti.
5. Jednotný a generický komunikační protokol FrameLink pro propojení interních komponent na čipu s ohledem na proudové zpracování dat.
6. Sada základních stavebních bloků ve formě IP Core pro analýzu nebo zpracování síťového provozu. Mezi příklady takovýchto komponent patří HFE procesor pro analýzu hlaviček paketů, Look-Up procesor pro klasifikaci paketů nebo OPE procesor pro editaci výstupních datových toků.

Blokové schéma infrastruktury platformy NetCOPE je znázorněno na obrázku. Navržená platforma zahrnuje všechny potřebné části a ze strany návrháře se tak stačí soustředit pouze na vývoj samotného aplikačního jádra. Mezi typické příklady aplikací patří: monitorovací adaptéry na bázi NetFlow, síťové adaptéry s filtrací, systémy pro detekcí nebezpečných toků apod.

Vývoj projektu začal počátkem června roku 2006. V průběhu několika měsíců jsme vytvořili detailní návrh sběrnicového systému pro platformu NetCOPE a implementovali jeho základní komponenty. V současné době probíhá ladění a testování systému na dvou základních aplikacích:

• NIC - síťová karta
• NIFIC - síťová karta s filtrací.

V následující části textu uvádíme stručný přehled nejdůležitější části platformy NetCOPE, kterou je interní systém sběrnic a koncept programovatelného DMA kontroléru. Podrobnější informace jsou pak uvedeny v technické zprávě [MT06].

4.3.1   Systém interních sběrnic a programovatelný DMA kontrolér

Platforma NetCOPE zahrnuje tři různé typy sběrnic, viz obrázek. Nejdůležitější z nich se nazývá interní sběrnice (Internal Bus) a slouží pro propojení komponent vyžadujících vysokou propustnost dat buď mezi sebou, nebo mezi FPGA adaptérem samotným a systémovou pamětí RAM. Typickými příklady komponent připojených k interní sběrnici jsou Software Receive/Transmit Buffer pro příjem/odeslání paketů síťovým rozhraním, DRAM kontrolér umístěný v FPGA čipu nebo procesor PowerPC zpracovávající náročné úlohy. Tato interní sběrnice je pak připojena k systémovému PCI rozhraní (PCI, PCI-X nebo PCI-Express) přes PCI Bridge.

Komponenty, které nevyžadují příliš velkou propustnost, jsou připojeny prostřednictvím tzv. lokální sběrnice (Local Bus). Tato sběrnice je zpravidla použita pro přenos malého množství dat jako jsou konfigurační data, programy pro mikrokontroléry nebo ladicí a stavové informace. Lokální sběrnice je na centrální interní sběrnici připojena prostřednictvím komponenty LB Bridge.

Posledním typem sběrnic je tzv. řídicí sběrnice (Control Bus), která je určena pro přenos dat mezi programovatelným DMA kontrolérem (PDMA) a komponentami, které potřebují odesílat nebo přijímat data do nebo ze systémové paměti RAM. PDMA je jednou z nejdůležitějších komponent, neboť řídí veškeré DMA operace mezi FPGA a softwarovým ovladačem. Poněvadž programovatelnost a rychlost DMA operací je jedním z nejdůležitějších požadavků na platformu NetCOPE, je jako hlavní prvek PDMA komponenty použit procesor PowerPC vestavěný uvnitř FPGA čipu.

Interní sběrnice (Internal Bus)

Interní sběrnice je sběrnicí s vysokou propustností. Je určena jednak pro přenos dat mezi jednotlivými komponentami v rámci FPGA, ale i pro přenosy dat mezi FPGA čipem a systémovou pamětí RAM. Jak je naznačeno na obrázku, interní sběrnice je založena na stromové struktuře. Její hlavní části proto tvoří komponenty s označením Root, Switch a Endpoint. Komponenta Root je součástí PCI Bridge, který zajišťuje komunikaci se systémovou sběrnicí PCI. Komponenty typu Switch směrují veškerou komunikaci v rámci interní sběrnice a jednotlivé Endpoint bloky pak připojují komponenty s požadavkem na vysokou propustnost dat. Typickými příklady takovýchto komponent jsou Software Receive/Transmit Buffer, interní DRAM kontrolér, Bridge mezi interní a lokální sběrnicí a potenciálně i některý z vestavěných procesorů PowerPC.

Linka interní sběrnice je široká 64 nebo 128 bitů (v závislosti na konfiguraci) a její pracovní frekvence je 125 MHz. Každá linka je plně duplexní, takže data mohou být přenášena oběma směry současně. Tato vlastnost je velice užitečná zejména pro oblast síťových aplikací. Tento systém je také jednoduše zapojitelný na novou generaci sběrnic PCI-Express. Stromová architektura umožňuje Endpointům komunikovat každý s každým a pokud oba uzly leží ve stejné větvi, nedochází k vytěžování ostatních linek interní sběrnice. Jak je naznačeno na obrázku, stromová architektura může být také překreslena do formy sběrnice, ve které jednotlivé Switch komponenty tvoří stupně ve smyslu zřetězení (pipelining). Tento druh zřetězení je velmi důležitý zejména pro technologii FPGA, kde vlivem omezených zdrojů pro propojování komponent jsou takto široké sběrnice velmi citlivé na vzdálenost.

Komunikační protokol na interní sběrnici je založen na posílání paketů. Podobně jako u sběrnice PCI-Express jsou i na interní sběrnici definovány transakce typu Read, Write a Completion. Jednou z hlavních výhod použitého komunikačního protokolu je i to, že v jeho základním módu je kompatibilní s protokoly FrameLink a Xilinx LocalLink. Díky této kompatibilitě lze do infrastruktury interní sběrnice snáze připojovat např. specializované IP Core komponenty, jakou je třeba Aurora od firmy Xilinx, která zajišťuje komunikaci multigigabitovými spoji RocketIO.

Lokální sběrnice (Local Bus)

Komponenty, které nevyžadují vysokou propustnost, jsou připojeny přes pomalejší lokální sběrnici, která má, podobně jako interní sběrnice, také stromovou strukturu, viz obrázek. Hlavní komponenty tedy opět tvoří prvky typu Root, Switch a Endpoint. Ve srovnání s interní sběrnicí je lokální sběrnice mnohem jednodušší. Veškeré čtecí nebo zápisové transakce mohou být iniciovány pouze komponentou Root. Komponenty Endpoint pracují v podřízeném režimu a prvky Switch pouze přeposílají transakce z upstream portů na downstream porty. Podobně jako u interní sběrnice, komponenty Switch pomáhají zřetězit komunikaci na sběrnici a redukovat tak její citlivost na vzdálenost.

Linka lokální sběrnice je 16 bitů široká a pracuje na frekvenci 125 MHz. I když je každá linka obousměrná, komunikace probíhá obvykle pouze jedním směrem (oboustrannost je nutná pro odstranění tzv. třístavových sběrnic). Komunikační protokol rozlišuje pouze základní typ čtecí a zápisové transakce a jeho hlavní předností je, že jej lze velmi jednoduše použít i pro komunikaci mezi více FPGA čipy bez potřeby speciálních komponent typu Bridge.

Řídicí sběrnice (Control Bus)

Řídicí sběrnice je v systému NetCOPE specializována na přenos řídicích informací mezi Programovatelným DMA kontrolérem (PDMA) a komponentami, které potřebují přenášet bloky dat mezi FPGA a systémovou RAM. Typicky ji využívají komponenty jako jsou Software Receive/Transmit Buffer, DRAM kontrolér, procesor PowerPC. Podobně jako interní a lokální má i řídicí sběrnice stromovou strukturu (viz obrázek). Komponenta Root je součástí PDMA kontroléru, komponenty Switch pouze přeposílají pakety mezi upstream a downstream porty a Endpointy připojují komponenty vyžadující DMA přenosy. Řídicí sběrnice je plně duplexní se šířkou 16 bitů pracující na 125 MHz synchronně s ostatními částmi sběrnicového systému NetCOPE. Komunikační protokol je kompatibilní s protokolem FrameLink s podmínkou, že komponenta Root může posílat pakety libovolnému Endpointu a libovolný Endpoint může poslat paket komponentě Root. Komunikace mezi Endpointy není povolena.

Jednou z nejdůležitějších komponent řídicí sběrnice je Root. Jak je naznačeno na obrázku, architektura Root je složena ze 16 přijímacích (RX) a vysílacích (TX) front, řídicích a stavových informací. Každý paket přicházející od Endpointu je zařazen do jedné z RX front na základě identifikace Endpointu. Podobně zápisem paketu do konkrétní TX fronty dojde k jeho odeslání příslušnému Endpointu. Všechny RX a TX fronty jsou realizovány uvnitř dvouportové paměti. První port je rezervován pro pakety přicházející z řídicí sběrnice a odesílané na ni. Druhý port je rezervován pro libovolnou uživatelskou komponentu. V našem případě je uživatelská komponenta tvořena PDMA kontrolérem. Stavové informace o začátcích a koncích jednotlivých front jsou uloženy ve stavových registrech. Posun těchto ukazatelů při čtení nebo zápisu je pak řízen prostřednictvím řídicích registrů.

Programovatelný DMA řadič

Hlavní úlohou Programovatelného DMA řadiče (PDMA) je řídit veškeré DMA operace mezi FPGA adaptérem a systémovou pamětí RAM. Typicky PDMA pracuje v následujících krocích:

1. načte scatter-gather seznamy (SG) z RAM do lokální paměti,
2. zpracuje všechny položky SG seznamu, kde každá položka reprezentuje DMA operaci,
3. modifikuje příslušné parametry SG seznamu,
4. na závěr přenese upravený SG seznam zpět do paměti RAM (a eventuálně vygeneruje přerušení).

Programovatelnost DMA řadiče je klíčovou vlastností, neboť každá aplikace běžící na platformě NetCOPE má jiné požadavky na DMA operace. Jak je ukázáno na obrázku, architektura PDMA je složena z procesoru PowerPC (PPC), komponenty Root řídicí sběrnice a lokálních pamětí pro program i data PPC procesoru. RX a TX fronty komponenty Root jsou mapovány do kešovatelného prostoru PPC procesoru. S využitím tohoto triku lze velmi rychle zpracovávat pakety z řídicí sběrnice uvnitř interní PPC keše.

Jak již bylo uvedeno v části o řídicí sběrnici, veškerá komunikace mezi PDMA a komponentou Endpoint řídicí sběrnice je založena na posílaní paketů (zpráv). Například při příchodu paketu do systému je PDMA odeslána zpráva o této události, PDMA přenese paket do paměti RAM a jakmile je přenos dokončen, zašle PDMA směrem k Endpointu potvrzovací zprávu. Předchozí implementace PDMA byla založena na jiném mechanismu, kdy si PPC procesor vyčítal informace přímo, bez zasílaní zpráv. Tento způsob však vykazoval velmi vysoké latence pro čtecí operace a nebyl tak vhodný pro vysokorychlostní síťové aplikace 10 Gb/s a výše.

4.3.2   Příklad aplikace na platformě NetCOPE

První aplikací pro platformu NetCOPE je síťová karta (Network Interface Card, NIC). Tento projekt nám pomůže ověřit výkon sběrnicového systému, odladit ovladače a otestovat základní moduly IP Core. Architektura této aplikace je velice jednoduchá a v podstatě jde o přenos paketů ze vstupních rozhraní do softwarového bufferu (SW_RXBUFFER) a z něj pak DMA přenosem do operačního systému hostitelského počítače. V opačném směru se jedná o přenos paketů z operačního systému do vysílacího softwarového bufferu (SW_TXBUFFER) a z něj dále na výstupní síťová rozhraní. Schéma této aplikace je na obrázku. K přenosu paketů mezi kartami používáme jednotky RocketIO, které jsou řízeny komponentou AURFC, řídící tok dat.

4.4   Sonda FlowMon

Projekt vývoje sondy pro sběr NetFlow statistik byl zahájen v roce 2004 v rámci aktivity JRA2 (Bezpečnost) projektu GN2. Cílem je samostatné monitorovací zařízení pro získávání informací o datových tocích IP ve vysokorychlostních sítích.

V říjnu 2005 jsme dokončili a úspěšně otestovali prototyp sondy pro analýzu datového provozu, založený na standardním PC s přidaným hardwarovým akcelerátorem COMBO6 s kartou rozhraní COMBO-4MTX.

Během roku 2006 jsme významně rozšířili funkce sondy a zároveň připravili přechod na novou hardwarovou platformu COMBO6X a kartu rozhraní COMBO-4SFPRO. Nová platforma má k dispozici více hardwarových zdrojů a umožňuje proto podstatně zvýšit výkon sondy. Dosáhli jsme toho několikanásobnou paralelizací datových cest a zvýšením pracovní frekvence na 100 MHz. Sondu jsme pojmenovali FlowMon a testujeme ji na živé síti v Praze a Brně.

Průmyslovým standardem pro výměnu statistických dat o tocích je protokol Cisco NetFlow, jehož nejnovější verze 9 je popsána v informativním RFC 3954 [Cla04]. Data NetFlow jsou obvykle generována směrovači. Použití autonomní sondy má proti tomuto tradičnímu uspořádání několik výhod:

• Část stávajících směrovačů nepodporuje sběr NetFlow dat.
• Hlavním úkolem směrovačů je směrování a předávání datagramů, jiné operace, zejména jsou-li náročné na výpočetní výkon, lze provádět jen ve velmi omezené míře. Samostatné zařízení je v tomto směru mnohem pružnější.
• Speciálním důsledkem předchozího bodu je statistické vzorkování provozu (sampling), které je u některých směrovačů povinné. Pro některé aplikace, zejména v oblasti bezpečnosti, je však vzorkování velmi nevhodné.
• Umožňuje experimentální implementace nově vyvíjených metod pro monitorovaní toků.

Další technické podrobnosti o sondě lze nalézt v technické zprávě [Zad06].

4.4.1   Hardware

Hardwarový akcelerátor pro sondu FlowMon je založen na kombinaci základní karty COMBO6X a dceřiné karty COMBO-4SFPRO poskytující čtyři rozhraní pro gigabitový Ethernet. Z hlediska síťové infrastruktury funguje sonda jako opakovač a splitter: Datový tok přicházející do portu 0 je bezprostředně vysílán portem 1 a kopírován na port 2. Zároveň se ještě kopie těchto dat předává firmwaru k analýze. Podobně je zpracováván vstupní tok přicházející do portu 1: data jsou opět ihned odesílána z portů 0 a 3 a jejich kopie je předána k analýze. Situaci blíže vystihuje obrázek.

4.4.2   Firmware

Firmware pro sondu FlowMon je napsán v jazyku VHDL a částečně vychází z předcházející verze pro kartu COMBO6. Jak již bylo uvedeno v úvodu, FlowMon umožňuje díky paralelnímu zpracování vstupních toků dosáhnout linkové rychlosti Gigabit Ethernet v plném duplexu, tedy analyzovat 2 Gb dat za sekundu. Podobně jako předchůdce je i FlowMon schopen současně zpracovávat datový provoz IPv4 i IPv6. Aktuální verze firmwaru je schopna v paměti uchovávat informace o 64 tisících toků. Na konci roku 2006 jsme testovali verzi využívající dynamickou paměť DDRAM, která umožňuje zpracovávat až 512 tisíc toků současně. V následujících odstavcích stručně popíšeme architekturu firmwaru sondy FlowMon.

Obrázek ukazuje blokové schéma firmwaru. Pakety přijaté ze dvou síťových portů do vstupních vyrovnávacích pamětí (Input Buffer, IBUF) jsou rovnoměrně distribuovány mezi analyzátory hlaviček (Header Field Extractor, HFE). Tyto jednotky analyzují hlavičky 2., 3. a 4. vrstvy, extrahují z nich všechna potřebná pole a uloží je do pevné datové struktury nazývané unifikovaná hlavička (UH). Jednotka UH driver (UHDRV) kruhově vyčítá UH záznamy, které se uloží do statistické fronty (STATFIFO). Paralelně s tím jsou určitá klíčová pole UH použita jako vstup rozptylovací funkce CRC-64, která je implementována jednotkou HASH. Z výsledných 64 bitů funkce CRC-64 používáme 64 bitů jako unikátní identifikátor toku. Klíčových polí je obvykle pět: zdrojová a cílová adresa IP, čísla zdrojového a cílového portu a číslo protokolu třetí vrstvy. Firmware lze konfigurovat tak, že se libovolná podmnožina bytů těchto pěti klíčových polí zamaskuje a jako vstup rozptylovací funkce se použijí pouze zbylé byty. Nově lze přidat jakékoliv pole UH jako další klíč toku (například značky MPLS).

Identifikátory toku jsou používány vyhledávací jednotkou (Hash Search Unit, HSRCH), která zjišťuje, zda je tento identifikátor již v paměti přítomen. Pokud ano, přečte se ukazatel na místo v paměti, kde se záznam nachází. V opačném případě se založí nová položka, do níž se uloží ukazatel na dynamicky alokované místo v paměti záznamů.

Řídicí jednotka (Manager Unit, MAN) spravuje seznamy identifikátorů toků a též udržuje seznam volných paměťových míst. Záznamy o tocích jsou uspořádány v obousměrném seznamu setříděném podle časové značky poslední změny záznamu. Neaktivní toky lze pak snadno rozpoznat, jakmile jejich stáří překročí stanovenou hranici (tzv. neaktivní časovač).

Konečně, úložná jednotka (Storage Unit, STO) provádí samotný sběr statistik o aktivních tocích. Neaktivní toky exportuje jako záznamy podle instrukcí obdržených od jednotky MAN.

Aktuální verze firmwaru podporuje nejnovější postupy zpracování toků. Z jednodušších je to například export toku na základě TCP příznaků či timeoutů. Dále je zahrnuta podpora standardního statistického vzorkování vstupního toku v jednotce IBUF.

Mezi pokročilejší techniky patří:

• adaptivní vzorkování vstupního provozu,
• sample-and-hold,
• dynamické nastavení neaktivního timeoutu založené na aktuálním využití paměti,
• výkonná anonymizace implementovaná ve firmwaru.

Adaptivní vzorkování je odpovědí na nedostatky pevně nastaveného vzorkování. V několika pracích na toto téma, např. [Est04], bylo ukázáno lepší využití výpočetních zdrojů, stejně tak predikovatelnost chování při útocích a jiných kritických situacích. Parametrem pro změnu vzorkovací frekvence mohou být různé ukazatele, například:

• počet příchozích paketů za sekundu,
• procentuální využití paměti,
• rychlost zaplňování paměti.

Ve firmwaru je funkce změny vzorkování implementována tabulkou, jež je adresována pomocí rozmezí parametrů. Vzorkovací frekvence i meze parametrů jsou vyplněny uživatelem, přičemž se doporučuje zachovat určitou hysterezi, aby změny neprobíhaly příliš často.

Další pokročilou technikou je experimentální vzorkovací procedura nazývaná sample-and-hold, která se od běžného statistického vzorkování liší tím, že vzorkování vstupních paketů je potlačeno u všech toků, které již existují v paměti. Tímto postupem lze získat velmi přesné informace o velkých tocích při malých paměťových nárocích. Dále pomáhá při útocích odfiltrovat velké množství malých toků, čímž zachovává schopnost sondy měřit i během útoku.

Dynamické nastavení neaktivního timeoutu umožňuje udržovat dostatek místa v paměti pro případ náhlého zvýšení počtu toků v síti. Firmware automaticky nastavuje neaktivní timeout podle předvyplněné tabulky na základě procentuálního využití paměti. Celkem má tabulka šestnáct řádků, každý postupně odpovídá zaplnění paměti 0 % až 6,24 %, 6,25 % až 12,49 %, atd.

Anonymizace IP adres přímo ve firmwaru snižuje zatížení procesoru v PC. Dále poskytuje další stupeň ochrany, neboť originální IP adresy se již vůbec nepřenášejí přes sběrnici a nevyskytují se v paměti. Implementovaná firmwarová anonymizace má propustnost 5 milionů paketů za sekundu a je založena na rozptylovací funkci.

Činnost firmwaru závisí na hodnotách několika numerických parametrů, které lze měnit i za běhu:

• vypršení aktivních toků (active timeout) v rozmezí 0-1200 sekund,
• vypršení neaktivních toků (inactive timeout) v rozmezí 0-60 sekund,
• vzorkovací frekvence v rozmezí od 1 do 2³²-1,
• vzorkovací frekvence pro sample-and-hold v rozmezí od 1 do 2³²-1,
• práh pro sample-and-hold - vzorkování nezačne dříve než počet toků v paměti dosáhne této hodnoty.

4.4.3   Softwarový ovladač akcelerátoru

Ovladač hardwarového akcelerátoru FlowMon je k dispozici pro Linux 2.4 a 2.6 s podporou i pro symetrický multiprocesing. Umožňuje současný přístup několika aplikací k záznamům o tocích: Vyhrazený blok sdílené paměti se používá pro uložení až 16 384 záznamů v logické struktuře kruhové vyrovnávací paměti. Jakmile se kruh zaplní, jsou nejstarší záznamy přepisovány novými. Každá aplikace si přitom udržuje vlastní ukazatel do této vyrovnávací paměti a navíc může uzamknout až 1024 položek - pokud například není hotova s jejich čtením - a zabrání tak jejich přepsání.

Aplikace mohou k ovladači přistupovat výhradně prostřednictvím speciální nízkoúrovňové knihovny libcsflow.

4.4.4   Konfigurační démon

Implementovali jsme systémový program (démon), který slouží k ovládání a konfiguraci sondy FlowMon. Jeho prostřednictvím lze nahrát firmware do karty, inicializovat jej a nastavit, dále spouštět a řídit programy pro export dat ze sondy. Tento démon se spouští ihned po startu systému, kdy provádí procedury potřebné pro spuštění sondy. Dále pak běží v pozadí a čeká na uživatelovy požadavky.

V současné době se dokončuje první verze WWW rozhraní. Jeho prostřednictvím bude možné démonu předávat požadavky na změnu konfigurace sondy. Tímto způsobem bude možné sondu FlowMon snadno a rychle spustit nebo přenastavit bez větších technických znalostí. Uživatel si na přehledném webovém rozhraní určí nastavení jednotlivých vlastností sondy. Po odeslání požadavku se vygeneruje konfigurační soubor ve formátu XML, který popisuje nově požadovanou konfiguraci. Konfigurační démon tento soubor načte a změní podle něj nastavení firmwaru nebo programů pro export dat.

4.4.5   Program pro export dat

Nejpoužívanějšími formáty pro export dat o IP tocích jsou protokoly NetFlow verze 5 a verze 9. Implementovali jsme oba dva a vyzkoušeli je v kombinaci s několika různými kolektory. V některých případech jsme narazili na nedostatky v implementaci kolektorů, což se týká zejména NetFlow v9. Některé kolektory například ignorují pole udávající frekvenci vzorkování, takže uživatel je pak nucen výsledná data dodatečně renormalizovat.

Na rozdíl od NetFlow v5 je formát NetFlow v9 pružný v tom, že umožňuje prakticky libovolně stanovit obsah odesílaných záznamů o tocích. Použitá uspořádání dat jsou kolektoru sdělena pomocí takzvaných předloh (templates). Náš exportér podporuje šest předloh pro všechny možné kombinace IPv4 a IPv6 na jedné straně a transportních protokolů TCP, UDP a ICMP na straně druhé. Další dvě předlohy (IPv4/OTHER a IPv6/OTHER) jsou používány pro ostatní protokoly třetí vrstvy.

Bez znalosti příslušné předlohy nemůže kolektor data interpretovat, a proto je důležité všechny používané předlohy kolektoru v pravidelných intervalech posílat. Prostřednictvím řádkového parametru je možné nastavit periodu jejich posílání.

U obou protokolů, NetFlow v5 i v9, probíhá export pomocí UDP protokolu, který ovšem nezaručuje spolehlivé doručení. Tento problém řeší až organizací IETF nově standardizovaný protokol IPFIX, jehož podpora je naplánována na léto roku 2007. Protokol IPFIX by se měl stát celosvětově využívaným protokolem pro export dat o tocích a postupně tak převzít roli NetFlow.

Sdílený přístup k tokům, který byl popsán v oddílu o ovladači, umožňuje spustit více exportérů na jedné sondě. Každý exportér přitom může být individuálně zkonfigurován tak, aby filtroval a anonymizoval záznamy. Uživatel má tedy možnost vybírat a modifikovat data podle cílového kolektoru. V exportérech je zabudována filtrace na základě rozsahu IP adres. Po filtraci se uplatní softwarová anonymizace. Existuje několik typů anonymizace, z nichž používáme šifrovací metodu AES, či metodu substituce části IP adresy za lokální typ adresy a části za náhodné číslo.

4.4.6   Testy

V listopadu a prosinci 2006 jsme realizovali úspěšné testy nové verze sondy FlowMon, a to jak v laboratorním prostředí, tak i v produkční síti. Při těchto testech jsme odhalili několik chyb, které se podařilo v krátké době lokalizovat a opravit. Další nezávislé testy - ovšem zatím jen staršího prototypu sondy - realizovali naši partneři v projektu GN2.

Propustnost firmwaru jsme testovali pomocí síťového analyzátoru Spirent AX/4000. Výsledky ukazují, že současná verze je schopna zpracovat datový tok 2 Gb/s bez ohledu na velikost paketů.

Na zvýšení propustnosti oproti původní prototypové verzi se významně podílí jednak nová implementace vstupních bufferů a dále pak optimalizovaná implementace analyzátoru hlaviček (HFE) založená na nově vyvinutém nanoprocesorovém jádru GENA (Generic Nanoprocessor). Aktuální propustnost je omezena na zhruba 3 miliony paketů za sekundu.

Sondu jsme rovněž testovali v reálném provozu páteřní sítě CESNET2. Připojili jsme ji na rozhraní přístupového směrovače v brněnském uzlu, do nějž byl zrcadlen veškerý provoz přicházející do metropolitní sítě BAPS. Data generovaná sondou byla zpracovávána kolektorovými systémy NFSen (NetFlow Sensor) a FTAS (Flow Traffic Analysis). Obrázek získaný z kolektoru NFSen ukazuje graf rozložení počtu paketů během dvou dnů, jak byly naměřeny sondou FlowMon.

4.4.7   Výhled do budoucnosti

Sonda FlowMon spolu s programy FTAS a NetFlow Monitor, vyvinutými rovněž sdružením CESNET v rámci výzkumného záměru, poskytuje již v současné době vcelku komplexní a použitelný systém, který může být užitečný pro řadu aplikací nejen v oblasti bezpečnostní analýzy provozu, ale též sledování kvality služby, účtování přenesených dat či plánování kapacity sítě.

Plány pro nejbližší období (do června 2007) zahrnují především rozšíření funkcí firmwaru a softwaru. Například vývoj inteligentního softwaru, který bude schopen na základě měření statistik provozu nastavit adaptivní vzorkování či neaktivní timeouty. Dále počítáme s implementací protokolu IPFIX [Qui04] a s tím souvisejícího rozšíření záznamu udržovaného ve firmwaru.

Základním prostředkem konfigurace sondy by se mělo zároveň s možností nastavení parametrů přes WWW stát textové uživatelské rozhraní.

Během roku 2007 plánujeme převedení firmwaru FlowMon na komunikační platformu NetCOPE, viz část 4.3. Tento strategický krok nám zaručí nezávislost na konkrétním hardwaru a FlowMon tak bude kompatibilní se všemi hardwarovými platformami, které bude NetCOPE v budoucnu podporovat. To je výhodné z hlediska vývoje nových karet pro 10 Gb/s a dalších. Na začátku roku 2007 bude firmware FlowMon připraven monitorovat až 512 tisíc toků současně a bude tak schopen monitorovat velmi zatížené linky, například 10 Gb/s, se vzorkováním na vstupu 1:5.

V delší časové perspektivě sledujeme především výzkumně orientované směry, jako je plná podpora protokolu IPFIX [Qui04] a automatická regulace konfiguračních parametrů sondy.

4.5   Sonda IDS

Projekt vývoje sondy pro detekci nebezpečného síťového provozu (Intrusion Detection System) začal v druhé polovině roku 2005. Cílem tohoto projektu je nalezení vhodné architektury pro využití FPGA v IDS, který by byl schopen monitorovat gigabitové sítě. V první fázi se tento projekt zaměřil na akceleraci již existujících programů, které dosahují propustností pouze v řádu stovek Mb/s. Tato řešení IDS, jejichž hlavním reprezentantem je program Snort, jsme akcelerovali předběžnou filtrací síťového provozu v hardwaru. Normální síťový provoz je v hardwaru zahozen a pouze potenciálně nebezpečný provoz je předán k dalšímu zpracování. Tento koncept se ukázal jako správný a dosáhli jsme jím velmi zajímavých výsledků, které jsou popsány společně s architekturou celého systému v následujících odstavcích.

4.5.1   Systémová architektura

Vrstvový model navržené architektury je zachycen na obrázku. Na nejnižší úrovni je karta COMBO6X osazena hradlovým polem Virtex-II Pro. Karta zpracovává příchozí pakety na gigabitových rychlostech. Jejím účelem je oddělit normální síťový provoz od potenciálně nebezpečného, který je ze sondy předáván vyšší vrstvě, tj. IDS ovladači. Ten zpřístupňuje hardware sondy operačnímu systému jako síťovou kartu. To znamená, že nad touto kartou lze spustit například tcpdump nebo Snort. Snort pak nemusí zpracovávat veškerý síťový provoz, ale pouze jeho potenciálně nebezpečnou část, což už zvládne i běžný procesoru bez problémů s propustností.

Hardwarový akcelerátor IDS (dále jen Traffic Scanner) může být do síťové infrastruktury zapojen dvěma způsoby. Jednak může monitorovat až čtyři GE porty (např. zrcadlené z přepínačů) nebo může být zapojen přímo v lince. V tomto druhém zapojení sonda funguje jako T-splitter a je schopna monitorovat provoz na lince v obou směrech. Obě možnosti zapojení jsou znázorněny na obrázku.

4.5.2   Firmware

Firmware sondy Traffic Scanner se skládá z jednotky pro klasifikaci paketů, jednotky pro vyhledávání vzorů a několika dalších komponent. Blokové schéma architektury je znázorněno na obrázku. Pakety jsou přijímány ze čtyř vstupních rozhraní do vstupních bufferů (IBUF). Pomocí jednotek HFE (Header Field Extractor) jsou položky v hlavičkách paketů (zdrojová a cílová adresa, porty, protokol atd.) převedeny na unifikovanou hlavičku (UH), která je pak předána klasifikační jednotce. Celý paket je uložen do výstupního bufferu (SWOBUF), kde čeká na výsledek analýzy. Klasifikační jednotka porovná UH s pravidly IDS systému a jednotka pro vyhledávání řetězců (PTRN_MATCH) vyhledá vzory vyskytující se v datovém obsahu paketu. Pravidla nalezená klasifikační jednotkou se porovnají s výsledkem vyhledávací jednotky. Pokud přijatý paket odpovídá alespoň jednomu IDS pravidlu, je paket exportován do softwaru, v opačném případě je zahozen.

Klasifikační jednotka

Při návrhu klasifikační jednotky jsme vycházeli z již publikovaných přístupů, které jsme modifikovali tak, aby podporovaly veškeré vlastnosti systému Snort se zachováním propustnosti až pro 10Gb sítě na krátkých paketech. Pro klasifikaci jsme zvolili několik metod, z nichž každá je vhodná pro klasifikaci jiných částí hlavičky. Pro klasifikaci IP adres a typu protokolu jsme zvolili CAM paměť. Pro klasifikaci portů, kde se vyskytuje řada rozsahových položek, jsme použili přístup převedení rozsahu do prefixové reprezentace a následné mapování do FPGA. Na základě zjištěných charakteristik četnosti klíčových slov v IDS pravidlech je klasifikace na základě zbylých položek hlavičky TCP/IP řešena použitím komparátorů.

Blok pro vyhledávání vzorů

Jádrem navržené architektury je jednotka pro vyhledávání vzorů. Obsah jednotky je generován ze zadané množiny řetězců. Při převodu jsou nejprve řetězce a regulární výrazy převedeny na nedeterministický konečný automat (NFA), který lze dále transformovat do ekvivalentní hardwarové reprezentace zachycené na obrázku. Pokud je použit NFA, který přijímá 8 bitů (1 znak) v jednom hodinovém cyklu a systémová frekvence je 100 MHz, je design schopen dosáhnout propustnosti jen 800 Mb/s. Propustnost však lze zvýšit převodem NFA na rozšířený automat (ENFA), který přijímá více znaků v jednom hodinovém cyklu. Tím lze podle velikosti hledané množiny řetězců dosáhnout propustnosti až 10 Gb/s. Větších propustností nelze s tímto přístupem dosáhnout vzhledem k nedostatečné kapacitě dostupných FPGA a problémům s omezenou kapacitou propojovací matice. V budoucnosti je proto nutné se soustředit na nalezení vhodného kódování stavů a rozdělení NFA na několik nezávislých části.

4.5.3   Webové rozhraní pro překlad firmwaru

Díky použití softwarového generátoru pro vyhledávací jednotku je možné do FPGA uložit velké množství pravidel. Pokud však uživatel chce sadu IDS pravidel změnit, nemůže to udělat okamžitě. Nejprve se musí vygenerovat nový program VHDL pro zadaná pravidla a pak spustit proces syntézy, jehož výsledkem je nový konfigurační soubor pro FPGA. Jelikož běžní uživatelé nemají k dispozici nástroje pro syntézu VHDL, vytvořili jsme jednoduché webové rozhraní, které tento krok zprostředkuje. Uživatel pouze na určený server uloží soubor s pravidly IDS, zadá e-mailovou adresu a pak již čeká na odpověď, ve které dostane odkaz na nový firmware. Ten si stáhne a zavede do FPGA, čímž je sonda připravena k analýze provozu podle nových pravidel IDS. Ukázku webového rozhraní najdete na obrázku.

4.5.4   Dosažené výsledky

Díky vyhledávání řetězců pomocí ENFA je možné převést veškerá pravidla z výchozí instalace programu Snort do FPGA a zároveň dosáhnout teoretické propustnosti 3,2 Gb/s. Skutečnou propustnost sondy Traffic Scanner jsme měřili zařízením Spirent AX/4000. Při testu byla sonda schopna zpracovávat provoz 2 Gb/s pro všechny délky paketů. Podotkněme, že výsledná propustnost nezávisí na počtu pravidel, což například neplatí u softwarových IDS, kde propustnost s rostoucím počtem pravidel rychle klesá.

Dále jsme porovnali rozdíly mezi Snortem akcelerovaným naší sondou a klasickým softwarovým Snortem. Test běžel 24 hodin na živé síti a obě sestavy byly nakonfigurovány pro vyhledávání virů. Počet poplachů a jejich typ se shodoval u obou řešení, avšak na Snort s předřazenou hardwarovou filtrací zbývalo v průměru jen 0,02 % paketů z veškerého síťového provozu. Zbylé pakety byly předem odfiltrovány kartou COMBO6X. Dosažené výsledky ukazují, že naše řešení výrazně zvyšuje propustnost IDS systému Snort, který díky tomu může být efektivně použit pro monitorování gigabitových sítí.

4.5.5   Shrnutí

I přes slibné výsledky je nutné pokračovat v dalším výzkumu a hledat řešení, které umožní monitorovat datové toky 10 Gb/s. Velkým problémem přístupu na bázi NFA je kódování stavu one-hot, kdy jednomu stavu odpovídá jeden klopný obvod. Tento přístup přináší omezení na množství stavů NFA, které je dané počtem registrů v FPGA a má také za následek zvýšené požadavky na rychlost a kapacitu propojovací sítě. Při použití tohoto kódování jsou rovněž problémy s přesunem vektoru nalezených řetězců do softwaru a s případným použitím tohoto přístupu pro realizaci IDS, který hledá vzory nejen v samotných paketech, ale i v TCP tocích. Tyto problémy se dají řešit vhodným rozdělením ENFA na několik částí a použitím kompaktnějšího kódování stavů, což bude předmětem dalšího výzkumu.

4.6   Směrovač Liberouter

Cílem projektu Liberouter je multigigabitový směrovač pro IPv6 a IPv4 založený na platformě PC a přídavné akcelerační kartě COMBO, která umožní rozložit zátěž při směrování mezi hardware a software podle myšlenky hardwarově-softwarového kodesignu. V minulém roce jsme prezentovali první funkčně omezený prototyp směrovače, v letošním roce se nám pak vývoj firmwaru podařilo kompletně dokončit.

4.6.1   Firmware

V první polovině roku 2006 jsme se soustředili na přechod z behaviorálních simulací firmwaru na testování v hardwaru a přechod na novou platformu karet COMBO6X a SFPRO. Souběžně s tímto testováním pak probíhal vývoj zbývajících jednotek, jež zatím nebyly implementovány ve finální verzi se všemi požadovanými funkcemi. Konkrétně se jednalo o systém prioritních front (Priority Queues, PQ), výstupní paketový editor (Output Packet Editor, OPE) a řadič dynamické paměti (SDRAM_CTRL).

Všechny tyto jednotky se podařilo úspěšně do poloviny roku implementovat a postupně byly začleňovány do architektury směrovače. V říjnu tohoto roku jsme odladili propojení všech komponent a jejich vzájemnou komunikaci, otestovali jejich funkčnost a počátkem listopadu jsme dokončili a prezentovali finální verzi firmwaru směrovače.

Architektura směrovače odpovídá původnímu návrhu, který je popsán v předchozích výročních zprávách či na webových stránkách projektu, a je zobrazena na obrázku. Doplněním posledních tří komponent je zkompletován celý řetězec pro realizaci směrování:

• IBUF - vstupní síťové rozhraní pro příjem paketů a kontrolu CRC,
• HFE - procesor pro extrakci dat z hlaviček paketů,
• DRAM - dočasné úložiště paketů v dynamické paměti,
• LUP - klasifikační procesor řídící hardwarové směrování,
• REP - komponenta pro replikaci paketů, realizace multicastu,
• PQ - prioritní fronty zajišťující QoS,
• OPE - procesor pro modifikaci hlaviček paketů (TTL, MAC),
• OBUF - výstupní síťový blok.

Vývoj firmwaru čtyřportového směrovače IPv4 a IPv6 byl dokončením prvního plně funkčního prototypu ukončen. Firmware prototypu je dostupný pro základní kartu COMBO6X a kartu síťového rozhraní SFPRO. V příštím roce předpokládáme pouze údržbu projektu a opravování nalezených chyb. Případný další vývoj by byl zřejmě zaměřen na zvládnutí vyšších propustností (10GE) a studii jiných přístupů pro klasifikaci a směrování paketů.

4.6.2   Software

Softwarovou podporu směrovače jsme rozšířili o nástroje pro konfiguraci a testování nově integrovaných hardwarových komponent. Tím byla sada těchto řídicích nástrojů zkompletována a nyní umožňuje veškeré nastavení směrovače. Všechny programy této sady mají jednotné ovládací rozhraní a jsou založeny na nízkoúrovňové knihovně libcombo, která realizuje vlastní komunikaci s kartou.

Akcelerační démon, jehož architektura a princip fungování byly popsány v loňské zprávě, prošel jen mírnými úpravami zejména v části generující transformaci směrovacích pravidel do programu klasifikačního procesoru. V souvislosti s reimplementací tohoto procesoru dále plánujeme v příštím roce využít obecného rozhraní OpenBSD Packet Filter pro jeho snazší konfiguraci.

4.7   Projekt NIFIC

Cílem projektu NIFIC je vyvinout síťovou kartu s hardwarovou filtrací a hardwarovým přeposíláním paketů umožňující zpracovávat síťové toky na plné rychlosti bez ztráty paketů. Typickým využitím této karty je hardwarový firewall. Další možná použití jsou například inteligentní a na rychlosti linky fungující rozdělovač toků, nástroj pro sledování vybraných síťových toků, replikátor toků atp.

V loňském roce byl již k dispozici firmware pro kartu COMBO6. Ten byl limitován pracovní frekvencí procesoru pro extrakci dat z hlaviček paketů (Header Field Extractor, HFE) a použitým konektorem PCI 32/33. Obě omezení se podařilo tento rok odstranit. HFE bylo přepracováno a jeho pracovní frekvenci se nám podařilo zvýšit na dvojnásobek (100 MHz), omezení systémovou sběrnicí jsme odstranili přechodem na platformu COMBO6X a COMBO-4SFPRO. Přechod na tuto novou platformu dále přinesl možnost využít procesor PowerPC vestavěný v hradlovém poli pro řízení systémové sběrnice, což nám společně s implementací sběrnice PCI 64/66 umožnilo dosáhnout při přenosu přes tuto sběrnici propustnost vyšší než 1 Gb/s.

Stejně jako HFE prošla redesignem i druhá klíčová komponenta návrhu - klasifikační procesor (Look-up processor, LUP). Cílem úpravy návrhu bylo zvýšení pracovní frekvence taktéž na 100 MHz a rozšíření instrukční sady tohoto procesoru. Novou verzi v současnosti právě intenzivně testujeme v hardwaru a počítáme s jejím začleněním do příštího oficiálního balíčku NIFIC.

V souvislosti s novou implementací klasifikačního procesoru také pracujeme na aktualizaci softwarové podpory pro tento procesor. Zatímco v předchozí verzi se pro nastavení konfiguračních pravidel (filtrační pravidla a nastavení přeposílání paketů) používal náš vlastní formát souboru a nastavení bylo do jisté míry omezeno, v nové verzi používáme obecný OpenBSD Packet Filter formát. Filtr v tomto jazyce je nejprve převeden do interní podoby jazyka mezivrstvy a z této je následně transformován na program klasifikačního procesoru. Hlavním přínosem této změny pro uživatele je použití dobře známého a ověřeného jazyka pro popis paketových filtrů. Zavedení jazyka mezivrstvy dále umožňuje jednoduše přidávat další frontendy pro konfiguraci filtru (např. iptables) nebo změnit princip klasifikace paketů v hardwaru přepsáním pouze jedné transformační vrstvy.

Významnou změnou prošel tento rok také balíček pro externí uživatele. První verze vydaná v minulém roce byla distribuována našim zahraničním partnerům a na základě připomínek jsme ji upravili tak, aby byl proces instalace i použití karty co možná nejjednodušší a nejsrozumitelnější. Součástí tohoto nového balíčku je již také nový firmware pro COMBO6X a SFPRO.

V příštím roce plánujeme využít pro projekt NIFIC síťovou platformu NetCOPE a implementovat NIFIC jako jednu z jejích aplikací. Výhodou tohoto řešení bude dosažení maximálních propustností při přenosu paketů po systémové sběrnici, sjednocení protokolu pro komunikaci mezi komponentami s možností využití předpřipravených komponent pro spojování a rozdělování toků paketů, a konečně menší přímá závislost na hardwaru díky použití modulů IP Core s jednotným rozhraním pro ovládání (paměťové řadiče, vstupní a výstupní síťové bloky).

předchozí

obsah

následující