Q-in-Qの設定

このトピックでは、Q-in-Q802.1Qトンネリング（Q-in-Qまたは802.1adとしても知られる）は、OSIレイヤー2プロバイダーが顧客のために使用する技術です。802.1adは内側および外側タグの両方を提供し、外側のタグ（時にはサービスプロバイダー用のSタグと呼ばれる）を取り除くことで、データをセグメント化する内側のタグ（Cタグまたは顧客）を露出させることができます。
（Azure ExpressRouteなど）を使用するクラウドサービスプロバイダ（CSP）に、オンプレミスのネットワーク機器を接続する方法について説明します。加えて、いくつかのCSPはQ-in-Qが必要ですが、すべてのネットワークデバイスがそれをサポートするわけではないため、このトピックには、ネイティブのQ-in-Qサポートなしで、複数のレイヤVLANタグ処理をネットワークデバイス上で設定する方法も含まれています。

概要

Q-in-Qは、別名802.1adとして知られ、一般的にネットワークサービスプロバイダ（NSP）がレイヤ2の柔軟性を向上させるために使用するプロトコルです。Q-in-Qにより、複数のVLANタグを単一のEthernetフレームに挿入することができます。フレームに複数のVLANタグをスタックすることで、ルーティングドメインの隔離が可能になり、追加タグが顧客トラフィックを識別し分離します。各顧客ごとに異なるVLANタグを使用することで、トラフィックがフレーム内で識別され、サービスプロバイダネットワーク全体を通じて転送されます。

重要

802.1ad標準に基づくVLANタグを区別するために、内側は通常EtherType 0x8100を使用し、外側は0x88a8を使用します。ほとんどのネットワークベンダーのQ-in-Qのデフォルト設定では、内側と外側の両方のEtherTypeが0x8100となっています。Megaportの二重タグ付きフレームの仕様は、内側と外側の両方のタグが0x8100となっています。

Q-in-Qでは、パケットがNSPやキャリアネットワークからクラウド（またはその他の）サービスプロバイダのVLANに移動すると、顧客トラフィックを識別する内側のVLANタグ（C-Tags）がサービスプロバイダが提供する外側のVLANタグ（S-Tags）の中に挿入されます。S-Tagはその中に複数のVLANをカプセル化する単一のVLANを提供します。この構成では、単一のVXCが異なるネットワークのエンドポイント間で複数のVLANタグを運ぶことが可能です。

Q-in-Qの詳細については、VXC を作成して接続するにはおよびMegaportのブログ投稿 Q & A for Q-in-Q: Part 1をご覧ください。 Azure向けのQ-in-Qの設定についての詳細は、Megaportのブログ投稿 Q & A for Q-in-Q: Part 2をご覧ください。

Megaport VXCにおけるQ-in-Qの理解

Virtual Cross Connect (VXC) は、二つのエンドポイント間の点対点レイヤ2回線であり、両端にVLAN IDでマッピングされ、必要に応じて、Megaportネットワーク全体でAエンドとBエンドのVLANタグが独立してマッピングされています。

この画像は、プライベートPeeringとMicrosoft Peeringが有効になっているAzure ExpressRouteを示しています。VXCが顧客エッジとMicrosoftエッジをVLAN 1000（S-Tag）で接続しています。顧客エッジはQ-in-Qをサポートしています。プライベートPeeringはVLAN 100（C-Tag）で実行されており、Microsoft PeeringはVLAN 200（C-Tag）で実行されており、Azureとのレイヤ3接続とBGP Peeringを確立します。

ルータやスイッチがQ-in-Qをサポートしていない場合はどうしますか？

このセクションでは、ネットワーク機器がネイティブにサポートしていない場合でも、Q-in-Qを必要とするB-エンドサービスに接続する方法について説明します。

