For å diskutere VXLAN-gatewayer, må vi først diskutere selve VXLAN. Husk at tradisjonelle VLAN-er (Virtual Local Area Networks) bruker 12-bits VLAN-ID-er for å dele nettverk, og støtter opptil 4096 logiske nettverk. Dette fungerer fint for små nettverk, men i moderne datasentre, med sine tusenvis av virtuelle maskiner, containere og miljøer med flere leietakere, er VLAN-er utilstrekkelige. VXLAN ble født, definert av Internet Engineering Task Force (IETF) i RFC 7348. Hensikten er å utvide kringkastingsdomenet for lag 2 (Ethernet) over lag 3 (IP)-nettverk ved hjelp av UDP-tunneler.
Enkelt sagt innkapsler VXLAN Ethernet-rammer i UDP-pakker og legger til en 24-bits VXLAN Network Identifier (VNI), som teoretisk støtter 16 millioner virtuelle nettverk. Dette er som å gi hvert virtuelt nettverk et "identitetskort", slik at de kan bevege seg fritt på det fysiske nettverket uten å forstyrre hverandre. Kjernekomponenten i VXLAN er VXLAN Tunnel End Point (VTEP), som er ansvarlig for å innkapsle og dekapsle pakker. VTEP kan være programvare (som Open vSwitch) eller maskinvare (som ASIC-brikken på svitsjen).
Hvorfor er VXLAN så populært? Fordi det passer perfekt til behovene til skytjenester og SDN (programvaredefinerte nettverk). I offentlige skyer som AWS og Azure muliggjør VXLAN sømløs utvidelse av leietakeres virtuelle nettverk. I private datasentre støtter det overlappende nettverksarkitekturer som VMware NSX eller Cisco ACI. Se for deg et datasenter med tusenvis av servere, som hver kjører dusinvis av VM-er (virtuelle maskiner). VXLAN lar disse VM-ene oppfatte seg selv som en del av det samme Layer 2-nettverket, noe som sikrer jevn overføring av ARP-kringkastinger og DHCP-forespørsler.
VXLAN er imidlertid ikke et universalmiddel. Å operere på et L3-nettverk krever L2-til-L3-konvertering, og det er her gatewayen kommer inn i bildet. VXLAN-gatewayen kobler det virtuelle VXLAN-nettverket til eksterne nettverk (som tradisjonelle VLAN-er eller IP-rutingsnettverk), og sikrer at data flyter fra den virtuelle verden til den virkelige verden. Videresendingsmekanismen er hjertet og sjelen til gatewayen, og bestemmer hvordan pakker behandles, rutes og distribueres.
VXLAN-videresendingsprosessen er som en delikat ballett, der hvert trinn fra kilde til destinasjon er tett knyttet sammen. La oss gå gjennom det trinn for trinn.
Først sendes en pakke fra kildeverten (for eksempel en virtuell maskin). Dette er en standard Ethernet-ramme som inneholder kilde-MAC-adressen, destinasjons-MAC-adressen, VLAN-taggen (hvis noen) og nyttelasten. Når kilde-VTEP-en mottar denne rammen, sjekker den destinasjons-MAC-adressen. Hvis destinasjons-MAC-adressen er i MAC-tabellen (hentet gjennom læring eller oversvømmelse), vet den hvilken ekstern VTEP den skal videresende pakken til.
Innkapslingsprosessen er avgjørende: VTEP legger til en VXLAN-header (inkludert VNI, flagg og så videre), deretter en ytre UDP-header (med en kildeport basert på en hash av den indre rammen og en fast destinasjonsport på 4789), en IP-header (med kilde-IP-adressen til den lokale VTEP og destinasjons-IP-adressen til den eksterne VTEP), og til slutt en ytre Ethernet-header. Hele pakken vises nå som en UDP/IP-pakke, ser ut som normal trafikk og kan rutes på L3-nettverket.
På det fysiske nettverket videresendes pakken av en ruter eller svitsj til den når destinasjons-VTEP. Destinasjons-VTEP fjerner den ytre headeren, sjekker VXLAN-headeren for å sikre at VNI samsvarer, og leverer deretter den indre Ethernet-rammen til destinasjonsverten. Hvis pakken er ukjent unicast-, kringkastings- eller multicast-trafikk (BUM), replikerer VTEP pakken til alle relevante VTEP-er ved hjelp av flooding, avhengig av multicast-grupper eller unicast-headerreplikasjon (HER).
Kjernen i videresendingsprinsippet er separasjonen av kontrollplanet og dataplanet. Kontrollplanet bruker Ethernet VPN (EVPN) eller Flood and Learn-mekanismen for å lære MAC- og IP-tilordninger. EVPN er basert på BGP-protokollen og lar VTEP-er utveksle rutingsinformasjon, for eksempel MAC-VRF (Virtual Routing and Forwarding) og IP-VRF. Dataplanet er ansvarlig for faktisk videresending, ved hjelp av VXLAN-tunneler for effektiv overføring.
I faktiske utrullinger påvirker imidlertid videresendingseffektiviteten ytelsen direkte. Tradisjonell flom kan lett forårsake kringkastingsstormer, spesielt i store nettverk. Dette fører til behov for gatewayoptimalisering: gatewayer kobler ikke bare sammen interne og eksterne nettverk, men fungerer også som proxy ARP-agenter, håndterer rutelekkasjer og sikrer de korteste videresendingsveiene.
Sentralisert VXLAN-gateway
En sentralisert VXLAN-gateway, også kalt en sentralisert gateway eller L3-gateway, distribueres vanligvis i kanten eller kjernelaget av et datasenter. Den fungerer som et sentralt knutepunkt, som all trafikk på tvers av VNI eller subnett må passere gjennom.
I prinsippet fungerer en sentralisert gateway som standard gateway, og tilbyr Layer 3-rutingstjenester for alle VXLAN-nettverk. Tenk deg to VNI-er: VNI 10000 (subnett 10.1.1.0/24) og VNI 20000 (subnett 10.2.1.0/24). Hvis VM A i VNI 10000 ønsker å få tilgang til VM B i VNI 20000, når pakken først den lokale VTEP-en. Den lokale VTEP-en oppdager at destinasjons-IP-adressen ikke er på det lokale subnettet og videresender den til den sentraliserte gatewayen. Gatewayen dekapslerer pakken, tar en rutingsbeslutning og innkapsler deretter pakken på nytt i en tunnel til destinasjons-VNI-en.
Fordelene er åpenbare:
○ Enkel administrasjonAlle rutingskonfigurasjoner er sentralisert på én eller to enheter, slik at operatører bare trenger å vedlikeholde noen få gatewayer for å dekke hele nettverket. Denne tilnærmingen er egnet for små og mellomstore datasentre eller miljøer som distribuerer VXLAN for første gang.
○RessurseffektivGatewayer er vanligvis maskinvare med høy ytelse (som Cisco Nexus 9000 eller Arista 7050) som er i stand til å håndtere enorme mengder trafikk. Kontrollplanet er sentralisert, noe som forenkler integrering med SDN-kontrollere som NSX Manager.
○Sterk sikkerhetskontrollTrafikk må passere gjennom gatewayen, noe som forenkler implementeringen av ACL-er (tilgangskontrolllister), brannmurer og NAT. Tenk deg et scenario med flere leietakere der en sentralisert gateway enkelt kan isolere leietakertrafikk.
Men manglene kan ikke ignoreres:
○ Enkelt feilpunktHvis gatewayen svikter, blir nivå 3-kommunikasjonen på tvers av hele nettverket lammet. Selv om VRRP (Virtual Router Redundancy Protocol) kan brukes til redundans, medfører det fortsatt risikoer.
○YtelsesflaskehalsAll øst-vest-trafikk (kommunikasjon mellom servere) må omgå gatewayen, noe som resulterer i en suboptimal bane. For eksempel, i en klynge med 1000 noder, hvis gateway-båndbredden er 100 Gbps, er det sannsynlig at det vil oppstå overbelastning i rushtiden.
○Dårlig skalerbarhetEtter hvert som nettverksskalaen vokser, øker gateway-belastningen eksponentielt. I et eksempel fra den virkelige verden har jeg sett et finansielt datasenter bruke en sentralisert gateway. I starten kjørte det problemfritt, men etter at antallet virtuelle maskiner doblet seg, økte latensen fra mikrosekunder til millisekunder.
Applikasjonsscenario: Passer for miljøer som krever enkel administrasjon, for eksempel private skyer for bedrifter eller testnettverk. Ciscos ACI-arkitektur bruker ofte en sentralisert modell, kombinert med en leaf-spine-topologi, for å sikre effektiv drift av kjernegatewayer.
Distribuert VXLAN-gateway
En distribuert VXLAN-gateway, også kjent som en distribuert gateway eller anycast-gateway, avlaster gateway-funksjonalitet til hver leaf-svitsj eller hypervisor VTEP. Hver VTEP fungerer som en lokal gateway og håndterer L3-videresending for det lokale delnettet.
Prinsippet er mer fleksibelt: hver VTEP er konfigurert med samme virtuelle IP-adresse (VIP) som standardgatewayen, ved hjelp av Anycast-mekanismen. Kryssnettpakker sendt av virtuelle maskiner rutes direkte på den lokale VTEP-en, uten å måtte gå gjennom et sentralt punkt. EVPN er spesielt nyttig her: gjennom BGP EVPN lærer VTEP-en rutene til eksterne verter og bruker MAC/IP-binding for å unngå ARP-flom.
For eksempel ønsker VM A (10.1.1.10) tilgang til VM B (10.2.1.10). Standardgatewayen til VM A er VIP-en til den lokale VTEP-en (10.1.1.1). Den lokale VTEP-en ruter til målnettet, innkapsler VXLAN-pakken og sender den direkte til VM Bs VTEP. Denne prosessen minimerer banen og ventetiden.
Enestående fordeler:
○ Høy skalerbarhetÅ distribuere gateway-funksjonalitet til hver node øker nettverksstørrelsen, noe som er fordelaktig for større nettverk. Store skyleverandører som Google Cloud bruker en lignende mekanisme for å støtte millioner av virtuelle maskiner.
○Overlegen ytelseØst-vest-trafikk behandles lokalt for å unngå flaskehalser. Testdata viser at gjennomstrømningen kan øke med 30–50 % i distribuert modus.
○Rask feilgjenopprettingEn enkelt VTEP-feil påvirker bare den lokale verten, og andre noder påvirkes ikke. Kombinert med EVPNs raske konvergens er gjenopprettingstiden sekunder.
○God bruk av ressurserBruk den eksisterende Leaf-switch ASIC-brikken for maskinvareakselerasjon, med videresendingshastigheter som når Tbps-nivå.
Hva er ulempene?
○ Kompleks konfigurasjonHver VTEP krever konfigurasjon av ruting, EVPN og andre funksjoner, noe som gjør den første utrullingen tidkrevende. Driftsteamet må være kjent med BGP og SDN.
○Høye maskinvarekravDistribuert gateway: Ikke alle svitsjer støtter distribuerte gatewayer; Broadcom Trident- eller Tomahawk-brikker er påkrevd. Programvareimplementeringer (som OVS på KVM) fungerer ikke like bra som maskinvare.
○KonsistensutfordringerDistribuert betyr at tilstandssynkronisering er avhengig av EVPN. Hvis BGP-økten svinger, kan det forårsake et svart hull i ruting.
Applikasjonsscenario: Perfekt for hyperskala datasentre eller offentlige skyer. VMware NSX-Ts distribuerte ruter er et typisk eksempel. Kombinert med Kubernetes støtter den sømløst containernettverk.
Sentralisert VxLAN-gateway vs. distribuert VxLAN-gateway
Nå til klimaks: hvilken er best? Svaret er «det kommer an på», men vi må grave dypt i dataene og casestudiene for å overbevise deg.
Fra et ytelsesperspektiv yter distribuerte systemer klart bedre. I en typisk datasenterbenchmark (basert på Spirent-testutstyr) var den gjennomsnittlige latensen for en sentralisert gateway 150 μs, mens den for et distribuert system bare var 50 μs. Når det gjelder gjennomstrømning, kan distribuerte systemer enkelt oppnå linjehastighetsvideresending fordi de bruker Spine-Leaf Equal Cost Multi-Path (ECMP)-ruting.
Skalerbarhet er en annen kamparena. Sentraliserte nettverk er egnet for nettverk med 100–500 noder; utover denne skalaen får distribuerte nettverk overtaket. Ta for eksempel Alibaba Cloud. Deres VPC (Virtual Private Cloud) bruker distribuerte VXLAN-gatewayer for å støtte millioner av brukere over hele verden, med en enkeltregionsforsinkelse på under 1 ms. En sentralisert tilnærming ville ha kollapset for lenge siden.
Hva med kostnader? En sentralisert løsning tilbyr lavere initial investering, og krever bare noen få avanserte gatewayer. En distribuert løsning krever at alle bladnoder støtter VXLAN-avlastning, noe som fører til høyere kostnader for maskinvareoppgradering. I det lange løp tilbyr imidlertid en distribuert løsning lavere drifts- og vedlikeholdskostnader, ettersom automatiseringsverktøy som Ansible muliggjør batchkonfigurasjon.
Sikkerhet og pålitelighet: Sentraliserte systemer legger til rette for sentralisert beskyttelse, men utgjør en høy risiko for enkeltstående angrepspunkter. Distribuerte systemer er mer robuste, men krever et robust kontrollplan for å forhindre DDoS-angrep.
En casestudie fra den virkelige verden: Et e-handelsselskap brukte sentralisert VXLAN til å bygge nettstedet sitt. I perioder med høy trafikk økte CPU-bruken til gatewayen til 90 %, noe som førte til brukerklager om latens. Å bytte til en distribuert modell løste problemet, slik at selskapet enkelt kunne doble skalaen sin. Omvendt insisterte en liten bank på en sentralisert modell fordi de prioriterte samsvarsrevisjoner og syntes sentralisert administrasjon var enklere.
Generelt sett, hvis du er ute etter ekstrem nettverksytelse og skala, er en distribuert tilnærming veien å gå. Hvis budsjettet ditt er begrenset og ledergruppen din mangler erfaring, er en sentralisert tilnærming mer praktisk. I fremtiden, med fremveksten av 5G og edge computing, vil distribuerte nettverk bli mer populære, men sentraliserte nettverk vil fortsatt være verdifulle i spesifikke scenarier, for eksempel sammenkobling av avdelingskontorer.
Mylinking™ Nettverkspakkemeglerestøtter VxLAN, VLAN, GRE, MPLS Header-stripping
Støttet VxLAN-, VLAN-, GRE- og MPLS-headeren som ble fjernet i den originale datapakken og videresendt utgang.
Publisert: 09. oktober 2025
