Internet Standard Multicast

ISM uses the following protocols to control broadcasts in your network:

• Distribution trees

• Protocol Independent Multicast (PIM)

• Reverse Path Forwarding (RPF)

• Router Group Management Protocol (RGMP)

• Bidirectional PIM (Bidir-PIM)

• Pragmatic General Multicast (PGM)

Distribution Trees

From a Layer 3 perspective, multicast information is propagated through a network with the use of distribution trees created by Layer 3 routers. Routers create source trees with the source of the multicast traffic at the root of the tree. Source trees provide the shortest path to each destination and are therefore called shortest path trees (SPT). The drawback to source trees is that routers in the network must track all sources by maintaining state information for each source. That is, each router in the network has an entry in its multicast state table for every source.

Note

For source trees, routers maintain state table entries in the form (S, G), where S is the source's IP address and G is the multicast group address.

With shared trees, however, routers are at the root; therefore, routers do not maintain individual sources in their state tables. The root of a shared tree is called a Rendezvous Point (RP). RPs establish multicast sessions between sources and receivers. Sources register with and forward all multicast traffic to the RP. The RP in turn forwards the traffic to receivers on behalf of sources.

Note

For shared trees, the group has a single entry stored as (*.G) in multicast state tables.

Although shared trees do not provide the shortest path to the receivers, the tradeoff is that routers need not track the state of all multicast sources. A large network with thousands of sources would have a significant performance impact on multicast routers.

Protocol Independent Multicast

PIM is a protocol to forward multicast traffic through a network. Instead of building its own routing tables, PIM uses the IGP routing protocol that populates the routing tables on the router. PIM uses RPF to ensure that multicast traffic is correctly distributed down a distribution tree. If the multicast traffic source is reachable through the interface that it was received on, the packet is forwarded out of the router's outgoing interface (OIF) list. The OIF list contains all interfaces enabled with multicast that are downstream from the source of the multicast data.

With RPF, if the multicast traffic source is not reachable through the interface the router received it on, then the router drops the packet. In other words, before forwarding multicast traffic, when the router receives a multicast packet it first looks up the source of the packet in its routing table. If the routing entry's next hop address is not via the same interface that the router received the packet from, then there may be a multicast forwarding loop. Therefore, the router drops the packet to avoid any loops in the distribution tree.

In Figure 5-7, Router B inadvertently forwards traffic to Router C instead of Router A. The RPF checks will pass on Routers B, C, and D. However, when Router A receives the packet from Router D and performs the RPF check, the router drops the packet, because the next hop of the routing entry for the source is via Router B, not Router D.

Figure 5-7. RPF Operation

Note

With shared trees, the PIM slightly modifies its RPF check to see if the packet came from the interface that the router uses to reach the RP, not the source.

Table 5-2 gives the available PIM messages. This Chapter explains the function of each of these messages.

Table 5-2. PIM Messages

Type	Description
0	Hello
1	Register
2	Register-Stop
3	Join/Prune
4	Bootstrap
5	Assert
6	Graft (used in PIM-DM only)
7	Graft-Ack (used in PIM-DM only)
8	Candidate-RP-Advertisement

The three PIM modes are

• PIM Dense Mode

• PIM Sparse Mode

• Bidirectional PIM Mode

Note

PIM routers periodically send PIM Hello messages to the all-PIM-routers group 224.0.0.13, out all their interfaces, to discover neighboring PIM routers.

PIM Dense Mode

In PIM dense mode, the multicast traffic is initially flooded throughout the network. Last-hop routers that do not contain active receivers of the multicast traffic on their directly connected LANs send PIM Prune messages in the reverse direction. To enable PIM dense mode on your network, use the interface command ip pim dense-mode.

During the flood-prune period, routers store (S, G) group information along with an associated OIF list for each (S, G) entry. Initially, the OIF list contains all interfaces except the RPF interface. However, when upstream routers receive Prune messages on an OIF interface, they remove that interface from the OIF list.

In Figure 5-8, the receiver joins the multicast group by sending an IGMP join message to Router A, before the sender starts sending data. When the multicast information is propagated toward the last-hop routers, all routers but Router A send prune messages toward the sender.

