SDN: Still Don't kNow?

Dat 'Still Don't kNow' niet de juiste betekenis is van SDN zal bij de meeste IT-professionals bekend zijn. Toch zou dit wel het antwoord kunnen zijn op de vraag: wat is Software Defined Networking (SDN) precies?

Kijken we naar cloud, een andere welbekende term in de IT, dan zien we dat daar officiële definities voor bestaan (NIST). Zo’n officiële definitie bestaat voor SDN (vooralsnog) niet. Ondanks grote veranderingen in het IT-landschap, zoals mobility, cloud en Internet of Things (digital business transformation), is het netwerk - en de manier waarop we ermee omgaan - eigenlijk hetzelfde gebleven. Daar lijkt met SDN nu verandering in te komen. Vraag verschillende professionals wat SDN inhoudt en je krijgt verschillende antwoorden, maar een aantal aspecten komen steeds terug. In deze blog worden die aspecten bekeken om zo een beeld te schetsen van SDN.

Scheiding van management-, control- en data-planes
In een traditioneel netwerk van routers en switches heeft elk device zijn eigen management-, control- en data-plane. Op de management-plane kan de beheerder het device configureren (Command Line Interface/CLI). In de control-plane vinden we onder andere de routingprotocollen waarmee beslissingen worden gemaakt over hoe het verkeer verstuurd moet worden. Het daadwerkelijk doorzetten van netwerkpakketten van A naar B vindt plaats in de data-plane. De data-plane is dus verantwoordelijk voor het feitelijke netwerkverkeer en de control- en management-plane zijn de ‘brains’ van het device.

Elk device heeft zijn eigen individuele configuratie-, controle- en gegevenslaag.

Kijken we naar SDN, dan zien we over het algemeen dat deze ‘brains’ voor een groot deel naar een centrale locatie verhuizen. De functionaliteiten komen bijvoorbeeld op een dedicated controller te draaien. En hier gebruiken we dan niet meer de taal die we van de Command Line Interface gewend zijn, maar kunnen we met een GUI werken. We vertellen de controller wat we in het netwerk willen hebben en de controller zorgt dat de feitelijke netwerk-devices geconfigureerd worden (hoe dat moet, is dus niet meer relevant). Als beheerder hoef je dus niet meer per device een stuk configuratie door te voeren, of de verschillende ‘talen’ van verschillende CLI’s te kennen als er meerdere smaken zijn. Bij een paar devices is dat misschien nog niet zo interessant, maar hoe groter de infrastructuur, hoe groter het voordeel. Voor de controller maakt het niet uit of er twee switches of tweehonderd geconfigureerd moeten worden.

Network (Function) Virtualization
Door netwerken te virtualiseren, ontstaat de flexibiliteit om snel stukken netwerk in de lucht te brengen (of op te ruimen). Hiervoor kunnen (software) overlays en hardware underlays worden gebruikt. De underlay is de verzameling van de fysieke netwerk hardware en onderlinge verbindingen. Voor de netwerk-engineers: een L3 routed non-blocking Equal Cost Multi Path fabric (spine/leaf topologie) wordt over het algemeen als geschikte basis gezien. De overlay is het virtuele netwerk dat softwarematig (door de controller) gerealiseerd wordt. Hiervoor worden technieken, zoals VXLAN of NVGRE gebruikt. De virtuele overlays bieden vaak mogelijkheden voor multi-tenancy. Dus: met dezelfde fysieke infrastructuur meerdere klanten bedienen. Met een druk op de knop zijn deze virtuele netwerken – waar je uiteindelijk je productie mee draait – te realiseren of op te ruimen. Doordat dit centraal en geautomatiseerd wordt aangestuurd, blijven er geen oude stukken configuratie achter. Denk aan lange firewall rule sets of access lists. Is het na vele jaren aan wijzigingen nog duidelijk welke rules kunnen verdwijnen bij het uitfaseren van een applicatie? Wanneer je applicatieomgeving centraal is gedefinieerd, wordt dat anders.

Bij Network Function Virtualization (NFV) kunnen we functies als Load-Balacing en Firewalling met één druk op de knop toevoegen aan de infrastructuur. De aansturende software zorgt dat de virtuele instanties worden aangemaakt en geconfigureerd (al dan niet als VM of gevirtualiseerde instantie op de hardware van het firewall-/loadbalancing-platform zelf).

Programmability and Automation
De kracht van SDN zit ‘m in de S: het is op software gebaseerd. Dit biedt veel mogelijkheden voor programmability en automation. Als je gehele netwerk infrastructuur één API heeft, wat zijn dan de mogelijkheden? Je kunt met eigen scripts/software tegen de infrastructuur (controller) praten om wijzigingen door te voeren dan wel informatie over je infrastructuur in te winnen (single pane of glass). Eind 2016 heeft Gartner’s research vice president Andrew Lerner de ‘dood van de CLI’ voorspeld. In 2020 gebruiken nog slechts 30% van alle netwerkoperatieteams de CLI als primaire interface richting het netwerk. Volgens Gartner was dat percentage eind 2016 nog 85%.

Toekomst
We moeten nog tot 2020 wachten om te weten of Gartner gelijk krijgt, maar de weg naar SDN lijkt zeker ingeslagen. Microsoft Azure, Cisco ACI, APIC-EM en VMWare NSX zijn allemaal producten die in het SDN-veld passen. Ook zie je dat diverse hardware leveranciers (routers, switches, firewall, loadbalancer) steeds meer mogelijkheden bieden om hun apparatuur via API’s aan te spreken. Voor de netwerk-engineer betekent het verdwijnen van de CLI en het verschijnen van API’s en programmability dat een nieuwe skillset gewenst is. Maar ook de organisatie moet mogelijk veranderen, zeker als SDN voor een cloud-omgeving wordt ingezet. Wanneer processen en procedures zijn afgestemd op de ‘ouderwetse’ infrastructuur zijn deze waarschijnlijk niet meer geschikt bij overgang naar cloud/SDN. Zie jij SDN ook aan terrein winnen of behoor je nog tot het ‘Still Don’t kNow’ kamp?

Gebruikte bronnen
• Cloud definition: https://www.nist.gov/programs-projects/nist-cloud-computing-program-nccp
• Whitepaper: Demystifying SDN for the network engineer – Cisco
• Lumos Consluting video “ACI Fundamentals” – youtube
Lees ook de blog Interface to the people - software enables the business van Bryan Mac Gillavry.

Deze blog verscheen eerder op www.centric.eu/craft