Google test OpenFlow-protocol op eigen netwerk

Google is begonnen met het testen van het OpenFlow-netwerkprotocol op de verbindingen tussen datacentra. Het protocol is bedoeld om servers direct switches aan te laten sturen waardoor netwerkconfiguratie vereenvoudigd kan worden.

Traditioneel bepaalt onder andere de routeringstabel in veelal propriëtaire firmware die verwerkt is in switches en routers de weg die datapakketjes moeten afleggen. Switches die het OpenFlow-protocol ondersteunen laten de high-level-routering echter door andere systemen aansturen. Dat kunnen servers zijn, maar ook andere netwerkapparatuur.

Steeds meer hardwarefabrikanten, waaronder Juniper, Cisco, IBM en HP, ondersteunen het netwerkprotocol in hun switches en routers. OpenFlow zou dan ook met name geschikt zijn voor cloudcomputing-platformen die gebruikmaken van verschillende datacentra, maar het protocol zou ook nuttig zijn voor extra beveiligde datanetwerken.

In een interview met GigaOM laat Google weten geïnteresseerd te zijn in het toepassen van OpenFlow. Volgens Google kan OpenFlow mogelijk meer 'intelligentie' in het netwerk brengen doordat het ip-verkeer via algoritmen voor bepaalde taken geoptimaliseerd kan worden. Zo zouden netwerken efficiënter en dus goedkoper benut kunnen worden, omdat netwerkbeheer minder complex zou zijn. Bovendien kunnen de softwarematige OpenFlow-controllers op conventionele hardware draaien.

De zoekgigant is inmiddels begonnen met het testen van het netwerkprotocol op directe dataverbindingen tussen diverse datacentra. Hoeveel datacentra bij de proef betrokken zijn, wil de zoekreus niet kwijt. Google wil bovendien nog niet te vroeg juichen; zo zouden er nog problemen zijn om het testnetwerk goed te laten communiceren met netwerken die nog niet met OpenFlow werken, maar juist 'traditionele' protocollen als bgp of mpls gebruiken. Google hoopt dat met het verder volwassen worden van het nog jonge protocol dergelijke problemen zullen verdwijnen.

Reacties (31)

[Verwijderd]

Stel er is verandering in je netwerk. Links up en down. Hoe gaat die centrale server praten met alle elementen in het netwerk ? Alleen als iedere router in het netwerk de weg kent.

Dus een IGP draait. Ik zie niet hoe je SDN (Software Defined Networking)/OpenFlow gaat laten werken zonder dat iedere router nog steeds de weg leert via IGPs. Dat is dus een stuk complexiteit die niet gaat verdwijnen op iedere router.

Je kunt wel natuurlijk je traffic engineering doen met SDN/OFlow. Maar dat vervangt niet je ouderwetste IGP. Dus meer complexiteit, niet minder.

Een aantal ISPs wil Quagga (een open-source routing protocol stack, met BGP, IS-IS, OSPF, etc) gebruiken in combinatie met SDN/OpenFlow. Maar Quagga is niet bepaald robust, scalable noch feature-rijk. Daar moet nog een hoop aan gebeuren. Ik vertel dit omdat, 1) hieruit blijkt dat SDN/OpenFlow niet de oude routing protocollen gaat vervangen, en 2) het nog een tijdje gaat duren voordat je alle proprietary software boven de pure forwarding hebt vervangen.

Je Opex wordt lager door dat je geen retraining cost

Ik hoop het voor je. Ikzelf denk dat de ISPs dit onderschatten. Ik denk dat SDN opeens een hoop meer gaat eisen van de network-engineers. De finesses van hoe een IGP te bouwen, hoe je IGP stabiel te krijgen, hoe snelle convergence te krijgen, dat is allemaal techniek uit de jaren negentig. Geen hond die zich nog kan herinneren hoe dat moest. De oude generatie werkt allemaal voor cisco en Juniper, is met (vervroegd) pensioen. En de nieuwe garde heeft zich er nooit mee bezig hoeven houden. Dus de nieuwe garde zal het opnieuw moeten leren. Misschien ben ik te pessimistisch, maar ik denk dat het een tijdje gaat duren voordat de kennis er is bij ISPs om SDN goed te gebruiken.
Tenzij ISPs hun zelf-geschreven software gaan delen met hun concurrenten. Maar dat zie ik niet zo gauw gaan gebeuren.

