板块2 · 二层交换基础：端口、MAC 表与镜像

目标与定位：本板块把端口参数、二层转发状态、接入安全、故障取证和二层防环放到同一条排障链路上。现场遇到“网络不通”时，先问三件事：端口是否真的 up、VLAN 与标签是否正确、交换机是否已经学到 MAC。
80% 的“网络不通”最终都归结到端口状态、VLAN 归属、MAC 表项这三件事；剩下 20% 才需要继续上升到三层、ACL、路由或应用。
学习要求是 ZCIA 会配会查、ZCIP 能解释工程取舍、ZCIE 能根据故障反推配置。配置必须能逐条验证，验证必须对应关键字段，不能以“命令敲完”代替“业务已通”。
本文命令覆盖体系A（盒式 set 风格）与体系B（机架式/新版 ZXR10 风格）。具体关键字、范围与缺省行为依型号、软件版本不同，现场执行前用 ? 帮助确认，并在测试环境先行验证。

2_1 端口参数体系总览

端口不是“插上网线就能通”的单一开关，而是一组协同参数。 物理层决定链路能否建立，VLAN 与 MAC 学习决定帧如何归属和转发，QoS 决定拥塞时的处理顺序，管理与统计则负责把“配置意图”变成可观测事实。任何一个层面错配，都可能表现为同一种“上不了网”，因此不能只凭端口指示灯或 ping 结果下结论。

2_1_1 端口能力全景（一个端口身上有多少开关）

                     ┌────────────────────────────────┐
   物理层  ─────────►│ 状态 enable/disable            │
                     │ 自协商 auto enable/disable     │
                     │ 速率 speed 10/100/1000         │
                     │ 双工 duplex full/half          │
                     │ 流控 flowcontrol               │
                     │ MDIX  auto/crossover/normal    │
                     │ PoE   auto/force/never         │
                     ├────────────────────────────────┤
   链路层  ─────────►│ PVID          1-4094           │
                     │ VLAN 成员     tag / untag       │
                     │ 地址学习      security         │
                     │ MAC 数目限制  macaddress 0-16   │
                     │ MAC 固化      fix-mac          │
                     ├────────────────────────────────┤
    QoS   ─────────►│ 默认优先级    default-priority  │
                     │ 出入方向限速  bandwidth        │
                     │ 组播过滤      multicast-filter │
                     ├────────────────────────────────┤
   管理   ─────────►│ 名称 name / 描述 description    │
                     │ 统计 statistics / 清零          │
                     └────────────────────────────────┘

现场处理顺序应是“自底向上、逐层闭合”。 推荐先确认 enable/disable、物理连接、速率双工与错包，再检查 PVID、VLAN 成员、MAC 学习和安全动作，最后才使用镜像取证。这样能够避免一个常见误区：在应用层反复测试，却忽略端口已经被 MAC 固化 shutdown，或上联口根本没有放行对应 VLAN。

端口配置台账是批量交付的最小治理单元。 每一张接入交换机工单至少记录端口用途、对端设备、PVID、限速、MAC 策略、上联/下联属性和责任人。否则，半年后的“临时配置”会变成无人敢动的黑盒，环路检测、镜像或安全策略也容易被误删。

2_1_2 端口配置命令全表（体系A）

#	功能	命令
1	配置端口状态	`set port [portlist] {enable\|disable}`
2	端口自适应（自协商）	`set port [portlist] auto {enable\|disable}`
3	端口双工模式	`set port [portlist] duplex {full\|half}`
4	端口速率	`set port [portlist] speed {10\|100\|1000}`
5	入方向带宽限制	`set port [portlist] bandwidth ingress {off\|on rate [64-256000] [tcpdrop\|flowcontrol]}`
6	出方向带宽限制	`set port [portlist] bandwidth egress {off\|on rate [64-256000]}`
7	流量控制	`set port [portlist] flowcontrol {enable\|disable}`
8	端口优先级	`set port [portlist] default-priority [0-7]`
9	地址学习开关	`set port [portlist] security {enable\|disable}`
10	组播包过滤	`set port [portlist] multicast-filter {enable\|disable}`
11	对外供电模式（PoE）	`set port [portlist] poe {auto\|force\|never}`
12	速率宣称	`set port [portlist] speedadvertise {maxspeed \| {speed10\|speed100\|speed1000} {fullduplex\|halfduplex}}`
13	学习 MAC 数目	`set port [portlist] macaddress {on [0-16] \| off}`
14	MAC 固化保护	`set port [portlist] fix-mac on [0-16] {shutdown \| protect}`
15	固化自动恢复时间	`set port [portlist] fix-mac auto-recover-time {on [5-240]\|off}`
16	绞线方式（MDIX）	`set port [portlist] mdix {auto\|crossover\|normal}`
17	创建端口名	`create port [portname] name [name]`
18	添加端口描述	`set port [portlist] description [string]`

命令表的正确使用方式是“配置—查看—统计”三连，而不是只敲配置命令。 set 只表达意图；show port 验证运行状态；show port statistics 反映真实流量和异常。例如，fix-mac on 1 shutdown 后必须看端口状态与 MAC 计数，否则无法区分“配置生效但合法 MAC 未学到”和“违规已触发但管理员未感知”。

配置端口时优先使用 portlist，但验收时必须逐口确认。 批量命令可以减少敲错概率，却不能证明每一口都满足接入策略。批量部署后建议按用途抽样检查：终端口查 MAC 限制、VLAN 和环路检测；上联口查速率双工、标签放行和风暴抑制策略；监控口查镜像目的端口是否被误用。

查看与清除命令

功能	命令
显示端口配置与工作状态	`show port [[portlist]]`
显示端口 QoS 配置	`show port [portlist] qos`
显示端口统计	`show port [portlist] statistics`
清除端口统计	`clear port [portlist] statistics`
清除端口名/描述	`clear port [portlist] {name\|description}`

排障中的“查看与清除”应成对使用。 不要在没有清零的情况下用累计统计判断故障，因为上线以来积累的正常错包和当前故障造成的增量混在一起，容易误判。正确流程是先 clear statistics，复现业务约 1~3 分钟，再观察 CRC、冲突、丢包等增量；如果清零后立即恢复，则说明问题可能具有持续性，适合继续抓包；如果计数不增长，则更像配置、ACL、地址或路径问题。

2_1_3 【必须记住】四条缺省行为与硬性约束

自适应缺省开启；一旦手工设置工作方式（双工）或速率，自适应自动关闭。
后果：手工锁定速率/双工后，如果对端仍开自协商，对端可能 fallback 到半双工，形成双工不匹配。恢复思路不是反复拔线，而是明确两端协商策略后重新配置。
所有以太网光口及 1000M 电口只能是全双工，无法修改。
现场如果尝试 duplex half，通常要么被拒绝、要么不生效；此时应检查命令体系和端口类型，而不是继续反复设置。
100M 和 1000M 光口的速率无法修改。
光模块、光纤和对端速率必须物理匹配；交换机侧“强制 100M/1000M”并不能替代光模块能力不匹配的问题。
MAC 地址限制缺省关闭；MAC 固化自动恢复时间缺省 30 分钟，且只对 shutdown 模式生效（protect 模式不会自动恢复）。
因此，fix-mac on 1 protect 后即使配置了 auto-recover-time，也不能期待端口自动恢复；而只配置 shutdown 却忘记配置恢复时间，则可能形成人工现场恢复任务。

缺省值不是“安全值”，而是配置基线。 端口自协商开启、MAC 限制关闭、固化恢复 30 分钟，都是设备启动后的初始状态；它们不等于生产环境已经具备防环、防私接和自动恢复能力。开局文档必须把“需要显式开启的项”与“沿用缺省的项”分别列出，并在变更窗口后逐条复核。

约束之间具有传导关系。 例如，光口/千兆电口只能全双工，意味着在这些端口上讨论半双工错包时，应优先怀疑对端配置或统计口径；100M/1000M 光口速率不可改，意味着速率异常更应检查模块、光纤和对端能力；MAC 限制关闭则是“接上 Hub 仍能学到多个 MAC”的正常前提。把这些约束串联起来，排障才不会逐个命令盲试。

