{"id":35973,"date":"2019-10-31T22:08:54","date_gmt":"2019-10-31T19:08:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti\/"},"modified":"2019-10-31T22:08:54","modified_gmt":"2019-10-31T19:08:54","slug":"avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti","title":{"rendered":"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>I <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/453516\/\">den forrige udgivelse<\/a><\/noindex> Jeg har beskrevet rammerne for netv\u00e6rksautomatisering. If\u00f8lge tilbagemeldinger hos nogle personer har denne f\u00f8rste tilgang til problemet allerede afklaret nogle sp\u00f8rgsm\u00e5l. Det gl\u00e6der mig, fordi vores m\u00e5l i cyklen ikke er at d\u00e6kke Ansible med Python-scripts, men at opbygge et system.<\/p>\n<p>Dette rammev\u00e6rk fastl\u00e6gger ogs\u00e5 r\u00e6kkef\u00f8lgen, hvori vi vil tackle emnet.<br \/>\nOg netv\u00e6rksvirtualisering, som dette afsnit er dedikeret til, falder ikke helt ind under temaet ADSM, hvor vi diskuterer automatisering. <\/p>\n<p>Men lad os se p\u00e5 det fra en anden vinkel.<\/p>\n<p>I lang tid har mange tjenester v\u00e6ret afh\u00e6ngige af det samme netv\u00e6rk. I tilf\u00e6lde af en teleudbyder kan det v\u00e6re 2G, 3G, LTE, bredb\u00e5nd og B2B, for eksempel. I tilf\u00e6lde af datacentre: forbindelse til forskellige kunder, internettet, bloklagring, objektslagring.<\/p>\n<p>Og alle tjenester kr\u00e6ver isolation fra hinanden. Derfor opstod overlay-netv\u00e6rk.<\/p>\n<p>Og alle tjenester vil ikke vente p\u00e5, at en person manuelt konfigurerer dem. Derfor opstod orkestratorer og SDN.<\/p>\n<p>Den f\u00f8rste systematiske tilgang til netv\u00e6rksautomatisering, n\u00e6rmere bestemt dens del, er l\u00e6nge blevet fors\u00f8gt og implementeret mange steder: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.<\/p>\n<p>Lad os dykke ned i dette i dag. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/kdpv.jpg\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/e0bf73b7b71c383c5526da48a6f6b776.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Indhold<\/h1>\n<p><\/p>\n<ul>\n<li><b>\u00c5rsager<\/b><\/li>\n<li><b>Terminologi<\/b><\/li>\n<li><b>Underlay \u2014 fysisk netv\u00e6rk<\/b><\/li>\n<li><b>Overlay \u2014 virtuelt netv\u00e6rk<\/b>\n<ul>\n<li>Overlay fra ToR'a<\/li>\n<li>Overlay fra host<\/li>\n<li>P\u00e5 eksemplet med Tungsten Fabric\n<ul>\n<li>Kommunikation inden for \u00e9n fysisk maskine<\/li>\n<li>Kommunikation mellem VM'er, der er placeret p\u00e5 forskellige fysiske maskiner<\/li>\n<li>Udgang til den ydre verden<\/li>\n<\/ul>\n<p>\n <\/li>\n<\/ul>\n<p>\n <\/li>\n<li><b>FAQ<\/b><\/li>\n<li><b>Konklusion<\/b><\/li>\n<li><b>Nyttige links<\/b><\/li>\n<\/ul>\n<p><\/p>\n<h1>\u00c5rsager<\/h1>\n<p>\nOg siden vi taler om det, er det v\u00e6rd at n\u00e6vne foruds\u00e6tningerne for netv\u00e6rksvirtualisering. Faktisk begyndte denne proces ikke i g\u00e5r. <\/p>\n<p>Du har sikkert h\u00f8rt, at netv\u00e6rket altid har v\u00e6ret den mest inaktive del af ethvert system. Og det er sandt i alle henseender. Netv\u00e6rket er det fundament, som alt hviler p\u00e5, og det er ret sv\u00e6rt at foretage \u00e6ndringer i det \u2014 tjenester kan ikke t\u00e5le, n\u00e5r netv\u00e6rket er nede. Ofte kan nedetid p\u00e5 \u00e9n node nedl\u00e6gge mange applikationer og p\u00e5virke mange kunder. Delvis derfor kan netv\u00e6rks-teamet modst\u00e5 enhver \u00e6ndring \u2014 fordi det lige nu fungerer p\u00e5 en eller anden m\u00e5de (<i>vi ved m\u00e5ske endda ikke hvordan<\/i>), og nu skal noget nyt konfigureres, og det er usikkert, hvordan det vil p\u00e5virke netv\u00e6rket.<\/p>\n<p>For ikke at skulle vente p\u00e5, at netv\u00e6rksfolkene ops\u00e6tter VLAN og registrerer tjenester p\u00e5 hver enkelt nodes netv\u00e6rk, har folk fundet p\u00e5 at bruge overlays \u2014 lagdelte netv\u00e6rk \u2014 der findes i mange variationer: GRE, IPinIP, MPLS, MPLS L2\/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE osv.<\/p>\n<p>Deres tiltr\u00e6kningskraft ligger i to enkle ting:<\/p>\n<ul>\n<li>Kun slutnoderne skal konfigureres \u2014 transit nodene skal ikke r\u00f8res. Det fremskynder processen markant og kan nogle gange helt undg\u00e5, at netv\u00e6rksafdelingen involveres ved indf\u00f8relsen af nye tjenester.<\/li>\n<li>Belastningen er skjult dybt inde i overskrifterne \u2014 transitnoderne beh\u00f8ver ikke at vide noget om det, om adressering p\u00e5 v\u00e6rterne, ruter i det lagdelte netv\u00e6rk. Det betyder, at der skal opbevares mindre information i tabellerne, hvilket betyder, at man kan v\u00e6lge enklere\/ billigere udstyr.<\/li>\n<\/ul>\n<p>\nI denne ikke helt udt\u00f8mmende udgave planl\u00e6gger jeg ikke at gennemg\u00e5 alle mulige teknologier, men snarere beskrive rammerne for arbejdsgangen i overlay-netv\u00e6rk i datacenteret.<\/p>\n<p>Hele serien vil beskrive et datacenter, der best\u00e5r af r\u00e6kker af ensartede skabe, hvor identisk serverudstyr er installeret. <\/p>\n<p>P\u00e5 dette udstyr k\u00f8res virtuelle maskiner\/containere\/serverless, der implementerer tjenester.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/a6863eb2804a298304d1e93daecf90d9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h1>Terminologi<\/h1>\n<p>\nI cyklussen <b>serveren<\/b> vil jeg kalde programmet, der implementerer serversiden af klient-server kommunikation.<\/p>\n<p>De fysiske maskiner i skabene vil blive kaldt servere <b>ikke<\/b> vil vi.<\/p>\n<p><b>Den fysiske maskine<\/b> \u2014 en x86-computer, der er installeret i et rack. Den mest anvendte betegnelse <b>host<\/b>. S\u00e5 vi kalder den &#171;<b>maskine<\/b>&#187; eller <b>host<\/b>.<\/p>\n<p><b>Hypervisor<\/b> \u2014 en applikation, der k\u00f8rer p\u00e5 den fysiske maskine og emulerer de fysiske ressourcer, som de Virtuelle Maskiner k\u00f8rer p\u00e5. I nogle litter\u00e6re v\u00e6rker og p\u00e5 nettet bruges ordet \u00abhypervisor\u00bb som synonym for \u00abhost\u00bb.<\/p>\n<p><b>Virtuel maskine<\/b> \u2014 et operativsystem, der k\u00f8rer p\u00e5 en fysisk maskine over hypervisoren. For os i denne sammenh\u00e6ng er det ikke s\u00e5 vigtigt, om det faktisk er en virtuel maskine eller blot en container. Vi kalder det &#171;<b>VM<\/b>\u00ab<\/p>\n<p><b>Tenant<\/b> \u2014 et bredt begreb, som jeg i denne artikel definerer som en separat tjeneste eller en separat klient.<\/p>\n<p><b>Multi-tenancy<\/b> eller multi-leje \u2014 brugen af den samme applikation af forskellige klienter\/tjenester. Kundenes isolering fra hinanden opn\u00e5s gennem applikationens arkitektur og ikke ved separat k\u00f8rende instanser.<\/p>\n<p><b>ToR \u2014 Top of the Rack-switch<\/b> \u2014 en switch, der er installeret i en rack, til hvilken alle fysiske maskiner er tilsluttet.<\/p>\n<blockquote><p> Udover ToR-topologien praktiserer forskellige udbydere End of Row (EoR) eller Middle of Row (selvom sidstn\u00e6vnte er sj\u00e6lden, og jeg har ikke m\u00f8dt forkortelsen MoR).\n<\/p><\/blockquote>\n<p> <b>Underlay-netv\u00e6rk<\/b> eller underliggende netv\u00e6rk eller anderlayers \u2014 den fysiske netv\u00e6rksinfrastruktur: switches, routere, kabler.<\/p>\n<p><b>Overlay-netv\u00e6rk<\/b> eller overliggende netv\u00e6rk eller overlays \u2014 et virtuelt netv\u00e6rk af tunneler, der fungerer oven p\u00e5 det fysiske.<\/p>\n<p><b>L3-fabrik eller IP-fabrik<\/b> \u2014 en fantastisk menneskelig opfindelse, der g\u00f8r det muligt ikke at gentage STP under samtaler og ikke at l\u00e6re TRILL. Et koncept, hvor hele netv\u00e6rket op til adgangsniveauet udelukkende er L3, uden VLAN og dermed enorme strakte broadcast-dom\u00e6ner. Hvor ordet \u201efabrik\u201c stammer fra, vil vi unders\u00f8ge i n\u00e6ste del.<\/p>\n<p><b>SDN<\/b> \u2014 Software Defined Network. Tr\u00e6nger n\u00e6ppe til pr\u00e6sentation. En tilgang til netv\u00e6rksstyring, hvor \u00e6ndringer i netv\u00e6rket udf\u00f8res ikke af mennesker, men af et program. Betyr normalt, at Control Plane flyttes uden for de endelige netv\u00e6rksenheder til en controller.<\/p>\n<p><b>NFV<\/b> \u2014 Network Function Virtualization \u2014 virtualisering af netv\u00e6rksenheder, hvilket indeb\u00e6rer, at dele af netv\u00e6rksfunktionerne kan k\u00f8res som virtuelle maskiner eller containere for at fremskynde implementeringen af nye tjenester, organisere Service Chaining og lettere horisontal skalerbarhed.<\/p>\n<p><b>VNF<\/b> \u2014 Virtual Network Function. En specifik virtuel enhed: router, switch, firewall, NAT, IPS\/IDS osv.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/971b6a28a9caab5f3a7067ce4d25749c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<blockquote><p> Jeg forenkler i \u00f8jeblikket beskrivelsen til den specifikke implementering for ikke at forvirre l\u00e6seren. For en mere dybdeg\u00e5ende l\u00e6sning henviser jeg til sektionen <noindex><a rel=\"nofollow\" href=\"#LINKS\">Links<\/a><\/noindex>. Desuden lover Roma Gorge, som kritiserer denne artikel for un\u00f8jagtigheder, at skrive et separat afsnit om virtualiseringsteknologier for servere og netv\u00e6rk, mere dybtg\u00e5ende og opm\u00e6rksom p\u00e5 detaljerne.<\/p><\/blockquote>\n<p>De fleste netv\u00e6rk i dag kan tydeligt opdeles i to dele: <\/p>\n<p><b>Underlay<\/b> \u2014 det fysiske netv\u00e6rk med en stabil konfiguration.<br \/>\n<b>Overlay<\/b> \u2014 en abstraktion over Underlay til isolering af lejere. <\/p>\n<p>Dette g\u00e6lder b\u00e5de for datacenteret (som vi vil gennemg\u00e5 i denne artikel) og for ISP (som vi ikke vil gennemg\u00e5, fordi det allerede er blevet n\u00e6vnt i <noindex><a rel=\"nofollow\" href=\"https:\/\/linkmeup.ru\/sdsm\">SDN<\/a><\/noindex>). For enterprise-netv\u00e6rk er situationen naturligvis noget anderledes. <\/p>\n<p>Billede med fokus p\u00e5 netv\u00e6rket:<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/7b7dabc6d9f3b87c598346bf9195d568.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h1>Underlay<\/h1>\n<p>\nUnderlay er et fysisk netv\u00e6rk: hardware-switches og kabler. Enheder i underlay ved, hvordan de n\u00e5r frem til de fysiske maskiner.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/776a77a3821fe79a7323947e0bdf67e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet bygger p\u00e5 standardprotokoller og -teknologier. Ikke mindst fordi hardware-enheder stadig i dag fungerer p\u00e5 propriet\u00e6r software, der ikke tillader programmering af chippen eller implementering af egne protokoller, derfor er der behov for kompatibilitet med andre leverand\u00f8rer og standardisering.<\/p>\n<blockquote><p>Men nogen som Google kan tillade sig at udvikle egne switches og undg\u00e5 almindeligt anerkendte protokoller. Men LAN_DC er ikke Google.\n<\/p><\/blockquote>\n<p> Underlay \u00e6ndres relativt sj\u00e6ldent, fordi dets opgave er grundl\u00e6ggende IP-konnektivitet mellem fysiske maskiner. Underlay ved intet om de tjenester, kunder eller lejere, der k\u00f8rer ovenp\u00e5; det skal kun transportere pakker fra \u00e9n maskine til en anden.<br \/>\nUnderlay kan v\u00e6re for eksempel s\u00e5dan: <\/p>\n<ul>\n<li>IPv4+OSPF<\/li>\n<li>IPv6+ISIS+BGP+L3VPN<\/li>\n<li>L2+TRILL<\/li>\n<li>L2+STP<\/li>\n<\/ul>\n<p>\nUnderlay-netv\u00e6rket konfigureres p\u00e5 klassisk vis: CLI\/GUID\/NETCONF.<\/p>\n<p>Manuelt, via scripts eller propriet\u00e6re v\u00e6rkt\u00f8jer.<\/p>\n<p>En mere detaljeret artikel om underlay vil blive dedikeret til emnet i den kommende del af cyklen.<\/p>\n<p><\/p>\n<h1>Overlay<\/h1>\n<p>\nOverlay er et virtuelt netv\u00e6rk af tunneler, trukket hen over Underlay, som tillader VMs fra \u00e9n kunde at kommunikere med hinanden, samtidig med at der sikres isolation fra andre kunder.<\/p>\n<p>Kundens data kapsles ind i tunnelerende headers for at blive sendt over det f\u00e6lles netv\u00e6rk.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/3060bc4913c55c21b785083fbe0b603b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDermed kan VMs fra \u00e9n kunde (\u00e9n service) kommunikere med hinanden gennem Overlay, uden at vide hvilken rute pakken reelt tager. <\/p>\n<p>Overlay kan v\u00e6re for eksempel s\u00e5dan, som jeg allerede har n\u00e6vnt ovenfor:<\/p>\n<ul>\n<li>GRE-tunnel<\/li>\n<li>VXLAN<\/li>\n<li>EVPN<\/li>\n<li>L3VPN<\/li>\n<li>GENEVE<\/li>\n<\/ul>\n<p>\nOverlay-netv\u00e6rket konfigureres og vedligeholdes normalt gennem en central controller. Fra denne leveres konfigurationen, Control Plane og Data Plane til enhederne, som h\u00e5ndterer routing og kapsling af klienttrafik. Lidt <noindex><a rel=\"nofollow\" href=\"#TF\">nedenfor<\/a><\/noindex> lader os se n\u00e6rmere p\u00e5 dette med eksempler.<\/p>\n<p><b>Ja, det er SDN i sin reneste form. <\/b><\/p>\n<p>Der eksisterer to principielt forskellige tilgange til opbygning af et Overlay-netv\u00e6rk:<\/p>\n<ol>\n<li>Overlay fra ToR'a<\/li>\n<li>Overlay fra host<\/li>\n<\/ol>\n<h2>Overlay fra ToR'a<\/h2>\n<p>\nOverlay kan starte p\u00e5 adgangsswitchens (ToR), der st\u00e5r i rack, som det er tilf\u00e6ldet i eksempelvis VXLAN-fabrikker. <\/p>\n<p>Det er en tidsafpr\u00f8vet mekanisme i ISP-netv\u00e6rk, og alle producenter af netv\u00e6rksudstyr underst\u00f8tter det.<\/p>\n<p>Men i dette tilf\u00e6lde skal ToR-switch v\u00e6re i stand til at adskille forskellige tjenester, og netv\u00e6rksadministratoren skal i et vist omfang samarbejde med administratorer af virtuelle maskiner og foretage \u00e6ndringer (selv om automatisk) i enhedernes konfiguration.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/9a5fe4d4a0cbb7e5c3bbac82527c6a6a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHer henviser jeg l\u00e6seren til artiklen om <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/344326\/\">VxLAN p\u00e5 Habr<\/a><\/noindex> vores gamle ven <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/bormoglotx\/\">@bormoglotx<\/a><\/noindex>.<br \/>\nI denne <noindex><a rel=\"nofollow\" href=\"https:\/\/www.enog.org\/wp-content\/uploads\/presentations\/enog-16\/18-Scaleway-P14-fabric-ENOG16.pdf\">pr\u00e6sentationer fra ENOG<\/a><\/noindex> hvor tilgange til opbygning af datacenter-netv\u00e6rk med EVPN VXLAN-fabrik er beskrevet i detaljer. <\/p>\n<p>For en dybere forst\u00e5else kan man l\u00e6se Ciscon's bog <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/dam\/en\/us\/td\/docs\/switches\/datacenter\/nexus9000\/sw\/vxlan_evpn\/VXLAN_EVPN.pdf\">A Modern, Open, and Scalable Fabric: VXLAN EVPN<\/a><\/noindex>.<\/p>\n<blockquote><p> Jeg bem\u00e6rker, at VXLAN kun er en metode til kapsling, og termineringen af tunneler kan ske ikke p\u00e5 ToR'a, men p\u00e5 v\u00e6rten, som det er tilf\u00e6ldet med OpenStack, for eksempel.<\/p>\n<p>Dog er VXLAN-fabrikken, hvor overlayet begynder p\u00e5 ToR'a, et af de etablerede designs for overlay-netv\u00e6rk.\n<\/p><\/blockquote>\n<p><\/p>\n<h2>Overlay fra host<\/h2>\n<p>\nEn anden tilgang er at starte og terminere tunneler p\u00e5 de endelige v\u00e6rter.<br \/>\nI dette tilf\u00e6lde forbliver netv\u00e6rket (Underlay) s\u00e5 simpelt og statisk som muligt.<br \/>\nOg v\u00e6rten udf\u00f8rer alle n\u00f8dvendige indkapslinger.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/c9c2971369d1b3e5f026d6844afeb67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette kr\u00e6ver selvf\u00f8lgelig, at man k\u00f8rer en s\u00e6rlig applikation p\u00e5 v\u00e6rterne, men det er det v\u00e6rd. <\/p>\n<p>For det f\u00f8rste er det lettere at starte klienten p\u00e5 en linux-maskine, eller man kan sige \u2014 overhovedet muligt \u2014 mens man p\u00e5 switchen sandsynligvis bliver n\u00f8dt til at bruge propriet\u00e6re SDN-l\u00f8sninger, hvilket dr\u00e6ber ideen om multivendoritet.<\/p>\n<p>For det andet kan ToR-switchen i dette tilf\u00e6lde forblive s\u00e5 simpel som muligt, b\u00e5de med hensyn til Control Plane og Data Plane. Faktisk \u2014 med en SDN-controller beh\u00f8ver den ikke at kommunikere, og den skal ikke opbevare netv\u00e6rk\/ARP'er for alle tilsluttede kunder \u2014 det er tilstr\u00e6kkeligt at kende IP-adressen p\u00e5 den fysiske maskine, hvilket betydeligt letter routing\/switching-tabellerne.<\/p>\n<p>\nI ADSM-serien v\u00e6lger jeg tilgangen til overlay med v\u00e6rten \u2014 herefter taler vi kun om den, og vi vil ikke g\u00e5 tilbage til VXLAN-fabrikken.<\/p>\n<p>\nDet er lettest at se p\u00e5 eksempler. Og som fors\u00f8g vil vi tage den OpenSource SDN-platform OpenContrail, nu kendt som <noindex><a rel=\"nofollow\" href=\"https:\/\/tungsten.io\">Tungsten Fabric<\/a><\/noindex>.<\/p>\n<blockquote><p> Mod slutningen af artiklen vil jeg give nogle overvejelser om analogien med OpenFlow og OpenvSwitch.\n<\/p><\/blockquote>\n<p><\/p>\n<h2>P\u00e5 eksemplet med Tungsten Fabric<\/h2>\n<p>\nP\u00e5 hver fysisk maskine er der <b>vRouter<\/b> \u2014 en virtuel router, der kender til de netv\u00e6rk, der er tilsluttet den, og hvilke kunder de tilh\u00f8rer \u2014 i essensen en PE-router. For hver kunde opretholder den en isoleret routingtabel (l\u00e6s VRF). Og selve vRouter udf\u00f8rer overlay-tunneling.<\/p>\n<p>Lidt mere om vRouter \u2014 i slutningen af artiklen.<\/p>\n<p>Hver VM, der er hostet p\u00e5 hypervisoren, forbinder til denne maskines vRouter gennem <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/TUN\/TAP\">TAP-interface<\/a><\/noindex>.<\/p>\n<p><b>TAP<\/b> \u2014 Terminal Access Point \u2014 et virtuelt interface i Linux-kernen, der muligg\u00f8r netv\u00e6rksinteraktion.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/a6fa1b4370ba4e787303ae647a28f5ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvis der er flere netv\u00e6rk bag vRouter'en, oprettes der et virtuelt interface for hvert af dem, hvortil der tildeles en IP-adresse \u2014 denne vil v\u00e6re standardgateway-adressen.<br \/>\nAlle netv\u00e6rk for \u00e9n kunde placeres i \u00e9n <b>VRF<\/b> (\u00e9n tabel), forskellige \u2014 i forskellige.<br \/>\n<i>Jeg vil g\u00f8re et forbehold her og sende den nysgerrige l\u00e6ser til slutningen af artiklen.<\/i>.<\/p>\n<p>For at vRoutere kan kommunikere med hinanden og dermed ogs\u00e5 VM'erne bag dem, udveksler de routinginformation gennem <b>SDN-controlleren.<\/b>.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/sdn-controller.png\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/8b133e10582dbde9c0670ad98c1840de.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>For at komme til den ydre verden findes der et udgangspunkt fra matrixen \u2014 gateway for det virtuelle netv\u00e6rk <b>VNGW<\/b> \u2014 Virtual Network GateWay (<i>dette udtryk er mit<\/i>).<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/vngw.png\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/9ac4d084d9b58b7ed1bc2c0ed6d06059.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>\nLad os nu se p\u00e5 eksempler p\u00e5 kommunikation \u2014 s\u00e5 bliver det klart.<\/p>\n<p><\/p>\n<h3>Kommunikation inden for \u00e9n fysisk maskine<\/h3>\n<p>\nVM0 \u00f8nsker at sende en pakke til VM2. Lad os antage, at dette er VM'en for \u00e9n kunde.<\/p>\n<h4>Data Plane<\/h4>\n<p><\/p>\n<ol>\n<li>VM-0 har en standardrute i sin interface eth0. Pakken sendes derhen.<br \/>\n Denne interface eth0 er i virkeligheden virtuelt forbundet til den virtuelle router vRouter gennem TAP-interfacet tap0.<\/li>\n<li>vRouter analyserer, hvilken interface pakken kom ind p\u00e5, det vil sige, hvilken kunde (VRF) den tilh\u00f8rer, og tjekker mod modtagerens adresse i denne kundes routingtabel.<\/li>\n<li>Ved at opdage, at modtageren er p\u00e5 samme maskine bag en anden port, sender vRouter simpelthen pakken til den uden yderligere overskrifter \u2014 i dette tilf\u00e6lde er der allerede en ARP-post p\u00e5 vRouter'en. <\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/a42da3f48a3f538eb92c1908d9d66921.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPakken rammer ikke det fysiske netv\u00e6rk i dette tilf\u00e6lde \u2014 det er blevet rutet internt i vRouter'en.<\/p>\n<p><\/p>\n<h4>Control Plane<\/h4>\n<p>\nHypervisoren informerer den virtuelle maskine ved opstart:<\/p>\n<ul>\n<li>Den egen IP-adresse.<\/li>\n<li>Standardruten g\u00e5r gennem IP-adressen p\u00e5 vRouter'en i dette netv\u00e6rk.<\/li>\n<\/ul>\n<p>\nvRouter'en informeres gennem et specialiseret API af hypervisoren:<\/p>\n<ul>\n<li>At der skal oprettes et virtuelt interface.<\/li>\n<li>Hvilken Virtual Network der skal oprettes (for VM'en).<\/li>\n<li>Hvilken VRF den (VN) skal knyttes til.<\/li>\n<li>Den statiske ARP-post for denne VM \u2014 hvilken interface dens IP-adresse er knyttet til, og til hvilken MAC-adresse den er forbundet.<\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p> Igennem forenkles den reelle interaktionsprocedure for at forst\u00e5 konceptet.\n<\/p><\/blockquote>\n<p> <img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/593d7ad41782e882a88732b475bf91cb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDermed ser vRouter alle VM'er fra \u00e9n kunde p\u00e5 denne maskine som direkte tilsluttede netv\u00e6rk og kan selv rute mellem dem.<\/p>\n<p>\nVM0 og VM1 tilh\u00f8rer forskellige kunder og er derfor i forskellige tabeller i vRouter'en.<\/p>\n<p>Om de kan kommunikere direkte med hinanden, afh\u00e6nger af indstillingerne i vRouter og netv\u00e6rksdesignet.<br \/>\nHvis VM'erne fra begge kunder bruger offentlige adresser, eller NAT sker p\u00e5 selve vRouter'en, kan der foretages direkte rutehenvisning til vRouter'en.<\/p>\n<p>I den modsatte situation kan der v\u00e6re overlap i adresseomr\u00e5derne \u2014 man skal g\u00e5 gennem en NAT-server for at f\u00e5 en offentlig adresse \u2014 dette er ligesom at oprette forbindelse til eksterne netv\u00e6rk, som n\u00e6vnt nedenfor.<\/p>\n<h3>Kommunikation mellem VM'er, der er placeret p\u00e5 forskellige fysiske maskiner<\/h3>\n<p><\/p>\n<h4>Data Plane<\/h4>\n<p><\/p>\n<ol>\n<li>Begyndelsen er pr\u00e6cis den samme: VM-0 sender en pakke til modtageren VM-7 (172.17.3.2) via sin standard.<\/li>\n<li>vRouter modtager den og ser denne gang, at modtageren befinder sig p\u00e5 en anden maskine og er tilg\u00e6ngelig via tunnel Tunnel0.<\/li>\n<li>F\u00f8rst tilf\u00f8jer den et MPLS-m\u00e6rke, der identificerer den fjerne interface, s\u00e5 vRouter p\u00e5 den anden side kan bestemme, hvor denne pakke skal placeres uden yderligere omveje.\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/inter-hv-dp.png\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/1e159049376e2bf458b8c6cb5878cc17.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex>\n <\/li>\n<li>Tunnel0 har en kilde p\u00e5 10.0.0.2, modtager: 10.0.1.2.<br \/>\n vRouter tilf\u00f8jer GRE (eller UDP) headers og en ny IP til den oprindelige pakke.<\/li>\n<li>I vRouter's routingtabel er der en standardrute gennem adressen ToR1 10.0.0.1. Den sender til den adresse.\n<p> <img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/8cb98a8ec43d202259acf6a1fcaeb3ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n \n <\/li>\n<li>ToR1, som deltager i Underlay-netv\u00e6rket, ved (for eksempel via OSPF), hvordan man n\u00e5r 10.0.1.2 og sender pakken via ruten. V\u00e6r opm\u00e6rksom p\u00e5, at der her inkluderes ECMP. P\u00e5 illustrationen er der to next-hops, og forskellige str\u00f8mme vil blive fordelt mellem dem p\u00e5 baggrund af hash. I en virkelig fabrik vil der sandsynligvis v\u00e6re 4 next-hops.\n<p>Desuden er det ikke n\u00f8dvendigt for den at vide, hvad der ligger under den ydre IP-header. S\u00e5 i praksis kan der under IP v\u00e6re et sandwich af IPv6 over MPLS over Ethernet over MPLS over GRE over over over GRE.<\/li>\n<li>P\u00e5 modtagerens side fjerner vRouter GRE og forst\u00e5r ud fra MPLS-m\u00e6rket, hvilket interface pakken skal sendes til, adskiller den og sender den i sin oprindelige form til modtageren.<\/li>\n<\/ol>\n<h4>Control Plane<\/h4>\n<p>\nN\u00e5r maskinen startes, sker alt det samme som beskrevet ovenfor.<\/p>\n<p>Og derudover f\u00f8lgende:<\/p>\n<ul>\n<li>For each client, the vRouter assigns an MPLS label. This is a service label for L3VPN, by which clients will be segregated within the same physical machine.<br \/>\n<blockquote><p> Faktisk tildeles MPLS-m\u00e6rket altid af vRouter'en \u2014 det er jo ikke muligt at vide p\u00e5 forh\u00e5nd, at maskinen kun vil interagere med andre maskiner bag den samme vRouter, og det er sandsynligvis ikke tilf\u00e6ldet. \n <\/p><\/blockquote>\n<\/li>\n<li>The vRouter establishes a connection to the SDN controller using the BGP protocol (or one similar to it \u2014 in the case of TF it's XMPP 0_o).<\/li>\n<li>Through this session, the vRouter informs the SDN controller of the routes to the connected networks:\n<ul>\n<li>Network address<\/li>\n<li>Encapsulation method (MPLSoGRE, MPLSoUDP, VXLAN)<\/li>\n<li>Client's MPLS label<\/li>\n<li>Its IP address as the nexthop<\/li>\n<\/ul>\n<p>\n <\/li>\n<li>SDN-controlleren modtager s\u00e5danne ruter fra alle tilsluttede vRoutere og reflekterer dem til andre. Det vil sige, at den fungerer som Route Reflector.<\/li>\n<\/ul>\n<p>\nThe same happens in the opposite direction.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/inter-hv-cp.png\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/feef9181133f3a50a5cb21aa7ba16dc0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>The overlay can change every minute. This is roughly how it happens in public clouds when clients regularly start and stop their virtual machines.<\/p>\n<p>The central controller takes on all the complexities of maintaining the configuration and controlling the switching\/routing tables on the vRouter.<\/p>\n<p>Groft sagt, s\u00e5 opretter controlleren forbindelse til alle vRoutere via BGP (eller et lignende protokol) og videresender simpelthen ruteinformation. BGP har for eksempel allerede en Address-Family til overf\u00f8rsel af kapslingsmetoden. <noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc4023\">MPLS-in-GRE<\/a><\/noindex> eller <noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc7510\">MPLS-in-UDP<\/a><\/noindex>.<\/p>\n<p>At the same time, the configuration of the Underlay network does not change in any way, which, by the way, is significantly more complex to automate, and it is easier to break with an awkward move.<\/p>\n<h3>Udgang til den ydre verden<\/h3>\n<p>\nSomewhere, the simulation must end, and one must step out of the virtual world into the real one. And a gateway taxophone is required.<\/p>\n<p>Two approaches are practiced:<\/p>\n<ol>\n<li>A hardware router is installed.<\/li>\n<li>Some appliance is launched, implementing the functions of a router (yes, following SDN, we also faced VNF). Let's call it a virtual gateway.<\/li>\n<\/ol>\n<p><\/p>\n<blockquote><p> The advantage of the second approach is its inexpensive horizontal scalability \u2014 if additional power is needed, just start another virtual machine with a gateway. On any physical machine, without needing to look for available racks, units, power outputs, buying the hardware itself, transporting it, installing it, connecting it, configuring it, and then also replacing failed components.<\/p>\n<p>Ulemperne ved en virtuel gateway er, at \u00e9n fysisk router stadig er langt st\u00e6rkere end en mangekerner virtuel maskine, og dens software, tilpasset dens egen hardware, fungerer betydeligt mere stabilt (<i>nej<\/i>). Det er sv\u00e6rt at ben\u00e6gte, at den program- og hardwarekompleks simpelthen fungerer og kun kr\u00e6ver konfiguration, mens ops\u00e6tningen og vedligeholdelsen af en virtuel gateway er en opgave for dygtige ingeni\u00f8rer.\n<\/p><\/blockquote>\n<p> Med \u00e9n fod ser gatewayen ind i det virtuelle Overlay-netv\u00e6rk ligesom en almindelig virtuel maskine og kan interagere med alle andre VM'er. Den kan ogs\u00e5 terminere alle kundernes netv\u00e6rk og dermed udf\u00f8re routing mellem dem.<\/p>\n<p>Med den anden fod ser gatewayen mod det centrale netv\u00e6rk og ved, hvordan man kommer ud p\u00e5 internettet.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/552fa0428ff8dd3aed76091a86a72109.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>Data Plane<\/h4>\n<p>\nS\u00e5ledes ser processen s\u00e5dan ud: <\/p>\n<ol>\n<li>VM-0, med standard VRouter, sender en pakke med adressaten i den ydre verden (185.147.83.177) til interface eth0.<\/li>\n<li>VRouter modtager denne pakke og udf\u00f8rer et opslag af destinationsadressen i routing-tabellen \u2014 finder standardruten gennem gateway VNGW1 via Tunnel 1. <br \/>\n Den ser ogs\u00e5, at det er en GRE-tunnel med SIP 10.0.0.2 og DIP 10.0.255.2, og der skal f\u00f8rst tilf\u00f8jes en MPLS-label for denne kunde, som VNGW1 forventer.\n <\/li>\n<li>VRouter pakker den oprindelige pakke ind i MPLS, GRE og nye IP-overskrifter og sender til adressen ToR1 10.0.0.1 som standard.<\/li>\n<li>Underliggende netv\u00e6rk leverer pakken til gateway VNGW1.<\/li>\n<li>Gateway VNGW1 fjerner de tunnelerende GRE- og MPLS-overskrifter, ser destinationsadressen, konsulterer sin routing-tabel og forst\u00e5r, at den er rettet mod internettet \u2014 hvilket betyder via Full View eller Default. Gennemf\u00f8rer NAT-overs\u00e6ttelse om n\u00f8dvendigt.<\/li>\n<li>Fra VNGW til border kan der v\u00e6re et almindeligt IP-netv\u00e6rk, hvilket n\u00e6ppe er tilf\u00e6ldet.<br \/>\n Det kan v\u00e6re et klassisk MPLS-netv\u00e6rk (IGP+LDP\/RSVP TE), det kan v\u00e6re en tilbageholdt fabrik med BGP LU eller en GRE-tunnel fra VNGW til border gennem et IP-netv\u00e6rk.<br \/>\n Hvordan det end er, udf\u00f8rer VNGW1 de n\u00f8dvendige indkapslinger og sender den oprindelige pakke mod border.<\/li>\n<\/ol>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/outside-dp.png\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/a66e490c75f8220349398af814d4ebf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Trafikken i den modsatte retning g\u00e5r gennem de samme trin i omvendt r\u00e6kkef\u00f8lge. <\/p>\n<ol>\n<li>Border afleverer pakken til VNGW1.<\/li>\n<li>Den fjerner overskriften, ser p\u00e5 modtagerens adresse og bem\u00e6rker, at den er tilg\u00e6ngelig gennem tunnelen Tunnel1 (MPLSoGRE eller MPLSoUDP).<\/li>\n<li>Rent faktisk tilf\u00f8jes en MPLS-label, GRE\/UDP-overskriften og nye IP-overskrifter, og den sendes til sit ToR3 10.0.255.1.<br \/>\n Tunnelens destinationsadresse er IP-adressen p\u00e5 vRouter'en, der st\u00e5r bag den m\u00e5let VM \u2014 10.0.0.2.<\/li>\n<li>Underliggende netv\u00e6rk leverer pakken til den \u00f8nskede vRouter. <\/li>\n<li>The target vRouter strips GRE\/UDP, identifies the interface based on the MPLS label, and sends a plain IP packet to its TAP interface linked to eth0 of the VM.<\/li>\n<\/ol>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/outside-dp-reverse.png\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/ba6748694a822fc04f4e872658d1fbbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<h4>Control Plane<\/h4>\n<p>\nVNGW1 opretter BGP-nabo med SDN-controlleren, som den modtager al ruteinformation om kunder fra: hvilke IP-adresser (vRoutere) hver kunde er tilknyttet, og hvilken MPLS-m\u00e6rkning de identificeres med.<\/p>\n<p>Ligeledes informerer den SDN-controlleren om standardruten med kundens m\u00e6rkning, mens den angiver sig selv som nexthop. Og s\u00e5 kommer denne standardrute ind p\u00e5 vRouterne.<\/p>\n<p>Route aggregation or NAT translation typically occurs at VNGW.<\/p>\n<p>Og i den modsatte retning sender den netop denne aggregerede rute til sessionen med border- eller Route Reflector'er. Og fra dem modtager den standardruten eller Full-View, eller noget andet.<\/p>\n<p>In terms of encapsulation and traffic exchange, VNGW is no different from vRouter. <br \/>\nHvis vi udvider omr\u00e5det en smule, kan VNGW og vRoutere tilf\u00f8jes andre netv\u00e6rksenheder som firewalls, trafikrense- eller berigelsesfarmen, IPS osv.<\/p>\n<p>Og ved successivt at oprette VRF og korrekt annoncere ruter kan du f\u00e5 trafik til at sno sig, som du \u00f8nsker, det kaldes Service Chaining.<\/p>\n<p>Det vil sige, at SDN-controlleren ogs\u00e5 fungerer som Route Reflector mellem VNGW, vRoutere og andre netv\u00e6rksenheder.<\/p>\n<p>But in fact, the controller also provides information about ACL and PBR (Policy Based Routing), forcing individual traffic flows not to follow the route dictated to them.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/outside-cp.png\"><img decoding=\"async\" alt=\"Automatisering For De Mindste. F\u00f8rste del (den der kommer efter nul). Netv\u00e6rksvirtualisering\" src=\"\/wp-content\/uploads\/2019\/07\/dbba5a93d64edf56dc9c2b82311c5a11.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<h1>FAQ<\/h1>\n<p><b>Why do you keep making the remark about GRE\/UDP?<\/b><\/p>\n<p>Well, actually, it can be said to be specific to Tungsten Fabric \u2014 it can really be disregarded.<\/p>\n<p>Men hvis man ser p\u00e5 det, s\u00e5 havde TF, selv da det var OpenContrail, st\u00f8tte for begge indkapslinger: MPLS i GRE og MPLS i UDP. <\/p>\n<p>UDP is advantageous because in the Source Port of its header, it is very easy to encode a hash function from the original IP+Proto+Port, allowing for load balancing. <\/p>\n<p>In the case of GRE, unfortunately, there are only external IP and GRE headers, which are the same for all encapsulated traffic, and load balancing is not an option \u2014 few can look that deeply inside the packet.<\/p>\n<p>Indtil for nylig kunne routere, hvis de kunne h\u00e5ndtere dynamiske tunneller, kun g\u00f8re det via MPLSoGRE, og f\u00f8rst for nylig har de l\u00e6rt at h\u00e5ndtere MPLSoUDP. Derfor skal vi altid bem\u00e6rke muligheden for to forskellige kapslinger.<\/p>\n<p>For retf\u00e6rdighedens skyld er det v\u00e6rd at bem\u00e6rke, at TF ogs\u00e5 st\u00f8tter L2-forbindelse ved hj\u00e6lp af VXLAN.<\/p>\n<p>\n<b>Du lovede at drage paralleller til OpenFlow.<\/b><br \/>\nDe er faktisk n\u00e6rliggende. vSwitch i det samme OpenStack laver meget lignende ting ved at bruge VXLAN, som for \u00f8vrigt ogs\u00e5 har en UDP-hoved.<\/p>\n<p>I Data Plane arbejder de omtrent ens, men Control Plane adskiller sig v\u00e6sentligt. Tungsten Fabric bruger XMPP til at levere ruteoplysninger til vRouter, mens OpenStack bruger Openflow.<\/p>\n<p>\n<b>Kan du fort\u00e6lle lidt mere om vRouter?<\/b><br \/>\nDet opdeles i to dele: vRouter Agent og vRouter Forwarder.<\/p>\n<p>F\u00f8rstn\u00e6vnte k\u00f8rer i User Space af v\u00e6rtens OS og kommunikerer med SDN-kontrolleren ved at udveksle ruteinformation, VRF og ACL.<\/p>\n<p>Den anden implementerer Data Plane \u2013 normalt i Kernel Space, men kan ogs\u00e5 k\u00f8re p\u00e5 SmartNIC'er \u2013 netv\u00e6rkskort med CPU og en separat programmerbar switchchip, som aflaster CPU'en p\u00e5 v\u00e6rtsmaskinen og g\u00f8r netv\u00e6rket hurtigere og mere forudsigeligt. <\/p>\n<p>Der kan ogs\u00e5 v\u00e6re et scenarie, hvor vRouter er en DPDK-applikation i User Space. <\/p>\n<p>vRouter Agent sender indstillinger til vRouter Forwarder.<\/p>\n<p>\n<b>Hvad er Virtual Network?<\/b><br \/>\nJeg n\u00e6vnte i begyndelsen af artiklen VRF, om at hver tenant knyttes til sin egen VRF. Og mens dette var tilstr\u00e6kkeligt til en overfladisk forst\u00e5else af, hvordan overlay-netv\u00e6rket fungerer, er det n\u00f8dvendigt med pr\u00e6ciseringer i n\u00e6ste iteration.<\/p>\n<p>Normalt introduceres entiteten Virtual Network (man kan betragte dette som et egennavn) i virtualiseringsmekanismer separat fra klienter\/tenanter\/virtuelle maskiner \u2013 en helt selvst\u00e6ndig ting. Og dette Virtual Network kan via gr\u00e6nseflader tilsluttes til en tenant, en anden, to, ja hvor som helst. P\u00e5 denne m\u00e5de implementeres for eksempel Service Chaining, n\u00e5r trafik skal passes gennem bestemte noder i den \u00f8nskede r\u00e6kkef\u00f8lge ved blot at skabe og knytte Virtual Networks i den rigtige sekvens.<\/p>\n<p>Derfor er der ikke noget direkte forhold mellem Virtual Network og tenant.<\/p>\n<h1>Konklusion<\/h1>\n<p>\nDette er en ret overfladisk beskrivelse af, hvordan et virtuelt netv\u00e6rk fungerer med overlay fra v\u00e6rten og en SDN-controller. Men uanset hvilken virtualiseringsplatform du v\u00e6lger i dag, vil den fungere p\u00e5 lignende m\u00e5de, hvad enten det drejer sig om VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric eller Juniper Contrail. De vil variere i typerne af indkapslinger og headers, og de protokoller, der bruges til at levere information til de endelige netv\u00e6rksenheder, men princippet for et programmatisk konfigurerbart overlay-netv\u00e6rk, der fungerer oven p\u00e5 et relativt simpelt og statisk underlay-netv\u00e6rk, forbliver det samme.<br \/>\nMan kan sige, at omr\u00e5det for oprettelse af private cloud i dag er blevet vundet af SDN baseret p\u00e5 overlay-netv\u00e6rk. Det betyder dog ikke, at Openflow ikke har sin plads i den moderne verden - det anvendes i OpenStack og ogs\u00e5 i VMWare NSX, og s\u00e5 vidt jeg ved, bruger Google det til at konfigurere underlay-netv\u00e6rket.<\/p>\n<p>Lidt l\u00e6ngere nede har jeg inkluderet links til mere detaljerede materialer, hvis man \u00f8nsker at dykke dybere ind i emnet. <\/p>\n<p>Og hvad med vores Underlay? <\/p>\n<p>Og i det store hele er der ikke meget. Det har ikke \u00e6ndret sig hele vejen. Alt, hvad det skal g\u00f8re i tilf\u00e6lde af overlay fra v\u00e6rten, er at opdatere ruter og ARP'er, efterh\u00e5nden som vRouter\/VNGW dukker op og forsvinder, og transportere pakkerne imellem dem.<\/p>\n<p>Lad os formulere en liste over krav til Underlay-netv\u00e6rket.<\/p>\n<ol>\n<li>At kunne h\u00e5ndtere en eller anden routingprotokol, i vores tilf\u00e6lde - BGP.<\/li>\n<li>At have en bred b\u00e5ndbredde, helst uden overtegn, for at undg\u00e5 pakktab p\u00e5 grund af overbelastninger.<\/li>\n<li>At underst\u00f8tte ECMP - en uundg\u00e5elig del af fabrikken.<\/li>\n<li>At kunne sikre QoS, herunder nogle snedige ting som ECN.<\/li>\n<li>At underst\u00f8tte NETCONF - en investering i fremtiden.<\/li>\n<\/ol>\n<p>\nJeg har brugt meget lidt tid p\u00e5 selve Underlay-netv\u00e6rket her. Det er fordi, at jeg senere i serien vil fokusere netop p\u00e5 det, mens vi kun vil ber\u00f8re Overlay kort.<\/p>\n<p>Det er tydeligt, at jeg begr\u00e6nser os alle meget ved at bruge et data center-netv\u00e6rk bygget p\u00e5 Clos-fabrikken med ren IP-routing og overlay fra v\u00e6rten som eksempel.<\/p>\n<p>Jeg er dog overbevist om, at ethvert netv\u00e6rk med et design kan beskrives i formelle termer og automatiseres. Min hensigt her er blot at forst\u00e5 tilgange til automatisering, ikke at forvirre alle ved at l\u00f8se opgaven generelt.<\/p>\n<p>Som en del af ADSM planl\u00e6gger jeg og Roman Gorje at udgive et s\u00e6rskilt nummer om virtualisering af computing ressourcer og dens interaktion med netv\u00e6rksvirtualisering. Bliv ved med at f\u00f8lge med.<\/p>\n<p><\/p>\n<h1>Nyttige links<\/h1>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tungstenfabric.github.io\/website\/\">Tungsten Fabric Arkitektur<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/Kr6WIYPts8I?t=3157\">om:cloud<\/a><\/noindex>. 6 timer om Yandex.Cloud, hvor den virtuelle netv\u00e6rk p\u00e5 TF ogs\u00e5 diskuteres.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.openvswitch.org\/en\/latest\/intro\/what-is-ovs\/\">Hvad er Open vSwitch?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/344326\/\">Introduktion til VxLAN<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc7348\">RFC 7348. Virtual eXtensible Local Area Network (VXLAN): En ramme for overlaying virtualiserede lag 2 netv\u00e6rk over lag 3 netv\u00e6rk.<br \/>\n <\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.enog.org\/wp-content\/uploads\/presentations\/enog-16\/18-Scaleway-P14-fabric-ENOG16.pdf\">Scaleway tilgang til VXLAN EVPN Fabric<\/a><\/noindex>. Her beskrives hele netv\u00e6rket i datacenteret, inklusiv Underlay, Overlay, tilgange til multi-homing og styring.<\/li>\n<\/ul>\n<p><\/p>\n<h5>Tak<\/h5>\n<p><\/p>\n<ul>\n<li><noindex>Roman Gorge<\/noindex> \u2014 tidligere v\u00e6rt for podcasten linkmeup, og nu ekspert inden for cloud-platforme. Tak for kommentarer og redigeringer. Og vi ser frem til hans dybere artikel om virtualisering i n\u00e6r fremtid.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.alexander-shalimov.com\">Alexander Shalimov<\/a><\/noindex> \u2014 min kollega og ekspert inden for udvikling af virtuelle netv\u00e6rk. Tak for kommentarer og redigeringer.<\/li>\n<li><noindex>Valentin Sinitsyn<\/noindex> \u2014 min kollega og ekspert inden for Tungsten Fabric. Tak for kommentarer og redigeringer.<\/li>\n<li><noindex>Artem Chernobay<\/noindex> \u2014 illustrator for linkmeup. Tak for KDPV.<\/li>\n<li>Alexander Limonov. Tak for meme \"automato\".<\/li>\n<\/ul>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/458622\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u043c \u0432\u044b\u043f\u0443\u0441\u043a\u0435 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0444\u0440\u0435\u0439\u043c\u0432\u043e\u0440\u043a \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438. \u041f\u043e \u043e\u0442\u0437\u044b\u0432\u0430\u043c \u0443 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043b\u044e\u0434\u0435\u0439 \u0434\u0430\u0436\u0435 \u044d\u0442\u043e\u0442 \u043f\u0435\u0440\u0432\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043a \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0435 \u0443\u0436\u0435 \u0440\u0430\u0437\u043b\u043e\u0436\u0438\u043b \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u043f\u043e \u043f\u043e\u043b\u043e\u0447\u043a\u0430\u043c. \u0418 \u044d\u0442\u043e \u043e\u0447\u0435\u043d\u044c \u043c\u0435\u043d\u044f \u0440\u0430\u0434\u0443\u0435\u0442, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043d\u0430\u0448\u0430 \u0446\u0435\u043b\u044c \u0432 \u0446\u0438\u043a\u043b\u0435 \u2014 \u043d\u0435 \u043e\u0431\u043c\u0430\u0437\u0430\u0442\u044c \u043f\u0438\u0442\u043e\u043d\u043e\u0432\u0441\u043a\u0438\u043c\u0438 \u0441\u043a\u0440\u0438\u043f\u0442\u0430\u043c\u0438 \u0430\u043d\u0437\u0438\u0431\u043b\u044c, \u0430 \u0432\u044b\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u0443. \u042d\u0442\u043e\u0442 \u0436\u0435 \u0444\u0440\u0435\u0439\u043c\u0432\u043e\u0440\u043a \u0437\u0430\u0434\u0430\u0451\u0442 \u043f\u043e\u0440\u044f\u0434\u043e\u043a, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u043c\u044b \u0431\u0443\u0434\u0435\u043c \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u0442\u044c\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26892,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35973","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u043c \u0432\u044b\u043f\u0443\u0441\u043a\u0435 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0444\u0440\u0435\u0439\u043c\u0432\u043e\u0440\u043a \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0414\u043b\u044f \u0421\u0430\u043c\u044b\u0445 \u041c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445. \u0427\u0430\u0441\u0442\u044c \u043f\u0435\u0440\u0432\u0430\u044f (\u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u043e\u0441\u043b\u0435 \u043d\u0443\u043b\u0435\u0432\u043e\u0439). \u0412\u0438\u0440\u0442\u0443\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0435\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u043c \u0432\u044b\u043f\u0443\u0441\u043a\u0435 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0444\u0440\u0435\u0439\u043c\u0432\u043e\u0440\u043a \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:08:54+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:08:54+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Automatisering For De Mindste. Del f\u00f8rste (som kommer efter nul). Virtualisering af netv\u00e6rk | ProHoster","description":"I det forrige afsnit beskrev jeg rammev\u00e6rket for netv\u00e6rksautomatisering.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0414\u043b\u044f \u0421\u0430\u043c\u044b\u0445 \u041c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445. \u0427\u0430\u0441\u0442\u044c \u043f\u0435\u0440\u0432\u0430\u044f (\u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u043e\u0441\u043b\u0435 \u043d\u0443\u043b\u0435\u0432\u043e\u0439). \u0412\u0438\u0440\u0442\u0443\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0435\u0442\u0438 | ProHoster","og:description":"\u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u043c \u0432\u044b\u043f\u0443\u0441\u043a\u0435 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0444\u0440\u0435\u0439\u043c\u0432\u043e\u0440\u043a \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:08:54+00:00","article:modified_time":"2019-10-31T19:08:54+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35973","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:28:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:30","updated":"2026-01-22 01:28:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/35973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=35973"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/35973\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/26892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=35973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=35973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=35973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}