Chapter 3 - Internet Group Management Protocol

Chapter 3: Internet Group Management Protocol  
  Overview  
  When a multicast router receives traffic destined for a multicast group, the router needs to know on which interfaces the traffic should be forwarded. The decision to forward is based on whether or not any group members or forwarding routers are on the subnet. Forwarding multicast traffic onto a subnet that has no group members is a waste of bandwidth.  
  Figure 3-1 illustrates the situation where a multicast router is receiving traffic for the group 224.65.10.154. Subnet 1 has no group members, so there is no need for the router to forward the traffic to subnet 1. Subnet 2 has one host, host C, which is a member of the multicast group 224.65.10.154, so the multicast traffic will be forwarded to subnet 2. What if host D in Figure 3-1 joins the group? The router only needs to know that at least one group member is on the subnet and it does not matter to the router if there is one group member or if there are 100.  
   
  Figure 3-1: Forwarding of multicast traffic  
  Figure 3-2 shows the scenario where subnet 1 has no group members, but a downstream multicast router on subnet 1 has group members attached to one of the router s interfaces. The multicast traffic would need to be forwarded onto subnet 1. As shown, the Internet Group Management Protocol (IGMP) is used between hosts and routers, and the multicast routing protocols, Distance Vector Multicast Routing Protocol (DVMRP) and Protocol Independent Multicast (PIM), are used between multicast routers.  
   
  Figure 3-2: Forwarding of multicast traffic to a downstream multicast router  
  IGMP is the mechanism used by hosts on a network to inform directly-attached routers which multicast group(s) the host wants to either join or leave. Multicast routers use IGMP to determine if any members of the multicast groups are located on any of their attached networks. If group members are present, multicast routers can then join a particular multicast group and forward multicast traffic to hosts that have joined the group(s). The original IGMP specification is detailed in RFC 1112, Host Extensions for IP Multicasting. This specification is typically referred to as IGMP version 1 and was written by S. Deering of Stanford University in August 1989. A subsequent RFC, written by W. Fenner of Xerox PARC, updated the original IGMP version 1 RFC. The update is RFC 2236, Internet Group Management Protocol, Version 2. Both RFCs will be examined because a mix of IGMP version 1 and version 2 hosts and routers may be present in the network, and you need to be aware of interoperability issues between the versions. Following the discussion of IGMP version 1 and version 2, we will examine configuring, monitoring, and debugging IGMP on Cisco routers.
