Bootstrap Router
The Bootstrap Router (BSR) capability was added in PIM version 2. It automates and simplifies the Auto-RP process. It is enabled by default in Cisco IOS releases supporting PIMv2.
There are interoperability and design issues with PIM v1. See the Configuration Guide for more advice on this. The short form of the advice is to set up your BSR to also be Auto-RP mapping agent, make sure all RP's run PIMv2, and then the PIM versions can interoperate. We'll assume you have upgraded your routers and all are running PIM v2. This means you'll have one active RP per multicast group, compared to several for the same group in PIMv1. You configure sparse-dense-mode on interfaces, since Sparse or Dense are now properties of a multicast group, not an interface.
PIMv1 plus Auto-RP does the same tasks as BSR. But Auto-RP is Cisco proprietary, whereas PIMv2 with BSR is an IETF standards track protocol, which means it should interoperate with routers from other vendors.
To use Bootstrap Router, configure one or more candidate BSR's. These should be well-placed, in the core of your network with good connectivity. Configuration command:
The type number part of this refers to the interface whose address is used to identify the BSR. The hash-mask-length is how many bits of a multicast group address to use before consulting a hash table of RP's. The priority is for election as BSR. The hashing allows load balancing across multiple RP's for a range of groups. Only one RP will be used for each group, but the hashing will divide up which RP is used for which group. The hashing scheme is deterministic, so that all routers will use the same scheme and determine the same RP for each group.
You also have to configure one or more candidate RPs, as with Auto-RP. RP's should also be well-connected and in a high-speed and accessible portion of the network.
The arguments are identical to those for the send-rp-announce command arguments above. (Interface for RP identity, access list controlling which multicast groups the router is to be an RP candidate for.)
The actual operation of BSR is a bit different than Auto-RP. First, a single BSR is elected, based on configured priority. (Highest IP address is used as a tie-breaker.) Candidate RP's then unicast announcements to this BSR, which stores all of the announcements. The BSR periodically floods BSR messages to all the other routers, hop by hop. The flooding is to 224.0.0.13 (all PIM routers) with TTL one. (All 224.0.0.x multicasts are link-local in scope.) Default flooding interval is 60 seconds. If a candidate BSR does not receive a BSR message within 150 seconds, it starts an election. It starts announcing itself until a BSR message with a higher priority is received.
To set up BSR domains, you need to stop BSR messages from going between the domains. This is done simply, via an interface command:
This causes the interface to neither send nor receive BSR messages on that interface. This is much simpler than TTL scoping!
There are interoperability and design issues with PIM v1. See the Configuration Guide for more advice on this. The short form of the advice is to set up your BSR to also be Auto-RP mapping agent, make sure all RP's run PIMv2, and then the PIM versions can interoperate. We'll assume you have upgraded your routers and all are running PIM v2. This means you'll have one active RP per multicast group, compared to several for the same group in PIMv1. You configure sparse-dense-mode on interfaces, since Sparse or Dense are now properties of a multicast group, not an interface.
PIMv1 plus Auto-RP does the same tasks as BSR. But Auto-RP is Cisco proprietary, whereas PIMv2 with BSR is an IETF standards track protocol, which means it should interoperate with routers from other vendors.
To use Bootstrap Router, configure one or more candidate BSR's. These should be well-placed, in the core of your network with good connectivity. Configuration command:
ip pim bsr-candidate type number hash-mask-length [priority]The type number part of this refers to the interface whose address is used to identify the BSR. The hash-mask-length is how many bits of a multicast group address to use before consulting a hash table of RP's. The priority is for election as BSR. The hashing allows load balancing across multiple RP's for a range of groups. Only one RP will be used for each group, but the hashing will divide up which RP is used for which group. The hashing scheme is deterministic, so that all routers will use the same scheme and determine the same RP for each group.
You also have to configure one or more candidate RPs, as with Auto-RP. RP's should also be well-connected and in a high-speed and accessible portion of the network.
ip pim rp-candidate type number [group-list access-list] [bidir]The arguments are identical to those for the send-rp-announce command arguments above. (Interface for RP identity, access list controlling which multicast groups the router is to be an RP candidate for.)
The actual operation of BSR is a bit different than Auto-RP. First, a single BSR is elected, based on configured priority. (Highest IP address is used as a tie-breaker.) Candidate RP's then unicast announcements to this BSR, which stores all of the announcements. The BSR periodically floods BSR messages to all the other routers, hop by hop. The flooding is to 224.0.0.13 (all PIM routers) with TTL one. (All 224.0.0.x multicasts are link-local in scope.) Default flooding interval is 60 seconds. If a candidate BSR does not receive a BSR message within 150 seconds, it starts an election. It starts announcing itself until a BSR message with a higher priority is received.
To set up BSR domains, you need to stop BSR messages from going between the domains. This is done simply, via an interface command:
interface serial 0
ip pim bsr-border
This causes the interface to neither send nor receive BSR messages on that interface. This is much simpler than TTL scoping!
Comments