В prior exitus Descripsi in compage retis automation. Secundum quosdam, etiam hic primus accessus ad quaestionem iam nonnullas quaestiones digessit. Et hoc me beatissimum facit, quod propositum nostrum in cyclo Ansible cum Pythone scriptis non obtegere, sed systema construere.

Eadem compago ponit ordinem quo in quaestione tractabimus.
Retis virtualizationis, cui haec quaestio dedicata est, non apprime convenit in thema ADSM, ubi automationem analysi.

Sed ex alio angulo inspiciamus.

Multa officia eadem retis diu utebantur. In casu operantis telecomes, hoc est 2G, 3G, LTE, ancha et B2B, exempli gratia. In casu DC: connectivity pro diversis clientibus, interretialibus, clausurae repositionis, obiecti reposita.

Et omnia officia solitaria ab invicem requirunt. Ita apparuit retiacula operies.

et omnia officia manualia configurare nolunt homini exspectare. Hoc modo orchestratores et SDN apparuerunt.

Primus accessus ad systematicam automationem retis, vel potius eius partem, multis in locis diu capta est et effecta: VMWare, OpenStack, Google Computo Cloud, AWS, Facebook.

Id est quod hodie agimus.

contentus

• causis
• terminology
• Underlay - network corporis
• Deaurabis - virtualis network
  • Deaurabis cum ToR
  • Deaurabis ab host
  • Usura Wolframium Fabricae ad exemplum
    • Communicationis intra unius corporis machina
    • Communicatio inter VMs posita in diversis machinis corporis
    • Exit ad extra mundum

• FAQ
• conclusio,
• Nexus utilis

causis

Et quoniam de hoc loquimur, requisita memorare virtualis retis est. Re vera, hic processus hesterno die non incepit.

Probabiliter audisti plus semel quam reticulum semper inertissimam cuiuslibet systematis partem fuisse. Et hoc est verum in omni sensu. Retis fundamentum est in quo omnia nititur, et mutationibus satis difficile est - officia non tolerant, cum retis est deorsum. Saepe, una nodo commendans magnam partem applicationum et multorum clientium incursum deponere potest. Hoc partim est cur turma network retis nulla mutatione resistat - quia nunc quodammodo operatur (non possumus scire quomodo) , sed hic debes aliquid novi configurare , et nescitur quomodo retis afficiat.

Ne expectes networkers inserendi VLANs nec operas in singulis nodi retis subcriptio, homines accesserunt cum idea utendi obducat retiacula obduces - quarum magna varietas exstant: GRE, IPinIP, MPLS; MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.

Eorum appellatio in duobus simplicibus consistit;

• Solus finis nodi configuratur: nodi transitus tangi non indigent. Hoc signanter processum accelerat, et interdum permittit ut retiaculum infrastructurae department funditus excludere a processu novorum officiorum introducendi.
• Onus in medio capitis - nodi transitus profunde reconditum est, neque opus est ut quid de eo scias, de contionandis in exercitibus, vel de viae ornatum ornatum. Hoc significat quod minus informationes in tabulis condere debes, quod simpliciori / viliori artificio utens significat.

In hac re non plane plena flexa, non dispono omnes technologias possibilis resolvere, sed potius compagem operationis retis obductis in DCs describere.

Tota series describet centrum notitiarum constans ordinum eculeorum numerorum in quibus idem servo instrumento inauguratus est.

Hoc apparatu virtualis machinis/ vasis/servilibus decurrit qui operas efficiendi.

terminology

In loop server Programma nominabo, quod servitori latus communicationis clientis inducit.

Machinae physicae in tormentis servientes dicuntur non volumus.

Apparatus corporis — x86 computatorium in eculeo inauguratus est. Maxime frequens usus est terminus host. Id est quod feres "машина"aut host.

Hypervisor - Applicatio cursus in machinam physicam aemulantem facultates physicas in quas Machinae Virtuales currunt. Interdum in litteris et Interreti vox "hypervisor" pro synonymo "exercitus" adhibetur.

Apparatus lorem ipsum - systema operativum currit super machina physica super hypervisoris. Nobis in hoc cyclo non refert vere utrum actu virtualis machina an continens tantum. Vocemus eam "Вм«