Q-in-Q代替手段	方法	欠点
単一Azure Peering VLAN	VXCを設定して、MegaportがプライベートPeeringまたはMicrosoft PeeringのB-エンドVLAN IDのいずれかを、顧客向けMegaport-対面VLAN（Aエンド）に再マッピングすることで、Q-in-Qの必要性を除去します。	VXCあたり一つのMicrosoft Peeringタイプのみを使用できます。
顧客ポートに接続されたVXCをアンタグ化	S-Tagを自動的に取り除くために、VXCをアンタグ化として設定します。	VLANをアンタグ化することは、ポートを単一のVXC接続に制限します。この方法を採用すると、ポートは単一のB-エンドターゲットのみを設定できますが、そのピアからの全ての内部/C-Tagsを単一/dot1qタグとして受信します。
Megaport Cloud Routerの展開	Megaport Cloud Router (MCR) を導入して、一方または両方のPeeringタイプのQ-in-Q要件を自動で管理します。	MCRとMCRへの追加VXCの追加コスト。

Microsoft ExpressRouteに接続するVXCは、内側に1つまたは2つのVLANタグを含むことがあります。これらは、Microsoft Azureコンソールで指定されたPeeringタイプに対して設定されるC-Tagsです。このシナリオではQ-in-Qが必須となります。たとえ一つだけのMicrosoftエッジデバイス（プライマリまたはセカンダリ）あるいはPeeringタイプ（プライベートまたはMicrosoft）が使用される場合であってもです。Q-in-Qをサポートするネットワーク機器は、外側のタグ（S-Tag）を剥がすことでこれらの内側タグにアクセスできます。あなたのネットワーク機器がQ-in-Qをサポートしていない場合、内部のタグにアクセスすることができません。

注記

顧客側でのデバイスを介した複数のデバイスでのQ-in-Qフレームのデカプセル化、または複数ポートを異なるVLAN設定で内外部タグにカスケードさせるためのループバックケーブルを使用するなど、他にもQ-in-Qの回避策が存在しますが、これは一般的に本番ネットワークでは推奨されません。

単一Azure Peering VLAN

Microsoft Azure ExpressRoute接続の場合、MegaportはMicrosoft Service Key（および関連するプライマリおよびセカンダリターゲットエンドポイントの選択）を使用し、指定されたAzureのPeeringタイプのためにカプセル化されたC-Tagを抜き出す機能を提供します。この機能は、プライマリまたはセカンダリのターゲットB-エンドポートを選択した後に、新しいExpressRoute接続の接続詳細パネルでConfigure Single Azure Peering VLANを有効にすることで、有効にできます。

ヒント

Single Azure Peering VLANオプションを使用することをお勧めします。このオプションは、完全な機能を提供し、最も簡単な実装を可能にします。Single Azure VLANの場合、Q-in-Q対応機器、MCR、またはアンタグされたポートを必要とせずに、単一のER回線でプライベートまたはMicrosoft Peeringのいずれかを使用できます。ただし、このオプションではVXCあたり一つのPeeringタイプ（プライベートまたはMicrosoft）のみを持つことができるため、両方のPeeringタイプを使用するには、二つのVXCが必要です。

Single Azure VLAN Peering VLAN機能を有効にすると、選択したAzure ExpressRoute設定（Microsoft Azureポータルまたはその他の設定方法経由による）ためのPeeringタイプ設定に（将来のステップで）設定する値と一致する単一のAzure Peering VLANを指定できます。詳細については、チュートリアル: Azureポータルを使用してExpressRoute回線のPeeringを作成および変更するをご覧ください。

Preferred A-End VLAN フィールドを空白のままにすると、注文を行った際にVXC用のランダムなVLANが割り当てられます。そうでない場合はVLANを入力し、使用可能性の確認が実行されます。

この例では、Azure C-tag値200（関連するExpressRoute回線上のプライベートまたはMicrosoft Peeringタイプのいずれか）は、単一タグのVXC VLAN値3001に透過的にマッピングされます。すなわち、物理的なMegaportインターフェイスに接続された顧客デバイスは、Q-in-Qの設定を特に必要とせず、dot1q VLAN 3001は正しくラベル付けされた形で関連するMicrosoft対向のBエンドエッジデバイスに伝送されます。

