简介IEC 62439-3:2016国际标准原版PDF面向工业自动化、电力、交通等领域的网络工程师与系统设计人员完整规定Parallel Redundancy ProtocolPRP和高可用性无缝冗余HSR的技术规范用于解决关键工业网络因单点故障导致业务中断的问题是高可用自动化网络设计的重要依据。标准内容涵盖PRP与HSR的架构原理、帧格式、冗余管理、配置方法、诊断与测试流程以及与其他工业通信协议的集成指导。资源为一份PDF文件共358页压缩包大小6.65MB属2016年3月发布的Edition 3.0英法双语版本适合离线查阅与团队共享。目前已有390人学习下载尤其适合变电站自动化、工业以太网、高可靠控制系统等领域的工程师用于保障关键任务系统在故障情况下实现无缝切换。1. IEC 62439-3-2016 是什么给过程工业的无缝冗余协议做变电站自动化、轨道信号或油气田 SIS 系统的工程师应该都遇到过这样的尴尬业务侧要求网络故障恢复时间小于 10ms甚至要求 0 丢包而传统环网协议 STP、MRP 的倒换时间再快也是几十毫秒。IEC 62439-3-2016 就是为这类需求编写的标准。它定义了 PRPParallel Redundancy Protocol和 HSRHigh-availability Seamless Redundancy两种无缝冗余机制思路不是故障后去收敛而是让每个帧同时走两条路径接收端只取到得早的那一份。适合正在做 IEC 61850 变电站、过程控制高可用网络或者准备把普通以太网升级成冗余网络的从业人员。这篇内容不解释条款只讲按这个标准做网络、调设备、排故障的真实路径。2. 为什么是 PRP 和 HSR原理与 2016 版的关键修正2.1 先分清三种冗余MRP、PRP、HSRIEC 62439 标准族里常被拿来对比的是 MRPMedia Redundancy Protocol、PRP 和 HSR。MRP 是环网协议适用于允许几十毫秒倒换的场景故障后需要重新收敛所以严格说它属于快速恢复而不是无缝冗余。PRP 和 HSR 才是真正意义上的无缝冗余发送端复制帧接收端收到两个完全相同但路径不同的帧后只保留一个丢一个链路对应用层完全无感知。理解 2016 版先要抓住一个关键点标准并没有重新发明协议而是把 PRP 和 HSR 统一纳入高可用无缝冗余框架并修正了之前版本里模糊的行为。PRP 面向两个相互独立、结构上平行的局域网HSR 面向单个环形拓扑。两者帧结构和工作模式不同但核心思想一样源节点发出双份目的节点去重。2.2 PRP 的双网复制DANP、SAN 与 RedBoxPRP 网络中每个支持冗余的节点叫 DANPDoubly Attached Node with PRP。它有两个以太网口分别接在 LAN A 和 LAN B 上。发送时DANP 将每个 L2 帧复制一份A 口和 B 口各发一帧接收时从两个口分别收到相同帧后按时间戳或序列号去重只把先到的帧交给应用层。两个 LAN 完全独立任何一侧断掉另一侧仍能拿到完整帧这就是并行冗余。实际现场不是所有设备都支持 PRP比如普通 PLC、摄像头或单网卡服务器。这类设备叫 SANSingly Attached Node它只有一份物理连接。标准给出的做法是给 SAN 挂一台 RedBoxRedundancy Box这台盒子一头连 SAN另一头同时连 LAN A 和 LAN B。SAN 发出的帧由 RedBox 复制两份进入两个 LANRedBox 收到的帧在去重后再转发给 SAN。RedBox 本质上是把不冗余的设备包装成逻辑上的双网设备。这里最容易产生误解PRP 的两个 LAN 不是链路聚合也不要求两边交换机配置一致。它们可以来自不同厂商、不同网络结构甚至一边直连一边经过多跳交换机。只要两个网络都存在且能转发同一 IP 子网的帧PRP 就能工作。这也是现场比较喜欢 PRP 的原因——不用改交换机只要加设备。2.3 HSR 的环形复制每一帧双向遍历HSR 不是双网络而是把节点串成一个环。每个支持 HSR 的节点有两个物理口分别连接环上的前一跳和后一跳。发送帧时源节点从两个口各发一份一份顺时针走一份逆时针走。每个收到帧的中间节点负责两件事如果帧的目的地址是它自己就交给上层处理同时把另一份副本丢弃如果目的地址不是它就继续原路转发但不再重复复制。环内所有 HSR 节点都在转发数据所以不需要外接交换机。这带来的好处是节省布线很适合舱室、车辆和设备间距离短的场景。代价是每个节点都要参与转发网络中的任何一个非 HSR 设备都会打断环路必须通过 RedBox 接入。HSR 节点也要维护一张 Node Table记录环上其他节点的 MAC 地址、端口和时间戳避免单播帧在整个环上无休止地泛洪。2.4 2016 版相比 2010 版改了什么很多手头有旧版资料的人直接拿 2010 版做设计落 2016 版时才发现行为对不上。按我的理解2016 版最重要的变化是把 PRP 的 RCTRedundancy Control Trailer和 HSR 的 HSR Tag 格式、节点表老化机制、监督帧Supervision Frame发送规则做了收紧。过去厂商可以自行决定节点表什么时候删除陈旧条目、监督帧周期是多少2016 版明确推荐了行为基准保证不同厂商 RedBox 混合接入时的互操作性。另一个被忽略的变化是标准对 SAN 接入的时序提出了更细的要求。比如 RedBox 什么时候开始复制未知目的地址的帧、收到重复帧后等待多久、哪些帧不做冗余处理。这些细节正是现场联调时最容易起争执的地方。如果你在选型时发现某个 RedBox 只标了支持 PRP/HSR但拿不出针对 IEC 62439-3-2016 的一致性测试报告我建议直接淘汰。3. 选型与参数设定先算拓扑、延时和监督帧3.1 PRP 还是 HSR变电站和轨交场景的选型建议选型不能只看协议名要看物理条件。变电站自动化是我见过用 PRP 最多的场景原因是站内通常已经有双光纤网或双交换机只需要把保护测控装置的 A/B 网口分别接到两套网络即可网络结构天然就是双星。整个过程不需要把站控层交换机串进环路扩容和检修一个网络时另一个网络仍在线。IEC 61850 的 GOOSE 和 SV 报文对实时性要求极高PRP 的路径独立性比共享环网更让人放心。HSR 适合新增布线成本高、空间受限的设备组比如车载系统、海上平台或者嵌入式设备之间。两台 HSR 交换机之间是一条环形的双口连接不需要像 PRP 那样建立两套独立网络。但要注意HSR 环上的所有节点都在帮别人转发业务帧链路带宽是共享的。如果环上接了太多摄像头或大流量采集器每个节点的吞吐压力都会上升。3.2 冗余连接节点RedBox与 SAN 接入RedBox 的选型参数不能只看支持 PRP/HSR还要看它是否支持混合模式。有些设备可以实现 PRP/HSR 转换也就是一边进 PRP 双网络另一边进 HSR 环网这在跨系统互联时非常实用。但混合模式会带来帧格式转换必须在验证环境里先做重复帧去重检查不能直接上现场。SAN 接入时还要想清楚一个 RedBox 只服务一个 SAN 设备还是多个 SAN 设备共享标准没有禁止多 SAN 挂在一个 RedBox 后面但共享 RedBox 可能成为单点故障。如果 SAN 是保护测控装置这种核心设备最好是每个装置配一个独立 RedBox链路、电源、设备都独立。3.3 监督帧、Node 表超时和序列号字段参数PRP 和 HSR 都通过监督帧来维护节点表。每个节点周期性地发送监督帧告知其他节点自己的 MAC 地址、端口信息和冗余状态。另一个节点如果在设定时间内没有收到该节点的任何帧就会把这个节点从表中删除之后发往它的单播帧会按未知单播启动泛洪。监督帧周期和 Node 表超时时间是需要联调的。周期太短网络里全是无用帧周期太长节点掉线后表项不能及时清除恢复时间变长。常见设备默认监督帧周期在 2 秒左右表项超时是周期的若干倍。如果你的网络里节点数量超过几十个建议监督帧周期不要激进缩短因为每个节点都要发出广播性的监督帧总带宽占用会线性增长。序列号字段是去重的关键。PRP 和 HSR 的帧头里都带 16 位序列号发送端每发一个帧就加一接收端用序列号识别重复帧。这里有隐藏问题当序列号翻转循环到 0时接收端不能简单认为这是重复帧必须结合 MAC 地址和时间窗口判断。我在 Linux 实验里就遇到过因为没有正确复位序列号导致丢了一小段窗口内的业务帧。3.4 交换机与光纤链路参数带宽容量的估算PRP 对交换机的参数要求往往被低估。虽然 PRP 复制的是单播帧但交换机可能会把冗余帧当成普通帧处理如果交换机开启了流量镜像或 ACL可能会过滤掉重复帧。更常见的问题是两个 LAN 的交换机端口数量、光纤带宽不一致导致同一帧在 A 网先到、B 网后到的时延差超过接收端的去重窗口。PRP 标准里给的是逻辑行为物理时延差要靠设计控制。带宽估算上要乘2。无论 PRP 还是 HSR一份业务帧在网络里实际是两份。假设业务总带宽 30MbpsPRP 在双网里各占 30Mbps总计 60MbpsHSR 受拓扑影响最坏情况下每个节点都要转发两份帧靠近环上某个出口的节点可能承担最多的转发压力。设计交换机时负荷临界值不能只看应用层流量冗余复制带来的额外带宽要预留 30% 余量。4. 用 Linux 驱动搭一套可复现的验证实验HSR/PRP 最小配置4.1 在两台 Linux 主机上创建 HSR 接口Linux 内核自带 HSR/PRP 协议栈虽然比不上商用 RedBox 的硬件转发性能但用来理解协议、验证帧格式、做互操作测试非常合适。我常用的做法是找两台 Ubuntu 主机每台给它插两张千兆网卡然后组成一个两节点的 HSR 环。两节点环也是有效拓扑能验证重复帧和链路切换。在每台主机上执行同样的命令组# 把两个物理口都关闭避免 DHCP 或 NetworkManager 抢占 ip link set eth0 down ip link set eth1 down # 用 eth0 和 eth1 作为两个从口创建 hsr0 逻辑口 ip link add hsr0 type hsr slave1 eth0 slave2 eth1 version 1 # 给 hsr0 配置管理 IP后续业务全部走这个口 ip addr add 192.168.200.5/24 dev hsr0 ip link set hsr0 up # 确认新建的接口和绑定关系 ip -d link show hsr0这段命令里slave1和slave2分别指定 HSR 环上的两个物理口。version 1对应 IEC 62439-3 中较新的 HSR 协议版本如果你的现场设备只支持协议版本 0这里要改成version 0。hsr0创建后系统会把 eth0 和 eth1 作为从口从普通网卡列表中移出所以需要在创建之前完成物理口的状态设置。创建完 hsr0 后路由表里会自动生成与 192.168.200.0/24 相关的本地路由。另一台主机用同样命令配置成 192.168.200.6/24物理口接线时注意交叉连接A 主机的 eth0 接 B 主机的 eth0A 主机的 eth1 接 B 主机的 eth1。直连时是否需要交叉线取决于网卡是否支持自动翻转千兆网卡基本都支持不需要手工做交叉。4.2 用 ping 验证双路径转发和丢包配置完成后从 A 主机 ping B 主机使用-I强制指定 hsr0 作为出口ping -I hsr0 192.168.200.6 -c 4如果配置正确ping 应当全部通过。实际发出的帧会从 eth0 和 eth1 各出去一份B 主机的 hsr0 口收到两个相同帧后在协议栈去重所以应用层只会收到一个 ICMP Echo。你可以在 ping 的同时分别把 eth0 和 eth1 个物理口用网线拔掉观察 ping 是否丢包。这里有一个值得注意的细节HSR 环上所有节点的 hsr0 口必须配置在同一个子网但物理口 eth0/eth1 本身不能配置 IP。很多新手会顺手给 eth0 配一个管理 IP结果 hsr0 创建时把这个口抢走了IP 配置消失然后业务就乱了。物理口加入 hsr0 后它的所有 L2/L3 配置都会由 hsr0 接管不需要也不应该在 eth0/eth1 上再做地址配置。4.3 用 tcpdump 观察重复帧和 HSR 标签要证明协议确实在工作可以在 B 主机的 eth0 和 eth1 上同时抓包。另开一个终端执行# 在 B 主机的两个物理口上分别抓包各自保存成文件 tcpdump -i eth0 -e -nn -v -w /tmp/eth0.pcap tcpdump -i eth1 -e -nn -v -w /tmp/eth1.pcap 然后回到 A 主机再 ping 一次。之后停止 tcpdump用tcpdump -r读包比较两个文件。你会在 eth0.pcap 和 eth1.pcap 中看到源 MAC、目的 MAC 相同的帧但到达时间不同并且链路层信息里比普通以太网多出冗余信息。这就是 HSR 的路径标识和序列号字段Wireshark 打开后能直接看到 HSR Tag 的解析。在-v输出里你可能看不到一个叫 HSR type 的协议名因为 HSR 不改变 EtherType它是在常规以太网帧头之后插入冗余标记。所以识别方法不是按协议类型过滤而是看同一对 MAC 地址是否在两个口上以极短时间间隔重复出现。这个习惯带到现场很实用很多商用抓包工具同样要靠这个特征定位。4.4 Linux 驱动方式模拟 PRP 的差别Linux 内核的 hsr 驱动在新版本里也能模拟 PRP 的重复帧去重逻辑。实现上ip link add命令的条目类型仍然是 hsr但内部协议可以切换成 PRP。不同内核版本对这个功能的支持差异比较大有的需要通过hsr0模块参数切换有的发行版并没有把 PRP 模式编译进去。我先用 HSR 验证重复帧机制再用 PRP 模式跑通同构实验。如果内核不支持 PRP 模式我一般会退回传统做法在普通 Linux 网卡上用软件或专用 RedBox 实际搭 PRP 双网络。拓扑是两台 DANP 设备各接两个独立交换机形成一个双星网络。DANP 的驱动由设备厂家提供行为逻辑和内嵌的 PRP 引擎一致。这种方式更贴近变电站现场适合验证 PRP 去重和链路切换时间。无论哪种方式实验环境里想要得到可信结果必须确保内核开启CONFIG_HSR或相应模块运行modinfo hsr能看到驱动信息。如果系统自带的驱动版本过低建议用厂商的补丁内核或独立驱动否则抓到的帧格式可能和 IEC 62439-3-2016 不一致。Linux 驱动是学习协议的好工具但不要把它当作正式 RedBox 的替代品来验证投标指标。5. 现场避坑与排查五个让冗余失效的常见问题5.1 双网口都在回 ARP交换机的 MAC 表来回跳现象PRP 网络里接入一台配置错误的 DANP 设备后网络出现间歇性连接失败交换机端口 MAC 表在几个端口间反复跳变监控系统出现大量 ARP 冲突告警。原因这台设备把两个物理口都暴露给了操作系统没有启用冗余去重功能。于是网卡从 LAN A 收到 ARP 请求并回应过几十毫秒又从 LAN B 收到同一份 ARP 请求再回应一次。交换机从两个端口学到了同一个 MAC 地址后续转发时来回震荡业务流量被频繁丢弃。解决先排查设备内部网卡是否被正确绑定成 PRP 口。Linux 系统查看ip -d link show确认口状态商用设备检查网卡驱动是否工作在 DANP 模式。如果设备本身不支持 PRP就把它降级成 SAN前端挂 RedBox避免双口直接暴露。只靠封禁一个交换机端口来让 MAC 地址不再跳是掩耳盗铃治标不治本。5.2 SAN 设备掉线因为上游 RedBox 没有开启重复帧消除现象PLC 挂在 RedBox 后面RedBox 上连 PRP 双网。业务运行正常但只要 LAN B 的交换机做一次端口重启PLC 与上位机的通信中断十几秒才恢复。原因RedBox 的重复帧去重功能默认关闭它把两个网络收到的同一份帧当作两个不同帧同时转发给 PLC。正常情况下 PLC 靠上层协议识别重复还能运行一旦某一侧网络抖动重复帧到达顺序错乱PLC 的协议栈被干扰连接就会复位。解决登录 RedBox确认 PRP 去重开关已打开并把去重等待窗口从默认值调整到和 LAN A/B 时延差匹配。现场验证时不要只测拔一根线要故意把一侧交换机重启观察 SAN 设备的通信中断时长。如果 RedBox 的去重窗口不可调坚决不用于控制类业务。5.3 环里混进了一台普通交换机网络风暴现象HSR 环网调试时某个节点下挂了一台普通二层交换机结果整个环的广播包呈指数增长所有节点 CPU 占用升高业务大面积卡顿。原因普通交换机不具备 HSR 转发和去重逻辑。HSR 环上的每个节点会把收到的 HSR 帧从另一个口转发出去而普通交换机接到环口后会把广播帧再反射回环形成重复帧不断绕环。HSR 的节点表无法识别普通交换机背后的设备导致广播风暴一直持续。解决强制规定 HSR 环上只允许连接支持 HSR 的设备普通设备全部通过 RedBox 或 HSR 交换机扩展。如果现场必须接入普通交换机要在 HSR 交换机上配置端口隔离和广播抑制但本质上这是一个错误的网络结构。排查时用 tcpdump 从环口抓包看到同一广播帧在一个口上反复出现就说明有非 HSR 设备在转发。5.4 高负荷下序列号翻转接收端把新帧误判成重复帧现象长时间跑大数据量吞吐测试时链路偶尔出现几秒全部丢包但网络设备状态和物理链路都正常丢包时间点没有规律。原因16 位序列号上限是 65535。发送速率高时序列号很快到最大值并翻转回 0。接收端在去重表里还留有刚才的记录看到新的 00 开头的序列号误认为是已经收过的旧帧直接丢弃导致丢包直到去重表项老化。解决正确实现的标准在接收端会把序列号相同和来源不同联合判断并通过 MAC 地址和时间戳排除翻转情况。遇到这个现象要检查设备固件是否按 2016 版要求处理序列号回绕。如果无法升级就只能限制发送速率或缩短去重表存活时间但这是临时方案正式设备不应该出现这种问题。5.5 监督帧被广播风暴淹没节点表频繁老化现象HSR 环上节点数量增多后部分远端节点从 Node Table 中反复消失单播帧被泛洪网络性能下降。原因所有节点都在发监督帧但交换机或 HSR 节点没有为监督帧配置较高优先级。在网络拥塞时监督帧的数据量本身不大却和业务广播帧一起被丢弃导致节点表维护超时。典型表现是节点表反复先超时、后恢复。解决给监督帧打上高优先级 VLAN 标签并限制广播业务占用带宽。标准对监督帧的处理有默认行为但现场多厂商设备混接时优先级策略往往不一致。确认所有设备都把监督帧归入同一个高优先级队列并在抓包中单独过滤监督帧看它们在高峰期是否仍能稳定到达。6. 调试技巧用一个小脚本完成切换时间验收现场验收 PRP/HSR 时最常被业主的问题是你说零丢包怎么证明。我一般会在两台设备之间跑一个持续 ping然后人为断开一个物理链路通过抓包或者 ping 回显来记录有没有丢包。注意普通 ping 的最小发包间隔是 100ms并不能证明 1ms 级切换所以要缩短发包间隔并且统计序列号。#!/bin/bash # 用 -f 发快速 ping每次间隔 100ms共 300 个包 # 中途手动断开再恢复 eth1验收后看序列号是否连续 ping -I hsr0 192.168.200.6 -f -c 300 -W 1 | tail -n 2 # 更严格的做法是抓 icmp echo request 的序列号 # tcpdump -i hsr0 -nn -c 400 icmp and host 192.168.200.6手动测试时我会配合 tcpdump 在接收端抓包然后在 tcpdump 的序列号输出里检查 ICMP ID 和 seq 是否连续。拔掉物理链路的那几百毫秒里只要 seq 还有没有空缺就说明切换是无缝的。如果是 PRP 网络我会分别在 LAN A 和 LAN B 的交换机上同时抓包确认断开 LAN A 后LAN B 的帧始终在正常到达。把这个脚本固定成验收用例配合大帧、小帧、组播三种流量类型各跑一轮比直接看设备面板上的链路状态有用。我还习惯在抓包里过滤出监督帧单独确认节点表记录正确。最后想提醒一句现场验收不要只测一次断链和恢复各测 5 轮观察最长丢包数和最大时延。很多设备第一次测表现很好第二次起因为节点表状态不同就现出原形。希望这篇内容能帮你少走弯路。本文还有配套的精品资源点击获取 IEC 62439-3-2016解读：PRP/HSR无缝冗余网络实战指南
简介IEC 62439-3:2016国际标准原版PDF面向工业自动化、电力、交通等领域的网络工程师与系统设计人员完整规定Parallel Redundancy ProtocolPRP和高可用性无缝冗余HSR的技术规范用于解决关键工业网络因单点故障导致业务中断的问题是高可用自动化网络设计的重要依据。标准内容涵盖PRP与HSR的架构原理、帧格式、冗余管理、配置方法、诊断与测试流程以及与其他工业通信协议的集成指导。资源为一份PDF文件共358页压缩包大小6.65MB属2016年3月发布的Edition 3.0英法双语版本适合离线查阅与团队共享。目前已有390人学习下载尤其适合变电站自动化、工业以太网、高可靠控制系统等领域的工程师用于保障关键任务系统在故障情况下实现无缝切换。1. IEC 62439-3-2016 是什么给过程工业的无缝冗余协议做变电站自动化、轨道信号或油气田 SIS 系统的工程师应该都遇到过这样的尴尬业务侧要求网络故障恢复时间小于 10ms甚至要求 0 丢包而传统环网协议 STP、MRP 的倒换时间再快也是几十毫秒。IEC 62439-3-2016 就是为这类需求编写的标准。它定义了 PRPParallel Redundancy Protocol和 HSRHigh-availability Seamless Redundancy两种无缝冗余机制思路不是故障后去收敛而是让每个帧同时走两条路径接收端只取到得早的那一份。适合正在做 IEC 61850 变电站、过程控制高可用网络或者准备把普通以太网升级成冗余网络的从业人员。这篇内容不解释条款只讲按这个标准做网络、调设备、排故障的真实路径。2. 为什么是 PRP 和 HSR原理与 2016 版的关键修正2.1 先分清三种冗余MRP、PRP、HSRIEC 62439 标准族里常被拿来对比的是 MRPMedia Redundancy Protocol、PRP 和 HSR。MRP 是环网协议适用于允许几十毫秒倒换的场景故障后需要重新收敛所以严格说它属于快速恢复而不是无缝冗余。PRP 和 HSR 才是真正意义上的无缝冗余发送端复制帧接收端收到两个完全相同但路径不同的帧后只保留一个丢一个链路对应用层完全无感知。理解 2016 版先要抓住一个关键点标准并没有重新发明协议而是把 PRP 和 HSR 统一纳入高可用无缝冗余框架并修正了之前版本里模糊的行为。PRP 面向两个相互独立、结构上平行的局域网HSR 面向单个环形拓扑。两者帧结构和工作模式不同但核心思想一样源节点发出双份目的节点去重。2.2 PRP 的双网复制DANP、SAN 与 RedBoxPRP 网络中每个支持冗余的节点叫 DANPDoubly Attached Node with PRP。它有两个以太网口分别接在 LAN A 和 LAN B 上。发送时DANP 将每个 L2 帧复制一份A 口和 B 口各发一帧接收时从两个口分别收到相同帧后按时间戳或序列号去重只把先到的帧交给应用层。两个 LAN 完全独立任何一侧断掉另一侧仍能拿到完整帧这就是并行冗余。实际现场不是所有设备都支持 PRP比如普通 PLC、摄像头或单网卡服务器。这类设备叫 SANSingly Attached Node它只有一份物理连接。标准给出的做法是给 SAN 挂一台 RedBoxRedundancy Box这台盒子一头连 SAN另一头同时连 LAN A 和 LAN B。SAN 发出的帧由 RedBox 复制两份进入两个 LANRedBox 收到的帧在去重后再转发给 SAN。RedBox 本质上是把不冗余的设备包装成逻辑上的双网设备。这里最容易产生误解PRP 的两个 LAN 不是链路聚合也不要求两边交换机配置一致。它们可以来自不同厂商、不同网络结构甚至一边直连一边经过多跳交换机。只要两个网络都存在且能转发同一 IP 子网的帧PRP 就能工作。这也是现场比较喜欢 PRP 的原因——不用改交换机只要加设备。2.3 HSR 的环形复制每一帧双向遍历HSR 不是双网络而是把节点串成一个环。每个支持 HSR 的节点有两个物理口分别连接环上的前一跳和后一跳。发送帧时源节点从两个口各发一份一份顺时针走一份逆时针走。每个收到帧的中间节点负责两件事如果帧的目的地址是它自己就交给上层处理同时把另一份副本丢弃如果目的地址不是它就继续原路转发但不再重复复制。环内所有 HSR 节点都在转发数据所以不需要外接交换机。这带来的好处是节省布线很适合舱室、车辆和设备间距离短的场景。代价是每个节点都要参与转发网络中的任何一个非 HSR 设备都会打断环路必须通过 RedBox 接入。HSR 节点也要维护一张 Node Table记录环上其他节点的 MAC 地址、端口和时间戳避免单播帧在整个环上无休止地泛洪。2.4 2016 版相比 2010 版改了什么很多手头有旧版资料的人直接拿 2010 版做设计落 2016 版时才发现行为对不上。按我的理解2016 版最重要的变化是把 PRP 的 RCTRedundancy Control Trailer和 HSR 的 HSR Tag 格式、节点表老化机制、监督帧Supervision Frame发送规则做了收紧。过去厂商可以自行决定节点表什么时候删除陈旧条目、监督帧周期是多少2016 版明确推荐了行为基准保证不同厂商 RedBox 混合接入时的互操作性。另一个被忽略的变化是标准对 SAN 接入的时序提出了更细的要求。比如 RedBox 什么时候开始复制未知目的地址的帧、收到重复帧后等待多久、哪些帧不做冗余处理。这些细节正是现场联调时最容易起争执的地方。如果你在选型时发现某个 RedBox 只标了支持 PRP/HSR但拿不出针对 IEC 62439-3-2016 的一致性测试报告我建议直接淘汰。3. 选型与参数设定先算拓扑、延时和监督帧3.1 PRP 还是 HSR变电站和轨交场景的选型建议选型不能只看协议名要看物理条件。变电站自动化是我见过用 PRP 最多的场景原因是站内通常已经有双光纤网或双交换机只需要把保护测控装置的 A/B 网口分别接到两套网络即可网络结构天然就是双星。整个过程不需要把站控层交换机串进环路扩容和检修一个网络时另一个网络仍在线。IEC 61850 的 GOOSE 和 SV 报文对实时性要求极高PRP 的路径独立性比共享环网更让人放心。HSR 适合新增布线成本高、空间受限的设备组比如车载系统、海上平台或者嵌入式设备之间。两台 HSR 交换机之间是一条环形的双口连接不需要像 PRP 那样建立两套独立网络。但要注意HSR 环上的所有节点都在帮别人转发业务帧链路带宽是共享的。如果环上接了太多摄像头或大流量采集器每个节点的吞吐压力都会上升。3.2 冗余连接节点RedBox与 SAN 接入RedBox 的选型参数不能只看支持 PRP/HSR还要看它是否支持混合模式。有些设备可以实现 PRP/HSR 转换也就是一边进 PRP 双网络另一边进 HSR 环网这在跨系统互联时非常实用。但混合模式会带来帧格式转换必须在验证环境里先做重复帧去重检查不能直接上现场。SAN 接入时还要想清楚一个 RedBox 只服务一个 SAN 设备还是多个 SAN 设备共享标准没有禁止多 SAN 挂在一个 RedBox 后面但共享 RedBox 可能成为单点故障。如果 SAN 是保护测控装置这种核心设备最好是每个装置配一个独立 RedBox链路、电源、设备都独立。3.3 监督帧、Node 表超时和序列号字段参数PRP 和 HSR 都通过监督帧来维护节点表。每个节点周期性地发送监督帧告知其他节点自己的 MAC 地址、端口信息和冗余状态。另一个节点如果在设定时间内没有收到该节点的任何帧就会把这个节点从表中删除之后发往它的单播帧会按未知单播启动泛洪。监督帧周期和 Node 表超时时间是需要联调的。周期太短网络里全是无用帧周期太长节点掉线后表项不能及时清除恢复时间变长。常见设备默认监督帧周期在 2 秒左右表项超时是周期的若干倍。如果你的网络里节点数量超过几十个建议监督帧周期不要激进缩短因为每个节点都要发出广播性的监督帧总带宽占用会线性增长。序列号字段是去重的关键。PRP 和 HSR 的帧头里都带 16 位序列号发送端每发一个帧就加一接收端用序列号识别重复帧。这里有隐藏问题当序列号翻转循环到 0时接收端不能简单认为这是重复帧必须结合 MAC 地址和时间窗口判断。我在 Linux 实验里就遇到过因为没有正确复位序列号导致丢了一小段窗口内的业务帧。3.4 交换机与光纤链路参数带宽容量的估算PRP 对交换机的参数要求往往被低估。虽然 PRP 复制的是单播帧但交换机可能会把冗余帧当成普通帧处理如果交换机开启了流量镜像或 ACL可能会过滤掉重复帧。更常见的问题是两个 LAN 的交换机端口数量、光纤带宽不一致导致同一帧在 A 网先到、B 网后到的时延差超过接收端的去重窗口。PRP 标准里给的是逻辑行为物理时延差要靠设计控制。带宽估算上要乘2。无论 PRP 还是 HSR一份业务帧在网络里实际是两份。假设业务总带宽 30MbpsPRP 在双网里各占 30Mbps总计 60MbpsHSR 受拓扑影响最坏情况下每个节点都要转发两份帧靠近环上某个出口的节点可能承担最多的转发压力。设计交换机时负荷临界值不能只看应用层流量冗余复制带来的额外带宽要预留 30% 余量。4. 用 Linux 驱动搭一套可复现的验证实验HSR/PRP 最小配置4.1 在两台 Linux 主机上创建 HSR 接口Linux 内核自带 HSR/PRP 协议栈虽然比不上商用 RedBox 的硬件转发性能但用来理解协议、验证帧格式、做互操作测试非常合适。我常用的做法是找两台 Ubuntu 主机每台给它插两张千兆网卡然后组成一个两节点的 HSR 环。两节点环也是有效拓扑能验证重复帧和链路切换。在每台主机上执行同样的命令组# 把两个物理口都关闭避免 DHCP 或 NetworkManager 抢占 ip link set eth0 down ip link set eth1 down # 用 eth0 和 eth1 作为两个从口创建 hsr0 逻辑口 ip link add hsr0 type hsr slave1 eth0 slave2 eth1 version 1 # 给 hsr0 配置管理 IP后续业务全部走这个口 ip addr add 192.168.200.5/24 dev hsr0 ip link set hsr0 up # 确认新建的接口和绑定关系 ip -d link show hsr0这段命令里slave1和slave2分别指定 HSR 环上的两个物理口。version 1对应 IEC 62439-3 中较新的 HSR 协议版本如果你的现场设备只支持协议版本 0这里要改成version 0。hsr0创建后系统会把 eth0 和 eth1 作为从口从普通网卡列表中移出所以需要在创建之前完成物理口的状态设置。创建完 hsr0 后路由表里会自动生成与 192.168.200.0/24 相关的本地路由。另一台主机用同样命令配置成 192.168.200.6/24物理口接线时注意交叉连接A 主机的 eth0 接 B 主机的 eth0A 主机的 eth1 接 B 主机的 eth1。直连时是否需要交叉线取决于网卡是否支持自动翻转千兆网卡基本都支持不需要手工做交叉。4.2 用 ping 验证双路径转发和丢包配置完成后从 A 主机 ping B 主机使用-I强制指定 hsr0 作为出口ping -I hsr0 192.168.200.6 -c 4如果配置正确ping 应当全部通过。实际发出的帧会从 eth0 和 eth1 各出去一份B 主机的 hsr0 口收到两个相同帧后在协议栈去重所以应用层只会收到一个 ICMP Echo。你可以在 ping 的同时分别把 eth0 和 eth1 个物理口用网线拔掉观察 ping 是否丢包。这里有一个值得注意的细节HSR 环上所有节点的 hsr0 口必须配置在同一个子网但物理口 eth0/eth1 本身不能配置 IP。很多新手会顺手给 eth0 配一个管理 IP结果 hsr0 创建时把这个口抢走了IP 配置消失然后业务就乱了。物理口加入 hsr0 后它的所有 L2/L3 配置都会由 hsr0 接管不需要也不应该在 eth0/eth1 上再做地址配置。4.3 用 tcpdump 观察重复帧和 HSR 标签要证明协议确实在工作可以在 B 主机的 eth0 和 eth1 上同时抓包。另开一个终端执行# 在 B 主机的两个物理口上分别抓包各自保存成文件 tcpdump -i eth0 -e -nn -v -w /tmp/eth0.pcap tcpdump -i eth1 -e -nn -v -w /tmp/eth1.pcap 然后回到 A 主机再 ping 一次。之后停止 tcpdump用tcpdump -r读包比较两个文件。你会在 eth0.pcap 和 eth1.pcap 中看到源 MAC、目的 MAC 相同的帧但到达时间不同并且链路层信息里比普通以太网多出冗余信息。这就是 HSR 的路径标识和序列号字段Wireshark 打开后能直接看到 HSR Tag 的解析。在-v输出里你可能看不到一个叫 HSR type 的协议名因为 HSR 不改变 EtherType它是在常规以太网帧头之后插入冗余标记。所以识别方法不是按协议类型过滤而是看同一对 MAC 地址是否在两个口上以极短时间间隔重复出现。这个习惯带到现场很实用很多商用抓包工具同样要靠这个特征定位。4.4 Linux 驱动方式模拟 PRP 的差别Linux 内核的 hsr 驱动在新版本里也能模拟 PRP 的重复帧去重逻辑。实现上ip link add命令的条目类型仍然是 hsr但内部协议可以切换成 PRP。不同内核版本对这个功能的支持差异比较大有的需要通过hsr0模块参数切换有的发行版并没有把 PRP 模式编译进去。我先用 HSR 验证重复帧机制再用 PRP 模式跑通同构实验。如果内核不支持 PRP 模式我一般会退回传统做法在普通 Linux 网卡上用软件或专用 RedBox 实际搭 PRP 双网络。拓扑是两台 DANP 设备各接两个独立交换机形成一个双星网络。DANP 的驱动由设备厂家提供行为逻辑和内嵌的 PRP 引擎一致。这种方式更贴近变电站现场适合验证 PRP 去重和链路切换时间。无论哪种方式实验环境里想要得到可信结果必须确保内核开启CONFIG_HSR或相应模块运行modinfo hsr能看到驱动信息。如果系统自带的驱动版本过低建议用厂商的补丁内核或独立驱动否则抓到的帧格式可能和 IEC 62439-3-2016 不一致。Linux 驱动是学习协议的好工具但不要把它当作正式 RedBox 的替代品来验证投标指标。5. 现场避坑与排查五个让冗余失效的常见问题5.1 双网口都在回 ARP交换机的 MAC 表来回跳现象PRP 网络里接入一台配置错误的 DANP 设备后网络出现间歇性连接失败交换机端口 MAC 表在几个端口间反复跳变监控系统出现大量 ARP 冲突告警。原因这台设备把两个物理口都暴露给了操作系统没有启用冗余去重功能。于是网卡从 LAN A 收到 ARP 请求并回应过几十毫秒又从 LAN B 收到同一份 ARP 请求再回应一次。交换机从两个端口学到了同一个 MAC 地址后续转发时来回震荡业务流量被频繁丢弃。解决先排查设备内部网卡是否被正确绑定成 PRP 口。Linux 系统查看ip -d link show确认口状态商用设备检查网卡驱动是否工作在 DANP 模式。如果设备本身不支持 PRP就把它降级成 SAN前端挂 RedBox避免双口直接暴露。只靠封禁一个交换机端口来让 MAC 地址不再跳是掩耳盗铃治标不治本。5.2 SAN 设备掉线因为上游 RedBox 没有开启重复帧消除现象PLC 挂在 RedBox 后面RedBox 上连 PRP 双网。业务运行正常但只要 LAN B 的交换机做一次端口重启PLC 与上位机的通信中断十几秒才恢复。原因RedBox 的重复帧去重功能默认关闭它把两个网络收到的同一份帧当作两个不同帧同时转发给 PLC。正常情况下 PLC 靠上层协议识别重复还能运行一旦某一侧网络抖动重复帧到达顺序错乱PLC 的协议栈被干扰连接就会复位。解决登录 RedBox确认 PRP 去重开关已打开并把去重等待窗口从默认值调整到和 LAN A/B 时延差匹配。现场验证时不要只测拔一根线要故意把一侧交换机重启观察 SAN 设备的通信中断时长。如果 RedBox 的去重窗口不可调坚决不用于控制类业务。5.3 环里混进了一台普通交换机网络风暴现象HSR 环网调试时某个节点下挂了一台普通二层交换机结果整个环的广播包呈指数增长所有节点 CPU 占用升高业务大面积卡顿。原因普通交换机不具备 HSR 转发和去重逻辑。HSR 环上的每个节点会把收到的 HSR 帧从另一个口转发出去而普通交换机接到环口后会把广播帧再反射回环形成重复帧不断绕环。HSR 的节点表无法识别普通交换机背后的设备导致广播风暴一直持续。解决强制规定 HSR 环上只允许连接支持 HSR 的设备普通设备全部通过 RedBox 或 HSR 交换机扩展。如果现场必须接入普通交换机要在 HSR 交换机上配置端口隔离和广播抑制但本质上这是一个错误的网络结构。排查时用 tcpdump 从环口抓包看到同一广播帧在一个口上反复出现就说明有非 HSR 设备在转发。5.4 高负荷下序列号翻转接收端把新帧误判成重复帧现象长时间跑大数据量吞吐测试时链路偶尔出现几秒全部丢包但网络设备状态和物理链路都正常丢包时间点没有规律。原因16 位序列号上限是 65535。发送速率高时序列号很快到最大值并翻转回 0。接收端在去重表里还留有刚才的记录看到新的 00 开头的序列号误认为是已经收过的旧帧直接丢弃导致丢包直到去重表项老化。解决正确实现的标准在接收端会把序列号相同和来源不同联合判断并通过 MAC 地址和时间戳排除翻转情况。遇到这个现象要检查设备固件是否按 2016 版要求处理序列号回绕。如果无法升级就只能限制发送速率或缩短去重表存活时间但这是临时方案正式设备不应该出现这种问题。5.5 监督帧被广播风暴淹没节点表频繁老化现象HSR 环上节点数量增多后部分远端节点从 Node Table 中反复消失单播帧被泛洪网络性能下降。原因所有节点都在发监督帧但交换机或 HSR 节点没有为监督帧配置较高优先级。在网络拥塞时监督帧的数据量本身不大却和业务广播帧一起被丢弃导致节点表维护超时。典型表现是节点表反复先超时、后恢复。解决给监督帧打上高优先级 VLAN 标签并限制广播业务占用带宽。标准对监督帧的处理有默认行为但现场多厂商设备混接时优先级策略往往不一致。确认所有设备都把监督帧归入同一个高优先级队列并在抓包中单独过滤监督帧看它们在高峰期是否仍能稳定到达。6. 调试技巧用一个小脚本完成切换时间验收现场验收 PRP/HSR 时最常被业主的问题是你说零丢包怎么证明。我一般会在两台设备之间跑一个持续 ping然后人为断开一个物理链路通过抓包或者 ping 回显来记录有没有丢包。注意普通 ping 的最小发包间隔是 100ms并不能证明 1ms 级切换所以要缩短发包间隔并且统计序列号。#!/bin/bash # 用 -f 发快速 ping每次间隔 100ms共 300 个包 # 中途手动断开再恢复 eth1验收后看序列号是否连续 ping -I hsr0 192.168.200.6 -f -c 300 -W 1 | tail -n 2 # 更严格的做法是抓 icmp echo request 的序列号 # tcpdump -i hsr0 -nn -c 400 icmp and host 192.168.200.6手动测试时我会配合 tcpdump 在接收端抓包然后在 tcpdump 的序列号输出里检查 ICMP ID 和 seq 是否连续。拔掉物理链路的那几百毫秒里只要 seq 还有没有空缺就说明切换是无缝的。如果是 PRP 网络我会分别在 LAN A 和 LAN B 的交换机上同时抓包确认断开 LAN A 后LAN B 的帧始终在正常到达。把这个脚本固定成验收用例配合大帧、小帧、组播三种流量类型各跑一轮比直接看设备面板上的链路状态有用。我还习惯在抓包里过滤出监督帧单独确认节点表记录正确。最后想提醒一句现场验收不要只测一次断链和恢复各测 5 轮观察最长丢包数和最大时延。很多设备第一次测表现很好第二次起因为节点表状态不同就现出原形。希望这篇内容能帮你少走弯路。本文还有配套的精品资源点击获取