В eelmine number Kirjeldasin võrgu automatiseerimise raamistikku. Mõnede inimeste arvates on isegi see esimene probleemikäsitlus mõne küsimuse juba lahendanud. Ja see teeb mind väga õnnelikuks, sest meie eesmärk tsüklis ei ole Ansible'i Pythoni skriptidega kinni katta, vaid süsteemi ehitada.

Sama raamistik määrab järjekorra, milles me küsimusega tegeleme.
Ja võrgu virtualiseerimine, millele see number on pühendatud, ei sobi eriti ADSM-i teemasse, kus analüüsime automatiseerimist.

Aga vaatame asja teise nurga alt.

Paljud teenused on pikka aega kasutanud sama võrku. Sideoperaatori puhul on selleks näiteks 2G, 3G, LTE, lairiba ja B2B. DC puhul: ühenduvus erinevatele klientidele, Internet, plokksalvestus, objektide salvestamine.

Ja kõik teenused nõuavad üksteisest eraldamist. Nii ilmusid ülekattevõrgud.

Ja kõik teenused ei taha oodata, kuni inimene neid käsitsi konfigureerib. Nii ilmusid orkestraatorid ja SDN.

Esimene lähenemine võrgu või õigemini selle osa süstemaatilisele automatiseerimisele on paljudes kohtades juba ammu kasutusele võetud ja rakendatud: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Sellega me täna tegelemegi.

Sisu

• Põhjustab
• Terminoloogia
• Aluskate – füüsiline võrk
• Ülekate – virtuaalne võrk
  • Ülekate ToR-iga
  • Ülekate hostilt
  • Kasutades näiteks volframkangast
    • Suhtlus ühes füüsilises masinas
    • Side erinevatel füüsilistel masinatel asuvate VM-ide vahel
    • Väljumine välismaailma

• FAQ
• Järeldus
• Kasulikud lingid

Põhjustab

Ja kuna me sellest räägime, tasub mainida võrgu virtualiseerimise eeltingimusi. Tegelikult ei alanud see protsess eile.

Olete ilmselt rohkem kui korra kuulnud, et võrk on alati olnud süsteemi kõige inertsem osa. Ja see on tõsi igas mõttes. Võrk on aluseks, millele kõik toetub ja selles on muudatuste tegemine üsna keeruline – teenused ei talu seda, kui võrk on maas. Sageli võib ühe sõlme dekomisjoneerimine kaotada suure osa rakendustest ja mõjutada paljusid kliente. Osaliselt seetõttu võib võrgumeeskond igasugustele muudatustele vastu seista – sest nüüd see kuidagi toimib (me ei pruugi isegi teada, kuidas), kuid siin peate konfigureerima midagi uut ja pole teada, kuidas see võrku mõjutab.

Et mitte oodata, kuni võrgutootjad VLAN-e sisestavad, ja mitte igas võrgusõlmes ühtegi teenust registreerida, tekkis inimestel idee kasutada ülekatteid - ülekattevõrke -, mida on väga erinevaid: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE jne.

Nende atraktiivsus seisneb kahes lihtsas asjas:

• Konfigureeritakse ainult lõppsõlmed – transpordisõlmi pole vaja puudutada. See kiirendab protsessi märkimisväärselt ja mõnikord võimaldab teil võrguinfrastruktuuri osakond uute teenuste juurutamise protsessist täielikult välja jätta.
• Koormus on peidetud sügavale päiste sisse – transiidisõlmed ei pea sellest, hostides adresseerimisest ega ülekattevõrgu marsruutidest midagi teadma. See tähendab, et peate tabelitesse salvestama vähem teavet, mis tähendab lihtsama/odavama seadme kasutamist.

Selles mitte täiesti täisväärtuslikus väljaandes ei kavatse ma analüüsida kõiki võimalikke tehnoloogiaid, vaid pigem kirjeldada DC-des ülekattevõrkude toimimise raamistikku.

Kogu seeria kirjeldab andmekeskust, mis koosneb identsete riiulite ridadest, kuhu on paigaldatud samad serveriseadmed.

See seade käitab teenuseid rakendavaid virtuaalmasinaid/konteinereid/serverita.

Terminoloogia

Silmuses server Nimetan programmi, mis rakendab kliendi-serveri suhtluse serveripoolt.

Riiulites olevaid füüsilisi masinaid nimetatakse serveriteks ei me teeme.

