Om VXLAN-gateways te bespreken, moeten we eerst VXLAN zelf bespreken. Traditionele VLAN's (Virtual Local Area Networks) gebruiken 12-bits VLAN-ID's om netwerken te verdelen en ondersteunen tot 4096 logische netwerken. Dit werkt prima voor kleine netwerken, maar in moderne datacenters, met hun duizenden virtuele machines, containers en multi-tenantomgevingen, zijn VLAN's onvoldoende. VXLAN is ontstaan en gedefinieerd door de Internet Engineering Task Force (IETF) in RFC 7348. Het doel is om het Layer 2 (Ethernet) broadcastdomein uit te breiden over Layer 3 (IP) netwerken met behulp van UDP-tunnels.
Simpel gezegd encapsuleert VXLAN Ethernet-frames in UDP-pakketten en voegt een 24-bits VXLAN Network Identifier (VNI) toe, die theoretisch 16 miljoen virtuele netwerken ondersteunt. Dit is vergelijkbaar met het geven van een "identiteitskaart" aan elk virtueel netwerk, waardoor ze zich vrij over het fysieke netwerk kunnen bewegen zonder elkaar te hinderen. De kerncomponent van VXLAN is het VXLAN Tunnel End Point (VTEP), dat verantwoordelijk is voor het encapsuleren en decapsuleren van pakketten. VTEP kan softwarematig zijn (zoals Open vSwitch) of hardwarematig (zoals de ASIC-chip op de switch).
Waarom is VXLAN zo populair? Omdat het perfect aansluit bij de behoeften van cloudcomputing en SDN (Software-Defined Networking). In publieke clouds zoals AWS en Azure maakt VXLAN naadloze uitbreiding van virtuele netwerken van gebruikers mogelijk. In private datacenters ondersteunt het overlay-netwerkarchitecturen zoals VMware NSX of Cisco ACI. Stel je een datacenter voor met duizenden servers, elk met tientallen VM's (virtuele machines). VXLAN zorgt ervoor dat deze VM's zichzelf als onderdeel van hetzelfde Layer 2-netwerk beschouwen, wat zorgt voor een soepele overdracht van ARP-broadcasts en DHCP-verzoeken.
VXLAN is echter geen wondermiddel. Om op een L3-netwerk te kunnen werken, is L2-naar-L3-conversie vereist, en daar komt de gateway om de hoek kijken. De VXLAN-gateway verbindt het virtuele VXLAN-netwerk met externe netwerken (zoals traditionele VLAN's of IP-routeringsnetwerken) en zorgt zo voor een goede gegevensstroom van de virtuele wereld naar de echte wereld. Het forwardingmechanisme vormt het hart van de gateway en bepaalt hoe pakketten worden verwerkt, gerouteerd en gedistribueerd.
Het VXLAN-forwardingproces is als een delicaat ballet, waarbij elke stap van bron tot bestemming nauw met elkaar verbonden is. Laten we het stap voor stap bekijken.
Eerst wordt er een pakket verzonden vanaf de bronhost (zoals een virtuele machine). Dit is een standaard Ethernet-frame met het bron-MAC-adres, het bestemmings-MAC-adres, de VLAN-tag (indien aanwezig) en de payload. Na ontvangst van dit frame controleert de bron-VTEP het bestemmings-MAC-adres. Als het bestemmings-MAC-adres in de MAC-tabel staat (verkregen via learning of flooding), weet de VTEP naar welke externe VTEP het pakket moet worden doorgestuurd.
Het encapsulatieproces is cruciaal: de VTEP voegt een VXLAN-header toe (inclusief de VNI, vlaggen, enzovoort), vervolgens een buitenste UDP-header (met een bronpoort gebaseerd op een hash van het interne frame en een vaste bestemmingspoort van 4789), een IP-header (met het bron-IP-adres van de lokale VTEP en het bestemmings-IP-adres van de externe VTEP) en tot slot een buitenste Ethernet-header. Het volledige pakket verschijnt nu als een UDP/IP-pakket, ziet eruit als normaal verkeer en kan worden gerouteerd via het L3-netwerk.
Op het fysieke netwerk wordt het pakket doorgestuurd door een router of switch totdat het de bestemmings-VTEP bereikt. De bestemmings-VTEP verwijdert de buitenste header, controleert de VXLAN-header om er zeker van te zijn dat de VNI overeenkomt en levert vervolgens het interne Ethernet-frame aan de bestemmingshost. Als het pakket onbekend unicast-, broadcast- of multicast (BUM)-verkeer betreft, repliceert de VTEP het pakket naar alle relevante VTEP's met behulp van flooding, waarbij gebruik wordt gemaakt van multicastgroepen of unicast header replication (HER).
De kern van het forwardingprincipe is de scheiding van het controlevlak en het datavlak. Het controlevlak gebruikt Ethernet VPN (EVPN) of het Flood and Learn-mechanisme om MAC- en IP-toewijzingen te leren. EVPN is gebaseerd op het BGP-protocol en stelt VTEP's in staat om routinginformatie uit te wisselen, zoals MAC-VRF (Virtual Routing and Forwarding) en IP-VRF. Het datavlak is verantwoordelijk voor de daadwerkelijke forwarding, waarbij VXLAN-tunnels worden gebruikt voor efficiënte transmissie.
Bij daadwerkelijke implementaties heeft de efficiëntie van de forwarding echter een directe invloed op de prestaties. Traditionele flooding kan gemakkelijk broadcast storms veroorzaken, vooral in grote netwerken. Dit leidt tot de noodzaak van gateway-optimalisatie: gateways verbinden niet alleen interne en externe netwerken, maar fungeren ook als proxy-ARP-agenten, verwerken routelekken en zorgen voor de kortste forwardingpaden.
Gecentraliseerde VXLAN-gateway
Een gecentraliseerde VXLAN-gateway, ook wel een gecentraliseerde gateway of L3-gateway genoemd, wordt doorgaans geïmplementeerd op de edge- of core-laag van een datacenter. Deze fungeert als een centrale hub waar al het cross-VNI- of cross-subnet-verkeer doorheen moet.
In principe fungeert een gecentraliseerde gateway als standaardgateway en biedt Layer 3-routeringsservices voor alle VXLAN-netwerken. Beschouw twee VNI's: VNI 10000 (subnet 10.1.1.0/24) en VNI 20000 (subnet 10.2.1.0/24). Als VM A in VNI 10000 toegang wil tot VM B in VNI 20000, bereikt het pakket eerst de lokale VTEP. De lokale VTEP detecteert dat het bestemmings-IP-adres zich niet op het lokale subnet bevindt en stuurt het door naar de gecentraliseerde gateway. De gateway decapsuleert het pakket, neemt een routeringsbeslissing en kapselt het vervolgens opnieuw in via een tunnel naar de bestemmings-VNI.
De voordelen zijn duidelijk:
○ Eenvoudig beheerAlle routeringsconfiguraties zijn gecentraliseerd op één of twee apparaten, waardoor operators slechts een paar gateways hoeven te beheren om het hele netwerk te bestrijken. Deze aanpak is geschikt voor kleine en middelgrote datacenters of omgevingen die voor het eerst VXLAN implementeren.
○Efficiënt gebruik van hulpbronnenGateways zijn doorgaans krachtige hardware (zoals de Cisco Nexus 9000 of Arista 7050) die enorme hoeveelheden verkeer aankan. Het controlepaneel is gecentraliseerd, wat integratie met SDN-controllers zoals NSX Manager vergemakkelijkt.
○Sterke beveiligingscontroleVerkeer moet via de gateway passeren, wat de implementatie van ACL's (Access Control Lists), firewalls en NAT vergemakkelijkt. Stel je een scenario met meerdere tenants voor waarbij een gecentraliseerde gateway het verkeer van de tenants eenvoudig kan isoleren.
Maar de tekortkomingen kunnen niet worden genegeerd:
○ Eén enkel punt van falenAls de gateway uitvalt, wordt de L3-communicatie in het hele netwerk platgelegd. Hoewel VRRP (Virtual Router Redundancy Protocol) kan worden gebruikt voor redundantie, brengt het nog steeds risico's met zich mee.
○PrestatieknelpuntAl het oost-westverkeer (communicatie tussen servers) moet de gateway omzeilen, wat resulteert in een suboptimaal pad. Bijvoorbeeld, in een cluster met 1000 knooppunten, als de gatewaybandbreedte 100 Gbps is, is er tijdens piekuren waarschijnlijk congestie.
○Slechte schaalbaarheidNaarmate de netwerkomvang toeneemt, neemt de gatewaybelasting exponentieel toe. In een praktijkvoorbeeld heb ik een financieel datacenter gezien dat een gecentraliseerde gateway gebruikte. Aanvankelijk liep het soepel, maar nadat het aantal VM's verdubbelde, schoot de latentie omhoog van microseconden naar milliseconden.
Toepassingsscenario: Geschikt voor omgevingen die een hoge mate van beheergemak vereisen, zoals private clouds of testnetwerken van bedrijven. Cisco's ACI-architectuur maakt vaak gebruik van een gecentraliseerd model, gecombineerd met een leaf-spine-topologie, om een efficiënte werking van kerngateways te garanderen.
Gedistribueerde VXLAN-gateway
Een gedistribueerde VXLAN-gateway, ook wel een gedistribueerde gateway of anycast-gateway genoemd, delegeert gatewayfunctionaliteit aan elke leaf-switch of hypervisor-VTEP. Elke VTEP fungeert als een lokale gateway en verwerkt L3-forwarding voor het lokale subnet.
Het principe is flexibeler: elke VTEP is geconfigureerd met hetzelfde virtuele IP-adres (VIP) als de standaardgateway, met behulp van het Anycast-mechanisme. Cross-subnet pakketten die door VM's worden verzonden, worden rechtstreeks naar de lokale VTEP gerouteerd, zonder dat ze via een centraal punt hoeven te gaan. EVPN is hier bijzonder nuttig: via BGP EVPN leert de VTEP de routes van externe hosts en gebruikt MAC/IP-binding om ARP-flooding te voorkomen.
Bijvoorbeeld, VM A (10.1.1.10) wil toegang tot VM B (10.2.1.10). De standaardgateway van VM A is de VIP van de lokale VTEP (10.1.1.1). De lokale VTEP routeert naar het doelsubnet, encapsuleert het VXLAN-pakket en stuurt het rechtstreeks naar de VTEP van VM B. Dit proces minimaliseert het pad en de latentie.
Uitstekende voordelen:
○ Hoge schaalbaarheidHet distribueren van gatewayfunctionaliteit naar elk knooppunt vergroot de netwerkgrootte, wat gunstig is voor grotere netwerken. Grote cloudproviders zoals Google Cloud gebruiken een vergelijkbaar mechanisme om miljoenen virtuele machines te ondersteunen.
○Superieure prestatiesOost-westverkeer wordt lokaal verwerkt om knelpunten te voorkomen. Testgegevens tonen aan dat de doorvoersnelheid in de gedistribueerde modus met 30%-50% kan toenemen.
○Snel herstel van storingenEén VTEP-storing heeft alleen invloed op de lokale host en laat andere knooppunten ongemoeid. Gecombineerd met de snelle convergentie van EVPN bedraagt de hersteltijd slechts enkele seconden.
○Goed gebruik van middelenGebruik de bestaande Leaf switch ASIC-chip voor hardwareversnelling, met doorstuursnelheden die het niveau van Tbps bereiken.
Wat zijn de nadelen?
○ Complexe configuratieElke VTEP vereist configuratie van routing, EVPN en andere functies, waardoor de initiële implementatie tijdrovend is. Het operationele team moet bekend zijn met BGP en SDN.
○Hoge hardwarevereistenGedistribueerde gateway: Niet alle switches ondersteunen gedistribueerde gateways; Broadcom Trident- of Tomahawk-chips zijn vereist. Software-implementaties (zoals OVS op KVM) presteren minder goed dan hardware.
○Consistentie-uitdagingenGedistribueerd betekent dat de statussynchronisatie afhankelijk is van EVPN. Als de BGP-sessie fluctueert, kan dit een routing black hole veroorzaken.
Toepassingsscenario: Perfect voor hyperscale datacenters of publieke clouds. De gedistribueerde router van VMware NSX-T is een typisch voorbeeld. In combinatie met Kubernetes ondersteunt het naadloos containernetwerken.
Gecentraliseerde VxLAN-gateway versus gedistribueerde VxLAN-gateway
En nu naar de climax: wat is beter? Het antwoord is "het hangt ervan af", maar we moeten diep in de data en casestudies duiken om u te overtuigen.
Vanuit prestatieperspectief presteren gedistribueerde systemen duidelijk beter. In een typische datacenterbenchmark (gebaseerd op Spirent-testapparatuur) bedroeg de gemiddelde latentie van een gecentraliseerde gateway 150 μs, terwijl die van een gedistribueerd systeem slechts 50 μs bedroeg. Qua doorvoer kunnen gedistribueerde systemen gemakkelijk line-rate forwarding bereiken omdat ze gebruikmaken van Spine-Leaf Equal Cost Multi-Path (ECMP) routing.
Schaalbaarheid is een ander strijdtoneel. Gecentraliseerde netwerken zijn geschikt voor netwerken met 100-500 knooppunten; boven deze schaal hebben gedistribueerde netwerken de overhand. Neem bijvoorbeeld Alibaba Cloud. Hun VPC (Virtual Private Cloud) maakt gebruik van gedistribueerde VXLAN-gateways om miljoenen gebruikers wereldwijd te ondersteunen, met een latentie binnen één regio van minder dan 1 ms. Een gecentraliseerde aanpak zou allang zijn mislukt.
Hoe zit het met de kosten? Een gecentraliseerde oplossing biedt een lagere initiële investering en vereist slechts een paar high-end gateways. Een gedistribueerde oplossing vereist dat alle leaf nodes VXLAN offload ondersteunen, wat leidt tot hogere hardware-upgradekosten. Op de lange termijn biedt een gedistribueerde oplossing echter lagere O&M-kosten, omdat automatiseringstools zoals Ansible batchconfiguratie mogelijk maken.
Beveiliging en betrouwbaarheid: Gecentraliseerde systemen bieden gecentraliseerde bescherming, maar vormen een hoog risico op aanvallen op één locatie. Gedistribueerde systemen zijn veerkrachtiger, maar vereisen een robuust controleplatform om DDoS-aanvallen te voorkomen.
Een praktijkvoorbeeld: een e-commercebedrijf gebruikte gecentraliseerd VXLAN om zijn website te bouwen. Tijdens piekmomenten steeg het CPU-gebruik van de gateway tot 90%, wat leidde tot klachten van gebruikers over latentie. De overstap naar een gedistribueerd model loste dit probleem op, waardoor het bedrijf zijn schaalgrootte gemakkelijk kon verdubbelen. Een kleine bank daarentegen stond op een gecentraliseerd model omdat ze prioriteit gaven aan compliance-audits en gecentraliseerd beheer eenvoudiger vonden.
Over het algemeen geldt: als u op zoek bent naar extreme netwerkprestaties en schaalbaarheid, is een gedistribueerde aanpak de beste keuze. Als uw budget beperkt is en uw managementteam onvoldoende ervaring heeft, is een gecentraliseerde aanpak praktischer. In de toekomst, met de opkomst van 5G en edge computing, zullen gedistribueerde netwerken populairder worden, maar gecentraliseerde netwerken zullen nog steeds waardevol zijn in specifieke scenario's, zoals de verbinding tussen vestigingen.
Mylinking™ Netwerkpakketbrokersondersteuning voor VxLAN, VLAN, GRE, MPLS Header Stripping
Ondersteunt de VxLAN-, VLAN-, GRE- en MPLS-header verwijderd uit het oorspronkelijke datapakket en doorgestuurde uitvoer.
Plaatsingstijd: 09-10-2025
