Devices signal membership in a bidirectional PIM group using explicit Join messages. Sources send multicast traffic up the shared tree toward the Rendezvous Point (RP). The RP then passes traffic down the tree to any receivers on each branch. Note that for these packets passed downstream, there is no fundamental difference between BIDIR-PIM and PIM-SM. The unique behavior is with the traffic that passes from the various sources upstream to the RP.

In PIM-SM, traffic from sources destined for the RP does not flow upstream in the shared tree, but downstream along the shortest path tree of the source until it reaches the RP. From the RP, traffic flows along the shared tree toward all receivers. In BIDIR-PIM, devices can pass traffic up the shared tree toward the RP. To avoid multicast packet looping, BIDIR-PIM introduces a new mechanism called the designated forwarder (DF). This establishes a loop-free shortest path tree rooted at the RP.

The designated forwarder (DF) election takes place for all PIM routers on every network segment and point-to-point link. The procedure selects one router as the DF for every RP of bidirectional groups. The designated forwarder is responsible for forwarding multicast packets received on that network. Routers use unicast routing metrics for this DF election process. The router with the most preferred unicast routing metric to the RP becomes the designated forwarder. This ensures that only one copy of every packet is sent to the RP, even if there are parallel equal-cost paths.

Note: Because a DF is selected for every RP of bidirectional groups, multiple routers may be elected as DF on any network segment.

The procedure for joining the shared tree of a bidirectional group is almost identical to that used in PIM-SM, except that with BIDIR-PIM, the role of the designated router (DR) is assumed by the designated forwarder for the RP. On a network that has local receivers, only the router elected as the DF populates the outgoing interface list (olist) upon receiving Internet Group Management Protocol (IGMP) Join messages. This DF then sends (*, G) Join and Leave messages upstream toward the RP. When a downstream router wishes to join the shared tree, the reverse path forwarding neighbor in the PIM Join and Leave messages is always the DF elected for the interface that leads to the RP. When a router receives a Join or Leave message, and the router is not the DF for the receiving interface, the message is ignored. Otherwise, the router updates the shared tree in the same way as in sparse mode.

Another unique property of BIDIR-PIM is that there is no need to send PIM assert messages. This is because the DF election procedure eliminates parallel downstream paths from any RP. An RP never joins a path back to the source, nor will it send any register stops.

The configuration of BIDIR-PIM on the router is very simple. First, configure PIM sparse-mode on the appropriate interfaces using the command ip pim sparse-mode. Then, use the global configuration mode command for BIDIR-PIM:

ip pim bidir-enable

Finally, to configure the BIDIR-PIM RP, use the command:

ip pim rp-address rp-address [access-list] [override] bidir

Where:

• access-list – permits the specification of the bidirectional multicast group
• override – specifies that if dynamic and static group-to-RP mappings are used together and there is an RP address conflict, the RP address configured for a static group-to-RP mapping will take precedence

Want to learn more about this multicast technology, as well as others that are covered in Cisco CCIE certification tracks? Check out IPv4/v6 Multicast Operation and Troubleshooting book from IPexpert.

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

Print Friendly

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

This code is not valid for the following products:

Any Instructor Led Bootcamp Course (Live or Online)
Online Learning Subscription
Blended Learning Solution – Use Coupon Code BLSCCFEB  to save $1500.

• CCIE R&S  Blended Learning Solution
• CCIE Voice Blended Learning Solution
• CCIE Security Blended Learning Solution

Note:

Offer ends Monday, February 6th, 2012 at 8:00 AM EST
Valid for all new orders only, and orders must be placed through website
(not called in or ordered via telephone).
Cannot be combined with any other promotion or discount.
NOTICE: These products will be issued to your account Monday morning.

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

	What’s included in our CCIE R&S Bundle Promotion? CCIE R&S 4.0 Lab Preparation Workbook, Volume 1 (eBook) Detailed Solution Guide, CCIE R&S Volume 1 (eBook) CCIE R&S 4.0 Lab Preparation Workbook, Volume 2 (eBook) Detailed Solution Guide, CCIE R&S Volume 2 (eBook) CCIE R&S 4.0 Lab Preparation Workbook, Volume 3 (eBook) Detailed Solution Guide, CCIE R&S Volume 3 (eBook) CCIE R&S 4.0 Lab Video On Demand (Streaming) Student Handbook for CCIE R&S VOD (eBook) Topology Book for CCIE R&S VOD (eBook) 25 – 8 Hour CCIE R&S vRack Vouchers Retail Price: $2246 Weekend Promotion Price $699
	What’s included in our CCIE Voice Bundle Promotion? CCIE Voice 3.0 Lab Preparation Workbook, Volume 1 (eBook) Detailed Solution Guide, CCIE Voice Volume 1 (eBook) CCIE Voice 3.0 Lab Preparation Workbook, Volume 2 (eBook) Detailed Solution Guide, CCIE Voice Volume 2 (eBook) CCIE Voice 3.0 Lab Video On Demand (Streaming) Student Handbook for CCIE Voice VOD (eBook) Topology Book for CCIE Voice VOD (eBook) 25 – 8 Hour CCIE Voice vRack Vouchers Retail Price $2296 Weekend Promotion Price $799
	What’s included in our CCIE Security Bundle Promotion? CCIE Security 3.0 Lab Preparation Workbook, Volume 1 (eBook) Detailed Solution Guide, CCIE Security Volume 1 (eBook) CCIE Security 3.0 Lab Preparation Workbook, Volume 2 (eBook) Detailed Solution Guide, CCIE Security Volume 2 (eBook) CCIE Security 3.0 Lab Video On Demand (Streaming) Student Handbook for CCIE Security VOD (eBook) Topology Book for CCIE Security VOD (eBook) 25 – 8 Hour CCIE Security vRack Vouchers Retail Price $2047 Weekend Promotion Price $699

Note:

• Offer ends Monday, January 23rd, 2011 at 5:00 PM EST
• Valid for all new orders only, and orders must be placed through website (not called in or ordered via telephone).
• Cannot be combined with any other promotion or discount.
• Video on Demand Course & vRacks will be issued to your account Monday morning.

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