Füüsiline masin — x86 arvuti, mis on paigaldatud riiulisse. Kõige sagedamini kasutatav termin võõrustaja. Nii me seda nimetame"masin"või võõrustaja.

Hüperviisor - füüsilises masinas töötav rakendus, mis emuleerib füüsilisi ressursse, millel virtuaalmasinad töötavad. Mõnikord kasutatakse kirjanduses ja Internetis sõna "hüperviisor" sõna "host" sünonüümina.

Virtuaalne masin - operatsioonisüsteem, mis töötab hüperviisori peal olevas füüsilises masinas. Meie jaoks selles tsüklis ei ole tegelikult vahet, kas see on tegelikult virtuaalne masin või lihtsalt konteiner. nimetagem seda"VM«

Üürnik on lai mõiste, mida ma selles artiklis määratlen eraldi teenuse või eraldi kliendina.

Mitmekordne üürimine või multirentancy – sama rakenduse kasutamine erinevate klientide/teenuste poolt. Samal ajal saavutatakse klientide üksteisest eraldamine tänu rakenduse arhitektuurile, mitte eraldi töötavate eksemplaride kaudu.

ToR – riiuli ülaosa lüliti - racki paigaldatud lüliti, millega on ühendatud kõik füüsilised masinad.

Lisaks ToR topoloogiale praktiseerivad erinevad pakkujad End of Row (EoR) või Middle of Row (kuigi viimane on halvustav haruldus ja ma pole MoR-i lühendit näinud).

Aluskatte võrk või aluseks olev võrk või aluskate on füüsiline võrgu infrastruktuur: kommutaatorid, ruuterid, kaablid.

Ülekattevõrk või overlay network ehk overlay – virtuaalne tunnelite võrk, mis jookseb füüsilise võrgustiku peal.

L3 kangas või IP kangas - inimkonna hämmastav leiutis, mis võimaldab teil vältida STP kordamist ja TRILL-i õppimist intervjuude jaoks. Kontseptsioon, milles kogu võrk kuni juurdepääsutasemeni on eranditult L3, ilma VLAN-ideta ja vastavalt ka tohutult laiendatud levidomeene. Järgmises osas uurime, kust sõna "vabrik" pärineb.

SDN - Tarkvaraga määratud võrk. Vaevalt tutvustamist vaja. Võrguhalduse lähenemine, kus muudatusi võrgus ei tee mitte inimene, vaid programm. Tavaliselt tähendab see juhtimistasandi viimist võrgu lõppseadmetest kaugemale kontrollerile.

NFV — Võrgufunktsiooni virtualiseerimine – võrguseadmete virtualiseerimine, mis viitab sellele, et mõningaid võrgufunktsioone saab käivitada virtuaalmasinate või konteinerite kujul, et kiirendada uute teenuste juurutamist, korraldada teenuseahelat ja lihtsamat horisontaalset skaleeritavust.

VNF - Virtuaalse võrgu funktsioon. Konkreetne virtuaalne seade: ruuter, lüliti, tulemüür, NAT, IPS/IDS jne.

Lihtsustan nüüd teadlikult kirjeldust konkreetse teostuseni, et lugejat mitte liigselt segadusse ajada. Mõtlikumaks lugemiseks viitan talle jaotisele Viited. Lisaks lubab Roma Gorge, kes kritiseerib seda artiklit ebatäpsuste pärast, kirjutada serveri ja võrgu virtualiseerimistehnoloogiate kohta eraldi numbri, mis on põhjalikum ja detailide suhtes tähelepanelik.

Enamiku võrkude tänapäeval saab selgelt jagada kaheks osaks:

Aluskate — stabiilse konfiguratsiooniga füüsiline võrk.
Overlay — üürnike isoleerimiseks aluskatte võtmine.

See kehtib nii alalisvoolu (mida analüüsime selles artiklis) kui ka Interneti-teenuse pakkuja kohta (mida me ei analüüsi, kuna see on juba tehtud SDSM). Ettevõtlusvõrkudega on olukord muidugi mõnevõrra erinev.

Pilt, mis keskendub võrgule:

Aluskate

Aluskiht on füüsiline võrk: riistvaralülitid ja kaablid. Maa-alused seadmed teavad, kuidas jõuda füüsiliste masinateni.

See tugineb standardsetele protokollidele ja tehnoloogiatele. Vähe sellest, et riistvaraseadmed töötavad tänapäevani patenteeritud tarkvaraga, mis ei võimalda kiipi programmeerida ega oma protokolle rakendada, seetõttu on vaja ühilduvust teiste tootjatega ja standardimist.

