Configurazione Q-in-Q

Questo argomento descrive i modi per connettere l’attrezzatura di rete on-premises a un provider di servizi cloud (CSP) che utilizza Q-in-QIl tunneling 802.1Q (noto anche come Q-in-Q o 802.1ad) è una tecnica utilizzata dai fornitori OSI Layer 2 per i clienti. 802.1ad prevede sia un tag interno che uno esterno in cui l’esterno (a volte chiamato S-tag per il fornitore di servizi) può essere rimosso per esporre i tag interni (C-tag o client) che segmentano i dati.
, come Azure ExpressRoute. Inoltre, poiché alcuni CSP richiedono Q-in-Q, ma non tutti i dispositivi di rete lo supportano, o la miscelazione di tag singoli e multipli su un’interfaccia fisica singola (“Q-in-Q selettivo”), questo argomento include modi per configurare la gestione di più tag VLAN su dispositivi di rete senza supporto Q-in-Q nativo.

Panoramica

Q-in-Q, noto anche come 802.1ad, è un protocollo comunemente utilizzato dai provider di servizi di rete (NSP) per fornire più flessibilità a livello 2. Q-in-Q consente di inserire più tag VLAN in un singolo frame Ethernet. L’impilamento di più tag VLAN in un frame consente l’isolamento dei domini di instradamento, perché i tag aggiuntivi identificano e separano il traffico del cliente. Utilizzando un tag VLAN diverso per ogni cliente, il traffico viene identificato all’interno del frame e viene trasferito attraverso la rete del provider di servizi.

Con Q-in-Q, quando un pacchetto viaggia da una rete NSP o carrier a una VLAN del provider di servizi cloud (o altro), i tag VLAN interni (C-Tags) che identificano il traffico del cliente vengono inseriti all’interno dei tag VLAN esterni (S-Tags) forniti dal provider di servizi. L’S-Tag fornisce una singola VLAN che incapsula più VLAN al suo interno. In questa configurazione, un singolo VXC può trasportare i tag VLAN multipli tra i due endpoint di rete.

Per ulteriori informazioni su Q-in-Q, vedere Connessione di un VXC e il post sul blog di Megaport Q & A per Q-in-Q: Parte 1. Per ulteriori informazioni su come configurare Q-in-Q per Azure, vedere il post sul blog di Megaport Q & A per Q-in-Q: Parte 2.

Comprensione di Q-in-Q con i VXC di Megaport

Il Virtual Cross Connect (VXC) è un circuito punto-punto di Livello 2 tra due endpoint che è mappato con un ID VLAN su ciascuna estremità, opzionalmente con i tag VLAN di estremità A e B mappati in modo indipendente attraverso la rete Megaport.

Questa immagine mostra un Azure ExpressRoute con peering privato e Microsoft Peering abilitato. Un VXC collega un bordo del cliente a un bordo Microsoft su VLAN 1000 (S-Tag). Il bordo del cliente supporta Q-in-Q. Il peering privato è in esecuzione su VLAN 100 (C-Tag) e il peering Microsoft è in esecuzione su VLAN 200 (C-Tag) per stabilire connessioni di Livello 3 e peering BGP con Azure.

E se i miei router o switch non supportano Q-in-Q?

Questa sezione descrive i modi per connettersi a un servizio di Estremità-B che richiede Q-in-Q anche quando l’attrezzatura di rete che termina la tua connessione Megaport non la supporta nativamente.

Un VXC che si collega a Microsoft ExpressRoute può contenere uno o due tag VLAN interni. Questi sono i C-tag configurati nella console Microsoft Azure per il tipo di peering specificato. Nota che Q-in-Q è un requisito in questo scenario, anche se viene utilizzato solo un dispositivo edge Microsoft (primario o secondario) o un tipo di peering (privato o Microsoft). Le attrezzature di rete che supportano Q-in-Q sono in grado di accedere a questi tag interni rimuovendo il tag VLAN esterno (S-Tag). Se le tue attrezzature di rete non supportano Q-in-Q, non possono accedere ai tag interni.

VLAN di peering Azure singola

Per le connessioni Microsoft Azure ExpressRoute, Megaport utilizza una chiave di servizio Microsoft (e la selezione associata dell’endpoint di destinazione primario e secondario) e offre la possibilità di “esternalizzare” il C-Tag incapsulato per un tipo di peering di Azure specificato. Attivi questa funzionalità abilitando la Configurazione della singola VLAN di Peering Azure nel pannello Dettagli Connessione di una nuova connessione ExpressRoute, dopo aver selezionato una porta Estremità-B primaria o secondaria.

