简介ITU-T G.8032 V5.003/2020以太网环保护切换ERPS标准文档面向电信与数据通信领域的网络工程师、协议开发人员及备考相关认证的技术人员用于解决环形以太网在链路或节点故障时的快速检测与自动保护切换问题。资源包为1个PDF文件大小约1.76MB完整收录ITU-T G.8032/Y.1344建议书正文涵盖以太网环保护特性、架构、R-APS协议及历次修订历史并更新了引用、移除了待研究项、整合了原G.8001/Y.1354中的术语定义。目前已有284人学习下载。读者可据此掌握ERPS的故障检测、自动保护切换与环网恢复机制理解其在城域以太网、广域网及数据中心网络中的部署要点为协议实现、网络规划与故障排查提供权威依据。1. 环网保护到底在保什么从一次倒换超时说起很多做城域以太网的工程师第一次接触 ITU-T G.8032都是在现网出了倒换超时之后。业务侧反馈丢包几百毫秒运维翻遍设备日志只看到 R-APS 报文收发的零星记录最后定位到环上某台设备的等待恢复计时器和另一台对不上。G.8032 就是干这件事的标准以太网环保护切换Ethernet Ring Protection SwitchingERPS用一套 R-APS 协议报文和状态机让一个物理环在链路故障时把业务倒换到备用路径恢复时间目标通常在 50ms 以内。它跑在二层不依赖三层路由收敛所以比路由协议倒换快得多。这篇笔记面向的是要在接入环、汇聚环上落地 ERPS 的工程师从标准里的状态机讲到配置参数怎么设、现网为什么翻车最后给一套能自己验证倒换时间的做法。V5.0 这个版本号对应的是 2020 年 3 月发布的那一版文本相比早期版本在互操作和管理上有不少补充下面会按落地顺序拆开讲。2. 先把状态机和 R-APS 报文吃透ERPS 为什么能压到 50msERPS 的快不是靠某个黑科技而是靠一套提前约定好的状态机和几种固定格式的控制报文。理解这两样后面配参数才不会瞎调。2.1 环上每个节点在跑什么状态机一个 ERPS 环由若干节点组成每个节点在每个环端口上维护一个状态机。核心状态有这么几个Idle空闲端口转发、Protection保护故障相邻节点阻塞故障侧端口、Pending等待收到 SF 后先等一段时间再动作、Forced Switch强制倒换、Manual Switch人工倒换。正常时环上有一个 RPL Owner 节点它的 RPLRing Protection Link端口是阻塞的整个环逻辑上是一条链避免环路。一旦某段链路断了断点两侧节点检测到信号失效SF立刻阻塞各自故障侧端口并向环上发 R-APS(SF) 报文。RPL Owner 收到后打开自己原本阻塞的端口业务就绕到备用路径上去了。这里的关键是阻塞和打开的动作是本地触发的不等全网收敛所以快。R-APS 报文的作用是通知其他节点更新转发表、清除 MAC 地址避免残留表项把流量引到断点。2.2 R-APS 报文的三种类型和字段含义R-APS 报文是以太网帧目的 MAC 用的是固定的组播地址 01-19-A7-00-00-01这个在标准里有定义配置时设备一般自动带。它有三种主要类型报文类型触发场景关键字段R-APS(SF)检测到信号失效Status 字段置 SF 位Node ID 标识发送节点R-APS(NR)故障恢复、无请求Status 为 NR用于恢复后的状态同步R-APS(FS/MS)强制/人工倒换Status 置 FS 或 MS 位报文里还有几个必须关注的字段Request/State请求状态、Sub-code子码区分 FS、SF、MS、NR 等、Status当前状态、Node ID6 字节节点唯一标识、Reserved。Node ID 特别重要环上每个节点必须唯一否则状态机认不出是谁发的报文会出现反复倒换。2.3 一个最小环的报文交互时序假设四节点环节点 A 是 RPL OwnerA 的 port1 是 RPL 端口阻塞。正常时 A 周期性发 R-APS(NR)其他节点收到后保持 Idle。当 B 和 C 之间的链路断了B 检测到 port2 信号失效阻塞 port2发 R-APS(SF)Node IDB。C 同样检测到阻塞 port1发 R-APS(SF)Node IDC。A 收到 SF 报文打开 RPL 端口转发业务。各节点收到 SF 后清除相关 MAC 表项重新学习。故障恢复后B、C 进入 Pending 状态等 WTR 计时器超时发 R-APS(NR)。A 收到 NR重新阻塞 RPL 端口环回到正常态。整个过程里WTRWait To Restore和 Guard 计时器决定了恢复的节奏配错了就会出现反复倒换或者恢复慢。2.4 用抓包确认状态机在动在设备上做镜像抓包过滤 R-APS 组播地址能看到报文交互。用 tcpdump 的话大概是这样# 在镜像口抓 R-APS 报文目的 MAC 是 ERPS 专用组播地址 tcpdump -i eth0 -nn -e ether dst 01:19:a7:00:00:01 -c 50抓到之后重点看 Sub-code 字段和 Node ID。如果看到同一个 Node ID 反复发 SF 又发 NR说明链路在抖动或者 WTR 设得太短。如果完全抓不到报文先查环端口有没有加入 ERPS 保护组、组播地址有没有被过滤。3. 在设备上把 ERPS 环配起来从保护组到 RPL Owner标准文本不会告诉你某台设备怎么敲命令但落地路径是通的先建保护组再绑端口再定角色最后调计时器。下面用一套通用的配置逻辑讲具体命令按设备厂商的语法替换。3.1 保护组和环端口的绑定关系ERPS 的保护组有些设备叫 ERPS Ring 或 G.8032 实例是配置的容器。一个保护组绑定两个环端口这两个端口必须属于同一个物理环。配置顺序一般是创建 ERPS 保护组指定 ID1-255。把两个环端口加入保护组指定 port0 和 port1。指定节点角色RPL Owner、RPL Neighbor 还是普通节点。配置 R-APS 报文的 VLAN 和优先级。使能保护组。以某类设备的配置风格为例# 创建 ERPS 保护组 1绑定两个环端口 erps ring 1 port0 interface GigabitEthernet0/1 port1 interface GigabitEthernet0/2 role rpl-owner rpl-port port0 control-vlan 100 guard-timer 500 wtr-timer 300 enable这段配置里control-vlan 是 R-APS 报文走的 VLAN必须环上所有节点一致。guard-timer 和 wtr-timer 单位是秒的百分之一还是秒不同设备不一样配之前一定查手册这是最常见的翻车点。3.2 RPL Owner 和 Neighbor 的角色分工一个环只能有一个 RPL Owner它的 RPL 端口正常时阻塞。RPL Neighbor 是 RPL 另一端的节点它不阻塞端口但要配合 Owner 做状态同步。其他节点都是普通节点。角色配错会怎样如果两个节点都配成 Owner环上会出现两个阻塞点业务路径就断了如果一个都没有环就成环了广播风暴直接打满。判断角色对不对看正常态下是不是只有一个端口阻塞。用显示命令查# 查看 ERPS 保护组状态确认阻塞端口和角色 show erps ring 1输出里应该看到 RPL Owner 的 RPL 端口是 Blocked其他端口是 Forwarding。3.3 计时器参数怎么设才不抖三个计时器最关键计时器作用常见取值设错的后果Guard收到 SF 后等待再动作500ms太短会误动作太长倒换慢WTR故障恢复后等待再回切300s太短会反复倒换太长恢复慢Hold-off检测到故障后延迟上报0-100ms太短会因瞬断触发倒换WTR 设 300 秒是常见做法目的是等链路真正稳定再回切。如果现网链路质量差可以适当加大。Guard 计时器的作用是防止在收到 SF 后立刻又收到 NR 造成状态机震荡一般 500ms 够用。3.4 用 display 命令验证倒换是否真的发生配完之后不能只看配置要验证。方法是在环上一条链路做断开同时看状态变化# 断开前记录状态 show erps ring 1 # 断开链路后立即查看 show erps ring 1 # 观察端口状态从 Forwarding 变 Blocked以及 R-APS 计数变化 show erps ring 1 statisticsstatistics 里能看到 SF、NR 报文的收发计数。如果断开后计数不涨说明报文没发出去或者被过滤了。如果状态变了但业务没恢复查 MAC 表有没有清除。4. 互操作和多环场景V5.0 里容易被忽略的细节单环配通只是入门现网更多是多环嵌套或者不同厂商设备混组。V5.0 在这些场景下有一些明确要求不遵守就会出玄学问题。4.1 多环嵌套时的虚拟通道和子环当一个环嵌套在另一个环里外层环的节点可能同时属于内层环。这时候 R-APS 报文不能互相干扰标准里用虚拟通道Virtual Channel和子环Sub-ring的概念来处理。子环的 R-APS 报文通过外层环的虚拟通道透传不参与外层环的状态机。配置时要明确指定哪个环是子环哪个端口接虚拟通道。如果配错会出现内层环的 SF 报文被外层环节点当成自己的事件处理导致外层环误倒换。排查方法是抓包看 R-APS 报文的环 ID 字段确认报文只在正确的环内传播。4.2 不同厂商设备混组时的三个一致性检查混组是血泪经验最多的场景。必须保证三件事一致Control VLAN 一致所有节点的 R-APS 报文 VLAN 必须相同。Node ID 唯一每个节点的 Node ID 不能重复有些设备默认用 MAC有些要手工配。计时器量纲一致前面说过Guard 和 WTR 的单位不同厂商可能不同混组前必须对齐。检查方法是在每个节点上 show 配置逐项对比。如果发现倒换后业务时通时断优先查 Node ID 有没有冲突。4.3 用 Y.1731 做倒换性能测量ERPS 本身不提供性能测量但可以配合 Y.1731 的 ETH-CC 和 ETH-LM 来测倒换时间和丢包。做法是在环上一条业务流的两端配 Y.1731 测量实例倒换发生时看丢包数和中断时长。这样能把「感觉慢」变成具体数字定位是 ERPS 状态机慢还是业务侧收敛慢。5. 避坑与排查倒换不成功时先看这五条现网出问题八成是下面几个原因。按现象、原因、解决三步走。5.1 现象倒换后业务不通但状态显示已切换原因MAC 地址表没有清除流量还被引向断点。ERPS 倒换时会发 R-APS 触发 MAC 清除但如果设备没正确处理残留表项会持续一段时间。解决检查设备是否支持 ERPS 触发的 MAC flush必要时手工清除或者把 MAC 老化时间调短。验证方法是倒换后立刻 show mac address-table看断点侧端口还有没有表项。5.2 现象环上反复倒换日志刷屏原因WTR 设得太短或者链路本身在抖动。链路瞬断导致 SF 和 NR 交替出现状态机跟着来回切。解决加大 WTR 到 300 秒以上同时在端口上配 hold-off 计时器过滤掉毫秒级瞬断。如果链路质量确实差先解决物理层问题。5.3 现象抓不到 R-APS 报文原因Control VLAN 没配通或者组播地址被过滤。有些设备的环端口默认不转发 ERPS 组播。解决确认环端口允许 Control VLAN 通过确认没有 ACL 过滤 01-19-A7-00-00-01。在中间节点抓包看报文有没有被转发。5.4 现象多环场景下内层环故障导致外层环倒换原因子环和主环的 R-APS 报文没有隔离内层 SF 被外层处理。解决检查虚拟通道配置确认子环报文带正确的环 ID外层环节点忽略非本环报文。5.5 现象混组时一边倒换一边不倒换原因Node ID 冲突或者计时器量纲不一致。解决逐节点核对 Node ID统一计时器单位。混组前先在实验室把两个厂商的设备对接测一遍别直接上现网。6. 自己搭一套验证环境把倒换时间测到毫秒级标准读再多不如自己测一遍。这一章给一套可复现的验证方法用两台设备加一台测试仪就能做。6.1 最小验证拓扑和仪表接法拓扑很简单两台支持 ERPS 的设备组成一个环中间用两条链路连起来一条主用一条备用。测试仪接在环的两端打一条已知速率的业务流。测试仪要能记录丢包和时间戳这样才能算出倒换时间。接法上注意测试仪的发送端口接节点 A 的业务口接收端口接节点 B 的业务口业务流穿过整个环。断开主用链路看测试仪记录的中断时长。6.2 用打流工具测倒换中断时长如果没有专业测试仪可以用两台 Linux 主机加打流工具。一台用 iperf3 持续打流另一台记录接收情况# 发送端持续打 UDP 流带时间戳 iperf3 -c 192.168.1.2 -u -b 100M -t 300 --timestamp # 接收端记录倒换时观察丢包 iperf3 -s -i 1倒换发生时接收端会看到一段丢包。用 iperf3 的间隔报告能粗略看出中断了几个报告周期精度到秒级。要测到毫秒级得用支持硬件时间戳的仪表。6.3 从测试结果反推参数是否合理测完之后看几个数中断时长、丢包数、恢复后有没有二次中断。如果中断时长超过 50ms先查 Guard 和 Hold-off 是不是设大了如果有二次中断查 WTR 和链路稳定性。把每次调整后的结果记下来形成自己环网的参数基线。6.4 我踩过的坑和现在的习惯早期我配 ERPS总觉得配完能通就行结果一次现网割接倒换时间到了 200ms业务侧投诉。后来养成习惯任何环网改动前先在实验室用仪表测一遍把 Guard、WTR、Hold-off 三个值记在配置模板里上现网前逐项核对。还有一个习惯是每次倒换测试都抓包存下来出问题的时候有据可查不用靠猜。ERPS 这东西参数对了很稳参数错了就是玄学而玄学基本都是没测到位。希望帮到你。本文还有配套的精品资源点击获取