2_2 自协商、速率与双工

自协商的目标是让两端在无人工干预时选择共同支持的最佳链路能力，而不是让一端永久主导另一端。 一旦一端固定、另一端自动，双方可能最终使用不同的双工方式；这种组合往往链路指示灯保持 up，却在大流量时出现严重性能劣化。

2_2_1 自协商到底协商了什么

自协商（Auto-Negotiation, 802.3u/802.3ab）在物理层通过 FLP 脉冲交换能力：
   ┌──────────────────────────────────────────┐
   │ 速率能力：10M / 100M / 100M / 1000M / 10G│
   │ 双工能力：半双工 / 全双工                 │
   │ 流控能力：PAUSE 帧对称/非对称             │
   │ 主从（1000BASE-T）/ 远端故障指示          │
   └──────────────────────────────────────────┘
  两端取"双方都支持的最高级别"作为最终结果（优先级：1000M全双工 > 1000M半双工
  > 100M全双工 > 100M半双工 > 10M全双工 > 10M半双工）

自协商成功只说明两端选定了共同能力，不保证上层业务正常。 协商出 1000M 全双工仍可能由于 VLAN、MAC 表、ACL、MTU 或上层地址问题不通；反过来，链路 up 也不能证明协商结果符合设计。验证时必须同时查看 Speed、Duplex、Auto 和错包，而不能只看 Link。

FLP 是“能力通告”，不是应用层心跳。 自协商完成之后，并不会持续检测对端配置变化。若中途有人修改一端为 fixed，另一端未必立刻调整；此时应重新触发协商或按既定顺序重配两端，而不能只检查当前配置文本。

2_2_2 双工不匹配的三种组合

组合 A：两端 auto            → 协商成功，全双工             ✅ 推荐
组合 B：两端手工 full/1000   → 正常（但要两端一致）        ✅ 可用
组合 C：一端 auto，一端 fixed → 危险！                      ❌ 典型故障
        ┌────────────┐                    ┌────────────┐
        │  SW   fixed │◄─────────────────►│  PC   auto │
        │  100M/FULL  │                    │            │
        └────────────┘                    └────────────┘
        SW 不发 FLP 脉冲 → PC 收不到协商信息 → PC 只能靠
        "并行检测"猜速率=100M，双工猜不出来 → 退回半双工
        结果：SW 全双工 vs PC 半双工
        现象：小流量正常、大流量极慢、ping 时通时断、端口出现
              late collision / alignment 错包

双工不匹配的本质是“全双工不检测冲突、半双工依赖 CSMA/CD”的语义冲突。 一端认为可以双向同时发送，另一端却按共享介质方式处理，结果高负载时出现大量 late collision、alignment error、FCS/CRC 等异常。低负载下帧少，问题不明显；一旦备份、文件传输或视频业务启动，吞吐会急剧下降。

三种组合中，最危险的是“一端 auto、一端 fixed”。 两端都 auto 时通常能够同步能力；两端都 fixed 且参数一致时，也属于明确配置。混合模式却可能使 fixed 端不发送足够协商信息，auto 端根据并行检测选择速率，双工则退回到保守值。因此故障现象通常不是“完全不通”，而是“ping 正常、业务极慢、时好时坏”。

光口与千兆电口只能全双工，不应把双工不匹配的常见电口排障经验机械套用到光口。 如果千兆链路实际运行异常，优先核对模块、光纤、接收功率、两端速率能力和 VLAN，而不是尝试 duplex half。

2_2_3 配置与验证

! 强制 1000M 全双工（两端必须都这么配）
zte(cfg)#set port 23 auto disable
zte(cfg)#set port 23 speed 1000
zte(cfg)#set port 23 duplex full

! 恢复自协商
zte(cfg)#set port 23 auto enable

! 速率宣称：只向上游宣称部分能力（如只宣称 100M 全双工，用于限速对接老设备）
zte(cfg)#set port 5 speedadvertise speed100 fullduplex

! 验证
zte#show port 23

【踩坑】改速率双工的正确顺序：先关自协商 → 再设速率和双工 → show port 确认。反着来，设置可能被自协商覆盖或直接不生效。如果链路已经异常，建议同时检查对端；仅在交换机一侧反复切换 auto/fixed，可能让对端停留在不一致的并行检测状态。

speedadvertise 不是对所有对端都等效于限速。 它缩小的是本端对外通告的能力集合，最终链路仍以双方共同选择为准。若目标是限制终端业务带宽，应使用 bandwidth；若目标是兼容老网卡或特殊设备，才考虑速率宣称，并随后抓包或观察统计确认。

2_2_4 决策建议（现网原则）

场景	建议	理由
交换机 ↔ 服务器/PC	两端都 auto	现代网卡千兆自协商通常稳定，减少固定配置带来的不对称风险
交换机 ↔ 交换机	建议手工锁定速率双工	稳定链路可避免偶发协商异常，但要求两端完全一致
对接老设备/工控设备	手工锁定，并抓包验证	老网卡、特殊光模块或私有实现可能偏离常规协商行为
光口对接	核对模块波长、速率和双工约束	光口不支持改双工；100M/1000M 光口速率通常不可修改

协商策略必须与变更管理绑定。 “auto 好还是 fixed 好”没有脱离场景的绝对答案：接入侧追求兼容与自动化，核心互联追求确定性和快速故障定位。真正的风险来自同一链路两端策略不一致、文档未记录、故障后被人随意切换。建议将 auto/fixed、speed、duplex、对端责任人 写入端口台账，变更后保留前后 show port 输出。

2_3 流量控制与带宽限速

流控解决的是短期接收缓冲压力，限速解决的是长期业务带宽分配；两者目标不同，不能互相替代。 PAUSE 面向链路对端请求暂停，能够减少瞬时丢包；带宽限速则在端口上设置业务上限，更适合隔离租户、终端或业务。若在园区网无差别开启 PAUSE，反而可能把低优先级拥塞扩散为高优先级业务停顿。

2_3_1 流控（PAUSE 帧）是双刃剑

PAUSE 帧机制：接收方缓存快满 → 向发送方发 PAUSE 帧 → 发送方暂停发送 X 时隙
                    ┌────────┐      PAUSE      ┌────────┐
                    │ 收端    │───────────────►│ 发端    │
                    │ 缓存满  │                │ 暂停发送│
                    └────────┘                └────────┘

PAUSE 的副作用来自“链路级暂停不区分业务”。 当一条链路上同时承载语音、视频、管理和数据，接收端因某类流量拥塞发出 PAUSE，发送端暂停的是整条链路发送能力。于是低优先级的批量下载可以间接导致语音、管理或控制报文被延迟，形成队头阻塞（Head-of-Line Blocking）。

队头阻塞并不意味着“流控一定不能开”，而是要求业务特征匹配。 纯存储、FCoE、RoCE 等无损或低丢包场景可能依赖 PAUSE/PFC；普通园区接入则应优先考虑 QoS 调度、队列、限速和拥塞避免。若对端设备不支持或错误实现 PAUSE，还可能形成反复暂停、假死或吞吐塌陷，因此开启后必须观察暂停帧计数。

2_3_2 配置与选型

zte(cfg)#set port 1-24 flowcontrol disable      ! 园区网推荐
zte(cfg)#set port 1-24 flowcontrol enable       ! 特殊无损场景

配置前先问“拥塞发生在哪里”。 若本端出口缓冲不足、下游处理能力不足，PAUSE 有机会减少丢包；若瓶颈在上游或拥塞来自多源聚合，仅靠 PAUSE 会把问题扩散到其他发送者。园区网更常见的组合是：关键业务给队列和保证带宽，普通业务在端口限速，风暴流量由风暴抑制截断。

2_3_3 出入方向限速（64 kbps ~ 256000 kbps）

! 入方向限速 10 Mbps，超限采用 tcpdrop（丢 TCP 包触发降速）
zte(cfg)#set port 5 bandwidth ingress on rate 10240 tcpdrop

