Learning Center
Plans & pricing Sign in
Sign Out

IP Multicast Fundamentals


									Certification Zone - Tutorial                                                        Page 1 of 39


   IP Multicast Fundamentals
                                                                              by David Wolsefer

    Why Multicast
    Multicast Applications
    Multicast Basics
   Multicast Addressing
    Class D Addresses
    Reserved Link Local Addresses
    Globally Scoped Addresses
    Limited Scope Addresses
    Global Addressing
    Layer 2 Multicast Addresses
    Layer 2 Multicast Frame Switching
      Manual Multicast Port Configuration
      Cisco Group Multicast Protocol (CGMP)
      IGMP Snooping
   Layer 3 IP Multicast
      IGMP Version 1
      IGMP Version 2
      IGMP Version 1-Version 2 Interoperability
      IGMP Version 3
    Multicast Distribution Trees
      Source Distribution Trees
      Shared Distribution Trees
    Multicast Forwarding
    Reverse Path Forwarding
    Multicast Static Routes
    TTL (Time-To-Live) Threshold Checks
   Multicast Routing Protocols
    Manual Multicast Router Configuration
      Static Rendezvous Points
      Special Cases
      PIM Dense Mode
      PIM Sparse Mode (RFC 2362)
      PIM Dense Mode vs. PIM Sparse Mode, A Comparison
      PIM Sparse-Dense Mode
   Advanced IP Multicast Topics
    Multiprotocol BGP
    Multicast Source Discovery Protocol (MSDP)
   Troubleshooting IP Multicast
    Show Commands
    Debug Commands
    Other Useful Commands
    Debugging Strategy 5/31/2005
Certification Zone - Tutorial                                                                        Page 2 of 39


   Why Multicast
   One of my personal areas of interest as a CCIE is IP multicast. If you are not very experienced with
   multicast, you may wonder what exactly multicast is and why we should employ multicast. Multicast is
   a technology that lets us save bandwidth in the network by sending a single traffic source stream to
   only those hosts interested in receiving the traffic. In the early days of radio on the Internet, one of the
   models that we commonly used was to click a link on a web page to listen to a given radio station. Your
   audio application would then open up and try to connect to the audio server. Each new person that
   clicked on the link would generate a new unicast stream of traffic. The user experience was not very
   good back then because each person who wanted to listen to the radio station generated a new data
   stream and this quickly overloaded both the audio server and the Internet links themselves. A lot of
   smart engineers saw this limitation and the MBONE was born. The MBONE provided a way to send a
   single stream to many users, and this technology is what multicast is all about.

   Multicast Applications
   With multicast, we can deliver a higher quality user experience by not overloading the source server
   and by conserving bandwidth. The problems described above are bad enough with simple audio, but are
   even worse when sending higher-bandwidth traffic like video. In a recent deployment in which I
   participated, we had three simultaneous multicast streams: a video stream, an audio stream, and an
   events-cueing stream. All three of these streams had to be synchronized to enable the end user to view
   the online presentation. This included a video window with matching audio, Power Point slides flipping
   in synchronization with the speaker in the video window, and a chat window for questions to the
   moderator. This type of application would have been impossible to carry out using just unicast because
   the bandwidth required would be too great in a large deployment.

   Multicast applications are by no means limited to audio and video. We are only limited by our
   imagination when it comes to applications capable of using multicast; new applications that use
   multicast come along all the time. Any time we have many receivers, but only a small number of
   sources, we can use multicast very effectively. Some of the current applications that take advantage of
   multicast are streaming audio, streaming video, video conferencing, whiteboard software, software
   updates, collaborative software, and real-time financial data delivery. So how does multicast work?
   What are the basic concepts behind multicast?

   Multicast Basics
   In answering the questions posed above, we must realize that multicast is dependent on the concept of
   multicast groups and more specifically, membership in a given multicast group. Suppose that an
   arbitrary group of hosts wanted to receive a particular data stream such as a broadcast of a baseball
   game. These hosts might be anywhere on the Internet, so there is no physical or geographical
   boundary. Clearly, there needs to be a mechanism for the hosts to indicate interest in a given multicast
   group. The mechanism for indicating desired membership in a multicast group is the Internet Group
   Management Protocol (IGMP). Although we will get into the nitty, gritty detail later in this paper, the
   basic concept is that a host joins a given multicast group using IGMP. The host's router then passes on
   to the multicast source's router that the source router needs to send the multicast packets to the host's
   router for transmission onto the subnet where the host resides. You should look at RFC 1112 for more
   information on IGMP and the early beginnings of multicast.

   It should be obvious by now that the multicast service model has many advantages, including increased
   efficiency by reducing network traffic and server CPU loads, optimized performance by eliminating 5/31/2005
Certification Zone - Tutorial                                                                      Page 3 of 39

   redundant traffic, and distributed applications made possible by the multipoint nature of multicast.
   Although multicast has many advantages, it is not without disadvantages. For example, most multicast
   applications are UDP based. This results in some problems when applications would be better served
   with TCP. Because UDP is, by definition, only best effort delivery, more packet drops will occur than you
   would see with TCP. Please note that this is not because TCP offers a guaranteed quality of service. TCP
   does no such thing. TCP has some congestion control mechanisms, such as TCP windowing or slow start
   that UDP does not. With UDP-based real-time data applications, e.g., video or audio, retransmission of
   the data by the application is not practical. If the losses get to be too extensive, you will start to see
   pixelation in the video, and audio will become broken and out of sync with the video. Because multicast
   applications tend to be UDP based, they need to be able to handle out-of-sequence packets as well as
   duplicate packets.

   Multicast Addressing
   Class D Addresses
   From a historical perspective, the Internet Assigned Numbers Authority (IANA) assigns IP Multicast
   addresses from the old Class D address space, - Note: This address range
   is only for the destination address or group address of IP Multicast traffic. The source address for IP
   multicast traffic is always the unicast source address. Don't forget that there is no longer any address
   space classified as Class A, B, C, D, or E. All address space is now assigned using Classless Internet
   Domain Routing rules (CIDR).

   Reserved Link Local Addresses
   Addresses in the range - are reserved by the IANA for use by network protocols
   on local network segments. Packets with these addresses should not be forwarded by routers, but
   should remain on their local LAN segment. Packets with addresses in this range are always transmitted
   with a time-to-live (TTL) of 1.

   Network protocols on local network segments use these reserved link local addresses to exchange
   routing information. For example, EIGRP uses for reliable delivery of Hello packets every 5
   seconds. Here are some well-known addresses in the - range:

                                   Address      Used For

                             All systems on this subnet

                             All routers on this subnet

                             OSPF Routers

                             OSPF Designated Routers

                             RIP Version 2


                          DHCP Server / Relay Agent

                          All PIM Routers

   Globally Scoped Addresses
   The address range through, known as the Globally Scoped Address range,
   can be used to multicast between different domains and across the Internet. Some of these addresses
   are also reserved by the IANA for specific multicast applications. Here are some sample addresses: 5/31/2005
Certification Zone - Tutorial                                                                      Page 4 of 39

                                    Address      Used For

                              All systems on this subnet



   You can find out more information about reserved multicast addresses at

   Limited Scope Addresses
   The address range - is known as the Limited Scope Addresses or
   Administratively Scoped Addresses as defined in RFC 2365. In more complex multicast
   implementations, filters are typically configured on border routers to prevent multicast traffic in this
   address range from flowing outside the Autonomous System or any other user-defined domain. Large
   organizations can also use these addresses to subdivide the Autonomous System into smaller areas so
   that local multicast boundaries can be defined.

   Global Addressing
   RFC 2770 proposes that the address range be used for statically defined addresses by
   organizations that already have an AS number reserved. The AS number of each domain is embedded
   into the second and third octets of the address range. For example, AS 14312, is written in
   hexadecimal as 37E8. If we separate the two octets 37 and E8, we get 55 and 232 in decimal. This
   would give us a subnet of to be globally reserved for AS14312's use.

   Layer 2 Multicast Addresses
   I cannot emphasize enough how important it is to understand what is happening at Layer 2 with
   multicast. For example, if you were tasked to support multicast on the Catalyst 3920 Token Ring
   switch, would you know what to do? If you were asked to configure a Catalyst 5000 to support
   multicast for Ethernet or Fast Ethernet, would you know what is required? Let's begin with Ethernet and
   then move on to cover Token Ring.

   Unless a Network Interface Card (NIC) is configured in a non-standard mode such as promiscuous
   mode, a standard NIC will only recognize packets sent to its burned in MAC address or the broadcast
   MAC address. This causes an acute problem with multicast because there needs to be a way for
   multicast group members on the same segment to receive the same packet, yet still be able to
   differentiate between different multicast groups on the same segment. Luckily, the Ethernet 802.3
   standard specifications make allowances for this requirement by using bit 0 of the first octet to indicate
   a broadcast or multicast by setting this bit to a 1. Figure 1 shows the broadcast/multicast bit in an
   Ethernet frame.

                      Figure 1. The Broadcast/Multicast Bit in an Ethernet Frame 5/31/2005
Certification Zone - Tutorial                                                                      Page 5 of 39

   The IANA owns a block of Ethernet MAC addresses that in
                                                                  You may wonder why this problem arose.
   hexadecimal begins with 00:00:5E. This represents the 24
                                                                  After all, why should we be willing to lose
   high order bits of the Ethernet address space ranging from
                                                                  five bits of information? This Layer 3 to
   00:00:5E:00:00:00 to 00:00:5E:FF:FF:FF. Remember that
                                                                  Layer 2 address mapping problem
   Ethernet addresses are 48 bits long. Out of this block, the
                                                                  occurred when Dr. Steve Deering was
   IANA allocates half the block for multicast addresses. Since
                                                                  doing his doctoral research in IP
   the first byte of any Ethernet address must be 01 to
                                                                  multicast. In order to map all 28 bits, Dr.
   represent multicast, the Ethernet address space
                                                                  Deering would need 16 OUIs to map all
   corresponding to IP multicast ranges from
                                                                  28 bits of Layer 3 address information
   01:00:5E:00:00:00 to 01:00:5E:7F:00:00. This address
                                                                  into Layer 2 MAC addresses. An OUI is
   allocation by the IANA only allows 23 bits of the multicast
                                                                  an Organizational Unique Identifier and is
   group ID to be represented in the Ethernet address. Normal
                                                                  the high 24 bits of a MAC address
   unicast IP addresses are represented by 32 bits in the
                                                                  assigned to an organization by the IEEE.
   dotted decimal format we are all used to, for example,
                                                                  This means that one OUI only provides Since multicast address space ranges from
                                                                  24 bits of unique MAC addresses to an to, or in binary 1110 0000.
                                                                  organization. At the time, Dr. Deering
   0000 0000. 0000 0000. 0000 0000 to 1110 1111. 1111
                                                                  was researching IP multicast, the IEEE
   1111. 1111 1111. 1111 1111, we can see that the four
                                                                  charged over $1000 per OUI. Dr.
   high order bits are always 1110, leaving only the last 28
                                                                  Deering's advisor was unwilling to spend
   bits to change. You should see by now that we have a
                                                                  $16,000 to obtain 16 OUIs, but was
   problem because we really need to be able to represent 28
                                                                  willing to purchase a single OUI. Dr.
   bits, but are only able to represent 23 bits. A clear
                                                                  Deering's advisor was also unwilling to
   understanding of the relationship between IP multicast at
                                                                  give Dr. Deering the entire 24 bits of the
   Layer 3 and IP multicast at Layer 2 is important because
                                                                  OUI's available MAC addresses since the
   we need to recognize that multicast works at Layer 3 on
                                                                  advisor wanted to reserve half of the
   routers and Layer 2 on switches. A traditional Layer 2
                                                                  OUI's MAC addresses for research by
   switch has no means of understanding what is happening
                                                                  other graduate students. This decision
   at Layer 3. The switch is only a Layer 2 device. We,
                                                                  meant that Dr. Deering was only
   therefore, need a way of representing Layer 3 multicast IP
                                                                  allocated half the MAC addresses to work
   group addresses as Layer 2 MAC addresses.
                                                                  with, resulting in the present 23 bits.

   What does this problem mean in a practical sense? In practical terms, because of this 28 bit Layer 3 vs.
   23 bit Layer 2 problem, we have a series of overlapping addresses sometimes referred to as the 32-to-
   1 problem. For example, the following 32 IP multicast addresses map to the same Layer 2 MAC address
   of 01:00:5E:0A:00:01 because the upper five bits of the IP Multicast address are dropped in the
   mapping to 23 bits:                

   In a similar fashion, you will see other addresses overlap because of this 32-to-1 problem. For example,,,, and all map to the same Layer 2 MAC address of
   01:00:5E:01:01:01. You may wonder what we mean by the term "32-to-1 problem." Since 28 bits of
   Layer 3 information must be mapped to 23 bits of Layer 2 information, 28-23 = 5. 25 = 32 resulting in
   a 32:1 overlap of Layer 3 addresses to Layer 2 addresses. As you should see by now, it is important to
   be able to convert Layer 3 IP multicast addresses to their Layer 2 MAC address. As an engineer, you
   need to be careful in choosing which multicast group addresses to use so that you can avoid this
   problem. Let's look at a practical example of how to convert a Layer 3 multicast IP address to a Layer 2
   multicast MAC address. 5/31/2005