Abilitando la funzionalità della singola VLAN di Peering di Azure, è possibile specificare una singola VLAN di peering di Azure che coinciderà con il valore che si configura (in un passo futuro) per la configurazione del tipo di Peering selezionato per la configurazione Azure ExpressRoute (tramite il portale Microsoft Azure o un altro metodo di configurazione). Per ulteriori informazioni, vedere il Tutorial: Creare e modificare il peering per un circuito ExpressRoute utilizzando il portale Azure.

Se si lascia il campo VLAN di Estremità-A Preferita vuoto, una VLAN scelta a caso verrà assegnata per il tuo VXC quando si effettua l’ordine, altrimenti inserisci una VLAN e verrà eseguito un controllo di validazione per assicurarsi che questa VLAN sia disponibile.

Questo esempio mostra che un valore di C-tag di Azure di 200 (per il tipo di Peering Privato o Microsoft sul circuito ExpressRoute associato) viene mappato in modo trasparente a un valore di VLAN VXC con tag singolo di 3001. Cioè, il dispositivo del cliente collegato all’interfaccia fisica Megaport non deve essere configurato per nessuna impostazione Q-in-Q, poiché il VLAN 3001 dot1q sarà conferito al dispositivo a bordo di Microsoft associato come correttamente etichettato.

In questa configurazione, è possibile utilizzare sia gli endpoint primari che secondari di Microsoft ExpressRoute su un determinato circuito ExpressRoute per mappare a diversi tag VLAN su una singola porta lato cliente. Questo è conforme per le finalità del Service Level Agreement (SLA) di Azure ExpressRoute. Tuttavia, raccomandiamo di impiegare o la diversità di dispositivo di porta e sito singolo (zonale), o di dividere le connessioni ExpressRoute primarie/secondarie su due posizioni abilitate a Megaport per garantire che non esista un singolo punto di fallimento con la configurazione.

Per ulteriori informazioni sul SLA di Azure ExpressRoute, vedere SLA for Azure ExpressRoute.

Con questo metodo, non è possibile utilizzare più di un tipo di peering su entrambi i VXC di ExpressRoute primari o secondari, poiché questa traduzione del tag può verificarsi solo una volta per il percorso del circuito VXC. Ulteriori soluzioni alternative sono dettagliate nelle sezioni seguenti, tuttavia, nota che la segmentazione della larghezza di banda tra più tipi di peering su una singola coppia di circuiti ExpressRoute non è attualmente supportata da Microsoft. Nella maggior parte dei casi, è preferibile implementare due coppie di ExpressRoute per raggiungere questo obiettivo di configurazione.

Configurare il VXC come non classificato per gestire automaticamente l’S-Tag

Puoi configurare il VXC in modo che Megaport rimuova il VLAN esterno (S-Tag) e presenti uno o entrambi i VLAN interni (C-Tag/s) per il Peering Privato, Microsoft Peering, o entrambi, alla Porta del cliente. Attualmente, questo processo consente solo una VXC per Connessione del Circuito ExpressRoute (selezionando dal portale Primario o Secondario), sebbene entrambi i tipi di peering possano essere supportati attraverso questo VXC poiché verranno presentati alla porta del cliente come uno o due VLAN dot1q (Peering Privato, Microsoft Peering, o entrambi).

Implementazione di un Megaport Cloud Router

Il Megaport Cloud Router (MCR) supporta l’abilitazione multicloud, multiregione, incluso il supporto per Q-in-Q per connettersi a molteplici destinazioni cloud. Gli S-Tag, o tag esterni, appartengono al VLAN di Estremità-A associato al tuo MCR e trasporteranno trasparentemente i tuoi C-Tag. Gli S-Tag vengono configurati automaticamente durante la provision del tuo peering privato e pubblico verso Azure Cloud nel Megaport Portal. Questa immagine mostra un esempio di configurazione:

Quando più Azure VXC su un MCR popolano lo stesso tag VLAN 100 (peering privato) e lo stesso tag VLAN 200 (peering pubblico), MCR gestisce il tunnel Q-in-Q per ogni Azure VXC che termina sul MCR. Ogni VLAN di Azure è comunque un’interfaccia logica separata.