<PARA><DROPCAP>T</DROPCAP>his chapter will cover the steps and syntax for configuring IP multicast on Cisco routers and switches. There will be several new commands seen in this chapter. Learning about multicast and actually getting it working on a network are two different things. By the time you finish this chapter, questions, and lab, you will be thoroughly familiar with multicast and its implementation. Pay attention to small details that would normally seem unimportant. They are usually the key to a successful implementation of an IP multicast network.</PARA>
<PARA>First you will need to understand how to deploy an IP multicast network. Once you have a plan in place, you can move on to actually configuring equipment. Not only do the routers have to be IP multicast enabled, but you must enable a multicast protocol on every interface that you want to be able to forward multicast traffic.</PARA>
<PARA>An IP multicast network won't work too well without a couple of (or at least one) rendezvous points (RPs), so you'll have to configure them as well. Then, in order to keep your multicast local to the enterprise network, you'll need to configure the Time to Live (TTL) thresholds on your external interfaces.</PARA>
<PARA>After the routers have been configured, you can concentrate on the hosts. Of course, we won't discuss host configuration in this chapter, but we will get down and enable Cisco Group Management Protocol (CGMP) on the routers and switches, so once the hosts are configured, the network will be available.</PARA>
<SECTION ID="10.1"><TITLE>Planning and Preparing for Using IP Multicast</TITLE>
<PARA><DROPCAP>A</DROPCAP>s you learned in <NOBR REF="9">Chapter 9</NOBR>, multicast networks behave differently than unicast networks. It is important to keep this in mind when planning the deployment of an IP multicast network. There are several factors that should be taken into consideration, including bandwidth implications, multicast applications, application requirements, user requirements, the location of the recipients, required equipment, cost, and most importantly, what multi- cast source(s) will be used.</PARA>
<PARA>All of these factors require attention and planning for a successful deployment of IP multicast throughout the network. You must also think upside down when thinking about multicast routing. As was discussed in the preceding chapter, distribution trees are built based on the position of the root (source) of the tree. Therefore, when planning the routing for the multicast network, you must know where your sources or RPs will be located.</PARA>
<PARA>By taking the time to plan and prepare for a multicast deployment, you will avoid headaches later on. You must become familiar with the customer's requirements as well as the impact multicast will have on the existing network.</PARA>
<PARA>There are many methods of implementing multicast on a network. Commonly, institutions will want to connect with the Multicast Backbone (MBONE) multicast sessions; therefore, they must implement multicast through a Distance Vector Multicast Routing Protocol (DVMRP) tunnel or with Multicast Border Gateway Protocol (MBGP). If the multicast source is within the network and meant to stay within the confines of the network, other design issues come into play. It is important that you understand what each multicast routing protocol brings to the table when it comes to operational functionality.</PARA>
<PARA>By better understanding the many protocols and possible implementations of multicast, you will be able to better plan and prepare for its deployment. With so many options, there is bound to be a solution for almost any requirement. Through understanding requirements, and through preparing and planning, you can successfully implement an IP multicast network.</PARA>
<SECTION ID="10.1.1" POS="1"><TITLE>End-to-End IP Multicast</TITLE>
<PARA>Part of deploying multicast is the determination of how much of the network should be multicast enabled. This is an important decision because it directly affects many aspects of multicast implementation. To strategically place the <KEYTERM>rendezvous points (RPs)</KEYTERM>, you must know where all of the multicast leaf routers will be. Knowing an approximate number of potential multicast subscribers can have an impact on which protocols are run in the network to allow efficient multicast forwarding and routing. </PARA>
<PARA>The decision to use end-to-end deployment can be based on the applications that will be used or the intent of multicast implementation. If you are enabling multicast for a corporate application, you would need to enable multicast on every interface on every router throughout the enterprise. However, if you need to provide access to only the MBONE for the engineering department, or some other department within the organization, perhaps the most efficient method would not include end-to-end configuration and deployment. </PARA>
<PARA>It is important to keep in mind that the state of technology is dynamic. Today, you might receive a request from a single department for multicast access. Before jumping on the project and planning for just that department, consider that in the near future, it is likely that other departments will also request access. Applications that will require end-to-end multicast capability may be purchased or integrated into the enterprise. It is far better to plan an end-to-end deployment and initially activate only the routers and interfaces that are needed than to plan your implementation on a limited initial activation. It will be easier to "build it right the first time" than to try to come back and work around or rebuild a poor IP multicast deployment. </PARA>
</SECTION>
</SECTION>
<SECTION ID="10.2"><TITLE>Configuring IP Multicast Routing</TITLE>
<PARA><DROPCAP>W</DROPCAP>hen configuring multicast, keep in mind that there are many different options and protocols that may be configured. This is why it is so important that you have previously prepared and planned for the actual configuration. It isn't something that you can just sit down and throw together (not without a lot of problems anyway). </PARA>
<PARA>Configuring routers for IP multicast is different than enabling CGMP on switches. You must also remember that switches do not understand Internet Group Management Protocol (IGMP) and that you will need to enable CGMP on switches and routers for hosts to be able to subscribe to a multicast group.</PARA>
<PARA>This section of the chapter covers the basics of configuring multicast on routers and switches. It also covers the configuration of rendezvous points. This is a very important task because without a rendezvous point, you will not be able to send or receive multicast packets across a network. We will also cover the individual interface configurations on routers. CGMP processes will be discussed in a little more detail than in the preceding chapter.</PARA>
<PARA>It is best to prepare a configuration task list before setting out to actually configure a group of routers. The configuration list should be specific to the device that will be configured. That fact makes it hard to present a set list of configuration tasks that would apply to all scenarios. However, there are definitely two items that must be configured on a router in order for multicast to even begin working. These items include enabling multicast routing and then enabling Protocol Independent Multicast (PIM) on the interfaces that will carry multicast traffic.</PARA>
<PARA>The following sections describe the multicast settings that can be made on a multicast-enabled router (and switches). The first two sections describe required configuration, whereas the configuration described in the remaining sections is optional. At the end of the configuration section, a summary of possible configuration tasks will be listed.</PARA>
<SECTION ID="10.2.1" POS="1"><TITLE>Enabling IP Multicast Routing</TITLE>
<PARA>First, multicast routing must be enabled on the router. This step is very straightforward, but without it, multicast will not work. Let's look at a configuration of a router that does not have multicast enabled:</PARA>
<PARA>Notice that there is no multicast information running on this machine. If we were to try to execute a multicast-related command, we wouldn't get any information returned. For example, look at what happens when the <INLINECODE>show ip mroute</INLINECODE> command is issued: </PARA>
<CODESNIPPET><CODELINE>RouterA#<EMPHASIS FORMAT="bold">sho ip mroute</EMPHASIS></CODELINE>
<CODELINE>IP Multicast Routing Table</CODELINE>
<CODELINE>Flags: D - Dense, S - Sparse, C - Connected, L - Local,</CODELINE>
<CODELINE>P - Pruned R - RP-bit set, F - Register flag,</CODELINE>
<CODELINE> T - SPT-bit set,J - Join SPT, M - MSDP created entry,X - Proxy Join Timer Running</CODELINE>
<CODELINE> A - Advertised via MSDP</CODELINE>
<CODELINE>Timers: Uptime/Expires</CODELINE>
<CODELINE>Interface state: Interface, Next-Hop or VCD, State/Mode</CODELINE>
<CODELINE></CODELINE>
<CODELINE>RouterA#</CODELINE></CODESNIPPET>
<PARA>The syntax for the command is <INLINECODE>ip multicast-routing</INLINECODE> and an example of the execution follows:</PARA>
<PARA>This enables the multicast on the router. Notice that it was executed while in the global configuration mode. However, the router still cannot exchange multicast information with any neighbors because none of the interfaces have been enabled. This step is next.</PARA>
</SECTION>
<SECTION ID="10.2.2"><TITLE>Enabling PIM on an Interface</TITLE>
<PARA><KEYTERM>Protocol Independent Multicast (PIM)</KEYTERM> is one of the required elements for multicast configuration. It enables IGMP on the router and allows it to receive and forward traffic on the specified interface. PIM must be enabled on every interface that is to participate in the multicast network.</PARA>
<PARA>PIM interface configuration has many options. Take a look at the available options in IOS 12.0(10)S1, shown in Table 10.1. Most of these options are for advanced multicast configuration that won't be addressed in detail here. The ones that will be discussed here are <INLINECODE>dense-mode</INLINECODE>, <INLINECODE>sparse-mode</INLINECODE>, and <INLINECODE>sparse-dense-mode</INLINECODE>.</PARA>
<PARA>Dense mode was discussed in <NOBR REF="9">Chapter 9</NOBR>. PIM dense mode functions by using the source root shared tree. It also assumes that all PIM neighbors have active multicast members directly connected, and therefore, it initially forwards multicast group data out all PIM-enabled interfaces.</PARA>
<PARA>The syntax for this command is very simple, <INLINECODE>ip pim dense-mode</INLINECODE>. An example of placing an interface in PIM dense mode follows:</PARA>
<PARA>Sparse mode was described to use shared root source tree distribution and relies on the knowledge of an RP. If an RP cannot be found, the router is unable to forward multicast information, strictly because it does not know where the source of the multicast traffic should come from. If it can't determine where the traffic is supposed to be coming from, the Reverse Path Forwarding (RPF) check will fail and no interfaces will be added to the multicast forwarding table.</PARA>
<PARA>Configuration of PIM sparse mode is just as simple as it was for IP dense mode. The command that needs to be used to enable IP PIM sparse mode is <INLINECODE>ip pim sparse-mode</INLINECODE>. Sparse mode PIM will also activate IGMP on the interface, allowing the interface to listen for IGMP membership reports. Here is an example of enabling IP PIM sparse mode multicast on an interface:</PARA>
<PARA>The name of this command gives an indication of the functionality it provides. Due to the increasing use of multicast and the variety of applications available today, it is best to configure an interface to be able to use both sparse mode and dense mode. With the previous commands, the interface was assigned the operating mode, and the interface could not change between modes depending on the need at the time. </PARA>
<PARA><KEYTERM>PIM sparse-dense mode</KEYTERM> configuration now allows the interface to use whichever forwarding method is needed by the application or multicast group. The interface uses the multicast group notation to decide which mode it needs to operate in. If the interface sees something with the notation (S, G), it will operate in dense mode. If the interface sees notation similar to (*, G), the interface will operate in sparse mode.</PARA>
<PARA>An added benefit of implementing sparse-dense mode on the interfaces is the elimination of the need to hard-configure the RP at every leaf router. The Auto-RP information is sent out across the network using dense mode forwarding.</PARA>
<PARA>IP PIM sparse-dense mode is enabled using <INLINECODE>ip pim sparse-dense-mode</INLINECODE> on the interface command line. Here is an example:</PARA>
<PARA>Again, here is what the interface looks like once the preceding lines have been entered:</PARA>
<CODESNIPPET><CODELINE>!</CODELINE>
<CODELINE>interface FastEthernet3/0</CODELINE>
<CODELINE> ip address 172.16.21.4 255.255.255.0</CODELINE>
<CODELINE> no ip directed-broadcast</CODELINE>
<CODELINE> ip pim sparse-dense-mode</CODELINE>
<CODELINE>!</CODELINE></CODESNIPPET>
<PARA>In summary, when using the sparse-dense mode configuration on an interface, you need to understand that there are three criteria that will activate the interface and place it into the multicast forwarding table. The first criterion applies to either sparse or dense mode; the others will cause the interface to operate specifically for sparse or dense mode. Look at Table 10.2 for the details.</PARA>
<TABLE NUM="10.2" TABLEENTRYNUM="2">
<TABLETITLE>Interface Activation Criteria for Sparse-Dense Mode Interfaces</TABLETITLE>
<TABLEHEAD>
<TABLEROW>
<TABLEENTRY><PARA>Criteria</PARA></TABLEENTRY>
<TABLEENTRY><PARA>Mode of Operation</PARA></TABLEENTRY>
</TABLEROW>
</TABLEHEAD>
<TABLEBODY>
<TABLEROW>
<TABLEENTRY><PARA>Directly connected group members or DVMRP neighbors</PARA></TABLEENTRY>
<TABLEENTRY><PARA>Sparse and dense</PARA></TABLEENTRY>
<SECTION ID="10.2.3"><TITLE>Configuring a Rendezvous Point</TITLE>
<PARA>If you are using PIM-DM throughout the multicast network, configuring a rendezvous point is an optional task. There are two ways of configuring a rendezvous point for a router. Notice that we did not say, "configuring a router <EMPHASIS FORMAT="italic">to be</EMPHASIS>" a rendezvous point. You can manually specify the IP address of the RP on a router, or you can enable Auto-RP. </PARA>
<PARA>Because multiple RPs may exist in a multicast network, the <KEYTERM>Auto-RP</KEYTERM> function aids by distributing the RP information across a multicast network. Different multicast groups may use different RPs, so this feature keeps track of which groups are using which RP. It will also fine-tune the leaf router's RP by choosing the RP nearest to the leaf. If you don't like to use static routes in a unicast network, you probably don't want to statically configure multicast RPs either.</PARA>
<PARA>Because there are two ways of configuring rendezvous points, we will describe both in the following subsections.</PARA>
<SECTION ID="10.2.3.1"><TITLE>Manual RP Configuration</TITLE>
<PARA>The syntax for the manual RP configuration command is very simple, <INLINECODE>ip pim rp-address </INLINECODE><INLINECODEVARIABLE>ip-address</INLINECODEVARIABLE><INLINECODE> [group-access-list-number] [override]</INLINECODE>. The <INLINECODEVARIABLE>ip-address</INLINECODEVARIABLE> is the IP address of the router that is the RP. The access list number is for a standard IP access list (1-99) or an expanded range from 1300 to 1999. These lists are used to define which multicast groups can or cannot use this RP. If no access list is specified, all multicast groups will use the configured RP. Finally, the override option can be used to override any RP information that may be learned via an Auto-RP update. The static RP takes precedence over any Auto-RP-learned RP. Here is a sample configuration for manual RP configuration:</PARA>
<PARA>Here is a look at the router after the execution. Notice that the command is a global command. Following the global configuration, you will see access-list 50. The list allows only groups within the range of 224.0.0.0 to 224.255.255.255 to use 172.16.1.253 as the RP. Other groups will need Auto-RP information or another statically configured RP in order to work properly:</PARA>
<PARA>There are also two procedures that can be used to enable Auto-RP; which one you use depends on the state of your multicast network. If you are beginning a new deployment, it isn't necessary to create a default RP. If you are modifying an existing multicast network, you will need to designate a default RP router in the network.</PARA>
<PARA>Here is a list of configuration tasks that must be completed to successfully implement Auto-RP in a multicast network:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>Designate a default RP (only when modifying an existing multicast network).</PARA></LISTITEM>
<LISTITEM><PARA>Advertise each RP and the multicast groups associated with the RP.</PARA></LISTITEM>
<LISTITEM><PARA>Enable an RP Mapping Agent.</PARA></LISTITEM>
</LIST>
<PARACONTINUED>As you can see the list is short and simple. Now that you know what has to be done, let's discuss each step individually.</PARACONTINUED>
<SECTION ID="10.2.3.2.1"><TITLE>Designate a Default RP</TITLE>
<PARA>This step is somewhat tricky, not so much because the configuration is tricky, but because of the decision regarding when to execute the step. The only time you need to designate a default RP is when you are running sparse mode only on any of your interfaces in an existing multicast network. If you are using sparse-dense mode, as suggested, you will not need to execute this step.</PARA>
<PARA>This step is executed as described in "Manual RP Configuration" earlier in this chapter. The default RP becomes the statically mapped RP on all of the leaf routers. The default RP should serve all global multicast groups. That is all that has to be done.</PARA>
</SECTION>
<SECTION ID="10.2.3.2.2"><TITLE>Advertise RP Group Assignments</TITLE>
<!-- <PARA>From each RP, a statement needs to be added that assigns and advertises multicast groups to that RP. The multicast groups are then advertised so the RP Mapping Agent can keep track of which RP hosts which multicast groups and resolve conflicts when necessary. </PARA>
<PARA>The syntax for the command is <INLINECODE>ip pim send-rp-announce </INLINECODE><INLINECODEVARIABLE>type number scope ttl</INLINECODEVARIABLE><INLINECODE> group-list </INLINECODE><INLINECODEVARIABLE>access-list-number</INLINECODEVARIABLE>. The command is entered under the global configuration interface. The first two options are <INLINECODEVARIABLE>type</INLINECODEVARIABLE> and <INLINECODEVARIABLE>number</INLINECODEVARIABLE>, which are the interface type and number that indicate the RP IP address. <INLINECODEVARIABLE>Scope</INLINECODEVARIABLE> defines the boundary of the RP advertisement by using a high TTL value that will be effectively blocked by interfaces with the TTL threshold set. The <INLINECODEVARIABLE>group-list</INLINECODEVARIABLE> uses the specified access list to determine which multicast group ranges the RP is allowed to announce.</PARA>
<PARA>Here is an example of the command as well as a valid access list:</PARA>
<SECTION ID="10.2.3.2.3"><TITLE>Configure the RP Mapping Agent</TITLE>
<PARA>This router is in charge of learning all of the rendezvous point routers in the network along with the multicast group assignments that each RP advertises. The Mapping Agent will then tell all the routers within the multicast network which RP should be used for their source.</PARA>
<PARA>This is done with the <INLINECODE>ip pim send-rp-discovery scope </INLINECODE><INLINECODEVARIABLE>ttl</INLINECODEVARIABLE> command. As you can see, this command is similar to the command in the preceding section. The scope defines the TTL value for the discovery. After the TTL is reached, the discovery packets are dropped. Here is an example:</PARA>
<PARA>In this example, you can see that the TTL value was set to 23. This means that after 23 hops, the discovery has expired. This command is the command that actually assigns to the router the role of RP Mapping Agent.</PARA>
<PARA>This concludes the configuration tasks for configuring a rendezvous point in a multicast network. Keep in mind that the RP Mapping Agent can be an RP, although it doesn't have to be. The Mapping Agent's role is to learn of all of the deployed rendezvous points throughout the network and then advertise which groups are available via the closest RP for all multicast-enabled routers in the network.</PARA>
<PARA>Time to Live (TTL) threshold configuration is done to limit the boundary of scope of the IP multicast network. As you learned in <NOBR REF="9">Chapter 9</NOBR>, limiting the scope of a multicast network is based on the TTL value in the multicast packet. Because this command is used to create a boundary, it must be executed on each border interface.</PARA>
<PARA>The default value for the TTL threshold is zero. The value can be changed with the <INLINECODE>ip multicast ttl-threshold </INLINECODE><INLINECODEVARIABLE>ttl</INLINECODEVARIABLE> command. The syntax is straightforward and the <INLINECODEVARIABLE>ttl</INLINECODEVARIABLE> value that is used is up to the discretion of the network administrator. The range of valid values for this option is between 0 and 255. However, the value should be high enough to stop multicast packets from exiting the interface. Here is an example:</PARA>
<CODELINE> ip address 172.16.5.1 255.255.255.0</CODELINE>
<CODELINE> no ip directed-broadcast</CODELINE>
<CODELINE> ip multicast ttl-threshold 230</CODELINE>
<CODELINE> no ip route-cache</CODELINE>
<CODELINE> no ip mroute-cache</CODELINE>
<CODELINE> full-duplex</CODELINE>
<CODELINE>!</CODELINE></CODESNIPPET>
</SECTION>
<SECTION ID="10.2.5"><TITLE>Joining a Multicast Group</TITLE>
<PARA>Once the main configuration is done on the router to enable multicast, PIM, rendezvous points, and RP Mapping Agents, the only other major task is allowing hosts to join multicast groups.</PARA>
<PARA>Within Cisco IOS, the network administrator has the opportunity to verify functionality and connectivity before users use the multicast system and applications. You can configure a router to join any number of IP multicast groups and, thus, verify functionality.</PARA>
<PARA>This is achieved through the <INLINECODE>ip igmp join-group </INLINECODE><INLINECODEVARIABLE>group-address</INLINECODEVARIABLE> command. The <INLINECODEVARIABLE>group-address</INLINECODEVARIABLE> is the multicast address of the group you want the router to join. An example follows:</PARA>
<PARACONTINUED>This tells the router to become a member of the 224.2.127.254 multicast group. Joining a group facilitates troubleshooting multicast connectivity issues as well.</PARACONTINUED>
<SECTION ID="10.2.5.1"><TITLE>Troubleshooting IP Multicast Connectivity</TITLE>
<PARA>Multicast can be a very difficult protocol to troubleshoot. There are, however, a few basic tools (mostly <INLINECODE>show</INLINECODE> commands) that can provide you with enough information to verify that connectivity is active or whether other steps, such as debugging, are needed to troubleshoot the problem.</PARA>
<PARA>If you do need to debug a multicast-enabled interface, you must first disable the multicast fast switching on the interface. This is done so that the debug messages can be logged. The command to disable fast switching is <INLINECODE>no ip mroute-cache</INLINECODE>. The normal unicast fast (or other forms of) switching may be left enabled.</PARA>
<PARA>You are familiar with the troubleshooting tools for unicast connectivity, Ping and traceroute. Well, these tools are also available for troubleshooting multicast connectivity. There is one minor difference, though: multicast requires a special version of traceroute, called mtrace or "multicast-traceroute." </PARA>
<SECTION ID="10.2.5.1.1"><TITLE>Ping</TITLE>
<PARA>Once a device on the network becomes a member of a group, it can be identified by its layer 3 multicast address as well as the layer 2 MAC address. Because the device has an active address on its interface, it can respond to ICMP request packets. Here is an example:</PARA>
<CODELINE>Target IP address: 224.2.143.55</CODELINE>
<CODELINE>Repeat count [1]: 5</CODELINE>
<CODELINE>Datagram size [100]: </CODELINE>
<CODELINE>Timeout in seconds [2]: </CODELINE>
<CODELINE>Extended commands [n]: </CODELINE>
<CODELINE>Sweep range of sizes [n]: </CODELINE>
<CODELINE>Type escape sequence to abort.</CODELINE>
<CODELINE>Sending 5, 100-byte ICMP Echos to 224.2.143.55, timeout is 2 seconds:</CODELINE>
<CODELINE>.!!!!</CODELINE>
<CODELINE>RouterA#</CODELINE></CODESNIPPET>
<PARA>This tool can be used to verify connectivity among RPs or other multicast routers.</PARA>
</SECTION>
<SECTION ID="10.2.5.1.2"><TITLE>Mtrace</TITLE>
<!-- <PARA>Cisco also provides a multicast traceroute tool. The multicast version of traceroute is somewhat different than the unicast version. The complete syntax for <KEYTERM>mtrace</KEYTERM> is <INLINECODE>mtrace </INLINECODE><INLINECODEVARIABLE>source</INLINECODEVARIABLE><INLINECODE> [</INLINECODE><INLINECODEVARIABLE>destination</INLINECODEVARIABLE><INLINECODE>] [</INLINECODE><INLINECODEVARIABLE>group</INLINECODEVARIABLE><INLINECODE>]</INLINECODE>. The <INLINECODEVARIABLE>source</INLINECODEVARIABLE> is the unicast IP address for the source of the multicast group. The <INLINECODEVARIABLE>destination</INLINECODEVARIABLE> is used when following the forwarding path established by the source or shared tree distribution toward a unicast destination. The <INLINECODEVARIABLE>group</INLINECODEVARIABLE> option is used to establish the tree for the specified group. If no destination or group options are specified, the mtrace will work from the incoming multicast interfaces back toward the multicast source. Here are a few samples of the command and its output:</PARA>
<PARA>As you can see, the outputs differ very little, but it is important to see how the paths are established. From the first sample output, no group or destination was specified, so the router strictly used RPF to calculate the path from the source to the router. In the other output, a group address was specified. This caused the router to specifically use the existing forwarding tree for group 224.2.243.55 to get back to the router.</PARA>
<PARA>These tools can be useful to determine connectivity as well as effectiveness of placement of RPs and multicast sources. There are other <INLINECODE>show</INLINECODE> commands that can aid you as well, but they are not related to the topic of this chapter.</PARA> -->
<SLUG NONUM="a2"/>
</SECTION>
</SECTION>
</SECTION>
<SECTION ID="10.2.6"><TITLE>Changing the IGMP Version</TITLE>
<PARA>There are several settings that can be tweaked in the router to enhance or change performance. The majority of them are beyond the scope of this chapter. However, we will discuss one important feature, changing the IGMP version.</PARA>
<PARA>It is important that you understand and know how to perform this change because of the compatibility issues between IGMP versions, as discussed in <NOBR REF="9">Chapter 9</NOBR>.</PARA>
<PARA>To put it simply, the IGMP version that runs on the hosts must also run on the router. Cisco routers use IGMPv2 by default and do not auto-detect the IGMP version the host is using. The command to change from IGMPv2 to IGMPv1, or vice versa, is <INLINECODE>ip igmp version (</INLINECODE><INLINECODEVARIABLE>2</INLINECODEVARIABLE><INLINECODE> | </INLINECODE><INLINECODEVARIABLE>1</INLINECODEVARIABLE><INLINECODE>)</INLINECODE>. Because the IGMP version needs to match only on the subnet, the command must be entered on the interface that connects to the subnet that houses the IGMPv1 hosts. The other interfaces on the router can remain on IGMPv2.</PARA>
</SECTION>
<SECTION ID="10.2.7"><TITLE>Enabling CGMP</TITLE>
<PARA>CGMP must be used when hosts connect to a router via a Catalyst switch. As we discussed in <NOBR REF="9">Chapter 9</NOBR>, Catalysts run CGMP so they can manage multicast membership reports from the router accordingly and so they can manage multicast ports on the switch. The router is the device that listens for the IGMP membership report; it then tells the switch, via CGMP, which port needs to be activated. CGMP must be activated on both the router and the switch.</PARA>
<PARA>The router configuration syntax is very simple. It must be applied to the interface connected to the Catalyst switch. The command is <INLINECODE>ip cgmp [</INLINECODE><INLINECODEVARIABLE>proxy</INLINECODEVARIABLE><INLINECODE>]</INLINECODE>. The <INLINECODEVARIABLE>proxy</INLINECODEVARIABLE> option is used for routers that are not CGMP capable. It allows them to use the proxy router for CGMP. Here is a sample configuration:</PARA>
<PARA>The Catalyst syntax is just as simple, if not more so, as the syntax for the router configuration. By default, CGMP is turned off on the switch. If you want multicast to work properly, you must enable CGMP on the switch. This is done by using the syntax <INLINECODE>set cgmp enable</INLINECODE>. Here is a sample:</PARA>
<PARA>Once CGMP is enabled, you can look at statistics using the <INLINECODE>show cgmp statistics</INLINECODE> command. This is all that is needed to enable CGMP on the switch so that it can communicate with the router.</PARA>
</SECTION>
</SECTION>
</SECTION>
<SECTION ID="10.3"><TITLE>Summary</TITLE>
<PARA><DROPCAP>T</DROPCAP>his chapter has been dedicated to the syntax and method of IP multi- cast configuration in Cisco routers and switches. Several points were discussed about the importance of planning the IP multicast deployment.</PARA>
<PARA>In addition to learning the commands for rendezvous points and hosts, you learned a few troubleshooting commands that will aid you in verifying that the multicast network has full functionality.</PARA>
<TABULARENTRY>Manually configures an RP address on a multicast router.</TABULARENTRY>
</TABULARROW>
<TABULARROW>
<TABULARENTRY><INLINECODE>ip pim send-rp-announce </INLINECODE><INLINECODEVARIABLE>type number scope ttl</INLINECODEVARIABLE><INLINECODE> group-list </INLINECODE><INLINECODEVARIABLE>access-list-number</INLINECODEVARIABLE></TABULARENTRY>
<TABULARENTRY>Assigns specific multicast group addresses to an RP. The RP can only announce multicast groups that are permitted by the specified access list.</TABULARENTRY>
<TABULARENTRY>Used on Catalyst switches to enable CGMP.</TABULARENTRY>
</TABULARROW>
</TABULARBODY>
</TABULARDATA>
</SECTION>
</SECTION>
<TESTSECTION ID="10.4"><TITLE>Written Lab</TITLE>
<!-- <PARA>Complete this lab by writing out the answers to the following questions.</PARA>
<TESTDATA>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that enables multicast routing on a router.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the commands that will enable PIM SM on interface FastEthernet4/0.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the configuration commands that will enable PIM DM on interface FastEthernet3/0.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the configuration for enabling PIM sparse-dense mode on interface FastEthernet0/0.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will show you the multicast route table.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Manually configure a router to be an RP using the IP address of 172.16.25.3 and apply access list number 30.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that is used when implementing Auto-RP so that the RP will announce only specific multicast groups. Use access list number 10 and interface FastEthernet 4/0. Use a TTL value of 220.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that enables an RP Mapping Agent. Use a TTL value of 32.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Apply a command that sets a TTL threshold of 235 on interface FastEthernet 2/0.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the commands that will enable CGMP on a router for interface FastEthernet 3/0, and then write the command that will enable CGMP on a switch.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
</TESTDATA> -->
<SLUG NONUM="w1"/>
</TESTSECTION>
<SECTION ID="10.5"><TITLE>Hands-On Lab</TITLE>
<PARA>Refer to Figure 10.1 as the diagram for this lab. The objective of this lab is to configure an IP multicast network from scratch. You will implement Auto-RP, PIM sparse-dense mode, and CGMP on all routers and switches. You will not have to configure host applications in this lab. Assume that Routers C and D have multicast sources attached to them.</PARA>
<SLUG NUM="10.1">Figure 10.1: Configuring an IP multicast network [f1001.eps]</SLUG>
<LIST MARK="number">
<LISTITEM><PARA>Because you are starting from scratch, the first step is to enable multi-cast on all routers.</PARA>
<CODELINE>CGMP support for IP multicast enabled.</CODELINE></CODESNIPPET></LISTITEM>
<LISTITEM><PARA>Assign multicast group 224.2.127.254 to RouterC via access list 5. This assignment will only allow RouterC to advertise that group. Assign a TTL value of 12. Then assign group 224.0.124.244 to RouterD via access list 6.</PARA>