Tenens lata est notio quam in hoc articulo definiam ut separatum servitium vel clientem separatum.

Multi-tenancy seu multitenancia - usus eiusdem applicationis a diversis clientibus/officiis. Eodem tempore solitudo clientium ab invicem fit per applicationes architecturae, et non per instantiam separatim currentium.

Tor - Top of Rack switch - virga in eculeo inauguratus, cui omnes machinæ physicae connectuntur.

Praeter topologiam ToR, provisores varii finem Row (EoR) seu Medio Row exercent (quamvis haec raritas obtrectata est et abbreviationem MoR non vidi).

Substratum network vel retis substratae vel substratae infrastructurae retis physicae est: virgas, iter, retinacula.

Ipsasque network vel retis obducere vel obducere - virtualis retis cuniculorum in vertice corporis unius.

L3 fabricae vel IP fabricae - Miram humani generis inventionem, quae te permittit ut STP iteratio ac discendi triduum ad colloquia vitandum sit. Conceptus in quo tota retis usque ad gradum accessum est solum L3, sine VLANs et, proinde, immensae ditiones patentes extensae. Inspiciemus ubi nomen "officinae" ex altera parte proveniat.

SDN - Software Definition Network. Vix opus est prooemio. Accessus ad ipsum dolor sit amet, ubi mutationes retis fiunt non ab homine, sed per rationem. Solet movere Imperium Planum ultra finem retis machinis ad moderatorem.

NFV - Function Virtualisation Network - virtualization of network machinis, suggerentes aliquas functiones retis posse currere in specie machinis virtualis vel vasis ad accelerandum novorum officiorum exsequendam, servitii vincendi et scalabilitatis simplicioris ordinandi.

VNF - Network Function lorem ipsum. Imprimis virtualis fabrica: iter, switch, firewall, NAT, IPS/IDS, etc.

Nunc de industria simpliciorem descriptionem ad certas exsecutiones sum, ne lectorem nimis confundam. Pro attentiore lectione, eum ad sectionem refero References. Praeterea Roma Gorge, qui hunc articulum de indiligentiis reprehendit, promittit se quaestionem singularem de technologia servo ac retiacula virtualizationis scribere, profundius et attentius perscrutari.

Pleraque retia hodie in duas partes clare destructae sunt;

underlay - corporis network cum stabili configuratione.
Ipsas — Abstractio super substratum pro colonis desolandis.

Hoc verum est tum pro casu DC (quod in hoc articulo resolvere volumus) et pro ISP (quod resolvere non volumus, quia iam fuit. SDSM). Retiaculis inceptis, sane, res aliqua est diversa.

Picture cum focus in retiacula:

underlay

Substratum retis corporis est: virgae ferrariae ac rudentes. machinae in subterraneo machinis corporis nesciunt pervenire.

Vexillum protocolla et technologiae nititur. Non minimum quod ferramenta machinae ad hunc diem operantur in programmate proprietario, quod non sinit vel assulam programmandi vel sua protocolla exsequenda, ideoque congruentia cum aliis venditoribus et standardisationi necessaria sunt.

Sed similis Google potest praestare suas virgas evolvere et protocolla generaliter recepta relinquere. Sed LAN_DC non est Google.

Substratum relative raro mutat quia eius officium est fundamentalis IP connexio inter machinas physicas. Substratum nihil scit de servitiis, clientibus, vel colonis super ipsum currentibus, solum sarcinam ab uno machinae in aliam liberare oportet.
Substratum esse potest sic:

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

Substratum retis figuratur in via classica: CLI/GUI/NETCONF.

Manuale, scriptorum, proprietatis utilitas.

Articulus sequens in serie infra fusius incumbet.

Ipsas

Deauratio est virtualis retis cuniculorum in summitate Underlay extenta, VMs unius clientis inter se communicare permittit, dum ab aliis clientibus segregationem praebet.

Cliens notitia in aliquo cuniculo caput capitis encapsulatur ad transmissionem per retia publica.

Ita VMs unius clientis (unius servitii) inter se per Overlay communicare potest, quin etiam sciat qua via fasciculus actu capit.

Operire posse, exempli causa, sicut supra dixi;

