ネットワークの「格付け」を制御せよ:PCPとDSCPの相互連携で実現するQoSの極意
ネットワークエンジニアの皆さん、こんにちは。現場でパケットを追いかけていると、「なぜか特定のトラフィックだけ遅延する」「VoIPの音質がWeb会議中に劣化する」といった問題に突き当たることがありますよね。その原因の多くは、帯域幅の不足ではなく、スイッチやルーターの「優先順位付け(QoS)」の不整合にあります。
今回は、レイヤ2の PCP(Priority Code Point)と、レイヤ3の DSCP(Differentiated Services Code Point)という、QoSの二大巨頭をどう橋渡しすべきか、実務的な視点で深掘りしていきます。
—
1. なぜ「格付け」の変換が必要なのか?
まず前提を整理しましょう。PCP はIEEE 802.1Qタグ内に存在する3ビットのフィールドで、L2スイッチングの世界で優先度を表現します。対して DSCP はIPヘッダーのTOS(Type of Service)フィールドを再定義した6ビットの値で、ルーターを越えたL3エンドツーエンドの品質保証を担います。
「なぜ両方必要なのか?」 という疑問に対する答えはシンプルです。ネットワークはL2のドメイン(スイッチ)とL3のドメイン(ルーター)で構成されており、パケットが境界を越えるたびに、この優先順位情報を「翻訳」してあげないと、QoSポリシーが途中で途切れてしまうからです。
—
2. PCPからDSCPへのマッピング:標準的な作法
IEEE 802.1pに基づき、一般的に以下のようなマッピングが推奨されます。これを「信頼境界(Trust Boundary)」で設定しておくことが、安定したトラフィック制御の第一歩です。
| PCP値 | トラフィッククラス | 推奨DSCP値 |
| :— | :— | :— |
| 7 | Network Control | CS7 (56) |
| 5 | Voice | EF (46) |
| 4 | Video | AF41 (34) |
| 0 | Best Effort | BE (0) |
—
3. 実装の現場:Cisco IOSでのマッピング設定例
現場でよく遭遇する、L2スイッチが受信した PCP 値を DSCP に変換(再マーキング)する設定例を見てみましょう。
! クラスマップでPCP 5 (Voice) をマッチング
class-map match-any VOICE-TRAFFIC
match cos 5
! ポリシーマップでDSCP EF (46) に書き換える
policy-map QOS-MAPPING-POLICY
class VOICE-TRAFFIC
set dscp ef
! インターフェースに適用
interface GigabitEthernet0/1
service-policy input QOS-MAPPING-POLICY
ここで重要なのは、set dscp ef が実行される瞬間、パケットのIPヘッダーが書き換わるだけでなく、内部的な優先度キューの割り当てが即座に変更されるという点です。設定後の show policy-map interface で、パケットが正しく分類(Match)されているかを確認するのを忘れないでください。
—
4. アプリケーション層からのアプローチ
インフラエンジニアとして、時として開発チームに「DSCP値を指定してパケットを投げてくれ」と依頼することもあるでしょう。Pythonの socket を使用すれば、アプリケーション側から DSCP を指定して送信することが可能です。
import socket
# ソケットを作成
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# DSCP EF (46) をセットする(IP_TOSオプションを使用)
# 46 << 2 = 184 (上位6ビットを有効化するため)
dscp_value = 46 << 2
s.setsockopt(socket.IPPROTO_IP, socket.IP_TOS, dscp_value)
# 送信
s.sendto(b"Voice Data Payload", ("192.168.1.100", 5060))
s.close()
このように、エンドデバイスが適切にマーキングを行うことで、ネットワーク機器は「このパケットは重要だ」と即座に判断し、混雑時でも優先的に転送(Priority Queuing)できるようになります。
—
5. トラブルシューティングの鉄則
最後に、現場でこの設定を行う際の「ハマりどころ」を共有します。
1. Trust設定の確認: スイッチのポートで mls qos trust dscp や trust cos を設定していないと、受信したタグやTOSフィールドはすべて無視され、デフォルトの優先度(通常は0)にリセットされます。
2. ヘッダーの書き換えによるMTU問題: 一部の古いトンネリング環境では、DSCPマーキングによってヘッダーが書き換わった結果、微妙にパケットサイズが変わりフラグメンテーションが発生することがあります。
3. パケットキャプチャの落とし穴: Wiresharkで確認する際、OSのネットワークスタックが送信時に DSCP 値をクリアしてしまうことがあります。必ず物理的なタップデバイスやスイッチのミラーポートを使って、ワイヤー上のパケットを確認してください。
QoS設定は、一度組んでしまえば終わりではありません。アプリケーションのトラフィックパターンが変われば、それに合わせてマッピング表を見直す必要があります。
皆さんのネットワークが、今日も滞りなく、最適な優先度でパケットを届けてくれることを願っています。何かトラブルがあれば、まずは show コマンドでパケットのカウンタがどこで止まっているかを確認することから始めましょう。それでは、良いエンジニアリングライフを!
コメント