- Finding Feature Information
- Prerequisites for Configuring Basic IP Multicast
- Information About Configuring Basic IP Multicast
Configuring Basic IP Multicast
IP multicast is a bandwidth-conserving technology that reduces traffic by delivering a single stream of information simultaneously to potentially thousands of corporate businesses and homes. Applications that take advantage of multicast include video conferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news. This module describes the tasks used to configure basic IP multicast.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Configuring Basic IP Multicast
- Before performing the tasks in this module, you should be familiar with the concepts explained in the "IP Multicast Technology Overview" module.
- To determine which of the tasks contained in this module you will have to perform, you must decide which Protocol Independent Multicast (PIM) mode will be used. This determination is based on the applications you intend to support on your network.
- All access lists you intend to use with the tasks in this module should be configured prior to beginning the configuration task. For information about how to configure an access list, see the " Creating an IP Access List and Applying It to an Interface " module.
Information About Configuring Basic IP Multicast
Auto-RP Overview
The Role of Auto-RP in a PIM Network
Auto-RP automates the distribution of group-to-rendezvous point (RP) mappings in a PIM network. To make Auto-RP work, a router must be designated as an RP mapping agent, which receives the RP announcement messages from the RPs and arbitrates conflicts. The RP mapping agent then sends the consistent group-to-RP mappings to all other routers by way of dense mode flooding.
Thus, all routers automatically discover which RP to use for the groups they support. The Internet Assigned Numbers Authority (IANA) has assigned two group addresses, 224.0.1.39 and 224.0.1.40, for Auto-RP.
The mapping agent receives announcements of intention to become the RP from Candidate-RPs. The mapping agent then announces the winner of the RP election. This announcement is made independently of the decisions by the other mapping agents.
IP Multicast Boundary
As shown in the figure, address scoping defines domain boundaries so that domains with RPs that have the same IP address do not leak into each other. Scoping is performed on the subnet boundaries within large domains and on the boundaries between the domain and the Internet.
| Figure 1 | Address Scoping at Boundaries |
You can set up an administratively scoped boundary on an interface for multicast group addresses using the ip multicast boundary command with the access-list argument. A standard access list defines the range of addresses affected. When a boundary is set up, no multicast data packets are allowed to flow across the boundary from either direction. The boundary allows the same multicast group address to be reused in different administrative domains.
The Internet Assigned Numbers Authority (IANA) has designated the multicast address range 239.0.0.0 to 239.255.255.255 as the administratively scoped addresses. This range of addresses can be reused in domains administered by different organizations. They would be considered local, not globally unique.
You can configure the filter-autorp keyword to examine and filter Auto-RP discovery and announcement messages at the administratively scoped boundary. Any Auto-RP group range announcements from the Auto-RP packets that are denied by the boundary access control list (ACL) are removed. An Auto-RP group range announcement is permitted and passed by the boundary only if all addresses in the Auto-RP group range are permitted by the boundary ACL. If any address is not permitted, the entire group range is filtered and removed from the Auto-RP message before the Auto-RP message is forwarded.
Benefits of Auto-RP in a PIM Network
- Auto-RP allows any change to the RP designation to be configured only on the routers that are RPs, not on the leaf routers.
- Auto-RP offers the ability to scope the RP address within a domain. Scoping can be achieved by using the ip multicast boundary command with the filter-autorp keyword.
Anycast RP Overview
Anycast RP is a useful application of MSDP. Originally developed for interdomain multicast applications, MSDP used for Anycast RP is an intradomain feature that provides redundancy and load-sharing capabilities. Enterprise customers typically use Anycast RP for configuring a Protocol Independent Multicast sparse mode (PIM-SM) network to meet fault tolerance requirements within a single multicast domain.
In anycast RP, two or more RPs are configured with the same IP address on loopback interfaces. The anycast RP loopback address should be configured with a 32-bit mask, making it a host address. All the downstream routers should be configured so that the anycast RP loopback address is the IP address of their local RP. IP routing will automatically select the topologically closest RP for each source and receiver. Assuming that the sources are evenly spaced around the network, an equal number of sources will register with each RP. That is, the process of registering the sources will be shared equally by all the RPs in the network.
Because a source may register with one RP and receivers may join to a different RP, a method is needed for the RPs to exchange information about active sources. This information exchange is done with MSDP.
In anycast RP, all the RPs are configured to be MSDP peers of each other. When a source registers with one RP, an SA message will be sent to the other RPs informing them that there is an active source for a particular multicast group. The result is that each RP will know about the active sources in the area of the other RPs. If any of the RPs were to fail, IP routing would converge, and one of the RPs would become the active RP in more than one area. New sources would register with the backup RP. Receivers would join the new RP and connectivity would be maintained.
The RP is normally needed only to start new sessions with sources and receivers. The RP facilitates the shared tree so that sources and receivers can establish a direct multicast data flow. If a multicast data flow is already established between a source and the receiver, an RP failure will not affect that session. Anycast RP ensures that new sessions with sources and receivers can begin at any time.
BSR Overview
BSR Election and Functionality
PIM uses the BSR to discover and announce RP-set information for each group prefix to all the routers in a PIM domain. This is the same function performed by Auto-RP, but the BSR is part of the PIM Version 2 specification. The BSR mechanism interoperates with Auto-RP on Cisco routers.
To avoid a single point of failure, you can configure several candidate BSRs in a PIM domain. A BSR is elected among the candidate BSRs automatically; they use bootstrap messages to discover which BSR has the highest priority. This router then announces to all PIM routers in the PIM domain that it is the BSR.
Following the election of the BSR, candidate RPs use unicast to announce to the BSR their willingness to be the RP. The BSR advertises the entire group-to-RP mapping set to the router link local address 224.0.0.13. Unlike the RP mapping agent in Auto-RP, which is used by Auto-RP to select the RP, every router in the BSR network is responsible for selecting the RP.
BSR lacks the ability to scope RP advertisements; however, BSR is used when vendor interoperability or open standard adherence is a requirement.
BSR Border Interface
A border interface in a PIM sparse mode domain requires precautions to prevent exchange of certain traffic with a neighboring domain reachable through that interface, especially if that domain is also running PIM sparse mode. BSR and Auto-RP messages should not be exchanged between different domains, because routers in one domain may elect RPs in the other domain, resulting in protocol malfunction or loss of isolation between the domains. Configure a BSR border interface to prevent BSR messages from being sent or received through an interface.
Static RP Overview
If you are configuring PIM sparse mode, you must configure a PIM RP for a multicast group. An RP can either be configured statically in each device, or learned through a dynamic mechanism. This task explains how to statically configure an RP, as opposed to the router learning the RP through a dynamic mechanism such as Auto-RP.
PIM designated routers (DRs) forward data from directly connected multicast sources to the RP for distribution down the shared tree. Data is forwarded to the RP in one of two ways. It is encapsulated in register packets and unicast directly to the RP, or, if the RP has itself joined the source tree, it is multicast forwarded per the RPF forwarding algorithm. Last hop routers directly connected to receivers may, at their discretion, join themselves to the source tree and prune themselves from the shared tree.
A single RP can be configured for multiple groups that are defined by an access list. If no RP is configured for a group, the router treats the group as dense using the PIM dense mode techniques. (You can prevent this occurrence by configuring the no ip pim dm-fallbackcommand.)
If dynamic and static group-to-RP mappings are used together and there is an RP address conflict, the RP address configured for a static group-to-RP mapping (with the ip pim rp-address overridecommand) will take precedence.
 Note |
