First of all, let’s take a look at the testbed network we can use for this situation.

In this scenario, routers R2 and R5 represent the two ISPs. Routers R6 and R9 represent our internal network, with two subnets we need to route differently represented by Loopback interfaces Loopback9 (9.9.9.0/24 subnet) and Loopback99 (from a 99.99.99.0/24 subnet) on R9. Router R4 represents a host “somewhere” on the Internet we’ll be using for testing. We’ll pretend to have no access to change any configurations on Internet routers, so only routers R6 and R9 are available to us. Let’s see the initial configurations and clarify few things there.

Initial Network Configuration

R2:

interface GigabitEthernet0/0
 ip address 172.16.24.2 255.255.255.0
!
interface GigabitEthernet0/1
 ip address 172.16.26.2 255.255.255.0
!
router bgp 65002
 neighbor 172.16.24.4 remote-as 65004
 neighbor 172.16.26.6 remote-as 65069
 address-family ipv4
  neighbor 172.16.24.4 activate
  neighbor 172.16.24.4 send-community
  neighbor 172.16.26.6 activate
  neighbor 172.16.26.6 send-community
!

Router R4 is a dual-homed, just like our AS is. We’re using a simple configuration to prevent transit. We will apply a very similar configuration in our AS later.

R4:

interface Loopback4
 ip address 10.0.0.4 255.255.255.255
!
interface FastEthernet0/0
 ip address 172.16.24.4 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.45.4 255.255.255.0
!
router bgp 65004
 neighbor 172.16.24.2 remote-as 65002
 neighbor 172.16.45.5 remote-as 65005
 address-family ipv4
  neighbor 172.16.24.2 activate
  neighbor 172.16.24.2 send-community
  neighbor 172.16.24.2 route-map NO-TRANSIT in
  neighbor 172.16.45.5 activate
  neighbor 172.16.45.5 send-community
  neighbor 172.16.45.5 route-map NO-TRANSIT in
  network 10.0.0.4 mask 255.255.255.255
!
route-map NO-TRANSIT permit 10
 set community no-advertise
!

R5:

interface FastEthernet0/0
 ip address 172.16.56.5 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.45.5 255.255.255.0
!
router bgp 65005
 neighbor 172.16.45.4 remote-as 65004
 neighbor 172.16.56.6 remote-as 65069
 address-family ipv4
  neighbor 172.16.45.4 activate
  neighbor 172.16.45.4 send-community
  neighbor 172.16.56.6 activate
  neighbor 172.16.56.6 send-community
!

Similarly to the configuration on R4, we need to prevent the transit between our ISPs. However, we can’t use the “no-advertise” community here, since we need to advertise the received route(s) to R9. This is easily fixed using “no-export” community instead.

R6:

interface FastEthernet0/0
 ip address 172.16.56.6 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.26.6 255.255.255.0
!
interface Serial0/2/0
 ip address 192.168.69.6 255.255.255.0
!
router bgp 65069
 neighbor 172.16.26.2 remote-as 65002
 neighbor 172.16.56.5 remote-as 65005
 neighbor 192.168.69.9 remote-as 65069
 address-family ipv4
  neighbor 172.16.26.2 activate
  neighbor 172.16.26.2 send-community
  neighbor 172.16.26.2 route-map NO-TRANSIT in
  neighbor 172.16.56.5 activate
  neighbor 172.16.56.5 send-community
  neighbor 172.16.56.5 route-map NO-TRANSIT in
  neighbor 192.168.69.9 activate
  neighbor 192.168.69.9 send-community
  neighbor 192.168.69.9 next-hop-self
!
route-map NO-TRANSIT permit 10
 set community no-export
!

R9:

interface Loopback9
 ip address 9.9.9.9 255.255.255.255
!
interface Loopback99
 ip address 99.99.99.99 255.255.255.255
!
interface Serial0/2/0
 ip address 192.168.69.9 255.255.255.0
!
router bgp 65069
 neighbor 192.168.69.6 remote-as 65069
 address-family ipv4
  neighbor 192.168.69.6 activate
  neighbor 192.168.69.6 send-community
  network 9.9.9.0 mask 255.255.255.0
  network 99.99.99.0 mask 255.255.255.0
!

At this point, router R9 should be able to reach Loopback4 interface advertised by R4 from its Loopback9 and Loopback99 interfaces. Let’s give it a go.

R9:

R9#ping 10.0.0.4 source Loopback9

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
Packet sent with a source address of 9.9.9.9
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R9#ping 10.0.0.4 source Loopback99

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
Packet sent with a source address of 99.99.99.99
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

