В vorig nummer Ik heb het netwerkautomatiseringsframework beschreven. Volgens sommige mensen heeft zelfs deze eerste benadering van het probleem al een aantal vragen opgelost. En daar word ik heel blij van, want ons doel in de cyclus is niet om de Ansible te verdoezelen met Python-scripts, maar om een ​​systeem te bouwen.

Hetzelfde raamwerk bepaalt de volgorde waarin we de vraag zullen behandelen.
En netwerkvirtualisatie, waar dit nummer aan gewijd is, past niet bepaald in het ADSM-onderwerp, waar we automatisering analyseren.

Maar laten we het vanuit een andere hoek bekijken.

Veel diensten maken al lange tijd gebruik van hetzelfde netwerk. In het geval van een telecomoperator is dit bijvoorbeeld 2G, 3G, LTE, breedband en B2B. In het geval van een DC: connectiviteit voor verschillende clients, internet, blokopslag, objectopslag.

En alle diensten vereisen isolatie van elkaar. Dit is hoe overlay-netwerken verschenen.

En alle services willen niet wachten tot iemand ze handmatig configureert. Dit is hoe orkestrators en SDN verschenen.

De eerste aanpak voor systematische automatisering van het netwerk, of beter gezegd een deel ervan, wordt al lang op veel plaatsen gevolgd en geïmplementeerd: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Dat is waar we het vandaag over zullen hebben.

Inhoud

• redenen
• terminologie
• Onderlaag - fysiek netwerk
• Overlay - virtueel netwerk
  • Overlay met ToR
  • Overlay van host
  • Gebruik wolfraamstof als voorbeeld
    • Communicatie binnen één enkele fysieke machine
    • Communicatie tussen VM's die zich op verschillende fysieke machines bevinden
    • Uitgang naar de buitenwereld

• FAQ
• Conclusie
• Nuttige links

redenen

En aangezien we het hierover hebben, is het de moeite waard om de vereisten voor netwerkvirtualisatie te vermelden. In feite is dit proces niet gisteren begonnen.

Je hebt waarschijnlijk meer dan eens gehoord dat het netwerk altijd het meest inerte onderdeel van welk systeem dan ook is geweest. En dit geldt in alle opzichten. Het netwerk is de basis waarop alles rust, en het aanbrengen van wijzigingen daarin is behoorlijk moeilijk - diensten tolereren het niet als het netwerk uitvalt. Vaak kan het buiten gebruik stellen van een enkel knooppunt een groot deel van de applicaties uitschakelen en gevolgen hebben voor veel klanten. Dit is gedeeltelijk de reden waarom het netwerkteam zich tegen elke verandering kan verzetten - omdat het nu op de een of andere manier werkt (we weten misschien niet eens hoe), maar hier moet je iets nieuws configureren, en het is onbekend welke invloed dit op het netwerk zal hebben.

Om niet te wachten tot netwerkers VLAN's invoegen en geen diensten op elk netwerkknooppunt te registreren, kwamen mensen op het idee om overlays - overlay-netwerken - te gebruiken waarvan er een grote verscheidenheid is: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, enz.

Hun aantrekkingskracht ligt in twee simpele dingen:

• Alleen eindknooppunten zijn geconfigureerd; transitknooppunten hoeven niet te worden aangeraakt. Dit versnelt het proces aanzienlijk en stelt u soms in staat de afdeling netwerkinfrastructuur volledig uit te sluiten van het proces van het introduceren van nieuwe diensten.
• De belasting is diep in de headers verborgen - transitknooppunten hoeven er niets van te weten, over de adressering op de hosts of over de routes van het overlay-netwerk. Dit betekent dat u minder informatie in tabellen hoeft op te slaan, wat betekent dat u een eenvoudiger/goedkoper apparaat moet gebruiken.

In deze niet geheel volwaardige kwestie ben ik niet van plan alle mogelijke technologieën te analyseren, maar eerder het raamwerk te beschrijven voor de werking van overlay-netwerken in DC's.

De hele serie beschrijft een datacenter dat bestaat uit rijen identieke racks waarin dezelfde serverapparatuur is geïnstalleerd.

Deze apparatuur voert virtuele machines/containers/serverless uit die services implementeren.

terminologie

In een cyclus server Ik zal een programma noemen dat de serverkant van client-servercommunicatie implementeert.

Fysieke machines in racks worden servers genoemd geen wij zullen.

Fysieke machine — x86-computer geïnstalleerd in een rek. De meest gebruikte term gastheer. Zo zullen we het noemen “machine"of gastheer.

