From rps at maine.edu  Fri Jun  1 13:55:21 2012
From: rps at maine.edu (Ray Soucy)
Date: Fri, 1 Jun 2012 16:55:21 -0400
Subject: [Xorp-users] Pica8
Message-ID: <CALFTrnNvAFXyuhFvHh3fywYwfTgjDie7=ezAfyJL-7SyZVkfqA@mail.gmail.com>

Has Pica8 released any source code?

They seem to be using XORP and other GPL software quite a bit but I can't
find any evidence that they're in compliance with the license in offering
source code.

http://www.pica8.org/

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120601/731a8d18/attachment.html 

From igorm at etf.rs  Fri Jun  1 14:15:22 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 1 Jun 2012 23:15:22 +0200
Subject: [Xorp-users] Pica8
In-Reply-To: <CALFTrnNvAFXyuhFvHh3fywYwfTgjDie7=ezAfyJL-7SyZVkfqA@mail.gmail.com>
References: <CALFTrnNvAFXyuhFvHh3fywYwfTgjDie7=ezAfyJL-7SyZVkfqA@mail.gmail.com>
Message-ID: <CAFdo_mXrs7Ppyc_bHeLVpxUctmYG0=D+aVWDhDsbxSBSAPqpug@mail.gmail.com>

Here is the source code:

http://sourceforge.net/projects/xorplus/files/

It was released in 2010.

