[Xorp-users] Problems with bootstrap and rp selection in pimsm
Dan Rosenqvist
danro at kth.se
Mon Jun 18 04:09:45 PDT 2012
Hi,
I've been investigating two separate scenarios and think I've found the problem. In the scenario given below, the problem was not related to XORP, but rather to the rp_filter (/proc/sys/net/ipv4/config/all/rp_filter) being activated.
The rp_filter is intended to block spoofed IP packets by verifying that the source address matches the network-address of the interface from which it originates. By setting the rp_filter to 0, the network worked as intended.
I will continue to investigate the problems I've been having in larger networks (to verify that the rp_filter is the real cause of the problem), and get back to you with my findings.
My scenario is posted below. I used "iperf -u -s -B <mcastgroup>" on the server side and "iperf -u -c <mcastgroup> -T 5" on the client side to test the multicast routing (alternated between Host1 and Host2).
Regards,
Dan
[Host1 eth0] --- [eth0 Router1 eth1] --- [eth0 Router2 eth1] --- [eth0 Router3 eth1] --- [eth0 Host2]
----Config R1----
interfaces {
interface "my_discard" {
unreachable: true
vif "my_discard" {
}
}
interface "eth0" {
vif "eth0" {
address 10.0.0.10 {
prefix-length: 24
}
}
}
interface "eth1" {
vif "eth1" {
address 10.10.0.10 {
prefix-length: 24
}
}
}
}
fea {
unicast-forwarding4 {
disable: false
}
}
plumbing {
mfea4 {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
interface "register_vif" {
vif "register_vif" {
disable: false
}
}
}
}
protocols {
static {
interface-route 0.0.0.0/0 {
next-hop-interface: "my_discard"
next-hop-vif: "my_discard"
}
}
ospf4 {
router-id: 1.1.1.1
area 0.0.0.0 {
interface "eth0" {
vif "eth0" {
address 10.0.0.10 {
interface-cost: 1
}
}
}
interface "eth1" {
vif "eth1" {
address 10.10.0.10 {
interface-cost: 1
}
}
}
}
}
fib2mrib {
disable: false
}
igmp {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
}
pimsm4 {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
interface "register_vif" {
vif "register_vif" {
disable: false
}
}
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
}
}
}
}
}
----End config R1----
----Config R2----
interfaces {
interface "my_discard" {
unreachable: true
vif "my_discard" {
}
}
interface "eth0" {
vif "eth0" {
address 10.10.0.20 {
prefix-length: 24
}
}
}
interface "eth1" {
vif "eth1" {
address 10.20.0.20 {
prefix-length: 24
}
}
}
}
fea {
unicast-forwarding4 {
disable: false
}
}
plumbing {
mfea4 {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
interface "register_vif" {
vif "register_vif" {
disable: false
}
}
}
}
protocols {
static {
interface-route 0.0.0.0/0 {
next-hop-interface: "my_discard"
next-hop-vif: "my_discard"
}
}
ospf4 {
router-id: 2.2.2.2
area 0.0.0.0 {
interface "eth0" {
vif "eth0" {
address 10.10.0.20 {
interface-cost: 1
}
}
}
interface "eth1" {
vif "eth1" {
address 10.20.0.20 {
interface-cost: 1
}
}
}
}
}
fib2mrib {
disable: false
}
igmp {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
}
pimsm4 {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
interface "register_vif" {
vif "register_vif" {
disable: false
}
}
bootstrap {
disable: false
cand-bsr {
scope-zone 224.0.0.0/4 {
cand-bsr-by-vif-name: "eth1"
bsr-priority: 190
}
}
cand-rp {
group-prefix 224.0.0.0/4 {
cand-rp-by-vif-name: "eth1"
rp-priority: 190
}
}
}
}
}
----End config R2----
----Config R3----
interfaces {
interface "my_discard" {
unreachable: true
vif "my_discard" {
}
}
interface "eth0" {
vif "eth0" {
address 10.20.0.30 {
prefix-length: 24
}
}
}
interface "eth1" {
vif "eth1" {
address 10.30.0.30 {
prefix-length: 24
}
}
}
}
fea {
unicast-forwarding4 {
disable: false
}
}
plumbing {
mfea4 {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
interface "register_vif" {
vif "register_vif" {
disable: false
}
}
}
}
protocols {
static {
interface-route 0.0.0.0/0 {
next-hop-interface: "my_discard"
next-hop-vif: "my_discard"
}
}
ospf4 {
router-id: 3.3.3.3
area 0.0.0.0 {
interface "eth0" {
vif "eth0" {
address 10.20.0.30 {
interface-cost: 1
}
}
}
interface "eth1" {
vif "eth1" {
address 10.30.0.30 {
interface-cost: 1
}
}
}
}
}
fib2mrib {
disable: false
}
igmp {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
}
pimsm4 {
disable: false
interface "eth0" {
vif "eth0" {
disable: false
}
}
interface "eth1" {
vif "eth1" {
disable: false
}
}
interface "register_vif" {
vif "register_vif" {
disable: false
}
}
bootstrap {
disable: false
cand-bsr {
scope-zone 224.0.0.0/4 {
cand-bsr-by-vif-name: "eth1"
bsr-priority: 191
}
}
cand-rp {
group-prefix 224.0.0.0/4 {
cand-rp-by-vif-name: "eth1"
rp-priority: 191
}
}
}
}
}
----End config R3----
________________________________
Från: xorp-users-bounces at xorp.org [xorp-users-bounces at xorp.org] för Dan Rosenqvist [danro at kth.se]
Skickat: den 16 juni 2012 17:49
Till: david at commroom.net
Kopia: xorp-users at xorp.org
Ämne: Re: [Xorp-users] Problems with bootstrap and rp selection in pimsm
Hi David,
Thank you for your thorough answer, much apprechiated! I havn't kept the configuration I used in the last setup, but while experimenting with PIM-SM in XORP, I've come across this problem in several configurations.
I will try to setup a small example today and post all the configurations and logs necessary.
Regarding your answer and the follow-up questions I can say that I'm not interested (at the moment) in dividing the multicast addressing (different RPs for different addresses) but rather that every router is a cand-rp, and let the bsr select which one to use. I'm also mostly interested in ASM rather than SSM (I don't have fixed senders or receivers).
Once again, thank you! I'll be back shortly with more information.
Regards,
Dan
________________________________
Från: David Davidson [david at commroom.net]
Skickat: den 16 juni 2012 17:14
Till: Dan Rosenqvist
Kopia: xorp-users at xorp.org
Ämne: Re: [Xorp-users] Problems with bootstrap and rp selection in pimsm
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/<http://www.xorp.org/config/>.
Regards,
Dan
_______________________________________________
Xorp-users mailing list
Xorp-users at xorp.org<mailto: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/20120618/473df0b6/attachment-0001.html
More information about the Xorp-users
mailing list