14.3 IGMP

Multicast packets need to be forwarded by the routers in between the source and destination just like in unicast routing. In multicast you must ensure that your multicast packets are only forwarded to LANs where a host is located that belongs to the multicast group . In other words do not send multicast transmissions to a LAN if no one has asked. IGMP must be enabled on routers that wish to receive multicast information. IGMP is also the transport protocol for multicast protocols (DVMRP and PIM).

Multicast-enabled routers need to learn which directly connected host wish to participate in a given multicast group use IGMP. This is accomplished by having the router send an IGMP query message onto the subnet to which a host will reply with the group membership information; we will look at this process in more detail shortly. Based on this information the routing of multicast data will be altered accordingly .

14.3.1 IGMP Operational Overview

IGMP messages are encapsulated in IP datagrams. IGMP has only two kinds of packets, host membership query and host membership report, with the same simple fixed format containing some control information in the first 32 bits and a Class D address in the second 32 bits as shown in Figure 14-7.

Figure 14-7. IGMP Message Format

In order for a router to determine if any hosts on a local subnet belong to a multicast group, one multicast-enabled router per LAN (subnet) periodically sends a hardware (data link layer) multicast IGMP host membership query to all IP hosts on its LAN, asking them to report back on their multicast groups memberships. This membership query message is sent to the all- hosts group (destination address 224.0.0.1 ) and a TTL of 1 is used so that these messages are not propagated outside of the LAN. Each host sends back one IGMP host membership report message per multicast group, sent to the group address ( 224.5.5.5 ), so all group members see it (only one member reports back membership). This process is shown in Figure 14-8, where you can see the router sending the IGMP query to all multicast hosts on the LAN.

Figure 14-8. IGMP Messages on a LAN

Periodically, IGMP will resend this message to verify the membership of each host. To avoid an immediate flood of responses as every host on the LAN responds, each host will reply at a random interval so the responses are staggered . When a host wants to leave a multicast group, it sends an IGMP leave message, as shown in Figure 14-9, to the multicast address 224.0.0.2 .

Figure 14-9. Host Leaving a Multicast Group

IGMP has three versions (1, 2, and 3), and in order for a router to interop, just make sure you are using the right version! Juniper Networks routers support all three versions. Version 3 inherently provides interoperability with versions 1 and 2. Also, the default version of IGMP, unless specified, is version 2. IGMP is defined in the following documents:

• RFC 1112, "Host Extensions for IP Multicasting" (defines IGMP Version 1)

• RFC 2236, "Internet Group Management Protocol, Version 2"

• "Internet Group Management Protocol, Version 3," draft-ietf-idmr-igmp-v3-01.txt

14.3.2 Configuring IGMP

In JUNOS the presence of IGMP is activated by default on broadcast interfaces once you turn on a multicast routing protocol. This is an extremely intelligent implementation of IGMP by Juniper Networks. You are thus freed from configuring the background communication of the dynamic routing protocol when, say, DVMRP or PIM is activated, provided your network and the default parameters of IGMP are compatible. Now, the chances of you running multicast on an all broadcast net works is not likely in the real world, so let's look at the various steps to activate IGMP and set its parameters. To activate IGMP manually, you enter the edit protocols igmp command in configuration mode.

 [edit]  Lab@Chicago# edit protocols igmp 

As you are by now aware, the various configuration options are accessible as you have entered into the IGMP protocol edit mode. In this instance IGMP provides you with the ability to activate it by interface (all are now on, unless an interface is specified). The example below shows the parameters that can be set, but we strongly suggest that you do not alter the defaults unless necessary and only after careful consideration. Consult the Juniper Networks documentation for the operational range of each parameter and the impact possible to your network.

 [edit protocols igmp]  Lab@Chicago# set ? Possible completions: + apply-groups         Groups from which to inherit configuration data > interface            Interface options for IGMP   query-interval       When to send host-query messages (1..1024 seconds)   query-last-member-interval  When to send group query messages (seconds)   query-response-interval  How long to wait for a host-query response (seconds)   robust-count         Expected packet loss on a subnet (2..10) > traceoptions         Trace options for IGMP 

