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
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
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-
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
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
14.3.2 Configuring IGMP
In JUNOS the presence of IGMP is activated by default on broadcast interfaces once you
 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 188.8.131.52 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
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 184.108.40.206 0.0.0.0 192.168.254.69 225 fe-0/0/1.0 220.127.116.11 0.0.0.0 18.104.22.168 229 fe-0/0/1.0 22.214.171.124 0.0.0.0 126.96.36.199 228 fe-0/0/1.0 188.8.131.52 0.0.0.0 184.108.40.206 225 fe-0/0/1.0 220.127.116.11 0.0.0.0 18.104.22.168 233 fe-0/0/2.0 22.214.171.124 0.0.0.0 10.0.0.2 229 fe-0/0/2.0 126.96.36.199 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 188.8.131.52 fe-0/0/1.0 Full 184.108.40.206 128 38 Lab@Chicago>