13.4 An Example

13.4 An Example

Now that we've gone through some of the details of IP multicasting, let's take a look at the messages involved. We've added IP multicasting support to the host sun and will use some test programs provided with the multicasting software to see what happens.

First we'll use a modified version of the netstat command that reports multicast group membership for each interface. (We showed the standard netstat -ni output for this host in Section 3.9.) In the following output we show the lines corresponding to multicast groups in a bold font:

 sun %  netstat -nia  Name  Mtu   Network     Address          Ipkts Ierrs     Opkts Oerrs  Coll     le0   1500  140.252.13. 140.252.13.33     4370     0      4924     0     0  224.0.0.1  08:00:20:03:f6:42  01:00:5e:00:00:01  sl0   552   140.252.1   140.252.1.29     13587     0     15615     0     0  224.0.0.1  lo0   1536  127         127.0.0.1         1351     0      1351     0     0  224.0.0.1  

The -n option prints IP addresses in numeric format (instead of trying to print them as names ), -i prints the interface statistics, and -a reports on all configured interfaces.

The second line of output for le0 (the Ethernet) shows that this interface belongs to the multicast group 224.0.0.1 ("all hosts "), and two lines later the corresponding Ethernet address is shown: 01:00:5e:00:00:01. This is what we expect for the Ethernet address, given the mapping we described in Section 12.4. We also see that the other two interfaces that support multicasting, the SLIP link sl0 and the loopback interface lo0, also belong to the all-hosts group.

We must also show the IP routing table, as the normal routing table is used for multicast datagrams. The bold entry shows that all datagrams for 224.0.0.0 are sent to the Ethernet:

 sun %  netstat -rn  Routing tables     Destination           Gateway         Flags     Refcnt   Use       Interface     140.252.13.65         140.252.13.35   UGH       0        32        le0     127.0.0.1             127.0.0.1       UH        1        381       lo0     140.252.1.183         140.252.1.29    UH        0        6         sl0     default               140.252.1.183   UG        0        328       sl0  224.0.0.0             140.252.13.33   U         0        66        le0  140.252.13.32         140.252.13.33   U         8        5581      le0 

If you compare this routing table to the one shown in Section 9.2 for the router sun, you'll see that the multicast entry is the only change.

We now run a test program that lets us join a multicast group on an interface. (We don't show any output for our use of this test program.) We join the group 224.1.2.3 on the Ethernet interface (140.252.13.33). Executing netstat shows that the kernel has joined the group, and again the Ethernet address is what we expect. We show the changes from the previous netstat output in a bold font:

 sun %  netstat -nia  Name  Mtu   Network      Address             Ipkts   Ierrs    Opkts   Oerrs   Coll     le0   1500  140.252.13.  140.252.13.33        4374       0     4929       0      0  224.1.2.3  224.0.0.1                              08:00:20:03:f6:42  01:00:5e:01:02:03  01:00:5e:00:00:01     sl0   552   140.252.1    140.252.1.29        13862       0    15943       0      0                              224.0.0.1     lo0   1536  127          127.0.0.1            1360       0     1360       0      0                              224.0.0.1 

We have shown the output again for the other two interfaces, sl0 and lo0, to reiterate that the multicast group is joined only on one interface.

Figure 13.4 shows the tcpdump output corresponding to the process joining the multicast group.

Figure 13.4. tcpdump output when a host joins a multicast group.
graphics/13fig04.gif

Line 1 occurs when the host joins the group. The next line is the delayed report that we said is sent at some random time up to 10 seconds afterward.

We have shown the hardware addresses in these two lines, to verify that the Ethernet destination address is the correct multicast address. We can also see that the source IP address is the one corresponding to sun, and the destination IP address is the multicast group address. We can also see that the reported address is that same multicast group address.

Finally, we note that the TTL is 1, as specified. tcpdump prints the TTL in square brackets when its value is 0 or 1. This is because the TTL is normally greater than this. With multicasting, however, we expect to see lots of IP datagrams with a TTL of 1.

Implied in this output is that a multicast router must receive all multicast datagrams on all its interfaces. The router has no idea which multicast groups the hosts might join.

Multicast Router Example

Let's continue the previous example, but we'll also start a multicast routing daemon on the host sun. Our interest here is not the details of multicast routing protocols, but to see the IGMP queries and reports that are exchanged. Even though the multicast routing daemon is running on the only host that supports multicasting ( sun ), all the queries and reports are multicast on the Ethernet, so we can see them on any other system on the Ethernet.

Before starting the routing daemon we joined another multicast group: 224.9.9.9. Figure 13.5 shows the output.

Figure 13.5. tcpdump output while multicast routing daemon is running.
graphics/13fig05.gif

We have not included the Ethernet addresses in this output, because we've already verified that they are what we expect. We've also deleted the notation that the TTL equals 1, because again that's what we expect.

Line 1 is output when the routing daemon starts. It sends a report that it has joined the group 224.0.0.4. Multicast address 224.0.0.4 is a well-known address used by DVMRP (Distance Vector Multicast Routing Protocol), the protocol currently used for multicast routing. (DVMRP is defined in RFC 1075 [Waitzman, Partridge, and Deering 1988].)

When the daemon starts it also sends out a query (line 2). The destination IP address of the query is 224.0.0.1 (all-hosts), as shown in Figure 13.3.

The first report (line 3) is received about 5 seconds later, for group 224.9.9.9. This is the only report received before another query is sent (line 4). These two queries (lines 2 and 4) occur rapidly when the daemon starts up, as it tries to build its multicast routing table.

Lines 5, 6, and 7 are what we expect: one report from the host sun for each group to which it belongs. Notice that the group 224.0.0.4 is reported, in addition to the two groups that we explicitly joined, because as long as the routing daemon is running, it belongs to this group.

The next query on line 8 occurs about 2 minutes after the previous query. Again it elicits the three reports we expect (lines 9, 10, and 11). The reports are in a different order this time, as expected, since the time between receiving the query and sending the report should be randomized.

The final query that we show occurs about 2 minutes after the previous query, and again we have the expected responses.



TCP.IP Illustrated, Volume 1. The Protocols
TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series)
ISBN: 0201633469
EAN: 2147483647
Year: 1993
Pages: 378

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net