• GRE cuniculum
• VXLAN
• EVPN
• L3VPN
• GENEVAE

Network deauratium typice figuratur et conservatur per moderatorem centralem. Ab ea, configuratione, Planum Imperium et Planum Data, traduntur machinis itineris illius et mercaturae clientis encapsulatae. Paululum inferius Intueamur hoc cum exemplis.

SDN hoc in purissima forma est.

Duae sunt rationes fundamentales diversae ad ordinandum retiacula ipsa deauratae;

1. Deaurabis cum ToR
2. Deaurabis ab host

Deaurabis cum ToR

Obducere incipere potest in accessu switch (ToR) stans in eculeo, ut fit, exempli gratia, in casu fabricae VXLAN.

Hoc est tempus probatum mechanismum in retiacula ISP et omnem apparatum retis venditores adiuvant.

Attamen hoc in casu, commutatio ToR varia officia, respective, et administrator retiacula separare poterit, aliquatenus cooperari cum administratoribus virtualibus et mutationibus (licet automatice) ad machinarum conformationem. .

Lectorem hic referam ad articulum de VxLAN die Habré vetus amicus noster @bormoglotx.
In hoc presentations cum ENOG accedit ad fabricam DC retis cum fabricae EVPN VXLAN singillatim descriptae.

Et pro immersione re pleniore, librum Tsiska legere potes Modern, Open, et Scalable Fabrica: VXLAN EVPN.

Adverto VXLAN solum encapsulationis modum ac terminationem cuniculorum non in ToR, sed in exercitu fieri posse, ut in OpenStack casu accidit, exempli gratia.

Nihilominus fabrica VXLAN, ubi operire incipit apud ToR, una ex instrumentis retis obductis statutis est.

Deaurabis ab host

Alia accessio est incipere cuniculis et in fine exercituum terminare.
Hoc in casu, reticulum (underlay) quam maxime simplex et static manet.
Et ipsa hostia omnia necessaria encapsulationis facit.

Hoc utique requiret cursus specialem applicationem exercituum, sed pretium est.

Uno modo, clientem machinae Linux in facilius vel, dicamus, etiam possibile est, cum in commutatione maxime probabile erit solutiones proprietariae convertendi SDN, quae ideam multi-vendoris necat.

Secundo, in hoc casu ToR switch quam maxime simplex relinqui potest, tum ex parte Plani Imperii et Plani Data. Re quidem vera, tunc cum SDN moderatoris communicare non oportet, et retiacula/ARPs omnium clientium conexorum condere etiam non indiget - satis est cognoscere IP oratio machinae physicae, quae mutabilitatem valde simplificat/ mensas excitandas.

In serie ADSM, accessum laminis eligo ab hospite - tunc tantum loqui de eo et ad officinam VXLAN non revertemur.

Exempla facillima intueri. Et ut de re probata accipiemus suggestum OpenSource SDN OpenContrail, nunc notum Wolframium Fabric.

In fine articuli nonnullas cogitationes dabo de analogia cum OpenFlow et OpenvSwitch.

Usura Wolframium Fabricae ad exemplum

Quisque corporalis apparatus est vRouter - virtuale iter quod scit de reticulis sibi connexis et quae clientes pertinent ad - essentialiter a PE iter. Pro unoquoque cliente, mensam solitariam fuso conservat (lego VRF). Et vRouter actu deaurat cuniculis.

Plura de vRouter in fine articuli.

Quaelibet VM in hypervisore sita coniungitur cum vRouter machinae huius via SPISSAMENTUM interface.

ICTUS - Terminal Access Point - virtualis interface in Linux nucleum quod permittit network commercium.

Si plures retia post vRouter sunt, virtualis interfacies pro singulis eorum creatur, cui IP oratio assignatur - erit defalta portae electronicae.
Omnes retia unius clientis ponuntur in uno VRF extensio (one table), different ones — in different ones.
Disclamare hic faciam quod non omnia tam simplicia sint, et lectorem curiosum in fine articuli mittam..

Ut vRouters inter se communicare possint, ac proinde VMs post se collocati, notitias per routas commutant. SDN controller.

Ut in extra mundum, punctum exit e matrice - virtualis retis porta VNGW - Rectum Network GateWay (terminus meus).