Hypervisor — een applicatie die draait op een fysieke machine en die de fysieke bronnen emuleert waarop virtuele machines draaien. Soms wordt in de literatuur en op internet het woord ‘hypervisor’ gebruikt als synoniem voor ‘host’.

Virtuele machine - een besturingssysteem dat draait op een fysieke machine bovenop een hypervisor. Voor ons in deze cyclus maakt het niet echt uit of het daadwerkelijk een virtuele machine is of gewoon een container. Laten we het noemen "VM«

Huurder is een breed begrip dat ik in dit artikel zal definiëren als een aparte dienst of een aparte klant.

Multi-tenancy of multitenancy - het gebruik van dezelfde applicatie door verschillende klanten/diensten. Tegelijkertijd wordt de isolatie van clients van elkaar bereikt dankzij de applicatiearchitectuur, en niet door afzonderlijk draaiende instances.

ToR — Top of the Rack-schakelaar - een switch geïnstalleerd in een rack waarop alle fysieke machines zijn aangesloten.

Naast de ToR-topologie hanteren verschillende providers End of Row (EoR) of Middle of Row (hoewel dit laatste een kleinerende zeldzaamheid is en ik de MoR-afkorting niet heb gezien).

Onderliggend netwerk of het onderliggende netwerk of de onderlaag is de fysieke netwerkinfrastructuur: switches, routers, kabels.

Overlay-netwerk of overlay-netwerk of overlay - een virtueel netwerk van tunnels dat bovenop de fysieke tunnel loopt.

L3-stof of IP-stof - een geweldige uitvinding van de mensheid waarmee je kunt voorkomen dat je STP herhaalt en TRILL leert voor interviews. Een concept waarbij het hele netwerk tot aan het toegangsniveau uitsluitend L3 is, zonder VLAN's en dus enorme uitgebreide broadcastdomeinen. In het volgende deel zullen we onderzoeken waar het woord ‘fabriek’ vandaan komt.

SDN - Softwaregedefinieerd netwerk. Behoeft nauwelijks een introductie. Een benadering van netwerkbeheer waarbij wijzigingen in het netwerk niet door een persoon worden aangebracht, maar door een programma. Meestal betekent dit dat het besturingsvlak voorbij de eindnetwerkapparaten naar de controller wordt verplaatst.

NFV - Netwerkfunctievirtualisatie - virtualisatie van netwerkapparaten, wat erop wijst dat sommige netwerkfuncties kunnen worden uitgevoerd in de vorm van virtuele machines of containers om de implementatie van nieuwe services te versnellen, Service Chaining te organiseren en de horizontale schaalbaarheid te vereenvoudigen.

VNF - Virtuele netwerkfunctie. Specifiek virtueel apparaat: router, switch, firewall, NAT, IPS/IDS, etc.

Ik vereenvoudig nu bewust de beschrijving tot een specifieke implementatie, om de lezer niet te veel in verwarring te brengen. Voor meer doordachte lectuur verwijs ik hem naar de paragraaf referenties. Bovendien belooft Roma Gorge, die dit artikel bekritiseert vanwege onnauwkeurigheden, een apart nummer te schrijven over server- en netwerkvirtualisatietechnologieën, diepgaander en met aandacht voor detail.

De meeste netwerken van vandaag kunnen duidelijk in twee delen worden opgesplitst:

underlay — een fysiek netwerk met een stabiele configuratie.
Bedekking — abstractie over Underlay voor het isoleren van huurders.

Dit geldt zowel voor het geval van DC (dat we in dit artikel zullen analyseren) als voor ISP (wat we niet zullen analyseren, omdat dit al is gebeurd). SDSM). Bij bedrijfsnetwerken is de situatie uiteraard enigszins anders.

Foto met focus op het netwerk:

underlay

Onderlaag is een fysiek netwerk: hardwareschakelaars en kabels. Apparaten in de metro weten hoe ze fysieke machines moeten bereiken.

Het is afhankelijk van standaardprotocollen en technologieën. Niet in de laatste plaats omdat hardwareapparaten tot op de dag van vandaag werken met propriëtaire software die het programmeren van de chip of het implementeren van eigen protocollen niet toestaat; daarom zijn compatibiliteit met andere leveranciers en standaardisatie nodig.

Maar iemand als Google kan het zich veroorloven zijn eigen schakelaars te ontwikkelen en algemeen aanvaarde protocollen achterwege te laten. Maar LAN_DC is niet Google.

