Configuring IP Multicast Routing

When configuring multicast, keep in mind that many options and protocols can 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).

Configuring routers for IP multicast is different from enabling CGMP on switches. You must also remember that switches do not understand Internet Group Management Protocol (IGMP) by default, and that you need to enable multicasting on switches and routers for hosts to be able to subscribe to a multicast group.

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 also cover the individual interface configurations on routers. CGMP processes are discussed in a little more detail than in the preceding chapter. Later, we will describe the multicast settings that can be made on a multicast-enabled router (and switches). 'Enabling IP Multicast Routing' and 'Enabling PIM on an Interface' describe required configuration, whereas the configuration described in the rest of this section is optional.

It is best to prepare a configuration task list before setting out to 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, two items definitely must be configured on a router in order for multicast to even begin working: enabling multicast routing and enabling PIM on the interfaces that will carry multicast traffic.

Enabling IP Multicast Routing

As we have said, 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:

Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Terry_3640 ! aaa new-model aaa authentication login default tacacs+ line aaa authentication login oldstyle line aaa accounting exec default start-stop tacacs+ enable secret 5 $1$G7Dq$em.LpM4Huem9uqjZDHLe4. ! ! ! ip subnet-zero ip telnet source-interface FastEthernet3/0 [output truncated]

Notice that no multicast information is 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 show ip mroute command is issued:

Terry_3640#sho 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, M - MSDP created entry, X - Proxy Join Timer Running     A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode Terry_3640# 

The syntax for the command is ip multicast-routing, and an example of the execution follows:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#ip multicast-routing Terry_3640(config)#^Z Terry_3640#

This enables the multicast on the router. Notice that it was executed while in global configuration mode. However, the router still can not exchange multicast information with any neighbors because none of the interfaces have been enabled. This step is next.

Enabling PIM on an Interface

PIM is one of the required elements for multicast configuration. It enables IGMP on the router and enables 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.

PIM interface configuration has many options. Take a look at the available options in IOS 12.0(10)S1, shown in Table 8.2. Most of these options are for advanced multicast configuration that won't be addressed in detail here. The ones that are discussed are dense-mode, sparse-mode, and sparse-dense-mode.

Table 8.2: IP PIM Configuration Options

IP PIM Options	Description
bsr-border	Specifies border of PIM domain
dense-mode	Enables PIM dense-mode operation
nbma-mode	Specifies use of Non-Broadcast Multi-Access (NBMA) mode on interface
neighbor-filter	Specifies PIM peering filter
query-interval	Specifies PIM router query interval
sparse-dense-mode	Enables PIM sparse-dense-mode operation
sparse-mode	Enables PIM sparse-mode operation
version	Displays PIM version

IP PIM Dense Mode

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.

The syntax for this command is simple: ip pim dense-mode. An example of placing an interface in PIM dense mode follows:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#interface FastEthernet3/0 Terry_3640(config-if)#ip pim dense-mode Terry_3640(config-if)#^Z Terry_3640#

This is what the interface configuration looks like now:

! interface FastEthernet3/0  ip address 172.16.21.4 255.255.255.0  no ip directed-broadcast  ip pim dense-mode !

IP PIM Sparse Mode

Sparse mode was developed to use shared root source tree distribution and relies on the knowledge of a RP. If a RP can not be found, the router is unable to forward multicast information, strictly because it does not know the source of the multicast traffic. If it can't determine where the traffic is supposed to be coming from, the Reverse Path Forwarding (RPF) check fails and no interfaces are added to the multicast forwarding table.

Configuration of PIM sparse mode is just as simple as it is for IP dense mode. The command for enabling IP PIM sparse mode is ip pim sparse-mode. Sparse mode PIM also activates 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:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#interface FastEthernet3/0 Terry_3640(config-if)#ip pim sparse-mode Terry_3640(config-if)#^Z Terry_3640# 

Here is a look at the interface configuration after the preceding execution:

! interface FastEthernet3/0  ip address 172.16.21.4 255.255.255.0  no ip directed-broadcast  ip pim sparse-mode !

Note 

All forms of sparse mode also require a rendezvous point to be configured.

IP PIM Sparse-Dense Mode

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.

PIM sparse-dense mode configuration now enables 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 operates in dense mode. If the interface sees a notation similar to (*, G), the interface operates in sparse mode.

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 by using dense mode forwarding.