! 入方向限速 20 Mbps，超限采用 flowcontrol（发 PAUSE）
zte(cfg)#set port 5 bandwidth ingress on rate 20480 flowcontrol

! 出方向限速 50 Mbps
zte(cfg)#set port 5 bandwidth egress on rate 51200

! 关闭限速
zte(cfg)#set port 5 bandwidth ingress off
zte(cfg)#set port 5 bandwidth egress off

! 验证
zte#show port 5 qos

入方向限速限制的是进入本交换机的流量，出方向限速限制的是从本端口向外发送的流量。 二者并非镜像关系：终端发往网络的上行流，在本接入口通常属于 ingress；网络返回给终端的下行流，在本接入口通常属于 egress。设计限速前先画清流量方向，否则会把“限制上传”误配成“限制下载”。

tcpdrop vs flowcontrol 的核心差异

方式	机制	优点	缺点	适用
`tcpdrop`	主动丢 TCP 包，触发 TCP 拥塞控制降速	对 TCP 友好，不拖累其他流	对 UDP 无效（UDP 照样被丢）	普通上网、下载类业务
`flowcontrol`	发 PAUSE 帧暂停对端	不丢包	队头阻塞，影响同链路其他流量	特殊无损场景

限速策略要与业务协议匹配。 视频监控、语音、游戏或实时组播大量使用 UDP；若只部署 tcpdrop，限速可能未产生预期降速，继而占满带宽。此时应结合整体 QoS 方案、风暴抑制或业务隔离，而不能把 ingress tcpdrop 视为万能限速器。

2_3_4 单位换算与常见错误

单位换算提醒：rate 单位为 kbps，10240 = 10 Mbps。推导关系是：

10 Mbps = 10 × 1000 kbps = 10000 kbps

但命令取值为离散的 64~256000 kbps，因此现场常用最接近的可配置值；例如 10240 对应 10 Mbps，20480 对应 20 Mbps，51200 对应 50 Mbps。切忌漏乘 1024，也不要把“端口号”或“百分比”当作 rate 值。

正确示例：10 Mbps → rate 10240
错误示例：把 10240 当成 10 kbps、10 MB/s，或把 10000 直接当成命令中的精确合法取值而不核对范围

限速值必须留出协议与管理开销余量。 若业务合同要求“10 Mbps 体验”，设备限速值、应用统计口径、二层开销、突发许可和测量位置可能不同。验收时不只看端口配置，还要在合法业务峰值下测试吞吐、丢包和时延，确认没有误伤控制报文。

2_4 端口安全：MAC 限制与固化

端口安全不是单条命令，而是“允许学多少、允许谁学、违规怎么办、何时恢复”的完整策略。 macaddress 限制数量，fix-mac 绑定首学地址并定义动作，security 决定是否继续动态学习；三者独立又相互叠加。若只配其中一项，可能得到与预期完全不同的结果。

2_4_1 三种能力对比

能力	命令	作用	超限行为
MAC 数目限制	`set port 1 macaddress on [0-16]`	限制该端口最多学习多少个 MAC	超出数目的 MAC 不再学习（不影响已有）
MAC 固化	`set port 1 fix-mac on [0-16] {shutdown\|protect}`	先学到的 MAC 被“粘”在端口上，他人接入即违规	`shutdown`：关端口；`protect`：丢弃违规帧
地址学习开关	`set port 1 security {enable\|disable}`	关闭后不再动态学习（只能用静态 FDB）	—

“最多学习 N 个”不等于“只允许某一个终端”。 macaddress on 1 允许首 MAC 学习成功，但若接入小交换机、IP 电话下联 PC、虚拟机迁移或 Hub，同一端口可能先后出现多个 MAC。它适合限制接入规模，不能单独作为“唯一终端”证明。

fix-mac 的确定性来自“首学即固化”。 若合法设备尚未发送流量，端口可能先学到非法 MAC；之后合法终端反而被判定违规。因此摄像头、打印机等场景应在维护窗口、终端已在线且 MAC 已确认时启用，或结合静态 FDB、认证方案，而不是在业务高峰期直接硬切换。

security disable 与“拒绝学习”不是同义。 security enable 通常用于控制动态学习；若端口关闭学习，静态表项、既有转发状态和业务恢复机制就成为关键。生产环境应明确静态 MAC 来源和变更流程，避免配置后无法学习新网关、虚拟机或备份路径。

2_4_2 典型配置：摄像头/打印机接入端口加固

! 场景：port 13 接一台固定摄像头，只允许 1 个 MAC，违规直接关端口
zte(cfg)#set port 13 macaddress on 1
zte(cfg)#set port 13 fix-mac on 1 shutdown
zte(cfg)#set port 13 fix-mac auto-recover-time on 30     ! 30 分钟后自动恢复
zte(cfg)#set port 13 description TO-Camera-Hall-01

! 验证
zte#show port 13

现场推荐流程：先确认现有 MAC，再固定策略，最后验证恢复路径。

① 查看当前学习到的 MAC：show fdb port 13
② 确认摄像头真实 MAC、VLAN、上联路径
③ 配置 macaddress、fix-mac、auto-recover-time
④ show port 13 核对状态、限制数、固化模式、恢复时间
⑤ 模拟替换终端或在变更窗口测试违规动作
⑥ 保存配置并记录告警联系人

【案例故事】摄像头端口配了 fix-mac shutdown，却没配 auto-recover-time

一次园区改造，我把某楼层 12 个摄像头端口统一加固：macaddress on 1、fix-mac on 1 shutdown，想着“摄像头 MAC 永不变化，谁换设备谁断”。配置后业务正常，我没再逐口测试恢复路径。
两周后，一只摄像头电源模块异常，维修人员借来一台同型号设备临时替换。设备刚上线，port 7 立刻 shutdown。我原本以为 30 分钟会自动恢复，结果它并没有——因为我只配了固化，没有配 fix-mac auto-recover-time on 30。
那台摄像头位于二楼机房走廊，维护人员又已经离开。我只能带着笔记本赶到现场，在确认新摄像头 MAC 已获物业审批后，先 disable/enable 端口，再补齐恢复时间配置。事后复盘发现：缺省 30 分钟只对已配置的自动恢复生效，而我的配置里根本没有打开自动恢复。
从那以后，凡是 fix-mac ... shutdown，台账里必须同时出现三列：max-mac、action、auto-recover-time；缺失任何一列都不允许提交变更。

【必须记住】 自动恢复时间只对 shutdown 模式生效，protect 模式下不恢复（因为端口本来就没关）。缺省 30 分钟，范围 5~240 分钟。这里“缺省 30 分钟”指功能打开后的默认恢复时长；若从未配置 auto-recover-time on，不能据此推断设备会自动恢复。

2_4_3 【ZCIP/ZCIE】MAC 限制为什么防不住 Hub 下挂

MAC 数目限制是端口级的。用户在下面接一个 Hub 或家用路由器，如果只接 1 台 PC，MAC 数目依然合规。更危险的是，Hub 可能让多台设备共享同一冲突域，交换机看到的源 MAC 数量却未立即突破上限；私接小交换机后，新设备上线也可能因 MAC 数、固化策略或 FDB 漂移才暴露。

进阶防护组合拳（写在方案里很加分）

MAC 数目限制 + 固化（基础）
802.1X 认证（板块9，从源头鉴权）
DHCP Snooping + 端口隔离 / PVLAN（板块3，防止私接 DHCP 服务器和互访）
定期审计 FDB：同 MAC 在不同端口出现提示“MAC 漂移”，可能是私接或环路

安全策略的验收不是“配置存在”，而是“违规确实被阻断且业务可恢复”。 对每个接入模板至少做三种测试：合法终端正常、替换 MAC 被拒绝、违规后按设计 shutdown 或 protect。对于 shutdown，还要确认自动恢复时间、人工恢复命令和告警通知；对于 protect，要确认丢弃与告警是否符合预期。

2_5 MAC 表（FDB）操作与转发分析