Underlay verandert relatief zelden omdat het doel ervan is de basis-IP-connectiviteit tussen fysieke machines. Underlay weet niets van de services, clients of tenants die er bovenop draaien; het hoeft alleen het pakket van de ene machine naar de andere te leveren.
Ondervloer zou er zo uit kunnen zien:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

Het Underlay-netwerk is op de klassieke manier geconfigureerd: CLI/GUI/NETCONF.

Handmatig, scripts, eigen hulpprogramma's.

Het volgende artikel in de serie gaat dieper in op de ondervloer.

Bedekking

Overlay is een virtueel netwerk van tunnels dat zich over Underlay uitstrekt. Het stelt VM's van de ene client in staat met elkaar te communiceren en tegelijkertijd isolatie van andere clients te bieden.

De klantgegevens zijn ingekapseld in een aantal tunnelheaders voor verzending via het openbare netwerk.

Dus VM's van één client (één service) kunnen via Overlay met elkaar communiceren, zonder zelfs maar te weten welk pad het pakket daadwerkelijk volgt.

Overlay zou bijvoorbeeld kunnen zijn zoals ik hierboven vermeldde:

• GRE-tunnel
• VXLAN
• EVPN
• L3VPN
• GENEVA

Een overlay-netwerk wordt doorgaans geconfigureerd en onderhouden via een centrale controller. Van daaruit worden de configuratie, Control Plane en Data Plane geleverd aan apparaten die clientverkeer routeren en inkapselen. Een beetje beneden Laten we dit met voorbeelden bekijken.

Ja, dit is SDN in zijn puurste vorm.

Er zijn twee fundamenteel verschillende benaderingen voor het organiseren van een Overlay-netwerk:

1. Overlay met ToR
2. Overlay van host

Overlay met ToR

Overlay kan beginnen bij de toegangsschakelaar (ToR) die in het rack staat, zoals bijvoorbeeld gebeurt bij een VXLAN-fabric.

Dit is een beproefd mechanisme op ISP-netwerken en alle leveranciers van netwerkapparatuur ondersteunen het.

In dit geval moet de ToR-switch echter de verschillende diensten kunnen scheiden en moet de netwerkbeheerder tot op zekere hoogte samenwerken met de beheerders van de virtuele machines en wijzigingen (zij het automatisch) aanbrengen in de configuratie van de apparaten. .

Hier verwijs ik de lezer naar een artikel over VxLAN op Habré onze oude vriend @bormoglotx.
In deze presentaties met ENOG De benaderingen voor het bouwen van een DC-netwerk met een EVPN VXLAN-fabric worden in detail beschreven.

En voor een completere onderdompeling in de werkelijkheid kun je het boek van Tsiska lezen Een moderne, open en schaalbare structuur: VXLAN EVPN.

Ik merk op dat VXLAN slechts een inkapselingsmethode is en dat het beëindigen van tunnels niet op ToR kan plaatsvinden, maar op de host, zoals bijvoorbeeld gebeurt in het geval van OpenStack.

VXLAN-fabric, waarbij de overlay begint bij ToR, is echter een van de gevestigde overlay-netwerkontwerpen.

Overlay van host

Een andere benadering is het starten en beëindigen van tunnels op de eindhosts.
In dit geval blijft het netwerk (Underlay) zo eenvoudig en statisch mogelijk.
En de host zelf doet alle noodzakelijke inkapseling.

Hiervoor is uiteraard een speciale applicatie op de hosts nodig, maar het is de moeite waard.

Ten eerste is het draaien van een client op een Linux-machine eenvoudiger of, laten we zeggen, zelfs mogelijk, terwijl je op een switch hoogstwaarschijnlijk je zult moeten wenden tot propriëtaire SDN-oplossingen, wat het idee van multi-vendor teniet doet.

Ten tweede kan de ToR-switch in dit geval zo eenvoudig mogelijk worden gelaten, zowel vanuit het oogpunt van het besturingsvlak als het datavlak. Dan hoeft het inderdaad niet te communiceren met de SDN-controller, en hoeft het ook niet de netwerken/ARP’s van alle aangesloten clients op te slaan – het is voldoende om het IP-adres van de fysieke machine te kennen, wat het schakelen/ routeringstabellen.

In de ADSM-serie kies ik voor de overlay-aanpak van de host - dan praten we er alleen over en keren we niet terug naar de VXLAN-fabriek.

