Chapter 9 BSR

Chapter 9: Bootstrap Router (BSR) Protocol
In this chapter of IPv4/6 Multicast Operation and Troubleshooting, the processes and the functionality of the Bootstrap Router (BSR) protocol are examined in great depth. Once the operational characteristics of this important protocol are detailed completely, the focus becomes that of troubleshooting. This includes the careful examination of symptoms, a fault isolation methodology, and the implementation of repairs for the Bootstrap Routing (BSR) protocol. The chapter begins with a thorough review of BSR, and then quickly launches in to an exhaustive analysis of the art of troubleshooting this multicast support protocol. This important chapter concludes with sample troubleshooting scenarios, reference materials for the most important show and debug commands, and exciting challenges that allow readers to practice implementing the troubleshooting skills they have obtained.
IPv4/6 Multicast Operation and Troubleshooting
BSR Technology Review

Bootstrap router (BSR) was created as an open standard solution meant to address many of the shortcomings in the Cisco proprietary AutoRP technology. The Protocol Independent Multicast Sparse Mode (PIM-SM) version 2 specification introduced BSR. Note: Many texts refer to BSR as simply PIM-SM version 2. While BSR addresses many issues with AutoRP, it operates in a very similar manner when examined from a high level. There are router(s) that act as candidate-Rendezvous Points (RPs) and router(s) that act similar to the Mapping Agent (MA) found in AutoRP. In BSR terminology, the equivalent to the Mapping Agent is the Bootstrap Router itself. Note: AutoRP is detailed in Chapter 8: AutoRP. Figure 9-1 demonstrates a sample BSR topology.
Figure 9-1: A Sample BSR Topology
9-2
A major design improvement over Ciscos AutoRP is the fact that BSR requires no dense mode operation whatsoever. Rendezvous Point (RP) information is within BSR messages, which are carried inside of Protocol Independent Multicast (PIM) messages themselves. These PIM messages are link-local multicast messages. When a router receives a BSR message containing RP information, the router applies the Reverse Path Forwarding (RPF) check and then floods the message out all of the PIM-enabled interfaces. Remember, the link-local multicast address used for PIM messages is 224.0.0.13. Since the PIM messages that carry the BSR information are link-local in scope, notice that there is no Time to Live (TTL) scoping that can be used with BSR. Note: BSR and AutoRP cannot interoperate directly with each other. Obviously, a key element to the BSR process is the device or devices that want to serve as the Rendezvous Point for multicast groups in the Sparse Mode domain. To configure a candidate-RP in BSR, use the following command: ip pim [vrf vrf-name] rp-candidate interface-type interface-number [bidir] [group-list accesslist] [interval seconds] [priority value] Where: vrf - configures the router to advertise itself as the candidate-RP to the Bootstrap Router for the Virtual Routing and Forwarding (VRF) instance specified for the vrf-name argument interface-type interface-number - the interface bound to the IP address to serve as the candidate-RP IP address; for availability purposes, consider the use of a loopback interface; this interface needs to be PIM enabled bidir - optional - indicates that the multicast groups specified by the access-list argument are to operate in PIM bidirectional mode; PIM bidirectional mode is covered in Chapter 6: Bidirectional PIM group-list - optional - specifies the prefixes that are advertised in association with the RP address; note that unlike AutoRP, this list cannot contain DENY entries interval - optional - specifies the candidate-RP advertisement interval, in seconds; the range is from 1 to 16383 with a default value of 60 seconds priority - optional - specifies the priority for the candidate-RP; the range is from 0 to 255; with a default priority value of 0; the BSR candidate-RP with the lowest priority value is preferred; be aware that other vendor implementations of BSR might default priority to 192 as this is the recommended default priority by the IETF
9-3
As stated earlier, the Bootstrap Router itself in the topology is similar to the Mapping Agent in AutoRP with some subtle differences. Like the AutoRP Mapping Agent, the BSR listens to the candidate-RP announcements, but the BSR does not actually select the best RP for every group range. Instead, the BSR builds a set of candidate-RPs for each group range and disseminates this information to the topology using PIM. Multicast routers that receive these BSR messages select the preferred candidate-RP using a special hash function. To configure the BSR router itself, use the following command: ip pim [vrf vrf-name] bsr-candidate interface-type interface-number [hash-mask-length [priority] ] Where: vrf - configures the router to advertise itself as the Bootstrap Router for the Virtual Routing and Forwarding (VRF) instance specified for the vrf-name argument interface-type interface-number - the interface bound to the IP address to serve as the BSR device IP address; for availability purposes, consider the use of a loopback interface; this interface needs to be PIM enabled and the IP address is sent in BSR messages as the BSR IP address hash-mask-length - optional - the length of the mask to be ANDed with the group address before the PIMv2 hash function; all groups with the same seed hash correspond to the same RP; the hash mask length allows one RP to be used for multiple groups; the default length is 0 priority - priority of the candidate-BSR; the range is from 0 to 255 with a default priority of 0; the candidate-BSR with the highest priority value is preferred; RFC 5059 specifies that 64 be used as the default priority value
It is important to remember that in BSR, the multicast routers determine the RP to use based on RP-set information received from the BSR itself. The RP selection process for a particular multicast group is as follows: Step 1 - a longest match lookup is performed on the group prefix that is announced by the BSR candidate-RPs Step 2 - if more than one candidate-RP is found by the longest match lookup, the candidate-RP with the lowest priority (configured with the ip pim rp-candidate command) is preferred Step 3 - if more than one candidate-RP have the same priority, the BSR hash function is used to select the RP for a group; this hash function is covered in detail in the Operation and Troubleshooting BSR section of this chapter
9-4
Step 4 - if more than one candidate-RP return the same hash value derived from the BSR hash function, the candidate-RP with the highest IP address is preferred Note: RFC 2362 does not specify the longest match lookup step, to ensure compatibility with this standard, configure the same group prefix length for redundant candidate-RPs.
9-5
The Operation and Troubleshooting of BSR