RFC 1112, Host Extensions for IP Multicasting (IGMP Version 1)  
  RFC 1112 obsoletes RFCs 988 and 1054 and details the requirements of a host in order for it to be able to support IP multicasting. The multicasting support needed is for hosts to be able to join and leave multicast groups with IP addresses in the range 224.0.0.0 to 239.255.255.255. Also specified are the mechanisms for hosts to be able to receive and send multicast traffic.  
  A host can have one out of three levels of multicasting capabilities. Level 0 defines a host that has no multicasting functionality beyond being able to detect and discard an IP Class D multicast packet. A level 1 host can send but not receive IP multicast traffic, while a level 2 host is a fully capable multicast entity and can send and receive multicast traffic. Level 2 hosts are required to implement IGMP and we will assume that all hosts in the following discussion are level 2 hosts. The relationship between IGMP and IP layered models is shown in Figure 3-3.  
   
  Figure 3-3: IGMP resides at the network layer of the IP layered model.  
  Sending an IGMP packet is really no different than sending a broadcast or unicast IP packet, although additional functionality is required for a level 2 host. The first required function concerns the TTL field in the IGMP packet. If a TTL value is not explicitly set, then the default TTL value should be set to 1 to prevent the IGMP traffic from leaving the host s network. The second required function is for hosts that are connected to more than one network. The host should only transmit multicast traffic on one of the directly connected networks because, in the multicasting paradigm, routers have the responsibility of forwarding multicast traffic to other networks. The third and last function specifies what a host should do when sending a multicast packet to a group of which the host is also a member. The transmitted multicast packet should be looped back to the host and the received packet that the host just sent should be discarded.  
  Ethernet Multicast Addressing  
  The datalink layer also requires additional functionality for mapping Class D IP addresses to ethernet MAC addresses. The procedure outlined in the RFC also applies to FDDI, but a procedure is not specified for a token ring. The mapping from multicast to token ring layer 2 addresses presented here are the implementation on Cisco routers. The ethernet and FDDI layer 3 to layer 2 address mapping is relatively straightforward. The low-order 23 bits of the IP multicast address replace the low-order 23 bits of the ethernet multicast address 01:00:5E:00:00:00, as shown in Figure 3-4.  
   
  Figure 3-4: Formation of the ethernet multicast address  
  As you can see in Figure 3-4, nine bits in the group IP address do not take place in the mapping, the upper byte, and the most significant bit of the next-to-upper byte. The upper four bits of the upper byte are always 1110 because these are all Class D IP addresses. This means that in reality there are only five bits that are not involved in the mapping. Whatever the value of these bits, the multicast ethernet address is the same. Because there are 32 possible combinations of five bits, the mapping is not unique. In the example in Figure 3-2, 31 other Class D IP addresses map to the same multicast ethernet address.  
  Table 3-1: Class D multicast IP addresses that map to the multicast ethernet address 01:00:5E:41:0A:9A  
 
 
  224.65.10.154  
  225.65.10.154  
 
  226.65.10.154  
 
  227.65.10.154  
 
  228.65.10.154  
  229.65.10.154  
 
  230.65.10.154  
 
  231.65.10.154  
 
  232.65.10.154  
  223.65.10.154  
 
  234.65.10.154  
 
  235.65.10.154  
 
  236.65.10.154  
  237.65.10.154  
 
  238.65.10.154  
 
  239.65.10.154  
 
  224.193.10.154  
  225.193.10.154  
 
  226.193.10.154  
 
  227.193.10.154  
 
  228.193.10.154  
  229.193.10.154  
 
  230.193.10.154  
 
  231.193.10.154  
 
  232.193.10.154  
  233.193.10.154  
 
  234.193.10.154  
 
  235.193.10.154  
 
  236.193.10.154  
  237.193.10.154  
 
  238.193.10.154  
 
  239.193.10.154  
 
 
 
  Let s examine the most significant byte of the IP address, 225.65.10.154. The byte 225 is represented in binary as 1110 0001. The upper four bits do not change because they are always 1110 for a Class D IP multicast address. The lower four bits have a range of values from 0000 to 1111, so the decimal range of values for the upper byte is 224 (224 + 0) to 239 (224 + 15). The most significant bit of the next-to-upper byte can be either 0 or 1, so this byte can be either 65 (0 + 65) or 193 (65 + 128). The upper byte can take on 16 values and the next-to-upper byte can take on two values, so there is a total of 32 Class D IP multicast addresses (16 x 2) that map to the multicast ethernet address 01 00 5E 41 0A 9A, as listed in Table 3-1. A host implementation must not only examine the ethernet address of the received multicast ethernet frame at layer 2 but must also examine the multicast IP address at layer 3 to determine if the packet is destined for a group that the host has joined.  
  Exercise 3-1  
  Determine which Class D IP multicast addresses map to the multicast ethernet address 01:00:5E:5F:00:01.  
  Solution.  We need to add the low-order 23 bits of the multicast ethernet address to the partial IP address 1110 xxxxx000 0000 0000 0000 0000 0000, which gives us  
  1110 xxxxx101 1111 0000 0000 0000 0001  
  where xxxx x = 0000 0 1111 1.  
      With xxxx x = 0000 0, the IP address is 224.95.0.1.  
      With xxxx x = 1111 1, the IP address is 239.223.0.1.  
  The other 30 possible IP addresses are found by substituting xxxx x with 0000 1 1111 0.  
  Token Ring Multicast Addressing  
  The bit order of the transmitted bytes for token ring is the opposite of ethernet. For example, the token ring address C0:00:00:05:00:01 has the binary representation  
  1100 0000 0000 0000 0000 0000 0000 0101 0000 0000 0000 0001  
  When written in ethernet form, the order of the bits in each byte is reversed, so the ethernet binary representation would be  
  0000 0011 0000 0000 0000 0000 1010 0000 0000 0000 1000 0000  
  which has the hexadecimal form  
  03:00:00:A0:00:80.  
  The mapping of a multicast Class D IP address for token ring can be accomplished using one of two methods. The first method is to map all Class D multicast IP addresses to a single token ring functional address as shown:  
  224.x.x.x-> C0:00:00:04:00:00  
  The general form of a token ring functional address is C0:00:00:04:xx:xx. Functional addresses are used for token ring functions, such as Ring Error Monitor. The last two bytes usually have only one bit set to 1 and a bit in the third byte is used to determine if this address is a functional address. The third byte of an ethernet multicast address is 5E, which, if used in a token ring to multicast IP address mapping, would trick the token ring hosts into accepting that the multicast address is functional. This is the reason that the same mapping method used for ethernet cannot be used for token ring. Mapping all IP multicast addresses to the same token ring functional address means that token ring end stations cannot determine if the multicast traffic is destined for them until the packet is examined at layer three. If multicast traffic is present on the token ring, then every host must examine the packet at layer three (in software), instead of at layer two (by the network interface card). This can put a strain on end stations that are not listening for packets of that particular multicast group.  
  The other method of mapping multicast IP addresses to token ring addresses is to simply map every multicast IP address to the broadcast address:  
  224.x.x.x -> FF:FF:FF:FF:FF:FF  
  To force the token ring interface to use the functional address, use the following command in interface configuration mode:  
  interface Token-ring 0  
  ip multicast use-functional
