From: David Lonnie (david.lonnie@gmail.com)
Date: Mon Jul 28 2008 - 06:37:02 ART
Hi,Scott
Thanks very much.This question messed me for about a week.
And i test all your solutions.
yes. they work perfectly.
I think i should hit the books harder.
Thanks again.
David
On Mon, Jul 28, 2008 at 12:33 AM, Scott Strobeck <scott@strobeck.net> wrote:
> Hi David,
>
> The issue I saw is that the hub (multipoint) configured for sparse mode
> won't, by default, forward mcast back out the interface. You would either
> need to create a tunnel between R2 & R3, or enable "ip pim nbma-mode" on the
> multipoint on R1. If you do a "debug ip pim bsr" on R2, you'll see that it
> never receives the BSR announcement. What you will see, however, is that
> when R2 goes to build its RP-Candidate announcement, it fails because it
> doesn't have the address of the BSR to send the message to.. . . I was
> intrigued, so I dynamipped this. . ..
>
> R2#debug ip pim bsr
> PIM-BSR debugging is on
> R2#
> *Mar 1 18:11:41.399: PIM-BSR(0): Build v2 Candidate-RP advertisement for 10.0.2.2 priority 0, holdtime 150
> *Mar 1 18:11:41.403: PIM-BSR(0): Candidate RP's group prefix 232.0.0.0/5
> *Mar 1 18:11:41.403: PIM-BSR(0): *no bootstrap router address*
> R2#
>
>
> Enabling 'ip pim nbma-mode' on R1 causes the bsr message to make it to R2.
> .. Here's R2 debug afterward. . . Voila, now your RP-mappings are there...
>
> R2#
> *Mar 1 18:15:04.207: PIM-BSR(0): triggered v2 Candidate-RP advertisements to 10.0.3.3
> *Mar 1 18:15:04.231: PIM-BSR(0): 10.0.3.3 bootstrap forwarded on Loopback0
> *Mar 1 18:15:04.231: PIM-BSR(0): 10.0.3.3 bootstrap forwarded on Serial1/0
> *Mar 1 18:15:04.251: PIM-BSR(0): bootstrap (10.0.3.3) on non-RPF path Loopback0 or from non-RPF neighbor 10.0.0.1 discarded
> R2#
> R2#
> R2#
> *Mar 1 18:15:41.571: PIM-BSR(0): Build v2 Candidate-RP advertisement for 10.0.2.2 priority 0, holdtime 150
> *Mar 1 18:15:41.575: PIM-BSR(0): Candidate RP's group prefix 232.0.0.0/5
> *Mar 1 18:15:41.575: PIM-BSR(0): Send Candidate RP Advertisement to 10.0.3.3
> *Mar 1 18:15:41.855: PIM-BSR(0): 10.0.3.3 bootstrap forwarded on Loopback0
> *Mar 1 18:15:41.859: PIM-BSR(0): 10.0.3.3 bootstrap forwarded on Serial1/0
> *Mar 1 18:15:41.875: PIM-BSR(0): bootstrap (10.0.3.3) on non-RPF path Loopback0 or from non-RPF neighbor 10.0.0.1 discarded
> R2#
> R2#
> R2#sh ip pi rp ma
> PIM Group-to-RP Mappings
> This system is a candidate RP (v2)
>
> Group(s) 224.0.0.0/5
> RP 10.0.1.1 (?), v2
> Info source: 10.0.3.3 (?), via bootstrap, priority 0, holdtime 150
> Uptime: 00:00:47, expires: 00:02:17
> Group(s) 232.0.0.0/5
> RP 10.0.2.2 (?), v2
> Info source: 10.0.3.3 (?), via bootstrap, priority 0, holdtime 150
> Uptime: 00:00:09, expires: 00:02:17
> R2#
>
>
> So, NO, the BSR candidate doesn't have to be the hub. In a live
> environment, however, you'd want to choose the bsr and rp's as centrally
> located routers with a good deal of BW. Also, you didn't forget your
> bsr-candidate config, as suggested below.
>
> Now, here's an interesting twist. This set-up is using EIGRP. Everything
> works fine. The first time I did this, however, I used OSPF and ran into a
> problem. Here's the debug on R2 when initially running ospf on the network:
>
> R2#
> *Mar 1 18:42:06.775: PIM-BSR(0): bootstrap (10.0.3.3) on non-RPF path Serial1/0 or from non-RPF neighbor 10.0.0.3 discarded
> R2#
>
> This brings up an interesting difference between OSPF and EIGRP in a
> hub-and-spoke environment. This is the kind of obscure thing they might
> throw into the lab. In the routing table, EIGRP will show the advertising
> router as the next hop, but OSPF will list the originating neighbor on the
> segment. Here's the output below before and after replacing OSPF with
> EIGRP:
>
> R2#sh ip route eigrp
> 10.0.0.0/24 is subnetted, 4 subnets
>
> D 10.0.3.0 [90/2809856] via 10.0.0.1, 02:52:16, Serial1/0
> D 10.0.1.0 [90/2297856] via 10.0.0.1, 02:54:59, Serial1/0
> R2#
>
> R2#sh ip route ospf
> 10.0.0.0/24 is subnetted, 4 subnets
> O 10.0.3.0 [110/65] via *10.0.0.3*, 00:00:04, Serial1/0
> O 10.0.1.0 [110/65] via 10.0.0.1, 00:00:04, Serial1/0
>
> I'm not sure exactly why the RPF check fails (anybody care to go into
> that?), but through experimentation, I found that it didn't like the
> next-hop address being 10.0.0.3 on s1/0. I found two ways to remedy
> this. The first is to change the ospf network types on the serials to
> point-to-point and point-to-multipoint (don't forget your hello intervals).
> (By default, these network types are non-broadcast, so I originally just
> added neighbor statements on R1.) This change fixes the next-hop in the
> routing table:
>
> R2#sh ip route ospf
> 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
> O 10.0.3.0/24 [110/129] via 10.0.0.1, 00:05:01, Serial1/0
> O 10.0.1.0/24 [110/65] via 10.0.0.1, 00:05:01, Serial1/0
> O 10.0.0.1/32 [110/64] via 10.0.0.1, 00:05:01, Serial1/0
>
> The second way to fix this is to add an mroute for 10.0.3.3 with a
> next-hop of 10.0.0.1.
>
> I can see this being a very good situation to throw at you in the real
> lab. How to get it all working depends on the constraints they give you.
> Just remember that when something doesn't work, DEBUG!!!
>
> Good luck,
> Scott
>
>
>
>
> shiran guez wrote:
>
> Hi David
>
> you are missing some config,
>
> ip pim bsr-candidate *type number* *hash-mask-length* [*priority*]
> for the bootstrap router (R1 in your case).
>
> also in hub and spoke you want only the hub to be the RP and not one of the
> spokes!
> also you do not need to set ip pim sparse-dense mode a ip pim sparse is
> enough.
>
> you can read thishttp://www.netcraftsmen.net/welcher/papers/multicast04.html
> or http://cciep3.blogspot.com/2007/10/ccie-pim-auto-rp.html although this is
> explaining AutoRP it will give you some ground for Multicast.
>
> On 7/26/08, David Lonnie <david.lonnie@gmail.com> <david.lonnie@gmail.com> wrote:
>
>
> Hi,experts:
> I have a question about bsr.
> R1,R2,R3 are in frame-relay cloud,and R1 is hub,R2 and R3 are spokes.
>
> R1:
> interface s0/0
> ip pim sparse-dense-mode
> interface l0
> ip pim sparse-dense-mode
>
> access-list 30 permit 224.0.0.0 7.255.255.255
> ip pim rp-candidate Loopback0 group-list 30
>
> R2:
> interface s0/0
> ip pim sparse-dense-mode
> interface l0
> ip pim sparse-dense-mode
>
> access-list 30 permit 232.0.0.0 7.255.255.255
> ip pim rp-candidate Loopback0 group-list 30
>
> R3:
> interface s0/0
> ip pim sparse-dense-mode
> interface l0
> ip pim sparse-dense-mode
>
> ip pim bsr-candidate lo0
>
>
> When i verified on R3:
> R3#sh ip pi rp mapping
> PIM Group-to-RP Mappings
> This system is the Bootstrap Router (v2)
>
> Group(s) 224.0.0.0/5
> RP 11.11.1.1 (?), v2
> Info source: 11.11.123.1 (?), via bootstrap, priority 0, holdtime 210
> Uptime: 00:00:15, expires: 00:03:08
>
>
>
>
> My question is that,why i can's see R2 is RP for 232.0.0.0/5?
> Can somebody explain for me?
>
> This is my debug information.
>
>
> R3#debug ip pim bsr
> *Jul 25 09:44:58.762: PIM-BSR(0): RP 11.11.1.1, 1 Group Prefixes,
> Priority
> 0, H
> oldtime 210
> R5#
> *Jul 25 09:45:03.462: PIM-BSR(0): RP-set for 224.0.0.0/5
> *Jul 25 09:45:03.462: PIM-BSR(0): RP(1) 11.11.1.1, holdtime 210 sec
> priority 0
>
> *Jul 25 09:45:03.466: PIM-BSR(0): Bootstrap message for 11.11.3.3originated
>
> R2#debug ip pim bsr
> *Mar 9 17:42:25.970: PIM-BSR(0): Build v2 Candidate-RP advertisement for
> 11.11.
> 2.2 priority 0, holdtime 210
> *Mar 9 17:42:25.970: PIM-BSR(0): Candidate RP's group prefix 232.0.0.0/5
> *Mar 9 17:42:25.970: PIM-BSR(0): no bootstrap router address
> R2#
> *Mar 9 17:43:26.022: PIM-BSR(0): Build v2 Candidate-RP advertisement for
> 11.11.
> 2.2 priority 0, holdtime 210
> *Mar 9 17:43:26.022: PIM-BSR(0): Candidate RP's group prefix 232.0.0.0/5
> *Mar 9 17:43:26.022: PIM-BSR(0): no bootstrap router address
>
>
>
>
> David
>
>
> _______________________________________________________________________
> Subscription information may be found at:http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:57 ART