From swdickey at rockwellcollins.com  Thu Sep  1 12:50:13 2011
From: swdickey at rockwellcollins.com (swdickey at rockwellcollins.com)
Date: Thu, 1 Sep 2011 15:50:13 -0400
Subject: [Xorp-users] My new XorpTimer not working in PIM
Message-ID: <OF8A76916F.2FEBA1D4-ON852578FE.006B8E92-852578FE.006CFAD1@rockwellcollins.com>

Hi Hackers,

I am trying out some code inside the 
pim_mre_join_prune::recompute_is_prune_desired_*** methods.  After every 
set_pruned_state() call I want to set my new timer to fire every 30 
seconds or so.  This is the code I am using, its pretty much identical to 
the join_timer() which is why I'm confused that it doesn't work.

Pim_Mre_Join_Prune::recompute_is_prune_desired_****

TimeVal timeval = TimeVal(30,0);

...

set_pruned_state();

new_timer() =
        pim_node().eventloop().new_oneoff_after(
            timeval,
            callback(this, &PimMre::new_timer_timeout));


//Later on...
void
PimMre::new_timer_timeout()
{
        XLOG_TRACE(true, "New timer fired.");
}


PimMre.hh: 

XorpTimer&      new_timer() { return (_new_timer); } 
const XorpTimer& const_new_timer() const {
                return (_new_timer);
    }
 
    XorpTimer   _new_timer; 

          //function to be called
    void        new_timer_timeout();



This code will run and will set the timer (new_timer().scheduled == true) 
but the timer will never fire!  Interestingly, if I change the time to 5 
milliseconds (TimeVal timeval = TimeVal(0,5);) then the new_timer will 
fire.  I'm not sure if this is a timing issue or some memory is going out 
of scope and the 5 msec will fire the timer before the memory is 
overwritten.

Any ideas?  Thanks!

S. Dickey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110901/cbbaca98/attachment.html 

From greearb at candelatech.com  Thu Sep  1 13:35:11 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 01 Sep 2011 13:35:11 -0700
Subject: [Xorp-users] My new XorpTimer not working in PIM
In-Reply-To: <OF8A76916F.2FEBA1D4-ON852578FE.006B8E92-852578FE.006CFAD1@rockwellcollins.com>
References: <OF8A76916F.2FEBA1D4-ON852578FE.006B8E92-852578FE.006CFAD1@rockwellcollins.com>
Message-ID: <4E5FEC7F.7050204@candelatech.com>

On 09/01/2011 12:50 PM, swdickey at rockwellcollins.com wrote:
>
> Hi Hackers,
>
> I am trying out some code inside the pim_mre_join_prune::recompute_is_prune_desired_*** methods. After every set_pruned_state() call I want to set my new timer
> to fire every 30 seconds or so. This is the code I am using, its pretty much identical to the join_timer() which is why I'm confused that it doesn't work.
>
> Pim_Mre_Join_Prune::recompute_is_prune_desired_****
>
> TimeVal timeval = TimeVal(30,0);
>
> ...
>
> set_pruned_state();
>
> new_timer() =
> pim_node().eventloop().new_oneoff_after(
> timeval,
> callback(this, &PimMre::new_timer_timeout));
>
>
> //Later on...
> void
> PimMre::new_timer_timeout()
> {
> XLOG_TRACE(true, "New timer fired.");
> }
>
>
> PimMre.hh:
>
> XorpTimer& new_timer() { return(_new_timer); }
> constXorpTimer& const_new_timer() const{
> return(_new_timer);
> }
>
> XorpTimer _new_timer;
>
> //function to be called
> voidnew_timer_timeout();
>
>
>
> This code will run and will set the timer (new_timer().scheduled == true) but the timer will never fire! Interestingly, if I change the time to 5 milliseconds
> (TimeVal timeval = TimeVal(0,5);) then the new_timer will fire. I'm not sure if this is a timing issue or some memory is going out of scope and the 5 msec will
> fire the timer before the memory is overwritten.

Maybe the callback method needs to be a static method or plain
function instead of a class member?

Thanks,
Ben

>
> Any ideas? Thanks!
>
> S. Dickey
>
>
> _______________________________________________
> 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 swdickey at rockwellcollins.com  Thu Sep  1 16:38:10 2011
From: swdickey at rockwellcollins.com (swdickey at rockwellcollins.com)
Date: Thu, 1 Sep 2011 19:38:10 -0400
Subject: [Xorp-users] My new XorpTimer not working in PIM
In-Reply-To: <4E5FEC7F.7050204@candelatech.com>
Message-ID: <OF5BF178A4.BC4ECEBD-ON852578FE.0080D923-852578FE.0081D9AD@rockwellcollins.com>

Good suggestion, doesn't seem to fix my problem though.  Actually, to 
debug this I went back to something even simpler which is giving me 
strange results.  I just copied the join_timer code:

join_timer() =
pim_node().eventloop().new_oneoff_after(
TimeVal(join_prune_period, 0);
callback(this, &PimMre::join_timer_timeout));

I added that code right before the 
pim_mre_join_prune::recompute_is_join_desired_**** methods call 
set_not_joined_state() and commented out all the join_timer().unschedule() 
calls.  [I know setting the join_timer in not_joined_state doesn't make 
sense for PIM but this is just to debug].  The join_timer won't fire when 
called during pruned state. This is the same code snippet which will 
successfully fire the join_timer() if we are in joined_state.

Is something stopping timers from firing when they are started in the 
not_joined / pruned state? 

S Dickey.





Ben Greear <greearb at candelatech.com> 
01/09/2011 04:35 PM

To
swdickey at rockwellcollins.com
cc
"xorp-users at xorp.org" <xorp-users at xorp.org>
Subject
Re: [Xorp-users] My new XorpTimer not working in PIM






On 09/01/2011 12:50 PM, swdickey at rockwellcollins.com wrote:
>
> Hi Hackers,
>
> I am trying out some code inside the 
pim_mre_join_prune::recompute_is_prune_desired_*** methods. After every 
set_pruned_state() call I want to set my new timer
> to fire every 30 seconds or so. This is the code I am using, its pretty 
much identical to the join_timer() which is why I'm confused that it 
doesn't work.
>
> Pim_Mre_Join_Prune::recompute_is_prune_desired_****
>
> TimeVal timeval = TimeVal(30,0);
>
> ...
>
> set_pruned_state();
>
> new_timer() =
> pim_node().eventloop().new_oneoff_after(
> timeval,
> callback(this, &PimMre::new_timer_timeout));
>
>
> //Later on...
> void
> PimMre::new_timer_timeout()
> {
> XLOG_TRACE(true, "New timer fired.");
> }
>
>
> PimMre.hh:
>
> XorpTimer& new_timer() { return(_new_timer); }
> constXorpTimer& const_new_timer() const{
> return(_new_timer);
> }
>
> XorpTimer _new_timer;
>
> //function to be called
> voidnew_timer_timeout();
>
>
>
> This code will run and will set the timer (new_timer().scheduled == 
true) but the timer will never fire! Interestingly, if I change the time 
to 5 milliseconds
> (TimeVal timeval = TimeVal(0,5);) then the new_timer will fire. I'm not 
sure if this is a timing issue or some memory is going out of scope and 
the 5 msec will
> fire the timer before the memory is overwritten.

Maybe the callback method needs to be a static method or plain
function instead of a class member?

Thanks,
Ben

>
> Any ideas? Thanks!
>
> S. Dickey
>
>
> _______________________________________________
> 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

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

From swdickey at rockwellcollins.com  Thu Sep  1 17:28:56 2011
From: swdickey at rockwellcollins.com (swdickey at rockwellcollins.com)
Date: Thu, 1 Sep 2011 20:28:56 -0400
Subject: [Xorp-users] My new XorpTimer not working in PIM
In-Reply-To: <OF5BF178A4.BC4ECEBD-ON852578FE.0080D923-852578FE.0081D9AD@rockwellcollins.com>
Message-ID: <OF23EC5BE7.96218561-ON852578FF.00027F83-852578FF.0002A983@rockwellcollins.com>

My MRE was being destructed after the timer would fire the one time. 
Thanks for everyone's suggestions.

S Dickey





swdickey at rockwellcollins.com 
Sent by: xorp-users-bounces at xorp.org
01/09/2011 07:38 PM

To
Ben Greear <greearb at candelatech.com>
cc
"xorp-users at xorp.org" <xorp-users at xorp.org>
Subject
Re: [Xorp-users] My new XorpTimer not working in PIM







Good suggestion, doesn't seem to fix my problem though.  Actually, to 
debug this I went back to something even simpler which is giving me 
strange results.  I just copied the join_timer code: 

join_timer() =
pim_node().eventloop().new_oneoff_after(
TimeVal(join_prune_period, 0);
callback(this, &PimMre::join_timer_timeout)); 

I added that code right before the 
pim_mre_join_prune::recompute_is_join_desired_**** methods call 
set_not_joined_state() and commented out all the join_timer().unschedule() 
calls.  [I know setting the join_timer in not_joined_state doesn't make 
sense for PIM but this is just to debug].  The join_timer won't fire when 
called during pruned state. This is the same code snippet which will 
successfully fire the join_timer() if we are in joined_state. 

Is something stopping timers from firing when they are started in the 
not_joined / pruned state? 

S Dickey. 




Ben Greear <greearb at candelatech.com> 
01/09/2011 04:35 PM 


To
swdickey at rockwellcollins.com 
cc
"xorp-users at xorp.org" <xorp-users at xorp.org> 
Subject
Re: [Xorp-users] My new XorpTimer not working in PIM








On 09/01/2011 12:50 PM, swdickey at rockwellcollins.com wrote:
>
> Hi Hackers,
>
> I am trying out some code inside the 
pim_mre_join_prune::recompute_is_prune_desired_*** methods. After every 
set_pruned_state() call I want to set my new timer
> to fire every 30 seconds or so. This is the code I am using, its pretty 
much identical to the join_timer() which is why I'm confused that it 
doesn't work.
>
> Pim_Mre_Join_Prune::recompute_is_prune_desired_****
>
> TimeVal timeval = TimeVal(30,0);
>
> ...
>
> set_pruned_state();
>
> new_timer() =
> pim_node().eventloop().new_oneoff_after(
> timeval,
> callback(this, &PimMre::new_timer_timeout));
>
>
> //Later on...
> void
> PimMre::new_timer_timeout()
> {
> XLOG_TRACE(true, "New timer fired.");
> }
>
>
> PimMre.hh:
>
> XorpTimer& new_timer() { return(_new_timer); }
> constXorpTimer& const_new_timer() const{
> return(_new_timer);
> }
>
> XorpTimer _new_timer;
>
> //function to be called
> voidnew_timer_timeout();
>
>
>
> This code will run and will set the timer (new_timer().scheduled == 
true) but the timer will never fire! Interestingly, if I change the time 
to 5 milliseconds
> (TimeVal timeval = TimeVal(0,5);) then the new_timer will fire. I'm not 
sure if this is a timing issue or some memory is going out of scope and 
the 5 msec will
> fire the timer before the memory is overwritten.

Maybe the callback method needs to be a static method or plain
function instead of a class member?

Thanks,
Ben

>
> Any ideas? Thanks!
>
> S. Dickey
>
>
> _______________________________________________
> 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
_______________________________________________
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/20110901/3f76abc6/attachment-0001.html 

From greearb at candelatech.com  Mon Sep 12 19:42:08 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 12 Sep 2011 19:42:08 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
Message-ID: <4E6EC300.6090803@candelatech.com>

I've pushed the changes to the source tree to update xorp to release 1.8.4.

I should have binary builds and the web page updated tomorrow.

If anyone wants to give the latest code a spin, it would be good to
get an extra bit of testing in....

Thanks,
Ben

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


From JoeCoco at mecnet.net  Tue Sep 13 06:00:36 2011
From: JoeCoco at mecnet.net (Joe Coco)
Date: Tue, 13 Sep 2011 13:00:36 +0000
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
Message-ID: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>


Ben,

Have we fixed multicast ipv6 routing under Linux?

At least older glibc  doesn't support inet6_option_*, so if  'HAVE_IPV6_MULTICAST_ROUTING' is enabled it will bomb.

For example, in Glibc 2.3.2 these calls don't exist at all.

In glibc 2.10.1 however, they appear to be  obsoleted:

(netinet/in.h)

extern int inet6_option_space (int __nbytes)
     __THROW __attribute_deprecated__;


Normally when I build XORP under linux, I just undef 'HAVE_IPV6_MULTICAST_ROUTING', however it seems like functionality that should otherwise work.

-- Joe


-----Original Message-----
From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Ben Greear
Sent: Monday, September 12, 2011 10:42 PM
To: xorp; xorp-users at xorp.org
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.

I've pushed the changes to the source tree to update xorp to release 1.8.4.

I should have binary builds and the web page updated tomorrow.

If anyone wants to give the latest code a spin, it would be good to get an extra bit of testing in....

Thanks,
Ben

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

_______________________________________________
Xorp-users mailing list
Xorp-users at xorp.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From greearb at candelatech.com  Tue Sep 13 07:25:19 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 13 Sep 2011 07:25:19 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
Message-ID: <4E6F67CF.7080109@candelatech.com>

On 09/13/2011 06:00 AM, Joe Coco wrote:
>
> Ben,
>
> Have we fixed multicast ipv6 routing under Linux?
>
> At least older glibc  doesn't support inet6_option_*, so if  'HAVE_IPV6_MULTICAST_ROUTING' is enabled it will bomb.
>
> For example, in Glibc 2.3.2 these calls don't exist at all.
>
> In glibc 2.10.1 however, they appear to be  obsoleted:
>
> (netinet/in.h)
>
> extern int inet6_option_space (int __nbytes)
>       __THROW __attribute_deprecated__;
>
>
> Normally when I build XORP under linux, I just undef 'HAVE_IPV6_MULTICAST_ROUTING', however it seems like functionality that should otherwise work.

I'm pretty sure it is working for us...I'll check with my system tester.

Do you have a specific OS/Distribution that it fails to work for?

Thanks,
Ben

>
> -- Joe
>
>
> -----Original Message-----
> From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Ben Greear
> Sent: Monday, September 12, 2011 10:42 PM
> To: xorp; xorp-users at xorp.org
> Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
>
> I've pushed the changes to the source tree to update xorp to release 1.8.4.
>
> I should have binary builds and the web page updated tomorrow.
>
> If anyone wants to give the latest code a spin, it would be good to get an extra bit of testing in....
>
> Thanks,
> Ben
>
> --
> Ben Greear<greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
> _______________________________________________
> 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 JoeCoco at mecnet.net  Tue Sep 13 08:21:58 2011
From: JoeCoco at mecnet.net (Joe Coco)
Date: Tue, 13 Sep 2011 15:21:58 +0000
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <4E6F67CF.7080109@candelatech.com>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
Message-ID: <9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>

Ben,

We're using our own embedded distribution internally, but I know specifically inet6_option_* is not available on Glibc 2.3.2 and earlier.

If you look around line 680 of allconfig.py, you'll find:

# XXX: linux marked inet6_option_space() and friends as deprecated;
    # either rework mfea code or do this.
    if has_netinet6_ip6_mroute_h or has_linux_mroute6_h:
        if not (env.has_key('disable_ipv6') and env['disable_ipv6']):
            conf.Define('HAVE_IPV6_MULTICAST_ROUTING')


So, these headers do exist as they come with the KERNEL and the support is enabled in the KERNEL, and ipv6 is not disabled so it will set
HAVE_IPV6_MULTICAST_ROUTING in xorp_config.h as expected.

However, in earlier glibc, these calls (inet6_option_*) don't exist and it will bomb on compile time. 

This may be a situation that you don't want to support, however, I think it's still likely some folks will run a modern kernel, with an older glibc and it
should check to see if inet6_option_* is available in netinet/in.h.

The question is, can you still do ipv6 multicast without those calls?

Should this be on xorp-hackers rather than xorp-users ?

-- Joe

-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Tuesday, September 13, 2011 10:25 AM
To: Joe Coco
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] Xorp 1.8.4 release almost ready.

On 09/13/2011 06:00 AM, Joe Coco wrote:
>
> Ben,
>
> Have we fixed multicast ipv6 routing under Linux?
>
> At least older glibc  doesn't support inet6_option_*, so if  'HAVE_IPV6_MULTICAST_ROUTING' is enabled it will bomb.
>
> For example, in Glibc 2.3.2 these calls don't exist at all.
>
> In glibc 2.10.1 however, they appear to be  obsoleted:
>
> (netinet/in.h)
>
> extern int inet6_option_space (int __nbytes)
>       __THROW __attribute_deprecated__;
>
>
> Normally when I build XORP under linux, I just undef 'HAVE_IPV6_MULTICAST_ROUTING', however it seems like functionality that should otherwise work.

I'm pretty sure it is working for us...I'll check with my system tester.

Do you have a specific OS/Distribution that it fails to work for?

Thanks,
Ben

>
> -- Joe
>
>
> -----Original Message-----
> From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Ben Greear
> Sent: Monday, September 12, 2011 10:42 PM
> To: xorp; xorp-users at xorp.org
> Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
>
> I've pushed the changes to the source tree to update xorp to release 1.8.4.
>
> I should have binary builds and the web page updated tomorrow.
>
> If anyone wants to give the latest code a spin, it would be good to get an extra bit of testing in....
>
> Thanks,
> Ben
>
> --
> Ben Greear<greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
> _______________________________________________
> 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 greearb at candelatech.com  Tue Sep 13 08:22:53 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 13 Sep 2011 08:22:53 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
Message-ID: <4E6F754D.7040701@candelatech.com>

On 09/13/2011 08:21 AM, Joe Coco wrote:
> Ben,
>
> We're using our own embedded distribution internally, but I know specifically inet6_option_* is not available on Glibc 2.3.2 and earlier.
>
> If you look around line 680 of allconfig.py, you'll find:
>
> # XXX: linux marked inet6_option_space() and friends as deprecated;
>      # either rework mfea code or do this.
>      if has_netinet6_ip6_mroute_h or has_linux_mroute6_h:
>          if not (env.has_key('disable_ipv6') and env['disable_ipv6']):
>              conf.Define('HAVE_IPV6_MULTICAST_ROUTING')
>
>
> So, these headers do exist as they come with the KERNEL and the support is enabled in the KERNEL, and ipv6 is not disabled so it will set
> HAVE_IPV6_MULTICAST_ROUTING in xorp_config.h as expected.
>
> However, in earlier glibc, these calls (inet6_option_*) don't exist and it will bomb on compile time.
>
> This may be a situation that you don't want to support, however, I think it's still likely some folks will run a modern kernel, with an older glibc and it
> should check to see if inet6_option_* is available in netinet/in.h.
>
> The question is, can you still do ipv6 multicast without those calls?
>
> Should this be on xorp-hackers rather than xorp-users ?

Probably we should just have one list, it's not like the traffic load is
overwhelming!

I'm not sure the inet6_option stuff is needed or not.  I'll poke at that
code today if I can get a chance.

Thanks,
Ben

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


From greearb at candelatech.com  Tue Sep 13 14:07:35 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 13 Sep 2011 14:07:35 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
Message-ID: <4E6FC617.5040809@candelatech.com>

On 09/13/2011 08:21 AM, Joe Coco wrote:
> Ben,
>
> We're using our own embedded distribution internally, but I know specifically inet6_option_* is not available on Glibc 2.3.2 and earlier.
>
> If you look around line 680 of allconfig.py, you'll find:
>
> # XXX: linux marked inet6_option_space() and friends as deprecated;
>      # either rework mfea code or do this.
>      if has_netinet6_ip6_mroute_h or has_linux_mroute6_h:
>          if not (env.has_key('disable_ipv6') and env['disable_ipv6']):
>              conf.Define('HAVE_IPV6_MULTICAST_ROUTING')
>
>
> So, these headers do exist as they come with the KERNEL and the support is enabled in the KERNEL, and ipv6 is not disabled so it will set
> HAVE_IPV6_MULTICAST_ROUTING in xorp_config.h as expected.
>
> However, in earlier glibc, these calls (inet6_option_*) don't exist and it will bomb on compile time.
>
> This may be a situation that you don't want to support, however, I think it's still likely some folks will run a modern kernel, with an older glibc and it
> should check to see if inet6_option_* is available in netinet/in.h.
>
> The question is, can you still do ipv6 multicast without those calls?
>
> Should this be on xorp-hackers rather than xorp-users ?