Certification Zone - Tutorial                                                                    Page 6 of 39

                                     Figure 2. A Multicast MAC Address

   In a recent multicast deployment, we used a multicast group address of for testing
   purposes. To determine the multicast MAC address for this group address, let's begin by representing in binary, = 1110 1111 1111 1111 0000 0000 0000 0011. Notice that in
   binary, is 32 bits in length. Since we can only use the low 23 bits in the multicast MAC
   address, if we take the 23 low order bits of, we get 111 1111 0000 0000 0000 0011 in
   binary or 7F 00 03 in hexadecimal. We begin the process to determine the multicast MAC address by
   remembering that multicast MAC addresses always begin with 01:00:5E. When we add the 23 low bits
   of, we get a Layer 2 multicast MAC address of 01:00:5E:7F:00:03. Before we move on to
   a discussion of just how we determine which multicast group a given host is a member of, let's also
   examine what happens at Layer 2 in the case of Token Ring because, as you might expect, Token Ring
   behaves quite differently from Ethernet.

   With Token Ring, the Layer 3 multicast IP address maps to only the broadcast MAC address or possibly
   to a single address referred to as the "functional address." We must also remember that with Token
   Ring, the bit order of bytes is reversed so Token Ring MAC addresses are normally represented in their
   non-canonical form. See my previous Bridging Study Guide for a more detailed discussion of canonical
   vs. non-canonical MAC addresses. It used to be that all multicast IP addresses only mapped to the
   broadcast MAC address. This creates tremendous problems on Token Ring networks because instead of
   a 32:1 problem, you have a 268,435,200:1 problem (32 bits in an IP address minus the first 4 bits
   leaves 228 or 268,435,200). By mapping all multicast groups to only a single MAC address, all end
   systems are unable to use their Token Ring NIC cards to filter wanted vs. unwanted multicast packets.
   These end systems must now use their onboard CPUs instead of onboard hardware processing by the
   NIC cards to filter wanted vs. unwanted packets. This results in a very significant decrease in end
   system performance on Token Ring networks when multicast traffic is present. This problem was
   recognized in 1993 when RFC 1469, "IP Multicast over Token-Ring Local Area Networks," was
   published. This RFC defined a new concept called the "functional address." The basic idea behind the
   functional address concept was to use an address other than the broadcast address to represent
   multicast on Token Ring networks. Cisco uses the Token Ring functional address 0xc000.0004.0000 to
   represent multicast. There are a limited number of Token Ring functional addresses and, in fact, not
   every packet destined for 0xc000.0004.0000 is a multicast packet. Because of this limited number of
   Token Ring functional addresses, it is impossible to perform any sort of Layer 3 to Layer 2 mapping as
   we can with Ethernet. The bottom line to you as an engineer is that, if you are working with a Token
   Ring network and need extensive multicast support, you really need to migrate to an Ethernet-based
   technology. Here are some examples of how we can use the broadcast and functional addresses for
   multicast on Token Ring networks.

   Example 1 - Using the broadcast address 0xffff.ffff.ffff to support multicast (the default)

   interface token-ring 0
   ip pim sparse

   Example 2- Using the functional address 0xc0000.0004.0000 to support multicast 5/31/2005
Certification Zone - Tutorial                                                                        Page 7 of 39

   interface token-ring 0
   ip pim sparse
   ip multicast use-functional

   Previously, we discussed the concept of group membership. You probably wondered just how does a
   given host computer join a multicast group? The answer to this question is that individual hosts use a
   dynamic protocol known as IGMP to join multicast groups on a given LAN segment. You need to know
   that IGMP is a Layer 3 protocol used for communications between hosts and routers to register
   multicast group membership. So, we will cover IGMP under Layer 3, but just be aware of what this
   protocol is used for until then because you need some idea of that to understand the problem created
   at Layer 2 on switches.

   Layer 2 Multicast Frame Switching
   Multicast traffic creates problems in Layer 2 switches that do not have technology specifically designed
   to counter these problems, such as Cisco Group Multicast Protocol (CGMP) or IGMP Snooping. To
   understand this problem, ask yourself what happens when Layer 2 traffic arrives on a switch and is a
   broadcast or has an unknown destination. The answer, of course, is that in these two cases, the traffic
   is flooded out to every port. The reason that multicast traffic is treated in this fashion is that multicast
   traffic arrives with a multicast MAC address. If you think about how a Layer 2 switch builds its tables,
   you will see that the switch has no means of associating a multicast MAC address with a specific port
   unless we use techniques such as CGMP or IGMP Snooping. Therefore, the switch will treat multicast
   traffic as "unknown." Besides the two dynamic methods we can use to fix this flooding of multicast
   traffic (CGMP and IGMP Snooping), there is also a manual technique available on some switches. We
   can make a static entry or permanent entry in the switch's CAM table to specify which ports should
   receive a given multicast group using the multicast MAC address. In a large network, this would clearly
   not scale well, so we generally use one of the two dynamic techniques. Before we take a closer look at
   the two dynamic protocols, let's first look at manual port configuration for specific multicast MAC

   Manual Multicast Port Configuration
   The first step in manual configuration is to define which ports are connected to multicast-capable
   routers. We can accomplish this using the set multicast router command on the switch.

   set multicast router mod_num/port_num

   You will want to confirm the configuration by using the show multicast router command.

   show multicast router [mod_num/port_num] [vlan_id]

   Here is an example. Note that the * indicates that the entry was manually configured:

   Switch> (enable) set multicast router 4/8
   Port 4/8 added to multicast router port list.
   Switch> (enable) show multicast router
   CGMP enabled
   IGMP disabled

   Port          Vlan
   ---------     ----------------
    4/1          2
    4/2          3
    4/8    *     1
    4/9          2,3 5/31/2005
Certification Zone - Tutorial                                                                      Page 8 of 39

   Total Number of Entries = 4
   '*' - Configured
   Switch> (enable)

   To manually configure multicast groups on a Catalyst 5000 switch, use the set cam static command
   or the set cam permanent command. Note: manually defined group membership for a multicast
   group address takes precedence over any dynamic manipulation by CGMP or IGMP. Multicast group
   membership lists can have both user-defined static settings and CGMP or IGMP dynamically learned

   Note: It is very important to understand the difference between set cam static and set cam
   permanent. If you want the manual configuration to be retained following a reboot of the switch, then
   you need to use set cam permanent instead of set cam static. Here is the command syntax:

   set cam {static | permanent} multicast_mac mod_num/port_num [vlan]

   You will want to check the configuration by using the show multicast group command.

   show multicast group [mac_addr] [vlan_id]

   Here is an example:

   Switch> (enable)      set cam static 01-11-22-33-44-55 2/1-8
   Static multicast      entry added to CAM table.
   Switch> (enable)      set cam static 01-22-33-44-55-66 2/1-8
   Static multicast      entry added to CAM table.
   Switch> (enable)      set cam permanent 01-33-44-55-66-77 2/1-8
   Static multicast      entry added to CAM table.
   Switch> (enable)      show multicast group
   CGMP enabled
   IGMP disabled

   VLAN   Dest MAC/Route Des         Destination Ports or VCs / [Protocol Type]
   ----   ------------------         --------------------------------------------
   1      01-11-22-33-44-55*         2/1-8
   1      01-22-33-44-55-66*         2/1-8
   1      01-33-44-55-66-77+         2/1-8

   Total Number of Entries = 3
   Switch> (enable)

   Again, note that the * indicates that the entries were statically configured, and the + indicates that the
   entry was configured as a permanent entry. Now that we have examined manual configuration, let's
   look at the two dynamic techniques: CGMP and IGMP Snooping.

   Cisco Group Multicast Protocol (CGMP)
   Cisco Group Management Protocol (CGMP) is used on routers connected to Cisco Catalyst switches to
   perform tasks similar to those performed by IGMP Snooping. CGMP was necessary because Catalyst
   switches without NetFlow Feature Cards (NFFC) could not differentiate between IP multicast data
   packets and IGMP Report messages, which are both MAC-addressed to the same group address. Once
   the newer Supervisor II and III modules with NFFC were available, then the Catalyst switches with
   them were able to use IGMP Snooping. Let's take a closer look at how CGMP works. 5/31/2005
Certification Zone - Tutorial                                                                     Page 9 of 39

                                 Figure 3. Cisco Group Multicast Protocol

   When a host wants to join an IP multicast group, it sends an IGMP join message to the router that
   specifies its MAC address and the IP multicast group it wants to join. The router then builds a join
   message and multicasts the join message to the well-known address that all switches listen to.

   When a router receives an IGMP control packet, it creates a CGMP or IGMP packet that contains the join
   or leave request, the multicast group address, and the MAC address of the host. The router will then
   send the control packet to a well-known address that all switches listen to. When a Catalyst switch
   receives the CGMP or IGMP control packet from the router, the supervisor engine responds by
   modifying the forwarding table automatically.

   Since there is most likely a switch between the host and the router, you may be wondering how the
   switch handles this join message since the switch would actually receive the join message before the
   router. What happens is that when the switch receives the join message, the switch searches its
   Enhanced Address Recognition Logic (EARL) table to see if it already contains the MAC address of the
   host asking to join the multicast group. If the switch finds the MAC address of the host in its EARL
   table, and the port associated with the MAC address is not a trunk, then the switch creates a multicast
   forwarding entry in the forwarding table. Now the host associated with that port will receive multicast
   traffic for that specific multicast group.

   The default configuration for Catalyst 5000 switches is that CGMP is not enabled. You should also note
   that you cannot enable CGMP if IGMP Snooping is enabled. You will also need to make sure that the
   multicast routers attached to the switch have CGMP enabled. To configure CGMP on the switch, just use
   the set cgmp enable command. You will want to check your work with the show cgmp statistics
   command. Here is a step-by-step guide to configuring CGMP on both the router and switch.

     1. Make sure that the router is configured for IP multicast, PIM, and CGMP as follows:

         To configure CGMP on the router, you must first make sure that multicast routing is enabled. In
         global configuration mode, use the ip multicast-routing command to enable multicast

         Next, you will need to enable IP PIM for the LAN interface with which you want to use CGMP. This
         is necessary because when you enable IP PIM, you also enable IGMP. IP PIM is covered in more 5/31/2005