Het is het gemakkelijkst om naar voorbeelden te kijken. En als proefpersoon nemen we het OpenSource SDN-platform OpenContrail, nu bekend als Wolfraam stof.

Aan het einde van het artikel zal ik enkele gedachten geven over de analogie met OpenFlow en OpenvSwitch.

Gebruik wolfraamstof als voorbeeld

Elke fysieke machine heeft vRouter - een virtuele router die weet welke netwerken erop zijn aangesloten en tot welke clients ze behoren - in wezen een PE-router. Voor elke client wordt een geïsoleerde routeringstabel bijgehouden (lees VRF). En vRouter doet eigenlijk Overlay-tunneling.

Aan het einde van het artikel vindt u iets meer over vRouter.

Elke VM op de hypervisor is via een verbinding met de vRouter van deze machine verbonden TAP-interface.

TAP - Terminal Access Point - een virtuele interface in de Linux-kernel die netwerkinteractie mogelijk maakt.

Als er meerdere netwerken achter de vRouter staan, wordt voor elk daarvan een virtuele interface gemaakt, waaraan een IP-adres wordt toegewezen - dit zal het standaard gateway-adres zijn.
Alle netwerken van één client worden in één geplaatst VRF-extensie (één tafel), verschillende - in verschillende.
Ik zal hier een disclaimer maken dat niet alles zo eenvoudig is, en ik zal de nieuwsgierige lezer naar het einde van het artikel sturen.

Zodat vRouters met elkaar kunnen communiceren, en dienovereenkomstig met de VM's die zich achter hen bevinden, wisselen ze routeringsinformatie uit via SDN-controller.

Om naar de buitenwereld te gaan, is er een uitgangspunt uit de matrix: een virtuele netwerkgateway VNGW - Virtuele netwerkgateway (mijn termijn).

Laten we nu eens kijken naar voorbeelden van communicatie - en er zal duidelijkheid zijn.

Communicatie binnen één enkele fysieke machine

VM0 wil een pakket naar VM2 sturen. Laten we voorlopig aannemen dat dit een VM met één client is.

Gegevensvlak

1. VM-0 heeft een standaardroute naar zijn eth0-interface. Het pakket wordt daarheen gestuurd.
   Deze interface eth0 is feitelijk virtueel verbonden met de virtuele router vRouter via de TAP-interface tap0.
2. vRouter analyseert naar welke interface het pakket is gekomen, dat wil zeggen tot welke client (VRF) het behoort, en controleert het adres van de ontvanger met de routeringstabel van deze client.
3. Nadat vRouter heeft gedetecteerd dat de ontvanger op dezelfde machine zich op een andere poort bevindt, verzendt hij het pakket er eenvoudigweg naartoe, zonder extra headers. In dit geval heeft vRouter al een ARP-vermelding.

In dit geval komt het pakket niet in het fysieke netwerk terecht, maar wordt het binnen de vRouter gerouteerd.

Controle vliegtuig

Wanneer de virtuele machine start, vertelt de hypervisor het volgende:

• Haar eigen IP-adres.
• De standaardroute loopt via het IP-adres van de vRouter op dit netwerk.

De hypervisor rapporteert aan vRouter via een speciale API:

• Wat je nodig hebt om een ​​virtuele interface te creëren.
• Wat voor soort virtueel netwerk moet het (VM) creëren?
• Aan welke VRF (VN) het moet worden gebonden.
• Een statische ARP-vermelding voor deze VM: welke interface zich achter het IP-adres bevindt en aan welk MAC-adres deze is gekoppeld.

Opnieuw wordt de feitelijke interactieprocedure vereenvoudigd om het concept te begrijpen.

vRouter beschouwt dus alle VM's van één client op een bepaalde machine als rechtstreeks verbonden netwerken en kan er zelf een route tussen maken.

Maar VM0 en VM1 behoren tot verschillende clients en bevinden zich dienovereenkomstig in verschillende vRouter-tabellen.

Of ze rechtstreeks met elkaar kunnen communiceren, hangt af van de vRouter-instellingen en het netwerkontwerp.
Als de VM's van beide clients bijvoorbeeld openbare adressen gebruiken, of als NAT op de vRouter zelf plaatsvindt, kan directe routering naar de vRouter worden uitgevoerd.

In de tegenovergestelde situatie is het mogelijk om adresruimten te kruisen - je moet via een NAT-server gaan om een ​​openbaar adres te krijgen - dit is vergelijkbaar met toegang krijgen tot externe netwerken, die hieronder worden besproken.

