レイヤ2の現場から見つめる802.1p CoS：パケットが織りなす優先制御の深淵
ネットワークの構築現場に身を置いていると、「なぜかミッションクリティカルなトラフィックに微小なゆらぎ（Jitter）が生じる」「高負荷時にTLSハンドシェイクのレイテンシがスパイクする」といった、教科書通りにいかない現象に幾度となく直面する。L3やL4のチューニングに走りがちだが、すべてのパケットの土台であるイーサネットフレームの足元、すなわちレイヤ2のレイヤーに目を向けなければ、真の極限パフォーマンスは引き出せない。
今回は、L2レイヤーにおけるQoS（Quality of Service）の要である IEEE 802.1p（現在はIEEE 802.1Qの一部に統合）に焦点を当て、8つのトラフィッククラスがスイッチングの現場でどのように扱われ、上位層のトランスポートやTLS、さらにはTCPの挙動にどう影響を与えるのかを、パケットの内部挙動レベルから解き明かしていく。
—
IEEE 802.1pの正体：タグ付きフレームとPCPフィールド
イーサネットフレームの構造を思い出してほしい。通常のアンタグ（Untagged）フレームにIEEE 802.1QのVLANタギングを施すと、源マックアドレスの直前に4バイトの「Qタグ」が挿入される。このQタグの内訳こそが、レイヤ2 QoSの核心だ。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPID (0x8100) |PCP|C| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+この2バイトのTCI（Tag Control Information）フィールドの先頭3ビット、それが PCP（Priority Code Point）、旧称 802.1p である。たった3ビット。表現できる値は 0 から 7 までの8通りに過ぎない。しかし、この3ビットがギガビット／10ギガビットのスイッチ内部のキューイング戦略を完全に支配する。
8つのトラフィッククラス（CoS）の階層構造
IEEE 802.1pでは、この3ビットのPCP値を用いてトラフィックを8つのクラスに分類（CoS: Class of Service）し、それぞれに推奨される用途が定義されている。
- PCP = 1 (BK: Background): バックグラウンド通信。ファイル転送やバッチ処理など、遅延に極めて寛容なトラフィック。
- PCP = 0 (BE: Best Effort): デフォルトのベストエフォート。タグなしパケットは内部的にここにマップされることが多い。
- PCP = 2 (EE: Excellent Effort): 優先度の高いベストエフォート。通常の業務トラフィック等。
- PCP = 3 (CA: Critical Applications): クリティカルデータ。ストリーミングや重要なデータベースの同期など。
- PCP = 4 (VI: Video): 動画ストリーミング。ジッターと遅延の抑制が求められる。
- PCP = 5 (VO: Voice): VoIPやリアルタイム音声。厳格な遅延バジェット（例: 片道10ms以内）が要求される。
- PCP = 6 (IC: Internetwork Control): ネットワーク制御トラフィック（BGP, OSPF等のルーティングプロトコル）。
- PCP = 7 (NC: Network Control): 機器管理・制御（STP, LACP, SNMP等）。絶対にドロップさせてはならない最優先パケット。
現場のアーキテクトとして特筆すべきは、PCP = 6 と 7 は、通常のユーザーデータが侵入してはならない領域であることだ。ここを誤って汎用アプリケーションのトラフィックに割り当てると、輻輳時にルーティングプロトコルのキープアライブがロストし、ネットワーク全体がデッドロックに陥るという致命的な障害を引き起こす。
—
スイッチ内部の挙動：プライオリティキューイングとスケジューリング
L2スイッチのASIC（Application-Specific Integrated Circuit）は、受信したフレームのPCP値を瞬時に読み取り、出力ポートに備えられた複数のハードウェアキュー（通常は4つまたは8つ）にパケットを振り分ける。
ここで重要になるのが、単なるプライオリティキューイング（Strict Priority Queuing: SPQ）の罠だ。最も優先度の高いキュー（例えばPCP 7や6）にパケットが流れ込み続けた場合、低優先度のキュー（PCP 0や1）のパケットが永遠に送信されない「スタベーション（Starvation、飢餓状態）」が発生する。
そのため、現代のエンタープライズスイッチでは、SPQと WFQ（Weighted Fair Queuing） や WRR（Weighted Round Robin） を組み合わせたハイブリッドなスケジューリングが採用される。
[受信ポート]
│
├─► PCP 7, 6 ──► [ Strict Priority Queue ] ──(最優先で処理)──┐
├─► PCP 5 ──► [ WFQ Queue 1 ] ──┐ │
├─► PCP 4 ──► [ WFQ Queue 2 ] ──┼─(帯域を分配)─┼─► [物理回線へ送出]
└─► PCP 0-3 ──► [ WFQ Queue 3 ] ──┘ │インフラエンジニアは、ハードウェアがサポートするキューの数と、PCP値から内部キューへのマッピング（CoS-to-Queue Map）を正しく把握し、設計に落とし込む必要がある。
—
上位層への影響：TLSハンドシェイクとRTTの極限最適化
「たかがレイヤ2の優先制御が、なぜトランスポート層やTLSにまで影響するのか？」と疑問に思うかもしれない。しかし、高負荷なデータセンターやクラウド基幹網において、マイクロ秒単位の遅延は全体のスループットを決定づける。
TLSハンドシェイクとTCPスロースタートの共犯関係セキュアな通信を確立する際、クライアントとサーバーの間でTLSハンドシェイク（Client Hello ➔ Server Hello ➔ Certificate/Key Exchange ➔ Finished）が行われる。このプロセスは、TCPの3ウェイハンドシェイク直後の TCPスロースタートフェーズ と完全に重なる。
もし、このクリティカルなタイミングで、バックグラウンドの巨大なファイル転送（PCP 1）やログ転送が同じ物理リンクを共有し、バッファロータ（Bufferbloat）を引き起こしていたらどうなるか？
TLSのハンドシェイクパケットがスイッチのバッファで数ミリ秒足止めを食らうだけで、TCPのACK返送が遅れ、輻輳ウィンドウ（Congestion Window: cwnd）の拡大が阻害される。結果として、アプリケーションのTimeToFirstByte（TTFB）が目に見えて悪化する。
ここで、TLSハンドシェイクやAPIリクエストのパケットに対して明示的にDSCP（L3）を付与し、それがL2エッジで適切なPCP値（例: PCP 3や5）にマッピングされるようポリシーを組むことで、輻輳時であってもハンドシェイクパケットは優先キューを駆け抜け、RTT（Round Trip Time）のスパイクを最小限に抑えることができるのだ。
—
実践：LinuxカーネルにおけるL2トランスマークとQoS設定
仮想化基盤やコンテナホスト（Linux）上で動作するアプリケーションから送出されるパケットに、意図したPCP値を付与するための実践的な設定を見ていこう。Linuxでは、traffic control (tc) サブシステムと vlan デバイスを組み合わせてこれを実現する。
以下のシェルスクリプトは、特定のソケットやマークを持つパケットに対して、VLANヘッダー内のPCP（skb->priority）をマッピングし、送出する設定の例である。
#!/bin/bash
# ==============================================================================
# Linux ネットワークインターフェースにおける 802.1p (PCP) マッピング設定スクリプト
# 対象インターフェース: eth0, VLAN ID: 10
# ==============================================================================
IFACE="eth0"
VLAN_ID=10
VLAN_IFACE="${IFACE}.${VLAN_ID}"
# 1. 802.1Q VLANインターフェースの作成
ip link add link ${IFACE} name ${VLAN_IFACE} type vlan id ${VLAN_ID}
ip link set dev ${VLAN_IFACE} up
# 2. Linuxカーネルのパケットプライオリティ（skb->priority）と
# 802.1p PCP値の関連付け（ egress 側のマッピング）
# 形式: ip link set dev <dev> egress-qos-map <prio> <pcp>
# 例: Linuxのプライオリティ 5 を VLANの PCP 5 (Voice) にマップする
ip link set dev ${VLAN_IFACE} type vlan egress-qos-map 0:0 5:5 6:6 7:7
# 3. iptables / nftables を用いたアプリケーション層からのパケットマーキング
# 例: 送信元ポートが 443 (HTTPS/TLS) のパケットに Linuxプライオリティ 5 を付与
iptables -t mangle -A OUTPUT -p tcp --dport 443 -j CLASSIFY --set-class 0005:0005
# 設定完了のログ出力
echo "[INFO] VLAN interface ${VLAN_IFACE} configured with 802.1p QoS mapping successfully."この設定により、LinuxカーネルはHTTPS（TLS）の送信パケットを検知して skb->priority = 5 を付与し、VLANヘッダーの構築時にPCP = 5（Voice/Critical class）をハードウェアへ引き渡す。スイッチ側がこのPCPを正しく解釈すれば、エッジからコアまで一貫した優先制御パイプラインが完成する。
—
脆弱性とセキュリティ：QoSを悪用した攻撃の回避策
ネットワークスペシャリストとして、QoS機能が持つダークサイドにも言及しておかねばならない。IEEE 802.1pのPCPフィールドやL3のDSCPは、悪意ある攻撃者にとっても格好の標的になり得る。
1. 優先度詐称（Priority Spoofing）の脅威
アクセスレイヤのスイッチポートにおいて、エンドユーザーや信頼できないホスト（ゲストWi-Fi、テナント間の接続ポートなど）からのトラフィックに無条件で高いPCP値（PCP 6や7）を許可してはならない。
攻撃者がすべての不正トラフィックにPCP = 7（Network Control）を付与して送信した場合、スイッチはそれを最優先で処理し、正当なルーティングプロトコルや管理トラフィックが圧迫されてサービス停止（DoS）に追い込まれる。
【対策】
エッジスイッチのポート設定では、原則として信頼境界（Trust Boundary）を厳格に定義すること。エンドポイントに接続するポートでは、受信したPCP/DSCPを強制的に 0 に書き換える（Trust-None または Explicit Remarking）設定を徹底する。
# Cisco IOS/IOS-XE でのエッジポートにおけるQoS信頼境界の設定例
interface GigabitEthernet0/1
description Untrusted Edge Port for Client Devices
switchport mode access
switchport access vlan 100
# 受信したすべてのQoSマーキングを信頼せず、デフォルト（BE: 0）にリセットする
no mls qos trust2. キューの枯渇を狙ったDDoSへの備え
高優先度キューの帯域制限（Policing / Rate Limiting）を怠ると、PCP = 5などのリアルタイムキューを標的にしたフラッド攻撃を受けた際、音声や制御トラフィックだけでなく、ネットワーク全体の健全性が完全に奪われる。ハードウェアレベルでのポリサー設定は、L2 QoS運用における必須の安全装置である。
—
結びにかえて：パケットの「意志」をデザインする
IEEE 802.1p CoSという、たった3ビットの小さな領域。しかし、この小さなビット列に込められた設計思想を理解し、Linuxカーネルのパケット処理からスイッチのハードウェアキューイング、そして上位のTLSやTCPの挙動までを一本の線として繋げられたとき、ネットワークは単なる「データパイプ」から「意思を持ったインフラ」へと昇華する。
教科書の定義をなぞるだけでは見えてこない、パケットの微細な息遣いを感じ取りながら、現場で牙を向く複雑なトラフィックの波を美しく制御し続けること――それこそが、我々インフラアーキテクトの矜持に他ならない。
コメント