Cisco Live 2017 – BRKDCN-2044 – Effective Evolution of the Data Center Virtual Network

Dag 1 begon met de sessie – BRKDCN-2044 – Effective Evolution of the Data Center Virtual Network (2 uur).

Deze sessie gaat over de evolutie van het Data Center Virtual netwerk en hoe dit efficiënt te doen. Het is begonnen met de adaptie van Virtualisatie, begin 2000. De introductie van de Virtuele Switch, deze had vaak geen eigenaar, was complex om te beheren, was niet schaalbaar, en het was moeilijk te zien wat er in de virtuele switch gebeurde.

Cisco heeft dit rond 2010 aangepakt met de eigen virtuele switch, Cisco Nexus 1000V, maar de adoptie van deze switch liep niet echt lekker. De complexiteit was nog steeds hoog.

Rond 2014 werd Cisco ACI gepresenteerd als oplossing voor de eerdergenoemde uitdagingen met Virtuele netwerken, complexiteit, schaalbaarheid en netwerkinzicht. Deze manier wordt ook wel “Application Centric” genoemd en gaat eigenlijk verder dan alleen maar Cisco ACI. Het draait bij Application Centric om, elke workload, waar dan ook, of het nu binnen Cisco ACI is, of in de Cloud, het maakt niet meer uit.

We krijgen nu te maken met ontwikkelaars en beheerders voor wie het niet meer uitmaakt waar hun applicatie draait. Als de applicatie maar toegankelijk is vanuit welke plek dan ook. Dit is alleen mogelijk door het gebruik van policies en deze in te zetten middels automation. De uitrol van applicatie omgevingen moet namelijk snel gebeuren. Dat gebeurt namelijk ook op Cloud platformen, zoals Azure en AWS.

Een ander belangrijk aspect dat invloed heeft op de evolutie van het Data Center virtuele netwerk, is de methode waarop applicaties worden ontwikkeld en steeds meer leunen op modulaire delen die via een zogenaamde service interface worden aangeboden, niet alleen meer via een website, maar ook aan “dingen”, dus daar speelt Mobile, IoT en Machine Learning weer een grote rol in de evolutie. Denk daarbij aan Mobiele Apps, Sensoren en website die allemaal met elkaar moeten communiceren.

Als we kijken naar de opkomst van steeds meer virtuele netwerkservices, zoals virtuele routers, switches, load balancers, etc. wat zijn dan de uitdaging die de netwerkbeheerders tegenkomen?

  • Complexiteit van de virtuele omgeving (Openstack, Linux, vCenter, Docker)
  • Toegang tot de virtuele omgeving, maar ook het beheer van de virtuele appliances
  • Gewend zijn aan hardware appliances en de betere performance die dit (soms) geeft.

Voorbeeld: De perimeter firewall is niet meer genoeg voor inzicht in Oost-West verkeer. De “per applicatie firewall” wordt steeds belangrijker. Deze virtuele firewalls draaien op een virtuele omgeving met de eerdergenoemde uitdagingen.

Deze uitdagingen lossen we alleen op met de inzet van policies en automation. Waarbij de integratie wordt gedaan met virtuele appliances en de virtuele omgevingen, of het nu on-premise is of in de Cloud.

5 jaar geleden zijn we begonnen met Virtual Overlay Extensibility in het Data Center. Natuurlijk was er al Overlay techniek om over het WAN-netwerk te gaan, zoals GRE tunnels, MPLS, etc. Maar dit soort configuraties is geen goede oplossing voor het Data Center netwerk.

Als we nu kijken naar wat deze evolutie ons heeft gebracht in het Data Center, dan kunnen we vaststellen dat VXLAN steeds vaker wordt ingezet als overlay technologie.

VXLAN – Virtual eXtensible Local Area Network is een encapsulation technologie die tunnels opzet tussen (virtuele) switches (VTEP) en zorgen voor een L2 extensie over een L3 netwerk. Omdat de complete L2 frame gebruikt wordt is er een additionele overhead van 50 bytes, waar rekening mee gehouden moet worden. Je kunt elk 24bit VXLAN-segment beschouwen als een logisch netwerk. Het is mogelijk 16 miljoen logische netwerken te gebruiken.

IP Multicast of MP-BGP met EVPN wordt gebruikt voor L2 BUM-verkeer.

Deze sessie gaat verder in op het gebruik van VXLAN met de verschillende soorten virtuele switches die Cisco aanbiedt. Cisco 1000v, AVS, en Cisco ACI met de DVS-integratie en waarom en hoe je (micro)segmentatie toepast

Er werd ook nog even ingegaan op het feit dat VMware de kernel niet meer toegankelijk maakt voor 3de partijen voor virtuele switches (=> vSphere 6.5u2). De bedoeling is dat er een soort native vSwitch komt die losstaat van de kernel. Die dan ook weer makkelijker is te integreren met externe policy tooling.

Published by

Michel van Kessel

Specialist in Data Center Infrastructure Designs and Cloud Designs. CCIE Data Center #44197 #CiscoChampion

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s