You want to enable routing of multicasts using sparse mode for better efficiency, and use BSR for distributing RP information.
We've already discussed how PIM-SM requires a Rendezvous Point 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 RPs and candidate BSRs. 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 RPs, 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-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#
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 RP router to act as the root of the multicast SPTs.
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 previous configuration for Router1.
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, in the example, it is statically configured 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 uses the Bootstrap Router method, which is part of the open PIM-SM standard defined in RFC 2362. 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.
There are two important commands that define how Router RP1 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 15, which specifies that this router will be the RP for any multicast group between 239.5.5.0 and 239.5.5.255. You may specify that the RP router can support any set of multicast group addresses. If you want it to support all multicast groups, simply eliminate the group-list keyword:
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 BSR election process.
The last number, 1, in the example's bsr-candidate command is a hash value that helps to select different RPs 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 useful only 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 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 BSRs 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 Router RP1. The static RP value is needed only when none of the usual RPs are 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, then relay the same information to all of the adjacent routers (except for the one that originally provided the information). 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.10.
To define distinct regions of a network served by different groups of RPs, you first need to decide where the boundaries of these regions will be, then 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.
 |
|
|
| Top |