Certification Zone - Tutorial                                                                     Page 10 of 39

         detail later in this Tutorial. For now, just remember that PIM is a multicast routing protocol, not a
         group membership protocol. The reason we need to configure PIM here is that it activates or
         enables IGMP for use as a group membership protocol. For now, you can use any IP PIM mode.
         We just want to make sure that IGMP is enabled.

         Once multicast routing is enabled and IP PIM is enabled on the LAN interface you want to use for
         CGMP, you will use the ip cgmp command only on LAN interfaces to enable CGMP. CGMP is not
         used on any interfaces that are not Ethernet interfaces and, even then, CGMP is only used if the
         switch connected to that interface is also configured for CGMP. Here is an example of how to
         configure CGMP on a router connected to a CGMP capable switch:

         Router(config)#ip multicast-routing
         Router(config)#interface FastEthernet 0/0
         Router(config-if)#ip pim dense-mode
         Router(config-if)#ip cgmp

         Now that the router configuration is complete, let's see how we configure the corresponding
         switch connected to the FastEthernet 0/0 interface.

     2. Enable CGMP on the switch.

         Switch> (enable) set cgmp enable
         CGMP support for IP multicast enabled.

     3. Check to make sure that CGMP is enabled on the switch.

         Switch> (enable) show cgmp statistics 1
         CGMP enabled

         CGMP statistics for vlan 1:
         valid rx pkts received                     199215
         invalid rx pkts received                   0
         valid cgmp joins received                  199215
         valid cgmp leaves received                 212
         valid igmp leaves received                 0
         valid igmp queries received                2096
         igmp gs queries transmitted                0
         igmp leaves transmitted                    0
         failures to add GDA to EARL                0
         topology notifications received            76
         number of CGMP packets dropped             1923512
         Switch> (enable)

   As you can see, CGMP configuration is simple. CGMP is also the technique that I prefer to use to solve
   the multicast MAC address problems on Layer 2 switches. CGMP, however, is not the only choice for
   preventing Layer 2 switches from seeing multicast packets as unknown traffic and forwarding these
   packets out all ports. IGMP Snooping is another method of dynamically controlling this traffic.

   IGMP Snooping
   Several years ago, switches did not have the intelligence required to look into packets and "snoop" out
   the information necessary to modify CAM tables with multicast MAC address information from the
   Layer3 packets passing through the Layer 2 switch. It took the development of advanced equipment
   such as Supervisor II and III modules with NetFlow Feature Cards (NFFC) before a technique as
   advanced as IGMP Snooping was possible. Since IGMP Snooping has some heavy equipment
   requirements, you will only find efficient IGMP Snooping in the higher-end Catalyst switches. Efficient
   IGMP Snooping requires the switch to have a Layer-3-aware ASIC to handle the IGMP Snooping and 5/31/2005
Certification Zone - Tutorial                                                                     Page 11 of 39

   this adds to the cost of the switch. In order to use IGMP Snooping on a Catalyst 5000 series switch, you
   must have a Supervisor Engine II G or III G, or Supervisor Engine II or III F with a NFFC or NFFC II.
   You must also have an IGMP-capable multicast router. Note that you cannot enable IGMP Snooping if
   CGMP is enabled. Configuring IGMP Snooping on a switch is easy and is very similar to configuring
   CGMP on a switch. You just use the set igmp enable command instead of the set cgmp enable
   command. You can check your configuration using the show igmp statistics command. Here is an

   Switch> (enable) set igmp enable
   IGMP Snooping is enabled.
   CGMP is disabled.
   Switch> (enable) show igmp statistics
   IGMP enabled
   IGMP fastleave disabled

   IGMP statistics for vlan 1:
   Total valid pkts rcvd:                     20541
   Total invalid pkts recvd                   0
   General Queries recvd                      402
   Group Specific Queries recvd               0
   MAC-Based General Queries recvd            0
   Leaves recvd                               21
   Reports recvd                              18423
   Other Pkts recvd                           0
   Queries Xmitted                            0
   GS Queries Xmitted                         15
   Reports Xmitted                            0
   Leaves Xmitted                             0
   Failures to add GDA to EARL                0
   Topology Notifications rcvd                11
   Switch> (enable)

   No special configuration is required on the router as long as multicast routing is enabled and the
   Ethernet interface is configured for a PIM mode to enable IGMP on that interface. You may wonder why
   you would want to use IGMP Snooping instead of CGMP. The answer, as always, is that the decision to
   use one technique over the other depends on the specific situation. CGMP is an active protocol and
   places more traffic on the network. IGMP Snooping, on the other hand, is a passive technique and does
   not place more traffic on the network. What if you are in a co-location facility and do not have
   administrative control over the upstream router? You may be able to request that the provider
   configure the upstream router or switch for CGMP, if they have Cisco equipment. They may not
   cooperate, however, or they may not have Cisco Equipment. Remember, CGMP is Cisco proprietary.
   IGMP Snooping is not. IGMP Snooping may not only be the better choice, it may be the only choice. It
   is difficult to understand IGMP Snooping well without understanding IGMP in general. With this in mind,
   let's take a closer look at how multicast functions at Layer3 since IGMP is a Layer3 protocol.

   Layer 3 IP Multicast
   Now that we have seen how multicast works at Layer 2, let's take a look at how multicast behaves at
   Layer 3 so that we can develop a clear understanding of what is happening with multicast at both
   layers. We need to understand the overall packet flow and associated signaling that occurs as a
   multicast packet leaves its source server, flows to its Layer 2 switch, to its upstream Layer 3 router,
   then downstream to the receiving host's router, to the host's switch, and finally to the host itself. Let's
   begin by examining one of the key protocols involved, the Internet Group Management Protocol (IGMP).

   IGMP (the Internet Group Management Protocol) provides a dynamic method for individual hosts to 5/31/2005
Certification Zone - Tutorial                                                                     Page 12 of 39

   register their membership in a given multicast group on that host's LAN segment. The way that IGMP
   works is that when a host wants to join a particular group, the host sends an IGMP message to the local
   multicast router. You might wonder how the host indicates that it wants to join a specific group. Most of
   the time, the host will indicate membership by having the user click on a particular web page multicast
   source such as real video or audio, but you can also use many different applications such as video
   conferencing software, group collaboration software, or perhaps a white board application. You may
   also wonder what is a good way to demonstrate and test multicast connectivity in your own network. I
   like to use a simple application called MCASTER, which is available as at To use MCASTER, you can connect two host computers
   into the network and run the application on each host. Within MCASTER, you can then choose to have
   one host act as a client and the other as a multicast source, or you can have both hosts act as multicast
   clients and sources. You can also specify which multicast groups to use and even choose which UDP
   ports to use with MCASTER. I find that it is a very handy little program to test multicast connectivity in

   There are three official versions of IGMP and several interim versions, so let's begin by taking a closer
   look at Version 1.

   IGMP Version 1
   RFC 1112 defines the specification for IGMP Version 1. See Figure 4 for the packet format.

                                 Figure 4. IGMP Version 1 Packet Format

   Notice that the IGMP Version 1 packet format is very simple because there are only two different types
   of IGMP messages: Membership Queries and Membership Reports.

   IGMP Version 1 works by having hosts send out IGMP Host Membership Reports to their router for the
   particular multicast group(s) that they are interested in joining. The router then sends out periodic
   IGMP Host Membership Queries to verify that at least one host on the subnet is still interested in
   receiving traffic for that particular multicast group. Note that when the router sends out periodic IGMP
   Host Membership Queries and there is more than one host on the subnet interested in that particular
   multicast group, only one of the hosts will answer the query. The other hosts will suppress reports back
   to the router. Since hosts silently leave the group, when there is no reply to three consecutive IGMP
   Host Membership Queries, the router will timeout the group and stop forwarding traffic for that
   particular multicast group. Since hosts silently leave multicast groups with IGMP Version 1, there is
   unnecessary multicast traffic on the network during the time between the host leaving the multicast
   group and the same group timing out on the router. IGMP Version 2 was developed to fix this problem.

   IGMP Version 2
   RFC 2236 defines the specification for IGMP Version 2. See Figure 5 below for the packet format. 5/31/2005
Certification Zone - Tutorial                                                                     Page 13 of 39

                                 Figure 5. IGMP Version 2 Packet Format

   Although IGMP Version 2 is very similar to IGMP Version 1, there are several differences. IGMP Version
   2 has four types of IGMP messages instead of just two. IGMP Version 2 still has the Host Membership
   Query message and the Version 1 Host Membership Report, but IGMP Version 2 also has a Version 2
   Host Membership Report and adds a new Host Leave Group message type. Because IGMP Version 1
   used silent leaves, traffic would be transmitted unnecessarily until the hosts timed out. IGMP Version 2
   provides a better solution because hosts can now explicitly inform the router that they wish to leave the
   multicast group. The router can then send out a group Host Membership Query and find out if there are
   any remaining hosts on the subnet that are multicast group members for that particular multicast
   group. If there are no replies, the router will time out that multicast group and stop forwarding
   multicast traffic to that subnet. The result is that unnecessary multicast traffic can be stopped much
   sooner and use even less bandwidth than with IGMP Version 1.

   By now, you may be wondering what happens if there is more than one router on the subnet. You
   should read RFC 2236 for a better understanding, but Figure 6 illustrates the situation. Basically, a
   Querier Election occurs, and the router with the lowest IP address is elected the Querier router. All
   other routers will become non-queriers. As with IGMP Version 1, only one host on the subnet will
   respond to the router queries. The other hosts will suppress the query response. 5/31/2005
Certification Zone - Tutorial                                                                   Page 14 of 39

                                   Figure 6. IGMP Version 2 Operation

   Since routers can use IGMP Version 1 and Version 2, you may wonder if you can use them together. Is
   there a clear migration path from networks using IGMP Version 1 to IGMP Version 2?

   IGMP Version 1-Version 2 Interoperability
   IGMP operates with both Version 1 and Version 2, but you must be aware of some of the problems that
   might arise. There are three basic cases. In the first case presented in Figure 7, all routers are using
   IGMP Version 1, but individual hosts may be using IGMP Version 1 or IGMP Version 2. In this case, all
   IGMP Version 2 hosts must send out Version 1 reports, but may suppress Version 2 leaves since the
   Version 1 routers will not understand them anyway. 5/31/2005
Certification Zone - Tutorial                                                                   Page 15 of 39

                                 Figure 7. IGMP Version Interoperability

   In the next case, presented in Figure 8, we have IGMP Version 1 and Version 2 hosts still, but all
   routers are using IGMP Version 2. In this case, IGMP Version 2 routers must set a timer since there is
   an IGMP Version 1 member present. The Version 2 routers must also suppress any leaves for groups
   with both IGMP Version 1 and Version 2 members until the timer expires.

                                 Figure 8. IGMP Version Interoperability 5/31/2005
