ネットワークの「静寂」を操る：IEEE 802.3az (EEE) が現場にもたらす光と影
ネットワークエンジニアとして現場に立っていると、ふと「パケットが流れていない瞬間のポートはどうなっているのか」と考えたことはないだろうか。
かつての10BASE-Tや100BASE-TXの時代、リンクは「常に何かを送り続ける」ことで回線を維持していた。しかし、昨今の高密度スイッチやデータセンターにおいて、全ポートが24時間365日フル稼働していることは稀だ。そこで登場したのが、IEEE 802.3az、通称 EEE (Energy Efficient Ethernet) である。
今日は、この「省電力」という美名に隠された、ネットワーク運用の現場における「深淵」について話をしよう。
—
EEE (802.3az) の本質：Low Power Idle (LPI) のメカニズム
EEEの核となる概念は LPI (Low Power Idle) だ。簡単に言えば、データの送信がない「隙間」を検知して、物理層（PHY）の動作を一時的に停止（スリープ）させる技術である。
通信フロー（シーケンス）のリアル
1. 通常稼働: データフレームを高速で送受信している状態。
2. LPI要求: 送信データが途切れると、送信側は「もう送るものがないよ」という合図として LPI シンボルを相手に送りつける。
3. 静寂期間 (Sleep): 両端のPHYが電力を落とす。この間、電気信号はほぼ停止する。
4. ウェイクアップ (Refresh/Wake): 新たなデータがバッファに到着すると、送信側は Wake 信号を送り、相手のPHYを叩き起こす。
5. 復帰: PHYが正常な動作状態（Active）に戻り、待機していたデータを送信する。
ここで注意すべきは、この「起こす」プロセスには必ず数マイクロ秒のレイテンシ（Wake-up time）が発生するということだ。この「一瞬の遅延」が、我々インフラ屋を悩ませるトラブルの種になることがある。
—
現場で遭遇する「EEEの罠」
理論上は素晴らしい技術だが、実務においてEEEは時として「気まぐれなトラブルメーカー」に変貌する。
- ジッターの増大: リアルタイム性が求められる音声パケット（VoIP）や、高精度な時刻同期（PTP）を行っている環境では、LPIからの復帰に伴う微細な遅延がパケットロスやジッターとして観測される。
- ネゴシエーションの失敗: 特定のNICとスイッチの相性問題で、LPIの遷移に失敗し、リンクがフラップ（Up/Downを繰り返す）することがある。
もし、Web APIのレスポンスタイムが「数ミリ秒単位で不定期に跳ね上がる」ような事象に悩まされたら、まずはスタック内のスイッチでEEEが無効化されているかを確認することをお勧めする。
—
設定と確認の実践
ここでは、一般的なエンタープライズスイッチ（Cisco Catalyst系を想定）での確認・設定例を紹介する。
1. 現状のEEEステータス確認
まずは現在のインターフェース設定を確認する。
# インターフェースのEEE状態を表示するコマンド
show power inline eee
# または、インターフェース詳細を確認
show interface gigabitEthernet 1/0/1 status2. EEEの無効化（トラブルシューティング時）
もしEEEが原因で通信断やパフォーマンス低下が疑われる場合、以下の設定で無効化する。
# コンフィグモードへ移行
configure terminal
interface gigabitEthernet 1/0/1
# EEEネゴシエーションをオフにする
no power efficient-ethernet
# 設定を抜けて保存
end
write memory3. Pythonによる監視のヒント
ネットワーク機器から SNMP や Netconf/Restconf を使ってEEEの状態を定期取得し、異常なリンクフラップがないか監視するスクリプトを組むのも良いだろう。
import netsnmp
# SNMPでEEEのステータスを取得する簡易的なイメージ
def check_eee_status(host, port_oid):
# OIDはメーカーのMIBリファレンスを参照
res = netsnmp.snmpget(netsnmp.Varbind(port_oid), DestHost=host, Version=2)
return res
# 運用時は「EEEが有効かつリンクフラップが頻発しているポート」を抽出する
# ロジックを組み込むと自動化が捗る—
まとめ：エンジニアとしてどう向き合うか
EEEは、データセンターの電力消費を劇的に改善する素晴らしい技術だ。しかし、ネットワークの「一瞬の静寂」を管理するということは、それだけプロトコルの挙動にシビアになる必要があるということでもある。
「デフォルト設定だから」と盲信せず、そのポートで流れるトラフィックの性質（低遅延が必須か、バースト性が高いか）を見極め、EEEを有効にするか否かを判断する。 それが、真に信頼されるインフラアーキテクトの矜持ではないだろうか。
もし、あなたが次回のメンテナンスでスイッチの設定を触る機会があれば、一度 show power efficient-ethernet を叩いてみてほしい。そのポートが、どんな「呼吸」をしているのかが見えてくるはずだ。
コメント