Før du tilføjer OTV, skriv den Ethernet-kontrakt ned, som du har brug for

En arbejdsbyrde flytter til et andet datacenter og begynder at få tidsudløb på en tjeneste, der svarede fint fra det første. Nogen foreslår OTV, fordi den eksisterende Layer 2 VPN »ikke gør broadcast«. Den konklusion er som regel forhastet. Tjenestekategorien og den konkrete kontrakt, du har købt, er to forskellige spørgsmål, og tidsudløbet er endnu ikke tilskrevet nogen af dem.

Symptomet, der starter sammenligningen

Skriv ned, hvad applikationen faktisk har brug for, før du sammenligner produkter. Antal lokationer, VLAN-omfang, adresselæring, flooding-tolerance og fejlopførsel beskriver kravet. »Layer 2« og »OTV« beskriver arkitekturer, og ingen af dem er et krav i sig selv. Fem egenskaber på én side overlever enhver leverandørsammenligning.

Kontroller derefter, om den nuværende tjeneste allerede opfylder de fem egenskaber. En udbyderstyret Layer 2 VPN kan indeholde multipoint-videresendelse og læring i kontrolplanet, som et hurtigt blik på fakturaen ikke nævnte.

Hvis den nuværende tjeneste opfylder dem, er tidsudløbet et andet sted: et MTU-problem, en routingasymmetri, en firewallregel, der er forskellig mellem lokationer. At skifte overlay ville efterlade den årsag og tilføje en migrering.

Hvad etiketten ikke fortæller dig

En Layer 2 VPN er en kategori, ikke et produkt. Punkt-til-punkt VPWS og multipoint VPLS videresender forskelligt, og kategorien omfatter tjenester med læring i kontrolplanet og loopstyring såvel som enklere. At antage, at enhver Layer 2 VPN forbinder præcis to lokationer og flooder alt, er måden at lave den forkerte sammenligning. Navnet på kontrakten siger intet om videresendelsestabellen bag det.

Spørg hvilken videresendelsesmodel den eksisterende tjeneste implementerer, og hvilken applikationen har brug for. Et hub-and-spoke-krav og et full-mesh-krav giver forskellige designs, selv når begge beskrives som Layer 2.

Hvor OTV trækker sin grænse

OTV kører over en IP-transport med MAC-rækkevidde i kontrolplanet og definerede edge-roller. Lokal spanning-tree-information forbliver lokal i stedet for at blive udvidet som ét ukontrolleret domæne over transporten. Det er en reel forskel fra en simpel broet udvidelse, og det er grunden til, at folk griber efter det.

Grænsen betyder lige så meget som fordelen. Håndtering af ukendt unicast, broadcast og multicast afhænger af platformen og dens konfiguration, og et edge-par skal samarbejde gennem den understøttede multihoming-mekanisme. To uafhængige enheder, der videresender samme VLAN, er ikke samme design og giver en anden fejltilstand.

Flooding reduceres, ikke fjernes

At undertrykke noget unødvendigt flooding er ikke det samme som at garantere, at ingen broadcast- eller multicast-frame nogensinde krydser udvidelsen. En storm, der starter på én lokation, kan stadig æde transporten, og en platformfunktion, der filtrerer én trafikklasse, filtrerer ikke de andre. Den forskel er, hvor det meste af skuffelsen med enhver overlay kommer fra.

Spørgsmålet er altså ikke, om OTV stopper broadcast-storme. Det er, hvilke trafikklasser der krydser, under hvilke betingelser, og hvad der begrænser raten, når de gør.

Bekræft underlayet, mens du er der: understøttet levering, pakkestørrelse, routing og det naboskab, den valgte version kræver. Intet af det følger gratis med overlayet, og en tunnel, der passer til en 1500-byte-frame, er ikke automatisk en tunnel, der passer til dine taggede frames.

Kontrakten, der skal anmodes om skriftligt

Uanset hvilken tjeneste du vælger, bed om de samme seks svar: punkt-til-punkt- eller multipoint-omfang, håndtering af kundeframe og tag, MAC-læringsmodel, flooding-grænser, genopretningsadfærd og den maksimale framestørrelse ende til ende. To tjenester med samme navn kan afvige på hver enkelt af dem. Få svarene skriftligt, fordi den ingeniør, der konfigurerede tjenesten, ikke nødvendigvis er den, der besvarer spørgsmålet.

Vælg kun en ændring for et krav, som den nuværende tjeneste beviseligt ikke kan opfylde. At udvide et VLAN yderligere udvider også applikationens og Ethernetets afhængigheder med det; et nyt overlay-navn fjerner dem ikke.

RFC 4664-rammeværket opstiller tjenestekategorierne og deres videresendelsesmodeller, hvilket er det ordforråd, du har brug for til at stille det rigtige spørgsmål. Tag de seks svar og den fejlende test med til samme møde, og beslutningen handler ikke længere om etiketter.