If the override keyword is not specified and there is RP address conflict, dynamic group-to-RP mappings will take precedence over static group-to-RP mappings. |
Bidir-PIM Overview
Bidir-PIM shares many of its shortest path tree (SPT) operations with PIM-SM. Bidir-PIM also has unconditional forwarding of source traffic toward the RP upstream on the shared tree, but has no registering process for sources as in PIM-SM. These modifications allow forwarding of traffic in all routers based solely on the (*, G) multicast routing entries. This form of forwarding eliminates any source-specific state and allows scaling capability to an arbitrary number of sources.
- Multicast Group Modes
- Bidirectional Shared Tree
- DF Election
- Bidirectional Group Tree Building
- Packet Forwarding
- Benefits of Bidirectional PIM
Multicast Group Modes
In PIM, packet traffic for a multicast group is routed according to the rules of the mode configured for that multicast group. The Cisco implementation of PIM supports four modes for a multicast group:
- PIM bidirectional mode
- PIM dense mode
- PIM sparse mode
- PIM Source Specific Mode (SSM)
A router can simultaneously support all four modes or any combination of them for different multicast groups.
Bidirectional Shared Tree
In bidirectional mode, traffic is routed only along a bidirectional shared tree that is rooted at the rendezvous point (RP) for the group. In bidir-PIM, the IP address of the RP acts as the key to having all routers establish a loop-free spanning tree topology rooted in that IP address. This IP address need not be a router, but can be any unassigned IP address on a network that is reachable throughout the PIM domain. This technique is the preferred configuration method for establishing a redundant RP configuration for bidir-PIM.
Membership in a bidirectional group is signaled by way of explicit Join messages. Traffic from sources is unconditionally sent up the shared tree toward the RP and passed down the tree toward the receivers on each branch of the tree.
The figures below show the difference in state created per router for a unidirectional shared tree and source tree versus a bidirectional shared tree.
| Figure 2 | Unidirectional Shared Tree and Source Tree |
| Figure 3 | Bidirectional Shared Tree |
For packets that are forwarded downstream from the RP toward receivers, there are no fundamental differences between bidir-PIM and PIM-SM. Bidir-PIM deviates substantially from PIM-SM for traffic that is passed from sources upstream toward the RP.
PIM-SM cannot forward traffic in the upstream direction of a tree because it accepts traffic from only one Reverse Path Forwarding (RPF) interface. This interface (for the shared tree) points toward the RP, thus allowing only downstream traffic flow. Upstream traffic is first encapsulated into unicast register messages, which are passed from the designated router (DR) of the source toward the RP. Second, the RP joins an SPT that is rooted at the source. Therefore, in PIM-SM, traffic from sources destined for the RP does not flow upstream in the shared tree, but downstream along the SPT of the source until it reaches the RP. From the RP, traffic flows along the shared tree toward all receivers.
In bidir-PIM, the packet-forwarding rules have been improved over PIM-SM, allowing traffic to be passed up the shared tree toward the RP. To avoid multicast packet looping, bidir-PIM introduces a new mechanism called designated forwarder (DF) election, which establishes a loop-free SPT rooted at the RP.
DF Election
On every network segment and point-to-point link, all PIM routers participate in a procedure called designated forwarder (DF) election. The procedure selects one router as the DF for every RP of bidirectional groups. This router is responsible for forwarding multicast packets received on that network.
The DF election is based on unicast routing metrics. The router with the most preferred unicast routing metric to the RP becomes the DF. Use of this method ensures that only one copy of every packet will be sent to the RP, even if there are parallel equal-cost paths to the RP.
A DF is selected for every RP of bidirectional groups. As a result, multiple routers may be elected as DF on any network segment, one for each RP. Any particular router may be elected as DF on more than one interface.
Bidirectional Group Tree Building
The procedure for joining the shared tree of a bidirectional group is almost identical to that used in PIM-SM. One main difference is that, for bidirectional groups, the role of the DR is assumed by the DF for the RP.
On a network that has local receivers, only the router elected as the DF populates the outgoing interface list (olist) upon receiving Internet Group Management Protocol (IGMP) Join messages, and sends (*, G) Join and Leave messages upstream toward the RP. When a downstream router wishes to join the shared tree, the RPF neighbor in the PIM Join and Leave messages is always the DF elected for the interface that lead to the RP.
When a router receives a Join or Leave message, and the router is not the DF for the receiving interface, the message is ignored. Otherwise, the router updates the shared tree in the same way as in sparse mode.
In a network where all routers support bidirectional shared trees, (S, G) Join and Leave messages are ignored. There is also no need to send PIM assert messages because the DF election procedure eliminates parallel downstream paths from any RP. An RP never joins a path back to the source, nor will it send any register stops.
Packet Forwarding
A router creates (*, G) entries only for bidirectional groups. The olist of a (*, G) entry includes all the interfaces for which the router has been elected DF and that have received either an IGMP or PIM Join message. If a router is located on a sender-only branch, it will also create a (*, G) state, but the olist will not include any interfaces.
If a packet is received from the RPF interface toward the RP, the packet is forwarded downstream according to the olist of the (*, G) entry. Otherwise, only the router that is the DF for the receiving interface forwards the packet upstream toward the RP; all other routers must discard the packet.
Benefits of Bidirectional PIM
- Bidir-PIM removes the performance cost of maintaining a routing state table for a large number of sources.
- Bidir-PIM is designed to be used for many-to-many applications within individual PIM domains. Multicast groups in bidirectional PIM mode can scale to an arbitrary number of sources without incurring overhead due to the number of sources.
How to Configure Basic IP Multicast
The tasks described in this section configure the basic IP multicast modes. No single task in this section is required; however, at least one of the tasks must be performed to configure IP multicast in a network. More than one of the tasks may be needed.
- Configuring Sparse Mode with Auto-RP
- Configuring Sparse Mode with Anycast RP
- Configuring Sparse Mode with a Bootstrap Router
- Configuring Sparse Mode with a Single Static RP
- Configuring Bidirectional PIM
Configuring Sparse Mode with Auto-RP
This section contains information about and instructions on how to configure auto-rendezvous point (Auto-RP). Auto-RP can also be optionally used with anycast RP.
Note |
The simultaneous deployment of Auto-RP and bootstrap router (BSR) is not supported. |
- When configuring Auto-RP, you must either configure the Auto-RP listener feature using the ip pim autorp listener command (Step 5) and specify sparse mode using the ip pim sparse-mode command (Step 7) or specify sparse-dense mode (Step 8) using the ip pim sparse-dense mode command.
Note |
When you configure sparse-dense mode, dense mode failover may result in a network dense-mode flood. To avoid this condition, use PIM sparse mode with the Auto-RP listener feature. |
- An interface configured in sparse-dense mode is treated in either sparse mode or dense mode of operation, depending on the mode in which the multicast group operates. You must decide how to configure your interfaces.
- All access lists that are needed when Auto-RP is configured should be configured prior to beginning the configuration task. For information about how to configure an access list, see the " Creating an IP Access List and Applying It to an Interface " module.
- If a group has no known RP and the interface is configured to be sparse-dense mode, the interface is treated as if it were in dense mode, and data is flooded over the interface. To avoid this data flooding, configure the Auto-RP listener using the ip pim autorp listener command and then configure the interface as sparse mode using the ip pim sparse mode command.
DETAILED STEPS
What to Do Next
Proceed to the " Verifying IP Multicast Operation " module.
Configuring Sparse Mode with Anycast RP
This section describes how to configure sparse mode with anycast RP for RP redundancy.
Anycast RPs are configured statically, and interfaces are configured to operate in Protocol Independent Multicast-Sparse Mode (PIM-SM). In an anycast RP configuration, two or more RPs are configured with the same IP address on loopback interfaces. The Anycast RP loopback address should be configured with a 32-bit mask, making it a host address. An Anycast RP configuration is easy to configure and troubleshoot because the same host address is used as the RP address regardless of which router it is configured on.
Anycast RP allows two or more rendezvous points (RPs) to share the load for source registration and have the ability to act as hot backup routers for each other. Multicast Source Discovery Protocol (MSDP) is the key protocol that makes anycast RP possible.
| Figure 4 | MSDP Sharing Source Information Between RPs in Each Domain |
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# ip multicast-routing |
Enables IP multicast routing. |
|
|
Example: Router(config)# interface gigabitethernet 1/0/0 |
Selects an interface that is connected to hosts on which PIM can be enabled. |
|
|
Example: Router(config-if)# ip pim sparse-mode |
Enables sparse mode. |
|
|
Example: Router(config-if)# ip pim rp-address 10.0.0.1 |
Configures the address of a PIM RP for a particular group. |
|
|
|
-- |
|
|
Example: Router(config-if)# interface loopback 0 Example: ip address 10.0.0.1 255.255.255.255 |
Configures the interface loopback IP address for the RP router. |
|
|
Example: Router(config-if)# interface loopback 1 Example: ip address 10.1.1.1 255.255.255.255 |
Configures the interface loopback IP address for MSDP peering. |
|
|
Example: Router(config-if)# exit |
Exits interface configuration mode and returns to global configuration mode. |
|
|
Example: Router(config)# ip msdp peer 10.1.1.2 connect-source loopback 1 |
Configures an MSDP peer. |
|
|
Example: Router(config)# ip msdp originator-id loopback 1 |
Allows an MSDP speaker that originates a SA message to use the IP address of the interface as the RP address in the SA message. |
|
|
|
-- |
What to Do Next
Proceed to the " Verifying IP Multicast Operation " module.
Configuring Sparse Mode with a Bootstrap Router
This section describes how to configure a bootstrap router (BSR), which provides a fault-tolerant, automated RP discovery and distribution mechanism so that routers learn the group-to-RP mappings dynamically.
Note |
The simultaneous deployment of Auto-RP and BSR is not supported. |
DETAILED STEPS
| Command or Action | Purpose | |||||
|---|---|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
||||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||||
|
|
Example: Router(config)# ip multicast-routing |
Enables IP multicast routing.
|
||||
|
|
Example: Router(config)# interface gigabitethernet 1/0/0 |
Selects an interface that is connected to hosts on which PIM can be enabled. |
||||
|
|
Example: Router(config-if)# ip pim sparse-mode |
Enables sparse mode. |
||||
|
|
Example: Router(config-if)# end |
Returns to global configuration mode. |
||||
|
|
|
-- |
||||
|
|
Example: Router(config)# ip pim bsr-candidate gigibitethernet 0/0/0 0 192 |
Configures the router to announce its candidacy as a bootstrap router (BSR).
|
||||
|
|
Example: Router(config)# ip pim rp-candidate gigabitethernet 2/0/0 group-list 4 priority 192 |
Configures the router to advertise itself as a PIM Version 2 candidate RP to the BSR.
|
||||
|
|
|
-- |
||||
|
|
Example: Router(config)# interface gigabitethernet 1/0/0 |
Selects an interface that is connected to hosts on which PIM can be enabled. |
||||
|
|
Example: Router(config-if)# ip pim bsr-border |
Prevents the bootstrap router (BSR) messages from being sent or received through an interface.
|
||||
|
|
Example: Router(config-if)# end |
Ends the current configuration session and returns to privileged EXEC mode. |
||||
|
|
|
-- |
||||
|
|
Example: Router# show ip pim rp |
(Optional) Displays active rendezvous points (RPs) that are cached with associated multicast routing entries. |
||||
|
|
Example: Router# show ip pim rp-hash 239.1.1.1 |
(Optional) Displays which rendezvous point (RP) is being selected for a specified group. |
||||
|
|
Example: Router# show ip pim bsr-router |
(Optional) Displays the bootstrap router (BSR) information. |
||||
|
|
Example: Router# show ip igmp groups |
(Optional) Displays the multicast groups having receivers that are directly connected to the router and that were learned through IGMP.
|
||||
|
|
Example: Router# show ip mroute cbone-audio |
(Optional) Displays the contents of the IP mroute table. |
What to Do Next
Proceed to the " Verifying IP Multicast Operation " module.
Configuring Sparse Mode with a Single Static RP
A rendezvous point (RP) is required in networks running Protocol Independent Multicast sparse mode (PIM-SM). In PIM-SM, traffic will be forwarded only to network segments with active receivers that have explicitly requested multicast data.
This section describes how to configure sparse mode with a single static RP.
All access lists that are needed when sparse mode is configured with a single static RP should be configured prior to beginning the configuration task.
Note |
The same RP address cannot be used for both bidirectional and sparse mode PIM groups. |
DETAILED STEPS
| Command or Action | Purpose | |||||
|---|---|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||||
|
|
Example: Router(config)# ip multicast-routing |
Enables IP multicast routing. |
||||
|
|
Example: Router(config)# interface gigabitethernet 1/0/0 |
Selects an interface that is connected to hosts on which PIM can be enabled.
|
||||
|
|
Example: Router(config-if)# ip pim sparse-mode |
Enables PIM on an interface. You must use sparse mode. |
||||
|
|
|
-- |
||||
|
|
Example: Router(config-if)# exit |
Returns to global configuration mode. |
||||
|
|
Example: Router(config)# ip pim rp-address 192.168.0.0 |
Configures the address of a PIM RP for a particular group.
|
||||
|
|
Example: Router(config)# end |
Ends the current configuration session and returns to EXEC mode. |
||||
|
|
Example: Router# show ip pim rp mapping |
(Optional) Displays RPs known in the network and shows how the router learned about each RP. |
||||
|
|
Example: Router# show ip igmp groups |
(Optional) Displays the multicast groups having receivers that are directly connected to the router and that were learned through IGMP. |
||||
|
|
Example: Router# show ip mroute |
(Optional) Displays the contents of the IP mroute table. |
What to Do Next
Proceed to the " Verifying IP Multicast Operation " module.
Configuring Bidirectional PIM
This section describes how to configure bidirectional PIM (bidir-PIM).
All access lists needed when configuring bidirectional PIM must be configured prior to beginning the configuration task.
DETAILED STEPS
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||
|
|
Example: Router(config)# ip multicast-routing |
Enables IP multicast routing.
|
||
|
|
Example: Router(config)# interface gigabitethernet 1/0/0 |
Selects an interface that is connected to hosts on which PIM can be enabled. |
||
|
|
Example: Router(config-if)# ip pim sparse-mode |
Enables sparse mode. |
||
|
|
Example: Router(config-if)# exit |
Returns to global configuration mode. |
||
|
|
Example: Router(config)# ip pim bidir-enable |
Enables bidir-PIM on a router.
|
||
|
|
Example: Router(config)# ip pim rp-address 10.0.1.1 45 bidir |
Configures the address of a PIM RP for a particular group.
|
||
|
|
Example: Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
||
|
|
|
-- |
||
|
|
Example: Router# show ip pim rp |
(Optional) Displays active RPs that are cached with associated multicast routing entries. |
||
|
|
Example: Router# show ip mroute |
(Optional) Displays the contents of the IP mroute table. |
||
|
|
Example: Router# show ip pim interface |
(Optional) Displays information about the elected DF for each RP of an interface, along with the unicast routing metric associated with the DF. |
Configuration Examples for Basic IP Multicast
- Sparse Mode with Auto-RP Example
- Sparse Mode with Anycast RP Example
- Sparse Mode with Bootstrap Router Example
- BSR and RFC 2362 Interoperable Candidate RP Example
- Sparse Mode with a Single Static RP Example
- Bidir-PIM Example
Sparse Mode with Auto-RP Example
The following example configures sparse mode with Auto-RP:
ip multicast-routing ip pim autorp listener ip pim send-rp-announce Loopback0 scope 16 group-list 1 ip pim send-rp-discovery Loopback1 scope 16 no ip pim dm-fallback access-list 1 permit 239.254.2.0 0.0.0.255 access-list 1 permit 239.254.3.0 0.0.0.255 . . . access-list 10 permit 224.0.1.39 access-list 10 permit 224.0.1.40 access-list 10 permit 239.254.2.0 0.0.0.255 access-list 10 permit 239.254.3.0 0.0.0.255
Sparse Mode with Anycast RP Example
The main purpose of an Anycast RP implementation is that the downstream multicast routers will have just one address for an RP. The example given in the figure below shows how loopback interface 0 of the RPs (RP1 and RP2) is configured with the 10.0.0.1 IP address. If this 10.0.0.1 address is configured on all RPs as the address for loopback interface 0 and then configured as the RP address, IP routing will converge on the closest RP. This address must be a host route; note the 255.255.255.255 subnet mask.
The downstream routers must be informed about the 10.0.0.1 RP address. In the figure below, the routers are configured statically with the ip pim rp-address 10.0.0.1global configuration command. This configuration could also be accomplished using the Auto-RP or bootstrap router (BSR) features.
The RPs in the figure must also share source information using MSDP. In this example, loopback interface 1 of the RPs (RP1 and RP2) is configured for MSDP peering. The MSDP peering address must be different from the anycast RP address.
| Figure 5 | AnyCast RP Configuration |
Many routing protocols choose the highest IP address on loopback interfaces for the router ID. A problem may arise if the router selects the anycast RP address for the router ID. It is recommended that you avoid this problem by manually setting the router ID on the RPs to the same address as the MSDP peering address (for example, the loopback 1 address in the figure above). In Open Shortest Path First (OSPF), the router ID is configured using the router-idrouter configuration command. In Border Gateway Protocol (BGP), the router ID is configured using the bgp router-id router configuration command. In many BGP topologies, the MSDP peering address and the BGP peering address must be the same in order to pass the RPF check. The BGP peering address can be set using the neighbor update-source router configuration command.
The anycast RP example above uses IP addresses taken from RFC 1918. These IP addresses are normally blocked at interdomain borders and therefore are not accessible to other ISPs. You must use valid IP addresses if you want the RPs to be reachable from other domains.
The following example shows how to perform an Anycast RP configuration.
On RP 1
ip pim rp-address 10.0.0.1 interface loopback 0 ip address 10.0.0.1 255.255.255.255 ! interface loopback 1 ip address 10.1.1.1. 255.255.255.255 ! ip msdp peer 10.1.1.2 connect-source loopback 1 ip msdp originator-id loopback 1
On RP 2
ip pim rp-address 10.0.0.1 interface loopback 0 ip address 10.0.0.1 255.255.255.255 interface loopback 1 ip address 10.1.1.2. 255.255.255.255 ! ip msdp peer 10.1.1.1 connect-source loopback 1 ip msdp originator-id loopback 1
All Other Routers
ip pim rp-address 10.0.0.1
Sparse Mode with Bootstrap Router Example
The following example is a configuration for a candidate BSR, which also happens to be a candidate RP:
! ip multicast-routing ! interface GigabitEthernet0/0/0 ip address 172.69.62.35 255.255.255.240 ip pim sparse-mode ! interface GigabitEthernet1/0/0 ip address 172.21.24.18 255.255.255.248 ip pim sparse-mode ! interface GigabitEthernet2/0/0 ip address 172.21.24.12 255.255.255.248 ip pim sparse-mode ! ip pim bsr-candidate GigabitEthernet2/0/0 30 10 ip pim rp-candidate GigabitEthernet2/0/0 group-list 5 access-list 5 permit 239.255.2.0 0.0.0.255
BSR and RFC 2362 Interoperable Candidate RP Example
When Cisco and non-Cisco routers are being operated in a single PIM domain with PIM Version 2 BSR, care must be taken when configuring candidate RPs because the Cisco implementation of the BSR RP selection is not fully compatible with RFC 2362.
RFC 2362 specifies that the BSR RP be selected as follows (RFC 2362, 3.7):
- Select the candidate RP with the highest priority (lowest configured priority value).
- If there is a tie in the priority level, select the candidate RP with the highest hash function value.
- If there is a tie in the hash function value, select the candidate RP with the highest IP address.
Cisco routers always select the candidate RP based on the longest match on the announced group address prefix before selecting an RP based on priority, hash function, or IP address.
Inconsistent candidate RP selection between Cisco and non-Cisco RFC 2362-compliant routers in the same domain if multiple candidate RPs with partially overlapping group address ranges are configured can occur. Inconsistent candidate RP selection can prevent connectivity between sources and receivers in the PIM domain. A source may register with one candidate RP and a receiver may connect to a different candidate RP even though it is in the same group.
The following example shows a configuration that can cause inconsistent RP selection between a Cisco and a non-Cisco router in a single PIM domain with PIM Version 2 BSR:
access-list 10 permit 224.0.0.0 7.255.255.255 ip pim rp-candidate gigabitethernet1/0/0 group-list 10 priority 20 access-list 20 permit 224.0.0.0 15.255.255.255 ip pim rp-candidate gigabitethernet2/0/0 group-list 20 priority 10
In this example, a candidate RP on GigabitEthernet interface 1/0/0 announces a longer group prefix of 224.0.0.0/5 with a lower priority of 20. The candidate RP on GigabitEthernet interface 2/0/0 announces a shorter group prefix of 224.0.0.0/4 with a higher priority of 10. For all groups that match both ranges a Cisco router will always select the candidate RP on Ethernet interface 1 because it has the longer announced group prefix. A non-Cisco fully RFC 2362-compliant router will always select the candidate RP on GigabitEthernet interface 2/0/0 because it is configured with a higher priority.
To avoid this interoperability issue, do not configure different candidate RPs to announce partially overlapping group address prefixes. Configure any group prefixes that you want to announce from more than one candidate RP with the same group prefix length.
The following example shows how to configure the previous example so that there is no incompatibility between a Cisco router and a non-Cisco router in a single PIM domain with PIM Version 2 BSR:
access-list 10 permit 224.0.0.0 7.255.255.255 ip pim rp-candidate gigabitethernet1/0/0 group-list 10 priority 20 access-list 20 permit 224.0.0.0 7.255.255.255 access-list 20 permit 232.0.0.0 7.255.255.255 ip pim rp-candidate gigabitethernet2/0/0 group-list 20 priority 10
In this configuration the candidate RP on Ethernet interface 2 announces group address 224.0.0.0/5 and 232.0.0.0/5 which equal 224.0.0.0/4, but gives the interface the same group prefix length (5) as the candidate RP on Ethernet 1. As a result, both a Cisco router and an RFC 2362-compliant router will select the RP Ethernet interface 2.
Sparse Mode with a Single Static RP Example
The following example sets the PIM RP address to 192.168.1.1 for all multicast groups and defines all groups to operate in sparse mode:
ip multicast-routing interface gigiabitethernet 1/0/0 ip pim sparse-mode ip pim rp-address 192.168.1.1
Note |
The same RP cannot be used for both bidirectional and sparse mode groups. |
The following example sets the PIM RP address to 172.16.1.1 for the multicast group 225.2.2.2 only:
access list 1 225.2.2.2 0.0.0.0 ip pim rp-address 172.17.1.1
Bidir-PIM Example
By default, a bidirectional RP advertises all groups as bidirectional. An access list on the RP can be used to specify a list of groups to be advertised as bidirectional. Groups with the deny keyword will operate in dense mode. A different, nonbidirectional RP address is required for groups that operate in sparse mode because a single access list only allows either a permit or deny keyword.
The following example shows how to configure an RP for both sparse mode and bidirectional mode groups. The groups identified as 224/8 and 227/8 are bidirectional groups, and 226/8 is a sparse mode group. The RP must be configured to use different IP addresses for the sparse mode and bidirectional mode operations. Two loopback interfaces are used to allow this configuration. The addresses of these loopback interfaces must be routed throughout the PIM domain in such a way that the other routers in the PIM domain can communicate with the RP.
ip multicast-routing ! . . . ! interface loopback 0 description One loopback address for this router's Bidir Mode RP function ip address 10.0.1.1 255.255.255.0 ! interface loopback 1 description One loopback address for this router's Sparse Mode RP function ip address 10.0.2.1 255.255.255.0 ! . . . ! ip pim bidir-enable ip pim rp-address 10.0.1.1 45 bidir ip pim rp-address 10.0.2.1 46 ! access-list 45 permit 224.0.0.0 0.255.255.255 access-list 45 permit 227.0.0.0 0.255.255.255 access-list 46 permit 226.0.0.0 0.255.255.255
Additional References
Related Documents
| Related Topic |
Document Title |
|---|---|
| IP multicast commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples |
Cisco IOS IP Multicast Command Reference |
Standards
| Standard |
Title |
|---|---|
| draft-kouvelas-pim-bidir-new-00.txt |
MIBs
| MIB |
MIBs Link |
|---|---|
| No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature. |
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL: |
RFCs
| RFC |
Title |
|---|---|
| RFC 1112 |
|
| RFC 1918 |
|
| RFC 2770 |
|
| RFC 3569 |
Technical Assistance
| Description |
Link |
|---|---|
| The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |
Feature Information for Configuring Basic IP Multicast
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
| Table 1 | Feature Information for Configuring Basic IP Multicast |
| Feature Name |
Releases |
Feature Information |
|---|---|---|
| AutoRP Enhancement |
12.2(33)SXH |
This feature enhancement avoids DM Fallback in the event that all RPs fail. |
| Bidirectional PIM |
12.2(17d)SXB1 |
Bidirectional PIM is an extension to the PIM suite of protocols that implements shared sparse trees with bidirectional data flow. In contrast to PIM-Sparse Mode, Bidirectional PIM avoids keeping source-specific state in a router and allows trees to scale to an arbitrary number of sources. |
| PIM Dense Mode Fallback Prevention in a Network Following RP Information Loss |
12.3(4)T 12.0(28)S 12.2(33)SRA 12.2(33)SXH 15.0(1)S |
The PIM Dense Mode Fallback Prevention in a Network Following RP Information Loss feature enables you to prevent PIM-DM fallback when all RPs fail. Preventing the use of dense mode is very important to multicast networks whose reliability is critical. This feature provides a mechanism to keep the multicast groups in sparse mode, thereby preventing dense mode flooding. The following command was introduced by this feature: ip pim dm-fallback. |
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
Feedback