Antes de añadir OTV, escriba el contrato Ethernet que necesita

Una carga de trabajo se traslada a un segundo centro de datos y empieza a agotar el tiempo de espera en un servicio que respondía bien desde el primero. Alguien propone OTV, porque la actual VPN de Capa 2 «no hace broadcast». Esa conclusión suele ser prematura. La categoría de servicio y el contrato concreto que compró son dos preguntas distintas, y el tiempo de espera aún no se ha atribuido a ninguna de ellas.

El síntoma que inicia la comparación

Escriba lo que la aplicación realmente necesita antes de comparar productos. El número de sedes, el alcance de VLAN, el aprendizaje de direcciones, la tolerancia a flooding y el comportamiento ante fallos describen el requisito. «Capa 2» y «OTV» describen arquitecturas, y ninguno de los dos es un requisito por sí solo. Cinco propiedades en una página sobrevivirán a cualquier comparación de proveedores.

Después compruebe si el servicio actual ya cumple esas cinco propiedades. Una VPN de Capa 2 gestionada por el proveedor puede incluir reenvío multipunto y aprendizaje en el plano de control que un vistazo rápido a la factura no mencionaba.

Si el servicio actual las cumple, el tiempo de espera está en otro sitio: un problema de MTU, una asimetría de enrutamiento, una regla de cortafuegos que difiere entre sedes. Cambiar el overlay dejaría esa causa en su sitio y añadiría una migración.

Lo que la etiqueta no le dice

Una VPN de Capa 2 es una categoría, no un producto. VPWS punto a punto y VPLS multipunto reenvían de forma distinta, y la categoría incluye servicios con aprendizaje en el plano de control y gestión de bucles, además de otros más simples. Suponer que toda VPN de Capa 2 conecta exactamente dos sedes y lo inunda todo es como se hace la comparación equivocada. El nombre en el contrato no dice nada sobre la tabla de reenvío que hay detrás.

Pregunte qué modelo de reenvío implementa el servicio existente, y cuál necesita la aplicación. Un requisito hub-and-spoke y un requisito full-mesh producen diseños distintos incluso cuando ambos se describen como Capa 2.

Dónde traza OTV su frontera

OTV funciona sobre un transporte IP con alcanzabilidad MAC en el plano de control y roles de borde definidos. La información local de spanning-tree permanece local en lugar de extenderse como un único dominio no controlado a través del transporte. Esa es una diferencia real respecto a una extensión puenteada simple, y es la razón por la que la gente recurre a ello.

La frontera importa tanto como el beneficio. El tratamiento de unicast, broadcast y multicast desconocidos depende de la plataforma y de su configuración, y una pareja de bordes debe cooperar mediante el mecanismo de multihoming admitido. Dos dispositivos independientes que reenvían el mismo VLAN no son el mismo diseño, y producen un modo de fallo diferente.

El flooding se reduce, no se elimina

Suprimir parte del flooding innecesario no es lo mismo que garantizar que ninguna trama broadcast o multicast cruce jamás la extensión. Una tormenta que se inicia en una sede aún puede consumir el transporte, y una función de plataforma que filtra una clase de tráfico no filtra las demás. De esa distinción viene la mayor parte de la decepción con cualquier overlay.

Así que la pregunta no es si OTV detiene las tormentas de broadcast. Es qué clases de tráfico cruzan, en qué condiciones, y qué limita la tasa cuando lo hacen.

Confirme el underlay mientras está allí: entrega admitida, tamaño de paquete, enrutamiento y la adyacencia que exige la versión elegida. Nada de eso viene gratis con el overlay, y un túnel que encaja una trama de 1500 bytes no es automáticamente un túnel que encaja sus tramas etiquetadas.

El contrato que hay que pedir, por escrito

Para cualquier servicio que elija, solicite las mismas seis respuestas: alcance punto a punto o multipunto, tratamiento de la trama y la etiqueta del cliente, modelo de aprendizaje MAC, límites de flooding, comportamiento de recuperación y el tamaño máximo de trama de extremo a extremo. Dos servicios con el mismo nombre pueden diferir en cada una de ellas. Consiga las respuestas por escrito, porque el ingeniero que configuró el servicio puede no ser el que responde a la pregunta.

Elija un cambio solo por un requisito que el servicio actual demuestra no poder cumplir. Extender una VLAN más allá extiende también las dependencias de la aplicación y de Ethernet con ella; un nuevo nombre de overlay no las elimina.

El marco RFC 4664 expone las categorías de servicio y sus modelos de reenvío, que es el vocabulario que necesita para plantear la pregunta correcta. Lleve las seis respuestas y la prueba fallida a la misma reunión, y la decisión deja de ser sobre etiquetas.