This works as expected. Now, lets’ work on our “traffic engineering”.

Chosing Different Paths from R9

Let’s say that our goal is to make the traffic between 9.9.9.0/24 and 10.0.0.0/24 take the path R9->R6->R2->R4, while the traffic between 99.99.99.0/24 needs to take the R9->R6->R5->R4 path. We can easily fix this issue using a simple policy-based routing (PBR) configuration on R6.

All we need is to match the source of traffic when it enters R6 from R9 and force it down the specific path. For example, a policy like this may do the trick.

ip access-list standard Network-9
 permit 9.9.9.0 0.0.0.255
!
ip access-list standard Network-99
 permit 99.99.99.0 0.0.0.255
!
route-map Force-Path permit 10
 match ip address Network-9
 set ip next-hop 172.16.26.2
!
route-map Force-Path permit 20
 match ip address Network-99
 set ip next-hop 172.16.56.5
!
interface Serial0/2/0
 ip policy route-map Force-Path
!

We could apply this policy and be done with it. However, there are couple of problems with this. What if the next-hop is not reachable? For example, the remote router crashes, the switch between R6 and R2/R5 drops the packets, etc? We would be black-holing the traffic. This is not a good thing in any kind of a production environment. Is there a way to solve this? As it turns out, there is. We can actually monitor the exit interface, next-hop route, as well as the next-hop itself, using object tracking. We can then have a conditional policy that will be taken into account only when all of these parameters are in place and operational. So, the policy I’m going to apply is a little bit more involved:

R6:

ip access-list standard Network-9
 permit 9.9.9.0 0.0.0.255
!
ip access-list standard Network-99
 permit 99.99.99.0 0.0.0.255
!
track 2 list boolean and
 object 21
 object 22
 object 23
!
track 5 list boolean and
 object 51
 object 52
 object 53
!
track 21 interface FastEthernet0/1 ip routing
track 22 ip route 172.16.26.0 255.255.255.0 reachability
track 23 ip sla 2
track 51 interface FastEthernet0/0 ip routing
track 52 ip route 172.16.56.0 255.255.255.0 reachability
track 53 ip sla 2
!
ip sla 2
 icmp-echo 172.16.26.2 source-ip 172.16.26.6
ip sla schedule 2 life forever start-time now
!
ip sla 5
 icmp-echo 172.16.56.5 source-ip 172.16.56.6
ip sla schedule 5 life forever start-time now
!
route-map Force-Path permit 10
 match ip address Network-9
 set ip next-hop verify-availability 172.16.26.2 10 track 2
!
route-map Force-Path permit 20
 match ip address Network-99
 set ip next-hop verify-availability 172.16.56.5 10 track 5
!
interface Serial0/2/0
 ip policy route-map Force-Path
!

That’s a lot to handle in one go. Let’s break it down a little bit. First off, I start by defining track lists. Track lists are simply multiple tracking objects that will be compared using a single boolean logic. In this case, I have three sub-objects I’m tracking and I’m combining them using “and” logic. In plain English, this means the track list will be “up” if all monitored sub-objects are “up”. The three objects are exit interface’s routing status, next-hop route and the next-hop reachability, which we monitor using IP SLA ICMP-Echo (ping) probe. Finally, it all comes together in a route-map, which uses “verify-availability” keyword to track the next-hop. Let’s see if it all works.

R6:

R6#show track 2
Track 2
  List boolean and
  Boolean AND is Up
    2 changes, last change 00:03:34
    object 21 Up
    object 22 Up
    object 23 Up
  Tracked by:
    ROUTE-MAP 0

R6#show track 5
Track 5
  List boolean and
  Boolean AND is Up
    2 changes, last change 00:03:36
    object 51 Up
    object 52 Up
    object 53 Up
  Tracked by:
    ROUTE-MAP 0

R6#show ip policy
Interface      Route map
Serial0/2/0    Force-Path

R9:

R9#traceroute 10.0.0.4 source Loopback9 

Type escape sequence to abort.
Tracing the route to 10.0.0.4

  1 192.168.69.6 0 msec 4 msec 0 msec
  2 172.16.26.2 4 msec 0 msec 0 msec
  3 172.16.24.4 4 msec *  0 msec

R9#traceroute 10.0.0.4 source Loopback99

Type escape sequence to abort.
Tracing the route to 10.0.0.4

  1 192.168.69.6 4 msec 0 msec 0 msec
  2 172.16.56.5 4 msec 0 msec 4 msec
  3 172.16.45.4 0 msec *  0 msec

