【実務・中級編】 DEI（Drop Eligible Indicator）フィールドの機能と輻輳制御 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

ネットワークの嵐を乗りこなせ！DEI（Drop Eligible Indicator）が拓く賢い輻輳制御の極意

やあ、諸君。今日もネットワークの深淵を覗きに来たかい？
Web APIを設計する君も、日夜インフラの番人としてサーバーを監視する君も、いつか必ず直面する「ネットワークの混雑」という名の嵐。この嵐をどう乗り切り、サービスの安定性を保つか。その鍵の一つが、今回深く掘り下げるDEI（Drop Eligible Indicator）という、たった1ビットのフィールドだ。

「たかが1ビット」と侮るなかれ。この1ビットが、輻輳時のネットワークの挙動を劇的に変え、サービスの品質を左右する。今日は、このDEIがどのような役割を果たし、どのように活用できるのかを、RFCの仕様から現場の泥臭い設定、そしてトラブルシューティングのヒントまで、徹底的に解説していこう。

1. ネットワークの航海士たる君へ：なぜDEIを知る必要があるのか

ネットワークは常にベストエフォートだ。つまり「頑張りますが、保証はできません」という建前の上で動いている。しかし、現実にはVoIPのようにミリ秒単位の遅延も許されないクリティカルなトラフィックもあれば、大容量ファイル転送のように多少の遅延や再送は許容できるトラフィックもある。

サービスを安定稼働させるためには、これらのトラフィックを賢く捌き、いざという時の「パケットドロップ」を最適化する必要がある。ここで登場するのが、IEEE 802.1QのVLANタグヘッダにこっそり隠れているDEIフィールドだ。

私はこれまで数々のネットワーク障害と戦ってきたが、その多くの原因は、輻輳に対する準備不足、あるいはQoS（Quality of Service）の不適切な設定にあった。DEIは、まさにそのQoS戦略の中核をなす要素の一つなんだ。

2. DEIとは何か？VLANタグに秘められた1ビットの意思表示

DEIは、IEEE 802.1Qで定義されるVLANタグヘッダの一部だ。以前はCFI（Canonical Format Indicator）という名前で、イーサネットフレームのフォーマット互換性を示すために使われていたが、現代のネットワークではほとんど使われなくなった。そこで、IEEE 802.1Q-2005でその役割がDEIへと変更され、輻輳制御のための重要なシグナルとして生まれ変わったんだ。

VLANタグヘッダの構造を見てみよう。

| フィールド名 | サイズ (ビット) | 説明 |
|——————–|—————–|————————————————————————-|
| TPID (Tag Protocol Identifier) | 16 | VLANタグであることを示す。通常 0x8100。 |
| TCI (Tag Control Information) | 16 | PCP、DEI、VID を含む。 |
| – PCP (Priority Code Point) | 3 | 802.1p プライオリティ。0-7までの優先度。 |
| – DEI (Drop Eligible Indicator) | 1 | ドロップ可否インジケータ。 |
| – VID (VLAN ID) | 12 | VLAN識別子。0-4095までのVLAN ID。 |

見ての通り、DEIはPCP（プライオリティ）とVID（VLAN ID）に挟まれて、たった1ビットを占めている。この1ビットが持つ意味はシンプルだ。

  • DEI = 0: このフレームは ドロップを許容しない （優先的に転送すべき）
  • DEI = 1: このフレームは ドロップを許容する （輻輳時には優先的に破棄対象となる）

この「ドロップを許容する」という意思表示は、ネットワーク機器が輻輳状態に陥った際に、どのパケットから捨て始めるかの判断材料として使われる。まさに、ネットワークが過負荷になった時に「この荷物は捨ててもいいよ」とあらかじめ伝えておくようなものだ。

3. DEIが拓く輻輳制御のメカニズム：賢いパケットドロップ

ネットワーク機器、特にスイッチやルータは、トラフィックが処理能力を超えると、一時的にパケットをキュー（バッファ）に貯め込む。しかし、キューにも限界がある。キューが満杯になると、それ以上新しいパケットを受け入れられなくなり、やむを得ずパケットをドロップし始める。これが「輻輳」だ。

DEIは、この「どのパケットをドロップするか」という判断を、よりインテリジェントに行うためのシグナルとなる。

3.1. PCPとDEIの連携

PCP（Priority Code Point）は802.1pプライオリティとも呼ばれ、フレームの優先度を8段階（0-7）で示す。一般的に、数字が大きいほど優先度が高い。例えば、VoIPは最高のプライオリティ（6や7）が割り当てられることが多い。