[Nickvda]

True, alhoewel ik er zeker van ben dat dit niet voor de gehele nieuwe garde telt. Er zal heus wel een flink aantal zijn die weten hoe het moet.

[Belboer]

OpenFlow is er nog lang niet en wat ik eerder zei is het gewenste eindplaatje. En daar zie ik dus wel een hoop voordelen in. Een IGP is echt niet noodzakelijk. Met behulp van het OpenFlow discovery protocol kan je de topologie in kaart brengen en vervolgens OpenFlow zelf de flows voor het control plane opzetten. Of een out of band control plane opzetten.

Overigens kan je nog geen native OpenFlow switches kopen. De switches die OpenFlow ondersteunen zijn nog hybride. Een bedrijf als Google laat gewoon hun eigen switches door chinezen bouwen waar zij dan een OpenFlow interface voor schrijven. Dat is het voordeel als je de grootste datacenter boer ter wereld bent (of tweede als Akamai groter mocht zijn).

Voor kleinere organisaties is het echt niet de bedoeling dat ze zelf een OpenFlow switch gaan bouwen en/of een eigen OpenFlow controller gaan schrijven. Die kunnen een standaard OpenFlow controller gebruiken. Bijvoorbeeld de commerciele die Google heeft gemaakt of een van de open source versies. Ook hier kan je het weer met servers vergelijken. Dat er standaard hardware is wil nog niet zeggen dat je je eigen software moet gaan schrijven. Je zet daar gewoon een commercieel OS op als Windows of een open source OS als Linux.

Maar zoals ik in het begin zei, zover is het nog lang niet. Switches die OpenFlow ondersteunen zijn over het algemeen high end switches die OpenFlow er bij kunnen doen en hebben ook een high end prijs. Daarmee ga je dus nog niets winnen. Ook zijn er nog voldoende problemen met de huidige OpenFlow specificatie. Voor dat dit echt interessant wordt voor normale bedrijven denk ik dat we een jaar of tien verder zijn.

[Verwijderd]

Ik ben het er helemaal mee eens dat open source platformen een gewenst plaatje zijn. Vooral de platformen zelf. Een OS, of een network-OS.

Linux is een goed voorbeeld van een opensource platform. Linux heeft groot succes in de servermarkt. Maar op de desktop vind ik het nog steeds knudde. Laten we het niet hebben over waarom. Linux is nu al 20 jaar bezig. Hoe lang gaat het duren voor SDN/OpenFlow een stabiel overal vertegenwoordigd platform is ? Hoeveel varianten en afsplitsingen zullen er komen ?

Een IGP is niet noodzakelijk ? Een discovery protocol is goed genoeg ? Voor zover ik zag, is OFDP niet veel meer dan cisco's CDP. En daar kun je echt geen topology mee discoveren. Tenzij we het over speelgoed netwerken hebben.

Voor dat dit echt interessant wordt voor normale bedrijven denk ik dat we een jaar of tien verder zijn

Ah, daar zijn we het dan over eens.
Het is een interessante ontwikkeling, daar ben ik het zeker mee eens. Behalve misschien voor Cisco en Juniper. Die hebben veel te verliezen.

[Bastiaan V]

Quagga niet robuust en scalable? kijk eens vaar vyatta!

[Verwijderd]

Quagga is niet echt robust en scalable.
En Vyatta focused op Firewalls en VPNs, niet echt op routing functionaliteit. Dus niet Quagga. (Quagga doet alleen routing protols, niet dingen als firewalls of VPNs).

Zover ik weet (is me onlangs verteld), wordt Quagga gedistribueerd onder een licensie die je verplicht om alle code die je nieuw geschreven/veranderd hebt, terug te geven aan de Quagga community. Dus alles wat Vyatta verbeterd aan Quagga, zou terug in de publieke Quagga moeten zitten.

Ik weet toevallig dat er dit jaar een project is gestart om Quagga te verbeteren.
http://opensourcerouting.org/