To better understand how to troubleshoot BSR we will divide its basic operation into three distinct stages: BSR election/announcements, candidate-Rendezvous Point announcements, and the propagation of group-to-RP mappings. Once each phase has been outlined and defined, we will see how its operation could be negatively impacted by environmental variables found in the multicasting, IP routing, and switching domains. BSR Election/Announcements In this stage of the BSR operation a Bootstrap Router has either been assigned, or elected on the basis of its configured priority. This works in a two stage process whereby the identity of a BSR is discovered. During this stage, every router that has been configured to work as a Bootstrap Router will begin to flood "bootstrap messages" while simultaneously listening for "bootstrap messages" from other candidate-BSRs in the domain. Once a BSR learns of another BSR with a higher priority it will immediately relinquish its role as BSR. This demonstrates that the BSR election process is preemptive in nature and is designed to provide alternate availability during equipment or process failures. It must be observed that this process ultimately, if configured properly, will result in the election of a single BSR. Other devices may exist in the multicast domain that can assume the role of the BSR, but they will always remain in a standby state until the existing BSR goes down or the priority settings are changed. After the BSR is elected, it will begin attempting to discover the identity of any existing candidate-RPs (CRPs). The BSR will also actively listen for messages coming from these C-RPs as they are discovered. In an effort to find the C-RPs in the domain, the BSR will first begin to inform the other devices in the topology of its existence. BSR accomplishes this using PIM-SM version 2 protocol messages. These messages are flooded on a hop-by-hop basis between all devices in the multicast domain. Figure 9-2 illustrates this process.
Figure 9-2: The BSR Announcing its Presence
9-6
Clearly, BSR can only be employed between PIM version 2 enabled devices. It is important to note that because of this; BSR is not compatible with PIM-SM version 1. The primary difference between PIM-SM versions 1 and 2 is that in version 2, messages are no longer encapsulated inside IGMP. PIM version 2 messages are encapsulated in IP packets with a protocol number of 103. Another significant difference is that PIM-SM version 2 messages are propagated throughout the domain via the link-local multicast group 224.0.0.13 (ALL-PIM-ROUTERS). As described in the BSR Technology Review section, this means that BSR does not require any legacy dense mode functionality to announce its presence throughout the multicast domain as is the case with AutoRP. Fortunately, these distinctions reduce the level of difficulty associated with troubleshooting all phases of the BSR operational process. Placement of the BSR is no longer as sensitive an issue as with its AutoRP counterpart, the Mapping Agent (MA). Furthermore, the use of a link-local multicast address for hop-by-hop flooding of BSR announcements creates fewer overall issues compared to AutoRP in general. The fact that BSR uses a multicast address to communicate its identity and presence to the multicast domain means that this phase of BSR is subjected to Reverse Path Forwarding (RPF) checks. Specifically, any messages destined for PIM speakers in the domain will need to pass the RPF check toward the IP address of the BSR from the C-RP. The multicast process drops messages that fail this check. The fastest method to determine that BSR announcements are being propagated successfully is to execute the show ip pim bsr-router command on each of the respective candidate-RPs. In a working environment, like that shown in Figure 9-3, we would expect to see output similar to the following for this command:
Figure 9-3: A Sample Working BSR Topology
9-7
R5#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.2.2 (?) Uptime: 00:00:21, BSR Priority: 0, Hash mask length: 0 Expires: 00:02:00 Candidate RP: 192.1.5.5(Loopback0) Holdtime 150 seconds Advertisement interval 60 seconds Next advertisement in 00:00:50 Notice the identity of the Bootstrap Router is 192.1.2.2, which is the Loopback0 interface of R2. We have two C-RPs in this topology so we will repeat this show command on the second C-RP: R7#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.2.2 (?) Uptime: 00:12:40, BSR Priority: 0, Hash mask length: 0 Expires: 00:01:59 Candidate RP: 192.1.7.7(Loopback0) Holdtime 150 seconds Advertisement interval 60 seconds Next advertisement in 00:00:49 The second C-RP knows the identity of the BSR as well. Clearly, the BSR announcements have successfully propagated to all C-RPs in the topology. Note: Notice the (?) entry next to the BSR address. This is not a point for concern. This simply means that the C-RP cannot resolve the IP address to a hostname. Earlier it was described how the elected BSR begins to actively listen for messages coming from the CRPs. It is clear now that the C-RPs know where to send their messages thanks to the propagation of the BSR information. Notice also in the output of the show commands used above that there is candidateRP information on both R5 and R7 that needs to be communicated. Also note the holdtime and advertisement intervals for each. Before the next stage of verification, however, execute the same show command on a device participating in the multicast domain that is not a C-RP. For example, R4: R4#sh ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.2.2 (?) Uptime: 00:41:02, BSR Priority: 0, Hash mask length: 0 Expires: 00:01:18
9-8
Note that R4 knows the identity of the BSR, but has no candidate-RP information to communicate. This is a normal condition for this stage of the BSR operation. It is time to take a closer look at the second stage of BSR. Candidate-Rendezvous Point Announcement In the previous section, the election of the BSR was observed, and the process of PIM-SM version 2 announcements were monitored. This resulted in the C-RPs and other PIM devices participating in the multicast domain learning the identity of the BSR. This section focuses on how the BSR dynamically learns the identity of all devices configured as RP candidates. After a C-RP discovers the BSR it will immediately begin to send periodic C-RP advertisements directly to the BSR every 60 seconds via unicast. This is the default advertisement interval and can be changed. The default holdtime is 150 seconds. In addition to notifying the BSR of its identity, the RP candidates also communicate what group-to-RP mappings they possess. Figure 9-4 illustrates this unicast process.
Figure 9-4: The C-RP Announcements
Let us examine the BSR to see if it is receiving the information unicast by the individual C-RPs. Use the show ip pim rp mapping command on the BSR itself to accomplish this:
9-9
R2#show ip pim rp mapping PIM Group-to-RP Mappings This system is the Bootstrap Router (v2) Group(s) 224.0.0.0/4 RP 192.1.7.7 (?), v2 Info source: 172.16.67.7 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:57:49, expires: 00:01:36 RP 192.1.5.5 (?), v2 Info source: 172.16.45.5 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:35:57, expires: 00:01:29 Note the BSR has learned the identity of both candidate-RP devices. The fact that C-RP advertisements are sent via unicast means that RPF checks are unnecessary. This makes this phase of the BSR operational mechanism very streamlined and easy to troubleshoot. Should any information from any RP candidate fail to appear in the BSR's group-to-RP mappings table, it is most likely an IP routing issue. This can quickly be identified by pinging the IP address of the C-RP in question from the BSR. To ensure the proper testing of bidirectional unicast reachability, always source this ping from the BSR's IP address. For example: R2#ping 192.1.7.7 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.1.7.7, timeout is 2 seconds: Packet sent with a source address of 192.1.2.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms In the third and final stage of the BSR operational mechanism, the BSR begins to flood group-to-RP mapping information to other devices in the multicast domain. Propagation of Group-to-RP Mappings In this phase of the BSR operation, the BSR floods all of the group-to-RP C-RP advertisements in its PIM group-to-RP mappings table throughout the multicast domain. In this stage, the information that the BSR communicates is known as the "candidate RP-set" or just "RP-set" for short. This propagation of mappings phase uses the same methodology that the BSR employed to communicate its presence to the RP candidates in the earlier step. This means that if the initial phase of the BSR announcement process operated without complication, then it is highly likely that this stage will
9-10
perform likewise. Figure 9-5 illustrates the hop-by-hop flooding process employed to propagate the RPset information.
Figure 9-5: The C-RP RP-Set Announcements
Remember, this process uses the PIM-SM version 2 multicast address of 224.0.0.13 to communicate with the PIM enabled devices in the network on a hop-by-hop basis. This process, because it employs multicast, is susceptible to the RPF check. The most efficient method employed to test whether or not the BSR has successfully communicated the RP-set information to each of the devices in the topology is to execute the show ip pim rp mapping command on each device participating in the multicast domain. This should produce identical output on all devices similar to the following: R4#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.1.7.7 (?), v2 Info source: 192.1.2.2 150 Uptime: 01:41:24, RP 192.1.5.5 (?), v2 Info source: 192.1.2.2 150 Uptime: 01:19:31,
(?), via bootstrap, priority 0, holdtime expires: 00:01:44 (?), via bootstrap, priority 0, holdtime expires: 00:01:43
The critical component here is that all devices should have the same group-to-RP mappings. Note that both RP candidates are mapped to provide RP services to the entire multicast group range of 224.0.0.0/4.
9-11
Which C-RP will assume the role of RP if a multicast source is introduced to the topology? Emulate a multicast source destined to the group address of 224.9.9.9 on the FastEthernet interface of R1 and examine where the source-based tree terminates: R1#ping 224.9.9.9 repeat 100000 This ping will not be successful because there are no multicast receivers for this group in the topology, but it provides a way to verify what C-RP will assume the role of RP for the group 224.9.9.9. This is proven using the show ip pim rp command on both R5 and R7: R5#show ip pim rp Group: 224.9.9.9, RP: 192.1.7.7, v2, uptime 01:34:58, expires 00:01:30 R7#show ip pim rp Group: 224.9.9.9, RP: 192.1.7.7, v2, next RP-reachable in 00:00:16 The output indicates that the RP is R7 (192.1.7.7). The BSR process selects R7 as the RP because the assigned priority for each of the candidates is the same. In this topology, the Cisco default of priority of 0 is used. In instances where the priority is a tie, the determining factor for RP selection is the highest IP address as described in the BSR Technology Review section. Once again, it is critical to note that this process of RP selection is not performed by the BSR. Unlike the mapping agent in AutoRP, the Bootstrap Router communicates the entire RP-set to the devices in the multicast domain. The individual devices accept the RP-set and then make logical decisions as to which C-RP they select. Network administrators can manipulate or influence this election process through the use of hashes, priorities, filters, and message constraints. Load Balancing Between Candidate-RPs It is possible to distribute RP functionality between multiple C-RPs when configuring BSR. This load balancing is not always a perfectly balanced approach between individual RPs. However, using factors like the total number of available C-RPs and an optional value known as the hash mask length can provide an approximation of load balancing. Assigning a value to the hash mask length greater than the default of "0" directly affects the normal RP selection algorithm that runs on all PIM-SM version 2 enabled devices. Hash mask length is communicated to all devices inside the BSR announcements. Generally, the longer the hash length, the more evenly the BSR process will try to assign groups to individual RPs in the candidate RP-Set. The assumptions are that the same hash mask length is communicated to each PIM-SM version 2 device by the BSR, and that each of those devices has the same candidate RP-set. As a result, each PIM device runs the same algorithm and makes the same RP selection for each multicast group.
9-12
There are three values used by this mathematical function in BSR: the candidate-RP address, a multicast group address, and the hash mask length. These values are all hashed together on a group-by-group basis in order to approximate the load balancing. This process can be summarized as follows: 1 - A hashing algorithm is run for each multicast group address for each C-RP in the RP-set and a hash value is obtained. 2 - The C-RP with the highest calculated hash value becomes the RP for that particular multicast group. 3 - There is the possibility that the hashing algorithm will result in equal hash values for different C-RPs. In this case, the C-RP with the highest IP address will become the RP for that group. With all this taken into account, the outcome should be predicable: 2(32 - hash length) = # of RPs that will be used in load balancing* * This assumes that there are enough C-RPs in the RP-set to allow an even distribution. Figure 9-6 shows a sample topology for load balancing.
Figure 9-6: A Sample C-RP Load Balancing Topology
In this example, there are two candidate-RPs. In order to achieve the most even distribution between these devices apply a hash mask length of 31 to the ip pim bsr-candidate command on R2: R2(config)#ip pim bsr-candidate Loopback0 31 Now verify what RP each device in the topology will use for any given group through the use of the show ip pim rp-hash command. Here is such a test on R4 using the multicast group addresses of 224.1.1.1 and 224.1.1.2:
9-13
R4#show ip pim rp-hash 224.1.1.1 RP 192.1.7.7 (?), v2 Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:18:30, expires: 00:02:06 PIMv2 Hash Value (mask 255.255.255.254) RP 192.1.7.7, via bootstrap, priority 0, hash value 1483128991 RP 192.1.5.5, via bootstrap, priority 0, hash value 1211976133 Note the hash value of R7=1,483,129,991. This is greater than R5's value of 1,211,976,133, so R7 is selected as the RP for the group 224.1.1.1. Now for the group 224.1.1.2: R4#show ip pim rp-hash 224.1.1.2 RP 192.1.5.5 (?), v2 Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:51:56, expires: 00:02:16 PIMv2 Hash Value (mask 255.255.255.254) RP 192.1.7.7, via bootstrap, priority 0, hash value 423840189 RP 192.1.5.5, via bootstrap, priority 0, hash value 694993047 The hashing process selects R5 as the RP because of its higher hash value. Now for 224.1.1.3: R4#show ip pim rp-hash 224.1.1.3 RP 192.1.5.5 (?), v2 Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:52:00, expires: 00:02:12 PIMv2 Hash Value (mask 255.255.255.254) RP 192.1.7.7, via bootstrap, priority 0, hash value 423840189 RP 192.1.5.5, via bootstrap, priority 0, hash value 694993047 Notice the hashing process selects R5 again. One might logically think that it would fall to R7, but notice this is not the case. The algorithm will try to evenly distribute the load between the two available candidate-RPs, but it will do so via a relatively random process, given the wide range of arbitrary variables that go into the hash calculation. The Final Step As one last step to fully demonstrate that our BSR configuration and multicast domain are configured properly, R9 joins the multicast group 224.9.9.9. Verify that a ping test from R1 is successful. R9(config)#interface FastEthernet0/1 R9(config-if)#ip igmp join-group 224.9.9.9 R9(config-if)#end
9-14
This results in successful pings on R1: R1#ping 224.9.9.9 repeat 100000 Type escape sequence to abort. Sending 100000, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds: Reply Reply Reply Reply to to to to request request request request 0 1 2 3 from from from from 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 4 1 1 1 ms ms ms ms
9-15
Common Issues with BSR

