Configurando Q-in-Q
Este tópico descreve maneiras de conectar seu equipamento de rede local a um provedor de serviços em nuvem (CSP) que usa Q-in-Q, como o Azure ExpressRoute. Além disso, como alguns CSPs exigem Q-in-Q, mas nem todos os dispositivos de rede suportam isso 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 manuseio de múltiplas tags VLAN em dispositivos de rede que não possuem suporte nativo para 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 só quadro permite o isolamento dos domínios de roteamento, pois as tags adicionais identificam e separam o tráfego do cliente. Usando uma tag VLAN diferente para cada cliente, o tráfego é identificado dentro do quadro e transferido por toda a rede do provedor de serviços.
Importante
Para diferenciar as tags VLAN sob o padrão 802.1ad, a tag interna usa comumente o EtherType 0x8100, e a tag externa usa 0x88a8. A configuração padrão para o Q-in-Q da maioria dos fornecedores de rede é que ambos os EtherTypes, interno e externo, sejam 0x8100. A especificação da Megaport para quadros com tags duplas é que ambas as tags, interna e externa, sejam 0x8100.
Com o Q-in-Q, à medida que um pacote viaja da rede do NSP ou da operadora para a VLAN de um provedor de serviços em nuvem (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. A S-Tag fornece uma única VLAN que encapsula várias VLANs dentro dela. Nessa configuração, um único VXC pode carregar as várias tags VLAN entre os dois endpoints da rede.
Para mais informações sobre o Q-in-Q, veja Conectando um VXC e o post do blog da Megaport Perguntas e Respostas sobre Q-in-Q: Parte 1. Para mais informações sobre como configurar o Q-in-Q para Azure, consulte o post do blog da Megaport Perguntas e Respostas sobre Q-in-Q: Parte 2.
Entendendo o Q-in-Q com VXCs da Megaport
Um Virtual Cross Connect (VXC) é um circuito de Camada 2 ponto a ponto entre dois endpoints, mapeado com um ID de VLAN em cada extremidade, opcionalmente com tags VLAN independentes nas terminações A e B sendo mapeadas através da rede da Megaport.
Esta imagem mostra um Azure ExpressRoute com peering privado e peering Microsoft habilitados. Um VXC conecta uma borda do cliente a uma borda da Microsoft na VLAN 1000 (S-Tag). A borda do cliente suporta Q-in-Q. O peering privado está operando na VLAN 100 (C-Tag) e o Peering Microsoft está 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 conectar-se a um serviço de terminação B que exige Q-in-Q, mesmo quando o equipamento de rede que termina sua conexão com a Megaport não oferece suporte nativo para isso.
| Alternativas ao Q-in-Q | Método | Desvantagens | ||
|---|---|---|---|---|
| VLAN de peering única da Azure | Você pode configurar o VXC para que a Megaport remova o requisito de Q-in-Q, remapeando um dos IDs de VLAN de terminação B para Peering Privado ou Peering Microsoft para a VLAN voltada ao cliente da Megaport (terminação A). | Você pode usar apenas um tipo de peering Microsoft por VXC. | ||
| Desmarcar o VXC conectado à Porta do cliente | Você pode configurar o VXC como sem marcação (untagged) para remover automaticamente a S-Tag. | Remover a marcação de uma VLAN limita a Porta a uma única conexão VXC. Usar este método significa que sua Porta só poderá configurar um único destino de terminação B, embora receba todas as C-Tags internas desse par como dot1q/tag única. | ||
| 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-se ao Microsoft ExpressRoute pode conter uma ou duas tags VLAN internas. Essas são as C-Tags configuradas no console do Microsoft Azure para o tipo de peering especificado. Note que o Q-in-Q é um requisito nesse cenário, mesmo se apenas um dispositivo de borda da Microsoft (primário ou secundário) ou tipo de peering (privado ou Microsoft) for utilizado. Equipamentos de rede que suportam Q-in-Q podem 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 poderá acessar as tags internas.
Aviso
Existem outros métodos alternativos para lidar com o Q-in-Q, como o manuseio no lado do cliente por meio de múltiplos dispositivos para des-encapsular os quadros Q-in-Q, ou usar cabos de loopback em um único dispositivo para gerenciar isso através da cascata por várias 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 Chave de Serviço Microsoft (e a seleção de terminação de destino primária e secundária associada) e oferece a capacidade de “desagregar” a C-Tag encapsulada para um tipo de peering do Azure especificado. Você habilita essa funcionalidade ativando o campo Configurar VLAN de Peering Única do Azure no painel de Detalhes da Conexão de uma nova conexão ExpressRoute, após selecionar uma porta da terminação B primária ou secundária.
Dica
Recomendamos o uso da opção de VLAN de Peering Única do Azure. Esta opção oferece funcionalidade completa e a implementação mais simples. Com a VLAN Única do Azure, você pode usar tanto o peering privado quanto o peering Microsoft com um único circuito ER sem a necessidade de equipamentos compatíveis com Q-in-Q, um MCR ou uma porta sem marcação. Note que você pode ter apenas um tipo de peering (privado ou Microsoft) por VXC com esta opção, então são necessários dois VXCs para usar ambos os tipos de peering.
Ao habilitar a funcionalidade de VLAN de Peering Única do Azure, você pode especificar uma única VLAN de peering do Azure que corresponderá ao valor que você configurará (em uma etapa futura) para a configuração do tipo de Peering selecionado para a configuração do Azure ExpressRoute (por meio do portal do Microsoft Azure ou outro método de configuração). Para mais informações, veja Tutorial: Criar e modificar o peering para um circuito ExpressRoute usando o portal do Azure.
Se você deixar o campo VLAN Preferida da Terminação A em branco, uma VLAN aleatória será atribuída ao seu VXC ao fazer o pedido. Caso contrário, insira uma VLAN e será realizada uma verificação de validação para garantir que essa VLAN esteja disponível.
Este exemplo mostra que um valor de C-Tag do Azure de 200 (para um peering Privado ou Microsoft no circuito ExpressRoute associado) é mapeado de forma transparente para um valor de VLAN de VXC de 3001. Ou seja, o dispositivo do cliente conectado à interface física da Megaport não precisa ser configurado para quaisquer configurações de Q-in-Q, pois a VLAN dot1q 3001 será conferida ao dispositivo de borda da Microsoft na terminação B com a rotulagem correta.
Nessa configuração, é possível usar os endpoints primário e secundário do Microsoft ExpressRoute em um determinado circuito ExpressRoute para mapear diferentes tags VLAN em uma única porta do lado do cliente. Isso está em conformidade com o Acordo de Nível de Serviço (SLA) do Azure ExpressRoute. No entanto, recomendamos que você empregue a diversidade de portas e dispositivos em um único site (zonas), ou divida as conexões primária/secundária do ExpressRoute em dois locais habilitados 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 o SLA para o Azure ExpressRoute.
Com este método, não é possível usar mais de um tipo de peering em qualquer uma das terminações primária ou secundária do VXC do ExpressRoute, pois essa tradução de tags pode ocorrer apenas uma vez por caminho de circuito do VXC. Outras soluções alternativas estão detalhadas nas seções seguintes; no entanto, observe que a segmentação de largura de banda entre vários tipos de peering em um único par de circuitos do ExpressRoute não é atualmente suportada pela Microsoft. Na maioria dos casos, é preferível implantar dois pares do ExpressRoute para atingir esse objetivo de configuração.
Aviso
As seções seguintes descrevem soluções alternativas que continuam com o exemplo do Microsoft ExpressRoute. Observe que essas soluções alternativas não são exclusivas para endpoints Azure e também podem ser usadas para outras conexões na Megaport onde a terminação B pode especificar ou exigir Q-in-Q para transportar múltiplas C-Tags/VLANs internas dentro de uma única S-Tag/VLAN externa do VXC. O exemplo do Microsoft ExpressRoute é usado para continuidade do cenário do cliente.
Configurar o VXC como desmarcado para gerenciar automaticamente a S-Tag
Aviso
Ao empregar este método, a Porta do cliente só poderá configurar um único alvo de terminação B, embora ela receba todas as C-tags internas desse peer como única/marcação dot1q.
Você pode configurar o VXC para que a Megaport remova a tag VLAN externa (S-Tag) e apresente uma ou ambas as tags VLAN internas (C-Tag/s) para Peering Privado, Peering Microsoft ou ambos, para a Porta do cliente.
Atualmente, esse processo permite apenas um VXC por conexão de Circuito ExpressRoute (selecionando a partir da apresentação da porta primária ou secundária), embora ambos os tipos de peering possam ser suportados por meio desse VXC, pois serão apresentados à Porta do cliente como uma ou duas VLANs dot1q (Privado, Peering Microsoft ou ambos).
Importante
A porta do cliente receberá as tags VLAN internas conforme definidas no portal do Azure para o tipo de peering especificado na terminação A da porta do cliente. Para mais informações, veja Conectando-se ao Microsoft Azure ExpressRoute.
Aviso
Cada assinatura do ExpressRoute inclui dois alvos de portas no local de borda da Microsoft escolhida. Para receber ambos os circuitos primário e secundário do ExpressRoute, você precisará de duas portas da Megaport nesta configuração. As tags VLAN do Azure VNET são as mesmas nas duas 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.
Aviso
Se você configurar apenas peering privado ou público na configuração do Azure ExpressRoute, apenas a VLAN associada à chave de serviço do ExpressRoute estará disponível no VXC configurado, mapeado um-para-um com a porta do cliente.
Usar um Megaport Cloud Router
O Megaport Cloud Router (MCR) suporta multi-nuvem e habilitação multi-região, incluindo suporte para Q-in-Q para conectar a vários destinos na nuvem. As S-Tags, ou tags externas, pertencem à VLAN da terminação A associada ao seu MCR e transportarão de forma transparente suas C-Tags. As S-Tags são configuradas automaticamente ao provisionar seu peering privado e público para a Nuvem Azure no Megaport Portal. Esta imagem mostra um exemplo de configuração:
Quando múltiplos VXCs do Azure em um MCR usam a mesma tag VLAN 100 (peering privado) e a mesma tag VLAN 200 (peering público), o MCR gerencia o túnel Q-in-Q para cada VXC do Azure que termina no MCR. Cada VLAN do Azure ainda é uma interface lógica separada.