Certification Zone - Tutorial                                                                   Page 16 of 39

   In the final example, presented in Figure 9 below, we still have Version 1 and Version 2 hosts, but we
   also have both IGMP Version 1 and Version 2 routers. In this case, IGMP must be configured manually
   on those routers that need to run IGMP Version 1.

                                 Figure 9. IGMP Version Interoperability

   The case presented in Figure 9 is the most problematic case. With newer versions of IOS, the router
   does not automatically detect other Version 1 routers and switch to Version 1. The default behavior in
   Cisco routers with IOS 12.0 and later is to use IGMP Version 2. If you have a situation where some
   routers are incapable of Version 2, or need to enable Version 1 to be compatible with other routers that
   can only use Version 1, then you must manually configure the router to use IGMP Version 1.

   To configure the version of IGMP that the router uses, use the ip igmp version interface
   configuration command. Remember that all devices on the subnet must support the same IGMP
   version. The command syntax is as follows:

   ip igmp version {3 | 2 | 1}

   Although IGMP Versions 1 and 2 are the versions in common use, there is a new IGMP version in
   development: IGMP Version 3.

   IGMP Version 3
   IGMP Version 3 is the newest version of the IGMP protocol. IGMP Version 3 differs from Version 1 and
   Version 2 in a number of ways, but the main difference is that IGMP Version 3 will let hosts tell routers
   which multicast traffic they want to receive and from which sources they want to receive it. Version 3 of
   this protocol adds support for host-specific membership reports, which, among other benefits, enables
   SSM. In Cisco IOS, IGMP Version 3 is part of the Source Specific Multicast (SSM) solution. Figure 10 is
   an example to illustrate how IGMP Version 3 works. 5/31/2005
Certification Zone - Tutorial                                                                     Page 17 of 39

                                    Figure 10. IGMP Version 3 Example

   IGMP Version 3 uses a new technology called Source Specific Multicast (SSM). SSM allows multicast
   traffic to be forwarded to receivers only from those multicast sources for which the receivers have
   explicitly expressed interest. SSM also provides a simple solution to IP multicast addressing problems,
   solves Denial of Service attack (DoS) related security concerns, and provides a better way to deploy
   multicast services in the Internet. SSM solves multicast addressing problems by generally using a single
   range of multicast IP addresses, the range, which is known as the SSM-Range. SSM
   addresses DoS attack concerns because, with SSM, multicast traffic will only flow from each individual
   source across the network if it was requested through an IGMP Version 3 group membership request
   from a receiver. This prevents someone from flooding your network by arbitrarily transmitting to a
   multicast group. SSM and IGMP Version 3 allow for simpler and easier scalable deployment of multicast
   services in the Internet because of the ability to allow receiver hosts and applications to define include
   or exclude lists for sources transmitting to a given multicast group. A detailed discussion of IGMP
   Version 3 will have to wait because the IETF is still defining the standards and basic support for IGMP
   Version 3 has only recently become available in IOS. You should be aware, however, that another key
   difference between IGMP Version 3 and previous versions of IGMP is that IGMP Version 3 requires host
   applications to be written specifically to support IGMP Version 3. For more information about Cisco's
   implementation of IGMP v.3, see the Source Specific Multicast (SSM) Homepage at You may also want to reference the related Internet
   draft documents. Links to these documents are also present on the Cisco SSM homepage.

   Multicast Distribution Trees

   Source Distribution Trees
   Multicast uses distribution trees. A distribution tree is simply the path in a network that traffic flows
   down from the source to the destinations. This concept is very similar to the mathematical concept of
   trees. There are two different types of distribution trees with multicast: source trees and shared trees. 5/31/2005
Certification Zone - Tutorial                                                                   Page 18 of 39

   A source distribution tree, or shortest path tree, is a minimal spanning tree with the lowest cost from
   the source to all leaves of the tree. Multicast packets are forwarded on the source tree using both the
   unicast source address S that the multicast packets originated from and the multicast group address G
   to which the packets are addressed. For this reason, the forwarding state on the source tree is referred
   to using the notation (S,G). For example, the shortest path between Source 1 and Receiver 1 is via R1,
   R2, and R3.

                                  Figure 11. Source Distribution Tree 1

   With source trees, there is a source path tree for every multicast source on the network. For example,
   the network shown in Figure 12 has an entirely different source path tree from Source 2 to Receiver 2
   than from Source 1 to Receiver 1. Clearly this type of distribution tree will not be optimum in a large
   network because there will be so many different source distribution trees. This leads us to our next
   topic of discussion: shared distribution trees. 5/31/2005
Certification Zone - Tutorial                                                                    Page 19 of 39

                                   Figure 12. Source Distribution Tree 2

   Shared Distribution Trees
   A shared distribution tree differs from a source distribution tree in a number of ways. With shared
   distribution trees, multicast traffic flows down to receivers from a central point. With PIM sparse-mode,
   which we will be discussing shortly, this point is known as the rendezvous point. You will notice another
   difference with shared distribution trees as well because multicast traffic is forwarded down the shared
   tree using just the multicast group address, G. The source address does not matter as it did with source
   trees. Instead of (S, G) with source trees, you will just see (*, G) with shared distribution trees. The *
   in this notation represents any source. See Figure 13. 5/31/2005
Certification Zone - Tutorial                                                                      Page 20 of 39

                                    Figure 13. Shared Distribution Tree

   One of the problems that a shared path tree must handle is the question "Just how does the multicast
   traffic get sent to the root of the tree?" After all, the router that is the root of the shared distribution
   tree does not know the instant a new multicast source starts sending multicast traffic. The answer may
   vary depending on which multicast protocol is being used, but let's examine the classic case of PIM
   sparse-mode. The rendezvous point (RP) forms a shortest path tree back to each multicast source. This
   allows the traffic to flow from each source to the RP using the shortest path tree, and then, from that
   point down the shared path tree. How does the RP know to join the shortest path tree to a new source?
   When a new multicast source starts sending packets, the multicast router directly connected to this new
   source sends a register message to the RP to let the RP know that there is a new active multicast
   source. In the example presented in Figure 14, the multicast sources use a source distribution tree to
   send multicast traffic to the RP. From that point, the multicast traffic will use a shared path tree to the
   receivers. 5/31/2005
Certification Zone - Tutorial                                                                      Page 21 of 39

                                Figure 14. PIM uses both distribution trees

   Previously, we discussed the fact that different multicast protocols form the distribution tree in different
   ways. Let's take a closer look at how some of the different protocols form distribution trees. As we
   already discussed, PIM uses the underlying unicast routing table to form the distribution tree, but PIM
   also uses Join, Prune, and Graft messages, which will be discussed in greater detail when we cover PIM
   later in the paper. DVMRP uses a special RIP-like multicast routing table plus Poison-Reverse, to tell the
   router to place itself on the distribution tree, as well as Prune and Graft messages similar to PIM.
   MOSPF utilizes the underlying OSPF unicast routing protocol's link state advertisements to build source
   path trees. Core Based Trees use the unicast routing table along with Join, Prune, and Graft messages
   in a manner nearly identical to that of PIM.

   Multicast Forwarding
   Multicast forwarding is very different from unicast forwarding. With unicast forwarding, the destination
   address is important. With multicast forwarding, however, the router uses the source address to make
   its forwarding decision. It may help to think of why multicast forwarding behaves this way. You have a
   known source, which needs to send to an unknown group of receivers; therefore, it is the known source
   that is important, not the destination.

   Reverse Path Forwarding
   It is very important to understand how multicast uses Reverse Path Forwarding (RPF) so that you can
   troubleshoot multicast problems effectively. So what is RPF? A router will only forward a multicast
   packet if the router receives the packet on the upstream interface to the source. You must be very
   aware that the multicast routing table for most multicast routing protocols, including PIM, is dependent
   on the unicast routing table for normal IP routing in a fashion similar to the way that iBGP depends on
   the unicast routing table. When the router receives a multicast packet, the router checks to see if the 5/31/2005
Certification Zone - Tutorial                                                                     Page 22 of 39

   packet arrived on the interface listed in the routing table for the source IP address. If this is the case,
   then the RPF check succeeds. If this is not the case, then the RPF check fails. One question that should
   come to mind is "What happens to the RPF check if the unicast routing table changes due to a topology
   change?" When this happens, RPF does not change immediately, but eventually (the current default is 5
   s), the RPF check will detect the change. When the RPF check is successful, the multicast packet will be
   forwarded out each interface in the outgoing interface list. When the RPF check fails, the multicast
   packet will be silently dropped. Note: before IOS 12.0, the multicast packet was never forwarded back
   out the interface on which it arrived.

                                         Figure 15 Failed RPF Check

   In the example seen in Figure 15 and in more detail in Figure 16, R2 receives multicast packets on two
   different interfaces: S0 and S1. Since there is only one multicast distribution tree to any one given
   source of multicast traffic, the router will perform an RPF check to prevent forwarding duplicate
   packets. In the first case, the RPF check is performed on multicast packets received on interface S0
   from multicast source This RPF check succeeds because the data was received on the
   correct incoming interface according to the unicast routing table. The data received on interface S0 will
   now be forwarded out all outgoing interfaces on the multicast distribution tree. In the second case, the
   RPF check is performed on multicast packets received on interface S1 from multicast source This RPF check fails because the data was not received on the correct interface according
   to the unicast routing table. Since the RPF check fails, these packets will be silently dropped. Here is a
   closer look at what happens in this example on R2. 5/31/2005
Certification Zone - Tutorial                                                                     Page 23 of 39

                                        Figure 16. RPF Check Detail

   The RPF check can create problems in situations where you need a different multicast traffic path than
   the unicast path. Although you can use several techniques in situations like this, a simple solution is to
   use a multicast static route. In situations where you are not allowed to use a multicast static route, you
   will have to manipulate the unicast routing tables with distribution lists and/or use tunnels.

   Multicast Static Routes
   IP multicast static routes (mroutes) allow you to have a different path for multicast traffic than the
   unicast paths. I ran into this problem recently when a customer used a DS3 VPN to connect their offices
   in Boston with their offices in San Jose. Since the VPN used IPSec and was carrying live voice and
   video, it was very sensitive to delay. With IPSec, you cannot use multicast. IPSec only supports unicast
   unless you use a GRE tunnel, but the time-sensitive data didn't allow for this added latency. (Note: this
   latency is vendor-specific. If the tunnels are done in hardware rather than software, this latency may
   not be an issue.) We had to work around the problem by using a backup link with a much lower
   bandwidth (8 Mb HSSI vs. 45 Mb DS3) and a static mroute. What happened is that the Boston router
   expected to receive packets on the same interface where it sends unicast packets back to the source
   (namely the VPN). This would have been great if the link were a point-to-point DS3 rather than a DS3
   VPN since the multicast and unicast topologies would be the same. In this case, however, we needed
   the unicast packets to take one path and multicast packets to take another. The most common reason
   for using separate unicast and multicast paths is tunneling. Normally, when a path between a source
   and a destination does not support multicast routing, the solution is to configure two routers with a GRE
   tunnel between them. Unfortunately, in this situation a GRE tunnel was unacceptable for security
   reasons. One solution was to use a distribute list on both of the VPN end routers to deny any unicast
   routing knowledge of the subnet containing the source, but this is not very scalable. What do you do if
   you have multicast sources on many subnets? Clearly, a better solution was needed. This better
   solution was a static mroute. A static mroute lets you configure a static multicast source. When you
   configure a static mroute, IOS prefers this route over the unicast routing table. You should note that
   static mroutes are local to the router on which they are configured and are not advertised or
   redistributed to any other router. Here is an example:

   To configure a multicast static route, use the following command in global configuration mode:

   Router(config)#ip mroute source-address mask [protocol as-number] {rpf-address | typ

   RPF checks are not the only checks that routers perform with multicast. With a static mroute, we found
   a way around the RPF checks, but routers perform another check as well, the TTL threshold check. 5/31/2005