Communicatie tussen VM's die zich op verschillende fysieke machines bevinden

Gegevensvlak

1. Het begin is precies hetzelfde: VM-0 verzendt een pakket met standaard de bestemming VM-7 (172.17.3.2).
2. vRouter ontvangt het en ziet deze keer dat de bestemming zich op een andere machine bevindt en toegankelijk is via Tunnel0.
3. Ten eerste hangt er een MPLS-label aan dat de externe interface identificeert, zodat vRouter aan de andere kant kan bepalen waar dit pakket moet worden geplaatst zonder extra zoekopdrachten.

   

4. Tunnel0 heeft bron 10.0.0.2, bestemming: 10.0.1.2.
   vRouter voegt GRE (of UDP) headers en een nieuw IP-adres toe aan het oorspronkelijke pakket.
5. De vRouter-routeringstabel heeft een standaardroute via het ToR1-adres 10.0.0.1. Daar stuurt hij het heen.

   
   

6. ToR1 weet als lid van het Underlay-netwerk (bijvoorbeeld via OSPF) hoe hij bij 10.0.1.2 moet komen en stuurt het pakket langs de route. Merk op dat ECMP hier is ingeschakeld. Er zijn twee nexthops in de illustratie en verschillende threads worden daarin op hash gesorteerd. In het geval van een echte fabriek zijn er waarschijnlijker 4 nexthops.

   Tegelijkertijd hoeft hij niet te weten wat zich onder de externe IP-header bevindt. Dat wil zeggen dat er onder IP in feite een sandwich kan zijn van IPv6 over MPLS over Ethernet over MPLS over GRE over over Grieks.

7. Dienovereenkomstig verwijdert vRouter aan de ontvangende kant GRE en begrijpt met behulp van de MPLS-tag naar welke interface dit pakket moet worden verzonden, stript het en verzendt het in zijn oorspronkelijke vorm naar de ontvanger.

Controle vliegtuig

Wanneer u de auto start, gebeurt hetzelfde als hierboven beschreven.

En plus het volgende:

• Voor elke client wijst vRouter een MPLS-tag toe. Dit is het L3VPN-servicelabel, waarmee clients binnen dezelfde fysieke machine worden gescheiden.
  

  In feite wordt de MPLS-tag altijd onvoorwaardelijk toegewezen door de vRouter. Het is immers niet op voorhand bekend dat de machine alleen zal communiceren met andere machines achter dezelfde vRouter en dit is hoogstwaarschijnlijk niet eens waar.