While not as problematic as AutoRP, there are a number of issues that can surface with Bootstrap Router protocol. The most common problems relate to the exchange of essential control plane information. By far the control plane establishment in BSR has many more components compared to its data plane process, but when compared to its AutoRP counterpart, BSR is much easier to troubleshoot. For simplicity in troubleshooting common issues while deploying BSR, we identify three categories of problems: Reverse Path Forwarding (RPF) failures, unicast routing issues, and multicast routing problems. RPF Failures In the Troubleshooting BSR section, this text discussed what phases of the BSR operational mechanisms where subject to Reverse Path Forwarding (RPF) checks. Recall that of the three phases, only the BSR election/announcement phase and the propagation of group-to-RP mappings phase are subject to the RPF process. Logically then, RPF issues can prevent a candidate-BSR from learning about other candidate-BSRs. Additionally, this problem can prevent an elected BSR from successfully communicating the candidate RP-set to any, some, or all of the other PIM enabled devices in the multicast domain. The following list of issues has a relatively high probability of occurring thanks to RPF failures. Remember that these RPF checks are performed against the IP address of the BSR itself. Be aware that anytime all interfaces in a network are not running PIM - these issues may arise. Candidate-BSRs do not agree on the identity of the BSR for the multicast domain. All or some of the PIM-SM version 2 enabled devices in the multicast domain do not receive any candidate RP-set information from the elected BSR.
We will perform a walk through for each of these RPF issues in the BSR Sample Troubleshooting Scenarios section that follows. Unicast Routing and Forwarding Problems From earlier portions of this chapter, it is clear that the ability of the RP candidates to communicate their candidate group-to-RP mapping information directly to the BSR is dependent on their ability to unicast to the advertised IP address of the BSR. Of course, since this reachability is unicast, it is not subject to RPF checks. As a result, a common issue is: An elected BSR fails to learn candidate group-to-RP mappings from all or some of the C-RPs in the topology and the IP address of the candidate RP(s) are not reachable when ICMP echoes are sourced from the IP address of the BSR.
9-16
This is a situation where it will be necessary to look at the underlying routing protocols used in the network. Typically, this would be an issue of asynchronous routing, and should be something obvious once the routing tables of the source and transit devices are analyzed. Multicast Routing and Forwarding Problems These problems manifest themselves in more subtle ways when compared to the previous points. As discussed earlier, the majority of the BSR operational mechanisms involve the formation of the control plane so that a device can be assigned as the BSR, and so that C-RP group-to-RP mappings can be communicated to the BSR. From that point, the candidate RP-set information can be propagated throughout the multicast domain. Situations like the following exist when information fails to propagate to any or all devices, but RPF checks and unicast routing seem to be functioning correctly: One or more candidate-RP(s) fail to receive any c-RP-set information from the BSR. One or more candidate-BSR fails to participate in the BSR election process resulting in the assignment of more than one BSR.
In the BSR Sample Troubleshooting Scenarios section that follows, troubleshooting these issues are demonstrated. For each problem, the text demonstrates how to quickly and efficiently verify each symptom, isolate the cause, and remediate the issue.
9-17
BSR Sample Troubleshooting Scenarios