What is needed in networking is a stable, feature rich routing ”platform” fostering innovation, fast development and deployment of routing protocol innovations in trial and production networks, without the bottleneck of incumbent equipment vendors. Several sponsors including Google, have helped initiate OSR to develop this new routing (Layer 3) “platform”.

Afijn, zelfs Google vindt dus dat er serieuze aandacht aan Quagga moet worden besteed voordat het een "stable, feature rich routing platform" kan worden genoemd.

[Verwijderd]

Eenvoudiger ?
Ik zie een hoop extra complexiteit. Als je routers centraal aan gaat te sturen, wil dat niet zeggen dat je complexiteit op de routers weg kunt nemen. Ten eerste zullen de routers nog steeds gewoon routing protcollen moeten draaien. Hoe kun je anders een router bereiken om hem te vertellen wat hij moet doen ? En door een model met centrale server te introduceren, komt er een nieuwe element bij in de architectuur. Met nieuwe APIs en nieuwe protocollen. Meer elementen -> meer complexiteit.

Wordt het goedkoper ?
Ik denk het niet. Ik denk dat het een verschuiving van capex naar opex wordt. Op z'n best. Straks moet iedere ISP en telco kennis in huis hebben om zijn eigen software voor OpenFlow te ontwikkelen. Daar zijn niet genoeg mensen voor. Dus wordt er straks een hoop gerommeld met OpenFlow door amateurs. Dat kost op de lange duur meer dan dat het op levert.

Het enige voordeel dat ik zie is dat ISPs nu meer kans hebben zich te kunnen onderscheiden van andere ISPs. Door zelf controller-software te bouwen, en die via OpenFlow hun routers trucjes te kunnen laten doen, kunnen ze misschien een betere, of andere service naar hun klanten geven. Maar zelf denk ik dat dat slechts weg is gelegd voor weinigen. De meesten gaan hun tanden stukbijten.

[Belboer]

Heb je wel eens een netwerk van enige complexiteit beheerd met LACP, MSTP, OSPF en BGP naar buiten ? Daarvoor ben op meerdere plekken meerdere protocollen aan het beheren. En dan nog heb je vaak linken die standby staan en dus alleen maar geld kosten tot het moment dat er iets mis gaat. Ook heb je geen of weinig controle over hoe verkeersstromen verdeeld worden over bijvoorbeeld een link aggregatie. Met OpenFlow worden alle routeringsbeslissingen op een centraal niveau genomen waardoor hiervoor de gehele staat en belasting van het netwerk meegenomen kan worden in die beslissingen. Daar valt aardig wat winst mee te halen. Plus dat de switches weer redelijk "dom" worden waardoor beheer daarop grotendeels weg valt.
Vergelijk het een beetje met het beheren van meerdere losse VM servers of het beheren van een cluster VM servers via een console. Je hebt een plek nodig om de console te draaien maar maakt wel veel efficienter gebruik van je servers. Nu is het bij servers al zo dat deze een commodity zijn. Het maakt voor beheer erg weinig uit of je servers van Dell hebt of van HP of van een ander. Bij high end netwerkapparatuur is dat nog niet zo. Elke fabrikant heeft zijn eigen manier van configureren en eigen firmware die op subtiele manieren anders werkt dan die van andere fabrikanten. Het idee bij OpenFlow is dat de switches ook een commodity worden en het voor beheer geen donder meer uit maakt of er hardware van fabrikant A of B staat. Je Opex wordt lager door dat je geen retraining cost hebt en beheerders uit een grotere pool kan halen. En je inkoop positie als afnemer wordt veel sterker waardoor je Capex ook lager wordt.

[webkiller71]

Wat denk je er van om vanuit je virtualisatie je routers te configureren? Ik verwacht dat virtualisatieproducten het gaan integreren om hun netwerken nog eenvoudiger te beheren en producten als RHEV, VMware, openstack en cloudstack worden bepaald door amateurs gebouwd.

[BrandALARM]

Intressant protocol.Zeker omdat dit ook met VMware te testen is. zie ook

Ik wist niet wat Propriëtaire pecies was; even opgezocht:

Propriëtaire software, of eigendomsmatige software, wordt door de Free Software Foundation (FSF) gedefinieerd als elke software die niet aan de criteria van FSF voor vrije software voldoet. Onvrij (Engels: Non-free) is een gebruikelijke aanduiding voor software die niet aan de Debian Free Software Guidelines voldoet, die het zelfde basisidee over softwarevrijheid volgen. De term eigendomssoftware wordt ook wel eens gebruikt.

Propriëtair betekent dat een individu of een bedrijf de exclusieve auteursrechten op de software heeft, en tegelijkertijd anderen toegang tot de broncode van de software weigert, evenals het recht om de software te kopiëren, wijzigen en te bestuderen.

De term propriëtair betekent "in privaat bezit en onder private controle". Dus software kan zelfs propriëtair blijven wanneer de broncode publiek beschikbaar is, als de controle over het gebruik, de verspreiding of het wijzigen behouden wordt (zoals bij de commerciële versie van SSH). Aan de andere kant wordt software niet-propriëtair beschouwd zodra het vrijgegeven is onder een licentie die anderen toestaat een 'fork' van de software te maken en om hun eigen aangepaste versie zonder zware beperkingen uit te geven, zelfs als de auteursrechten in handen blijven van een enkel persoon.

[Verwijderd]

Jammer is dan weer dat VMWare proprietaire delen bevat, en ook een patentenlijst heeft waar je u tegen zegt: http://www.vmware.com/go/patents. (Maar ook weer doodnormaal, ieder commercieel bedrijf heeft dat.)

Maar wel een goede zet van de grote jongens op dit gebied, niet alleen qua kostenplaatje. Het is ook een stuk efficienter zoals ze zeggen. Ik had alleen niet verwacht van Cisco e.a. dat ze mee gingen doen... zij hebben baat bij ingewikkelde hardware (of de proprietaire firmware).

[Koos Ofzo]

Ik snap niet helemaal wat een patentlijst te maken heeft met OpenFlow?

[David Mulder]

offtopic:
@Koos Ofzo: Als je de comment had gelezen had je door dat de ppatentlijst over vmware ging en niets te maken had met OpenFlow, maar het sloeg op de (fipo-achige) post van MatthijsE die het over proprietairy software en vmware had.

Ach jah, alhoewel ik me gelukkig niet te vaak op dit niveau van netwerk en server beheer hoef te verdiepen (ik kom meestal niet verder dan een rits van virtuele servers en wat amazon meuk (gelukkig )) lijkt dit wel in lijn te zijn met het feit dat het steeds makkelijker word om dergelijke systemen te beheren.. wat ik me dan wel weer afvraag is of dit misschien op lange termijn juist ook het idee van cloud computing zal gaan tegenwerken als het weer doe-baar word om zo iets zelf te beheren... maja, dat is eigenlijk ook een half offtopic gedachte.

[wica]

gelukkig kan je ook gebruik maken van kvm, xen als je geen howto nodig hebt

[himlims_]

Jammerlijk dat je niet wist wat voor software je gebruikt. Er is veel moois mogelijk wanneer je met OSS werkt. OpenFlow is een project wat nu aantal jaar in ontwikkeling is. Welke aardig gebruik maakt(e) van Open vSwitch (een multilayer virtual switch) en OpenWrt(voor embedded devices). Wat OpenFlow leuk doet is ondersteuning voor multiple writers en het dynamisch inzetten van het systeem door gebruik te maken van reeds bestaande projecten. Een van de voordelen wanneer je werkt met openstandaarden en -software.

[Reactie gewijzigd door himlims_ op 23 juli 2024 15:58]

[ro8in]

Ik heb er zelf nog helemaal niet naar gekeken, maar kan me voorstellen dat dit je netwerk ook weer hack gevoeliger maakt. Toch raak ik wel enthausiast van openflow.

[polthemol]

ligt er maar net aan hoe het geimplementeerd is. Ik neem aan dat het zeker op een afgeschermd gedeelte al draait. An sich kun je ook niet stellen dat het wijzigen van een protocol per definitie een netwerk hackgevoeliger gaat maken (al kun je ook niet weten of het niet meer designflaws heeft dan het protocol dat je vervangt ) De enige manier om daar meer over te vinden is door het te proberen, goed te testen en adequaat reageren mocht er iets opduiken dat op een security lek wijst.

