Configurando Q-in-Q
Este tópico descreve maneiras de conectar seu equipamento de rede on-premises a um Cloud Service Provider (CSP) que usa Q-in-QO tunelamento 802.1Q (também conhecido como Q-in-Q ou 802.1ad) é uma técnica usada por provedores de Camada 2 do OSI para clientes. O 802.1ad prevê tanto uma tag interna quanto uma tag externa, na qual a externa (às vezes chamada de S-tag, de provedor de serviços) pode ser removida para expor as tags internas (C-tag, de cliente) que segmentam os dados.
, como o Azure ExpressRoute. Além disso, como alguns CSPs exigem Q-in-Q, mas nem todos os dispositivos de rede o suportam, ou a mistura de tags simples e múltiplas em uma única interface física (“Q-in-Q seletivo”), este tópico inclui maneiras de configurar o tratamento de tags VLAN em múltiplas camadas em dispositivos de rede sem suporte nativo a Q-in-Q.
Visão geral
Q-in-Q, também conhecido como 802.1ad, é um protocolo comumente usado por provedores de serviços de rede (NSPs) para fornecer mais flexibilidade na Camada 2. O Q-in-Q permite que múltiplas tags VLAN sejam inseridas em um único quadro Ethernet. Empilhar múltiplas tags VLAN em um quadro permite o isolamento de domínios de roteamento, pois as tags adicionais identificam e separam o tráfego do cliente. Ao usar uma tag VLAN diferente para cada cliente, o tráfego é identificado dentro do quadro e é transportado por toda a rede do provedor de serviços.
Importante
Para diferenciar as tags VLAN sob o padrão 802.1ad, a interna usa comumente EtherType 0x8100 e a externa usa 0x88a8. A configuração padrão do Q-in-Q da maioria dos fabricantes de rede é que tanto o EtherType interno quanto o externo sejam 0x8100. A especificação da Megaport para quadros com dupla tag é que tanto as tags internas quanto as externas sejam 0x8100.
Com Q-in-Q, à medida que um pacote viaja de uma rede de NSP ou operadora para a VLAN de um provedor de serviços de cloud (ou outro), as tags VLAN internas (C-Tags) que identificam o tráfego do cliente são inseridas dentro das tags VLAN externas (S-Tags) fornecidas pelo provedor de serviços. O S-Tag fornece uma única VLAN que encapsula múltiplas VLANs dentro dela. Nessa configuração, um(a) único(a) VXC pode transportar múltiplas tags VLAN entre os dois endpoints de rede.
Para mais informações sobre Q-in-Q, consulte Conectando um VXC e o Megaport blog post Q & A for Q-in-Q: Part 1. Para mais informações sobre como configurar Q-in-Q para Azure, consulte o Megaport blog post Q & A for Q-in-Q: Part 2.
Entendendo o Q-in-Q com Megaport VXCs
Um Virtual Cross Connect (VXC) é um circuito de Camada 2 ponto a ponto entre dois endpoints que é mapeado com um ID de VLAN em cada extremidade, opcionalmente com as tags VLAN de A-End e B-End mapeadas de forma independente pela rede da Megaport.
Esta imagem mostra um Azure ExpressRoute com Private Peering e Microsoft Peering habilitados. Um VXC conecta a borda do cliente à borda da Microsoft na VLAN 1000 (S-Tag). A borda do cliente suporta Q-in-Q. O Private Peering está em execução na VLAN 100 (C-Tag) e o Microsoft Peering está em execução na VLAN 200 (C-Tag) para estabelecer conexões de Camada 3 e peering BGP com o Azure.
E se meus roteadores ou switches não suportarem Q-in-Q?
Esta seção descreve maneiras de se conectar a um serviço B-End que exige Q-in-Q, mesmo quando o equipamento de rede que termina sua conexão Megaport não oferece suporte nativo.
| Alternativas ao Q-in-Q | Método | Desvantagens | ||
|---|---|---|---|---|
| VLAN de Peering única do Azure | Você pode configurar o VXC para que a Megaport remova a exigência de Q-in-Q ao remapear um dos IDs de VLAN do B-End para Private Peering ou Microsoft Peering para a VLAN voltada ao cliente da Megaport (A-End). | Você só pode usar um único tipo de Microsoft Peering por VXC. | ||
| Remover a tag do VXC anexado à Port do cliente | Você pode configurar o VXC como untagged para remover automaticamente o S-Tag. | Remover a tag de uma VLAN (untagging) limita a Port a uma única conexão de VXC. Empregar esse método significa que sua Port só poderá configurar um único destino B-End, embora receba todas as C-Tags internas desse par como tags simples/dot1q. | ||
| Implantar um Megaport Cloud Router | Você pode implantar um Megaport Cloud Router (MCR) para gerenciar automaticamente os requisitos de Q-in-Q para um ou ambos os tipos de Peering. | Custo adicional do MCR e VXC adicional para o MCR. |
Um VXC conectando ao Microsoft ExpressRoute pode conter uma ou duas tags VLAN internas. Estas são as C-tags configuradas no console do Microsoft Azure para o tipo de Peering especificado. Observe que o Q-in-Q é um requisito nesse cenário, mesmo se apenas um único dispositivo de borda da Microsoft (primário ou secundário) ou tipo de Peering (Private ou Microsoft) for utilizado. Equipamentos de rede que suportam Q-in-Q conseguem acessar essas tags internas removendo a tag VLAN externa (S-Tag). Se o seu equipamento de rede não suportar Q-in-Q, ele não conseguirá acessar as tags internas.
Nota
Existem outras alternativas para Q-in-Q, como tratar no lado do cliente por meio de múltiplos dispositivos para desencapsular os quadros Q-in-Q, ou usar cabos de loopback dentro de um único dispositivo para gerenciar isso em cascata por múltiplas portas com diferentes configurações de VLAN para tags internas e externas. No entanto, isso geralmente não é recomendado em redes de produção.
VLAN de Peering única do Azure
Para conexões Microsoft Azure ExpressRoute, a Megaport usa uma Microsoft Service Key (e a seleção associada de endpoints de destino primário e secundário) e fornece a capacidade de fazer o break out do C-Tag encapsulado para um tipo de Peering do Azure especificado. Você habilita essa funcionalidade ativando a Configure Single Azure Peering VLAN no painel Connection Details de uma nova conexão ExpressRoute, após selecionar uma porta B-End de destino primária ou secundária.
Dica
Recomendamos usar a opção Single Azure Peering VLAN. Essa opção fornece funcionalidade completa e a implementação mais simples. Com Single Azure VLAN, você pode usar Private ou Microsoft Peering com um único circuito ER sem a necessidade de equipamento compatível com Q-in-Q, um MCR, ou uma porta untagged. Observe que você só pode ter um tipo de Peering (Private ou Microsoft) por VXC com essa opção, portanto você precisa de dois VXCs para usar ambos os tipos de Peering.
Ao habilitar a funcionalidade Single Azure VLAN Peering VLAN, você pode especificar uma única VLAN de peering do Azure que corresponderá ao valor que você configurar (em uma etapa futura) para o tipo de Peering selecionado na configuração do Azure ExpressRoute (via Microsoft Azure portal ou outro método de configuração). Para mais informações, consulte Tutorial: Create and modify peering for an ExpressRoute circuit using the Azure portal.
Se você deixar o campo Preferred A-End VLAN (VLAN preferencial do A-End) em branco, uma VLAN escolhida aleatoriamente será atribuída ao seu VXC quando você fizer o pedido; caso contrário, insira uma VLAN e uma verificação de validação será executada para garantir que essa VLAN esteja disponível.
Este exemplo mostra que um valor de C-tag do Azure de 200 (para Private ou Microsoft Peering no circuito ExpressRoute associado) é mapeado de forma transparente para um valor de VLAN de VXC com tag única de 3001. Ou seja, o dispositivo do cliente conectado à interface física da Megaport não precisa ser configurado com nenhuma definição de Q-in-Q, pois a VLAN dot1q 3001 será entregue ao dispositivo de borda B-End voltado para a Microsoft como corretamente etiquetada.
Nessa configuração, é possível usar ambos os endpoints Microsoft ExpressRoute primário e secundário em um determinado circuito ExpressRoute para mapear para diferentes tags VLAN em uma única porta do lado do cliente. Isso está em conformidade para os propósitos do Service Level Agreement (SLA) do Azure ExpressRoute. No entanto, recomendamos que você empregue diversidade de Port e dispositivo em um único site (zonal) ou divida as conexões ExpressRoute primárias/secundárias entre duas localidades habilitadas pela Megaport para garantir que não exista um único ponto de falha na configuração.
Para mais informações sobre o SLA do Azure ExpressRoute, consulte SLA for Azure ExpressRoute.
Com esse método, não é possível usar mais de um tipo de Peering em nenhum dos VXCs voltados para o ExpressRoute primário ou secundário, pois essa tradução de tag só pode ocorrer uma vez por caminho de circuito do VXC. Outras alternativas são detalhadas nas seções a seguir; no entanto, observe que a segmentação de banda entre múltiplos tipos de Peering em um único par de circuitos ExpressRoute não é atualmente suportada pela Microsoft. Na maioria dos casos, é preferível implantar dois pares de ExpressRoute para atingir esse objetivo de configuração.
Nota
As seções a seguir descrevem alternativas que continuam com o exemplo do Microsoft ExpressRoute. Observe que essas alternativas não são exclusivas para endpoints do Azure e também podem ser usadas para outras conexões através da Megaport, onde o B-End pode especificar ou exigir Q-in-Q para transportar múltiplas VLANs internas/C-Tag dentro de uma única VLAN externa/S-Tag de VXC. O exemplo do Microsoft ExpressRoute é usado para manter a continuidade do cenário do cliente.
Configurar o VXC como untagged para gerenciar automaticamente o S-Tag
Nota
Empregar esse método significa que a Port do cliente só poderá configurar um único destino B-End, embora receba todas as C-tags internas desse par como tags simples/dot1q.
Você pode configurar o VXC para que a Megaport remova a VLAN externa (S-Tag) e apresente uma ou ambas as VLANs internas (C-Tag/s) para Private Peering, Microsoft Peering, ou ambos, à Port do cliente.
Atualmente, esse processo permite apenas um VXC por ExpressRoute Circuit Connection (selecionando entre apresentação de porta primária ou secundária), embora ambos os tipos de Peering possam ser suportados nesse VXC, pois serão apresentados à porta do cliente como uma ou duas VLANs dot1q (Private, Microsoft Peering, ou ambos).
Importante
A porta do cliente receberá as tags VLAN internas conforme definido no Azure portal sob o tipo de Peering especificado na porta do cliente A-End. Para mais informações, consulte Conectando-se ao Microsoft Azure ExpressRoute.
Nota
Cada assinatura do ExpressRoute inclui dois destinos de porta na localização de borda da Microsoft escolhida. Para receber ambos os circuitos ExpressRoute primário e secundário, você precisará de duas portas da Megaport nesta configuração. As tags de VLAN do Azure VNET são as mesmas em ambas as portas. A Megaport não pode alterar a tag VLAN nos circuitos primário e secundário e não pode entregar a mesma VLAN duas vezes na mesma interface física.
Nota
Se você configurar apenas Private ou Public Peering na configuração do Azure ExpressRoute, somente a VLAN associada à service key do ExpressRoute estará disponível no VXC configurado, mapeada um-para-um com a porta do cliente.
Implantar um Megaport Cloud Router
O Megaport Cloud Router (MCR) oferece suporte a multicloud e habilitação multi-região, incluindo suporte a Q-in-Q para conectar a múltiplos destinos de cloud. Os S-Tags, ou tags externas, pertencem à VLAN A-End associada ao seu MCR e transportarão seus C-Tags de forma transparente. Os S-Tags são configurados automaticamente ao provisionar seu Private e Public Peering para a Azure Cloud no Megaport Portal. Esta imagem mostra uma configuração de exemplo:
Quando múltiplos VXCs do Azure em um MCR utilizam a mesma tag VLAN 100 (private peering) e a mesma tag VLAN 200 (public peering), o MCR gerencia o túnel Q-in-Q para cada VXC do Azure que termina no MCR. Cada VLAN do Azure continua sendo uma interface lógica separada.