FDB 是二层转发的决策表，端口只是 MAC 表项的来源之一。 交换机根据源 MAC 与进入端口建立或刷新表项，再根据目的 MAC 查表决定单播转发、泛洪或丢弃。因此，“终端已连接、端口已 up”并不能证明帧一定被正确转发；必须同时确认 VLAN/FID、MAC、端口和表项类型。

2_5_1 FDB 表项结构

一条 FDB 表项 ≈  MAC 地址 + VLAN(FID) + 端口/Trunk + 类型(静态/动态/过滤) + 老化计时

FDB 的查询维度应与故障现象匹配。 知道终端 MAC 就按 MAC 查；知道端口就按端口查；需要确认 VLAN 内泛洪范围就按 VLAN 查；涉及聚合链路再按 Trunk 查。只执行无条件的 show fdb 容易在表项很多时漏掉关键变化。

动态表项不是永久证据。 它随流量学习和老化；静态表项也不会因为“配置中有”就自动代表业务正常。实际验收还应结合连续帧、ARP、DHCP 和端口统计，确认转发路径两侧都能看到对方。

2_5_2 FDB 命令全表

#	功能	命令
1	配置 FDB 过滤地址	`set fdb filter [xx.xx.xx.xx.xx.xx] fid [1-256]`
2	添加静态绑定	`set fdb add [xx.xx.xx.xx.xx.xx] fid [1-256] {port [portname]\|trunk [trunkid]} [priority [0-7]]`
3	删除 FDB 记录	`set fdb delete [xx.xx.xx.xx.xx.xx] fid [1-256]`
4	设置老化时间	`set fdb agingtime [15-3600]`（默认 240s）
5	显示老化时间	`show fdb agingtime`
6	显示 FDB 表	`show fdb [[static\|dynamic] [detail]]`
7	按端口显示动态 FDB	`show fdb dynamic port [portname] [detail]`
8	显示过滤地址	`show fdb filter`
9	按 MAC 查	`show fdb mac [xx.xx.xx.xx.xx.xx]`
10	按端口查	`show fdb port [portname]`
11	按 VLAN 查	`show fdb vlan [vlanname]`
12	按 Trunk 查	`show fdb trunk [trunkid]`

静态、动态和过滤表项承担不同职责。 静态绑定用于固定关键转发或黑名单；动态表项反映真实流量学习；过滤则明确丢弃特定 MAC。不要把“删除一条动态表项”理解为永久封堵，也不要把 set fdb filter 误当作普通静态转发项。

删除 FDB 记录是有范围的操作。 命令需要明确 MAC 和 FID；在表项很多时不要盲目清空或误删其他业务表项。若目标是让某终端立即重新学习，应确认其在目标 FID/VLAN 中重新发送源帧，并观察新旧端口变化。

2_5_3 静态绑定的三个真实用途

用途 1：服务器/网关 MAC 固定绑定，防 ARP 欺骗与 MAC 漂移
   zte(cfg)#set fdb add 00.11.22.33.44.55 fid 100 port 5 priority 7

用途 2：非法终端 MAC 直接过滤（黑名单）
   zte(cfg)#set fdb filter 00.AA.BB.CC.DD.EE fid 10

用途 3：组播/特殊业务静态指向，避免泛洪（配合 IGMP Snooping，见板块6）

静态绑定不是万能的 ARP 防护。 它能固定二层转发位置，但网关 IP 与 MAC 的映射、DHCP 分配、跨网段行为还涉及 ARP、ACL、DHCP Snooping 等机制。若终端更换网卡或迁移到别的 VLAN，静态 FDB 必须同步更新，否则会形成“配置看起来安全、实际却把流量指向旧端口”的新故障。

用途选择要遵循最小影响原则。 关键网关或服务器的白名单式绑定适合明确拓扑；非法终端过滤适合已知风险 MAC；组播静态指向则要考虑组成员变化。若业务频繁迁移，静态绑定会增加维护成本，此时应评估认证、动态防护和自动化同步。

2_5_4 【踩坑】静态绑定用的是 FID，不是 VID

【踩坑】静态绑定用的是 FID 不是 VID。多数情况下 FID 默认等于 VID，但如果手工改过 VLAN 的 FID（见板块3 set vlan <id> fid <1-256>），静态 MAC 必须按 FID 配，否则绑到错误的转发表上，表现为“配了静态 MAC 还是不通”。

验证静态绑定的最短闭环：

① show vlan <id> 确认 VLAN 对应 FID
② show fdb add 后按 show fdb mac <mac> 检查 FID、端口、类型
③ 从终端发一个已知帧（例如 ping 网关）
④ show fdb dynamic/static port <port> 观察是否仍按预期命中
⑤ 若不通，先核对 FID，再核对 VLAN 成员、PVID、ACL 和上联路径

为什么这个坑容易被忽略？ 因为日常输出中 VLAN 与 FID 经常相同，测试环境碰巧通过，到了多租户或特殊 VLAN 映射环境却失败。考试中应把 FID 与 VID 作为两个字段分别核对；生产变更单也应同时保留两者。

2_5_5 老化时间的工程取舍

场景	建议值	理由
默认	240s	通用
终端频繁变动（无线漫游、会议室）	60~120s	加快收敛，避免 MAC 指向旧端口
稳定服务器/机房	300~600s	减少未知单播泛洪与 CPU 负担
存在环路风险且未开 STP	更短	缩短错误表项存活时间（临时手段，不能替代 STP）

老化时间过短会增加未知单播泛洪、消耗带宽与 CPU；过长则终端迁移后长时间不通。没有一劳永逸的值，按场景调。

老化时间本质上是“收敛速度”和“泛洪成本”的折中。 时间越短，终端换端口后错误表项消失越快，但交换机需要更频繁地重新学习；时间越长，表项稳定、未知单播泛洪较少，但漂移、迁移或故障切换后的收敛也越慢。

不能把调小老化时间当成防环方案。 环路存在时，缩短老化只会让错误表项更快刷新，不能消除广播循环本身。正确顺序是先依靠 STP、边缘保护、环路检测和风暴抑制控制环路，再把老化时间作为收敛参数优化。

2_5_6 MAC 漂移：环路与私接的“指纹”

判断方法（连续 3 次采样，间隔 10 秒）：
zte#show fdb mac 00.11.22.33.44.55

  第1次：port 3    VLAN 10
  第2次：port 17   VLAN 10     ← 同一 MAC 跳到另一个端口
  第3次：port 3    VLAN 10     ← 又跳回来
结论：MAC 漂移 → 大概率是二层环路（也可能是无线漫游、双网卡绑定切换、虚拟机迁移）

MAC 漂移是线索，不是最终根因。 同一 MAC 反复在两端口出现，说明转发表不断被刷新。可能来自物理环路、私接桥接、无线漫游、虚拟机迁移、双活网卡或故障模块；不能看到漂移就立即 shutdown 随机端口，而应按 VLAN、端口、STP、物理连接和流量变化逐步收敛。

采样频率要服从业务节奏。 10 秒三次采样适合快速变化的环路；无线、虚拟化环境可适当拉长间隔并结合日志。关键是保存每次的 MAC、FID/VLAN、端口和时间戳，形成可以比较的趋势，而不是仅凭一次查询下结论。

2_5_7 排查决策树

发现 MAC 漂移
      │
      ├─ 是否有 STP？ ── 否 ──► 立即启用 STP / 检查物理连线
      │
      ├─ 两个端口是否在同一 VLAN？ ── 是 ──► 高度怀疑环路
      │                              └─ 否 ──► 查 VLAN 配置/双 tagging
      │
      ├─ 是否伴随广播包激增？ ── 是 ──► 广播风暴，先 shutdown 一侧端口止血
      │
      └─ 是否伴随端口 up/down 抖动？ ── 是 ──► 物理层问题（光模块/网线），
                                              先看 statistics 的 CRC

控制故障影响应优先于寻找“理论完美根因”。 若确认某一接入口形成全网广播风暴，可以在变更授权范围内临时隔离该口；但操作前必须确认不会切断关键业务或管理通道，操作后保留现场信息并继续追查，而不能把“拔线恢复”写成永久方案。

2_6 端口镜像与抓包

