<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>功率预算 on Zero Day Notes</title>
        <link>https://blog.5772447.xyz/tags/%E5%8A%9F%E7%8E%87%E9%A2%84%E7%AE%97/</link>
        <description>Recent content in 功率预算 on Zero Day Notes</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh</language>
        <lastBuildDate>Tue, 06 Oct 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://blog.5772447.xyz/tags/%E5%8A%9F%E7%8E%87%E9%A2%84%E7%AE%97/index.xml" rel="self" type="application/rss+xml" /><item>
            <title>PoE 供电不足致 AP 批量重启：功率预算被低估</title>
            <link>https://blog.5772447.xyz/posts/15191373/</link>
            <pubDate>Tue, 06 Oct 2026 09:00:00 +0800</pubDate>
            <guid>https://blog.5772447.xyz/posts/15191373/</guid>
            <description>&lt;h2 id=&#34;问题背景&#34;&gt;&lt;a href=&#34;#%e9%97%ae%e9%a2%98%e8%83%8c%e6%99%af&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;问题背景&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;公司四楼办公区 9 月底完成无线网络扩容：新增 12 台 Wi-Fi 6 无线 AP,同一楼层还顺带部署了 8 路 IP 摄像头做安全监控，全部接入同一台 24 口 PoE+ 交换机。交换机是三年前采购的，标称 PoE 总功率 370W,当时只带 6 台老 AP,余量充足——采购扩容设备时没有人重新算过功率账。&lt;/p&gt;&#xA;&lt;p&gt;设备割接完成后第一周风平浪静。第二周开始，无线控制器上每天出现两三次&amp;quot;多台 AP 同时离线再上线&amp;quot;的告警，每次 3~5 台、持续一分多钟自行恢复；同一交换机下的摄像头也在夜间偶发掉线重连。AP 位置分散在整层，不是集中某几个——这个&amp;quot;随机批量&amp;quot;的模式持续了五天，运维按&amp;quot;交换机固件 bug&amp;quot;申请了换机，换完照旧。&lt;/p&gt;&#xA;&lt;h2 id=&#34;故障现象&#34;&gt;&lt;a href=&#34;#%e6%95%85%e9%9a%9c%e7%8e%b0%e8%b1%a1&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;故障现象&#xD;&#xA;&lt;/h2&gt;&lt;ul&gt;&#xA;&lt;li&gt;无线控制器告警：AP 批量断开重连，时间点不固定，白天夜间都有，单次涉及 3~5 台，恢复后功能正常。&lt;/li&gt;&#xA;&lt;li&gt;AP 本地日志显示是&lt;strong&gt;断电重启&lt;/strong&gt;而非软件重启——事件序列为&amp;quot;供电中断，设备冷启动&amp;quot;，不是 CAPWAP 隧道掉线。&lt;/li&gt;&#xA;&lt;li&gt;摄像头夜间红外模式开启时掉线频率明显升高，白天几乎不掉。&lt;/li&gt;&#xA;&lt;li&gt;交换机自身运行正常，端口状态灯正常，&lt;code&gt;show interface&lt;/code&gt; 无 CRC/错包，链路从未 down——供电问题不体现在链路层。&lt;/li&gt;&#xA;&lt;li&gt;交换机电源模块无告警，风扇正常，机箱温度正常——不是过热保护。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;排查过程&#34;&gt;&lt;a href=&#34;#%e6%8e%92%e6%9f%a5%e8%bf%87%e7%a8%8b&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;排查过程&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;第一步看交换机的 PoE 状态。&lt;code&gt;show power inline&lt;/code&gt; 的输出给出第一个关键信息：总功率 370W 的预算，当前实际输出 365W 左右，&lt;strong&gt;几乎贴着上限&lt;/strong&gt;；12 台新 AP 的协商功率全部在 25.5W 一档(802.3at),而当初扩容预算是按 15.4W(802.3af)一台估的——差出来的 120W 正好被新 AP 吃掉。剩下 8 台老 AP 和摄像头把预算占满，只留了 5W 左右的余量。&lt;/p&gt;&#xA;&lt;p&gt;第二步解释&amp;quot;为什么是随机批量重启&amp;quot;。PoE 交换机的功率分配是动态的：每台受电设备(PD)的实际取电会随工作状态波动，AP 在满负荷射频发射(多用户并发、mesh 回传)时瞬时功率比协商值再高几瓦。当多个 AP 恰好同时进入高负载、总需求超过 370W 时，交换机按优先级&lt;strong&gt;拒绝或切断部分端口的供电&lt;/strong&gt;——被切掉的 AP 断电重启，重启期间其余 AP 的功率需求回落，于是几分钟后又能重新上电。哪个 AP&amp;quot;中奖&amp;quot;取决于当时的瞬时负载分布，这就是&amp;quot;随机批量&amp;quot;的成因。&lt;/p&gt;&#xA;&lt;p&gt;第三步解释摄像头为何夜间高发。摄像头白天用红外关闭模式，整机功率约 8W;夜间红外补光灯开启，功率爬到 13W 以上。8 路 × 5W 的夜间增量，恰好是压垮本就贴顶的功率预算的最后一根稻草——所以掉线集中在夜间。&lt;/p&gt;&#xA;&lt;p&gt;第四步核实施工环节的疏漏。查采购与实施记录：扩容方案里写了&amp;quot;AP 802.3at、单台 30W 供电&amp;quot;，但功率预算表却按 15.4W/台 计算并标注&amp;quot;370W 充裕&amp;quot;——两处数字自相矛盾，实施时没人交叉核对；LLDP-MED 协商会向交换机请求更高功率档位，进一步抬高了实际占用，这一层在预算表里完全没有体现。&lt;/p&gt;&#xA;&lt;h2 id=&#34;解决方案&#34;&gt;&lt;a href=&#34;#%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;解决方案&#xD;&#xA;&lt;/h2&gt;&lt;ol&gt;&#xA;&lt;li&gt;&lt;strong&gt;短期&lt;/strong&gt;：把 8 路摄像头迁到一台独立的老交换机(非 PoE+ 但摄像头功率低，af 足够)，为 AP 释放约 110W 预算；当天完成后一周内零重启。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;正式&lt;/strong&gt;：按&amp;quot;802.3at 满档 30W + 20% 余量&amp;quot;重新核定该交换机的接入计划，上限 9 台 AP(当前 12 台超出)，超出的 3 台 AP 迁到隔壁机柜的另一台交换机；为高密区域两台 AP 配置为&amp;quot;关键优先级&amp;quot;(交换机 PoE port priority),拥塞时优先保无线。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;流程&lt;/strong&gt;：扩容审批表增加一行强制项——&amp;ldquo;PoE 功率预算核算(按 PD 协商标准上限计，非最低值)&amp;quot;，预算表必须体现 LLDP-MED 峰值；采购 PoE 交换机时按&amp;quot;当前需求 × 1.5&amp;quot;选容量。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;监控&lt;/strong&gt;：网管平台增加对该交换机 &lt;code&gt;powerUsed / powerAvailable&lt;/code&gt; 比值的采集，超 80% 告警——这次故障中，365/370 的比值在告警眼皮底下躺了五天，因为没人定义过这个指标。&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;h2 id=&#34;根因分析&#34;&gt;&lt;a href=&#34;#%e6%a0%b9%e5%9b%a0%e5%88%86%e6%9e%90&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;根因分析&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;直接根因是&lt;strong&gt;扩容按 802.3af 低档估算功率，实际设备以 802.3at 高档协商，叠加 LLDP-MED 峰值请求后总需求逼近 370W 上限&lt;/strong&gt;；任何瞬时波动都会触发交换机按优先级切断部分端口供电，被切断的 AP 断电重启，负载回落后又恢复，形成&amp;quot;随机批量重启&amp;quot;的循环。深层根因是变更流程缺陷：预算核算用了错误的单台功率基准，且功率余量没有纳入任何监控指标，隐患在告警体系里不可见。&lt;/p&gt;&#xA;&lt;h2 id=&#34;预防措施&#34;&gt;&lt;a href=&#34;#%e9%a2%84%e9%98%b2%e6%8e%aa%e6%96%bd&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;预防措施&#xD;&#xA;&lt;/h2&gt;&lt;ul&gt;&#xA;&lt;li&gt;全网 PoE 交换机功率占用率盘点，超 80% 的列入整改清单；&lt;/li&gt;&#xA;&lt;li&gt;PoE 扩容审批强制附功率预算表，按 PD 协商上限+20% 余量计算，双人复核；&lt;/li&gt;&#xA;&lt;li&gt;PoE 端口为关键设备(AP/门禁)配置高供电优先级，普通终端低优先级；&lt;/li&gt;&#xA;&lt;li&gt;功率占用率指标纳入网管采集，80% 告警、90% 严重。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;总结&#34;&gt;&lt;a href=&#34;#%e6%80%bb%e7%bb%93&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;总结&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;PoE 功率问题和机房 UPS 容量问题是同一类错误的两张面孔：按&amp;quot;铭牌最低值&amp;quot;而不是&amp;quot;实际协商上限&amp;quot;做容量规划。370W 听起来很大，但 12 台 at 级 AP 就是 360W 起步——数字不会骗人，被跳过的只是那一步乘法。这次还暴露了告警体系的盲区：数据一直在，指标没定义，等于没有。容量类资源(功率、IP 池、存储、license)的占用率，都应该成为一等公民的监控项。&lt;/p&gt;&#xA;&lt;h2 id=&#34;延伸阅读&#34;&gt;&lt;a href=&#34;#%e5%bb%b6%e4%bc%b8%e9%98%85%e8%af%bb&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;延伸阅读&#xD;&#xA;&lt;/h2&gt;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/460eac0e/&#34; &gt;记一次无线 AP 信道干扰致高层半层网络瘫痪&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/cbaa3ade/&#34; &gt;办公区无线网络为何间歇性断连？&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/4561423f/&#34; &gt;记一次 NAC 802.1X 认证后终端无法获取 IP 的排查记录&lt;/a&gt;&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;</description>
        </item></channel>
</rss>
