[参考译文] AM6422：交换机模式下 CPSW 网络端口的恢复时间

您正在运行哪个软件版本、您使用的硬件是什么(TI SK、EVM 或您自己的硬件)？  

 Pekka

该软件是 Linux 开发11、硬件 基于 senux 平台构建、而不是基于 TI SDK 构建。

尊敬的 Daolin：

这是一个采用 AM6422的定制设计电路板。

Linux 内核版本为

$ uname -A
Linux Aug 6.1.33-g40c32565ca #1 SMP preemt 星期四7月6日14：17：24 UTC 2023 AArch64 GNU/Linux

60秒是 ping 再次成功的时间。

30s 是从我再次链接 br0或再次插入表到日志显示"br0 link 变为就绪"的时间

尊敬的 Zitong：  

上周、我尝试使用 RT-Linux SDK 10.1在 AM64x EVM (TMDS64EVM)上重现相同问题、但对于链路建立 br0部分、我看不到30秒或更长的恢复时间。 我将在本周重试、并分享我的日志。

Unknown 说：

60s 是 ping 再次成功的时间。

您是在 BR0备份后从主机 PC 手动运行 ping 测试、还是始终在后台运行？

Unknown 说：

SW is linux Debian11

Unknown 说：

Linux Aug 6.1.33-g40c32565ca #1 preempt Thu Jul 6 14：17：24 UTC ASMP/archlinux 2023[Archex]

对于使用 Debian 而不是 Linux 或 RT-Linux 的 Yocto 版本、有什么特别的吗？

-道林

您好 Daolin、

  昨天、我们与 TI 团队进行了在线讨论。（Semon 是我们的支持者 M ü）、我尝试了更多测试。 结果如下

1. 如果禁用 RSTP、则 eth 端口的恢复时间为1-2s。
2. 如果启用 RSTP、请使用2台 Windows PC (192.168.1.10和192.168.1.20)、连接 CPSW 的2 eth 端口。 我们发现、如果连续 ping、使用命令`ping xxxx -t`、恢复时间会非常长。

通过数据包捕获工具、我们可以看到来自随机 IP (例如下图为192.168.1.192)的许多 ARP 请求、直到另一台 PC 发出 ping 请求或重新启动当前的 ping 请求、 ARP 请求 IP 恢复到正常状态(192.168.1.20)、另一台 PC 也可以成功 ping 通。

   ...

尊敬的 Zitong：  

Unknown 说：

如果禁用 RSTP、则 eth 端口的恢复时间为1-2s。

Unknown 说：

上周、我尝试查看是否可以在 AM64x EVM (TMDS64EVM)上复制相同的问题、使用0.1/30s 恢复时间、但链接时间不长。

感谢您指出这一点。 事实上、在我的测试过程中、我没有启用 RSTP、所以这可能是我无法重现问题的原因。

Unknown 说：

IP link set dev br0 type bridge stp_state 1

我查看了您使用的脚本、似乎这是唯一与启用 STP 相关的行。 您是否认为这应该启用 RSTP 而不是 STP？ 如果是 STP、根据我的理解、当拓扑发生变化时、恢复时间可能需要30-60秒。

-道林

[/quote]

尊敬的 Daolin：

  此脚本实际上仅启用 STP、而不是 RSTP。  

  当我 `下面的脚本时、它会启用 RSTP、并发现如果 I` link br0 down `和` link br0 up 、ping 的恢复时间小于3s

  但另一个问题是 、当我交换 cpsw-eth0和 cpsw-eth1的两根电缆时、恢复时间仍然非常长、PC 可以成功再次 ping、直到另一台 PC 发出 ping 请求。 您能找出原因吗？

ip link set dev br0 type bridge stp_state 1
sudo mstpd
sudo mstpctl setforcevers br0 rstp
sudo mstpctl addbridge br0

尊敬的 Daolin：

  删除该命令完全解决了我的问题、谢谢。