

前面把双供电切换测试、Wireshark 抓包排障讲透了。这一篇回到供电侧——当你的机柜里有 24 口、48 口交换机,每口都插着 PoE 温湿度传感器(或者更耗电的 PoE 网口记录仪),你以为插满就能用?PoE 交换机的总功率预算是有限的,超了会怎样、谁先被断电、断电后数据还连不连得上——这些在标书里永远不会写清楚。
先说一个现场最常见的"翻车"场景:
48 口接入交换机,前 24 口接了 PoE 温湿度传感器(每路 2W),后 24 口接了 PoE 摄像头(每路 7W),还混了几个 PoE 门禁(每路 5W)。 夏天机柜温度到了 40℃,交换机内部温度保护启动,开始按优先级砍端口供电。 结果:摄像头还在跑(因为后插的优先级高),温湿度传感器全灭(先插的优先级低)。 动环监控"消失"了,空调不知道库内温度,调控系统瞎了——监控系统自己先挂了。
标准 | 别名 | 单端口最大供电 | 线缆要求 | 典型设备 |
|---|---|---|---|---|
IEEE 802.3af | PoE | 15.4W(PSE 端) / 12.95W(PD 端) | Cat3+ | 温湿度传感器、IP 电话 |
IEEE 802.3at | PoE+ | 30W / 25.5W | Cat5e+ | 摄像头、AP |
IEEE 802.3bt Type 3 | PoE++ | 60W / 51W | Cat5e+ | 高清 PTZ 摄像头 |
IEEE 802.3bt Type 4 | PoE++ | 100W / 71W | Cat6A+ | 显示器、瘦客户机 |
关键认知:标称 15.4W 是交换机端口输出,经过 100 米网线衰减,设备端只能拿到 12.95W。对于温湿度传感器(通常 1–3W)绰绰有余,但功率预算是整台交换机共享的。
交换机型号(举例) | 端口数 | 标称 PoE 总预算 | 实际可用 | 说明 |
|---|---|---|---|---|
入门级 8 口 PoE | 8 | 65W | ~55W | 满载 8×7W 摄像头就超 |
企业级 24 口 PoE+ | 24 | 370W | ~330W | 24×15.4W 理论满载,实际按协商功率分配 |
企业级 48 口 PoE+ | 48 | 740W | ~660W | 48×15.4W = 739W,但摄像头混插就超 |
数据中心级 48 口 PoE++ | 48 | 1600W | ~1400W | 需要双电源冗余 |
重点:PoE 交换机的总功率预算不是"每口独立",而是所有端口共享一个功率池。当总请求功率超过预算时,交换机会启动功率管理策略——决定给谁供电、不给谁供电。
不同厂商、不同档位的交换机,功率分配策略差异巨大。部署前必须确认。
管理员手动配置每个端口的最大功率上限:
interface GigabitEthernet 0/1
power inline static max 4000 (4W)
interface GigabitEthernet 0/2
power inline static max 7000 (7W)优点 | 缺点 |
|---|---|
精确控制每个端口的功率上限 | 配置繁琐(48 口逐一配置) |
防止某个端口"贪婪"占用过多功率 | 端口未插设备时也预留功率,浪费预算 |
可预留功率给关键设备 | 设备实际功耗变化时不会动态调整 |
交换机通过 LLDP-MED 协议与 PD 设备协商实际所需功率:
1. 设备插入 → 交换机先分配一个"探测功率"(通常 15.4W)
2. PD 通过 LLDP-MED TLV 通告自己的实际功率需求(如 2.5W)
3. 交换机调整分配,释放多余功率回池优点 | 缺点 |
|---|---|
自动适配设备实际需求,功率利用率最高 | 依赖 PD 支持 LLDP-MED(部分廉价传感器不支持) |
即插即用,无需手动配置 | 协商过程有延迟(几秒到十几秒) |
设备拔掉后功率自动回收 | 恶意设备可谎报低功率,实际高耗电 |
先按静态配置分配,未配置的端口走动态协商。
优先级:静态 > 动态 > 未分类这是最关键的部分——当总功率不足时,交换机会按端口优先级决定给谁断电:
优先级等级(从高到低):
1. Critical(关键) → 永不掉电,除非交换机整体过载保护
2. High(高) → 功率不足时,最后被砍
3. Low(低) → 功率不足时,最先被砍
4. 未配置 → 默认 Low典型厂商命令:
# Cisco
interface GigabitEthernet 0/1
power inline priority critical
# H3C
poe priority critical interface GigabitEthernet 1/0/1
# 华为
interface GigabitEthernet 0/1
poe priority critical设备类型 | 典型功耗 | PoE 等级 | 备注 |
|---|---|---|---|
基础型温湿度传感器 | 1.5–2.5W | 802.3af Class 1–2 | 无屏、无继电器输出 |
带屏显温湿度变送器 | 3–5W | 802.3af Class 2–3 | 带 LCD 背光 |
四合一一体机(温湿度+PM2.5+压差+UVC) | 5–8W | 802.3af Class 3 | 内置风扇、UVC 灯 |
网口温湿度记录仪(带存储) | 2–4W | 802.3af Class 2 | 带 microSD 卡、RTC |
带继电器输出的控制器 | 4–7W | 802.3af Class 3 | 继电器吸合瞬间电流大 |
场景:48 口交换机,总预算 740W
设备分布:
32 路温湿度传感器 × 2.5W = 80W
8 路四合一一体机 × 6W = 48W
4 路摄像头 × 7W = 28W
4 路门禁 × 5W = 20W
─────────────────────────────────
总请求功率 176W
可用预算 740W × 0.9(安全余量)= 666W
结论:充足,无需担心但如果是这个场景:
场景:24 口 PoE 交换机,总预算 180W
设备分布:
12 路温湿度传感器 × 2.5W = 30W
12 路摄像头 × 12W = 144W
─────────────────────────────────
总请求功率 174W
可用预算 180W × 0.8 = 144W
结论:超了!功率不足,摄像头和传感器会争抢设计原则 | 推荐值 | 原因 |
|---|---|---|
总功率不超过预算的 80% | 740W → 实际用 ≤ 590W | 留余量给启动浪涌、温度降额 |
单端口不超过 Class 限值 | af: 15.4W, at: 30W | 防止端口过载 |
温度降额 | 40℃ 以上降额 20–30% | 高温下 PSE 芯片效率下降 |
启动浪涌 | 预留 20% 余量 | 设备启动时电容充电瞬间电流大 |
条件 | 交换机行为 |
|---|---|
总请求功率 > 总预算 | 按优先级从低到高断电 |
单端口电流 > 阈值 | 该端口立即断电,记录日志 |
端口短路(线缆破损) | 立即断电,标记端口为 error-disabled |
交换机内部温度 > 阈值 | 全局降功率或按优先级砍端口 |
PSE 芯片过温 | 该芯片管理的端口组断电 |
功率不足时:
1. 先砍 Priority = Low 的端口
2. 再砍未配置优先级的端口
3. 最后砍 Priority = High 的端口
4. Critical 端口永不砍(除非交换机整体过载保护)问题来了:如果你没有配置优先级,所有端口默认 Low——温湿度传感器和摄像头一起被砍,谁先谁后取决于端口号大小或插入顺序。
Cisco 日志示例:
%ILPOWER-5-ILPOWER_LOW_POWER: Interface Gi0/12: power denied, low power available
%ILPOWER-7-ILPOWER_PORT_SHUTDOWN: Interface Gi0/12: power shutdown due to power budget exceeded
H3C 日志示例:
POE/4/POWEROVER: Port GigabitEthernet1/0/12 power off due to insufficient power budget关键:这些日志默认只写在交换机本地,不发送到动环平台——你以为传感器坏了,其实是交换机把它断电了,而你的监控系统完全不知道。
方案 | 优点 | 缺点 |
|---|---|---|
动环专用 PoE 交换机(独立) | 功率预算独立、不受其他系统影响、优先级可控 | 多一台设备、多一个故障点 |
混插(和摄像头/门禁共用) | 省设备、省端口 | 功率竞争、优先级冲突、摄像头故障可能拖垮动环 |
强烈建议:动环监控的 PoE 传感器独立使用一台交换机,不与其他系统混插。如果必须混插,至少做到:
Critical 优先级 Low 或 High(但不能高于动环) # 动环专用交换机配置模板(Cisco 风格)
# 全局:启用 PoE,设置告警阈值
power inline budget 80% # 告警阈值 80%
power inline never off all # 禁止节能模式关闭端口
# 动环端口(1-32):Critical 优先级
interface range GigabitEthernet 0/1 - 32
power inline priority critical
power inline static max 4000 # 限制每口最大 4W
spanning-tree portfast
spanning-tree bpduguard enable
# 预留端口(33-48):Low 优先级,用于未来扩展
interface range GigabitEthernet 0/33 - 48
power inline priority low
power inline autoSNMP 监控:
OID 分支:
CISCO-POWER-ETHERNET-EXT-MIB
cpeExtPsePortPwrConsumption → 每端口当前功耗
cpeExtPsePortPwrAllocated → 每端口分配功率
cpeExtPsePortEnable → 端口供电状态(1=on, 2=off)
cpeExtMainPseUsageThreshold → 全局功率使用率
关键指标:
cpeExtPsePowerMonitorTotalConsumption → 总消耗功率
cpeExtPsePowerMonitorTotalAllocated → 总分配功率Python 采集脚本:
from pysnmp.hlapi import *
def get_poe_status(host, community, port=161):
"""通过 SNMP 获取交换机 PoE 状态"""
oids = {
'total_consumption': '1.3.6.1.4.1.9.9.402.1.2.1.0', # 总消耗
'total_allocated': '1.3.6.1.4.1.9.9.402.1.2.2.0', # 总分配
'budget': '1.3.6.1.4.1.9.9.402.1.2.3.0', # 总预算
}
results = {}
for name, oid in oids.items():
iterator = getCmd(
SnmpEngine(),
CommunityData(community),
UdpTransportTarget((host, port)),
ContextData(),
ObjectType(ObjectIdentity(oid))
)
errorIndication, errorStatus, errorIndex, varBinds = next(iterator)
if not errorIndication and not errorStatus:
results[name] = int(varBinds[0][1])
usage_pct = results.get('total_consumption', 0) / results.get('budget', 1) * 100
results['usage_percent'] = round(usage_pct, 1)
return results
# 示例
status = get_poe_status('192.168.10.254', 'public')
print(f"PoE 总预算: {status.get('budget', 'N/A')} mW")
print(f"已分配: {status.get('total_allocated', 'N/A')} mW")
print(f"实际消耗: {status.get('total_consumption', 'N/A')} mW")
print(f"使用率: {status.get('usage_percent', 'N/A')}%")
if status.get('usage_percent', 0) > 80:
print("⚠️ PoE 功率使用率超过 80%,存在过载风险!")PoE 使用率 > 70% → 平台提示(黄色)
PoE 使用率 > 85% → 平台告警(橙色),通知运维
PoE 使用率 > 95% → 平台紧急告警(红色),触发降级预案
端口被断电 → 立即告警,标记对应传感器为 quality=bad前面讲过 24VDC + PoE 双供电。在交换机 PoE 过载场景下,双供电的价值被放大:
场景 | 单 PoE 供电 | 24VDC + PoE 双供电 |
|---|---|---|
交换机 PoE 过载,端口被砍 | 传感器断电,数据全丢 | 自动切换到 24VDC,数据不断 |
交换机整机故障 | 所有传感器断电 | 24VDC 独立供电,传感器继续工作 |
交换机固件升级/重启 | 传感器断电 | 24VDC 维持,传感器不掉 |
部署建议:
问题 | 后果 | 正确做法 |
|---|---|---|
不计算功率预算 | 插满后发现部分端口不供电 | 部署前算总功率,留 20% 余量 |
动环和摄像头混插 | 摄像头抢功率,传感器被断电 | 独立交换机,或动环端口设 Critical |
不配置端口优先级 | 默认 Low,过载时最先被砍 | 动环端口全部 Critical |
不监控 PoE 状态 | 端口被断电了不知道 | SNMP 监控 PoE 使用率 + 端口状态 |
交换机节能模式开启 | 夜间低流量时端口休眠 | 关闭节能,静态供电 |
温度降额忽略 | 夏天机柜 45℃,交换机降额后过载 | 机柜温控 + 功率预算按 70% 计算 |
启动浪涌不预留 | 32 台设备同时上电,瞬间过载 | 错峰上电或预留 20% 浪涌余量 |
廉价传感器不支持 LLDP | 交换机按最大功率分配 | 静态配置端口功率上限 |
不测试过载场景 | 验收时没问题,夏天出事 | 模拟过载,验证断电顺序和恢复 |
PoE 交换机不是"插上就有电"的无限电源——它是一池共享的功率预算,过载时会按优先级砍端口。 动环监控系统的传感器如果和摄像头共用交换机且不配优先级,监控系统自己会先挂。 部署前算清功率预算、配好优先级、监控 PoE 状态、关键节点双供电——这四件事不做,验收时一切正常,出事时全盘皆输。
当飞检人员问"如果交换机 PoE 过载,你的监测数据会不会断"时,你拿出的不应该是一份端口配置截图,而应该是一份PoE 功率规划表 + 过载测试报告 + 双供电切换验证——这才是过载保护机制真正落地的证明,而不是"交换机支持 PoE"的证明。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。