Kuid keegi nagu Google võib endale lubada oma lülitite väljatöötamist ja loobuda üldtunnustatud protokollidest. Kuid LAN_DC pole Google.

Aluskate muutub suhteliselt harva, kuna selle ülesanne on põhiline IP-ühenduvus füüsiliste masinate vahel. Underlay ei tea midagi selle peal töötavatest teenustest, klientidest ega rentnikest – tal on vaja pakk vaid ühest masinast teise toimetada.
Aluskate võiks olla selline:

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

Aluskatte võrk on konfigureeritud klassikalisel viisil: CLI/GUI/NETCONF.

Käsitsi, skriptid, patenteeritud utiliidid.

Sarja järgmine artikkel on põhjalikumalt pühendatud aluskattele.

Overlay

Overlay on Underlay peale venitatud tunnelite virtuaalne võrk, mis võimaldab ühe kliendi VM-idel omavahel suhelda, pakkudes samas isolatsiooni teistest klientidest.

Kliendiandmed on avaliku võrgu kaudu edastamiseks kapseldatud mõnesse tunnelipäisesse.

Seega saavad ühe kliendi (ühe teenuse) VM-id üksteisega Overlay kaudu suhelda, isegi teadmata, millist teed pakett tegelikult liigub.

Ülekate võib olla näiteks selline, nagu ma eespool mainisin:

• GRE tunnel
• VXLAN
• EVPN
• L3VPN
• GENEVA

Ülekattevõrk konfigureeritakse ja hooldatakse tavaliselt keskkontrolleri kaudu. Sellest edastatakse konfiguratsioon, juhtimistasand ja andmetasand seadmetesse, mis suunavad ja kapseldavad kliendi liiklust. Natuke allpool Vaatame seda näidetega.

Jah, see on SDN oma puhtaimal kujul.

Ülekattevõrgu korraldamiseks on kaks põhimõtteliselt erinevat lähenemisviisi:

1. Ülekate ToR-iga
2. Ülekate hostilt

Ülekate ToR-iga

Ülekate võib alata riiulil seisvast juurdepääsulülitist (ToR), nagu juhtub näiteks VXLAN-kanga puhul.

See on ISP-võrkudes ajaproovitud mehhanism ja kõik võrguseadmete müüjad toetavad seda.

Sel juhul peab aga ToR-lüliti suutma erinevaid teenuseid vastavalt eraldada ning võrguadministraator peab teatud määral tegema koostööd virtuaalmasina administraatoritega ja tegema (küll automaatselt) seadmete konfiguratsioonis muudatusi. .

Siin viitan lugejale artiklile, mis käsitleb VxLAN on Habré meie vana sõber @bormoglotx.
Selles ettekanded ENOGiga üksikasjalikult kirjeldatakse lähenemisviise alalisvooluvõrgu ehitamiseks EVPN VXLAN-kangaga.

Ja täielikumaks reaalsusesse sukeldumiseks võite lugeda Tsiska raamatut Moodne, avatud ja skaleeritav kangas: VXLAN EVPN.

Märgin, et VXLAN on ainult kapseldamise meetod ja tunnelite lõpetamine võib toimuda mitte ToR-is, vaid hostis, nagu näiteks OpenStacki puhul.

VXLAN-kangas, kus ülekate algab ToR-ist, on aga üks väljakujunenud ülekattevõrgu kujundusi.

Ülekate hostilt

Teine lähenemisviis on tunnelite käivitamine ja lõpetamine lõpphostides.
Sel juhul jääb võrk (Aluskiht) võimalikult lihtsaks ja staatiliseks.
Ja peremees ise teeb kõik vajaliku kapseldamise.

See nõuab muidugi spetsiaalse rakenduse käivitamist hostides, kuid see on seda väärt.

Esiteks on kliendi käivitamine Linuxi masinas lihtsam või, ütleme, isegi võimalik, samas kui lüliti puhul peate suure tõenäosusega pöörduma patenteeritud SDN-lahenduste poole, mis tapab mitme müüja idee.

Teiseks võib ToR-i lüliti sel juhul jätta võimalikult lihtsaks, seda nii juhttasandi kui ka andmetasandi seisukohast. Tõepoolest, siis ei pea ta suhtlema SDN-kontrolleriga, samuti ei pea ta salvestama kõigi ühendatud klientide võrke/ARP-sid – piisab füüsilise masina IP-aadressi teadmisest, mis lihtsustab oluliselt ümberlülitamist/ marsruutimistabelid.

