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

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

 Pekka

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

您好、Zitong、  

Unknown 说：

HW 基于 senux 平台构建、而不是来自 TI SDK。

只是为了澄清、这是在 TI AM64x EVM 还是在采用 AM6422的定制设计电路板上进行测试？  

Unknown 说：

SW is linux debian11

该软件不是来自 TI 提供的 Debian (Trixie)映像？  https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-InmvA50mCw/10.01.10.04/tisdk-debian-trixie-rt-am64xx-evm-10.01.10.04.wic.xz 

能否分享您正在使用的 Linux 内核版本？ (通用-A)

Unknown 说：

您可以看到、日志显示 br0准备就绪需要30秒、但是、我使用 PC ping 192.168.1.101 (br0 ip)可能需要更多时间、时间似乎是随机的、有时需要超过60秒。

您能否解释一下如何确定恢复时间为60秒、因为您说日志计时不正确？ 另外、您在日志中专门比较哪些时间戳来确定30s？

-道林

尊敬的 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 变为就绪"的时间

您好 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：

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