Expert Ronny Lam legt uit

Het begrip ‘software-defined networks’ is volgens diverse trendwatchers een belangrijke nieuwe ontwikkeling in de komende jaren. Maar waarom eigenlijk? En welke standaarden zijn er precies? Expert Ronny Lam (NetYCE), die ook op de NLUUG-conferentie een talk houdt over het onderwerp, legt het ons haarfijn uit.

Wat betekent SDN voor een systeembeheerder?
“Software-defined networking is eigenlijk een andere naam voor de trend dat de wereld van systemen en van netwerken naar elkaar toegroeien. Daardoor kunnen netwerken sneller en makkelijker geconfigureerd worden, alsof je een server beheert of aan een applicatie ontwikkelt. Als je vroeger een nieuw segment in de lucht wilde brengen of een firewallpoort wilde openen, dan was dat een langzame en relatief statische operatie. Nu wordt het netwerk veel meer agile.”

Net zoals je met ‘configuration management’ (Puppet, Ansible, cfengine, etc.) een heel serverpark centraal beheert, zou je met SDN niet meer alle routers apart hoeven te configureren?

“Precies. Dat wordt vaak als één van de grote voordelen gezien van software-defined networking. Een ander voordeel is dat je een centraal overzicht hebt van de status en het gebruik van het netwerk. Maar er zijn voor de toekomst wel nog wat dingen op te lossen. Zo kun je de domeinen niet te groot maken en de afstanden tot de controller moeten ook niet te groot worden. Als SDN een vlucht gaat nemen, zul je in zeer grote netwerken, bijvoorbeeld bij service providers, gaan zien dat je meerdere domeinen krijgt met eigen controllers, met een of meerdere supercontrollers daaroverheen.”

Wanneer gaat die vlucht komen?
“Het gaat hier over een paradigmaverschuiving: SDN is een andere technologie, vergelijkbaar met de overgang van IPv4 naar IPv6. Zolang de voordelen -die zitten heel vaak in tijd en geld- nog niet aantoonbaar zijn, is het een zaak van de lange adem. Mensen stappen nog niet over naar nieuwe techniek, zolang het oude nog prima werkt.”

Verwacht je veranderingen voor consumenten?
“Nee, niet op korte termijn. Het is vooral nuttig voor grote netwerken. Een consument heeft maar één router en/of een switch staan dat zijn netwerk verzorgt. De consument is daarom niet gebaat bij een scheiding van forwarding en control plane. Maar als bijvoorbeeld OpenFlow als open standaard doorbreekt, krijg je wel standaard API’s om op afstand routers te bedienen. De configuratie wordt steeds meer API-gebaseerd en steeds minder CLI-gebaseerd. Dat is een grote verbetering.”

Hoe zit dat met OpenFlow?
“Er begint een duidelijke definitie van SDN in de markt te ontstaan, namelijk: 

-De netwerkfunctie (de forwarding plane) en het beheer (de control plane) zijn fysiek gescheiden;

-Meerdere devices worden door één controller aangestuurd;

-Het netwerk is programmeerbaar geworden door open, gestandaardiseerde API’s.

Momenteel zijn allerlei vendors met hun eigen versie van SDN bezig, bijvoorbeeld Cisco met OnePK en Juniper met (Open)Contrail. Ook die bieden een centrale interface naar alle netwerkcomponenten, al bevindt de control plane zich nog steeds binnen de devices zelf. OpenFlow is een open standaard. Een voordeel daarvan is dat het de hardware gestandaardiseerd maakt, waardoor je naar goedkopere hardware zou kunnen gaan van welke vendor het ook is. Ze noemen dat ook wel whiteboxing. Met iedere nieuwe versie van OpenFlow (momenteel zitten we op versie 1.4) wordt er weer meer toegevoegd. Het is nodig, want er moet een wereld van vijfentwintig jaar networking overwonnen worden om aan te  sluiten bij een behoefte uit de markt. Er zijn een aantal controllers in de markt, waarvan een deel Open Source. De user interface naar de controller, de zogenoemde north-bound API, was echter niet gestandaardiseerd. Dat is iets waar we nu middenin zitten. Dit moet het makkelijker maken om applicaties op een controller te kunnen schrijven. Uiteindelijk zou hiermee een soort van SDN app-store kunnen ontstaan. Onder de vlag van de Linux Foundation is een groot open source project gestart om een SDN-controller te ontwikkelen. Dit OpenDayLight-project is een samenwerking van bedrijven als Cisco, Juniper, Red-Hat, IBM en vele anderen. Recent is na een jaar ontwikkeling de eerste release, genaamd Hydrogen, gelanceerd.”

Dus de Cisco CLI-commando’s hoeven we straks niet meer te kennen?

“Het werk van de netwerkbeheerder gaat inderdaad veranderen. Het netwerk gaat steeds meer programmeerbaar worden. Dat vereist meer scripting-, meer developmentachtige kennis, waardoor je ook een ander soort mensen nodig hebt die het netwerk beheren. Gaan de netwerkbeheerders daar naartoe groeien of gaan de systeembeheerders dit overnemen? Je ziet nu al dat bijvoorbeeld Puppet en Ansible een deel van de netwerkconfiguratie doen. Daar ligt, qua kennis, een uitdaging voor de toekomst.”