This section provides a detailed look at how to best approach troubleshooting some of the common issues discussed in previous sections. It includes coverage of a methodology for identification, isolation, and remediation of faults in the BSR operational process. The intent here is to hone and develop troubleshooting skills tailored to first identify if a problem is multicast or unicast related, and then how to begin isolating the cause of the fault in the most efficient manner possible. Figure 9-7 illustrates the topology used to explore this topic. Note that R4 and R6 operate as C-RPs and R5 and R7 are C-BSRs:
In the Common Issues with BSR section, three primary types of problems were identified: RPF failures, unicast routing failures, and multicast forwarding and routing failures. This section explores these three categories of failure, by directing our attention to the commands necessary to identify that a problems exists. There are three types of devices in this topology: C-RP(s), C-BSR(s), and transit devices (PIM enabled routers). Step One: Which device won the BSR election - R5 or R7? R5#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.5.5 (?) Uptime: 00:01:35, BSR Priority: 0, Hash mask length: 0 Next bootstrap message in 00:00:25 R5 believes that it is the PIM version 2 Bootstrap Router. Given that the priority is zero, this seems odd, because R7 has a higher IP address. Issue the same show command on R7:
9-18
R7#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.7.7 (?) Uptime: 00:13:11, BSR Priority: 0, Hash mask length: 0 Next bootstrap message in 00:00:48 R7 has also elected itself as the Bootstrap Router. It is not possible for this to happen in a correctly configured BSR environment. This issue seems to indicate that the two candidate-BSR devices have failed to exchange their BSR announcement messages. How are those BSR announcement messages exchanged? As discussed previously, PIM-SM version 2 messages exchange the BSR information, and these Bootstrap messages are how the C-BSRs discover each other and decide which assumes the role of the BSR. The link-local multicast group 224.0.0.13 accomplishes this process and is subject to the RPF check mechanism. There are a number of ways to isolate RPF issues (mstat, mtrace, show ip rpf, debug ip pim bsr), but mstat and mtrace cannot be used with link-local multicast as they result in a "% bad IP group address" message. Eliminating the mstat and mtrace commands leaves either show ip rpf or debug ip pim bsr, or some combination of both. However, this brings up an issue that should be considered. The BSR advertisement interval is fixed at 60 seconds and cannot be changed. This means valuable time could be wasted waiting for results using debug ip pim bsr on all devices in the multicast path. This leaves show ip rpf as the best option to isolate this issue. Does R5 have any RPF issues reaching R7's Loopback0 interface? R5#show ip rpf 192.1.7.7 RPF information for ? (192.1.7.7) RPF interface: FastEthernet0/1 RPF neighbor: ? (172.16.45.4) RPF route/mask: 192.1.7.0/24 RPF type: unicast (eigrp 100) RPF recursion count: 0 Doing distance-preferred lookups across tables No, it does not. Does R7 have any issues reaching R5's Loopback0 interface?
9-19
R7#show ip rpf 192.1.5.5 RPF information for ? (192.1.5.5) failed, no route exists R7 does in fact have an issue related to RPF failure. How would R7 reach the IP address of 192.1.5.5: R7#show ip route 192.1.5.5 Routing entry for 192.1.5.0/24 Known via "eigrp 100", distance 90, metric 163840, type internal Redistributing via eigrp 100 Last update from 172.16.67.6 on FastEthernet0/0, 01:59:59 ago Routing Descriptor Blocks: * 172.16.67.6, from 172.16.67.6, 01:59:59 ago, via FastEthernet0/0 Route metric is 163840, traffic share count is 1 Total delay is 5400 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 4 R7 will use FastEthernet0/0 as the RPF interface. An RPF interface must be configured to participate in PIM-SM version 2 for BSR messages to be exchanged successfully. Use the show ip pim interface command to most quickly verify if this is taking place. R7#show ip pim interface Address 192.1.7.7 172.16.79.7 Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior Loopback0 v2/S 0 30 1 FastEthernet0/1 v2/S 1 30 1
192.1.7.7 172.16.79.9
FastEthernet0/0 is not in the interface list. To remediate this, enable PIM-SM version 2 on R7's FastEthernet0/0 interface. R7(config)#int FastEthernet0/0 R7(config-if)#ip pim sparse-mode Note the PIM neighborship between R7 and R6 immediately comes up. R7(config-if)# %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.67.7 on interface FastEthernet0/0
9-20
Verification in now necessary to determine if one BSR has been elected. Based on the equal priority values, R7 should be elected as the BSR. R7#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.7.7 (?) Uptime: 00:47:31, BSR Priority: 0, Hash mask length: 0 Next bootstrap message in 00:00:29 And R5 should agree: R5#show ip pim bsr PIMv2 Bootstrap information BSR address: 192.1.7.7 (?) Uptime: 00:03:15, BSR Priority: 0, Hash mask length: 0 Expires: 00:01:54 This system is a candidate BSR Candidate BSR address: 192.1.5.5, priority: 0, hash mask length: 0 This output indicates that both R5 and R7 agree that R7 (192.1.7.7) is the BSR. Note that R5 maintains its Candidate-BSR status; it will opt to elect itself BSR should R7 stop functioning. This is part of the normal Active/Passive failover mechanism employed by BSR. Having corrected the issue related to the actual election of the BSR, the next step is to determine whether or not the BSR is learning each of the C-RP RP-sets. This is best accomplished with the show ip rp mapping command on the BSR itself.
9-21
R7#show ip pim rp mapping PIM Group-to-RP Mappings This system is the Bootstrap Router (v2) Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 172.16.67.6 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:21:10, expires: 00:02:16 The BSR is only learning about R6's RP-Set information for the multicast scope of 224.0.0.0/4. How are the C-RPs communicating this information to the BSR? Unicast routing is used to deliver this information from the C-RP, but multicast is used by the BSR to communicate its presence to the individual C-RPs. Has the BSR successfully communicated its existence to both C-RPs? R4#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.7.7 (?) Uptime: 00:03:21, BSR Priority: 0, Hash mask length: 0 Expires: 00:01:48 Candidate RP: 192.1.4.4(Loopback0) Holdtime 150 seconds Advertisement interval 60 seconds Next advertisement in 00:00:35 R6#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.7.7 (?) Uptime: 00:54:57, BSR Priority: 0, Hash mask length: 0 Expires: 00:01:12 Candidate RP: 192.1.6.6(Loopback0) Holdtime 150 seconds Advertisement interval 60 seconds Next advertisement in 00:00:22 R4 and R6 know that R7 is the BSR. These C-RPs now unicast their RP-Set information to the BSR for dissemination throughout the multicast domain. Knowing that this is a unicast problem, the most
9-22
effective tool now is ping. Remember, the unicast of the RP-Set information will be sourced and destined to specific IP addresses, and the easiest method of testing reachability is to verify from the BSR. Specifically, pings should be sourced from the IP address of the BSR to the IP address of each C-RP. R7#ping 192.1.6.6 source 192.1.7.7 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.1.6.6, timeout is 2 seconds: Packet sent with a source address of 192.1.7.7 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms Based on the fact that the BSR learned the RP-set information for R6, it should come as no surprise that unicast reachability exists. R4, however, is the C-RP in question: R7#ping 192.1.4.4 source 192.1.7.7 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.1.4.4, timeout is 2 seconds: Packet sent with a source address of 192.1.7.7 ..... Success rate is 0 percent (0/5) This output is proof of a unicast routing problem between R7 and R4. Now, several options can be used including pinging almost every interface between the two devices. The best course of action in this scenario would be to utilize the traceroute command from the BSR using the same source and destination used in the ping test:
9-23
R7#traceroute 192.1.4.4 source 192.1.7.7 Type escape sequence to abort. Tracing the route to 192.1.4.4 1 172.16.67.6 0 msec 0 msec 0 msec 2 172.16.26.2 4 msec 0 msec 0 msec 3 * * * <output omitted> This output clearly illustrates the fact that the unicast issue exits on the router immediately after R2. According to the topology, this is R4 itself. Go to R4 and verify the contents of the routing table. Specifically, the IP address of interest is the Loopback0 interface of R7 (192.1.7.7): R4#show ip route 192.1.7.7 Routing entry for 192.1.7.7/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 Based on this output, any traffic destined to R7's Loopback0 interface is immediately forwarded to the Null0 interface via the static route configured. To remediate this problem, the best course of action is to remove this static route, and then check if R7 begins to learn RP-sets from both R4 and R6. R4(config)#no ip route 192.1.7.7 255.255.255.255 null 0 Verification on R7 should show that both R4 and R6 are now sending their respective RP-Set information to the BSR:
9-24
R7#show ip pim rp mapping PIM Group-to-RP Mappings This system is the Bootstrap Router (v2) Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 172.16.67.6 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:59:04, expires: 00:02:20 RP 192.1.4.4 (?), v2 Info source: 172.16.24.4 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:00:27, expires: 00:01:58 R6 (192.1.6.6) and R4 (192.1.4.4) have actually succeeded in communicating their RP-sets to the BSR. Now that the BSR has learned each of these sets, the BSR will communicate this information to all PIMSM version 2 enabled devices in the multicast domain. This is observed by issuing the show ip pim rp mapping command on each device: R1#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:12:33, RP 192.1.4.4 (?), v2 Info source: 192.1.7.7 150 Uptime: 01:11:37,
9-25
R2#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 192.1.7.7 150 Uptime: 02:54:14, RP 192.1.4.4 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:11:37,
R4#show ip pim rp mapping PIM Group-to-RP Mappings This system is a candidate RP (v2) Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:12:33, RP 192.1.4.4 (?), v2 Info source: 192.1.7.7 150 Uptime: 01:11:37, R5#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:12:33, RP 192.1.4.4 (?), v2 Info source: 192.1.7.7 150 Uptime: 01:11:37,
9-26
R6#show ip pim rp mapping PIM Group-to-RP Mappings This system is a candidate RP (v2) Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 192.1.7.7 150 Uptime: 02:54:14, RP 192.1.4.4 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:11:37,
R7#show ip pim rp mapping PIM Group-to-RP Mappings This system is the Bootstrap Router (v2) Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 172.16.67.6 (?), via bootstrap, priority 0, holdtime 150 Uptime: 02:10:14, expires: 00:02:14 RP 192.1.4.4 (?), v2 Info source: 172.16.24.4 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:11:37, expires: 00:01:49 R9#show ip pim rp mapping PIM Group-to-RP Mappings R9 has not received any RP-Set information from the BSR. How is this information being communicated? Recall that BSR announcements are sent via multicast. Multicast traffic is susceptible to RPF checks. Failure of the multicast traffic to pass the RPF check can be verified via the show ip rpf command on R9. This test should be done toward the IP address of the BSR.
9-27
R9#show ip rpf 192.1.7.7 RPF information for ? (192.1.7.7) RPF interface: FastEthernet0/1 RPF neighbor: ? (172.16.79.7) RPF route/mask: 192.1.7.0/24 RPF type: unicast (eigrp 100) RPF recursion count: 0 Doing distance-preferred lookups across tables This output indicates that there are no RPF issues. This begs the question, "If there are no RPF failures, what else can cause problems with multicast traffic?" The answer - issues related to the forwarding, routing, and filtering of multicast traffic. debug ip pim bsr is the best tool for troubleshooting issues on one device associated with multicast forwarding and how this can specifically effect BSR messages: R9#debug ip pim bsr PIM-BSR debugging is on R9# PIM-BSR(0): bootstrap dropped In this particular instance, the output of the debug command states specifically that the bootstrap packets are being dropped. This message will appear every 60 seconds, as new BSR announcements arrive from R7. Why are the packets being dropped? Careful observation will show that under the FastEthernet0/1 interface of R9 someone has configured the ip pim bsr-border command.
9-28
R9#show run int f0/1 Building configuration... Current configuration : 165 bytes ! interface FastEthernet0/1 ip address 172.16.79.9 255.255.255.0 ip pim bsr-border ip pim sparse-mode ip igmp join-group 224.9.9.9 duplex auto speed auto end When this command is configured on an interface, no PIM-SM version 2 BSR messages will be sent or received through the interface. Removal of this command will allow R9 to receive the RP-set information. R9(config)#interface fastethernet0/1 R9(config-if)#no ip pim bsr-border Once this is accomplished, perform the verification again: R9#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:00:51, RP 192.1.4.4 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:00:51,
The remediation has worked and now all devices have received complete RP-set information from the information source: 192.1.7.7.
9-29
As a final verification, a simulated source generated on R1 bound for the multicast group 224.9.9.9 can successfully reach R9's FastEthernet0/1 interface: R1#ping 224.9.9.9 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds: Reply Reply Reply Reply Reply Reply Reply Reply Reply Reply to to to to to to to to to to request request request request request request request request request request 0 1 2 3 4 5 6 7 8 9 from from from from from from from from from from 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 172.16.79.9, 1 1 1 1 1 1 1 1 1 1 ms ms ms ms ms ms ms ms ms ms
9-30
BSR show Command Tools