镜像的价值在于把“设备认为发生了什么”与“线路上实际发生了什么”对照起来。 端口、MAC、VLAN 和统计只能提供局部状态；抓包可以看到 DHCP、ARP、IGMP、TCP 握手和重传。配置镜像时必须同时考虑源方向、目的口承载能力、VLAN Tag 和业务影响。

2_6_1 镜像命令全表

#	功能	命令
1	设置入/出向监控目的端口	`set mirror add dest-port [portname] {ingress\|egress}`
2	删除监控目的端口	`set mirror delete dest-port [portname] {ingress\|egress}`
3	添加镜像源端口	`set mirror add source-port [portlist] {ingress\|egress}`
4	删除镜像源端口	`set mirror delete source-port [portlist] {ingress\|egress}`
5	显示镜像配置	`show mirror`

术语：ingress = 入向（进入交换机），egress = 出向（离开交换机）。

镜像方向与业务视角必须对齐。 站在终端角度看，“发送请求”对应交换机在接入端口的 ingress；站在交换机角度看，同一帧进入交换矩阵也是 ingress。配置前先标注“报文从哪台设备发出、经过哪个端口进入、准备从哪个端口离开”，再选择方向，避免凭感觉同时镜像所有端口。

2_6_2 镜像方向与抓包位置

       源端口 port 5               目的端口 port 24 ──► 抓包机/分析仪
   ┌──────────────────┐
   │  终端 PC          │
   └────────┬─────────┘
            │
   ┌────────▼─────────────────────────────────────┐
   │              交换机交换矩阵                    │
   │                                              │
   │   ingress 镜像：抓取"从 PC 进入交换机"的帧      │
   │   egress  镜像：抓取"从交换机发给 PC"的帧       │
   └──────────────────────────────────────────────┘

方向选择的经验口诀

要看终端发了什么（DHCP 请求、ARP、IGMP Report）→ 镜像 ingress
要看网络回了什么（DHCP Offer、组播流）→ 镜像 egress
拿不准 → 两个方向都配（很多场景需要完整会话）

抓包位置决定能看到什么。 在接入端口镜像可以看到终端原始请求；在上联口镜像更适合观察跨网段、组播或全网路径。但上联口流量大，容易超过目的口带宽，因此只应在必要时短期开启，并优先选择单方向、单源端口或明确过滤条件。

2_6_3 配置实例：抓取 IPTV 机顶盒的 IGMP 交互

! 场景：port 8 接 IPTV 机顶盒，port 24 接抓包笔记本
zte(cfg)#set mirror add dest-port 24 ingress
zte(cfg)#set mirror add source-port 8 ingress
zte(cfg)#set mirror add source-port 8 egress

! 验证
zte#show mirror

! 抓完后清理（镜像会消耗带宽与 CPU，不要长期挂着）
zte(cfg)#set mirror delete source-port 8 ingress
zte(cfg)#set mirror delete source-port 8 egress
zte(cfg)#set mirror delete dest-port 24 ingress

镜像配置必须遵循“先建、后验、最后清理”。 建立后立即 show mirror，确认目的口、源口和方向；抓包结束后按相同粒度删除。遗留镜像不仅占用资源，还可能让目的口持续接收敏感业务流量，形成安全风险。

2_6_4 【踩坑】镜像的四个限制与注意事项

目的端口会被独占：目的端口上接的设备在镜像期间不能正常通信（它只接收镜像流量）。抓包机最好单独留一个口。
带宽溢出：多个源端口流量之和超过目的端口带宽时，镜像报文会被丢弃，抓到的包不完整 → 表现为“抓不到想看的包”。解决：减少源端口、只镜像一个方向，或改用聚合口做目的端口。
镜像影响性能：镜像是 CPU/芯片复制动作，大规模镜像会影响转发性能，排障完务必删除。
抓不到 VLAN Tag？ 取决于镜像实现，有的镜像保留 tag，有的剥掉。分析前先用 show vlan 确认端口属性，不要在抓包机上纠结。

“没抓到”要先分为三类：配置没命中、流量没到达、目的口装不下。 检查 show mirror 确认源/目的和方向；在源口 show statistics 确认预期报文确实经过；再估算源聚合带宽与目的口带宽。若源口统计不增长，问题在上游；若统计增长但抓包缺失，则可能是镜像带宽溢出或过滤问题。

2_6_5 Wireshark 常用过滤表达式

bootp || dhcp                ! 看 DHCP 全过程（DORA）
arp                          ! 看 ARP 请求/应答，判断网关可达性
icmp                         ! 看 ping
igmp                         ! 看组播加入/离开（IPTV 排障神器）
tcp.flags.reset == 1         ! 看连接被 Reset（ACL/防火墙拦截的典型特征）
tcp.analysis.retransmission  ! 看重传（丢包/拥塞）

抓包结论要与时间、端口、VLAN 和统计交叉确认。 例如，Wireshark 中看到 DHCP Request 但没有 Offer，不能立刻断言服务器故障；还需确认交换机是否把 ingress 正确转发、上联口是否放行对应 VLAN、是否存在 DHCP Snooping/ACL，以及抓包点是否位于 Offer 返回路径上。

2_7 广播风暴抑制、巨帧与端口别名

风暴抑制、巨帧和别名虽分属不同层次，但都体现同一原则：异常流量要有限制、跨设备报文要有一致边界、配置对象必须可识别。 风暴抑制控制损害半径；巨帧要求端到端 MTU 协同；别名降低端口误操作概率。三者都应进入开局模板，而不能等故障后补配。

2_7_1 广播风暴抑制：限制损害半径

为什么要单独做风暴抑制？
   环路检测是"事后发现"（15 秒间隔 + 判定 + 动作），在动作生效前，
   广播风暴已经把带宽和 CPU 打满了。风暴抑制是"实时限速"，
   把广播/组播/未知单播限制在一个安全阈值内，即使成环也不会全网瘫痪。

配置思路（三层保险）：
   ① 预防：STP + 边缘端口 + BPDU 保护
   ② 兜底：环路检测（15 秒发现并阻塞）
   ③ 限速：风暴抑制（把广播限制在端口带宽的 5%~10%，即便风暴也不致命）

典型取值：
   千兆用户口：广播限速 10~50 Mbps
   上联/聚合口：通常不限制或放宽（避免影响正常协议报文）

风暴抑制不是环路检测的替代品。 前者是持续速率限制，后者是基于探测报文的成环判定；前者降低爆炸半径，后者识别并隔离具体端口。生产设计中应让 STP 预防拓扑环、环路检测发现数据平面自环、风暴抑制限制残余流量。

阈值设置要区分用户口和上联口。 用户口主要承载单终端或少量接入流量，较低阈值通常可接受；上联口可能承载大量合法广播、组播、未知单播或协议报文，过度限制可能误伤业务。具体命令、单位、是否支持未知单播/组播分别限制，依型号/软件版本不同，现场用 ? 帮助确认。

验证风暴抑制必须先测基线。 在业务稳定时记录广播/组播速率；变更后再制造可控测试或使用监控趋势对比。若阈值过低，可能出现视频、发现协议或 DHCP 异常；若阈值过高，则失去抑制价值。因此不要照抄一个数值到所有端口。

2_7_2 巨帧（1560 → 9216）

! ---------- 体系B ----------
ZXR10(config)#interface gei-0/1/0/5
ZXR10(config-gei_0/1/0_5)#jumbo-frame enable           ! 默认禁止，最大帧 1560 字节
                                                       ! 开启后最大帧可达 9216 字节

巨帧的前提是端到端 MTU 一致。 仅在一个接入端口开启，并不能保证服务器、虚拟机、上联、汇聚和存储网络都支持相同最大帧长。中间任何一跳限制更小，就可能出现分片、丢弃或应用层大包失败，因此应沿真实路径逐跳核对。

“默认 1560、开启后 9216”是设备既定口径。 部署时仍要以设备实际命令和帮助信息为准；不要假设所有板卡、版本和接口类型都支持相同最大值。若承载 NFS、iSCSI、备份或视频等大帧业务，最好在维护窗口使用可控大包测试，而不是仅凭配置判断。