DEIは、このPCPと組み合わせて使われる。

  • 高優先度トラフィック（例: VoIP）: PCPを高く設定し、DEI=0とする。これにより、輻輳時でも極力ドロップされずに転送される。
  • 低優先度トラフィック（例: バックアップデータ）: PCPを低く設定し、DEI=1とする。輻輳時には、これらのパケットが優先的にドロップされる候補となる。
  • 通常のビジネストラフィック: PCPを中程度に設定し、DEI=0とする。高優先度ではないが、ドロップも極力避けたい。
  • 優先度はあるが、ドロップは許容できるトラフィック: PCPを中程度に設定し、DEI=1とする。例えば、Web閲覧など、再送でリカバリできるが、ある程度の体感速度は維持したい場合。

この組み合わせにより、ネットワーク機器は単に優先度だけでなく、「この優先度の中で、さらにドロップしてもいいもの」というきめ細かい制御が可能になるわけだ。

3.2. WRED（Weighted Random Early Detection）との協調

多くのエンタープライズやキャリアグレードのネットワーク機器では、RED（Random Early Detection）やその発展形であるWRED（Weighted Random Early Detection）のような輻輳回避アルゴリズムが採用されている。

WREDは、キューが満杯になる前に、ランダムにパケットをドロップし始めることで、TCPの輻輳制御メカニズムを起動させ、ネットワーク全体の輻輳を緩和しようとする。

DEIは、このWREDのドロップ判断に影響を与えることができる。例えば、WREDは通常、キューの深さに基づいてドロップ確率を調整するが、DEI=1のパケットに対しては、DEI=0のパケットよりも低いキュー閾値でドロップを開始したり、より高い確率でドロップしたりするように設定できる。

これにより、高優先度かつドロップ不許可なトラフィックを守りつつ、ネットワーク全体の安定性を維持することが可能になる。

4. DEIの具体的な活用シーンと実務での考慮点

DEIは、特にトラフィックの種類が多様で、かつQoSが求められる環境でその真価を発揮する。

4.1. データセンターネットワーク

データセンターでは、ストレージトラフィック（例: iSCSI、FCoE）、VM間通信、アプリケーションサーバー間のAPI通信、そして管理トラフィックなど、様々な種類のトラフィックが混在する。
ここでDEIは、例えば以下のように活用される。

  • ストレージトラフィック: PCPを高く、DEI=0。データロスは許されないため。
  • API通信: PCPを中程度、DEI=0。アプリケーションの応答速度に直結するため。
  • バックアップトラフィック: PCPを低く、DEI=1。多少の遅延や再送は許容されるため。

これにより、輻輳時でも基幹業務に影響を与えずに、効率的なリソース利用が可能になる。

4.2. キャリアネットワークとブロードキャスト

キャリアネットワークでは、顧客ごとにSLA（Service Level Agreement）が異なるため、QoSは必須だ。また、IPTVのようなマルチキャストストリームでは、リアルタイム性が求められる一方で、一部のパケットロスは許容できる場合もある。

  • IPTVの主要ストリーム: PCPを高く、DEI=0。
  • IPTVの補助ストリームや低画質ストリーム: PCPを中程度、DEI=1。
  • ベストエフォートなインターネットトラフィック: PCPを低く、DEI=1。

4.3. VoIPやビデオ会議

これらは非常に遅延に敏感なトラフィックだ。

  • 音声パケット: PCPを最高（通常6または7）、DEI=0。
  • ビデオパケット: PCPを音声より一段低く（通常5）、DEI=0。
  • データ共有やチャット: PCPをさらに低く、DEI=1。

このように、アプリケーションの特性に応じてPCPとDEIを適切にマーキングすることで、ユーザー体験の向上に直結する。

5. 実践！DEIを意識したネットワーク設定と監視

では、具体的にどのようにDEIを設定し、確認するのか。ここでは代表的なネットワーク機器の設定例と、Linuxでの確認方法を示す。

5.1. ネットワーク機器（Cisco IOS）での設定例

Cisco IOSでは、policy-mapとclass-mapを使ってトラフィックを分類し、set deiコマンドでDEI値を設定する。

! トラフィック分類の定義
class-map match-any CRITICAL_TRAFFIC
 match dscp ef             ! DSCP EF (Expedited Forwarding) を持つトラフィック
 match cos 5               ! CoS値が5のトラフィック (PCP=5)
!
class-map match-any BULK_TRAFFIC
 match dscp af11           ! DSCP AF11 (Assured Forwarding Class 1 Low Drop) を持つトラフィック
 match cos 1               ! CoS値が1のトラフィック (PCP=1)
