[Xorp-users] Problems with bootstrap and rp selection in pimsm
David Davidson
david at commroom.net
Sat Jun 16 08:14:00 PDT 2012
Hi Dan:
So I think that in order to test, we need to get some more information.
First off, we should get a better understanding of the router topology,
and where the multicast senders and receivers are positioned in your
router topology. I understand that you wanted to save some space and
omit a lot of the configuration and that's understandable, but it leaves
us with an unclear picture of the topology, especially where the
senders/receivers are positioned in relation to you BSR routers and RP.
Best practices always suggest having the RP as close to the sender as
possible, so is it safe to assume that your multicast sender is also in
the same subnet as the R1-eth1 and R2-eth0 interfaces? Maybe make us a
basic drawing, something like the following:
[Rec]---[eth0 R1 eth1]---[Sdr]---[eth0 R2 eth1]---[Rec]
Or:
[Sdr]---[eth0 R1 eth1]---[eth0 R2 eth1]---[Rec]
Or something to this effect; note that [Rec] is a receiver and [Sdr] is
a sender in the basic example I did above.
It's also important to note that the PIM-SM protocol permits the use of
multiple RP's. For example, consider the best practices sender
positioning that I mentioned above. Suppose you have a sender positioned
at one of a large network, transmitting on group 239.251.100.1 and you
have a different sender, transmitting a completely different
application, sitting at the opposite end of the same large network,
transmitting on a different group 239.64.0.50. Notice how you /could/
scope 2 different RP's on your network, one of them scoped for
239.0.0.0/9 (covering ALL groups from 239.0.0.0 through
239.127.255.255), which would cover the sender doing the 239.64.0.50
application. And then have a different RP, closer to your other sender,
(the other sending being 239.251.100.1), scoped for 239.128.0.0/9
(covering ALL groups from 238.128.0.0 through 239.255.255.255), here
again, covering that sender. This kind of RP design end up dividing the
239.0.0.0/8 block in half between 2 RP's at two different opposite ends
of the large network. The PIM-SM specification, allows such a
configuration, and because of this, perhaps this could be the reason
that you're going to see 2 different RP's. Again, the key thing to note
here is that a single PIM domain can have multiple RP's.
In the case of scoping both RP's for for 224.0.0.0/4, you will probably
still see both RP's configured and active, but only one of them actually
processing the multicast traffic (except in cases where the streams
might switch over to the shortest path tree if a SPT exists differing
from the path through the RP).
What do you think? You follow me? The key thing here to check to see if
the receivers can join groups and multicast streams through the paths of
both routers; for example, senders on the opposite site of R1 and R2
should be able to receive streams from a sender between R1 and R2, and
vice-versa, or perhaps from one end to the other, depending on where
your listeners and senders are positioned. Can your receivers join
streams through these routers?
If the answer is still no, then we should be given the full picture,
including all of the configuration. In order for this to properly work,
IGMP, mfea plumbing, and the register_vif will need some configuration,
and it's only fair that we're given the full picture of the routers in
order help you troubleshoot and give you some quality help with it.
I think you're right though - I believe there are some potential issues
with this PIM implementation when there is more than one bootstrap RP.
It seems that this should be allowed for fault tolerance or bootstrap
router/RP router redundancy, so I am thinking that this should be
addressed. I have done some initial testing with a topology like this,
and I have seen some oddities in the results, perhaps the same as yours,
but we should still get a better picture of your topology and test it
verbatim.
Please share this with us and I will have a 2nd look at it. If anyone
else has some comments, I would also appreciate them. Thank you folks
and thank you Dan for reporting this.
David
On 05/23/2012 04:46 AM, Dan Rosenqvist wrote:
> Hi,
>
> There seems to be an error/bug in xorps bootstrap mechanism for the
> pimsm4
> protocol. In my test network, I've set up two adjacent routers both
> running
> ospf4 as well as pimsm4.
>
> Each of these have bootstrap enabled with one cand-bsr and one cand-rp
> each. As
> the bootstrap router gets elected, one of the routers will have one
> selected rp
> in the list of rps (from "show pim rps"), while the other one will
> have two rps.
>
> This will cause strange behaviour in the routing of multicast packets.
>
> If I remove one cand-rp from one of the nodes, I get the normal
> (expected)
> behaviour. I suspect that this is a bug. If you can't post several
> candidate
> rps, what's the use of a bootstrap mechanism?
>
> Has anyone else seen similar errors/problems? Is there a known solution?
>
> Here's the bootstrap part of router 1 and router 2:
>
> --- R1 ---
>
> bootstrap {
> disable: false
> cand-bsr {
> scope-zone 224.0.0.0/4 {
> cand-bsr-by-vif-name: "eth1"
> bsr-priority: 189
> }
> }
> cand-rp {
> group-prefix 224.0.0.0/4 {
> cand-rp-by-vif-name: "eth1"
> rp-priority: 189
> }
> }
> }
>
> --- R2 ---
> bootstrap {
> disable: false
> cand-bsr {
> scope-zone 224.0.0.0/4 {
> cand-bsr-by-vif-name: "eth0"
> bsr-priority: 190
> }
> }
> cand-rp {
> group-prefix 224.0.0.0/4 {
> cand-rp-by-vif-name: "eth0"
> rp-priority: 190
> }
> }
> }
>
> In these configurations R1s eth1 interface and R2s eth0 interface are
> connected
> to the same subnet.
>
> I haven't posted the entire configurations of the two routers, but
> they are in
> line with the configurations in www.xorp.org/config/.
>
> Regards,
> Dan
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120616/676183ae/attachment.html
More information about the Xorp-users
mailing list