Abans d’afegir OTV, escriviu el contracte Ethernet que necessiteu

Una càrrega de treball es trasllada a un segon centre de dades i comença a esgotar el temps en un servei que responia bé des del primer. Algú proposa OTV, perquè l’actual Layer 2 VPN «no fa broadcast». Aquesta conclusió sol ser prematura. La categoria de servei i el contracte concret que heu comprat són dues preguntes diferents, i l’esgotament de temps encara no s’ha atribuït a cap de les dues.

El símptoma que inicia la comparació

Escriviu què necessita realment l’aplicació abans de comparar productes. El nombre de seus, l’abast de VLAN, l’aprenentatge d’adreces, la tolerància a flooding i el comportament en cas de fallada descriuen el requisit. «Layer 2» i «OTV» descriuen arquitectures, i cap dels dos no és un requisit per si sol. Cinc propietats en una pàgina sobreviuran a qualsevol comparació de proveïdors.

Després comproveu si el servei actual ja compleix aquestes cinc propietats. Un Layer 2 VPN gestionat pel proveïdor pot incloure reenviament multipoint i aprenentatge de pla de control que una mirada ràpida a la factura no esmentava.

Si el servei actual les compleix, l’esgotament de temps és en un altre lloc: un problema d’MTU, una asimetria d’encaminament, una regla de tallafoc que difereix entre seus. Canviar l’overlay deixaria aquesta causa al seu lloc i afegiria una migració.

Què no us diu l’etiqueta

Un Layer 2 VPN és una categoria, no un producte. VPWS punt a punt i VPLS multipoint reenvien de manera diferent, i la categoria inclou serveis amb aprenentatge de pla de control i gestió de bucles, així com d’altres més senzills. Suposar que cada Layer 2 VPN connecta exactament dues seus i ho inunda tot és com es fa la comparació equivocada. El nom al contracte no diu res sobre la taula de reenviament que hi ha darrere.

Pregunteu quin model de reenviament implementa el servei existent, i quin necessita l’aplicació. Un requisit hub-and-spoke i un requisit full-mesh produeixen dissenys diferents fins i tot quan tots dos es descriuen com a Layer 2.

On OTV dibuixa la seva frontera

OTV funciona sobre un transport IP amb abast de MAC al pla de control i rols d’edge definits. La informació local de spanning-tree es queda local en lloc d’estendre’s com un únic domini no controlat a través del transport. Aquesta és una diferència real respecte a una extensió pontada simple, i és la raó per la qual la gent hi recurre.

La frontera importa tant com el benefici. El tractament d’unicast, broadcast i multicast desconeguts depèn de la plataforma i de la seva configuració, i una parella d’edge ha de cooperar mitjançant el mecanisme de multihoming suportat. Dos dispositius independents que reenvien el mateix VLAN no són el mateix disseny, i produeixen un mode de fallada diferent.

El flooding es redueix, no s’elimina

Suprimir part del flooding innecessari no és el mateix que garantir que cap trama broadcast o multicast travessarà mai l’extensió. Una tempesta que comença en una seu encara pot consumir el transport, i una funció de plataforma que filtra una classe de trànsit no filtra les altres. D’aquesta distinció ve la major part de la decepció amb qualsevol overlay.

Així, la pregunta no és si OTV atura les tempestes de broadcast. És quines classes de trànsit travessen, sota quines condicions, i què limita la taxa quan ho fan.

Confirmeu l’underlay mentre hi sou: lliurament suportat, mida de paquet, encaminament i l’adjacència que requereix la versió triada. Res d’això no ve gratis amb l’overlay, i un túnel que encaixa una trama de 1500 bytes no és automàticament un túnel que encaixa les vostres trames etiquetades.

El contracte que cal demanar, per escrit

Per qualsevol servei que trieu, demaneu les mateixes sis respostes: abast punt a punt o multipoint, tractament de la trama i l’etiqueta del client, model d’aprenentatge MAC, límits de flooding, comportament de recuperació i la mida màxima de trama d’extrem a extrem. Dos serveis amb el mateix nom poden diferir en cadascuna d’elles. Obteniu les respostes per escrit, perquè l’enginyer que va configurar el servei pot no ser el qui respon la pregunta.

Trieu un canvi només per a un requisit que el servei actual demostradament no pot complir. Estendre un VLAN més enllà estén també les dependències de l’aplicació i d’Ethernet amb ell; un nom nou d’overlay no les elimina.

El marc RFC 4664 estableix les categories de servei i els seus models de reenviament, que és el vocabulari que necessiteu per fer la pregunta correcta. Porteu les sis respostes i la prova fallida a la mateixa reunió, i la decisió deixa de ser sobre etiquetes.