’n Werklading verhuis na ’n tweede datakesenter en begin tyd uitloop op ’n diens wat van die eerste een af goed geantwoord het. Iemand stel OTV voor, omdat die bestaande Layer 2 VPN “nie broadcast doen nie”. Daardie gevolgtrekking is gewoonlik voortydig. Die dienskategorie en die spesifieke kontrak wat jy gekoop het, is twee verskillende vrae, en die tydloop is nog nie aan een van die twee toegeskryf nie.

Die simptoom wat die vergelyking begin

Skryf neer wat die toepassing werklik nodig het voordat jy produkte vergelyk. Site-getal, VLAN-omvang, adreslering, flooding-toleransie en foutgedrag beskryf die vereiste. “Layer 2” en “OTV” beskryf argitekture, en nie een van hulle is op sigself ’n vereiste nie. Vyf eienskappe op een bladsy sal enige verkoopvergelyking oorleef.

Kontroleer dan of die huidige diens reeds aan daardie vyf eienskappe voldoen. ’n Layer 2 VPN wat deur die verskaffer beheer word, kan multipoint-forwarding en beheervlak-lering insluit wat ’n vinnige kyk na die faktuur nie vermeld nie.

As die huidige diens wel aan hulle voldoen, is die tydloop elders: ’n MTU-probleem, ’n roeterings-asimmetrie, ’n vuurmuur reël wat tussen sites verskil. Om die overlay te verander, sou daardie oorsaak in plek los en ’n migrasie byvoeg.

Wat die etiket jou nie sê nie

’n Layer 2 VPN is ’n kategorie, nie ’n produk nie. Punt-tot-punt VPWS en multipoint VPLS forward anders, en die kategorie sluit dienste met beheervlak-lering en lusbeheer sowel as eenvoudiger dienste in. Om aan te neem dat elke Layer 2 VPN presies twee sites verbind en alles flood, is hoe die verkeerde vergelyking gemaak word. Die naam op die kontrak sê niks oor die forwarding-tabel wat daaragter staan nie.

Vra welke forwarding-model die bestaande diens implementeer, en watter een die toepassing nodig het. ’n Hub-en-spoke-vereiste en ’n full-mesh-vereiste produseer verskillende ontwerpe, selfs wanneer albei as Layer 2 beskryf word.

Waar OTV sy grens teken

OTV loop oor ’n IP-transport met beheervlak-MAC-bereikbaarheid en gedefinieerde edge-rolle. Plaaslike spanning-tree-inligting bly plaaslik, eerder as om as een onbeheerde domein oor die transport uitgebrei te word. Dit is ’n werklike verskil van ’n gewone gebrugde uitbreiding, en dit is die rede waarom mense dit gebruik.

Die grens is net so belangrik soos die voordeel. Onbekende unicast, broadcast en multicast hantering hang af van die platform en sy konfigurasie, en ’n edge-paar moet deur die ondersteunde multihoming-meganisme saamwerk. Twee onafhanklike toestelle wat dieselfde VLAN forward, is nie dieselfde ontwerp nie, en dit produseer ’n ander foutmodus.

Flooding word verminder, nie verwyder nie

Om een of ander onnodige flooding te onderdruk is nie dieselfde as om te waarborg dat geen broadcast- of multicast-frame ooit die uitbreiding kruis nie. ’n Storm wat op een site begin, kan steeds die transport verteer, en ’n platformfunksie wat een verkeersklas filter, filter nie die ander nie. Daardie onderskeid is waar die meeste teleurstelling met enige overlay uit kom.

Die vraag om te vra is dus nie of OTV broadcast-storms stop nie. Dit is welke verkeersklasse kruis, onder welke voorwaardes, en wat die tempo beperk wanneer hulle dit doen.

Bevestig die underlay terwyl jy daar is: ondersteunde aflewering, pakketgrootte, roetering en die adjacensie wat die gekose uitgawe vereis. Niks daarvan kom gratis met die overlay nie, en ’n tonnel wat ’n 1500-byte-raam pas, is nie outomaties ’n tonnel wat jou getagde rame pas nie.

Die kontrak wat jy op skrif moet vra

Vir watter diens jy ook al keuse, versoek dieselfde ses antwoorde: punt-tot-punt- of multipoint-omvang, hantering van klantrame en -etikette, MAC-lering-model, flooding-limiete, herstelgedrag en die maksimum raamgrootte van einde tot einde. Twee dienste met dieselfde naam kan op elkeen van hulle verskil. Kry die antwoorde op skrif, want die ingenieur wat die diens gekonfigureer het, is miskien nie die een wat die vraag beantwoord nie.

Keuse ’n verandering net vir ’n vereiste wat die huidige diens aantoonbaar nie kan meet nie. Om ’n VLAN verder uit te brei, brei die toepassing se en Ethernet se afhanklikhede saam uit; ’n nuwe overlay-naam verwyder hulle nie.

Die RFC 4664-raamwerk lê die dienskategorieë en hul forwarding-modelle uit, wat die woordeskat is wat jy nodig het om die regte vraag te vra. Bring die ses antwoorde en die falende toets na dieselfde vergadering, en die beslissing is nie meer oor etikette nie.

Verwante artikels