Nunc inspiciamus exempla communicationum - et claritas erit.

Communicationis intra unius corporis machina

VM0 fasciculum mittere vult ad VM2. Demus nunc hunc unicum esse clientem VM.

Data Plane

1. VM-0 defaltam itineris ad eth0 interfaciem habet. In sarcina ibi emissa est.
   Hoc interface eth0 actu virtualiter coniungitur cum itineris virtuali vRouter per tap0 interfaciei TAP.
2. vRouter analyses quae interfaciunt fasciculum advenit, hoc est, cuius client (VRF) convenit, et sistit inscriptionem recipientis cum tabula fusa huius clientis.
3. Cognito recipiens in eadem machina esse in alio portu, vRouter simpliciter emittit fasciculum ad eam sine ullo addito capite - hoc casu, vRouter iam habet ARP record.

In hoc casu, fasciculus retis corporis non intrat - intra vRouter fusus est.

Imperium Planum

Cum machina virtualis incipit, hypervisor hoc dicit;

• IP oratio sua.
• Iter per default vRouter inscriptionis IP in hac retis est.

Hypervisor ad vRouter per specialem API refert;

• Quod virtualis interface creare debes.
• Quod genus virtualis retis opus est facere?
• Quas VRF(VN) ligatura m.
• Stabilis ARP viscus huius VM - quae interfacies est post eius IP inscriptionem et MAC electronicam associatur.

Iterum, processus actualis commercium simplicior est propter intellectum conceptum.

Sic vRouter videt omnes VMs unius clientis in machina data sicut retiacula directe connexa et inter eas se iter facere potest.

Sed VM0 et VM1 ad diversos clientes pertinent et proinde in diversis tabulis vRouter.

Utrum directe inter se communicare possint ex consilio vRouter occasus et retis.
Exempli gratia, si ambo clientes VMs inscriptionibus publicis utantur, vel NAT in ipso vRouter occurrat, tunc dirigere ad vRouter fieri potest.

In opposito situ electronica spatia transire potest - debes ire per servo NAT electronicam orationem publicam - hoc simile est accessu reticulorum externorum, de quibus infra agetur.

Communicatio inter VMs posita in diversis machinis corporis

Data Plane

1. Initium prorsus simile est: VM-0 fasciculum cum destinatione VM-7 (172.17.3.2) mittit.
2. vRouter recipit et hoc tempus videt destinationem in alia machina esse et per Tunnel0 adiri.
3. Primum, pendet MPLS label identificatio interfaciem remotam, ita ut in parte adversa vRouter determinare possit ubi hunc fasciculum ponere sine specula addito.

   

4. Tunnel0 fontem habet 10.0.0.2, destination: 10.0.1.2.
   vRouter addit GRE (vel UDP) capita et novum IP ad fasciculum originalem.
5. Mensa vRouter fusura defaltam habet itineris per electronicam ToR1 10.0.0.1. Id ubi mittit.

   
   

6. ToR1, membrum retis Underlay, scit (exempli gratia per OSPF) quomodo ad 10.0.1.2 perveniatur et fasciculum per viam mittit. Nota quod ECMP hic datur. Duo sunt sequentia in illustratione, et stamina nulla in illis digerunt. In officina reali, verisimilius erunt 4 nexthops.

   Eodem tempore, quid sub externo IP titulo non indiget. Hoc est, revera, sub IP fartum esse potest ex IPv6 super MPLS super Aer per MPLS super GRE per supra Graecam.

7. Itaque, parte accepta, vRouter GRE removet et, utens MPLS tag, intelligit, quae interfacies huic fasciculo mitti debet, exuit et in pristinam formam recipienti emittit.

Imperium Planum

Cum currus incipias, idem fit quod supra.

Et plus his;

• Pro quolibet cliente, vRouter an MPLS tag collocat. Hic est titulus muneris L3VPN, quo clientes in eadem machina corporis separabuntur.
  

  Revera, MPLS tag semper sine condicione ab vRouter collocatur - tamen praecognitum non est machinam cum aliis machinis post eandem vRouter tantum penitus secare et hoc verisimilius est ne verum quidem.

