Chapter 4. Protocol Independent Multicast
Chapter 3, “IP Multicast at Layer 3,” addressed the different protocol independent multicast (PIM) modes and how those modes affected the growing or building of multicast trees. You saw the significant role that the rendezvous point (RP) played in establishing PIM sparse-mode and BiDir trees. In addition, you learned that source-specific multicast (SSM) does not require the use of an RP. This chapter covers the RP design mechanisms and configuration nuances using various Cisco platforms.
RP Overview
PIM-SM uses shared trees. With shared trees, multicast distribution is rooted at the RP. The process of building a shared tree requires that the network components register active sources as well as receivers for a given multicast group to the RP. To register to the RP, routers must encapsulate data in PIM control messages and send it by unicast to the RP. The source’s upstream designated router (DR) encapsulates and sends the register packet. Remember, the DR is a router on the source’s local network. A single DR is elected from all PIM routers on a subnet so that unnecessary control messages are not sent.
It should be noted that any number of routers could be configured as an RP for a given multicast group range. When the RP is configured, this information must be available to downstream Layer 3 devices on the network so that a shared tree for a specific group can be established. In simple sparse-mode deployments, all multicast groups are mapped to a single RP. Figure 4-1 provides an example of the RP concept using a shared tree.
In this example, router R1 is defined as the RP for multicast group 239.1.1.1. The other routers in the diagram are called the downstream routers. Each of the downstream routers needs to know about the RP. The RP information contains details about the IP address the RP is using (the location of the RP) and the group addresses for which the RP will require registration. It is imperative that the router acting as RP and the downstream routers all agree whom the RP is for a given group.
The downstream routers use this information to create mappings of groups to a given RP address. This mapping is not necessarily one-to-one; there might be many RPs for different groups, or there might be only one RP for all groups. The number and placement of RPs is an administrative decision that is usually based on network scale and other best practices.
The RP-to-group mapping is a critical step in building sparse mode trees. If there is no group mapping, DRs will not be able to register group subscriptions, active sources cannot be tracked, and routers downstream will not know the direction in which to RPF check shared tree entries. In short, the shared tree will not form across the network, from the RP to the receivers, and the multicast path will fail.
Examining the following show command output from an IOS router can give us additional insight into how routers use this information:
R1#show ip pim rp 239.127.1.1
Group: 239.127.1.1, RP: 192.168.0.2, v2, v1, uptime 05:44:08, expires 00:02:53
Using the show ip pim rp address command, you see that the configured RP for multicast group 239.127.1.1 is the router with an interface using 192.168.0.2, but this only tells you what RP address the router is aware of for group 238.127.1.1. Using the show ip pim rp mapping command shows all the mappings learned by the router, even those that have been learned dynamically but are not installed. Adding the in-use option shows only those mappings that are installed in the mRIB and how the mapping was learned. Example 4-1 shows that all multicast groups are mapped to RP 192.168.0.2, and the mapping was learned dynamically through Auto-RP, a Cisco proprietary RP information distribution protocol.
Example 4-1 show ip pim rp mapping in-use Command Output
R1#show ip pim rp mapping in-use
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.168.0.2 (?), v2v1
Info source: 192.168.0.2 (?), elected via Auto-RP
Uptime: 05:44:19, expires: 00:02:42
Dynamic (Auto-RP or BSR) RPs in cache that are in use:
Group(s): 224.0.0.0/4, RP: 192.168.0.2, expires: 00:00:58
Adding a group address to the show ip pim rp mapping command provides the mapping information for that specific group; in the case of Example 4-2, the mapping is using static ACL 10.
Example 4-2 show ip pim rp mapping group-address Command Output
R1#show ip pim rp mapping 239.127.1.1
PIM Group-to-RP Mappings
Acl: 10, Static-Override
RP: 192.168.0.2 (?)
This output clearly shows that group-to-RP mappings can be learned by the router through various methods. This brings us to the concept of propagating the RP information to the downstream devices. Any inconsistencies in RP group mappings by downstream routers also cause trees to fail because downstream routers will not have the appropriate RPF or other information from which to build a share tree.
The downstream devices can learn this RP information in one of two ways: static mapping through manual configuration, or dynamic sharing and mapping through protocols. A network administrator has two protocol options for dynamic distribution: Auto-RP (Cisco proprietary) or the IETF standard bootstrap router (BSR). These RP propagation methods are considered at length in later sections of this chapter.
Similar to other IP protocols, reliability and availability are very important in any network, especially if forwarding information is being propagated dynamically. Networks often address availability, frequently called high availability (HA), through redundancy of critical systems. IP multicast networks are similar in function and RPs can be configured with HA in mind.
Figure 4-2 shows a network with HA added to the RP configuration. RP redundancy provides high availability to RP resources using shared trees. High availability in networking terms can usually be classified as active/active or active/standby. The same is true for RP redundancy configurations.
IP Multicast Domains
In order to create effective multicast designs, we need to understand the meaning and use of a multicast domain. Just like the unicast routing protocols OSPF and EIGRP, PIM routers have the capability to dynamically share information about multicast trees. For most networks, there is only one routing protocol that is used internally, the interior gateway protocol, or IGP.
When the IGP network is properly designed, most routers in the network will have the same routes in their individual routing information base (RIB). The routes may be summarized into larger entries on some routers, even as far as having only one summary (default) route on stub routers. Often, this process is controlled by the use of regions (or areas, in the case of IS-IS or OSPF). The point is that when it’s configured, the IGP dynamically provides the necessary routing information to all of the routers that need the information, and those routers interacting with each other are part of a domain.
Of course, the deployed IGP has a natural, physical boundary. When the interface of an IGP router is not configured to send/receive IGP information, that interface bounds the IGP. This serves the purpose of preventing internal routing information from leaking to routers that should not or do not need internal information.
To share routes outside the network, administrators generally use an External Gateway Protocol (EGP). If a network needs to connect to the global Internet, it will generally use Border Gateway Protocol (BGP) as the EGP. The EGP only shares essential IGP routes with external routers, so that only internal networks meant for public access are reachable by external devices. The routing process of the IGP is kept separate and secure from external influence. For most networks, the natural boundary of the internal routing domain lies between the IGP and the EGP of the network.
We often call the internal network, as it appears to the outside, an autonomous system (AS). In fact, BGP relies heavily on this concept because each public BGP network must use an assigned AS number (ASN) to participate in the global Internet. As with IP address and multicast IP group assignments, IANA assigns these ASNs to participating networks. To more deeply understand the division of networks into domains and autonomous systems, please refer to IETF RFCs 1136 and 1930.
Multicast networks also must have boundaries; however, the boundaries may be drastically different than those of the underlying unicast network. Why? It is important to remember that IP multicast networks are an overlay on the IGP network, and the network routers can only have one PIM process.
The unicast network could use multiple routing processes or even protocols through the use of redistribution. Sophisticated link-state protocols, like OSPF and IS-IS, provide built-in mechanisms for tighter controls on route sharing. PIM routers can share tree state information with any PIM neighbors and have no similar structures.
Under the definition of a domain, all PIM routers with the capability to share trees could be considered a part of the domain. Although convenient for the purposes of multicast forwarding, it may not be secure or desirable to have all multicast sources and groups available to all routers within that domain. It also may not be entirely efficient, depending on the location of sources, receivers, and RPs. PIM networks need tighter, more configurable boundaries and a different definition for a domain.
Network architects can define and create PIM domains in multiple ways. If the multicast overlay is very simple, then the domain may also be very simple. The domain could span an entire IGP network, with universal PIM neighbor relationships between all IGP routers. When required, a single RP could be used for all group mappings. In this type of domain, all multicast groups and sources would be available to all systems within the domain.
If the network requirements are more stringent, it is likely that a defined tiered domain model will be needed. Many network architects use group access requirements as a way to define a multicast domain. Let’s look at a theoretical example, in this case, Multicaster’s Bank Corporation.
Figure 4-3 shows the Multicaster’s global network. It is very likely, especially in a financial institution, that applications will require intense security between various portions of the network. For example, there might be a financial trading application that must update several local servers in real time. The security and accuracy of such information is of paramount concern. Thus, the network architect may want to define a single domain around that application.
In the case of Multicaster’s there are two data centers at each of the two major trading locations, L.A. and N.Y. Each data center must process only the local trading information and should not share multicast data flows between them. A domain with secure boundaries must then be configured for each data center.
Multicaster’s Bank Corp. system administrators also prefer to use multicast groups for local administrative tasks, or for local services like music on hold for local IP telephony systems. It would not be very secure or prudent to allow the local administrator’s multicast flows to interrupt or possibly corrupt the flows updating the trade floor application in the L.A. data center.
One effective way to divide these two types of flows into separate domains is to simply use sparse mode on all router links but to use a unique RP for each domain. With different RP structures, the routers in each domain will build trees only within that domain. Figure 4-4 takes a closer look at the L.A. location using such a model.
As discussed earlier, an RP is quantified and mapped for specific multicast groups. This multicast group presence with the mapped RP is called a multicast scope range, and that scope becomes the domain, the boundaries being any routers in the PIM network not configured with the RP information for a given group. In enterprise designs, you can have multiple scopes specific to a group. These scope ranges are aligned with RP and PIM domains. Scope ranges can superimpose over each other or be a subset of one another. Figure 4-5 illustrates a scope range.
The scope of the domain is dependent on the capability of the downstream routers to properly map group addresses to the appropriate RP. In order to build shared trees and subsequent source trees, each router in the domain must map group addresses to the same RP for a given group in that domain. As mentioned previously, if this group mapping is not consistent, or present, tree formation cannot be completed and flows will fail.
The configuration items and criteria reviewed here, especially RP propagation, availability, and scoping, are important to consider while learning dynamic RP protocols. Scoped multicast domains play a very important role in multicast design. Multicast domains and the relationships between them will be discussed in greater detail in Chapter 5.
Basic PIM Configuration
The PIM process begins when two or more routers establish a PIM neighbor adjacency on a given segment. To begin the adjacency process, any interfaces participating in multicast routing must be configured for PIM communications. To configure an IOS router interface for PIM, use the following interface level command:
ip pim { dense-mode [ proxy-register {list access-list | route-map map-name} ]
| passive | sparse-mode | sparse-dense-mode }
In IOS-XE and in NX-OS, the ip pim command is entered at the interface configuration mode. For IOS-XR, the command is entered as router pim, which enables PIM for the default context and enters the PIM configuration submode. The passive command option prevents the sending of PIM messages from this interface and instead duplicates and forwards any IGMP reports received.
Don’t forget the importance of the underlying unicast network. Because of the heavy reliance on unicast, it is wise and recommended to simply include every interface in the domain in the PIM topology. That means configuring PIM on every IP interface within the domain. As the domain, or the network grows, you can simply make the PIM configuration a network standard. There might be cases where this does not make sense; see Chapter 5 for more details.
Note
The dense-mode proxy register command option allows a dense-mode router to use a designated router to join a sparse-mode domain. The DR elected can generate and send a (*,G) register messages from the (S,G) dense-mode trees in the routers mRIB. This allows for full multicast domain participation where legacy routers cannot support sparse mode. The administrator can also assign a route map or access list to limit the groups allowed by the proxy.
Because dense-mode PIM is no longer a recommended mode for multicast networks, it is likely that most networks will be running in sparse-mode. In a sparse-mode deployment, it is not enough to have neighbor adjacencies. We also need an RP and a way to associate the group to RP mapping. As previously mentioned, RPs and group mappings can be learned statically (through manual configuration) at each router or dynamically (by using either the Auto-RP or BSR protocols for propagation).
Static RP
Enabling PIM sparse-mode using a static RP is perhaps the simplest way to configure a multicast domain. A static RP is defined through manual configuration on the RP itself and at every downstream router. The configuration, with multicast scoping (that is, multicast RP configuration with an access-list for multicast group definition), has to be defined at every downstream router in exactly the same way; otherwise, the domain will be incomplete.
Using a static RP might be a good choice for certain multicast configurations, including Anycast RP with MSDP for RP redundancy. This can also be an attractive option if the network is small. This RP mechanism does not provide any redundancy (unless coupled with Anycast RP). Anycast RP is discussed more fully in subsequent sections of this chapter.
Use the commands in Table 4-1, shown by platform, to configure a static RP.
A static RP can coexist with dynamic RP mechanisms such as Auto-RP. By default, dynamically learned RP mappings take precedence over manually configured RPs. Thus, if a router receives Auto-RP information for a multicast group that has been manually configured, the Auto-RP information will be used unless the override keyword is specified. This scenario occurs only if there are multiple RPs available for mapping to the same group(s).
Let’s look at a basic configuration example using only one static RP for all multicast group addresses. Figure 4-6 shows the network diagram for this configuration.
The following are step-by-step configuration instructions to enable PIM sparse-mode for IOS, IOS-XR and NX-OS using static RP.
The steps to configure static RP with IOS and enabling PIM sparse-mode are as follows:
Step 1. Enable IP multicast routing.
ip multicast-routing
Step 2. Enable interfaces in the Layer 3 domain, including the loopback with the ip pim sparse-mode command:
interface Loopback0
ip address 192.168.0.1 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
ip pim sparse-mode
Step 3. Add the static RP configuration:
R3(config)#ip pim rp-address 192.168.0.1 ?
<1-99> Access-list reference for group
<1300-1999> Access-list reference for group (expanded range)
WORD IP Named Standard Access list
override Overrides dynamically learnt RP mappings
Configuring IOS-XR is significantly different from configuring IOS. The PIM configuration is accomplished through separate multicast-routing and router pim configuration modes. The following basic steps explain how to configure PIM using a static RP with PIM sparse-mode in IOS XR:
Step 1. Enable multicast-routing and enable Layer 3 interfaces:
multicast-routing
address-family ipv4
interface Loopback0
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
!
interface all enable
Step 2. Enable interfaces in the Layer 3 domain, including the loopback with the ip pim sparse-mode command:
router pim
address-family ipv4
interface Loopback0
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
Step 3. Add the static RP configuration:
RP/0/0/CPU0:R1(config-pim)#router pim
RP/0/0/CPU0:R1(config-pim)#address-family ipv4
RP/0/0/CPU0:R1(config-pim-default-ipv4)#rp-address 192.168.0.1?
WORD Access list of groups that should map to given RP
bidir Specify keyword bidir to configure a bidir RP
override Static RP config overrides auto-rp and BSR
<cr>
The static RP configuration in NX-OS is similar to IOS and IOS-XE configurations and is as follows:
Step 1. Enable the feature pim.
feature pim
Step 2. Enable interfaces in the Layer 3 domain, including the loopback with ip pim sparse-mode:
interface Ethernet2/1
no switchport
mac-address 0001.4200.0001
ip address 192.168.23.1/24
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown
Step 3. Add the static RP configuration:
nexusr1(config)# ip pim rp-address 192.168.0.1 ?
<CR>
bidir Group range is treated in PIM bidirectional mode
group-list Group range for static RP
override RP address will override the dynamically learnt RPs
prefix-list Prefix List policy for static RP
route-map Route Map policy for static RP
Note
Why is it important to configure the main network loopback interface with sparse-mode PIM as shown in the preceding examples? After all, the loopback interface is unlikely to have any PIM neighbors. This is a recommended practice for any multicast overlay. The reason for this recommendation is that the router can then fully participate in the multicast domain, even if errors are occurring on leaf facing interfaces. It also allows the loopback interfaces to be used as a RP addresses or mapping agents in dynamic RP propagation, making them more reliable. See Chapter 5, “IP Multicast Design Considerations and Implementation,” for more information on this and other best practices for multicast networks.
PIM Dense Mode
To configure dense mode on older Cisco IOS routers and switches, use the following commands:
C6K-720(config)#ip multicast-routing [vrf vrf-name] [distributed]
C6K-720(config)#interface {type [number|slot/port[/port]]}
C6K-720(config-if)#ip pim dense-mode [proxy-register {list access-list |
route-map map-name}]
Figure 4-7 depicts a small campus network with a very limited multicast deployment for minor host updates. The underlying configuration example enables PIM dense-mode multicast and utilizes IGMP snooping for improved Layer 2 efficiency. IGMP snooping should be enabled by default.
Note
As discussed previously, there are very few reasons to ever deploy a PIM-DM network. Because of this, many Cisco networking operating systems will not support dense-mode configuration or certain dense-mode features. At presstime, Cisco IOS-XR and NX-OS do not support any PIM dense-mode–deployment or configurations. The following sample configuration is only provided as supplemental for existing dense-mode–compatible systems.
Using the network topology in Figure 4-7, the IOS configuration commands in Example 4-3 demonstrate how to configure dense-mode multicast.
Example 4-3 Configuring Dense-Mode Multicast in IOS
CR1(config)#ip multicast routing
CR1(config)#interface vlan 10
CR1(config-if)#ip pim dense-mode
CR2(config)#ip multicast routing
CR2(config)#interface vlan 10
CR2(config-if)#ip pim dense-mode
Dynamic RP Information Propagation
There are two ways to dynamically propagate RP information to routers within a domain:
Auto-RP (Cisco proprietary)
Bootstrap router (BSR)
Both solutions are acceptable because they provide a similar service and play a key role in a multicast design.
You may be asking yourself, “If static configurations work well, why have a dynamic protocol at all?” As discussed earlier, one of the most important concepts in group mapping is that all routers within a domain agree on the RP for a given group. If a network is very large, has many overlapping domains, many multicast applications, many rendezvous points, or all of the above, a consistent group mapping through static commands may become extremely difficult to manage. In fact, it is for this reason that these two dynamic protocols provide not only dynamic propagation, but also methods of ensuring RP mapping accuracy and consistency throughout a domain at all downstream routers. Remember, the RP itself does not make mapping decisions for downstream routers. Each router must learn of the RP individually and use the provided information to determine the best RP to map a group to. There are some similarities between Auto-RP and BSR that provide this consistency to downstream routers.
The control for this process is accomplished through the concept of centralized mapping. This means that some routers in the network are configured as RP routers and advertise themselves as such to other routers in the network. Centralized mapping routers receive the information about the RPs available within the network and establish group to RP mapping parameters, or compile available RP sets. When RP information is distributed from the centralized mapping routers, downstream routers need only listen to these advertisements and use the advertised information to create local RP mapping entries. This also serves the added purpose of limiting the number of protocol messages required throughout the domain.
Auto-RP and BSR both perform these mapping and advertising functions differently. But in the end, they provide the same essential functions to the network.
Auto RP
Auto-RP provides HA (active/standby) to the RP service. The propagation of RP information to the downstream routers is done via Auto-RP messages. The downstream routers do not require an explicit RP configuration. Rendezvous points using Auto-RP announce their availability to the mapping agents via the 224.0.1.39 multicast group. The RP mapping agent listens to the announced packets from the RPs, then sends RP-to-group mappings in a discovery message to 224.0.1.40. Downstream routers listen for mapping advertisements on group 224.0.1.40 and install the RP mappings as advertised from the mapping agent. It is acceptable to use the same interface address RP as a candidate and mapping agent. In larger systems to provide greater scalability, it would more efficient to use different interfaces, or to separate the candidate and agent functions to different routers. Figure 4-8 shows the Auto-RP mechanism.
The two multicast groups for Auto-RP information are advertised via dense mode in the sparse-dense mode of interface operation. This flooding of message allows automatic propagation to the downstream routers. As mentioned earlier, some operating systems do not support dense mode. How can RP information be propagated in a sparse-mode–only environment? You can use “listen” configuration commands in global configuration mode to cause IP multicast traffic for the two Auto-RP groups of 224.0.1.39 and 224.0.1.40 to be protocol independent multicast (PIM) dense-mode flooded across interfaces operating in PIM sparse-mode.
The Auto-RP mapping agent uses the following logic to build the RP-cache:
When there is a tie between two candidate RPs, the RP with the highest IP address wins the tie.
Two candidate RPs contest where one group is a subset of another, but the RPs are different. Both will be sent in the discovery RP-cache.
Auto-RP is best-suited in a multicast scoped environment. The Auto-RP message has an inbuilt time to live (TTL) and various other boundary features that make it best-suited in scoped multicast environments. A scoped multicast domain has its own RP with a group address assigned, which makes it a separate PIM domain.
Table 4-2 outlines some items to remember using Auto-RP:
Table 4-3 outlines the IOS/XE, IOS XR, and NX-OS mapping agent commands.
Table 4-4 outlines the IOS/XE, IOS XR, and NX-OS Candidate RP commands.
Table 4-5 outlines the IOS/XE, IOS XR, and NX-OS Auto-RP Listener commands.
Note
With NX-OS, use the listen keyword to process the Auto-RP message and use the forward keyword to send the Auto-RP message to next-downstream routers.
Figures 4-9 through 4-11 illustrate a typical deployment example on how to configure Auto-RP in IOS, IOS-XR and NX-OS. In this example, R1 and R2 are the candidate RPs and mapping agents, a common deployment practice.
Sample Configuration: Auto-RP for IOS
Example 4-4 shows the RP configuration for Router R1 and R2.
Example 4-4 Configuring RP for R1 and R2 in IOS
Example 4-5 shows the downstream router configuration:
Example 4-5 Configuring the Downstream Router in IOS
R3: Downstream router
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.3 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.12.3 255.255.255.0
ip pim sparse-mode
!
!
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
!
Sample Configuration: Auto-RP for IOS-XR
Figure 4-10 shows the topology for the following sample configuration of Auto-RP for IOS-XR.
Example 4-6 shows the RP configuration for Router R1 and R2.
Example 4-6 Configuring RP for R1 and R2 in IOS-XR
Example 4-7 shows the downstream router configuration.
Example 4-7 Configuring the Downstream Router in IOS
R3 : Downstream router
hostname R3
!
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
Sample Configuration: Auto-RP for NX-OS
Figure 4-11 shows the topology for the following sample configuration of Auto-RP for NX-OS.
Sample configuration—Auto-RP for NX-OS:
Example 4-8 shows the RP configuration for Router R1 and R2.
Example 4-8 Configuring RP for R1 and R2 in NX-OS
Example 4-9 shows the downstream router configuration.
Example 4-9 Configuring the Downstream Router in IOS
R3 : Downstream router
hostname R3
!
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
!
BSR
BSR is an open standards protocol defined by the IETF. BSR is another RP high-availability mechanism that provides active/standby functionality and automatic downstream RP information propagation. The candidate RP in the BSR domain advertises its availability by sending RP cache information to all the downstream routers in the PIM domain. The function of the BSR is to collect and broadcast the RP set to all routers in the domain. The RP cache information is sent to all downstream routers using PIMv2 message group (224.0.0.13) hop-by-hop to all routers in the PIM domain. As Figure 4-12 shows, the candidate RP sends its availability as RP only to the BSR router.
The bootstrap message sent by the BSR includes information about all the candidate-RPs. Each router uses a common algorithm to select the same RP address for a given multicast group. The selection criterion for the RP is based on the common algorithm and is the responsibility of each downstream router. This is one of the major differences between BSR and Auto-RP. Downstream routers use the following criteria to select the RP in BSR:
Multicast group range: Reviews the group that is attached to the RP for the selection.
RP priority: Configured field on the candidate RP, the higher priority wins the RP selection process for a specific group.
Hash Mask: Hash-mask-length bits of the group IP address are used to calculate the hash value. It uses a selection procedure for the whole multicast address space advertised in the RP multicast group. This multicast group is partitioned among different RPs. Every RP gets approximately 2^[32-hash-mask-length] groups assigned, provided that there are enough RPs to evenly distribute the load. This does not offer active/active within a group range. It does however, provide address that use RP-1 within the multicast range based on the hashed value and addresses that use RP-2. The BSR mechanism is a nonproprietary method of defining RPs that can be used with third-party routers. Similar to Auto-RP, there is no configuration necessary on downstream router for BSR (except on candidate-BSRs and candidate-RPs).
BSR is a standards-based protocol available with PIMv2. Unlike Auto-RP, BSR does not use any dense-mode groups to flood candidate RP and RP mapping information. BSR uses PIM messages on a hop-by-hop basis with all messages flooded using the all-PIM routers group with TTL of 1. This keeps those multicast advertisements to a local subnet.
Table 4-6 outlines the IOS/XE, IOS XR, and NX-OS commands for configuring the BSR.
Table 4-7 outlines the IOS/XE, IOS XR, and NX-OS commands for configuring the BSR candidate RP.
Figures 4-13 through 4-15 illustrate a typical deployment example on how to configure BSR in IOS, IOS-XR and NX-OS. In this example, R1 and R2 are the candidate RPs and BSR routers, a common deployment practice.
Sample Configuration: BSR in IOS
Figure 4-13 shows the topology for the following sample configuration of BSR in IOS.
Example 4-10 shows the BSR RP configuration for Router R1 and R2.
Example 4-10 Configuring BSR RP for R1 and R2 in IOS
Remember, because BSR uses the local PIM multicast group (224.0.0.13) no additional configuration is required for downstream routers to process BSR updates. The downstream router will receive the BSR mapping advertisements, process the update, and update any group mappings as necessary. Multicast group state entries will, of course, use the RP(s) in the mapping as processed.
Sample Configuration: BSR in IOS-XR
Figure 4-14 shows the topology for the following sample configuration of BSR in IOS-XR.
Example 4-11 shows the BSR RP configuration for Router R1 and R2.
Example 4-11 Configuring BSR RP for R1 and R2 in IOS-XR
Sample Configuration: BSR in NX-OS
Figure 4-15 shows the topology for the following sample configuration of BSR in NX-OS.
Example 4-12 shows the BSR RP configuration for Router R1 and R2.
Example 4-12 Configuring BSR RP for R1 and R2 in NX-OS
It is important to note that because of the differences between mapping process used by BSR and Auto-RP the two protocols should never be used simultaneously in the same network or PIM domain.
Anycast RP
Anycast RP uses a load-balancing technique that achieves active/active RP distribution for a multicast group. Figure 4-16 illustrates the mechanics of active/active RP distribution using Anycast techniques.
There are two variants of Anycast RP you should be aware of.
RFC 3446 based on Multicast Source Discovery Protocol (MSDP) to maintain the active state between the RPs.
RFC 4610 based on protocol independent multicast (PIM) to maintain the active state in the RPs.
Anycast allows two or more RPs to participate simultaneously within the multicast PIM domain. Based on one of the methods described in these RFCs, the state of the tree is maintained between two or more RPs. Using the protocols specified, the RPs also monitor and share active sources so that the state information is always current. Thus, the administrative domain can have more than one active RP.
What is very different about Anycast RP from other active/active network mechanisms is that Anycast requires both RPs to use the same IP address. This is the mechanism that allows receiver and source routers to register groups with the RP, regardless of the location, or which physical router is used. The registration messages are simply sent to the physical RP with the closest unicast routing metric. The IP address used for the RP for Anycast RP must be the same on each router.
Multicast Source Discovery Protocol
Multicast forwarding domains are designed to be secure and separate, just like their unicast counterparts. However, even private unicast routing domains can be, and most often are designed to connect to external domains or the Internet. What about multicast domains? Multicast domains are more fluid by definition and many domains may exist in a single IGP autonomous system. It stands to reason that some multicast applications will need external reach and therefore a way to bridge multicast domains and autonomous systems must also exist.
The way routers and networks build a multicast tree can make cross-domain forwarding a conundrum. In a sparse-mode network we must have both an active source and an active receiver to build the shared and source trees required to forward traffic. Routers and RPs use the unicast routing table to perform loop avoiding RPF checks against the sources in the network. If the source is outside the unicast domain, how do we learn about it? How can we trust that the source is legitimate when it is outside our control? How do we limit the sources to only those needed without flooding the entire network like the Internet with every known source?
There must be a protocol that can track and share active sources between domains. That protocol is Multicast Source Discovery Protocol (MSDP). MSDP tracks active sources in a network and shares those sources only with configured neighbors. It allows routers to extend multicast forwarding beyond internal boundaries, yet maintain a secure multicast posture.
Like BGP, MSDP uses a preconfigured peering relationship to exchange information. MSDP also uses TCP to securely establish the peering sessions, using port 639 for transport. Each MSDP peer must be explicitly configured to reach any other peer for which session establishment is required. Let’s examine how this relationship is formed and what it does.
Referring to Figure 4-17, R1 is a receiver for multicast group S1. RP1 and RP2 have the same IP address; however, the Anycast PIM relationship needs to be built via a unique IP address that is assigned to the local RP device. The following provides a step-by-step flow using Anycast, as illustrated in Figure 4-17:
1. S1 sends a multicast packet to the first hop-designated router. The designated router sends a PIM register message to RP1.
2. RP1 and RP2 have an established MSDP relationship. RP1 sends a source active (SA) message to RP2. The SA message is sent via MSDP between RP1 and RP2. The SA message contains the following fields:
The source address of the data source.
The group address the data source is sending to.
The IP address of the RP.
3. RP2 has the state information (*,G) for receiver R1. After RP2 receives the SA message, the shortest path tree is built for the S, G flow.
Anycast with MSDP is supported on all Cisco Layer 3 platforms: NX-OS, IOS-XR, and IOS.
PIM Anycast RP
PIM Anycast RP is a variant of Anycast deployments that use PIM to build the active/active multicast state distribution between the RPs. This process is illustrated in Figure 4-18.
R1 is a receiver for multicast group S1. RP1 and RP2 have the same IP address; however, the Anycast PIM relationship needs to be built via a unique IP address that is assigned to the local RP device. The following provides a step-by-step flow using Anycast as illustrated in the Figure 4-18.
1. S1 sends a multicast packet to the first-hop designated router. The designated router sends a PIM register message to RP1.
2. RP1 and RP2 are configured with the same IP address. Because the register message did not come from one of the RPs in the Anycast RP set, RP1 then sends a copy of the register message to RP2. In this case, this register message will use RP1s own IP address as the source address for the PIM Register message. RP2 receives the register message from RP1 and checks the state table. R1 is in RP2’s multicast state table, RP2 decapsulates the register packet from RP1 and sends the flow down the shared-tree to receiver R1. It should be noted if RP2 does not have a receiver in its multicast state table the register stop is sent in similar manner as the PIM register process.
RP2 sends a register stop back to RP1. This is the state maintenance mechanism between the RPs.
3. RP1 joins the multicast PIM state for S1 by triggering a (S1,G) join message toward S1 and (S1,G) state is created. After this, RP2 also joins to the source tree by creating a (S1,G) join towards S1.
Anycast with PIM using IPv4 is only supported with NX-OS. Anycast deployment in IPv6 environment supports PIM Anycast feature in all IOS, IOS-XE and Nexus platforms. The Nexus platform supports both Anycast PIM and MSDP modes.
Sample Configuration: Anycast RP with MSDP on IOS
The following configurations provide examples for configuring Anycast with IOS (with MSDP), IOS-XR (with MSDP), and NX-OS (Anycast PIM 4610). In this example, R1 and R2 are the candidate RPs using loopback 1 as the Anycast RP address. The loopback 0 interfaces of R1 and R2 are used to establish the MSDP relationship and also for PIM. The downstream routers are statically configured using the RP address of 10.100.1.1. The unicast routing protocol controls the receivers and/or sources joining one of the active/active RP. Figure 4-19 shows us this example network diagram.
Note
The recovery from a failure in an Anycast environment when compared to Auto-RP or BSR is significantly faster. This is because as soon as unicast routing protocol converges, the multicast control plan RP reachability will take place simultaneously.
Example 4-13 shows the PIM Anycast RP configuration for Router R1 and R2.
Example 4-13 Configuring PIM Anycast RP for R1 and R2 in IOS
Loopback 1 is the Anycast RP address, which is the same on both the RPs.
Note
Make sure you have the router-id configured for unique local node. The same loopback 1 is used in all the anycast examples.
Example 4-14 shows the downstream router configuration.
Example 4-14 Configuring the Downstream Router in IOS
R4 : Downstream router
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim rp-address 10.100.1.1 GROUPS
!
ip access-list standard GROUPS
permit 239.0.0.0 0.255.255.255
Sample Configuration: Anycast with MSDP on IOS-XR
If we change the RP routers in our network diagram to IOS-XR routers, in this case ASR 9Ks, we need to adjust our configurations accordingly. The diagram in Figure 4-20 depicts this change to the network. Example configurations for XR follow the diagram.
Example 4-15 shows the PIM Anycast RP configuration for Router R1 and R2.
Example 4-15 Configuring PIM Anycast RP for R1 and R2 in IOS-XR
Example 4-16 shows the downstream router configuration.
Example 4-16 Configuring the Downstream Router in IOS
R4 : Downstream router
hostname R4
!
ip multicast-routing
ip cef
no ipv6 cef
!
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
ip pim rp-address 10.100.1.1 1
!
!
access-list 1 permit 239.0.0.0 0.255.255.255
Sample Configuration: Anycast on NX-OS
Let’s take one more look at the same network, but here we replace the RP routers with Cisco Nexus switches using NX-OS. Figure 4-21 reflects the changed topology for the accompanying configuration examples.
Example 4-17 shows the PIM Anycast RP configuration for Router R1 and R2.
Example 4-17 Configuring PIM Anycast RP for R1 and R2 in NX-OS
Example 4-18 shows the downstream router configuration.
Example 4-18 Configuring the Downstream Router in IOS
R4 : Downstream router
hostname R4
!
no ip domain lookup
ip multicast-routing
ip cef
no ipv6 cef
!
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
ip pim rp-address 10.100.1.1 1
!
!
access-list 1 permit 239.0.0.0 0.255.255.255
Use caution when configuring Anycast RP. The configuration is quite simple, but the selection of the RP address on the Anycast loopback can create problems if not designed properly. Although not a multicast-specific issue, remember that many protocols use loopback addresses as a router identification, including BGP, MPLS, OSPF, and IS-IS. In each of these protocols, if the router-ID is not explicitly configured, the highest IP address on a loopback interface will be used. If the Anycast loopback IP address happens to be the highest, you could end up with multiple routers having the same router-id! This causes peers and neighbors to crash and routing anomalies to occur. It is always best practice to explicitly configure router-IDs in all protocols that use them. It is also best practice to never use the Anycast loopback for any other purpose other than as an RP, such as, for example, a configured tunnel destination/source or any other non-Anycast mechanism.
Phantom RP
The concept of a phantom RP is used with BiDir PIM designs. BiDir PIM designs work with regular RP distribution methods that we described in the earlier sections. Unlike PIM ASM, with BiDir the RP does not handle any control plane load and RP information. A good BiDir RP design does not need to provide a physical RP, but rather use a phantom RP. As the name states, the phantom RP uses a virtual IP address as an RP that is advertised as the RP address but is not locally present on any router.
Figure 4-22 illustrates a BiDir domain.
Sample Configuration—Phantom RP on IOS
The following configuration provides a configuration example of a phantom RP using IOS. R1 and R2 are two routers that have RP information in the PIM BiDir domain.
Example 4-19 shows the Phantom RP configuration for Router R1 and R2.
Example 4-19 Configuring Phantom RP for R1 and R2 in IOS
In this example, the RP (10.100.1.2) does not physically exist on any device. The subnet to which the RP belongs, exists with a different mask. The different mask creates a virtual identity for 10.100.1.2. The command ip ospf network point-to-point makes the route of 10.100.1.1 appear with its configured mask, because by default OSPF advertises all loopbacks as /32. The downstream routers will see the 10.100.1.2 using the show ip route command, as shown in Example 4-20.
Example 4-20 Route to 10.100.1.2 on R4
R4#show ip route
Routing entry for 192.168.3.0/24, 2 known subnets
Variably subnetted with 2 masks
O 10.100.1.0/30 [110/21] via 192.168.34.1, 00:10:03, Ethernet0/0
O 10.100.1.0/29 [110/11] via 192.168.34.1, 00:10:03, Ethernet0/0
The preferred route(s) is the one with the longest prefix.
R4#show ip route 10.100.1.2
Routing entry for 10.100.1.0/30
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 192.168.0.2 on Ethernet0/0, 00:10:19 ago
Routing Descriptor Blocks:
……
The Phantom RP configuration example uses a static RP assignment. Phantom RP with PIM BiDir is compatible with dynamic RP propagation using Auto-RP protocol. Phantom RP propagation using BSR is not a configuration option at this time; because a virtual address is used that can exist on both R1 and R2, redundancy is built into the RP configuration. Any failure of the R1 router or the /30 route configured for the R1 loopback interface, would cause the network to reconverge on the larger /29 subnet route configured for the R2 loopback interface. Because the RP address is virtual, the mappings would use R2 as the next path to reach the RP until such time as the R1 loopback is reintroduced to the network.
PIM SSM Configuration
As you read earlier in Chapter 3, SSM is the only configuration that does not require a RP. Remember that PIM SSM uses IGMPv3 source-specific joins to subscribe to the appropriate channel, and the network uses only source trees to forward each flow. Consequently, configuring SSM is very easy in an established IP multicast network using sparse or sparse-dense mode. Enabling PIM SSM and defining a range is the only required step and is only required on leaf routers. The SSM source trees within the existing network form a new SSM multicast domain that coexists but does not interfere with the existing sparse domain(s).
If the network is using only source-specific applications and is not PIM-configured, PIM-SSM is very simple to enable. Use the following steps and configuration commands to configure an IP network for PIM-SSM from scratch.
Step 1. Enable PIM-SSM and define a range for SSM forwarding. Remember the default group block for SSM is 232.0.0.0/8. If you do not configure a range, the default is assumed.
IOS/XE: ip pim ssm[default | range access-list]
IOS-XR: ip pim ssm range {ip-prefix | none | route-map policy-name}
NX-OS: ssm [allow-override | disable | range access-list]
Step 2. Enable Interfaces for PIM sparse-mode/ (There is no “ssm mode” configuration option, and no dense-mode operations are required for SSM; thus, sparse-mode configuration is sufficient.)
IOS/XE: ip pim sparse-mode
IOS-XR: router pim
NX-OS: ip pim sparse-mode
Note
IOS-XR supports only sparse mode and it is assumed on any interface configured under the router pim configuration.
Step 3. Gateway router interfaces, host interfaces, and L3 switch interfaces should be configured with igmp version 3.
IOS/XE: ip igmp version 3
IOS-XR: router igmp
NX-OS: ip igmp version 3
Note
For IOS-XR, IGMP version 3 is the default. Use the version command under igmp config to change versions if necessary.
Note
Make sure that all Layer 2 switches at the leaf edges of the network support IGMPv3 snooping. Refer to Chapter 2 for additional information on IGMP versions and Layer 2 configurations.
Example 4-21 (for IOS) configures PIM SSM as the only PIM mode available for applications using the default PIM group addressing. Remember that no RP is required for SSM.
Example 4-21 Sample SSM Configuration
RouterX
hostname rX
!
no ip domain lookup
ip multicast-routing
ip cef
no ipv6 cef
!
!
interface Loopback0
ip address 192.168.0.X 255.255.255.255
ip pim sparse-mode
ip igmp version 3
!
interface Ethernet0/0
ip address 192.168.X.X 255.255.255.0
ip pim sparse-mode
ip igmp version 3
!
interface Ethernet0/1
ip address 192.168.X.X 255.255.255.0
ip pim sparse-mode
ip igmp version 3
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip pim ssm default
!
ip igmp version 3
Summary
A rendezvous point (RP) is the service in the network where both multicast senders and receivers go to “connect” with their associated counterpart in a shared tree environment. The process of building a shared tree requires that the network components register active sources, as well as receivers for a given multicast group to the RP.
IP multicast domains are generally a subset of the entire network infrastructure. This offers an administrator the ability to have better control over multicast messaging. You can consider a group of PIM routers with the ability to share the same tree as part of a domain or scope. These scope ranges are aligned with RP and PIM domains. A scope range can superimpose over each other or be a subset of one another.
The first step in building a PIM domain for sparse-mode or BiDir is to establish a PIM neighbor adjacency on a given subnet. The second step is to agree on an RP. RPs and group mappings can be learned statically using manual configuration at each router or dynamically by using either Auto-RP or BSR.
There are two ways to dynamically propagate RP information to routers within a domain, Auto-RP and bootstrap router (BSR). Auto-RP is a Cisco proprietary solution. Rendezvous points using Auto-RP announce their availability to the mapping agents via the 224.0.1.39 multicast group. The RP mapping agent listens to the announced packets from the RPs, then sends RP-to-group mappings in a discovery message to 224.0.1.40. BSR is another RP high-availability mechanism that provides active/standby functionality of the RP and automatic downstream RP information propagation. The function of the BSR is to broadcast the RP set to all routers in the domain. The RP cache information is sent to all downstream routers using PIMv2 message group (224.0.0.13) hop-by-hop to all routers in the PIM domain.
Maintaining the integrity of the multicast infrastructure can be a concern in high-availability (HA) environments. Anycast RP uses a load-balancing technique that achieves active/active RP distribution for a multicast group. There are two variants of Anycast RP, one based on Multicast Source Discovery Protocol (MSDP) (RFC 3446) and one based on protocol independent multicast (PIM) (RFC 4610) to maintain the active state in the RPs.
A phantom RP is used with BiDir PIM designs for HA. BiDir PIM designs work with regular RP distribution methods, but unlike PIM ASM, BiDir does not handle any control plane load and RP information. The phantom RP uses a virtual IP address that is advertised as an RP address but not locally present on any router.
Both PIM dense-mode and SSM do not require the use of an RP. Dense mode is not a recommend solution for most implementations, as some networking operating systems will not support dense mode operation. SSM uses IGMPv3 source specific joins to subscribe to the appropriate channel and the network uses only source trees to forward each flow. Consequently, configuring SSM is very easy in an established IP multicast network using sparse.