Q-in-Qの深淵：プロバイダー網を透過するイーサネットフレームの「二重の深層」
ネットワークの現場において、VLAN（IEEE 802.1Q）はもはや空気のような存在だ。しかし、その「空気」がISP（通信事業者）のバックボーンという巨大な真空へと解き放たれるとき、我々は「VLAN IDの枯渇」という現実的な壁に直面する。この絶望的な制約を打破し、顧客のL2ドメインを保護したまま広域イーサネットを構築する――そのための切り札が、IEEE 802.1ad、通称「Q-in-Q（VLAN Stacking）」である。
今回は、単なる「タグを二重にする技術」という表面的な理解を超え、パケットの内部挙動、MTUの攻防、そして極限のパフォーマンスを引き出すためのインフラ設計思想について深掘りしていく。
—
1. カプセル化の解剖学：スタックされたヘッダーの真実
Q-in-Qの基本原理はシンプルだ。顧客の持つ 802.1Q タグ（C-TAG）を、プロバイダーが付与する 802.1ad タグ（S-TAG）で包み込む。これにより、パケットはプロバイダー網内を「S-VLAN ID」という巨大な識別子によってルーティングされる。
ここで重要なのは、EtherTypeの変化である。従来の 0x8100 が 0x88a8（S-TAG）へと書き換わることで、スイッチのASICは「これはサービスプロバイダーの制御下にあるフレームだ」と即座に判断する。
パケットの構造（物理層からの視点）
[Ethernet Header] + [S-TAG (0x88a8)] + [C-TAG (0x8100)] + [Payload]この「タグの多重化」が発生した瞬間、ネットワークエンジニアが直面するのが MTU（Maximum Transmission Unit）問題 だ。4バイトのタグが余分に付加されることで、フレームサイズは最低でも4バイト、実運用上はバッファの整合性を考慮してさらに大きなオーバーヘッドを考慮しなければならない。
—
2. パフォーマンスのボトルネックとTCPチューニング
Q-in-Q環境下では、MTU不足による断片化やドロップが、TCPのスループットを劇的に低下させる。特に、クラウド間を跨ぐバックボーンでは、MSS（Maximum Segment Size）の適正化が不可欠だ。
推奨するMSSクランプの設定（Cisco IOS-XE等の例）
物理インターフェースでQ-in-Qを終端する場合、1500 バイトのパケットを通すために、少なくとも 1504 バイト以上のMTUを許可する必要がある。
# インターフェース単位でのMTU拡張
interface GigabitEthernet0/0/1
mtu 9216 # ジャンボフレームを考慮し、余裕を持って設定
# TCPセッションに対するMSSクランプの設定（SYNパケットを書き換える）
ip tcp adjust-mss 1456
# 1500 - 20(IP) - 20(TCP) - 4(C-TAG) - 4(S-TAG) = 1452程度が安全圏もし、あなたがハイパフォーマンスなデータ転送を維持したいのであれば、TCP Window Scaling と合わせて、カーネルレベルでの tcp_rmem / tcp_wmem のチューニングも推奨する。広域イーサネットの長いRTT（Round Trip Time）では、BDP（Bandwidth Delay Product）を満たすための巨大なバッファが不可欠だからだ。
—
3. セキュリティの陥陷：VLANホッピングとタグ操作の脆弱性
Q-in-Q環境で最も警戒すべきは、タグ・マニピュレーションによる攻撃である。悪意のあるエンドユーザーが、自前で二重タグを付与したフレームを送信し、プロバイダー網のS-TAGを偽装して他のユーザーのVLANへ侵入しようとするケースだ。
防御の鉄則
1. TPIDの厳格な管理: 0x8100 以外のタグを許可しない、あるいは許可するタグを特定のポートにのみ限定する。
2. Untrustedポートの制御: 顧客接続ポート（UNI）では、受信したフレームに必ず S-TAG を強制的に付与し、かつ顧客が送信してくる S-TAG をすべて剥ぎ取る（あるいはドロップする）設定を徹底せよ。
# Juniper Junosでの設定例：顧客ポートの信頼境界構築
set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 100
# 顧客がタグ付きフレームを送ってきたら即時破棄するポリシーを適用—
4. プロトコルスタックの最適化：TLSハンドシェイクの視点
Q-in-Q環境を流れるトラフィックの大部分はTLS化されている。もし、パケットロスがわずかでも発生すれば、TCP Retransmission が発生し、TLSの Client Hello から Finished までのハンドシェイク時間が指数関数的に増大する。
インフラアーキテクトとして意識すべきは、「Q-in-Qの導入によってパスの安定性がどう変化するか」だ。レイテンシの揺らぎ（ジッタ）は、TLS 1.3の 0-RTT 接続において、リプレイアタックの防御ロジックを複雑化させる可能性がある。
- RTT削減のTips: 可能な限り同一プロバイダー内でのパスを最短化するよう、
LACPではなく、より高度なレイヤ3ルーティング（IS-ISやOSPF）を用いたトラフィックエンジニアリングを組み合わせるべきである。
—
結びに：物理と論理の境界を見極める
Q-in-Qは、イーサネットという枯れた技術の中に、いまだ広がる可能性を示唆している。しかし、それは魔法ではない。MTUの微調整、タグの適切なフィルタリング、そしてパケットが流れる物理配線の素性を見極めるという、極めて泥臭い作業の積み重ねの上に成り立つ「秩序」である。
ネットワークの深淵を覗くとき、そこには常に「パケットは何を語っているか」という問いがある。タグが重なり、スタックが深くなっても、その中にあるペイロードは誠実だ。我々の仕事は、その誠実なデータが誰にも邪魔されず、意図した場所へ最速で届くための「道」を整備することに他ならない。
次にあなたが tcpdump を叩くとき、-e オプションをつけて二重のタグを確認してみてほしい。そこには、インフラエンジニアだけが見ることのできる、美しい階層構造が広がっているはずだ。
コメント