!
! QoSポリシーの定義
policy-map QOS_POLICY_OUT
 class CRITICAL_TRAFFIC
  priority level 1         ! 高優先度キューに入れる
  set dei 0                ! DEIを0に設定（ドロップ不可）
  bandwidth percent 30     ! 帯域保証
 class BULK_TRAFFIC
  bandwidth percent 10     ! 帯域保証
  set dei 1                ! DEIを1に設定（ドロップ可能）
 class class-default
  fair-queue               ! 残りのトラフィックは公平にキューイング
  set dei 1                ! デフォルトではDEIを1に設定（輻輳時は破棄候補）

! インターフェースへの適用
interface GigabitEthernet0/1
 service-policy output QOS_POLICY_OUT
!

解説:

  • class-mapでDSCP値やCoS（PCP）値に基づいてトラフィックを分類します。
  • policy-map内で、分類されたトラフィックに対してアクションを定義します。
  • set dei 0でDEIを0（ドロップ不可）、set dei 1でDEIを1（ドロップ可能）に設定します。
  • priority levelで優先キューへの投入、bandwidth percentで帯域保証も行い、より詳細なQoS制御を実現します。
  • class-defaultで、明示的に分類されなかったトラフィックに対するデフォルトのDEI値を設定することが重要です。

5.2. LinuxでのVLANタグ付きパケットの確認（tcpdump/Wireshark）

DEIはネットワーク機器で設定される値なので、アプリケーションやOSから直接操作することはできない。しかし、tcpdumpやWiresharkを使えば、実際にネットワークを流れるパケットのDEI値を確認できる。

# tcpdumpでVLANタグ付きパケットをキャプチャし、詳細を表示
# `-i <interface>`: キャプチャするインターフェースを指定
# `-vvv`: 詳細表示レベルを上げる
# `-e`: イーサネットヘッダを表示
# `'vlan'`：VLANタグ付きパケットのみをフィルタリング
sudo tcpdump -i eth0 -vvv -e 'vlan'

このコマンドを実行すると、以下のような出力が得られるはずだ。

20:01:23.456789 00:0c:29:12:34:56 > 00:0c:29:ab:cd:ef, ethertype 802.1Q (0x8100), length 74: vlan 100, p 7, dei 1, id 100, IP <source_ip>.<source_port> > <dest_ip>.<dest_port>: Flags [S], seq ...

解説:

  • vlan 100: VLAN IDが100である。
  • p 7: PCP（Priority Code Point）が7である。これは最高優先度を示す。
  • dei 1: DEIが1に設定されている。このパケットは輻輳時にドロップ可能であることを示唆している。

Wiresharkでキャプチャした場合は、VLANタグヘッダを展開するとDEIフィールドが明確に表示される。実際にネットワークを流れるパケットのDEI値を確認することは、QoS設定が正しく機能しているかを検証する上で不可欠だ。

5.3. アプリケーション層でのDEIの意識（Fetch API, Python等）

Web API設計者やアプリケーション開発者にとって、直接DEIを操作するAPIは存在しない。DEIはL2のVLANタグの一部であり、OSのネットワークスタックやNICドライバ、そしてネットワーク機器によって設定・処理されるものだからだ。

しかし、アプリケーションがネットワークのQoSを意識した設計をすることは可能だ。
例えば、以下のようなアプローチが考えられる。

  • DSCP値の利用: DEIではなく、L3ヘッダのDSCP（Differentiated Services Code Point）を利用する。多くのOSでは、ソケットオプションでDSCP値を設定できる。ネットワーク機器はDSCP値に基づいてPCPやDEIをマッピングする設定が可能だ。
  • Pythonの例 (DSCP設定のヒント):
import socket

    # DSCP値の設定例 (EF: Expedited Forwarding, 46)
    # ソケットタイプとプロトコルに応じて適宜変更
    DSCP_EF = 46 << 2 # DSCP値は6ビットなので、TOSフィールドの適切な位置にシフト

    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        # LinuxではIP_TOSオプションでDSCPを設定可能
        # WindowsやmacOSでは異なる方法が必要な場合がある
        s.setsockopt(socket.IPPROTO_IP, socket.IP_TOS, DSCP_EF)
        s.connect(('example.com', 80))
        s.sendall(b"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n")
        response = s.recv(4096)
        print(response.decode())
    except Exception as e:
        print(f"エラーが発生しました: {e}")
    finally:
        if 's' in locals():
            s.close()