2_7_3 端口别名（byname）

! ---------- 体系B ----------
ZXR10(config)#interface gei-0/1/0/5
ZXR10(config-gei_0/1/0_5)#byname TO-Office-3F-PC-01    ! 可用别名代替端口名访问

别名解决的是“端口编号可识别性”，不等于替代 description。 对运维人员而言，TO-Office-3F-PC-01 比裸端口号更容易判断影响范围；但别名也可能因机房搬迁、用途变化而过时。建议把别名、description、VLAN、对端资产、变更单号放在同一台账，任何一项变化都同步更新。

体系A 与体系B 的治理重点不同。 体系A 可通过 create port ... name 和 description 管理；体系B 使用接口名与 byname。跨设备变更时，应统一使用“站点—楼层—机柜—用途—端口”命名规则，避免同一条链路在两台设备上名称不一致。

2_8 环路检测 loopdetect

环路检测是数据平面的自环兜底机制，最适合补位 STP 未覆盖或配置不一致的边缘场景。 它通过识别“本端口发出的探测报文又被本端口收回”来判定环路；不依赖对端协议配合。代价是误开在上联口可能形成大面积断网，因此部署纪律比命令本身更重要。

2_8_1 三种防环机制的分工

机制	工作层级	检测对象	动作	是否依赖对端
STP / MSTP	控制平面	拓扑环路（BPDU 计算）	阻塞端口	是（需全网运行）
BPDU 保护	接入端口	边缘口收到 BPDU	关闭端口	否
环路检测	数据平面	本端口发出的探测报文又回到本端口	阻塞/关端口/告警	否（独立工作）

三种机制的正确关系是叠加而非互斥。 STP 负责全网拓扑收敛，BPDU 保护负责防止边缘口接入非授权桥接设备，环路检测负责在数据平面发现未被 STP 覆盖的自环。只开环路检测而完全放弃 STP，可能在多设备复杂拓扑中出现检测盲区；只开 STP 而没有边缘策略和兜底检测，又可能在配置遗漏时形成风暴。

2_8_2 环路检测原理（自环探测）

                   交换机 port 1
                        │
              ① 每 15 秒发送一个二层探测报文
                 （携带：交换机源 MAC + 端口号 + 判别字段）
                        │
                        ▼
                 ┌──────────────┐
                 │  探测报文进入网络 │
                 └──────┬───────┘
                        │
        无环路：报文被正常转发走，port 1 收不回来 → 正常
                        │
        有环路：报文绕回 port 1（例如用户把两根线插在同一交换机、
                或下挂交换机自己打环）→ port 1 收到自己发的报文
                        │
                        ▼
        判定依据（三个参数全部相同即确认环路）：
              · 源 MAC 地址 == 本交换机 MAC
              · 端口号 == 发送端口
              · 判别字段（数字签名）匹配
                        │
                        ▼
        触发动作：block（阻塞端口）/ shutdown（关闭）/ 仅告警

“收到自己发的报文”必须三个条件同时满足，才能避免普通转发误判。 只匹配源 MAC 可能受其他设备影响；只匹配端口号无法防止伪造；只匹配判别字段而不绑定本机/端口，也不足以证明是同一端口自环。三要素共同构成判定闭环，因此现场应优先保留完整的探测参数和告警字段。

探测间隔决定理论发现时延上限。 默认 15 秒意味着不能期待环路瞬间被隔离；风暴抑制必须在等待检测期间承担限流职责。若业务对收敛要求极高，应先从拓扑设计、STP 和边缘保护入手，而不是盲目把检测间隔压到极限。

2_8_3 体系A（盒式）环路检测命令全表

功能	命令
端口环路检测开关	`set loopdetect port <portlist> {enable\|disable}`
指定 VLAN 的环路检测	`set loopdetect port <portlist> vlan <vlanid> {enable\|disable}`
Trunk 环路检测	`set loopdetect trunk <trunklist> {enable\|disable}`
Trunk 指定 VLAN 检测	`set loopdetect trunk <trunklist> vlan <vlanid> {enable\|disable}`
扩展检测（双端口环）	`set loopdetect extend port <portlist> enable`
查看全局检测参数	`show loopdetect`
查看端口检测状态	`show loopdetect port <portname>`

默认参数（背下来）

参数	默认值	说明
环路检测功能	缺省关闭	必须显式开启
检测报文发送间隔	15 秒	决定了环路发现的最大时延
阻塞延时 block-delay	5 分钟	端口被阻塞后多久尝试恢复
单端口可检测 VLAN 数	最多 8 个	未指定 VLAN 时检测端口 PVID 所在 VLAN

“缺省关闭”意味着开局模板必须显式启用，也意味着可以分阶段灰度。 先在低风险终端口开启，观察告警、CPU、业务和误判情况，再扩大到同类接入口；核心、上联和跨设备聚合口不在此列。任何批量启用命令都应附带回退脚本。

2_8_4 配置实例（体系A）

场景一：单端口自环检测（接入交换机接终端的口）

! 对 1-20 号用户口开启环路检测
zte(cfg)#set loopdetect port 1-20 enable

! 查看
zte#show loopdetect
! 输出示例：
!   The block-delay of loopdetect : 5 (min)
!   The packet interval of loopdetect : 15 (sec)
!   PortId  isUp  isStp  isProtect  isLoop  isBlock  isExtend  loopVlanNum  loopType
!   ------  ----  -----  ---------  ------  -------  --------  -----------  --------
!   1       Up    No     Yes        Yes     Yes      No        1            Port

! 查看单个端口细节
zte#show loopdetect port 1

场景二：双端口环检测（用户把两个口插在一起）

! 开启双端口环路检测（port 1、2 同属一个下挂交换机且互连）
zte(cfg)#set loopdetect port 1,2 enable
zte(cfg)#set loopdetect extend port 1 enable

场景三：指定 VLAN 检测（Trunk 场景）

! 在聚合组 trunk 1 上针对 VLAN 100 做检测
zte(cfg)#set loopdetect trunk 1 enable

! 或在端口上指定 VLAN
zte(cfg)#set loopdetect port 5 vlan 100 enable

VLAN 显式指定是跨 VLAN 拓扑的关键。 未指定时通常检测端口 PVID 所在 VLAN；若业务环发生在其他 VLAN、Trunk 携带多个 VLAN，或被检测端口 PVID 与业务 VLAN 不一致，就可能漏检。单端口最多 8 个 VLAN，因此应先梳理业务 VLAN 集合，再选择最需要保护的子集。

2_8_5 体系B（机架式/新版）环路检测与配套配置

! ---------- 环路检测 ----------
ZXR10(config)#loop-detect interface gei-0/1/0/5 enable
ZXR10(config)#loop-detect interface gei-0/1/0/5 vlan 100 enable

! 设置检测到环路后端口的状态
ZXR10(config)#loop-detect portstate block gei-0/1/0/5      ! 阻塞
ZXR10(config)#loop-detect portstate protect gei-0/1/0/5    ! 保护模式
ZXR10(config)#loop-detect portstate normal gei-0/1/0/5     ! 恢复正常

! ---------- 广播风暴抑制（接口下） ----------
ZXR10(config)#interface gei-0/1/0/5
ZXR10(config-gei_0/1/0_5)#broadcast-limit 1000        ! 限制广播速率，超限丢弃

! ---------- 巨帧（Jumbo Frame） ----------
ZXR10(config)#interface gei-0/1/0/5
ZXR10(config-gei_0/1/0_5)#jumbo-frame enable           ! 默认禁止，最大帧 1560 字节
                                                       ! 开启后最大帧可达 9216 字节

! ---------- 端口别名（等价于端口描述） ----------
ZXR10(config-gei_0/1/0_5)#byname TO-Office-3F-PC-01    ! 可用别名代替端口名访问

三种环路动作的选择取决于“恢复成本”和“误阻断代价”。

block：阻塞端口（保留配置，可自动恢复），适合用户端口
protect：保护模式（仅告警不阻断或按策略处理），适合需要观察的场景
shutdown：直接关闭端口（视型号支持），适合严格管控场景