Figure 5-8. Dense Mode Operation

After the sender commences sending data, receivers may join the multicast session by sending IGMP joins to their last-hop routers. For example, in Figure 5-8, imagine that a new receiver on the LAN segment attached to Router B decides to join the session. To elicit the multicast session, Router B sends a PIM Graft message up the distribution tree. The router uses a Graft message to indicate to Router E that it should start sending the multicast traffic down the tree. Router E in response sends a PIM Graft-Ack message to Router B, before sending the multicast data.

The result of this flood-prune mechanism is a SPT with the sender at the root of the tree, free of unnecessary flood traffic (once the PIM routers complete the prune process). However, because the flood process repeats every 3 minutes, dense mode may prove inefficient if your application does not have receivers on the majority of your LAN segments. Your network may experience unnecessary congestion during these periods. However, with the PIM dense mode state-refresh feature, you can configure your PIM routers to send periodic PIM control messages down the source distribution tree to prevent the state of the tree from timing out every three minutes. The control messages simulate flood traffic to check to see if downstream routers have members of the group. If the downstream routers have members, they do not respond to the control messages with PIM Prune messages. As a result, the upstream router adds the interface to its OIF list and starts forwarding the traffic downstream. If the downstream routers do not have members of the requested group, they send a PIM Prune message upstream. To enable the state refresh feature, use the interface configuration command ip pim state-refresh origination-interval.

PIM Sparse Mode

PIM Sparse mode uses a pull method to send multicast traffic only to last-hop routers that have LAN segments that contain active receivers. The receivers solicit group traffic for group (G) using IGMP join messages. The IGMP Join triggers the last-hop router to send a PIM Join message toward the RP. Routers send the PIM Join message to the all-PIM-routers address 224.0.0.13 with a TTL of 1, out its RPF interface. Each router updates the PIM state tables with an (*, G) entry for the desired group and forwards the Join hop-by-hop along the path to the RP. Additionally, the interface the PIM Join was received on is added to the outgoing interface (OIF) list for the (*, G) entry. Figure 5-9 illustrates how PIM-SM creates a shared tree.

Figure 5-9. Creating the PIM-SM Shared Tree

Note

To enable PIM sparse mode on your network, use the interface command ip pim sparse-mode.

When a source has multicast traffic to send to a multicast group, it simply starts sending. In Figure 5-10, the multicast data triggers the first-hop designated router (DR) to create a (S, G) state entry in its PIM table and register the group with the RP on behalf of the source. To register with the RP, the DR encapsulates the multicast UDP packets from the source into unicast PIM Register messages. The PIM Register messages are routed with the unicast IGP routing table to the RP.

Figure 5-10. Registering a Multicast Group with the RP

Note

You can configure a leaf router with the RP IP address using the global configuration command ip pim rp-address or by using Auto-RP, as discussed later in this Chapter.

Figure 5-10 illustrates how the RP receives and forwards the multicast data down the shared tree.

Because the RP is aware of receivers interested in the group, it decapsulates the PIM Register messages and forwards the multicast data down the shared tree. The shared tree consists of the RP, DR, and Router A, in that order. The RP then responds to the DR's PIM Register with a PIM Join message, to join the SPT to the receiver, rooted at the source. The SPT consists of the DR, RP, DR, and Router A, in that order (notice that the DR is in the tree twice). When the DR receives the Join message, it sends the raw UDP multicast traffic stream to the RP, thus duplicating the UDP stream.

Not until the RP sends a PIM Register Stop message to DR will the DR discontinue sending the multicast stream encapsulated within PIM Register messages.

Note

It is preferable for the RP to receive native multicast data, because decapsulation of PIM headers takes unnecessary router memory and processing cycles.

Once this registration is completed, the DR sends dataless periodic PIM Register messages (approximately every 2 minutes, by default) to the RP in order to maintain (S, G) state on the DR and RP.

In Figure 5-10, you can see that the multicast traffic does not take the most efficient route to the receiver. Indeed, the SPT is not the "shortest path," because the shared tree consists of the DR, followed by the RP, the DR again, and then Router A. Therefore, when the edge Router A receives the multicast traffic, it attempts to optimize the connectivity to the source by switching over to a source distribution tree. Figure 5-11 illustrates the switchover to a source tree by sending a PIM (S, G) Join message not to the RP, but to the source of the multicast.