• vRouter brengt een verbinding tot stand met de SDN-controller met behulp van het BGP-protocol (of iets soortgelijks - in het geval van TF is dit XMPP 0_o).
• Via deze sessie rapporteert vRouter routes naar verbonden netwerken aan de SDN-controller:
  • Netwerkadres
  • Inkapselingsmethode (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS-clienttag
  • Uw IP-adres als nexthop

• De SDN-controller ontvangt dergelijke routes van alle aangesloten vRouters en geeft deze door aan anderen. Dat wil zeggen, het fungeert als een routereflector.

Hetzelfde gebeurt in de tegenovergestelde richting.

Overlay kan minstens elke minuut veranderen. Dit is ongeveer wat er gebeurt in publieke clouds, waar klanten hun virtuele machines regelmatig opstarten en afsluiten.

De centrale controller zorgt voor alle complexiteit van het onderhouden van de configuratie en het monitoren van de schakel-/routingtabellen op de vRouter.

Grofweg communiceert de controller met alle vRouters via BGP (of een vergelijkbaar protocol) en verzendt eenvoudigweg routeringsinformatie. BGP beschikt bijvoorbeeld al over Address-Family om de inkapselingsmethode over te brengen MPLS-in-GRE of MPLS-in-UDP.

Tegelijkertijd verandert de configuratie van het Underlay-netwerk op geen enkele manier, wat overigens veel moeilijker te automatiseren is en gemakkelijker te doorbreken met een ongemakkelijke beweging.

Uitgang naar de buitenwereld

Ergens moet de simulatie eindigen en moet je de virtuele wereld verlaten en naar de echte gaan. En u hebt een telefooncelgateway nodig.

Er worden twee benaderingen beoefend:

1. Er is een hardwarerouter geïnstalleerd.
2. Er wordt een apparaat gelanceerd dat de functies van een router implementeert (ja, na SDN kwamen we ook VNF tegen). Laten we het een virtuele gateway noemen.

Het voordeel van de tweede benadering is goedkope horizontale schaalbaarheid - er is niet genoeg stroom - we hebben nog een virtuele machine met een gateway gelanceerd. Op elke fysieke machine, zonder te hoeven zoeken naar vrije racks, units, vermogen, de hardware zelf te kopen, te transporteren, te installeren, te schakelen, te configureren en vervolgens ook nog defecte componenten erin te vervangen.

De nadelen van een virtuele gateway zijn dat een eenheid van een fysieke router nog steeds ordes van grootte krachtiger is dan een multi-core virtuele machine, en dat de software, afgestemd op de eigen hardwarebasis, veel stabieler werkt (geen). Het is ook moeilijk te ontkennen dat het hardware- en softwarecomplex gewoon werkt en alleen configuratie vereist, terwijl het lanceren en onderhouden van een virtuele gateway een taak is voor sterke ingenieurs.

Met één voet kijkt de gateway in het virtuele Overlay-netwerk, net als een gewone virtuele machine, en kan communiceren met alle andere VM's. Tegelijkertijd kan het de netwerken van alle clients afsluiten en dienovereenkomstig routering tussen deze clients uitvoeren.

Met zijn andere voet kijkt de gateway in het backbone-netwerk en weet hoe hij op internet moet komen.

Gegevensvlak

Dat wil zeggen, het proces ziet er als volgt uit:

1. VM-0, die standaard dezelfde vRouter gebruikt, stuurt een pakket met een bestemming in de buitenwereld (185.147.83.177) naar de eth0-interface.
2. vRouter ontvangt dit pakket en zoekt het bestemmingsadres op in de routeringstabel - vindt de standaardroute via de VNGW1-gateway via Tunnel 1.
   Hij ziet ook dat dit een GRE-tunnel is met SIP 10.0.0.2 en DIP 10.0.255.2, en hij moet ook eerst het MPLS-label van deze client bevestigen, wat VNGW1 verwacht.
3. vRouter verpakt het initiële pakket met MPLS, GRE en nieuwe IP-headers en verzendt dit standaard naar ToR1 10.0.0.1.
4. Het onderliggende netwerk levert het pakket af aan de gateway VNGW1.
5. De VNGW1-gateway verwijdert de GRE- en MPLS-tunnelingheaders, ziet het bestemmingsadres, raadpleegt de routeringstabel en begrijpt dat het naar internet wordt geleid - dat wil zeggen via Volledige weergave of Standaard. Voert indien nodig een NAT-vertaling uit.
6. Er zou sprake kunnen zijn van een regulier IP-netwerk van VNGW tot aan de grens, wat onwaarschijnlijk is.
   Er kan sprake zijn van een klassiek MPLS-netwerk (IGP+LDP/RSVP TE), er kan sprake zijn van een back fabric met BGP LU of een GRE-tunnel van VNGW naar de grens via een IP-netwerk.
   Hoe het ook zij, VNGW1 voert de nodige inkapselingen uit en stuurt het eerste pakket naar de grens.

Verkeer in tegengestelde richting doorloopt dezelfde stappen in omgekeerde volgorde.

1. De grens laat het pakket naar VNGW1 vallen
2. Hij kleedt hem uit, kijkt naar het adres van de ontvanger en ziet dat hij bereikbaar is via de Tunnel1-tunnel (MPLSoGRE of MPLSoUDP).
3. Dienovereenkomstig voegt het een MPLS-label, een GRE/UDP-header en een nieuw IP-adres toe en stuurt dit naar zijn ToR3 10.0.255.1.
   Het tunnelbestemmingsadres is het IP-adres van de vRouter waarachter de doel-VM zich bevindt - 10.0.0.2.
4. Het onderliggende netwerk levert het pakket af bij de gewenste vRouter.
5. De doel-vRouter leest GRE/UDP, identificeert de interface met behulp van het MPLS-label en verzendt een kaal IP-pakket naar de TAP-interface die is gekoppeld aan eth0 van de VM.

Controle vliegtuig

VNGW1 brengt met een SDN-controller een BGP-buurt tot stand, van waaruit het alle routeringsinformatie over clients ontvangt: welk IP-adres (vRouter) achter welke client zit en door welk MPLS-label het wordt geïdentificeerd.

Op dezelfde manier informeert hij zelf de SDN-controller over de standaardroute met het label van deze client, waarbij hij zichzelf aangeeft als de nexthop. En dan arriveert deze standaard bij vRouters.

Op VNGW vindt meestal routeaggregatie of NAT-vertaling plaats.

En in de andere richting stuurt het precies deze geaggregeerde route naar de sessie met grenzen of Route Reflectors. En van hen ontvangt het de standaardroute of Full-View, of iets anders.

Op het gebied van inkapseling en verkeersuitwisseling verschilt VNGW niet van vRouter.
Als u de reikwijdte een beetje uitbreidt, kunt u andere netwerkapparaten toevoegen aan VNGW's en vRouters, zoals firewalls, verkeersopschonings- of verrijkingsfarms, IPS, enzovoort.

En met behulp van de sequentiële creatie van VRF's en de correcte aankondiging van routes, kunt u het verkeer dwingen de door u gewenste lus te maken, wat Service Chaining wordt genoemd.

Dat wil zeggen dat ook hier de SDN-controller fungeert als Route-Reflector tussen VNGW's, vRouters en andere netwerkapparaten.

Maar feitelijk geeft de verkeersleider ook informatie vrij over ACL en PBR (Policy Based Routing), waardoor individuele verkeersstromen anders verlopen dan de route aangeeft.

FAQ

Waarom blijf je de GRE/UDP-opmerking maken?

Over het algemeen kan worden gezegd dat dit specifiek is voor Tungsten Fabric - u hoeft er helemaal geen rekening mee te houden.

Maar als we ervan uitgaan dat TF zelf, hoewel nog steeds OpenContrail, beide inkapselingen ondersteunde: MPLS in GRE en MPLS in UDP.

UDP is goed omdat het in de bronpoort heel eenvoudig is om een ​​hash-functie van de originele IP+Proto+Port in de header te coderen, waardoor je balancering kunt uitvoeren.

In het geval van GRE zijn er helaas alleen externe IP- en GRE-headers, die hetzelfde zijn voor al het ingekapselde verkeer en er is geen sprake van balanceren - weinig mensen kunnen zo diep in het pakket kijken.

Tot enige tijd deden routers, als ze wisten hoe ze dynamische tunnels moesten gebruiken, dit alleen in MPLSoGRE, en pas zeer recent leerden ze MPLSoUDP te gebruiken. Daarom moeten we altijd rekening houden met de mogelijkheid van twee verschillende inkapselingen.

In alle eerlijkheid is het de moeite waard om op te merken dat TF de L2-connectiviteit volledig ondersteunt met behulp van VXLAN.

U beloofde parallellen te trekken met OpenFlow.
Ze vragen er echt om. vSwitch in dezelfde OpenStack doet zeer vergelijkbare dingen, met behulp van VXLAN, dat trouwens ook een UDP-header heeft.

In het Data Plane werken ze ongeveer hetzelfde; het Control Plane verschilt aanzienlijk. Tungsten Fabric gebruikt XMPP om routeringsinformatie aan vRouter te leveren, terwijl OpenStack Openflow uitvoert.

Kun je me iets meer vertellen over vRouter?
Het is verdeeld in twee delen: vRouter Agent en vRouter Forwarder.

De eerste draait in de gebruikersruimte van het host-besturingssysteem en communiceert met de SDN-controller, waarbij informatie wordt uitgewisseld over routes, VRF's en ACL's.

De tweede implementeert Data Plane - meestal in Kernel Space, maar kan ook op SmartNIC's draaien - netwerkkaarten met een CPU en een afzonderlijke programmeerbare schakelchip, waarmee u de belasting van de CPU van de hostmachine kunt wegnemen en het netwerk sneller en beter kunt maken voorspelbaar.

Een ander mogelijk scenario is dat vRouter een DPDK-applicatie in User Space is.

vRouter Agent verzendt instellingen naar vRouter Forwarder.

Wat is een virtueel netwerk?
Ik vermeldde aan het begin van het artikel over VRF dat elke huurder gebonden is aan zijn eigen VRF. En als dit genoeg was voor een oppervlakkig begrip van de werking van het overlay-netwerk, dan is het bij de volgende iteratie noodzakelijk om opheldering te geven.

Normaal gesproken wordt in virtualisatiemechanismen de virtuele netwerkentiteit (je kunt dit als een eigennaam beschouwen) afzonderlijk van clients/tenants/virtuele machines geïntroduceerd - iets volledig onafhankelijks. En dit virtuele netwerk kan al via interfaces worden verbonden met de ene huurder, met de andere, met twee of waar dan ook. Service Chaining wordt bijvoorbeeld geïmplementeerd wanneer verkeer in de vereiste volgorde door bepaalde knooppunten moet worden geleid, simpelweg door virtuele netwerken in de juiste volgorde te creëren en te verbinden.

Daarom is er als zodanig geen directe correspondentie tussen het virtuele netwerk en de huurder.

Conclusie

Dit is een zeer oppervlakkige beschrijving van de werking van een virtueel netwerk met een overlay van de host en een SDN-controller. Maar welk virtualisatieplatform u vandaag ook kiest, het zal op een vergelijkbare manier werken, of het nu VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric of Juniper Contrail is. Ze zullen verschillen in de soorten inkapselingen en headers, protocollen voor het leveren van informatie aan eindnetwerkapparaten, maar het principe van een softwarematig configureerbaar overlay-netwerk dat opereert bovenop een relatief eenvoudig en statisch onderliggend netwerk zal hetzelfde blijven.
We kunnen zeggen dat SDN, gebaseerd op een overlay-netwerk, vandaag de dag het veld heeft gewonnen van het creëren van een private cloud. Dit betekent echter niet dat Openflow geen plaats heeft in de moderne wereld - het wordt gebruikt in OpenStacke en in dezelfde VMWare NSX, voor zover ik weet gebruikt Google het om het ondergrondse netwerk op te zetten.

Hieronder heb ik links naar meer gedetailleerd materiaal gegeven als je het onderwerp dieper wilt bestuderen.

En hoe zit het met onze ondervloer?

Maar over het algemeen niets. Hij is niet helemaal veranderd. Het enige dat hij hoeft te doen in het geval van een overlay van de host is het bijwerken van routes en ARP's terwijl vRouter/VNGW verschijnt en verdwijnt en pakketten daartussen vervoert.

Laten we een lijst met vereisten voor het Underlay-netwerk opstellen.

1. In onze situatie kunnen we een soort routeringsprotocol gebruiken: BGP.
2. Zorg voor een grote bandbreedte, bij voorkeur zonder overabonnement, zodat er geen pakketten verloren gaan door overbelasting.
3. Ondersteuning van ECMP is een integraal onderdeel van de stof.
4. QoS kunnen bieden, inclusief lastige zaken zoals ECN.
5. Het ondersteunen van NETCONF is een basis voor de toekomst.

Ik heb hier heel weinig tijd besteed aan het werk van het Underlay-netwerk zelf. Dit komt omdat ik me er later in de serie op zal concentreren, en we zullen Overlay slechts terloops bespreken.

Het is duidelijk dat ik ons ​​allemaal ernstig beperk door als voorbeeld een DC-netwerk te gebruiken dat in een Cloz-fabriek is gebouwd met pure IP-routering en een overlay van de host.

Ik ben er echter van overtuigd dat elk netwerk met een ontwerp in formele termen kan worden beschreven en geautomatiseerd. Het is gewoon mijn doel hier om de benaderingen van automatisering te begrijpen, en niet om iedereen in verwarring te brengen door het probleem in een algemene vorm op te lossen.

Als onderdeel van ADSM zijn Roman Gorge en ik van plan een apart nummer te publiceren over de virtualisatie van rekenkracht en de interactie ervan met netwerkvirtualisatie. Blijf in contact.

Nuttige links

• Architectuur van wolfraamstof.
• over: wolk. 6 uur over Yandex.Cloud, dat ook het virtuele netwerk op TF omvat.
• Wat is Open vSwitch?
• Inleiding tot VxLAN.
• RFC 7348. Virtueel eXtensible Local Area Network (VXLAN): een raamwerk voor het overlappen van gevirtualiseerde Layer 2-netwerken over Layer 3-netwerken.
  
• Scaleway-benadering van VXLAN EVPN Fabric. Er wordt gesproken over het gehele DC-netwerk, inclusief Underlay, Overlay, benaderingen van multi-homing en beheer.

Bedankt

• Romeinse Gorga - voormalig host van de linkmeup podcast en nu expert op het gebied van cloudplatforms. Voor opmerkingen en bewerkingen. Welnu, we wachten in de nabije toekomst op zijn diepgaandere artikel over virtualisatie.
• Alexander Sjalimov - mijn collega en expert op het gebied van virtuele netwerkontwikkeling. Voor opmerkingen en bewerkingen.
• Valentin Sinitsyn - mijn collega en expert op het gebied van Tungsten Fabric. Voor opmerkingen en bewerkingen.
• Artjom Tsjernobaai — illustrator linkmeup. Voor KDPV.
• Alexander Limonov. Voor de "automatische" meme.

Bron: www.habr.com