この構成では、特定のExpressRoute回線で、プライマリおよびセカンダリのMicrosoft ExpressRouteエンドポイントを使用して、単一の顧客側ポート上で異なるVLANタグにマップすることが可能です。これにより、Azure ExpressRouteサービスレベルアグリーメント（SLA）の目的においても適合します。しかし、この構成に関連して単一故障点が存在しないように、単一サイトポートおよびデバイス（ゾーン）での多様性を利用するか、Megaport対応の二つのロケーションにプライマリ/セカンダリExpressRoute接続を分割することを推奨します。

Azure ExpressRoute SLAに関する詳細については、Azure ExpressRouteのSLAをご覧ください。

この方法では、プライマリまたはセカンダリExpressRoute対向VXCをいずれかにわたって一つ以上のPeeringタイプを使用することはできません。このタグ変換はVXCの回線経路毎に一度だけ発生し得るためです。以下のセクションではさらなる回避策が詳述されていますが、単一のExpressRoute回線ペア上での複数のPeeringタイプ間の帯域幅のセグメント化は現在Microsoftによってサポートされていません。ほとんどの場合、この設定目標を達成するために二つのExpressRouteペアを導入することが推奨されます。

注記

以下のセクションでは、Microsoft ExpressRouteの例を元にした回避策について説明していますが、これらの回避策はAzureエンドポイントに限定されるものではなく、B-エンドがQ-in-Qを指定または要求し、単一S-Tag/外部VXC VLAN内で複数のC-Tag/内部VLANを運ぶ必要がある他の接続にも使用できます。顧客シナリオの継続性のためにMicrosoft ExpressRouteの例が使用されています。

VXCをアンタグ化として設定し、自動的にS-Tagを管理

注記

この方法を使用すると、顧客ポートは単一のB-エンドターゲットのみを設定することができ、そのピアからの全ての内部/Cタグを単一/dot1qタグとして受信します。

VXCを設定することで、Megaportが外側VLAN（S-Tag）を削除し、プライベートPeering、Microsoft Peering、またはその両方のための内側VLAN（C-Tag/s）のいずれかまたは両方を顧客ポートに提示します。現在、このプロセスは、プライマリまたはセカンダリポートプレゼンテーションのいずれかから選択して対するExpressRoute回線接続毎のVXC一つのみを許可しますが、両方のPeeringタイプはこのVXCを越えてサポートされ、顧客ポートに対して一つまたは二つのdot1q VLAN（プライベート、Microsoft Peeringのいずれかまたは両方）として提示されます。

重要

顧客ポートは、Aエンド顧客ポートで指定されたPeeringタイプの下でAzureポータルで定義された内部VLANタグを受信します。詳細については、Microsoft Azure ExpressRouteへの接続をご覧ください。

注記

各ExpressRouteサブスクリプションには、選択されたMicrosoftエッジのロケーションで二つのポートターゲットが含まれています。この構成でプライマリおよびセカンダリのExpressRoute回線の両方を受け取るためには、この構成ではMegaportから二つのポートが必要です。Azure VNET VLANタグは両方のポートで同じです。Megaportはプライマリとセカンダリの回線上のVLANタグを変更することができず、同じ物理インタフェースで同じVLANを二度配信することはできません。

注記

Azure ExpressRoute設定でプライベートまたはパブリックPeeringのいずれかのみを設定した場合、ExpressRouteサービスキーに関連付けられたVLANのみが、設定されたVXCで使用可能で、顧客ポートと一対一でマッピングされます。

Megaport Cloud Routerの展開

Megaport Cloud Router (MCR) は、Q-in-Qを含む複数のクラウドの宛先への接続をサポートしているため、多くのクラウド、地域での連携を提供します。S-Tagまたは外部タグは、MCRと関連付けられたAエンドVLANに属しており、内部C-Tagを透過的に運びます。S-Tagは、Megaport Portal でのAzureクラウドへのプライベートおよびパブリックPeeringをプロビジョニングする際に自動的に設定されます。この画像は、例としての設定を示しています：

MCR上の複数のAzure VXCが同じVLAN 100タグ（プライベートPeering）および同じVLAN 200タグ（パブリックPeering）を持つ場合、MCR はMCRに終端するそれぞれのAzure VXCのためにQ-in-Qトンネルを管理します。各Azure VLANは依然として独立した論理インターフェースです。