Figure 5-11. Switchover to a PIM-SM Source Tree

Note

Because PIM Join messages travel upstream, in the opposite direction of downstream multicast data, the RPF algorithm fails because the source of the packet is not reachable from the interface that the router uses to reach the RP. Instead of checking to see if the source of the packet (the last hop router, in this case) is reachable from the RP interface, the router checks its OIF list. If the router received the packet from an interface in its OIF list, it forwards the packet out its RPF interface; otherwise, the router drops the packet to avoid multicast loops.

To switch to a source distribution tree, each router compares the IGP routing metrics of the RP and source of the multicast. If the RP metric is better, the router forwards the PIM Join toward the RP, based on the PIM forwarding table; otherwise, the router forwards the PIM Join toward the source. Router B then sends a PIM Prune message, with the RP-bit flag in the PIM header set to 1, to the RP to indicate that the shared tree traffic is no longer necessary. The result is now truly the SPT, consisting of only the DR followed by Router A.

By default, last-hop routers immediately switch over to a source distribution tree. However, you can configure the bandwidth threshold that the router must reach before switching to SPT by using the ip pim spt-threshold global configuration command.

PIM routers detect LAN loops when multicast traffic is received on an OIF. The routers on the LAN elect a designated router by sending PIM Assert messages to one another. The routers then compare routing metric values to the RP. The one with the best route to the RP is elected as the DR for the LAN. Figure 5-12 shows how routers elect the DR upon reception of multicast traffic on an OIF.

Figure 5-12. Designated Router Election

PIM Sparse-Dense Mode

Instead of designating every group in a network to either sparse or dense mode, sparse-dense mode enables different groups to run in different modes. This enables easy migration from one mode to the other. If a group contains an RP, the router is in sparse-mode for the group; otherwise, the group is considered dense. To enable sparse-dense mode, use the interface configuration command ip pim sparse-dense-mode.

Bidirectional PIM

PIM-SM allows routers to forward multicast traffic down only the shared tree. PIM-SM is beneficial for applications such as corporate communications, in which a single user, such as the CEO, must convey a message to many employees. However, many-to-many applications, such as video conferencing, require a bidirectional infrastructure to enable any participant to both send and receive data up and down the tree during the communication. Bidir-PIM extends PIM-SM to enable any number of sources to send multicast traffic over a shared tree in both directions.

Recall with PIM-SM that data traveling up the distribution tree requires a modified forwarding mechanism, such as described previously for PIM Join messages. Also, recall that source multicast traffic is encapsulated into PIM Register messages and sent to the RP. The RP then joins the SPT with the source as the root of the shared tree, and forwards the multicast traffic to the receivers in the shared tree.

Bidir-PM uses shared trees with the RP permanently remaining at the rootlast-hop routers can no longer switch over to source distribution trees. In order to enable senders to forward loop-free multicast traffic upstream, Bidir-PIM requires every network segment (including point-to-point links and LAN segments) to elect a designated forwarder (DF) for the segment. Now, if routers receive multicast traffic on an upstream interface, the DF for the segment forwards multicast traffic toward the RP. Downstream traffic still uses the RPF mechanism.

Routers elect the DF in the same manner as they elect DRs for LAN segments with PIM-SM. Using PIM Assert messages, the routers select the router with the best unicast routing metrics to the RP as the DF. Routers with identical metrics break the tie using the router with the lower IP address. In Figure 5-13, the sender forwards traffic upstream through Router A and Router E to the RP. Router B is not elected as DF for traffic originating from the sender because its unicast routing metrics to the RP are not better than those for its directly connected neighbors.

Figure 5-13. Illustrating Bidirectional PIM

Note

No source state is maintained through (S, G) entries in the Bidir-PIM tables.

To configure Bidir-PIM, use the global interface configuration command ip pim bidir-enable.