Please try pulling the latest from github and see if it works for you.

Your system must not support RFC3542 calls, otherwise I'm not sure
how you hit this problem.  It seems my systems do support 3542,
(all the way back to Fedora Core 5), so I never saw the issue that you
reported.

Anyway, let me know how the latest code works out...

Thanks,
Ben

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


From JoeCoco at mecnet.net  Wed Sep 14 06:22:58 2011
From: JoeCoco at mecnet.net (Joe Coco)
Date: Wed, 14 Sep 2011 13:22:58 +0000
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <4E6FC617.5040809@candelatech.com>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
Message-ID: <9513B0D809E3024A85A611E9B3726CA99B98DC@MECnetExchange.mecnet.net>

> Please try pulling the latest from github and see if it works for you.

> Your system must not support RFC3542 calls, otherwise I'm not sure how you hit this problem.  It seems my systems do support 3542, (all the way back to Fedora Core 5), so I never saw > the issue that you reported.

> Anyway, let me know how the latest code works out...

It's an older 32bit platform. 

Latest code pulled this morning builds fine. Will perform some lab testing today. 

I'll try to beat it up as best I can over the next week and report back any issues.

-- Joe


From esj at cs.fiu.edu  Wed Sep 14 08:08:11 2011
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Wed, 14 Sep 2011 11:08:11 -0400
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <4E6FC617.5040809@candelatech.com> 
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
Message-ID: <20110914150811.E70553680005@cheetah.cs.fiu.edu>


Centos5 32bit.
(latest updates for libs/apps but still 2.6.18-164.6.1.el5 kernel)

A git from late yesterday built. (after the Support for IEEE754 binary64 format
fixes)

But OSPF seems to start but then not work. I saw adjacency's start to
form, DB loads start, but then nothing, not even any hellos.