工程建议：用户接入口用 block + 默认 5 分钟 block-delay；核心/上联口不要开启（误判代价太大）。

block、protect、shutdown 的语义必须结合型号文档确认。 不同版本对恢复方式、日志级别和组合策略的实现可能不同。配置后应通过真实测试验证告警、状态和恢复流程，而不能仅凭命令名称推断。

2_8_6 【案例故事】环路检测误开在上行口，整层楼断网

某办公楼接入交换机做安全加固，我准备给所有面向用户的端口开启环路检测。脚本原本是 set loopdetect port 1-24 enable，但现场设备 23、24 口已经改为上联聚合成员，我忘记从列表中剔除。
提交后约 15 秒，整层约 60 个终端同时失去网关。监控显示接入交换机管理 IP 仍可达，但用户 VLAN 的 ARP 和 DHCP 大量超时。我第一时间执行 show loopdetect，发现 port 23 的 isLoop=Yes、isBlock=Yes。
原因很清楚：环路检测探测报文经上联口进入汇聚，又被某种临时桥接路径或下游测试环路带回同一端口；交换机三要素匹配成功，于是把上联口判为自环并 block。上行口一 block，不是某一个用户口断，而是整台接入交换机都失去上层转发。
我立即在授权窗口执行 set loopdetect port 23,24 disable，端口恢复后业务在数分钟内回归。复盘把“上行口不开”写成硬规则：环路检测对象清单必须从 show port description 中排除所有 Uplink/To-Core/Trunk-To-* 端口，并加入配置评审。
此后任何 loopdetect 启用单都必须带三列信息：端口用途、是否上联、排除原因。没有这三列，变更单不予通过。

这个案例说明“测试环境通过”不能覆盖“生产拓扑差异”。 实验室往往没有完整汇聚、桥接设备和临时跳线，自环判定相对单纯；生产网存在跨设备转发、遗留跳线、未受控小交换机和运维临时操作。环路检测应面向真实接入边界部署，而不是简单按端口号区间批量开启。

2_8_7 完整开局模板

! Step 1：明确对象，禁止在上行口开启
!   用户口：1-20；上联口：23-24（已排除）

! Step 2：开启接入端口检测
zte(cfg)#set loopdetect port 1-20 enable

! Step 3：多 VLAN 业务按实际需要显式指定，单端口最多 8 个 VLAN
zte(cfg)#set loopdetect port 5 vlan 100 enable
zte(cfg)#set loopdetect port 5 vlan 200 enable

! Step 4：双端口互连环使用 extend（仅在确有此类风险时开启）
zte(cfg)#set loopdetect extend port 1 enable

! Step 5：风暴抑制作为第二道防线（单位与命令依版本确认）
ZXR10(config-gei_0/1/0_5)#broadcast-limit 1000

! Step 6：验证
zte#show loopdetect
zte#show loopdetect port 1
zte#show running | include loopdetect

! Step 7：测试与回退
!   模拟接入口自环 → 确认告警、isLoop、动作
!   无误判后保留；出现异常立即 disable 对应端口并复盘

“上行口不开”的论证基于故障爆炸半径。 环路检测不依赖对端配合，探测报文只要被网络返回并满足三要素就可能触发动作。若对象恰好是上联口，其下游通常包括大量接入设备、转发路径和协议通信，误 block 会同时切断多个用户口甚至整台接入交换机。接入口误 block 则通常只影响单终端或单部门，风险可控。

模板不能替代拓扑审查。 上联口不仅包括直连核心的端口，也可能包括临时调试口、跨设备堆叠链路、面向未受控网络的接口；反之，某些看似“普通口”的端口若承载汇聚业务，也不应草率开启。每次变更前用端口台账和物理连线图交叉确认。

2_8_8 环路检测故障速查

现象	原因	判据	处理
开了检测但环路没被发现	检测报文间隔 15s，需等待	`show loopdetect port <id>`	等待 1~2 个检测周期
端口被误判阻塞	下挂设备透传了探测报文	`show loopdetect port <id>` 的 isLoop	排查下挂设备，或改用指定 VLAN 检测
端口一直 block 不恢复	block-delay 未到（默认 5 分钟）	`show loopdetect`	等待或手工 `disable/enable`
检测不到指定 VLAN 的环	未指定 VLAN，只检测 PVID	`show loopdetect port <id>` 的 loopVlanNum	用 `vlan <id>` 显式指定（最多 8 个）
上联口被阻塞导致全网断	上联口误开环路检测	`show loopdetect`	上联口不开启环路检测

故障处理要区分“告警事实”和“业务影响”。 isLoop=Yes 是设备判定，端口 block 是动作结果；还需要结合终端能否获取地址、ARP 是否完成、上联统计是否中断、FDB 是否漂移来确认范围。仅凭一条告警直接 shutdown 其他端口，可能扩大事故。

2_9 笔记方法与验证清单

知识库的价值不在“命令抄得全”，而在故障发生后能迅速重建现场。 端口台账回答“这台设备应该怎么配”，抓包记录回答“当时线路上发生了什么”，环路/风暴记录回答“控制机制是否正确触发”。三类模板应互相引用，而不是分散在不同人的本地文件中。

2_9_1 【笔记方法】端口用途与配置台账模板

# 端口用途与配置台账
设备名称 / 机柜位置：
管理 IP / 型号 / 软件版本：
最后巡检日期 / 责任人：

| 端口 | 对端设备:端口 | 用途 | PVID | 成员VLAN | Auto/Fixed | Speed/Duplex | 限速 | MAC策略 | 环路检测 | 上联(Y/N) | 变更单号 |
| ---- | ------------- | ---- | ---- | -------- | --------- | ----------- | ---- | ------- | -------- | --------- | -------- |
| gei-0/1/0/5 | SW-CORE:gei-0/1/0/1 | 上联 | 100 | 100,200 | fixed | 1000/full | - | off | 禁止 | Y | CHG-001 |
| port 13 | Camera-Hall-01 | 摄像头 | 10 | 10 | auto | auto | off | fix-mac shutdown, recover 30 | 开启 | N | CHG-002 |

特殊约束：
- 光口/1000M电口：仅全双工
- 100M/1000M光口：速率不可改
- fix-mac 自动恢复：仅 shutdown 模式生效
- 上联口：禁止 loopdetect

台账更新应成为变更流程的一部分。 配置备份、端口用途、VLAN、MAC 策略和环路检测状态必须同时变化。若某人临时调整端口却只改设备、不更新台账，下一次巡检就可能把正确配置误判为异常并回退。

2_9_2 【笔记方法】镜像抓包记录模板

# 镜像抓包记录
CASE 编号：PCAP-<板块号>-<日期>-<序号>
故障现象 / 验证目标：
源端口、方向（ingress/egress）、目的端口：
抓包机位置、抓包起止时间、Wireshark 过滤条件：
业务路径：终端 → 接入口 → 上联 → …… → 服务器

配置前 show mirror：
配置步骤（可直接回放）：
show mirror（配置后）：
抓包文件：文件名、SHA256/位置、保留期限：
关键帧时间线：
- T+0.00s：Client → DHCP Discover
- T+0.12s：未见 Offer → 怀疑上联/服务器侧
结论：定位到哪一跳、下一步验证项：
清理命令：

抓包记录必须把“看到什么”与“说明什么”分开。 原始报文或过滤结果属于证据；从证据推出的故障点属于判断。若两者混写，后续复盘无法区分事实与推断。对于 DHCP、ARP、IGMP、TCP 握手等关键事件，应按时间戳列出请求与应答是否成对出现。

2_9_3 【笔记方法】环路/风暴事件记录模板

# 环路/风暴事件记录
EVENT 编号：LOOP-<日期>-<序号>
发生时间 / 发现方式（告警、监控、用户报障）：
影响范围：单端口 / 单设备 / 单楼层 / 多楼层：

拓扑快照：
  SW-ACCESS(portlist) — uplink — SW-CORE
  下挂设备/临时跳线/测试线：

环路检测配置：
  show loopdetect：
  检测端口、指定 VLAN、动作、block-delay：