Certification Zone - Tutorial                                                                    Page 24 of 39

   TTL (Time-To-Live) Threshold Checks
   A "TTL Threshold" can be set on multicast router interfaces to prevent the forwarding of multicast traffic
   unless the packets have a TTL greater than the TTL threshold value. To configure the TTL threshold of
   packets being forwarded out an interface, use the ip multicast ttl-threshold interface
   configuration command. When an IP packet arrives at a router, the router will perform the following TTL
   threshold checks:

     1. All incoming IP packets first have their TTL decremented by one. If the TTL value is less than or
        equal to 0, then those packets will be dropped.

     2. If a multicast packet has a TTL greater than 0, then its TTL is checked against the TTL threshold.
        If the packet's TTL is less than the specified threshold, then the packet is not forwarded out the
        interface. If the packet's TTL is greater than the TTL threshold, then the packet will be forwarded
        out the interface.

   You should only configure the TTL threshold on border routers. Note: routers set with a TTL threshold
   value automatically become border routers.

   Now that we understand what is happening with multicast at Layer 3, let's take a closer look at the
   multicast routing protocols.

   Multicast Routing Protocols
   Manual Multicast Router Configuration
   Before we move on to cover some of the dynamic multicast routing protocols, it is important to
   understand how to manually configure a router for multicast routing. Keep in mind that, in preparation
   for the CCIE lab exam, you should know every possible way of configuring something.

   One of the ways that I like to test multicast reachability in a network is to manually configure a router
   as a member of a given multicast group. I like to do this because this way the router will respond to the
   protocol being transmitted to the group if the router supports that protocol. For example, since a given
   router supports ICMP, the router will respond to ICMP echo request (i.e. PING) packets addressed to a
   multicast group if you configure the router to join that group. Just how do we configure a router
   manually to become a member of a given multicast group? We enter interface configuration mode and
   use the ip igmp join-group command. There may be other times when you want to manually
   configure the router to join a group. For example, you may have a situation where there is not a
   multicast group member on a specific network segment or a host on that network segment cannot
   report its group membership using IGMP, but you want multicast traffic to be forwarded to that
   segment. In this case, you have two different ways to make sure that multicast traffic is forwarded to
   that segment. The first method is to use the ip igmp join-group command as previously discussed,
   but you should note that when using this method, the router accepts the multicast packets in addition
   to forwarding them. There is a downside though because accepting the multicast packets prevents the
   router from fast switching them. The second way is to use the ip igmp static-group command.
   When using the static-group method, the router will not accept the multicast packets; it will only
   forward them. Unlike the first method, the second method supports fast switching of the multicast
   packets. The outgoing interface does show up in the IGMP cache, but the router itself will not be a
   member, as seen by the missing "L" (Local) flag in the multicast route entry. Configuring a router to
   support the second method is very similar to configuring the router using the first method. We just use
   a slightly different command. Here is a practical example of both methods:

   In the following example, the router joins multicast group on FastEthernet 0/0:

   Router(config)#interface FastEthernet 0/0 5/31/2005
Certification Zone - Tutorial                                                                    Page 25 of 39

   Router(config-if)#ip igmp join-group

   Next, the router is configured for multicast group on FastEthernet 1/0:

   Router(config)#interface FastEthernet 1/0
   Router(config-if)#ip igmp static-group

   Unfortunately, manual configuration does not scale well. Consequently, some dynamic multicast routing
   protocols were developed. The solution that Cisco routers use in purely Cisco networks is known as
   Protocol Independent Multicast or PIM. Cisco routers may also use DVMRP or PIM Version 2 when
   connecting to other manufacturers' routers.

   Before we can discuss the multicast routing protocol we use the most often, Protocol Independent
   Multicast (PIM), we must cover an essential concept first: the rendezvous point (RP). Although you do
   not need a rendezvous point for PIM dense mode, you do need one for PIM sparse mode, and you
   should have an RP for PIM sparse-dense mode.

   Static Rendezvous Points
   To use PIM sparse mode, one or more routers must be configured as a rendezvous point (RP). This
   should be obvious after our discussion of shared path trees because the RP is the point where the
   shared path tree starts. Suppose that you want to deploy IP multicast in a network using IP PIM sparse
   mode. You know that you need to use an RP, but you have two choices. You can use a static RP or you
   can use Auto-RP. (Auto-RP will be covered later.) With a static RP, you do not need any special
   commands to configure the router chosen to be the RP itself. This router will learn that it is the RP when
   you configure all the other routers to use it as the RP. (See the example below.) If you remember our
   discussion of shared path trees, then you will see that RPs are necessary so that senders to a multicast
   group have a central place to which to announce their existence, and so that receivers of multicast
   packets can learn about new multicast senders or sources from a central place. An RP works by having
   first hop routers directly upstream from multicast sources send PIM register messages to the RP
   address on behalf of the multicast source. The RP address is also used by having last hop routers send
   PIM join and prune messages to the RP address to inform the RP when a host has requested
   membership in a multicast group. To use a static RP, you must configure the RP address on all routers
   (including the RP router). Note: a PIM router can be an RP for more than one group, but only one RP
   address can be used at a time within a PIM domain. You can apply access lists to define for which
   groups the router is an RP. The command to configure a router with a static RP is the global command:

   Router(config)#ip PIM rp-address rp-address [access-list]

   The following example shows how to configure a router with IP PIM sparse mode using a static RP for a
   particular multicast group. Don't worry about how to configure a router for IP PIM. This will be covered
   next. Note: you do not have to use an access-list to specify the group unless you want to limit which
   groups a given RP can serve.

   ip multicast-routing
   ip PIM rp-address 1
   interface ethernet 0
   ip PIM sparse-mode
   interface ethernet 1
   ip PIM sparse-mode
   access-list 1 permit 5/31/2005
Certification Zone - Tutorial                                                                    Page 26 of 39

   Although static RPs are very easy to configure, they are not very scalable in large deployments because
   there is a large potential to make a typographical mistake with the RP address or to even forget to
   configure the RP on a particular router. A much more scalable solution is to use Auto-RP. Auto-RP is still
   easy to configure and is Cisco's recommended best practice.

   Auto-RP is a feature that automates the distribution of group-to-RP mappings in a PIM network. Auto-
   RP has a number of benefits over static RP configuration. First, using Auto-RP helps to avoid potentially
   inconsistent, manual RP configurations that can cause connectivity problems. In large, complex
   networks, Auto-RP lets you split the load between different RPs, depending on the location of the group
   participants. For example, in a recent multicast deployment, we used an RP in Europe for receivers
   located there and assigned them their own multicast group. We used a second RP in the US for
   receivers in North America. These receivers were also assigned their own multicast group. Auto-RP also
   lets you easily configure backup RPs in case the main RP fails or loses network connectivity. One
   question that you should be asking yourself is "Which router in a given network should be the RP?" The
   RP should be the router closest to the multicast source with the best network connectivity. It does not
   have to be the router directly upstream from the source. In fact, it can be any multicast router, but the
   best practice is to choose a router near the source with high redundancy and good connections.

   You may wonder what happens if you already have a static RP defined and then start to configure the
   network for Auto-RP. This is not a problem because RPs discovered dynamically through Auto-RP take
   precedence over statically configured RPs.

   Although using a static RP may seem simpler than using Auto-RP, Auto-RP is much more scalable. Think
   of a network with several hundred routers. The chances of making a typo when entering the static RP
   address or even forgetting to configure the RP on a particular router are much greater with static RPs
   than when using Auto-RP. Setting up Auto-RP is different from setting up a static RP because one
   router, usually an RP itself, is designated as the RP-mapping agent. The RP mapping agent receives RP-
   announcement messages from any other RPs and arbitrates conflicts between them such as overlapping
   group-to-RP ranges. The RP-mapping agent also sends the group-to-RP mappings to all other multicast
   routers, allowing all other multicast routers to automatically discover which RP to use for the groups
   they support. The RP mapping agent also sends the authoritative discovery packets informing other
   multicast routers which group-to-RP-mappings to use. Here is an example of the configuration. Note:
   you do not have to use an access list, but using an access list lets you use multiple mapping agents for
   different multicast group ranges. When configuring Auto-RP, you will notice the word "scope." The
   "scope" is really the TTL value. You may wonder what a reasonable TTL value is for this command. In
   most networks a scope or TTL value of 16 to 32 is more than sufficient. If you are confused by some of
   the terms like announce and mapping, be patient. These terms will be explained further when we talk
   about PIM next. It is difficult to explain PIM without understanding RPs and difficult to explain RPs
   without understanding some of the PIM signaling.

   Announce the RP and the Group Range it serves

   Router(config)#ip PIM send-rp-announce ethernet0 scope 16 group-list 1
   Router(config)#access-list 1 permit

   Assign the RP Mapping Agent

   Router(config)#ip PIM send-rp-discovery scope 16

   Although RPs are mostly easy to configure and use, there are a few situations when RPs can be
   problematic. In addition to obvious situations like placing the RP on a router where the link to the
   network is 300% oversubscribed or where CPU utilization is greater than 80% because you need a
   more robust router, there are some special cases you need to be aware of.

   Special Cases 5/31/2005
Certification Zone - Tutorial                                                                      Page 27 of 39

   As a CCIE candidate, you need to be aware of two special situations that can occur with rendezvous
   points. The first special situation is called "RP on-a-stick" by Cisco and can occur (in IOS versions prior
   to 12.0) when all members have joined a shared tree only via a single interface on the RP, and the
   source is out the same interface. When this combination occurs, the result is a special state at the RP
   because the incoming interface can never appear in the outgoing interface list of a group entry. The
   second special situation is referred to as the "Turnaround Router" problem by Cisco. The two problems
   are actually related because the "RP on-a-stick" problem is a subset of the "Turnaround Router"
   problem. The "Turnaround Router" problem occurs when there is only one branch of the shared tree,
   and the shared tree and a source path tree share a common path to the RP. This problem occurs
   because we want the multicast traffic to flow along the source path tree towards the RP, but
   "turnaround" at the appropriate router and flow back down the shared tree without sending any
   unnecessary traffic all the way to the RP.

   RP on-a-Stick

   Let's take a closer look at the "RP on-a-stick" problem and make sure you know how to recognize it. In
   the example in Figure 17, when Source 1 behind R2 begins sending to the multicast group, a
   series of signaling messages will flow from the source to the RP to register this source with the RP.
   Now, suppose that a host receiver behind R3 joins group This action will result in the
   creation of a branch of a shared path tree (as shown by the solid red arrow). After the normal register
   process, a branch of the SPT (as shown by the solid yellow arrow) is built from R2 to the RP. This allows
   traffic to flow to Receiver 1 (as shown by the blue dashed arrow). If we follow the normal rules of the
   RPF check, we can see that there is a need to send multicast traffic received on R1's Ethernet interface
   from source 1 back out the same interface to Receiver 1. This results in a violation of RPF rules, and the
   traffic would be dropped, resulting in Receiver 1 behind R3 not receiving the multicast traffic.
   Obviously, something else must be done to prevent this. The solution to this problem is to upgrade IOS
   to version 12.0 or later. A detailed discussion of how this upgrade solves the problem is beyond the
   scope of this paper, but with IOS 12.0, the PIM implementation was modified to include some new
   concepts, including atomic joins and non-atomic joins, the proxy join timer, and header-only registers.
   If you want to learn more, research these terms on CCO.

                                           Figure 17. RP on a Stick

   Earlier, we learned that the "RP on-a-stick" problem is actually a subset of the "turnaround router"
   problem, so let's take a closer look at the "turnaround router" problem and make sure you know how to
   recognize it. Again, this problem is solved with IOS version 12.0 or greater, but remains in older IOS

   Turnaround Router 5/31/2005