So far, you've learned the basics of how IP multicast networks function and the basic commands for enabling IP multicast. The remainder of the "Internet Standard Multicast" section will show you how to fine-tune your ISM network, by teaching you how to configure:

• Redundant RPs

• Inter-domain Multicast

• Any-cast RP

• Cisco Group Management Protocol (CGMP) and IGMP Snooping

Configuring Rendezvous Point and Multicast Group Selection

You learned previously that RPs establish multicast connectivity between senders and receivers. DRs send PIM Register messages to RPs on behalf of hosts sending traffic to a multicast group. Additionally, last-hop routers send PIM Join messages to RPs, on behalf of receivers of the group, to inform of group membership. You can assign routers as RPs based on the location of the senders and receivers of the group traffic. For example, if your application restricts the senders and receivers of a particular range of multicast addresses to a portion of your network, then allocate the multicast group address ranges to an RP in close proximity to the participants. If the application's participants are located throughout your network, then assign a router in a central network location as the RP.

Note

Because routers use only the RP to connect sources to receivers, once the participants establish a multicast session, failure of the RP has no effect on the session. RP failures affect only new sessions.

The routers in your PIM network must be aware of the IP addresses of the RPs and the multicast address ranges they serve. To configure the PIM routers in your network to obtain RP-to-group mappings, you have three options:

• Static RP

• Auto-RP

• Bootstrap Routers (BSR)

To configure static RP addresses, you must use the ip pim rp-address command on each router in your network. Because static RP does not provide redundancy and is not scaleable, you should use it for small multicast deployments only.

For large multicast environments, use either Auto-RP or BSR. These two protocols provide scalability and redundancy of RP-to-group assignments. They can scale your PIM-SM domain by automatically distributing RP-to-group mappings throughout your network. Automatic distribution ensures that the mappings are consistent throughout the networkstatic RP configuration may lead to inconsistencies in large networks. They also enable you to configure load sharing and backup of multicast groups across RPs.

The advantage of using Auto-RP or BSR or both is that, if you decide to change the RPs, you need make changes only on the candidate RPs, not on every router in your network.

Auto-RP

Auto-RP is a Cisco proprietary protocol for automatically advertising RP-to-group mappings to routers in your PIM network. It is an extension of PIM version 1 that provides automatic RP-to-group mapping distribution, load sharing, and backup of RPs.

Auto-RP mapping agents elect RPs from available candidate RPs and advertise the RP-to-group mappings to the other routers in your network. You need to configure at least one router as a candidate RP and at least one router as a candidate mapping agent for Auto-RP to work. However, you can configure more than one of each to provide fault tolerance between mapping agents and between RPs.

To assign a router as a candidate RP, use the global configuration command ip pim send-rp-announce. To assign a router as a mapping agent, use the global configuration command ip pim send-rp-discovery.

When you configure more than one router as a mapping agent, no election process takes placeall configured mapping agents are active at once. The RP candidates advertise their groups to the mapping agents by sending PIM Candidate-RP-Advertisement messages to the reserved address 224.0.1.39 using PIM dense-mode multicast. Once the mapping agents select the RPs and groups from these advertisements, they in turn advertise the mappings to the PIM routers in the network by sending PIM Candidate-RP-Advertisement messages to the address 224.0.1.40 using PIM dense-mode multicast. The mapping agents select the candidate with the highest IP address as the RP for the group.

The PIM first-hop routers use the mappings to send PIM Register messages to the correct RP for the desired group. Additionally, the last-hop routers use the mappings to send PIM joins to the correct RP for the desired group.

Note

To configure Auto-RP, your PIM network must be in sparse-dense mode. The network must be able to perform dense-mode multicast to flood RP-to-group mapping information through the network. BSR does not use dense-mode to flood candidacy information. Therefore, you can configure BSR in sparse-mode only.

Figure 5-14 designates the two core routers both as RP candidates and mapping agents.

Figure 5-14. Auto-RP and Mapping Agent Fault-Tolerance