(though the xorp_ospfv2 didn't die...)

Same world/config works with 1.8.3 ...
Using xorp for ospfv4 and pim-sm...

Will investigate further later, but a data point for ya...

E


From greearb at candelatech.com  Wed Sep 14 09:08:27 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 14 Sep 2011 09:08:27 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <20110914150811.E70553680005@cheetah.cs.fiu.edu>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
	<20110914150811.E70553680005@cheetah.cs.fiu.edu>
Message-ID: <4E70D17B.80708@candelatech.com>

On 09/14/2011 08:08 AM, Eric S. Johnson wrote:
>
> Centos5 32bit.
> (latest updates for libs/apps but still 2.6.18-164.6.1.el5 kernel)
>
> A git from late yesterday built. (after the Support for IEEE754 binary64 format
> fixes)
>
> But OSPF seems to start but then not work. I saw adjacency's start to
> form, DB loads start, but then nothing, not even any hellos.
>
> (though the xorp_ospfv2 didn't die...)
>
> Same world/config works with 1.8.3 ...
> Using xorp for ospfv4 and pim-sm...
>
> Will investigate further later, but a data point for ya...

Please post (or email me directly if too big for the list) the
full xorp logs...maybe there will be some clue as to why it's
failing.

Thanks,
Ben

>
> E


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


From greearb at candelatech.com  Wed Sep 14 10:01:50 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 14 Sep 2011 10:01:50 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <4E70D17B.80708@candelatech.com>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
	<20110914150811.E70553680005@cheetah.cs.fiu.edu>
	<4E70D17B.80708@candelatech.com>
Message-ID: <4E70DDFE.5050807@candelatech.com>

On 09/14/2011 09:08 AM, Ben Greear wrote:
> On 09/14/2011 08:08 AM, Eric S. Johnson wrote:
>>
>> Centos5 32bit.
>> (latest updates for libs/apps but still 2.6.18-164.6.1.el5 kernel)
>>
>> A git from late yesterday built. (after the Support for IEEE754 binary64 format
>> fixes)
>>
>> But OSPF seems to start but then not work. I saw adjacency's start to
>> form, DB loads start, but then nothing, not even any hellos.
>>
>> (though the xorp_ospfv2 didn't die...)
>>
>> Same world/config works with 1.8.3 ...
>> Using xorp for ospfv4 and pim-sm...
>>
>> Will investigate further later, but a data point for ya...
>
> Please post (or email me directly if too big for the list) the
> full xorp logs...maybe there will be some clue as to why it's
> failing.

I ran a quick test here, and xorp appears to work for me with OSPF + multicast.

I have only xorp routers talking to themselves (and virtualized at that),
so there could easily be other issues I'm not seeing in my test setup...

Thanks,
Ben

>
> Thanks,
> Ben
>
>>
>> E
>
>


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


From oren.manzury at elbitsystems.com  Thu Sep 15 05:13:31 2011
From: oren.manzury at elbitsystems.com (Manzury Oren)
Date: Thu, 15 Sep 2011 15:13:31 +0300
Subject: [Xorp-users] xorp 1.8.3 pim-sm4 does not send pim register message
Message-ID: <467A8F7AFAD8AF44AF0B49C597568BE9168B82@mailesl7.esl.corp.elbit.co.il>

Hello users,

I am playing with xorp 1.8.3 pim-sm ipv4, trying to figure out how
pim-sm protocol is working.

I have host computer (10.0.0.1) , directly connected to pim-sm router
which is directly connected to another router (the Rendezvous Point
router).

The host is sending multicast udp packet (directed to mc address
224.5.6.7) to his directly connected router, but NO pim register message
is sent toward the RP .

Attached the following log fragment, regarding the event of the
multicast packet caption by the near pim-sm router:

[ 2011/09/15 14:28:13.633408  TRACE xorp_fea:8624 MFEA +1625
fea/mfea_node.cc signal_message_recv ] RX kernel signal: message_type =
1 vif_index = 1 src = 10.0.0.1 dst = 224.5.6.7
[ 2011/09/15 14:28:13.633408 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal
from MFEA_4: vif_index = 1 src = 10.0.0.1 dst = 224.5.6.7
[ 2011/09/15 14:28:13.633408 TRACE xorp_pimsm4 PIM ] Add MFC entry:
(10.0.0.1, 224.5.6.7) iif = 1 olist = ... olist_disable_wrongvif = OOO
[ 2011/09/15 14:28:13.633408 TRACE xorp_pimsm4 PIM ] Add dataflow
monitor: source = 10.0.0.1 group = 224.5.6.7 threshold_interval_sec =
210 threshold_interval_usec = 0 threshold_packets = 0 threshold_bytes =
0 is_threshold_in_packets = 1 is_threshold_in_bytes = 0 is_geq_upcall =
0 is_leq_upcall = 1
[ 2011/09/15 14:28:13.633408  TRACE xorp_fea:8624 MFEA +1571
fea/mfea_mrouter.cc add_mfc ] Add MFC entry: (10.0.0.1, 224.5.6.7) iif =
1 olist = ...
[ 2011/09/15 14:28:13.661422 TRACE xorp_pimsm4 PIM ] Add MFC entry:
(10.0.0.1, 224.5.6.7) iif = 1 olist = ..O olist_disable_wrongvif = O..
[ 2011/09/15 14:28:13.661422  TRACE xorp_fea:8624 MFEA +1571
fea/mfea_mrouter.cc add_mfc ] Add MFC entry: (10.0.0.1, 224.5.6.7) iif =
1 olist = ..O
[ 2011/09/15 14:28:13.673428 TRACE xorp_pimsm4 PIM ] Add MFC entry:
(10.0.0.1, 224.5.6.7) iif = 1 olist = ..O olist_disable_wrongvif = OO.
[ 2011/09/15 14:28:13.673428  TRACE xorp_fea:8624 MFEA +1571
fea/mfea_mrouter.cc add_mfc ] Add MFC entry: (10.0.0.1, 224.5.6.7) iif =
1 olist = ..O
[ 2011/09/15 14:28:14.465824 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G)
= false: upstream neighbor for source 10.0.0.1 and group 224.5.6.7: not
found
[ 2011/09/15 14:28:14.465824 TRACE xorp_pimsm4 PIM ] Add MFC entry:
(10.0.0.1, 224.5.6.7) iif = 0 olist = ... olist_disable_wrongvif = OOO
[ 2011/09/15 14:28:14.465824  TRACE xorp_fea:8624 MFEA +1571
fea/mfea_mrouter.cc add_mfc ] Add MFC entry: (10.0.0.1, 224.5.6.7) iif =
0 olist = ...
[ 2011/09/15 14:28:14.469826 TRACE xorp_pimsm4 PIM ] Delete MFC entry:
(10.0.0.1, 224.5.6.7) iif = 0 olist = ...
[ 2011/09/15 14:28:14.469826  TRACE xorp_fea:8624 MFEA +1701
fea/mfea_mrouter.cc delete_mfc ] Delete MFC entry: (10.0.0.1, 224.5.6.7)

It seems that something is wrong, the MFC entry is deleted very near
after the creation. 
I suppose that after the RX NOCACHE signal there should be RX WHOLEPKT
signal which triggers the pim register message.

My xorp configuration files are just standard from the "getting started
manual", I am using openSUSE 11.4 with linux 2.6.37.1 kernel (No lack
with openSUSE 11.1 either).

Can anyone enlighten what happens ?

Best Regards,

Oren 

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110915/f33240b7/attachment.html 

From esj at cs.fiu.edu  Thu Sep 15 08:15:36 2011
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 15 Sep 2011 11:15:36 -0400
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <4E70D17B.80708@candelatech.com> 
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
	<20110914150811.E70553680005@cheetah.cs.fiu.edu>
	<4E70D17B.80708@candelatech.com>
Message-ID: <20110915151536.1DAEE3680005@cheetah.cs.fiu.edu>

Curiouser and curiouser. 

So.. It turns out 1.8.3 is also *now* having problems starting on 
the same machine. Same sort of errors as with 1.8.4. 

Most odd since 1.8.3 had been running on this host for a while
with no problems. A 1.7-svn dated 2010-02-17 does still run fine.

And even odder is the exact same 1.8.3 with the exact same config file
(well, IP address diffs but that is it) runs on another router
(and does still shutdown/startup fine, multiple time). I can 
not explain it. But it seems to be host centric.

(oh, same OS/kernels too)

The problem seems to be in some XRL keepalive. On the failing host
all seems fine (IE it start to make adjacency's and some of them 
get into db transfer) untill the logs start saying:

[ 2011/09/15 10:17:35.245634  ERROR xorp_fea:3846 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
[ 2011/09/15 10:17:36.107436  ERROR xorp_rtrmgr:3845 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
[ 2011/09/15 10:17:37.24165  ERROR xorp_ospfv2:3849 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
[ 2011/09/15 10:17:37.24503  ERROR xorp_ospfv2:3849 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
[ 2011/09/15 10:17:37.24733  ERROR xorp_fea:3846 LIBXORP libxorp/buffered_asyncio.cc:226 io_event ] read error 104
[ 2011/09/15 10:17:37.24525  ERROR xorp_rib:3847 LIBXORP libxorp/buffered_asyncio.cc:226 io_event ] read error 104
[ 2011/09/15 10:17:37.24828  ERROR xorp_fea:3846 XRL libxipc/xrl_pf_stcp.cc:197 read_event ] Read failed (error = 104)
[ 2011/09/15 10:17:37.24890  ERROR xorp_fea:3846 XRL libxipc/xrl_pf_stcp.cc:407 die ] STCPRequestHandler died: read error
[ 2011/09/15 10:17:37.24908  ERROR xorp_rib:3847 XRL libxipc/xrl_pf_stcp.cc:197 read_event ] Read failed (error = 104)
[ 2011/09/15 10:17:37.24992  ERROR xorp_rib:3847 XRL libxipc/xrl_pf_stcp.cc:407 die ] STCPRequestHandler died: read error
[ 2011/09/15 10:17:44.972044  WARNING xorp_ospfv2:3849 LIBXORP libxorp/timer.cc:439 expire_one ] Timer Expiry *much* later than scheduled: behind by 18.910527 seconds
[ 2011/09/15 10:17:44.972329  WARNING xorp_ospfv2:3849 LIBXORP libxorp/timer.cc:439 expire_one ] Timer Expiry *much* later than scheduled: behind by 18.889423 seconds
[ 2011/09/15 10:17:51.287571  INFO xorp_rtrmgr:3845 RTRMGR rtrmgr/task.cc:1033 shutdown ] Shutting down module: ospf4
[ 2011/09/15 10:17:51.287821  INFO xorp_rtrmgr:3845 RTRMGR rtrmgr/task.cc:1073 shutdown ] Shutdown with XRL: >finder://ospfv2/common/0.1/shutdown<
[ 2011/09/15 10:17:51.289067  INFO xorp_rtrmgr:3845 XRL libxipc/xrl_router.cc:459 lookup_sender ] Sender died (protocol = "unix", address = ":var:tmp:xrl.seHY26")

the xorp_ospfv2 doesn't die though, but it doesn't do anything else
either. xorpsh show ospf neighbor shows all the links as down (though as I said
before the error it shows the adjacency's starting (EXSTART etc).

Takes about 30 seconds for the whole thing to die.



The mentioned socket  /var/tmp/seHY26 doesn't exist.

Ive tried rebooting the box. No change.

Am I running into some socket limit? (I thought a reboot might help that.. 
but no)

Any ideas? Anything I could do debug wise to shine light?

E


From esj at cs.fiu.edu  Thu Sep 15 08:35:41 2011
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Thu, 15 Sep 2011 11:35:41 -0400
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <20110915151536.1DAEE3680005@cheetah.cs.fiu.edu> 
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
	<20110914150811.E70553680005@cheetah.cs.fiu.edu>
	<4E70D17B.80708@candelatech.com>
	<20110915151536.1DAEE3680005@cheetah.cs.fiu.edu>
Message-ID: <20110915153541.86ADD3680004@cheetah.cs.fiu.edu>


One more piece of data:

Good router:

 lsof | grep /var/tmp | wc
     41     328    4141

Busted router

lsof | grep /var/tmp | wc
     41     328    3772


but 

Good router

lsof | grep /var/tmp | grep xorp_ospf 
xorp_ospf  5454      root    5u     unix 0xffff81006ce00340             30051337 /var/tmp/xrl.RkzQdx
xorp_ospf  5454      root    6u     unix 0xffff81006ce00e40             30051342 /var/tmp/xrl.6kncNe
xorp_ospf  5454      root    9u     unix 0xffff81007affc680             30051600 /var/tmp/xrl.xnSoAK
xorp_ospf  5454      root   11u     unix 0xffff81007affd9c0             30051605 /var/tmp/xrl.xSWGTy
xorp_ospf  5454      root   18u     unix 0xffff81002d3e7c00             30051610 /var/tmp/xrl.lsHmgn
xorp_ospf  5454      root   21u     unix 0xffff81002d3e7940             30051613 /var/tmp/xrl.nrm3Cb
xorp_ospf  5454      root   27u     unix 0xffff81006b791180             30051622 /var/tmp/xrl.lsHmgn
xorp_ospf  5454      root   28u     unix 0xffff81006ce00600             30051624 /var/tmp/xrl.xnSoAK
xorp_ospf  5454      root   30u     unix 0xffff81006b791c80             30051632 /var/tmp/xrl.xnSoAK

Busted router

lsof | grep /var/tmp | grep xorp_ospf 
xorp_ospf 3914      root    5u     unix 0xf6b27080                45901 /var/tmp/xrl.7EEKRN
xorp_ospf 3914      root    6u     unix 0xf6b27280                45906 /var/tmp/xrl.XZxQQE
xorp_ospf 3914      root   11u     unix 0xf5f87c80                46123 /var/tmp/xrl.A1gmf9
xorp_ospf 3914      root   16u     unix 0xf5f87a80                46128 /var/tmp/xrl.W3Cyb7
xorp_ospf 3914      root   21u     unix 0xf5f87880                46133 /var/tmp/xrl.Qvree5
xorp_ospf 3914      root   23u     unix 0xf5f87680                46136 /var/tmp/xrl.ypcXg3
xorp_ospf 3914      root   28u     unix 0xf64b2700                46145 /var/tmp/xrl.Qvree5
xorp_ospf 3914      root   29u     unix 0xf5f5d580                46147 /var/tmp/xrl.A1gmf9


Am I even on the right track here?

E


From greearb at candelatech.com  Thu Sep 15 09:16:23 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 15 Sep 2011 09:16:23 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <20110915151536.1DAEE3680005@cheetah.cs.fiu.edu>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
	<20110914150811.E70553680005@cheetah.cs.fiu.edu>
	<4E70D17B.80708@candelatech.com>
	<20110915151536.1DAEE3680005@cheetah.cs.fiu.edu>
Message-ID: <4E7224D7.7060206@candelatech.com>

On 09/15/2011 08:15 AM, Eric S. Johnson wrote:
> Curiouser and curiouser.
>
> So.. It turns out 1.8.3 is also *now* having problems starting on
> the same machine. Same sort of errors as with 1.8.4.
>
> Most odd since 1.8.3 had been running on this host for a while
> with no problems. A 1.7-svn dated 2010-02-17 does still run fine.
>
> And even odder is the exact same 1.8.3 with the exact same config file
> (well, IP address diffs but that is it) runs on another router
> (and does still shutdown/startup fine, multiple time). I can
> not explain it. But it seems to be host centric.
>
> (oh, same OS/kernels too)
>
> The problem seems to be in some XRL keepalive. On the failing host
> all seems fine (IE it start to make adjacency's and some of them
> get into db transfer) untill the logs start saying:
>
> [ 2011/09/15 10:17:35.245634  ERROR xorp_fea:3846 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
> [ 2011/09/15 10:17:36.107436  ERROR xorp_rtrmgr:3845 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
> [ 2011/09/15 10:17:37.24165  ERROR xorp_ospfv2:3849 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
> [ 2011/09/15 10:17:37.24503  ERROR xorp_ospfv2:3849 XRL libxipc/xrl_pf_stcp.cc:783 die ] XrlPFSTCPSender died: Keepalive timeout
> [ 2011/09/15 10:17:37.24733  ERROR xorp_fea:3846 LIBXORP libxorp/buffered_asyncio.cc:226 io_event ] read error 104
> [ 2011/09/15 10:17:37.24525  ERROR xorp_rib:3847 LIBXORP libxorp/buffered_asyncio.cc:226 io_event ] read error 104

I saw this same thing while trying to debug a user's system running xorp on
windows.  There is some serious slowness in processing OSPF sometimes, and
does appear xrl related (or maybe the xrl reader(s) are not waking up
properly or something).

Their system takes a long time (minutes) to fully associate with the
other OSPF routers.

I started documenting some env variables to adjust some of the timers:

http://xorp.run.montefiore.ulg.ac.be/latex2wiki/user_manual/environment_variables

Please try setting XORP_SENDER_KEEPALIVE_TIME to 30 or so and see if the problems
go away.

You might also try using strace [pid] on the ospf process in case that gives some
clues as to what is taking so long.

Unfortunately, I haven't been able to reproduce any of these problems on
my systems, so it's been slow to debug it...

> [ 2011/09/15 10:17:37.24828  ERROR xorp_fea:3846 XRL libxipc/xrl_pf_stcp.cc:197 read_event ] Read failed (error = 104)
> [ 2011/09/15 10:17:37.24890  ERROR xorp_fea:3846 XRL libxipc/xrl_pf_stcp.cc:407 die ] STCPRequestHandler died: read error
> [ 2011/09/15 10:17:37.24908  ERROR xorp_rib:3847 XRL libxipc/xrl_pf_stcp.cc:197 read_event ] Read failed (error = 104)
> [ 2011/09/15 10:17:37.24992  ERROR xorp_rib:3847 XRL libxipc/xrl_pf_stcp.cc:407 die ] STCPRequestHandler died: read error
> [ 2011/09/15 10:17:44.972044  WARNING xorp_ospfv2:3849 LIBXORP libxorp/timer.cc:439 expire_one ] Timer Expiry *much* later than scheduled: behind by 18.910527 seconds
> [ 2011/09/15 10:17:44.972329  WARNING xorp_ospfv2:3849 LIBXORP libxorp/timer.cc:439 expire_one ] Timer Expiry *much* later than scheduled: behind by 18.889423 seconds
> [ 2011/09/15 10:17:51.287571  INFO xorp_rtrmgr:3845 RTRMGR rtrmgr/task.cc:1033 shutdown ] Shutting down module: ospf4
> [ 2011/09/15 10:17:51.287821  INFO xorp_rtrmgr:3845 RTRMGR rtrmgr/task.cc:1073 shutdown ] Shutdown with XRL:>finder://ospfv2/common/0.1/shutdown<
> [ 2011/09/15 10:17:51.289067  INFO xorp_rtrmgr:3845 XRL libxipc/xrl_router.cc:459 lookup_sender ] Sender died (protocol = "unix", address = ":var:tmp:xrl.seHY26")
>
> the xorp_ospfv2 doesn't die though, but it doesn't do anything else
> either. xorpsh show ospf neighbor shows all the links as down (though as I said
> before the error it shows the adjacency's starting (EXSTART etc).
>
> Takes about 30 seconds for the whole thing to die.
>
>
>
> The mentioned socket  /var/tmp/seHY26 doesn't exist.

Probably cleanup code removes it when the sender dies.  Timeout causes it
to die, but I'm not sure why it times out.  Saw the same thing on windows using
xrl over tcp, so it's not specifically a unix-socket thing it seems.

>
> Ive tried rebooting the box. No change.
>
> Am I running into some socket limit? (I thought a reboot might help that..
> but no)
>
> Any ideas? Anything I could do debug wise to shine light?

Enabling the various environ variables that turn on tracing for xrls
and such, as well as turning on ospf tracing in the xorp config file
is what I was using to debug this...  Makes a big log file, but
with the timestamps, you can start to see where the slownesses are.

Thanks,
Ben

>
> E


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


From greearb at candelatech.com  Thu Sep 15 09:16:33 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 15 Sep 2011 09:16:33 -0700
Subject: [Xorp-users] Xorp 1.8.4 release almost ready.
In-Reply-To: <20110915153541.86ADD3680004@cheetah.cs.fiu.edu>
References: <9513B0D809E3024A85A611E9B3726CA99B91F8@MECnetExchange.mecnet.net>
	<4E6F67CF.7080109@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99B9360@MECnetExchange.mecnet.net>
	<4E6FC617.5040809@candelatech.com>
	<20110914150811.E70553680005@cheetah.cs.fiu.edu>
	<4E70D17B.80708@candelatech.com>
	<20110915151536.1DAEE3680005@cheetah.cs.fiu.edu>
	<20110915153541.86ADD3680004@cheetah.cs.fiu.edu>
Message-ID: <4E7224E1.6030700@candelatech.com>

On 09/15/2011 08:35 AM, Eric S. Johnson wrote:
>
> One more piece of data:
>
> Good router:
>
>   lsof | grep /var/tmp | wc
>       41     328    4141
>
> Busted router
>
> lsof | grep /var/tmp | wc
>       41     328    3772
>
>
> but
>
> Good router
>
> lsof | grep /var/tmp | grep xorp_ospf
> xorp_ospf  5454      root    5u     unix 0xffff81006ce00340             30051337 /var/tmp/xrl.RkzQdx
> xorp_ospf  5454      root    6u     unix 0xffff81006ce00e40             30051342 /var/tmp/xrl.6kncNe
> xorp_ospf  5454      root    9u     unix 0xffff81007affc680             30051600 /var/tmp/xrl.xnSoAK
> xorp_ospf  5454      root   11u     unix 0xffff81007affd9c0             30051605 /var/tmp/xrl.xSWGTy
> xorp_ospf  5454      root   18u     unix 0xffff81002d3e7c00             30051610 /var/tmp/xrl.lsHmgn
> xorp_ospf  5454      root   21u     unix 0xffff81002d3e7940             30051613 /var/tmp/xrl.nrm3Cb
> xorp_ospf  5454      root   27u     unix 0xffff81006b791180             30051622 /var/tmp/xrl.lsHmgn
> xorp_ospf  5454      root   28u     unix 0xffff81006ce00600             30051624 /var/tmp/xrl.xnSoAK
> xorp_ospf  5454      root   30u     unix 0xffff81006b791c80             30051632 /var/tmp/xrl.xnSoAK
>
> Busted router
>
> lsof | grep /var/tmp | grep xorp_ospf
> xorp_ospf 3914      root    5u     unix 0xf6b27080                45901 /var/tmp/xrl.7EEKRN
> xorp_ospf 3914      root    6u     unix 0xf6b27280                45906 /var/tmp/xrl.XZxQQE
> xorp_ospf 3914      root   11u     unix 0xf5f87c80                46123 /var/tmp/xrl.A1gmf9
> xorp_ospf 3914      root   16u     unix 0xf5f87a80                46128 /var/tmp/xrl.W3Cyb7
> xorp_ospf 3914      root   21u     unix 0xf5f87880                46133 /var/tmp/xrl.Qvree5
> xorp_ospf 3914      root   23u     unix 0xf5f87680                46136 /var/tmp/xrl.ypcXg3
> xorp_ospf 3914      root   28u     unix 0xf64b2700                46145 /var/tmp/xrl.Qvree5
> xorp_ospf 3914      root   29u     unix 0xf5f5d580                46147 /var/tmp/xrl.A1gmf9
>
>
> Am I even on the right track here?

Maybe, but I think the problem is that something is slow enough to make it the xrl sender
timeout.  After that, the system will not recover.

Thanks,
Ben

>
> E


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


From greearb at candelatech.com  Thu Sep 15 09:24:52 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 15 Sep 2011 09:24:52 -0700
Subject: [Xorp-users] xorp 1.8.3 pim-sm4 does not send pim register
	message
In-Reply-To: <467A8F7AFAD8AF44AF0B49C597568BE9168B82@mailesl7.esl.corp.elbit.co.il>
References: <467A8F7AFAD8AF44AF0B49C597568BE9168B82@mailesl7.esl.corp.elbit.co.il>
Message-ID: <4E7226D4.1050505@candelatech.com>

On 09/15/2011 05:13 AM, Manzury Oren wrote:
> Hello users,
>
> I amplaying with xorp 1.8.3 pim-smipv4, trying tofigureouthow pim-sm protocol is working.

Can you try the latest 1.8.4?  Either compile from latest github xorp.ct source
tree, or use one of the binaries I just uploaded here:

http://www.xorp.org/releases/1.8.4/

Thanks,
Ben

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


From p_latini at hotmail.com  Thu Sep 15 14:31:28 2011
From: p_latini at hotmail.com (Patricio Latini)
Date: Thu, 15 Sep 2011 18:31:28 -0300
Subject: [Xorp-users] Multicast flooded on one interface and not in other.
Message-ID: <COL117-DS17F297A67CC4998B02FEE6F7070@phx.gbl>

I am experiencing a weird issue. I have on vlan30 the servers with groups
233.0.0.1 and 232.0.0.1. When I join from a host on vlan31 to any of the
groups the flooding works perfect. However when I join from vlan12 or vlan15
to any of that groups the multicast is not flooded, however the interface is
shown as being in that group as in the logs bellow.

 

All the interfaces (vlan12,15,31) have the same configuration.

 

Any idea on how I can troubleshoot why the traffic is not be flooded?

 

Thanks


Patricio

 

 

root at dns> show igmp interface 

Interface    State    Querier         Timeout Version Groups

eth0         DISABLED 0.0.0.0            None       2      0

vlan10       DISABLED 172.16.1.1         None       2      0

vlan11       DISABLED 172.16.1.5         None       2      0

vlan12       UP       172.16.1.9         None       2      6

vlan13       DISABLED 172.16.1.13        None       2      0

vlan14       DISABLED 172.16.1.17        None       2      0

vlan15       UP       172.16.1.21        None       2      7

vlan18       DISABLED 0.0.0.0            None       2      0

vlan19       DISABLED 0.0.0.0            None       2      0

vlan20       DISABLED 172.16.3.1         None       2      0

vlan30       UP       172.16.4.1         None       3      4

vlan31       UP       172.16.5.1         None       2      5

 

 

root at dns> show igmp group 

Interface    Group           Source          LastReported Timeout V State

vlan12       224.0.0.2       0.0.0.0         172.16.1.9        25 2     E

vlan12       224.0.0.5       0.0.0.0         172.16.1.9        22 2     E

vlan12       224.0.0.6       0.0.0.0         172.16.1.9        29 2     E

vlan12       224.0.0.13      0.0.0.0         172.16.1.9        22 2     E

vlan12       224.0.0.22      0.0.0.0         172.16.1.9        21 2     E

vlan12       224.0.0.251     0.0.0.0         172.16.1.9        25 2     E

vlan15       224.0.0.2       0.0.0.0         172.16.1.21       23 2     E

vlan15       224.0.0.5       0.0.0.0         172.16.1.21       28 2     E

vlan15       224.0.0.6       0.0.0.0         172.16.1.21       27 2     E

vlan15       224.0.0.22      0.0.0.0         172.16.1.21       22 2     E

vlan15       224.0.0.251     0.0.0.0         172.16.1.21       27 2     E

vlan15       232.0.0.1       0.0.0.0         172.16.1.22       28 2     E

vlan15       233.0.0.1       0.0.0.0         172.16.1.22       21 2     E

vlan30       224.0.0.2       0.0.0.0         172.16.4.1        24 3     E

vlan30       224.0.0.13      0.0.0.0         172.16.4.1        24 3     E

vlan30       224.0.0.22      0.0.0.0         172.16.4.1        24 3     E

vlan30       224.0.0.251     0.0.0.0         172.16.4.1        24 3     E

vlan31       224.0.0.2       0.0.0.0         172.16.5.1        25 2     E

vlan31       224.0.0.13      0.0.0.0         172.16.5.1        23 2     E

vlan31       224.0.0.22      0.0.0.0         172.16.5.1        25 2     E

vlan31       224.0.0.251     0.0.0.0         172.16.5.1        23 2     E

vlan31       233.0.0.1       0.0.0.0         172.16.5.2        20 2     E

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

From peirce at maine.edu  Fri Sep 16 07:12:55 2011
From: peirce at maine.edu (Garry Peirce)
Date: Fri, 16 Sep 2011 10:12:55 -0400
Subject: [Xorp-users] Mcast issues
Message-ID: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>

Just a general comment/suggestion re: mcast issues.

If you are experiencing mcast issues it is very difficult for anyone to
provide insight when the entire picture is not supplied.

Help others help you - provide your XORP config (anonymize addressing
consistently if you need to) , the entire relevant topology, and
IGMP/PIM/MFEA state. 

 

Otherwise it can result in numerous back/forth messages to try and get the
full picture and those assisting may become disinterested or available in
continuing to help solve your issue.  I suppose this holds true for any type
of problem, but mcast is enough of a different bird that it certainly helps
to provide as much info as possible.

 

Oren:  perhaps your routers have some PIM adjacency/RP/mapping issue so
traffic cannot reach the RP.

[ 2011/09/15 14:28:14.465824 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) =
false: upstream neighbor for source 10.0.0.1 and group 224.5.6.7: not found

 

Patricio:  you show some IGMP info but nothing of PIM state.  I'd change
your addressing to avoid 32:1 overlap. The addresses you chose to use for
two different services will end up using the same L2 address which may make
other troubleshooting more difficult as well as pass both streams to all
participating NICs only to be dropped.  Sensing your addressing did not
actually have SSM/GLOP needs, you might move these, for example, into the
239.x.x.x block. 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110916/6ddb7223/attachment.html 

From p_latini at hotmail.com  Fri Sep 16 07:44:34 2011
From: p_latini at hotmail.com (Patricio Latini)
Date: Fri, 16 Sep 2011 11:44:34 -0300
Subject: [Xorp-users] Mcast issues
In-Reply-To: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>
References: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>
Message-ID: <COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>

Garry, thanks for your response, I changed the groups to all of them in the
239.x.x.x range however the behaivior is the same. Do you know any useful
command to troubleshoot this?

 

Patricio

 

xorp at dns> show pim mfc 

Group           Source          RP             

229.255.0.1     172.16.4.254    0.0.0.0        

    Incoming interface :      vlan30

    Outgoing interfaces:      ............O

239.1.0.1       172.16.4.254    172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.2.0.1       172.16.4.14     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.3.0.1       172.16.4.10     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      ...........O.

xorp at dns> show pim mfc 

Group           Source          RP             

229.255.0.1     172.16.4.254    0.0.0.0        

    Incoming interface :      vlan30

    Outgoing interfaces:      ............O

239.1.0.1       172.16.4.254    172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.2.0.1       172.16.4.14     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.3.0.1       172.16.4.10     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      ...........O.

xorp at dns> show igmp group 

Interface    Group           Source          LastReported Timeout V State

vlan12       224.0.0.2       0.0.0.0         172.16.1.9        28 2     E

vlan12       224.0.0.5       0.0.0.0         172.16.1.9        20 2     E

vlan12       224.0.0.6       0.0.0.0         172.16.1.9        19 2     E

vlan12       224.0.0.13      0.0.0.0         172.16.1.9        28 2     E

vlan12       224.0.0.22      0.0.0.0         172.16.1.9        27 2     E

vlan12       224.0.0.251     0.0.0.0         172.16.1.9        28 2     E

vlan15       224.0.0.2       0.0.0.0         172.16.1.21       29 2     E

vlan15       224.0.0.5       0.0.0.0         172.16.1.21       25 2     E

vlan15       224.0.0.6       0.0.0.0         172.16.1.21       26 2     E

vlan15       224.0.0.22      0.0.0.0         172.16.1.21       24 2     E

vlan15       224.0.0.251     0.0.0.0         172.16.1.21       26 2     E

vlan15       239.3.0.1       0.0.0.0         172.16.1.22       23 2     E

vlan30       224.0.0.2       0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.13      0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.22      0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.251     0.0.0.0         172.16.4.1        28 3     E

vlan31       224.0.0.2       0.0.0.0         172.16.5.1        25 2     E

vlan31       224.0.0.13      0.0.0.0         172.16.5.1        29 2     E

vlan31       224.0.0.22      0.0.0.0         172.16.5.1        23 2     E

vlan31       224.0.0.251     0.0.0.0         172.16.5.1        27 2     E

vlan31       239.3.0.1       0.0.0.0         172.16.5.2        21 2     E

xorp at dns> show igmp interface 

Interface    State    Querier         Timeout Version Groups

eth0         DISABLED 0.0.0.0            None       2      0

vlan10       DISABLED 172.16.1.1         None       2      0

vlan11       DISABLED 172.16.1.5         None       2      0

vlan12       UP       172.16.1.9         None       2      6

vlan13       DISABLED 172.16.1.13        None       2      0

vlan14       DISABLED 172.16.1.17        None       2      0

vlan15       UP       172.16.1.21        None       2      6

vlan18       DISABLED 0.0.0.0            None       2      0

vlan19       DISABLED 0.0.0.0            None       2      0

vlan20       DISABLED 172.16.3.1         None       2      0

vlan30       UP       172.16.4.1         None       3      4

vlan31       UP       172.16.5.1         None       2      5

 

From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On
Behalf Of Garry Peirce
Sent: Friday, September 16, 2011 11:13 AM
To: xorp-users at xorp.org
Subject: Re: [Xorp-users] Mcast issues

 

Just a general comment/suggestion re: mcast issues.

If you are experiencing mcast issues it is very difficult for anyone to
provide insight when the entire picture is not supplied.

Help others help you - provide your XORP config (anonymize addressing
consistently if you need to) , the entire relevant topology, and
IGMP/PIM/MFEA state. 

 

Otherwise it can result in numerous back/forth messages to try and get the
full picture and those assisting may become disinterested or available in
continuing to help solve your issue.  I suppose this holds true for any type
of problem, but mcast is enough of a different bird that it certainly helps
to provide as much info as possible.

 

Oren:  perhaps your routers have some PIM adjacency/RP/mapping issue so
traffic cannot reach the RP.

[ 2011/09/15 14:28:14.465824 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) =
false: upstream neighbor for source 10.0.0.1 and group 224.5.6.7: not found

 

Patricio:  you show some IGMP info but nothing of PIM state.  I'd change
your addressing to avoid 32:1 overlap. The addresses you chose to use for
two different services will end up using the same L2 address which may make
other troubleshooting more difficult as well as pass both streams to all
participating NICs only to be dropped.  Sensing your addressing did not
actually have SSM/GLOP needs, you might move these, for example, into the
239.x.x.x block. 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110916/4c284472/attachment-0001.html 

From greearb at candelatech.com  Fri Sep 16 09:12:21 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 16 Sep 2011 09:12:21 -0700
Subject: [Xorp-users] Mcast issues
In-Reply-To: <COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>
References: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>
	<COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>
Message-ID: <4E737565.6060206@candelatech.com>

On 09/16/2011 07:44 AM, Patricio Latini wrote:
> Garry, thanks for your response, I changed the groups to all of them in the 239.x.x.x range however the behaivior is the same. Do you know any useful command to
> troubleshoot this?

There are definitely bugs in 1.8.3, so please make sure you try the 1.8.4
or compile from latest github source tree (which is 1.8.4).

We've been testing ipv4 multicast lately and it works for us.  We are
having troubles with IPv6, but not sure if it's xorp related
yet...

As always, make sure your generator has TTL high enough..it's
usually 1 by default which will not route.

Thanks,
Ben

>
> Patricio
>
> xorp at dns> show pim mfc
>
> Group Source RP
>
> 229.255.0.1 172.16.4.254 0.0.0.0
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ............O
>
> 239.1.0.1 172.16.4.254 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.2.0.1 172.16.4.14 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.3.0.1 172.16.4.10 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ...........O.
>
> xorp at dns> show pim mfc
>
> Group Source RP
>
> 229.255.0.1 172.16.4.254 0.0.0.0
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ............O
>
> 239.1.0.1 172.16.4.254 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.2.0.1 172.16.4.14 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.3.0.1 172.16.4.10 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ...........O.
>
> xorp at dns> show igmp group
>
> Interface Group Source LastReported Timeout V State
>
> vlan12 224.0.0.2 0.0.0.0 172.16.1.9 28 2 E
>
> vlan12 224.0.0.5 0.0.0.0 172.16.1.9 20 2 E
>
> vlan12 224.0.0.6 0.0.0.0 172.16.1.9 19 2 E
>
> vlan12 224.0.0.13 0.0.0.0 172.16.1.9 28 2 E
>
> vlan12 224.0.0.22 0.0.0.0 172.16.1.9 27 2 E
>
> vlan12 224.0.0.251 0.0.0.0 172.16.1.9 28 2 E
>
> vlan15 224.0.0.2 0.0.0.0 172.16.1.21 29 2 E
>
> vlan15 224.0.0.5 0.0.0.0 172.16.1.21 25 2 E
>
> vlan15 224.0.0.6 0.0.0.0 172.16.1.21 26 2 E
>
> vlan15 224.0.0.22 0.0.0.0 172.16.1.21 24 2 E
>
> vlan15 224.0.0.251 0.0.0.0 172.16.1.21 26 2 E
>
> vlan15 239.3.0.1 0.0.0.0 172.16.1.22 23 2 E
>
> vlan30 224.0.0.2 0.0.0.0 172.16.4.1 28 3 E
>
> vlan30 224.0.0.13 0.0.0.0 172.16.4.1 28 3 E
>
> vlan30 224.0.0.22 0.0.0.0 172.16.4.1 28 3 E
>
> vlan30 224.0.0.251 0.0.0.0 172.16.4.1 28 3 E
>
> vlan31 224.0.0.2 0.0.0.0 172.16.5.1 25 2 E
>
> vlan31 224.0.0.13 0.0.0.0 172.16.5.1 29 2 E
>
> vlan31 224.0.0.22 0.0.0.0 172.16.5.1 23 2 E
>
> vlan31 224.0.0.251 0.0.0.0 172.16.5.1 27 2 E
>
> vlan31 239.3.0.1 0.0.0.0 172.16.5.2 21 2 E
>
> xorp at dns> show igmp interface
>
> Interface State Querier Timeout Version Groups
>
> eth0 DISABLED 0.0.0.0 None 2 0
>
> vlan10 DISABLED 172.16.1.1 None 2 0
>
> vlan11 DISABLED 172.16.1.5 None 2 0
>
> vlan12 UP 172.16.1.9 None 2 6
>
> vlan13 DISABLED 172.16.1.13 None 2 0
>
> vlan14 DISABLED 172.16.1.17 None 2 0
>
> vlan15 UP 172.16.1.21 None 2 6
>
> vlan18 DISABLED 0.0.0.0 None 2 0
>
> vlan19 DISABLED 0.0.0.0 None 2 0
>
> vlan20 DISABLED 172.16.3.1 None 2 0
>
> vlan30 UP 172.16.4.1 None 3 4
>
> vlan31 UP 172.16.5.1 None 2 5
>
> *From:*xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] *On Behalf Of *Garry Peirce
> *Sent:* Friday, September 16, 2011 11:13 AM
> *To:* xorp-users at xorp.org
> *Subject:* Re: [Xorp-users] Mcast issues
>
> Just a general comment/suggestion re: mcast issues.
>
> If you are experiencing mcast issues it is very difficult for anyone to provide insight when the entire picture is not supplied.
>
> Help others help you - provide your XORP config (anonymize addressing consistently if you need to) , the entire relevant topology, and IGMP/PIM/MFEA state.
>
> Otherwise it can result in numerous back/forth messages to try and get the full picture and those assisting may become disinterested or available in continuing
> to help solve your issue. I suppose this holds true for any type of problem, but mcast is enough of a different bird that it certainly helps to provide as much
> info as possible.
>
> Oren: perhaps your routers have some PIM adjacency/RP/mapping issue so traffic cannot reach the RP.
>
> [ 2011/09/15 14:28:14.465824 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for source 10.0.0.1 and group 224.5.6.7: not found
>
> Patricio: you show some IGMP info but nothing of PIM state. I?d change your addressing to avoid 32:1 overlap. The addresses you chose to use for two different
> services will end up using the same L2 address which may make other troubleshooting more difficult as well as pass both streams to all participating NICs only
> to be dropped. Sensing your addressing did not actually have SSM/GLOP needs, you might move these, for example, into the 239.x.x.x block.
>
>
>
> _______________________________________________
> 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 p_latini at hotmail.com  Fri Sep 16 12:13:52 2011
From: p_latini at hotmail.com (Patricio Latini)
Date: Fri, 16 Sep 2011 16:13:52 -0300
Subject: [Xorp-users] Mcast issues
In-Reply-To: <4E737565.6060206@candelatech.com>
References: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>
	<COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>
	<4E737565.6060206@candelatech.com>
Message-ID: <COL117-DS16D2C22A364DD9545DD012F7060@phx.gbl>

I have upgraded to 1.8.4 and still have the traffic being flooded to only
one interface.

Patricio

-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, September 16, 2011 1:12 PM
To: Patricio Latini
Cc: 'Garry Peirce'; xorp-users at xorp.org
Subject: Re: [Xorp-users] Mcast issues

On 09/16/2011 07:44 AM, Patricio Latini wrote:
> Garry, thanks for your response, I changed the groups to all of them 
> in the 239.x.x.x range however the behaivior is the same. Do you know any
useful command to troubleshoot this?

There are definitely bugs in 1.8.3, so please make sure you try the 1.8.4 or
compile from latest github source tree (which is 1.8.4).

We've been testing ipv4 multicast lately and it works for us.  We are having
troubles with IPv6, but not sure if it's xorp related yet...

As always, make sure your generator has TTL high enough..it's usually 1 by
default which will not route.

Thanks,
Ben

>
> Patricio
>
> xorp at dns> show pim mfc
>
> Group Source RP
>
> 229.255.0.1 172.16.4.254 0.0.0.0
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ............O
>
> 239.1.0.1 172.16.4.254 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.2.0.1 172.16.4.14 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.3.0.1 172.16.4.10 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ...........O.
>
> xorp at dns> show pim mfc
>
> Group Source RP
>
> 229.255.0.1 172.16.4.254 0.0.0.0
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ............O
>
> 239.1.0.1 172.16.4.254 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.2.0.1 172.16.4.14 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: .............
>
> 239.3.0.1 172.16.4.10 172.16.1.9
>
> Incoming interface : vlan30
>
> Outgoing interfaces: ...........O.
>
> xorp at dns> show igmp group
>
> Interface Group Source LastReported Timeout V State
>
> vlan12 224.0.0.2 0.0.0.0 172.16.1.9 28 2 E
>
> vlan12 224.0.0.5 0.0.0.0 172.16.1.9 20 2 E
>
> vlan12 224.0.0.6 0.0.0.0 172.16.1.9 19 2 E
>
> vlan12 224.0.0.13 0.0.0.0 172.16.1.9 28 2 E
>
> vlan12 224.0.0.22 0.0.0.0 172.16.1.9 27 2 E
>
> vlan12 224.0.0.251 0.0.0.0 172.16.1.9 28 2 E
>
> vlan15 224.0.0.2 0.0.0.0 172.16.1.21 29 2 E
>
> vlan15 224.0.0.5 0.0.0.0 172.16.1.21 25 2 E
>
> vlan15 224.0.0.6 0.0.0.0 172.16.1.21 26 2 E
>
> vlan15 224.0.0.22 0.0.0.0 172.16.1.21 24 2 E
>
> vlan15 224.0.0.251 0.0.0.0 172.16.1.21 26 2 E
>
> vlan15 239.3.0.1 0.0.0.0 172.16.1.22 23 2 E
>
> vlan30 224.0.0.2 0.0.0.0 172.16.4.1 28 3 E
>
> vlan30 224.0.0.13 0.0.0.0 172.16.4.1 28 3 E
>
> vlan30 224.0.0.22 0.0.0.0 172.16.4.1 28 3 E
>
> vlan30 224.0.0.251 0.0.0.0 172.16.4.1 28 3 E
>
> vlan31 224.0.0.2 0.0.0.0 172.16.5.1 25 2 E
>
> vlan31 224.0.0.13 0.0.0.0 172.16.5.1 29 2 E
>
> vlan31 224.0.0.22 0.0.0.0 172.16.5.1 23 2 E
>
> vlan31 224.0.0.251 0.0.0.0 172.16.5.1 27 2 E
>
> vlan31 239.3.0.1 0.0.0.0 172.16.5.2 21 2 E
>
> xorp at dns> show igmp interface
>
> Interface State Querier Timeout Version Groups
>
> eth0 DISABLED 0.0.0.0 None 2 0
>
> vlan10 DISABLED 172.16.1.1 None 2 0
>
> vlan11 DISABLED 172.16.1.5 None 2 0
>
> vlan12 UP 172.16.1.9 None 2 6
>
> vlan13 DISABLED 172.16.1.13 None 2 0
>
> vlan14 DISABLED 172.16.1.17 None 2 0
>
> vlan15 UP 172.16.1.21 None 2 6
>
> vlan18 DISABLED 0.0.0.0 None 2 0
>
> vlan19 DISABLED 0.0.0.0 None 2 0
>
> vlan20 DISABLED 172.16.3.1 None 2 0
>
> vlan30 UP 172.16.4.1 None 3 4
>
> vlan31 UP 172.16.5.1 None 2 5
>
> *From:*xorp-users-bounces at xorp.org 
> [mailto:xorp-users-bounces at xorp.org] *On Behalf Of *Garry Peirce
> *Sent:* Friday, September 16, 2011 11:13 AM
> *To:* xorp-users at xorp.org
> *Subject:* Re: [Xorp-users] Mcast issues
>
> Just a general comment/suggestion re: mcast issues.
>
> If you are experiencing mcast issues it is very difficult for anyone to
provide insight when the entire picture is not supplied.
>
> Help others help you - provide your XORP config (anonymize addressing
consistently if you need to) , the entire relevant topology, and
IGMP/PIM/MFEA state.
>
> Otherwise it can result in numerous back/forth messages to try and get 
> the full picture and those assisting may become disinterested or 
> available in continuing to help solve your issue. I suppose this holds
true for any type of problem, but mcast is enough of a different bird that
it certainly helps to provide as much info as possible.
>
> Oren: perhaps your routers have some PIM adjacency/RP/mapping issue so
traffic cannot reach the RP.
>
> [ 2011/09/15 14:28:14.465824 WARNING xorp_pimsm4 PIM ] 
> JoinDesired(S,G) = false: upstream neighbor for source 10.0.0.1 and 
> group 224.5.6.7: not found
>
> Patricio: you show some IGMP info but nothing of PIM state. I'd change 
> your addressing to avoid 32:1 overlap. The addresses you chose to use 
> for two different services will end up using the same L2 address which may
make other troubleshooting more difficult as well as pass both streams to
all participating NICs only to be dropped. Sensing your addressing did not
actually have SSM/GLOP needs, you might move these, for example, into the
239.x.x.x block.
>
>
>
> _______________________________________________
> 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 p_latini at hotmail.com  Fri Sep 16 21:21:47 2011
From: p_latini at hotmail.com (Patricio Latini)
Date: Sat, 17 Sep 2011 01:21:47 -0300
Subject: [Xorp-users] Mcast issues
In-Reply-To: <000301cc74aa$71adf530$5509df90$@hotmail.com>
References: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>	<COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>	<4E737565.6060206@candelatech.com>
	<000301cc74aa$71adf530$5509df90$@hotmail.com>
Message-ID: <COL117-DS18AC47DE44415032EF4334F7090@phx.gbl>

 

I have done some extra troubleshooting,  have the show igmp group where it
shows that there are igmp joins from 239.3.0.1 in both vlan15 and vlan31
however in the mr_cache shows only one output interface 11:1 (vlan31).

 

root at dns> show igmp group 

Interface    Group           Source          LastReported Timeout V State

vlan12       224.0.0.2       0.0.0.0         172.16.1.9        24 2     E

vlan12       224.0.0.5       0.0.0.0         172.16.1.9        19 2     E

vlan12       224.0.0.6       0.0.0.0         172.16.1.9        29 2     E

vlan12       224.0.0.13      0.0.0.0         172.16.1.9        28 2     E

vlan12       224.0.0.22      0.0.0.0         172.16.1.9        26 2     E

vlan12       224.0.0.251     0.0.0.0         172.16.1.9        15 2     E

vlan15       224.0.0.2       0.0.0.0         172.16.1.21       16 2     E

vlan15       224.0.0.5       0.0.0.0         172.16.1.21       24 2     E

vlan15       224.0.0.6       0.0.0.0         172.16.1.21       25 2     E

vlan15       224.0.0.22      0.0.0.0         172.16.1.21       16 2     E

vlan15       224.0.0.251     0.0.0.0         172.16.1.21       18 2     E

vlan15       239.3.0.1       0.0.0.0         172.16.1.22       16 2     E

vlan30       224.0.0.2       0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.13      0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.22      0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.251     0.0.0.0         172.16.4.1        28 3     E

vlan31       224.0.0.2       0.0.0.0         172.16.5.1        19 2     E

vlan31       224.0.0.13      0.0.0.0         172.16.5.1        19 2     E

vlan31       224.0.0.22      0.0.0.0         172.16.5.1        24 2     E

vlan31       224.0.0.251     0.0.0.0         172.16.5.1        27 2     E

vlan31       239.3.0.1       0.0.0.0         172.16.5.2        28 2     E

root at dns> show igmp interface 

Interface    State    Querier         Timeout Version Groups

eth0         DISABLED 0.0.0.0            None       2      0

vlan10       DISABLED 172.16.1.1         None       2      0

vlan11       DISABLED 172.16.1.5         None       2      0

vlan12       UP       172.16.1.9         None       2      6

vlan13       DISABLED 172.16.1.13        None       2      0

vlan14       DISABLED 172.16.1.17        None       2      0

vlan15       UP       172.16.1.21        None       2      6

vlan18       DISABLED 0.0.0.0            None       2      0

vlan19       DISABLED 0.0.0.0            None       2      0

vlan20       DISABLED 172.16.3.1         None       2      0

vlan30       UP       172.16.4.1         None       3      4

vlan31       UP       172.16.5.1         None       2      5

root at dns> exit

root at dns:~# cat /proc/net/ip_mr_vif

Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote

3 vlan12            0       0         0       0 00000 090110AC 00000000

6 vlan15            0       0         0       0 00000 150110AC 00000000

10 vlan30     356427750 9852609         0       0 00000 010410AC 00000000

11 vlan31            0       0  890386048 7053810 00000 010510AC 00000000

root at dns:~# cat /proc/net/ip_mr_cache

Group    Origin   Iif     Pkts    Bytes    Wrong Oifs

010002EF 0E0410AC 10   1129162 1517593728        0

010003EF 0A0410AC 10   8763936 3188795392        0 11:1  

0100FFE5 FE0410AC 10       476    60452        0

 

-----Original Message-----
From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On
Behalf Of Patricio Latini
Sent: Friday, September 16, 2011 4:14 PM
To: 'Ben Greear'
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] Mcast issues

 

I have upgraded to 1.8.4 and still have the traffic being flooded to only
one interface.

 

Patricio

 

-----Original Message-----

From: Ben Greear [mailto:greearb at candelatech.com]

Sent: Friday, September 16, 2011 1:12 PM

To: Patricio Latini

Cc: 'Garry Peirce'; xorp-users at xorp.org

Subject: Re: [Xorp-users] Mcast issues

 

On 09/16/2011 07:44 AM, Patricio Latini wrote:

> Garry, thanks for your response, I changed the groups to all of them 

> in the 239.x.x.x range however the behaivior is the same. Do you know 

> any

useful command to troubleshoot this?

 

There are definitely bugs in 1.8.3, so please make sure you try the 1.8.4 or
compile from latest github source tree (which is 1.8.4).

 

We've been testing ipv4 multicast lately and it works for us.  We are having
troubles with IPv6, but not sure if it's xorp related yet...

 

As always, make sure your generator has TTL high enough..it's usually 1 by
default which will not route.

 

Thanks,

Ben

 

> 

> Patricio

> 

> xorp at dns> show pim mfc

> 

> Group Source RP

> 

> 229.255.0.1 172.16.4.254 0.0.0.0

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: ............O

> 

> 239.1.0.1 172.16.4.254 172.16.1.9

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: .............

> 

> 239.2.0.1 172.16.4.14 172.16.1.9

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: .............

> 

> 239.3.0.1 172.16.4.10 172.16.1.9

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: ...........O.

> 

> xorp at dns> show pim mfc

> 

> Group Source RP

> 

> 229.255.0.1 172.16.4.254 0.0.0.0

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: ............O

> 

> 239.1.0.1 172.16.4.254 172.16.1.9

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: .............

> 

> 239.2.0.1 172.16.4.14 172.16.1.9

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: .............

> 

> 239.3.0.1 172.16.4.10 172.16.1.9

> 

> Incoming interface : vlan30

> 

> Outgoing interfaces: ...........O.

> 

> xorp at dns> show igmp group

> 

> Interface Group Source LastReported Timeout V State

> 

> vlan12 224.0.0.2 0.0.0.0 172.16.1.9 28 2 E

> 

> vlan12 224.0.0.5 0.0.0.0 172.16.1.9 20 2 E

> 

> vlan12 224.0.0.6 0.0.0.0 172.16.1.9 19 2 E

> 

> vlan12 224.0.0.13 0.0.0.0 172.16.1.9 28 2 E

> 

> vlan12 224.0.0.22 0.0.0.0 172.16.1.9 27 2 E

> 

> vlan12 224.0.0.251 0.0.0.0 172.16.1.9 28 2 E

> 

> vlan15 224.0.0.2 0.0.0.0 172.16.1.21 29 2 E

> 

> vlan15 224.0.0.5 0.0.0.0 172.16.1.21 25 2 E

> 

> vlan15 224.0.0.6 0.0.0.0 172.16.1.21 26 2 E

> 

> vlan15 224.0.0.22 0.0.0.0 172.16.1.21 24 2 E

> 

> vlan15 224.0.0.251 0.0.0.0 172.16.1.21 26 2 E

> 

> vlan15 239.3.0.1 0.0.0.0 172.16.1.22 23 2 E

> 

> vlan30 224.0.0.2 0.0.0.0 172.16.4.1 28 3 E

> 

> vlan30 224.0.0.13 0.0.0.0 172.16.4.1 28 3 E

> 

> vlan30 224.0.0.22 0.0.0.0 172.16.4.1 28 3 E

> 

> vlan30 224.0.0.251 0.0.0.0 172.16.4.1 28 3 E

> 

> vlan31 224.0.0.2 0.0.0.0 172.16.5.1 25 2 E

> 

> vlan31 224.0.0.13 0.0.0.0 172.16.5.1 29 2 E

> 

> vlan31 224.0.0.22 0.0.0.0 172.16.5.1 23 2 E

> 

> vlan31 224.0.0.251 0.0.0.0 172.16.5.1 27 2 E

> 

> vlan31 239.3.0.1 0.0.0.0 172.16.5.2 21 2 E

> 

> xorp at dns> show igmp interface

> 

> Interface State Querier Timeout Version Groups

> 

> eth0 DISABLED 0.0.0.0 None 2 0

> 

> vlan10 DISABLED 172.16.1.1 None 2 0

> 

> vlan11 DISABLED 172.16.1.5 None 2 0

> 

> vlan12 UP 172.16.1.9 None 2 6

> 

> vlan13 DISABLED 172.16.1.13 None 2 0

> 

> vlan14 DISABLED 172.16.1.17 None 2 0

> 

> vlan15 UP 172.16.1.21 None 2 6

> 

> vlan18 DISABLED 0.0.0.0 None 2 0

> 

> vlan19 DISABLED 0.0.0.0 None 2 0

> 

> vlan20 DISABLED 172.16.3.1 None 2 0

> 

> vlan30 UP 172.16.4.1 None 3 4

> 

> vlan31 UP 172.16.5.1 None 2 5

> 

> *From:*xorp-users-bounces at xorp.org

>  <mailto:[mailto:xorp-users-bounces at xorp.org]>
[mailto:xorp-users-bounces at xorp.org] *On Behalf Of *Garry Peirce

> *Sent:* Friday, September 16, 2011 11:13 AM

> *To:*  <mailto:xorp-users at xorp.org> xorp-users at xorp.org

> *Subject:* Re: [Xorp-users] Mcast issues

> 

> Just a general comment/suggestion re: mcast issues.

> 

> If you are experiencing mcast issues it is very difficult for anyone 

> to

provide insight when the entire picture is not supplied.

> 

> Help others help you - provide your XORP config (anonymize addressing

consistently if you need to) , the entire relevant topology, and
IGMP/PIM/MFEA state.

> 

> Otherwise it can result in numerous back/forth messages to try and get 

> the full picture and those assisting may become disinterested or 

> available in continuing to help solve your issue. I suppose this holds

true for any type of problem, but mcast is enough of a different bird that
it certainly helps to provide as much info as possible.

> 

> Oren: perhaps your routers have some PIM adjacency/RP/mapping issue so

traffic cannot reach the RP.

> 

> [ 2011/09/15 14:28:14.465824 WARNING xorp_pimsm4 PIM ]

> JoinDesired(S,G) = false: upstream neighbor for source 10.0.0.1 and 

> group 224.5.6.7: not found

> 

> Patricio: you show some IGMP info but nothing of PIM state. I'd change 

> your addressing to avoid 32:1 overlap. The addresses you chose to use 

> for two different services will end up using the same L2 address which 

> may

make other troubleshooting more difficult as well as pass both streams to
all participating NICs only to be dropped. Sensing your addressing did not
actually have SSM/GLOP needs, you might move these, for example, into the
239.x.x.x block.

> 

> 

> 

> _______________________________________________

> Xorp-users mailing list

>  <mailto:Xorp-users at xorp.org> Xorp-users at xorp.org

>  <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users>
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

 

 

--

Ben Greear < <mailto:greearb at candelatech.com> greearb at candelatech.com>

Candela Technologies Inc   <http://www.candelatech.com>
http://www.candelatech.com

 

 

_______________________________________________

Xorp-users mailing list

 <mailto:Xorp-users at xorp.org> Xorp-users at xorp.org

 <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users>
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/20110917/78baa2de/attachment-0001.html 

From visser.rob at gmail.com  Mon Sep 19 01:22:20 2011
From: visser.rob at gmail.com (Rob Visser)
Date: Mon, 19 Sep 2011 10:22:20 +0200
Subject: [Xorp-users] PIM-SSM without RP
Message-ID: <CAKuuTyYsJENLEKzT0+eJbQhZs5oDUqKia+rL4kznDzjU1XyZPA@mail.gmail.com>

Hello,

I must admit: I am an XORP newby.
Is it possible to set-up a Source Specific Multicast tree with an implict RP
at the root of each source?

Thanks

Rob Visser
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110919/028d6743/attachment.html 

From JoeCoco at mecnet.net  Mon Sep 19 05:58:24 2011
From: JoeCoco at mecnet.net (Joe Coco)
Date: Mon, 19 Sep 2011 12:58:24 +0000
Subject: [Xorp-users] 1.8.4 problems with xorpsh
Message-ID: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net>

Hello,

So we're seeing this problem.  Once you have the router configured, a number of hours or a day later when we run xorpsh from the command prompt we get the following error:


Saturn:/Log_Drive# xorpsh

Failed to register with router manager process

102 Command failed Failed to close temporary file: /tmp/rtrmgr-xorpsh-3990-Saturn

The following files are in /tmp

xrl.DfneQu  xrl.Dm4fN3  xrl.HRzApF  xrl.V3ucPO  xrl.fI4sT3  xrl.he3lP3  xrl.l027P5  xrl.p9pZbl


The following xorp processes are in the list:

2379 ?        S     12:03 xorp_fea
2380 ?        S      6:51 xorp_rib
2381 ?        S      0:02 xorp_policy
2382 ?        S      0:02 xorp_static_routes
2383 ?        S     11:02 xorp_bgp
2384 ?        Ss     0:48 /usr/local/xorp/sbin/xorp_rtrmgr -b /home/xorp/config.boot -l /var/log/xo


Attached is a log file, not sure if it is telling us anything related to this issue.

The only way to manage the router at this point is to kill and restart all processes.


n  Joe


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110919/e3146c51/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorp.log
Type: application/octet-stream
Size: 238401 bytes
Desc: xorp.log
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110919/e3146c51/attachment-0001.obj 

From greearb at candelatech.com  Mon Sep 19 09:22:16 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 19 Sep 2011 09:22:16 -0700
Subject: [Xorp-users] [Xorp-hackers] 1.8.4 problems with xorpsh
In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net>
References: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net>
Message-ID: <4E776C38.3060902@candelatech.com>

On 09/19/2011 05:58 AM, Joe Coco wrote:
> Hello,
>
> So we?re seeing this problem. Once you have the router configured, a number of hours or a day later when we run xorpsh from the command prompt we get the
> following error:
>
> Saturn:/Log_Drive# xorpsh
>
> Failed to register with router manager process
>
> 102 Command failed Failed to close temporary file: /tmp/rtrmgr-xorpsh-3990-Saturn
>
> The following files are in /tmp
>
> xrl.DfneQu xrl.Dm4fN3 xrl.HRzApF xrl.V3ucPO xrl.fI4sT3 xrl.he3lP3 xrl.l027P5 xrl.p9pZbl
>
> The following xorp processes are in the list:
>
> 2379 ? S 12:03 xorp_fea
>
> 2380 ? S 6:51 xorp_rib
>
> 2381 ? S 0:02 xorp_policy
>
> 2382 ? S 0:02 xorp_static_routes
>
> 2383 ? S 11:02 xorp_bgp
>
> 2384 ? Ss 0:48 /usr/local/xorp/sbin/xorp_rtrmgr -b /home/xorp/config.boot -l /var/log/xo
>
> Attached is a log file, not sure if it is telling us anything related to this issue.

I don't see any obvious errors in the logs...but maybe the problem happened
before the time covered in these logs?

One thing though:  It seems we are deleting already-deleted routes very often..multiple
per second.  Any idea why this is?  Are your links in constant heavy modification?

Can you have it log to a file so that we have the complete logs
available?

Also, if that doesn't show an obvious problem, please run strace xorpsh
to see what system calls it makes (and which ones fail, perhaps).

Finally, you might try increasing the xrl related timeouts by setting
the environ vars on this page before starting xorpsh:

http://xorp.run.montefiore.ulg.ac.be/latex2wiki/user_manual/environment_variables

If increasing timeouts somehow 'fixes' it, then things are still weird, but
it gives us some additional information...

Thanks,
Ben


>
> The only way to manage the router at this point is to kill and restart all processes.
>
> nJoe
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


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


From JoeCoco at mecnet.net  Mon Sep 19 10:24:21 2011
From: JoeCoco at mecnet.net (Joe Coco)
Date: Mon, 19 Sep 2011 17:24:21 +0000
Subject: [Xorp-users] [Xorp-hackers] 1.8.4 problems with xorpsh
In-Reply-To: <4E776C38.3060902@candelatech.com>
References: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net>
	<4E776C38.3060902@candelatech.com>
Message-ID: <9513B0D809E3024A85A611E9B3726CA99BC638@MECnetExchange.mecnet.net>

Hi Ben,

> I don't see any obvious errors in the logs...but maybe the problem happened before the time covered in these logs?

Yeah, I didn't realize that route flap was so bad and was filling up the log.

> One thing though:  It seems we are deleting already-deleted routes very often..multiple per second.  Any idea why this is?  Are your links in constant heavy modification?

This is a BGP link, and apparently the route for this network (2610:1e0:1f00::/48) keeps flapping. I'm going to contact my peer and find out what is going on.
Is there a way  I can suppress that route from being logged?

-- Joe


From greearb at candelatech.com  Mon Sep 19 10:54:34 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 19 Sep 2011 10:54:34 -0700
Subject: [Xorp-users] [Xorp-hackers] 1.8.4 problems with xorpsh
In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99BC638@MECnetExchange.mecnet.net>
References: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net>
	<4E776C38.3060902@candelatech.com>
	<9513B0D809E3024A85A611E9B3726CA99BC638@MECnetExchange.mecnet.net>
Message-ID: <4E7781DA.7050302@candelatech.com>

On 09/19/2011 10:24 AM, Joe Coco wrote:
> Hi Ben,
>
>> I don't see any obvious errors in the logs...but maybe the problem happened before the time covered in these logs?
>
> Yeah, I didn't realize that route flap was so bad and was filling up the log.
>
>> One thing though:  It seems we are deleting already-deleted routes very often..multiple per second.  Any idea why this is?  Are your links in constant heavy modification?
>
> This is a BGP link, and apparently the route for this network (2610:1e0:1f00::/48) keeps flapping. I'm going to contact my peer and find out what is going on.
> Is there a way  I can suppress that route from being logged?

No, not w/out commenting out that particular bit of code.

Thanks,
Ben

>
> -- Joe


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


From greearb at candelatech.com  Mon Sep 19 10:59:55 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 19 Sep 2011 10:59:55 -0700
Subject: [Xorp-users] Mcast issues
In-Reply-To: <COL117-DS16D2C22A364DD9545DD012F7060@phx.gbl>
References: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>
	<COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>
	<4E737565.6060206@candelatech.com>
	<COL117-DS16D2C22A364DD9545DD012F7060@phx.gbl>
Message-ID: <4E77831B.9010208@candelatech.com>

On 09/16/2011 12:13 PM, Patricio Latini wrote:
> I have upgraded to 1.8.4 and still have the traffic being flooded to only
> one interface.

We ran some tests here, and IPv4 multicast routing is working for us.

Except that on route-flap, we are seeing a crash in xorp_pimsm4.  We hope
to have that fixed today as we need it for our own product.

Also, you might try making sure that your VLANs all have unique
MAC addresses.  I'm not sure that is required, but often it helps
with subtle issues.

Thanks,
Ben

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


From peirce at maine.edu  Mon Sep 19 12:39:27 2011
From: peirce at maine.edu (Garry Peirce)
Date: Mon, 19 Sep 2011 15:39:27 -0400
Subject: [Xorp-users] Mcast issues
In-Reply-To: <COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>
References: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>
	<COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>
Message-ID: <00f401cc7703$d7918ff0$86b4afd0$@maine.edu>

Patricio,

 

1)      (again) the config of XORP router and topology would be most helpful

a.       VL12 and 15 are what /20's?

2)      Is 172.16.1.9 this same XORP router?  As this is the RP.

3)      I see the 239.3.0.1 join from VL15 and VL30 but not from VL12

4)      Also helpful, the output of 'show pim interface','show pim
neighbors', 'show pim bootstrap', 'show pim mrib'

 

 

From: Patricio Latini [mailto:p_latini at hotmail.com] 
Sent: Friday, September 16, 2011 10:45 AM
To: 'Garry Peirce'; xorp-users at xorp.org
Subject: RE: [Xorp-users] Mcast issues

 

Garry, thanks for your response, I changed the groups to all of them in the
239.x.x.x range however the behaivior is the same. Do you know any useful
command to troubleshoot this?

 

Patricio

 

xorp at dns> show pim mfc 

Group           Source          RP             

229.255.0.1     172.16.4.254    0.0.0.0        

    Incoming interface :      vlan30

    Outgoing interfaces:      ............O

239.1.0.1       172.16.4.254    172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.2.0.1       172.16.4.14     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.3.0.1       172.16.4.10     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      ...........O.

xorp at dns> show pim mfc 

Group           Source          RP             

229.255.0.1     172.16.4.254    0.0.0.0        

    Incoming interface :      vlan30

    Outgoing interfaces:      ............O

239.1.0.1       172.16.4.254    172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.2.0.1       172.16.4.14     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      .............

239.3.0.1       172.16.4.10     172.16.1.9     

    Incoming interface :      vlan30

    Outgoing interfaces:      ...........O.

xorp at dns> show igmp group 

Interface    Group           Source          LastReported Timeout V State

vlan12       224.0.0.2       0.0.0.0         172.16.1.9        28 2     E

vlan12       224.0.0.5       0.0.0.0         172.16.1.9        20 2     E

vlan12       224.0.0.6       0.0.0.0         172.16.1.9        19 2     E

vlan12       224.0.0.13      0.0.0.0         172.16.1.9        28 2     E

vlan12       224.0.0.22      0.0.0.0         172.16.1.9        27 2     E

vlan12       224.0.0.251     0.0.0.0         172.16.1.9        28 2     E

vlan15       224.0.0.2       0.0.0.0         172.16.1.21       29 2     E

vlan15       224.0.0.5       0.0.0.0         172.16.1.21       25 2     E

vlan15       224.0.0.6       0.0.0.0         172.16.1.21       26 2     E

vlan15       224.0.0.22      0.0.0.0         172.16.1.21       24 2     E

vlan15       224.0.0.251     0.0.0.0         172.16.1.21       26 2     E

vlan15       239.3.0.1       0.0.0.0         172.16.1.22       23 2     E

vlan30       224.0.0.2       0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.13      0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.22      0.0.0.0         172.16.4.1        28 3     E

vlan30       224.0.0.251     0.0.0.0         172.16.4.1        28 3     E

vlan31       224.0.0.2       0.0.0.0         172.16.5.1        25 2     E

vlan31       224.0.0.13      0.0.0.0         172.16.5.1        29 2     E

vlan31       224.0.0.22      0.0.0.0         172.16.5.1        23 2     E

vlan31       224.0.0.251     0.0.0.0         172.16.5.1        27 2     E

vlan31       239.3.0.1       0.0.0.0         172.16.5.2        21 2     E

xorp at dns> show igmp interface 

Interface    State    Querier         Timeout Version Groups

eth0         DISABLED 0.0.0.0            None       2      0

vlan10       DISABLED 172.16.1.1         None       2      0

vlan11       DISABLED 172.16.1.5         None       2      0

vlan12       UP       172.16.1.9         None       2      6

vlan13       DISABLED 172.16.1.13        None       2      0

vlan14       DISABLED 172.16.1.17        None       2      0

vlan15       UP       172.16.1.21        None       2      6

vlan18       DISABLED 0.0.0.0            None       2      0

vlan19       DISABLED 0.0.0.0            None       2      0

vlan20       DISABLED 172.16.3.1         None       2      0

vlan30       UP       172.16.4.1         None       3      4

vlan31       UP       172.16.5.1         None       2      5

 

From:  <mailto:xorp-users-bounces at xorp.org> xorp-users-bounces at xorp.org
<mailto:[mailto:xorp-users-bounces at xorp.org]>
[mailto:xorp-users-bounces at xorp.org] On Behalf Of Garry Peirce
Sent: Friday, September 16, 2011 11:13 AM
To:  <mailto:xorp-users at xorp.org> xorp-users at xorp.org
Subject: Re: [Xorp-users] Mcast issues

 

Just a general comment/suggestion re: mcast issues.

If you are experiencing mcast issues it is very difficult for anyone to
provide insight when the entire picture is not supplied.

Help others help you - provide your XORP config (anonymize addressing
consistently if you need to) , the entire relevant topology, and
IGMP/PIM/MFEA state. 

 

Otherwise it can result in numerous back/forth messages to try and get the
full picture and those assisting may become disinterested or available in
continuing to help solve your issue.  I suppose this holds true for any type
of problem, but mcast is enough of a different bird that it certainly helps
to provide as much info as possible.

 

Oren:  perhaps your routers have some PIM adjacency/RP/mapping issue so
traffic cannot reach the RP.

[ 2011/09/15 14:28:14.465824 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) =
false: upstream neighbor for source 10.0.0.1 and group 224.5.6.7: not found

 

Patricio:  you show some IGMP info but nothing of PIM state.  I'd change
your addressing to avoid 32:1 overlap. The addresses you chose to use for
two different services will end up using the same L2 address which may make
other troubleshooting more difficult as well as pass both streams to all
participating NICs only to be dropped.  Sensing your addressing did not
actually have SSM/GLOP needs, you might move these, for example, into the
239.x.x.x block. 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110919/465bcadb/attachment-0001.html 

From greearb at candelatech.com  Mon Sep 19 21:15:38 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 19 Sep 2011 21:15:38 -0700
Subject: [Xorp-users] New 1.8.4 builds uploaded
Message-ID: <4E78136A.1040606@candelatech.com>

I uploaded some new xorp 1.8.4 binaries at:

http://www.xorp.org/releases/1.8.4/

(You can build from source via github xorp.ct project)

This fixes some memory leaks and such found under valgrind, and
some crashes due to timers hitting deleted memory.  And, some
PIM bugs that I introduced in the builds from a few days ago.

Thanks,
Ben

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


From greearb at candelatech.com  Tue Sep 20 11:47:50 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Sep 2011 11:47:50 -0700
Subject: [Xorp-users] New 1.8.4 builds uploaded
In-Reply-To: <4E78136A.1040606@candelatech.com>
References: <4E78136A.1040606@candelatech.com>
Message-ID: <4E78DFD6.5060905@candelatech.com>

On 09/19/2011 09:15 PM, Ben Greear wrote:
> I uploaded some new xorp 1.8.4 binaries at:
>
> http://www.xorp.org/releases/1.8.4/
>
> (You can build from source via github xorp.ct project)
>
> This fixes some memory leaks and such found under valgrind, and
> some crashes due to timers hitting deleted memory.  And, some
> PIM bugs that I introduced in the builds from a few days ago.

The final bug we were tracking internally was ipv6 multicast not
working.

Turns out it was a config issue...ipv6 mcast addrs that should be
routed need to start with: ff0e (or, at the least, ff01 does NOT work
and ff0e does.  Maybe some others route as well...)

There is still an issue with OSPF being slow to process some
xrl messages, sometimes causing timeouts that totally break
xorp.  Looks like it might not be new to 1.8.4 (v/s 1.8.3),
and I cannot reproduce it locally, so not planning to hold
up the release for it.

So, xorp 1.8.4 is done as far as I'm concerned.  If someone
else know of any regressions from 1.8.3, please let me know.

Thanks,
Ben

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


From yanwei at bupt.edu.cn  Wed Sep 21 00:30:12 2011
From: yanwei at bupt.edu.cn (=?UTF-8?B?6aKc546u?=)
Date: Wed, 21 Sep 2011 15:30:12 +0800
Subject: [Xorp-users] How does the OSPF packet be handled when using kernel
 level Click as the FEA?
Message-ID: <4E799284.2050702@bupt.edu.cn>

Hi,i'm new to xorp.
I'm using xorp 1.6,with kernel level Click being its FEA.
And I have some questions. Needs help^_^

1.when an Ospf packet arrives at the interface of the click
router ,which part of the click is responsible for handling
the ospf packet? Is it directly captured by the xorp on the
very interface or is it firstly sent to an element within
the click and then sent to the xorp by the click element?

2.When the xorp generates ospf packet,how does it send the
packet out of Click?

Any help would be appreciated!

-----
yan


From vglafirov at gmail.com  Wed Sep 21 04:48:32 2011
From: vglafirov at gmail.com (Vladimir Glafirov)
Date: Wed, 21 Sep 2011 13:48:32 +0200
Subject: [Xorp-users] Multicast over GRE tunnel with Xorp.
Message-ID: <4E79CF10.10803@gmail.com>

Dear Xorp users.

I am really new in Linux routing.

I am trying to setup multicast routing through GRE tunnel on RHEL5 
(2.6.18 kernel) with xorp.

My network configuration is following:
1. I have two RHEL boxes in two different subnets with unicast routing 
enabled.

first#ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:30:48:C9:CB:CA
           inet addr:128.142.172.31  Bcast:128.142.255.255  Mask:255.255.0.0
           inet6 addr: fe80::230:48ff:fec9:cbca/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:12059720 errors:0 dropped:0 overruns:0 frame:0
           TX packets:9352026 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:9085645050 (8.4 GiB)  TX bytes:8887662470 (8.2 GiB)
           Memory:faf60000-faf80000

second#ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:15:5D:FF:0D:A7
           inet addr:128.142.194.68  Bcast:128.142.255.255  Mask:255.255.0.0
           inet6 addr: fe80::215:5dff:feff:da7/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:4125721 errors:0 dropped:0 overruns:0 frame:0
           TX packets:1145635 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:1253283412 (1.1 GiB)  TX bytes:254188384 (242.4 MiB)




2. I have GRE tunnel between this boxes

first#ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:192.168.1.1  P-t-P:192.168.1.2  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
           RX packets:4 errors:0 dropped:0 overruns:0 frame:0
           TX packets:91 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:336 (336.0 b)  TX bytes:6804 (6.6 KiB)

second#ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:192.168.1.2  P-t-P:192.168.1.1  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
           RX packets:4 errors:0 dropped:0 overruns:0 frame:0
           TX packets:125 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:336 (336.0 b)  TX bytes:8352 (8.1 KiB)

Tunnel itself works fine:
first# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.667 ms

second# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.696 ms

First host sends UDP packets to address 239.192.106.130 (RH cluster 
suite) and waiting for reply. Second host has to receive them and send 
something like I_AM_ALIVE packet back to 239.192.106.130 group.

My xorp configurations is following:

For first host:

/*XORP Configuration File, v1.0*/

rtrmgr {
     config-directory: "/etc/xorp"
}

interfaces {

         interface eth0 {
          description: "upstream interface"
          disable:false
          default-system-config
           vif eth0{
                 address 128.142.172.31 {
                     prefix-length:24
                     multicast-capable: true
                 }
           }
         }


         interface tun0 {
          description: "downstream interface"
          disable: false
          default-system-config
           vif tun0{
                 address 192.168.1.1 {
                     prefix-length:24
                     multicast-capable: true
                 }
           }
         }

}
plumbing {
  mfea4 {
   disable: false
         interface eth0 {
          vif eth0 {
           disable: false
          }
         }

         interface tun0 {
          vif tun0 {
           disable: false
          }
         }

         interface register_vif {
          vif register_vif {
           /* Note: this vif should be always enabled */
           disable: false
          }
         }
         traceoptions {
          flag all {
           disable: false
          }
         }
  }
}
protocols {

  igmp {
           disable: false
         interface eth0 {
          vif eth0 {
           disable: false
          }
         }

         interface tun0 {
          vif tun0 {
           disable: false
          }
         }

         traceoptions {
           flag all {
           disable: false
           }

         }
  }

  pimsm4 {
           disable: false

         interface eth0 {
          vif eth0 {
           disable: false
          }
         }

         interface tun0 {
          vif tun0 {
           disable: false
          }
         }

         interface register_vif {
          vif register_vif {
           /* Note: this vif should be always enabled */
           disable: false
          }
         }

         static-rps {
          rp 192.168.1.1 {
           group-prefix 239.192.106.130/32 {
            /* rp-priority: 192 */
           }
          }
         }

  bootstrap {
           disable: false
          cand-bsr {
           scope-zone 239.192.106.130/32 {
            cand-bsr-by-vif-name: "tun0"
            bsr-priority: 1
            hash-mask-len: 30
           }
          }
   cand-rp {
    group-prefix 239.192.106.130/32 {
      cand-rp-by-vif-name: "tun0"
      rp-priority: 192
      rp-holdtime: 150
    }
   }
  }


  traceoptions {
         flag all {
           disable: false
         }
  }

}

fib2mrib {
           disable: false
}

For second host:

/*XORP Configuration File, v1.0*/

rtrmgr {
     config-directory: "/etc/xorp"
}

interfaces {

         interface eth0 {
          description: "upstream interface"
          disable:false
          default-system-config
           vif eth0{
                 address 128.142.194.68 {
                     prefix-length:24
                     multicast-capable: true
                 }
           }
         }


         interface tun0 {
          description: "downstream interface"
          disable: false
          default-system-config
           vif tun0{
                 address 192.168.1.2 {
                     prefix-length:24
                     multicast-capable: true
                 }
           }
         }

}
plumbing {
  mfea4 {
   disable: false
         interface eth0 {
          vif eth0 {
           disable: false
          }
         }

         interface tun0 {
          vif tun0 {
           disable: false
          }
         }

         interface register_vif {
          vif register_vif {
           /* Note: this vif should be always enabled */
           disable: false
          }
         }
         traceoptions {
          flag all {
           disable: false
          }
         }
  }
}
protocols {

  igmp {
           disable: false
         interface eth0 {
          vif eth0 {
           disable: false
          }
         }

         interface tun0 {
          vif tun0 {
           disable: false
          }
         }

         traceoptions {
           flag all {
           disable: false
           }

         }
  }

  pimsm4 {
           disable: false

         interface eth0 {
          vif eth0 {
           disable: false
          }
         }

         interface tun0 {
          vif tun0 {
           disable: false
          }
         }

         interface register_vif {
          vif register_vif {
           /* Note: this vif should be always enabled */
           disable: false
          }
         }

         static-rps {
          rp 192.168.1.1 {
           group-prefix 239.192.106.130/32 {
            /* rp-priority: 192 */
           }
          }
         }

/*
  bootstrap {
           disable: false
          cand-bsr {
           scope-zone 239.192.106.130/32 {
            cand-bsr-by-vif-name: "tun0"
            bsr-priority: 1
            hash-mask-len: 30
           }
          }
   cand-rp {
    group-prefix 239.192.106.130/32 {
      cand-rp-by-vif-name: "tun0"
      rp-priority: 192
      rp-holdtime: 150
    }
   }
  }
*/

  traceoptions {
         flag all {
           disable: false
         }
  }

}

fib2mrib {
           disable: false
}

}

I don't see neighbors at all.

Here is an output of some xorp monitoring:

first#show pim interface
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0         UP       Sparse 2 DR              1 128.142.172.31          0
tun0         UP       Sparse 2 DR              1 192.168.1.1             0
register_vif UP       Sparse 2 DR              1 128.142.172.31          0

second#show pim interface
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0         UP       Sparse 2 DR              1 128.142.194.68          0
tun0         UP       Sparse 2 DR              1 192.168.1.2             0
register_vif UP       Sparse 2 DR              1 128.142.194.68          0

first#show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout

second#show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout

Here is an error log for first host:

[ 2011/09/21 13:36:30.763491  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/master_conf_tree.cc:257 execute ] Changed modules: interfaces, 
rtrmgr, firewall, fea, mfea4, rib, igmp, pimsm4, policy, fib2mrib
[ 2011/09/21 13:36:30.765260  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_command.cc:327 startup_validation ] WARNING:  Using 
DelayValidation, module_name: rtrmgr
[ 2011/09/21 13:36:30.765288  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_command.cc:348 config_validation ] WARNING:  Using 
DelayValidation, module_name: rtrmgr
[ 2011/09/21 13:36:30.766144  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_command.cc:369 ready_validation ] WARNING:  Using 
DelayValidation, module_name: rtrmgr
[ 2011/09/21 13:36:30.766210  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: interfaces 
(xorp_fea)
[ 2011/09/21 13:36:30.766814  WARNING xorp_rtrmgr:11195 XrlFinderTarget 
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for 
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"fea" does not exist or is not enabled.
[ 2011/09/21 13:36:30.766956  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve 
failed  retries: 0  max_retries: 30
[ 2011/09/21 13:36:31.768742  INFO xorp_fea:11196 MFEA 
fea/mfea_node.cc:317 enable ] MFEA enabled
[ 2011/09/21 13:36:31.768846  INFO xorp_fea:11196 MFEA 
fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 2011/09/21 13:36:31.769004  INFO xorp_fea:11196 MFEA 
fea/mfea_node_cli.cc:92 start ] CLI started
[ 2011/09/21 13:36:31.769024  INFO xorp_fea:11196 MFEA 
fea/mfea_node.cc:317 enable ] MFEA enabled
[ 2011/09/21 13:36:31.769034  INFO xorp_fea:11196 MFEA 
fea/mfea_node_cli.cc:126 enable ] CLI enabled
[ 2011/09/21 13:36:31.769126  INFO xorp_fea:11196 MFEA 
fea/mfea_node_cli.cc:92 start ] CLI started
[ 2011/09/21 13:36:31.779877  WARNING xorp_fea:11196 FEA 
fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:303 
nlm_cond_newlink_to_fea_cfg ] Could not find interface name for 
interface index 2 in netlink msg.
   Attempting work-around by using ifindex to find the name.
   This warning will be printed only once.
[ 2011/09/21 13:36:31.779945  WARNING xorp_fea:11196 FEA 
fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:408 
nlm_cond_newlink_to_fea_cfg ] WARNING:  MTU was not in rta_array, 
attempting to get it via/sys/class/net/eth0/mtu instead.  Will not print 
this message again.
[ 2011/09/21 13:36:31.780130  WARNING xorp_fea:11196 FEA 
fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:138 
try_read_config_one ] NOTE:  Netlink get single network device works on 
this system.
[ 2011/09/21 13:36:31.781129  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: rtrmgr ()
[ 2011/09/21 13:36:37.784327  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: firewall (xorp_fea)
[ 2011/09/21 13:36:37.785348  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: fea (xorp_fea)
[ 2011/09/21 13:36:37.785697  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: mfea4 (xorp_fea)
[ 2011/09/21 13:36:37.787013  INFO xorp_fea:11196 MFEA 
fea/mfea_node.cc:940 add_vif ] Interface added: Vif[eth0] pif_index: 2 
vif_index: 0 addr: 128.142.172.31 subnet: 128.142.0.0/16 broadcast: 
128.142.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST 
UNDERLYING_VIF_UP MTU: 1500
[ 2011/09/21 13:36:37.787056  INFO xorp_fea:11196 MFEA 
fea/mfea_node.cc:940 add_vif ] Interface added: Vif[tun0] pif_index: 17 
vif_index: 1 addr: 192.168.1.1 subnet: 192.168.1.1/32 broadcast: 0.0.0.0 
peer: 192.168.1.2 Flags: P2P MULTICAST UNDERLYING_VIF_UP MTU: 1476
[ 2011/09/21 13:36:37.787138  WARNING xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:310 IoIpSocket ] Registering with 
iftree: pushed-config
[ 2011/09/21 13:36:37.787248  ERROR xorp_fea:11196 MFEA 
fea/mfea_mrouter.cc:844 start_mrt ] MROUTE:  WARNING:  
setsockopt(MRT_INIT) does not support multiple routing tables:: Protocol 
not available
[ 2011/09/21 13:36:37.787310  INFO xorp_fea:11196 MFEA 
fea/mfea_node.cc:217 final_start ] MFEA started
[ 2011/09/21 13:36:37.787945  INFO xorp_fea:11196 MFEA 
fea/mfea_vif.cc:217 enable ] MfeaVif: Interface enable Vif[eth0] 
pif_index: 2 vif_index: 0 addr: 128.142.172.31 subnet: 128.142.0.0/16 
broadcast: 128.142.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST 
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 DISABLED
[ 2011/09/21 13:36:37.801700  INFO xorp_fea:11196 MFEA 
fea/mfea_vif.cc:136 start ] Interface started: Vif[eth0] pif_index: 2 
vif_index: 0 addr: 128.142.172.31 subnet: 128.142.0.0/16 broadcast: 
128.142.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST 
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2011/09/21 13:36:37.801755  INFO xorp_fea:11196 MFEA 
fea/mfea_node.cc:940 add_vif ] Interface added: Vif[register_vif] 
pif_index: 2 vif_index: 2 addr: 128.142.172.31 subnet: 128.142.172.31/32 
broadcast: 128.142.172.31 peer: 0.0.0.0 Flags: PIM_REGISTER 
UNDERLYING_VIF_UP MTU: 1500
[ 2011/09/21 13:36:37.802126  INFO xorp_fea:11196 MFEA 
fea/mfea_vif.cc:217 enable ] MfeaVif: Interface enable Vif[tun0] 
pif_index: 17 vif_index: 1 addr: 192.168.1.1 subnet: 192.168.1.1/32 
broadcast: 0.0.0.0 peer: 192.168.1.2 Flags: P2P MULTICAST 
UNDERLYING_VIF_UP MTU: 1476 DOWN IPv4 DISABLED
[ 2011/09/21 13:36:37.815636  INFO xorp_fea:11196 MFEA 
fea/mfea_vif.cc:136 start ] Interface started: Vif[tun0] pif_index: 17 
vif_index: 1 addr: 192.168.1.1 subnet: 192.168.1.1/32 broadcast: 0.0.0.0 
peer: 192.168.1.2 Flags: P2P MULTICAST UNDERLYING_VIF_UP MTU: 1476 UP 
IPv4 ENABLED
[ 2011/09/21 13:36:37.815900  INFO xorp_fea:11196 MFEA 
fea/mfea_vif.cc:217 enable ] MfeaVif: Interface enable Vif[register_vif] 
pif_index: 2 vif_index: 2 addr: 128.142.172.31 subnet: 128.142.172.31/32 
broadcast: 128.142.172.31 peer: 0.0.0.0 Flags: PIM_REGISTER 
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 DISABLED
[ 2011/09/21 13:36:37.833905  INFO xorp_fea:11196 MFEA 
fea/mfea_vif.cc:136 start ] Interface started: Vif[register_vif] 
pif_index: 2 vif_index: 2 addr: 128.142.172.31 subnet: 128.142.172.31/32 
broadcast: 128.142.172.31 peer: 0.0.0.0 Flags: PIM_REGISTER 
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2011/09/21 13:36:37.834711  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: rib (xorp_rib)
[ 2011/09/21 13:36:37.835139  WARNING xorp_rtrmgr:11195 XrlFinderTarget 
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for 
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"rib" does not exist or is not enabled.
[ 2011/09/21 13:36:37.835274  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve 
failed  retries: 0  max_retries: 30
[ 2011/09/21 13:36:38.837505  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: igmp (xorp_igmp)
[ 2011/09/21 13:36:38.837927  WARNING xorp_rtrmgr:11195 XrlFinderTarget 
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for 
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"IGMP" does not exist or is not enabled.
[ 2011/09/21 13:36:38.838070  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve 
failed  retries: 0  max_retries: 30
[ 2011/09/21 13:36:38.867662 INFO xorp_igmp MLD6IGMP ] Protocol enabled
[ 2011/09/21 13:36:38.867764 INFO xorp_igmp MLD6IGMP ] CLI enabled
[ 2011/09/21 13:36:38.867919 INFO xorp_igmp MLD6IGMP ] CLI started
[ 2011/09/21 13:36:38.977528  TRACE xorp_fea:11196 MFEA +1625 
fea/mfea_node.cc signal_message_recv ] RX kernel signal: message_type = 
1 vif_index = 0 src = 128.142.172.8 dst = 239.192.172.232
[ 2011/09/21 13:36:39.881377 INFO xorp_igmp MLD6IGMP ] Protocol started
[ 2011/09/21 13:36:39.881615 INFO xorp_igmp MLD6IGMP ] mld6igmp: 
Interface added: Vif[eth0] pif_index: 2 vif_index: 0 addr: 
128.142.172.31 subnet: 128.142.0.0/16 broadcast: 128.142.255.255 peer: 
0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500
[ 2011/09/21 13:36:39.881689 INFO xorp_igmp MLD6IGMP ] mld6igmp: 
Interface added: Vif[tun0] pif_index: 17 vif_index: 1 addr: 192.168.1.1 
subnet: 192.168.1.1/32 broadcast: 0.0.0.0 peer: 192.168.1.2 Flags: P2P 
MULTICAST UNDERLYING_VIF_UP MTU: 1476
[ 2011/09/21 13:36:40.841570 INFO xorp_igmp MLD6IGMP ] Interface 
enabled: Vif[eth0] pif_index: 2 vif_index: 0 addr: 128.142.172.31 
subnet: 128.142.0.0/16 broadcast: 128.142.255.255 peer: 0.0.0.0 Flags: 
MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2011/09/21 13:36:40.844974 INFO xorp_igmp MLD6IGMP ] Interface 
started: Vif[eth0] pif_index: 2 vif_index: 0 addr: 128.142.172.31 
subnet: 128.142.0.0/16 broadcast: 128.142.255.255 peer: 0.0.0.0 Flags: 
MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2011/09/21 13:36:40.845161 INFO xorp_igmp MLD6IGMP ] Interface 
enabled: Vif[tun0] pif_index: 17 vif_index: 1 addr: 192.168.1.1 subnet: 
192.168.1.1/32 broadcast: 0.0.0.0 peer: 192.168.1.2 Flags: P2P MULTICAST 
UNDERLYING_VIF_UP MTU: 1476 DOWN IPv4 ENABLED
[ 2011/09/21 13:36:40.846725  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:878 findOrCreateInputSocket ] 
Successfully bound socket: 48 to interface: eth0  input sockets size: 1
[ 2011/09/21 13:36:40.846761  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.1 on interface eth0 vif eth0  socket: 48
[ 2011/09/21 13:36:40.847390 INFO xorp_igmp MLD6IGMP ] Interface 
started: Vif[tun0] pif_index: 17 vif_index: 1 addr: 192.168.1.1 subnet: 
192.168.1.1/32 broadcast: 0.0.0.0 peer: 192.168.1.2 Flags: P2P MULTICAST 
UNDERLYING_VIF_UP MTU: 1476 UP IPv4 ENABLED
[ 2011/09/21 13:36:40.848178  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: pimsm4 
(xorp_pimsm4)
[ 2011/09/21 13:36:40.848589  WARNING xorp_rtrmgr:11195 XrlFinderTarget 
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for 
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"PIMSM_4" does not exist or is not enabled.
[ 2011/09/21 13:36:40.848868  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve 
failed  retries: 0  max_retries: 30
[ 2011/09/21 13:36:40.859460  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.2 on interface eth0 vif eth0  socket: 48
[ 2011/09/21 13:36:40.868158  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.22 on interface eth0 vif eth0  socket: 48
[ 2011/09/21 13:36:40.868740 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.2 on vif eth0
[ 2011/09/21 13:36:40.868817 TRACE xorp_igmp MLD6IGMP ] Notify routing 
add membership for (0.0.0.0, 224.0.0.2) on vif eth0
[ 2011/09/21 13:36:40.868861 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.2 on vif eth0
[ 2011/09/21 13:36:40.868913 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.22 on vif eth0
[ 2011/09/21 13:36:40.868935 TRACE xorp_igmp MLD6IGMP ] Notify routing 
add membership for (0.0.0.0, 224.0.0.22) on vif eth0
[ 2011/09/21 13:36:40.868966 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.22 on vif eth0
[ 2011/09/21 13:36:40.869335 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_MEMBERSHIP_QUERY from 128.142.172.31 to 
224.0.0.1 on vif eth0
[ 2011/09/21 13:36:40.869392 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_MEMBERSHIP_QUERY from 128.142.172.31 to 
224.0.0.1 on vif eth0
[ 2011/09/21 13:36:40.869502  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:878 findOrCreateInputSocket ] 
Successfully bound socket: 50 to interface: tun0  input sockets size: 2
[ 2011/09/21 13:36:40.869521  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.1 on interface tun0 vif tun0  socket: 50
[ 2011/09/21 13:36:40.878390  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.2 on interface tun0 vif tun0  socket: 50
[ 2011/09/21 13:36:40.888157  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.22 on interface tun0 vif tun0  socket: 50
[ 2011/09/21 13:36:40.986690 INFO xorp_pimsm4 PIM ] Protocol enabled
[ 2011/09/21 13:36:40.986785 INFO xorp_pimsm4 PIM ] CLI enabled
[ 2011/09/21 13:36:40.986914 INFO xorp_pimsm4 PIM ] CLI started
[ 2011/09/21 13:36:41.601680 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.8 to 
239.192.172.232 on vif eth0
[ 2011/09/21 13:36:41.601716 TRACE xorp_igmp MLD6IGMP ] Notify routing 
add membership for (0.0.0.0, 239.192.172.232) on vif eth0
[ 2011/09/21 13:36:41.900076 INFO xorp_pimsm4 PIM ] Protocol started
[ 2011/09/21 13:36:41.900411 INFO xorp_pimsm4 PIM ] Interface added: 
Vif[eth0] pif_index: 2 vif_index: 0 addr: 128.142.172.31 subnet: 
128.142.0.0/16 broadcast: 128.142.255.255 peer: 0.0.0.0 Flags: MULTICAST 
BROADCAST UNDERLYING_VIF_UP MTU: 1500
[ 2011/09/21 13:36:41.900570 INFO xorp_pimsm4 PIM ] Interface added: 
Vif[register_vif] pif_index: 0 vif_index: 2 addr: 128.142.172.31 subnet: 
128.142.172.31/32 broadcast: 0.0.0.0 peer: 0.0.0.0 Flags: PIM_REGISTER 
UNDERLYING_VIF_UP MTU: 1500
[ 2011/09/21 13:36:41.900799 INFO xorp_pimsm4 PIM ] Interface added: 
Vif[tun0] pif_index: 17 vif_index: 1 addr: 192.168.1.1 subnet: 
192.168.1.1/32 broadcast: 0.0.0.0 peer: 192.168.1.2 Flags: P2P MULTICAST 
UNDERLYING_VIF_UP MTU: 1476
[ 2011/09/21 13:36:42.852252 INFO xorp_pimsm4 PIM ] Interface enabled: 
Vif[eth0] pif_index: 2 vif_index: 0 addr: 128.142.172.31 subnet: 
128.142.0.0/16 broadcast: 128.142.255.255 peer: 0.0.0.0 Flags: MULTICAST 
BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2011/09/21 13:36:42.854818 INFO xorp_pimsm4 PIM ] Interface started: 
Vif[eth0] pif_index: 2 vif_index: 0 addr: 128.142.172.31 subnet: 
128.142.0.0/16 broadcast: 128.142.255.255 peer: 0.0.0.0 Flags: MULTICAST 
BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2011/09/21 13:36:42.855007 INFO xorp_pimsm4 PIM ] Interface enabled: 
Vif[tun0] pif_index: 17 vif_index: 1 addr: 192.168.1.1 subnet: 
192.168.1.1/32 broadcast: 0.0.0.0 peer: 192.168.1.2 Flags: P2P MULTICAST 
UNDERLYING_VIF_UP MTU: 1476 DOWN IPv4 ENABLED
[ 2011/09/21 13:36:42.855630  WARNING xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:310 IoIpSocket ] Registering with 
iftree: pushed-config
[ 2011/09/21 13:36:42.856976 INFO xorp_pimsm4 PIM ] Interface started: 
Vif[tun0] pif_index: 17 vif_index: 1 addr: 192.168.1.1 subnet: 
192.168.1.1/32 broadcast: 0.0.0.0 peer: 192.168.1.2 Flags: P2P MULTICAST 
UNDERLYING_VIF_UP MTU: 1476 UP IPv4 ENABLED
[ 2011/09/21 13:36:42.857690 INFO xorp_pimsm4 PIM ] Interface enabled: 
Vif[register_vif] pif_index: 0 vif_index: 2 addr: 128.142.172.31 subnet: 
128.142.172.31/32 broadcast: 0.0.0.0 peer: 0.0.0.0 Flags: PIM_REGISTER 
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2011/09/21 13:36:42.858157 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) 
= true: RP for group 239.192.172.232: not found
[ 2011/09/21 13:36:42.858529  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:878 findOrCreateInputSocket ] 
Successfully bound socket: 57 to interface: eth0  input sockets size: 1
[ 2011/09/21 13:36:42.858782 INFO xorp_pimsm4 PIM ] Interface started: 
Vif[register_vif] pif_index: 0 vif_index: 2 addr: 128.142.172.31 subnet: 
128.142.172.31/32 broadcast: 0.0.0.0 peer: 0.0.0.0 Flags: PIM_REGISTER 
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2011/09/21 13:36:42.860296 INFO xorp_pimsm4 PIM ] Bootstrap mechanism 
enabled
[ 2011/09/21 13:36:42.862668 INFO xorp_pimsm4 PIM ] Bootstrap mechanism 
started
[ 2011/09/21 13:36:42.863258  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: policy 
(xorp_policy)
[ 2011/09/21 13:36:42.863759  WARNING xorp_rtrmgr:11195 XrlFinderTarget 
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for 
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"policy" does not exist or is not enabled.
[ 2011/09/21 13:36:42.863914  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve 
failed  retries: 0  max_retries: 30
[ 2011/09/21 13:36:42.871902  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.13 on interface eth0 vif eth0  socket: 57
[ 2011/09/21 13:36:42.872117 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:36:42.872156 TRACE xorp_igmp MLD6IGMP ] Notify routing 
add membership for (0.0.0.0, 224.0.0.13) on vif eth0
[ 2011/09/21 13:36:42.872208 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:36:42.872587  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:878 findOrCreateInputSocket ] 
Successfully bound socket: 58 to interface: tun0  input sockets size: 2
[ 2011/09/21 13:36:42.882931  INFO xorp_fea:11196 FEA 
fea/data_plane/io/io_ip_socket.cc:607 join_multicast_group ] Joined IPv4 
group: 224.0.0.13 on interface tun0 vif tun0  socket: 58
[ 2011/09/21 13:36:43.866053  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/module_manager.cc:100 execute ] Executing module: fib2mrib 
(xorp_fib2mrib)
[ 2011/09/21 13:36:43.866554  WARNING xorp_rtrmgr:11195 XrlFinderTarget 
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for 
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"fib2mrib" does not exist or is not enabled.
[ 2011/09/21 13:36:43.866693  WARNING xorp_rtrmgr:11195 RTRMGR 
rtrmgr/task.cc:215 xrl_done ] Failed to receive reply, code: 201 Resolve 
failed  retries: 0  max_retries: 30
[ 2011/09/21 13:36:43.932237 TRACE xorp_pimsm4 PIM ] pim_send: TX 
PIM_HELLO from 128.142.172.31 to 224.0.0.13 on vif eth0
[ 2011/09/21 13:36:44.869467  INFO xorp_rtrmgr:11195 RTRMGR 
rtrmgr/task.cc:2242 run_task ] No more tasks to run
[ 2011/09/21 13:36:44.980136 TRACE xorp_pimsm4 PIM ] pim_send: TX 
PIM_HELLO from 192.168.1.1 to 224.0.0.13 on vif tun0
[ 2011/09/21 13:36:46.850232 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:36:46.850299 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:36:47.18127 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:36:47.18184 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:36:48.421892 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.22 on vif eth0
[ 2011/09/21 13:36:48.421950 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.22 on vif eth0
[ 2011/09/21 13:36:48.523875 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
239.192.106.130 on vif eth0
[ 2011/09/21 13:36:48.523918 TRACE xorp_igmp MLD6IGMP ] Notify routing 
add membership for (0.0.0.0, 239.192.106.130) on vif eth0
[ 2011/09/21 13:36:48.523970 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
239.192.106.130 on vif eth0
[ 2011/09/21 13:36:48.524058 TRACE xorp_pimsm4 PIM ] Add membership for 
(0.0.0.0, 239.192.106.130) on vif eth0
[ 2011/09/21 13:36:49.306540  TRACE xorp_fea:11196 MFEA +1625 
fea/mfea_node.cc signal_message_recv ] RX kernel signal: message_type = 
1 vif_index = 0 src = 128.142.172.31 dst = 239.192.106.130
[ 2011/09/21 13:36:49.307563 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal 
from MFEA_4: vif_index = 0 src = 128.142.172.31 dst = 239.192.106.130
[ 2011/09/21 13:36:49.307691 TRACE xorp_pimsm4 PIM ] pim_send: TX 
PIM_ASSERT from 128.142.172.31 to 224.0.0.13 on vif eth0
[ 2011/09/21 13:36:49.307767 TRACE xorp_pimsm4 PIM ] Add MFC entry: 
(128.142.172.31, 239.192.106.130) iif = 0 olist = ... 
olist_disable_wrongvif = OOO
[ 2011/09/21 13:36:49.307790 TRACE xorp_pimsm4 PIM ] Add dataflow 
monitor: source = 128.142.172.31 group = 239.192.106.130 
threshold_interval_sec = 210 threshold_interval_usec = 0 
threshold_packets = 0 threshold_bytes = 0 is_threshold_in_packets = 1 
is_threshold_in_bytes = 0 is_geq_upcall = 0 is_leq_upcall = 1
[ 2011/09/21 13:36:49.308565  TRACE xorp_fea:11196 MFEA +1570 
fea/mfea_mrouter.cc add_mfc ] Add MFC entry: (128.142.172.31, 
239.192.106.130) iif = 0 olist = ...
[ 2011/09/21 13:36:49.456733 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.2 on vif eth0
[ 2011/09/21 13:36:49.456791 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.2 on vif eth0
[ 2011/09/21 13:36:50.405391  TRACE xorp_fea:11196 MFEA +1625 
fea/mfea_node.cc signal_message_recv ] RX kernel signal: message_type = 
1 vif_index = 0 src = 128.142.172.8 dst = 239.192.172.232
[ 2011/09/21 13:36:50.405566 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal 
from MFEA_4: vif_index = 0 src = 128.142.172.8 dst = 239.192.172.232
[ 2011/09/21 13:36:50.405648 TRACE xorp_pimsm4 PIM ] pim_send: TX 
PIM_ASSERT from 128.142.172.31 to 224.0.0.13 on vif eth0
[ 2011/09/21 13:36:50.405701 TRACE xorp_pimsm4 PIM ] Add MFC entry: 
(128.142.172.8, 239.192.172.232) iif = 0 olist = ..O 
olist_disable_wrongvif = OO.
[ 2011/09/21 13:36:50.405718 TRACE xorp_pimsm4 PIM ] Add dataflow 
monitor: source = 128.142.172.8 group = 239.192.172.232 
threshold_interval_sec = 210 threshold_interval_usec = 0 
threshold_packets = 0 threshold_bytes = 0 is_threshold_in_packets = 1 
is_threshold_in_bytes = 0 is_geq_upcall = 0 is_leq_upcall = 1
[ 2011/09/21 13:36:50.406087  TRACE xorp_fea:11196 MFEA +1570 
fea/mfea_mrouter.cc add_mfc ] Add MFC entry: (128.142.172.8, 
239.192.172.232) iif = 0 olist = ..O
[ 2011/09/21 13:37:12.94914 TRACE xorp_igmp MLD6IGMP ] TX 
IGMP_MEMBERSHIP_QUERY from 128.142.172.31 to 224.0.0.1
[ 2011/09/21 13:37:12.95315 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_MEMBERSHIP_QUERY from 128.142.172.31 to 
224.0.0.1 on vif eth0
[ 2011/09/21 13:37:12.95365 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_MEMBERSHIP_QUERY from 128.142.172.31 to 
224.0.0.1 on vif eth0
[ 2011/09/21 13:37:12.97815 TRACE xorp_igmp MLD6IGMP ] TX 
IGMP_MEMBERSHIP_QUERY from 192.168.1.1 to 224.0.0.1
[ 2011/09/21 13:37:12.874618 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.8 to 
239.192.172.232 on vif eth0
[ 2011/09/21 13:37:13.932620 TRACE xorp_pimsm4 PIM ] pim_send: TX 
PIM_HELLO from 128.142.172.31 to 224.0.0.13 on vif eth0
[ 2011/09/21 13:37:14.188862 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:37:14.188920 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.13 on vif eth0
[ 2011/09/21 13:37:14.980444 TRACE xorp_pimsm4 PIM ] pim_send: TX 
PIM_HELLO from 192.168.1.1 to 224.0.0.13 on vif tun0
[ 2011/09/21 13:37:16.401527 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.2 on vif eth0
[ 2011/09/21 13:37:16.401586 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.2 on vif eth0
[ 2011/09/21 13:37:18.511193 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.22 on vif eth0
[ 2011/09/21 13:37:18.511251 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
224.0.0.22 on vif eth0
[ 2011/09/21 13:37:19.863977 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
239.192.106.130 on vif eth0
[ 2011/09/21 13:37:19.864034 TRACE xorp_igmp MLD6IGMP ] 
mld6igmp_process:  RX IGMP_V2_MEMBERSHIP_REPORT from 128.142.172.31 to 
239.192.106.130 on vif eth0


I've spent one week to understand the reason why machines don't see each 
other, but now I am close to give up. I would be very appriciated for help.

Thank you.




From greg.johnson at fecinc.com  Wed Sep 21 06:08:33 2011
From: greg.johnson at fecinc.com (Greg Johnson)
Date: Wed, 21 Sep 2011 08:08:33 -0500
Subject: [Xorp-users] PIM SM Register Messages
Message-ID: <F0E59BA523B932449F9D1FD590186689313C4D62C8@fecrp01>

I have a question about PIM-SM register messages from the DR that is on the same subnet as the sender. Is it possible for the DR to not be on the same subnet as the sender and still tunnel register messages towards the RP? So for example if I don't control the network with the sources (video encoders) and they are using something like PIM-Dense-Mode to flood the traffic into my network (one hop away), can I define my interfaces as PIM-SM and create my own RP even though I do not have any router directly connected to the sources?  How does the DR know that the source is directly connected or not?....by IP subnet?

Thanks,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110921/7d8036c9/attachment.html 

From greearb at candelatech.com  Wed Sep 21 10:31:00 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 21 Sep 2011 10:31:00 -0700
Subject: [Xorp-users] Xorp 1.8.4 is released.
Message-ID: <4E7A1F54.7090008@candelatech.com>

I have uploaded binaries & source code to www.xorp.org.

The downloads link points to xorp.org now instead of SourceForge,
but I put the windows binary and source code snapshot on sourceforge
and github as well, just in case someone prefers that.

Generally, 1.8.4 is mostly a bug-fix release.

Here's the release notes highlights:

    *  Add async-XRL support, from Steven Simpson

    *  Fix bug in deleting non-VLAN interface.  Commit would fail
       because the code would attempt to remove the interface from
       the kernel and fail.

    *  Fix BSD related crash when adding interface with same ifindex
       as a previous interface.  OpenBSD has the nasty habit of re-using
       the ifindex when creating/deleting virtual interfaces.

    *  Fix multicast bug that totally breaks XORP multicast on recent
       Linux kernels.  The problem is that I chose the wrong default
       multicast routing table (254, instead of 253 as it should be).
       So, if users don't specify a routing table, it pokes routes into
       the wrong table.  This wasn't caught in my testing because I always
       explicitly set the routing table ID.

    *  Add some env variable controlled debugging to the libxorp and libxipc
       logic for better debugging of xrls and the event loop.

Full release notes and change log are available here:

http://www.xorp.org/releases/1.8.4/docs/RELEASE_NOTES


Please post to the list if you have a chance to try this out,
and let us know how it works for you.

Thanks,
Ben

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


From greearb at candelatech.com  Wed Sep 21 10:33:51 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 21 Sep 2011 10:33:51 -0700
Subject: [Xorp-users] How does the OSPF packet be handled when using
 kernel level Click as the FEA?
In-Reply-To: <4E799284.2050702@bupt.edu.cn>
References: <4E799284.2050702@bupt.edu.cn>
Message-ID: <4E7A1FFF.40908@candelatech.com>

On 09/21/2011 12:30 AM, ?? wrote:
> Hi,i'm new to xorp.
> I'm using xorp 1.6,with kernel level Click being its FEA.
> And I have some questions. Needs help^_^
>
> 1.when an Ospf packet arrives at the interface of the click
> router ,which part of the click is responsible for handling
> the ospf packet? Is it directly captured by the xorp on the
> very interface or is it firstly sent to an element within
> the click and then sent to the xorp by the click element?
>
> 2.When the xorp generates ospf packet,how does it send the
> packet out of Click?

I'm not sure about click, but for regular xorp usage, the
OSFP protocol packets are handled by xorp, which configures
routes in the kernel as needed.  The kernel handles
actually routing the packets.

This is true for all protocols, except that in some cases,
xorp directly handles routed multicast packets.

Patches & documentation to get click working in the current xorp versions
are welcome, by the way.

Thanks,
Ben

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


From greearb at candelatech.com  Wed Sep 21 11:05:49 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 21 Sep 2011 11:05:49 -0700
Subject: [Xorp-users] Who maintains the xorp freshmeat entry?
Message-ID: <4E7A277D.9060601@candelatech.com>

If you are on the list, please send me email.  I'd like to
make sure I send you email when I do releases so you can
update the freshmeat page.

Thanks,
Ben

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


From greearb at candelatech.com  Thu Sep 22 12:51:21 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Sep 2011 12:51:21 -0700
Subject: [Xorp-users] Multicast over GRE tunnel with Xorp.
In-Reply-To: <4E79CF10.10803@gmail.com>
References: <4E79CF10.10803@gmail.com>
Message-ID: <4E7B91B9.6080306@candelatech.com>

On 09/21/2011 04:48 AM, Vladimir Glafirov wrote:
> Dear Xorp users.
>
> I am really new in Linux routing.
>
> I am trying to setup multicast routing through GRE tunnel on RHEL5
> (2.6.18 kernel) with xorp.

Someone just opened a bug with some good details.  Seems
GRE tunnels have their IPs messed up by xorp for some reason.

http://www.xorp.org/bugzilla/show_bug.cgi?id=102

Can you check to see if your system shows similar
symptoms?

Thanks,
Ben

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


From vglafirov at gmail.com  Fri Sep 23 05:32:28 2011
From: vglafirov at gmail.com (Vladimir Glafirov)
Date: Fri, 23 Sep 2011 14:32:28 +0200
Subject: [Xorp-users] Multicast over GRE tunnel with Xorp.
In-Reply-To: <4E7B91B9.6080306@candelatech.com>
References: <4E79CF10.10803@gmail.com> <4E7B91B9.6080306@candelatech.com>
Message-ID: <4E7C7C5C.4000604@gmail.com>

On 09/22/2011 09:51 PM, Ben Greear wrote:
> On 09/21/2011 04:48 AM, Vladimir Glafirov wrote:
>> Dear Xorp users.
>>
>> I am really new in Linux routing.
>>
>> I am trying to setup multicast routing through GRE tunnel on RHEL5
>> (2.6.18 kernel) with xorp.
>
> Someone just opened a bug with some good details.  Seems
> GRE tunnels have their IPs messed up by xorp for some reason.
>
> http://www.xorp.org/bugzilla/show_bug.cgi?id=102
>
> Can you check to see if your system shows similar
> symptoms?

Ben.

Yes. I've also noticed same behavior of xorp 1.8.3 with GRE tunnel. 
Could it be fixed?

Thank you.

Vladimir.




>
> Thanks,
> Ben
>


From greearb at candelatech.com  Fri Sep 23 09:14:07 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Sep 2011 09:14:07 -0700
Subject: [Xorp-users] Multicast over GRE tunnel with Xorp.
In-Reply-To: <4E7C7C5C.4000604@gmail.com>
References: <4E79CF10.10803@gmail.com> <4E7B91B9.6080306@candelatech.com>
	<4E7C7C5C.4000604@gmail.com>
Message-ID: <4E7CB04F.1080909@candelatech.com>

On 09/23/2011 05:32 AM, Vladimir Glafirov wrote:
> On 09/22/2011 09:51 PM, Ben Greear wrote:
>> On 09/21/2011 04:48 AM, Vladimir Glafirov wrote:
>>> Dear Xorp users.
>>>
>>> I am really new in Linux routing.
>>>
>>> I am trying to setup multicast routing through GRE tunnel on RHEL5
>>> (2.6.18 kernel) with xorp.
>>
>> Someone just opened a bug with some good details. Seems
>> GRE tunnels have their IPs messed up by xorp for some reason.
>>
>> http://www.xorp.org/bugzilla/show_bug.cgi?id=102
>>
>> Can you check to see if your system shows similar
>> symptoms?
>
> Ben.
>
> Yes. I've also noticed same behavior of xorp 1.8.3 with GRE tunnel. Could it be fixed?

I'm pretty sure I can fix it quickly, but first I have to reproduce
it on a machine I can debug on.  If someone has some scripts to set up
a GRE tunnel between two linux boxes, please post them...

Thanks,
Ben

>
> Thank you.
>
> Vladimir.
>
>
>
>
>>
>> Thanks,
>> Ben
>>


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


From greearb at candelatech.com  Fri Sep 23 10:44:00 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Sep 2011 10:44:00 -0700
Subject: [Xorp-users] Multicast over GRE tunnel with Xorp.
In-Reply-To: <4E7CB04F.1080909@candelatech.com>
References: <4E79CF10.10803@gmail.com> <4E7B91B9.6080306@candelatech.com>
	<4E7C7C5C.4000604@gmail.com> <4E7CB04F.1080909@candelatech.com>
Message-ID: <4E7CC560.1020708@candelatech.com>

On 09/23/2011 09:14 AM, Ben Greear wrote:
> On 09/23/2011 05:32 AM, Vladimir Glafirov wrote:
>> On 09/22/2011 09:51 PM, Ben Greear wrote:
>>> On 09/21/2011 04:48 AM, Vladimir Glafirov wrote:
>>>> Dear Xorp users.
>>>>
>>>> I am really new in Linux routing.
>>>>
>>>> I am trying to setup multicast routing through GRE tunnel on RHEL5
>>>> (2.6.18 kernel) with xorp.
>>>
>>> Someone just opened a bug with some good details. Seems
>>> GRE tunnels have their IPs messed up by xorp for some reason.
>>>
>>> http://www.xorp.org/bugzilla/show_bug.cgi?id=102
>>>
>>> Can you check to see if your system shows similar
>>> symptoms?
>>
>> Ben.
>>
>> Yes. I've also noticed same behavior of xorp 1.8.3 with GRE tunnel. Could it be fixed?
>
> I'm pretty sure I can fix it quickly, but first I have to reproduce
> it on a machine I can debug on.  If someone has some scripts to set up
> a GRE tunnel between two linux boxes, please post them...

I think I've reproduced the problem on my systems...will start debugging
and hopefully have something for you guys to test soon.

Thanks,
Ben

>
> Thanks,
> Ben
>
>>
>> Thank you.
>>
>> Vladimir.
>>
>>
>>
>>
>>>
>>> Thanks,
>>> Ben
>>>
>
>


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


From p_latini at hotmail.com  Fri Sep 23 13:34:11 2011
From: p_latini at hotmail.com (Patricio Latini)
Date: Fri, 23 Sep 2011 17:34:11 -0300
Subject: [Xorp-users] Mcast issues
In-Reply-To: <4E77831B.9010208@candelatech.com>
References: <017601cc747a$ba95bfb0$2fc13f10$@maine.edu>
	<COL117-DS1AEC55A76BBC826214939F7060@phx.gbl>
	<4E737565.6060206@candelatech.com>
	<COL117-DS16D2C22A364DD9545DD012F7060@phx.gbl>
	<4E77831B.9010208@candelatech.com>
Message-ID: <COL117-DS10A1FC53F25B60D8EBB441F70F0@phx.gbl>

Ben:
Just wanted to let you know that for some reason after compiling the latest
version on the SVN with the latest fixes, the problem disappeared and joins
are accepted on all the interfaces.

Thanks

Patricio

-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Monday, September 19, 2011 3:00 PM
To: Patricio Latini
Cc: 'Garry Peirce'; xorp-users at xorp.org
Subject: Re: [Xorp-users] Mcast issues

On 09/16/2011 12:13 PM, Patricio Latini wrote:
> I have upgraded to 1.8.4 and still have the traffic being flooded to 
> only one interface.

We ran some tests here, and IPv4 multicast routing is working for us.

Except that on route-flap, we are seeing a crash in xorp_pimsm4.  We hope to
have that fixed today as we need it for our own product.

Also, you might try making sure that your VLANs all have unique MAC
addresses.  I'm not sure that is required, but often it helps with subtle
issues.

Thanks,
Ben

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



From vglafirov at gmail.com  Fri Sep 23 14:22:24 2011
From: vglafirov at gmail.com (Vladimir Glafirov)
Date: Fri, 23 Sep 2011 23:22:24 +0200
Subject: [Xorp-users] Multicast over GRE tunnel with Xorp.
In-Reply-To: <4E7CB04F.1080909@candelatech.com>
References: <4E79CF10.10803@gmail.com> <4E7B91B9.6080306@candelatech.com>
	<4E7C7C5C.4000604@gmail.com> <4E7CB04F.1080909@candelatech.com>
Message-ID: <4E7CF890.3090901@gmail.com>

On 9/23/2011 6:14 PM, Ben Greear wrote:
> On 09/23/2011 05:32 AM, Vladimir Glafirov wrote:
>> On 09/22/2011 09:51 PM, Ben Greear wrote:
>>> On 09/21/2011 04:48 AM, Vladimir Glafirov wrote:
>>>> Dear Xorp users.
>>>>
>>>> I am really new in Linux routing.
>>>>
>>>> I am trying to setup multicast routing through GRE tunnel on RHEL5
>>>> (2.6.18 kernel) with xorp.
>>>
>>> Someone just opened a bug with some good details. Seems
>>> GRE tunnels have their IPs messed up by xorp for some reason.
>>>
>>> http://www.xorp.org/bugzilla/show_bug.cgi?id=102
>>>
>>> Can you check to see if your system shows similar
>>> symptoms?
>>
>> Ben.
>>
>> Yes. I've also noticed same behavior of xorp 1.8.3 with GRE tunnel. 
>> Could it be fixed?
>
> I'm pretty sure I can fix it quickly, but first I have to reproduce
> it on a machine I can debug on.  If someone has some scripts to set up
> a GRE tunnel between two linux boxes, please post them...

Hi Ben.

I used ifcfg scripts to create GRE tunnel on my RedHat machine:

--- /etc/sysconfig/network-scripst/ifcfg-tun0 --
DEVICE=tun0
BOOTPROTO=none
ONBOOT=yes
TYPE=GRE
PEER_OUTER_IPADDR=172.18.172.31
PEER_INNER_IPADDR=192.168.2.1
MY_INNER_IPADDR=192.168.1.1
-----------------------------------------------------------


Thank you in advance.
Vladimir.

>
> Thanks,
> Ben
>
>>
>> Thank you.
>>
>> Vladimir.
>>
>>
>>
>>
>>>
>>> Thanks,
>>> Ben
>>>
>
>


From greearb at candelatech.com  Fri Sep 23 14:27:46 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Sep 2011 14:27:46 -0700
Subject: [Xorp-users] Multicast over GRE tunnel with Xorp.
In-Reply-To: <4E7CF890.3090901@gmail.com>
References: <4E79CF10.10803@gmail.com> <4E7B91B9.6080306@candelatech.com>
	<4E7C7C5C.4000604@gmail.com> <4E7CB04F.1080909@candelatech.com>
	<4E7CF890.3090901@gmail.com>
Message-ID: <4E7CF9D2.2020302@candelatech.com>

On 09/23/2011 02:22 PM, Vladimir Glafirov wrote:
> On 9/23/2011 6:14 PM, Ben Greear wrote:
>> On 09/23/2011 05:32 AM, Vladimir Glafirov wrote:
>>> On 09/22/2011 09:51 PM, Ben Greear wrote:
>>>> On 09/21/2011 04:48 AM, Vladimir Glafirov wrote:
>>>>> Dear Xorp users.
>>>>>
>>>>> I am really new in Linux routing.
>>>>>
>>>>> I am trying to setup multicast routing through GRE tunnel on RHEL5
>>>>> (2.6.18 kernel) with xorp.
>>>>
>>>> Someone just opened a bug with some good details. Seems
>>>> GRE tunnels have their IPs messed up by xorp for some reason.
>>>>
>>>> http://www.xorp.org/bugzilla/show_bug.cgi?id=102
>>>>
>>>> Can you check to see if your system shows similar
>>>> symptoms?
>>>
>>> Ben.
>>>
>>> Yes. I've also noticed same behavior of xorp 1.8.3 with GRE tunnel. Could it be fixed?
>>
>> I'm pretty sure I can fix it quickly, but first I have to reproduce
>> it on a machine I can debug on. If someone has some scripts to set up
>> a GRE tunnel between two linux boxes, please post them...
>
> Hi Ben.
>
> I used ifcfg scripts to create GRE tunnel on my RedHat machine:
>
> --- /etc/sysconfig/network-scripst/ifcfg-tun0 --
> DEVICE=tun0
> BOOTPROTO=none
> ONBOOT=yes
> TYPE=GRE
> PEER_OUTER_IPADDR=172.18.172.31
> PEER_INNER_IPADDR=192.168.2.1
> MY_INNER_IPADDR=192.168.1.1
> -----------------------------------------------------------

I just committed something that might fix the problem for you.

Please pull the latest from the github git repository and
see if it works for you.

Thanks,
Ben

>
>
> Thank you in advance.
> Vladimir.
>
>>
>> Thanks,
>> Ben
>>
>>>
>>> Thank you.
>>>
>>> Vladimir.
>>>
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>
>>


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


From JoeCoco at mecnet.net  Tue Sep 27 05:42:16 2011
From: JoeCoco at mecnet.net (Joe Coco)
Date: Tue, 27 Sep 2011 12:42:16 +0000
Subject: [Xorp-users] ospfv3 (1.8.4)
Message-ID: <9513B0D809E3024A85A611E9B3726CA99BF769@MECnetExchange.mecnet.net>

Hello,

Anyone get ospfv3 working with an instance id other than zero?

It appears, no matter what you set it to, the LSA packets set the instance id to zero.

>From what I understand, Zero should be the default if none is set, but it appears other products (Cisco for example) allow you to set the instance id to other than Zero even if only one instance exists.



n  Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110927/6c46c97f/attachment.html 

From 6bone at 6bone.informatik.uni-leipzig.de  Tue Sep 27 22:36:41 2011
From: 6bone at 6bone.informatik.uni-leipzig.de (6bone at 6bone.informatik.uni-leipzig.de)
Date: Wed, 28 Sep 2011 07:36:41 +0200 (CEST)
Subject: [Xorp-users] xorp and netbsd
Message-ID: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>

Hello,

I am trying to compile xorp 1.8.4 at netbsd-5.1 (amd64). Unfortunately I get a 
lot of errors.

Can anyone build a binary package for netbsd-5.1 (amd64) or update the xorp 
version in the pkgsrc tree?


Thank you for your efforts

Regards
Uwe


From greearb at candelatech.com  Wed Sep 28 08:14:20 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 28 Sep 2011 08:14:20 -0700
Subject: [Xorp-users] xorp and netbsd
In-Reply-To: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>
References: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>
Message-ID: <4E8339CC.3020008@candelatech.com>

On 09/27/2011 10:36 PM, 6bone at 6bone.informatik.uni-leipzig.de wrote:
> Hello,
>
> I am trying to compile xorp 1.8.4 at netbsd-5.1 (amd64). Unfortunately I get a
> lot of errors.
>
> Can anyone build a binary package for netbsd-5.1 (amd64) or update the xorp
> version in the pkgsrc tree?

Please post your compile command and the errors you see, for a clean tree.

Thanks,
Ben

>
>
> Thank you for your efforts
>
> Regards
> Uwe
>
> _______________________________________________
> 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 6bone at 6bone.informatik.uni-leipzig.de  Wed Sep 28 23:11:52 2011
From: 6bone at 6bone.informatik.uni-leipzig.de (6bone at 6bone.informatik.uni-leipzig.de)
Date: Thu, 29 Sep 2011 08:11:52 +0200 (CEST)
Subject: [Xorp-users] xorp and netbsd
In-Reply-To: <4E8339CC.3020008@candelatech.com>
References: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>
	<4E8339CC.3020008@candelatech.com>
Message-ID: <Pine.NEB.4.64.1109290804570.3592@6bone.informatik.uni-leipzig.de>

first, a symbolic link to python26 is created

tar xvjf xorp-1.8.4-src.tar.bz2
cd xorp
scons

...
g++ -o obj/x86_64-unknown-netbsd5.1./libxipc/permits.os -c -O1 -g3 -Werror 
-W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align 
-Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 
-D_FORTIFY_SOURCE=0 -Iobj/x86_64-unknown-netbsd5.1. -I. -I. 
libxipc/permits.cc
g++ -o obj/x86_64-unknown-netbsd5.1./libxipc/sockutil.os -c -O1 -g3 
-Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align 
-Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 
-D_FORTIFY_SOURCE=0 -Iobj/x86_64-unknown-netbsd5.1. -I. -I. 
libxipc/sockutil.cc
cc1plus: warnings being treated as errors
libxipc/sockutil.cc: In function 'void get_active_ipv4_addrs(std::vector<IPv4, std::allocator<IPv4> >&)':
libxipc/sockutil.cc:311: warning: deleting 'void*' is undefined
libxipc/sockutil.cc:317: warning: deleting 'void*' is undefined
libxipc/sockutil.cc:334: warning: deleting 'void*' is undefined
scons: *** [obj/x86_64-unknown-netbsd5.1./libxipc/sockutil.os] Error 1
scons: building terminated because of errors.



Regards
Uwe


On Wed, 28 Sep 2011, Ben Greear wrote:

> Date: Wed, 28 Sep 2011 08:14:20 -0700
> From: Ben Greear <greearb at candelatech.com>
> To: 6bone at 6bone.informatik.uni-leipzig.de
> Cc: xorp-users at xorp.org
> Subject: Re: [Xorp-users] xorp and netbsd
> 
> On 09/27/2011 10:36 PM, 6bone at 6bone.informatik.uni-leipzig.de wrote:
>> Hello,
>> 
>> I am trying to compile xorp 1.8.4 at netbsd-5.1 (amd64). Unfortunately I 
>> get a
>> lot of errors.
>> 
>> Can anyone build a binary package for netbsd-5.1 (amd64) or update the xorp
>> version in the pkgsrc tree?
>
> Please post your compile command and the errors you see, for a clean tree.
>
> Thanks,
> Ben
>
>> 
>> 
>> Thank you for your efforts
>> 
>> Regards
>> Uwe
>> 
>> _______________________________________________
>> 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 greearb at candelatech.com  Thu Sep 29 10:51:28 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 29 Sep 2011 10:51:28 -0700
Subject: [Xorp-users] xorp and netbsd
In-Reply-To: <Pine.NEB.4.64.1109290804570.3592@6bone.informatik.uni-leipzig.de>
References: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>
	<4E8339CC.3020008@candelatech.com>
	<Pine.NEB.4.64.1109290804570.3592@6bone.informatik.uni-leipzig.de>
Message-ID: <4E84B020.5000303@candelatech.com>

On 09/28/2011 11:11 PM, 6bone at 6bone.informatik.uni-leipzig.de wrote:
> first, a symbolic link to python26 is created
>
> tar xvjf xorp-1.8.4-src.tar.bz2
> cd xorp
> scons
>
> ...
> g++ -o obj/x86_64-unknown-netbsd5.1./libxipc/permits.os -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align
> -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/x86_64-unknown-netbsd5.1. -I. -I. libxipc/permits.cc
> g++ -o obj/x86_64-unknown-netbsd5.1./libxipc/sockutil.os -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align
> -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/x86_64-unknown-netbsd5.1. -I. -I. libxipc/sockutil.cc
> cc1plus: warnings being treated as errors
> libxipc/sockutil.cc: In function 'void get_active_ipv4_addrs(std::vector<IPv4, std::allocator<IPv4> >&)':
> libxipc/sockutil.cc:311: warning: deleting 'void*' is undefined
> libxipc/sockutil.cc:317: warning: deleting 'void*' is undefined
> libxipc/sockutil.cc:334: warning: deleting 'void*' is undefined
> scons: *** [obj/x86_64-unknown-netbsd5.1./libxipc/sockutil.os] Error 1
> scons: building terminated because of errors.

Please try the latest code from github:

https://github.com/greearb/xorp.ct

I just pushed some patches from the netbsd project
that should fix this and some related issues.

Might yet be other problems, so if it fails to work, send me the logs.

Thanks,
Ben

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


From 6bone at 6bone.informatik.uni-leipzig.de  Thu Sep 29 23:49:01 2011
From: 6bone at 6bone.informatik.uni-leipzig.de (6bone at 6bone.informatik.uni-leipzig.de)
Date: Fri, 30 Sep 2011 08:49:01 +0200 (CEST)
Subject: [Xorp-users] xorp and netbsd
In-Reply-To: <4E84B020.5000303@candelatech.com>
References: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>
	<4E8339CC.3020008@candelatech.com>
	<Pine.NEB.4.64.1109290804570.3592@6bone.informatik.uni-leipzig.de>
	<4E84B020.5000303@candelatech.com>
Message-ID: <Pine.NEB.4.64.1109300845580.3592@6bone.informatik.uni-leipzig.de>

scons

...

g++ -o obj/x86_64-unknown-netbsd5.1./fea/data_plane/ifconfig/ifconfig_vlan_get_linux.os -c -O2 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXORP_BUILDINFO -fPIC -DXRL_PF=120 -DXORP_VERSION=1.8.5-WIP -D_FORTIFY_SOURCE=0 -Iobj/x86_64-unknown-netbsd5.1. -I. -I. fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc
fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc: In member function 'int IfConfigVlanGetLinux::read_config(IfTree&, bool&)':
fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc:200: error: aggregate 
'vlanreq vlanreq' has incomplete type and cannot be defined
fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc:208: error: 
'SIOCGETVLAN' was not declared in this scope
scons: *** 
[obj/x86_64-unknown-netbsd5.1./fea/data_plane/ifconfig/ifconfig_vlan_get_linux.os] 
Error 1
scons: building terminated because of errors.


Regards
Uwe


> I just pushed some patches from the netbsd project
> that should fix this and some related issues.
>
> Might yet be other problems, so if it fails to work, send me the logs.
>
> Thanks,
> Ben
>
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From greearb at candelatech.com  Thu Sep 29 23:59:21 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 29 Sep 2011 23:59:21 -0700
Subject: [Xorp-users] xorp and netbsd
In-Reply-To: <Pine.NEB.4.64.1109300845580.3592@6bone.informatik.uni-leipzig.de>
References: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>
	<4E8339CC.3020008@candelatech.com>
	<Pine.NEB.4.64.1109290804570.3592@6bone.informatik.uni-leipzig.de>
	<4E84B020.5000303@candelatech.com>
	<Pine.NEB.4.64.1109300845580.3592@6bone.informatik.uni-leipzig.de>
Message-ID: <4E8568C9.8060309@candelatech.com>

On 09/29/2011 11:49 PM, 6bone at 6bone.informatik.uni-leipzig.de wrote:
> scons
>
> ...
>
> g++ -o obj/x86_64-unknown-netbsd5.1./fea/data_plane/ifconfig/ifconfig_vlan_get_linux.os -c -O2 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith
> -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXORP_BUILDINFO -fPIC -DXRL_PF=120 -DXORP_VERSION=1.8.5-WIP -D_FORTIFY_SOURCE=0
> -Iobj/x86_64-unknown-netbsd5.1. -I. -I. fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc
> fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc: In member function 'int IfConfigVlanGetLinux::read_config(IfTree&, bool&)':
> fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc:200: error: aggregate 'vlanreq vlanreq' has incomplete type and cannot be defined
> fea/data_plane/ifconfig/ifconfig_vlan_get_linux.cc:208: error: 'SIOCGETVLAN' was not declared in this scope
> scons: *** [obj/x86_64-unknown-netbsd5.1./fea/data_plane/ifconfig/ifconfig_vlan_get_linux.os] Error 1
> scons: building terminated because of errors.

Hrm, does netbsd support VLANs?

The scons logic to detect what type of vlan support to use is
pretty lame right now, so it probably needs help to work on
your system.

Looks like I'll have to get a netbsd system working so I can do at
least some compile testing...

Thanks,
Ben

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


From 6bone at 6bone.informatik.uni-leipzig.de  Fri Sep 30 00:23:24 2011
From: 6bone at 6bone.informatik.uni-leipzig.de (6bone at 6bone.informatik.uni-leipzig.de)
Date: Fri, 30 Sep 2011 09:23:24 +0200 (CEST)
Subject: [Xorp-users] xorp and netbsd
In-Reply-To: <4E8568C9.8060309@candelatech.com>
References: <Pine.NEB.4.64.1109280736170.3592@6bone.informatik.uni-leipzig.de>
	<4E8339CC.3020008@candelatech.com>
	<Pine.NEB.4.64.1109290804570.3592@6bone.informatik.uni-leipzig.de>
	<4E84B020.5000303@candelatech.com>
	<Pine.NEB.4.64.1109300845580.3592@6bone.informatik.uni-leipzig.de>
	<4E8568C9.8060309@candelatech.com>
Message-ID: <Pine.NEB.4.64.1109300918430.3592@6bone.informatik.uni-leipzig.de>

On Thu, 29 Sep 2011, Ben Greear wrote:

>
> Hrm, does netbsd support VLANs?

Yes

> The scons logic to detect what type of vlan support to use is
> pretty lame right now, so it probably needs help to work on
> your system.
>
> Looks like I'll have to get a netbsd system working so I can do at
> least some compile testing...

It sounds like SIOCGETVLAN is not defined. Maybe <net/if_vlanvar.h> is not 
included?


Regards
Uwe


From greearb at candelatech.com  Fri Sep 30 14:16:05 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 30 Sep 2011 14:16:05 -0700
Subject: [Xorp-users] OSPF slow-to-converge bug fixed.
Message-ID: <4E863195.2040304@candelatech.com>

A customer reported some problems with OSPF being very slow to go to
'Full' state.

Turns out, there was a retransmit timer bug in ospf.  It's been there
for a while, probably back to at least 1.7

Anyway, it appears to be fixed now.  So, if anyone had any issues with
OSPF being slow to converge, please try out the top-of-tree and see
if it works better for you.

And of course everyone else is invited to try it as well,
and let me know if you see any funny-ness.

I also attempted some logging optimization.  I believe the old code
would compute all of the logging data arguments (like if you had
XLOG_TRACE(true, "%s", foo.str().c_str()), then foo.str() would be
called even if tracing was disabled).

I think I have that fixed as well.  Should make things perform
better, but at a cost of slightly larger executables.

Thanks,
Ben

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