Pirms pievienojat OTV, pierakstiet nepieciešamo Ethernet līgumu

Darba slodze pārceļas uz otru datu centru un sāk pārsniegt laika limitu pakalpojumā, kas no pirmā atbildēja labi. Kāds ierosina OTV, jo esošais Layer 2 VPN „neveic broadcast“. Šis secinājums parasti ir pāragrs. Pakalpojuma kategorija un konkrētais iegādātais līgums ir divi dažādi jautājumi, un laika limita pārsniegums vēl nav attiecināts ne uz vienu no tiem.

Simptoms, ar kuru sākas salīdzinājums

Pierakstiet, kas lietotnei patiešām nepieciešams, pirms salīdzināt produktus. Vietņu skaits, VLAN apjoms, adrešu mācīšanās, flooding tolerance un uzvedība atteices gadījumā raksturo prasību. „Layer 2“ un „OTV“ raksturo arhitektūras, un neviens no tiem pats par sevi nav prasība. Piecas īpašības vienā lapā pārdzīvos jebkuru piegādātāju salīdzinājumu.

Pēc tam pārbaudiet, vai pašreizējais pakalpojums jau atbilst šīm piecām īpašībām. Pakalpojumu sniedzēja pārvaldīts Layer 2 VPN var ietvert multipoint pārsūtīšanu un mācīšanos vadības plaknē, ko ātrs skats rēķinā neminēja.

Ja pašreizējais pakalpojums tām atbilst, laika limita pārsniegums ir citur: MTU problēma, maršrutēšanas asimetrija, ugunsmūra noteikums, kas atšķiras starp vietnēm. Overlay maiņa atstātu šo cēloni vietā un pievienotu migrāciju.

Ko etiķete jums nepasaka

Layer 2 VPN ir kategorija, nevis produkts. Punkts-punktam VPWS un multipoint VPLS pārsūta atšķirīgi, un kategorija ietver pakalpojumus ar mācīšanos vadības plaknē un cilpu pārvaldību, kā arī vienkāršākus. Pieņēmums, ka katrs Layer 2 VPN savieno tieši divas vietnes un pārpludina visu, ir veids, kā izveidot nepareizu salīdzinājumu. Nosaukums līgumā neko nepasaka par pārsūtīšanas tabulu aiz tā.

Jautājiet kādu pārsūtīšanas modeli īsteno esošais pakalpojums, un kāds nepieciešams lietotnei. Hub-and-spoke prasība un full-mesh prasība dod atšķirīgus projektus pat tad, ja abas tiek aprakstītas kā Layer 2.

Kur OTV velk savu robežu

OTV darbojas virs IP transporta ar MAC sasniedzamību vadības plaknē un definētām edge lomām. Vietējā spanning-tree informācija paliek vietēja, nevis tiek paplašināta kā viens nekontrolēts domēns pāri transportam. Tā ir reāla atšķirība no vienkārša tiltotā paplašinājuma, un tas ir iemesls, kāpēc cilvēki pie tā ķeras.

Robeža ir tikpat svarīga kā ieguvums. Nezināmas unicast, broadcast un multicast apstrāde ir atkarīga no platformas un tās konfigurācijas, un edge pārim jāsadarbojas ar atbalstīto multihoming mehānismu. Divas neatkarīgas ierīces, kas pārsūta vienu un to pašu VLAN, nav viens un tas pats projekts, un tās rada citu atteices režīmu.

Flooding tiek samazināts, nevis noņemts

Daļas liekā flooding nomākšana nav tas pats, kas garantija, ka neviens broadcast vai multicast kadrs nekad nešķērsos paplašinājumu. Vētra, kas sākas vienā vietnē, joprojām var patērēt transportu, un platformas funkcija, kas filtrē vienu trafika klasi, nefiltrē pārējās. No šīs atšķirības nāk lielākā daļa vilšanās ar jebkuru overlay.

Tātad jautājums nav par to, vai OTV aptur broadcast vētras. Jautājums ir, kuras trafika klases šķērso, kādos apstākļos un kas ierobežo ātrumu, kad tās šķērso.

Apstipriniet underlay, kamēr esat tur: atbalstīta piegāde, paketes izmērs, maršrutēšana un kaimiņattiecības, ko prasa izvēlētā versija. Nekas no tā nenāk bez maksas kopā ar overlay, un tunelis, kurā ietilpst 1500 baitu kadrs, automātiski nav tunelis, kurā ietilpst jūsu atzīmētie kadri.

Līgums, kas jāpieprasa rakstiski

Par kuru vien pakalpojumu jūs izvēlaties, pieprasiet tos pašus sešus atbildes: punkts-punktam vai multipoint apjoms, klienta kadra un atzīmes apstrāde, MAC mācīšanās modelis, flooding limiti, atjaunošanas uzvedība un maksimālais kadra izmērs no gala līdz galam. Divi pakalpojumi ar vienu nosaukumu var atšķirties katrā no tiem. Iegūstiet atbildes rakstiski, jo inženieris, kurš konfigurēja pakalpojumu, var nebūt tas, kurš atbild uz jautājumu.

Izvēlieties izmaiņas tikai tādai prasībai, kuru pašreizējais pakalpojums acīmredzami nevar izpildīt. Tālāka VLAN paplašināšana paplašina arī lietotnes un Ethernet atkarības kopā ar to; jauns overlay nosaukums tās nenoņem.

RFC 4664 ietvars izklāsta pakalpojumu kategorijas un to pārsūtīšanas modeļus, un tas ir vārdu krājums, kas nepieciešams pareiza jautājuma uzdošanai. Atnesiet sešas atbildes un neizdevušos testu uz vienu sanāksmi, un lēmums vairs nebūs par etiķetēm.