Case Study Configuring the Bootstrap Protocol

When PIMv2 was first described in RFC 2117, the bootstrap protocol was specified as the mechanism for automatic RP discovery. Cisco first supported PIMv2 in Cisco IOS Software Release 11.3T, and the bootstrap protocol is included in that support.

The two steps to configure bootstrap are very similar to the two steps for configuring Auto-RP:

1 All candidate RPs must be configured.

2 All candidate bootstrap routers (C-BSRs) must be configured.

Figure 6-7 shows the same PIM topology used in the preceding two case studies, but now it is running bootstrap rather than Auto-RP. Stetson and Fedora are again the C-RPs, but now they are also C-BSRs in keeping with a more robust design, providing failover for both the RP and BSR function.

Figure 6-7 Stetson and Fedora Serve as Both Candidate RPs and Candidate BSRs

Fedora

Figure 6-7 Stetson and Fedora Serve as Both Candidate RPs and Candidate BSRs

Fedora

Member, Group 228.13.20.216

Example 6-38 shows the relevant configurations of Stetson and Fedora.

Example 6-38 Configuring Routers Stetson and Fedora as Both Candidate RPs and Candidate BSRs

Stetson interface LoopbackO ip address 10.224.1.1 255.255.255.255

i ip pim bsr-candidate LoopbackO 0 ip pim rp-candidate LoopbackO

Fedora interface Loopback0 ip address 10.224.1.2 255.255.255.255

ip pim bsr-candidate LoopbackO 0 ip pim rp-candidate Loopback0

The command ip pim bsr-candidate sets the router as a C-BSR and specifies that the BSR address is to be taken from interface L0. The 0 at the end of the command specifies the hash-mask length, which is 0 by default on Cisco routers. Use of the hash-mask is demonstrated later in this case study. The command ip pim rp-candidate sets the router as a C-RP and specifies that the RP address also is to be taken from interface L0.

First, a BSR must be elected from the available C-BSRs. The C-BSRs send Bootstrap messages throughout the PIM domain, with the destination address 224.0.0.13, that contain the originator's BSR address and priority. In the configuration so far, the default priority of 0 and the default hash-mask length of 0 remain unchanged, and therefore equal, on both C-BSRs. As a result, the higher BSR address is used as a tiebreaker. Fedora's BSR address (10.224.1.2) is higher than Stetson's (10.224.1.1), so Fedora is the BSR. Example 6-39 confirms the fact. By using show ip pim bsj-router on any router in the domain, you can observe not only the active BSR, but also the BSR's address, uptime, priority, hash-mask length, and holdtime.

Example 6-39 The show ip pim bsr-router Command Displays the PIMv2 Domain's BSR

Bowler#show ip pim bsr-router

PIMv2 Bootstrap information BSR address: 10.224.1.2 (?)

Uptime: 00:17:35, BSR Priority: 0, Hash mask length: 0

Expires: 00:01:56 Bowier#

When the C-RPs receive the Bootstrap messages and determine the address of the BSR, they unicast their Candidate-RP-Advertisement messages to the BSR. These messages contain the C-RP's address and priority. The BSR collects the C-RPs into an RP-Set, which is then included in its Bootstrap messages. This is where bootstrap diverges sharply from Auto-RP: Unlike the Auto-RP mapping agent, the BSR does not select RPs. The PIMv2 routers receive the Bootstrap messages, and they select the RP. The algorithm used to make the selection ensures that all routers select the same RPs for the same groups.

Example 6-40 shows the group-to-RP mappings at Bowler. You can see that the RP is Stetson, which is elected RP because of its lower RP address. (The C-RP priorities in this example are equal.)

Example 6-40 The Active Groups at Bowler Are All Mapped to Stetson. Unlike Auto-RP, the C-RP with the Lowest RP Address Is Elected as the RP

Bowler#show ip pim rp

Group: 239.255.255.254, RP: 10.224.1.1, v2, uptime 00:25:16, expires 00:02:40 Group: 228.13.20.216, RP: 10.224.1.1, v2, uptime 00:25:16, expires 00:02:40 Group: 224.2.127.254, RP: 10.224.1.1, v2, uptime 00:25:16, expires 00:02:40 Group: 230.253.84.168, RP: 10.224.1.1, v2, uptime 00:25:16, expires 00:02:40 Bowler#