• vRouter nexum cum SDN moderatoris utens protocollo BGP (vel ei simile - in casu TF, hoc est XMPP 0_o).
• Per hanc sessionem, vRouter vias refert ad retiacula coniuncta cum SDN moderatoris:
  • Network inscriptio
  • Encapsulation methodus (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS clientis tag
  • Tua IP oratio ut nexthop

• Gubernator SDN tales vias accipit ab omnibus vRouters connexis et eas aliis reddit. Hoc est, ut Reflector iter agit.

Idem fit ex opposito.

Deaurabis mutare potest saltem perparvis. Hoc fere fit in nubibus publicis, ubi clientes regulariter incipiunt et claudunt machinas suas virtuales.

Moderator centralis omnium multiplicitatem conservandi schematismi et vigilantiam in vRouter mensas commutatione/routingentes curat.

Dure loquendo moderatoris cum omnibus vRouters per BGP (vel protocollo simile) communicat et simpliciter notitias fundere tradit. BGP, exempli gratia, iam habet Oratio-Familia ad modum encapsulationis deferendum MPLS-in-GRE aut MPLS-in-UDP.

Eodem tempore, conformatio network Underlay nullo modo mutat, quae obiter multo difficilior est automate, et facilius motu imperito frangitur.

Exit ad extra mundum

Alicubi simulatio finire debet, et rectum mundum in verum exire debes. Tincidunt eget porta et.

Duo sunt aditus;

1. A hardware iter is installed.
2. Instruitur instrumentum quod munia itineris conficit (sic, SDN sequentes, etiam VNF occurrerunt). Vocemus portam virtualem.

Commodum secundi accessionis est vilis scalabilitatis horizontalis - potestas non sufficit - aliam machinam virtualem cum porta egimus. In quavis corporis machina, sine quaerere gratis eculei, unitates, potentiae output, ipsum ferramentum emere, deportare, instituere, flectere, configurare, ac deinde etiam vitia in ea membra mutare.

Incommoda portae virtualis sunt quod unitas itineris physici adhuc ordines magnitudinis potentior est quam multi-core virtualis apparatus, et eius institutio, ad suum basium ferramentarium formandam, multo stabilius operatur (no). Etiam difficile est negare ferramenta et software complexa simpliciter opera, solum configurationem requirunt, cum portae virtualis deducendae et conservandae munus est fortium fabrum.

Uno pede, porta in Ipsum retis virtualis inspicit, sicut Machina virtualis regularis, et cum omnibus aliis VMs potest correspondere. Eodem tempore reticulas omnium clientium terminare potest ac proinde inter eos fundere fugam.

Cum altero pede, porta spinam retis inspicit et scit eundo in lorem.

Data Plane

Hoc est, processus similis est;

1. VM-0, eidem vRouter defaltam mittit fasciculum cum destinatione in extra (185.147.83.177) ad interfaciem eth0.
2. vRouter hanc fasciculum accipit et locum desideratum in tabula fuso suspicit - itineris defectus invenit per VNGW1 portae per cuniculum 1 .
   Etiam videt hoc esse cuniculum GRE cum SIP 10.0.0.2 et DIP 10.0.255.2, et praeterea necesse est ut MPLS titulus huius clientis, quem VNGW1 expectat, adiungat.
3. vRouter sarcinam initialem cum MPLS, GRE et novis IP capitis fasciculis infert et ad ToR1 10.0.0.1 per defaltam mittit.
4. Ratio retis fasciculum ad portam VNGW1 tradit.
5. VNGW1 porta GRE et MPLS caput capitis obliquatio aufert, inscriptionem destinatum videt, mensam fuso consulit et intellegit eam ad Internet dirigi - hoc est, per plenam Visum seu Default. Si opus est, praestat NAT translationem.
6. Recta IP network ex VNGW ad terminum esse potest, quod est inconveniens.
   Sit retis classicus MPLS (IGP+LDP/RSVP TE), fabricae dorsum cum BGP LU vel GRE cuniculum ab VNGW usque ad terminum retis IP.
   Sit ut licet, VNGW1 peragit necessarias encapsationes et fasciculum initialem versus terminum emittit.

Negotiatio in oppositum vadit per eosdem gradus in opposito ordine.

1. Terminus deponat fasciculum VNGW1
2. Exponit eum, inscriptionis recipientis spectat et videt se per cuniculum pervium (MPLSoGRE vel MPLSoUDP).
3. Ideoque titulum MPLS, caput GRE/UDP et IP novum adiungit et ad suum ToR3 10.0.255.1 mittit.
   Cuniculum destinationis inscriptio est IP oratio vRouter a tergo in quo scopo VM sita est - 10.0.0.2.
4. Ratio network fasciculum tradit vRouter desideratum.
5. Scopum vRouter legit GRE/UDP, interfaciem designat MPLS label utens et nudum IP fasciculum mittit ad interfaciem TAP cum eth0 VM.

Imperium Planum

VNGW1 vicinitatem BGP cum SDN moderatore constituit, unde omnes informationes de clientibus fugandas accipit: quae IP oratio (vRouter) est post quem clientem, et quem MPLS label notatur.

Similiter ipse SDN moderatorem itineris defaltam cum huius clientis pittacium informat, se tamquam proximum hop indicans. Et tunc hoc defalta peruenit ad vRouters.

In VNGW, iter aggregationis vel translationis NAT plerumque occurrit.

Et in alteram partem emittit hoc iter aggregatum ad sessionem cum limitibus seu Reflectoribus. Et ab eis recipit iter defaltam vel plenam View, vel aliquid aliud.

In terminis encapsulationis et permutationis commercii, VNGW ab vRouter non differt.
Si scopum parvum expandis, alias machinas retis addere potes ad VNGWs et vRouters, ut ignium, negotiationis purgatio vel locupletandi praedia, IPS, et sic porro.

Et ope sequentiae creationis VRFs et viarum recta denuntiatio, mercaturam facere potes viam quam vis discludere, quae Service Chaining appellatur.

Hoc est, etiam hic moderator SDN agit ut Reflector itineris inter VNGWs, vRouters et aliae machinae retis.

Sed re vera, moderator informationes de ACL et PBR remittit (Policy Based Routing) causando singula negotiatio fluit ut aliter quam iter facere iubet.

FAQ

Cur observas GRE/UDP notare?

Bene, in genere, haec specifica Tungsten Fabricae dici possunt - eam rationem omnino habere non debes.

Sed si sumatur, ipsa TF, adhuc OpenContrail, utraque encapsulationum sustentatur: MPLS in GRE et MPLS in UDP.

UDP bonum est quod in Ipso Portu facillime est munus detrahere ab originali IP+Proto+Port in capite eius enodare, quod te conpensationem facere permittet.

In GRE, proh dolor, tantum externa IP et GRE capitis, quae eadem sunt pro omnibus mercationibus encapsulatis et nulla disputatio librationis - pauci homines tam profunde intra fasciculum spectare possunt.

Usque ad aliquod tempus itinerarii, si cuniculis dynamicis uti sciverunt, hoc solum in MPLSoGRE fecerunt, et modo recentissime MPLSoUDP didicerunt. Ideo semper notandum est de possibilitate duarum encapsulationum diversarum.

In aequitate notabile est quod TF plene sustinet L2 connectivity utens VXLAN.

Parallela trahere cum OpenFlow pollicitus es.
Vere, petendo. vSwitch in eodem OpenStack simillima facit, usus VXLAN, quae obiter etiam UDP header habet.

In Data Plano fere idem operantur, Imperium Planum insigniter differt. Tungsten Fabrica utitur XMPP ut informationes ad vRouter tradendas adhibeat, dum OpenStack Openflow decurrit.

De vRouter paulo plura mihi dicere potes?
Dividitur in duas partes: vRouter Agens et vRouter Forwarder.

Primus in spatium usoris exercitus OS decurrit et cum SDN moderatoris communicat, informationes permutandi de itineribus, VRFs et ACLs.

Secunda instrumenta Data Plani - plerumque in spatio Kernel, sed etiam incurrere in SmartNICs - retis chartis cum CPU et separatim programmabili commutatione chip, quod sinit te onus e machinae CPU submovere, et retiaculum fac citius et plus praedictio.

Alia possibilis missio est illa vRouter applicationem DPDK in spatio usoris.

vRouter agens mittit occasus vRouter Forwarder.

What is a Virtual Network?
In principio articuli de VRF monui quod quilibet tenens ligatur suo VRF. Et si hoc sufficiat ad intellegentiam superficialem retis operimenti, tunc in altera iteratione opus est declarationes facere.

De more, in mechanicis virtualizationis, Entas Virtualis Network (hoc proprium nomen considerare potes) separatim a clientibus/tenentibus/machinis virtualibus introducitur — res omnino independentes. Atque haec Virtualis Network iam per interfaces uni tenenti, alteri, duobus, vel alicubi coniungi potest. Sic, exempli gratia, Vinculum servitii impletur cum negotiatio per certos nodos in serie requiritur, simpliciter creando et connectens Networks Virtuales in recta serie.

Ergo, ut talis, nulla est recta correspondentia inter Network Virtualem et tenentem.

conclusio,

Haec superficialis descriptio operationis virtualis retis cum obduces ab exercitu et moderatore SDN. Quacumque autem virtualizationis suggestu hodie libet, simili modo operabitur, VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric vel Juniperum Contrail. Differunt in generibus encapsulationum et capitis, protocolla tradendi informationes ad finem retis machinis, sed principium retis software-configurabilis operiens in summitate reticuli relativi simplicis et statici substrata manebit.
Dicere possumus hodie SDN subnixum retis obductis obtinuisse campum creandi nubem privatam. Nihilominus hoc non significat Openflow in mundo hodierno locum non habere - in OpenStacke et in eodem VMWare NSX ponitur, quantum scio, Google hoc utitur ad subterranea retia erigendum.

Infra nexus materiarum accuratiorum mihi comparavi si quaestionem altius investigare vis.

Et quid de nostro underlayo?

Sed generaliter nihil. Totam viam non mutavit. Omnes in casu obduci ab hoste opus faciunt itinera renovatio et ARPs sicut vRouter/VNGW apparent et evanescunt et inter eas facis.

Praestare indices requisitorum ad network substratum.

1. Protocollo quodam fuso uti poterit in situ nostro - BGP.
2. Latam bandam habent, praesertim sine subscriptione, ut ob fasciculos non pereant onera.
3. ECMP sustinens pars integralis est fabricae.
4. QoS praebere poterit, etiam rebus captiosis sicut ECN.
5. NETCONF favens fundamentum est in futurum.

Ipsum retis underlay temporis opusculum hic devovi. Hoc est quia postea in serie quam intendunt, et in obiter deaurabimus tantum attingemus.

Patet, me omnes nos graviter cohibere utendo exemplo retis DC constructum in officina Cloz cum puris IP fusis et operimento ab hospite.

Confido tamen nullam retis, quae consilium habet, formalibus verbis describi et automated. Propositum est hic me cognoscere accessiones ad automationis, nec omnes confundere problema solvendo in forma generali.

Cum ADSM partem, Gorge Roman et I. quaestionem separatam de virtualizatione computandi potestas et commercium cum retis virtualizatione evulgare cogito. Maneo amicus.

Nexus utilis

• Tungsten Fabricae Archivitectura.
• de: nubem. 6 horas circa Yandex.Cloud, quae etiam in TF retiacula virtualis tegit.
• What Is Open vSwitch?
• Introductio ad VxLAN.
• RFC 7348. Area virtuale extensible Local Area Network (VXLAN): Artus obductio Virtualis iacuit 2 Networks super Stratum 3 Networks.
  
• Scalway accessus ad VXLAN EVPN Fabric. Loquitur de tota DC retis, inclusis Underlay, Overlay, accedit ad multi homing et administratione.

Gratias tibi

• Romanus Gorga - hospes pristinus de linkmeup podcast et nunc perito in campo nubes pulpita. Ad commentarios et emendationes. Bene exspectamus articulum profundiorem de virtualizatione in proximo futuro.
• Alexander Shalimov — collega et perito in campo virtualis retis explicatio. Ad commentarios et emendationes.
• Valentinus Sinitsyn — Collega et doctissimus Wolframmus in agro Fabric. Ad commentarios et emendationes.
• Artyom Chernobay — linkmeup illustrator. Nam KDPV.
• Alexander Limonov. Nam "automato" quentiam.

Source: www.habr.com