Internet Group Management Protocol, IGMP Version 1  
  IGMP is used by hosts to inform the directly connected router of their choice to join a multicast group. IGMP messages have the format shown in Figure 3-5. IGMP messages are encapsulated in IP datagrams and use a protocol identifier of 2.  
   
  Figure 3-5: IGMP version 1 message format  
  Version Number = 1  
  Type  
  1 = Host Membership Query 2 = Host Membership Report  
 
  Unused  
  Set to zero when sending Ignore when receiving  
 
  Checksum  
  16-bit complement of the complement sum of the 8-byte IGMP message  
 
  Group Address  
  Host Membership Query Message = 0
Host Membership Report Message = IP multicast address of the group being reported
 
 
  A router sends Host Membership Query messages to determine if any hosts are members of any multicast groups (see Figure 3-6). As long as one host responds to the query, then the router must continue to send multicast traffic for that group to the network. Queries are sent to the all-hosts group address (224.0.0.1) and have a TTL value of 1.  
   
  Figure 3-6: Multicast routers use IGMP Host Membership Query messages to determine if any hosts are members of any multicast group.  
  When a host receives a Host Membership Query message, the host responds with one or more Host Membership Report messages (see Figure 3-7). Each Host Membership Report message contains the multicast group of which the host is a member.  
   
  Figure 3-7: Hosts report their group memberships with IGMP Host Membership Reports.  
  If multiple group members are on the network, a flood of report messages can be generated. Two techniques can be employed to avoid this possibility. The first is to have the host start a delay timer with a delay value randomly chosen between zero and some maximum value, usually 10 seconds. When the delay timer expires, the host sends the report. This spreads the Host Membership Reports over time. Because a router only needs to know if there is at least one group member on the network, it is not necessary for every host that is a member of a group to send a Host Membership Report message.  
  The second technique is to send the report to the host group address that is being reported. Hosts still use the delay timer, but if they receive a Host Membership Report for the group that they are waiting to report, the timer is canceled and no report is sent. This method is preferred because only one report is generated for each Host Membership Query (see Figures 3-8 and 3-9).  
   
  Figure 3-8: Routers determine group membership using IGMP Host Membership Queries.  
   
  Figure 3-9: Host report group memberships with IGMP Host Membership Reports.  
  In Figure 3-8, when hosts A, C, and D receive a Host Membership Query message from the router, the hosts start a timer with a random value. When the first timer counts down to zero, an IGMP Host Membership Report is sent, as in the example by host A. When host A sends the report, the timer values for hosts C and D have decremented by one. Before the timers for host C and D expire, they receive the Host Membership Report that is sent by host A. Because this is a report for the group that they are waiting to report to, there is no need for hosts C and D to send their reports.  
  The various states that a host can be in are shown in Figure 3-10. Hosts can be in one of three states: Non-Member, Delaying Member, and Idle Member. In the Non-Member state, a host is simply not a member of the multicast group. The Delaying Member state indicates that the host is a member of the multicast group, has received a Host Membership Query message from the router, and has the report delay timer running. A host enters the idle state after it has sent a Host Membership Report message to the router or has heard a Host Membership Report from another host that is a member of the group. Hosts will make transition between states on the occurrence of the following events:  
   
  Figure 3-10: IGMP Version 1 host state diagram  
  1.   A host decides to join a multicast group.  
  2.   A host decides to leave a multicast group.  
  3.   A Host Membership Query message is received.  
  4.   A Host Membership Report is received.  
  5.   The host s delay timer has expired.  
  When a host decides to join a multicast group, it does not know if any other hosts are on the network that are members of the group. If this host is the first member and the host waits for a Host Membership Query from the router, the host will wait forever. Therefore, when a host decides to join a multicast group, it should immediately send a Host Membership Report.  
  The possibility exists, however, that this initial report message will not reach the router. The host should make a transition from the Non-Member state to the Delaying Member state, as though the host had received a Host Membership Query message. The host then starts the delay timer. If a Host Membership Report is received, the host stops the timer and makes a transition to the Idle Member state. If the timer expires, the host sends a Host Membership Report message to the router and then moves to the idle state. When a Host Membership query is received, the host could be in any of the three states. In the Non-Member state, the host simply ignores the message. In the idle state, the host will make a transition to the delaying state and start the report delay timer. If the report is received while the host is in the delaying state, the host does not reset the timer but continues to delay with the current timer value. Finally, when a host decides to leave the group, it does so silently because there is not a leave group message in IGMP version 1. If the host is the last host to leave the group, the router does not know this until there has been no response to the router s periodic Host Membership Query messages.
