現場で語る「PoE+（802.3at）」の裏側：電力ネゴシエーションの深淵
ネットワークエンジニアの皆さん、こんにちは。現場で「APが再起動を繰り返す」「カメラの映像が夜間だけ落ちる」というトラブルに遭遇したことはありませんか？
多くの場合、犯人は「電力不足」です。L2スイッチからLANケーブル一本で電力を送るPoE（Power over Ethernet）。今日はその中でも、現代のインフラのスタンダードである IEEE 802.3at（いわゆるPoE+）の電力クラス分類と、その裏で行われている静かなる会話について、泥臭い経験を交えて紐解いていきましょう。
—
1. なぜ「ネゴシエーション」が必要なのか？
PoE+（802.3at）は、最大 30W の電力を供給できる規格です。しかし、スイッチ（PSE: Power Sourcing Equipment）は、接続された端末（PD: Powered Device）が「どれだけ電気を欲しがっているか」を知らなければ、無駄な電力を確保し続けなければなりません。
ここで重要なのが、物理層による分類（Hardware Classification）とデータリンク層による分類（LLDP-MED）という二段構えのネゴシエーションです。
物理層の握手：抵抗値によるクラス判定
ケーブルを挿した瞬間、PSEはPDに対して低い電圧（2.7V〜10.1V）をかけ、抵抗値を測定します。この「検出（Detection）」と「分類（Classification）」により、PDは自分の「クラス」を名乗ります。
- Class 0-3: 最大12.95W (802.3af準拠)
- Class 4: 最大25.5W (802.3at準拠)
ここで重要なのは、Class 4は「2段階のパルス」で判定されるという点です。これを「2-Event Classification」と呼びます。スイッチが「お前はClass 4だな」と認識すると、電力配分の上限を 30W に引き上げます。現場のトラブルでよくあるのが、この2段階目のパルスを古いスイッチが正しく送れず、PDが 15.4W モードで動作してしまい、結果として「電力不足で機能制限（APの無線ラジオOFFなど）が発生する」というケースです。
—
2. LLDP-MEDによる「より細やかな」電力調整
物理層の分類はあくまで大雑把です。そこで登場するのが LLDP-MED（Link Layer Discovery Protocol for Media Endpoint Discovery）です。
物理層の初期ネゴシエーションが終わった後、スイッチとAPの間でLLDPパケットが交換されます。ここで初めて、PDは「自分は正確に 22.5W 必要だ」といった精密な要求を送れます。
Cisco IOSでの確認コマンド例
まずは、スイッチがどのようにデバイスを認識しているか確認しましょう。
# 接続されているPDの詳細を確認するコマンド
show power inline
# 出力例:
# Interface Admin Oper Power Device Class
# Gi0/1 auto on 22.5W Cisco-AP-3802 4もし show power inline で認識が正しくない場合、以下のコマンドでLLDPの状態を確認します。
# LLDPネイバーの状態を確認
show lldp neighbors detail
# 「Power Management」セクションに、要求電力と供給電力が表示されているはずです—
3. Webエンジニアが知るべき「電力の監視」と自動化
最近では、SDN環境やクラウド管理型スイッチにおいて、API経由で電力状況を監視することも一般的です。例えば、PythonでスイッチのPoE状態をポーリングし、電力消費が閾値を超えたらSlackへ通知するスクリプトを書くといった運用です。
以下は、Netmikoライブラリを使用してPoEの消費電力を取得するイメージコードです。
from netmiko import ConnectHandler
# スイッチへの接続設定
switch = {
'device_type': 'cisco_ios',
'host': '192.168.1.1',
'username': 'admin',
'password': 'password123',
}
def check_poe_status():
with ConnectHandler(**switch) as net_connect:
# PoEの詳細情報を取得
output = net_connect.send_command("show power inline")
# 行ごとにパースして消費電力を抽出するロジック
for line in output.splitlines():
if "Gi0/1" in line:
# 実際の現場ではここを正規表現等で数値化し、
# 閾値（例: 25W以上）を超えたらアラートを飛ばす運用にします
print(f"現在のPoEポート状態: {line}")
if __name__ == "__main__":
check_poe_status()—
4. 現場からの教訓：トラブルシューティングの極意
私が新人時代、一番苦労したのは「ケーブルの品質」でした。
- 抵抗値の罠: 粗悪なLANケーブルを使うと、ケーブル内で電圧降下が発生します。PSEは
30W出していても、PDの手前では24Wになっている。するとAPは「電力不足」と判断し、パフォーマンスを落とします。 - 温度と電力: 多くのスイッチは「スイッチ全体の最大電力供給量（Power Budget）」が決まっています。気温が高い夏場、冷却ファンが全開のスイッチは、過熱を防ぐためにPoEの供給量を絞ることがあります。
結論:
「PoE+の仕様を満たしているはずなのに動作がおかしい」時は、まず show power inline で 「Admin（設定値）」と「Oper（実際の供給値）」が一致しているか を見てください。もし一致していないなら、スイッチの予算（Budget）不足か、LLDPのネゴシエーション失敗、あるいは単純なケーブル長による電力ロスを疑うべきです。
ネットワークは物理層が全て。どんなに高度なWeb APIを叩こうが、その下のLANケーブルが電気を運べなければ、すべては絵に描いた餅です。
皆さんのインフラ運用が、今日も安定して稼働することを願っています。何か深掘りしたい技術テーマがあれば、いつでも聞いてくださいね。
コメント