<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Nimbus Sans L">Hi Dan:<br>
<br>
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.<br>
<br>
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:<br>
<br>
</font><font face="Nimbus Sans L">[Rec]</font><font face="Nimbus
Sans L">---[eth0 R1 eth1]---[Sdr]---[eth0 R2 eth1]---[Rec]<br>
Or:<br>
</font><font face="Nimbus Sans L">[Sdr]</font><font face="Nimbus
Sans L">---[eth0 R1 eth1]---</font><font face="Nimbus Sans L">[eth0
R2 eth1]---[Rec]</font><br>
<font face="Nimbus Sans L"><br>
Or something to this effect; note that [Rec] is a receiver and
[Sdr] is a sender in the basic example I did above.<br>
<br>
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 <i>could</i> 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.<br>
<br>
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).<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
David<br>
<br>
<br>
</font> <br>
<br>
On 05/23/2012 04:46 AM, Dan Rosenqvist wrote:
<blockquote
cite="mid:54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">Hi,<br>
<br>
There seems to be an error/bug in xorps bootstrap mechanism for
the pimsm4 <br>
protocol. In my test network, I've set up two adjacent routers
both running <br>
ospf4 as well as pimsm4.<br>
<br>
Each of these have bootstrap enabled with one cand-bsr and one
cand-rp each. As <br>
the bootstrap router gets elected, one of the routers will have
one selected rp <br>
in the list of rps (from "show pim rps"), while the other one
will have two rps.<br>
<br>
This will cause strange behaviour in the routing of multicast
packets.<br>
<br>
If I remove one cand-rp from one of the nodes, I get the normal
(expected) <br>
behaviour. I suspect that this is a bug. If you can't post
several candidate<br>
rps, what's the use of a bootstrap mechanism?<br>
<br>
Has anyone else seen similar errors/problems? Is there a known
solution?<br>
<br>
Here's the bootstrap part of router 1 and router 2:<br>
<br>
--- R1 ---<br>
<br>
bootstrap {<br>
disable: false<br>
cand-bsr {<br>
scope-zone 224.0.0.0/4 {<br>
cand-bsr-by-vif-name: "eth1"<br>
bsr-priority: 189<br>
}<br>
}<br>
cand-rp {<br>
group-prefix 224.0.0.0/4 {<br>
cand-rp-by-vif-name: "eth1"<br>
rp-priority: 189<br>
}<br>
}<br>
}<br>
<br>
--- R2 ---<br>
bootstrap {<br>
disable: false<br>
cand-bsr {<br>
scope-zone 224.0.0.0/4 {<br>
cand-bsr-by-vif-name: "eth0"<br>
bsr-priority: 190<br>
}<br>
}<br>
cand-rp {<br>
group-prefix 224.0.0.0/4 {<br>
cand-rp-by-vif-name: "eth0"<br>
rp-priority: 190<br>
}<br>
}<br>
}<br>
<br>
In these configurations R1s eth1 interface and R2s eth0
interface are connected<br>
to the same subnet.<br>
<br>
I haven't posted the entire configurations of the two routers,
but they are in <br>
line with the configurations in <a
class="moz-txt-link-abbreviated"
href="http://www.xorp.org/config/">www.xorp.org/config/</a>.<br>
<br>
Regards,<br>
Dan<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Xorp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xorp-users@xorp.org">Xorp-users@xorp.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users</a>
</pre>
</blockquote>
</body>
</html>