正文共：1234 字 13 图，预估阅读时间：2 分钟
可能是前面的组播测试有点超出HCL的能力范围了（通过抓包简单对比一下单播、广播和组播的区别），今天换成HCL自带的组播测试工具Openwrt试一下（HCL中竟然新增了Openwrt服务器，你知道怎么用吗？）。
首先登录WEB管理页面，注意在修改LAN侧的管理地址之后，HCL并不能感知到改变，此时再通过右击设备图标选择“配置”进行登录，它仍然会打开默认的管理地址（192.168.56.4），导致登录失败。此时需要手工在浏览器输入新的管理地址进行登录。
登录成功之后，我们可以看到HCL目录下集成了很多测试工具。其中“多播”就是我们常说的组播，组播的英文为Multicast，只是翻译不同而已，我一般还是习惯称之为组播。
“组播组”是一个用IP组播地址进行标识的接收者集合，主机通过加入某组播组成为该组播组的成员，从而可以接收发往该组播组的组播数据。
信息的发送者称为“组播源”，一个组播源可以同时向多个组播组发送信息，多个组播源也可以同时向一个组播组发送信息。组播源通常不需要加入组播组。
所有加入某组播组的主机便成为该组播组的成员，组播组中的成员是动态的，主机可以在任何时刻加入或离开组播组。
在配置时，我们首先配置“组播接收者”，勾选“启用”，配置好“组播组”，设置好接收“间隔”和“接口”，点击“保存并应用”。
不过页面并不能直观地展示接收的数据，需要到查看文件/tmp/iperf，但是设备上默认是不存在这个文件的。
应用成功之后，我们就可以看到系统下生成了/tmp/iperf文件。
查看文件内容，竟然是启动iperf服务器的记录。看一下是否有iperf的进程。
可以看到，有一个进程，对应的命令为iperf -s -u -B 224.2.2.4 -i 1 -o /tmp/iperf，这不就是iperf服务器吗？有需要的可以回顾一下iperf配置（iperf命令简介）。
接下来，我们先配置组播源和组播接收者直连，然后配置组播源。配置和接收者一样的组播组，配置好互联的IP地址，视情况配置好带宽、间隔、传输时间和生存时间等参数，点击开始“测试”。
测试过程中，我们可以通过不断刷新来查看/tmp/iperf的文件信息，能看到文件是在不断增长的。
文件内容如下：
比较有趣的是，第一行竟然显示的是不支持组播，但是下面还是提示了加入了组播组224.2.2.4。文件的内容就是我们所能看到的iperf服务器端的连接和测试记录，可以清楚地看到，客户端的IP地址是20.1.1.2，使用的协议是UDP。
回到组播源这一端，我们从页面上也可以看到测试记录。
可以看到，显示的信息就是iperf客户端的测试记录，里面清楚地记录着，本地使用源地址20.1.1.2、源端口33194，连接到了组播组224.2.2.4，目的端口是UDP端口5001，和服务器端（组播接收者）的记录完全吻合。
我猜，对应的测试命令应该是iperf -c 224.2.2.4 -u -i 1 -t 60 -B 20.1.1.2，对应的输出与前面测试的记录完全一致，参数也与配置相同。
对应的，我们也可以查看/tmp/iperf文件中记录的信息。
与测试过程完全匹配。
即使组播接收者不停止iperf服务器，仍然可以使用组播源进行测试，进程不会冲突。但是建议大家在测试完成之后，及时关闭iperf服务器功能，仅需要在“组播接收者”选项卡中，取消“启用”，然后点击“保存并应用”即可。
关闭之后，iperf进程被关闭，但是文件得到了保存，不影响后续操作和查看。
不过这里我倒是想给HCL提个小建议，既然我们知道了要查看的文件是/tmp/iperf，那为什么不在下面增加一个监控窗口呢？命令也很简单，只需要再配置一个监控时间范围和间隔即可，然后就可以使用tail命令按照监控时间范围读取/tmp/iperf文件的最后几行，用时间间隔来定时刷新就好了，读取效果如下：
这个小需求，对于H3C内部人士价值至少100元，对于外部人士也价值50元（在知了社区提交需求即可）。需求通过了别忘了回来给我赞赏！
长按二维码
关注我们吧
