{"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\/nl\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-pervaya-kotoraya-posle-nulevoj-virtualizatsiya-seti","title":{"rendered":"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/453516\/\">de vorige release<\/a><\/noindex> Ik heb een kader voor netwerkautomatisering beschreven. Volgens feedback van sommige mensen heeft zelfs deze eerste benadering van het probleem al enkele vragen helderheid gegeven. Dit maakt me erg blij, omdat ons doel in de cyclus niet is om Ansible vol te stoppen met Python-scripts, maar om een systeem op te bouwen.<\/p>\n<p>Ditzelfde kader stelt de volgorde vast waarin we de kwestie zullen aanpakken.<br \/>\nEn netwerkvirtualisatie, waar deze aflevering aan gewijd is, valt niet helemaal binnen het thema van ADSM, waar we de automatisering behandelen. <\/p>\n<p>Maar laten we er vanuit een ander perspectief naar kijken.<\/p>\n<p>Al geruime tijd maken veel diensten gebruik van hetzelfde netwerk. Voor een telecomoperator gaat dit om 2G, 3G, LTE, DSL en B2B, bijvoorbeeld. Voor datacenters: connectiviteit voor verschillende klanten, internet, block storage, object storage.<\/p>\n<p>En alle diensten vereisen isolatie van elkaar. Dit heeft geleid tot de ontwikkeling van overlay-netwerken.<\/p>\n<p>En alle diensten willen niet wachten tot iemand ze handmatig instelt. Dit heeft geleid tot de ontwikkeling van orchestrators en SDN.<\/p>\n<p>De eerste benadering van systematische netwerkautomatisering, of beter gezegd een deel daarvan, is al geruime tijd ondernomen en op veel plaatsen ge\u00efmplementeerd: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.<\/p>\n<p>Daar zullen we vandaag dieper op ingaan. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/kdpv.jpg\"><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" 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>Inhoud<\/h1>\n<p><\/p>\n<ul>\n<li><b>Redenen<\/b><\/li>\n<li><b>Terminologie<\/b><\/li>\n<li><b>Underlay \u2014 fysieke netwerk<\/b><\/li>\n<li><b>Overlay \u2014 virtueel netwerk<\/b>\n<ul>\n<li>Overlay met ToR'a<\/li>\n<li>Overlay vanaf de host<\/li>\n<li>Aan het voorbeeld van Tungsten Fabric\n<ul>\n<li>Communicatie binnen \u00e9\u00e9n fysieke machine<\/li>\n<li>Communicatie tussen VM's op verschillende fysieke machines<\/li>\n<li>Toegang tot de buitenwereld<\/li>\n<\/ul>\n<p>\n <\/li>\n<\/ul>\n<p>\n <\/li>\n<li><b>FAQ<\/b><\/li>\n<li><b>Conclusie<\/b><\/li>\n<li><b>Nuttige links<\/b><\/li>\n<\/ul>\n<p><\/p>\n<h1>Redenen<\/h1>\n<p>\nEn aangezien we het daarover hebben, is het de moeite waard om de voorwaarden voor netwerkvirtualisatie te noemen. Dit proces is in werkelijkheid al een tijd aan de gang. <\/p>\n<p>Misschien hebt u wel eens gehoord dat netwerken altijd de meest trage schakel van elk systeem zijn geweest. En dat is in alle opzichten waar. Het netwerk is de basis waarop alles steunt, en veranderingen aanbrengen is vrij lastig \u2014 diensten kunnen niet wachten als het netwerk uitvalt. Vaak kan het buiten gebruik stellen van \u00e9\u00e9n knooppunt een groot aantal applicaties be\u00efnvloeden en talloze klanten raken. Dit is deels de reden waarom het netwerkteam kan terughoudend zijn wat betreft wijzigingen \u2014 omdat het nu op zijn minst werkt (<i>misschien weten we zelfs niet hoe<\/i>), en nu moet er iets nieuws worden ingesteld, en het is onbekend hoe dit het netwerk zal be\u00efnvloeden.<\/p>\n<p>Om niet te hoeven wachten tot netwerkbeheerders VLAN instellen en om services niet op elk knooppunt van het netwerk te hoeven configureren, hebben mensen overlays bedacht - op elkaar liggende netwerken - waarvan er vele soorten zijn: GRE, IPinIP, MPLS, MPLS L2\/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, enzovoort.<\/p>\n<p>Hun aantrekkelijkheid ligt in twee simpele dingen:<\/p>\n<ul>\n<li>Alleen de eindknopen hoeven te worden geconfigureerd - transitknooppunten blijven onaangeroerd. Dit versnelt het proces aanzienlijk en stelt soms zelfs in staat om de afdeling netwerkinfrastructuur uit het proces van het invoeren van nieuwe services te verwijderen.<\/li>\n<li>De belasting is diep verborgen in de headers - transitknooppunten hoeven hier niet van op de hoogte te zijn, noch van de adressering op hosts of de routes van het overlay-netwerk. Dit betekent dat er minder informatie in de tabellen hoeft te worden opgeslagen, waardoor eenvoudiger\/goedkopere apparatuur kan worden gebruikt.<\/li>\n<\/ul>\n<p>\nIn deze niet helemaal volwaardige aflevering ga ik niet alle mogelijke technologie\u00ebn bespreken, maar eerder de werkstructuur van overlay-netwerken in datacenters beschrijven.<\/p>\n<p>De hele serie zal een datacenter beschrijven dat bestaat uit rijen identieke racks, waarin identieke servers zijn ge\u00efnstalleerd. <\/p>\n<p>Op deze apparatuur worden virtuele machines\/container\/serverless uitgevoerd die de diensten realiseren.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/a6863eb2804a298304d1e93daecf90d9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h1>Terminologie<\/h1>\n<p>\nIn de cyclus <b>server<\/b> zal ik het programma dat de serverzijde van de client-servercommunicatie implementeert, aanduiden.<\/p>\n<p>Fysieke machines in racks zullen we servers noemen <b>niet<\/b> .<\/p>\n<p><b>Een fysieke machine<\/b> is een x86-computer die in een rack is ge\u00efnstalleerd. Het meest gebruikte begrip is <b>host<\/b>. Zo zullen we het noemen &#171;<b>machine<\/b>&#187; of <b>host<\/b>.<\/p>\n<p><b>Hypervisor<\/b> is een applicatie die op een fysieke machine draait en fysieke middelen emuleert waarop Virtuele Machines worden uitgevoerd. Soms wordt in de literatuur en op het internet het woord 'hypervisor' als synoniem voor 'host' gebruikt.<\/p>\n<p><b>Virtuele machine<\/b> \u2014 een besturingssysteem dat draait op een fysieke machine bovenop een hypervisor. Voor ons is het in dit kader niet zo belangrijk of het nu echt een virtuele machine is of gewoon een container. We zullen het &#171; noemen<b>VM<\/b>\u00ab<\/p>\n<p><b>Tenant<\/b> is een brede term die ik in dit artikel zal defini\u00ebren als een afzonderlijke service of een afzonderlijke klant.<\/p>\n<p><b>Multi-tenancy<\/b> of multi-huur is het gebruik van dezelfde applicatie door verschillende klanten\/diensten. Hierbij wordt de isolatie van klanten van elkaar bereikt door de architectuur van de applicatie en niet door afzonderlijk uitgevoerde instanties.<\/p>\n<p><b>ToR \u2014 Top of the Rack switch<\/b> \u2014 een switch die in een rack is ge\u00efnstalleerd, waaraan alle fysieke machines zijn aangesloten.<\/p>\n<blockquote><p> Naast de ToR-topologie passen verschillende providers End of Row (EoR) of Middle of Row toe (hoewel de laatste zeldzaam is en ik de afkorting MoR nog niet ben tegengekomen).\n<\/p><\/blockquote>\n<p> <b>Underlay netwerk<\/b> of het onderliggende netwerk of underlay \u2014 de fysieke netwerkinfrastructuur: switches, routers, kabels.<\/p>\n<p><b>Overlay netwerk<\/b> of het overlay netwerk \u2014 een virtueel netwerk van tunnels dat bovenop de fysieke laag werkt.<\/p>\n<p><b>L3-fabriek of IP-fabriek<\/b> \u2014 een geweldig uitvinding van de mensheid, waardoor je tijdens gesprekken niet STP hoeft te herhalen en TRILL niet hoeft te leren. Een concept waarbij het hele netwerk tot aan de toegang laag uitsluitend L3 is, zonder VLAN's en bijgevolg enorme, uitgestrekte broadcast domeinen. Waar de term 'fabriek' vandaan komt, bespreken we in het volgende deel.<\/p>\n<p><b>SDN<\/b> \u2014 Software Defined Network. Heeft nauwelijks introductie nodig. Een benadering voor netwerken waarbij veranderingen niet door mensen, maar door software worden uitgevoerd. Betekent meestal dat het Control Plane buiten de eindnetwerkapparaten naar een controller wordt verhuisd.<\/p>\n<p><b>NFV<\/b> \u2014 Network Function Virtualization \u2014 de virtualisatie van netwerkapparaten, waarbij sommige functies van het netwerk kunnen worden uitgevoerd als virtuele machines of containers om de implementatie van nieuwe services, het organiseren van Service Chaining en eenvoudiger horizontale schaalbaarheid te versnellen.<\/p>\n<p><b>VNF<\/b> \u2014 Virtual Network Function. Een specifiek virtueel apparaat: router, switch, firewall, NAT, IPS\/IDS, enz.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/971b6a28a9caab5f3a7067ce4d25749c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<blockquote><p> Ik vereenvoudig de beschrijving opzettelijk tot een specifieke implementatie om de lezer niet te verwarren. Voor een zorgvuldiger lezen verwijs ik naar de sectie <noindex><a rel=\"nofollow\" href=\"#LINKS\">Links<\/a><\/noindex>. Bovendien belooft Roma Gorg\u00e9, die dit artikel bekritiseert vanwege onnauwkeurigheden, een aparte editie te schrijven over server- en netwerktechnologie\u00ebn, die dieper ingaat op de details.<\/p><\/blockquote>\n<p>De meeste netwerken kunnen vandaag de dag duidelijk in twee delen worden opgesplitst: <\/p>\n<p><b>Underlay<\/b> \u2014 een fysiek netwerk met een stabiele configuratie.<br \/>\n<b>Overlay<\/b> \u2014 een abstractie bovenop de Underlay voor isolatie van tenants. <\/p>\n<p>Dit geldt zowel voor datacenters (die we in dit artikel bespreken) als voor ISP's (die we niet zullen bespreken, omdat dit al in <noindex><a rel=\"nofollow\" href=\"https:\/\/linkmeup.ru\/sdsm\">SDCM<\/a><\/noindex>). De situatie is natuurlijk iets anders bij enterprise-netwerken. <\/p>\n<p>Afbeelding met focus op het netwerk:<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" 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 is a physical network: hardware switches and cables. Devices in the underlay know how to reach the physical machines.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/776a77a3821fe79a7323947e0bdf67e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIt relies on standard protocols and technologies. Not least because hardware devices still operate on proprietary software that does not allow chip programming or the implementation of their own protocols, making compatibility with other vendors and standardization necessary.<\/p>\n<blockquote><p>But someone like Google can afford to develop its own switches and abandon commonly accepted protocols. However, LAN_DC is not Google.\n<\/p><\/blockquote>\n<p> Underlay changes relatively rarely because its task is basic IP connectivity between physical machines. The underlay knows nothing about the services, clients, or tenants running above it \u2014 it only needs to deliver packets from one machine to another.<br \/>\nAn example of Underlay might be: <\/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>\nHet Underlay-netwerk wordt op de klassieke manier ingesteld: CLI\/GUI\/NETCONF.<\/p>\n<p>Manually, with scripts, proprietary utilities.<\/p>\n<p>A more detailed article on the underlay will be dedicated to the next part of the series.<\/p>\n<p><\/p>\n<h1>Overlay<\/h1>\n<p>\nOverlay is a virtual network of tunnels stretched over the Underlay, allowing a client's VMs to communicate with each other while ensuring isolation from other clients.<\/p>\n<p>Client data is encapsulated in tunneling headers for transmission across the shared network.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/3060bc4913c55c21b785083fbe0b603b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThus, a client's VMs (from one service) can communicate with each other through the Overlay without even realizing the actual path the packet takes. <\/p>\n<p>An example of Overlay could be, as I mentioned earlier:<\/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>\nHet Overlay-netwerk wordt doorgaans ingesteld en beheerd via een centrale controller. Van daaruit worden de configuratie, Control Plane en Data Plane naar de apparaten verzonden die verantwoordelijk zijn voor het routeren en encapsuleren van het klantverkeer. Een beetje <noindex><a rel=\"nofollow\" href=\"#TF\">below<\/a><\/noindex> we will break this down with examples.<\/p>\n<p><b>Yes, this is pure SDN. <\/b><\/p>\n<p>There are two fundamentally different approaches to organizing an Overlay network:<\/p>\n<ol>\n<li>Overlay met ToR'a<\/li>\n<li>Overlay vanaf de host<\/li>\n<\/ol>\n<h2>Overlay met ToR'a<\/h2>\n<p>\nOverlay can start on an access switch (ToR) located in the rack, as is the case, for example, in a VXLAN factory. <\/p>\n<p>This is a time-tested mechanism in ISP networks, and all network equipment vendors support it.<\/p>\n<p>In dit geval moet de ToR-switch verschillende diensten kunnen scheiden, en de netwerkbeheerder moet in zekere mate samenwerken met de beheerders van virtuele machines en wijzigingen (zelfs automatisch) in de configuratie van de apparaten aanbrengen.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/9a5fe4d4a0cbb7e5c3bbac82527c6a6a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHierverwijs ik de lezer naar het artikel over <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/344326\/\">VxLAN op Habr\u00e9<\/a><\/noindex> onze oude vriend <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/bormoglotx\/\">@bormoglotx<\/a><\/noindex>.<br \/>\nIn dit <noindex><a rel=\"nofollow\" href=\"https:\/\/www.enog.org\/wp-content\/uploads\/presentations\/enog-16\/18-Scaleway-P14-fabric-ENOG16.pdf\">de presentatie op ENOG<\/a><\/noindex> gaan de benaderingen voor de constructie van datacenter-netwerken met EVPN VXLAN-fabrieken uitgebreid aan bod. <\/p>\n<p>Voor een completer inzicht in de realiteit kan men het boek van Cisco lezen, <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> Ik bemerk dat VXLAN slechts een methode van encapsulatie is en de terminatie van tunnels kan niet op de ToR plaatsvinden, maar op de host, zoals het geval is bij OpenStack bijvoorbeeld.<\/p>\n<p>Echter, een VXLAN-fabriek waarbij de overlay begint op de ToR is een van de gevestigde ontwerpen van overlay-netwerken.\n<\/p><\/blockquote>\n<p><\/p>\n<h2>Overlay vanaf de host<\/h2>\n<p>\nEen andere benadering is om de tunnels op de eindhosts te starten en te termineren.<br \/>\nIn dit geval blijft het netwerk (Underlay) zo eenvoudig en statisch mogelijk.<br \/>\nDe host zelf voert alle benodigde encapsulaties uit.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/c9c2971369d1b3e5f026d6844afeb67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDit vereist inderdaad het draaien van een speciale applicatie op de hosts, maar dat is het waard. <\/p>\n<p>Ten eerste is het eenvoudiger om een cli\u00ebnt op een Linux-machine te starten of, laten we zeggen, is het \u00fcberhaupt mogelijk, terwijl je op de switch waarschijnlijk gebruik zult moeten maken van propri\u00ebtaire SDN-oplossingen, wat het idee van multi-vendor-compatibiliteit tenietdoet.<\/p>\n<p>Ten tweede kan de ToR-switch in dit geval zo eenvoudig mogelijk worden gehouden, zowel vanuit het perspectief van de Control Plane als van de Data Plane. Inderdaad, met een SDN-controller hoeft hij dan niet te communiceren en hoeft hij ook niet de netwerken\/ARP's van alle aangesloten klanten op te slaan \u2014 het is voldoende om het IP-adres van de fysieke machine te kennen, wat de switching\/routing-tabellen aanzienlijk vereenvoudigt.<\/p>\n<p>\nIn de ADSK-serie kies ik voor de overlay-benadering vanaf de host \u2014 hier bespreken we alleen dat onderwerp en we zullen niet terugkeren naar de VXLAN-fabriek.<\/p>\n<p>\nHet is het gemakkelijkst om dit aan de hand van voorbeelden te bekijken. En als proeftuin nemen we het open-source SDN-platform OpenContrail, tegenwoordig bekend als <noindex><a rel=\"nofollow\" href=\"https:\/\/tungsten.io\">Tungsten Fabric<\/a><\/noindex>.<\/p>\n<blockquote><p> Aan het einde van het artikel zal ik enkele overpeinzingen delen over de analogie met OpenFlow en OpenvSwitch.\n<\/p><\/blockquote>\n<p><\/p>\n<h2>Aan het voorbeeld van Tungsten Fabric<\/h2>\n<p>\nOp elke fysieke machine zijn er <b>vRouter<\/b> \u2014 een virtuele router die op de hoogte is van de netwerken die eraan zijn gekoppeld en aan welke klanten deze behoren \u2014 in wezen een PE-router. Voor elke klant houdt hij een ge\u00efsoleerde routingtabel bij (lees VRF). En de vRouter zorgt voor de overlay-tunneling.<\/p>\n<p>Wat betreft de vRouter \u2014 aan het einde van het artikel meer.<\/p>\n<p>Elke VM die op de hypervisor is geplaatst, is verbonden met de vRouter van deze machine via <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 een virtuele interface in de Linux-kernel, die netwerkintegratie mogelijk maakt.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/a6fa1b4370ba4e787303ae647a28f5ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAls er achter de vRouter meerdere netwerken zijn, wordt er voor elk een virtuele interface aangemaakt waarop een IP-adres wordt toegewezen \u2014 dit wordt het standaard gateway-adres.<br \/>\nAlle netwerken van \u00e9\u00e9n klant worden in \u00e9\u00e9n <b>VRF<\/b> (\u00e9\u00e9n tabel) geplaatst, verschillende \u2014 in verschillende.<br \/>\n<i>Ik wil hier een kanttekening maken dat niet alles zo eenvoudig is en ik stuur de nieuwsgierige lezer naar het einde van het artikel.<\/i>.<\/p>\n<p>Zodat de vRouters met elkaar kunnen communiceren, en dus ook de VMs die erachter zitten, wisselen ze routeninformatie uit via <b>SDN-controller<\/b>.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/sdn-controller.png\"><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/8b133e10582dbde9c0670ad98c1840de.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Om de buitenwereld te bereiken, is er een uitgangspunt uit de matrix \u2014 de gateway van het virtuele netwerk. <b>VNGW<\/b> \u2014 Virtual Network GateWay (<i>de term is van mij)<\/i>).<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/vngw.png\"><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/9ac4d084d9b58b7ed1bc2c0ed6d06059.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>\nLaten we nu voorbeelden van communicatie bekijken \u2014 dan zal het duidelijk zijn.<\/p>\n<p><\/p>\n<h3>Communicatie binnen \u00e9\u00e9n fysieke machine<\/h3>\n<p>\nVM0 wil een pakket naar VM2 sturen. Laten we voorlopig aannemen dat dit VM's van dezelfde klant zijn.<\/p>\n<h4>Data Plane<\/h4>\n<p><\/p>\n<ol>\n<li>VM-0 heeft een standaardroute naar zijn interface eth0. Het pakket wordt daarheen gestuurd.<br \/>\n Deze interface eth0 is in feite virtueel verbonden met de virtuele router vRouter via de TAP-interface tap0.<\/li>\n<li>vRouter analyseert via welke interface het pakket is ontvangen, dat wil zeggen aan welke klant (VRF) het behoort, en vergelijkt het ontvangstadres met de routeringstabel van die klant.<\/li>\n<li>Wanneer de vRouter ontdekt dat de ontvanger op dezelfde machine aan een andere poort zit, stuurt hij het pakket gewoon naar hem zonder extra headers \u2014 in dit geval is er al een ARP-record op de vRouter. <\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/a42da3f48a3f538eb92c1908d9d66921.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn dit geval komt het pakket niet in het fysieke netwerk \u2014 het is binnen de vRouter gemarshroutriseerd.<\/p>\n<p><\/p>\n<h4>Control Plane<\/h4>\n<p>\nDe hypervisor geeft bij het opstarten van de virtuele machine aan:<\/p>\n<ul>\n<li>Haar eigen IP-adres.<\/li>\n<li>De standaardroute gaat via het IP-adres van de vRouter in dit netwerk.<\/li>\n<\/ul>\n<p>\nDe vRouter ontvangt via een speciale API van de hypervisor:<\/p>\n<ul>\n<li>Dat er een virtuele interface moet worden aangemaakt.<\/li>\n<li>Welke Virtual Network (VN) er moet worden aangemaakt.<\/li>\n<li>Aan welke VRF deze (VN) moet worden gekoppeld.<\/li>\n<li>De statische ARP-vermelding voor deze VM - achter welke interface haar IP-adres zich bevindt en aan welk MAC-adres het is gekoppeld.<\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p> En opnieuw is de werkelijke interactieprocedure vereenvoudigd ten behoeve van het begrip van het concept.\n<\/p><\/blockquote>\n<p> <img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/593d7ad41782e882a88732b475bf91cb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZo ziet vRouter alle VM's van dezelfde klant op deze machine als direct aangesloten netwerken en kan hij zelfstandig tussen deze netwerken routeren.<\/p>\n<p>\nVM0 en VM1 behoren tot verschillende klanten en staan dus in verschillende tabellen van de vRouter.<\/p>\n<p>Of ze rechtstreeks met elkaar kunnen communiceren hangt af van de instellingen van de vRouter en het netwerkontwerp.<br \/>\nAls beide klanten VM's publieke adressen gebruiken of als NAT op de vRouter zelf plaatsvindt, kan directe routering op de vRouter worden uitgevoerd.<\/p>\n<p>In een andere situatie kunnen de adresruimten zich overlappen - je moet via een NAT-server om een publiek adres te verkrijgen - dit lijkt op het naar externe netwerken gaan, waarover hieronder meer.<\/p>\n<h3>Communicatie tussen VM's op verschillende fysieke machines<\/h3>\n<p><\/p>\n<h4>Data Plane<\/h4>\n<p><\/p>\n<ol>\n<li>Het begin is precies hetzelfde: VM-0 verzendt een pakket met als bestemmingsadres VM-7 (172.17.3.2) volgens zijn standaard.<\/li>\n<li>vRouter ontvangt het en ziet deze keer dat de ontvanger zich op een andere machine bevindt en bereikbaar is via tunnel Tunnel0.<\/li>\n<li>Eerst hangt hij een MPLS-label aan, dat de externe interface identificeert, zodat de vRouter aan de andere kant weet waar hij dit pakket zonder aanvullende haken moet plaatsen.\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/inter-hv-dp.png\"><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/1e159049376e2bf458b8c6cb5878cc17.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex>\n <\/li>\n<li>Tunnel0 heeft een bron van 10.0.0.2, bestemmeling: 10.0.1.2.<br \/>\n vRouter voegt GRE (of UDP) headers toe en een nieuw IP aan het oorspronkelijke pakket.<\/li>\n<li>In de routingtabel heeft vRouter een standaardroute via adres ToR1 10.0.0.1. Dat is waar hij naartoe verzendt.\n<p> <img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/8cb98a8ec43d202259acf6a1fcaeb3ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n \n <\/li>\n<li>ToR1, als deelnemer aan het Underlay-netwerk, weet (bijvoorbeeld via OSPF) hoe hij 10.0.1.2 moet bereiken en verzendt het pakket via de route. Let op dat hier ECMP wordt ingeschakeld. In de illustratie zijn er twee next-hops, en verschillende stromen worden volgens de hash verdeeld.\n<p>Hij hoeft echter niet te weten wat er onder de externe IP-header ligt. Dit betekent dat er feitelijk onder IP een sandwich van IPv6 over MPLS over Ethernet over MPLS over GRE over over over GRE kan zijn.<\/li>\n<li>Aan de ontvangende zijde verwijdert vRouter GRE en begrijpt hij aan de hand van het MPLS-label naar welke interface dit pakket moet worden doorgestuurd, opent het en verzendt het in zijn oorspronkelijke vorm naar de ontvanger.<\/li>\n<\/ol>\n<h4>Control Plane<\/h4>\n<p>\nBij het opstarten van de machine gebeurt alles wat hierboven is beschreven.<\/p>\n<p>En daarnaast nog het volgende:<\/p>\n<ul>\n<li>Voor elke klant wijst de vRouter een MPLS-label toe. Dit is een service-label voor L3VPN, waarmee klanten binnen dezelfde fysieke machine van elkaar worden gescheiden.<br \/>\n<blockquote><p> In werkelijkheid wordt de MPLS-label altijd door de vRouter toegewezen \u2014 want het is van tevoren onbekend of de machine alleen met andere machines achter dezelfde vRouter zal communiceren, en dat is waarschijnlijk zelfs niet het geval. \n <\/p><\/blockquote>\n<\/li>\n<li>De vRouter maakt verbinding met de SDN-controller via het BGP-protocol (of een vergelijkbaar protocol \u2014 in het geval van TF is dat XMPP 0_o).<\/li>\n<li>Via deze sessie geeft de vRouter de SDN-controller de routes naar de aangesloten netwerken door:\n<ul>\n<li>Netwerkadres<\/li>\n<li>Incapsulatiemethode (MPLSoGRE, MPLSoUDP, VXLAN)<\/li>\n<li>MPLS-label van de klant<\/li>\n<li>Eigen IP-adres als nexthop<\/li>\n<\/ul>\n<p>\n <\/li>\n<li>De SDN-controller ontvangt dergelijke routes van alle aangesloten vRouters en reflecteert deze naar anderen. Dat wil zeggen, hij fungeert als Route Reflector.<\/li>\n<\/ul>\n<p>\nHetzelfde gebeurt ook in de omgekeerde richting.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/inter-hv-cp.png\"><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/feef9181133f3a50a5cb21aa7ba16dc0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>De overlay kan elke minuut veranderen. Zo gaat het ongeveer in publieke clouds, wanneer klanten regelmatig hun virtuele machines opstarten en uitschakelen.<\/p>\n<p>De centrale controller neemt alle moeilijkheden op zich met het onderhouden van de configuratie en het beheren van de switch-\/routertabellen op de vRouter.<\/p>\n<p>In grove termen verbindt de controller zich met alle vRouters via BGP (of een vergelijkbaar protocol) en geeft eenvoudig de route-informatie door. BGP heeft bijvoorbeeld al een Address-Family voor het doorgeven van de encapsulatiemethode. <noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc4023\">MPLS-in-GRE<\/a><\/noindex> of <noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc7510\">MPLS-in-UDP<\/a><\/noindex>.<\/p>\n<p>De configuratie van het Underlay-netwerk verandert hierbij op geen enkele manier, wat overigens aanzienlijk moeilijker te automatiseren is, terwijl het gemakkelijker is om het met een onhandige beweging te verstoren.<\/p>\n<h3>Toegang tot de buitenwereld<\/h3>\n<p>\nOp een bepaald moment moet de simulatie eindigen en moet je de virtuele wereld verlaten om de echte binnen te gaan. En daarvoor is een gateway-telefoon nodig.<\/p>\n<p>Er worden twee benaderingen toegepast:<\/p>\n<ol>\n<li>Er wordt een hardware-router geplaatst.<\/li>\n<li>Er wordt een appliance opgestart die de functies van een router uitvoert (ja, ja, na SDN hebben we ook met VNF te maken gehad). Laten we het de virtuele gateway noemen.<\/li>\n<\/ol>\n<p><\/p>\n<blockquote><p> Het voordeel van de tweede benadering is de goedkope horizontale schaalbaarheid \u2014 als er niet genoeg vermogen is, start je gewoon nog een virtuele machine met een gateway. Op elke fysieke machine, zonder dat je hoeft te zoeken naar beschikbare racks, eenheden, voeding, de hardware zelf aan te schaffen, deze te vervoeren, te installeren, te verbinden, in te stellen, en daarna ook nog eens de defecte componenten te vervangen.<\/p>\n<p>De nadelen van een virtuele gateway zijn echter dat de eenheid van de fysieke router nog steeds veel krachtiger is dan de multicore virtuele machine, en dat de software, die is afgestemd op zijn hardware, aanzienlijk stabieler werkt (<i>nee<\/i>). Het is ook moeilijk om het feit te ontkennen dat het software-hardwarecomplex gewoon werkt, vereist alleen configuratie, terwijl de implementatie en het onderhoud van een virtuele gateway een taak is voor sterke ingenieurs.\n<\/p><\/blockquote>\n<p> Met \u00e9\u00e9n voet kijkt de gateway naar het virtuele Overlay-netwerk, zoals een gewone Virtuele Machine, en kan het met alle andere VM's communiceren. Tegelijkertijd kan het de netwerken van alle klanten afhandelen en dus routing tussen hen uitvoeren.<\/p>\n<p>Met de andere voet kijkt de gateway naar het backbone-netwerk en weet hoe het naar het internet moet.<\/p>\n<p><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/552fa0428ff8dd3aed76091a86a72109.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>Data Plane<\/h4>\n<p>\nDus het proces ziet er als volgt uit: <\/p>\n<ol>\n<li>VM-0, met de standaard naar de vRouter, verzendt een pakket met een bestemming in de externe wereld (185.147.83.177) naar de interface eth0.<\/li>\n<li>De vRouter ontvangt dit pakket en kijkt naar het bestemmingsadres in de routeringstabel \u2014 vindt de standaardroute via de gateway VNGW1 via Tunnel 1. <br \/>\n Het ziet ook dat dit een GRE-tunnel is met SIP 10.0.0.2 en DIP 10.0.255.2, en dat eerst de MPLS-tag van deze klant moet worden toegevoegd, die VNGW1 verwacht.\n <\/li>\n<li>De vRouter verpakt het oorspronkelijke pakket in MPLS-, GRE- en nieuwe IP-koppen en verzendt het naar het adres ToR1 10.0.0.1 volgens de standaard.<\/li>\n<li>Het onderliggende netwerk levert het pakket af bij de gateway VNGW1.<\/li>\n<li>De gateway VNGW1 verwijdert de tunneling-koppen GRE en MPLS, ziet het bestemmingsadres, raadpleegt zijn routeringstabel en begrijpt dat het naar het internet is gericht \u2014 dus via Full View of Default. Indien nodig voert het NAT-vertaling uit.<\/li>\n<li>Van VNGW naar de border kan een gewone IP-netwerk zijn, wat onwaarschijnlijk is.<br \/>\n Het kan een klassieke MPLS-netwerk zijn (IGP+LDP\/Rsvp TE), een terugfabriek met BGP LU of een GRE-tunnel van VNGW naar de border via een IP-netwerk.<br \/>\n Hoe dan ook, VNGW1 voert de noodzakelijke encapsulaties uit en verzendt het oorspronkelijke pakket in de richting van de 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=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/a66e490c75f8220349398af814d4ebf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Het verkeer in de omgekeerde richting doorloopt dezelfde stappen in omgekeerde volgorde. <\/p>\n<ol>\n<li>De border levert het pakket af bij VNGW1.<\/li>\n<li>Die ontledigt het, kijkt naar het ontvangstadres en ziet dat het beschikbaar is via de tunnel Tunnel1 (MPLSoGRE of MPLSoUDP).<\/li>\n<li>Daarom plaatst het een MPLS-tag, GRE\/UDP-kop en nieuw IP en verzendt het naar zijn ToR3 10.0.255.1.<br \/>\n Het bestemmingsadres van de tunnel is het IP-adres van de vRouter waarachter de doel-VM zich bevindt \u2014 10.0.0.2.<\/li>\n<li>Het onderliggende netwerk levert het pakket af bij de juiste vRouter. <\/li>\n<li>De doel-vRouter verwijdert GRE\/UDP, bepaalt via de MPLS-label de interface en verzendt het pure IP-pakket naar zijn TAP-interface, die verbonden is met eth0 van de WM.<\/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=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" 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 stelt een BGP-buurt op met de SDN-controller, van wie hij alle route-informatie over klanten ontvangt: achter welk IP-adres (vRouter) elke klant zich bevindt en met welke MPLS-label hij wordt ge\u00efdentificeerd.<\/p>\n<p>Evenzo informeert hij zelf de SDN-controller over de standaardroute met het label van deze klant, waarbij hij zichzelf als nexthop opgeeft. En vervolgens komt deze standaardroute aan bij de vRouters.<\/p>\n<p>Op VNGW vindt meestal route-aggregatie of NAT-translatie plaats.<\/p>\n<p>In de andere richting geeft hij in de sessie met de borders of Route Reflectors precies deze geaggregeerde route door. En van hen ontvangt hij de standaardroute of Full-View, of iets anders.<\/p>\n<p>In termen van encapsulatie en verkeeruitwisseling verschilt VNGW niet van vRouter. <br \/>\nAls we het gebied iets uitbreiden, kunnen we naast VNGW en vRouters ook andere netwerkapparaten toevoegen, zoals firewalls, schoonmaak- of verrijkingsboerderijen, IPS, en zo verder.<\/p>\n<p>En door VRF's sequentaal te cre\u00ebren en routes correct aan te kondigen, kun je het verkeer doen cirkelen zoals jij wilt, wat 'Service Chaining' wordt genoemd.<\/p>\n<p>Dus hier fungeert de SDN-controller ook als Route-Reflector tussen VNGW, vRouters en andere netwerkapparaten.<\/p>\n<p>Maar in feite geeft de controller ook informatie over ACL en PBR (Policy Based Routing) door, waardoor individuele verkeersstromen niet gaan zoals de route het voorschrijft.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/1\/outside-cp.png\"><img decoding=\"async\" alt=\"\ud83e\udd47Automatisering voor de allerkleinsten. Deel nul. Planning | ProHoster\" src=\"\/wp-content\/uploads\/2019\/07\/dbba5a93d64edf56dc9c2b82311c5a11.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<h1>FAQ<\/h1>\n<p><b>Waarom maak je voortdurend de opmerking GRE\/UDP?<\/b><\/p>\n<p>Nou, eigenlijk is dit, laten we zeggen, specifiek voor Tungsten Fabric \u2014 je kunt het helemaal negeren.<\/p>\n<p>Maar als we het hebben over de TF, ondersteunde het, terwijl het nog OpenContrail was, beide encapsulaties: MPLS in GRE en MPLS in UDP. <\/p>\n<p>UDP heeft het voordeel dat het in de Source Port in zijn header heel eenvoudig een hashfunctie van de oorspronkelijke IP+Proto+Port kan coderen, wat load balancing mogelijk maakt. <\/p>\n<p>In het geval van GRE zijn er helaas alleen de externe IP- en GRE-headers, die hetzelfde zijn voor alle ingekapselde verkeersstromen, en is load balancing niet mogelijk \u2014 weinig mensen kunnen zo diep in het pakket kijken.<\/p>\n<p>Tot een tijdje geleden konden routers, als ze in staat waren tot dynamische tunnels, dat alleen via MPLSoGRE, en pas recentelijk leerden ze MPLSoUDP. Daarom moeten we altijd een kanttekening maken over de mogelijkheid van twee verschillende encapsulaties.<\/p>\n<p>Ter rechtvaardigheid moet worden opgemerkt dat TF ook L2-connectiviteit ondersteunt via VXLAN.<\/p>\n<p>\n<b>Je beloofde parallellen te trekken met OpenFlow.<\/b><br \/>\nZe vragen er ook echt om. De vSwitch in hetzelfde OpenStack doet eigenlijk vergelijkbare dingen met VXLAN, dat trouwens ook een UDP-header heeft.<\/p>\n<p>In de Data Plane werken ze ongeveer hetzelfde, maar de Control Plane verschilt aanzienlijk. Tungsten Fabric gebruikt XMPP voor het verzenden van route-informatie naar de vRouter, terwijl OpenStack Openflow gebruikt.<\/p>\n<p>\n<b>Kun je iets meer vertellen over vRouter?<\/b><br \/>\nHet is onderverdeeld in twee delen: vRouter Agent en vRouter Forwarder.<\/p>\n<p>De eerste draait in de User Space van het hostbesturingssysteem en communiceert met de SDN-controller, waarbij informatie over routes, VRF en ACL word uitgewisseld.<\/p>\n<p>De tweede implementeert de Data Plane - meestal in Kernel Space, maar kan ook draaien op SmartNIC's - netwerkk kaarten met een CPU en een aparte programmeerbare switch-chip, wat de belasting van de CPU van de hostmachine vermindert en het netwerk sneller en voorspelbaarder maakt. <\/p>\n<p>Er is ook een scenario mogelijk waarin de vRouter een DPDK-applicatie in User Space is. <\/p>\n<p>vRouter Agent geeft instellingen door aan vRouter Forwarder.<\/p>\n<p>\n<b>Wat is er aan de hand met het Virtuele Netwerk?<\/b><br \/>\nIk heb in het begin van het artikel gesproken over VRF, waarbij elk huurder aan zijn eigen VRF is gekoppeld. En als dit voor een oppervlakkig begrip van de werking van het overlay-netwerk voldoende was, dan zijn er bij de volgende iteratie verduidelijkingen nodig.<\/p>\n<p>Meestal in virtualisatiemechanismen wordt de entiteit Virtual Network (je kunt dit beschouwen als een eigennaam) apart ge\u00efntroduceerd van klanten\/tenants\/virtuele machines - het is een volkomen zelfstandige zaak. En dit Virtual Network kan via interfaces aan een tenant, een andere, of zelfs meerdere worden gekoppeld. Zo wordt bijvoorbeeld Service Chaining ge\u00efmplementeerd, waarbij het verkeer door bepaalde knooppunten in de juiste volgorde moet worden geleid door simpelweg de Virtual Networks in de juiste volgorde te cre\u00ebren en aan elkaar te koppelen.<\/p>\n<p>Daarom is er niet echt een directe overeenkomst tussen het Virtuele Netwerk en de huurder.<\/p>\n<h1>Conclusie<\/h1>\n<p>\nDit is een vrij oppervlakkige beschrijving van hoe een virtueel netwerk met overlay werkt vanaf een host en een SDN-controller. Maar welke virtualisatieplatform je ook vandaag de dag gebruikt, het zal op een vergelijkbare manier werken, of het nu VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric of Juniper Contrail is. Ze zullen verschillen in soorten encapsulaties en headers, protocollen voor het afleveren van informatie aan eindnetwerkapparaten, maar het principe van een programmatisch instelbaar overlay-netwerk dat bovenop een relatief eenvoudig en statisch onderliggend netwerk werkt, blijft hetzelfde.<br \/>\nJe zou kunnen zeggen dat het gebied van priv\u00e9-cloud creatie tegenwoordig SDN op basis van overlay-netwerken heeft overwonnen. Dit betekent echter niet dat OpenFlow geen plaats heeft in de moderne wereld - het wordt gebruikt in OpenStack en evenzeer in VMWare NSX, en voor zover ik weet maakt Google gebruik van OpenFlow voor het instellen van het onderliggende netwerk.<\/p>\n<p>Hieronder heb ik links gegeven naar meer gedetailleerde materialen als je het onderwerp dieper wilt bestuderen. <\/p>\n<p>En wat is er met ons Underlay? <\/p>\n<p>In het algemeen eigenlijk niets. Het is het hele tijd hetzelfde gebleven. Alles wat het moet doen in het geval van overlay met de host - is routes en ARP's bijwerken naarmate vRouter\/VNGW verschijnt en verdwijnt, en pakketten tussen hen heen en weer sturen.<\/p>\n<p>Laten we een lijst met vereisten voor het Underlay-netwerk opstellen.<\/p>\n<ol>\n<li>Moet in staat zijn tot een bepaald routeringsprotocol, in onze situatie - BGP.<\/li>\n<li>Moet een hoge bandbreedte hebben, bij voorkeur zonder herondertekening, zodat er geen pakketten verloren gaan door overbelasting.<\/li>\n<li>Ondersteuning voor ECMP is een essentieel onderdeel van de fabriek.<\/li>\n<li>Moet QoS kunnen bieden, inclusief complexe functies zoals ECN.<\/li>\n<li>Ondersteuning voor NETCONF - een basis voor de toekomst.<\/li>\n<\/ol>\n<p>\nIk heb niet veel tijd gewijd aan de werking van het Underlay-netwerk hier. Dit komt omdat ik me in de vervolgserie juist daarop ga concentreren, terwijl we het Overlay slechts terloops zullen aansteken.<\/p>\n<p>Het is duidelijk dat ik ons allemaal sterk beperk door als voorbeeld een datacenter netwerk te gebruiken dat is gebouwd op een Clos-fabriek met pure IP-routing en een overlay van een host.<\/p>\n<p>Toch ben ik ervan overtuigd dat elke netwerk met een ontwerp kan worden beschreven in formele termen en geautomatiseerd. Mijn doel hier is gewoon om de benaderingen van automatisering te begrijpen, niet om iedereen in de war te brengen door de taak in het algemeen aan te pakken.<\/p>\n<p>Binnen het ADSM plannen Roman Gorgh en ik om een aparte uitgave te publiceren over de virtualisatie van computermiddelen en de interactie ervan met netwerkvirtualisatie. Blijf op de hoogte.<\/p>\n<p><\/p>\n<h1>Nuttige links<\/h1>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tungstenfabric.github.io\/website\/\">Tungsten Fabric Architectuur<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/Kr6WIYPts8I?t=3157\">about:cloud<\/a><\/noindex>. 6 uur over Yandex.Cloud, waarin ook het virtuele netwerk op TF wordt besproken.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.openvswitch.org\/en\/latest\/intro\/what-is-ovs\/\">Wat is Open vSwitch?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/344326\/\">Inleiding tot 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): Een kader voor het overlayen van gevirtualiseerde laag 2-netwerken over laag 3-netwerken.<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 aanpak voor VXLAN EVPN Fabric<\/a><\/noindex>. Hier wordt het hele datacenter netwerk besproken, inclusief Underlay, Overlay, benaderingen voor multi-homing en beheer.<\/li>\n<\/ul>\n<p><\/p>\n<h5>Bedankt<\/h5>\n<p><\/p>\n<ul>\n<li><noindex>Roman Gorg\u00e9<\/noindex> \u2014 de voormalige host van de podcast linkmeup, en nu een expert op het gebied van cloudplatforms. Voor de opmerkingen en correcties. We kijken ook uit naar zijn diepgaandere artikel over virtualisatie in de nabije toekomst.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.alexander-shalimov.com\">Alexander Shalimov<\/a><\/noindex> \u2014 mijn collega en expert op het gebied van het ontwikkelen van virtuele netwerken. Voor de opmerkingen en correcties.<\/li>\n<li><noindex>Valentin Sinitsyn<\/noindex> \u2014 mijn collega en expert op het gebied van Tungsten Fabric. Voor de opmerkingen en correcties.<\/li>\n<li><noindex>Artyom Chernobay<\/noindex> \u2014 illustrator van linkmeup. Voor de KDPV.<\/li>\n<li>Alexander Limonov. Voor de meme 'automato'.<\/li>\n<\/ul>\n<p>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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 Voor De Kleinsten. Deel \u00e9\u00e9n (die na de nulde). Netwerkvirtualisatie | ProHoster","description":"In de vorige aflevering beschreef ik het kader voor netwerkautomatisering.","canonical_url":"https:\/\/prohoster.info\/nl\/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":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/35973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=35973"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/35973\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/26892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=35973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=35973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=35973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}