Example 6-41 shows the complete group address range that is mapped to the RP. Compare this display to that of Example 6-33; of particular interest here is that the mapping is shown to be derived from bootstrap, and that the router knows all the C-RPs from the RP-Set.

Example 6-41 Bowler Indicates That It Is Aware of Both Stetson and Fedora as C-RPs

Bowler#show ip pim rp mapping

PIM Group-to-RP Mappings

Info source: 10.224.1.2 (?), via bootstrap Uptime: 00:29:07, expires: 00:02:30 RP 10.224.1.2 (?), v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 00:29:07, expires: 00:02:17

Bowler#

The default behavior of both the BSR and the RP can be changed. In Example 6-39, for instance, the BSR is Fedora because its IP address is higher. If you want Stetson to be the BSR, with Fedora acting only as a backup in case Stetson fails, you can change Stetson's priority to something higher than the default of 0. To change Stetson's priority to 100, you need to configure Stetson as in Example 6-42.

Example 6-42 Configuring Stetson with a Priority of 100 to Make It the BSR

interface Loopback© ip address 10.224.1.1 255.255.255.255

i ip pim bsr-candidate Loopback© 0 100 ip pim rp-candidate Loopback©

Example 6-43 shows the results of the new configuration. Bowler now shows Stetson as the BSR, with a priority of 100. Fedora assumes that role only if Stetson fails.

Example 6-43 Stetson (10.224.1.1), with a Priority of 100, Has Become the BSR

Bowler#show ip pim bsr-router

PIMv2 Bootstrap information

BSR address: 10.224.1.1 (?)

Uptime: 00:10:27, BSR Priority: 100

i, Hash mask length: 0

Expires: 00:02:02

Bowler#

As with Auto-RP, you also can use access lists to distribute the RP duties among multiple RPs. Suppose, for example, that you want Fedora to be the RP for any groups whose addresses are in the 228.13.0.0/16 range, and Stetson to be the RP for all other groups. You use the configurations in Example 6-44.

Example 6-44 Distributing RP Duties Between Fedora and Stetson

Stetson interface LoopbackO ip address 10.224.1.1 255.255.255.255

i

ip pim bsr-candidate LoopbackO 0 100 ip pim rp-candidate LoopbackO group-li|t

20

access-list 20 deny 228.13.0.0 0.0.255. access-list 20 permit any

.255

Fedora interface LoopbackO ip address 10.224.1.2 255.255.255.255

i

ip pim bsr-candidate LoopbackO 0 ip pim rp-candidate LoopbackO group-list i

10

access-list 10 permit 228.13.0.0 0.0.255.

.255

Example 6-45 shows the results of these configurations. The BSR advertises the constraints in its Bootstrap messages, and Bowler maps its groups to the RPs based on those constraints. Of course, these configurations are not advised in a real internetwork. If one RP fails, the other can no longer assume a backup role. A more practical implementation would use access lists to distribute groups among multiple C-RPs, with at least two C-RPs for each group range created by the access lists.

Example 6-45 After the Access Lists Are Added to Constrain the RP Mappings at Stetson and Fedora, Bowler Has Mapped Group 228.13.20.216 to Fedora and the Other Groups to Stetson

Bowler#show ip pim rp mapping

PIM Group-to-RP Mappings

Info source: 10.224.1.1 (?), via bootstrap Uptime: 00:07:25, expires: 00:02:26 Group(s) 228.13.0.0/16 RP 10.224.1.2 (?), v2

Info source: 10.224.1.1 (?), via bootstrap Uptime: 00:07:25, expires: 00:02:54

Bowler#show ip pim rp

Group: 239.255.255.254, RP: 10.224.1.1, v2, uptime 00:07:30, expires 00:02:52 Group: 228.13.20.216, RP: 10.224.1.2, v2, uptime 00:07:30, expires 00:03:32 Group: 224.2.127.254, RP: 10.224.1.1, v2, uptime 00:07:30, expires 00:02:52 Group: 230.253.84.168, RP: 10.224.1.1, v2, uptime 00:07:30, expires 00:02:52 Bowler#

