Routing Multicast Traffic with PIM-SM and BSR

Problem

You want to enable routing of multicasts using Sparse Mode for better efficiency and use BSR for distributing RP information.

Solution

We've already discussed how PIM-SM requires a Rendezvous Point (RP) router. The most reliable way to achieve this is to have the network automatically discover the RP. This way, if the RP fails, another can automatically take over for it. We recommend using the Bootstrap Router (BSR) mechanism to dynamically distribute RP information.

There are two different types of router configurations for this type of network. Most of the routers will support end devices, both group members and servers. But a small number are configured to act as candidate RP's and candidate Bootstrap Routers (BSR). In the example, we show the RP and BSR configuration in the same router. This isn't actually necessary, but it is convenient.

Router1 is an example of a "normal" multicast router. It forwards multicasts, takes part in PIM-SM, and may support group members or multicast servers as required:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip multicast-routing
Router1(config)#ip pim rp-address 192.168.15.5
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip address 192.168.1.1 255.255.255.0
Router1(config-if)#ip pim sparse-mode
Router1(config-if)#interface Serial1/0
Router1(config-if)#ip address 192.168.2.5 255.255.255.252
Router1(config-if)#ip pim sparse-mode
Router1(config-if)#end
Router1#

Router RP1 is one of the candidate RP's, and it is also configured as a candidate BSR. It may also support multicast group members or servers, if required. It is a good idea to configure two or more routers as RPs and BSRs in each multicast domain like this to provide redundancy:

Router-RP1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router-RP1(config)#ip multicast-routing
Router-RP1(config)#interface Loopback0
Router-RP1(config-if)#ip address 192.168.12.1 255.255.255.255
Router-RP1(config-if)# ip pim sparse-mode
Router-RP1(config-if)#exit
Router-RP1(config)#interface FastEthernet0/0
Router-RP1(config-if)#ip address 192.168.1.1 255.255.255.0
Router-RP1(config-if)#ip pim sparse-mode
Router-RP1(config-if)#exit
Router-RP1(config)#interface Serial1/0
Router-RP1(config-if)#ip address 192.168.2.5 255.255.255.252
Router-RP1(config-if)#ip pim sparse-mode
Router-RP1(config-if)#exit
Router-RP1(config)#ip pim rp-address 192.168.12.1 15
Router-RP1(config)#ip pim rp-candidate loopback0 group-list 15
Router-RP1(config)#ip pim bsr-candidate loopback0 1
Router-RP1(config)#access-list 15 permit 239.5.5.0 0.0.0.255
Router-RP1(config)#access-list 15 deny any
Router-RP1(config)#end
Router-RP1#

 

Discussion

In larger networks, particularly networks with WAN links, the PIM-DM approach of forwarding all multicasts to all routers until they explicitly opt out of the group tends to be inefficient with network resources. So it is useful to configure a Sparse Mode multicast routing protocol such as PIM-SM. The basic configuration for most of the routers is similar to what we did in Recipe 23.1. The difference is that PIM-SM allows you to set up a Rendezvous Point (RP) router to act as the root of the multicast Shortest Path Trees (SPT).

There are two ways to configure the routers to use an RP. The conceptually simpler method is to explicitly define the RP in the other routers, using the ip pim rp-address command, as shown in the configuration for Router1 above:

Router1(config)#ip pim rp-address 192.168.15.5

This method has two important administrative problems. If you ever want to change the RP to another router, you have to change it separately in every router, and it lacks the ability to automatically switch to a backup RP in case of failure. However, it is statically configured in the example for a different reason, which we will explain in a moment.

The alternative is to configure the network to discover the RP dynamically, which is also shown in the Solution. This is preferable in most cases. In fact, there are two ways to accomplish this. One uses a Cisco proprietary method called Auto-RP, and the other called the Bootstrap Router method, which is part of the open PIM-SM standard defined in RFC 4601. This recipe shows the Bootstrap Router method, which we generally prefer for interoperability reasons. The Auto-RP, which will only work in an all-Cisco network, is discussed in Recipe 23.3.

In Router-RP1, there are two important commands that define how it will advertise itself. The first is ip pim rp-candidate, which allows the router to advertise itself as a possible RP:

Router-RP1(config)#ip pim rp-candidate loopback0 group-list 15

There are two modifiers on this command. The first, loopback0, tells the network to use the loopback interface as the RP address. If there are several candidate RP routers, the PIM-SM algorithm prefers the one with the highest IP address. So be careful if you want a particular router to be the default.

This command also includes the group-list tag. In this case, it associates the RP functions for this router with access-list number 15, which specifies that this router will be RP for any multicast group between 239.5.5.0 and 239.5.5.255. You can specify that the RP router can support any set of multicast group addresses. If you want it to support all multicast groups, then simply eliminate the group-list keyword as follows:

Router-RP1(config)#ip pim rp-candidate loopback0

Using the group-list option is most useful if you have an extremely large number of multicast groups to distribute and the load is too heavy for one router. Some network administrators may also decide to use a different RP for a few specific local groups for ease of management as well. But in most networks there is relatively little benefit to breaking up the RP functions by group this way. We have just included the option here to show how it works in case you do need it. If you decide to break up the RP responsibilities among many routers, be careful to ensure that all possible groups have an RP available.

The next important command in Router-RP1 is ip pim bsr-candidate:

Router-RP1(config)#ip pim bsr-candidate loopback0 1

This allows the router to act as a Bootstrap Router (BSR). BSRs are responsible for distributing information about all of the known candidate RPs throughout the network. In this example, we use the loopback interface to define the IP address that this router will use when advertising itself as a BSR candidate. The protocol uses this address in the election process to select the BSR from all of the possible candidates. This command also accepts a priority keyword that you can use to help bias the election process to prefer one BSR candidate.

The last number in the example's bsr-candidate command, 1, is a hash value that helps to select different RP's for different ranges of multicast group addresses. Because the example uses a range of addresses from 239.5.5.0 to 239.5.5.255, we could have configured the candidate BSR to allow RPs to control a similar range of multicast addresses. There are 8 bits of freedom in this range, which would give a hash value of 8. If you're not sure what to use here, it is safest to just use a value of 1 bit. This will allow the network to select the best RPs on a group-by-group basis. In fact this option is really only useful when you have several RPs, each supporting different ranges of multicast group addresses. When in doubt, it is safe to use a value of 1. There is a slight performance advantage to using larger hash values, however.

We note in passing that the RP router's configuration in our example also includes a static rp-address configuration command, pointing to itself and including the same access-list defining the multicast groups served by this RP:

Router-RP1(config)#ip pim rp-address 192.168.12.1 15

This command is completely redundant in most IOS releases, but appears to have suddenly become necessary in IOS Version 12.3, as it ensures that the RP router is aware that it is the RP for these groups. We don't understand why this change was made, as the ip pim rp-candidate command would appear to perform the same function. In any case, it doesn't hurt anything to include this command, so we recommend including it.

We have one final comment on the configuration of the candidate RP/BSR router. Since we are using the loopback interface as the source for both RP and BSR functions, it is important that this interface be configured for PIM-SM. This seems counter-intuitive because a loopback interface can't have any neighbors by definition. But the BSR function in particular will not work properly without this configuration, because we use the loopback interface to define this router as a BSR candidate.

We use the loopback interface for this purpose because it can't go down. If there is any path to this router, it will retain the RP role. This may not always be desirable, of course. If this is a WAN router, for example, we certainly wouldn't want all multicast traffic to have to cross the WAN twice just because an Ethernet interface went down. In such cases, it would be better to use the Ethernet port for the BSR and RP addresses.

In general, it is a good practice to set up several BSR's to spread the word about several RPs with overlapping group ranges for redundancy. This gives a much more reliable network. And, if it ever happens that no RPs are available, the router will revert to the statically configured RP address, which we have configured using the following command:

Router1(config)#ip pim rp-address 192.168.15.5

Note that the address specified is not the same as RouterRP1. The static RP value is only needed when none of the usual RPs is available. So a good choice for this last resort RP would be one of your central core routers. Naturally, you must make sure that the router you specify is configured to act as an RP.

If you are going to use this BSR method for RP discovery, you need to take certain network design precautions. Sometimes you will want an RP to serve a particular section of the network. In smaller networks, you may have RPs serve the entire physical expanse of the network, but with different RPs serving different multicast groups. However, in larger networks, or when two or more networks adjoin, it is necessary to limit the region of the network served by any RP.

The BSR works by sending out information to all of the adjacent PIM routers. These routers record all of the information, and then relay the same information to all of the adjacent routers, except the one where this information came from in the first place. Because this process is repeated at each hop, it could expand indefinitely. In fact, the process is not even bounded by the usual IP TTL limit of 255 hops because a new packet is created at each hop. So it is possible to have the network choose an RP that some devices cannot reach, particularly if you use TTL to control multicast scope, as in Recipe 23.14.

To define distinct regions of a network served by different groups of RPs, first you need to decide where the boundaries of these regions will be, and then you configure the routers along the boundary so that they will neither transmit nor receive any BSR information on those interfaces:

Router-Border1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router-Border1(config)#ip multicast-routing
Router-Border1(config-if)#interface FastEthernet0/0
Router-Border1(config-if)#ip pim sparse-mode
Router-Border1(config-if)#ip pim border
Router-Border1(config-if)#end
Router-Border1#

Note that the ip pim border command affects only the exchange of BSR information. Multicast traffic can still flow across the interface, and PIM will still form SPT trees that cross the interface.