[Wampa1]

Als dit iets groots gaat worden moet ik er toch rekening mee gaan houden me hierin bij te scholen. Dat wil zeggen, mochten ze het ooit publiek maken, kan natuurlijk ook hun eigen goudmijntje worden.

[Shuriken]

Openflow spec is beschikbaar onder BSD-like licentie. Ziet er uit als iets wat uit de Universitaire wereld komt. Dus dat goudmijntje scenario is niet zo waarschijnlijk.

[webfreakz.nl]

Dus dat goudmijntje scenario is niet zo waarschijnlijk.

Waarom niet? Als jij relevante boeken schrijft over een bepaald onderwerp, of je bent een gevraagd consultant, dan kan je zéker een goudmijntje aangeboord hebben.

[Shuriken]

Zoals jij het beschrijft kan dan uiteraard. Maar in de post van wampa1 klinkt het meer alsof Openflow niet publiek is en dat Google(?) er later een goudmijn van kan maken.

[Wampa1]

Dit bedoelde ik er inderdaad mee, maar als het al beschikbaar is ga ik er zeker even naar kijken.

[RielN]

Och, niet lang geleden kwam het bericht van Red Hat dat ze een miljard omzet gedraaid hadden?

[BrandALARM]

Omzet is geen goudmijn.

Omzet is een bedrijfseconomische term die duidt op het totaalbedrag van verkopen van een bedrijf (organisatie, rechtspersoon) in een bepaalde periode en bestaat uit twee componenten, prijs en afzet (verkochte hoeveelheid). Omzet houdt geen rekening met de vraag of de opbrengst van de verkopen al in geld aanwezig is, of dat het nog uitstaande vorderingen bij klanten betreft.

bron

[Verwijderd]

Even googlen.
Cijfers van Maart 2012.
http://www.reuters.com/ar...hat-idUSBRE82R1CU20120328

Red Hat ....rode a 21 percent jump in fourth-quarter revenue to $297 million.
.... Net income for the quarter ended February 29 rose to $36 million, ....

Ruim een miljard doller per jaar omzet.
En een winst van 120 miljoen dollar per jaar (ruwe schatting).
Goudmijn dus.

[PiepPiep]

Maar een omzet zegt wel dat er veel geld in omgaat en dus potentieel veel mee te verdienen valt. Ik denk dat hij daar op doelde.

[erwinb]

Google en Facebook zijn ook afkomstig uit de universitaire wereld. Redelijke goudmijntjes.

[arjankoole]

Laten we dan gerust wat verder terug gaan: Microsoft en Apple zijn beiden opgericht door drop-outs. Goudmijnen vind je overal, je moet alleen het inzicht hebben ze te herkennen, en soms de moed er voor hebben.

[Verwijderd]

Waar het om ging is het woord "proprietary".
Dat is grofweg-gezegd het tegenovergestelde van opensource, public domain, gratis, etc.

Proprietay software kun je verkopen.
Non-proprietary software kun je niet verkopen.
Dus denk sommigen dat je met non-proprietary software geen geld kunt verdienen.
Echter, er zijn diensten te verkopen, die te maken hebben met non-proprietary software.
En Redhat is een prima voorbeeld van hoe je op die manier goed geld kunt verdienen.

Heeft allemaal niks te maken met universitaire wereld.
High-tech wordt nu eenmaal niet vaak uitgevonden door putjesscheppers en keuterboeren.

[himlims_]

Waarom niet? specialisme is altijd een goudmijn! ongeacht welke branche of tak van sport je beoefend. En specialisme betaald men voor. Stel jij richt je volledig op OpenFlow. Ongetwijfeld dat jij jouw kennis kunt verkopen als support. Een van de commerciële uitgangspunten van de linux kennis....

[citegrene]

Zoals ik het artikel lees, servers die netwerkapparatuur aansturen, klinkt alsof openflow een soort SNMP protocol is, de zoveelste netwerkmanagement protocol want bijna iedere hardware router vendor heeft wel zijn eigen standaard hiervoor.