ADSM-i seerias valin hostilt overlay lähenemise - siis me ainult räägime sellest ja me ei pöördu tagasi VXLAN-i tehasesse.

Kõige lihtsam on vaadata näiteid. Ja katsealusena võtame OpenSource SDN platvormi OpenContrail, mida nüüd tuntakse kui Volfram kangas.

Artikli lõpus annan mõned mõtted analoogia kohta OpenFlow ja OpenvSwitchiga.

Kasutades näiteks volframkangast

Igal füüsilisel masinal on vruuter - virtuaalne ruuter, mis teab sellega ühendatud võrke ja millistele klientidele need kuuluvad - sisuliselt PE-ruuter. Iga kliendi jaoks haldab see isoleeritud marsruutimistabelit (loe VRF). Ja vRouter teeb tegelikult Overlay tunneldamist.

Lisateavet vRouteri kohta leiate artikli lõpus.

Iga hüperviisoris asuv VM on selle masina vRouteriga ühendatud kaudu TAP liides.

TAP - Terminali pääsupunkt – virtuaalne liides Linuxi tuumas, mis võimaldab võrguga suhtlemist.

Kui vRouteri taga on mitu võrku, siis luuakse igaühe jaoks virtuaalne liides, millele määratakse IP-aadress – see on vaikimisi lüüsi aadress.
Kõik ühe kliendi võrgud on paigutatud ühte VRF (üks laud), erinevad - erinevatesse.
Teen siinkohal lahtiütlemise, et kõik pole nii lihtne ja saadan uudishimuliku lugeja artikli lõppu.

Et vruuterid saaksid omavahel suhelda ja vastavalt ka nende taga asuvad virtuaalsed masinad, vahetavad nad marsruutimisteavet SDN kontroller.

Välismaailma pääsemiseks on maatriksist väljumispunkt - virtuaalne võrguvärav VNGW - Virtual Network GateWay (minu termin).

Vaatame nüüd kommunikatsiooni näiteid - ja siis saab selgust.

Suhtlus ühes füüsilises masinas

VM0 soovib saata paketi VM2-le. Oletame praegu, et tegemist on ühe kliendi VM-iga.

Andmetasand

1. VM-0-l on vaikemarsruut eth0 liideseni. Pakk saadetakse sinna.
   See liides eth0 on tegelikult TAP-liidese tap0 kaudu virtuaalselt ühendatud virtuaalse ruuteri vRouteriga.
2. vRouter analüüsib, millisele liidesele pakett tuli, st millisele kliendile (VRF) see kuulub, ja kontrollib adressaadi aadressi selle kliendi marsruutimistabeliga.
3. Olles tuvastanud, et samas masinas olev adressaat on teises pordis, saadab vRouter paketi talle lihtsalt ilma täiendavate päisteta – sellisel juhul on vRouteril juba ARP-kirje.

Sellisel juhul pakett füüsilisse võrku ei sisene – see suunatakse vRouteri sees.

Juhtplaat

Kui virtuaalmasin käivitub, ütleb hüperviisor sellele:

• Tema enda IP-aadress.
• Vaikimisi marsruut läbib selles võrgus oleva vRouteri IP-aadressi.

Hüperviisor annab vRouterile aru spetsiaalse API kaudu:

• Mida on vaja virtuaalse liidese loomiseks.
• Millist virtuaalset võrku see (VM) peab looma?
• Millise VRF-iga (VN) see siduda.
• Selle VM-i staatiline ARP-kirje – milline liides on selle IP-aadressi taga ja millise MAC-aadressiga see on seotud.

Jällegi on tegelik interaktsiooniprotseduur kontseptsiooni mõistmise huvides lihtsustatud.

Seega näeb vRouter kõiki ühe kliendi VM-e antud masinas otse ühendatud võrkudena ja saab ise nende vahel marsruutida.

Kuid VM0 ja VM1 kuuluvad erinevatele klientidele ja on vastavalt erinevatesse vRouteri tabelitesse.

See, kas nad saavad omavahel suhelda, sõltub otseselt vRouteri sätetest ja võrgukujundusest.
Näiteks kui mõlema kliendi VM-id kasutavad avalikke aadresse või NAT esineb vRouteris endas, saab teha otse marsruutimise vRouterisse.

Vastupidises olukorras on võimalik aadressiruume ületada - avaliku aadressi saamiseks peate läbima NAT-serveri - see sarnaneb juurdepääsuga välistele võrkudele, millest on juttu allpool.

