Abych řekl pravdu, dosud jsem si myslel, že OpenFlow je záležitost povýtce akademická a nemá valného praktického významu. Přispěla k tomu jistě i prezentace „Software Defined Networking“ na IETF 82, která ve mně i řadě dalších posluchačů zanechala dojem ryzího slidewaru.
Krátká přednáška Todda Underwooda (Google) na nedávném RIPE 64 mě ale přivedla k úvahám, zda bych neměl svůj postoj k OpenFlow a SDN přehodnotit. Google totiž používá OpenFlow switche ve dvou svých produkčních páteřních sítích, které propojují lokality na třech kontinentech. OpenFlow jim umožňuje pojímat tyto sítě jako systém pro transport dat a ne pouze jako soubor jednotlivých switchů a linek.
OpenFlow je postaven na myšlence oddělení forwardovací logiky (data plane) od směrovacích, filtrovacích a jiných algoritmů (control plane). Zatímco data plane zůstává „zadrátovaná“ ve switchi, control plane se přesouvá na samostatný počítač (controller), který může řídit jeden nebo více switchů. Jádrem OpenFlow je protokol a API umožňující kontroléru konfigurovat zacházení s pakety ve switchi.
OpenFlow předpokládá, že data plane je ve switchi implementována ve formě tabulky toků s využitím hardwarové asociativní paměti (TCAM). V tom ovšem vidím jistý problém: špičkové TCAM čipy mají kapacitu jednotek až desítek tisíc položek, takže se do nich rozhodně nevejde kompletní směrovací tabulka BGP. Mohli bychom sice zvolit alternativní strategii – plnit tabulku na základě toků, které switch skutečně přenáší – ale ani s tou se moc daleko nedostaneme, protože typické počty aktivních toků v páteřních internetových směrovačích kapacitu TCAM rovněž vysoko překračují. Zdá se tedy, že kombinace OpenFlow switche a směrovacího démona není v roli obecného BGP routeru příliš použitelná.
Myslím si ale, že i tak bychom se v Laboratořích CZ.NIC mohli OpenFlow trochu podívat na zoubek. Minimálně by stálo za to demonstrovat, že OpenFlow switch může fungovat i s BIRDem v pozici kontroléru (Google používá Quaggu). Je docela možné, že takový hardwarově akcelerovaný směrovač by se mohl v některých situacích dobře uplatnit.
Za pozornost stojí také standard OF-CONFIG 1.0, který se zabývá konfigurací a správou „provozního kontextu“ OpenFlow switche, tedy de facto všeho kromě tabulky toků. Standard pro tento účel používá protokol NETCONF a datové modely zapsané v jazyku YANG. Jde zřejmě o dosud největší otevřeně dostupnou aplikaci technologií NETCONF/YANG.
Ladislav Lhotka
„TCAM chipy“ resp. interface kontrolery samozrejme maji kapacitu dostatecnou na plne smerovaci tabulky, jinak by nam ten internet uz asi davno nefungoval :-)
dukaz misto slibu:
L3 Forwarding Resources
Module FIB TCAM usage: Total Used %Used
5 72 bits (IPv4, MPLS, EoM) 524288 407995 78%
144 bits (IP mcast, IPv6) 262144 9186 4%
L3 Forwarding Resources
Module FIB TCAM usage: Total Used %Used
6 72 bits (IPv4, MPLS, EoM) 524288 407995 78%
144 bits (IP mcast, IPv6) 262144 9186 4%
a to neni „spickovy chip“, to je stary chip z roku 2006 z 6500/7600, coz je uz dost zastarala (byt stale dostacujici) krabice. Vsechny ostatni modernejsi platformy (ASR9k, Juniper MX, Brocade MLXe apod.) to pochopitelne zvladaji take a jeste o poznani lepe.
Díky za komentář.
Já samozřejmě netvrdím, že HW data plane ve velkých routerech nepojme tabulku BGP, nejsem si ale jist, jestli ji opravdu drží celou v TCAM paměti jako takové. Spíš si myslím, že to bude kombinované s vyhledávacími algoritmy pro IP prefixy implementovanými v HW (trie lookup), tj. že emuluje asociativní paměť pro speciální případ vyhledávání nejdelšího prefixu.
Jeden dostupný OpenFlow switch HP má počet řádků ve flow table omezen na 10000.
Láďa