13.4 一个例子
现在我们已经了解了一些 I P多播的细节，再来看看所包含的信息。我们使 s u n主机能够支持多播，并将采用一些多播软件所提供的测试程序来观察具体的过程。
首先，采用一个经过修改的 n e t s t a t命令来报告每个接口上的多播组成员情况（在 3 . 9节显示了n e t s t a t - n i命令的输出结果）。在下面的输出中，用黑体表示有关的多播组。
其中，- n参数将以数字形式显示 I P地址（而不是按名字来显示它们），- i参数将显示接口的统计结果，- a参数将显示所有配置的接口。
输出结果中的第2行l e 0（以太网）显示了这个接口属于主机组 2 2 4 . 0 . 0 . 1（“所有主机”），和两行地址，后一行显示相应的以太网地址为： 0 1 : 0 0 : 5 e : 0 0 : 0 0 : 0 1。这正是我们期望看到的以太网地址，和 1 2 . 4节介绍的地址映射一致。我们还看到其他两个支持多播的接口： S L I P接口s l 0和回送接口l o 0，它们也属于所有主机组。
我们也必须显示 I P路由表，用于多播的路由表同正常的路由表一样。黑体表项显示了所有传往2 2 4 . 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行是经过时延后的I G M P报告，我们介绍过报告重发的时延是1 0秒内的随机时延。
在两行中显示硬件地址证实了以太网目的地址就是正确的多播地址。我们也看到了源 I P地址为相应的 s u n主机地址，而目的 I P地址是多播组地址。同时，报告的地址和期望的多播组地址是一致的。
最后，我们注意到，正像指明的那样， T T L是1。当T T L的值为0或1时，t c p d u m p在打印时用方括号将它们括起来，这是因为 T T L在正常情况下均高于这些值。然而，使用多播我们期望看到许多T T L为1的I P数据报。
在这个输出中暗示了一个多播路由器必须接收在它所有接口上的所有多播数据报。路由器无法确定主机可能加入哪个多播组。多播路由器的例子
继续前面的例子，但我们将在 s u n主机中启动一个多播选路的守护程序。这里我们感兴趣的并不是多播选路协议，而是要研究所交换的 I G M P查询和报告。即使多播选路守护程序只运行在支持多播的主机（ s u n）上，所有的查询和报告都将在那个以太网上进行多播，所以我们在该以太网中的其他系统中也能观察到它们。
在启动选路守护程序之前，加入另外一个多播组 2 2 4 . 9 . 9 . 9，图1 3 - 5显示了输出的结果。
在这个输出中没有包括以太网地址，因为已经证实了它们是正确的。也删去了 T T L等于1的说明，同样因为它们也是我们期望的那样。
当选路守护程序启动时，输出第 1行。它发出一个已经加入了组 2 2 4 . 0 . 0 . 4的报告。多播地址2 2 4 . 0 . 0 . 4是一个知名的地址，它被当前用于多播选路的距离向量多播选路协议 D V M R P(Distance Vector Multicast Routing Protocol)所使用（D V M R P在RFC 1075中定义[ Wa i t z m a n ,Partridge, and Deering]）。
在该守护程序启动时，它也发送一个 I G M P查询（第 2行）。该查询的目的 I P地址为2 2 4 . 0 . 0 . 1（所有主机组），如图1 3 - 3所示。
第一个报告（第 3行）大约在5秒后收到，报告给组 2 2 4 . 9 . 9 . 9。这是在下一个查询发出之前（第4行）收到的唯一报告。当守护程序启动后，两次查询（第 2行和第4行）发出的间隔很短，这是因为守护程序要将其多播路由表尽快建立起来。
第5、6和7行正是我们期望看到的： s u n主机针对它所属的每个组发出一个报告。注意组2 2 4 . 0 . 0 . 4是被报告的，而其他两个组则是明确加入的，因为只要选路守护程序还在运行，它始终要属于组2 2 4 . 0 . 0 . 4。
下一个查询位于第 8行，大约在前一个查询的 2分钟后发出。它再次引发三个我们所期望的报告（第9、1 0和11行）。这些报告的时间顺序与前面不同，因为接收查询和发送报告的时间是随机的。
最后的查询在前一个查询的大约 2分钟后发出，我们再次得到了期望的响应。
