Antaŭ ol aldoni OTV, skribu la Ethernet-kontrakton, kiun vi bezonas
Nombro de ejoj, VLAN-amplekso, lernado, flooding kaj fiaskokonduto decidas tion. Komparu la kontrakton, kiun via L2VPN jam provizas, antaŭ ol ŝanĝi la overlay.
Laborŝarĝo transloĝiĝas al dua datena centro kaj ekas tempolimon ĉe servo, kiu bone respondis el la unua. Iu proponas OTV, ĉar la ekzistanta Layer 2 VPN “ne faras broadcast”. Tiu konkludo kutime estas tro frua. La servokategorio kaj la konkreta kontrakto, kiun vi aĉetis, estas du malsamaj demandoj, kaj la tempolimo ankoraŭ ne estas atribuita al iu el ili.
La simptomo, kiu komencas la komparadon
Skribu, kion la aplikaĵo vere bezonas antaŭ kompari produktojn. Nombro de ejoj, VLAN-amplekso, adreslernado, flooding-tolerado kaj fiaskokonduto priskribas la postulon. “Layer 2” kaj “OTV” priskribas arkitekturojn, kaj neniu el ili mem estas postulo. Kvin ecoj sur unu paĝo daŭros pli longe ol iu ajn komparado de vendistoj.
Poste kontrolu, ĉu la nuna servo jam plenumas tiujn kvin ecojn. Provizanto-administrata Layer 2 VPN povas inkluzivi multipoint-plusendadon kaj lernadon en la regplano, kiujn rapida rigardo al la fakturo ne menciis.
Se la nuna servo plenumas ilin, la tempolimo estas aliloke: problemo pri MTU, malsimetrio en enkursigo, fajroŝirma regulo kiu diferencas inter ejoj. Ŝanĝi la overlay lasus tiun kaŭzon en loko kaj aldoni migradon.
Kion la etikedo ne diras al vi
Layer 2 VPN estas kategorio, ne produkto. Punkto-al-punkto VPWS kaj multipoint VPLS plusendas malsame, kaj la kategorio inkluzivas servojn kun lernado en la regplano kaj bukla administrado kaj ankaŭ pli simplajn. Supozi ke ĉiu Layer 2 VPN konektas ekzakte du ejojn kaj inundas ĉion estas kiel oni faras la malĝustan komparadon. La nomo sur la kontrakto diras nenion pri la plusenda tabelo malantaŭ ĝi.
Demandu kiun plusendan modelon la ekzistanta servo efektivigas, kaj kiun la aplikaĵo bezonas. Postulo hub-and-spoke kaj postulo full-mesh produktas malsamajn desegnojn eĉ kiam ambaŭ estas priskribitaj kiel Layer 2.
Kie OTV desegnas sian limon
OTV funkcias sur IP-transporto kun MAC-atingebleco en la regplano kaj difinitaj edge-rojloj. Loka spanning-tree-informo restas loka anstataŭ esti etendigita kiel unu nekontrolita domajno trans la transporto. Tio estas vera diferenco de simpla ponta etendigo, kaj tial homoj turnas sin al ĝi.
La limo gravas same kiel la avantaĝo. Traktado de nekonata unicast, broadcast kaj multicast dependas de la platformo kaj ĝia agordo, kaj edge-paro devas kunlabori per la subtenata multihoming-mekanismo. Du sendependaj aparatoj plusendantaj la saman VLAN ne estas la sama desegno, kaj ĝi produktas malsaman fiaskmanieron.
Flooding estas reduktita, ne forigita
Subpremi iom da nebezona flooding ne samas garantii, ke neniu broadcast- aŭ multicast-kadro iam transiros la etendigon. Ŝtormo komenciĝanta en unu ejo ankoraŭ povas konsumi la transporton, kaj platforma trajto filtranta unu trafikklason ne filtras la aliajn. El tiu diferenco venas la plej granda parto de la seniluziigo kun iu ajn overlay.
Do la demando estas ne ĉu OTV haltigas broadcast-ŝtormojn. Ĝi estas kiuj trafikklasoj transiras, sub kiuj kondiĉoj, kaj kio limigas la rapidon kiam ili faras tion.
Konfirmu la underlay dum vi estas tie: subtenata liverado, paketa grandeco, enkursigo kaj la najbareco kiun la elektita eldono postulas. Nenio el tio venas senpage kun la overlay, kaj tunelo kiu konvenas al 1500-bajta kadro ne aŭtomate estas tunelo kiu konvenas al viaj etikeditaj kadroj.
La kontrakto, kiun peti skribe
Por kiu ajn servo vi elektos, petu la samajn ses respondojn: punkto-al-punkto aŭ multipoint-amplekso, traktado de klienta kadro kaj etikedo, MAC-lernmodelo, flooding-limoj, rekupera konduto kaj la maksimuma kadrograndeco de fino al fino. Du servoj kun la sama nomo povas diferencas en ĉiu unu el ili. Akiru la respondojn skribe, ĉar la inĝeniero, kiu agordis la servon, eble ne estas tiu, kiu respondas la demandon.
Elektu ŝanĝon nur por postulo, kiun la nuna servo pruveble ne povas plenumi. Etendi VLAN plu etendas ankaŭ la dependecojn de la aplikaĵo kaj de Ethernet kun ĝi; nova overlay-nomo ne forigas ilin.
La kadro RFC 4664 elmetas la servokategoriojn kaj iliajn plusendajn modelojn, tio estas la vortprovizo, kiun vi bezonas por meti la ĝustan demandon. Alportu la ses respondojn kaj la malsukcesan teston al la sama kunveno, kaj la decido ĉesas temi pri etikedoj.