L2VPN, VPLS y EVPN: la etiqueta no es el servicio
El acrónimo del formulario de pedido nombra una familia, un comportamiento de reenvío o un plano de control. Cuatro preguntas los separan antes de comparar dos presupuestos.
Lees «L2VPN» en un presupuesto, luego «VPLS» en la hoja de configuración, y das por hecho que la segunda palabra restringe la primera. A veces lo hace, y a veces las dos líneas responden preguntas no relacionadas. El error es tratar estos nombres como peldaños de una escala de lo básico a lo avanzado. L2VPN es una familia, VPWS y VPLS son dos comportamientos de servicio dentro de ella, y EVPN es un mecanismo de plano de control que puede transportar cualquiera de los dos.
Cada acrónimo responde a una pregunta distinta
Empieza por lo que debe hacer el acceso del cliente, porque esa es la única pregunta que responde el modelo de servicio. Un circuito punto a punto entre dos sedes y un segmento Ethernet compartido por diez sedes son productos distintos, aunque ambos se vendan como conectividad de capa 2.
| Name | Question it answers | What it does not tell you |
|---|---|---|
| L2VPN | Which family of services carries Ethernet frames | Point-to-point or multipoint |
| VPWS | A pair of attachment circuits behaves as one wire | Which control plane builds it |
| VPLS | Many attachments share a bridged broadcast domain | Whether MAC learning is limited or flooded |
| EVPN | BGP distributes MAC and IP reachability | Which service model it is being used for |
Esa tabla no es una jerarquía, y leerla como tal provoca el error de compra habitual: comparar un presupuesto de VPWS con uno de VPLS como si el segundo fuera la versión más completa del primero. Resuelven problemas distintos, y ninguno es un superconjunto en el sentido que suponen los compradores.
VPWS y VPLS se separan en la decisión de reenvío
En un servicio de cable privado virtual, el acceso selecciona el extremo remoto. El tráfico que llega a ese puerto sale hacia el puerto emparejado, y el borde del proveedor no necesita aprender qué direcciones MAC hay detrás para la decisión básica de reenvío.
En un VPLS, el borde del proveedor hace de puente. Examina la dirección MAC de destino de cada trama, aprende las direcciones de origen por acceso e inunda los destinos desconocidos dentro de la LAN emulada. Eso hace que el servicio se comporte como una LAN, y de ahí vienen también los límites operativos.
Un diagrama que parece multipunto no demuestra que todas las sedes compartan un único dominio de difusión. Dos proveedores pueden dibujar la misma nube y vender un dominio puente o varios circuitos punto a punto, y la diferencia solo se hace visible cuando una difusión, una trama unicast desconocida o un movimiento de MAC cruza la frontera de una sede. Un ping de difusión entre dos sedes responde la pregunta más rápido que cualquier diapositiva de arquitectura. Si las respuestas llegan de todas las demás sedes, tienes un puente; si solo responde la pareja, tienes un cable.
EVPN es un plano de control, no una topología
La especificación base de EVPN, la RFC 7432, define procedimientos de Ethernet VPN basados en BGP MPLS: la alcanzabilidad de las MAC se anuncia en BGP en lugar de aprenderse solo por inundación del plano de datos. Después la RFC 8214 especifica el soporte de VPWS con EVPN, y ese es el punto que rompe el modelo de escala. El mismo plano de control sirve un servicio punto a punto y uno multipunto.
Así que «ejecutamos EVPN» no es una respuesta a «qué compramos». El proveedor todavía tiene que decir si el servicio es un par de accesos o un puente compartido, y si el transporte es MPLS, VXLAN o algo más. Esas decisiones viven en documentos distintos y en partes distintas de la configuración.
Para un operador, la consecuencia práctica es que elegir EVPN pronto abarata los cambios posteriores del servicio, porque la alcanzabilidad ya se señaliza en lugar de inundarse. No elimina la necesidad de decidir primero el modelo de servicio, ni corrige un puente mal configurado.
MPLS es una ruta de datos, no la definición
Los documentos marco describen la familia y sus requisitos; no exigen una encapsulación. El apilamiento de etiquetas MPLS es un transporte habitual para estos servicios, y no es el único. Un servicio señalizado por BGP y una ruta de reenvío MPLS son decisiones de diseño separadas que solo suelen aparecer juntas.
Cuando un proveedor dice «MPLS L2VPN», pregunta qué mitad se está describiendo. Si la respuesta es solo el transporte, el modelo de servicio sigue sin especificar y el comportamiento del acceso sigue siendo desconocido.
Cuatro preguntas que convierten una etiqueta en un contrato
Pregunta qué es la entrega: un puerto, una VLAN o un conjunto de VLAN, y cuáles pueden hablar entre sí. Pregunta si las sedes comparten un único dominio de difusión, porque esa única respuesta determina la inundación, los límites de MAC y cómo se comportará un bucle.
Pide el presupuesto de tamaño de trama de extremo a extremo y luego añade tú mismo la sobrecarga de encapsulación. Pregunta qué ocurre cuando falla un acceso, si los demás siguen reenviando y si el proveedor retira la alcanzabilidad o la deja hasta que caduca un temporizador.
Escribe esas cuatro respuestas junto al nombre del producto en tu registro. Cuando llegue el siguiente presupuesto con otro acrónimo y el mismo precio, la comparación se convierte en una comparación de comportamiento, que es la única que predice qué hará la red en un mal día.