Certification Zone - Tutorial                                                                   Page 28 of 39

   The "turnaround router" problem occurs when there is only one branch of the shared path tree, and the
   shared path tree and SPT share a common path to the RP. This problem arose because there is no need
   to send multicast traffic all the way to the RP just to have the RP "turnaround" the traffic and send it
   back. Although this may not seem like much of a problem in a small network or a lab environment, in
   larger networks where there are many hops between the turnaround router and the RP or where the
   links along this path have limited bandwidth available, the flow of traffic to and from the RP can
   consume significant network bandwidth. For example, I had a customer whose company had a 512K
   frame-relay link from San Jose to India. Imagine the wasted bandwidth to transmit a 128K video
   conferencing stream for in-country traffic if the RP was located in the other country. IOS 12.0 uses the
   same concepts discussed earlier with the "RP on-a-stick" problem to solve this "turnaround router"
   problem, including both atomic and non-atomic joins, header-only registers, and the proxy join timer. A
   detailed discussion of each of these new concepts is beyond the scope of this paper, but you can find a
   more detailed explanation in documentation at Cisco's web site by searching for "turnaround router."
   Let's look at an example to make sure you can recognize a "turnaround router" situation. See Figure

                                      Figure 18. Turnaround Router

   In this example, we again have a single branch of the shared path tree at the RP. The source
   path tree for Source 1 merges with the single branch of the shared path tree at R4. R4 is
   known as the "turnaround router" because we want the multicast traffic for group to turn
   around here and flow back down the shared path tree to Receiver 1 located behind R3. The dashed blue
   arrows in the drawing represent the desired traffic flow. Again, the solution to the "turnaround router"
   problem is to upgrade to IOS 12.0 or greater. Now that we have examined some special problems you
   might see with RPs, let's look at IP PIM itself.

   PIM Dense Mode
   PIM stands for Protocol Independent Multicast and is the major multicast routing protocol on Cisco
   routers. PIM uses two different models: dense mode and sparse mode. It is critically important that you
   understand both modes. Some very important things happen when you configure an interface for PIM.
   When you enable PIM on a given LAN interface, you also enable IGMP operation on that interface if it is
   an Ethernet/Fast Ethernet/Gigabit Ethernet interface. Remember that IGMP is used to communicate
   between hosts and routers, not between routers themselves. Router-to-router communication uses PIM.

   With PIM dense mode, we, in essence, configure the router to use a client push model for multicast 5/31/2005
Certification Zone - Tutorial                                                                     Page 29 of 39

   packets. When a router configured for PIM dense mode receives a multicast packet, the router will
   automatically send the packet out all other dense mode interfaces until the router receives prune
   messages from subnets with no multicast receivers. These prune messages take time, however,
   resulting in unwanted multicast traffic consuming bandwidth in network segments that do not need to
   receive the multicast traffic. You may wonder how long it takes to prune back multicast traffic. This
   flood and prune process occurs every three minutes.

   There is no default PIM mode setting of either sparse mode or dense mode. By default, multicast
   routing is disabled on every interface. You must specifically enable the mode of choice on each desired
   interface. To configure PIM dense mode on an interface, just use the ip pim dense-mode command in
   interface configuration mode. Keep in mind as you prepare for the CCIE lab exam that the exam tends
   to be very specific about what you cannot do, but very general about what you can do. As a CCIE
   candidate, you can use this to your advantage. Suppose you were given a task that required you to
   configure multicast. If you are not prohibited from using dense mode, then this is the easiest way to
   configure multicast because all you have to do is enable multicast routing in global configuration mode
   and configure each active interface for PIM dense mode, using the command above, and you are done.
   Keep in mind in a lab situation that real world considerations may not apply. After all, there is unlikely
   to be enough traffic on a lab network that using one PIM mode vs. another is going to make a
   difference. Please also keep in mind that any topic in IOS is fair game. This paper was not written
   because multicast will definitely be on your exam. This paper was written because multicast can be a
   topic on any given exam. Now that we have looked at PIM dense mode, let's take a closer look at IP
   PIM sparse mode.

   PIM Sparse Mode (RFC 2362)
   Although we briefly mentioned the fact that PIM sparse is different from PIM dense mode, let's take a
   more detailed look at PIM sparse mode to see why. PIM sparse mode differs from PIM dense mode in a
   number of important ways. First, sparse mode uses a client pull model. This means that traffic is only
   sent out a given interface when that interface is configured for sparse mode and there is a client
   downstream of that interface that wishes to receive the multicast traffic. You should be asking yourself
   "Yes, but how does the router know that there is a client downstream who wants to receive the
   multicast traffic?" If you remember the previous discussion of IGMP, then the answer, of course, is that
   the client downstream must explicitly join each multicast group of interest using IGMP.

   With IOS 12.0, we now have full support for PIM Version 2. Keep in mind that PIM Version 2 is what
   you want to use, especially if you have to connect to non-Cisco routers. It is very likely that a non-Cisco
   router will only support PIM Version 2. PIM Version 2 differs from PIM Version 1 in the following ways:

         PIM packets are no longer inside IGMP packets; PIM Version 2 packets are standalone packets.

         PIM Version 2 only uses one active RP for each multicast group; however, you can have multiple
         backup RPs. PIM Version 1 allowed for multiple active RPs for the same group. The active RP for
         PIM Version 2 is chosen based on which router configured as an RP for a given multicast group
         has the highest IP address. You can use loopback interfaces to manipulate this choice.

         PIM Version 1 only supported sparse mode or dense mode. PIM Version 2 supports a "sparse-
         dense" mode. This allows both sparse mode and dense mode properties to be assigned to a
         multicast group rather than to an interface as with PIM Version 1. According to Cisco, the best
         practice when setting up multicast is always to use sparse-dense mode and IOS 12.0 or greater.

         PIM Version 2 Register messages to an RP indicate whether they were sent by a border router or
         by a designated router. A border router is a router on the boundary between one autonomous
         system and another. This router defines the edge of the multicast domain. A designated router is
         used in multiple access networks like an Ethernet subnet for multicast in much the same way you
         see a designated router used with a routing protocol such as OSPF. A designated router is elected
         and handles signaling traffic for the subnet. 5/31/2005
Certification Zone - Tutorial                                                                     Page 30 of 39

         PIM Version 2 has a bootstrap router (BSR) functionality to provide for fault-tolerant, automated
         RP discovery and an automated group-to-RP mappings distribution mechanism.

         PIM Version 2 join and prune messages have more flexible encoding for multiple address

         An enhanced PIM Version 2 hello packet format replaces the PIM Version 1 query packet to allow
         for the encoding of both current and future capability options.

   IOS 12.0 PIM Version 2 is backwards compatible with PIM Version 1 so that networks can transition
   smoothly from Version 1 to Version 2. PIM Versions 1 and 2 can be configured on different routers
   within one network, but routers on a given segment must run the same PIM version. Suppose that you
   had an Ethernet segment with multiple routers attached to it. Suppose that some of the routers were
   configured to support PIM Version 1 and others were configured to support PIM Version 2. You would
   need to either upgrade the PIM Version 1 routers with a newer IOS that supports PIM Version 2, or you
   would need to manually configure the PIM Version 2 routers to use PIM Version 1.

   Let's look at how we configure the network for PIM sparse mode and PIM sparse-dense mode. The basic
   configuration on a per-interface basis is the same as for PIM dense mode except that you use the key
   word "sparse" instead of "dense." Don't forget that you first need to enable multicast routing using the
   ip multicast-routing global command. If you are going to use Auto-RP, then no further
   configuration needs to be done except for the RP router itself. Refer to the detailed Auto-RP
   configuration discussed earlier in the paper. Remember that if you are going to use a fixed RP, then you
   will also need to specify the RP router. Here is an example using PIM sparse mode and a static RP:

   ip multicast-routing
   ip PIM rp-address 1
   interface ethernet 0/0
    ip PIM sparse-mode

   Since PIM dense mode is very different from PIM sparse mode, let's take a look at how the two

   PIM Dense Mode vs. PIM Sparse Mode, A Comparison
   In our earlier discussion of distribution trees, we talked about two different types: source distribution
   trees and shared distribution trees. With PIM dense mode, you have a source distribution tree. With PIM
   sparse mode, you actually use both. There will be a source distribution tree constructed from the source
   to the rendezvous point (RP) and a shared distribution tree constructed from the RP to the client
   receiver of the multicast traffic. PIM dense mode and PIM sparse mode also populate their multicast
   routing tables differently. For example, with PIM dense mode, all dense-mode interfaces are
   automatically added to the multicast routing table. With PIM sparse mode, however, interfaces are only
   added to the multicast routing table when periodic join messages are received from downstream
   routers, or when there is a directly connected source or receiver on the interface configured for sparse
   mode. We already examined how sparse mode works with a client receiver, but how does sparse mode
   work with a multicast source? Suppose that we are looking at the router directly upstream from a
   multicast source. When multicast traffic is received on a router directly upstream from a multicast
   source, and that router knows the RP for the multicast group that the source is using, the router sends
   the traffic toward the RP. On the other hand, if no RP is known for the multicast group that the source
   is using, the packet will be flooded out all interfaces configured for PIM in a dense-mode fashion. PIM
   sparse mode has the ability to switch back to the shortest path tree for the final hop between a source
   and its directly upstream router if the traffic is high enough to exceed the SPT-Threshold. Note that the
   default value for the SPT-Threshold in Cisco routers is zero so that the default behavior of Cisco routers
   configured for PIM sparse mode and attached to receivers is to immediately join the source path tree to
   the source as soon as the first packet arrives at this router via the (*,G) shared path tree instead of via
   the (S,G) source path tree. Now that we have covered PIM dense mode and PIM sparse mode, let's look
   at the hybrid mode that uses both. It is known as sparse-dense mode. This is the mode you really 5/31/2005