In Example 5-1, both Routers A and B are active mapping agents. Router A is the RP for group 224.2.2.2, and Router B is the RP for group 224.1.1.1, thus providing load sharing of the two multicast groups between the RPs. Because Router A's Loopback 1 interface has a higher-value IP address for group 224.2.2.2 than Router B's Loopback 0 interface, Router A is elected RP for group 224.2.2.2. Additionally, because Router B's Loopback 0 interface has a higher-value IP address for group 224.1.1.1 than Router A's Loopback 0 interface, Router B is elected RP for group 224.1.1.1.

This configuration also provides redundancy between the mapping agents and RPs because, if one of the routers fails, the other takes over group and mapping-agent responsibilities.

Example 5-1. Configuring Auto-RP and Mapping Agent Fault-Tolerance

 Router A ip multicast-routing access-list 1 224.1.1.0 255.255.255.0 access-list 2 224.2.2.0 255.255.255.0 interface loopback 0  ip address 10.1.1.1 255.255.255.0  ip pim sparse-dense-mode interface loopback 1  ip address 10.3.3.3 255.255.255.0  ip pim sparse-dense-mode ip pim send-rp-announce interface loopback 0 group-list 1 ip pim send-rp-announce interface loopback 1 group-list 2 ip pim send-rp-discovery interface loopback 0 Router B ip multicast-routing access-list 1 224.1.1.0 255.255.255.0 access-list 1 224.2.2.0 255.255.255.0 interface loopback 0  ip address 10.2.2.2 255.255.255.0  ip pim sparse-dense-mode ip pim send-rp-announce interface loopback 0 group-list 1 ip pim send-rp-discovery interface loopback 0 

Bootstrap Routers

PIM version 2 introduces a standards-based mechanism for RP fault tolerance and scalability. With PIMv2, BSRs provide automatic discovery and distribution of RP-to-group mappings. Use Auto-RP if you have only Cisco routers in your network. Otherwise, use BSR if you have any non-Cisco routers and require RP fault tolerance and scalability.

BSR candidates are the mapping agents and announce themselves to PIM routers by sending PIM Bootstrap messages to the all-PIM-routers group address 224.0.0.13. Routers do not distribute messages sent to this address using dense-mode multicast. Rather, when PIMv2 routers receive PIM Bootstrap messages on a local interface to this address, they forward the message out all interfaces except the originating interface. This hop-by-hop forwarding avoids having to multicast the candidacy information throughout the network by using dense-mode flooding.

Note

An advantage of BSR over Auto-RP is that you can configure interfaces to operate only in sparse mode by issuing the ip pim sparse-mode command. This is because BSR messages are flooded hop-by-hop and not by using dense-mode flooding.

All routers in the PIM domain (including the RP candidates) receive the PIM Bootstrap messages and choose the BSR themselves based on the candidate with the lowest configured priority value. Because candidate RPs are aware of the IP address of the BSR, they unicast the groups they serve to the BSR directly. In turn, the BSRs forward the RPs-to-group mappings to the PIM routers hop-by-hop. The PIM routers choose the best RP-to-group mappings themselves using the priority values you configure for the RP candidates. In contrast, the Auto-RP mapping agents elect the appropriate RP-to-group mappings before advertising the mappings to the network

You can assign one or more routers as a BSR using the global configuration command ip pim bsr-candidate. To assign one or more routers as RP candidates, use the global configuration command ip pim rp-candidate. If you configure multiple RPs to serve the same group, PIMv2 will load-share requests across them. When last-hop PIM routers receive the sender's multicast data, to choose which RP to select for the group traffic, they perform a hash on the sending source and group address. The router uses the result of the hash function as the index into a table of candidate RPs for the group. The hash function is deterministic in that all PIM routes hash to the same RP for a particular group. As with Auto-RP, only one RP per group is in use at any time. You can set an RP to take priority over another by specifying a priority level in the ip pim rp-candidate command. The router selects the RP with the lowest configured priority value. If the priority values are the same, the router chooses the RP by the hash value. If both the priority and hash values are the same, then the PIM routers choose the RP with the lowest IP address.