Internet Group Management Protocol, IGMP Version 2  
  IGMP version 2 is detailed in RFC 2236 (Copyright The Internet Society 1997), written by W. Fenner of Xerox PARC in November 1997. IGMP version 2 messages have the format shown in Figure 3-11. The shaded parameters highlight the changes from the IGMP version 1 packet.  
   
  Figure 3-11: IGMP version 2 packet format  
  Type:  
  0x11 = Membership Query  
 
     
  0x16 = Version 2 Membership Report  
 
     
  0x17 = Leave Group  
 
     
  0x12 = Version 1 Membership Report for backwards
             compatibility with IGMP version 1.
 
 
  Membership Query messages, type 0x11, come in two flavors. The first is a General Query that is used to determine which groups on a network have active members. The second is a Group-Specific Query that is used to determine if a particular multicast group has active members. The type of Membership Query message can be determined by the group address. For a General Query, the group address is zero and, for a Membership Query, the group address contains the address of the multicast group that is being queried.  
  The Maximum Response Time field (Max. Rtime) applies only to Membership Query messages. This field specifies the maximum amount of time a host can wait before responding to a Membership Query report. Maximum Response Time is in units of 0.1 seconds.  
  Protocol Operation  
  One improvement that IGMP version 2 has over version 1 concerns multi-access networks, such as ethernet, that have more than one attached multicast router (see Figure 3-12). Only one router needs to send Membership Query messages because all attached routers running IGMP hear the Membership Report messages from the hosts. IGMP version 2 adds a feature that enables routers to determine which router is responsible for sending Membership Query messages with the other routers becoming Non-Querier routers. In Figure 3-12, assume that router A sends the first Membership Query message onto the multiaccess network. Router B receives this message and, because router A has a lower IP address than router B, router A remains the Querier for the network and router B the Non-Querier. If router B had sent the first Membership Query message (all routers start in the role of Querier), this would not suppress Membership Query messages from router A because router A has the lower IP address. Router A would send a Membership Query message and router B, upon receiving this message, would become a Non-Querier for the network.  
   
  Figure 3-12: On a multi-access network, the router with the lowest IP address becomes the Querier.
IGMP Version 2: Timers and Counters  
  To account for the possibility of router A ceasing to send Query messages, Non-Querier routers set a timer, the Other Querier Present Interval timer, whenever a Query message is received. If this timer expires before receiving a Query message, the router assumes the role of Querier. Of course, more than one Non-Querier router may be attached to the network and they will all try to assume the role of Querier. As before, the router with the lowest IP address on the net work becomes Querier and the others assume the Non-Querier role.  
  To prevent Non-Querier routers from mistakenly assuming the role of Querier, the Querier router must periodically send Membership Query messages using the Query Interval timer. Of course, the Query Interval Timer must be less than the Other Querier Present Interval timer. The timer values that are used in IGMP Version 2 are listed in Table 3-2.  
  TABLE 3-2: IGMP Version 2 timers, counters, and variables  
 
 
  Parameter  
Default Value  
 
 
 
  Robustness Variable (RV)  
2 (Must not be zero and should not be 1)  
 
  Query Interval (QI)  
125 Seconds  
 
  Query Response Interval (QRI)  