Certification Zone - Tutorial                                                                    Page 31 of 39

   should be using on a daily basis in a real network.

   PIM Sparse-Dense Mode
   If you configure either just ip pim sparse-mode or just ip pim dense-mode in interface
   configuration command, sparseness or denseness is applied to just the configured interface as a whole.
   Sparse-dense mode is different because, with sparse-dense mode, the interface is treated as dense
   mode if the group is in dense mode or as sparse mode if the group is in sparse mode. Note that you
   must have an RP (defined either manually or via auto-RP) if the interface is in sparse-dense mode and
   you want to treat the group as a sparse group. Another reason to use sparse-dense mode is that Auto-
   RP information can be distributed using dense mode manner; yet, multicast traffic for hosts can be sent
   in a sparse mode manner. In the example below, the router is configured to use sparse-dense mode
   with auto-RP. This is the best implementation practice according to Cisco. The scalability advantages
   should be obvious.

   ip multicast-routing
   interface ethernet 0/0
    ip PIM sparse-dense-mode

   Although IP PIM is the multicast routing protocol used most often with Cisco routers, you will also see
   DVMRP (Distance Vector Multicast Routing Protocol). DVMRP is used when you need to connect a Cisco
   router to a non-Cisco router for IP multicast. The most common reason for this is to connect to the
   MBONE over the Internet. Note that this does not mean that you must use DVMRP to connect to non-
   Cisco routers. For example, you might very well use PIM Version 2.

   The Distance Vector Multicast Routing Protocol is very similar to RIP except that, with DVMRP, infinity is
   defined as 32 hops instead of 16. DVMRP also uses a dense mode model similar to IP PIM dense mode.
   DVMRP is similar to RIP version 2 because DVMRP transmits subnet mask information in route
   advertisements. DVMRP is very different from other IP multicast protocols because there does not need
   to be an underlying unicast routing protocol such as RIP, EIGRP, or OSPF. Even though other
   manufacturers such as Extreme fully support DVMRP, Cisco's support for DVMRP is limited in
   connections with other manufacturers' routers. Since DVMRP in IOS only supports interconnectivity with
   non-Cisco routers, this topic is beyond the scope of both the CCIE exams and this paper.

   MOSPF is documented in RFC 1584 and is currently at "proposed standard" status. MOSPF has some
   major problems, however. These problems are significant enough that even the author, J. Moy, as well
   as the members of the IETF IDMR working group, cannot recommend that MOSPF be named a standard
   for IP multicasting until/unless these scalability problems can be overcome. For these reasons, MOSPF
   is not commonly used and is not supported at all by Cisco's IOS. Since OSPF scales fairly well for
   normal routing, you may wonder just what scaling problems arise with MOSPF.

   There are several reasons for the scaling problems with MOSPF. First, OSPF must be the underlying
   routing protocol. Secondly, with MOSPF, the Dijkstra algorithm must be run for every (S,G) pair.
   Thirdly, the Dijkstra algorithm must be rerun every time multicast group membership changes. A fourth
   factor limiting scalability with MOSPF is that it does not support shared trees. When you consider how
   often the Dijkstra algorithm must be run for the reasons above as well as when links flap, it should be
   obvious that MOSPF is both extremely memory and CPU-intensive, and thus, does not scale well.

   CBT 5/31/2005
Certification Zone - Tutorial                                                                      Page 32 of 39

   CBTs or Core Based Trees are discussed in an Internet draft and currently have no commercial
   implementation. The future for Core Based Trees does not appear to be very good because Core Based
   Trees have already gone through three separate and incompatible revisions. In addition, CBTs are not a
   focus of the IETF IDMR working group. CBTs were pursued because they do have some advantages.
   They have increased scalability and improved efficiency. CBTs use a sparse model with shared delivery
   trees, constructed using the concept of a core router in much the same fashion as an IP PIM sparse
   mode RP router. One of the advantages that Core Based Trees have over IP PIM sparse mode is that
   CBTs use a bi-directional shared path tree model. One of the disadvantages that Core Based Trees have
   compared to IP PIM sparse mode is that CBTs do not have the ability to switch to a shared path tree
   model. The result is increased latency in the network since all traffic must first be unicast from the
   source to the core router, and then multicast by the core router. This problem can become significant
   when the multicast source and receiver are far apart. IOS does not have any type of CBT

   Advanced IP Multicast Topics
   Multiprotocol BGP
   Multiprotocol BGP (see RFC 2283, Multiprotocol Extensions for BGP-4) was designed to solve some of
   the limitations of BGP. MBGP contains enhancements to BGP that let BGP communicate routing
   information for multiple network layer protocols and IP multicast routes. BGP carries two sets of routes,
   one set for unicast routing and one set for multicast routing. Multiprotocol BGP is sometimes,
   mistakenly, called multicast BGP, but this is incorrect. MBGP merely makes use of multicast. MBGP was
   designed to solve the problem of wanting to have a unicast routing topology different from the
   multicast routing topology. Prior to MBGP, this was very problematic because multicast is dependent on
   the underlying unicast route table. Some instances where MBGP might be useful are when you want a
   link dedicated to multicast traffic. For example, you might want to send all external multicast traffic to a
   single network access point (NAP). With traditional BGP4, the only way to perform interdomain
   multicast routing was to use the BGP unicast routing topology. If the BGP-speaking routers were not
   multicast-capable or had policy conflicts with neighbors, interdomain multicast routing could not be
   supported. With MBGP, however, the situation is much improved and these problems are resolved.
   MBGP gives engineers more control over their traffic. A detailed description of MBGP is beyond the
   scope of this paper. MBGP is complex enough that you might even see a future CertificationZone Study
   Guide devoted to just this topic.

   As the Internet and applications develop, there will clearly be a need to support robust multicast not
   just within a single domain but between domains. One of the ways of doing this is to use Multicast
   Source Discovery Protocol or MSDP.

   Multicast Source Discovery Protocol (MSDP)
   MSDP was developed to provide a better way to connect multiple Protocol Independent Multicast sparse
   mode domains. MSDP functions by making all rendezvous points (RPs) in different domains aware of
   multicast groups known to RPs in each domain. In this way, each domain uses its own RPs and does not
   have to use RPs in other domains. Note that MSDP runs only between the RPs in each domain rather
   than on every multicast router. MSDP RPs also use TCP to discover multicast sources in other domains.

   An MSDP-enabled RP in a PIM sparse mode domain forms an MSDP peering relationship with MSDP-
   enabled RP routers in other domains. MSDP works by using this peering relationship over a TCP
   connection to exchange a list of sources and their associated multicast groups. The TCP connections
   between RPs are built using the underlying unicast routes in the same way you might see with BGP
   routers. The receiving RP uses the source lists to establish a source path. MSDP is also used to
   announce new sources and multicast groups. Since MSDP is heavily dependent on BGP or MBGP for
   interdomain operation, Cisco recommends that you run MSDP on RPs in your domain that are RPs for
   sources sending to global groups you want announced to the Internet. You do not have to run MSDP on
   every RP, just on the RPs that you want to send global groups to the Internet. 5/31/2005
Certification Zone - Tutorial                                                                    Page 33 of 39

   Now that we have examined the basic theory and configurations for IP multicast, let's look at the best
   tools and strategies for troubleshooting IP multicast. It is imperative that you have a strong mastery of
   troubleshooting to be able to handle the pressure and challenges of the lab. You do not have time to
   research and plan during the lab itself. You must have a plan before you walk in the door for just how
   you are going to handle any troubleshooting situations that arise.

   Troubleshooting IP Multicast
   Show Commands
   Troubleshooting IP multicast requires standard troubleshooting methods similar to those you would use
   to troubleshoot a unicast problem. The difference is in the tools used. For example, suppose that you
   were troubleshooting a unicast routing problem over an ISDN connection. You would focus your
   troubleshooting on two areas: signaling and packet flow. You would look at each of these two areas at
   both the source and destination as well as in the middle. Only when each of these two areas is working
   correctly from end to end, will your ISDN unicast connection work properly. The same principles apply
   with multicast. If the multicast source never initiates a multicast session, then the other pieces will
   never work. If there is a configuration problem on the receiver or the receiver's upstream router (e.g.,
   that multicasting is not enabled on the router), then multicast will not work. Troubleshooting should be
   progressive, starting with the source, next the network, and, finally, the destination. You should work
   layer-by-layer using the OSI model. What is the point of troubleshooting a Layer 3 routing problem
   when your Layer 2 frame-relay is not up? Let's look at some of the tools available for troubleshooting IP

   show ip igmp group can be used to verify which multicast groups are actively joined. Here is some
   sample output.

   router#show ip     igmp groups
   IGMP Connected     Group Membership
   Group Address      Interface Uptime         Expires      Last Reporter          Ethernet1 3d16h          00:01:59         Ethernet0 4d15h          never

   show ip igmp interface can be used to verify that IGMP and CGMP are enabled or disabled on an
   interface. You can also verify which IGMP version is in use. This command will also tell you when there
   is a multicast Designated Router (DR) and which router is the IGMP querier in a case where a DR is
   necessary. You can also examine the current settings for IGMP timers in case you want to adjust them
   for tuning purposes. Here is some sample output:

   router#show ip igmp interface
   FastEthernet0/0 is up, line protocol is up
   Internet address is, subnet mask is
   IGMP is enabled on interface
   Current IGMP version is 2
   CGMP is enabled 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
   Multicast routing is enabled on interface
   Multicast TTL threshold is 0
   Multicast designated router (DR) is (this system)
   IGMP querying router is (this system)
   No multicast groups joined

   show ip pim neighbor is great for making sure that your routers see all PIM neighbors. You can spot 5/31/2005