解説:

  • socket.IP_TOSオプションを使って、IPヘッダのType of Serviceフィールド、実質的にはDSCP値を設定する試みです。
  • この設定はOSやネットワークスタックのポリシーに依存し、必ずしもネットワーク機器のQoS設定に直接マッピングされるとは限りません。
  • ただし、ネットワーク管理者がDSCPに基づいてL2のPCP/DEIをマーキングするポリシーを設定していれば、アプリケーションから間接的にQoSに影響を与えることができます。
  • 輻輳発生時の自律的な振る舞い:
  • APIクライアントがネットワーク遅延やエラーを検知した場合、優先度の低いAPIリクエスト（例: 分析データの送信、ログアップロード）の送信レートを自動的に下げる。
  • リアルタイム性の高いAPI（例: チャット、ゲーム）は優先的に処理し、それ以外のAPIはバックオフ戦略を適用する。
  • Webhookなどでのイベント通知において、重要度に応じて再送回数やタイムアウトを設定する。重要度の低いものは早めに諦める。

これは直接DEIを設定するわけではないが、アプリケーションがネットワークの輻輳状況を「察知」し、自律的に協調動作することで、ネットワーク全体の負荷を軽減し、結果的にDEIによって守られた高優先度トラフィックの安定性を向上させることに繋がる。

6. DEIに関するトラブルシューティングのヒント

「サービスが遅い」「パケットロスが頻発する」そんな時、DEIが絡んでいる可能性も考慮に入れよう。

6.1. ネットワーク機器でのドロップカウンタ確認

まず疑うべきは、ネットワーク機器のインターフェースでパケットがドロップされていないかだ。

# Cisco IOSでのインターフェース統計情報表示
show interface GigabitEthernet0/1

# 出力例 (抜粋)
  Input queue: 0/75 (0 elements, 0 bytes)
  Output queue: 0/40 (0 elements, 0 bytes)
  ...
  Queueing strategy: fifo
  Output drops: 1234, output flushes: 0
  ...

Output dropsが増加している場合、キューイングポリシーやQoS設定が適切でない可能性がある。
特定のQoSポリシーが適用されているインターフェースでは、以下のコマンドで詳細な統計情報を確認できる。

# QoSポリシーの統計情報表示
show policy-map interface GigabitEthernet0/1 output

# 出力例 (抜粋)
 Service-policy output: QOS_POLICY_OUT

  Class-map: CRITICAL_TRAFFIC (match-any)
    ...
    Queueing
      Packets output 1000000, Bytes output 1000000000
      (Total drops 0)  <-- ここが重要！
      (Tail drops 0)
      (Random drops 0)

  Class-map: BULK_TRAFFIC (match-any)
    ...
    Queueing
      Packets output 500000, Bytes output 500000000
      (Total drops 5000) <-- BULK_TRAFFICでドロップが発生している
      (Tail drops 0)
      (Random drops 5000)

解説:

  • Total dropsのカウンタを確認する。特にDEI=1に設定したクラスでドロップが増加している場合、それは輻輳制御が意図通りに機能している証拠とも言える。
  • ただし、DEI=0に設定したクラスでドロップが発生している場合は、QoS設定が不十分か、ネットワーク全体の帯域が決定的に不足している可能性が高い。その場合は、帯域増強や、より厳密なトラフィックシェーピングが必要となるだろう。

6.2. tcpdump / Wiresharkでのパケット分析

実際にドロップされたと考えられるパケットと、転送されたパケットのPCPとDEIを比較してみよう。
tcpdumpやWiresharkでキャプチャしたパケットを分析し、意図しないDEI値が付与されていないか、あるいは高優先度であるべきトラフィックにDEI=1が設定されていないかを確認する。

もし高優先度トラフィック（例: VoIP）のパケットにdei 1と表示されていたら、それはQoS設定の誤りであり、輻輳時にそのトラフィックが不当にドロップされる危険性がある。

7. まとめ：DEIを理解し、賢いネットワーク設計を

DEIは、たった1ビットのシンプルな情報だが、その影響力は計り知れない。輻輳という避けられない現実の中で、どのトラフィックを「守り」、どのトラフィックを「犠牲にするか」をネットワークに明確に指示するための、極めて強力なツールだ。

Web APIの設計者も、インフラの運用者も、このDEIの存在とその機能、そしてそれがどのようにネットワーク機器で処理されるかを理解しておくことは、より堅牢で安定したサービスを提供するために不可欠だ。

ネットワークは生き物だ。常に変動し、時には予期せぬ混雑に見舞われる。だが、DEIのような賢いメカニズムを使いこなすことで、我々はただ嵐に翻弄されるだけでなく、その嵐を乗りこなし、目的地へと確実にサービスを届け続けることができる。

さあ、今日から君のネットワーク設計と運用に、このDEIの概念を取り入れて、一歩先の堅牢性を手に入れよう！
現場からは以上だ。また次の深淵で会おう！

スポンサーリンク

コメント

タイトルとURLをコピーしました