Configuración de Q-in-Q
Este tema describe las formas de conectar su equipo de red local a un proveedor de servicios en la nube (CSP) que utiliza Q-in-Q, como Azure ExpressRoute. Además, dado que algunos CSP requieren Q-in-Q, pero no todos los dispositivos de red admiten esto o la mezcla de etiquetas simples y múltiples en una sola interfaz física («Q-in-Q selectivo»), este tema incluye formas de configurar la gestión de etiquetas VLAN con varias capas en dispositivos de red sin soporte nativo de Q-in-Q.
Descripción general
Q-in-Q, también denominado «802.1ad», es un protocolo que suelen utilizar los proveedores de servicios de red (NSP) para proporcionar más flexibilidad de capa 2. Q-in-Q permite insertar varias etiquetas VLAN en una sola trama Ethernet. El apilamiento de varias etiquetas VLAN en una trama permite aislar los dominios de enrutamiento, ya que las etiquetas adicionales identifican y separan el tráfico de los clientes. Al utilizar una etiqueta VLAN diferente para cada cliente, el tráfico se identifica en la trama y se transfiere a través de la red del proveedor de servicios.
Importante
Para diferenciar las etiquetas VLAN bajo el estándar 802.1ad, el interior suele utilizar EtherType 0x8100, y el exterior, 0x88a8. La configuración por defecto de la mayoría de los proveedores de red Q-in-Q es que los EtherTypes tanto internos como externos sean 0x8100. La especificación de Megaport para las tramas con doble etiqueta es que tanto las etiquetas interiores como las exteriores sean 0x8100.
Con Q-in-Q, cuando un paquete viaja desde un NSP o una red de operador a la VLAN de un proveedor de servicios en la nube (u otro tipo), las etiquetas VLAN internas (C-Tags) que identifican el tráfico del cliente se insertan en las etiquetas VLAN externas (S-Tags) proporcionadas por el proveedor de servicios. La etiqueta S proporciona una VLAN única que encapsula varias VLAN en su interior. En esta configuración, una sola VXC puede transportar las etiquetas VLAN entre los dos puntos de conexión de la red.
Para obtener más información sobre Q-in-Q, consulte Conexión de VXC y la entrada del blog de Megaport Preguntas y respuestas sobre Q-in-Q: parte 1. Para obtener más detalles sobre la configuración de Q-in-Q en Azure, consulte la entrada del blog de Megaport Preguntas y respuestas sobre Q-in-Q: parte 2.
Explicación de Q-in-Q con VXC de Megaport
Una VXC (conexión cruzada virtual) es un circuito punto a punto de capa 2 entre dos puntos de conexión, que se asigna con un ID de VLAN en cada extremo. De manera opcional, también se pueden asignar etiquetas de VLAN en los extremos A y B de la red de Megaport.
Esta figura muestra Azure ExpressRoute con emparejamiento privado y emparejamiento de Microsoft habilitado. Una VXC conecta un perímetro del cliente a un perímetro de Microsoft en la VLAN 1000 (S-Tag). El perímetro del cliente admite Q-in-Q. El emparejamiento privado se ejecuta en la VLAN 100 (C-Tag), mientras que el emparejamiento de Microsoft se ejecuta en la VLAN 200 (C-Tag) para establecer conexiones de capa 3 y emparejamiento de BGP con Azure.
¿Qué pasa si mis enrutadores o conmutadores no admiten Q-in-Q?
Esta sección describe las formas de conectarse a un servicio del extremo B que requiere Q-in-Q, incluso si el equipo de red que termina la conexión de Megaport no lo admite de forma nativa.
| Alternativas de Q-in-Q | Método | Desventajas | ||
|---|---|---|---|---|
| Única VLAN de emparejamiento de Azure | Puede configurar la VXC para que Megaport elimine el requisito de Q-in-Q reasignando uno de los ID de VLAN de extremo B para el emparejamiento privado o de Microsoft a la VLAN del cliente orientada a Megaport (extremo A). | Solo puede usar un tipo de emparejamiento de Microsoft por cada VXC. | ||
| Quitar etiqueta de la VXC adjunta al Puerto del cliente | Puede quitar la etiqueta de la VXC para eliminar automáticamente la etiqueta S. | Quitar la etiqueta de una VLAN limita el Puerto a una sola conexión VXC. Emplear este método implica que el Puerto solo podrá configurar un único destino en el extremo B, aunque recibirá todas las C-Tag internas de ese par etiquetadas como single/dot1q. | ||
| Implementación de un Megaport Cloud Router | Puede implementar un Megaport Cloud Router (MCR) para administrar automáticamente los requisitos de Q-in-Q en uno o ambos tipos de emparejamiento. | Coste adicional del MCR y VXC adicional al MCR. |
Una VXC que se conecta a Microsoft ExpressRoute puede contener una o dos etiquetas VLAN internas. Estas son las C-Tag configuradas en la consola de Microsoft Azure para el tipo de emparejamiento especificado. Tenga en cuenta que Q-in-Q es un requisito en este caso, aunque solo se utilice un único dispositivo perimetral de Microsoft (primario o secundario) o un tipo de emparejamiento (privado o de Microsoft). Los equipos de red que admiten Q-in-Q podrán acceder a estas etiquetas internas si eliminan la etiqueta VLAN externa (S-Tag). En caso de que el equipo de red no admita Q-in-Q, no podrá acceder a las etiquetas internas.
Nota
Existen otras soluciones de Q-in-Q, como la gestión en el lado del cliente mediante varios dispositivos para desencapsular las tramas de Q-in-Q o el uso de cables de bucle invertido en un solo dispositivo para administrarlo mediante la conexión en cascada de varios puertos con diferentes configuraciones de VLAN respecto a las etiquetas internas y externas. Sin embargo, esto no suele recomendarse en las redes de producción.
Única VLAN de emparejamiento de Azure
En las conexiones de Microsoft Azure ExpressRoute, Megaport utiliza una clave de servicio de Microsoft (y la selección de los puntos de conexión de destino primario y secundario asociados) y permite extraer la C-Tag encapsulada para el tipo de emparejamiento de Azure especificado. Para habilitar esta funcionalidad, habilite la opción Configure Single Azure Peering VLAN (Configurar una única VLAN de emparejamiento de Azure) en el panel Connection Details (Detalles de la conexión) de una nueva conexión de ExpressRoute tras seleccionar un puerto del extremo B de destino principal o secundario.
Consejo
Recomendamos utilizar la opción Single Azure Peering VLAN (Única VLAN de Emparejamiento de Azure). Esta opción ofrece una funcionalidad completa y la implementación más sencilla. Con Single Azure VLAN (Única VLAN de Azure), puede utilizar tanto el emparejamiento privado como el de Microsoft con un único circuito ER sin necesidad de un equipo con capacidad Q-in-Q, un MCR o un puerto no etiquetado. Tenga en cuenta que solo puede tener un tipo de emparejamiento (privado o Microsoft) por VXC con esta opción, así que necesita dos VXC para usar los dos tipos de emparejamiento.
Si habilita la funcionalidad de única VLAN de emparejamiento de Azure, puede especificar una única VLAN de emparejamiento de Azure que coincida con el valor indicado (en un paso posterior) para configurar el tipo de emparejamiento para la configuración de Azure ExpressRoute, ya sea a través del portal de Microsoft Azure u otro método. Para obtener más detalles, consulte Tutorial: Cree y modifique el emparejamiento para un circuito de ExpressRoute a través del portal de Azure.
Si deja en blanco el campo Preferred A-End VLAN (VLAN Preferida en el Extremo A), se asignará una VLAN elegida al azar a la VXC cuando realice el pedido. De lo contrario, introduzca una VLAN para realizar una comprobación de disponibilidad.
Este ejemplo muestra que un valor de C-Tag de Azure de 200 (para un tipo de emparejamiento privado o de Microsoft en el circuito de ExpressRoute asociado) se ha asignado de forma transparente a un valor VLAN de VXC con una sola etiqueta de 3001. Esto implica que el dispositivo del cliente adjunto a la interfaz física de Megaport no se debe configurar en ningún parámetros de Q-in-Q, ya que la VLAN 3001 de dot1q se transmitirá al dispositivo perimetral del extremo B orientado a Microsoft como correctamente etiquetada.
En esta configuración, se pueden utilizar los puntos de conexión de Microsoft ExpressRoute primarios o secundarios en un circuito de ExpressRoute determinado para asignarlos a varias etiquetas VLAN en un solo puerto del lado del cliente. Esto cumple con los propósitos del Acuerdo de Nivel de Servicio (SLA) de Azure ExpressRoute. Sin embargo, le recomendamos emplear la diversidad de puertos y dispositivos (por zonas) en un solo sitio o dividir las conexiones ExpressRoute primarias/secundarias en dos ubicaciones habilitadas para Megaport. De este modo, garantizará que no se produzcan fallos en la configuración.
Para obtener detalles sobre el SLA de Azure ExpressRoute, consulte SLA de Azure ExpressRoute.
Con este método, no se puede utilizar más de un tipo de emparejamiento a través de los ExpressRoute primarios o secundarios orientados a VXC, ya que esta traducción de etiquetas solo puede ocurrir una vez por ruta de circuito de VXC. En las siguientes secciones se detallan más soluciones alternativas. Sin embargo, tenga en cuenta que Microsoft todavía no admite la segmentación del ancho de banda entre varios tipos de emparejamiento en un único par de circuitos de ExpressRoute. En la mayoría de casos, es preferible implementar dos pares de ExpressRoute para lograr este objetivo de configuración.
Nota
Las secciones siguientes describen las soluciones que siguen adoptando el ejemplo de Microsoft ExpressRoute. Tenga en cuenta que estas alternativas no son exclusivas de los puntos de conexión de Azure, ya que también se pueden utilizar en otras conexiones de Megaport donde el extremo B especifique o requiera Q-in-Q para transportar varias C-Tag/internas de VLAN en una sola VXC S-Tag/externa de VLAN. El ejemplo de Microsoft ExpressRoute se utiliza para la continuidad del caso del cliente.
Configurar la VXC sin etiquetas para administrar automáticamente la S-Tag
Nota
Emplear este método implica que el Megaport del cliente solo podrá configurar un único destino en el extremo B, aunque recibirá todas las C-Tag internas de ese par etiquetadas como «single»/«dot1q».
Puede configurar la VXC para que Megaport elimine la VLAN externa (S-Tag) y presente una o dos VLAN internas (C-Tag) en relación el emparejamiento privado, de Microsoft o ambos al Megaport del cliente.
Actualmente, este proceso solo permite una VXC por conexión de circuito de ExpressRoute (seleccione la presentación del puerto primario o secundario). No obstante, la VXC admite ambos tipos de emparejamiento, ya que se presentarán al puerto del cliente como una o dos VLAN dot1q (privada, emparejamiento de Microsoft o ambas).
Importante
El puerto del cliente recibirá las etiquetas VLAN internas que se definen en el portal Azure con el tipo de emparejamiento especificado en el puerto de cliente del extremo A. Para obtener más detalles, consulte Conexión a Microsoft Azure ExpressRoute.
Nota
Cada suscripción a ExpressRoute incluye dos objetivos de puerto en la ubicación perimetral de Microsoft que haya elegido. Para recibir los circuitos de ExpressRoute primario y secundario, necesitará dos puertos de Megaport en esta configuración. Las etiquetas VLAN de Azure VNET son las mismas en ambos puertos. Megaport no puede cambiar la etiqueta VLAN en los circuitos primario y secundario ni puede entregar la misma VLAN dos veces en la misma interfaz física.
Nota
Si solo configura los emparejamientos privado o público en la configuración de Azure ExpressRoute, la VXC configurada mostrará únicamente la VLAN asociada a la clave de servicio de ExpressRoute, que se asigna uno a uno con el puerto del cliente.
Implementar un Megaport Cloud Router
Megaport Cloud Router (MCR) admite la habilitación de varias nubes y regiones, incluida la compatibilidad con Q-in-Q para conectarse a varios destinos en la nube. Las S-Tags (etiquetas externas) pertenecen al extremo A de la VLAN asociada al MCR y transportan C-Tags de forma transparente. Las S-Tags se configuran automáticamente al aprovisionar los emparejamientos privado y público a Azure Cloud en el portal de Megaport. Esta figura muestra un ejemplo de configuración:
Si varias VXC de Azure en un MCR completan la misma etiqueta VLAN 100 (emparejamiento privado) y la misma etiqueta VLAN 200 (emparejamiento público), el MCR administrará el túnel de Q-in-Q para cada VXC de Azure que termina en el MCR. Cada VLAN de Azure sigue siendo una interfaz lógica independiente.