STP/BPDU 保护状态：
风暴抑制配置与阈值：

时间线：
- T0：业务异常
- T1：show loopdetect port X 显示 isLoop/isBlock
- T2：临时隔离/恢复操作
- T3：业务验证通过

根因：用户自环 / 下挂桥接设备 / 配置遗漏 / 拓扑变化 / 待定
修复与预防：
- 删除临时跳线 / 调整 loopdetect 对象 / 补充 STP 或 BPDU 保护
回退验证：
复盘关联考点：loopdetect 三要素、上行口不开、风暴抑制分层

事件记录的核心价值是防止同类事故重复发生。 每条记录至少应形成一个可执行改进：变更评审项、台账字段、监控规则、接口禁用策略或测试步骤。若复盘只停留在“下次注意”，说明没有把现场经验沉淀为流程。

2_9_4 【验证】端口—VLAN—MAC—镜像闭环验证表

验证命令	预期结果/关键字段	不符时的排查方向
`show port <id>`	Status=Up、Auto/Speed/Duplex 与两端设计一致	检查线缆、光模块、disable、auto/fixed 不对称
`show port <id> statistics`	CRC、Collision、Drop 在清零后无明显增长	CRC→物理层；Late Collision→双工；Drop→拥塞/限速/ACL
`show port <id> qos`	ingress/egress 限速、rate、模式符合设计	核对 kbps 换算、方向、tcpdrop/flowcontrol 选择
`show port <id>`（security）	macaddress、fix-mac、auto-recover-time 已配	确认限制数、shutdown/protect、恢复仅对 shutdown 生效
`show vlan` + `show port <id>`	PVID、tag/untag、上联放行与业务 VLAN 一致	检查 PVID、成员关系、上联 tag、FID/VID 映射
`show fdb mac <mac>`	MAC 所在 FID/VLAN、端口、类型稳定	查漂移、老化、静态绑定 FID、端口安全动作
`show fdb port <id>`	有合法动态/静态 MAC，数量未超过 macaddress	查 Hub/NIC 虚拟化、fix-mac、security、私接设备
`show mirror`	源/目的口、方向正确，目的口未被业务误用	查目的口独占、带宽溢出、遗留镜像、Tag 处理
`show loopdetect`	仅接入口开启，interval=15s、block-delay=5min	查上联误开、等待周期、恢复时间、VLAN 指定
`show loopdetect port <id>`	isUp、isLoop、isBlock、loopVlanNum 与场景匹配	查下挂透传、探测三要素、扩展检测、误判
`clear statistics` + 复现 + `show statistics`	只看复现窗口增量	避免历史错包误导，先清零再观察
业务测试（DHCP/ARP/ping/视频）	请求与应答成对，吞吐与限速目标匹配	镜像抓包，核对 VLAN、MAC、ACL、MTU、QoS

验证表不是一次性的“show 集合”，而是变更的验收标准。 每次端口、VLAN、MAC 安全、镜像或环路检测变更，都应逐项勾选；任何一项不符合预期，都不能仅凭业务初步恢复而关闭变更。尤其要保留 show 的前后输出，便于回退和责任追溯。

2_10 考点速记与自检清单

本节要解决什么问题：最后是考点速记与自检清单。

2_10_1 考点速记【ZCIA】

端口自协商缺省开启；手工设速率或双工后自协商自动关闭。
光口与 1000M 电口只能全双工；100M/1000M 光口速率不可改。
MAC 数目限制缺省关闭；固化自动恢复缺省 30 分钟且仅对 shutdown 生效。
限速单位 kbps（64~256000）；tcpdrop 对 TCP 友好，flowcontrol 会队头阻塞。
FDB 老化默认 240s，范围 15~3600s。
静态 FDB 绑定使用 FID（默认 FID=VID）。
镜像 ingress/egress 的方向定义与四大限制（独占、溢出、性能、用完删除）。
MAC 漂移是环路与私接的重要指纹。
show port statistics 三大字段故障映射：CRC→物理、Collision→双工、Drop→拥塞/策略。
排障三步清零法：清零 → 复现 → 看增量。
环路检测缺省关闭；检测报文间隔 15 秒，block-delay 5 分钟，单端口最多检测 8 个 VLAN。
环路检测判据三要素：源 MAC == 本交换机 MAC、端口号相同、判别字段匹配。
环路检测独立于 STP，不依赖对端配合，是 STP 的兜底保险。
体系B 风暴抑制用 broadcast-limit；巨帧 jumbo-frame（默认 1560，开启后 9216）；端口别名 byname。
防环三层保险：STP 预防 → 环路检测兜底 → 风暴抑制限速；上联口不开环路检测。

【ZCIP】 应能根据业务类型解释 auto/fixed、PAUSE/tcpdrop、MAC 限制/fix-mac、老化时间和风暴阈值的取舍，并把端口台账、变更回退、镜像取证写成可执行方案。
【ZCIE】 应能由“上联 block 导致整层断网”“fix-mac shutdown 后无恢复”“抓包缺失但统计增长”等现象反推配置对象、故障边界和验证顺序，并说明为何不能仅靠缩短老化时间或盲目启用 PAUSE 解决。

2_10_2 本板块自检清单

posted @ 2026-09-16 06:53 睡到自然醒的猪阅读(12) 评论(0) 收藏举报

刷新页面返回顶部

板块2 · 二层交换基础：端口、MAC 表与镜像

板块2 · 二层交换基础：端口、MAC 表与镜像

2_1 端口参数体系总览

2_1_1 端口能力全景（一个端口身上有多少开关）

2_1_2 端口配置命令全表（体系A）

2_1_3 【必须记住】四条缺省行为与硬性约束

2_2 自协商、速率与双工

2_2_1 自协商到底协商了什么

2_2_2 双工不匹配的三种组合

2_2_3 配置与验证

2_2_4 决策建议（现网原则）

2_3 流量控制与带宽限速

2_3_1 流控（PAUSE 帧）是双刃剑

2_3_2 配置与选型

2_3_3 出入方向限速（64 kbps ~ 256000 kbps）

2_3_4 单位换算与常见错误

2_4 端口安全：MAC 限制与固化

2_4_1 三种能力对比

2_4_2 典型配置：摄像头/打印机接入端口加固

2_4_3 【ZCIP/ZCIE】MAC 限制为什么防不住 Hub 下挂

2_5 MAC 表（FDB）操作与转发分析

2_5_1 FDB 表项结构

2_5_2 FDB 命令全表

2_5_3 静态绑定的三个真实用途

2_5_4 【踩坑】静态绑定用的是 FID，不是 VID

2_5_5 老化时间的工程取舍

2_5_6 MAC 漂移：环路与私接的“指纹”

2_5_7 排查决策树

2_6 端口镜像与抓包

2_6_1 镜像命令全表

2_6_2 镜像方向与抓包位置

2_6_3 配置实例：抓取 IPTV 机顶盒的 IGMP 交互

2_6_4 【踩坑】镜像的四个限制与注意事项

2_6_5 Wireshark 常用过滤表达式

2_7 广播风暴抑制、巨帧与端口别名

2_7_1 广播风暴抑制：限制损害半径

2_7_2 巨帧（1560 → 9216）

2_7_3 端口别名（byname）

2_8 环路检测 loopdetect

2_8_1 三种防环机制的分工

2_8_2 环路检测原理（自环探测）

2_8_3 体系A（盒式）环路检测命令全表

2_8_4 配置实例（体系A）

2_8_5 体系B（机架式/新版）环路检测与配套配置

2_8_6 【案例故事】环路检测误开在上行口，整层楼断网

2_8_7 完整开局模板

2_8_8 环路检测故障速查

2_9 笔记方法与验证清单

2_9_1 【笔记方法】端口用途与配置台账模板

2_9_2 【笔记方法】镜像抓包记录模板

2_9_3 【笔记方法】环路/风暴事件记录模板

2_9_4 【验证】端口—VLAN—MAC—镜像闭环验证表

2_10 考点速记与自检清单

2_10_1 考点速记【ZCIA】

2_10_2 本板块自检清单

公告