IP PIM sparse-dense mode is enabled by using ip pim sparse-dense-mode on the interface command line. Here is an example:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#interface FastEthernet3/0 Terry_3640(config-if)#ip pim sparse-dense-mode Terry_3640(config-if)#^Z Terry_3640# 

Again, here is what the interface looks like after the preceding lines have been entered:

! interface FastEthernet3/0  ip address 172.16.21.4 255.255.255.0  no ip directed-broadcast  ip pim sparse-dense-mode !

In summary, when using the sparse-dense mode configuration on an interface, you need to understand that three criteria will activate the interface and place it into the multicast forwarding table. The first criterion applies to either sparse or dense mode; the others cause the interface to operate specifically for sparse or dense mode. Table 8.3 provides the details.

Table 8.3: Interface Activation Criteria for Sparse-Dense Mode Interfaces

Criteria	Mode of Operation
Directly connected group members or DVMRP neighbors	Sparse and dense
Non-pruned PIM neighbors	Dense
Join request received	Sparse

Configuring a Rendezvous Point

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 to be' a rendezvous point. You can manually specify the IP address of the RP on a router, or you can enable Auto-RP. Both are described in this section.

Manual RP Configuration

The syntax for the manual RP configuration command is simple: ip pim rp-address ip_address group_access_list_number [override]. The ip_address 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 can not 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 might 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:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#ip pim rp-address 172.16.1.253 50 override Terry_3640(config)#^Z Terry_3640# 

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 need Auto-RP information or another statically configured RP in order to work properly:

! no ip classless ip route 0.0.0.0 0.0.0.0 172.16.22.2 ip pim rp-address 172.16.1.253 50 override ! access-list 50 permit 224.0.0.0 0.255.255.255 access-list 50 deny  any !

Auto-RP Configuration

Because multiple RPs can exist in a multicast network, the Auto-RP function aids by distributing the RP information across a multicast network. Different multicast groups can 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.

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 need to designate a default RP router in the network.

Here is a list of configuration tasks that must be completed to successfully implement Auto- RP in a multicast network:

• Designate a default RP (only when modifying an existing multicast network).

• Advertise each RP and the multicast groups associated with the RP.

• Enable an RP Mapping Agent.

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.

Designating a Default RP

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 do not need to execute this step.

This step is executed as described in the 'Manual RP Configuration' section earlier in this chapter. The default RP becomes the statically mapped RP on all the leaf routers. The default RP should serve all global multicast groups. That is all that has to be done.

Advertising RP Group Assignments

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.

The syntax for the command is ip pim send-rp-announce type number scope ttl group_list access_list_number. The command is entered in global configuration mode. The first two options, type and number, are the interface type and number that indicate the RP IP address. Scope 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 group_list uses the specified access list to determine which multicast group ranges the RP is allowed to announce.

Here is an example of the command as well as a valid access list:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#access-list 5 permit 224.0.0.0 0.0.255.255 Terry_3640(config)#ip pim send-rp-announce fastethernet4/0 scope 230 group-list 5 Terry_3640(config)#^Z Terry_3640# Terry_3640#write terminal … ! ip pim send-rp-announce FastEthernet4/0 scope 230 group-list 5 ! access-list 5 permit 224.0.0.0 0.0.255.255 ! …

Configuring the RP Mapping Agent

This router is in charge of learning all the rendezvous point routers in the network along with the multicast group assignments that each RP advertises. The Mapping Agent then tells all the routers within the multicast network which RP should be used for their source.

This is done with the ip pim send-rp-discovery scope ttl 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:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#ip pim send-rp-discovery scope 23 Terry_3640(config)#^Z Terry_3640 

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 actually assigns to the router the role of RP Mapping Agent.

This concludes the 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 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.

Configuring TTL

TTL threshold configuration is done to limit the boundary of scope of the IP multicast network. As you learned earlier in this chapter, 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.

The default value for the TTL threshold is zero. The value can be changed with the ip multicast ttl-threshold ttl command. The syntax is straightforward, and the ttl 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:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#interface FastEthernet0/0 Terry_3640(config-if)#ip multicast ttl-threshold 230 Terry_3640(config-if)#^Z Terry_3640# ! interface FastEthernet0/0  ip address 172.16.5.1 255.255.255.0  no ip directed-broadcast  ip pim sparse-dense-mode  ip multicast ttl-threshold 230  no ip route-cache  no ip mroute-cache  full-duplex ! 