They announced that they will release the newest version 2 months ago,
but they didn't do anything about it...
(http://pica8.org/blogs/?p=137)

So, what do you think that we can do about that?
BR
Igor

2012/6/1 Ray Soucy <rps at maine.edu>:
> Has Pica8 released any source code?
>
> They seem to be using XORP and other GPL software quite a bit but I can't
> find any evidence that they're in compliance with the license in offering
> source code.
>
> http://www.pica8.org/
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


From greearb at candelatech.com  Fri Jun  1 14:20:38 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 14:20:38 -0700
Subject: [Xorp-users] Pica8
In-Reply-To: <CALFTrnNvAFXyuhFvHh3fywYwfTgjDie7=ezAfyJL-7SyZVkfqA@mail.gmail.com>
References: <CALFTrnNvAFXyuhFvHh3fywYwfTgjDie7=ezAfyJL-7SyZVkfqA@mail.gmail.com>
Message-ID: <4FC93226.8040501@candelatech.com>

On 06/01/2012 01:55 PM, Ray Soucy wrote:
> Has Pica8 released any source code?
>
> They seem to be using XORP and other GPL software quite a bit but I can't find any evidence that they're in compliance with the license in offering source code.
>
> http://www.pica8.org/

First I've heard of them.  I found the xorplus project here, but it's a pretty
dated download:

http://sourceforge.net/projects/xorplus/

Looks like it's based on xorp 1.6, which is quite old at this point.

I can't find any code repositories with change-sets.

Seems they claim their code is licensed GPL, so either they are
still shipping a version from 2010, or they have fallen behind
a bit :P

Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Fri Jun  1 14:32:49 2012
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 01 Jun 2012 14:32:49 -0700
Subject: [Xorp-users] Pica8
In-Reply-To: <CAFdo_mXrs7Ppyc_bHeLVpxUctmYG0=D+aVWDhDsbxSBSAPqpug@mail.gmail.com>
References: <CALFTrnNvAFXyuhFvHh3fywYwfTgjDie7=ezAfyJL-7SyZVkfqA@mail.gmail.com>
	<CAFdo_mXrs7Ppyc_bHeLVpxUctmYG0=D+aVWDhDsbxSBSAPqpug@mail.gmail.com>
Message-ID: <4FC93501.5030603@candelatech.com>

On 06/01/2012 02:15 PM, Igor Maravi? wrote:
> Here is the source code:
>
> http://sourceforge.net/projects/xorplus/files/
>
> It was released in 2010.
>
> They announced that they will release the newest version 2 months ago,
> but they didn't do anything about it...
> (http://pica8.org/blogs/?p=137)
>
> So, what do you think that we can do about that?

Looks like they bought the remains of the xorp corporation.  Xorp
used to be BSD licensed, so they probably can do whatever they like.

That can't legally take later releases (ie, what I maintain)
w/out abiding by the GPL, but for their 1.6 related stuff, I'm
guessing they can do whatever they want.

 From their blog, they re-wrote xorp extensively,
so probably the chance of merging our xorp with the pica-8
stuff is slim to none.

http://pica8.org/blogs/?p=28


Thanks,
Ben


> BR
> Igor
>
> 2012/6/1 Ray Soucy<rps at maine.edu>:
>> Has Pica8 released any source code?
>>
>> They seem to be using XORP and other GPL software quite a bit but I can't
>> find any evidence that they're in compliance with the license in offering
>> source code.
>>
>> http://www.pica8.org/
>>
>> --
>> Ray Soucy
>>
>> Epic Communications Specialist
>>
>> Phone: +1 (207) 561-3526
>>
>> Networkmaine, a Unit of the University of Maine System
>> http://www.networkmaine.net/
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From jens.devel at gmail.com  Fri Jun  8 03:46:16 2012
From: jens.devel at gmail.com (Jens Dackenberg)
Date: Fri, 8 Jun 2012 12:46:16 +0200
Subject: [Xorp-users] Problem regarding policy/network4-list/modifier
Message-ID: <CAMBajAaKXUbzfDbyhU1mp6SX_VMp-L0PQisiO8qSS1A-CNSx_w@mail.gmail.com>

Hi!

I have a problem with defining network4-lists with modifiers in policy
configuration.
So I have the following configuration (see below) but xorp wont start with
it.
I've also tried to make the configuration manually via xorpshell like:
# create policy network4-list No_Advertise network 10.0.0.0/8 modifier
orlonger
# commit
Commit Failed
102 Command failed add_to_set: PolicyException from line 158 of
policy/common/element.cc: Can't init ipv4net using 10.0.0.0/8orlonger

This doesn't happen if I remove "modifier orlonger". Can somebody please
tell me what I'm doing wrong?

Regards,
/Jens

/*-----------------------------------
Parts of the config.boot file
--------------------------------------*/

policy {
    policy-statement "Route_Export" {
        term 10 {
            from {
                protocol: "connected"
                network4-list: "Default_Route"
            }
            then {
                reject {
                }
            }
        }
        term 20 {
            from {
                protocol: "connected"
                network4-list: "No_Advertise"
            }
            then {
                reject {
                }
            }
        }
        term 30 {
            from {
                protocol: "connected"
        prefix-length4 < 32..32
            }
            then {
                accept {
                }
            }
        }
        then {
            reject {
            }
        }
    }
    network4-list "No_Advertise" {
        network 127.0.0.0/8 {
            modifier: "orlonger"
        }
        network 10.0.0.0/8 {
            modifier: "orlonger"
        }
        network 172.16.0.0/12 {
            modifier: "orlonger"
        }
        network 192.168.0.0/16 {
            modifier: "orlonger"
        }
    }
    network4-list "Default_Route" {
        network 0.0.0.0/0
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120608/aa7ada96/attachment.html 

From igorm at etf.rs  Fri Jun  8 06:45:09 2012
From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=)
Date: Fri, 8 Jun 2012 15:45:09 +0200
Subject: [Xorp-users] Problem regarding policy/network4-list/modifier
In-Reply-To: <CAMBajAaKXUbzfDbyhU1mp6SX_VMp-L0PQisiO8qSS1A-CNSx_w@mail.gmail.com>
References: <CAMBajAaKXUbzfDbyhU1mp6SX_VMp-L0PQisiO8qSS1A-CNSx_w@mail.gmail.com>
Message-ID: <CAFdo_mU6tK=ejmbmmsxwh6deTtgkm+38U=54m3d7q9uQh9c9Nw@mail.gmail.com>

I think that you are doing everything wright. I think that I know
where BUG is. String's are concatenated without " " as the code
expects.
I can fix that in Monday.
BR
Igor

2012/6/8 Jens Dackenberg <jens.devel at gmail.com>:
> Hi!
>
> I have a problem with defining network4-lists with modifiers in policy
> configuration.
> So I have the following configuration (see below) but xorp wont start with
> it.
> I've also tried to make the configuration manually via xorpshell like:
> # create policy network4-list No_Advertise network 10.0.0.0/8 modifier
> orlonger
> # commit
> Commit Failed
> 102 Command failed add_to_set: PolicyException from line 158 of
> policy/common/element.cc: Can't init ipv4net using 10.0.0.0/8orlonger
>
> This doesn't happen if I remove "modifier orlonger". Can somebody please
> tell me what I'm doing wrong?
>
> Regards,
> /Jens
>
> /*-----------------------------------
> Parts of the config.boot file
> --------------------------------------*/
>
> policy {
> ??? policy-statement "Route_Export" {
> ??????? term 10 {
> ??????????? from {
> ??????????????? protocol: "connected"
> ??????????????? network4-list: "Default_Route"
> ??????????? }
> ??????????? then {
> ??????????????? reject {
> ??????????????? }
> ??????????? }
> ??????? }
> ??????? term 20 {
> ??????????? from {
> ??????????????? protocol: "connected"
> ??????????????? network4-list: "No_Advertise"
> ??????????? }
> ??????????? then {
> ??????????????? reject {
> ??????????????? }
> ??????????? }
> ??????? }
> ??????? term 30 {
> ??????????? from {
> ??????????????? protocol: "connected"
> ??? ??? prefix-length4 < 32..32
> ??????????? }
> ??????????? then {
> ??????????????? accept {
> ??????????????? }
> ??????????? }
> ??????? }
> ??????? then {
> ??????????? reject {
> ??????????? }
> ??????? }
> ??? }
> ??? network4-list "No_Advertise" {
> ??????? network 127.0.0.0/8 {
> ??????????? modifier: "orlonger"
> ??????? }
> ??????? network 10.0.0.0/8 {
> ??????????? modifier: "orlonger"
> ??????? }
> ??????? network 172.16.0.0/12 {
> ??????????? modifier: "orlonger"
> ??????? }
> ??????? network 192.168.0.0/16 {
> ??????????? modifier: "orlonger"
> ??????? }
> ??? }
> ??? network4-list "Default_Route" {
> ??????? network 0.0.0.0/0
> ??? }
> }
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


From jens.devel at gmail.com  Fri Jun  8 06:55:00 2012
From: jens.devel at gmail.com (Jens Dackenberg)
Date: Fri, 8 Jun 2012 15:55:00 +0200
Subject: [Xorp-users] Problem regarding policy/network4-list/modifier
In-Reply-To: <CAFdo_mU6tK=ejmbmmsxwh6deTtgkm+38U=54m3d7q9uQh9c9Nw@mail.gmail.com>
References: <CAMBajAaKXUbzfDbyhU1mp6SX_VMp-L0PQisiO8qSS1A-CNSx_w@mail.gmail.com>
	<CAFdo_mU6tK=ejmbmmsxwh6deTtgkm+38U=54m3d7q9uQh9c9Nw@mail.gmail.com>
Message-ID: <CAMBajAZ+zBCez7pfParDD6vLPt9eFZeQ3cYsfsKzwy=7az6jhQ@mail.gmail.com>

Great. Thanks!

BR
Jens

2012/6/8 Igor Maravi? <igorm at etf.rs>

> I think that you are doing everything wright. I think that I know
> where BUG is. String's are concatenated without " " as the code
> expects.
> I can fix that in Monday.
> BR
> Igor
>
> 2012/6/8 Jens Dackenberg <jens.devel at gmail.com>:
> > Hi!
> >
> > I have a problem with defining network4-lists with modifiers in policy
> > configuration.
> > So I have the following configuration (see below) but xorp wont start
> with
> > it.
> > I've also tried to make the configuration manually via xorpshell like:
> > # create policy network4-list No_Advertise network 10.0.0.0/8 modifier
> > orlonger
> > # commit
> > Commit Failed
> > 102 Command failed add_to_set: PolicyException from line 158 of
> > policy/common/element.cc: Can't init ipv4net using 10.0.0.0/8orlonger
> >
> > This doesn't happen if I remove "modifier orlonger". Can somebody please
> > tell me what I'm doing wrong?
> >
> > Regards,
> > /Jens
> >
> > /*-----------------------------------
> > Parts of the config.boot file
> > --------------------------------------*/
> >
> > policy {
> >     policy-statement "Route_Export" {
> >         term 10 {
> >             from {
> >                 protocol: "connected"
> >                 network4-list: "Default_Route"
> >             }
> >             then {
> >                 reject {
> >                 }
> >             }
> >         }
> >         term 20 {
> >             from {
> >                 protocol: "connected"
> >                 network4-list: "No_Advertise"
> >             }
> >             then {
> >                 reject {
> >                 }
> >             }
> >         }
> >         term 30 {
> >             from {
> >                 protocol: "connected"
> >         prefix-length4 < 32..32
> >             }
> >             then {
> >                 accept {
> >                 }
> >             }
> >         }
> >         then {
> >             reject {
> >             }
> >         }
> >     }
> >     network4-list "No_Advertise" {
> >         network 127.0.0.0/8 {
> >             modifier: "orlonger"
> >         }
> >         network 10.0.0.0/8 {
> >             modifier: "orlonger"
> >         }
> >         network 172.16.0.0/12 {
> >             modifier: "orlonger"
> >         }
> >         network 192.168.0.0/16 {
> >             modifier: "orlonger"
> >         }
> >     }
> >     network4-list "Default_Route" {
> >         network 0.0.0.0/0
> >     }
> > }
> >
> > _______________________________________________
> > 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/20120608/3687faca/attachment.html 

From david at commroom.net  Sat Jun 16 08:14:00 2012
From: david at commroom.net (David Davidson)
Date: Sat, 16 Jun 2012 08:14:00 -0700
Subject: [Xorp-users] Problems with bootstrap and rp selection in pimsm
In-Reply-To: <54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se>
References: <54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se>
Message-ID: <4FDCA2B8.1030103@commroom.net>

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 

From danro at kth.se  Sat Jun 16 08:49:02 2012
From: danro at kth.se (Dan Rosenqvist)
Date: Sat, 16 Jun 2012 15:49:02 +0000
Subject: [Xorp-users] Problems with bootstrap and rp selection in pimsm
In-Reply-To: <4FDCA2B8.1030103@commroom.net>
References: <54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se>,
	<4FDCA2B8.1030103@commroom.net>
Message-ID: <54DD4F682C240845BF5F7D0EECBDB6F20839A0FD@EXDB3.ug.kth.se>

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/20120616/4bf519ed/attachment-0001.html 

From danro at kth.se  Mon Jun 18 04:09:45 2012
From: danro at kth.se (Dan Rosenqvist)
Date: Mon, 18 Jun 2012 11:09:45 +0000
Subject: [Xorp-users] Problems with bootstrap and rp selection in pimsm
In-Reply-To: <54DD4F682C240845BF5F7D0EECBDB6F20839A0FD@EXDB3.ug.kth.se>
References: <54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se>,
	<4FDCA2B8.1030103@commroom.net>,
	<54DD4F682C240845BF5F7D0EECBDB6F20839A0FD@EXDB3.ug.kth.se>
Message-ID: <54DD4F682C240845BF5F7D0EECBDB6F20839A13C@EXDB3.ug.kth.se>

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 

From danro at kth.se  Tue Jun 19 04:40:47 2012
From: danro at kth.se (Dan Rosenqvist)
Date: Tue, 19 Jun 2012 11:40:47 +0000
Subject: [Xorp-users] Problems with bootstrap and rp selection in pimsm
In-Reply-To: <4FE00EC9.5060409@commroom.net>
References: <54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se>,
	<4FDCA2B8.1030103@commroom.net>,
	<54DD4F682C240845BF5F7D0EECBDB6F20839A0FD@EXDB3.ug.kth.se>
	<54DD4F682C240845BF5F7D0EECBDB6F20839A13C@EXDB3.ug.kth.se>,
	<4FE00EC9.5060409@commroom.net>
Message-ID: <54DD4F682C240845BF5F7D0EECBDB6F20839A191@EXDB3.ug.kth.se>

Hi David,

This problem was discovered by a friend who tried setting up a network with multiple paths from sender to receiver (this was unicast traffic). As he changed the interface cost of one of the interfaces, he actively created asymmetric routing, causing rp_filter to start dropping packets. He tipped me that I could test this for mcast as well, and it worked.

The question now is why this is happening for multicast packets? My best guess is that it has to do with the register message encapsulation. When rp_filter is run in strict mode (1), my rp is receiving the register messages. As the rp in this case is directly connected to the receiver, the message should be decapsulated and forwarded to the receiver, but this never happens. Could it be that the rp_filter is blocking these messages? Upon decapsulation, the message is once again treated as a multicast packet, but it wasn't received from any interface (as it was recreated in the node itself) and thus blocked by rp_filter. So basically, the RP in this case is spoofing messages as a part of the protocol.

Regarding the list of RPs, I've found that all cand-rps are listed, but if you'd have a look at "show pim mfc" in order to see which rp is used for the current groups (showing the correctly chosen RP).

Regards,
Dan

________________________________
Fr?n: David Davidson [david at commroom.net]
Skickat: den 19 juni 2012 07:31
Till: Dan Rosenqvist
Kopia: xorp-users at xorp.org
?mne: Re: [Xorp-users] Problems with bootstrap and rp selection in pimsm

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120619/796fce9b/attachment.html 

From david at commroom.net  Mon Jun 18 22:31:53 2012
From: david at commroom.net (David Davidson)
Date: Mon, 18 Jun 2012 22:31:53 -0700
Subject: [Xorp-users] Problems with bootstrap and rp selection in pimsm
In-Reply-To: <54DD4F682C240845BF5F7D0EECBDB6F20839A13C@EXDB3.ug.kth.se>
References: <54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se>,
	<4FDCA2B8.1030103@commroom.net>,
	<54DD4F682C240845BF5F7D0EECBDB6F20839A0FD@EXDB3.ug.kth.se>
	<54DD4F682C240845BF5F7D0EECBDB6F20839A13C@EXDB3.ug.kth.se>
Message-ID: <4FE00EC9.5060409@commroom.net>

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





From jens.devel at gmail.com  Wed Jun 20 01:29:55 2012
From: jens.devel at gmail.com (Jens Dackenberg)
Date: Wed, 20 Jun 2012 10:29:55 +0200
Subject: [Xorp-users] Problem with export policy OSPF
Message-ID: <CAMBajAZFzzyCpQuuo7ds8hyABoipif4Ry8etCrZbV2v7wBYmUQ@mail.gmail.com>

Hi!

I have an issue regarding the route export policy for OSPF. What I have in
my setup is 4 routers that are connected as following:

[ R1 ]  ------BGP----- [R2] ---- [HOST]
   |
   |
 OSPF
   |
   |
[ R3 ]
   |
   |
 OSPF
   |
   |
[ R4 ]

R1 is in ospf area 0, redistributes between BGP and OSPF  (loopback address
1.1.0.1)
R2 is running BGP and redistributes "connected" to BGP  (loopback address
1.1.10.1)
R4 is in ospf area 1   (loopback address 1.1.3.3)
R3 is ABR       (loopback address 1.1.3.1)

My problem is that the loopback address of R1 is not visible at R4 when
enabling BGP-TO-OSPF redistribution in R1.
Is there somebody that can help me sort this out? :-)


My configurations are as following:

/************************************  R1
***************************************/

interfaces {
    interface "eth1" {
        vif "eth1" {
            address 10.5.0.2 {
                prefix-length: 24
            }
        }
    }
    interface "eth2" {
        vif "eth2" {
            address 10.7.0.1 {
                prefix-length: 24
            }
        }
    }
    interface "dummy0" {
        vif "dummy0" {
                address 1.1.0.1 {
                prefix-length: 32
            }
        }
    }
}
fea {
    unicast-forwarding4 {
        disable: false
    }
}
policy {

    policy-statement ospf-to-bgp {
        term 10 {
            from {
                protocol: "ospf4"
                }
            }
        term 20 {
            from {
                protocol: "connected"
                }
            }
    }
    policy-statement bgp-to-ospf {
        term 10 {
            from {
                protocol: "bgp"
                }
            }
        term 20 {
            from {
                protocol: "connected"
                }
            }
        }
}

protocols {
    ospf4 {
        router-id: 1.1.0.1
        area 0.0.0.0 {
            interface "eth1" {
                vif "eth1" {
                    address 10.5.0.2 {
                        interface-cost: 1
                    }
                }
            }
            interface "dummy0" {
                vif "dummy0" {
                        address 1.1.0.1 {
                        interface-cost: 1
                    }
                }
            }
        }
        export: "bgp-to-ospf"
    }

    bgp {
        bgp-id: 1.1.0.1
        local-as: 65001

        peer 10.7.0.2 {
            local-ip: 10.7.0.1
            as: 65002
            next-hop: 10.7.0.1
            export: "ospf-to-bgp"     /*********  <---- if I comment this
line, 1.1.0.1 is visible in R4 ************/
        }
    }
}


/********************  R2
*********************************************************/

interfaces {
    interface "eth1" {
        vif "eth1" {
            address 10.7.0.2 {
                prefix-length: 24
            }
        }
    }
    interface "eth2" {
        vif "eth2" {
            address 192.168.100.1 {
                prefix-length: 24
            }
        }
    }
    interface "dummy0" {
        vif "dummy0" {
                address 1.1.10.1 {
                prefix-length: 32
            }
        }
    }
}
fea {
    unicast-forwarding4 {
        disable: false
    }
}
policy {
    policy-statement connected-to-bgp {
        term 10 {
            from {
                protocol: "connected"
            }
        }
    }
}

protocols {

    bgp {
        bgp-id: 1.1.10.1
        local-as: 65002

        peer 10.7.0.1 {
            local-ip: 10.7.0.2
            as: 65001
            next-hop: 10.7.0.2
            export: "connected-to-bgp"
        }
    }
}

/******************    R3
***********************************************************/

interfaces {
    interface "eth1" {
        vif "eth1" {
            address 10.5.0.1 {
                prefix-length: 24
            }
        }
    }
    interface "eth2" {
        vif "eth2" {
            address 10.6.0.1 {
                prefix-length: 24
            }
        }
    }
    interface "dummy0" {
        vif "dummy0" {
            address 1.1.3.1 {
                prefix-length: 32
            }
        }
    }
}
fea {
    unicast-forwarding4 {
        disable: false
    }
}
protocols {
    ospf4 {
        router-id: 1.1.3.1
        area 0.0.0.0 {
            interface "eth1" {
                vif "eth1" {
                    address 10.5.0.1 {
                        interface-cost: 1
                    }
                }
            }
        }
        area 0.0.0.1 {
            interface "eth2" {
                vif "eth2" {
                    address 10.6.0.1 {
                        interface-cost: 10
                    }
                }
            }
            interface "dummy0" {
                vif "dummy0" {
                    address 1.1.3.1 {
                        interface-cost: 1
                    }
                }
            }
        }
    }
}

/******************************* R4
****************************************************/
interfaces {
    interface "eth2" {
        vif "eth2" {
            address 10.6.0.2 {
                prefix-length: 24
            }
        }
    }
    interface "dummy0" {
        vif "dummy0" {
            address 1.1.3.3 {
                prefix-length: 32
            }
        }
    }
}
fea {
    unicast-forwarding4 {
        disable: false
    }
}
protocols {
    ospf4 {
        router-id: 1.1.3.3
        area 0.0.0.1 {
            interface "eth2" {
                vif "eth2" {
                    address 10.6.0.2 {
                        interface-cost: 1
                    }
                }
            }
            interface "dummy0" {
                vif "dummy0" {
                    address 1.1.3.3 {
                        interface-cost: 1
                    }
                }
            }
        }
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120620/bcc2d825/attachment.html 

From iarvind at cdac.in  Tue Jun 26 05:30:02 2012
From: iarvind at cdac.in (iarvind at cdac.in)
Date: Tue, 26 Jun 2012 18:00:02 +0530 (IST)
Subject: [Xorp-users] regarding  packet forwarding speed of xorp
Message-ID: <twig.1340713802.43120@cdac.in>

Dear Sir/Madam

I'm looking for a software router which has the capability of forwarding
packets whose sizes range from 64 - 1518 bytes, at 10Gbps speed. I would
like to know is XORP capable of forwarding at that speed.


Thanks & Regards,

I Aravind.



-------------------------------------------------------------------------------------------------------------------------------

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------


From greearb at candelatech.com  Tue Jun 26 09:22:03 2012
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 26 Jun 2012 09:22:03 -0700
Subject: [Xorp-users] regarding  packet forwarding speed of xorp
In-Reply-To: <twig.1340713802.43120@cdac.in>
References: <twig.1340713802.43120@cdac.in>
Message-ID: <4FE9E1AB.8010408@candelatech.com>

On 06/26/2012 05:30 AM, iarvind at cdac.in wrote:
> Dear Sir/Madam
>
> I'm looking for a software router which has the capability of forwarding
> packets whose sizes range from 64 - 1518 bytes, at 10Gbps speed. I would
> like to know is XORP capable of forwarding at that speed.

Xorp just sets up the routing tables..it's the OS that does the packet
forwarding.  And, I don't think any OS on normal hardware can handle
10G at 64-byte frames.  Linux should be able to handle at least near 10G
with larger frames.

Thanks,
Ben

>
>
> Thanks&  Regards,
>
> I Aravind.
>
>
>
> -------------------------------------------------------------------------------------------------------------------------------
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> -------------------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com