Før du legger til OTV, skriv ned Ethernet-kontrakten du trenger

En arbeidsbelastning flyttes til et andre datasenter og begynner å få tidsavbrudd på en tjeneste som svarte fint fra det første. Noen foreslår OTV, fordi den eksisterende Layer 2 VPN-en «ikke gjør broadcast». Den konklusjonen er vanligvis forhastet. Tjenestekategorien og den konkrete kontrakten du kjøpte er to forskjellige spørsmål, og tidsavbruddet er ennå ikke tilskrevet noen av dem.

Symptomet som starter sammenligningen

Skriv ned hva applikasjonen faktisk trenger før du sammenligner produkter. Antall nettsteder, VLAN-omfang, adresselæring, flooding-toleranse og feilatferd beskriver kravet. «Layer 2» og «OTV» beskriver arkitekturer, og ingen av dem er et krav i seg selv. Fem egenskaper på én side overlever enhver leverandørsammenligning.

Sjekk deretter om den nåværende tjenesten allerede oppfyller de fem egenskapene. En leverandørstyrt Layer 2 VPN kan inneholde multipoint-videresending og læring i kontrollplanet som et raskt blikk på fakturaen ikke nevnte.

Hvis den nåværende tjenesten oppfyller dem, er tidsavbruddet et annet sted: et MTU-problem, en rutingsasymmetri, en brannmurregel som er forskjellig mellom nettsteder. Å bytte overlay ville la den årsaken stå og legge til en migrering.

Hva etiketten ikke forteller deg

En Layer 2 VPN er en kategori, ikke et produkt. Punkt-til-punkt VPWS og multipoint VPLS videresender ulikt, og kategorien omfatter tjenester med læring i kontrollplanet og løkkestyring så vel som enklere. Å anta at enhver Layer 2 VPN kobler nøyaktig to nettsteder og flommer alt, er måten å gjøre den gale sammenligningen. Navnet på kontrakten sier ingenting om videresendingstabellen bak det.

Spør hvilken videresendingsmodell den eksisterende tjenesten implementerer, og hvilken applikasjonen trenger. Et hub-and-spoke-krav og et full-mesh-krav gir forskjellige design selv når begge beskrives som Layer 2.

Hvor OTV trekker grensen sin

OTV kjører over en IP-transport med MAC-tilgjengelighet i kontrollplanet og definerte edge-roller. Lokal spanning-tree-informasjon forblir lokal i stedet for å utvides som ett ukontrollert domene over transporten. Det er en reell forskjell fra en enkel broet utvidelse, og det er grunnen til at folk griper til det.

Grensen betyr like mye som fordelen. Håndtering av ukjent unicast, broadcast og multicast avhenger av plattformen og konfigurasjonen, og et edge-par må samarbeide gjennom den støttede multihoming-mekanismen. To uavhengige enheter som videresender samme VLAN er ikke samme design, og de gir en annen feilmodus.

Flooding reduseres, ikke fjernes

Å undertrykke noe unødvendig flooding er ikke det samme som å garantere at ingen broadcast- eller multicast-ramme noensinne krysser utvidelsen. En storm som starter på ett nettsted kan fortsatt spise transporten, og en plattformfunksjon som filtrerer én trafikkklasse filtrerer ikke de andre. Fra den forskjellen kommer det meste av skuffelsen med enhver overlay.

Spørsmålet er altså ikke om OTV stopper broadcast-stormer. Det er hvilke trafikkklasser som krysser, under hvilke betingelser, og hva som begrenser raten når de gjør det.

Bekreft underlaget mens du er der: støttet levering, pakkestørrelse, ruting og naboskapet den valgte versjonen krever. Ingenting av dette kommer gratis med overlayet, og en tunnel som passer en 1500-byte ramme er ikke automatisk en tunnel som passer dine taggede rammer.

Kontrakten som skal kreves skriftlig

Uansett hvilken tjeneste du velger, be om de samme seks svarene: punkt-til-punkt- eller multipoint-omfang, håndtering av kunderamme og tag, MAC-læringsmodell, flooding-grenser, gjenopprettingsatferd og maksimal rammestørrelse ende til ende. To tjenester med samme navn kan avvike på hver enkelt av dem. Få svarene skriftlig, fordi ingeniøren som konfigurerte tjenesten ikke nødvendigvis er den som svarer på spørsmålet.

Velg en endring bare for et krav den nåværende tjenesten beviselig ikke kan oppfylle. Å utvide et VLAN videre utvider også applikasjonens og Ethernets avhengigheter med det; et nytt overlay-navn fjerner dem ikke.

RFC 4664-rammeverket legger fram tjenestekategoriene og videresendingsmodellene deres, som er ordforrådet du trenger for å stille det riktige spørsmålet. Ta med de seks svarene og den mislykkede testen til samme møte, og beslutningen handler ikke lenger om etiketter.