Joining a Multicast Group

After the main configuration is done on the router to enable multicast, PIM, rendezvous points, and RP Mapping Agents, the only other major task is enabling hosts to join multicast groups.

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.

This is achieved through the ip igmp join-group group_address command. The group_address is the multicast address of the group you want the router to join. An example follows:

Terry_3640(config)#interface FastEthernet4/0 Terry_3640(config-if)#ip igmp join-group 224.2.127.254 Terry_3640(config-if)#^Z Terry_3640#

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.

Troubleshooting IP Multicast Connectivity

Multicast can be a difficult protocol to troubleshoot. However, a few basic tools (mostly show commands) can provide enough information for you to verify that connectivity is active or to determine whether other steps, such as debugging, are needed to troubleshoot the problem.

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 no ip mroute-cache. The standard unicast fast (or other forms of) switching can be left enabled.

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.'

Ping After 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:

Terry_3640#ping Protocol [ip]: Target IP address: 224.2.143.55 Repeat count [1]: 5 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 224.2.143.55, timeout is 2 seconds: .!!!! Terry_3640# 

This tool can be used to verify connectivity among RPs or other multicast routers.

mtrace Cisco also provides a multicast traceroute tool. The multicast version of traceroute is somewhat different from the unicast version. The complete syntax for mtrace is mtrace source_ ip destination_ip group. The source_ip is the unicast IP address for the source of the multicast group. The destination_ip is used when following the forwarding path established by the source or shared tree distribution toward a unicast destination. The group 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:

Jack_3640#mtrace 198.32.163.74 Type escape sequence to abort. Mtrace from 198.32.163.74 to 172.16.25.9 via RPF From source (blaster.oregon-gigapop.net) to destination (?) Querying full reverse path…  0 172.16.25.9 -1 172.16.25.9 PIM/MBGP [198.32.163.0/24] -2 172.16.25.10 PIM/MBGP [198.32.163.0/24] -3 ogig-den.oregon-gigapop.net (198.32.163.13) [AS 4600]  PIM [198.32.163.64/26] -4 0car-0gw.oregon-gigapop.net (198.32.163.26) [AS 4600]  PIM [198.32.163.64/26] -5 blaster.oregon-gigapop.net (198.32.163.74) Jack_3640# Jack_3640#mtrace 198.32.163.74 224.2.243.55 Type escape sequence to abort. Mtrace from 198.32.163.74 to 172.16.25.9 via group 224.2.243.55 From source (blaster.oregon-gigapop.net) to destination (?) Querying full reverse path…  0 172.16.25.9 -1 172.16.25.9 PIM/MBGP Reached RP/Core [198.32.163.0/24] -2 172.16.25.10 PIM/MBGP Reached RP/Core [198.32.163.0/24] -3 ogig-den.oregon-gigapop.net (198.32.163.13) [AS 4600]  PIM Reached RP/Core [198.32.163.64/26] -4 0car-0gw.oregon-gigapop.net (198.32.163.26) [AS 4600]  PIM [198.32.163.64/26] Jack_3640# 

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.

These tools can be useful to determine connectivity as well as the effectiveness of the placement of RPs and multicast sources. There are other show commands that can aid you as well, but they are not related to the topic of this chapter.

Changing the IGMP Version

Several settings can be tweaked in the router to enhance or change performance. The majority of them are beyond the scope of this chapter. However, in this section, we discuss one important feature: changing the IGMP version. It is important that you understand and know how to perform this change because of the compatibility issues between IGMP versions, as discussed earlier in this chapter in the section 'Changing the IGMP Version.'

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 that the host is using. The command to change from IGMPv2 to IGMPv1, or vice versa, is ip igmp version (2 | 1). Because the IGMP version needs to match only on the subnet, the command must be entered on the interface that connects to the subnet housing the IGMPv1 hosts. The other interfaces on the router can remain on IGMPv2.

Enabling CGMP and IGMP Snooping

When hosts connect to a router via a Catalyst switch, either CGMP or IGMP Snooping can be used to enable the switch to learn appropriate information. Catalysts run both 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 which port needs to be activated. CGMP or IGMP Snooping must be activated on both the router and the switch.