A better way to distribute the RP duties when using PIMv2 bootstrap is to use the hash-mask. The hash-mask is a 32-bit number assigned to the BSR, and it is used in a somewhat similar fashion to a standard IP address mask. The BSR advertises the hash-mask in its Bootstrap messages, and the receiving routers run a hash algorithm that assigns a consecutive number of group addresses to one C-RP and then assigns the next group of addresses to the next C-RP.

If the hash-mask is 30 bits, for example, it masks the first 30 bits of all IP multicast addresses. The last 2 bits describe a range of four group addresses that will be assigned to an RP. So the addresses 225.1.1.0, 225.1.1.1, 225.1.1.2, and 225.1.1.3 are all part of one range and are assigned to one RP. The addresses 225.1.1.4, 225.1.1.5, 225.1.1.6, and 225.1.1.7 belong to the next range and are assigned to another RP. This "bundling" of group addresses continues throughout the entire IP multicast address range and across all available C-RPs. The result is that the IP multicast group addresses have been evenly distributed among the C-RPs. The mask gives you the flexibility to decide how many consecutive addresses are bundled into a single range so that related addresses are more likely to share the same RP. If the mask is 26 bits, for instance, 64 consecutive addresses are assigned to each range.

The hash-mask length is specified as part of the ip pim bsr-candidate command. As you have observed in previous examples in this case study, the default mask length is 0, meaning that there is a single bundle of group addresses spanning the entire range of the IP multicast address space. Example 6-46 shows the configurations to assign a hash-mask length of 30 for both Stetson and Fedora in Figure 6-7.

Example 6-46 Assigning a Hash-Mask Length of 30 to Routers Stetson and Fedora

Stetson interface LoopbackO ip address 10.224.1.1 255.255.255.255

ip pim bsr-candidate Loopback0 30 ip pim rp-candidate LoopbackO

Fedora interface LoopbackO ip address 10.224.1.2 255.255.255.255

i ip pim bsr-candidate LoopbackO 30 ip pim rp-candidate LoopbackO

In Example 6-47, the show ip pim rp-hash command is used to demonstrate the results. Beginning with 231.1.1.0, you can see that it and the next three consecutive group addresses are mapped to Fedora. Continuing the sequence, the next four addresses are mapped to Stetson. Across the entire range of IP multicast addresses, there should be a 50-50 distribution between the two RPs.

Example 6-47 The Hash Algorithm Distributes Group Addresses Evenly Among the Available C-RPs

Bowler#show ip pim rp-hash 231.1.1.0

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:14, expires: 00:02:29 Bowler#show ip pim rp-hash 231.1.1.1 RP 10.224.1.2 (?) , v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:19, expires: 00:02:24 Bowler#show ip pim rp-hash 231.1.1.2 RP 10.224.1.2 (?), v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:22, expires: 00:02:21 Bowler#show ip pim rp-hash 231.1.1.3 RP 10.224.1.2 (?), v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:28, expires: 00:02:15 Bowler#show ip pim rp-hash 231.1.1.4 RP 10.224.1.1 (?), v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:31, expires: 00:02:13 Bowler#show ip pim rp-hash 231.1.1.5 RP 10.224.1.1 (?), v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:35, expires: 00:02:10 Bowler#show ip pim rp-hash 231.1.1.6 RP 10.224.1.1 (?), v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:38, expires: 00:02:06 Bowler#show ip pim rp-hash 231.1.1.7 RP 10.224.1.1 (?), v2

Info source: 10.224.1.2 (?), via bootstrap Uptime: 07:22:43, expires: 00:02:02

Was this article helpful?

0 0
100 SEO Tips

100 SEO Tips

100 SEO Tips EVERY SEO Enthusiast Should Know. This Report 100 SEO Tips will help you to Utilize These Tips to Dominate The Search Engine Today.

Get My Free Ebook


Post a comment