This seems to be working, as we expected. What about the return traffic?

R4:

R4#traceroute 9.9.9.9 source Loopback4

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 0 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec
R4#traceroute 99.99.99.99 source Loopback4

Type escape sequence to abort.
Tracing the route to 99.99.99.99

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 4 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec

We can clearly see that R4 is preferring the path R4->R2->R6-?R9 for both destinations. This means that the traffic between 10.0.0.0/24 and 99.99.99.0/24 networks is taking the asymmetric route, which was one of the things we needed to avoid. Let’s handle that part now.

Chosing Different Paths from R4

Let’s not be misguided by the subtitle. Remember that R4 is just another Internet host. We can’t modify any configuration on it, yet we need to influence the decisions it makes.

Possibly the simplest solution in this case would be to take the 9.9.9.0/24 network and prepend our AS when advertising it to R5 and do the same for 99.99.99.0/24 when advertising to R2. In the lab environment, this works like a charm. In real life, all our prepending can be easily overridden with a higher local preference or a similar thing. We can only hint our preference for the incoming traffic – we cannot decide it. It would also be a very simple thing to do. I don’t like simple things, so let’s complicate our solution a little bit.

There is one thing in IP routing that trumps all weights, local preferences and as-paths of this world. It’s a rule that “more specific route always wins”. How about we use that solution for our return traffic? Let’s inject 9.9.9.0/25 and 9.9.9.128/25 towards R2, and 99.99.99.0/25 and 99.99.99.128/25 towards R5. That way, R2 will advertise more specific 9.0.0.0/24 subnets and R5 will do the same for 99.0.0.0/24. To prevent black-holing, we’ll keep advertising both original /24 routes to both R2 and R5. Let’s take a look at that solution.

R6:

ip prefix-list Network-Inject-9 seq 10 permit 9.9.9.0/25
ip prefix-list Network-Inject-9 seq 20 permit 9.9.9.128/25
!
ip prefix-list Network-Inject-99 seq 10 permit 99.99.99.0/25
ip prefix-list Network-Inject-99 seq 20 permit 99.99.99.128/25
!
ip prefix-list Network-Match-9 seq 10 permit 9.9.9.0/24
!
ip prefix-list Network-Match-99 seq 10 permit 99.99.99.0/24
!
ip prefix-list R9 seq 5 permit 192.168.69.9/32
!
route-map Inject permit 10
 set ip address prefix-list Network-Inject-9
!
route-map Inject permit 20
 set ip address prefix-list Network-Inject-99
!
route-map Match permit 10
 match ip address prefix-list Network-Match-9
 match ip route-source prefix-list R9
!
route-map Match permit 20
 match ip address prefix-list Network-Match-99
 match ip route-source prefix-list R9
!
route-map Filter-Specific-R2 deny 10
 match ip address prefix-list Network-Inject-99
!
route-map Filter-Specific-R2 permit 20
!
route-map Filter-Specific-R5 deny 10
 match ip address prefix-list Network-Inject-9
!
route-map Filter-Specific-R5 permit 20
!
router bgp 65069
 address-family ipv4
  bgp inject-map Inject exist-map Match copy-attributes
  neighbor 172.16.26.2 route-map Filter-Specific-R2 out
  neighbor 172.16.56.5 route-map Filter-Specific-R5 out
!

Again, quite a long configuration is in front of us. To solve the problem at hand, I’m using a BGP feature called “inject-map”. This feature works by referencing two route-maps, one to specify the routes to be injected and the other one to specify when these routes should be injected. In this case, my injection map is called “Inject” and the selection route-map is called “Match”. This is where simplicity ends and “IOS mind tricks” begin.

BGP inject-map feature is a tricky one. The “match” route-map must use two prefix-lists; one to match the source of the route (in our case a prefix-list called R9) and the second one to specify the routes to be considered as a condition for injection. We’re using two separate routes as triggers and for some odd reason, we must use two route-map entries to solve this problem. Each of these entries specifies a different prefix-list for the trigger route (Network-Match-9 and Network-Match-99).

The “injection” route-map works in a similar fashion. We have two-entry route-map, which uses two separate prefix-lists to inject more specific routes. These prefix-lists are Network-Inject-9 and Network-Inject-99. At this point, we should have all those more-specific routes in the BGP table on R6.

R6:

R6#show ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*>i9.9.9.0/25       192.168.69.9             0    100      0 i
*>i9.9.9.0/24       192.168.69.9             0    100      0 i
*>i9.9.9.128/25     192.168.69.9             0    100      0 i
*> 10.0.0.4/32      172.16.26.2                            0 65002 65004 i
*                   172.16.56.5                            0 65005 65004 i
*>i99.99.99.0/25    192.168.69.9             0    100      0 i
*>i99.99.99.0/24    192.168.69.9             0    100      0 i
*>i99.99.99.128/25  192.168.69.9             0    100      0 i

The very last bit is to make sure the injected routes are advertised only to those neighbors we want them advertised to. For this purpose, I used Filter-Specific-R2 and Filter-Specific-R5 route-maps. If we examine routes received from R6 on R2 and R5, we should see a different picture on each.

R2:

R2#show ip bgp neighbors 172.16.26.6 routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 9.9.9.0/25       172.16.26.6                            0 65069 i
*> 9.9.9.0/24       172.16.26.6                            0 65069 i
*> 9.9.9.128/25     172.16.26.6                            0 65069 i
*> 99.99.99.0/24    172.16.26.6                            0 65069 i

Total number of prefixes 4

R5:

R5#show ip bgp neighbors 172.16.56.6 routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 9.9.9.0/24       172.16.56.6                            0 65069 i
*> 99.99.99.0/25    172.16.56.6                            0 65069 i
*> 99.99.99.0/24    172.16.56.6                            0 65069 i
*> 99.99.99.128/25  172.16.56.6                            0 65069 i

Total number of prefixes 4

This is exactly what I wanted to see. Last, but not the least, the routing table on R4 should also tell us that our solution worked. We’ll also confirm all this with two tracroutes.

R4:

R4#show ip route bgp
     99.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B       99.99.99.0/25 [20/0] via 172.16.45.5, 00:09:26
B       99.99.99.0/24 [20/0] via 172.16.45.5, 00:09:26
B       99.99.99.128/25 [20/0] via 172.16.45.5, 00:09:26
     9.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B       9.9.9.0/25 [20/0] via 172.16.24.2, 00:09:25
B       9.9.9.0/24 [20/0] via 172.16.45.5, 00:09:26
B       9.9.9.128/25 [20/0] via 172.16.24.2, 00:09:25

R4#traceroute 9.9.9.9 source Loopback4    

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 0 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec

R4#traceroute 99.99.99.99 source Loopback4

Type escape sequence to abort.
Tracing the route to 99.99.99.99

  1 172.16.45.5 0 msec 0 msec 0 msec
  2 172.16.56.6 4 msec 0 msec 0 msec
  3 192.168.69.9 4 msec *  0 msec

There we go, a perfect solution, for a very real problem. Do you have an alternative solution to this? If you do, please post it in the comments below!

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

Print Friendly

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:

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:

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:

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

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

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.

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

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:

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.

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   DR
Address                                                            Prio/Mode
R1#

There is no neighbor relationship between R1 and R5. A show run interface FastEthernet0/0 command will reveal the issue.

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 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:00:15, expires: 00:02:13
 RP 192.1.4.4 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 255, holdtime 150
 Uptime: 00:00:15, expires: 00:02:12

R1 now has the complete C-RP RP-set information as expected.

Print Friendly

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.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

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.