As a quick reference, here are the show command tools utilized in this chapter. This section utilizes the BSR topology in Figure 9-8 for all example output.
show COMMAND: show ip pim [vrf vrf-name] bsr-router This command displays information about a bootstrap router (BSR) Where: vrf optional; specifies the name of the multicast VRF instance
EXAMPLE OUTPUT: R1#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.2.2 (?) Uptime: 00:26:57, BSR Priority: 0, Hash mask length: 0 Expires: 00:01:12
9-31
show COMMAND: show ip pim [vrf vrf-name] rp-hash {group-address | group-name} This command displays the mappings for the PIM group to the active Rendezvous Point(s). Where: vrf optional; specifies the name of the multicast VRF instance group-address the multicast group address
EXAMPLE OUTPUT: R4#show ip pim rp-hash 224.9.9.9 RP 192.1.7.7 (?), v2 Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 03:32:33, expires: 00:01:27 PIMv2 Hash Value (mask 0.0.0.0) RP 192.1.7.7, via bootstrap, priority 0, hash value 390961567 RP 192.1.5.5, via bootstrap, priority 0, hash value 119808709 show COMMAND: show ip pim [vrf vrf-name] rp mapping [rp-address] This command displays the mappings for the PIM group to the active Rendezvous Point(s). Where: vrf optional; specifies the name of the multicast VRF instance rp-address optional; allows the specification of a specific RP IP address in order to filter the output
EXAMPLE OUTPUT: R4#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.1.7.7 (?), v2 Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 03:45:33, expires: 00:01:29 RP 192.1.5.5 (?), v2
9-32
Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 03:45:47, expires: 00:01:30
show COMMAND: show ip rpf [vrf vrf-name] {route-distinguisher | source-address [group-address] [rd routedistinguisher]} [metric] This command displays information that IP multicast routing uses to perform the Reverse Path Forwarding (RPF) check for a multicast source Where: vrf optional; specifies the name of the multicast VRF instance route-distinguisher - Route distinguisher (RD) of a VPNv4 prefix; entering the routedistinguisher argument displays RPF information related to the specified VPN route source-address - IP address or name of a multicast source for which to display RPF information group-address - optional; IP address or name of a multicast group for which to display RPF information rd route-distinguisher - optional; displays the Border Gateway Protocol (BGP) RPF next hop for the VPN route associated with the RD specified for the route-distinguisher argument metric - optional; displays the unicast routing metric
EXAMPLE OUTPUT: R5#show ip rpf 192.1.2.2 RPF information for ? (192.1.2.2) RPF interface: FastEthernet0/1 RPF neighbor: ? (172.16.45.4) RPF route/mask: 192.1.2.0/24 RPF type: unicast (eigrp 100) RPF recursion count: 0 Doing distance-preferred lookups across tables
show COMMAND: show ip pim [vrf vrf-name] neighbor [interface-type interface-number] This command displays information about Protocol Independent Multicast (PIM) neighbors discovered by PIM version 1 router query messages or PIM version 2 hello messages.
9-33
Where: vrf optional; specifies the name of the multicast VRF instance interface-type - optional; restricts the output to information about PIM neighbors reachable on the specified interface
EXAMPLE OUTPUT: R4#show ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 172.16.45.5 FastEthernet0/1 01:17:41/00:01:25 v2 1 / DR S 172.16.46.6 Serial0/0/0.1 01:16:39/00:01:19 v2 1 / S
9-34
BSR debug Command Tools

