1. 先说结论PoE 不是“插上就有电”而是两套机制在猜需求你在项目里配过 PoE 摄像头大概率遇到过这种事网线插上去交换机端口灯是亮的但摄像头死活不开机或者开机闪一下就反复重启。很多人第一反应是“摄像头坏了”“交换机端口坏了”但真正的问题往往出在 PoE 的功率协商上——PoE 供电设备PSE通常是交换机和受电设备PD摄像头、AP、电话机之间并没有一个“我饿了给我 14.2W”的直接对话通道。PoE 想知道对方要多少电靠的是两套并行机制一套是物理层的 class 分级从 802.3af 时代就存在相当于手动挡PD 告诉你一个功率“档位”PSE 按档位给另一套是 LLDP 功率握手从 802.3at 开始引入类似实时竞价PD 可以在运行过程中向 PSE 报出更精确的功率请求PSE 再告诉它“我最多给你多少”。两个机制的关系不是替代而是先分级、后精调。这篇文章把这两套机制从头到尾拆开讲清楚包括 PD 端 25kΩ 特征电阻是怎么被探测的、分类电流对应的 class 表、LLDP 里 Power via MDI TLV 的实际交互过程再结合我在摄像头、AP 项目中踩过的功率预算坑给你一套可以直接拿去排障的实操思路。1.1 为什么 PSE 不能直接送 48V这是最多人忽略的基础。如果 PSE 一看到网线插上就送 48V那普通电脑、打印机这类非 PoE 设备直接就被打坏了。所以 IEEE 规定了一个“先探测再上电”的安全流程PSE 会先施加一个很低的电压检测对端是否存在一个 25kΩ 的特征电阻——这个电阻是 PD 内部刻意设计出来的“我是受电设备”信号。只有探到合法电阻PSE 才会继续走分类流程最终才敢送上 48V。说白了PoE 的功率协商不是一个“问功耗”的过程而是一个“验明正身”的过程第一问你是谁第二问你要几档电第三问能不能再精确点最后才真正供电。接下来我按这个顺序展开。2. class 分级物理层的“手动挡”先把功率档位定下来class 分级的思路特别像汽车变速箱的手动挡。PD 在设计时就知道自己大概的功耗范围比如红外摄像头常态 10W、夜间加红外灯 14W那它就通过物理层的分类电流告诉 PSE“我要按 class 3 对待”。PSE 收到这个信号后会把这个端口的功率预算记为 15.4W并在后续运转时按这个级别限制输出。这里有一个容易混淆的地方class 分级里的“功率”有两个值一个是 PSE 侧的输出功率上限一个是 PD 侧可用的最大功率。两者中间差的部分是线缆损耗。因为 PoE 标准按 100 米五类线来评估线缆本身会吃掉一部分功率所以 PD 真正能用的永远比 PSE 标称输出低一截。2.1 三个标准对应的 class 功率表从 802.3af 到 802.3at再到 802.3btclass 的数量和含义一直在扩展。我把最常见的映射关系整理成一张表这张表我项目里反复对照建议保存。PoE 标准classPSE 输出功率上限PD 最大可用功率典型场景802.3af Type 1class 015.4W12.95W早期摄像头、IP 电话802.3af Type 1class 14.0W3.84W低功耗传感器802.3af Type 1class 27.0W6.49W部分 AP802.3af Type 1class 315.4W12.95W普通摄像头802.3af Type 1class 4保留保留af 阶段不使用802.3at Type 2class 430.0W25.5W云台摄像头、高端 AP802.3bt Type 3class 545.0W40.0W带加热器的摄像头802.3bt Type 3class 660.0W51.0W双射频 AP、LED 大屏802.3bt Type 4class 775.0W62.0W高功率 PTZ 摄像机802.3bt Type 4class 890.0W71.3W大功率加热、室外设备看这张表你会发现一个有意思的细节class 0 在 af 里其实代表“未知或由 PD 自定义”但很多 PSE 会直接按最大档位 15.4W 给它预算。所以早期设备上“class 0”很常见并不代表这个设备耗电小反而它可能拿到最高的默认功率预算。到了 at 和 bt 阶段class 4 的含义被重新定义了。802.3af 里 class 4 是保留项到了 802.3at 里 class 4 就是 Type 2 的标记。再往后到 802.3bt单单报一个 class 4 还不够因为 bt 要求 PD 通过“两事件分类”来确认自己是否支持 Type 3/Type 4否则 PSE 会默认按 at 的 25.5W 来限制你。这是很多 bt 摄像头插到老交换机上拿不到高功率的直接原因。2.2 PSE 怎么把 class “读”出来两段式探测PSE 读 class 不是靠软件协议而是靠物理层的电流特征。整个过程分两步第一步是检测。PSE 在网线对上施加一个 2.7V 到 10.1V 之间的电压测量电流再换个电压再测一次通过两个采样点计算斜率得到对端电阻。正常的 PD 签名电阻是 25kΩ容差在正负 5% 以内。如果算出来是 25kΩPSE 确认“这是合法 PD”如果不是大概率是普通网卡或空线PSE 不会继续下一步。第二步是分类。PSE 把电压抬升到 15.5V 到 20.5V 之间PD 内部会根据自己设计的 class 接入不同的电流负载PSE 测量这个电流区间。大致上0 到 5mA 对应 class 09 到 12mA 对应 class 117 到 20mA 对应 class 226 到 30mA 对应 class 336 到 44mA 对应 class 4。电流区间之间有明显的间隙就是为了防止误判。这套机制的巧妙之处在于检测和分类阶段的功率都非常小不会损坏非 PoE 设备。即使你误插了一台不支持 PoE 的电脑PSE 探测不到 25kΩ 特征电阻也就不会进入供电阶段。所以在排障时如果你的交换机端口显示“Detecting”状态一直不变先怀疑 PD 端签名电阻异常或者网线质量太差而不是怀疑电源板坏了。3. LLDP 功率握手从“档位”到“实时报价”class 分级有一个先天缺陷——它只能表达几个固定档位精度太粗。class 3 和 class 4 之间差了 15W如果一台设备实际峰值功耗是 18W报 class 3 可能不够报 class 4 又浪费端口预算。更麻烦的是很多设备的功耗不是恒定的红外灯开启前后可能差 3 到 5W云台电机启动瞬间可能冲到正常功耗的三倍。这种动态变化靠固定 class 根本没法处理。LLDP 功率握手就是为这个场景设计的。它不是一个单独的协议而是把功率协商信息塞进 LLDP 报文里由 IEEE 802.3at 定义了一种叫 Power via MDI 的 TLV。如果你用 Wireshark 抓包能看到 Type 为 127 的组织特定 TLVOUI 是 00-12-0Fsubtype 是 1。这才是 PoE 功率协商真正的“对话内容”。3.1 为什么 class 都报上去了还要 LLDP我见过不少项目里工程师以为 PoE 功率是靠 class 一锤定音的其实不是。class 完成的是“预算立项”LLDP 做的是“动态结算”。具体来说PSE 在分类阶段知道 PD 是 class 4就会在端口上预留 30W。但这个预算不一定真的全部给出去。PSE 还要看交换机整机电源余量、端口优先级、系统策略最终在 LLDP 报文里告诉 PD“我给你分配 20W。”PD 收到这个分配值之后会主动调节自己的功耗比如降低红外灯亮度、限制云台转速、关闭某些射频链。反过来PD 也可以通过 LLDP 向 PSE 请求更高的功率。比如 AP 在夜间开启第二路射频PD 可以在 LLDP 里把请求值从 15W 改到 25WPSE 收到后看预算还有余量就会更新分配值。这种动态协商能力是 class 完全做不到的。LLDP 的交互周期通常是 1 到 2 秒发一次报文所以功率变化不需要重启设备几个报文周期就能同步完成。这也是为什么很多高端 PoE 交换机在管理页面上能看到“当前协商功率”这样实时变化的数据背后就是 LLDP 在不停更新。3.2 一次完整的功率握手流程我把一次标准的 LLDP 功率握手拆成四步方便对照抓包去看。第一步PD 上电进入运行状态后开始在 LLDP 报文中携带 Power via MDI TLV。PD 会在这条 TLV 里上报自己的功率类型PD、优先级、当前请求的功率值这个值以 0.1W 为单位。举个例子如果 PD 请求 15W报文里的数值就是 150。第二步PSE 收到 PD 的 LLDP 报文后会对比本端口的预算分配和整机剩余功率。如果余量充足PSE 会回复一条携带分配功率值的 LLDP 报文明确告知 PD“我分给你多少”。假如 PSE 因为整机预算不足给了一个比 PD 请求值更低的分配值PD 就必须调整自己否则 PSE 可能会触发过流保护。第三步PD 收到 PSE 分配值之后会把这个值当作自己的“功耗天花板”开始动态调整负载。这个过程不是一次性的PD 可以随时发起新请求PSE 也可以主动更新分配值。第四步如果链路断开或者 PD 掉电PSE 会在很短时间内停止供电端口状态回到检测阶段。下次重新上电要再走一遍探测、分类、LLDP 协商的完整流程。在实际抓包里你只要看 LLDP 报文里的 Power via MDI TLV 字段就能直接看到“请求 25.5W、分配 30W”这种具体数字比去交换机管理页面翻日志直观得多。3.3 802.3bt 对 LLDP 的强化以及两事件分类到了 802.3bt 阶段功率协商变得更复杂因为功率上限已经到 90W不能再依赖老一套的简单分类。802.3bt 引入了一个叫“两事件分类”的机制。老标准的分类只有一次电压脉冲PD 报一个 class 就完了。bt 里 PSE 会连续给两个电压事件第一次让 PD 报基础 class第二次确认“你是否支持更高功率”。只有完整经历两个事件的 PD才会被 PSE 认定为 Type 3 或 Type 4 设备才有资格拿到 40W 以上功率。LLDP 在 bt 里也升级了Power via MDI TLV 增加了更多字段比如电源类型、优先级、可用功率、分类信息、请求值和分配值。其中让我印象最深的是“可用功率”这个概念PSE 可以在广播自己的整机功率预算PD 收到后能自动判断自己该不该请求更多功率。这就从一个“点对点协商”变成了“集中调度”在大型 PoE 供电项目中非常有用。如果你用的是 bt 交换机但 PD 端是老设备整个过程会退化为经典模式反过来bt 设备插到 af 交换机上最多只能拿到 12.95W 或 25.5W别指望它能通过某种协议魔法突破物理层的功率上限。协议之间的兼容性是向下兼容的不是向上飞跃的。4. 一帧完整握手复盘从插上网线到摄像头亮灯讲了协议部件我把整个链路的时序串起来复盘一遍。这个时序非常重要排障时你先知道设备走到哪一步才能判断问题出在哪个环节。第一步是物理连接。网线插上后PSE 开始做检测。它输出两个不同的低压采样点测量对端电阻。如果你的网线质量差、线对电阻太大或者线缆超过 100 米PSE 看到的等效电阻可能偏离 25kΩ 太多直接判定“没有 PD”端口状态卡在检测阶段。这是我在现场遇到最多的“假死”问题之一。第二步是分类。PSE 确认 PD 合法后开始施加分类电压读取当前档位。PD 的 class 值由它内部的分类电路决定这个电路通常是根据设备设计功耗选定的。如果 PD 的设计功耗是 14W它的分类电路可能被设计成 class 3如果 PSE 认为 class 3 的 15.4W 不够设备吃它可以拒绝上电或者后续触发过流保护。第三步是上电。PSE 输出 48V 电压同时限制启动浪涌电流。很多摄像头在启动瞬间会有一个电容充电过程表现为大电流脉冲PSE 的浪涌限制就是为了防止这个时候误判短路。上电完成后PD 的 DC-DC 电路开始工作系统启动。第四步是 LLDP 协商。PD 启动后开始发 LLDP 报文请求精确功率。这里有个细节很多 PD 在系统还没完全启动时用的是“低功耗模式”比如摄像头先不开红外灯、AP 先不启动高功率射频等拿到 PSE 的分配值后再逐步加载功能。这么做就是为了避免“还没协商完就超功率导致掉电”。第五步是动态运行。设备正常工作期间LLDP 报文持续交互。如果 PSE 整机功率被其他端口挤占它可能下调某个端口的分配值PD 收到后可能被迫降功耗。如果你看到摄像头夜间红外灯自动变暗、AP 莫名其妙降速可以先查 LLDP 分配值是不是被压了。完整时序里最容易被忽略的是第二和第四步之间。有些 PSE 在分类阶段给的功率和后续 LLDP 分配值不一致比如分类给 30W 预算但 LLDP 只分配 20W。PD 如果按 30W 去设计行为就很容易发生过流。所以我在项目里一定要求交换机侧把 LLDP 的分配策略配置为“按最大分类功率分配”而不是“按整机预算动态压缩”除非特别清楚 PD 端能自适应。5. 实战排查与选型摄像头场景下的功率计算和“闪断”案例下面这部分是这套协议知识在项目里最值钱的地方——怎么避免摄像头反复重启、怎么算功率预算、怎么在现场快速定位是 class 问题还是 LLDP 问题。5.1 功率预算别按“铭牌功耗”算要按峰值算我在做一栋楼的全 IP 化改造时统计过所有 PoE 摄像头的实际功耗。铭牌上写 12W 的固定摄像头夜间红外全开能到 14W云台摄像头更夸张启动瞬间电流能到额定值的 2.5 倍左右。如果你按铭牌功耗做预算整机算出来还剩 10W 余量实际一到夜间全端口一起拉高交换机电源直接过载出现大面积端口掉电。我给一个保守但不会出问题的估算公式。每个端口的 PoE 预算 设备峰值功耗 × 1.2 的保险系数 线缆功耗预留。线缆预留按线缆长度估算百米五类线大约损耗 2.45W 到 4.5W。以固定红外摄像头为例铭牌 12W、峰值 14W乘 1.2 后是 16.8W这意味着你至少需要给它配一个 class 4 级别的端口而不是 class 3。因为 class 3 的 PSE 输出上限只有 15.4W卡得刚刚好夜间红外一开就会顶到保护阈值。为什么要留 20% 余量因为 PoE 交换机的功率保护是按端口电流阈值触发的分类电流和实际电流之间存在差异再加上线缆电阻受温度影响铜的电阻温度系数约为 0.4%/℃线缆夏天和冬天的损耗能差出不少。卡着 1W 余量的设计到了夏天必炸。5.2 三个典型故障现场class 不对、LLDP 分配过低、网线拖后腿第一个高频故障是设备实耗超过了 PSE 按 class 给出的功率上限。现象是摄像头启动正常但红外灯一开就断线重启查看交换机日志能看到“power over current”或“PD disconnected due to over current”这类记录。这种问题优先检查端口分类如果你的交换机支持手动锁定 class把这个端口强制锁定到更高档位问题立解如果不支持只能换更高等级的 PSE 或者外部供电。别想着靠 LLDP 解决因为耗电增长是在 LLDP 协商周期之外发生的物理突变。第二个高频故障是 LLDP 分配值被 PSE 压得太低。现象是 AP 接入后只能跑到一半速率或者摄像头的云台转动时频繁掉电但正常静态画面没问题。这种情况去交换机管理界面看端口 PoE 实时功率一般会看到分配值只有 PD 请求值的 60% 左右。解决方案是调整交换机 PoE 策略把端口优先级调高或者直接关闭动态功率压缩让端口按最大分类功率分配。第三个高频故障是网线问题导致 PSE 根本探测不到合法 PD。现象是端口一直处于“Detecting”状态或者“Searching”状态。这个我在现场用万用表量过很多次劣质铜包铝网线 80 米外电阻可以超标两倍PSE 读到的等效电阻完全偏离 25kΩ。这时候换 PoE 交换机、改摄像头配置都没用老老实实换线。判断方法很简单把 PD 拿到交换机旁边用一米成品跳线插上如果立即正常供电90% 是线缆问题。5.3 现场常用验证手段排障时我最常用的不是网线测试仪而是 Wireshark 抓 LLDP 报文。在交换机镜像端口或者在 PD 端接一个抓包工具抓到的 Power via MDI TLV 里能看到双方实际协商的功率值。Linux 下可以直接用 tcpdump 抓sudo tcpdump -i eth0 -XX -s 0 ether[12:2] 0x88ccLLDP 的以太网类型是 0x88cc抓到后重点看 Type 127 的 TLV里面会有 PD 请求值和 PSE 分配值。这个方法比看交换机日志准确得多因为日志只是记录保护动作抓包能看到协商过程。另外在交换机管理界面里几乎所有主流厂商都有查看端口 PoE 状态的命令。典型的有show power inline interface这条命令在不同厂商系统里略有差异但基本都会显示该端口的分类状态、实际消耗功率、当前分配功率、供电状态。先看状态是不是“Delivering Power”再看实际功率是不是逼近分配值峰值一步一步排查。6. 关于选型我个人的不严谨但好用的经验最后分享一个我反复使用的选型思路。如果你给一个摄像头配 PoE 交换机首选支持 802.3bt 的型号哪怕当前只有几台设备需要高功率。原因很现实bt 交换机向下兼容 af/at 设备同时端口预算宽裕调试时不用拿计算器逐台算 class。而 af 交换机端口预算 15.4W 封顶遇到需要高功率的摄像机就只能外接电源这会直接破坏施工的整洁度。如果预算有限必须用 at 交换机端口功率预算尽量不连续部署超过总预算的 80%。很多中低端 PoE 交换机的整机功率预算和端口分类功率是完全独立的两套逻辑每个端口按分类预留了 30W整机却只有 120W一旦同时接入 4 台以上 class 4 设备整机电源就过载了。这个“端口预算 vs 整机预算”的差额是 PoE 排障里最容易骗到人的细节。PoE 的功率协商从 class 分级到 LLDP 握手本质是两套不同颗粒度的机制相互配合。物理层分类负责确定设备类型和初始安全供电范围LLDP 负责运行期的动态精准调节。理解了这两个层次你在查 PoE 故障时就会形成一条清晰的判断链设备不启动先看检测、检测通过后看分类、分类正确后看运行时功率、运行时异常再看 LLDP 分配值。大部分问题都能在这一条链路上定位出来。