[Xorp-users] Problems with bootstrap and rp selection in pimsm
David Davidson
david at commroom.net
Mon Jun 18 22:31:53 PDT 2012
Hi Dan:
That's an excellent find! I also discovered your finding to be correct.
How did you find that? So that's an excellent find - thank you for
sharing this.
And so in my testing I found the same thing. First, I used udpcast
instead of iperf. You will notice how I did these in the attachment. I
had host1 be one of the receivers AND the sender, since udpcast requires
there to be 2 (or more) real receivers in order to send a real multicast
stream (if there is only one receiver, it will unicast the stream to the
one receiver which doesn't help our test).
By default, my test machines all had "net.ipv4.conf.all.rp_filter = 1"
set in the /etc/sysctl.conf file.
And then I couldn't join any groups (specifically, host2's join would
not be propagated through the PIM domain, toward the RP and ultimately,
never toward the sender). As soon as I set"net.ipv4.conf.all.rp_filter =
0" in the /etc/sysctl.conf file, and then doing a sysctl -p, it worked.
That would be a permanent solution, or simply doing an echo of zero to
it, meaning, doing a "echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter"
then it also worked perfectly, but this obviously this wouldn't survive
a reboot without modifying /etc/sysctl.conf.
Before noticing this, I did still go ahead and test your configuration
in a vacuum. I like set commands, so please check over my attachment - I
am pretty certain that it's what you're also using on your routers.
After reading what you wrote (and testing it) I found at least one
production XORP machine that I have, that is definitely being used for
multicast, in which the init script (the startup script for XORP) has
"echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter" in the script, which
leads me to believe that there once was a time when I discovered this
myself (I wrote pieces of this particular init script). It puzzled me
because this line was commented in my script, but as it turns out that
this machine has another process that sets this to zero (doing a cat
/proc/sys/net/ipv4/conf/all/rp_filter on that machine returns a zero on
this production machine that I was looking at this evening). So I
discovered this one other time, but I certainly do not recall the why or
the how. Maybe you could share with us how you found this and what led
you to it.
However, I still think that this should work, even with RP checking
being enforced. Many systems enforce reverse path checking, and for a
very good reason. It seems like it would be less secure to have this RP
checking turned off throughout one's routing domain. Often times, many
network vendors implement 2 options for RP checking, one less stricter
than the other; 1 option is just to make sure that the return route is
in the routing table, /no matter what the next-hop interface for that
route/, while the other option would enforce the next-hop interface for
that route. Some refer to these as "loose" and "strict" RP checking.
Notice how the first option, being less strict, and more flexible, would
definitely qualify under a default route; for example, having a
0.0.0.0/0 route on the system would pass the RP check for the less
strict option, even if the route wasn't explicitly configured (as long
as 0/0 was there, this would cover it for the "loose" option).
That said, I am still puzzled as to why this RP checking would affect
multicast numbers. So then I thought, maybe we need to have this set to
a "2" which would make your default route (the 0.0.0.0/0 route you have
resolving to the "my_discard" interface) qualify for the RP check (the
"loose" RP check). Still, this is less than secure in many instances,
depending on the network security policies for a particular organization
-and, it didn't really matter anyway because, during my testing, this
still didn't do the trick. rp_filter = 0 was the only thing that worked.
Also I wanted to share that I also found that regardless of the RP check
(whether set to zero, one, or two) I always had converged on 1 elected
bootstrap router, and there were 3 active RP's, but Router3 was always
the elected BSR. The RP with the priority of 191 always bubbled to the
top of the list when I did a "show pim rps" or "show pim bootstrap rps"
So here again, this should fit the scenario you described - having a
single BSR choose which RP to use for a particular sender.
What do you think? If you find out anything else, please let us know.
Thanks again for testing and reporting!
David
On 06/18/2012 04:09 AM, Dan Rosenqvist wrote:
> 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/.
>>
>> 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/20120618/1872eb8c/attachment-0001.html
-------------- next part --------------
#PIM-SM RP TEST FOR DAN. From XORP users mailing list from 6/18/2012.
#############################################
#ROUTER1
#############################################
configure exclusive
#INTERFACES
set interfaces interface my_discard vif my_discard disable false
set interfaces interface my_discard unreachable true
set interface interface eth0 vif eth0 address 10.0.0.10 prefix-length 24
set interface interface eth1 vif eth1 address 10.10.0.10 prefix-length 24
#FORWARDING
set fea unicast-forwarding4 disable false
#MFEA - dependecy for multicast routing
set plumbing mfea4 disable false
set plumbing mfea4 interface eth0 vif eth0 disable false
set plumbing mfea4 interface eth1 vif eth1 disable false
set plumbing mfea4 interface register_vif vif register_vif disable false
#STATIC DEFAULT ROUTE [to /dev/null]
set protocols static interface-route 0.0.0.0/0 next-hop-interface my_discard
set protocols static interface-route 0.0.0.0/0 next-hop-vif my_discard
#OSPF
set protocols ospf4 router-id 1.1.1.1
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.0.0.10 interface-cost 1
set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 10.10.0.10 interface-cost 1
#IGMP
set protocols igmp disable false
set protocols igmp interface eth0 vif eth0 disable false
set protocols igmp interface eth1 vif eth1 disable false
#PIM-SM2
set protocols pimsm4 disable false
set protocols pimsm4 interface eth0 vif eth0 disable false
set protocols pimsm4 interface eth1 vif eth1 disable false
set protocols pimsm4 interface register_vif vif register_vif disable false
set protocols pimsm4 bootstrap disable false
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 is-scope-zone false
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 cand-bsr-by-vif-name eth1
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 bsr-priority 189
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 is-scope-zone false
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 cand-rp-by-vif-name eth1
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 rp-priority 189
#FIB2MRIB
set protocols fib2mrib disable false
commit
save config
exit configuration-mode
#############################################
#ROUTER2
#############################################
configure exclusive
#INTERFACES
set interfaces interface my_discard vif my_discard disable false
set interfaces interface my_discard unreachable true
set interface interface eth0 vif eth0 address 10.10.0.20 prefix-length 24
set interface interface eth1 vif eth1 address 10.20.0.20 prefix-length 24
#FORWARDING
set fea unicast-forwarding4 disable false
#MFEA - dependecy for multicast routing
set plumbing mfea4 disable false
set plumbing mfea4 interface eth0 vif eth0 disable false
set plumbing mfea4 interface eth1 vif eth1 disable false
set plumbing mfea4 interface register_vif vif register_vif disable false
#STATIC DEFAULT ROUTE [to /dev/null]
set protocols static interface-route 0.0.0.0/0 next-hop-interface my_discard
set protocols static interface-route 0.0.0.0/0 next-hop-vif my_discard
#OSPF
set protocols ospf4 router-id 2.2.2.2
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.0.20 interface-cost 1
set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 10.20.0.20 interface-cost 1
#IGMP
set protocols igmp disable false
set protocols igmp interface eth0 vif eth0 disable false
set protocols igmp interface eth1 vif eth1 disable false
#PIM-SM2
set protocols pimsm4 disable false
set protocols pimsm4 interface eth0 vif eth0 disable false
set protocols pimsm4 interface eth1 vif eth1 disable false
set protocols pimsm4 interface register_vif vif register_vif disable false
set protocols pimsm4 bootstrap disable false
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 is-scope-zone false
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 cand-bsr-by-vif-name eth1
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 bsr-priority 190
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 is-scope-zone false
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 cand-rp-by-vif-name eth1
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 rp-priority 190
#FIB2MRIB
set protocols fib2mrib disable false
commit
save config
exit configuration-mode
#############################################
#ROUTER3
#############################################
configure exclusive
#INTERFACES
set interfaces interface my_discard vif my_discard disable false
set interfaces interface my_discard unreachable true
set interface interface eth0 vif eth0 address 10.20.0.30 prefix-length 24
set interface interface eth1 vif eth1 address 10.30.0.30 prefix-length 24
#FORWARDING
set fea unicast-forwarding4 disable false
#MFEA - dependecy for multicast routing
set plumbing mfea4 disable false
set plumbing mfea4 interface eth0 vif eth0 disable false
set plumbing mfea4 interface eth1 vif eth1 disable false
set plumbing mfea4 interface register_vif vif register_vif disable false
#STATIC DEFAULT ROUTE [to /dev/null]
set protocols static interface-route 0.0.0.0/0 next-hop-interface my_discard
set protocols static interface-route 0.0.0.0/0 next-hop-vif my_discard
#OSPF
set protocols ospf4 router-id 3.3.3.3
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.20.0.30 interface-cost 1
set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 10.30.0.30 interface-cost 1
#IGMP
set protocols igmp disable false
set protocols igmp interface eth0 vif eth0 disable false
set protocols igmp interface eth1 vif eth1 disable false
#PIM-SM2
set protocols pimsm4 disable false
set protocols pimsm4 interface eth0 vif eth0 disable false
set protocols pimsm4 interface eth1 vif eth1 disable false
set protocols pimsm4 interface register_vif vif register_vif disable false
set protocols pimsm4 bootstrap disable false
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 is-scope-zone false
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 cand-bsr-by-vif-name eth1
set protocols pimsm4 bootstrap cand-bsr scope-zone 224.0.0.0/4 bsr-priority 191
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 is-scope-zone false
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 cand-rp-by-vif-name eth1
set protocols pimsm4 bootstrap cand-rp group-prefix 224.0.0.0/4 rp-priority 191
#FIB2MRIB
set protocols fib2mrib disable false
commit
save config
exit configuration-mode
#############################################
#HOST1
#############################################
/etc/init.d/xorp stop
cd /tmp/
ifconfig eth0 10.0.0.50 netmask 255.255.255.0 up
route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.0.0.10
ping -c 300 10.30.0.50
###########
#this makes a 100MB file
###########
cat /usr/lib/xorp/lib/libxorp_bgp.so > /tmp/bgp.so
for i in {1..4}
do
cat /usr/lib/xorp/lib/libxorp_bgp.so >> /tmp/bgp.so
done
######################
#UDP-CAST (SENDER)
######################
cd /tmp/
udp-sender --file /tmp/bgp.so --pipe "gzip -c" --interface eth0 --full-duplex --mcast-data-address 239.239.239.239 --mcast-rdv-address 239.253.253.1 --ttl 15 --min-receivers 2 --nokbd --log /tmp/udp-sender.log
######################
#TEST IPERF
#iperf -u -c <mcastgroup> -T 5
######################
iperf -u -c 239.215.215.215 -T 15
#############################################
#HOST2
#############################################
/etc/init.d/xorp stop
cd /tmp/
ifconfig eth0 10.30.0.50 netmask 255.255.255.0 up
route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.30.0.30
ping -c 300 10.0.0.50
######################
#UDP-RECEIVE
######################
cd /tmp/;rm -f /tmp/bgp.so
udp-receiver --file /tmp/bgp.so --pipe "gzip -d" --nokbd --interface eth0 --ttl 15 --mcast-rdv-address 239.253.253.1
######################
#TEST IPERF
#iperf -u -s -B <mcastgroup>
######################
iperf -u -s -B 239.215.215.215
#############################################
#FOR UDPCAST "2 RECEIVER" TEST:
#SSH TO HOST1 FROM Router2 TO START 2ND MULTICAST CLIENT (this lab only has 2 hosts-you need at least 2 receivers)
#############################################
ssh root at 10.0.0.50
#STOP HERE TO AUTHENTICATE
cd /tmp;mkdir -p /tmp/stream2/;cd /tmp/stream2/
rm -f /tmp/stream2/bgp.so
udp-receiver --file /tmp/stream2/bgp.so --pipe "gzip -d" --nokbd --interface eth0 --ttl 15 --mcast-rdv-address 239.253.253.1
#############################################
#QUICK CHANGE FOR RP_CHECK
#############################################
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
More information about the Xorp-users
mailing list