As a quick reference, here are the debug command tools utilized in this chapter. This section utilizes the BSR topology in Figure 9-9 for all example output.
debug COMMAND: debug ip mpacket [vrf vrf-name] [detail | fastswitch] [access-list] [group] This command displays multicast packets that are received and sent on the device. Where: vrf optional; specifies the name of the multicast VRF instance detail optional; displays IP header and MAC information fastswitch optional; displays IP packet information in the fast path access-list optional; restricts the output per the specified access-list
EXAMPLE OUTPUT: IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=7, ttl=254, prot=1, len=114(100), mroute olist null IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=8, ttl=254, prot=1, len=114(100), mroute olist null IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=9, ttl=254, prot=1, len=114(100), mroute olist null
9-35
debug COMMAND: debug ip pim [vrf vrf-name] [bsr] This command displays the mappings for the PIM group to the active Rendezvous Point(s). Where: vrf optional; specifies the name of the multicast VRF instance
EXAMPLE OUTPUT: R4#debug ip pim bsr PIM-BSR debugging is on R4# PIM-BSR(0): 192.1.2.2 PIM-BSR(0): 192.1.2.2 PIM-BSR(0): bootstrap from non-RPF neighbor R2#debug ip pim bsr PIM-BSR(0): RP-set for 224.0.0.0/4 PIM-BSR(0): RP(1) 192.1.7.7, holdtime 150 sec priority PIM-BSR(0): RP(2) 192.1.5.5, holdtime 150 sec priority PIM-BSR(0): Bootstrap message for 192.1.2.2 originated R2# PIM-BSR(0): RP 192.1.5.5, 1 Group Prefixes, Priority 0, R2# PIM-BSR(0): RP 192.1.7.7, 1 Group Prefixes, Priority 0, R2# R5#debug ip PIM-BSR(0): 0, holdtime PIM-BSR(0): PIM-BSR(0): R5# 0 0 bootstrap forwarded on FastEthernet0/1 bootstrap forwarded on Serial0/0/0.1 (192.1.2.2) on non-RPF path Serial0/0/0.1 or 172.16.24.2 discarded
Holdtime 150 Holdtime 150
pim bsr Build v2 Candidate-RP advertisement for 192.1.5.5 priority 150 Candidate RP's group prefix 224.0.0.0/4 Send Candidate RP Advertisement to 192.1.2.2
9-36
Chapter Challenge: BSR Sample Trouble Tickets

