终端带机量大以后三层交换机ARP表更新慢

可以的话。细分业务VLAN。看网络规模。增加汇聚。网关和DHCP放到汇聚。与核心BGP互通。

GigabitEthernet1/0/24 这个上联口源源不断收到TC‑BPDU 拓扑变化报文（MSTP 拓扑变更报文）H3C。 当交换机收到 TC 报文，MSTP 默认行为：清空该实例下全部 MAC 地址表，同时将 ARP 表项置为待重新探测状态，交换机需要向全网发送大量 ARP‑Request 重新学习 ARP 表项。 带机六七百台规模，短时间海量 ARP 探测报文上送 CPU，受 CPCAR 限速，部分 ARP‑Reply 被丢弃，ARP 表更新严重滞后；终端虽然拿到 DHCP‑IP，但三层网关没有 ARP，业务访问卡顿 / 延迟几分钟才恢复。

日志 was notified a topology change = 本设备收到其他设备发送过来的 TC‑BPDU，通知本设备刷新表项，不是本机端口 UP/DOWN。端口 G1/0/24 就是 TC 报文的来源入口。

第一步：确认 TC 报文统计，定位震荡源

• 如果GigabitEthernet1/0/24的 Receive 数值持续快速上涨，确认 TC 报文从这个端口流入核心交换机。
• 断开 G1/0/24 故障消失，说明下游接入网络存在 STP 震荡（环路、终端端口没有配置边缘端口、接入交换机频繁端口 up‑down）。

注意：核心交换机本身没有环路；问题出在 G1/0/24 下联的接入层网络，下联网络频繁产生 TC‑BPDU，上送到核心三层，冲击核心的 MAC/ARP 表项。

方案 A：核心侧隔离 TC 风暴（先缓解故障，生产优先执行）

接口 G1/0/24 是连接不稳定接入网络的上联口，配置stp tc‑restriction，该端口收到 TC‑BPDU 不再扩散，不再触发本机 MAC/ARP 表项刷新，阻断震荡向上冲击核心设备H3C。

⚠️提醒：stp tc‑restriction仅用在上行接收外部 TC 的端口；不要用在双核心互联、堆叠 IRF 链路。开启之后，下游网络自己的拓扑变化不会再影响核心交换机的 MAC、ARP 表，直接解决 ARP 表更新慢的现象。

方案 B：根治 —— 排查下游 G1/0/24 下面接入网络（根本解决，不能只做隔离）

TC 报文源头在 G1/0/24 的下游接入交换机，下游常见诱因：

1. 接入交换机接终端的端口没有配置边缘端口 stp edged‑port enable；终端网线插拔、PC 开关机就会产生 TC‑BPDU，大量终端频繁上下线，持续生成 TC 报文。
2. 接入网络存在二层环路；
3. 接入端口网线质量差，端口频繁 flapping（up/down 震荡）。

接入交换机标准化配置（所有接 PC/AP 终端端口）

边缘端口核心作用：终端设备上下线不会产生 TC‑BPDU 拓扑变更报文，这是消除 TC 风暴的根本手段H3C。

ARP 层面配套优化（带机六七百台三层网关）

排查判断关键点

1. 执行完stp tc‑restriction之后，观察日志：Instance 0's port GigabitEthernet1/0/24 was notified a topology change不再刷屏；ARP 表学习速度恢复正常。
2. 但是下游接入网络的 STP 震荡还存在，必须去处理下游接入交换机边缘端口配置，否则下游网络本身业务依旧会受影响。

常见踩坑

1. 只开启stp tc‑protection全局防护，不配置端口stp tc‑restriction：只能降低刷新频率，不能完全阻止大量 ARP 探测，故障现象会减轻，但不会彻底消失。
2. 只在核心排查，忽略下游接入交换机边缘端口配置：重启后、终端大规模插拔网线故障复现。
3. 不要关闭全局 MSTP；关闭 STP 会引入二层环路风险。