Software Defined Networking
In mijn vorige blog schreef ik over Software Defined Access, een voorbeeld van “Software Defined Networking” (SDN). Ik zie SDN als de inhaalslag die Networking aan het maken is in de virtualisatie. Networking was één van de eerste gebieden in IT waar virtualisatie doordrong. Denk maar aan netwerken als Frame Relay en ATM. Daar kon je meerdere netwerken op één fysieke infrastructuur draaien en natuurlijk Virtuele LANs, VLANs, in Ethernet. Toen virtualisatie in de serverwereld gemeengoed werd, bleef de netwerkwereld een beetje achter: features waren vaak gekoppeld aan hardware. Maar inmiddels is Networking met een inhaalslag bezig.
Uitrollen betekent extra apparatuur op locaties
In het WAN zie je “Software Defined WAN”, SD-WAN steeds meer gebruikt worden om remote locaties te ontsluiten. Naast de dure, relatief trage, maar betrouwbare MPLS-verbinding wordt er dan een relatief goedkope en snelle, lokale Internet-verbinding gebruikt. Dit betekent echter wel het uitrollen van extra apparatuur op de locaties, minimaal een SD-WAN appliance, maar meestal ook een decentrale firewall.
Network Function Virtualization
Een ander voorbeeld van SDN is “Network Function Virtualization”. Dit wordt nog minder in de praktijk toegepast dan SD-WAN, maar het zeker iets wat in ontwikkeling is.
Op Cisco Live volgde ik een sessie van een hele dag over Network Function Virtualization. Deze sessie bestond uit een introductie in NFV, de oplossingen die Cisco daarvoor heeft en een een labsessie waarin je zelf een gevirtualiseerde locatie kon opzetten.
Apparaten hoeven niet per se van Cisco te zijn
Network Function Virtualization (NFV) is, zoals de naam al zegt, het virtualiseren van de verschillende functies in het netwerk. Hierbij kun je denken aan routers en switches, maar ook aan bijvoorbeeld firewalls. Wat wel opvallend is, zeker in de relatief gesloten wereld van Cisco, is dat deze apparaten niet per se Cisco-apparaten hoeven te zijn. Zo kun je bijvoorbeeld je virtuele Palo Alto firewall gewoon op je Cisco NFV-platform draaien.
Fysiek aansluiten appparatuur is tijdroven
Het fysiek aansluiten van apparatuur kost vaak relatief veel tijd. In een recent project waar ik aan meewerkte moesten we op 50 verschillende locaties firewalls aansluiten. Deze apparatuur werd door de leverancier direct naar de locatie gestuurd en door een lokale medewerker van spanning en netwerk voorzien. Om dit voor alle locaties geregeld te krijgen, hadden we een doorlooptijd van 3 maanden nodig!
Met een NFV-oplossing had deze tijd flink verkort kunnen worden. Cisco heeft een aantal oplossingen voor NFV, waaronder de ENCS serie, waar dit lab om draaide.
Cultuurshock
Voor wie een command line interface (CLI) gewend is, is dit wel een cultuurshock: alles wordt via een web-interface geconfigureerd. De onderlinge koppelingen tussen de verschillende apparaten en fysieke interfaces kan je letterlijk klikken en slepen. Erg mooi en erg overzichtelijk gemaakt.
Tijdens het lab merkte ik ook wel dat door de verschillende menu's heen gaan om instellingen te maken best tijdrovend is. Als je dit in productie zou toepassen is het natuurlijk de bedoeling je de configuraties gaat maken via een automation platform of een orchestrator die dan de API aanspreken.
Uithuilen en opnieuw beginnen
Op een gegeven moment wilde het lab helemaal niks meer. Zelfs de docent (die één van Cisco's experts op dit platform was) kwam er niet meer uit. De oefening op een nieuw lab doen was de “oplossing”. Zo zie je maar dat de mooie grafische interface een hoop complexiteit verbergt en dat als het niet meer werkt dat zelfs de experts het niet meer weten. “Uithuilen en opnieuw beginnen” lijkt tegenwoordig de standaardoplossing voor problemen in complexe omgevingen te zijn, zie ook bijvoorbeeld containeroplossingen, waarbij containers worden verwijderd en opnieuw aangemaakt, in plaats van bijvoorbeeld een softwareupdate doen.
Lees ook blog 1: Cisco Software Defined Acces
------------------------------------------------
Jeroen Roos is principal consultant bij Nivo