The following section includes three sample Trouble Tickets designed to challenge the troubleshooting skills that have been developed in all previous sections of this chapter. These Trouble Tickets were designed using the Routing & Switching rental racks at www.ProctorLabs.com with the initial configurations provided in the file MCAST-CH9-BSR-TT-INITIAL.txt. Keep in mind these sample Trouble Tickets were also tested against home practice racks and the most popular router emulators. The network topology used in this section is shown in Figure 9-10 below:
Figure 9-10: The Chapter Challenge Topology
Trouble Ticket #1 Your supervisor has brought to your attention that the C-BSR routers R2 and R7 do not agree on the identity of the BSR. You must correct the issue. Trouble Ticket #2 After solving Trouble Ticket #1, your supervisor has observed that a new C-BSR (R5) that has just been introduced in the network does not agree with R2 and R7 regarding the identity of the Bootstrap Router. Correct this issue. Trouble Ticket #3 Your supervisor has notified you that R1 is not receiving any RP-set information from the BSR. You must correct this issue.
9-37
Chapter Challenge: BSR Sample Trouble Tickets Solutions

The following section includes the solutions to the three Trouble Tickets presented in the previous section. Figure 9-11 provides a flowchart that outlines a "quick fire" approach to isolating and remediating issues associated with BSR.
Figure 9-11: BSR Quick Fire Troubleshooting Flowchart
Trouble Ticket #1 Solution Your supervisor has brought to your attention that the C-BSR routers R2 and R7 do not agree on the identity of the BSR. You must correct the issue.
Step 1 - Fault Verification:
9-38
R2 and R7 are the C-BSRs that are of interest in this trouble ticket: R2#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.2.2 (?) Uptime: 00:59:48, BSR Priority: 200, Hash mask length: 0 Next bootstrap message in 00:00:12 R7#show ip pim bsr PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.7.7 (?) Uptime: 03:35:07, BSR Priority: 255, Hash mask length: 0 Next bootstrap message in 00:00:53 These two C-BSRs each think they are the BSR in this topology. This verifies that the problem actually exists. Step 2 - Fault Isolation: The next course of action is to use the mtrace utility to rule out the possibility of an RPF issue. Make certain to perform this process in both directions, first from R2 toward R7, then from R7 toward R2. R2#mtrace 192.1.2.2 192.1.7.7 Type escape sequence to abort. Mtrace from 192.1.2.2 to 192.1.7.7 via RPF From source (?) to destination (?) Querying full reverse path... 0 192.1.7.7 -1 172.16.67.7 PIM [192.1.2.0/24] -2 172.16.67.6 PIM [192.1.2.0/24] -3 172.16.26.2 PIM [192.1.2.0/24] -4 192.1.2.2 There are no problems in the path from R2 to R7. Now reverse the testing:
9-39
R7#mtrace 192.1.7.7 192.1.2.2 Type escape sequence to abort. Mtrace from 192.1.7.7 to 192.1.2.2 via RPF From source (?) to destination (?) Querying full reverse path... 0 192.1.2.2 -1 172.16.26.2 PIM [192.1.7.0/24] -2 172.16.26.6 PIM [192.1.7.0/24] -3 172.16.67.7 PIM [192.1.7.0/24] -4 192.1.7.7 This output indicates that there are no Reverse Path Forwarding errors in the path between the C-BSRs. With this confirmed, the next step in the process is to utilize debug ip pim bsr on all candidate-BSRs and the devices in the path between them. R2#debug ip pim bsr PIM-BSR(0): Bootstrap message for 192.1.2.2 originated R6#debug ip pim bsr PIM-BSR(0): 192.1.2.2 bootstrap forwarded on FastEthernet0/0 R7#debug ip pim bsr PIM-BSR(0): bootstrap dropped The verification clearly demonstrates that R2 generates a Bootstrap message. R6 forwards that Bootstrap message, and R7 drops it. This means that either there is a PIM neighborship issue or a filter/border/boundary command on R7. The FastEthernet0/0 interface of R7 is the only interface capable of receiving any BSR messages from R2 (192.1.2.2). The quickest method to verify this is to execute the show run interface FastEthernet0/0 command on R7:
9-40
R7#show run interface FastEthernet0/0 Building configuration... Current configuration : 135 bytes ! interface FastEthernet0/0 ip address 172.16.67.7 255.255.255.0 ip pim bsr-border ip pim sparse-mode duplex auto speed auto end The ip pim bsr-border command under the interface stops the BSR messages as they arrive at or exit R7. This has unquestionably isolated our fault. Step 3 - Fault Remediation: In this scenario, the ip pim bsr-border command needs to be removed. R7(config)#interface FastEthernet0/0 R7(config-if)#no ip pim bsr-border Step 4 - Verification of Remediation Once the error has been isolated and remediated it is highly recommended to verify that the Trouble Ticket has been repaired using the same method of the initial fault verification. R2#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.7.7 (?) Uptime: 00:01:51, BSR Priority: 255, Hash mask length: 0 Expires: 00:01:18 This system is a candidate BSR Candidate BSR address: 192.1.2.2, priority: 200, hash mask length: 0
9-41
R7#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.7.7 (?) Uptime: 04:14:14, BSR Priority: 255, Hash mask length: 0 Next bootstrap message in 00:00:46 Both the C-BSRs agree that R7 is the BSR (based on the priority of 255), and R2 is continuing to announce itself as a C-BSR should R7 fail. Trouble Ticket #2 Solution After solving Trouble Ticket #1, your supervisor has observed that a new C-BSR (R5) that has just been introduced in the network does not agree with R2 and R7 regarding the identity of the Bootstrap Router. Correct this issue. Step 1 - Fault Verification: R2 and R7 are the C-BSRs that are of interest in this trouble ticket: R2#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.7.7 (?) Uptime: 00:01:51, BSR Priority: 255, Hash mask length: 0 Expires: 00:01:18 This system is a candidate BSR Candidate BSR address: 192.1.2.2, priority: 200, hash mask length: 0 R7#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.7.7 (?) Uptime: 04:14:14, BSR Priority: 255, Hash mask length: 0 Next bootstrap message in 00:00:46 R5#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.5.5 (?) Uptime: 04:15:26, BSR Priority: 255, Hash mask length: 0 Next bootstrap message in 00:00:33
9-42
R2 and R7 agree that R7 is the BSR, but R5 is reporting itself as the BSR in the topology. This verifies that the problem actually exists. Step 2 - Fault Isolation: In order to verify that RPF issues are not at fault, use the mtrace utility. Perform this check in both directions, first from R2 toward R5, and then in reverse. R2#mtrace 192.1.2.2 192.1.7.7 Type escape sequence to abort. Mtrace from 192.1.2.2 to 192.1.7.7 via RPF From source (?) to destination (?) Querying full reverse path... 0 192.1.7.7 -1 172.16.67.7 PIM [192.1.2.0/24] -2 172.16.67.6 PIM [192.1.2.0/24] -3 172.16.26.2 PIM [192.1.2.0/24] -4 192.1.2.2 R5#mtrace 192.1.5.5 192.1.2.2 Type escape sequence to abort. Mtrace from 192.1.5.5 to 192.1.2.2 via RPF From source (?) to destination (?) Querying full reverse path... 0 192.1.2.2 -1 172.16.24.2 PIM [192.1.5.0/24] -2 172.16.24.4 PIM [192.1.5.0/24] -3 172.16.45.5 PIM [192.1.5.0/24] -4 192.1.5.5 Next is the verification of the BSR messaging. Use the debug ip pim bsr command on R2, R4 and R5: R2#debug ip pim bsr PIM-BSR debugging is on R2# PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Loopback0 PIM-BSR(0): 192.1.7.7 bootstrap forwarded on GigabitEthernet0/0 R2 is sending BSR announcements out the Gi0/0 interface directed to R4.
9-43
R4#debug ip pim bsr PIM-BSR debugging is on R4# PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Serial0/0/0.1 PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Loopback0 We see that R4 is forwarding BSR messages from R7 out the Serial0/0/0.1 and on Loopback0, but not out FastEthernet 0/0 toward R5. The next step is to examine PIM neighbor relationships and inspect for multicast boundaries/filters. R4#show ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 172.16.24.2 FastEthernet0/0 22:34:25/00:01:23 v2 1 / S 172.16.46.6 Serial0/0.1 22:35:35/00:01:17 v2 1 / S 172.16.45.5 FastEthernet0/1 22:35:14/00:01:06 v1 1 / DR S Looking carefully at this output on R4 demonstrates that PIM version 2 neighbor relationships have formed across the FastEthernet0/0 and Serial0/0/0.1 interfaces, but a PIM version 1 neighbor relationship has formed across FastEthernet0/1 toward R5. BSR requires the use of PIM-SM version 2 in order to operate. This has isolated our fault. Step 3 - Fault Remediation: In this scenario, ip pim version 2 needs to be configured between R4 and R5: R4(config)#int f0/1 R4(config-if)#no ip pim version 1 R5(config)#int f0/1 R5(config-if)#no ip pim version 1 Step 4 - Verification of Remediation
9-44
Once the error has been isolated and remediated, it is highly recommended to verify that the Trouble Ticket has been repaired using the same method used to verify the fault initially: R2#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.7.7 (?) Uptime: 00:36:11, BSR Priority: 255, Hash mask length: 0 Expires: 00:01:58 This system is a candidate BSR Candidate BSR address: 192.1.2.2, priority: 200, hash mask length: 0 R7#show ip pim bsr-router PIMv2 Bootstrap information This system is the Bootstrap Router (BSR) BSR address: 192.1.7.7 (?) Uptime: 04:48:37, BSR Priority: 255, Hash mask length: 0 Next bootstrap message in 00:00:23 R5#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 192.1.7.7 (?) Uptime: 00:02:06, BSR Priority: 255, Hash mask length: 0 Expires: 00:02:03 This system is a candidate BSR Candidate BSR address: 192.1.5.5, priority: 250, hash mask length: 0 All three C-BSRs agree that R7 is the BSR. Trouble Ticket #3 Solution Your supervisor has notified you that R1 is not receiving any RP-set information from the BSR. You must correct this issue. Step 1 - Fault Verification: R1 is the router of interest in this trouble ticket:
9-45
R1#sh ip pim rp mapping PIM Group-to-RP Mappings R1# R1 is not receiving the C-RP RP-set information from the BSR. This verifies that the problem actually exists. Step 2 - Fault Isolation: To ensure that BSR messages have made it to all PIM devices, use the mtrace utility. Make certain to perform this process from the C-RPs to the BSR. R4#mtrace 192.1.4.4 192.1.7.7 Type escape sequence to abort. Mtrace from 192.1.4.4 to 192.1.7.7 via RPF From source (?) to destination (?) Querying full reverse path... 0 192.1.7.7 -1 172.16.67.7 PIM [192.1.4.0/24] -2 172.16.67.6 PIM [192.1.4.0/24] -3 172.16.26.2 PIM [192.1.4.0/24] -4 172.16.24.4 PIM [192.1.4.0/24] -5 192.1.4.4 There are no problems in the path from R4 to R7. Now repeat the test from R6 to R7: R6#mtrace 192.1.6.6 192.1.7.7 Type escape sequence to abort. Mtrace from 192.1.6.6 to 192.1.7.7 via RPF From source (?) to destination (?) Querying full reverse path... 0 192.1.7.7 -1 172.16.67.7 PIM [192.1.6.0/24] -2 172.16.67.6 PIM [192.1.6.0/24] -3 192.1.6.6 This indicates that there are no RPF errors. Next, execute the debug ip pim bsr command on R1, R4, R5, R2, R6 and R7.
9-46
R1#debug ip pim bsr PIM-BSR debugging is on R1# R1# The output on R1 indicates it is not receiving any BSR messages on Fa0/0 from R5. On R5: R5#debug ip pim bsr PIM-BSR debugging is on R5# PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Loopback0 PIM-BSR(0): 192.1.7.7 bootstrap forwarded on FastEthernet0/0 R5# R5 is forwarding BSR messages from R7 out FastEthernet0/0 toward R1. The previous output on R1 indicated that no BSR messages are arriving. The next verification is to look for RPF failures on R1. R1#sh ip rpf 192.1.7.7 RPF information for ? (192.1.7.7) failed, no route exists R1# The issue is an RPF failure on R1 toward R5. This is best verified by examining the PIM-SM neighbors on R1: R1#sh ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver Address Prio/Mode R1#
DR
There is no neighbor relationship between R1 and R5. A show run interface FastEthernet0/0 command will reveal the issue.
9-47
R1#sh run interface FastEthernet 0/0 Building configuration... Current configuration : 96 bytes ! interface FastEthernet0/0 ip address 172.16.15.1 255.255.255.0 duplex auto speed auto end Looking carefully at this output on R1 demonstrates that PIM-SM version 2 is not enabled on FastEthernet0/0. Step 3 - Fault Remediation: In this scenario, ip pim sparse-mode needs to be configured on FastEthernet0/0. R1(config)#int f0/0 R1(config-if)#ip pim sparse-mode Step 4 - Verification of Remediation Once the error has been isolated and remediated, it is highly recommended to verify that the Trouble Ticket has been repaired using the same method used to verify the fault initially. R1#sh ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.1.6.6 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:00:15, RP 192.1.4.4 (?), v2 Info source: 192.1.7.7 150 Uptime: 00:00:15,
R1 now has the complete C-RP RP-set information as expected.
9-48

Chapter 9 BSR

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chapter 9 BSR

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

BSR Technology Review

Figure 9-1: A Sample BSR Topology

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

The Operation and Troubleshooting of BSR

Figure 9-2: The BSR Announcing its Presence

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

Figure 9-3: A Sample Working BSR Topology

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

Figure 9-4: The C-RP Announcements

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

Figure 9-5: The C-RP RP-Set Announcements

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

Figure 9-6: A Sample C-RP Load Balancing Topology

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

Common Issues with BSR

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

BSR Sample Troubleshooting Scenarios

Figure 9-7: A Sample BSR Topology

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting

Chapter 9: Bootstrap Router (BSR) Protocol

IPv4/6 Multicast Operation and Troubleshooting