Før du legg til OTV, skriv ned Ethernet-kontrakten du treng
Talet på nettstader, VLAN-omfang, læring, flooding og feilåtferd avgjer dette. Samanlikn kontrakten L2VPN-en din allereie leverer før du endrar overlayet.
Ei arbeidsbelastning flyttar til eit andre datasenter og byrjar å få tidsavbrot på ei teneste som svara fint frå det første. Nokon føreslår OTV, fordi den eksisterande Layer 2 VPN-en «ikkje gjer broadcast». Den konklusjonen er vanlegvis forhasta. Tenestekategorien og den konkrete kontrakten du kjøpte er to ulike spørsmål, og tidsavbrotet er enno ikkje tilskrive nokon av dei.
Symptomet som startar samanlikninga
Skriv ned kva applikasjonen faktisk treng før du samanliknar produkt. Talet på nettstader, VLAN-omfang, adresselæring, flooding-toleranse og feilåtferd skildrar kravet. «Layer 2» og «OTV» skildrar arkitekturer, og ingen av dei er eit krav i seg sjølv. Fem eigenskapar på éi side overlever kvar leverandørsamanlikning.
Sjekk deretter om den noverande tenesta allereie oppfyller dei fem eigenskapane. Ein leverandørstyrt Layer 2 VPN kan innehalde multipoint-vidaresending og læring i kontrollplanet som eit raskt blikk på fakturaen ikkje nemnde.
Viss den noverande tenesta oppfyller dei, er tidsavbrotet ein annan stad: eit MTU-problem, ein rutingsasymmetri, ein brannmurregel som er ulik mellom nettstader. Å byte overlay ville la den årsaka stå og leggje til ein migrasjon.
Kva etiketten ikkje fortel deg
Ein Layer 2 VPN er ein kategori, ikkje eit produkt. Punkt-til-punkt VPWS og multipoint VPLS vidaresender ulikt, og kategorien omfattar tenester med læring i kontrollplanet og løkkestyring så vel som enklare. Å anta at kvar Layer 2 VPN koplar nøyaktig to nettstader og flaumar alt, er måten å gjere den gale samanlikninga. Namnet på kontrakten seier ingenting om vidaresendingstabellen bak det.
Spør kva vidaresendingsmodell den eksisterande tenesta implementerer, og kva applikasjonen treng. Eit hub-and-spoke-krav og eit full-mesh-krav gir ulike design sjølv når begge blir skildra som Layer 2.
Kvar OTV dreg grensa si
OTV køyrer over ein IP-transport med MAC-tilgjenge i kontrollplanet og definerte edge-roller. Lokal spanning-tree-informasjon blir verande lokal i staden for å bli utvida som eitt ukontrollert domene over transporten. Det er ein reell skilnad frå ei enkel brua utviding, og det er grunnen til at folk grip til det.
Grensa tyder like mykje som fordelen. Handsaming av ukjend unicast, broadcast og multicast avheng av plattformen og konfigurasjonen, og eit edge-par må samarbeide gjennom den støtta multihoming-mekanismen. To uavhengige einingar som vidaresender same VLAN er ikkje same design, og dei gir ein annan feilmodus.
Flooding blir redusert, ikkje fjerna
Å undertrykkje noko unødvendig flooding er ikkje det same som å garantere at inga broadcast- eller multicast-ramme nokosinne kryssar utvidinga. Ein storm som startar på ein nettstad kan framleis ete transporten, og ein plattformfunksjon som filtrerer éin trafikkklasse filtrerer ikkje dei andre. Frå den skilnaden kjem det meste av skuffinga med kvar overlay.
Spørsmålet er altså ikkje om OTV stoppar broadcast-stormar. Det er kva trafikkklassar som kryssar, under kva vilkår, og kva som avgrensar raten når dei gjer det.
Stadfest underlaget medan du er der: støtta levering, pakkestorleik, ruting og naboskapet den valde versjonen krev. Ingenting av dette kjem gratis med overlayet, og ein tunnel som passar ei 1500-byte ramme er ikkje automatisk ein tunnel som passar dei tagga rammene dine.
Kontrakten som skal krevjast skriftleg
Uansett kva teneste du vel, be om dei same seks svara: punkt-til-punkt- eller multipoint-omfang, handsaming av kunderamme og tag, MAC-læringsmodell, flooding-grenser, gjenopprettingsåtferd og maksimal rammestorleik ende til ende. To tenester med same namn kan avvike på kvar einskild av dei. Få svara skriftleg, fordi ingeniøren som konfigurerte tenesta er kanskje ikkje den som svarar på spørsmålet.
Vel ei endring berre for eit krav den noverande tenesta bevisleg ikkje kan oppfylle. Å utvide eit VLAN vidare utvidar òg avhengnadene til applikasjonen og Ethernet med det; eit nytt overlay-namn fjernar dei ikkje.
RFC 4664-rammeverket legg fram tenestekategoriane og vidaresendingsmodellane deira, som er ordforrådet du treng for å stille det rette spørsmålet. Ta med dei seks svara og den mislykka testen til same møte, og avgjerda handlar ikkje lenger om etikettar.