输出结果中的第2行le0（以太网）显示了这个接口属于主机组224.0.0.1（“所有主机”），和两行地址，后一行显示相应的以太网地址为：01:00:5e:00:00:01 。这正是我们期望看到的以太网地址，和12 . 4节介绍的地址映射一致 。我们还看到其他两个支持多播的接口：SLIP接口sl0和回送接口l o 0，它们也属于所有主机组 。
我们也必须显示IP路由表，用于多播的路由表同正常的路由表一样 。黑体表项显示了所有传往224.0.0.0的数据报均被送往以太网：
(点击查看原图)
假如将这个路由表与9 . 2节中s u n路由器的路由表作比较，会发现只是多了有关多播的条目 。
现在使用一个测试程序来让我们能在一个接口上加入一个多播组（不再显示使用这个测试程序的过程） 。在以太网接口（ 1 4 0 . 2 5 2 . 1 3 . 3 3）上加入多播组2 2 4 . 1 . 2 . 3 。执行n e t s t a t程序看到内核已加入这个组，并得到期望的以太网地址 。用黑体字来突出显示和前面n e t s t a t输出的不同 。
(点击查看原图)
我们在输出中再次显示了其他两个接口： s l 0和l o 0，目的是为了重申加入多播组只发生在一个接口上 。
图1 3 - 4显示了t c p d u m p对进程加入这个多播组的跟踪过程 。
当主机加入多播组时产生第1行的输出显示 。第2行是经过时延后的IGMP报告，我们介绍过报告重发的时延是1 0秒内的随机时延 。
在两行中显示硬件地址证实了以太网目的地址就是正确的多播地址 。我们也看到了源IP地址为相应的s u n主机地址，而目的IP地址是多播组地址 。同时，报告的地址和期望的多播组地址是一致的 。
;;;;最后，我们注重到，正像指明的那样， TTL是1 。当TTL的值为0或1时，tcpdump在打印时用方括号将它们括起来，这是因为TTL在正常情况下均高于这些值 。然而，使用多播我们期望看到许多TTL为1的IP数据报 。
在这个输出中暗示了一个多播路由器必须接收在它所有接口上的所有多播数据报 。路由器无法确定主机可能加入哪个多播组 。
多播路由器的例子
继续前面的例子，但我们将在s u n主机中启动一个多播选路的守护程序 。这里我们感爱好的并不是多播选路协议，而是要研究所交换的IGMP查询和报告 。即使多播选路守护程序只运行在支持多播的主机（sun）上，所有的查询和报告都将在那个以太网上进行多播，所以我们在该以太网中的其他系统中也能观察到它们 。
在启动选路守护程序之前，加入另外一个多播组224.9.9.9，图13-5显示了输出的结果 。
在这个输出中没有包括以太网地址，因为已经证实了它们是正确的 。也删去了TTL等于1的说明，同样因为它们也是我们期望的那样 。
当选路守护程序启动时，输出第1行 。它发出一个已经加入了组224.0.0.4的报告 。多播地址224.0.0.4是一个知名的地址，它被当前用于多播选路的距离向量多播选路协议DVMRP(Distance Vector Multicast Routing Protocol)所使用（DVMRP在RFC 1075中定义[Waitzman ,Partridge, and Deering]） 。
在该守护程序启动时，它也发送一个IGMP查询（第2行） 。该查询的目的IP地址为224.0.0.1（所有主机组），如图13-3所示 。
第一个报告（第3行）大约在5秒后收到，报告给组224.9.9.9 。这是在下一个查询发出之前（第4行）收到的唯一报告 。当守护程序启动后，两次查询（第2行和第4行）发出的间隔很短，这是因为守护程序要将其多播路由表尽快建立起来 。
第5、6和7行正是我们期望看到的：sun主机针对它所属的每个组发出一个报告 。注重组224.0.0.4是被报告的，而其他两个组则是明确加入的，因为只要选路守护程序还在运行，它始终要属于组224.0.0.4 。
推荐阅读
- 肉羊四季放牧管理及注意事项
- 因特网子网
- 猎豹清理大师如何管理系统进程
- 基于TCP/IP网络的管理结构和标记
- 意蜂饲养管理要点
- IOTP Internet开放贸易协议HTTP 补充
- 802．2分组在IPX网络上传输的标准
- 实时传输协议管理信息库
- Internet电子邮件保密增强：Part1-消息编码和鉴别过程
- HTTP 超文本传输协议状态管理的应用