Side erinevatel füüsilistel masinatel asuvate VM-ide vahel

Andmetasand

1. Algus on täpselt sama: VM-0 saadab paketi vaikimisi sihtpunktiga VM-7 (172.17.3.2).
2. vRouter võtab selle vastu ja näeb seekord, et sihtkoht asub teises masinas ja on juurdepääsetav Tunnel0 kaudu.
3. Esiteks riputab see MPLS-i sildi, mis tuvastab kaugliidese, nii et vRouter saab tagaküljel ilma täiendavate otsinguteta määrata, kuhu see pakett paigutada.

   

4. Tunnel0 allikas on 10.0.0.2, sihtkoht: 10.0.1.2.
   vRouter lisab algsele paketile GRE (või UDP) päised ja uue IP.
5. VRouteri marsruutimistabelil on vaikemarsruut läbi ToR1 aadressi 10.0.0.1. Sinna ta selle saadab.

   
   

6. ToR1 kui Underlay võrgu liige teab (näiteks OSPF-i kaudu), kuidas pääseda 10.0.1.2-sse ja saadab paketi marsruudil. Pange tähele, et ECMP on siin lubatud. Illustratsioonil on kaks nexthopi ja erinevad lõimed sorteeritakse neisse räsi järgi. Päris tehase puhul on tõenäolisem 4 nexthopi.

   Samas ei pea ta teadma, mis on välise IP päise all. See tähendab, et tegelikult võib IP all olla IPv6 võileib MPLS-i kaudu Etherneti kaudu MPLS-i kaudu GRE-ga üle kreeka keele.

7. Vastavalt sellele eemaldab vRouter vastuvõtva poolelt GRE ja MPLS-märgendi abil saab aru, millisele liidesele see pakett saata, eemaldab selle ja saadab selle algsel kujul adressaadile.

Juhtplaat

Auto käivitamisel juhtub sama, mis eespool kirjeldatud.

Ja lisaks järgmised:

• Iga kliendi jaoks eraldab vRouter MPLS-sildi. See on L3VPN-i teenusesilt, mille abil eraldatakse kliendid samas füüsilises masinas.
  

  Tegelikult eraldab MPLS sildi alati tingimusteta vRouter – ju pole ju ette teada, et masin suhtleb ainult teiste sama vRouteri taga olevate masinatega ja see pole suure tõenäosusega isegi tõsi.

