板块10 · 综合实战项目（园区网 + IPTV 承载网）
板块10 · 综合实战项目（园区网 + IPTV 承载网）
目标与定位：本板块不是“实验命令汇编”，而是把前九个板块的二层、三层、组播、QoS、保护与运维能力，压缩为两个可交付的完整工程：中型园区网与 IPTV 承载网。
交付节奏固定为 需求 → 规划 → 拓扑 → 配置 → 测试 → 割接 → 回退；每一阶段都要有可追溯的输入、配置、验证和回退证据。
【ZCIP】重在综合设计、整网联调与方案答辩；【ZCIE】重在组播/IPTV 深度、容量核算、异常定位与“为什么这么设计”的解释能力。
本板块保留全部规划表、拓扑、逐设备脚本、测试矩阵和割接回退逻辑；同时消除命令体系混用、引用不存在接口和非中兴原生 STP 写法。
10_1 项目一：中型园区网（ZCIP 级）
本节要解决什么问题：第一个项目是中型园区网。它把 VLAN、聚合、MSTP、VRRP、OSPF、QoS 串成一套可交付方案，按真实节奏从需求走到验收。
10_1_1 从业务边界开始：先确定角色、隔离域和故障域
园区网设计的起点不是“选设备”，而是把业务角色、访问边界和故障边界拆开。办公、无线、安防、语音、访客和管理各自对应独立 VLAN、地址块与转发策略；核心仅承担高速交换与网关，接入承担端口角色和终端隔离。这样做的好处是：一个业务域出现广播、MAC 漂移或非法接入时，不会直接波及全网的 DHCP、语音或摄像头。
某集团新建办公楼，需建设一张承载办公、无线、安防、语音的综合园区网。
业务需求：
① 办公有线：约 400 个信息点，分 3 个楼层
② 无线覆盖：AP 约 60 个，员工无线与访客无线分离
③ 安防监控：摄像头 80 路，仅允许 NVR 与安防客户端访问
④ IP 语音：IP 电话 100 部，要求低时延、优先保障
⑤ 访客网络：仅允许访问互联网，禁止访问内网
⑥ 远程管理：全网设备可网管，管理流量与业务流量隔离
非功能需求：
· 核心双机热备，单台核心故障业务不中断
· 关键链路冗余，倒换时间 < 1 秒（核心层 < 50ms 更佳）
· 具备广播风暴抑制与环路防护能力
· 具备完善的可观测性（日志、镜像、统计）
容量只是需求，不是网络上限。 400 个办公点分 3 层，平均每层约 133 点；接入交换机不宜全部堆叠成一张无分层平面，而应按楼层形成“核心—接入”两层。60 个 AP、80 路摄像头、100 部电话不应共用一个广播域：AP 管理、终端业务、摄像头和语音分别规划，既便于 DHCP 策略，也便于 ACL、镜像和 QoS 精准命中。若将来扩到 800 个办公点，优先横向复制“每楼层接入 + 楼层聚合”的结构，而不是继续扩大单个接入交换机 VLAN。
倒换 < 1 秒必须拆成两层目标。 LACP 短超时、MSTP 点到点快速收敛主要解决二层故障；VRRP 解决的是网关缺省路由器和三层 ARP 映射的切换。素材要求核心倒换尽可能小于 50 ms，这更接近链路聚合和 STP 无阻塞切换的理想收敛目标；VRRP 端到端业务感知还会受 ARP 学习、上游路由收敛、DHCP 续租等影响。因此验收时要分别测试“拔上行链路”“关闭一台核心”“关闭 VRRP 上行跟踪接口”，不能只用一个 ping 总时长概括所有倒换。
10_1_2 拓扑必须体现转发层次、冗余关系和复制点
┌──────────┐
│ 出口防火墙│
│ (NAT/安全)│
└────┬─────┘
│ 10.0.200.0/30
┌──────────────┴──────────────┐
│ │
┌──────▼──────┐ ┌──────▼──────┐
│ CORE-01 │════聚合══════│ CORE-02 │
│ 核心交换机 │ (LACP 2×10G)│ 核心交换机 │
│ 10.0.0.1/32 │ │ 10.0.0.2/32 │
└───┬─────┬───┘ └───┬─────┬───┘
│ │ │ │
聚合组1 聚合组2 聚合组1 聚合组2
│ │ │ │
└──┬──┴──────────┬───────────┴──┬──┘
│ │ │
┌──────▼─────┐ ┌─────▼──────┐ ┌─────▼─────┐
│ ACC-1F-01 │ │ ACC-2F-01 │ │ ACC-3F-01 │
│ 1层接入 │ │ 2层接入 │ │ 3层接入 │
└──────┬─────┘ └─────┬──────┘ └─────┬─────┘
│ │ │
PC/AP/摄像头 PC/AP/摄像头 PC/AP/摄像头
三层网关位置：核心（CORE-01/02 上跑 VRRP）
二层环路防护：MSTP（核心-接入）
风暴抑制与观测：接入端口限速/风暴抑制；核心镜像、日志、SNMP
这张图的关键不是画得漂亮，而是每个连接都有用途。 两台核心之间的聚合是控制平面与数据平面双承载：既传递互为主备的业务 VLAN，也保证 MSTP 域、OSPF 邻接和 VRRP 心跳有稳定路径。接入到两台核心建议形成双上行；若实际只有单上行聚合组，仍可获得链路级冗余，但没有核心设备级冗余，验收必须如实标注，不能把“单核心故障”写成可通过项。
组播复制点在核心，组播接收复制点则应尽可能靠近用户。 园区网本身并非 IPTV 网络，但摄像头、无线组播、视频会议等未来业务也应预留 TC2。接入层只把必要 VLAN 向上透传，避免把 100 个业务 VLAN 无差别放进每一个 trunk。这里的取舍是：trunk 越宽，配置越省；但广播域、MAC 表、故障域也越大。因此下联 trunk 应遵循“该楼层用到哪些 VLAN，就放哪些 VLAN”。
10_1_3 规划表要能回答“为什么”与“还能怎么改”
VLAN 与地址规划：隔离优先，地址块连续便于汇总
| VLAN ID | 名称 | 网段 | 网关（VRRP 虚拟） | 用途 | 规划取舍 |
|---|---|---|---|---|---|
| 100 | MGMT | 10.0.100.0/24 | 10.0.100.1 | 设备管理 | 独立管理网段，ACL 限制源地址；不承载终端业务 |
| 10 | Office-1F | 192.168.10.0/24 | 192.168.10.1 | 1 层办公 | 按楼层划分，故障域和 DHCP 策略清晰 |
| 11 | Office-2F | 192.168.11.0/24 | 192.168.11.1 | 2 层办公 | 同 Office 域，跨层不要求二层漫游 |
| 12 | Office-3F | 192.168.12.0/24 | 192.168.12.1 | 3 层办公 | 三层互通由核心控制 |
| 50 | AP-Mgmt | 10.0.50.0/24 | 10.0.50.1 | AP 管理 | AP 自身管理流量与 STA 业务分离 |
| 60 | STA-User | 192.168.60.0/24 | 192.168.60.1 | 员工无线 | 员工终端单独认证和策略 |
| 70 | Guest | 192.168.70.0/24 | 192.168.70.1 | 访客无线 | 默认仅 NAT 出口，禁访内网 |
| 40 | Camera | 192.168.40.0/24 | 192.168.40.1 | 安防 | 摄像头、NVR、安防客户端专用 |
| 45 | Voice | 10.0.45.0/24 | 10.0.45.1 | IP 语音 | 独立语音域，便于 DSCP、队列和电话准入 |
| 200 | Link-FW | 10.0.200.0/30 | — | 上联出口 | 核心与防火墙三层互联，避免借用业务 VLAN |
为什么不用一个 192.168.0.0/16 直接按端口划分？ 技术上可行，但 400 个办公终端、100 部电话、80 路摄像头和访客共处大广播域时，DHCP 冲突、ARP 泛洪、非法扫描、镜像范围都会恶化。按角色划分后，访问控制可以落在三层网关，QoS 可以基于 VLAN/DSCP 命中，业务也可以独立扩容。替代方案有两种：第一，办公按部门而非楼层划分 VLAN，适合跨层移动办公，但需要无线控制器与终端认证协同；第二，语音与摄像头采用独立物理网，适合极高安全要求，但成本和管理复杂度上升。本项目的平衡点是按业务角色为主、楼层为辅。
地址块连续性服务于路由汇总，但不可机械汇总。 192.168.10/11/12 三个办公网可表达为 192.168.8.0/21，Camera 40、Voice 45、Guest 70 不建议和办公网强行拼成一条汇总；否则防火墙或核心 ACL 会出现“允许整个汇总，却忘了拒绝 Guest→Office”的漏洞。现场应采用“汇总用于路由，明细用于控制”的双轨思路：OSPF 可汇总发布，ACL 则保留业务明细。
VRRP 主备负载分担：让两台核心都有业务价值
| VLAN | Master | Backup | VRRP 优先级 | 设计意图 |
|---|---|---|---|---|
| 10、11、12、50 | CORE-01 | CORE-02 | Master 120 / Backup 100 | 办公与 AP 管理主走 CORE-01 |
| 40、60、70、45 | CORE-02 | CORE-01 | Master 120 / Backup 100 | 安防、员工无线、访客、语音主走 CORE-02 |
所谓“负载分担”不是让同一网关同时使用两台核心转发。 VRRP 同一虚拟网关在正常状态下只有一个 Master，避免 MAC/ARP 冲突；这里的主备分担，是把不同业务 VLAN 的 Master 分别放在两台核心上，使两台设备都承担本机网关 CPU、ARP、DHCP 中继和部分三层转发。替代方案有双活网关、多 VRRP 组、Anycast 网关等，但复杂度更高；本场景的 VRRP 主备已足以满足“单机故障业务不中断”。
优先级差必须配合 track 和抢占延时。 优先级差 20 只是手工角色，并不代表上行链路失效后应让位。CORE-01 对上行口 gei-0/1/0/1 配置 track，可降低 30，使 Backup 的 100 高于故障后的 90，从而实现上行故障后业务切换到 CORE-02。生产网还应给上行链路、互联聚合和关键 OSPF 邻居设计一致的降级量；否则上行断了但 VRRP 仍不切换，会形成“有网关、没出口”的黑 hole。
MSTP 实例规划：区域一致性优先于实例数量
| 实例 | VLAN | 主根 | 备根 | 规划逻辑 |
|---|---|---|---|---|
| 0（IST） | 1、100、200 | CORE-01 | CORE-02 | 承载公共/管理/互联，保证区域基线连续 |
| 1 | 10、11、12、50 | CORE-01 | CORE-02 | 办公与 AP 管理跟随 CORE-01 |
| 2 | 40、45、60、70 | CORE-02 | CORE-01 | 安防、语音、无线跟随 CORE-02 |
MSTP 的价值是让不同 VLAN 集走不同无环路径，而不是追求实例越多越好。 本方案三个实例足以映射两个核心的 VRRP 主备关系；若把所有 VLAN 塞进 instance 0，虽然配置简单，却可能导致 CORE-02 大部分业务在核心互联链路上被阻塞，失去主备分担意义。反过来，每个 VLAN 一个实例会增加 BPDU、运维和故障定位成本。
区域三要素必须全网一致：name、revision、VLAN-to-instance。 只有这三个要素一致，多台设备才被视作同一 MST 区域；否则会出现 CIST 边界，实例映射可能错乱。CORE-01/02 与 ACC 的 ZTE-CAMPUS、revision 1、instance 1/2 映射必须逐项核对。接入层 edge-port 只面向终端，上联聚合口应配置为 point-to-point，绝不能在面向上游的口开启 loopdetect。
QoS 队列规划：先保控制与语音，再保障视频，最后公平处理普通流量
| 队列 | 业务 | 802.1p | DSCP | 调度 | 工程含义 |
|---|---|---|---|---|---|
| TC3 | 网络控制、语音 | 6-7 | 46、48-56 | SP | 路由协议、语音 EF 最高优先 |
| TC2 | 安防视频、组播 | 4-5 | 32-36 | SP | 摄像头、视频会议、组播低丢包 |
| TC1 | 办公、员工无线 | 0、3 | 0、18-26 | WFQ | 普通业务公平共享 |
| TC0 | 访客、下载备份 | 1-2 | 8-16 | WFQ | 带宽受限，避免影响生产业务 |
队列不是“设了就加速”。 TC3 采用 SP，保证语音和网络控制最优先；但若把大量数据标记为 46，反而会饿死其他队列。因此必须在信任边界重新标记：核心互联、语音服务器、摄像头入口可信，普通办公和访客不可信。TC2 对视频的效益主要来自低丢包与有界时延，不能把办公大文件也放进 TC2。TC0/TC1 采用 WFQ，是公平性、配置复杂度与突发吸收能力的折中；拥塞点明确的链路也可用 WRR/SP+限流组合，命令形态依型号和版本确定。
10_1_4 配置实施：逐设备脚本以“可粘贴、可验证、可回退”为目标
【步骤 1】CORE-01 基础、VLAN 与聚合
! ========== 基础 ==========
ZXR10(config)#hostname CORE-01
ZXR10(config)#interface loopback1
ZXR10(config-if)#ip address 10.0.0.1 255.255.255.255
! ========== VLAN 创建 ==========
ZXR10(config)#vlan 100
ZXR10(config-vlan)#name MGMT
ZXR10(config)#vlan 10
ZXR10(config-vlan)#name Office-1F
ZXR10(config)#vlan 11
ZXR10(config-vlan)#name Office-2F
ZXR10(config)#vlan 12
ZXR10(config-vlan)#name Office-3F
ZXR10(config)#vlan 40
ZXR10(config-vlan)#name Camera
ZXR10(config)#vlan 45
ZXR10(config-vlan)#name Voice
ZXR10(config)#vlan 50
ZXR10(config-vlan)#name AP-Mgmt
ZXR10(config)#vlan 60
ZXR10(config-vlan)#name STA-User
ZXR10(config)#vlan 70
ZXR10(config-vlan)#name Guest
ZXR10(config)#vlan 200
ZXR10(config-vlan)#name Link-FW
! ========== 核心互联聚合（CORE-01 ↔ CORE-02） ==========
ZXR10(config)#interface smartgroup10
ZXR10(config-smartgroup10)#smartgroup mode 802.3ad
ZXR10(config-smartgroup10)#smartgroup load-balance src-dst-ip
ZXR10(config)#interface xgei-0/1/0/1
ZXR10(config-if)#smartgroup 10 mode active
ZXR10(config-if)#lacp timeout short
ZXR10(config)#interface xgei-0/1/0/2
ZXR10(config-if)#smartgroup 10 mode active
ZXR10(config-if)#lacp timeout short
ZXR10(config)#interface smartgroup10
ZXR10(config-smartgroup10)#switchport mode trunk
ZXR10(config-smartgroup10)#switchport trunk vlan 10,11,12,40,45,50,60,70,100
! ========== 下联接入聚合组 ==========
! 聚合组 1 接 ACC-1F-01，聚合组 2 接 ACC-2F-01，聚合组 3 接 ACC-3F-01
ZXR10(config)#interface smartgroup1
ZXR10(config-smartgroup1)#smartgroup mode 802.3ad
ZXR10(config)#interface gei-0/2/0/1
ZXR10(config-if)#smartgroup 1 mode active
ZXR10(config-if)#lacp timeout short
ZXR10(config)#interface gei-0/2/0/2
ZXR10(config-if)#smartgroup 1 mode active
ZXR10(config-if)#lacp timeout short
ZXR10(config)#interface smartgroup1
ZXR10(config-smartgroup1)#switchport mode trunk
ZXR10(config-smartgroup1)#switchport trunk vlan 10,40,50,60,70,100
聚合配置要先建组、再绑口、最后做业务。 顺序混乱时，成员口可能仍处于 access 状态或已有 PVID，导致 trunk VLAN 不生效。核心互联口的 xgei-0/1/0/1/2 必须与实际板卡、光模块和连纤一致；脚本中的接口仅为规划名，现场应以 show interface brief 或 ? 确认。两端 LACP 模式、短超时、负载算法应尽量一致；若对端不支持短超时，则先保持默认长超时，避免误判伙伴离线。
下联 trunk 采用最小授权集合。 ACC-1F-01 的示例仅需 10、40、50、60、70、100；不把 11、12 提前加进 1 层 trunk，能减少广播和未知单播范围。三层接入或跨楼层扩展时再按接入交换机实际业务追加。CORE-02 的 smartgroup 2/3 与 CORE-01 形成交叉上行，应在拓扑表中记录“接入左上行、右上行分别接 CORE-01/02”，否则双上行物理链路虽在，逻辑根路径仍可能不对称。
【步骤 2】CORE-01 三层接口、DHCP 中继与 VRRP
! ========== 上联出口物理口（先建接口，供 VRRP track 引用） ==========
ZXR10(config)#interface gei-0/1/0/1
ZXR10(config-if)#description UPLINK-TO-FW
ZXR10(config-if)#switchport mode access
ZXR10(config-if)#switchport access vlan 200
! ========== 管理 VLAN ========== ! CORE-01 为实例0/1相关Master，MGMT按统一主根规划
ZXR10(config)#interface vlan 100
ZXR10(config-if)#ip address 10.0.100.2 255.255.255.0
ZXR10(config-if)#vrrp 100 ip 10.0.100.1
ZXR10(config-if)#vrrp 100 priority 120
ZXR10(config-if)#vrrp 100 preempt
ZXR10(config-if)#vrrp 100 preempt delay 10
ZXR10(config-if)#vrrp 100 track interface gei-0/1/0/1 30
! ========== 办公 VLAN（CORE-01 为 Master） ==========
ZXR10(config)#interface vlan 10
ZXR10(config-if)#ip address 192.168.10.2 255.255.255.0
ZXR10(config-if)#vrrp 10 ip 192.168.10.1
ZXR10(config-if)#vrrp 10 priority 120
ZXR10(config-if)#vrrp 10 preempt
ZXR10(config-if)#vrrp 10 preempt delay 10
ZXR10(config-if)#vrrp 10 track interface gei-0/1/0/1 30
ZXR10(config-if)#ip helper-address 10.0.100.10
ZXR10(config)#interface vlan 11
ZXR10(config-if)#ip address 192.168.11.2 255.255.255.0
ZXR10(config-if)#vrrp 11 ip 192.168.11.1
ZXR10(config-if)#vrrp 11 priority 120
ZXR10(config-if)#vrrp 11 preempt
ZXR10(config-if)#vrrp 11 preempt delay 10
ZXR10(config-if)#vrrp 11 track interface gei-0/1/0/1 30
ZXR10(config-if)#ip helper-address 10.0.100.10
ZXR10(config)#interface vlan 12
ZXR10(config-if)#ip address 192.168.12.2 255.255.255.0
ZXR10(config-if)#vrrp 12 ip 192.168.12.1
ZXR10(config-if)#vrrp 12 priority 120
ZXR10(config-if)#vrrp 12 preempt
ZXR10(config-if)#vrrp 12 preempt delay 10
ZXR10(config-if)#vrrp 12 track interface gei-0/1/0/1 30
ZXR10(config-if)#ip helper-address 10.0.100.10
ZXR10(config)#interface vlan 50
ZXR10(config-if)#ip address 10.0.50.2 255.255.255.0
ZXR10(config-if)#vrrp 50 ip 10.0.50.1
ZXR10(config-if)#vrrp 50 priority 120
ZXR10(config-if)#vrrp 50 preempt
ZXR10(config-if)#vrrp 50 preempt delay 10
ZXR10(config-if)#vrrp 50 track interface gei-0/1/0/1 30
ZXR10(config-if)#ip helper-address 10.0.100.10
! ========== 安防/无线/语音 VLAN（CORE-01 为 Backup，优先级 100） ==========
ZXR10(config)#interface vlan 40
ZXR10(config-if)#ip address 192.168.40.2 255.255.255.0
ZXR10(config-if)#vrrp 40 ip 192.168.40.1
ZXR10(config-if)#vrrp 40 priority 100
ZXR10(config-if)#vrrp 40 preempt
ZXR10(config-if)#vrrp 40 preempt delay 10
ZXR10(config-if)#ip helper-address 10.0.100.10
ZXR10(config)#interface vlan 45
ZXR10(config-if)#ip address 10.0.45.2 255.255.255.0
ZXR10(config-if)#vrrp 45 ip 10.0.45.1
ZXR10(config-if)#vrrp 45 priority 100
ZXR10(config-if)#vrrp 45 preempt
ZXR10(config-if)#vrrp 45 preempt delay 10
ZXR10(config-if)#ip helper-address 10.0.100.10
ZXR10(config)#interface vlan 60
ZXR10(config-if)#ip address 192.168.60.2 255.255.255.0
ZXR10(config-if)#vrrp 60 ip 192.168.60.1
ZXR10(config-if)#vrrp 60 priority 100
ZXR10(config-if)#vrrp 60 preempt
ZXR10(config-if)#vrrp 60 preempt delay 10
ZXR10(config-if)#ip helper-address 10.0.100.10
ZXR10(config)#interface vlan 70
ZXR10(config-if)#ip address 192.168.70.2 255.255.255.0
ZXR10(config-if)#vrrp 70 ip 192.168.70.1
ZXR10(config-if)#vrrp 70 priority 100
ZXR10(config-if)#vrrp 70 preempt
ZXR10(config-if)#vrrp 70 preempt delay 10
ZXR10(config-if)#ip helper-address 10.0.100.10
! ========== 上联出口（三层互联，跑 OSPF） ==========
ZXR10(config)#interface vlan 200
ZXR10(config-if)#ip address 10.0.200.2 255.255.255.252
ZXR10(config)#router ospf 1
ZXR10(config-router)#router-id 10.0.0.1
ZXR10(config-router)#network 10.0.0.1 0.0.0.0 area 0
ZXR10(config-router)#network 10.0.200.0 0.0.0.3 area 0
ZXR10(config-router)#network 192.168.10.0 0.0.0.255 area 0
ZXR10(config-router)#network 192.168.11.0 0.0.0.255 area 0
ZXR10(config-router)#network 192.168.12.0 0.0.0.255 area 0
ZXR10(config-router)#network 192.168.40.0 0.0.0.255 area 0
ZXR10(config-router)#network 192.168.60.0 0.0.0.255 area 0
ZXR10(config-router)#network 192.168.70.0 0.0.0.255 area 0
ZXR10(config-router)#network 10.0.45.0 0.0.0.255 area 0
ZXR10(config-router)#network 10.0.50.0 0.0.0.255 area 0
ZXR10(config-router)#network 10.0.100.0 0.0.0.255 area 0
track 引用的接口必须先真实创建。 规划中 VRRP track 使用 gei-0/1/0/1，在配置 SVI 之前先建立该物理口、命名并放入 VLAN 200，避免“track 对象不存在”导致 track 不生效。若设备上行实际走 smartgroup 上联而非物理口，则 track 应改为相应 smartgroup；判断依据是三层出口实际承载接口，而不是配置脚本里随手写的一个 GE 口。
preempt delay 是防震荡的保险。 若不设置延时，链路短暂抖动恢复后，Master 会立即抢占，正在迁移的 ARP、DHCP 和 TCP 连接可能再次中断。10 秒仅为规划值，需结合现网 OSPF 收敛、防火墙会话同步和设备重启时间调整；原则是在上游路由已经稳定后再抢占，而不是越快越好。
DHCP 中继必须能回程到服务器。 ip helper-address 解决的是从客户端广播到服务器单播，但服务器回包依赖核心到 10.0.100.10 的路由和管理 VLAN 的可达性。防火墙还需放行 DHCP/BOOTP，不能只在交换机配 helper。若使用多台 DHCP 服务器，应按实际软件能力配置多个 helper；若 DHCP 服务器跨三层且存在 ACL，优先从“中继—服务器—地址池”三段同时抓包。
【步骤 3】CORE-01 MSTP：采用中兴原生 spantree 配置模式
! ---------- 进入 STP 配置模式并全局启用（体系B 全局 STP 默认关闭！） ----------
ZXR10(config)#spantree
ZXR10(config-stp)#enable
ZXR10(config-stp)#mode mstp
! ---------- MST 区域三要素 ----------
ZXR10(config-stp)#mst name ZTE-CAMPUS
ZXR10(config-stp)#mst revision 1
ZXR10(config-stp)#instance 1 vlan 10,11,12,50
ZXR10(config-stp)#instance 2 vlan 40,45,60,70
! ---------- 实例优先级（主根 4096，备根 8192） ----------
ZXR10(config-stp)#instance 0 priority 4096
ZXR10(config-stp)#instance 1 priority 4096
ZXR10(config-stp)#instance 2 priority 8192
! ---------- 端口级参数 ----------
ZXR10(config-stp)#interface smartgroup10
ZXR10(config-stp-if-smartgroup10)#enable
ZXR10(config-stp-if-smartgroup10)#packet-type ieee
ZXR10(config-stp-if-smartgroup10)#link-type point-to-point
ZXR10(config-stp-if-smartgroup10)#exit
ZXR10(config-stp)#interface smartgroup1
ZXR10(config-stp-if-smartgroup1)#enable
ZXR10(config-stp-if-smartgroup1)#packet-type ieee
ZXR10(config-stp-if-smartgroup1)#link-type point-to-point
ZXR10(config-stp-if-smartgroup1)#exit
ZXR10(config-stp)#exit
! ---------- 验证 ----------
ZXR10(config)#show spantree mst-config
ZXR10(config)#show spantree instance 0
ZXR10(config)#show spantree instance 1
ZXR10(config)#show spantree instance 2
ZXR10(config)#show spantree interface smartgroup1
ZXR10(config)#show spantree interface smartgroup10
MSTP 必须使用中兴原生 spantree 模式，不应在同一体系B配置块中混入 spanning-tree vlan ... root 等其它厂商语法。 核心配置链是 spantree → enable → mode mstp，再设置 name、revision、instance 与端口参数；show spantree 验证的是区域一致性、根桥、端口角色和状态。不同版本可能是 smartgroup 端口进入方式、priority 取值范围略有差异，因此脚本落地前应在测试机用 ? 确认；但“区域三要素 + 实例优先级 + 点到点快速收敛”的设计原则不变。
为什么 CORE-02 要把 instance 2 设为 4096、instance 1 设为 8192？ 因为 VRRP Master 应尽量与 MSTP 根桥对齐：CORE-01 是 instance 1 的 root，负责办公和 AP；CORE-02 是 instance 2 的 root，负责安防、语音和无线。这样本地网关、下行转发路径和 STP 根端口方向一致，能减少跨核心互联链路的非必要转发。替代做法是两台核心都为 instance 0 主备、所有业务仅用 VRRP 分担，配置更简单；但当接入双上行时，可能出现某些 VLAN 的最优路径与网关位置不一致，故本方案选择按业务拆分实例。
【步骤 4】CORE-01 QoS：体系B 不出现体系A 的 set qos
! ========== 体系 A（盒式）写法要点，仅用于接入交换机，不要粘贴到体系B核心 ==========
! 映射原则与完整命令见板块7（7_5_1 IPTV 与语音队列规划）；此处只强调落地要点：
! ① 调度模型先定：语音/网管走最高队列，其余按业务分配；
! ② CoS→TC 与 DSCP→TC 两套映射都要写，避免只信任一种标记；
! ③ 办公与访客必须落到不同队列，否则访客大流量会挤占办公；
! ④ 配完用 show qos priority-map 与 show qos queue-schedule 双向核对。
! ========== 体系 B 配置思路（命令以设备实际为准） ==========
! 第一步：全局定义队列调度模型；拥塞发生时 TC3 优先于 TC2，TC2 优先于 TC1/TC0。
! 第二步：建立 CoS→TC、DSCP→TC 映射；信任边界重新标记，不信任终端原始 DSCP。
! 第三步：在面向接入的上行口与面向核心的下行口应用调度；确保端到端队列方向一致。
! 第四步：对访客和备份业务配置令牌桶/带宽限制，防止 TC0 侵占 TC1。
! 第五步：验证队列命中计数、丢包计数和时延；空跑时队列计数不会增长，必须用流量验证。
体系A与体系B必须物理或逻辑隔离，不能在同一份 CORE 脚本中混用。 本项目中 CORE-01/02 为体系B，QoS 使用 qos 相关配置模式；ACC 若是体系A盒式，才可使用 set qos。因此此处将 set qos 明确标注为体系A示例，避免“把盒式命令粘贴到机架式核心”的常见错误。实际设备可能采用 MQC、全局队列模板或接口策略，具体关键字、TC 数量和取值范围须通过 qos ?、show qos 确认。
QoS 验收必须观察拥塞点。 空载时所有队列都“正常”，无法证明 TC3/TC2 有效。正确方法是：在核心上行口制造受控拥塞，采集语音/视频和办公流量，检查高优先级队列丢包是否显著低于低优先级队列；同时确认普通业务不会被完全饿死。若 SP 严格优先级导致 TC0 长期零吞吐，应改为 SP+带宽下限或 WRR/SP 混合模型。
【步骤 5】接入交换机 ACC-1F-01（体系A 盒式）
zte>enable
zte#configure terminal
zte(cfg)#hostname ACC-1F-01
! ========== VLAN ==========
zte(cfg)#set vlan 10 enable
zte(cfg)#set vlan 40 enable
zte(cfg)#set vlan 50 enable
zte(cfg)#set vlan 60 enable
zte(cfg)#set vlan 70 enable
zte(cfg)#set vlan 100 enable
zte(cfg)#create vlan 10 name Office-1F
zte(cfg)#create vlan 40 name Camera
zte(cfg)#create vlan 50 name AP-Mgmt
zte(cfg)#create vlan 60 name STA-User
zte(cfg)#create vlan 70 name Guest
zte(cfg)#create vlan 100 name MGMT
! ========== 上联聚合（双上行到两台核心） ==========
zte(cfg)#set lacp enable
zte(cfg)#set lacp aggregator 1 add port 23-24
zte(cfg)#set lacp aggregator 1 mode dynamic
zte(cfg)#set lacp port 23-24 mode active
zte(cfg)#set lacp port 23-24 timeout short
zte(cfg)#set vlan 10 add trunk 1 tag
zte(cfg)#set vlan 40 add trunk 1 tag
zte(cfg)#set vlan 50 add trunk 1 tag
zte(cfg)#set vlan 60 add trunk 1 tag
zte(cfg)#set vlan 70 add trunk 1 tag
zte(cfg)#set vlan 100 add trunk 1 tag
! ========== 办公端口（1-12） ==========
zte(cfg)#set vlan 10 add port 1-12 untag
zte(cfg)#set port 1-12 pvid 10
zte(cfg)#set port 1-12 macaddress on 3
zte(cfg)#set port 1-12 fix-mac on 3 protect
zte(cfg)#set port 1-12 broadcast-limit on rate 1024
zte(cfg)#set port 1-12 description TO-Office-1F
! ========== AP 端口（13-16）：管理 VLAN untag + 用户 VLAN tag ==========
zte(cfg)#set vlan 50 add port 13-16 untag
zte(cfg)#set port 13-16 pvid 50
zte(cfg)#set vlan 60 add port 13-16 tag
zte(cfg)#set vlan 70 add port 13-16 tag
zte(cfg)#set port 13-16 description TO-AP-1F
! ========== 摄像头端口（17-20） ==========
zte(cfg)#set vlan 40 add port 17-20 untag
zte(cfg)#set port 17-20 pvid 40
zte(cfg)#set port 17-20 macaddress on 1
zte(cfg)#set port 17-20 fix-mac on 1 protect
zte(cfg)#set port 17-20 broadcast-limit on rate 512
zte(cfg)#set port 17-20 description TO-Camera-1F
! ========== 管理 IP ==========
zte(cfg)#config router
zte(cfg-router)#set ipport 0 ipaddress 10.0.100.21/24
zte(cfg-router)#set ipport 0 vlan 100
zte(cfg-router)#set ipport 0 enable
zte(cfg-router)#iproute 0.0.0.0 0.0.0.0 10.0.100.1
zte(cfg-router)#exit
! ========== MSTP（区域参数必须与核心一致） ==========
zte(cfg)#set stp enable
zte(cfg)#set stp forceversion mstp
zte(cfg)#set stp name ZTE-CAMPUS
zte(cfg)#set stp revision 1
zte(cfg)#set stp instance 1 add vlan 10,11,12,50
zte(cfg)#set stp instance 2 add vlan 40,45,60,70
zte(cfg)#set stp interface trunk1 point-to-point enable
! ========== 边缘端口 + BPDU 保护 ==========
zte(cfg)#set stp edge-port add port 1-20
zte(cfg)#set stp port 1-20 bpdu-guard enable
! ========== 环路检测：仅终端接入口，不上联口 ==========
zte(cfg)#set loopdetect port 1-20 enable
! ========== 802.1X 透传 ==========
zte(cfg)#set dot1x-relay enable
! ========== 闲置端口关闭 ==========
zte(cfg)#set port 21-22 disable
zte(cfg)#set port 21-22 description UNUSED
! ========== 保存 ==========
zte(cfg)#exit
zte#save
接入层是环路防护的第一道防线，但不是所有口都一套参数。 办公、AP、摄像头口都是边缘口，可启用 BPDU Guard；上联聚合口承载 MSTP，绝不能当边缘口，也不能开 loopdetect。loopdetect 的语义是“如果探测报文被环回来就处理”，而上行口会把探测正常转发到上游，易造成误阻塞。端口 MAC 限制、风暴抑制、禁用闲置口和 description 都是低成本高收益措施，但 MAC 数、广播阈值应按终端密度校准；例如会议室或 IP 电话下挂 PC 时，单口 MAC 限制为 1 可能误阻断。
接入配置也要满足可回退。 每次配置变更前，应导出 startup、running 与端口映射；批量 set port 前先确认端口范围与现场跳线一致。接入交换机虽然不直接承载 VRRP，但其 trunk VLAN、边缘端口、DHCP snooping（若启用）和 MSTP 参数错误，都会让核心“配置正确但业务不通”。
10_1_5 验收不是“ping 通即可”，而是逐项给出方法、预期和排查方向
| # | 测试项 | 方法 | 预期 | 不符排查方向 |
|---|---|---|---|---|
| T1 | 同 VLAN 二层互通 | 同接入同 VLAN 两台 PC 互 ping，查看 MAC 表 | 通，源目 MAC/FDB 正确 | PVID、untag/tag、端口 MAC 限制 |
| T2 | 跨 VLAN 三层互通 | 办公 PC ping 服务器网关与地址 | 通，经核心 SVI 转发 | SVI 状态、VRRP、ACL、helper |
| T3 | 业务隔离 | 办公 PC ping 摄像头；访客 ping 内网 | 不通或被明确放行 | 网关 ACL、防火墙 zone、路由泄漏 |
| T4 | VRRP 网关冗余 | 持续 ping 虚拟网关，关闭 CORE-01 | 中断后恢复，Master 切换 | track、priority、preempt delay |
| T5 | 核心上行 track | 关闭上行口而非整机，观察 VRRP | 优先级下降，Backup 接管 | track 对象、降低值、上行 SVI |
| T6 | 接入链路冗余 | 拔一条双上行链路，业务打流 | LACP 收敛，丢包窗口 < 1s | LACP 模式、短超时、聚合成员状态 |
| T7 | 聚合负载 | 多流 iperf 跨核心/接入 | 多成员均有流量，非单口跑满 | 哈希算法、流数量、同一条流天然单口 |
| T8 | 环路防护 | 办公口私接小交换机形成环 | BPDU Guard/loopdetect 处理，不影响其他口 | edge-port、BPDU Guard、上联误开启 |
| T9 | 无线业务 | 员工连 SSID，获取地址并访问授权资源 | 进入 VLAN60，DHCP 成功 | AP 管理 VLAN、SSID-VLAN、helper |
| T10 | 访客隔离 | 访客终端获取地址并访问内外网 | 仅允许授权外网 | Guest ACL、NAT、DNS、 captive portal |
| T11 | 语音质量 | 通话并打满瓶颈链路，采集 MOS/时延 | 无断续，语音优先 | DSCP 信任、队列映射、带宽预留 |
| T12 | MSTP 实例 | show spantree instance 1/2 |
实例1 根 CORE-01，实例2 根 CORE-02 | name/revision/instance、端口角色 |
| T13 | 风暴抑制 | 测试口发送广播/未知单播风暴 | 端口速率受控，CPU 稳定 | broadcast-limit、限速、镜像确认 |
| T14 | 管理可达 | 网管服务器 SSH/syslog/trap 全部设备 | 可达且有权限审计 | MGMT 路由、ACL、时间、日志服务器 |
| T15 | 配置一致性 | 比对配置库、MAC/端口表、版本 | 无漂移，保存后重启仍一致 | save、版本回退、批量下发日志 |
测试矩阵的关键在最后一行。 “预期”只写“通/不通”不够，应写出根桥、Master、队列、丢包窗口等可判定结果；“排查方向”只列出第一优先路径，避免测试人员遇到异常后无头绪。生产验收还应保留原始 show 输出、抓包、测试时间、操作者和回退确认，形成可审计证据。
10_1_6 割接时序、风险控制与回退必须可落地
割接窗口：业务低峰期（变更窗口内，建议连续 4 小时）
参与人员：网络 2 人、系统/安全 1 人、业务验证 2 人、值班经理 1 人
T-1 日：
① 备份 startup/running、版本、MAC 表、路由表、端口与光功率基线
② 在测试环境验证关键脚本；现场核对接口名、光模块、电源、跳线
③ 建立回退包：原配置、恢复命令、恢复顺序、回退验收清单
④ 通知业务方、值班与监控；确认变更授权和应急联系人
割接当晚（相对时间）：
T+00 冻结变更、复核备份、确认监控基线
T+10 先配置核心互联、MSTP、OSPF，检查邻接与根桥
T+30 逐台导入接入配置，先边缘端口后业务口，避免临时环路
T+60 配置 VRRP、DHCP、ACL、QoS，检查双核心状态
T+90 执行 T1-T15，业务方验证办公/无线/安防/语音/出口
T+150 观察期：CPU、内存、温度、光功率、广播、队列、日志
T+180 决策：达标则解除冻结；否则按回退决策树执行
割接开始
│
T1-T15 全部通过？
├─ 是 ─→ 观察期 ─→ 无新增告警 ─→ 割接成功 ─→ 归档
│
└─ 否
│
核心业务中断 > 15min？
├─ 是 ─→ 立即回退 ─→ 验证基线 ─→ 复盘
├─ 否 ─→ 单点异常？
│ ├─ 是 ─→ 局部配置回退/替换设备 ─→ 重测
│ └─ 否 ─→ 是否仍在观察窗口？
│ ├─ 是 ─→ 继续定位
│ └─ 否 ─→ 回退 ─→ 改期
回退触发条件必须“可测量、可授权、不犹豫”。 本项目的硬条件是：核心业务中断超过 15 分钟且无法定位；出现无法解释的广播风暴或环路；关键设备 CPU 持续高位并影响转发；观察期结束仍未通过关键测试组合。关键测试组合至少包括：管理可达、核心双机、办公/语音/安防各一个代表业务、出口连通。某个非关键测试项（如镜像统计）失败不一定要整体回退，但必须在变更单中登记为遗留项。
! ========== CORE-01 回退脚本片段（以实际备份文件为准） ==========
ZXR10#copy tftp://10.0.100.10/backup/CORE-01-prechange.cfg startup-config
ZXR10#reload
! 重启后确认：
ZXR10(config)#show vrrp brief
ZXR10(config)#show ospf neighbor
ZXR10(config)#show spantree instance 1
ZXR10(config)#show interface smartgroup10
! 若原方案采用差异回退，则按预审批的 undo 顺序逐条执行，而非临时手写。
回退不是“删配置”，而是恢复经过验证的已知状态。 逐条 undo 容易漏项，尤其 MSTP 实例、聚合成员、VRRP track 之间存在依赖。优先使用完整配置恢复；若只能差异回退，脚本中应按“接口→聚合→VLAN→控制平面”的逆序编写，并在测试环境演练。回退完成后必须再跑关键业务，证明不是“配置变了，但根因仍在”。
10_1_7 【案例故事】VRRP 双主：地址冲突只是表象，track 与延时才是解法
割接当晚，我在监控屏前看到办公网段连续弹出“duplicate IP 10”告警，电话同时响了：一层会议室视频会议卡顿。拓扑显示 CORE-01 和 CORE-02 都应在线，可是 show vrrp brief 里两边都是 Master。我先让业务验证人停止接入新终端，避免 ARP 表继续抖动，然后在核心互联聚合上抓包：两端都在发 VRRP 通告，通告间隔正常，但 priority 都是 120。
问题很快清楚了：前一个变更把互联聚合 smartgroup10 的成员口调整过，新的 trunk 放行策略漏掉了 VLAN 10、11、12，VRRP 报文只在本机域里生效。两台核心都认为 Backup 失联，于是都升为 Master，虚拟 MAC 在两个网关间反复漂移。此时若直接 shut 一台核心，会议室马上恢复，但这是把冗余设计打回单机，不能作为正式处置。
我先确认 VRRP track 已引用真实存在的 gei-0/1/0/1 上联口，随后在变更窗口内补上互联 trunk 的缺失 VLAN，并检查 MSTP instance 1 的 root 是否回到 CORE-01。为了不让链路抖动时反复抢占，我把 preempt delay 统一设为 10 秒。恢复顺序是：先稳定 CORE-01 为 Master，再让 CORE-02 成为 Backup；持续 ping 虚拟网关 60 秒无丢包后，才允许会议室重新入会。
这个案例的沉淀有三点：第一，VRRP 双主不是“优先级配错”的专属症状，控制 VLAN 不通也会造成；第二，track 接口必须真实存在且与三层出口一致；第三，割接验收应把“虚拟网关的 Master/Backup 状态”和“跨核心 VRRP 通告可达”作为硬项，而不只测终端 ping。若项目规模扩大，建议再叠加 BFD 或路由跟踪，缩短上行故障感知，但那要以现网软件版本和邻接能力为前提。
10_2 项目二：IPTV 承载网（ZCIE 级）
本节要解决什么问题：第二个项目是 IPTV 承载网，面向 ZCIE。组播的难点不在单台配置，而在复制点、准入与端到端质量保障。
10_2_1 需求、容量与业务边界决定组播架构
IPTV 承载网的核心不是“把组播打通”，而是在大规模并发下把组播复制点、频道权限、带宽准入和切换体验同时控制住。园区网项目锻炼综合广度，IPTV 项目则要求对组播从规划、核算、调优到故障定位形成完整闭环。
某地市运营商需建设 IPTV 承载网，为 20000 用户提供直播与点播业务。
业务需求：
① 直播频道 100 个，其中高清 30 个（8Mbps/频道），标清 70 个（2Mbps/频道）
② 用户并发峰值约 8000 户同时观看
③ 组播复制点下沉到接入层（减少汇聚-接入带宽压力）
④ 频道切换时间 < 1 秒
⑤ 支持免费预览（3 次，每次 5 分钟）与付费频道控制
⑥ 组播流量不得影响宽带上网业务
关键约束：
· 组播流必须精确转发，禁止在 VLAN 内泛洪
· 组播 QoS 优先级高于普通上网
· 每用户端口组播带宽需受限（防止单用户抢占）
频道数和并发数必须转化为逐层带宽。 100 个频道只是内容目录，真正决定网络容量的是“同时观看的频道数 × 码率”，不是总用户数。30 路高清 × 8 Mbps 与 70 路标清 × 2 Mbps 是源侧最大可能带宽；接入层则取决于本设备实际并发。若把全网 8000 并发全部复制到每一台接入交换机，规划必然失败，因此“组播复制点下沉”是本项目最重要的架构约束。
切换 < 1 秒是端到端目标，不能只归给 fastleave。 网络侧通过 IGMP Leave/快速离开、静态组播组和稳定 STP 收敛缩短空窗；终端、EPG、机顶盒、视频服务器还需要及时发送 I 帧或快发流。网络工程师只能对网络部分负责，验收时须记录“机顶盒发出 Leave 到画面切换”的端到端时间，并区分网络丢组、终端缓冲、服务器 I 帧延迟。
10_2_2 拓扑：组播 VLAN 承载节目，用户 VLAN 承载单播与认证
┌──────────┐
│ 节目源/ │ 239.10.1.x（直播）
│ 流媒体 │
└────┬─────┘
│
┌──────▼──────┐
│ 核心路由器 │◄── PIM/组播路由
│ (组播源侧) │
└──────┬──────┘
│ 组播 VLAN 1000
┌────────┴────────┐
┌───▼────┐ ┌────▼───┐
│ 汇聚-1 │ │ 汇聚-2 │
│ OLT上联 │ │ OLT上联 │
└───┬────┘ └────┬───┘
│ 组播VLAN透传 │
┌───▼──────────┐ ┌────▼─────────┐
│ 接入交换机 │ │ 接入交换机 │
│ (IGMP Snooping│ │ (IGMP Snooping│
│ + 组播复制) │ │ + 组播复制) │
└───┬──────────┘ └────┬─────────┘
│ │
机顶盒×N 机顶盒×N
(单播VLAN 2001) (单播VLAN 2002)
典型架构：组播 VLAN（1000）承载组播流，用户单播 VLAN（2001/2002）承载宽带与认证
组播 VLAN 与用户 VLAN 分离，是精确复制的前提。 组播流通过 MVLAN 1000 从节目源下发到接入层；机顶盒所在的用户 VLAN 2001/2002 承载 DHCP、认证、EPG、点播和控制面单播。接入交换机根据 IGMP Snooping 成员表，把组播流从 MVLAN 复制到用户端口。若把组播直接放进用户 VLAN，容易造成同 VLAN 泛洪、成员控制困难和隔离策略复杂化。
组播路由与二层 Snooping 的职责不能混淆。 核心/汇聚的 PIM 负责把组播从源送到最后一跳路由器或组播网关；接入交换机的 IGMP Snooping 只负责“哪个用户端口加入了哪个组”。没有 PIM 或静态组播路由，Snooping 可能收不到真正的组播源；只有 PIM、没有 Snooping，接入层也可能把组播在用户 VLAN 泛洪。项目验收必须分层验证。
10_2_3 规划表、容量核算与工程取舍
| 项目 | 规划值 | 设计解释 |
|---|---|---|
| 组播 VLAN | 1000（全网统一） | MVLAN 统一，便于 Snooping、静态组和策略复用 |
| 用户单播 VLAN | 2001-2100 | 每接入设备/每 PON 口一个，故障域可控 |
| 组播地址段 | 239.10.1.1 - 239.10.1.100 | 100 个频道一一对应规划 |
| 高清频道 | 239.10.1.1-30（8Mbps） | 高频/付费内容可进一步分组播 CAC |
| 标清频道 | 239.10.1.31-100（2Mbps） | 普通频道批量授权 |
| 每端口组播带宽限制 | 20 Mbps | 约 2 路高清 + 2 路标清，防止单端口抢占 |
| 组播 802.1p | 4（映射到 TC2） | 高于普通上网，低于语音/网络控制 |
| 每 VLAN 组数限制 | 100 | 与频道规模一致，防止表项滥用 |
| 快速离开 | 启用 | 缩短 Leave 到停止复制的空窗 |
单接入交换机（24 口，按 60% 并发）：
峰值同时观看 = 24 × 0.6 ≈ 14 户
假设 50% 看高清：7 × 8Mbps + 7 × 2Mbps = 56 + 14 = 70 Mbps
→ 上行链路需 ≥ 100 Mbps，建议 1G（留有余量）
汇聚层：
假设汇聚 20 台接入：20 × 70 Mbps = 1.4 Gbps
→ 汇聚上行建议 10G
核心层：
20000 用户 × 30% 并发 = 6000 户
50% 高清：3000 × 8 + 3000 × 2 = 24000 + 6000 = 30 Gbps
→ 核心需 40G/100G 互联
带宽是概率值，不是每用户固定 8 Mbps。 上述核算采用 50% 高清的假设，实际晚高峰、热门赛事和区域用户偏好都会改变。规划时应按“峰值频道分布”而非平均码率设计，并在汇聚和核心保留至少 30% 余量。若未来引入 4K/8K，单频道码率会明显上升，此时不能简单把 TC2 队列放大，而应优先扩容复制点上联和缓存架构。
每端口 20 Mbps 是准入边界，不是 QoS 保证。 CAC/带宽限制用于防止机顶盒异常、恶意测试或终端多流把接入端口打满；QoS 用于在拥塞时决定丢包顺序。二者必须组合：没有限速，TC2 也可能被组内多频道挤占；没有 QoS，突发上网流量仍可能在瓶颈口抢占组播。
10_2_4 接入交换机配置：IGMP Snooping、CAC 与 QoS 协同
zte>enable
zte#configure terminal
zte(cfg)#hostname IPTV-ACC-01
! ========== VLAN ==========
zte(cfg)#set vlan 1000 enable
zte(cfg)#create vlan 1000 name MCAST
zte(cfg)#set vlan 2001 enable
zte(cfg)#create vlan 2001 name USER-2001
! ========== 端口规划 ==========
! port 1-23：用户口（单播 VLAN untag + 组播 VLAN tag，Hybrid 型）
! port 24：上联（组播 VLAN + 单播 VLAN 全 tag）
zte(cfg)#set vlan 2001 add port 1-23 untag
zte(cfg)#set port 1-23 pvid 2001
zte(cfg)#set vlan 1000 add port 1-23 tag
zte(cfg)#set vlan 1000 add port 24 tag
zte(cfg)#set vlan 2001 add port 24 tag
! ========== IGMP Snooping 核心配置 ==========
zte(cfg)#set igmp snooping enable
zte(cfg)#set igmp snooping add vlan 1000
zte(cfg)#set igmp snooping vlan 1000 add smr port 24
zte(cfg)#set igmp snooping fastleave enable
zte(cfg)#set igmp snooping add maxnum 100 vlan 1000
! ========== 定时器调优 ==========
zte(cfg)#set igmp snooping query_interval 60
zte(cfg)#set igmp snooping response_interval 100
zte(cfg)#set igmp snooping lastmember_query 20
zte(cfg)#set igmp snooping timeout 260 host
zte(cfg)#set igmp snooping timeout 260 router
! ========== 组播 QoS：保障组播优先 ==========
zte(cfg)#set qos queue-schedule sp
zte(cfg)#set qos priority-map user-priority 4 traffic-class 2
zte(cfg)#set vlan 1000 priority on 4
! ========== 每端口组播带宽限制 20Mbps ==========
zte(cfg)#set port 1-23 bandwidth egress on rate 20480
! ========== 组播过滤：只放行合法频道段 ==========
zte(cfg)#set igmp filter enable
zte(cfg)#set igmp filter add groupip 239.10.1.1 vlan 1000
zte(cfg)#set igmp filter add groupip 239.10.1.31 vlan 1000
! （其余频道同样添加，或按网段批量配置；以设备实际批量语法为准）
! ========== 端口安全（防止用户私接） ==========
zte(cfg)#set port 1-23 macaddress on 2
zte(cfg)#set port 1-23 fix-mac on 2 protect
zte(cfg)#set stp edge-port add port 1-23
zte(cfg)#set stp port 1-23 bpdu-guard enable
! ========== 保存 ==========
zte(cfg)#exit
zte#save
静态组播路由端口（smr）定义的是“上游方向”，不是所有组播来源。 port 24 应朝向汇聚/组播网关，使 IGMP Query、PIM 和相关组播流正确学习。若错误地把用户口配置为 smr，可能造成查询器方向混乱、组播表项异常，甚至组播环路。多上联场景中，应结合 MSTP 根端口、PIM 邻居和实际转发路径确认，不能机械地把所有 trunk 口都加为 smr。
fastleave 的代价是依赖 Leave 的可靠性。 开启后，最后一个成员 Leave 时可快速停止向该端口复制，利于 < 1 秒换台；但如果 Leave 在链路中丢失，端口可能继续占用带宽，甚至用户下线后流不停。因此需要与稳定查询器、合理 lastmember_query 和端口链路质量监控一起评估。极端情况下可保留慢速超时作为兜底，但换台体验会下降，工程上要二选一明确目标。
组播过滤不是万能安全。 它能限制可加入的组地址范围，防止非法组播组耗尽表项；但频道权限、预览次数、用户认证仍应由 IPTV 控制平面和 CAC 负责。若仅依赖交换机 filter，付费控制容易被绕过；若只有业务系统而没有 filter，异常组播可能占用接入资源。二者是纵深防御，而非替代关系。
10_2_5 IPTV 业务配置：频道、预览与 CAC
zte(cfg)#config nas
zte(cfg-nas)#iptv control enable
zte(cfg-nas)#iptv control log-time 300
zte(cfg-nas)#iptv control prvcount 3
zte(cfg-nas)#iptv control prvtime 300
zte(cfg-nas)#iptv control prvinterval 1800
zte(cfg-nas)#iptv control prvcount reset-period 24
! ========== 频道创建 ==========
zte(cfg-nas)#create iptv channel 1-100
zte(cfg-nas)#iptv channel 1 name CCTV-1-HD
zte(cfg-nas)#iptv channel 1 mvlan 1000
zte(cfg-nas)#iptv channel 2 name CCTV-2-SD
zte(cfg-nas)#iptv channel 2 mvlan 1000
! ========== CAC 规则 ==========
zte(cfg-nas)#create iptv cac-rule 1
zte(cfg-nas)#iptv cac-rule 1 name FreePreview
zte(cfg-nas)#iptv cac-rule 1 prvcount 3
zte(cfg-nas)#iptv cac-rule 1 prvtime 300
zte(cfg-nas)#iptv cac-rule 1 prvinterval 1800
zte(cfg-nas)#iptv cac-rule 1 right 31-100
zte(cfg-nas)#create iptv cac-rule 2
zte(cfg-nas)#iptv cac-rule 2 name PaidHD
zte(cfg-nas)#iptv cac-rule 2 prvcount 0
! ========== 验证 ==========
zte(cfg-nas)#show iptv control
zte(cfg-nas)#show iptv channel
zte(cfg-nas)#show iptv cac-rule
zte(cfg-nas)#show iptv client
预览规则要按业务 Rights 而不是频道名称管理。 CAC 规则中的 right 31-100 对应标清频道范围，表示允许预览；高清付费频道 prvcount 0 不允许预览。上线前应建立“频道 ID—组播地址—码率—Right—CAC 规则—业务产品”的映射表，避免配置顺序错乱导致付费频道被免费放行。具体规则关键字和取值范围依型号、版本不同，现场用 ? 帮助确认。
日志周期、预览次数和复位周期共同决定运营体验。 log-time 300 用于统计最小观看时长，prvcount 3 和 prvtime 300 是次数与时间上限，reset-period 24 决定计数复位周期。它们必须与业务产品合同一致：若合同允许“每天 3 次”，复位周期应为 24；若允许“每次开机 3 次”，则应由业务系统会话状态控制，交换机静态配置无法感知。
10_2_6 IPTV 测试矩阵：验证精确复制、切换、带宽和权限
| # | 测试项 | 方法 | 预期 | 不符排查方向 |
|---|---|---|---|---|
| T1 | Snooping 生效 | 1 户看频道，其他端口抓包 | 其他端口收不到该组播流 | smr、VLAN tag、成员表、泛洪 |
| T2 | 组播精确转发 | show igmp snooping vlan 1000 host |
用户端口和组地址对应 | Join 报文、端口角色、filter |
| T3 | 路由端口 | show igmp snooping vlan 1000 router |
port 24 为路由端口 | smr、上联 VLAN、PIM/Query |
| T4 | 频道切换 | 机顶盒换台并计时 | < 1 秒 | fastleave、lastmember、I 帧 |
| T5 | 多用户并发 | 20 户看不同频道 | 流畅、无马赛克 | 上行带宽、复制点、组数限制 |
| T6 | 端口带宽限制 | 单端口多频道/打流 | 总速率 ≤ 20 Mbps | egress 限速、TC、队列统计 |
| T7 | 组播 QoS | 打满上网流量后看 IPTV | IPTV 优先，无明显丢包 | CoS/DSCP 信任、TC2、拥塞点 |
| T8 | 频道过滤 | 加入非法组播组 | filter 拦截 | filter enable、组范围、顺序 |
| T9 | 预览控制 | 未订购用户反复预览 | 3 次后无法继续预览 | CAC rule、right、计数复位 |
| T10 | 快速离开 | 最后一成员 Leave | fastleave enable，流快速停止 | Leave 报文、smr、定时器 |
| T11 | 组数限制 | 加入超过 100 个组 | 超限组被拒绝或按版本处理 | maxnum、表项资源、版本 |
| T12 | 长时间稳定性 | 连续运行 72 小时 | 无中断，表项稳定 | 查询器、内存、光链路、CPU |
“看不到频道”要按层次二分。 第一层检查组播源、组地址、PIM 和 MVLAN 是否到达汇聚；第二层检查接入 Snooping、smr、成员端口；第三层检查机顶盒、DHCP、认证、EPG 和 CAC。不能一上来就在用户口抓包：如果核心根本没有该组播（S，G），接入配置再正确也无流可复制。反过来，核心有流但用户口无流，则应优先看 VLAN 1000 是否透传、端口是否 tag、是否命中 filter。
10_2_7 故障模式、优化进阶与答辩逻辑
| 问题 | 根因 | 优化方案 |
|---|---|---|
| 换台慢（> 2s） | 未开 fastleave；lastmember_query 过长 | 开 fastleave，调小 lastmember_query |
| 高峰期卡顿 | 上行带宽不足 | 重新核算并发带宽，扩容上行 |
| 部分用户看不到 | 组播 VLAN 未透传到该接入 | 全网核对 VLAN 透传表 |
| 组播影响上网 | 未做 QoS 或未限速 | 组播进 TC2，用户口限速 |
| 组播表项震荡 | 查询器不稳定、定时器过短 | 稳定查询器，适当增大 host timeout |
| 用户下线后流不停 | Leave 丢失或未开 fastleave | 检查链路质量，开启 fastleave |
| 单用户抢占带宽 | 未做端口限速 | bandwidth egress on rate |
① 组播复制点下沉：在接入交换机完成复制，汇聚-接入链路上每个频道只有 1 份流
② 静态组播组预加入：热门频道配置静态组，用户切换即达（省去 IGMP 交互时间）
③ 频道预缓存/快速频道切换（FCC）：服务器侧配合，发送单播快发流补齐 I 帧
④ 组播 VLAN 与用户 VLAN 分离（Cross-VLAN）：节省组播 VLAN 资源，简化管理
⑤ 组播 QoS 与带宽准入（CAC）：端口组播带宽总和受控，避免过载
优化必须说明成立条件。 静态组适合热门频道占比高、频道数可控的网络；若长尾频道极多，静态组会占用大量表项并增加运维成本。FCC 需要视频平台和机顶盒支持，单靠交换机无法完成“I 帧快速补齐”。复制点下沉能节约汇聚—接入带宽，却会增加接入交换机表项和复制压力，所以接入上行的 1G/10G 选择必须回到容量核算，而非口号。
【ZCIE】答辩时最有说服力的不是命令，而是权衡。 例如：MVLAN 全网统一简化策略，但跨业务共享风险较高；每用户一个单播 VLAN 隔离清晰，却增加 VLAN 规模；20 Mbps 端口限制防止滥用，但多屏家庭可能不足。应主动说明“本方案采用 X，因为当下的约束是 Y；若约束变成 Z，则改为 A”。这种表达证明已经具备网络工程决策能力。
10_2_8 【案例故事】首晚频道切换慢：先怀疑网络，最终用 fastleave 与静态组收尾
IPTV 首晚上线，投诉集中在“换台要两三秒，画面先绿一下”。我先在汇聚口镜像抓包，确认频道流确实在用户上线后几秒内到达接入；这说明 PIM、MVLAN 和节目源没有明显中断。再看机顶盒的 IGMP：Join 发出后，接入交换机有时仍保留旧组成员，Leave 报文在用户快速连续换台时丢了一部分。根因不是带宽不足——汇聚上行峰值只有约 40%，而是 lastmember 查询偏长，且没有充分利用 fastleave。
我在变更窗口内核对了接入配置，确认 fastleave enable 已配，但 lastmember_query 仍沿用默认值；同时发现热门频道依赖用户 Join 后才建立完整复制路径。调整时先统一查询器和定时器，然后在接入层对热门频道增加静态组播组。再次测试，热门频道切换时间从约 2.5 秒降到 1 秒以内，冷门频道也在稳定 Leave 后恢复正常。
这次处理有两个教训。第一，抓包要覆盖“机顶盒 Join/Leave—接入 Snooping 表—端口复制”三段，只在大口看流量会误判为源侧问题。第二，静态组是容量与体验的交易：它让切换更快，却占用表项和控制面资源，所以只对高热频道启用，并记录在频道运营表里。若后来频道数量翻倍或热门度变化，必须重新评估，而不是把首晚参数永久固化。
10_3 割接、回退与风险控制
本节要解决什么问题：方案再好，割接出问题也是事故。本节把割接时序、回退触发条件与回退脚本固化成可执行的动作。
10_3_1 把变更拆成可审批、可观测、可回退的闭环
割接不是“深夜改配置”，而是工程交付的受控试验。园区网与 IPTV 的割接策略有共同点：先备份和基线，再按依赖顺序实施，随后做分层验证，最后根据明确条件决定是否回退。不同点是：园区网更关注二层无环、网关冗余和业务隔离；IPTV 更关注组播复制、切换时延和并发容量。
共同控制项：
① 变更单：目标、影响范围、风险等级、审批、负责人、沟通计划
② 基线：配置、版本、CPU/内存/光功率、关键业务连通、组播表项
③ 实施顺序：物理层 → 二层 → 三层 → 路由/组播 → 业务策略 → QoS
④ 验证顺序：单设备 → 单链路 → 单业务 → 全网业务 → 观察期
⑤ 回退策略：完整配置恢复优先；差异回退必须预先审批和演练
⑥ 归档：命令回显、测试记录、监控截图、遗留项、复盘结论
控制平面应先于业务上线。 园区网若先把 VRRP、DHCP 配好，再去修 MSTP 和聚合，可能造成短暂双主、临时环路或 trunk 缺失；正确顺序是先稳定互联、STP、LACP，再配置网关与业务。IPTV 则应先保证 MVLAN 全路径、PIM/路由端口和 Snooping，再上线频道权限与 CAC；否则用户 Join 到达时，网络尚无稳定复制路径，易被误判为机顶盒问题。
10_3_2 割接时序图：并行准备不能替代串行验收
T-1日：准备 ── 备份 ── 测试验证 ── 回退包 ── 审批
│
割接日： ▼
冻结 ─→ 核心/路由 ─→ 接入/复制点 ─→ 业务策略 ─→ 测试 ─→ 观察 ─→ 决策
│ │ │
└── 失败 ──┐ └── 失败 ──┐ └── 失败 ──┐
▼ ▼ ▼
局部回退 局部回退 整体回退
│ │ │
└──── 验证基线 ──── 复盘 ──── 改期 ─┘
观察期不是空闲时间。 至少应覆盖一个完整的高峰业务周期，若变更窗口不足，可先完成关键测试并安排次日白天观察。观察期内应检查：CPU/内存趋势、广播/组播比例、接口 error/discard、VRRP/MSTP/OSPF/PIM 状态、队列丢包、DHCP 成功率和 IPTV 换台体验。没有基线就没有“异常”判断，因此不能省略 T-1 日的数据采集。
10_3_3 回退决策树必须写明责任人和动作
出现告警或测试失败
│
是否属于预登记低风险遗留项？
├─ 是 ─→ 是否影响关键业务？
│ ├─ 否 ─→ 记录并继续观察
│ └─ 是 ─→ 进入回退评估
└─ 否
│
核心业务中断 > 15min？或存在环路/安全风险？
├─ 是 ─→ 立即启动整体回退
└─ 否
│
是否可在剩余窗口内定位并修复？
├─ 是 ─→ 局部回退/替换，重测
└─ 否 ─→ 启动整体回退
│
恢复基线配置
│
关键业务 + 监控验证通过
│
归档、复盘、改期
回退条件不能靠现场“感觉”。 必须预先约定硬指标：关键业务中断时长、CPU/内存阈值、环路告警、关键测试未通过数量、剩余窗口。责任人也应明确：变更负责人决定是否回退，业务负责人确认业务状态，值班经理承担授权与沟通。多人现场“各自尝试”会拖延回退黄金时间。
10_3_4 回退脚本与验证：恢复后必须证明业务回到基线
! ========== 园区核心回退示例（仅示例，路径/文件名以备份为准） ==========
ZXR10#copy tftp://10.0.100.10/rollback/CORE-01-before.cfg startup-config
ZXR10#reload
! 或接入设备采用差异回退：
! zte#copy tftp://10.0.100.10/rollback/ACC-1F-01-before.cfg running-config
! 回退后验证（园区）
CORE-01(config)#show vrrp brief
CORE-01(config)#show ospf neighbor
CORE-01(config)#show spantree instance 1
CORE-01(config)#show interface smartgroup1
CORE-01(config)#show qos interface smartgroup1
! 回退后验证（IPTV）
IPTV-ACC-01(cfg)#show igmp snooping vlan 1000 router
IPTV-ACC-01(cfg)#show igmp snooping vlan 1000 host
IPTV-ACC-01(cfg)#show iptv client
IPTV-ACC-01(cfg)#show port 1-23 bandwidth
回退成功的定义是“业务回到变更前基线”，不是“配置恢复”。 因此要同时核对：配置哈希、版本、邻居、关键业务、监控告警和性能计数。尤其在 IPTV 场景，静态组、CAC、机顶盒会话可能在变更过程中发生变化，恢复旧配置后仍要确认没有残留异常组播流或僵尸会话。
10_4 笔记方法与交付文档模板
本节要解决什么问题：项目交付的价值一半在配置，一半在文档。本节给出交付清单、变更回退记录与验收测试三类模板。
10_4_1 笔记方法：从“记录命令”升级为“记录决策与证据”
【笔记方法】的目标不是把文档抄一遍，而是让三个月后的自己能在变更窗口里复现当时的判断。每个项目至少形成四类文档：需求与决策、网络基线、变更与回退、测试与复盘。配置脚本本身不是知识，只有附上“为什么这样配、失败时如何验证、何时必须回退”才是可交付知识。
建议的项目笔记目录：
project/
├─ 01_需求与验收.md
├─ 02_拓扑与地址规划.xlsx或md
├─ 03_逐设备配置/
│ ├─ CORE-01.cfg
│ ├─ CORE-02.cfg
│ └─ ACC-1F-01.cfg
├─ 04_变更与回退/
│ ├─ change-order.md
│ ├─ rollback-plan.md
│ └─ baseline-YYYYMMDD.csv
├─ 05_测试记录/
│ └─ test-Tx.md
└─ 06_复盘.md
每条配置笔记都应采用“现象—假设—证据—处置—沉淀”五段式。 例如：现象是 VRRP 双主；假设是控制 VLAN 不通；证据是互联口无 VRRP 通告、trunk VLAN 缺失；处置是补 trunk 并设 preempt delay；沉淀是“VRRP 状态必须纳入割接验收”。这种结构直接对应 ZCIE 故障定位与答辩要求。
10_4_2 项目交付文档清单模板（可直接复制）
# 项目交付文档清单
## 1. 项目信息
- 项目名称：
- 客户/网络名称：
- 交付版本：
- 项目负责人 / 技术负责人：
- 交付日期：
## 2. 文档清单
| 编号 | 文档 | 负责人 | 版本 | 状态 |
|---|---|---|---|---|
| D01 | 需求说明书 | | | 已评审 |
| D02 | 网络设计方案 | | | 已评审 |
| D03 | IP/VLAN/MSTP/QoS 规划表 | | | 已评审 |
| D04 | 逐设备配置脚本 | | | 已验证 |
| D05 | 变更与回退方案 | | | 已审批 |
| D06 | 验收测试报告 | | | 已完成 |
| D07 | 运维巡检手册 | | | 已移交 |
| D08 | 竣工资产与标签表 | | | 已归档 |
## 3. 交付确认
- 需求覆盖率：
- 遗留风险：
- 业务验收人签字：
- 技术验收人签字：
10_4_3 割接回退记录模板（可直接复制）
# 割接与回退记录
## 1. 变更信息
- 变更单号：
- 窗口开始/计划结束：
- 影响范围：园区网 / IPTV / 子网 / 设备
- 变更类型：新建 / 扩容 / 优化 / 故障修复
- 审批人 / 操作人 / 验证人：
## 2. 变更前基线
| 项目 | 基线值 | 采集时间 | 证据文件 |
|---|---|---|---|
| 配置备份 | | | |
| CPU/内存 | | | |
| 关键链路带宽 | | | |
| VRRP/OSPF/PIM 状态 | | | |
| 组播成员表 | | | |
## 3. 实施步骤
| 时间 | 操作 | 预期 | 实际 | 操作者 |
|---|---|---|---|---|
| | 备份与冻结 | | | |
| | 核心/路由 | | | |
| | 接入/复制点 | | | |
| | 业务策略 | | | |
| | 观察期 | | | |
## 4. 回退信息
- 回退触发条件：
- 回退决策人 / 时间：
- 回退方式：完整配置恢复 / 差异回退
- 回退脚本位置：
- 回退后关键验证：
## 5. 结论
- 成功 / 部分成功 / 回退
- 遗留项：
- 下次变更建议：
10_4_4 验收测试记录模板（可直接复制）
# 验收测试记录
## 测试对象
- 设备/子网：
- 测试时间：
- 测试人 / 业务验证人：
## 测试矩阵
| 编号 | 测试项 | 方法 | 预期 | 实际 | 证据 | 结论 |
|---|---|---|---|---|---|---|
| T1 | | | | | 截图/命令回显 | 通过/失败 |
| T2 | | | | | | |
| T3 | | | | | | |
## 异常与处置
| 编号 | 现象 | 定位证据 | 根因 | 处置 | 是否阻塞验收 |
|---|---|---|---|---|---|
| E1 | | | | | |
## 验收结论
- 关键项通过率：
- 非关键遗留项：
- 验收签字：
10_5 考点速记与自检清单
本节要解决什么问题：最后是考点速记与自检清单。
10_5_1 考点速记
【ZCIA】基础配置与验证
- 接入端口
untag + pvid；上联 trunk 必须明确允许业务 VLAN，禁止“配了 VLAN 却忘记放行”。 - MSTP 区域三要素：
name、revision、VLAN-to-instance，全网必须一致。 - VRRP 虚拟 IP 是网关，Master 由较高优先级或抢占机制决定；同一时刻正常只应有一个 Master。
- IGMP Snooping 的作用是建立“端口—组”表，实现组播精确转发，而不是让组播在所有端口泛洪。
【ZCIP】设计与联调
- 核心双机的“主备负载分担”是按不同业务/实例分配 Master，不是让一个 VRRP 组同时使用两台网关。
- VRRP track 引用的接口必须真实存在；上行故障时降优先级，应使 Backup 稳定接管。
- MSTP instance 根桥应与 VRRP Master 尽量对齐，减少跨核心互联的非必要转发。
- QoS 必须识别拥塞点：TC3 语音、TC2 视频/组播、TC1 办公、TC0 访客；不可信终端的 DSCP 应在信任边界重标记。
【ZCIE】深度与决策
- IPTV 容量核算按“并发用户 × 频道码率”，复制点下沉后接入上行带宽只与该接入实际并发有关。
- fastleave 缩短换台空窗，但依赖 Leave 报文可靠；静态组适合热门频道，不能无差别覆盖全部频道。
- CAC、filter、端口限速、QoS 是四层控制：权限、组地址、带宽、拥塞调度，不能只配其一。
- 割接回退必须有基线、触发条件、恢复顺序和回退后验证；配置恢复不等于业务恢复。
10_5_2 本板块自检清单
10_6 附：综合实战练习（先做后对照）
本节要解决什么问题：留一道综合练习题，建议先自己写一遍排查思路，再对照参考思路找差距。
练习一：三步排查
场景：园区网割接后，2 层办公用户反映"能上内网，但上不了外网"，
1 层和 3 层用户正常。
请写出：① 至少 5 条排查命令；② 3 个最可能的原因；③ 对应的验证方法。
参考思路： ① 先核对 VLAN 11、接入 trunk、SVI、VRRP、helper、ACL；再看 CORE 到防火墙的 OSPF、NAT、出口路由；最后在 DHCP、DNS 和终端抓包。② 最可能原因：2 层接入 trunk 漏放 VLAN 11；CORE-02 上 VLAN11 SVI/VRRP/DHCP 中继异常；防火墙仅放行 10/12 网段而漏放 11。③ 验证方法是用固定地址终端分别 ping 网关、DHCP 服务器、DNS、防火墙内网口和公网地址，并以 show/抓包确定断点。
练习二：方案设计
场景：某医院有 门诊网、住院网、影像网（PACS，大流量）、设备网、访客网 五个业务域。
要求：① 影像网不得被其他业务挤占；② 访客网严格隔离；
③ 门诊大厅 Wi-Fi 需支持 200 并发；④ 核心双机。
请输出：VLAN 规划表、地址规划表、QoS 队列规划表、可靠性方案、至少 3 条关键配置。
参考思路： 五个业务域对应至少五个 VLAN；影像网独立高带宽 VLAN，进入 TC2 或更高队列并配置带宽保障；访客网仅允许 NAT 出口，网关 ACL 禁止访问医疗业务；门诊无线按 SSID→VLAN 映射，独立 DHCP 地址池并预留 200 并发；核心双机采用 VRRP + MSTP 实例分担；关键配置包括 trunk VLAN、DHCP relay、影像网 QoS、访客 ACL、双上行聚合。具体地址、掩码、队列参数须结合终端规模测算，不能照搬本项目。
练习三：故障演练
场景：IPTV 用户投诉"晚上 8 点后所有频道都卡"。
请写出：① 排查顺序（含命令）；② 至少 4 个可能根因；③ 每个根因的判据与解法；
④ 如何从架构上避免该问题再次发生。
参考思路： ① 从监控基线、核心组播源/PIM、汇聚—接入带宽、接入并发和组播表、机顶盒/服务器分段排查；命令涵盖接口带宽/error、PIM/IGMP 表项、Snooping host/router、队列丢包、CPU、光功率。② 根因可能是晚高峰并发超过接入上行容量、复制点未下沉导致汇聚拥塞、组播 QoS/限速缺失、节目源或服务器性能瓶颈、链路误码导致组播丢包。③ 判据分别是峰值带宽、拥塞口 discard、TC2 丢包、源侧统计、CRC/error；解法对应扩容、下沉复制、配置 CAC/QoS、升级平台、更换光链路。④ 架构上应建立容量预测、分层复制、端口 CAC、热门频道静态组、端到端监控和定期压测。
浙公网安备 33010602011771号