Internet Core Protocols: The Definitive Guide

Troubleshooting Multicasts and IGMP

Since IGMP is a very small and lightweight protocol, there aren’t many things that can go wrong with it. The only real errors that are likely to occur are problems with programs that implement the specification poorly. For example, the party.exe application that is provided by Microsoft does not use the appropriate system calls for generating multicast traffic. As such, it does not cause a Membership Report to be sent when the program is started, and does not cause a Leave Report to be issued when it is stopped.

Another implementation problem can be seen with the SNTP client provided with RedHat Linux 5.2. Although this same client code executes properly on Solaris and Digital Unix systems, RedHat Linux 5.2 had some bugs in the multicasting code that caused some malformed IGMP messages to be sent. Figure 4.18 shows this in detail.

Figure 4.18. A malformed IGMP Leave Report

The first mistake that is made is that the SNTP client does not issue multiple Membership Reports when it is started. Instead, only one Membership Report is issued, although RFC 2236 specifically states that applications should issue at least two separate Membership Reports whenever they join a multicast group.

The second mistake—and one that is much more problematic—is that the Leave Report issued by this implementation is completely malformed. Although the client does send the Leave Report to the all-routers multicast group (224.0.0.2), it also specifies that the group it wants to leave is 224.0.0.2, which is not correct. It should be advertising that it wants to leave the 224.0.1.1 group (the well-known multicast address for SNTP, the same group that it joined in the previous message). As it stands, this client is offering to leave the all-routers group of 224.0.0.2, rather than the NTP group.

This is the wrong behavior and will likely result in some problems eventually. For example, any multicast routers that are on the network (such as Sasquatch) will never find out that Greywolf wants to leave the NTP multicast group, and as such will continue forwarding NTP data to this network segment. Although that’s okay here (we have many NTP clients), if Greywolf were on a remote network accessible via a dial-on-demand connection, we would likely see the link being brought up every so often just for the NTP traffic.

In addition, multicast datagrams are basically indistinguishable from IP datagrams, so one way to test for basic multicasting functionality is to use a program like ping to determine which hosts are currently listening for a specific group address.

For example, Figure 4.19 shows a single ICMP Echo Request Query Message being sent from Krill to the all-hosts multicast group address of 224.0.0.1. In response, Krill receives three different ICMP Echo Response Query Messages back, with the IP addresses of the responding systems shown in the ping output. Also notice that Krill’s implementation of ping thinks that two of the responses are duplicates (which they are), although they were returned from different hosts.

Figure 4.19. The output from a ping test to the multicast all-hosts address of 224.0.0.1

Note that many TCP/IP stacks will not respond to ICMP Echo Request messages that are sent to multicast addresses, and that this method is not a sure-fire indicator of the active listeners on a network. For example, there are more than three multicast-aware hosts active on the local network, although Krill only got answers back from three hosts (one of which was itself) in the test shown in Figure 4.19. For a detailed discussion on ways to use ping, refer to Section 5.3.2 in Chapter 5.

General problems with multicasting will also result from configuration problems with your multicast-enabled routers. Multicasting and IGMP both rely on the presence of a multicast router in order for the multicast datagrams to be forwarded across network boundaries. Although many IP routers offer multicast support, most of them do not have these protocols enabled by default. You may need to enable a multicast-specific routing protocol such as DVMRP (the Distance-Vector Multicast Routing Protocol), or you may need to acquire a new router if the one you currently have does not support either multicast routing or the version of IGMP in use by your hosts.

Also, if you are trying to interact with multicasting traffic from the Internet, then you will need to configure your firewalls to allow that type of traffic through. This is not a widely-supported option at the present time, and the only viable solution may involve the creation of multicast tunnels (using a multicast routing protocol), or the creation of a secure, encrypted virtual private network link. In both cases, you will need to find an external organization that can provide you with those services (although the chances are good that the external organizations are also suffering under security issues with multicast traffic). For more information on this subject, refer to RFC 2588, which covers the issues around IP multicasting and firewalls in great detail.