In Example 5-2, Router B is the BSR, because it has a higher priority (200) configured than Router B (100). Based on the priority values, Router A is the RP for groups within 224.1.1.0/24, and Router B is the RP for groups within 224.2.2.0/24. Because Router A has a higher priority value (200) for group 224.2.2.2 than Router B (150), Router A is elected RP for group 224.2.2.2. Additionally, because Router B has a higher priority value (150) for group 224.1.1.1 than Router A (100), Router B is elected RP for group 224.1.1.1. Note that the Loopback IP addresses in Example 5-2 are used by the last-hop PIM routers to reach the RPs, not to select which RP to send the PIM Join message to.

Example 5-2. Configuring PIM Version 2 BSR and RP Fault-Tolerance

 Router A ip multicast-routing access-list 1 224.1.1.0 255.255.255.0 access-list 2 224.2.2.0 255.255.255.0 interface loopback 0     ip address 10.1.1.1 255.255.255.0     ip pim sparse-mode ip pim bsr-candidate loopback 0 24 100 ip pim rp-candidate loopback 0 group-list 1 priority 100 ip pim rp-candidate loopback 0 group-list 2 priority 200  Router B ip multicast-routing access-list 1 224.1.1.0 255.255.255.0 access-list 1 224.2.2.0 255.255.255.0 interface loopback 0  ip address 10.2.2.2 255.255.255.0  ip pim sparse-dense-mode ip pim bsr-candidate loopback 0 24 200 ip pim rp-candidate loopback 0 group-list 1 priority 150 

Although you can configure multiple RPs per group with Auto-RP and BSR, only one is active at any given time. Only when the active RP fails will the other RP for the group take over. This provides load sharing and not load balancing. Load sharing means that RPs serve different groups but share the overall multicast traffic load. For example, Router A serving 224.2.2.2 and Router B serving 224.1.1.1 provide load sharing of the total load of the two groups. Load balancing would have both routers serving 224.2.2.2, with the PIM routers distributing requests for the group between the two RPs. Unfortunately, neither Auto-RP nor BSR supports load balancing across multiple RPs for the same group. To provide true RP load balancing, you can use Anycast RP with the Multicast Source Discovery Protocol (MSDP).

Configuring Inter-Domain Multicast with Multicast Source Discovery Protocol

You can use MSDP to advertise sources between PIM-SM domains. Recall that, with PIM-SM, a source multicast stream is encapsulated in PIM Register messages by the first-hop DR and sent to the RP for the domain. The RP decapsulates the traffic and forwards the multicast data down the local shared tree. With MSDP, RPs of different domains maintain TCP connections between one another to advertise their sources across domains.

Figure 5-15 illustrates how RPs communicate source traffic across three domains.

Figure 5-15. Multicast Delivery Across PIM Domains Using MSDP

In Figure 5-15, when RP A receives the source multicast PIM Register messages, it determines that it has a (*, G) entry in its PIM table for the group, decapsulates the traffic, and forwards it down the shared tree for the Receiver A. RP A then reencapsulates the first data packet into MSDP Source Active (SA) messages and forwards it to remote RP B. When the RP B receives the traffic, it first verifies the peer using a modified version of RPF. The modified RPF includes RP B performing a lookup into its BGP RIB table or MBGP table to determine the next-hop peer (RPF peer) for the domain that the MSDP SA message originated from. If the RPF peer is not in the direction of the originating MSDP peer, RP B drops the SA message to avoid loops. Otherwise, RP B decapsulates the packets, forwards them down the local shared tree to Receiver B, and joins the SPT to the source. When Receiver B receives the traffic, it too joins the SPT to the source and sends a RP-bit PIM Prune message to RP B to remove RP B from the SPT.

RP B then floods the MSDP SA message using peer-RPF flooding. With peer-RPF flooding, RP B floods the MSDP SA messages to all MSDP peers except to the peer that it originated from. That is, in this example, RP B floods the MSDP SA message to RP C. In turn, RP C performs the RPF check to verify the message received from RP B and then decapsulates the data and forwards the traffic to members of the group (Receiver C).

Anycast RP

BSR and Auto-RP allow only a single active RP per group. All other candidate RPs are backups to the active RP. To load balance requests for RP serving the same group, you can use Anycast RP.