CGMP Router Configuration

The router configuration syntax is simple. It must be applied to the interface connected to the Catalyst switch. The command is ip cgmp proxy. The proxy option is used for routers that are not CGMP capable. It enables them to use the proxy router for CGMP. Here is a sample configuration:

Terry_3640#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Terry_3640(config)#interface FastEthernet4/0 Terry_3640(config-if)#ip cgmp Terry_3640(config-if)#^Z Terry_3640# 

Use the command show running-config to see whether CGMP is enabled or disabled on a particular router interface, as shown here:

! interface FastEthernet4/0  ip address 172.16.10.1 255.255.255.0  no ip directed-broadcast  ip pim sparse-dense-mode  no ip route-cache  ip igmp join-group 224.2.127.254  ip cgmp !

Catalyst Switch Configuration

The Catalyst syntax is just as simple as the syntax for the router configuration, if not simpler. By default, CGMP is turned off on the switch. If you want multicast to work properly, you must enable CGMP or IGMP Snooping on the switch. Enabling CGMP is done by using the syntax set cgmp enable. Here is a sample:

Terry_4000> (enable) set cgmp enable CGMP support for IP multicast enabled. Terry_4000> (enable) Terry_4000> (enable) show cgmp statistics CGMP enabled CGMP statistics for vlan 1: valid rx pkts received            6 invalid rx pkts received          0 valid cgmp joins received         6 valid cgmp leaves received        0 valid igmp leaves received        0 valid igmp queries received       0 igmp gs queries transmitted       0 igmp leaves transmitted           0 failures to add GDA to EARL       0 topology notifications received   0 number of packets dropped         0 Terry_4000> (enable)

After CGMP is enabled, you can look at statistics by using the show cgmp statistics command. This is all that is needed to enable CGMP on the switch so that it can communicate with the router.

A CGMP-enabled switch can also be configured to detect IGMPv2 Leave messages generated by clients. To do this, simply use the command set cgmp leave enable. This command takes place globally on the switch.

The switch collects multicast group MAC addresses for each group address. To see what multicast groups your switch knows about, use the command show multicast group cgmp.

IGMP Snooping

IGMP Snooping can be configured to enable the switch to learn multicast information by examining the frames as they pass through the switch. The switch doesn't depend wholly on information received from the multicast router.

To configure IGMP Snooping on the switch, use the command set igmp enable. You can not have CGMP and IGMP Snooping enabled on the same switch at the same time. To enable IGMP Snooping on the router, use the command ip igmp snooping while in global configuration mode.

Fast-Leave processing is a new feature that works only with IGMP Snooping and is one of the main reasons for its use. Fast-Leave processing enables a switch to receive an IGMP Leave message and immediately remove the interface from the table that lists which ports receive the multicast stream. Thus, if a client on port 2/5 generates a Leave message, the switch immediately removes port 2/5 from the list of ports receiving the multicast stream. To enable Fast-Leave processing on the switch, use the command set igmp fastleave enable.

Just as with CGMP, IGMP Snooping has a way of displaying the configuration and statistics. Using the command show igmp statistics will display the status of IGMP Snooping on the switch as well as the amount of traffic that has been processed.

Real World Scenario-The Fast-Leave Trap

Fast Leave is a great tool in an organization that uses quite a bit of multicasting. There can be a problem though, when using it in a network where Spanning Tree changes frequently.

When a switch configured for Fast Leave receives a Leave message, the switch will remove the port at which the message arrived from the forwarding table for the particular stream. What happens if this occurs on a core switch, on the port going out to a closet switch or stack? The core switch will remove all entries associated with that port. If several clients were listening to the stream and one leaves, the core switch will remove them all.

Whenever possible, only enable Fast-Leave processing on switches that have clients terminating at individual ports. Turn this feature on at the closets but think twice before doing so at core and distribution layer switches.

Note 

It is early to be too definite about this, but it would seem that Cisco is moving away from CGMP towards IGMP Snooping as a preference. With pressure on all the giant companies moving them toward a standards-based intercommunications approach, this would make sense, as would the fact that IGMP Snooping supports the Fast-Leave process. Readers should note that IGMP Snooping is enabled by default on both the 2950 and 3550 switches.