Certification Zone - Tutorial                                                                     Page 34 of 39

   any PIM problems easily using this command. It is also a handy command for verifying that your
   neighbors are in the correct PIM mode. Here is some sample output:

   router#show ip pim neighbor
   PIM Neighbor Table
   Neighbor Address Interface                    Uptime    Expires       Mode         Serial0/0                  2d12h     00:00:19      Dense         Serial0/1                  2d12h     00:00:19      Dense         FastEthernet0/0            3d11h     00:00:43      Sparse

   show ip pim interface can be used to determine how many neighbors an interface has, what the
   query time interval is, what PIM mode a given interface is using, and if there is a DR present. Note: an
   entry of for the DR means that there is no DR for that interface. You will see this especially with
   point-to-point serial interfaces. Here is some sample output:

   router#show ip pim interface
   Address     Interface        Mode              Nbr      Query    DR
                                                  Count    Intvl     Serial0/0              Dense    1        30     Serial0/1              Dense    1        30     FastEthernet0/0        Dense    1        30

   show ip rpf gets reverse path forwarding information. Here is an example:

   router#show ip rpf
   RPF information for router2 (
     RPF interface: FastEthernet0/0
     RPF neighbor: router3 (
     RPF route/mask:
     RPF type: unicast

   show ip mroute and show ip mroute summary -- Don't forget that multicast routing tables depend
   on the underlying unicast routing table. You must make sure that you do not have any unicast routing
   problems before you even begin to troubleshoot any sort of multicast routing table problems. Here is
   some sample output for both commands. Note the (*,G) and (S,G) entries as well as the incoming and
   outgoing interfaces, RPs, and Flags:

   router#show ip mroute
   IP Multicast Routing Table
   Flags: D - Dense, S - Sparse, C - Connected, L - Local,                  P - Pruned
   R - RP-bit set, F - Register flag, T - SPT-bit set, J -                  Join SPT
   Timers: Uptime/Expires
   Interface state: Interface, Next-Hop, State/Mode
   (*,, 00:12:22/00:01:48, RP, flags:                  D
   Incoming interface: Null, RPF nbr
   Outgoing interface list:
   FastEthernet1/0, Forward/Dense, 00:10:21/00:01:59
   Serial1/0, Forward/Dense, 00:19:53/00:00:00
   (,, 00:19:53/00:03:01, flags:                  T
   Incoming interface: Serial1/0, RPF nbr
   Outgoing interface list:
   FastEthernet1/0, Forward/Dense, 00:17:15/00:03:38
   (*,, 05:23:09/00:02:59, RP,                  flags: DP
   Incoming interface: Null, RPF nbr
   Outgoing interface list: Null

   router#show ip mroute summary
   IP Multicast Routing Table 5/31/2005
Certification Zone - Tutorial                                                                  Page 35 of 39

   Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
   R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
   Timers: Uptime/Expires
   Interface state: Interface, Next-Hop, State/Mode

   (*,, 00:01:47/00:02:51, RP, flags: D
   (,, 00:01:49/00:02:09, flags: CT

   (*,, 2d12h/00:00:00, RP, flags: DCL

   show ip pim rp displays information on the RP. Don't forget that, in complex multicast
   implementations, you can have multiple RPs. Different RPs can be used for different multicast group
   ranges. This command will only display active rendezvous points (RPs) that are cached with associated
   multicast routing entries. Here is some sample output:

   router#show ip pim rp
   Group:, RP:, uptime 2d12h, expires 00:02:28
   Group:, RP:, uptime 2d12h, expires 00:02:28

   show ip pim rp mapping , a more specific form of the command above, is useful because it shows
   all group-to-RP mappings of which the router is aware (either configured or learned from Auto-RP).

   Debug Commands
   As you can see, there are some very useful show commands. As a CCIE candidate, you should go
   through the configuration guides and command references for every routing protocol and make sure
   that you are familiar with what information each command gives you. You will not have time in the lab
   to hunt for the right command. You need to have already ingrained in your mind which command to use
   to get the information you need. Remember too that the show commands are just one of your tools.
   The debug commands provide you with another set of powerful tools. Use both sets of commands not
   just for troubleshooting, but for verification as well. Practice checking your work using the show and
   debug commands so that you can be confident that your configuration is correct and not waste valuable
   time due to uncertainty.

   debug ip igmp -- Use this command to see which version of IGMP the clients are using as well as to
   make sure you are sending queries and what the query interval is. Here is some sample output:

   router# debug ip igmp
   IGMP: Send v2 Query on Ethernet1 to
   IGMP: Received v2 Report from (Ethernet1) for
   IGMP: Received v2 Query from (Ethernet0)
   IGMP: Set report delay time to 2.2 seconds for on Ethernet0
   IGMP: Send v2 Report for on Ethernet0
   IGMP: Received v2 Report from (Ethernet0) for
   IGMP: Received v2 Report from (Ethernet0) for

   debug ip pim -- Use this command to observe periodic query messages and PIM neighbor
   adjacencies. Here is some sample output:

   router# debug ip pim
   PIM: Send Router-Query on FastEthernet0/0
   PIM: Send Router-Query on FastEthernet0/1
   PIM: Received Router-Query on FastEthernet0/0 from

   Here is some more output. Notice that this router sends periodic joins to the RP. The RP then sends
   back an RP-Reachable message: 5/31/2005
Certification Zone - Tutorial                                                                 Page 36 of 39

   router# debug ip pim
   PIM: Building Join/Prune message for
   PIM: For RP, Join-list:, RP-bit, WC-bit
   PIM: Send periodic Join/Prune to RP via (Ethernet0)
   PIM: Received RP-Reachable on Ethernet0 from
   for group
   PIM: Update RP expiration timer (270 sec) for

   Here is the corresponding output from the RP:

   RP# debug ip pim
   PIM: Received Join/Prune on Serial0/0 from
   PIM: Join-list: (*, RP, RP-bit set, S-bit set
   PIM: Add Serial0/0/ to (*,, Forward state
   PIM: Received Join/Prune on Serial0/0 from
   PIM: Building Join/Prune message for
   PIM: Send RP-reachability for on RP#
   PIM: Received Join/Prune on Serial0 from
   PIM: Join-list: (*, RP, RP-bit set, S-bit set
   PIM: Add Serial0/0/ to (*,, Forward state
   PIM: Received Join/Prune on Serial0 from
   PIM: Building Join/Prune message for
   PIM: Send RP-reachability for on Serial0/0

   debug ip mroute -- Use this command to observe multicast routing table maintenance. Here is some
   sample output:

   router# debug ip mrout
   MRT: Create (*,, RPF Null, PC 0x6032D254
   MRT: Create (,, RPF Ethernet1/, PC x6032D378

   Although the show command and the debug command are powerful tools for troubleshooting in
   general, don't forget that there are some other useful troubleshooting tools available.

   Other Useful Commands
   mtrace can be an extremely useful command because it lets you see where multicast traffic stops and
   helps to identify sub-optimal paths. mtrace is based on the Unix mtrace command and works in a very
   similar fashion to the trace command. mtrace uses special IGMP packets with type codes of 0x1E
   (response) and 0x1F (queries).

   mstat is also a very useful command because it shows the multicast traffic path in a semi-graphical
   format allowing you to trace the path between any two points on the network and shows TTL and Delay
   at each hop. You can use the mstat command to find congestion in the network and routing problems
   by looking for a high drop/duplicate count. Here is some sample output from the mstat command:

   Source address or name:
   Destination address or name:
   Group address or name:
   Multicast request TTL [64]:
   Response address for mtrace:
   Type escape sequence to abort.
   Mtrace from to via group
   From source (?) to destination (?)
   Waiting to accumulate statistics......
   Results after 10 seconds: 5/31/2005
Certification Zone - Tutorial                                                                     Page 37 of 39

     Source           Response Dest     Packet Statistics For                  Only For Traffic     All Multicast Traffic                  From
        |          __/ rtt 7      ms   Lost/Sent = Pct Rate                   To
        v        /      hop 6     ms   ---------------------                  --------------------        ?
        |      ^        ttl   0
        v      |        hop 0     ms    -3/0 = --%      0 pps                  0/0 = --%     0 pps        ? Prune sent upstream
        |        \__    ttl   1
        v            \ hop 1      ms        0         0 pps                          0      0 pps
     Receiver         Query Source

   mrinfo is used to query a neighboring router about its multicast information. Here is some sample

   router>mrinfo routerberwyn-gw ( [version cisco 11.3] [flags: PMSA]: -> [1/0/PIM/querier/leaf] -> [1/0/PIM/querier/leaf] -> ( [1/0/PIM]

   ping is very useful for testing multicast connectivity. You can ping a multicast group just like you can a
   normal IP address. Here is an example:

   Type escape sequence to abort.
   Sending 1, 100-byte ICMP Echos to, timeout is 2 seconds:
   Reply to request 0 from, 15 ms
   Reply to request 0 from, 19 ms

   Caching IP multicast packet headers

   You can see (S, G) traffic pairs, IP ident and ttl, and Inter-packet delay using the ip multicast
   cache-headers and show ip mpacket source group [detail] commands. This can be very
   helpful when troubleshooting because you can see detailed information. For example, suppose that you
   have a rather large network. You may find that the RP is not setting a TTL value high enough to reach
   all distant routers. Suppose that you set the scope on an RP to 16 using ip pim send-rp-announce
   ethernet0 scope 16 and ip PIM send-rp-discovery scope 16. By examining the cached
   multicast headers on some distant routers, you would be able to see that the scope needs to be
   increased to 32 for the multicast packets to reach all routers in the network. In the same way, you
   could check the TTL values on border routers to see what TTL value is needed to prevent multicast
   packets from leaving your own autonomous system. Is this a big deal? It depends on what your
   application is. It may not be a big deal if your application is an Internet radio station, but what if you
   are using a hoot and holler voice over IP application using multicast so that your securities traders can
   talk trading strategy for the firm in a permanent conference call?

   Debugging Strategy
   As a CCIE, you will bring several valuable benefits to your employer. One of those benefits is that you
   will know what tools to use in a given situation. It doesn't matter whether the tool is a debug
   command, a show command, or some other command. As a CCIE, you need to know what tools to use
   and even when to use an external tool such as a sniffer trace. For example, on a recent consulting
   assignment at a Fortune 100 firm, we implemented multicast on the firm's global network. Once the
   networking team had completed the initial multicast configuration on all routers and switches, problems
   developed when we tried to test the live video feed with the server team. The internetworking team 5/31/2005
Certification Zone - Tutorial                                                                      Page 38 of 39

   was able to demonstrate using debug and show commands that multicast was working properly in the
   network, but the high-level management team of the client was still skeptical. It wasn't until the
   Internetworking team recorded a sniffer trace and showed the failed application transaction from the
   video server that we were able to prove that the problem was server related and not network related. It
   turned out that the video server application had a bug in it and needed to be upgraded with a fix. As a
   CCIE, I knew what tools to use both to pinpoint and to fix the problem. This saved both valuable time
   and money for the client. Sometimes, however, you simply won't know every tool or how to use every
   tool. Another very valuable skill you need to develop, as a CCIE, is how to research an issue. You need
   to know where to go to find that relevant RFC, where the IP multicast section of IOS documentation is
   or where to find the documentation on a command with an example. If you don't know how to do these
   things yet, then you are not ready to take your CCIE lab exam. You should know exactly where to find
   every topic you might possibly have on the exam by going directly to it in the documentation. If you
   have to use the search engine on the documentation CD, then you are not ready for the lab exam.
   Study until you learn what the tools are, what output you should expect with each tool, and where to
   find more information. Once you have learned these things, then you are ready to develop and learn a
   solid debugging strategy.

   Earlier, we briefly discussed the need to troubleshoot methodically using an OSI model layer-by-layer
   approach to troubleshoot two different areas, packet flow and signaling.

   Let's start with packet flow and see some further examples of what show/debug/other command tools
   we can use to verify packet flow. A good strategy would be to use interface counters to see if the
   interface thinks it is sending packets. Next, you might want to check the next upstream router to see if
   it is receiving multicast packets from the source's router using the show ip mroute command. You
   could also use the debug ip mpacket command, but use caution! If you do this on a production
   router, you will want to use an access list to limit the traffic or you could end up having to reload the
   router because there is so much output you won't be able to issue the no debug ip mpacket
   command. Continue this process with each hop until you can verify end-to-end packet flow. Once you
   have verified packet flow, it is time to troubleshoot signaling.

   Troubleshooting signaling is much more difficult than
                                                                    Hint: You will have results that are much
   troubleshooting basic packet flow because you have to
                                                                    more consistent if you use PIM version 2
   verify the basic functionality of IP multicast including things
                                                                    and IGMP version 2 with an IOS that is
   like the initial flow creation, pruning, timer expirations, etc.
                                                                    at least version 12.0(x). You will also
   Use a similar methodology to the one we used to
                                                                    need at least an IP Plus version of IOS. A
   troubleshoot packet flow. Start with the source and work
                                                                    1605 with just an IP version of IOS will
   your way, hop by hop, to the destination. Use the
                                                                    not work.
   show/debug ip igmp and show/debug ip pim
   commands to check that the correct versions of IGMP and PIM are being used. Use the show ip pim
   rp mapping command to check that each router has the correct RP. Use the show/debug ip mroute
   commands and the mtrace command to verify, hop by hop, that each router is working correctly in
   terms of signaling.

   IP multicast is only going to grow in importance. Just as the 1993 bombing of the World Trade Center
   taught Wall Street firms of the need for redundancy and disaster recovery plans, the disaster on 11
   September 2001 has taught everyone that we must be prepared to operate and communicate in
   environments where person-to-person meetings may not be possible. As a NYC resident, I observed an
   instant growth in video conferencing following the disaster. It is clear that video conferencing is going
   to undergo tremendous growth as an application this year. It is also clear that this growth is going to
   require that video conferencing supports IP multicast because of the unprecedented traffic requirements
   this growth is going to place on networks. Other applications are going to grow as well, such as using
   hoot and holler for voice over IP multicast phone conferencing on trading floors. I believe that we may
   soon see the ability to log onto the web and subscribe to a multicast of the NFL or MLB game of your
   choice. Clearly, unicast streams will not be able to support the traffic loads this type of application will
   place on the Internet. Multicast is going to become a necessity. Multicast implementation at the truly 5/31/2005
Certification Zone - Tutorial                                                                 Page 39 of 39

   advanced level is undergoing tremendous change and development. To understand and follow these
   developments, however, you must begin with the roots of multicast. This paper has, hopefully, provided
   you with a brief synopsis of these roots.

   Cisco Routers for IP Routing: Little Black Book by Innokenty Rudenko


   Change History
   2004-03-01: corrected "Glop Address" to "Global Address" in headings and links 5/31/2005

To top