With Anycast RP, you configure your RP candidates with the same IP address. When the first- and last-hop PIM routers send registers and joins to the shared RP IP address, they use the underlying IGP to route the packets to the candidate RP closest to the originating PIM router. The router selects the route with the best metrics. In case your routers have equal-cost routes to the RP, you should enable CEF per-flow load balancing. Most PIM messages do not span multiple packets, but if they did, per-packet load balancing would distribute the multipacket message to both RPs, causing both RPs to drop the request.

To enable Anycast RP, you must first configure MSDP to connect the candidate RPs together. The candidate RPs must be aware of all the groups that the other RPs serve. Otherwise, if the IGP forwards the PIM Join message of a group to a different RP than it sends the PIM Register messages to, the session is not established. Figure 5-16 illustrates the MSDP requirement for Anycast RP.

Figure 5-16. Using Anycast RP to Provide Per-Group Load Balancing Across Multiple RPs

In Figure 5-16, when RP A receives the PIM Register messages from the sender, it determines that it does not have an entry (*, G) in its PIM tables (that is, it has not received any PIM Join messages from interested receivers). As a result, RP A peer-RPF floods the register as an MSDP SA message to RP B. Because RP B has an entry for (*, G), it decapsulates the MSDP SA message, forwards the traffic down its shared tree to the receiver, and joins the SPT to the source. When the last-hop router receives the traffic, it joins the SPT to the source and forwards a PIM RP-bit Prune to RP B to remove RP B from the SPT.

Note

Global Server Load Balancing also uses the IGP Anycast for global site selection, as described in Chapter 12, "Exploring Global Server Load Balancing."

Layer 2 Multicast Protocols

For switched environments, to avoid duplicating multicast traffic on LAN switch ports, you can use either Cisco Group Management Protocol (CGMP) or IGMP Snooping.

Cisco Group Management Protocol (CGMP)

To reduce multicast traffic at Layer 2, you can configure CGMP between routers and switches (that is, you do not configure CGMP between hosts and routers). When a router receives an IGMP join message from a receiver, it sends a CGMP Join message to the switch. The CGMP Join message includes two MAC addresses: one for the receiver and the other for the multicast group. The switch then looks up the receiver MAC (from the CGMP join packet) in its MAC address table to deduce the switch port number that the receiver is located on. The switch then adds an entry in its MAC forwarding table for the multicast group MAC and receiver switch port. Figure 5-17 illustrates the CGMP process of learning the multicast MAC address and receiving switch ports.

Figure 5-17. CGMP Operation

In Figure 5-17, the receiver with MAC 0050.ba28.0f6b on port 11 of the switch sends an IGMP join for group 224.2.2.2 with group MAC address 0100.5e02.0202. The switch then generates the entry [0010.3be4.21fd, port 11] for the receiver. When the router receives the IGMP Join, it sends a CGMP Join to the switch. The switch then generates the entry [0100.5e02.0202, port 11] based on the CGMP join that it receives from the router.

IGMP Snooping

For IGMP Snooping, the switch inspects Layer 3 information of the IGMP packet directly and builds the MAC entries for multicast groups based on information that it inspects. You should enable IGMP Snooping on high-end switches only, such as the Catalyst 4000 and 6000-series switches, because they have dedicated ASICS for multicast inspection. IGMP Snooping also inspects CGMP join messages generated by routers, thereby allowing you to enable both CGMP capabilities in conjunction with standard IGMP snooping.

Router-Port Group Management Protocol

CGMP and IGMP Snooping are appropriate for networks where Layer 3 routers are at the core/ distribution layer and Layer 2 switches are at the access layer. However, if Layer 2 switches are located in the core of your network and routers are at the access layer, you should use Router-Port Group Management Protocol (RGMP) to limit multicast traffic to the necessary switch ports in the core. Neither IGMP snooping nor CGMP are useful in the network illustrated in Figure 5-18 because both work by using IGMP Join messages. You can configure your router with RGMP to indicate to the core switch that it wants to receive traffic from a particular multicast group. When a receiver sends an IGMP Join to the router, the router generates and sends an RGMP join to the switch, in addition to forwarding the PIM join from the receiver destined to the RP. In Figure 5-18, the switch populates its forwarding tables using the RGMP join.

Figure 5-18. RGMP Operation