14.3.3 Verifying an IGMP Configuration

To verify that your configuration of IGMP was successful you can execute a show igmp keyword command at the CLI to determine IGMP's status.

 Lab@Chicago> show igmp ?  Possible completions:   group                Show IGMP group members   interface            Show IGMP interfaces   statistics           Show IGMP statistics 

The following example shows an executed show igmp interface command. By default, JUNOS activates IGMP on all router interfaces if none are specified in edit mode.

 Lab@Chicago> show igmp interface  Interface              State    Querier         Timeout Version Groups fe-0/0/0.0                 Up       192.168.254.70     None       2      1 fe-0/0/1.0                 Up       51.0.0.1           None       2      0 fe-0/0/2.0                 Up       10.0.0.1           None       2      0 Configured Parameters: IGMP Query Interval (1/10 secs): 1250 IGMP Query Response Interval (1/10 secs): 100 IGMP Last Member Query Interval (1/10 secs): 10 IGMP Robustness Count: 2 Derived Parameters: IGMP Membership Timeout (1/10 secs): 2600 IGMP Other Querier Present Timeout (1/10 secs): 2550 Lab@Chicago> 

Monitoring the transmission statistics for IGMP is also possible through the use of the show igmp statistics command, as shown below. Notice in the command output that you see individual reports on the various types of multicast transmissions the router is sending and receiving; plus, the JUNOS implementation is multivendor capable as well!

 Lab@Chicago> show igmp statistics  IGMP packet statistics for all interfaces IGMP Message type      Received       Sent  Rx errors Membership Query              9         42          0 V1 Membership Report         17          0          0 DVMRP                         0          0          0 PIM V1                        0          0          0  Cisco Trace                   0          0          0  V2 Membership Report          0          0          0 Group Leave                   0          0          0 Mtrace Response               0          0          0 Mtrace Request                0          0          0 Domain Wide Report            0          0          0 V3 Membership Report          0          0          0  Other Unknown types                                 0  IGMP v3 unsupported type                            0 IGMP v3 source required for SSM                     0 IGMP v3 mode not applicable for SSM                 0 IGMP Global Statistics Bad Length                    0 Bad Checksum                  0 Bad Receive If                0 Rx non-local                  9 Lab@Chicago> 

You can use the show igmp statistics command to see not only all the IGMP processes running, but, if you recall, OSPF also uses multicast, and the multicast OSPF-assigned addresses show up in this command, giving you a nice way to see OSPF's operation in the most unlikely place. As the network is running IGMP and OSPF to the same neighbor, the entries are there for each multicast address (IGMP, IGMP Group, OSPF ALL, OSPF DR). Specifically, the use of the show igmp group brief command shows you the multicast addresses that are being used on a per-interface basis.

 Lab@Chicago> show igmp group ?  Possible completions:   <[Enter]>            Execute this command   <group-name>         Show a particular IGMP group   brief                Show brief view   detail               Show detail view                       Pipe through a command Lab@Chicago> show igmp group brief Interface              Group           Source          Last Reported   Timeout fe-0/0/0.0             224.0.0.2       0.0.0.0         192.168.254.69      225 fe-0/0/1.0             224.0.0.2       0.0.0.0         51.0.0.2            229 fe-0/0/1.0             224.0.0.5       0.0.0.0         51.0.0.2            228  fe-0/0/1.0             224.0.0.6       0.0.0.0         51.0.0.2            225   fe-0/0/1.0             224.0.0.22      0.0.0.0         51.0.0.2            233  fe-0/0/2.0             224.0.0.5       0.0.0.0         10.0.0.2            229  fe-0/0/2.0             224.0.0.6       0.0.0.0         10.0.0.2            224  

The output below shows the actual OSPF neighbors that are present.

 Lab@Chicago> show ospf neighbor    Address         Interface          State      ID              Pri  Dead 192.168.254.253  fe-0/0/0.0          Full      10.10.10.10        1   33 10.0.0.2         fe-0/0/2.0          Full      10.0.0.2         128   34 51.0.0.2         fe-0/0/1.0          Full      51.0.0.2         128   38 Lab@Chicago>