100 (10 seconds)  
 
  Startup Query Interval (SQI)  
One-quarter of the Query Interval = 31  
 
  Startup Query Count (SQC)  
Robustness Variable Value  
 
  Other Querier Present Interval (OQPI)  
(RV * QI) 1 QRI/2 = 255  
 
  Group Membership Interval (GMI)  
(RV * QI) 1 QRI = 260  
 
  Last Member Query Interval (LMQI)  
10 (1 second)  
 
  Last Member Query Count (LMQC)  
Robustness Variable Value  
 
  Unsolicited Report Interval (URI)  
10 seconds  
 
  Version 1 Router Present Timeout  
400 Seconds  
 
 
 
  When IGMP is first enabled on a multicast router, the router should send a number of General Query messages to determine if the hosts on the network are members of any multicast groups. The number of initial queries is given by the Startup Query Count and the initial queries are separated in time by the Startup Query Interval. When a host receives a General Query message from the router, the host sets a delay timer for each multicast group of which the host is a member. These delay values are chosen at random from the range 0 to Maximum Response Time (specified in the IGMP version 2 packet), and the value zero is not used. If any of these timers counts down to zero before the host has heard a Membership Report for a particular group, the host sends a Membership Report to the multicast group. If a host receives a Membership Report from another host for a group that the host is a member, the timer and report for that group is canceled. If a host receives a Membership Query for a group that the host already has a timer running, the timer is reset only if the remaining value of the timer is greater than the value of the Maximum Response Time contained in the IGMP packet.  
  When an IGMP-enabled multicast router receives a Membership Report from a host, the router checks the table of multicast groups for which the router is forwarding multicast traffic. If the group being reported by the host is not in the router s table, the router adds this group to the table. For each multicast group in the router s table, a periodic timer is set to the value Group Membership Interval. Whenever a router receives a Membership Report from a host for a multicast group, the timer associated with that group is reset to the value Group Membership Interval. When the Group Membership Interval timer counts down to zero, meaning that no Membership Reports have been received from a host during this time period, the router assumes that hosts on the network no longer want to receive multicast traffic for that particular group, and the router does not forward multicast traffic for it.  
  When a multicast application is enabled, the host should immediately send a Membership Report for the group that the application needs to join. Because the possibility exists that the report could be lost, the host should send a Membership Report at least one more time after delaying for the Unsolicited Report Interval.  
  Another addition to IGMP version 2 is the Leave Group message. In IGMP version 1, hosts left the group quietly and no message was sent. When a host decides to leave a group and if the host was the one that responded to the last Membership Query message, then the host should send a Leave Group message to the address 224.0.0.2, the all-routers multicast group. If the host was not the last one to respond to the Membership Query message, then a Leave Group message does not have to be sent, but it does no harm to send one, except for using a little bit of bandwidth. The RFC also allows the sending of the Leave Group message to the group address instead of the all-routers address. The benefit of sending the Leave Group message to the all-routers address is that hosts that are members of that group do not have to process the message.  
  When the Querier router receives the Leave Group message, the router does not know if this was the last host on the network for that group. The Querier router sends a number of Group-Specific Membership Queries, one in which the group address in the IGMP packet contains the address of the group being left. The number of Group-Specific Queries that are sent is given by the value Last Member Query Count, which is equal to the value of the Robustness Variable (RV) as shown in Table 3-2. The Group-Specific Queries are sent on an interval equal to the Last Member Query Interval. The Group-Specific Queries have the Maximum Response Interval in the IGMP packet set to the value of the Last Member Query Interval (see Figure 3-13). After sending the Group-Specific Queries, the router waits for a time given by the Last Member Query Interval for Group Membership reports. If none are received, then multicast traffic for the specific group is no longer forwarded by the router. The state diagram for a host running IGMP version 2 is shown in Figure 3-14.  
   
  Figure 3-13: IGMP version 2 packet format for the Group-Specific Query in response to a Leave Group message  
   
  Figure 3-14: IGMP version 2 host state diagram. Each group a host belongs to has its own state.  
  As shown in Figure 3-14, an IGMP version 2 host can be in one of three states. The Non-Member state indicates that the host does not belong to the multicast group; the host will make a transition to the Delaying Member state when the host decides to join the multicast group. The host sends a Membership Report for the group and sets a timer as though the host received a Membership Query from the router.  
  There are four transitions from the Delaying Member state. If the host s timer counts down to zero, the host sends a Membership Report and makes a transition to the Idle Member state. If a Membership Report for the group is received from another host, the host stops the delay timer and makes a transition to the Idle Member state. If a Membership Query is received from the router, the host resets the delay timer if the Maximum Response Time in the IGMP message is less than the time remaining on the delay timer. In this case, the host remains in the Delaying Member state. Finally, a host makes a transition from the Delaying Member state to the Non-Member state if the host decides to leave the group. The host sends a Leave Group message if it was the host that responded to the last Membership Query message. A host makes a transition from the Idle Member state on one of two events. If a Membership Query is received for the group, the host makes a transition to the Delaying Member state and starts the delay timer. If a host decides to leave the group while in the Idle Member state, the host sends a Leave Group message and makes a transition to the Non-Member state. The all-systems group (224.0.0.1) is a special case with respect to the host state diagram. Every host that is running IGMP version 2 is a member of the all-systems group, but no reports are ever sent for this group and the hosts are always in the Idle Member state with respect to this group.  
  If there is more than one router on the network, then the possibility exists that one or more routers are running IGMP version 1 and one or more routers are running IGMP version 2. A version 2 host can therefore be in one of two states with respect to the multicast routers that are present on the network, as shown in Figure 3-15.  
   
  Figure 3-15: IGMP version 1 and version 2 interaction  
  Hosts will initially be in the state No IGMP Version 1 Router Present. If a host receives a version 1 IGMP Membership Query, one in which the Maximum Runtime field is zero, the host makes a transition to the state IGMP Version 1 Router Present and sets a timer equal to the value Version 1 Router Present Timeout. Whenever a version 1 Membership Query is received while in this state, the timer is reset to the Version 1 Router Present Timeout value. If this timer counts down to zero, then the host makes a transition to the No IGMP Version 1 Router Present state.
