OpenFlow s otazníky

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

Autor:

Komentáře (3)

  1. ZP říká:

    „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.

  2. Ladislav Lhotka říká:

    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

Zanechte komentář

Všechny údaje jsou povinné. E-mail nebude zobrazen.

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..