正文共: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元(在知了社区提交需求即可)。需求通过了别忘了回来给我赞赏!
长按二维码
关注我们吧
使用VLC media player初步认识单播、广播和组播
配置Windows Server 2016作为DHCP服务器