• vRouter loob ühenduse SDN-kontrolleriga, kasutades BGP-protokolli (või sellega sarnast - TF-i puhul on see XMPP 0_o).
• Selle seansi jooksul edastab vRouter SDN-kontrollerile marsruudid ühendatud võrkudesse:
  • Võrguaadress
  • Kapseldamise meetod (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS-kliendi silt
  • Teie IP-aadress kui nexthop

• SDN-kontroller võtab sellised marsruudid vastu kõigilt ühendatud vRouteritelt ja kajastab neid teistele. See tähendab, et see toimib marsruudi peegeldajana.

Sama asi juhtub vastupidises suunas.

Ülekate võib muutuda vähemalt iga minuti järel. Umbes nii juhtub avalikes pilvedes, kus kliendid käivitavad ja sulgevad regulaarselt oma virtuaalseid masinaid.

Keskkontroller hoolitseb kogu keerukuse eest, mis on seotud vRouteri konfiguratsiooni säilitamise ja lülitus-/marsruutimistabelite jälgimisega.

Jämedalt öeldes suhtleb kontroller kõigi vRouteritega BGP (või sarnase protokolli) kaudu ja edastab lihtsalt marsruutimisteavet. Näiteks BGP-l on kapseldamismeetodi edastamiseks juba aadress-perekond MPLS-in-GRE või MPLS-in-UDP.

Samas ei muutu kuidagi Underlay võrgu konfiguratsioon, mida, muide, on palju keerulisem automatiseerida ja kohmaka liigutusega lihtsam lõhkuda.

Väljumine välismaailma

Kusagil peab simulatsioon lõppema ja virtuaalsest maailmast tuleb väljuda pärismaailma. Ja teil on vaja taksofoni lüüsi.

Kasutatakse kahte lähenemisviisi:

1. Riistvara ruuter on installitud.
2. Käivitatakse mõni seade, mis rakendab ruuteri funktsioone (jah, pärast SDN-i kohtasime ka VNF-i). Nimetagem seda virtuaalseks väravaks.

Teise lähenemise eeliseks on odav horisontaalne skaleeritavus – võimsust pole piisavalt – käivitasime veel ühe lüüsiga virtuaalmasina. Igas füüsilises masinas, ilma et peaksite otsima vabu riiulid, agregaate, väljundvõimsust, ostma riistvara ise, seda transportima, installima, lülitama, konfigureerima ja seejärel ka vigaseid komponente vahetama.

Virtuaalse lüüsi miinusteks on see, et füüsilise ruuteri üksus on siiski suurusjärgus võimsam kui mitmetuumaline virtuaalmasin ja selle tarkvara, mis on kohandatud oma riistvarabaasi järgi, töötab palju stabiilsemalt (ei). Samuti on raske eitada tõsiasja, et riist- ja tarkvarakompleks lihtsalt töötab, nõudes vaid konfigureerimist, samas kui virtuaalse lüüsi käivitamine ja hooldamine on tugevate inseneride ülesanne.

Lüüs vaatab ühe jalaga ülekattega virtuaalvõrku, nagu tavaline virtuaalmasin, ja saab suhelda kõigi teiste VM-idega. Samal ajal võib see lõpetada kõigi klientide võrgud ja vastavalt teostada nende vahel marsruutimist.

Teise jalaga vaatab värav magistraalvõrku ja teab, kuidas pääseda Internetti.

Andmetasand

See tähendab, et protsess näeb välja selline:

1. VM-0, olles vaikimisi valinud sama vRouteri, saadab eth185.147.83.177 liidesele paketi välismaailma sihtkohaga (0).
2. vRouter võtab selle paketi vastu ja otsib marsruutimistabelist sihtkoha aadressi – leiab vaikemarsruudi läbi VNGW1 lüüsi läbi tunneli 1.
   Samuti näeb ta, et see on GRE tunnel, millel on SIP 10.0.0.2 ja DIP 10.0.255.2, ning ta peab esmalt kinnitama ka selle kliendi MPLS-märgise, mida VNGW1 ootab.
3. vRouter pakib esialgse paketi MPLS-i, GRE-i ja uute IP-päistega ning saadab selle vaikimisi ToR1 10.0.0.1-le.
4. Alusvõrk edastab paketi lüüsile VNGW1.
5. VNGW1 lüüs eemaldab GRE ja MPLS tunnelipäised, näeb sihtkoha aadressi, vaatab oma marsruutimistabelit ja mõistab, et see on suunatud Internetti – st täisvaate või vaikerežiimi kaudu. Vajadusel teostab NAT tõlke.
6. VNGW-st piirini võiks olla tavaline IP-võrk, mis on ebatõenäoline.
   Võib olla klassikaline MPLS võrk (IGP+LDP/RSVP TE), võib olla tagakangas BGP LU-ga või GRE tunnel VNGW-st piirini läbi IP võrgu.
   Olgu kuidas on, VNGW1 teostab vajalikud kapseldamised ja saadab esialgse paketi piiri poole.

Vastassuunaline liiklus läbib samad sammud vastupidises järjekorras.

1. Piir langetab paketi VNGW1-le
2. Ta riietab ta lahti, vaatab saaja aadressi ja näeb, et talle pääseb Tunnel1 tunneli kaudu (MPLSoGRE või MPLSoUDP).
3. Vastavalt sellele lisab see MPLS-sildi, GRE/UDP-päise ja uue IP-aadressi ning saadab selle oma ToR3-le 10.0.255.1.
   Tunneli sihtkoha aadress on vRouteri IP-aadress, mille taga siht-VM asub – 10.0.0.2.
4. Alusvõrk edastab paketi soovitud vRouterile.
5. Siht-vRouter loeb GRE/UDP-d, tuvastab liidese MPLS-märgise abil ja saadab tühja IP-paketi oma TAP-liidesele, mis on seotud VM-i eth0-ga.

Juhtplaat

VNGW1 loob SDN-kontrolleriga BGP naabruskonna, kust saab kogu marsruutimisteabe klientide kohta: milline IP-aadress (vRouter) millise kliendi taga on ja millise MPLS-sildiga see tuvastatakse.

Samamoodi teavitab ta ise SDN-i kontrollerit selle kliendi sildiga vaikemarsruudist, näidates end nexthopiks. Ja siis jõuab see vaikimisi vRouterisse.

VNGW-l toimub tavaliselt marsruudi liitmine või NAT-i translatsioon.

Ja teises suunas saadab see seansile täpselt selle koondatud marsruudi piiride või marsruudi peegeldajatega. Ja neilt saab see vaikemarsruudi või täisvaate või midagi muud.

Kapseldamise ja liikluse vahetamise osas ei erine VNGW vRouterist.
Kui laiendate ulatust veidi, saate VNGW-dele ja vruuteritele lisada muid võrguseadmeid, nagu tulemüürid, liikluse puhastus- või rikastamisfarmid, IPS jne.

Ja VRF-ide järjestikuse loomise ja marsruutide õige teatamise abil saate sundida liiklust soovitud viisil liikuma, mida nimetatakse teenuseahelaks.

See tähendab, et ka siin toimib SDN-kontroller VNGW-de, vruuterite ja muude võrguseadmete vahel marsruudi peegeldajana.

Kuid tegelikult lekib kontroller teavet ka ACL-i ja PBR-i (poliitikapõhise marsruutimise) kohta, põhjustades üksikute liiklusvoogude kulgemise erinevalt, kui marsruut ette näeb.

FAQ

Miks te muudkui teete GRE/UDP märkust?

Noh, üldiselt võib öelda, et see on volframkanga jaoks spetsiifiline - te ei pea seda üldse arvesse võtma.

Aga kui võtta, siis TF ise, olles veel OpenContrail, toetas mõlemat kapseldamist: MPLS-i GRE-s ja MPLS-i UDP-s.

UDP on hea, sest Source Portis on väga lihtne kodeerida selle päisesse algsest IP+Proto+Port räsifunktsioon, mis võimaldab tasakaalustamist teha.

GRE puhul on paraku ainult välised IP ja GRE päised, mis on kogu kapseldatud liikluse puhul ühesugused ja tasakaalustamisest pole juttugi - vähesed suudavad nii sügavale paketi sisse vaadata.

Kuni mõne ajani tegid ruuterid, kui nad teadsid, kuidas dünaamilisi tunneleid kasutada, ainult MPLSoGRE-s ja alles väga hiljuti õppisid nad kasutama MPLSoUDP-d. Seetõttu peame alati märkima kahe erineva kapseldamise võimaluse kohta.

Ausalt öeldes väärib märkimist, et TF toetab täielikult L2-ühenduvust VXLAN-i abil.

Lubasite tõmmata paralleele OpenFlowga.
Nad tõesti küsivad seda. vSwitch teeb samas OpenStackis väga sarnaseid asju, kasutades VXLAN-i, millel, muide, on ka UDP päis.

Andmetasandil töötavad need ligikaudu samamoodi, juhtimistasand erineb oluliselt. Tungsten Fabric kasutab XMPP-d marsruutimisteabe edastamiseks vRouterile, samal ajal kui OpenStack töötab Openflow.

Kas saate mulle vRouteri kohta natuke rohkem rääkida?
See on jagatud kaheks osaks: vRouter Agent ja vRouter Forwarder.

Esimene töötab host OS-i kasutajaruumis ja suhtleb SDN-kontrolleriga, vahetades teavet marsruutide, VRF-ide ja ACL-ide kohta.

Teine realiseerib Data Plane’i – tavaliselt Kernel Space’is, aga võib töötada ka SmartNIC’idel – CPU ja eraldi programmeeritava lülituskiibiga võrgukaardid, mis võimaldab eemaldada hostmasina protsessorilt koormuse ning muuta võrk kiiremaks ja enamaks. etteaimatav.

Teine võimalik stsenaarium on see, et vRouter on kasutajaruumis DPDK rakendus.

vRouter Agent saadab sätted vRouter Forwarderile.

Mis on virtuaalne võrk?
VRF-i käsitleva artikli alguses mainisin, et iga üürnik on seotud oma VRF-iga. Ja kui sellest piisas ülekattevõrgu toimimise pealiskaudseks mõistmiseks, siis on järgmise iteratsiooni käigus vaja teha selgitusi.

Tavaliselt tutvustatakse virtualiseerimismehhanismides Virtual Network (võid seda pärisnimisõnaks pidada) olemit klientidest/üürnikest/virtuaalsetest masinatest eraldi – täiesti sõltumatu asi. Ja seda virtuaalset võrku saab juba liideste kaudu ühendada ühe rentnikuga, teise, kahe või ükskõik kuhu. Näiteks teenuseahelat rakendatakse siis, kui liiklust on vaja teatud sõlmede kaudu läbida vajalikus järjestuses, lihtsalt luues ja ühendades virtuaalsed võrgud õiges järjestuses.

Seetõttu ei ole virtuaalse võrgu ja rentniku vahel otsest kirjavahetust.

Järeldus

See on väga pealiskaudne kirjeldus virtuaalse võrgu toimimisest koos hosti ja SDN-kontrolleriga. Kuid olenemata sellest, millise virtualiseerimisplatvormi te täna valite, töötab see sarnaselt, olgu selleks VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric või Juniper Contrail. Need erinevad kapselduste ja päiste ning lõppvõrguseadmetesse teabe edastamise protokollide poolest, kuid suhteliselt lihtsa ja staatilise alusvõrgu peal töötava tarkvaraga konfigureeritava ülekattevõrgu põhimõte jääb samaks.
Võib öelda, et täna on privaatpilve loomise valdkonnas võitnud ülekattevõrgul põhinev SDN. See aga ei tähenda, et Openflow'l poleks tänapäeva maailmas kohta – seda kasutatakse OpenStacke'is ja samas VMWare NSX-is, minu teada kasutab Google seda maa-aluse võrgu seadistamiseks.

Allpool olen lisanud lingid üksikasjalikumatele materjalidele, kui soovite teemat põhjalikumalt uurida.

Ja kuidas on lood meie aluskattega?

Aga üldiselt mitte midagi. Ta ei muutnud kogu teed. Kõik, mida ta peab hostist ülekatte korral tegema, on värskendada marsruute ja ARP-sid, kui vRouter/VNGW ilmub ja kaob ning kannab pakette nende vahel.

Koostame aluskatte võrgu nõuete loendi.

1. Oskab kasutada mingit marsruutimisprotokolli, meie olukorras - BGP.
2. Lai ribalaius, eelistatavalt ilma ületellimiseta, et paketid ülekoormuse tõttu kaduma ei läheks.
3. ECMP toetamine on kanga lahutamatu osa.
4. Suuda pakkuda QoS-i, sealhulgas keerulisi asju, nagu ECN.
5. NETCONF-i toetamine on tuleviku aluseks.

Ma pühendasin siin väga vähe aega Underlay võrgu enda tööle. Selle põhjuseks on asjaolu, et sarjas keskendun sellele hiljem ja ülekatteid puudutame vaid möödaminnes.

Ilmselgelt piiran ma meid kõiki tõsiselt, kasutades näitena Closi tehases ehitatud alalisvooluvõrku, millel on puhas IP-marsruutimine ja hosti ülekate.

Olen siiski kindel, et iga kujundusega võrku saab ametlikult kirjeldada ja automatiseerida. Lihtsalt minu eesmärk on mõista automatiseerimise lähenemisviise ja mitte ajada kõiki segadusse, lahendades probleemi üldises vormis.

ADSM-i raames plaanime Roman Gorge'iga välja anda eraldi numbri arvutusvõimsuse virtualiseerimisest ja selle koostoimest võrgu virtualiseerimisega. Ühendust pidama.

Kasulikud lingid

• Volframkangaarhitektuur.
• umbes:pilv. 6 tundi Yandex.Cloudi kohta, mis hõlmab ka TF-i virtuaalset võrku.
• Mis on Open vSwitch?
• Sissejuhatus VxLAN-i.
• RFC 7348. Virtuaalne laiendatav kohtvõrk (VXLAN): raamistik virtualiseeritud kihi 2 võrkude katmiseks üle 3. kihi võrkude.
  
• Scaleway lähenemine VXLAN EVPN Fabricule. See räägib kogu alalisvooluvõrgust, sealhulgas aluskihist, ülekattest, lähenemisviisidest mitmele asukohale ja haldamisele.

Aitäh

• Roman Gorga - endine linkmeupi taskuhäälingusaate juht ja nüüd pilveplatvormide valdkonna ekspert. Kommentaarideks ja toimetusteks. Noh, ootame lähiajal tema põhjalikumat artiklit virtualiseerimise kohta.
• Aleksander Šalimov - minu kolleeg ja ekspert virtuaalse võrgu arendamise alal. Kommentaarideks ja toimetusteks.
• Valentin Sinitsõn - minu kolleeg ja volframkanga valdkonna ekspert. Kommentaarideks ja toimetusteks.
• Artjom Tšernobai — illustraator linkmeup. KDPV jaoks.
• Aleksander Limonov. "Automaat" meemi jaoks.

Allikas: www.habr.com