IGMP Router States  
  We have seen that a router can be in one of two states with respect to its query status on the network, being either the Querier or the Non-Querier, as shown in Figure 3-16. An IGMPv2-enabled router starts in the Initial state, sends a General Membership Query message, and sets the General Query timer. Whenever the General Query Timer expires, the timer is reset and a General Membership Query message is sent. If a router in the Querier state hears a General Membership Querier message from a router with a lower IP address, then the router makes a transition from the Query state to the Non-Querier state and sets the Other Querier Present Timer. While in the Non-Querier state, this Other Querier Present Timer is reset each time a General Membership Query is received from a router with a lower IP address. If the timer times out, then no General Membership Queries have been received during the Other Querier Present time and the router changes from the Non-Querier state to the Query state.  
   
  Figure 3-16: Query status state diagram for IGMPv2-enabled routers  
  The state diagram for a router in the Query state is shown in Figure 3-17 and the Non-Query state in Figure 3-18. When IGMPv2 is initialized, the router enters the initial state and sends General Membership Queries on all interfaces and then makes a transition to the Querier state. If no members are present on an attached network, the state for that interface will be No Members Present. Because no members are present on the network, the router does not need to periodically transmit General Membership Queries out of the interface.  
   
  Figure 3-17: State diagram for an IGMPv2 enabled router in the Query state  
   
  Figure 3-18: State diagram for an IGMPv2-enabled router in the Non-Querier state  
  Routers will be notified by hosts that want to join a particular group. A host can either transmit a version 1 or version 2 IGMP Membership report. If only version 2 Membership Reports are received, the router will make a transition to the Members Present state. If a version 1 report is received, then the router will make a transition to the Version 1 Members Present state, even though there may be version 2 hosts present.  
  While in the Version 1 Members Present state, the router needs to track whether or not version 2 hosts are present on the attached network. When the version 1 host timer expires, the router will either move to the Members Present state if there are version 2 hosts present or to the No Members Present state. As long as version 1 Membership Reports are being received, the router will stay in the Version 1 Members Present state.  
  In the Members Present State, the reception of version 2 Membership Reports refreshes the Group Membership Interval timer and the router stays in the Members Present state. If a version 1 Membership Report is received, a transition to the Version 1 Members Present state occurs. Recall that one enhancement to IGMP version 2 was the Leave Group Message. When a Leave Group Message is received, the router has no idea if this is the last host to leave the group because routers only need to track if there is at least one member of the group on the network and not the number of members. A Leave Group Message in the Members Present state causes a transition to the Checking Membership state, while a Leave Group message in the Version 1 Members Present state has no effect because there is at least one Version 1 host that is still a member of the group.  
  The state diagram for a router in the Non-Querier state is passive in nature because the router is only listening to Membership reports and Membership Queries and is not actively polling for group members (see Figure 3-18).  
  Configuring IGMP  
  Configuring IGMP on Cisco routers is very easy you don t have to do anything. When a multicast routing protocol is enabled on a router interface, IGMP is automatically enabled. A number of commands exist to tailor IGMP to suit your environment. IGMP interface commands can be listed by entering interface configuration mode and typing  
  router(config-if)aip igmp ?  
  access-group  
  IGMP group-access group  
 
  helper-address  
  IGMP helper address  
 
  join-group  
  IGMP join multicast group  
 
  querier-timeout  
  IGMP previous querier timeout  
 
  query-interval  
  IGMP host query interval  
 
  query-max-response-time  
  IGMP max query response value  
 
  version  
  IGMP version  
 
  By default, all hosts on a subnet are allowed to join all multicast groups. The groups that hosts on a subnet can join are controlled using the interface command:  
  ip igmp access-group access-list-number [version].  
  access-list-number  
  IP standard access-list number (1 99)  
 
  version  
  Optional. Changes the IGMP version number. Default is 2.  
 
  Example  
  Configure the ethernet 0 interface on a router such that hosts can only join multicast groups 239.0.0.0 through 239.255.255.255.  
  interface ethernet 0  
  ip igmp access-group 1  
  access-list 1 permit 239.0.0.0 0.255.255.255  
  To enable stub multicast routing, use the ip igmp helper-address in conjunction with the ip pim neighbor-filter command. This IGMP command causes the router to forward IGMP Host Reports and Leave Group messages received on the interface to the IP address specified. An example of this command and stub multicast routing is contained in Chapter 7, Protocol Independent Multicast Sparse Mode.  
  ip igmp helper-address ip-address  
  IP address where IGMP Host Reports and Leave Group messages are forwarded  
  Example  
  See Chapter 7.  
  A router interface can be configured as though there are always receivers for a multicast group present on the interface. One reason to do this is to be able to ping all multicast routers. Sending a ping to a multicast group causes all routers that have joined that group to respond. To configure a router in order to join a multicast group on an interface, use the interface configuration command:  
  ip igmp join-group group-address  
  Multicast group IP address  
  Example  
  Configure interface ethernet 0 to join the multicast group 225.250.250.1.  
  interface ethernet 0  
  ip igmp join-group 225.250.250.1  
  The default IGMP query interval on an interface is 60 seconds. Every 60 seconds the router sends IGMP host-query messages on the interface. To modify this default value, use the interface command:  
  ip igmp query-interval seconds  
  seconds  
  Number of seconds between host-query messages. The value can be between 0 and 65535.  
 
  Example  
  Change the query interface on interface serial 0 to 3 minutes.  
  interface serial 0  
  ip igmp query-interval 180  
  Be very careful with this command. If the query interval is longer than the query timeout value, then IGMP is effectively broken on the interface. All neighbor routers should be configured with the same value.  
  The default Maximum Response Time that is advertised in IGMP queries is 10 seconds. This value can be modified using the interface command:  
  ip igmp query-max-response-time seconds  
  seconds  
  Maximum Response Time that is advertised in IGMP queries  
 
  Example  
  Configure the Maximum Response Time on interface ethernet 0 to 15 seconds.  
  interface ethernet 0  
  ip igmp query-max-response-time 15  
  A Non-Querier router on a multi-access network becomes the Querier if the current Querier times out. The default value for the time out is twice the Query Interval. To modify the Query Timeout Value, use the interface command:  
  ip igmp query-timeout seconds  
  seconds  
  Number of seconds a Non-Querier router will wait before taking over as Querier if the current Querier times out  
 
  Example  
  Change the Query Timeout Value to 60 seconds on interface serial 1  
  interface serial  
  ip igmp query-interval 30  
  ip igmp query-timeout 60  
  The ip igmp join-group command can be used to statically configure a router to join a multicast group. When this command is used, packets for the configured group are handled at the process level. To fast-switch the packets for a static group, use the interface command:  
  ip igmp static-group group-address  
  Group IP multicast address  
  Example  
  Configure interface ethernet 0 to join the multicast group 225.250.250.1.  
  interface ethernet 0  
  ip igmp static-group 225.250.250.1  
  When PIM is enabled on an interface, IGMP version 2 is automatically enabled. To change the version, use the interface command:  
  ip igmp version {2 | 1 }  
  Example  
  Configure the ethernet 0 interface to use IGMP version 1. If version 1 is configured on an interface, then the commands ip igmp query-max-response-time and ip igmp query-timeout cannot be used because they are version 2-specific.  
  interface ethernet 0  
  ip igmp version 1  
  Entries in the router s IGMP cache can be deleted using the Exec command:  
  clear ip igmp group [group-name | group-address |interface-type interface-number]  
  group-name  
  Optional. Multicast group name. Defined either in DNS or by the ip host command  
 
  group-address  
  Optional. Multicast group address  
 
  interface-type  
  Specify the interface (ethernet 0, serial 0, and so on)  
 
  Examples  
  To clear a particular group, use clear ip igmp group 225.250.250.1.  
  To clear all groups on an interface, use clear ip igmp group ethernet 0.  
  To clear all groups, use clear ip igmp group.  
  IGMP Show and Debug Commands  
  The available show commands can be listed in Exec mode by typing  
  router#show ip igmp ?  
  groups  
  IGMP group membership information  
 
  interface  
  IGMP interface information  
 
  Additional show options can be found by entering  
  router#show ip igmp groups ?  
  Ethernet  
  IEEE 802.3  
 
  Hostname or A.B.C.D  
  IP name or group address  
 
  Loopback  
  Loopback interface  
 
  Null  
  Null interface  
 
  Serial  
  Serial  
 
  |  
  Output modifiers  
 
  <cr>  
  Example  
  Show all multicast groups on all interfaces  
  router#show ip igmp groups  
  IGMP-Connected Group Membership  
  Group Address  