Figure 9-9: A Sample BSR Topology

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 nullIP(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

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 bootstrap forwarded on FastEthernet0/1
PIM-BSR(0): 192.1.2.2 bootstrap forwarded on Serial0/0/0.1
PIM-BSR(0): bootstrap (192.1.2.2) on non-RPF path Serial0/0/0.1 or from non-RPF neighbor 172.16.24.2 discarded 

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 0
PIM-BSR(0):   RP(2) 192.1.5.5, holdtime 150 sec priority 0
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, Holdtime 150
R2#
PIM-BSR(0):  RP 192.1.7.7, 1 Group Prefixes, Priority 0, Holdtime 150
R2# 

R5#debug ip pim bsr
PIM-BSR(0): Build v2 Candidate-RP advertisement for 192.1.5.5 priority 0, holdtime 150
PIM-BSR(0):  Candidate RP's group prefix 224.0.0.0/4
PIM-BSR(0): Send Candidate RP Advertisement to 192.1.2.2
R5#

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

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.

Figure 9-8: A Sample BSR Topology

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

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
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 route-distinguisher]} [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 route-distinguisher 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.

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

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

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:

Figure 9-7: A Sample BSR Topology

 

 

 

 

 

 

 

 

 

 

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:

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?

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 Interface Ver/ Nbr Query DR DR
 Mode Count Intvl Prior
192.1.7.7 Loopback0 v2/S 0 30 1 192.1.7.7
172.16.79.7 FastEthernet0/1 v2/S 1 30 1 172.16.79.9

FastEthernet0/1 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

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.

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 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:

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:

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 PIM-SM 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 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:12:33, expires: 00:01:53
 RP 192.1.4.4 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 01:11:37, expires: 00:01:55 

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 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 02:54:14, expires: 00:01:56
 RP 192.1.4.4 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:11:37, expires: 00:01:56 

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 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:12:33, expires: 00:01:54
 RP 192.1.4.4 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 01:11:37, expires: 00:01:53

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 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:12:33, expires: 00:01:55
 RP 192.1.4.4 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 01:11:37, expires: 00:01:56

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 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 02:54:14, expires: 00:01:53
 RP 192.1.4.4 (?), v2

 Info source: 192.1.7.7 (?), via bootstrap, priority 0, holdtime 150

 Uptime: 00:11:37, expires: 00:01:56

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.

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.

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 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:00:51, expires: 00:01:37
 RP 192.1.4.4 (?), v2
 Info source: 192.1.7.7 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:00:51, expires: 00:01:37

The remediation has worked and now all devices have received complete RP-set information from the information source: 192.1.7.7.

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 to request 0 from 172.16.79.9, 1 ms
Reply to request 1 from 172.16.79.9, 1 ms
Reply to request 2 from 172.16.79.9, 1 ms
Reply to request 3 from 172.16.79.9, 1 ms
Reply to request 4 from 172.16.79.9, 1 ms
Reply to request 5 from 172.16.79.9, 1 ms
Reply to request 6 from 172.16.79.9, 1 ms
Reply to request 7 from 172.16.79.9, 1 ms
Reply to request 8 from 172.16.79.9, 1 ms
Reply to request 9 from 172.16.79.9, 1 ms

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

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 (C-RPs). 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

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

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 C-RPs. 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 candidate-RP 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

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:

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 perform likewise. Figure 9-5 illustrates the hop-by-hop flooding process employed to propagate the RP-set 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 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 01:41:24, expires: 00:01:44
 RP 192.1.5.5 (?), v2
 Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 01:19:31, 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.

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.

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:

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

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 to request 0 from 172.16.79.9, 4 ms
Reply to request 1 from 172.16.79.9, 1 ms
Reply to request 2 from 172.16.79.9, 1 ms
Reply to request 3 from 172.16.79.9, 1 ms

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

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.

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

A major design improvement over Cisco’s 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 access-list] [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

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

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.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

IPexpert is thrilled to introduce the first installment in our NEW Protocol Operation and Troubleshooting Series, IPexpert’s IPv4/IPv6 Multicast Operation and Troubleshooting.  This series was designed around CCIE student feedback on specific protocols and technologies that they feel they struggled with most when preparing for the CCIE Lab exam. IPexpert’s IPv4/IPv6 Multicast Operation and Troubleshooting dives deep into the specific operations and troubleshooting technologies for key multicast areas such as IGMP,  PIM Sparse Mode, multicast security and much more.

Developed by the industry’s most recognized Senior Technical Instructors, Editors, and Consultants, this new book series is sure to assist you in better understanding IPv4/IPv6 Multicast operations, troubleshooting methodologies, and time saving fault isolation techniques.

IPexpert’s IPv4/IPv6 Multicast Operation and Troubleshooting Topics:

I. Introduction to Multicast Troubleshooting
II. IGMP
III. PIM Dense Mode
IV. PIM Sparse Mode
V. PIM Sparse-Dense Mode
VI. Bidirectional PIM
VII. Static RPs
VII. AutoRP
IX. BSR
X.  MSDP
XI. Anycast
XII. MP-BGP for Multicast
XIII. Interdomain Multicast
XIV. Multicast Advanced Features
XV. Multicast Security
XVI. IPv6 PIM
XVII. IPv6 MLD

Each section listed above contains an exhaustive technology review, show and debug command tools, review of common issues, sample troubleshooting scenarios and chapter challenge sample Trouble Tickets with solutions. Sample trouble tickets follow Proctor Labs topologies, and have also been fully tested on home racks and the most popular emulators in use today.

Check out the free sample chapter Chapter 9: Bootstrap Router Protocol to examine this incredible new product series. The full IPv4/IPv6 Multicast Operations and Troubleshooting text releases Feb 20, 2012.

Print Friendly