Antes de engadir OTV, escriba o contrato Ethernet que necesita

Unha carga de traballo trasládase a un segundo centro de datos e comeza a esgotar o tempo de espera nun servizo que respondía ben desde o primeiro. Alguén propón OTV, porque a actual VPN de Capa 2 «non fai broadcast». Esa conclusión adoita ser prematura. A categoría de servizo e o contrato concreto que comprou son dúas preguntas distintas, e o tempo de espera aínda non se atribuíu a ningunha delas.

O síntoma que inicia a comparación

Escriba o que a aplicación realmente necesita antes de comparar produtos. O número de sedes, o alcance de VLAN, a aprendizaxe de enderezos, a tolerancia a flooding e o comportamento ante fallos describen o requisito. «Capa 2» e «OTV» describen arquitecturas, e ningún dos dous é un requisito por si só. Cinco propiedades nunha páxina sobrevivirán a calquera comparación de provedores.

Despois comprobe se o servizo actual xa cumpre esas cinco propiedades. Unha VPN de Capa 2 xestionada polo provedor pode incluír reenvío multipunto e aprendizaxe no plano de control que unha ollada rápida á factura non mencionaba.

Se o servizo actual as cumpre, o tempo de espera está noutro sitio: un problema de MTU, unha asimetría de encamiñamento, unha regra de devasa que difire entre sedes. Cambiar o overlay deixaría esa causa no seu sitio e engadiría unha migración.

O que a etiqueta non lle di

Unha VPN de Capa 2 é unha categoría, non un produto. VPWS punto a punto e VPLS multipunto reenvían de forma distinta, e a categoría inclúe servizos con aprendizaxe no plano de control e xestión de bucles, ademais doutros máis simples. Supor que toda VPN de Capa 2 conecta exactamente dúas sedes e o inunda todo é como se fai a comparación equivocada. O nome no contrato non di nada sobre a táboa de reenvío que hai detrás.

Pregunte que modelo de reenvío implementa o servizo existente, e cal necesita a aplicación. Un requisito hub-and-spoke e un requisito full-mesh producen deseños distintos mesmo cando ambos se describen como Capa 2.

Onde traza OTV a súa fronteira

OTV funciona sobre un transporte IP con alcanzabilidade MAC no plano de control e roles de borde definidos. A información local de spanning-tree permanece local en lugar de estenderse como un único dominio non controlado a través do transporte. Esa é unha diferenza real respecto a unha extensión ponteada simple, e é a razón pola que a xente recorre a iso.

A fronteira importa tanto como o beneficio. O tratamento de unicast, broadcast e multicast descoñecidos depende da plataforma e da súa configuración, e unha parella de bordes debe cooperar mediante o mecanismo de multihoming admitido. Dous dispositivos independentes que reenvían o mesmo VLAN non son o mesmo deseño, e producen un modo de fallo diferente.

O flooding redúcese, non se elimina

Suprimir parte do flooding innecesario non é o mesmo que garantir que ningunha trama broadcast ou multicast cruce xamais a extensión. Unha tormenta que se inicia nunha sede aínda pode consumir o transporte, e unha función de plataforma que filtra unha clase de tráfico non filtra as demais. Desa distinción vén a maior parte da decepción con calquera overlay.

Así que a pregunta non é se OTV detén as tormentas de broadcast. É que clases de tráfico cruzan, en que condicións, e que limita a taxa cando o fan.

Confirme o underlay mentres está alí: entrega admitida, tamaño de paquete, encamiñamento e a adxacencia que esixe a versión elixida. Nada diso vén gratis co overlay, e un túnel que encaixa unha trama de 1500 bytes non é automaticamente un túnel que encaixa as súas tramas etiquetadas.

O contrato que hai que pedir, por escrito

Para calquera servizo que elixa, solicite as mesmas seis respostas: alcance punto a punto ou multipunto, tratamento da trama e da etiqueta do cliente, modelo de aprendizaxe MAC, límites de flooding, comportamento de recuperación e o tamaño máximo de trama de extremo a extremo. Dous servizos co mesmo nome poden diferir en cada unha delas. Consiga as respostas por escrito, porque o enxeñeiro que configurou o servizo pode non ser o que responde á pregunta.

Elixa un cambio só por un requisito que o servizo actual demostra non poder cumprir. Estender un VLAN máis aló estende tamén as dependencias da aplicación e de Ethernet con el; un novo nome de overlay non as elimina.

O marco RFC 4664 expón as categorías de servizo e os seus modelos de reenvío, que é o vocabulario que necesita para formular a pregunta correcta. Leve as seis respostas e a proba fallida á mesma reunión, e a decisión deixa de ser sobre etiquetas.