Interface  
 
Uptime  
 
Expires  
 
Last Reporter  
 
  225.250.250.1  
ethernet 0  
 
03:05:59  
 
Never  
 
172.16.4.3  
 
  group-address  
  Multicast group address  
 
  interface  
  Interface where the group joined  
 
  Uptime  
  How long the group has been joined on the interface in hours, minutes, and seconds  
 
  Expires  
  The time when the group is removed from the table in hours, minutes, and seconds  
 
  Last Reported  
  IP address of the last host to report membership  
 
  The current state of IGMP on an interface along with IGMP timer values can be shown using the Exec command:  
  router#show ip igmp interface ?  
  Ethernet  
  IEEE 802.3  
 
  Loopback  
  Loopback interface  
 
  Null  
  Null interface  
 
  Serial  
  Serial  
 
  |  
  Output modifiers  
 
  <cr>  
  An individual interface can be displayed using  
  router#show ip igmp interface ethernet 0  
  ethernet 0 is up; line protocol is up  
  Internet address is 172.16.4.3/24  
  IGMP is enabled on interface  
  Current IGMP version is 2  
  CGMP is disabled on interface  
  IGMP query interval is 60 seconds  
  IGMP querier timeout is 120 seconds  
  IGMP max query response time is 10 seconds  
  Inbound IGMP access group is not set  
  IGMP activity: 1 joins, 0 leaves  
  Multicast routing is disabled on interface  
  Multicast TTL threshold is 0  
  Multicast groups joined (number of users): 225.250.250.1(1)  
  Finally, the operation of IGMP can be monitored using the debug ip igmp command:  
  router#debug ip igmp  
  05:09:55: IGMP: Received v2 Query from 172.16.4.1 (ethernet 0)  
  05:09:55: IGMP: Set report delay time to 7.0 seconds for 225.250.250.1 on ethernet 0  
  05:10:02: IGMP: Send v2 Report for 225.250.250.1 on ethernet 0  
  05:10:02: IGMP: Received v2 Report from 172.16.4.3 (ethernet 0) for 225.250.250.1  
  05:10:15: IGMP: Send Leave for 225.250.250.1 on ethernet 0  
  References  
  RFC 1054, Host Extensions for IP Multicasting, S. Deering, Stanford University, 1988  
  RFC 1112, Host Extensions for IP Multicasting, S. Deering, Stanford University, 1989  
  RFC 2236, Internet Group Management Protocol Version 2, W. Fenner, Xerox PARC, 1997  

 


 
 


Cisco Multicast Routing and Switching
Cisco Multicast Routing & Switching
ISBN: 0071346473
EAN: 2147483647
Year: 1999
Pages: 15

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