Configuración de Q-in-Q
Este tema describe formas de conectar su equipo de red local (on‑premises) a un Proveedor de Servicios en la Nube (CSP) que usa Q-in-QLa tunelización 802.1Q (también conocida como Q-in-Q o 802.1ad) es una técnica utilizada por proveedores de Capa 2 del modelo OSI para clientes. 802.1ad admite tanto una etiqueta interna como una externa mediante la cual la externa (a veces llamada S-tag de proveedor de servicios) puede eliminarse para exponer las etiquetas internas (C-tag o de cliente) que segmentan los datos.
, como Azure ExpressRoute. Además, debido a que algunos CSP requieren Q-in-Q, pero no todos los dispositivos de red lo admiten, o la mezcla de etiquetas únicas y múltiples en una única interfaz física (“Q-in-Q selectivo”), este tema incluye formas de configurar el manejo de múltiples capas de etiquetas VLAN en dispositivos de red sin compatibilidad nativa con Q-in-Q.
Descripción general
Q-in-Q, también conocido como 802.1ad, es un protocolo comúnmente utilizado por los proveedores de servicios de red (NSP) para proporcionar mayor flexibilidad de Capa 2. Q-in-Q permite insertar múltiples etiquetas VLAN en una sola trama Ethernet. Apilar múltiples etiquetas VLAN en una trama permite el aislamiento de dominios de enrutamiento, porque las etiquetas adicionales identifican y separan el tráfico del cliente. Al usar una etiqueta VLAN diferente para cada cliente, el tráfico se identifica dentro de la trama y se transfiere a través de la red del proveedor de servicios.
Importante
Para diferenciar las etiquetas VLAN según el estándar 802.1ad, la etiqueta interna usa comúnmente EtherType 0x8100 y la externa usa 0x88a8. La configuración predeterminada del Q-in-Q de la mayoría de los fabricantes de redes es que tanto los EtherType internos como los externos sean 0x8100. La especificación de Megaport para tramas con doble etiqueta es que tanto las etiquetas internas como las externas sean 0x8100.
Con Q-in-Q, a medida que un paquete viaja desde una red NSP o de carrier a la VLAN de un proveedor de servicios cloud (u otro), las etiquetas VLAN internas (C-Tags) que identifican el tráfico del cliente se insertan dentro de las etiquetas VLAN externas (S-Tags) proporcionadas por el proveedor de servicios. El S-Tag proporciona una única VLAN que encapsula múltiples VLAN en su interior. En esta configuración, un solo VXC puede transportar múltiples etiquetas VLAN entre los dos extremos de la red.
Para obtener más información sobre Q-in-Q, consulte Conectar un VXC y la Megaport blog post Q & A for Q-in-Q: Part 1. Para obtener más información sobre la configuración de Q-in-Q para Azure, consulte la Megaport blog post Q & A for Q-in-Q: Part 2.
Comprender Q-in-Q con Megaport VXCs
Un Virtual Cross Connect (VXC) es un circuito de Capa 2 punto a punto entre dos extremos que se asigna con un ID de VLAN en cada extremo, opcionalmente con etiquetas VLAN de A-End y B-End mapeadas de forma independiente a través de la red de Megaport.
Esta imagen muestra un Azure ExpressRoute con Peering privado y Microsoft Peering habilitados. Un VXC conecta un borde del cliente con un borde de Microsoft en la VLAN 1000 (S-Tag). El borde del cliente admite Q-in-Q. El Peering privado se ejecuta en la VLAN 100 (C-Tag) y Microsoft Peering se ejecuta en la VLAN 200 (C-Tag) para establecer conexiones de Capa 3 y Peering BGP con Azure.
¿Qué ocurre si mis routers o switches no admiten Q-in-Q?
Esta sección describe formas de conectarse a un servicio B-End que requiere Q-in-Q incluso cuando el equipo de red que termina su conexión de Megaport no lo admite de forma nativa.
| Alternativas de Q-in-Q | Método | Inconvenientes | ||
|---|---|---|---|---|
| VLAN de Peering única de Azure | Puede configurar el VXC para que Megaport elimine el requisito de Q-in-Q volviendo a mapear uno de los ID de VLAN de B-End para Private Peering o Microsoft Peering a la VLAN orientada al cliente de Megaport (A-End). | Solo puede usar un único tipo de Microsoft Peering por VXC. | ||
| Quitar la etiqueta (untag) a la VXC conectada al Port del cliente | Puede configurar el VXC como untagged para eliminar automáticamente el S-Tag. | Quitar la etiqueta (untag) de una VLAN limita el Port a una sola conexión de VXC. Emplear este método significa que su Port solo podrá configurar un único destino B-End, aunque recibirá todos los C-Tags internos de ese peer como etiquetados simple/dot1q. | ||
| Implementar un Megaport Cloud Router | Puede implementar un Megaport Cloud Router (MCR) para gestionar automáticamente los requisitos de Q-in-Q para uno o ambos tipos de Peering. | Costo adicional del MCR y una VXC adicional hacia el MCR. |
Un VXC que se conecta a Microsoft ExpressRoute puede contener una o dos etiquetas VLAN internas. Estas son las C-Tags configuradas en la consola de Microsoft Azure para el tipo de Peering especificado. Tenga en cuenta que Q-in-Q es un requisito en este escenario, incluso si solo se emplea un único dispositivo de borde de Microsoft (primario o secundario) o un tipo de Peering (privado o Microsoft). El equipo de red que admite Q-in-Q puede acceder a estas etiquetas internas eliminando la etiqueta VLAN externa (S-Tag). Si su equipo de red no admite Q-in-Q, no podrá acceder a las etiquetas internas.
Nota
Existen otras alternativas para Q-in-Q, como manejarlo del lado del cliente mediante múltiples dispositivos para desencapsular las tramas Q-in-Q, o usar cables de loopback dentro de un mismo dispositivo para gestionarlo en cascada a través de múltiples puertos con diferentes configuraciones de VLAN para etiquetas internas y externas. Sin embargo, en general no se recomienda en redes de producción.
VLAN de Peering única de Azure
Para las conexiones de Microsoft Azure ExpressRoute, Megaport utiliza una Clave de servicio de Microsoft (Microsoft Service Key) (y la selección asociada de endpoints de destino primario y secundario) y proporciona la capacidad de extraer la C-Tag encapsulada para un tipo de Peering de Azure especificado. Habilita esta funcionalidad activando Configurar VLAN de Peering única de Azure en el panel Detalles de la conexión de una nueva conexión de ExpressRoute, después de seleccionar un puerto de destino B-End primario o secundario.
Consejo
Recomendamos usar la opción VLAN de Peering única de Azure. Esta opción proporciona funcionalidad completa y la implementación más sencilla. Con VLAN de Azure única, puede usar Peering privado o Microsoft Peering con un solo circuito ER sin necesidad de equipos compatibles con Q-in-Q, un MCR, o un puerto untagged. Tenga en cuenta que solo puede tener un tipo de Peering (privado o Microsoft) por VXC con esta opción, por lo que necesita dos VXCs para usar ambos tipos de Peering.
Al habilitar la funcionalidad VLAN de Peering de Azure única, puede especificar una VLAN de Peering de Azure única que coincidirá con el valor que configure (en un paso futuro) para la configuración del tipo de Peering seleccionado en la configuración de Azure ExpressRoute (a través del portal de Microsoft Azure u otro método de configuración). Para obtener más información, consulte Tutorial: Create and modify peering for an ExpressRoute circuit using the Azure portal.
Si deja el campo Preferred A-End VLAN (VLAN A-End preferida) en blanco, se asignará una VLAN escogida aleatoriamente para su VXC cuando realice el pedido; de lo contrario, introduzca una VLAN y se realizará una comprobación de validación para garantizar que esta VLAN esté disponible.
Este ejemplo muestra que un valor de C-Tag de Azure de 200 (ya sea para un tipo de Peering privado o Microsoft en el circuito ExpressRoute asociado) se mapea de forma transparente a un valor de VLAN de VXC de etiqueta única de 3001. Es decir, el dispositivo del cliente conectado a la interfaz física de Megaport no necesita configurarse con ningún ajuste de Q-in-Q, ya que la VLAN dot1q 3001 se entregará al dispositivo de borde B-End orientado a Microsoft con la etiqueta correcta.
En esta configuración, es posible usar tanto los endpoints primario como secundario de Microsoft ExpressRoute en un circuito ExpressRoute determinado para mapear a diferentes etiquetas VLAN en un único puerto del lado del cliente. Esto cumple con el Acuerdo de Nivel de Servicio (SLA) de Azure ExpressRoute. Sin embargo, recomendamos que emplee diversidad por sitio y equipo (zonal), o dividir las conexiones ExpressRoute primarias/secundarias en dos ubicaciones habilitadas por Megaport para asegurar que no exista un único punto de falla en la configuración.
Para obtener más información sobre el SLA de Azure ExpressRoute, consulte SLA for Azure ExpressRoute.
Con este método, no es posible usar más de un tipo de Peering en ninguno de los VXC orientados a ExpressRoute primario o secundario, ya que esta traducción de etiquetas solo puede ocurrir una vez por ruta de circuito de VXC. Se detallan más alternativas en las siguientes secciones; sin embargo, tenga en cuenta que la segmentación del ancho de banda entre múltiples tipos de Peering en un único par de circuitos ExpressRoute no está actualmente soportada por Microsoft. En la mayoría de los casos, es preferible implementar dos pares de ExpressRoute para lograr este objetivo de configuración.
Nota
Las siguientes secciones describen alternativas que continúan con el ejemplo de Microsoft ExpressRoute. Tenga en cuenta que estas alternativas no son exclusivas de endpoints de Azure y también pueden utilizarse para otras conexiones a través de Megaport donde el B-End pueda especificar o requerir Q-in-Q para transportar múltiples C-Tag/VLAN internas dentro de una única VLAN VXC S-Tag/externa. Se utiliza el ejemplo de Microsoft ExpressRoute por continuidad del escenario del cliente.
Configurar la VXC como untagged para gestionar automáticamente el S-Tag
Nota
Emplear este método significa que el Port del cliente solo podrá configurar un único destino B-End, aunque recibirá todos los C-Tags internos de ese peer como etiquetados simple/dot1q.
Puede configurar el VXC para que Megaport elimine la VLAN externa (S-Tag) y presente una o ambas VLAN internas (C-Tag/s) para Private Peering, Microsoft Peering, o ambos, al Port del cliente.
Actualmente, este proceso permite solo un VXC por conexión de circuito ExpressRoute (seleccionando entre la presentación de puerto primario o secundario), aunque ambos tipos de Peering pueden ser soportados a través de este VXC ya que se presentarán al puerto del cliente como una o dos VLAN dot1q (Private, Microsoft Peering, o ambos).
Importante
El puerto del cliente recibirá las etiquetas VLAN internas tal como se definen en el portal de Azure bajo el tipo de Peering especificado en el puerto del cliente de A-End. Para obtener más información, consulte Conexión a Microsoft Azure ExpressRoute.
Nota
Cada suscripción de ExpressRoute incluye dos destinos de puerto en la ubicación de borde de Microsoft elegida. Para recibir ambos circuitos ExpressRoute, primario y secundario, necesitará dos puertos de Megaport en esta configuración. Las etiquetas VLAN de la VNET de Azure son las mismas en ambos puertos. Megaport no puede cambiar la etiqueta VLAN en los circuitos primario y secundario y no puede entregar la misma VLAN dos veces en la misma interfaz física.
Nota
Si configura solo Peering privado o público en la configuración de Azure ExpressRoute, solo la VLAN asociada con la Service Key de ExpressRoute estará disponible en el VXC configurado, mapeada uno a uno con el puerto del cliente.
Implementar un Megaport Cloud Router
El Megaport Cloud Router (MCR) admite habilitación multinube y multirregión, incluyendo compatibilidad con Q-in-Q para conectar a múltiples destinos cloud. Los S-Tags, o etiquetas externas, pertenecen a la VLAN de A-End asociada con su MCR y transportarán de forma transparente sus C-Tags. Los S-Tags se configuran automáticamente al aprovisionar su Peering privado y público con Azure Cloud en el Megaport Portal. Esta imagen muestra un ejemplo de configuración:
Cuando múltiples VXCs de Azure en un MCR pueblan la misma etiqueta VLAN 100 (Peering privado) y la misma etiqueta VLAN 200 (Peering público), MCR gestiona el túnel Q-in-Q para cada VXC de Azure que termina en el MCR. Cada VLAN de Azure sigue siendo una interfaz lógica independiente.