交换机每个端口是独立的冲突域和带宽域，一个口出问题，通常只影响这个口和它的上联。PON 不是这样。
GPON 的下行是 2.488 Gbps 的连续广播流，OLT 把所有下行帧发到整个 ODN，每个 ONU 都能收到全部内容，靠 GEM Port ID 和 ONU-ID 过滤出属于自己的部分（ITU-T G.984.3）。上行是 1.244 Gbps，由多个 ONU 按 TDMA 分时隙发送，测距保证各 ONU 的突发在 OLT 侧不重叠。
这两点决定了环路的后果完全不同于交换机：
下行任何广播帧，都会被分光器复制到每一个 ONU，不管这个 ONU 是不是环的一部分；
上行是全体 ONU 共享 1.244 Gbps，一个 ONU 持续发包，直接压缩同口其他 ONU 的可用时隙。
一个用户的错误接线，影响面是整条 PON 口，而不是他自己那一户。这是 PON 上防环比交换机上更紧迫的原因。
先算下行的放大倍数。
设分光比 1:64，一个 64 字节的最小以太网广播帧，净帧长 512 bit；加上前导码 8 字节与帧间隙 12 字节的线路开销，实际占用 84 字节 = 672 bit。
单帧在 ODN 上的总开销 = 672 bit × 64 = 43,008 bit ≈ 43 kbit。
如果这个广播以 1000 pps 的速率持续存在，下行占用 = 43 kbit × 1000 = 43 Mbps，占 2.488 Gbps 的 1.7%。
这个数字看着不大，但它有三个特点：
一是持续。 环路不老化，广播会一直转下去，直到有人拔线或抑制生效。交换机上的广播风暴往往几分钟就把 CPU 打满然后自愈（端口被 STP 阻塞），PON 上如果没有抑制手段，它不衰减。
二是叠加。 同一 PON 口下如果两个用户各有一个环，就是 86 Mbps，占 3.5%。用户侧小交换机的广播源不止环路，还有 ARP、DHCP、组播加入报文，实际速率往往高于 1000 pps。
三是打的是 OLT 的 PON 口处理能力，不是带宽。 每个下行帧 OLT 都要做 GEM 端口映射与队列调度，广播帧要复制到所有 GEM Port。pps 高了之后，先出问题的是 OLT 的包处理能力，表现为该 PON 口下所有 ONU 的时延一起上升。
上行的放大机制不一样，它不是"复制"，而是"挤占"。
上行 1.244 Gbps 由全口 ONU 分时使用，DBA 按 T-CONT 的保证带宽与最大带宽分配时隙。一个处于环中的 ONU，其上行队列里始终有包，于是：
它按分配到的时隙持续发送，不会出现空闲；
如果它的 T-CONT 类型允许用满剩余带宽（Type 5 的最大带宽可设到 PON 口总带宽），它可以把整条上行的空闲时隙全部吃掉；
同口其他 ONU 只能拿到自己的保证带宽，突发时没有余量。
这意味着一个 100 Mbps 的环路流量，可能让整条 PON 口的可用余量归零。 不是因为它真的占了 1.244 Gbps，而是因为其他 ONU 一旦超过保证带宽就借不到空闲时隙了。
现场的表现很容易误判：其他用户报"晚上网速慢""视频卡"，光功率测下来正常（−22 dBm 在范围内），于是怀疑 OLT 或上游。真正的原因是同口某个 ONU 在持续占用空闲带宽。
信号一：OLT 的 PON 口广播包速率突增。 大多数 OLT 的端口统计里有广播包计数，正常情况下这个值应该很低且平稳。突增到基线的几十倍，且持续不回落，基本可以确定有环或广播源。
信号二：单 ONU 的上行字节数异常。 在 OMCI 的 PM 计数或 OLT 的 ONU 流量统计里，看每个 ONU 的上行字节数。一个家庭 ONU 的上行通常几十 kbps 到几 Mbps，出现持续几十 Mbps 的就是嫌疑对象。这个方法比看广播计数更直接，因为它能指到具体哪一台。
信号三：MAC 地址漂移。 环形成后，同一个 MAC 会在 ONU 的两个 LAN 口之间来回学习，OLT 的 MAC 表里表现为同一 MAC 在两个 GEM Port 或两个 ONU 之间跳动。有些平台会直接报"MAC 漂移"告警，这是最省事的判据。
三个信号里，先看第二个。它定位最快，而且不需要额外工具。
风暴抑制的阈值不能拍脑袋写一个"1000 pps"，要按链路带宽和业务容忍度反算。
设上行 1.244 Gbps，允许广播占用 2%（这是一个常见起点，具体按业务定）：
可用广播带宽 = 1.244 × 10⁹ × 2% = 24.88 Mbps
按 64 字节最小帧、含线路开销 672 bit 计算：
阈值 pps = 24.88 × 10⁶ ÷ 672 ≈ 37,024 pps
若只算净帧 512 bit，则是 48,594 pps。工程上取小值更安全，37,000 pps 左右。
这个阈值要配在 ONU 的 UNI 端口上，而不是 OLT 的 PON 口。理由：PON 口的聚合流量本来就高，配低了会误伤正常的组播和 ARP；UNI 口是单用户，基线清晰，超阈值就是异常。
| 位置 | 抑制对象 | 建议阈值 | 副作用 |
|---|---|---|---|
| ONU UNI 口 | 该用户上行的广播/组播/未知单播 | 按 2% 上行带宽折算，约 37,000 pps | 抑制期间该用户业务受损，但范围可控 |
| OLT PON 口 | 整口的广播总量 | 按 5–10% 折算，约 90,000–185,000 pps | 阈值过低会误伤 IPTV 组播 |
| OLT 上联口 | 进入城域的广播 | 按上联带宽 1% 折算 | 只能兜底，不能定位 |
PON 上没有"跑个 STP 就好了"这条路。原因有三：
其一，PON 是无源分光，不存在二层环路检测的天然位置。 ONU 到 OLT 之间是点对多点，STP 的 BPDU 在 PON 上的透传行为依赖厂商实现，多数场景默认不透传或不建议开启。
其二，环在用户侧。 用户把两台小交换机互连，这个环在 ONU 的两个 LAN 口之间闭合。STP 要生效，得让 ONU 参与生成树，而 ONU 通常只做二层透传。
其三，端口隔离更直接。 在 ONU 上把同一台设备的多个 LAN 口设为隔离（端口隔离 / private VLAN），两个口之间不能二层互通，环在闭合点就被切断。代价是同一个 ONU 下的设备不能互访——对家庭和小商户通常没影响，对企业用户要提前确认。
| 手段 | 作用位置 | 能否断环 | 代价 |
|---|---|---|---|
| UNI 端口隔离 | ONU 的 LAN 口之间 | 能，环在 ONU 内部就被切断 | 同 ONU 下设备不能互访 |
| 风暴抑制 | ONU UNI 口或 OLT PON 口 | 不能断环，只能限制影响 | 超限期间丢包 |
| loopback detection | OLT 的 PON 口（部分平台支持） | 能检测并阻塞，需平台支持 | 依赖厂商实现，非通用 |
| 现场拔线 | 用户侧 | 能 | 需要上门，响应慢 |
实际部署的做法是三层一起上：UNI 端口隔离防环形成，风暴抑制限制影响范围，OLT 侧检测负责告警。 只配其中一层，都会在某个场景下漏掉。
ONU 下挂的是工业交换机时，环路防护要在交换机侧再叠一层。工业交换机的 STP/RSTP、BPDU 防护与端口风暴控制可以兜住用户侧自建的环，具体配法见 工业交换机方案，PON 侧与交换机侧的抑制阈值要按各自的带宽口径分别设定，不能互相套用。
发现某 PON 口下用户集体变慢时，按这个顺序走，通常 10 分钟内能定位：
看 PON 口广播包速率：相对基线涨了 10 倍以上，进入下一步；没涨，查别的原因（光衰、上联拥塞）。
按 ONU 排序上行字节数：取前 3 名，与历史基线比。持续 10 分钟以上高位的就是嫌疑。
看 MAC 漂移告警：有告警直接锁定，没有也不排除（部分平台不报）。
远程关掉嫌疑 ONU 的 UNI 口或下线该 ONU：如果 PON 口广播速率立刻回落，确认。
恢复后配端口隔离与风暴抑制，再让用户接回设备。
锐应 XPON ONU 与 L102P 这类 mini GPON OLT 的组合里，ONU 侧的端口隔离与 OLT 侧的 PON 口统计是配套使用的：先靠 OLT 的统计定位到 ONU，再在 ONU 上做隔离。L102P 单 PON 口支持 1:128 分光，意味着一个口下最多 128 个 ONU 共享 1.244 Gbps 上行，抑制阈值更要在开通时就配好，而不是等出事。完整的 PON 侧接法与设备规格见 PON 方案页。
一般不建议，也多半开不起来。PON 是点对多点共享介质，ONU 通常只做二层透传，BPDU 的处理依赖厂商实现，跨 ONU 的生成树在标准里没有定义。防环的落点是 ONU 的 UNI 端口隔离，配一条命令就能切断用户侧的环，比引入 STP 简单得多。
因为上行是共享的 1.244 Gbps，按 TDMA 分时隙。环中 ONU 的上行队列始终非空，它会把自己能拿到的时隙全部占满；其他 ONU 超过保证带宽的部分就借不到余量。下行则是广播被复制到所有 ONU，pps 高了会拖慢 OLT 的包处理。两头叠加，整口用户体验一起下降。
按带宽占比反算，不要抄一个固定 pps。上行允许广播占 2%，1.244 Gbps × 2% = 24.88 Mbps，按 64 字节帧含开销 672 bit 折算约 37,000 pps。配在 ONU 的 UNI 口，不要配在 OLT 的 PON 口（会误伤 IPTV 组播）。
先看 OLT 的每 ONU 上行字节数排行，取前几名；再看 MAC 漂移告警。两步都不需要断业务。确认后再远程关闭该 ONU 的 UNI 口做验证，观察 PON 口广播速率是否回落——回落就是它。
会，取决于生产设备之间是否需要二层互访。如果 PLC、HMI、摄像头在同一个 ONU 下需要互访，就不能开全隔离，只能靠风暴抑制限制影响，并在交换机侧开启 STP 或 ERPS。这种情况下建议把这几个设备改到独立的 ONU，隔离边界更清晰。
PON 上的环路之所以难处理，是因为它的破坏不像交换机那样立竿见影，而是把整条 PON 口的余量一点点吃掉，表现成"大家都有点慢"。等用户集中投诉时，往往已经持续了几天。可行的做法是把防线前移：开通时配好 UNI 端口隔离和风暴抑制，日常监控盯着 PON 口广播速率与单 ONU 上行排行这两个指标。设备侧的方案与规格见 关于锐应。
