From greearb at candelatech.com  Thu Apr  1 16:45:23 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 01 Apr 2010 16:45:23 -0700
Subject: [Xorp-hackers] xorp.ct gitweb interface is up
Message-ID: <4BB53013.9050107@candelatech.com>

I configured a gitweb interface to my xorp.ct repo.  So, if anyone
wants to browse patches w/out having to clone the repository using
git, please see:

http://dmz1.candelatech.com/git/gitweb.cgi?p=xorp.ct/.git;a=summary

Thanks,
Ben

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


From greearb at candelatech.com  Mon Apr  5 15:53:57 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 05 Apr 2010 15:53:57 -0700
Subject: [Xorp-hackers] xorp.ct:  VRRP and pim updates
Message-ID: <4BBA6A05.6030602@candelatech.com>

Hello!

I just pushed some patches to xorp.ct repository that were sent to me
to fix up some VRRP issues and conditionally compile more IPv6 logic in PIM.

The VRRP patch fixes at least one assert that could hit in real
life, so anyone using VRRP may find the update useful.

Thanks,
Ben

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


From greearb at candelatech.com  Tue Apr  6 09:52:34 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 06 Apr 2010 09:52:34 -0700
Subject: [Xorp-hackers] xorp.ct gitweb interface is up
In-Reply-To: <y2j4769af411004060839g897fd86bq9f038d2c152199ae@mail.gmail.com>
References: <4BB53013.9050107@candelatech.com>
	<m2j4769af411004060128p849b448ei30c1cd400a2d8d86@mail.gmail.com>
	<4BBB525C.9090904@candelatech.com>
	<y2j4769af411004060839g897fd86bq9f038d2c152199ae@mail.gmail.com>
Message-ID: <4BBB66D2.9000701@candelatech.com>

On 04/06/2010 08:39 AM, Adam Greenhalgh wrote:
> Great, we need to try and kick others into progress, one way is to
> have a list of your patches so we can work them slowly into svn on sf.
> My own opinion is that we should role a version of your patches in and
> sync both trees at that point. We probably need a huge list of patches
> that can be merged by a set of people.

Well, we'll see if anyone volunteers.

If these git commands don't exist, try installing 'git, git-email, git-svn, gitk'
packages.

To make diffs, first find the latest commit from SVN in my tree using
gitk or 'git log'.  I haven't merged the doc changes you made yet, so
it's this one:

50c9ffc966b9a0b88d7359a6c2ec4e24fd7b816f

# Generate patch-set for differences in xorp.ct from that commit (ie SVN)
git format-patch --stat -p --raw --subject-prefix="xorp.ct" -o /tmp/xorp 50c9ffc966b9a0b88d7359a6c2ec4e24fd7b816f


Some of these, or bits of these, have been merged with svn, and some of my
patches modify my previous patches.  I can easily send all of these patches as
email to the mailing-list (or any other email addresses) if you want, but
likely it will piss off more people than it would help to get that big of an
patch bomb on a public list.

You might also be interested in a single patch, which takes all merges
into account:

git diff 50c9ffc966b9a0b88d7359a6c2ec4e24fd7b816f

This generates a 1.4MB patch, btw!

Thanks,
Ben

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


From saurabh.pandya at elitecore.com  Thu Apr  8 23:22:32 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Fri, 09 Apr 2010 11:52:32 +0530
Subject: [Xorp-hackers] [Xorp-users] How can I Update XORP configriation
 on the fly without having xorpsh?
In-Reply-To: <4BBCBC30.3030604@candelatech.com>
References: <47609.203.88.140.119.1270653208.squirrel@203.88.135.194>
	<4BBCBC30.3030604@candelatech.com>
Message-ID: <4BBEC7A8.5010908@elitecore.com>

On 04/07/2010 10:39 PM, Ben Greear wrote:
> On 04/07/2010 08:13 AM, saurabh.pandya at elitecore.com wrote:
>> Dear All,
>>
>> Well I after log message swipe can save around 1.3 MB .. Thanks ben !
>
> Plz post a patch when you have that working properly.  It would be good
> to add a scons argument to compile out logging for folks with
> space constraints.  (Maybe with some sort of option to just compile
> out TRACE and WARNINGs and not errors/fatal?)
>
> I'm pretty sure there is some more ipv6 stuff in fea that could be
> conditionally compiled as well.
>
> Thanks,
> Ben
>
Hi Ben!

Patch attached here.

Log Removal Patch:
One more workaround I had to do else this patch was in SConstruct file !
,  It was to make
compilation without -Werror ( else it gives wraning of unused arguments
and then build fails
as warning being treated as error due to -Werror), if any other good way
(other then change
code of every call) to avoid removing -Wrror , it will work batter.

User Authentication Hack:
Once we discussed about removing of user authentication from xorp (or
hack in someway)
,so that any (root) user can start and configure xorpsh , would you have
any patch for this?
Or I can make patch if you suggest me something.

Thanks in advance,
Saurabh





-------------- next part --------------
A non-text attachment was scrubbed...
Name: LogRemove.patch
Type: text/x-patch
Size: 3004 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100409/4af1f2eb/attachment.bin 

From airkh at email.arizona.edu  Mon Apr 12 23:53:16 2010
From: airkh at email.arizona.edu (Kyuhan Nam)
Date: Mon, 12 Apr 2010 23:53:16 -0700
Subject: [Xorp-hackers] Actual FIB Structure
Message-ID: <003d01cadad5$ff87cea0$fe976be0$@arizona.edu>

Hi, all.

I'm a newbie to see the XORP.

I tried to find the actual structure of FIB.

I traced 'XrlFibClientManager::send_fib_client_add_route' to see where the
actual FIB entries are stored.

 

I saw 'success = _xrl_fea_fib_client.send_add_route4(.' inside, and I found
_xrl_fea_fib_client is  XrlFeaFibClientV0p1Client type.

So, I traced  bool send_add_route4 inside.

 

I saw  'return _sender->send(.)' inside. This process is too iterative, so
I'm lost here L

 

Anyone knows where can I find the FIB table? (tree or list)

 

 

One more question, I found that the RIB is implemented with the tree. What
kind of tree is this? Patricia Trie,Binary trie or other types?

 

 

Thank you in advance

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100412/cdaa5517/attachment.html 

From morethanair at gmail.com  Mon Apr 12 23:54:42 2010
From: morethanair at gmail.com (Kyuhan Nam)
Date: Mon, 12 Apr 2010 23:54:42 -0700
Subject: [Xorp-hackers] Actual FIB Structure
Message-ID: <004201cadad6$32efe700$98cfb500$@com>

Hi, all.

I'm a newbie to see the XORP.

I tried to find the actual structure of FIB.

I traced 'XrlFibClientManager::send_fib_client_add_route' to see where the
actual FIB entries are stored.

 

I saw 'success = _xrl_fea_fib_client.send_add_route4(.' inside, and I found
_xrl_fea_fib_client is  XrlFeaFibClientV0p1Client type.

So, I traced  bool send_add_route4 inside.

 

I saw  'return _sender->send(.)' inside. This process is too iterative, so
I'm lost here L

 

Anyone knows where can I find the FIB table? (tree or list)

 

 

One more question, I found that the RIB is implemented with the tree. What
kind of tree is this? Patricia Trie,Binary trie or other types?

 

 

Thank you in advance

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100412/8f558609/attachment.html 

From greearb at candelatech.com  Tue Apr 13 10:23:19 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 13 Apr 2010 10:23:19 -0700
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
Message-ID: <4BC4A887.8030600@candelatech.com>


The callback logic seems to pass strings by copy instead of
by reference.  I think you can gain some improvements in
code size, and definitely gain RAM & performance improvements
by changing as many of these as possible to 'const string&'.

This might require hacking the logic that generates the XRL
code, so it may not be trivial...I haven't looked in any
detail yet.

With a clever perl script (or maybe grep command), you could
likely find these instances automatically and allow us to audit
the tree for such issues easily...

Thanks,
Ben

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


From saurabh.pandya at elitecore.com  Wed Apr 14 22:08:57 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Thu, 15 Apr 2010 10:38:57 +0530
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
In-Reply-To: <4BC4A887.8030600@candelatech.com>
References: <4BC4A887.8030600@candelatech.com>
Message-ID: <4BC69F69.8070304@elitecore.com>

On 04/13/2010 10:53 PM, Ben Greear wrote:
>
> The callback logic seems to pass strings by copy instead of
> by reference.  I think you can gain some improvements in
> code size, and definitely gain RAM & performance improvements
> by changing as many of these as possible to 'const string&'.
>
> This might require hacking the logic that generates the XRL
> code, so it may not be trivial...I haven't looked in any
> detail yet.
>
Thanks Ben, Well I will try to look in to this , I think you are talking
about perl scripts
within xrl/scripts directory, [clnt-gen  skel-gen  tgt-gen 
thrift-clnt-gen  thrift-gen  thrift-tgt-gen]
is it?

-
Thanks,
Saurabh


From greearb at candelatech.com  Wed Apr 14 23:48:02 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 14 Apr 2010 23:48:02 -0700
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
In-Reply-To: <4BC69F69.8070304@elitecore.com>
References: <4BC4A887.8030600@candelatech.com> <4BC69F69.8070304@elitecore.com>
Message-ID: <4BC6B6A2.4000802@candelatech.com>

On 04/14/2010 10:08 PM, saurabh wrote:
> On 04/13/2010 10:53 PM, Ben Greear wrote:
>>
>> The callback logic seems to pass strings by copy instead of
>> by reference.  I think you can gain some improvements in
>> code size, and definitely gain RAM&  performance improvements
>> by changing as many of these as possible to 'const string&'.
>>
>> This might require hacking the logic that generates the XRL
>> code, so it may not be trivial...I haven't looked in any
>> detail yet.
>>
> Thanks Ben, Well I will try to look in to this , I think you are talking
> about perl scripts
> within xrl/scripts directory, [clnt-gen  skel-gen  tgt-gen
> thrift-clnt-gen  thrift-gen  thrift-tgt-gen]
> is it?

I'm not too sure.  It might be that horribly complex template
thing that builds callbacks methods.  If I were to tackle it, I'd
probably change some callback signatures to pass in const string&
and then see what broke and try to work backwards from there...

Thanks,
Ben

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


From bms at incunabulum.net  Thu Apr 15 09:10:03 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 15 Apr 2010 17:10:03 +0100
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
In-Reply-To: <4BC6B6A2.4000802@candelatech.com>
References: <4BC4A887.8030600@candelatech.com> <4BC69F69.8070304@elitecore.com>
	<4BC6B6A2.4000802@candelatech.com>
Message-ID: <4BC73A5B.3070102@incunabulum.net>

On 04/15/10 07:48, Ben Greear wrote:
> ...
> I'm not too sure.  It might be that horribly complex template
> thing that builds callbacks methods.  If I were to tackle it, I'd
> probably change some callback signatures to pass in const string&
> and then see what broke and try to work backwards from there...
>    

Futzing with 'string' might be a noop, because many STL implementations 
ref-count the internal string representation (GNU libstdc++ does, for 
example).


From greearb at candelatech.com  Thu Apr 15 11:26:48 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 15 Apr 2010 11:26:48 -0700
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
In-Reply-To: <4BC73A5B.3070102@incunabulum.net>
References: <4BC4A887.8030600@candelatech.com>
	<4BC69F69.8070304@elitecore.com>	<4BC6B6A2.4000802@candelatech.com>
	<4BC73A5B.3070102@incunabulum.net>
Message-ID: <4BC75A68.40508@candelatech.com>

On 04/15/2010 09:10 AM, Bruce Simpson wrote:
> On 04/15/10 07:48, Ben Greear wrote:
>> ...
>> I'm not too sure.  It might be that horribly complex template
>> thing that builds callbacks methods.  If I were to tackle it, I'd
>> probably change some callback signatures to pass in const string&
>> and then see what broke and try to work backwards from there...
>>
>
> Futzing with 'string' might be a noop, because many STL implementations
> ref-count the internal string representation (GNU libstdc++ does, for
> example).

Yeah, looks like it wouldn't save much..but would still save a little,
and should be cleaner code.

There might be other areas where we are passing stuff by value that
could be const foo& as well..but I haven't looked hard.

Anyone know of any tools that help figure out what source code
is generating lots of object code?  (Ie, places to look to decrease
the size of the generated binaries & libraries).

Thanks,
Ben

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


From bms at incunabulum.net  Thu Apr 15 11:45:15 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 15 Apr 2010 19:45:15 +0100
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
In-Reply-To: <4BC75A68.40508@candelatech.com>
References: <4BC4A887.8030600@candelatech.com>
	<4BC69F69.8070304@elitecore.com>	<4BC6B6A2.4000802@candelatech.com>
	<4BC73A5B.3070102@incunabulum.net> <4BC75A68.40508@candelatech.com>
Message-ID: <4BC75EBB.5040200@incunabulum.net>

On 04/15/10 19:26, Ben Greear wrote:
> On 04/15/2010 09:10 AM, Bruce Simpson wrote:
>> On 04/15/10 07:48, Ben Greear wrote:
>>> ...
>>> I'm not too sure.  It might be that horribly complex template
>>> thing that builds callbacks methods.  If I were to tackle it, I'd
>>> probably change some callback signatures to pass in const string&
>>> and then see what broke and try to work backwards from there...
>>>
>>
>> Futzing with 'string' might be a noop, because many STL implementations
>> ref-count the internal string representation (GNU libstdc++ does, for
>> example).
>
> Yeah, looks like it wouldn't save much..but would still save a little,
> and should be cleaner code.

I'm not sure what you mean by cleaner code here.

It's difficult for me to assess this further without seeing sample code.

>
> There might be other areas where we are passing stuff by value that
> could be const foo& as well..but I haven't looked hard.

I'm deeply concerned that XORP is still not API-stable enough to be used 
commercially.

Changing what is generated for XRL, is effectively changing a published 
API, although XORP has never really had a policy on this; common sense 
needs to prevail. With the Thrift work (suspended), I was looking to 
shim at the level of that API, to avoid introducing piecemeal changes 
across the tree.

XRL send methods are pretty trivial (and I believe already constified). 
XRL recieve callbacks are not so trivial, because they potentially need 
to validate unmarshalled arguments.

Input arguments are generally passed by value (and constified) already. 
Output arguments are passing values back to the glue wrapper which 
invokes them. They are then responsible for output marshaling. As a 
side-effect, they can't be const and remain references; they'd have to 
become pointers.

This is a side-effect of delegating marshaling to the XRL layer, rather 
than doing it directly. Any RPC layer (CORBA, RMI etc) generally behaves 
like this.

To get more background on XRL, please refer to my Thrift related posts 
on this list from the XORP, Inc era.

The usual practice for profiling code size changes, in static binary 
footprint, is to use 'nm' and 'size' a lot. You can profile RSS at load 
time using Exmap. If you're looking for a source to crib scripts from, 
please see my posts on the Apache JIRA thrift-users list from around 4 
months ago.

regards
BMS


From greearb at candelatech.com  Thu Apr 15 11:55:44 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 15 Apr 2010 11:55:44 -0700
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
In-Reply-To: <4BC75EBB.5040200@incunabulum.net>
References: <4BC4A887.8030600@candelatech.com>
	<4BC69F69.8070304@elitecore.com>	<4BC6B6A2.4000802@candelatech.com>
	<4BC73A5B.3070102@incunabulum.net> <4BC75A68.40508@candelatech.com>
	<4BC75EBB.5040200@incunabulum.net>
Message-ID: <4BC76130.2060204@candelatech.com>

On 04/15/2010 11:45 AM, Bruce Simpson wrote:
> On 04/15/10 19:26, Ben Greear wrote:
>> On 04/15/2010 09:10 AM, Bruce Simpson wrote:
>>> On 04/15/10 07:48, Ben Greear wrote:
>>>> ...
>>>> I'm not too sure. It might be that horribly complex template
>>>> thing that builds callbacks methods. If I were to tackle it, I'd
>>>> probably change some callback signatures to pass in const string&
>>>> and then see what broke and try to work backwards from there...
>>>>
>>>
>>> Futzing with 'string' might be a noop, because many STL implementations
>>> ref-count the internal string representation (GNU libstdc++ does, for
>>> example).
>>
>> Yeah, looks like it wouldn't save much..but would still save a little,
>> and should be cleaner code.
>
> I'm not sure what you mean by cleaner code here.
>
> It's difficult for me to assess this further without seeing sample code.

It's a personal preference..and it saves a small bit of stack
space and ref-count increment/decrement.  But, probably it's
a small thing and not worth much worry, and certainly some time
it's not at all convenient or useful to pass by reference.

>> There might be other areas where we are passing stuff by value that
>> could be const foo& as well..but I haven't looked hard.

> Input arguments are generally passed by value (and constified) already.
> Output arguments are passing values back to the glue wrapper which
> invokes them. They are then responsible for output marshaling. As a
> side-effect, they can't be const and remain references; they'd have to
> become pointers.

Ok, I haven't yet looked closely enough to understand the limitations
of callbacks.

> The usual practice for profiling code size changes, in static binary
> footprint, is to use 'nm' and 'size' a lot. You can profile RSS at load
> time using Exmap. If you're looking for a source to crib scripts from,
> please see my posts on the Apache JIRA thrift-users list from around 4
> months ago.

Thanks,
Ben

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


From a.greenhalgh at cs.ucl.ac.uk  Thu Apr 15 13:11:39 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Thu, 15 Apr 2010 21:11:39 +0100
Subject: [Xorp-hackers] Conference Call to co-ordinate XORP going forward.
Message-ID: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com>

Hi Folks,

I am proposing that we have a Conference call on Thursday 22nd April
at 9pm BST (GMT +1 ) / 1pm PDT. Ben Greear has offered use of his
conference bridge facilities, further details will be available later.
If you wish to join the call please sign up to the doodle poll.

http://www.doodle.com/b7keavmxu53epw74

I'd like to propose the following as an outline agenda, please send
any items you'd wish to be added to the agenda.

Adam

Agenda - XORP Conference Call - 9pm BST Thursday 22nd April 2010.

1. Copyright attribution for new changes.
   - Which organisation should possibly hold the new attribution ?
     - UCL
     - a XORP foundation (Do we need to set one up ?)
     - Individual
     - Other

2. LGPL / GPL / BSD license for new changes.

3. Policy for adding committers.

4. What is the patch approval process.

5. Project Management.
   - Who is in charge ?
   - How do we run things going forward ?

6. Tinderbox
   - Current 4 Platforms.

7. Do we need mirrors ?

8. What is the todo list for the next release (1.7) of XORP.
   - What is required to get the current svn repository out as a release.

9. Is Sourceforge what we need ?

10. Do we need a wiki and bug tracing system ?
     - is the one on Trac sufficient.

11. Mailing list memebership.
     - Should xorp-dev become the xorp committers list ?

12. Boost usage

13. AOB


From saurabh.pandya at elitecore.com  Fri Apr 16 03:22:49 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Fri, 16 Apr 2010 15:52:49 +0530
Subject: [Xorp-hackers]  More ideas for xorp code size improvements.
References: 4BC75A68.40508@candelatech.com
Message-ID: <4BC83A79.2030909@elitecore.com>

>I'm deeply concerned that XORP is still not API-stable enough to be used 
>commercially.

You concern about stability of xorp(1.6) to use in Real world - heavy network load 
environment as standalone product ? I think it is well tested. 
 


From bms at incunabulum.net  Fri Apr 16 06:40:23 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Fri, 16 Apr 2010 14:40:23 +0100
Subject: [Xorp-hackers] API stability
In-Reply-To: <4BC83A79.2030909@elitecore.com>
References: 4BC75A68.40508@candelatech.com <4BC83A79.2030909@elitecore.com>
Message-ID: <4BC868C7.3000504@incunabulum.net>

On 04/16/10 11:22, saurabh wrote:
>> I'm deeply concerned that XORP is still not API-stable enough to be used
>> commercially.
>>      
> You concern about stability of xorp(1.6) to use in Real world - heavy network load
> environment as standalone product ? I think it is well tested.
>    

With respect, this point is not relevant. I presume by 'heavy network 
load' you are referring to forwarding performance.
Forwarding performance has nothing to do with XORP, which is control 
plane software. The problems are elsewhere.

Consider:
  * XORP was positioned as an 'eXtensible' routing platform.
  * The components in the system talk to each other over XRL.
  * XRL is used as the core API.
   * It has been demonstrated to be a source of problems.
   * Look at the poor BGP convergence performance. XRL is clearly on the 
hot path.

Ben was proposing piecemeal changes to XRL itself, which effectively 
change the core API.
That's fine, but the Linux approach to APIs -- just break them on a 
point release -- doesn't scale to real-world use.

Be safe out there.


From a.greenhalgh at cs.ucl.ac.uk  Fri Apr 16 06:46:04 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Fri, 16 Apr 2010 14:46:04 +0100
Subject: [Xorp-hackers] API stability
In-Reply-To: <4BC868C7.3000504@incunabulum.net>
References: <4BC83A79.2030909@elitecore.com> <4BC868C7.3000504@incunabulum.net>
Message-ID: <y2m4769af411004160646rdea72f93xb4be37a97b7806a6@mail.gmail.com>

I'll add this to the agenda for the conference call. Whether we get to
this in the allocated time , I am not sure.

Adam

On 16 April 2010 14:40, Bruce Simpson <bms at incunabulum.net> wrote:
> On 04/16/10 11:22, saurabh wrote:
>>> I'm deeply concerned that XORP is still not API-stable enough to be used
>>> commercially.
>>>
>> You concern about stability of xorp(1.6) to use in Real world - heavy network load
>> environment as standalone product ? I think it is well tested.
>>
>
> With respect, this point is not relevant. I presume by 'heavy network
> load' you are referring to forwarding performance.
> Forwarding performance has nothing to do with XORP, which is control
> plane software. The problems are elsewhere.
>
> Consider:
> ?* XORP was positioned as an 'eXtensible' routing platform.
> ?* The components in the system talk to each other over XRL.
> ?* XRL is used as the core API.
> ? * It has been demonstrated to be a source of problems.
> ? * Look at the poor BGP convergence performance. XRL is clearly on the
> hot path.
>
> Ben was proposing piecemeal changes to XRL itself, which effectively
> change the core API.
> That's fine, but the Linux approach to APIs -- just break them on a
> point release -- doesn't scale to real-world use.
>
> Be safe out there.
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Fri Apr 16 08:01:40 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 16 Apr 2010 08:01:40 -0700
Subject: [Xorp-hackers] API stability
In-Reply-To: <4BC868C7.3000504@incunabulum.net>
References: 4BC75A68.40508@candelatech.com <4BC83A79.2030909@elitecore.com>
	<4BC868C7.3000504@incunabulum.net>
Message-ID: <4BC87BD4.6020806@candelatech.com>

On 04/16/2010 06:40 AM, Bruce Simpson wrote:
> On 04/16/10 11:22, saurabh wrote:
>>> I'm deeply concerned that XORP is still not API-stable enough to be used
>>> commercially.
>>>
>> You concern about stability of xorp(1.6) to use in Real world - heavy network load
>> environment as standalone product ? I think it is well tested.
>>
>
> With respect, this point is not relevant. I presume by 'heavy network
> load' you are referring to forwarding performance.
> Forwarding performance has nothing to do with XORP, which is control
> plane software. The problems are elsewhere.
>
> Consider:
>    * XORP was positioned as an 'eXtensible' routing platform.

It supports lots of protocols..seems like that part worked fine.

Anyone capable of developing a new protocol for xorp can easily
change a few callback signatures and re-compile.

>    * The components in the system talk to each other over XRL.
>    * XRL is used as the core API.
>     * It has been demonstrated to be a source of problems.
>     * Look at the poor BGP convergence performance. XRL is clearly on the
> hot path.
>
> Ben was proposing piecemeal changes to XRL itself, which effectively
> change the core API.
> That's fine, but the Linux approach to APIs -- just break them on a
> point release -- doesn't scale to real-world use.

Instead of hand-waving, why not give a real example?  You think someone
is going to try to distribute binary xorp modules to work on random
Xorp installations or something?

Thanks,
Ben

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


From greearb at candelatech.com  Fri Apr 16 12:10:04 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 16 Apr 2010 12:10:04 -0700
Subject: [Xorp-hackers] More ideas for xorp code size improvements.
In-Reply-To: <4BC4A887.8030600@candelatech.com>
References: <4BC4A887.8030600@candelatech.com>
Message-ID: <4BC8B60C.4020203@candelatech.com>

Maybe callbacks are too much trouble to bother with, but there
are other areas for improvement.  For instance, this patch
(against xorp.ct) saves  around 30KB, and it should help
run-time and stack usage as well.

diff --git a/libxipc/xrl_error.cc b/libxipc/xrl_error.cc
index fd96af1..b6626f1 100644
--- a/libxipc/xrl_error.cc
+++ b/libxipc/xrl_error.cc
@@ -116,3 +116,6 @@ XrlError::error_msg() const
  {
      return _errlet->error_msg();
  }
+
+
+XrlCmdError XrlCmdError::_xce_ok(XrlError::OKAY());
diff --git a/libxipc/xrl_error.hh b/libxipc/xrl_error.hh
index 44dd2fb..4ad2f26 100644
--- a/libxipc/xrl_error.hh
+++ b/libxipc/xrl_error.hh
@@ -179,7 +179,7 @@ public:
       * still return OKAY(), but the return list should indicate the
       * error.
       */
-    static const XrlCmdError OKAY() { return XrlError::OKAY(); }
+    static const XrlCmdError& OKAY() { return _xce_ok; }

      /**
       * Return value when the method arguments are incorrect.
@@ -215,11 +215,12 @@ public:
      /**
       * @return note associated with origin of error (i.e., the reason).
       */
-    string note() const { return _xrl_error.note(); }
+    const string& note() const { return _xrl_error.note(); }

  private:
      XrlCmdError(const XrlError& xe) : _xrl_error(xe) {}
      XrlError _xrl_error;
+    static XrlCmdError _xce_ok;
  };

  ^L
diff --git a/libxipc/xrl_sender.hh b/libxipc/xrl_sender.hh
index 991d40a..123bcec 100644
--- a/libxipc/xrl_sender.hh
+++ b/libxipc/xrl_sender.hh
@@ -30,6 +30,7 @@ class XrlError;

  /**
   * Base for classes able to transport Xrls.
+ * See xrl_router.hh for implementor of this base class.
   */
  class XrlSender {
  public:


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


From saurabh.pandya at elitecore.com  Sat Apr 17 06:11:30 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Sat, 17 Apr 2010 18:41:30 +0530
Subject: [Xorp-hackers] Xorp Router with ISP  (RP discovery?)
Message-ID: <4BC9B382.70006@elitecore.com>

Dear All,

I wish to connect my xorp router (with 3 Ethernet ports total) directly
to ISP.

eth3 of my router is WAN, and eth1 - eth2 are local zone.

While PIM-SM4 Bootstrap section is to configured as below (rightnow !)

    bootstrap {                                      
            disable: false                               
            cand-bsr {                                   
                    scope-zone 224.0.0.0/4 {             
                    is-scope-zone: true                  
                    cand-bsr-by-vif-name: "eth3"        
                    bsr-priority: 10                     
                    hash-mask-len: 30                    
                }                                        
            }                                            
            cand-rp {                                    
                group-prefix 224.0.0.0/4 {               
                    is-scope-zone: true                  
                    cand-rp-by-vif-name: "eth3"         
                    rp-priority: 45                      
                    rp-holdtime: 150                     
                }                                        
            }                                            
        }                

My question: When some hosts under eth1 , eth2 (local zone) have multi-cast
receivers of some multi-cast group (say 239.1.1.45),

"Then xorp router will able to obtain RP-set for each Multicast Group
address
by BSR mechanism from ISP router-path?"  (First Considering ISP router
is PIM enabled
then other case)

Anybody have tested this? or Static RP for each know group will have to
supplied
manually?

Thanks in advance
Saurabh


From greearb at candelatech.com  Sat Apr 17 22:01:29 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 17 Apr 2010 22:01:29 -0700
Subject: [Xorp-hackers] XRL performance
Message-ID: <4BCA9229.7060904@candelatech.com>

After some prodding from Bruce I took a closer look at xrl and noticed
that it used new/delete for each xrl_atom for things like IPv4
addresses, macs, etc.

As a proof of concept, I moved IPv4 and IPv4Net object types directly
into the xrl atom class instead of using new/delete.  This uses an extra
12 bytes per XRL atom, but I think that is a good trade-off to remove
the new/delete logic.

I also got the libxipc test logic working again (it had been broken in
xorp.ct for some months due to a bad merge I did..not sure if it works
in upstream or not) and tweaked the sender to allow sending different
XRL types.

These changes have just been pushed to xorp.ct

On my test machine (3.3Ghz quad-core i&), I see this performance
when sending the 'large' xrl.  It's maybe a bit better than before
my changes, but normally it bouches around quite a lot, so
it's hard to benchmark small improvements.

[root at ct503-10G-09 tests]# ./test_xrl_sender -s 2 -N 500000
XrlAtoms per call = 1
Send method = pipeline
Send style = 2
start_transmission_cb 100 Okay
Received 500000 XRLs; delta_time = 4.212246 secs; speed = 118701.519332 XRLs/s
start_transmission_cb 100 Okay
Received 500000 XRLs; delta_time = 4.498949 secs; speed = 111137.067791 XRLs/s
start_transmission_cb 100 Okay
Received 500000 XRLs; delta_time = 4.079798 secs; speed = 122555.087286 XRLs/s
start_transmission_cb 100 Okay
Received 500000 XRLs; delta_time = 4.071571 secs; speed = 122802.721603 XRLs/s
start_transmission_cb 100 Okay


There is certainly more to optimize in xrl logic, including moving such things
as MACs inline like I did for ipv4 and probably encoding them in 6 binary bytes
instead of ascii (as it appears to do now).  But, at over 100,000 XRLs per second,
it's reasonably fast as is.

I hear bgp has issues with large route databases, so I'm going to attempt to
find some way to reproduce that and debug it directly.  My guess is that the
root cause is not directly related to XRL/s but probably a lack of batching
or some other similar issue.

Thanks,
Ben

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


From a.greenhalgh at cs.ucl.ac.uk  Mon Apr 19 08:00:03 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Mon, 19 Apr 2010 16:00:03 +0100
Subject: [Xorp-hackers] Conference Call to co-ordinate XORP going
	forward.
In-Reply-To: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com>
References: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com>
Message-ID: <k2j4769af411004190800x964f5212h3d6278a2e7efdab7@mail.gmail.com>

Just a reminder, this is this Thursday

Adam

On 15 April 2010 21:11, Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk> wrote:
> Hi Folks,
>
> I am proposing that we have a Conference call on Thursday 22nd April
> at 9pm BST (GMT +1 ) / 1pm PDT. Ben Greear has offered use of his
> conference bridge facilities, further details will be available later.
> If you wish to join the call please sign up to the doodle poll.
>
> http://www.doodle.com/b7keavmxu53epw74
>
> I'd like to propose the following as an outline agenda, please send
> any items you'd wish to be added to the agenda.
>
> Adam
>
> Agenda - XORP Conference Call - 9pm BST Thursday 22nd April 2010.
>
> 1. Copyright attribution for new changes.
> ? - Which organisation should possibly hold the new attribution ?
> ? ? - UCL
> ? ? - a XORP foundation (Do we need to set one up ?)
> ? ? - Individual
> ? ? - Other
>
> 2. LGPL / GPL / BSD license for new changes.
>
> 3. Policy for adding committers.
>
> 4. What is the patch approval process.
>
> 5. Project Management.
> ? - Who is in charge ?
> ? - How do we run things going forward ?
>
> 6. Tinderbox
> ? - Current 4 Platforms.
>
> 7. Do we need mirrors ?
>
> 8. What is the todo list for the next release (1.7) of XORP.
> ? - What is required to get the current svn repository out as a release.
>
> 9. Is Sourceforge what we need ?
>
> 10. Do we need a wiki and bug tracing system ?
> ? ? - is the one on Trac sufficient.
>
> 11. Mailing list memebership.
> ? ? - Should xorp-dev become the xorp committers list ?
>
> 12. Boost usage
>
> 13. AOB
>


From greearb at candelatech.com  Mon Apr 19 08:43:36 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 19 Apr 2010 08:43:36 -0700
Subject: [Xorp-hackers] Conference Call to co-ordinate XORP
	going	forward.
In-Reply-To: <k2j4769af411004190800x964f5212h3d6278a2e7efdab7@mail.gmail.com>
References: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com>
	<k2j4769af411004190800x964f5212h3d6278a2e7efdab7@mail.gmail.com>
Message-ID: <4BCC7A28.6090809@candelatech.com>

On 04/19/2010 08:00 AM, Adam Greenhalgh wrote:
> Just a reminder, this is this Thursday

You want me to go ahead and set up the webex conference?

Thanks,
Ben

>
> Adam
>
> On 15 April 2010 21:11, Adam Greenhalgh<a.greenhalgh at cs.ucl.ac.uk>  wrote:
>> Hi Folks,
>>
>> I am proposing that we have a Conference call on Thursday 22nd April
>> at 9pm BST (GMT +1 ) / 1pm PDT. Ben Greear has offered use of his
>> conference bridge facilities, further details will be available later.
>> If you wish to join the call please sign up to the doodle poll.
>>
>> http://www.doodle.com/b7keavmxu53epw74
>>
>> I'd like to propose the following as an outline agenda, please send
>> any items you'd wish to be added to the agenda.
>>
>> Adam
>>
>> Agenda - XORP Conference Call - 9pm BST Thursday 22nd April 2010.
>>
>> 1. Copyright attribution for new changes.
>>    - Which organisation should possibly hold the new attribution ?
>>      - UCL
>>      - a XORP foundation (Do we need to set one up ?)
>>      - Individual
>>      - Other
>>
>> 2. LGPL / GPL / BSD license for new changes.
>>
>> 3. Policy for adding committers.
>>
>> 4. What is the patch approval process.
>>
>> 5. Project Management.
>>    - Who is in charge ?
>>    - How do we run things going forward ?
>>
>> 6. Tinderbox
>>    - Current 4 Platforms.
>>
>> 7. Do we need mirrors ?
>>
>> 8. What is the todo list for the next release (1.7) of XORP.
>>    - What is required to get the current svn repository out as a release.
>>
>> 9. Is Sourceforge what we need ?
>>
>> 10. Do we need a wiki and bug tracing system ?
>>      - is the one on Trac sufficient.
>>
>> 11. Mailing list memebership.
>>      - Should xorp-dev become the xorp committers list ?
>>
>> 12. Boost usage
>>
>> 13. AOB
>>
>
> _______________________________________________
> 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 ldacol at gmail.com  Mon Apr 19 16:52:01 2010
From: ldacol at gmail.com (Luca Da Col)
Date: Tue, 20 Apr 2010 08:52:01 +0900
Subject: [Xorp-hackers] Conference Call to co-ordinate XORP going
	forward.
In-Reply-To: <4BCC7A28.6090809@candelatech.com>
References: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com>
	<k2j4769af411004190800x964f5212h3d6278a2e7efdab7@mail.gmail.com>
	<4BCC7A28.6090809@candelatech.com>
Message-ID: <k2sf4acd0281004191652ta0c50f10hb36f7ccfc99b9510@mail.gmail.com>

Hi everybody,

would it be possible to record the conference for the benefit of those who
are interested on it but cannot attend live?

Thanks,
Luca

On Tue, Apr 20, 2010 at 12:43 AM, Ben Greear <greearb at candelatech.com>wrote:

> On 04/19/2010 08:00 AM, Adam Greenhalgh wrote:
> > Just a reminder, this is this Thursday
>
> You want me to go ahead and set up the webex conference?
>
> Thanks,
> Ben
>
> >
> > Adam
> >
> > On 15 April 2010 21:11, Adam Greenhalgh<a.greenhalgh at cs.ucl.ac.uk>
>  wrote:
> >> Hi Folks,
> >>
> >> I am proposing that we have a Conference call on Thursday 22nd April
> >> at 9pm BST (GMT +1 ) / 1pm PDT. Ben Greear has offered use of his
> >> conference bridge facilities, further details will be available later.
> >> If you wish to join the call please sign up to the doodle poll.
> >>
> >> http://www.doodle.com/b7keavmxu53epw74
> >>
> >> I'd like to propose the following as an outline agenda, please send
> >> any items you'd wish to be added to the agenda.
> >>
> >> Adam
> >>
> >> Agenda - XORP Conference Call - 9pm BST Thursday 22nd April 2010.
> >>
> >> 1. Copyright attribution for new changes.
> >>    - Which organisation should possibly hold the new attribution ?
> >>      - UCL
> >>      - a XORP foundation (Do we need to set one up ?)
> >>      - Individual
> >>      - Other
> >>
> >> 2. LGPL / GPL / BSD license for new changes.
> >>
> >> 3. Policy for adding committers.
> >>
> >> 4. What is the patch approval process.
> >>
> >> 5. Project Management.
> >>    - Who is in charge ?
> >>    - How do we run things going forward ?
> >>
> >> 6. Tinderbox
> >>    - Current 4 Platforms.
> >>
> >> 7. Do we need mirrors ?
> >>
> >> 8. What is the todo list for the next release (1.7) of XORP.
> >>    - What is required to get the current svn repository out as a
> release.
> >>
> >> 9. Is Sourceforge what we need ?
> >>
> >> 10. Do we need a wiki and bug tracing system ?
> >>      - is the one on Trac sufficient.
> >>
> >> 11. Mailing list memebership.
> >>      - Should xorp-dev become the xorp committers list ?
> >>
> >> 12. Boost usage
> >>
> >> 13. AOB
> >>
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100420/a5140356/attachment.html 

From greearb at candelatech.com  Mon Apr 19 20:30:39 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 19 Apr 2010 20:30:39 -0700
Subject: [Xorp-hackers] Conference Call to co-ordinate XORP going
	forward.
In-Reply-To: <k2sf4acd0281004191652ta0c50f10hb36f7ccfc99b9510@mail.gmail.com>
References: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com>	
	<k2j4769af411004190800x964f5212h3d6278a2e7efdab7@mail.gmail.com>	
	<4BCC7A28.6090809@candelatech.com>
	<k2sf4acd0281004191652ta0c50f10hb36f7ccfc99b9510@mail.gmail.com>
Message-ID: <4BCD1FDF.9010402@candelatech.com>

On 04/19/2010 04:52 PM, Luca Da Col wrote:
> Hi everybody,
>
> would it be possible to record the conference for the benefit of those
> who are interested on it but cannot attend live?

If everyone wants to, I'll attempt it..but not sure it can easily
be done, and not sure everyone would want to be recorded.

More likely, we can take notes and just publish those as email.

Thanks,
Ben

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


From ldacol at gmail.com  Tue Apr 20 02:42:30 2010
From: ldacol at gmail.com (Luca Da Col)
Date: Tue, 20 Apr 2010 18:42:30 +0900
Subject: [Xorp-hackers] Conference Call to co-ordinate XORP going
	forward.
In-Reply-To: <4BCD1FDF.9010402@candelatech.com>
References: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com>
	<k2j4769af411004190800x964f5212h3d6278a2e7efdab7@mail.gmail.com>
	<4BCC7A28.6090809@candelatech.com>
	<k2sf4acd0281004191652ta0c50f10hb36f7ccfc99b9510@mail.gmail.com>
	<4BCD1FDF.9010402@candelatech.com>
Message-ID: <s2lf4acd0281004200242i7bf2363fg2bd174aef6a73608@mail.gmail.com>

yes I thought about the record issue may be a problem for someone...
Published notes would be highly appreciated then.

Thanks,
Luca

On Tue, Apr 20, 2010 at 12:30 PM, Ben Greear <greearb at candelatech.com>wrote:

> On 04/19/2010 04:52 PM, Luca Da Col wrote:
>
>> Hi everybody,
>>
>> would it be possible to record the conference for the benefit of those
>> who are interested on it but cannot attend live?
>>
>
> If everyone wants to, I'll attempt it..but not sure it can easily
> be done, and not sure everyone would want to be recorded.
>
> More likely, we can take notes and just publish those as email.
>
> Thanks,
> Ben
>
> --
> 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-hackers/attachments/20100420/4e854ef8/attachment.html 

From a.greenhalgh at cs.ucl.ac.uk  Tue Apr 20 04:16:22 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Tue, 20 Apr 2010 12:16:22 +0100
Subject: [Xorp-hackers] Conference Call to co-ordinate XORP going
	forward.
In-Reply-To: <s2lf4acd0281004200242i7bf2363fg2bd174aef6a73608@mail.gmail.com>
References: <k2o4769af411004151311z5ff59f5bk31b49e5613a4ac23@mail.gmail.com> 
	<k2j4769af411004190800x964f5212h3d6278a2e7efdab7@mail.gmail.com> 
	<4BCC7A28.6090809@candelatech.com>
	<k2sf4acd0281004191652ta0c50f10hb36f7ccfc99b9510@mail.gmail.com>
	<4BCD1FDF.9010402@candelatech.com>
	<s2lf4acd0281004200242i7bf2363fg2bd174aef6a73608@mail.gmail.com>
Message-ID: <h2m4769af411004200416m60100504z4513b31b3191b75b@mail.gmail.com>

We will attempt to publish minutes after the call. Unless those on the
call decide otherwise the proceedure for publishing the minutes will
be this :

1. Minutes will be written up and circulated to all those on the call
for corrections and amendments. Two working days will be allowed for
corrections.
2. Corrected minutes will be circulated. Two working days will be
allowed for corrections.
3. Minutes will be posted to xorp-hackers.

Adam

On 20 April 2010 10:42, Luca Da Col <ldacol at gmail.com> wrote:
> yes I thought about the record issue may be a problem for someone...
> Published notes would be?highly appreciated then.
> Thanks,
> Luca
>
> On Tue, Apr 20, 2010 at 12:30 PM, Ben Greear <greearb at candelatech.com>
> wrote:
>>
>> On 04/19/2010 04:52 PM, Luca Da Col wrote:
>>>
>>> Hi everybody,
>>>
>>> would it be possible to record the conference for the benefit of those
>>> who are interested on it but cannot attend live?
>>
>> If everyone wants to, I'll attempt it..but not sure it can easily
>> be done, and not sure everyone would want to be recorded.
>>
>> More likely, we can take notes and just publish those as email.
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc ?http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>


From greearb at candelatech.com  Tue Apr 20 09:32:38 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Apr 2010 09:32:38 -0700
Subject: [Xorp-hackers] BGP questions
Message-ID: <4BCDD726.9010106@candelatech.com>

I noticed bgp wasn't being compiled with shared libraries,
or at least didn't fully use shared libray logic.  I fixed
that and the 'harness' directory build in xorp.ct

Now, I'm trying to do some basic testing of bgp.

Anyone have any ideas for how to configure up a router network
that uses BGP in a useful manner?

I was thinking maybe something like
ospf-router-1 -- [ ospf/bgp router ] -- [ bgp/ospf router] -- ospf-router-2

??

Thanks,
Ben

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


From lizhaous2000 at yahoo.com  Tue Apr 20 10:15:21 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Tue, 20 Apr 2010 10:15:21 -0700 (PDT)
Subject: [Xorp-hackers] BGP questions
In-Reply-To: <4BCDD726.9010106@candelatech.com>
Message-ID: <757685.11372.qm@web58702.mail.re1.yahoo.com>

The real simple one might be that using two routers to build bgp adjacency. And then redistribute some static routes. And then change interface state which the static route is using as next-hop to see if bgp stopped redistributing it.

--- On Tue, 4/20/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: [Xorp-hackers] BGP questions
> To: "xorp" <xorp-hackers at xorp.org>
> Date: Tuesday, April 20, 2010, 12:32 PM
> I noticed bgp wasn't being compiled
> with shared libraries,
> or at least didn't fully use shared libray logic.? I
> fixed
> that and the 'harness' directory build in xorp.ct
> 
> Now, I'm trying to do some basic testing of bgp.
> 
> Anyone have any ideas for how to configure up a router
> network
> that uses BGP in a useful manner?
> 
> I was thinking maybe something like
> ospf-router-1 -- [ ospf/bgp router ] -- [ bgp/ospf router]
> -- ospf-router-2
> 
> ??
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From greearb at candelatech.com  Tue Apr 20 10:18:17 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Apr 2010 10:18:17 -0700
Subject: [Xorp-hackers] BGP questions
In-Reply-To: <757685.11372.qm@web58702.mail.re1.yahoo.com>
References: <757685.11372.qm@web58702.mail.re1.yahoo.com>
Message-ID: <4BCDE1D9.1030800@candelatech.com>

On 04/20/2010 10:15 AM, Li Zhao wrote:
> The real simple one might be that using two routers to build bgp adjacency. And then redistribute some static routes. And then change interface state which the static route is using as next-hop to see if bgp stopped redistributing it.

Ok, I'll try that next.  I wasn't using any policies before, but I'm
guessing that I need export policies similar to what I have below?

          "policy {\n"
          "    policy-statement static-to-bgp {\n"
          "        term export {\n"
          "            from {\n"
          "                protocol: \"static\"\n"
          "            }\n"
          "            then {\n"
          "                metric: 0\n"
          "            }\n"
          "        }\n"
          "    }\n\n";

          "    policy-statement connected-to-bgp {\n"
          "        term export {\n"
          "            from {\n"
          "                protocol: \"connected\"\n"
          "            }\n"
          "            then {\n"
          "                metric: 0\n"
          "            }\n"
          "        }\n"
          "    }\n"
          "}\n\n";

Thanks,
Ben

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


From greearb at candelatech.com  Tue Apr 20 10:54:35 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Apr 2010 10:54:35 -0700
Subject: [Xorp-hackers] BGP questions
In-Reply-To: <757685.11372.qm@web58702.mail.re1.yahoo.com>
References: <757685.11372.qm@web58702.mail.re1.yahoo.com>
Message-ID: <4BCDEA5B.8060508@candelatech.com>

On 04/20/2010 10:15 AM, Li Zhao wrote:
> The real simple one might be that using two routers to build bgp adjacency. And then redistribute some static routes. And then change interface state which the static route is using as next-hop to see if bgp stopped redistributing it.

I'm not sure things are working.  Should I expect to see more info about
the bgp peer (like state, for instance?)

And I assume at least subnet routes should be shown in 'show bgp routes' ?

My current config has two routers.  Outside interfaces are running OSPF
but not connected to other OSPF routers.  One pair of interfaces (rddVR8, rddVR9)
connects the two routers, and these interfaces are supposed to be running
BGP.  There are no obvious errors in the logs, and bgp connections appear
to be properly established:

[root at ct503-10G-09 lanforge]# netstat -an|grep 179
tcp        0      0 5.1.1.2:179                 0.0.0.0:*                   LISTEN
tcp        0      0 5.1.1.1:179                 0.0.0.0:*                   LISTEN
tcp        0      0 5.1.1.1:179                 5.1.1.2:18692               ESTABLISHED
tcp        0      0 5.1.1.2:18692               5.1.1.1:179                 ESTABLISHED



root at ct503-10G-09> show bgp peers
Peer 1: local 5.1.1.1/179 remote 5.1.1.2/179
root at ct503-10G-09> show bgp routes
Status Codes: * valid route, > best route
Origin Codes: i IGP, e EGP, ? incomplete

    Prefix                Nexthop                    Peer            AS Path
    ------                -------                    ----            -------
root at ct503-10G-09> show route table ipv4 unicast connected
2.2.2.0/24	[connected(0)/0]
		> via rddVR6/rddVR6
5.1.1.0/24	[connected(0)/0]
		> via rddVR8/rddVR8
8.1.2.0/24	[connected(0)/0]
		> via rddVR3/rddVR3
root at ct503-10G-09> show route table ipv4 unicast ebgp
root at ct503-10G-09> show route table ipv4 unicast ibgp
root at ct503-10G-09> show route table ipv4 unicast final
0.0.0.0/0	[static(220)/1]
		> to 0.0.0.0 via my_discard/my_discard
2.2.2.0/24	[connected(0)/0]
		> via rddVR6/rddVR6
5.1.1.0/24	[connected(0)/0]
		> via rddVR8/rddVR8
8.1.2.0/24	[connected(0)/0]
		> via rddVR3/rddVR3
root at ct503-10G-09>



Config file for this router is below.  The other router's config is similar (and farther below)
/* For Virtual-Router: Router-0 */

interfaces {
     interface my_discard {
         unreachable: true
         vif my_discard {
         }
     }

     interface "rddVR6" {
         vif "rddVR6" {
             address 2.2.2.1 {
                 prefix-length: 24
             }
         }
     }

     interface "rddVR8" {
         vif "rddVR8" {
             address 5.1.1.1 {
                 prefix-length: 24
             }
         }
     }

     interface "rddVR3" {
         vif "rddVR3" {
             address 8.1.2.1 {
                 prefix-length: 24
             }
         }
     }

}

fea {
     unicast-forwarding4 {
         disable: false
         table-id: 10001
     }
}

policy {
     policy-statement static-to-bgp {
         term export {
             from {
                 protocol: "static"
             }
             then {
                 metric: 0
             }
         }
     }

     policy-statement connected-to-bgp {
         term export {
             from {
                 protocol: "connected"
             }
             then {
                 metric: 0
             }
         }
     }
}

protocols {
     static {
         interface-route 0.0.0.0/0 {
             next-hop-interface: "my_discard"
             next-hop-vif: "my_discard"
         }
     }

     ospf4 {
         router-id: 127.1.0.1
         area 0.0.0.0 {
             interface "rddVR6" {
                 vif "rddVR6" {
                     address 2.2.2.1 {
                        interface-cost: 1
                     }
                 }
             }

             interface "rddVR3" {
                 vif "rddVR3" {
                     address 8.1.2.1 {
                        interface-cost: 1
                     }
                 }
             }

         } /* area */

         /* traceoptions {
             flag all {
                 disable: false
             }
         } */
     }
     bgp {
         bgp-id: 0.0.0.1
         local-as: 1
         peer 5.1.1.2 {
             local-ip: 5.1.1.1
             /* local-dev: "rddVR8" */
             as: 2
             next-hop: 5.1.1.2
             holdtime: 5
             delay-open-time: 5
             client: false
             confederation-member: false
             ipv4-unicast: false
             disable: false
         }
     } /* end of bgp4 proto */

}

  /* End of Config File */

Router-2 config:

/* For Virtual-Router: Router-1 */

interfaces {
     interface my_discard {
         unreachable: true
         vif my_discard {
         }
     }

     interface "rddVR0" {
         vif "rddVR0" {
             address 1.1.1.2 {
                 prefix-length: 24
             }
         }
     }

     interface "rddVR13" {
         vif "rddVR13" {
             address 4.1.1.2 {
                 prefix-length: 24
             }
         }
     }

     interface "rddVR9" {
         vif "rddVR9" {
             address 5.1.1.2 {
                 prefix-length: 24
             }
         }
     }

}

fea {
     unicast-forwarding4 {
         disable: false
         table-id: 10002
     }
}

policy {
     policy-statement static-to-bgp {
         term export {
             from {
                 protocol: "static"
             }
             then {
                 metric: 0
             }
         }
     }

     policy-statement connected-to-bgp {
         term export {
             from {
                 protocol: "connected"
             }
             then {
                 metric: 0
             }
         }
     }
}

protocols {
     static {
         interface-route 0.0.0.0/0 {
             next-hop-interface: "my_discard"
             next-hop-vif: "my_discard"
         }
     }

     ospf4 {
         router-id: 127.1.0.2
         area 0.0.0.0 {
             interface "rddVR0" {
                 vif "rddVR0" {
                     address 1.1.1.2 {
                        interface-cost: 1
                     }
                 }
             }

             interface "rddVR13" {
                 vif "rddVR13" {
                     address 4.1.1.2 {
                        interface-cost: 1
                     }
                 }
             }

         } /* area */

         /* traceoptions {
             flag all {
                 disable: false
             }
         } */
     }
     bgp {
         bgp-id: 0.0.0.2
         local-as: 2
         peer 5.1.1.1 {
             local-ip: 5.1.1.2
             /* local-dev: "rddVR9" */
             as: 1
             next-hop: 5.1.1.1
             holdtime: 5
             delay-open-time: 5
             client: false
             confederation-member: false
             ipv4-unicast: false
             disable: false
         }
     } /* end of bgp4 proto */

}

  /* End of Config File */



Thanks,
Ben

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


From lizhaous2000 at yahoo.com  Tue Apr 20 11:53:17 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Tue, 20 Apr 2010 11:53:17 -0700 (PDT)
Subject: [Xorp-hackers] BGP questions
In-Reply-To: <4BCDE1D9.1030800@candelatech.com>
Message-ID: <965747.46371.qm@web58707.mail.re1.yahoo.com>

if you do not use "then" clause the default action is "accept". you can use these policy statement under protocol bgp.

--- On Tue, 4/20/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] BGP questions
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: "xorp" <xorp-hackers at xorp.org>
> Date: Tuesday, April 20, 2010, 1:18 PM
> On 04/20/2010 10:15 AM, Li Zhao
> wrote:
> > The real simple one might be that using two routers to
> build bgp adjacency. And then redistribute some static
> routes. And then change interface state which the static
> route is using as next-hop to see if bgp stopped
> redistributing it.
> 
> Ok, I'll try that next.? I wasn't using any policies
> before, but I'm
> guessing that I need export policies similar to what I have
> below?
> 
> ? ? ? ???"policy {\n"
> ? ? ? ???"? ?
> policy-statement static-to-bgp {\n"
> ? ? ? ???"? ?
> ? ? term export {\n"
> ? ? ? ???"? ?
> ? ? ? ? from {\n"
> ? ? ? ???"? ?
> ? ? ? ? ? ? protocol:
> \"static\"\n"
> ? ? ? ???"? ?
> ? ? ? ? }\n"
> ? ? ? ???"? ?
> ? ? ? ? then {\n"
> ? ? ? ???"? ?
> ? ? ? ? ? ? metric: 0\n"
> ? ? ? ???"? ?
> ? ? ? ? }\n"
> ? ? ? ???"? ?
> ? ? }\n"
> ? ? ? ???"? ?
> }\n\n";
> 
> ? ? ? ???"? ?
> policy-statement connected-to-bgp {\n"
> ? ? ? ???"? ?
> ? ? term export {\n"
> ? ? ? ???"? ?
> ? ? ? ? from {\n"
> ? ? ? ???"? ?
> ? ? ? ? ? ? protocol:
> \"connected\"\n"
> ? ? ? ???"? ?
> ? ? ? ? }\n"
> ? ? ? ???"? ?
> ? ? ? ? then {\n"
> ? ? ? ???"? ?
> ? ? ? ? ? ? metric: 0\n"
> ? ? ? ???"? ?
> ? ? ? ? }\n"
> ? ? ? ???"? ?
> ? ? }\n"
> ? ? ? ???"? ? }\n"
> ? ? ? ???"}\n\n";
> 
> Thanks,
> Ben
> 
> -- Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From lizhaous2000 at yahoo.com  Tue Apr 20 12:02:15 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Tue, 20 Apr 2010 12:02:15 -0700 (PDT)
Subject: [Xorp-hackers] BGP questions
In-Reply-To: <4BCDEA5B.8060508@candelatech.com>
Message-ID: <600999.12832.qm@web58706.mail.re1.yahoo.com>

I used cisco bgp a lot in the passed. After established, the recieved route number is shown. I have not used xorp to config bgp yet. But remember bgp is not link state protocol like ospf. Only if you have some bgp routes incoming or redistributing igp routes, you won't see bgp routes.
try to redistribute some static routes, you probably will see something different.

--- On Tue, 4/20/10, Ben Greear <greearb at candelatech.com> wrote:

> From: Ben Greear <greearb at candelatech.com>
> Subject: Re: [Xorp-hackers] BGP questions
> To: "Li Zhao" <lizhaous2000 at yahoo.com>
> Cc: "xorp" <xorp-hackers at xorp.org>
> Date: Tuesday, April 20, 2010, 1:54 PM
> On 04/20/2010 10:15 AM, Li Zhao
> wrote:
> > The real simple one might be that using two routers to
> build bgp adjacency. And then redistribute some static
> routes. And then change interface state which the static
> route is using as next-hop to see if bgp stopped
> redistributing it.
> 
> I'm not sure things are working.? Should I expect to
> see more info about
> the bgp peer (like state, for instance?)
> 
> And I assume at least subnet routes should be shown in
> 'show bgp routes' ?
> 
> My current config has two routers.? Outside interfaces
> are running OSPF
> but not connected to other OSPF routers.? One pair of
> interfaces (rddVR8, rddVR9)
> connects the two routers, and these interfaces are supposed
> to be running
> BGP.? There are no obvious errors in the logs, and bgp
> connections appear
> to be properly established:
> 
> [root at ct503-10G-09 lanforge]# netstat -an|grep 179
> tcp? ? ? ? 0? ? ? 0
> 5.1.1.2:179? ? ? ? ? ? ?
> ???0.0.0.0:*? ? ? ?
> ? ? ? ? ???LISTEN
> tcp? ? ? ? 0? ? ? 0
> 5.1.1.1:179? ? ? ? ? ? ?
> ???0.0.0.0:*? ? ? ?
> ? ? ? ? ???LISTEN
> tcp? ? ? ? 0? ? ? 0
> 5.1.1.1:179? ? ? ? ? ? ?
> ???5.1.1.2:18692? ? ? ?
> ? ? ???ESTABLISHED
> tcp? ? ? ? 0? ? ? 0
> 5.1.1.2:18692? ? ? ? ? ?
> ???5.1.1.1:179? ? ? ?
> ? ? ? ???ESTABLISHED
> 
> 
> 
> root at ct503-10G-09> show bgp peers
> Peer 1: local 5.1.1.1/179 remote 5.1.1.2/179
> root at ct503-10G-09> show bgp routes
> Status Codes: * valid route, > best route
> Origin Codes: i IGP, e EGP, ? incomplete
> 
> ???Prefix? ? ? ? ?
> ? ? ? Nexthop? ? ? ?
> ? ? ? ? ? ? Peer? ?
> ? ? ? ? AS Path
> ???------? ? ? ? ?
> ? ? ? -------? ? ? ?
> ? ? ? ? ? ? ----? ?
> ? ? ? ? -------
> root at ct503-10G-09> show route table ipv4 unicast
> connected
> 2.2.2.0/24??? [connected(0)/0]
> ??? ??? > via
> rddVR6/rddVR6
> 5.1.1.0/24??? [connected(0)/0]
> ??? ??? > via
> rddVR8/rddVR8
> 8.1.2.0/24??? [connected(0)/0]
> ??? ??? > via
> rddVR3/rddVR3
> root at ct503-10G-09> show route table ipv4 unicast ebgp
> root at ct503-10G-09> show route table ipv4 unicast ibgp
> root at ct503-10G-09> show route table ipv4 unicast final
> 0.0.0.0/0??? [static(220)/1]
> ??? ??? > to 0.0.0.0 via
> my_discard/my_discard
> 2.2.2.0/24??? [connected(0)/0]
> ??? ??? > via
> rddVR6/rddVR6
> 5.1.1.0/24??? [connected(0)/0]
> ??? ??? > via
> rddVR8/rddVR8
> 8.1.2.0/24??? [connected(0)/0]
> ??? ??? > via
> rddVR3/rddVR3
> root at ct503-10G-09>
> 
> 
> 
> Config file for this router is below.? The other
> router's config is similar (and farther below)
> /* For Virtual-Router: Router-0 */
> 
> interfaces {
> ? ? interface my_discard {
> ? ? ? ? unreachable: true
> ? ? ? ? vif my_discard {
> ? ? ? ? }
> ? ? }
> 
> ? ? interface "rddVR6" {
> ? ? ? ? vif "rddVR6" {
> ? ? ? ? ? ? address 2.2.2.1
> {
> ? ? ? ? ? ? ? ?
> prefix-length: 24
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> ? ? interface "rddVR8" {
> ? ? ? ? vif "rddVR8" {
> ? ? ? ? ? ? address 5.1.1.1
> {
> ? ? ? ? ? ? ? ?
> prefix-length: 24
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> ? ? interface "rddVR3" {
> ? ? ? ? vif "rddVR3" {
> ? ? ? ? ? ? address 8.1.2.1
> {
> ? ? ? ? ? ? ? ?
> prefix-length: 24
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> }
> 
> fea {
> ? ? unicast-forwarding4 {
> ? ? ? ? disable: false
> ? ? ? ? table-id: 10001
> ? ? }
> }
> 
> policy {
> ? ? policy-statement static-to-bgp {
> ? ? ? ? term export {
> ? ? ? ? ? ? from {
> ? ? ? ? ? ? ? ?
> protocol: "static"
> ? ? ? ? ? ? }
> ? ? ? ? ? ? then {
> ? ? ? ? ? ? ? ?
> metric: 0
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> ? ? policy-statement connected-to-bgp {
> ? ? ? ? term export {
> ? ? ? ? ? ? from {
> ? ? ? ? ? ? ? ?
> protocol: "connected"
> ? ? ? ? ? ? }
> ? ? ? ? ? ? then {
> ? ? ? ? ? ? ? ?
> metric: 0
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> }
> 
> protocols {
> ? ? static {
> ? ? ? ? interface-route 0.0.0.0/0 {
> ? ? ? ? ? ?
> next-hop-interface: "my_discard"
> ? ? ? ? ? ? next-hop-vif:
> "my_discard"
> ? ? ? ? }
> ? ? }
> 
> ? ? ospf4 {
> ? ? ? ? router-id: 127.1.0.1
> ? ? ? ? area 0.0.0.0 {
> ? ? ? ? ? ? interface
> "rddVR6" {
> ? ? ? ? ? ? ? ? vif
> "rddVR6" {
> ? ? ? ? ? ? ? ?
> ? ? address 2.2.2.1 {
> ? ? ? ? ? ? ? ?
> ? ? ???interface-cost: 1
> ? ? ? ? ? ? ? ?
> ? ? }
> ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? }
> 
> ? ? ? ? ? ? interface
> "rddVR3" {
> ? ? ? ? ? ? ? ? vif
> "rddVR3" {
> ? ? ? ? ? ? ? ?
> ? ? address 8.1.2.1 {
> ? ? ? ? ? ? ? ?
> ? ? ???interface-cost: 1
> ? ? ? ? ? ? ? ?
> ? ? }
> ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? }
> 
> ? ? ? ? } /* area */
> 
> ? ? ? ? /* traceoptions {
> ? ? ? ? ? ? flag all {
> ? ? ? ? ? ? ? ?
> disable: false
> ? ? ? ? ? ? }
> ? ? ? ? } */
> ? ? }
> ? ? bgp {
> ? ? ? ? bgp-id: 0.0.0.1
> ? ? ? ? local-as: 1
> ? ? ? ? peer 5.1.1.2 {
> ? ? ? ? ? ? local-ip:
> 5.1.1.1
> ? ? ? ? ? ? /* local-dev:
> "rddVR8" */
> ? ? ? ? ? ? as: 2
> ? ? ? ? ? ? next-hop:
> 5.1.1.2
> ? ? ? ? ? ? holdtime: 5
> ? ? ? ? ? ? delay-open-time:
> 5
> ? ? ? ? ? ? client: false
> ? ? ? ? ? ?
> confederation-member: false
> ? ? ? ? ? ? ipv4-unicast:
> false
> ? ? ? ? ? ? disable: false
> ? ? ? ? }
> ? ? } /* end of bgp4 proto */
> 
> }
> 
>  /* End of Config File */
> 
> Router-2 config:
> 
> /* For Virtual-Router: Router-1 */
> 
> interfaces {
> ? ? interface my_discard {
> ? ? ? ? unreachable: true
> ? ? ? ? vif my_discard {
> ? ? ? ? }
> ? ? }
> 
> ? ? interface "rddVR0" {
> ? ? ? ? vif "rddVR0" {
> ? ? ? ? ? ? address 1.1.1.2
> {
> ? ? ? ? ? ? ? ?
> prefix-length: 24
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> ? ? interface "rddVR13" {
> ? ? ? ? vif "rddVR13" {
> ? ? ? ? ? ? address 4.1.1.2
> {
> ? ? ? ? ? ? ? ?
> prefix-length: 24
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> ? ? interface "rddVR9" {
> ? ? ? ? vif "rddVR9" {
> ? ? ? ? ? ? address 5.1.1.2
> {
> ? ? ? ? ? ? ? ?
> prefix-length: 24
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> }
> 
> fea {
> ? ? unicast-forwarding4 {
> ? ? ? ? disable: false
> ? ? ? ? table-id: 10002
> ? ? }
> }
> 
> policy {
> ? ? policy-statement static-to-bgp {
> ? ? ? ? term export {
> ? ? ? ? ? ? from {
> ? ? ? ? ? ? ? ?
> protocol: "static"
> ? ? ? ? ? ? }
> ? ? ? ? ? ? then {
> ? ? ? ? ? ? ? ?
> metric: 0
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> 
> ? ? policy-statement connected-to-bgp {
> ? ? ? ? term export {
> ? ? ? ? ? ? from {
> ? ? ? ? ? ? ? ?
> protocol: "connected"
> ? ? ? ? ? ? }
> ? ? ? ? ? ? then {
> ? ? ? ? ? ? ? ?
> metric: 0
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
> }
> 
> protocols {
> ? ? static {
> ? ? ? ? interface-route 0.0.0.0/0 {
> ? ? ? ? ? ?
> next-hop-interface: "my_discard"
> ? ? ? ? ? ? next-hop-vif:
> "my_discard"
> ? ? ? ? }
> ? ? }
> 
> ? ? ospf4 {
> ? ? ? ? router-id: 127.1.0.2
> ? ? ? ? area 0.0.0.0 {
> ? ? ? ? ? ? interface
> "rddVR0" {
> ? ? ? ? ? ? ? ? vif
> "rddVR0" {
> ? ? ? ? ? ? ? ?
> ? ? address 1.1.1.2 {
> ? ? ? ? ? ? ? ?
> ? ? ???interface-cost: 1
> ? ? ? ? ? ? ? ?
> ? ? }
> ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? }
> 
> ? ? ? ? ? ? interface
> "rddVR13" {
> ? ? ? ? ? ? ? ? vif
> "rddVR13" {
> ? ? ? ? ? ? ? ?
> ? ? address 4.1.1.2 {
> ? ? ? ? ? ? ? ?
> ? ? ???interface-cost: 1
> ? ? ? ? ? ? ? ?
> ? ? }
> ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? }
> 
> ? ? ? ? } /* area */
> 
> ? ? ? ? /* traceoptions {
> ? ? ? ? ? ? flag all {
> ? ? ? ? ? ? ? ?
> disable: false
> ? ? ? ? ? ? }
> ? ? ? ? } */
> ? ? }
> ? ? bgp {
> ? ? ? ? bgp-id: 0.0.0.2
> ? ? ? ? local-as: 2
> ? ? ? ? peer 5.1.1.1 {
> ? ? ? ? ? ? local-ip:
> 5.1.1.2
> ? ? ? ? ? ? /* local-dev:
> "rddVR9" */
> ? ? ? ? ? ? as: 1
> ? ? ? ? ? ? next-hop:
> 5.1.1.1
> ? ? ? ? ? ? holdtime: 5
> ? ? ? ? ? ? delay-open-time:
> 5
> ? ? ? ? ? ? client: false
> ? ? ? ? ? ?
> confederation-member: false
> ? ? ? ? ? ? ipv4-unicast:
> false
> ? ? ? ? ? ? disable: false
> ? ? ? ? }
> ? ? } /* end of bgp4 proto */
> 
> }
> 
>  /* End of Config File */
> 
> 
> 
> Thanks,
> Ben
> 
> -- Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc? http://www.candelatech.com
> 
> 


      


From greearb at candelatech.com  Tue Apr 20 12:19:43 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Apr 2010 12:19:43 -0700
Subject: [Xorp-hackers] BGP questions
In-Reply-To: <600999.12832.qm@web58706.mail.re1.yahoo.com>
References: <600999.12832.qm@web58706.mail.re1.yahoo.com>
Message-ID: <4BCDFE4F.4070104@candelatech.com>

On 04/20/2010 12:02 PM, Li Zhao wrote:
> I used cisco bgp a lot in the passed. After established, the recieved route number is shown. I have not used xorp to config bgp yet. But remember bgp is not link state protocol like ospf. Only if you have some bgp routes incoming or redistributing igp routes, you won't see bgp routes.
> try to redistribute some static routes, you probably will see something different.

Thanks.  I think I need to read up on policies.

Ben

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


From greearb at candelatech.com  Tue Apr 20 14:00:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Apr 2010 14:00:45 -0700
Subject: [Xorp-hackers] BGP questions
In-Reply-To: <600999.12832.qm@web58706.mail.re1.yahoo.com>
References: <600999.12832.qm@web58706.mail.re1.yahoo.com>
Message-ID: <4BCE15FD.7080209@candelatech.com>

On 04/20/2010 12:02 PM, Li Zhao wrote:
> I used cisco bgp a lot in the passed. After established, the recieved route number is shown. I have not used xorp to config bgp yet. But remember bgp is not link state protocol like ospf. Only if you have some bgp routes incoming or redistributing igp routes, you won't see bgp routes.
> try to redistribute some static routes, you probably will see something different.

Ok, seems it's trying to do something now that I have the policies more
correct:  It crashes on exception because a next-hop is 0.0.0.0:

CorruptMessage from line 325 of bgp/path_attribute.cc -> NextHop 0.0.0.0 is not a unicast address

Guess I'll go digging in the code...

Ben

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


From greearb at candelatech.com  Tue Apr 20 14:59:44 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Apr 2010 14:59:44 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
Message-ID: <4BCE23D0.9040100@candelatech.com>

I seem to have BGP working now, at least to some degree.

I fixed one exception that was thrown when route destination
is 0.0.0.0 (pushed the fix to xorp.ct), and it's included
below.

The rest of my problems were self-inflicted mis-configuration of
the peers and export policies.

I'm attaching two working configurations in hopes they prove
useful to someone.  There may still be issues with these,
but it works enough for BGP to exchange routes and let clients
attached to the two routers send traffic through them.

Here's the fix for 0.0.0.0 destination.  It should also
just catch the exception and ignore the route instead
of crash..but that's a fix for another day.

[greearb at ben-dt2 libxorp]$ git diff
diff --git a/bgp/path_attribute.cc b/bgp/path_attribute.cc
index f1326b2..b82475c 100644
--- a/bgp/path_attribute.cc
+++ b/bgp/path_attribute.cc
@@ -318,7 +318,7 @@ NextHopAttribute<A>::NextHopAttribute(const uint8_t* d)

      _next_hop = A(payload(d));

-    if (!_next_hop.is_unicast())
+    if (!(_next_hop.is_unicast() || _next_hop.is_zero()))
         xorp_throw(CorruptMessage,
                    c_format("NextHop %s is not a unicast address",
                             _next_hop.str().c_str()),


Thanks,
Ben

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp-vr10001.conf
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100420/3142715f/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp-vr10002.conf
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100420/3142715f/attachment-0001.ksh 

From greearb at candelatech.com  Tue Apr 20 21:58:01 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 20 Apr 2010 21:58:01 -0700
Subject: [Xorp-hackers] Anyone have the icsi1.mrtd file?
Message-ID: <4BCE85D9.6080104@candelatech.com>

I'm trying to get the bgp/harness stuff working, and the inject.sh script
references a file "icsi1.mrtd".

I found this reference, but it's not obvious to me how to create
the file from what those links are talking about:
http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-September/002028.html

If anyone has a copy of the icsi1.mrtd file, or knows how to create one
sufficient to stress test bgp, please send me a link (or the file).

Thanks,
Ben

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


From a.greenhalgh at cs.ucl.ac.uk  Wed Apr 21 11:14:29 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Wed, 21 Apr 2010 19:14:29 +0100
Subject: [Xorp-hackers] Tomorrow : Conference Call to co-ordinate XORP going
	forward.
Message-ID: <z2l4769af411004211114y1859f9e3re0f32333db58bc12@mail.gmail.com>

Hi Folks,

Here are the details of the first xorp meeting to decide how xorp
progresses. This email is made up of three parts, attendee list,
agenda and finally at the bottom the conference call details. In
particular please look at the conference call details in advance and
yell if you have a problem with them. Please also take note of the
minutes policy for the call which forms part of the agenda.

The conference call is on Thursday 22nd April at 9pm BST (GMT +1 ) /
1pm PDT. This is tomorrow.

Adam

Attendee List :
===========

Adam Greenhalgh
Eric Johnson
Lin Du
Ben Greear
Fred Bauer
Michael Paisner
Bruce Simpson
Aaron Shang
Mark Handley
Atanu Ghosh

Agenda :
=======

0. (Adam to chair this item)
  - Introductions of those on the call and background.
  - Agree who is to chair the main call, proposal is Mark Handley.
  - Agree who is going to take minutes.

1. Copyright attribution for new changes.
  - Which organisation should possibly hold the new attribution ?
    - UCL
    - a XORP foundation (Do we need to set one up ?)
    - Individual
    - Other

2. LGPL / GPL / BSD license for new changes.

3. Policy for adding committers.

4. What is the patch approval process.

5. Project Management.
  - Who is in charge ?
  - How do we run things going forward ?

6. Tinderbox
  - Current 4 Platforms.
  http://buildbot.cs.ucl.ac.uk:8010/waterfall (and for the xorp-ct
tree http://buildbot.cs.ucl.ac.uk:7010/waterfall )

7. Do we need mirrors ?

8. What is the todo list for the next release (1.7) of XORP.
  - What is required to get the current svn repository out as a release.

9. Is Sourceforge what we need ?

10. Do we need a wiki and bug tracing system ?
    - is the one on Trac sufficient.

11. Mailing list memebership.
    - Should xorp-dev become the xorp committers list ?

12. API stability.

13. Boost usage

14. AOB

Notes : Minutes policy.
----------------------------------

1. Minutes will be written up and circulated to all those on the call

for corrections and amendments. Two working days will be allowed for

corrections.

2. Corrected minutes will be circulated. Two working days will be

allowed for corrections.

3. Minutes will be posted to xorp-hackers.

Conference Call details :
==================

Ben is hosting the call on the Web, using WebEx MeetMeNow.

MEETING PASSWORD: No password
Date: April 22, 2010
Time: 1:00 pm, Pacific Daylight Time (GMT -07:00, San Francisco)
Teleconference: Call-in toll number (US/Canada): 1-650-429-3300
Meeting Number: 941 137 073

Please click on the appropriate link to join the meeting:

ATTENDEE: < https://mwmus.webex.com/mwmus/jm.php?PWD=&MK=941137073 >

HOST: < https://mwmus.webex.com/mwmus/sm.php?PWD=&MK=941137073 >

Ben will try to start it a bit early so folks can join early..and it
can run as long as we want.

*** If you don't have windows, the best solution is to dial in to the
access number above, I am going to dial in from the UK to the access
number using skype. I probably could bridge people in using skype if i
have too. ***


From greearb at candelatech.com  Wed Apr 21 12:07:04 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 21 Apr 2010 12:07:04 -0700
Subject: [Xorp-hackers] [Xorp-users] Anyone have the icsi1.mrtd file?
In-Reply-To: <4BCE85D9.6080104@candelatech.com>
References: <4BCE85D9.6080104@candelatech.com>
Message-ID: <4BCF4CD8.7000801@candelatech.com>

On 04/20/2010 09:58 PM, Ben Greear wrote:
> I'm trying to get the bgp/harness stuff working, and the inject.sh script
> references a file "icsi1.mrtd".
>
> I found this reference, but it's not obvious to me how to create
> the file from what those links are talking about:
> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-September/002028.html
>
> If anyone has a copy of the icsi1.mrtd file, or knows how to create one
> sufficient to stress test bgp, please send me a link (or the file).
>
> Thanks,
> Ben

Nevermind on this..I think I found an acceptable work-around for
my purposes.  One can use 'call_xrl' to 'originate_route4'
and poke a route into bgp.  BGP then updates its peer(s)
accordingly, as far as I can tell.

So, I can script that call_xrl logic and poke in thousands of routes
to do my testing.

Also, I noticed that the bgp/harness logic appears to use a single
callback loop (request, wait for response, do another request, etc)
to load the mrt file, and that is likely to be quite slow since most
of the time processes will be waiting on responses.  Call-xrl isn't
any better in that respect, but it's easier.  And, I could probably
run lots of call-xrl processes in parallel to load routes faster.

Either way, by loading in one bgp router and then letting it peer with a second,
the peer-sync logic should be 100% production xorp code, and can be
optimized/debugged independently of any test harness logic.

Thanks,
Ben

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


From lizhaous2000 at yahoo.com  Wed Apr 21 12:45:44 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Wed, 21 Apr 2010 12:45:44 -0700 (PDT)
Subject: [Xorp-hackers] Tomorrow : Conference Call to co-ordinate XORP
	going forward.
In-Reply-To: <z2l4769af411004211114y1859f9e3re0f32333db58bc12@mail.gmail.com>
Message-ID: <111818.53446.qm@web58705.mail.re1.yahoo.com>

I might dial in the meeting. But my company only has access to toll-free numbers. Don't blame on me. So I can only access the webcast. I guess.

Li

--- On Wed, 4/21/10, Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk> wrote:

> From: Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk>
> Subject: [Xorp-hackers] Tomorrow : Conference Call to co-ordinate XORP going forward.
> To: xorp-hackers at xorp.org, xorp-dev at xorp.org
> Date: Wednesday, April 21, 2010, 2:14 PM
> Hi Folks,
> 
> Here are the details of the first xorp meeting to decide
> how xorp
> progresses. This email is made up of three parts, attendee
> list,
> agenda and finally at the bottom the conference call
> details. In
> particular please look at the conference call details in
> advance and
> yell if you have a problem with them. Please also take note
> of the
> minutes policy for the call which forms part of the
> agenda.
> 
> The conference call is on Thursday 22nd April at 9pm BST
> (GMT +1 ) /
> 1pm PDT. This is tomorrow.
> 
> Adam
> 
> Attendee List :
> ===========
> 
> Adam Greenhalgh
> Eric Johnson
> Lin Du
> Ben Greear
> Fred Bauer
> Michael Paisner
> Bruce Simpson
> Aaron Shang
> Mark Handley
> Atanu Ghosh
> 
> Agenda :
> =======
> 
> 0. (Adam to chair this item)
> ? - Introductions of those on the call and
> background.
> ? - Agree who is to chair the main call, proposal is
> Mark Handley.
> ? - Agree who is going to take minutes.
> 
> 1. Copyright attribution for new changes.
> ? - Which organisation should possibly hold the new
> attribution ?
> ? ? - UCL
> ? ? - a XORP foundation (Do we need to set one up
> ?)
> ? ? - Individual
> ? ? - Other
> 
> 2. LGPL / GPL / BSD license for new changes.
> 
> 3. Policy for adding committers.
> 
> 4. What is the patch approval process.
> 
> 5. Project Management.
> ? - Who is in charge ?
> ? - How do we run things going forward ?
> 
> 6. Tinderbox
> ? - Current 4 Platforms.
> ? http://buildbot.cs.ucl.ac.uk:8010/waterfall (and for
> the xorp-ct
> tree http://buildbot.cs.ucl.ac.uk:7010/waterfall )
> 
> 7. Do we need mirrors ?
> 
> 8. What is the todo list for the next release (1.7) of
> XORP.
> ? - What is required to get the current svn repository
> out as a release.
> 
> 9. Is Sourceforge what we need ?
> 
> 10. Do we need a wiki and bug tracing system ?
> ? ? - is the one on Trac sufficient.
> 
> 11. Mailing list memebership.
> ? ? - Should xorp-dev become the xorp committers
> list ?
> 
> 12. API stability.
> 
> 13. Boost usage
> 
> 14. AOB
> 
> Notes : Minutes policy.
> ----------------------------------
> 
> 1. Minutes will be written up and circulated to all those
> on the call
> 
> for corrections and amendments. Two working days will be
> allowed for
> 
> corrections.
> 
> 2. Corrected minutes will be circulated. Two working days
> will be
> 
> allowed for corrections.
> 
> 3. Minutes will be posted to xorp-hackers.
> 
> Conference Call details :
> ==================
> 
> Ben is hosting the call on the Web, using WebEx MeetMeNow.
> 
> MEETING PASSWORD: No password
> Date: April 22, 2010
> Time: 1:00 pm, Pacific Daylight Time (GMT -07:00, San
> Francisco)
> Teleconference: Call-in toll number (US/Canada):
> 1-650-429-3300
> Meeting Number: 941 137 073
> 
> Please click on the appropriate link to join the meeting:
> 
> ATTENDEE: < https://mwmus.webex.com/mwmus/jm.php?PWD=&MK=941137073
> >
> 
> HOST: < https://mwmus.webex.com/mwmus/sm.php?PWD=&MK=941137073
> >
> 
> Ben will try to start it a bit early so folks can join
> early..and it
> can run as long as we want.
> 
> *** If you don't have windows, the best solution is to dial
> in to the
> access number above, I am going to dial in from the UK to
> the access
> number using skype. I probably could bridge people in using
> skype if i
> have too. ***
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From M.Handley at cs.ucl.ac.uk  Wed Apr 21 15:15:42 2010
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Wed, 21 Apr 2010 23:15:42 +0100
Subject: [Xorp-hackers] Anyone have the icsi1.mrtd file?
In-Reply-To: <4BCE85D9.6080104@candelatech.com>
References: <4BCE85D9.6080104@candelatech.com>
Message-ID: <r2y84a612dd1004211515ka92870xa94c5d3dca356ff1@mail.gmail.com>

Ben,

I've put the file here:
http://www.xorp.org/data/bgp/icsi1.mrtd

Cheers,
Mark

On 21 April 2010 05:58, Ben Greear <greearb at candelatech.com> wrote:
> I'm trying to get the bgp/harness stuff working, and the inject.sh script
> references a file "icsi1.mrtd".
>
> I found this reference, but it's not obvious to me how to create
> the file from what those links are talking about:
> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-September/002028.html
>
> If anyone has a copy of the icsi1.mrtd file, or knows how to create one
> sufficient to stress test bgp, please send me a link (or the file).
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Wed Apr 21 15:41:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 21 Apr 2010 15:41:45 -0700
Subject: [Xorp-hackers] BGP and exceptions
Message-ID: <4BCF7F29.4050001@candelatech.com>

Hello!

It seems that pretty much any invalid data (using mcast addr for
next-hop, for instance), will cause xorp_bgp to throw an exception
and crash.

Since you don't even get a useful stack-trace out of the exception
crashes, and since the attribute decode logic is typically ~20 stack frames
deep, it's very difficult to debug the cause of the exceptions and to
figure out where to add appropriate catch() logic.

Does anyone have any strong attraction to using exceptions, or can
we move to returning NULL and/or checking an 'is_valid()' flag
on the attributes instead of throwing lots of exceptions?

Thanks,
Ben

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


From bms at incunabulum.net  Thu Apr 22 02:23:27 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 22 Apr 2010 10:23:27 +0100
Subject: [Xorp-hackers] BGP and exceptions
In-Reply-To: <4BCF7F29.4050001@candelatech.com>
References: <4BCF7F29.4050001@candelatech.com>
Message-ID: <4BD0158F.2080203@incunabulum.net>

Ben Greear wrote:
...
> Since you don't even get a useful stack-trace out of the exception
> crashes, and since the attribute decode logic is typically ~20 stack frames
> deep, it's very difficult to debug the cause of the exceptions and to
> figure out where to add appropriate catch() logic.

Perhaps finishing the backtrace() facility would help.

I have run into this issue myself on some current work, the trouble is
getting clients to run code out of SVN may still be asking too much--
although some shops do have enough in-house talent to swing it.

Our policy of not implementing release branches has worked against us
here, however, that was not a policy I instituted; there just haven't
been enough people working full-time on the code to justify it outside
of the company.

> Does anyone have any strong attraction to using exceptions, or can
> we move to returning NULL and/or checking an 'is_valid()' flag
> on the attributes instead of throwing lots of exceptions?

It's how we've always done things, as it's a good use of the language
and helps to cut down on cluttering the code with conditionals.

+1 for staying with exceptions.


From bms at incunabulum.net  Thu Apr 22 02:24:18 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 22 Apr 2010 10:24:18 +0100
Subject: [Xorp-hackers] BGP and exceptions
In-Reply-To: <4BCF7F29.4050001@candelatech.com>
References: <4BCF7F29.4050001@candelatech.com>
Message-ID: <4BD015C2.5080800@incunabulum.net>

Ben Greear wrote:

> Since you don't even get a useful stack-trace out of the exception
> crashes, and since the attribute decode logic is typically ~20 stack frames
> deep, it's very difficult to debug the cause of the exceptions and to
> figure out where to add appropriate catch() logic.

BTW I find code navigators e.g. KScope, Red Hat Source Navigators are
very useful for debugging and understanding real large C++ systems such
as XORP


From a.greenhalgh at cs.ucl.ac.uk  Thu Apr 22 03:17:36 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Thu, 22 Apr 2010 11:17:36 +0100
Subject: [Xorp-hackers] BGP and exceptions
In-Reply-To: <4BD0158F.2080203@incunabulum.net>
References: <4BCF7F29.4050001@candelatech.com>
	<4BD0158F.2080203@incunabulum.net>
Message-ID: <o2u4769af411004220317u1da3db53k1a2f0db8a6d1a11d@mail.gmail.com>

Its this type of discussion that should probably occur on the
teleconferences after we've got the first one out of the way.

adam

On 22 April 2010 10:23, Bruce Simpson <bms at incunabulum.net> wrote:
> Ben Greear wrote:
> ...
>> Since you don't even get a useful stack-trace out of the exception
>> crashes, and since the attribute decode logic is typically ~20 stack frames
>> deep, it's very difficult to debug the cause of the exceptions and to
>> figure out where to add appropriate catch() logic.
>
> Perhaps finishing the backtrace() facility would help.
>
> I have run into this issue myself on some current work, the trouble is
> getting clients to run code out of SVN may still be asking too much--
> although some shops do have enough in-house talent to swing it.
>
> Our policy of not implementing release branches has worked against us
> here, however, that was not a policy I instituted; there just haven't
> been enough people working full-time on the code to justify it outside
> of the company.
>
>> Does anyone have any strong attraction to using exceptions, or can
>> we move to returning NULL and/or checking an 'is_valid()' flag
>> on the attributes instead of throwing lots of exceptions?
>
> It's how we've always done things, as it's a good use of the language
> and helps to cut down on cluttering the code with conditionals.
>
> +1 for staying with exceptions.
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From lizhaous2000 at yahoo.com  Thu Apr 22 06:19:59 2010
From: lizhaous2000 at yahoo.com (Li Zhao)
Date: Thu, 22 Apr 2010 06:19:59 -0700 (PDT)
Subject: [Xorp-hackers] BGP and exceptions
In-Reply-To: <4BD015C2.5080800@incunabulum.net>
Message-ID: <412720.11059.qm@web58704.mail.re1.yahoo.com>

I used cscope for many many years.

--- On Thu, 4/22/10, Bruce Simpson <bms at incunabulum.net> wrote:

> From: Bruce Simpson <bms at incunabulum.net>
> Subject: Re: [Xorp-hackers] BGP and exceptions
> To: "Ben Greear" <greearb at candelatech.com>
> Cc: "xorp" <xorp-hackers at xorp.org>
> Date: Thursday, April 22, 2010, 5:24 AM
> Ben Greear wrote:
> 
> > Since you don't even get a useful stack-trace out of
> the exception
> > crashes, and since the attribute decode logic is
> typically ~20 stack frames
> > deep, it's very difficult to debug the cause of the
> exceptions and to
> > figure out where to add appropriate catch() logic.
> 
> BTW I find code navigators e.g. KScope, Red Hat Source
> Navigators are
> very useful for debugging and understanding real large C++
> systems such
> as XORP
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      


From a.greenhalgh at cs.ucl.ac.uk  Thu Apr 22 06:55:29 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Thu, 22 Apr 2010 14:55:29 +0100
Subject: [Xorp-hackers] TODAY : Conference Call to co-ordinate XORP going
	forward
Message-ID: <q2i4769af411004220655jf8a7d292h35d403ac15618d0b@mail.gmail.com>

Hi Folks,

Here are the details of the first xorp meeting to decide how xorp
progresses. This email is made up of three parts, attendee list,
agenda and finally at the bottom the conference call details. In
particular please look at the conference call details in advance and
yell if you have a problem with them. Please also take note of the
minutes policy for the call which forms part of the agenda.

The conference call is on Thursday 22nd April at 9pm BST (GMT +1 ) /
1pm PDT. This is TODAY.

Adam

Attendee List :
===========

Adam Greenhalgh
Eric Johnson
Lin Du
Ben Greear
Fred Bauer
Michael Paisner
Bruce Simpson
Aaron Shang
Mark Handley
Atanu Ghosh

Agenda :
=======

0. (Adam to chair this item)
 - Introductions of those on the call and background.
 - Agree who is to chair the main call, proposal is Mark Handley.
 - Agree who is going to take minutes.

1. Copyright attribution for new changes.
 - Which organisation should possibly hold the new attribution ?
   - UCL
   - a XORP foundation (Do we need to set one up ?)
   - Individual
   - Other

2. LGPL / GPL / BSD license for new changes.

3. Policy for adding committers.

4. What is the patch approval process.

5. Project Management.
 - Who is in charge ?
 - How do we run things going forward ?

6. Tinderbox
 - Current 4 Platforms.
 http://buildbot.cs.ucl.ac.uk:8010/waterfall (and for the xorp-ct
tree http://buildbot.cs.ucl.ac.uk:7010/waterfall )

7. Do we need mirrors ?

8. What is the todo list for the next release (1.7) of XORP.
 - What is required to get the current svn repository out as a release.

9. Is Sourceforge what we need ?

10. Do we need a wiki and bug tracing system ?
   - is the one on Trac sufficient.

11. Mailing list memebership.
   - Should xorp-dev become the xorp committers list ?

12. API stability.

13. Boost usage

14. AOB

Notes : Minutes policy.
----------------------------------

1. Minutes will be written up and circulated to all those on the call

for corrections and amendments. Two working days will be allowed for

corrections.

2. Corrected minutes will be circulated. Two working days will be

allowed for corrections.

3. Minutes will be posted to xorp-hackers.

Conference Call details :
==================

Ben is hosting the call on the Web, using WebEx MeetMeNow.

MEETING PASSWORD: No password
Date: April 22, 2010
Time: 1:00 pm, Pacific Daylight Time (GMT -07:00, San Francisco)
Teleconference: Call-in toll number (US/Canada): 1-650-429-3300
Meeting Number: 941 137 073

Please click on the appropriate link to join the meeting:

ATTENDEE: < https://mwmus.webex.com/mwmus/jm.php?PWD=&MK=941137073 >

HOST: < https://mwmus.webex.com/mwmus/sm.php?PWD=&MK=941137073 >

Ben will try to start it a bit early so folks can join early..and it
can run as long as we want.

*** If you don't have windows, the best solution is to dial in to the
access number above, I am going to dial in from the UK to the access
number using skype. I probably could bridge people in using skype if i
have too. ***


From atanu at xorp.org  Thu Apr 22 08:41:14 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Thu, 22 Apr 2010 08:41:14 -0700
Subject: [Xorp-hackers] Anyone have the icsi1.mrtd file?
In-Reply-To: <r2y84a612dd1004211515ka92870xa94c5d3dca356ff1@mail.gmail.com>
References: <4BCE85D9.6080104@candelatech.com>
	<r2y84a612dd1004211515ka92870xa94c5d3dca356ff1@mail.gmail.com>
Message-ID: <i2l9a09c93f1004220841s7021c8e3sad3c67a9249d9651@mail.gmail.com>

Hi,

It already seems to be in the tree:
URL: https://xorp.svn.sourceforge.net/svnroot/xorp/trunk/data/bgp/icsi1.mrtd
Repository Root: https://xorp.svn.sourceforge.net/svnroot/xorp
Repository UUID: 26435e26-4b25-483a-942d-477236992e84
Revision: 11694
Node Kind: file
Schedule: normal
Last Changed Author: atanu
Last Changed Rev: 266
Last Changed Date: 2003-01-28 21:15:49 -0800 (Tue, 28 Jan 2003)
Text Last Updated: 2010-03-09 21:11:10 -0800 (Tue, 09 Mar 2010)
Checksum: a59aaee0095db9ff6d344b1cccbfaecf

On Wed, Apr 21, 2010 at 3:15 PM, Mark Handley <M.Handley at cs.ucl.ac.uk> wrote:
> Ben,
>
> I've put the file here:
> http://www.xorp.org/data/bgp/icsi1.mrtd
>
> Cheers,
> Mark
>
> On 21 April 2010 05:58, Ben Greear <greearb at candelatech.com> wrote:
>> I'm trying to get the bgp/harness stuff working, and the inject.sh script
>> references a file "icsi1.mrtd".
>>
>> I found this reference, but it's not obvious to me how to create
>> the file from what those links are talking about:
>> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-September/002028.html
>>
>> If anyone has a copy of the icsi1.mrtd file, or knows how to create one
>> sufficient to stress test bgp, please send me a link (or the file).
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc ?http://www.candelatech.com
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Thu Apr 22 08:43:27 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 08:43:27 -0700
Subject: [Xorp-hackers] BGP and exceptions
In-Reply-To: <4BD0158F.2080203@incunabulum.net>
References: <4BCF7F29.4050001@candelatech.com>
	<4BD0158F.2080203@incunabulum.net>
Message-ID: <4BD06E9F.2060503@candelatech.com>

On 04/22/2010 02:23 AM, Bruce Simpson wrote:
> Ben Greear wrote:

>> Does anyone have any strong attraction to using exceptions, or can
>> we move to returning NULL and/or checking an 'is_valid()' flag
>> on the attributes instead of throwing lots of exceptions?
>
> It's how we've always done things, as it's a good use of the language
> and helps to cut down on cluttering the code with conditionals.

I'm not sure about the conditionals thing.  Sure, the bgp code is clean of
conditionals..but to be stable and robust, we'll have to add a lot of
try / catch logic, and since we currently get no useful backtraces of
what call chain caused the exception, debugging each instance is slow
and painful, even if you have a reproducible test case.

A functional backtrace logic would be very useful, but it would have
to be fast enough that it could run in the hot path to keep someone
from being able to DOS the box into submission with faulty input
that throws exceptions.

Maybe if the backtrace work was only done when we have an un-caught exception
or otherwise explicitly wanted to print out the backtrace, it would be fine.

> +1 for staying with exceptions.

I'll work with them for now...

Thanks,
Ben

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


From atanu at xorp.org  Thu Apr 22 08:52:43 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Thu, 22 Apr 2010 08:52:43 -0700
Subject: [Xorp-hackers] [Xorp-users] Anyone have the icsi1.mrtd file?
In-Reply-To: <4BCF4CD8.7000801@candelatech.com>
References: <4BCE85D9.6080104@candelatech.com>
	<4BCF4CD8.7000801@candelatech.com>
Message-ID: <i2h9a09c93f1004220852x3668822dh8d9d9ab5c08c810e@mail.gmail.com>

Hi,

For testing rather than introduce routes directly into BGP we build a
test harness that we used to peer with the BGP process under test
bgp/harness/harness.py is probably the simplest example of how to
inject or extract routes from a bgp process.

        Atanu.

On Wed, Apr 21, 2010 at 12:07 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 04/20/2010 09:58 PM, Ben Greear wrote:
>> I'm trying to get the bgp/harness stuff working, and the inject.sh script
>> references a file "icsi1.mrtd".
>>
>> I found this reference, but it's not obvious to me how to create
>> the file from what those links are talking about:
>> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-September/002028.html
>>
>> If anyone has a copy of the icsi1.mrtd file, or knows how to create one
>> sufficient to stress test bgp, please send me a link (or the file).
>>
>> Thanks,
>> Ben
>
> Nevermind on this..I think I found an acceptable work-around for
> my purposes. ?One can use 'call_xrl' to 'originate_route4'
> and poke a route into bgp. ?BGP then updates its peer(s)
> accordingly, as far as I can tell.
>
> So, I can script that call_xrl logic and poke in thousands of routes
> to do my testing.
>
> Also, I noticed that the bgp/harness logic appears to use a single
> callback loop (request, wait for response, do another request, etc)
> to load the mrt file, and that is likely to be quite slow since most
> of the time processes will be waiting on responses. ?Call-xrl isn't
> any better in that respect, but it's easier. ?And, I could probably
> run lots of call-xrl processes in parallel to load routes faster.
>
> Either way, by loading in one bgp router and then letting it peer with a second,
> the peer-sync logic should be 100% production xorp code, and can be
> optimized/debugged independently of any test harness logic.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From atanu at xorp.org  Thu Apr 22 09:02:46 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Thu, 22 Apr 2010 09:02:46 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <4BCE23D0.9040100@candelatech.com>
References: <4BCE23D0.9040100@candelatech.com>
Message-ID: <s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>

Hi,

The test for the nexthop being zero is in
FastPathAttributeList<A>::load_raw_data:

                // if there's an NLRI, there must be a non-zero nexthop
                if (do_checks && mp4_reach_att->nexthop() == IPv4::ZERO()) {
                    uint8_t data = NEXT_HOP;
                    xorp_throw(CorruptMessage,"Illegal nexthop", UPDATEMSGERR,
                               MISSWATTR, &data, 1);
                }

I don't know why it isn't being caught here.

       Atanu.

On Tue, Apr 20, 2010 at 2:59 PM, Ben Greear <greearb at candelatech.com> wrote:
> I seem to have BGP working now, at least to some degree.
>
> I fixed one exception that was thrown when route destination
> is 0.0.0.0 (pushed the fix to xorp.ct), and it's included
> below.
>
> The rest of my problems were self-inflicted mis-configuration of
> the peers and export policies.
>
> I'm attaching two working configurations in hopes they prove
> useful to someone. ?There may still be issues with these,
> but it works enough for BGP to exchange routes and let clients
> attached to the two routers send traffic through them.
>
> Here's the fix for 0.0.0.0 destination. ?It should also
> just catch the exception and ignore the route instead
> of crash..but that's a fix for another day.
>
> [greearb at ben-dt2 libxorp]$ git diff
> diff --git a/bgp/path_attribute.cc b/bgp/path_attribute.cc
> index f1326b2..b82475c 100644
> --- a/bgp/path_attribute.cc
> +++ b/bgp/path_attribute.cc
> @@ -318,7 +318,7 @@ NextHopAttribute<A>::NextHopAttribute(const uint8_t* d)
>
> ? ? _next_hop = A(payload(d));
>
> - ? ?if (!_next_hop.is_unicast())
> + ? ?if (!(_next_hop.is_unicast() || _next_hop.is_zero()))
> ? ? ? ?xorp_throw(CorruptMessage,
> ? ? ? ? ? ? ? ? ? c_format("NextHop %s is not a unicast address",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?_next_hop.str().c_str()),
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>


From greearb at candelatech.com  Thu Apr 22 09:13:58 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 09:13:58 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
References: <4BCE23D0.9040100@candelatech.com>
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
Message-ID: <4BD075C6.9040903@candelatech.com>

On 04/22/2010 09:02 AM, Atanu Ghosh wrote:
> Hi,
>
> The test for the nexthop being zero is in
> FastPathAttributeList<A>::load_raw_data:
>
>                  // if there's an NLRI, there must be a non-zero nexthop
>                  if (do_checks&&  mp4_reach_att->nexthop() == IPv4::ZERO()) {
>                      uint8_t data = NEXT_HOP;
>                      xorp_throw(CorruptMessage,"Illegal nexthop", UPDATEMSGERR,
>                                 MISSWATTR,&data, 1);
>                  }
>
> I don't know why it isn't being caught here.

 From debugging yesterday, it seems that routes can get into the route entry cache
that are invalid (multicast addr for next-hop, for instance), but they
are not immediately parsed.  As soon as they *are* parsed and verified,
the exception is thrown.

For the 0.0.0.0 nexthop, I have an explicit null default gw route configured
in Xorp.  I didn't have to do any funny external xrl calls to get that exception
to happen..probably loading a similar config as what I posted would reproduce
the problem for you.

Thanks,
Ben

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


From greearb at candelatech.com  Thu Apr 22 09:58:49 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 09:58:49 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
References: <4BCE23D0.9040100@candelatech.com>
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
Message-ID: <4BD08049.9000506@candelatech.com>

On 04/22/2010 09:02 AM, Atanu Ghosh wrote:
> Hi,
>
> The test for the nexthop being zero is in
> FastPathAttributeList<A>::load_raw_data:
>
>                  // if there's an NLRI, there must be a non-zero nexthop
>                  if (do_checks&&  mp4_reach_att->nexthop() == IPv4::ZERO()) {
>                      uint8_t data = NEXT_HOP;
>                      xorp_throw(CorruptMessage,"Illegal nexthop", UPDATEMSGERR,
>                                 MISSWATTR,&data, 1);
>                  }
>
> I don't know why it isn't being caught here.

I need to back out a few of my hacks I think.  Can you confirm that this
patch is a bad idea?  Ie, is it always invalid to have a 0.0.0.0 nexthop
in BGP?

@@ -318,7 +318,7 @@ NextHopAttribute<A>::NextHopAttribute(const uint8_t* d)

      _next_hop = A(payload(d));

-    if (!_next_hop.is_unicast())
+    if (!(_next_hop.is_unicast() || _next_hop.is_zero()))
  	xorp_throw(CorruptMessage,
  		   c_format("NextHop %s is not a unicast address",
  			    _next_hop.str().c_str()),



Also, does this patch look correct and useful?  It catches
some of the exceptions that were crashing bgp.  Or maybe this
logic should go higher..ie try/catch around the xrl input handling code?

@@ -1069,7 +1069,14 @@ BGPPlumbingAF<A>::add_route(const IPNet<A>& net,
  		   pretty_string_safi(_master.safi()));

      rib_in = iter->second;
-    result = rib_in->add_route(net, pa_list, policy_tags);
+    try {
+	result = rib_in->add_route(net, pa_list, policy_tags);
+    }
+    catch(XorpException &e) {
+	XLOG_WARNING("Exception in add_route: %s, assuming failure\n",
+		     e.str().c_str());
+	result = ADD_FAILURE;
+    }

      if (result == ADD_USED || result == ADD_UNUSED) {
  	_awaits_push = true;


Thanks,
Ben

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


From greearb at candelatech.com  Thu Apr 22 10:10:24 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 10:10:24 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
References: <4BCE23D0.9040100@candelatech.com>
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
Message-ID: <4BD08300.3010907@candelatech.com>

On 04/22/2010 09:02 AM, Atanu Ghosh wrote:
> Hi,
>
> The test for the nexthop being zero is in
> FastPathAttributeList<A>::load_raw_data:
>
>                  // if there's an NLRI, there must be a non-zero nexthop
>                  if (do_checks&&  mp4_reach_att->nexthop() == IPv4::ZERO()) {
>                      uint8_t data = NEXT_HOP;
>                      xorp_throw(CorruptMessage,"Illegal nexthop", UPDATEMSGERR,
>                                 MISSWATTR,&data, 1);
>                  }
>
> I don't know why it isn't being caught here.

Here is a stack trace of an assert when next-hop was 0.0.0.0.
(I added the assert instead of throwing an exception for debugging
purposes).

It's hard to tell exactly, but I think this is the case that
triggers the un-caught exception as well.  Any ideas on where
the exception should be caught?

#0  0x0000003b07c332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
warning: (Internal error: pc 0x7f2b72192dec in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x7f2b72192620 in read in psymtab, but not in symtab.)

#0  0x0000003b07c332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0000003b07c34b20 in *__GI_abort () at abort.c:88
#2  0x00007f2b707e16bd in xlog_fatal (module_name=0x7f2b721b3ef5 "BGP", line=<value optimized out>, file=<value optimized out>,
     function=<value optimized out>, fmt=0x7f2b70802f2c "Assertion (%s) failed") at libxorp/xlog.c:467
#3  0x00007f2b707e175d in xlog_assert (module_name=0x1902 <Address 0x1902 out of bounds>, line=6402, file=0x6 <Address 0x6 out of bounds>,
     function=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>, failedexpr=<value optimized out>) at libxorp/xlog.c:480
#4  0x00007f2b7210eda6 in NextHopAttribute<IPv4>::NextHopAttribute (this=0x2229360, d=0x22288c0 "@\3\4") at bgp/path_attribute.cc:321
#5  0x00007f2b7210666a in PathAttribute::create (d=0x22288c0 "@\3\4", max_len=<value optimized out>, l=@0x7fffc5af5fb8,
     peerdata=<value optimized out>, ip_version=<value optimized out>) at bgp/path_attribute.cc:1733
#6  0x00007f2b7211157e in FastPathAttributeList<IPv4>::find_attribute_by_type (this=0x223ad40, type=<value optimized out>)
     at bgp/path_attribute.cc:3116
#7  0x00007f2b72111692 in FastPathAttributeList<IPv4>::nexthop_att (this=0x1902) at bgp/path_attribute.cc:2693
#8  0x00007f2b721116a1 in FastPathAttributeList<IPv4>::nexthop (this=0x1902) at bgp/path_attribute.cc:2699
#9  0x00007f2b72179e34 in NexthopRewriteFilter<IPv4>::filter (this=0x22291e0, rtmsg=@0x7fffc5af6360) at bgp/route_table_filter.cc:200
#10 0x00007f2b72176ffe in FilterVersion<IPv4>::apply_filters (this=0x21da6d0, rtmsg=@0x7fffc5af6360, ref_change=1)
     at bgp/route_table_filter.cc:747
#11 0x00007f2b721796d0 in FilterTable<IPv4>::apply_filters (this=0x2228cd0, rtmsg=@0x7fffc5af6360, ref_change=1)
     at bgp/route_table_filter.cc:1159
#12 0x00007f2b72179a15 in FilterTable<IPv4>::add_route (this=0x2228cd0, rtmsg=@0x7fffc5af6360, caller=<value optimized out>)
     at bgp/route_table_filter.cc:820
#13 0x00007f2b7216c2c1 in DumpTable<IPv4>::route_dump (this=0x222b400, rtmsg=@0x7fffc5af6360, caller=<value optimized out>,
     dump_peer=<value optimized out>) at bgp/route_table_dump.cc:193
#14 0x00007f2b7217213c in FanoutTable<IPv4>::route_dump (this=0x21f9f30, rtmsg=@0x7fffc5af6360, caller=<value optimized out>, dump_peer=
     0x21d8830) at bgp/route_table_fanout.cc:409
#15 0x00007f2b7213d2fc in AggregationTable<IPv4>::route_dump (this=0x21f9ea0, rtmsg=@0x7fffc5af6360, caller=<value optimized out>,
     dump_peer=<value optimized out>) at bgp/route_table_aggregation.cc:660
#16 0x00007f2b7218381e in PolicyTable<IPv4>::route_dump (this=0x21f89b0, rtmsg=@0x7fffc5af6360, caller=<value optimized out>,
     dump_peer=0x21d8830) at bgp/route_table_policy.cc:300
#17 0x00007f2b7215d6a0 in DecisionTable<IPv4>::route_dump (this=0x21f7f30, rtmsg=@0x7fffc5af6360, peer=0x21d8830)
     at bgp/route_table_decision.cc:866
#18 0x00007f2b72148650 in BGPRouteTable<IPv4>::route_dump (this=0x21f6db0, rtmsg=@0x7fffc5af6360, peer=0x21d8830)
     at bgp/route_table_base.cc:59
#19 0x00007f2b72155255 in CacheTable<IPv4>::route_dump (this=0x21fa7a0, rtmsg=<value optimized out>, caller=<value optimized out>,
     dump_peer=0x21d8830) at bgp/route_table_cache.cc:402
---Type <return> to continue, or q <return> to quit---
#20 0x00007f2b7218381e in PolicyTable<IPv4>::route_dump (this=0x21fa090, rtmsg=@0x7fffc5af65a0, caller=<value optimized out>,
     dump_peer=0x21d8830) at bgp/route_table_policy.cc:300
#21 0x00007f2b7218506e in PolicyTableImport<IPv4>::route_dump (this=0x21fa090, rtmsg=@0x7fffc5af65a0, caller=0x6,
     dump_peer=0xffffffffffffffff) at bgp/route_table_policy_im.cc:56
#22 0x00007f2b721797c1 in FilterTable<IPv4>::route_dump (this=0x21fa260, rtmsg=@0x7fffc5af65a0, caller=<value optimized out>,
     dump_peer=0x21d8830) at bgp/route_table_filter.cc:895
#23 0x00007f2b72192ded in RibInTable<IPv4>::dump_next_route (this=<value optimized out>, dump_iter=<value optimized out>)
     at bgp/route_table_ribin.cc:374
#24 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21fa260, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
#25 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21fa090, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
#26 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21fa7a0, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
#27 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21f6db0, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
#28 0x00007f2b7215d630 in DecisionTable<IPv4>::dump_next_route (this=<value optimized out>, dump_iter=@0x222b430)
     at bgp/route_table_decision.cc:857
#29 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21f89b0, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
#30 0x00007f2b72147699 in AggregationTable<IPv4>::dump_next_route (this=<value optimized out>, dump_iter=@0x222b430)
     at bgp/route_table_aggregation.cc:568
#31 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21f9f30, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
#32 0x00007f2b7216ad3f in DumpTable<IPv4>::do_next_route_dump (this=0x222b400) at bgp/route_table_dump.cc:358
#33 0x00007f2b7216aef7 in DumpTable<IPv4>::get_next_message (this=0x222b400, next_table=<value optimized out>)
     at bgp/route_table_dump.cc:413
#34 0x00007f2b72177ab5 in FilterTable<IPv4>::get_next_message (this=0x2228cd0, next_table=0x2226a70) at bgp/route_table_filter.cc:1196
#35 0x00007f2b72182e55 in PolicyTable<IPv4>::get_next_message (this=0x2226a70, next_table=0x21da840) at bgp/route_table_policy.cc:395
#36 0x00007f2b72193f8f in RibOutTable<IPv4>::pull_next_route (this=0x21da840) at bgp/route_table_ribout.cc:422
#37 0x00007f2b721940c3 in XorpMemberCallback0B0<bool, RibOutTable<IPv4> >::dispatch (this=<value optimized out>)
     at ./libxorp/callback_nodebug.hh:286
#38 0x00007f2b707f955e in RepeatedTaskNode2::run (this=<value optimized out>, xorp_task=@0x1902) at libxorp/task.cc:122
#39 0x00007f2b707f8937 in TaskList::run (this=<value optimized out>) at libxorp/task.cc:231
#40 0x00007f2b707e54dc in EventLoop::do_work (this=0x7fffc5af6b70, can_block=<value optimized out>) at libxorp/eventloop.cc:133
#41 0x00007f2b707e55c8 in EventLoop::run (this=0x7fffc5af6b70) at libxorp/eventloop.cc:96
#42 0x00007f2b720bbb15 in BGPMain::main_loop (this=0x7fffc5af7060) at bgp/bgp.cc:758
#43 0x00000000004015f8 in main (argv=0x7fffc5af73d8) at bgp/main.cc:93
Current language:  auto; currently minimal


Thanks,
Ben

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


From atanu at xorp.org  Thu Apr 22 10:37:30 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Thu, 22 Apr 2010 10:37:30 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <4BD08300.3010907@candelatech.com>
References: <4BCE23D0.9040100@candelatech.com>
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
	<4BD08300.3010907@candelatech.com>
Message-ID: <n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>

Hi,

The original code caught all exceptions from bad update packets in
peer.cc:BGPPeer::get_message. At the bottom of this routine you can
see the CorruptMessage exceptions being caught and the notification
being sent to the peer.

Your stack backtrace looks like the current code does not check the
update packet for sanity but just queues it, then later when the
packet is being processed it notices a problem and throws an
exception, which is not caught. Temporarily you could try catching the
exceptions around pull_next_route in the RibOutTable.

       Atanu.

On Thu, Apr 22, 2010 at 10:10 AM, Ben Greear <greearb at candelatech.com> wrote:
> On 04/22/2010 09:02 AM, Atanu Ghosh wrote:
>> Hi,
>>
>> The test for the nexthop being zero is in
>> FastPathAttributeList<A>::load_raw_data:
>>
>> ? ? ? ? ? ? ? ? ?// if there's an NLRI, there must be a non-zero nexthop
>> ? ? ? ? ? ? ? ? ?if (do_checks&& ?mp4_reach_att->nexthop() == IPv4::ZERO()) {
>> ? ? ? ? ? ? ? ? ? ? ?uint8_t data = NEXT_HOP;
>> ? ? ? ? ? ? ? ? ? ? ?xorp_throw(CorruptMessage,"Illegal nexthop", UPDATEMSGERR,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? MISSWATTR,&data, 1);
>> ? ? ? ? ? ? ? ? ?}
>>
>> I don't know why it isn't being caught here.
>
> Here is a stack trace of an assert when next-hop was 0.0.0.0.
> (I added the assert instead of throwing an exception for debugging
> purposes).
>
> It's hard to tell exactly, but I think this is the case that
> triggers the un-caught exception as well. ?Any ideas on where
> the exception should be caught?
>
> #0 ?0x0000003b07c332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 ? ? ? ?return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> warning: (Internal error: pc 0x7f2b72192dec in read in psymtab, but not in symtab.)
>
> warning: (Internal error: pc 0x7f2b72192620 in read in psymtab, but not in symtab.)
>
> #0 ?0x0000003b07c332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 ?0x0000003b07c34b20 in *__GI_abort () at abort.c:88
> #2 ?0x00007f2b707e16bd in xlog_fatal (module_name=0x7f2b721b3ef5 "BGP", line=<value optimized out>, file=<value optimized out>,
> ? ? function=<value optimized out>, fmt=0x7f2b70802f2c "Assertion (%s) failed") at libxorp/xlog.c:467
> #3 ?0x00007f2b707e175d in xlog_assert (module_name=0x1902 <Address 0x1902 out of bounds>, line=6402, file=0x6 <Address 0x6 out of bounds>,
> ? ? function=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>, failedexpr=<value optimized out>) at libxorp/xlog.c:480
> #4 ?0x00007f2b7210eda6 in NextHopAttribute<IPv4>::NextHopAttribute (this=0x2229360, d=0x22288c0 "@\3\4") at bgp/path_attribute.cc:321
> #5 ?0x00007f2b7210666a in PathAttribute::create (d=0x22288c0 "@\3\4", max_len=<value optimized out>, l=@0x7fffc5af5fb8,
> ? ? peerdata=<value optimized out>, ip_version=<value optimized out>) at bgp/path_attribute.cc:1733
> #6 ?0x00007f2b7211157e in FastPathAttributeList<IPv4>::find_attribute_by_type (this=0x223ad40, type=<value optimized out>)
> ? ? at bgp/path_attribute.cc:3116
> #7 ?0x00007f2b72111692 in FastPathAttributeList<IPv4>::nexthop_att (this=0x1902) at bgp/path_attribute.cc:2693
> #8 ?0x00007f2b721116a1 in FastPathAttributeList<IPv4>::nexthop (this=0x1902) at bgp/path_attribute.cc:2699
> #9 ?0x00007f2b72179e34 in NexthopRewriteFilter<IPv4>::filter (this=0x22291e0, rtmsg=@0x7fffc5af6360) at bgp/route_table_filter.cc:200
> #10 0x00007f2b72176ffe in FilterVersion<IPv4>::apply_filters (this=0x21da6d0, rtmsg=@0x7fffc5af6360, ref_change=1)
> ? ? at bgp/route_table_filter.cc:747
> #11 0x00007f2b721796d0 in FilterTable<IPv4>::apply_filters (this=0x2228cd0, rtmsg=@0x7fffc5af6360, ref_change=1)
> ? ? at bgp/route_table_filter.cc:1159
> #12 0x00007f2b72179a15 in FilterTable<IPv4>::add_route (this=0x2228cd0, rtmsg=@0x7fffc5af6360, caller=<value optimized out>)
> ? ? at bgp/route_table_filter.cc:820
> #13 0x00007f2b7216c2c1 in DumpTable<IPv4>::route_dump (this=0x222b400, rtmsg=@0x7fffc5af6360, caller=<value optimized out>,
> ? ? dump_peer=<value optimized out>) at bgp/route_table_dump.cc:193
> #14 0x00007f2b7217213c in FanoutTable<IPv4>::route_dump (this=0x21f9f30, rtmsg=@0x7fffc5af6360, caller=<value optimized out>, dump_peer=
> ? ? 0x21d8830) at bgp/route_table_fanout.cc:409
> #15 0x00007f2b7213d2fc in AggregationTable<IPv4>::route_dump (this=0x21f9ea0, rtmsg=@0x7fffc5af6360, caller=<value optimized out>,
> ? ? dump_peer=<value optimized out>) at bgp/route_table_aggregation.cc:660
> #16 0x00007f2b7218381e in PolicyTable<IPv4>::route_dump (this=0x21f89b0, rtmsg=@0x7fffc5af6360, caller=<value optimized out>,
> ? ? dump_peer=0x21d8830) at bgp/route_table_policy.cc:300
> #17 0x00007f2b7215d6a0 in DecisionTable<IPv4>::route_dump (this=0x21f7f30, rtmsg=@0x7fffc5af6360, peer=0x21d8830)
> ? ? at bgp/route_table_decision.cc:866
> #18 0x00007f2b72148650 in BGPRouteTable<IPv4>::route_dump (this=0x21f6db0, rtmsg=@0x7fffc5af6360, peer=0x21d8830)
> ? ? at bgp/route_table_base.cc:59
> #19 0x00007f2b72155255 in CacheTable<IPv4>::route_dump (this=0x21fa7a0, rtmsg=<value optimized out>, caller=<value optimized out>,
> ? ? dump_peer=0x21d8830) at bgp/route_table_cache.cc:402
> ---Type <return> to continue, or q <return> to quit---
> #20 0x00007f2b7218381e in PolicyTable<IPv4>::route_dump (this=0x21fa090, rtmsg=@0x7fffc5af65a0, caller=<value optimized out>,
> ? ? dump_peer=0x21d8830) at bgp/route_table_policy.cc:300
> #21 0x00007f2b7218506e in PolicyTableImport<IPv4>::route_dump (this=0x21fa090, rtmsg=@0x7fffc5af65a0, caller=0x6,
> ? ? dump_peer=0xffffffffffffffff) at bgp/route_table_policy_im.cc:56
> #22 0x00007f2b721797c1 in FilterTable<IPv4>::route_dump (this=0x21fa260, rtmsg=@0x7fffc5af65a0, caller=<value optimized out>,
> ? ? dump_peer=0x21d8830) at bgp/route_table_filter.cc:895
> #23 0x00007f2b72192ded in RibInTable<IPv4>::dump_next_route (this=<value optimized out>, dump_iter=<value optimized out>)
> ? ? at bgp/route_table_ribin.cc:374
> #24 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21fa260, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
> #25 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21fa090, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
> #26 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21fa7a0, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
> #27 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21f6db0, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
> #28 0x00007f2b7215d630 in DecisionTable<IPv4>::dump_next_route (this=<value optimized out>, dump_iter=@0x222b430)
> ? ? at bgp/route_table_decision.cc:857
> #29 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21f89b0, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
> #30 0x00007f2b72147699 in AggregationTable<IPv4>::dump_next_route (this=<value optimized out>, dump_iter=@0x222b430)
> ? ? at bgp/route_table_aggregation.cc:568
> #31 0x00007f2b721485a6 in BGPRouteTable<IPv4>::dump_next_route (this=0x21f9f30, dump_iter=@0x222b430) at bgp/route_table_base.cc:49
> #32 0x00007f2b7216ad3f in DumpTable<IPv4>::do_next_route_dump (this=0x222b400) at bgp/route_table_dump.cc:358
> #33 0x00007f2b7216aef7 in DumpTable<IPv4>::get_next_message (this=0x222b400, next_table=<value optimized out>)
> ? ? at bgp/route_table_dump.cc:413
> #34 0x00007f2b72177ab5 in FilterTable<IPv4>::get_next_message (this=0x2228cd0, next_table=0x2226a70) at bgp/route_table_filter.cc:1196
> #35 0x00007f2b72182e55 in PolicyTable<IPv4>::get_next_message (this=0x2226a70, next_table=0x21da840) at bgp/route_table_policy.cc:395
> #36 0x00007f2b72193f8f in RibOutTable<IPv4>::pull_next_route (this=0x21da840) at bgp/route_table_ribout.cc:422
> #37 0x00007f2b721940c3 in XorpMemberCallback0B0<bool, RibOutTable<IPv4> >::dispatch (this=<value optimized out>)
> ? ? at ./libxorp/callback_nodebug.hh:286
> #38 0x00007f2b707f955e in RepeatedTaskNode2::run (this=<value optimized out>, xorp_task=@0x1902) at libxorp/task.cc:122
> #39 0x00007f2b707f8937 in TaskList::run (this=<value optimized out>) at libxorp/task.cc:231
> #40 0x00007f2b707e54dc in EventLoop::do_work (this=0x7fffc5af6b70, can_block=<value optimized out>) at libxorp/eventloop.cc:133
> #41 0x00007f2b707e55c8 in EventLoop::run (this=0x7fffc5af6b70) at libxorp/eventloop.cc:96
> #42 0x00007f2b720bbb15 in BGPMain::main_loop (this=0x7fffc5af7060) at bgp/bgp.cc:758
> #43 0x00000000004015f8 in main (argv=0x7fffc5af73d8) at bgp/main.cc:93
> Current language: ?auto; currently minimal
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Thu Apr 22 10:46:42 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 10:46:42 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>
References: <4BCE23D0.9040100@candelatech.com>	
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>	
	<4BD08300.3010907@candelatech.com>
	<n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>
Message-ID: <4BD08B82.8010403@candelatech.com>

On 04/22/2010 10:37 AM, Atanu Ghosh wrote:
> Hi,
>
> The original code caught all exceptions from bad update packets in
> peer.cc:BGPPeer::get_message. At the bottom of this routine you can
> see the CorruptMessage exceptions being caught and the notification
> being sent to the peer.
>
> Your stack backtrace looks like the current code does not check the
> update packet for sanity but just queues it, then later when the
> packet is being processed it notices a problem and throws an
> exception, which is not caught. Temporarily you could try catching the
> exceptions around pull_next_route in the RibOutTable.

I think the bad route is coming in via a policy I have that tells
BGP to export static and connected routes...not from a peer.

Maybe we need some tighter checks in whatever code handles the
routes from the policy logic?

Thanks,
Ben

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


From greearb at candelatech.com  Thu Apr 22 11:25:30 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 11:25:30 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>
References: <4BCE23D0.9040100@candelatech.com>	
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>	
	<4BD08300.3010907@candelatech.com>
	<n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>
Message-ID: <4BD0949A.3090500@candelatech.com>

On 04/22/2010 10:37 AM, Atanu Ghosh wrote:
> Hi,
>
> The original code caught all exceptions from bad update packets in
> peer.cc:BGPPeer::get_message. At the bottom of this routine you can
> see the CorruptMessage exceptions being caught and the notification
> being sent to the peer.
>
> Your stack backtrace looks like the current code does not check the
> update packet for sanity but just queues it, then later when the
> packet is being processed it notices a problem and throws an
> exception, which is not caught. Temporarily you could try catching the
> exceptions around pull_next_route in the RibOutTable.

How does the attached patch look to you?  It seems to fix
the problem for me...

Thanks,
Ben

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp_bgp_originate_exception.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100422/a92604eb/attachment.ksh 

From atanu at xorp.org  Thu Apr 22 11:36:00 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Thu, 22 Apr 2010 11:36:00 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <4BD0949A.3090500@candelatech.com>
References: <4BCE23D0.9040100@candelatech.com>
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
	<4BD08300.3010907@candelatech.com>
	<n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>
	<4BD0949A.3090500@candelatech.com>
Message-ID: <g2i9a09c93f1004221136ief816d81g2fe66cf6c6c71b0d@mail.gmail.com>

Hi,

The patch looks good assuming that a bad nexthop from a peer is still
handled correctly.

       Atanu.

On Thu, Apr 22, 2010 at 11:25 AM, Ben Greear <greearb at candelatech.com> wrote:
> On 04/22/2010 10:37 AM, Atanu Ghosh wrote:
>>
>> Hi,
>>
>> The original code caught all exceptions from bad update packets in
>> peer.cc:BGPPeer::get_message. At the bottom of this routine you can
>> see the CorruptMessage exceptions being caught and the notification
>> being sent to the peer.
>>
>> Your stack backtrace looks like the current code does not check the
>> update packet for sanity but just queues it, then later when the
>> packet is being processed it notices a problem and throws an
>> exception, which is not caught. Temporarily you could try catching the
>> exceptions around pull_next_route in the RibOutTable.
>
> How does the attached patch look to you? ?It seems to fix
> the problem for me...
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>


From greearb at candelatech.com  Thu Apr 22 11:42:02 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 11:42:02 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <g2i9a09c93f1004221136ief816d81g2fe66cf6c6c71b0d@mail.gmail.com>
References: <4BCE23D0.9040100@candelatech.com>	
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>	
	<4BD08300.3010907@candelatech.com>	
	<n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>	
	<4BD0949A.3090500@candelatech.com>
	<g2i9a09c93f1004221136ief816d81g2fe66cf6c6c71b0d@mail.gmail.com>
Message-ID: <4BD0987A.7030707@candelatech.com>

On 04/22/2010 11:36 AM, Atanu Ghosh wrote:
> Hi,
>
> The patch looks good assuming that a bad nexthop from a peer is still
> handled correctly.

I don't think it would change peer message behaviour one way or another..but at
this time, I don't have a good way to inject faulty routes from a peer
for testing.

I've pushed this patch to xorp.ct.

Thanks,
Ben

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


From atanu at xorp.org  Thu Apr 22 11:47:59 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Thu, 22 Apr 2010 11:47:59 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <4BD0987A.7030707@candelatech.com>
References: <4BCE23D0.9040100@candelatech.com>
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>
	<4BD08300.3010907@candelatech.com>
	<n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>
	<4BD0949A.3090500@candelatech.com>
	<g2i9a09c93f1004221136ief816d81g2fe66cf6c6c71b0d@mail.gmail.com>
	<4BD0987A.7030707@candelatech.com>
Message-ID: <j2u9a09c93f1004221147t6715ff32m20b78c0db49abdf4@mail.gmail.com>

Hi,

If you are going to be making changes to BGP it would make sense to
try and get the regression tests working again.
The support for sending badly formed packets already exists.

        Atanu.

On Thu, Apr 22, 2010 at 11:42 AM, Ben Greear <greearb at candelatech.com> wrote:
> On 04/22/2010 11:36 AM, Atanu Ghosh wrote:
>>
>> Hi,
>>
>> The patch looks good assuming that a bad nexthop from a peer is still
>> handled correctly.
>
> I don't think it would change peer message behaviour one way or another..but
> at
> this time, I don't have a good way to inject faulty routes from a peer
> for testing.
>
> I've pushed this patch to xorp.ct.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>


From greearb at candelatech.com  Thu Apr 22 11:55:36 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 11:55:36 -0700
Subject: [Xorp-hackers] Here's some bgp config files that work.
In-Reply-To: <j2u9a09c93f1004221147t6715ff32m20b78c0db49abdf4@mail.gmail.com>
References: <4BCE23D0.9040100@candelatech.com>	
	<s2i9a09c93f1004220902x2489e5fnb39e4ee1348cb4af@mail.gmail.com>	
	<4BD08300.3010907@candelatech.com>	
	<n2x9a09c93f1004221037mcfdaf07ye44eccb0524d886f@mail.gmail.com>	
	<4BD0949A.3090500@candelatech.com>	
	<g2i9a09c93f1004221136ief816d81g2fe66cf6c6c71b0d@mail.gmail.com>	
	<4BD0987A.7030707@candelatech.com>
	<j2u9a09c93f1004221147t6715ff32m20b78c0db49abdf4@mail.gmail.com>
Message-ID: <4BD09BA8.3080003@candelatech.com>

On 04/22/2010 11:47 AM, Atanu Ghosh wrote:
> Hi,
>
> If you are going to be making changes to BGP it would make sense to
> try and get the regression tests working again.
> The support for sending badly formed packets already exists.

I agree.  I'm attempting to checkout the 'data' svn tree now.

Thanks,
Ben

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


From greearb at candelatech.com  Thu Apr 22 12:38:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 12:38:45 -0700
Subject: [Xorp-hackers] TODAY : Conference Call to co-ordinate XORP
 going forward
In-Reply-To: <q2i4769af411004220655jf8a7d292h35d403ac15618d0b@mail.gmail.com>
References: <q2i4769af411004220655jf8a7d292h35d403ac15618d0b@mail.gmail.com>
Message-ID: <4BD0A5C5.5040407@candelatech.com>

On 04/22/2010 06:55 AM, Adam Greenhalgh wrote:
> Hi Folks,
>
> Here are the details of the first xorp meeting to decide how xorp
> progresses. This email is made up of three parts, attendee list,
> agenda and finally at the bottom the conference call details. In
> particular please look at the conference call details in advance and
> yell if you have a problem with them. Please also take note of the
> minutes policy for the call which forms part of the agenda.

I have started the web portion of the meeting.
I know that webex works with Windows and IE.

It may work with other platforms as well.  I started the meeting early so
that folks can test out their systems if they haven't used webex before.

That said, I'm not sure if we have much to display via the web.  If folks
are interested, I can show how we are using Xorp after the rest of
the agenda has been taken care of.  We can also flip to any other participant's
desktops if they have something to share.

Thanks,
Ben

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


From greearb at candelatech.com  Thu Apr 22 16:02:34 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 22 Apr 2010 16:02:34 -0700
Subject: [Xorp-hackers] PATCH:  Fix build on Fedora 12.
Message-ID: <4BD0D58A.9030604@candelatech.com>

This changes XIF syntax slightly to require a semi-colon after
each statement instead of depending on using a newline.

This in turn fixes issues with building xorp on Fedora 12 due to
c preprocessor issues and xif.

This is a back-ported version of the same fix in xorp.ct.

I'll attempt to commit this to xorp-svn unless there are objections.

Thanks,
Ben

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorp-f12.patch.bz2
Type: application/x-tar
Size: 26801 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100422/c6a6a5a8/attachment-0001.tar 

From greearb at candelatech.com  Fri Apr 23 09:39:59 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 09:39:59 -0700
Subject: [Xorp-hackers] TODO list for rls 1.7
Message-ID: <4BD1CD5F.3080603@candelatech.com>


I just committed a fix for the Fedora 12 build issue to svn.

Sparc compile still fails due to alignment issues.  I have
a fairly invasive patch that changes the Arp code that fixes
some of this, but a simpler patch (and required regardless of
Arp changes) is to just not use -Werror when compiling on non-x86
platforms.

Shall I go ahead and commit the -Werror change so that sparc will
build (with warnings)?  I'll push the bigger changes into rls 1.8
once we have 1.7 released.

Aside from sparc-build, I'd like for us to decide if we are removing
boost requirement or not.  If we agree to remove it, I will happily
submit patches to do so, including a re-work of Bruce's patch that
added boost smart pointers.

Other than that, I think we can go ahead and finalize a 1.7 release.

We can tag it so that we can always go back and branch off a bug-fix
branch if we desire, but I see no need to branch before it's proven
to be required.

Thanks,
Ben

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


From M.Handley at cs.ucl.ac.uk  Fri Apr 23 10:10:42 2010
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Fri, 23 Apr 2010 18:10:42 +0100
Subject: [Xorp-hackers] TODO list for rls 1.7
In-Reply-To: <4BD1CD5F.3080603@candelatech.com>
References: <4BD1CD5F.3080603@candelatech.com>
Message-ID: <k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>

Thanks for the fix Ben.

On -Werror, on many occasions it's annoyed me, but on a fair number of
occasions it's saved my bacon.  I'd rather keep it and do the right
thing.  Just my personal view though.

Regarding boost, I think how we left it on the phone call last night
was that Bruce would write a short note saying what he believes boost
gives us, and why it's the right thing for Xorp.  So I'd like to wait
for that before we make a decision.

 - Mark

On 23 April 2010 17:39, Ben Greear <greearb at candelatech.com> wrote:
>
> I just committed a fix for the Fedora 12 build issue to svn.
>
> Sparc compile still fails due to alignment issues. ?I have
> a fairly invasive patch that changes the Arp code that fixes
> some of this, but a simpler patch (and required regardless of
> Arp changes) is to just not use -Werror when compiling on non-x86
> platforms.
>
> Shall I go ahead and commit the -Werror change so that sparc will
> build (with warnings)? ?I'll push the bigger changes into rls 1.8
> once we have 1.7 released.
>
> Aside from sparc-build, I'd like for us to decide if we are removing
> boost requirement or not. ?If we agree to remove it, I will happily
> submit patches to do so, including a re-work of Bruce's patch that
> added boost smart pointers.
>
> Other than that, I think we can go ahead and finalize a 1.7 release.
>
> We can tag it so that we can always go back and branch off a bug-fix
> branch if we desire, but I see no need to branch before it's proven
> to be required.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Fri Apr 23 10:24:46 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 10:24:46 -0700
Subject: [Xorp-hackers] RFC: Explicitly note that new code contributions are
 copy-righted by the submitter.
Message-ID: <4BD1D7DE.3050600@candelatech.com>


I propose to update the LICENSE file to explicitly note that contributions
on or after today are copyright by the submitter unless otherwise specified
in the commit message and/or committed code.

This ensures that no single entity can re-license XORP or otherwise
take changes in the public svn tree and use or relicense them in ways not compatible
with the current license scheme (GPL, LGPL, other) without consent
of all committers from today on.  I believe this will help make
xorp stronger and it will certainly make me happier about committing
my changes to the public svn tree.



[greearb at ben-dt2 xorp]$ git diff
diff --git a/trunk/xorp/LICENSE b/trunk/xorp/LICENSE
index 69e6102..a143666 100644
--- a/trunk/xorp/LICENSE
+++ b/trunk/xorp/LICENSE
@@ -1,11 +1,11 @@
-#
-# $XORP: xorp/LICENSE,v 1.11 2008/10/02 21:56:13 bms Exp $
-#

  With the exception of code derived from other sources, all XORP software
-is copyrighted by XORP, Inc. [Copyright (c) 2001-2009 XORP, Inc.].
-Files containing derived software are listed in the "LICENSE.other" file
-together with their corresponding copyrights and original licenses.
+committed prior to April 23, 2010 is copyrighted by
+XORP, Inc. [Copyright (c) 2001-2009 XORP, Inc.].  Changes committed
+on or after April 23, 2010 are copyrighted by the author unless
+otherwise specified in the commit message. Files containing derived
+software are listed in the "LICENSE.other" file together with their
+corresponding copyrights and original licenses.

  All XORP software is licensed under the GNU General Public License,
  Version 2, June 1991 contained in the "LICENSE.gpl" file unless


Thanks,
Ben

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


From greearb at candelatech.com  Fri Apr 23 10:23:20 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 10:23:20 -0700
Subject: [Xorp-hackers] TODO list for rls 1.7
In-Reply-To: <k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
References: <4BD1CD5F.3080603@candelatech.com>
	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
Message-ID: <4BD1D788.6090702@candelatech.com>

On 04/23/2010 10:10 AM, Mark Handley wrote:
> Thanks for the fix Ben.
>
> On -Werror, on many occasions it's annoyed me, but on a fair number of
> occasions it's saved my bacon.  I'd rather keep it and do the right
> thing.  Just my personal view though.

I'm all for fixing the warnings, but the netlink related alignment errors on Linux
cannot be fixed in a useful manner as far as I can tell because the errors are in the
standard linux include headers.

The Arp code is used for VRRP, which is just barely functional in 1.7
anyway, so I think even if the warnings are critical, it won't be a big
problem for most users.

We can continue to try to remove as many warnings as possible in the 1.8
release cycle (I have some fixes queued up in xorp.ct waiting...)

> Regarding boost, I think how we left it on the phone call last night
> was that Bruce would write a short note saying what he believes boost
> gives us, and why it's the right thing for Xorp.  So I'd like to wait
> for that before we make a decision.

Agreed.  I'd just like to make the decision before 1.7 is released
so that anyone packaging xorp doesn't have to deal with boost if they
don't have to.

Thanks,
Ben

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


From M.Handley at cs.ucl.ac.uk  Fri Apr 23 10:43:11 2010
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Fri, 23 Apr 2010 18:43:11 +0100
Subject: [Xorp-hackers] TODO list for rls 1.7
In-Reply-To: <4BD1D788.6090702@candelatech.com>
References: <4BD1CD5F.3080603@candelatech.com>
	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD1D788.6090702@candelatech.com>
Message-ID: <s2m84a612dd1004231043pc1523c4aib1b164eba0b5bbc9@mail.gmail.com>

On 23 April 2010 18:23, Ben Greear <greearb at candelatech.com> wrote:
> On 04/23/2010 10:10 AM, Mark Handley wrote:
>>
>> Thanks for the fix Ben.
>>
>> On -Werror, on many occasions it's annoyed me, but on a fair number of
>> occasions it's saved my bacon. ?I'd rather keep it and do the right
>> thing. ?Just my personal view though.
>
> I'm all for fixing the warnings, but the netlink related alignment errors on
> Linux
> cannot be fixed in a useful manner as far as I can tell because the errors
> are in the
> standard linux include headers.

Fair enough.  I just want to minimize the code that is compiled
without -Werror, not reduce it to absolutely zero.

>> Regarding boost, I think how we left it on the phone call last night
>> was that Bruce would write a short note saying what he believes boost
>> gives us, and why it's the right thing for Xorp. ?So I'd like to wait
>> for that before we make a decision.
>
> Agreed. ?I'd just like to make the decision before 1.7 is released
> so that anyone packaging xorp doesn't have to deal with boost if they
> don't have to.

Definitely.

 - Mark


From greearb at candelatech.com  Fri Apr 23 10:49:39 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 10:49:39 -0700
Subject: [Xorp-hackers] TODO list for rls 1.7
In-Reply-To: <s2m84a612dd1004231043pc1523c4aib1b164eba0b5bbc9@mail.gmail.com>
References: <4BD1CD5F.3080603@candelatech.com>
	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD1D788.6090702@candelatech.com>
	<s2m84a612dd1004231043pc1523c4aib1b164eba0b5bbc9@mail.gmail.com>
Message-ID: <4BD1DDB3.1010208@candelatech.com>

On 04/23/2010 10:43 AM, Mark Handley wrote:
> On 23 April 2010 18:23, Ben Greear<greearb at candelatech.com>  wrote:
>> On 04/23/2010 10:10 AM, Mark Handley wrote:
>>>
>>> Thanks for the fix Ben.
>>>
>>> On -Werror, on many occasions it's annoyed me, but on a fair number of
>>> occasions it's saved my bacon.  I'd rather keep it and do the right
>>> thing.  Just my personal view though.
>>
>> I'm all for fixing the warnings, but the netlink related alignment errors on
>> Linux
>> cannot be fixed in a useful manner as far as I can tell because the errors
>> are in the
>> standard linux include headers.
>
> Fair enough.  I just want to minimize the code that is compiled
> without -Werror, not reduce it to absolutely zero.

I couldn't find a way to disable it for individual files.  Seems like
#pragmas should work from gcc docs I read..but they didn't work in
practice, especially not on slightly older compilers.

Here's my proposed patch.  It leaves warnings on for x86 and x86-64,
so I think that's pretty good coverage.  If someone can confirm that
other architectures work, we can add those to the white-list.


diff --git a/trunk/xorp/SConstruct b/trunk/xorp/SConstruct
index 49c1b81..0d469bc 100644
--- a/trunk/xorp/SConstruct
+++ b/trunk/xorp/SConstruct
@@ -535,9 +535,22 @@ env.AppendUnique(CPPDEFINES = [
      ( 'BOOST_DISABLE_THREADS' ),
      ])

+# Some platforms have alignment warnings that cannot easily be
+# fixed, so we can't enable Werror for them.
+if (host_cpu == "i686" or
+    host_cpu == "x86_64"):
+        env.AppendUnique(CFLAGS = [
+               '-Werror',
+               ])
+       env.AppendUnique(CXXFLAGS = [
+               '-Werror',
+               ])
+else:
+       print "WARNING:  Detected non x86 platform, will not enable -Werror compile option: ", host_cpu
+
+
  # NOTE: gcc specific flags.
  env.AppendUnique(CFLAGS = [
-    '-Werror',
      '-W',
      '-Wall',
      '-Wwrite-strings',
@@ -553,7 +566,6 @@ env.AppendUnique(CFLAGS = [
      ])

  env.AppendUnique(CXXFLAGS = [
-    '-Werror',
      '-W',
      '-Wall',
      '-Wwrite-strings',


Thanks,
Ben

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


From greearb at candelatech.com  Fri Apr 23 16:03:08 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 16:03:08 -0700
Subject: [Xorp-hackers] BGP issue in test harness (xorp.ct)
Message-ID: <4BD2272C.5030309@candelatech.com>

I've got at least partial functionality in the bgp test harness
working in my xorp.ct tree.

I am getting a failure (with crash due to uncaught exception)
in test_peering1.sh:

test28_ipv6()
{
     echo "TEST28 (IPV6) - Verify that routes originated by BGP reach an EBGP peer"
     echo "Also verify that the nexthop is rewritten and the provided nexthop"
     echo "is ignored"

     coord reset
     coord target $HOST $PORT4
     coord initialise attach peer1

     coord peer1 expect packet open asnum $AS bgpid $ID holdtime $HOLDTIME \
	afi 2 safi 1

     coord peer1 expect packet keepalive

     coord peer1 expect packet update \
	origin 0 \
	aspath 65008 \
	med 1 \
	nlri6 2000::/3 \
	nexthop6 ::

It is crashing because :: isn't a unicast address.  I think this is basically
the same problem I hit the other day with IPv4, and I can fix it by catching
the exception and ignoring the update.  But, assuming this test case should
function...should we perhaps allow :: for a nexthop?

Thanks,
Ben

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


From greearb at candelatech.com  Fri Apr 23 16:07:01 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 16:07:01 -0700
Subject: [Xorp-hackers] BGP harness question related to 'runit'
Message-ID: <4BD22815.3090909@candelatech.com>

I notice that this or similar logic is found in most of the BGP test harness
scripts:

if [ $START_PROGRAMS = "yes" ]
then
     CXRL="$CALLXRL -r 10"
     runit $QUIET $VERBOSE -c "$0 -s -c $*" <<EOF
     ../../libxipc/xorp_finder
     ../../fea/xorp_fea_dummy  = $CXRL finder://fea/common/0.1/get_target_name
     ../../rib/xorp_rib        = $CXRL finder://rib/common/0.1/get_target_name
     ../xorp_bgp               = $CXRL finder://bgp/common/0.1/get_target_name
     ./test_peer -s peer1      = $CXRL finder://peer1/common/0.1/get_target_name
     ./coord                   = $CXRL finder://coord/common/0.1/get_target_name
EOF
     trap '' 0
     exit $?
fi


Even after tweaking for correct binary paths, the applications fail to properly
start unless I delete everything after the first token.  For instance:


if [ $START_PROGRAMS = "yes" ]
then
     CXRL="$CALLXRL -r 10"
     runit $QUIET $VERBOSE -c "$0 -s -c $*" <<EOF
     ../../libxipc/xorp_finder
     ../../fea/xorp_fea_dummy
     ../../rib/xorp_rib
     ../xorp_bgp
     ./test_peer -s peer1
     ./coord
EOF
     trap '' 0
     exit $?
fi


Anyone know what that CXRL logic was supposed to accomplish?  Maybe it only
works with xorp_rtrmgr is running?

Thanks,
Ben


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


From atanu at xorp.org  Fri Apr 23 17:18:20 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Fri, 23 Apr 2010 17:18:20 -0700
Subject: [Xorp-hackers] BGP harness question related to 'runit'
In-Reply-To: <4BD22815.3090909@candelatech.com>
References: <4BD22815.3090909@candelatech.com>
Message-ID: <y2j9a09c93f1004231718nf48fe32ew68cfe60102d5200a@mail.gmail.com>

Hi,

>From memory, the runit program needs to know that the programs it has
started are ready to accept XRLs. The argument after the '=''s is a
program to run to determine that the program is ready. In the case of
xorp_fea_dummy the call_xrl program makes 10 attempts ("-r 10") to get
the target name. Without this the programs will be started without
delay and XRLs will be sent to the programs before they are ready to
accept them. The runit program does not require the router manager, in
a simpler universe it would have been nice to have been able to use
the router manage to start the programs.

In the xorp/tests directory I was starting to experiment with using
python only for testing. The runit program not only starts the
programs but more importantly notices if they fail.

       Atanu.

On Fri, Apr 23, 2010 at 4:07 PM, Ben Greear <greearb at candelatech.com> wrote:
> I notice that this or similar logic is found in most of the BGP test harness
> scripts:
>
> if [ $START_PROGRAMS = "yes" ]
> then
> ? ? CXRL="$CALLXRL -r 10"
> ? ? runit $QUIET $VERBOSE -c "$0 -s -c $*" <<EOF
> ? ? ../../libxipc/xorp_finder
> ? ? ../../fea/xorp_fea_dummy ?= $CXRL finder://fea/common/0.1/get_target_name
> ? ? ../../rib/xorp_rib ? ? ? ?= $CXRL finder://rib/common/0.1/get_target_name
> ? ? ../xorp_bgp ? ? ? ? ? ? ? = $CXRL finder://bgp/common/0.1/get_target_name
> ? ? ./test_peer -s peer1 ? ? ?= $CXRL finder://peer1/common/0.1/get_target_name
> ? ? ./coord ? ? ? ? ? ? ? ? ? = $CXRL finder://coord/common/0.1/get_target_name
> EOF
> ? ? trap '' 0
> ? ? exit $?
> fi
>
>
> Even after tweaking for correct binary paths, the applications fail to properly
> start unless I delete everything after the first token. ?For instance:
>
>
> if [ $START_PROGRAMS = "yes" ]
> then
> ? ? CXRL="$CALLXRL -r 10"
> ? ? runit $QUIET $VERBOSE -c "$0 -s -c $*" <<EOF
> ? ? ../../libxipc/xorp_finder
> ? ? ../../fea/xorp_fea_dummy
> ? ? ../../rib/xorp_rib
> ? ? ../xorp_bgp
> ? ? ./test_peer -s peer1
> ? ? ./coord
> EOF
> ? ? trap '' 0
> ? ? exit $?
> fi
>
>
> Anyone know what that CXRL logic was supposed to accomplish? ?Maybe it only
> works with xorp_rtrmgr is running?
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From atanu at xorp.org  Fri Apr 23 17:19:43 2010
From: atanu at xorp.org (Atanu Ghosh)
Date: Fri, 23 Apr 2010 17:19:43 -0700
Subject: [Xorp-hackers] BGP issue in test harness (xorp.ct)
In-Reply-To: <4BD2272C.5030309@candelatech.com>
References: <4BD2272C.5030309@candelatech.com>
Message-ID: <r2r9a09c93f1004231719r7f811cd9k8f01cdf96649dd47@mail.gmail.com>

Hi,

I think that there are two problems, BGP shouldn't be sending an
update with with a nexthop of zero and the test shouldn't be expecting
to see a nexthop of zero. I would expect that the nexthop should be
the IP address of the router. The test is failing to set a nexthop
address for IPv6 as it does for IPv4, it looks like in the past an
IPv6 address of zero passed through the system and now BGP is no
longer allowing it.

My suggestion is to log this as a bug and add this to the
TEST_NOT_FIXED variable and remove it from TESTS.

       Atanu.

On Fri, Apr 23, 2010 at 4:03 PM, Ben Greear <greearb at candelatech.com> wrote:
> I've got at least partial functionality in the bgp test harness
> working in my xorp.ct tree.
>
> I am getting a failure (with crash due to uncaught exception)
> in test_peering1.sh:
>
> test28_ipv6()
> {
> ? ? echo "TEST28 (IPV6) - Verify that routes originated by BGP reach an EBGP peer"
> ? ? echo "Also verify that the nexthop is rewritten and the provided nexthop"
> ? ? echo "is ignored"
>
> ? ? coord reset
> ? ? coord target $HOST $PORT4
> ? ? coord initialise attach peer1
>
> ? ? coord peer1 expect packet open asnum $AS bgpid $ID holdtime $HOLDTIME \
> ? ? ? ?afi 2 safi 1
>
> ? ? coord peer1 expect packet keepalive
>
> ? ? coord peer1 expect packet update \
> ? ? ? ?origin 0 \
> ? ? ? ?aspath 65008 \
> ? ? ? ?med 1 \
> ? ? ? ?nlri6 2000::/3 \
> ? ? ? ?nexthop6 ::
>
> It is crashing because :: isn't a unicast address. ?I think this is basically
> the same problem I hit the other day with IPv4, and I can fix it by catching
> the exception and ignoring the update. ?But, assuming this test case should
> function...should we perhaps allow :: for a nexthop?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Fri Apr 23 21:38:47 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 21:38:47 -0700
Subject: [Xorp-hackers] BGP harness question related to 'runit'
In-Reply-To: <y2j9a09c93f1004231718nf48fe32ew68cfe60102d5200a@mail.gmail.com>
References: <4BD22815.3090909@candelatech.com>
	<y2j9a09c93f1004231718nf48fe32ew68cfe60102d5200a@mail.gmail.com>
Message-ID: <4BD275D7.1000802@candelatech.com>

On 04/23/2010 05:18 PM, Atanu Ghosh wrote:
> Hi,
>
>> From memory, the runit program needs to know that the programs it has
> started are ready to accept XRLs. The argument after the '=''s is a
> program to run to determine that the program is ready. In the case of
> xorp_fea_dummy the call_xrl program makes 10 attempts ("-r 10") to get
> the target name. Without this the programs will be started without
> delay and XRLs will be sent to the programs before they are ready to
> accept them. The runit program does not require the router manager, in
> a simpler universe it would have been nice to have been able to use
> the router manage to start the programs.
>
> In the xorp/tests directory I was starting to experiment with using
> python only for testing. The runit program not only starts the
> programs but more importantly notices if they fail.

Thanks, I found the problem.

runit was using execv instead of execvp, and I was passing in an executable
name 'call_xrl' instead of a full path to call_xrl.  I changed it to use execvp
for more flexibility.

Also, call_xrl was running it's 10 tries in a tight loop..so I added
a sleep(1) between retries.

Thanks,
Ben

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


From greearb at candelatech.com  Fri Apr 23 23:26:01 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 23 Apr 2010 23:26:01 -0700
Subject: [Xorp-hackers] BGP issue in test harness (xorp.ct)
In-Reply-To: <r2r9a09c93f1004231719r7f811cd9k8f01cdf96649dd47@mail.gmail.com>
References: <4BD2272C.5030309@candelatech.com>
	<r2r9a09c93f1004231719r7f811cd9k8f01cdf96649dd47@mail.gmail.com>
Message-ID: <4BD28EF9.5040302@candelatech.com>

On 04/23/2010 05:19 PM, Atanu Ghosh wrote:
> Hi,
>
> I think that there are two problems, BGP shouldn't be sending an
> update with with a nexthop of zero and the test shouldn't be expecting
> to see a nexthop of zero. I would expect that the nexthop should be
> the IP address of the router. The test is failing to set a nexthop
> address for IPv6 as it does for IPv4, it looks like in the past an
> IPv6 address of zero passed through the system and now BGP is no
> longer allowing it.
>
> My suggestion is to log this as a bug and add this to the
> TEST_NOT_FIXED variable and remove it from TESTS.

I fixed the crash, added a new test that I think should work
(ie, with proper nexhop) but it doesn't work.  So, added that one
to TEST_NOT_FIXED.  The old test is in there but expects to fail
(just not crash xorp_bgp).

I've pushed all this to xorp.ct

The test_peering* scripts are now at least mostly right, but not
yet tied into the 'scons test' framework.  Hopefully the rest
will come easier and I can tie it into 'scons test' shortly.

Thanks,
Ben


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


From bms at incunabulum.net  Sat Apr 24 20:30:23 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Sun, 25 Apr 2010 04:30:23 +0100
Subject: [Xorp-hackers] Boost use
In-Reply-To: <k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
References: <4BD1CD5F.3080603@candelatech.com>
	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
Message-ID: <4BD3B74F.9060709@incunabulum.net>

On 04/23/10 18:10, Mark Handley wrote:
> Regarding boost, I think how we left it on the phone call last night
> was that Bruce would write a short note saying what he believes boost
> gives us, and why it's the right thing for Xorp.  So I'd like to wait
> for that before we make a decision.
>    

I have set out many of the benefits Boost offers for XORP, in previous 
postings to this mailing list over the last 6-9 months, so I'll be as 
concise here as possible:

     * Boost is widely used by C++ projects of comparable size, and 
offer a thoroughly peer-reviewed alternative to some of what we have in 
libxorp.
     Innovations from Boost itself are becoming part of the C++0x 
language specification. It is technically very strong.
     I think it's unreasonable to expect folk to reinvent wheels which 
exist out there, and pretty much essential to stuff they're now doing; 
Boost can be considered part of the C++ state-of-the-art now, as such, 
it has project currency.

     * The Boost shared_ptr/weak_ptr idioms, are a clean solution,
       to very specific problems we see in async systems such as XORP.

     That is, where we need to cleanly separate the reference of a C++ 
object from its storage lifecycle.
     Abusing ref_ptr further is syntactically not clear at all, and I 
strongly feel we should be using Boost instead. I am opposed to further 
use of ref_ptr (with &) because the intent of it is overloaded and 
confusing, to developers who are not intimately familiar with ref_ptr.
     Far more C++ developers out there are likely to be familiar with 
Boost than libxorp.

     * The Boost.Interprocess library will enable using shared memory 
efficiently for fast-path IPC in future, something which currently slows 
down XORP *significantly* compared to other BGP designs;
     14m vs 1m for full routing table convergence.
     As I've said to Mark and others before, there are shared-memory 
versions of the list, map and other STL containers, which drop straight 
in to shared memory.
     [FWIW Ravi at XORP, Inc. was proposing doing much the same thing, 
but hand-rolled]

     * The Boost multi-index container has the potential to make large 
indexed structures, such as the RIB tables, and routing tables internal 
to most protocols, more efficient in time and space.
     [I would have used it for OLSR, but ran out of time]

     * Thrift requires Boost anyway. Despite forwarding the full 
reasoning behind my recommendation of Thrift to XORP, Inc., to replace 
much of XRL and fix the problems with it, I have still not had an 
opinion from Mark either way.

     * There are numerous other Boost refactorings possible. I did not 
finish them because life support went offline.

     * Finally: We have already had others on xorp-hackers@ come 
forward, to say that work they've been doing on XORP requires Boost. Off 
the top of my head, Luca Belforte, for marshaling compound data 
structures out of routing processes.

...

I don't buy the argument that '1 more external dependency is bad'. The 
Boost libraries as currently used, are mostly used as header files. 
However beyond regex, we don't use the runtime libraries. The use of the 
libraries, can easily be switched back over to pcre or platform regex 
(at a minimum). At the moment boost regex is just shimmed in.

My view is that this argument is rooted more in unfamiliarity with 
systems-level C++, and how to optimize it effectively, than it actually 
posing a real problem.

Boost is generally available as a binary package for the platforms 
tested by the Tinderbox.
The Boost headers don't have any cross-compilation implications, apart 
from what someone cross-compiling XORP would need to do for an embedded 
target anyway, i.e. populate the staging area.

...

I'd far rather see a release made than not, if only to regain confidence 
with an otherwise unheard-from user base.
If the use of libboost_regex is the issue, that's a point I'm willing to 
compromise on for 1.7.

But I'm not willing to do the work of backing anything out, as I firmly 
believe it's in XORP's future interests for the reasons given above.
This is view borne in experience of being the only active developer on 
the open SVN branch for well over 6 months.

For future directions, Boost is a place we very much have to visit.
It offers concrete benefits for actually improving the performance, and 
code quality, of a large C++ system such as XORP.

regards
BMS


From bms at incunabulum.net  Sun Apr 25 00:26:53 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Sun, 25 Apr 2010 08:26:53 +0100
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD3B74F.9060709@incunabulum.net>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net>
Message-ID: <4BD3EEBD.7090808@incunabulum.net>

On 04/25/10 04:30, Bruce Simpson wrote:
>       * Boost is widely used by C++ projects of comparable size, and
> offer a thoroughly peer-reviewed alternative to some of what we have in
> libxorp.
>       Innovations from Boost itself are becoming part of the C++0x
> language specification. It is technically very strong.
>    

FYI: http://www.boost.org/
%%%
Ten Boost libraries are already included in the C++ Standards 
Committee's <http://www.open-std.org/jtc1/sc22/wg21/> Library Technical 
Report (TR1 
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf>) and 
will be in the new C++0x Standard now being finalized. C++0x will also 
include several more Boost libraries in addition to those from TR1. More 
Boost libraries are proposed for TR2 
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html>.
%%%

So, in the short to medium term, adoption of Boost leads to being more 
prepared for C++0x, which will happen; it's on the table already for 
LLVM / Clang to replace G++.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100425/3ba0d08d/attachment.html 

From M.Handley at cs.ucl.ac.uk  Sun Apr 25 01:50:44 2010
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Sun, 25 Apr 2010 09:50:44 +0100
Subject: [Xorp-hackers] RFC: Explicitly note that new code contributions
	are copy-righted by the submitter.
In-Reply-To: <4BD1D7DE.3050600@candelatech.com>
References: <4BD1D7DE.3050600@candelatech.com>
Message-ID: <r2o84a612dd1004250150mc26e5ca9v51972566e207c00d@mail.gmail.com>

The LICENCE file does need to change, or it could be viewed as
granting copyright to XORP, Inc, which is not the intent.  I'm fine
with your wording.  It seems reasonably unambiguous.

In addition to amending the licence, we should amend the copyright
line on any file we update to be:
// Copyright (c) 2001-2009 XORP, Inc and (c) 2010 by individual contributors.

This makes it clear that XORP, Inc does not own the copyright on new
changes on that specific file.

 - Mark


On 23 April 2010 18:24, Ben Greear <greearb at candelatech.com> wrote:
>
> I propose to update the LICENSE file to explicitly note that contributions
> on or after today are copyright by the submitter unless otherwise specified
> in the commit message and/or committed code.
>
> This ensures that no single entity can re-license XORP or otherwise
> take changes in the public svn tree and use or relicense them in ways not
> compatible
> with the current license scheme (GPL, LGPL, other) without consent
> of all committers from today on. ?I believe this will help make
> xorp stronger and it will certainly make me happier about committing
> my changes to the public svn tree.
>
>
>
> [greearb at ben-dt2 xorp]$ git diff
> diff --git a/trunk/xorp/LICENSE b/trunk/xorp/LICENSE
> index 69e6102..a143666 100644
> --- a/trunk/xorp/LICENSE
> +++ b/trunk/xorp/LICENSE
> @@ -1,11 +1,11 @@
> -#
> -# $XORP: xorp/LICENSE,v 1.11 2008/10/02 21:56:13 bms Exp $
> -#
>
> ?With the exception of code derived from other sources, all XORP software
> -is copyrighted by XORP, Inc. [Copyright (c) 2001-2009 XORP, Inc.].
> -Files containing derived software are listed in the "LICENSE.other" file
> -together with their corresponding copyrights and original licenses.
> +committed prior to April 23, 2010 is copyrighted by
> +XORP, Inc. [Copyright (c) 2001-2009 XORP, Inc.]. ?Changes committed
> +on or after April 23, 2010 are copyrighted by the author unless
> +otherwise specified in the commit message. Files containing derived
> +software are listed in the "LICENSE.other" file together with their
> +corresponding copyrights and original licenses.
>
> ?All XORP software is licensed under the GNU General Public License,
> ?Version 2, June 1991 contained in the "LICENSE.gpl" file unless
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>


From greearb at candelatech.com  Sun Apr 25 08:33:22 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 25 Apr 2010 08:33:22 -0700
Subject: [Xorp-hackers] RFC: Explicitly note that new code contributions
 are copy-righted by the submitter.
In-Reply-To: <r2o84a612dd1004250150mc26e5ca9v51972566e207c00d@mail.gmail.com>
References: <4BD1D7DE.3050600@candelatech.com>
	<r2o84a612dd1004250150mc26e5ca9v51972566e207c00d@mail.gmail.com>
Message-ID: <4BD460C2.30605@candelatech.com>

On 04/25/2010 01:50 AM, Mark Handley wrote:
> The LICENCE file does need to change, or it could be viewed as
> granting copyright to XORP, Inc, which is not the intent.  I'm fine
> with your wording.  It seems reasonably unambiguous.
>
> In addition to amending the licence, we should amend the copyright
> line on any file we update to be:
> // Copyright (c) 2001-2009 XORP, Inc and (c) 2010 by individual contributors.
>
> This makes it clear that XORP, Inc does not own the copyright on new
> changes on that specific file.

Would it be fair to just change ALL copyright headers to have the wording
as you suggest above, or just files we touch as we touch them in a non-trivial
manner?

Thanks,
Ben

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


From M.Handley at cs.ucl.ac.uk  Sun Apr 25 12:27:32 2010
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Sun, 25 Apr 2010 20:27:32 +0100
Subject: [Xorp-hackers] RFC: Explicitly note that new code contributions
	are copy-righted by the submitter.
In-Reply-To: <4BD460C2.30605@candelatech.com>
References: <4BD1D7DE.3050600@candelatech.com>
	<r2o84a612dd1004250150mc26e5ca9v51972566e207c00d@mail.gmail.com>
	<4BD460C2.30605@candelatech.com>
Message-ID: <m2n84a612dd1004251227ma4e4ba2erdadf109cd88569a6@mail.gmail.com>

On 25 April 2010 16:33, Ben Greear <greearb at candelatech.com> wrote:
> On 04/25/2010 01:50 AM, Mark Handley wrote:
>>
>> The LICENCE file does need to change, or it could be viewed as
>> granting copyright to XORP, Inc, which is not the intent. ?I'm fine
>> with your wording. ?It seems reasonably unambiguous.
>>
>> In addition to amending the licence, we should amend the copyright
>> line on any file we update to be:
>> // Copyright (c) 2001-2009 XORP, Inc and (c) 2010 by individual
>> contributors.
>>
>> This makes it clear that XORP, Inc does not own the copyright on new
>> changes on that specific file.
>
> Would it be fair to just change ALL copyright headers to have the wording
> as you suggest above, or just files we touch as we touch them in a
> non-trivial
> manner?

I think we need to do it on a case by case basis, tedious though that
is.  Changing it on files we have made no additional contribution to
seems to misrepresent the actual copyright situation.

Note that there is no issue if we forget to do this - copyright still
exists, event if you don't put a copyright notice on something.  The
copyright notice can always be fixed later.

 - Mark


From greearb at candelatech.com  Sun Apr 25 20:45:22 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 25 Apr 2010 20:45:22 -0700
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD3B74F.9060709@incunabulum.net>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net>
Message-ID: <4BD50C52.2050108@candelatech.com>

On 04/24/2010 08:30 PM, Bruce Simpson wrote:
> On 04/23/10 18:10, Mark Handley wrote:
>> Regarding boost, I think how we left it on the phone call last night
>> was that Bruce would write a short note saying what he believes boost
>> gives us, and why it's the right thing for Xorp.  So I'd like to wait
>> for that before we make a decision.
>>
>
> I have set out many of the benefits Boost offers for XORP, in previous
> postings to this mailing list over the last 6-9 months, so I'll be as
> concise here as possible:
>
>       * Boost is widely used by C++ projects of comparable size, and
> offer a thoroughly peer-reviewed alternative to some of what we have in
> libxorp.
>       Innovations from Boost itself are becoming part of the C++0x
> language specification. It is technically very strong.
>       I think it's unreasonable to expect folk to reinvent wheels which
> exist out there, and pretty much essential to stuff they're now doing;
> Boost can be considered part of the C++ state-of-the-art now, as such,
> it has project currency.
>
>       * The Boost shared_ptr/weak_ptr idioms, are a clean solution,
>         to very specific problems we see in async systems such as XORP.
>
>       That is, where we need to cleanly separate the reference of a C++
> object from its storage lifecycle.
>       Abusing ref_ptr further is syntactically not clear at all, and I
> strongly feel we should be using Boost instead. I am opposed to further
> use of ref_ptr (with&) because the intent of it is overloaded and
> confusing, to developers who are not intimately familiar with ref_ptr.
>       Far more C++ developers out there are likely to be familiar with
> Boost than libxorp.

The ref-pointer logic might could be done better, but I don't think we need
to include boost to do that.  We could, for instance, use a 'RefCountable'
base class that stores a ref count, and a RefPointer objec that stores a pointer
to RefCountable and manages the object lifetime.  In general, I think we
should minimize ref-pointer usage where possible, but in some places,
it is quite useful.

With regard to passing by reference or value, I do not understand the
confusion.  It's no different than any other object in that regard
and anyone programming in C++ just needs to understand the difference
in passing by ref v/s passing by value.

>       * The Boost.Interprocess library will enable using shared memory
> efficiently for fast-path IPC in future, something which currently slows
> down XORP *significantly* compared to other BGP designs;
>       14m vs 1m for full routing table convergence.
>       As I've said to Mark and others before, there are shared-memory
> versions of the list, map and other STL containers, which drop straight
> in to shared memory.
>       [FWIW Ravi at XORP, Inc. was proposing doing much the same thing,
> but hand-rolled]

Shared memory would require locking and/or message passing, and allows one
app to corrupt another.

My perf tests show in excess of 100,000 XRL transactions per second.  I suspect
that the main performance problem is that much of xorp is implemented to
allow only a single outstanding XRL at any given time.  We would likely
gain a great deal of performance by just implementing batching for operations
needing lots of XRLs.

I'd love to be able to reproduce this 14m v/s 1m BGP issue, but to date,
I haven't found a way to do that.  If anyone can help set up such a test,
I am very interested in diagnosing it.

>       * The Boost multi-index container has the potential to make large
> indexed structures, such as the RIB tables, and routing tables internal
> to most protocols, more efficient in time and space.
>       [I would have used it for OLSR, but ran out of time]

This sounds interesting, and might be a reason to look at boost again in
the future if/when someone had interest in implementing this sort of thing,
but without a patch to actually use this feature and some demonstration
of actual gain, it is not enough reason to start using boost in my opinion.

>       * Thrift requires Boost anyway. Despite forwarding the full
> reasoning behind my recommendation of Thrift to XORP, Inc., to replace
> much of XRL and fix the problems with it, I have still not had an
> opinion from Mark either way.

Again, XRL may not be perfect, but it seems relatively fast as is,
and there are several easy memory new/delete optimizations waiting
for an hour or two of time to implement.  If, as I suspect, the
root cause of performance issues is non-batching use of the IPC
mechanism, we just need to change the higher level code, and even
if XRL layer was infinitely fast, it would not solve the problem
without fixing the higher-level code.

>       * There are numerous other Boost refactorings possible. I did not
> finish them because life support went offline.
>
>       * Finally: We have already had others on xorp-hackers@ come
> forward, to say that work they've been doing on XORP requires Boost. Off
> the top of my head, Luca Belforte, for marshaling compound data
> structures out of routing processes.

No one has offered lately.  If someone plans to actively work on the public
XORP SVN tree and wants to use boost, hopefully they can also speak up
in support of using Boost.

> I don't buy the argument that '1 more external dependency is bad'. The
> Boost libraries as currently used, are mostly used as header files.
> However beyond regex, we don't use the runtime libraries. The use of the
> libraries, can easily be switched back over to pcre or platform regex
> (at a minimum). At the moment boost regex is just shimmed in.

The default regex works fine (at least on Linux), and I didn't even
have to link against any external libraries.  From what I can tell,
this is also the case on BSD.

> My view is that this argument is rooted more in unfamiliarity with
> systems-level C++, and how to optimize it effectively, than it actually
> posing a real problem.
>
> Boost is generally available as a binary package for the platforms
> tested by the Tinderbox.
> The Boost headers don't have any cross-compilation implications, apart
> from what someone cross-compiling XORP would need to do for an embedded
> target anyway, i.e. populate the staging area.

The downsides of boost for me are:

1)  It's a large, complex set of libraries that one would have to understand well to
   make good use of or even read boost-enabled xorp code.  It doesn't seem like
   it would replace any sizeable amount of Xorp logic, so it's simply more learning
   curve to overcome for anyone who doesn't already know boost.

2)  It is not installed by default on Fedora Linux (and others).  This means that users
   must install this to use xorp.  In some ways, this is a minor problem easily fixed, but
   it is one more impediment that might discourage new users.  Also, that it is not required
   by the base install of Fedora, indicates to me that it is not that widely used, at least in
   Linux.

2b.  It is a pain to get xorp-svn to compile on Ubuntu because you have to install a specific
   version of boost, and ubuntu has 2 to choose from.

3)  For anyone working with constrained amounts of disk storage, lib-boost is a large
   amount of extra disk space.

> I'd far rather see a release made than not, if only to regain confidence
> with an otherwise unheard-from user base.
> If the use of libboost_regex is the issue, that's a point I'm willing to
> compromise on for 1.7.
>
> But I'm not willing to do the work of backing anything out, as I firmly
> believe it's in XORP's future interests for the reasons given above.
> This is view borne in experience of being the only active developer on
> the open SVN branch for well over 6 months.

I'm more than happy to do the work to back it out, and I will do so in
a way that allows us to easily start using boost again in the future if
we so decide (xorp.ct can currently be compiled with or without boost support
currently).

So, as I'm sure you've noticed, my vote is to not use boost.

Thanks,
Ben

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


From bms at incunabulum.net  Mon Apr 26 02:28:55 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Mon, 26 Apr 2010 10:28:55 +0100
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD50C52.2050108@candelatech.com>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net>
	<4BD50C52.2050108@candelatech.com>
Message-ID: <4BD55CD7.7040202@incunabulum.net>

Hi,

Nothing like a good healthy rigorous technical debate on a caffeinated 
Monday morning.

On 04/26/10 04:45, Ben Greear wrote:
>
> The ref-pointer logic might could be done better, but I don't think we 
> need
> to include boost to do that.  We could, for instance, use a 
> 'RefCountable'
> base class that stores a ref count, and a RefPointer objec that stores 
> a pointer
> to RefCountable and manages the object lifetime.  In general, I think we
> should minimize ref-pointer usage where possible, but in some places,
> it is quite useful.

Thoroughly disagree,
the above is more or less suggesting reinventing the Boost smart_ptr 
library.

Why reinvent when you can reuse?

Your position seems to be that the cost of reuse is too high. I'll 
refute this position below

>
> With regard to passing by reference or value, I do not understand the
> confusion.  It's no different than any other object in that regard
> and anyone programming in C++ just needs to understand the difference
> in passing by ref v/s passing by value.

Thoroughly disagree,
operator overloads are what kibosh this argument

Taking the reference of a ref_ptr influences its behaviour,
in a way which is not at all clear from its syntax.

It isn't the first time I've had to do this, and I complained loudly to 
Atanu about it when I had to fix Spt's memory leaks when developing 
xorp_olsr for CenGen back in 2007, because it breaks the intent of the code.

This is a danger of operator overloads in C++ and the semantics aren't 
clear from the syntax --
Boost on the contrary has dealt with this problem well, it is becoming 
part of C++0x, it is already part of C++0x.

Do you honestly expect a developer under pressure to deliver rapidly,
to not make the mistake of misreading a & symbol?

For my part, I find this risk unacceptable, in my best professional 
judgement.

>
> Shared memory would require locking and/or message passing, and allows 
> one
> app to corrupt another.

We already implicitly lock on the socket buffers,
this is in effect pushing the burden of synchronization onto the host OS.

Shared memory allows "one app to corrupt another" if and only if page 
mappings fail a bounds check, this would either be due to software 
failure in the app's mappings, or a serious kernel security regression.

In practice address space is carefully managed and page boundaries are 
enforced
-- this point seems moot


> I'd love to be able to reproduce this 14m v/s 1m BGP issue, but to date,
> I haven't found a way to do that.  If anyone can help set up such a test,
> I am very interested in diagnosing it.

Please try running a production XORP router in the Default-Free Zone, or 
see:
     
http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2009-July/003277.html

PS I remember RIPE were very interested in XORP for collection --
they switched to Quagga probably for performance reasons (pure 
speculation on my part)

[Again see RIPE MRTd collection feeds I sent you off-list in the last 10 
days]

>
> Again, XRL may not be perfect, but it seems relatively fast as is,
> and there are several easy memory new/delete optimizations waiting
> for an hour or two of time to implement.

"Relatively fast" -- have you benchmarked this in a real app?

I have no reason to doubt Sebastien's figures,
and they converge with the experience of other former users such as 
Hasso Tepper.

Hasso was particularly critical of XORP's performance across the board,
however he was always careful to point out his criticism was constructive

If you want to tackle this point head on, feel free,
but I speculate that ye may reach much the same conclusions as I did,
when I was on the XORP, Inc. account.

Again, Mark's silence on this point is inscrutable.

>
> No one has offered lately.  If someone plans to actively work on the 
> public
> XORP SVN tree and wants to use boost, hopefully they can also speak up
> in support of using Boost.
>

Arguments about silent majorities abound.
I certainly plan to vote in the upcoming UK election --
unfortunately that system is largely not representative of my beliefs.

> The default regex works fine (at least on Linux), and I didn't even
> have to link against any external libraries.  From what I can tell,
> this is also the case on BSD.

It seems Boost's regex library is large relative to the size of regex/pcre
(mostly because of the C++ wrapper which we don't use yet)

I responded to Adam Greenhalgh off-list yesterday,
suggesting that moving back to platform regex is a reasonable compromise.

I believe this alone is enough to address boost objections based on 
resource -- please read on

We are in agreement on this point, but little else.

> The downsides of boost for me are:
>
> 1)  It's a large, complex set of libraries that one would have to 
> understand well to
>   make good use of or even read boost-enabled xorp code.  It doesn't 
> seem like
>   it would replace any sizeable amount of Xorp logic, so it's simply 
> more learning
>   curve to overcome for anyone who doesn't already know boost.

On the contrary, it's clearly documented and well presented in "Beyond 
the C++ Template Library" -- Karlsson
I encourage you to actually review the libraries and what they offer.

It's also part of the emerging new C++ standards.

I was reading "the Boost book" at the time when writing OLSR, and I can 
happily relate, that in that time, I spotted a number of opportunities 
for code re-use with Boost.
Indeed, ref_ptr was a garden rake on the ground for message processing.

There wasn't enough time to start from scratch once the project was in 
flight, and I had to deliver something which worked.
If I were to start again, I would use Boost. For me, it's as simple as 
that, I have confidence in it

XORP is already pretty sophisticated stuff for an entry-level C++ 
developer to comprehend.

This is largely qualitative argument, but it seems reasonable to believe 
that professional C++ developers nowadays,
are likely to find the learning curve for the XORP source code *lower*,
if it were to make use of a class/template library seeing uptake in that 
industry.

Currently this is not the case.

FWIW anyone in my day-to-day life outside of this screen and 4 walls,
who seek to learn C++, I tell them:
   "Learn Boost if you want a future in C++"

>
> 2)  It is not installed by default on Fedora Linux (and others).  This 
> means that users
>   must install this to use xorp.  In some ways, this is a minor 
> problem easily fixed, but
>   it is one more impediment that might discourage new users.  Also, 
> that it is not required
>   by the base install of Fedora, indicates to me that it is not that 
> widely used, at least in
>   Linux.

Neither is libncurses-dev, another XORP compile-time dependency,
which surely does not satisfy the definition of 'not that widely used' 
above -- but open to discussion

Quick search on rpm.pbone.net yields: 150 hits for Fedora 11 packages 
requiring boost

It is mostly a template library which tends to be used by servers / 
daemons / frameworks rather than desktop apps.
It is used by last.fm, Facebook, Spotify, and others.
   (Last reality check I did, those were highly successful ventures)

Their dev teams clearly see the value of Boost.
They have a set of requirements not dissimilar to those of XORP.

-- this point seems moot

>
> 2b.  It is a pain to get xorp-svn to compile on Ubuntu because you 
> have to install a specific
>   version of boost, and ubuntu has 2 to choose from.

This is only an issue if you're developing the code, not deploying it

-- this point seems moot
.
>
> 3)  For anyone working with constrained amounts of disk storage, 
> lib-boost is a large
>   amount of extra disk space.

This is only really an issue, if you actually need to deploy all of the 
libraries,
in addition to the headers.

We don't even touch the libraries apart from libboost_regex,
and as pointed out elsewhere in this response,
this issue is easily resolved.

Are you honestly saying,
that 35MB of headers/libs (which don't change apart from on a point 
release of the package),
is a problem for you when hosting a compile at development time?
(16MB of those are headers, and then, mostly comments and whitespace)

It's still substantially less than e.g. SunStudio or Intel C/C++'s disk 
footprint.
For the purposes of utility, it's not an apples-and-oranges comparison
(all are build infrastructure/toolchain)

If you must take that up with someone, take it up with your package vendor.

Ubuntu have split up the Boost packages significantly for this reason,
which helps folk out at deployment time.

Again, as Boost is mostly a C++ *TEMPLATE* library, as soon as we move 
back to platform regex,

-- this point seems moot


>
> I'm more than happy to do the work to back it out, and I will do so in
> a way that allows us to easily start using boost again in the future if
> we so decide (xorp.ct can currently be compiled with or without boost 
> support
> currently).

Backspace is an option for some.

What I'm advocating isn't even new or risky; it's state-of-the-art now,
and your objections seem easily met.

>
> So, as I'm sure you've noticed, my vote is to not use boost.

There seems to be significant difference of opinion on this issue,
and many of the points raised in objection,
don't seem rooted in fact (or are based on poor research)--

Apart from the point about libboost_regex being on the large side,
which I informally discussed with Adam yesterday,
and which is very easy to fix.

best regards
BMS


From a.greenhalgh at cs.ucl.ac.uk  Mon Apr 26 05:48:43 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Mon, 26 Apr 2010 13:48:43 +0100
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD55CD7.7040202@incunabulum.net>
References: <4BD1CD5F.3080603@candelatech.com>
	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net> <4BD50C52.2050108@candelatech.com> 
	<4BD55CD7.7040202@incunabulum.net>
Message-ID: <l2r4769af411004260548i4b494ec7g28cbf1300cf5c174@mail.gmail.com>

One possible approach is to just use those components of boost that
are going to form the C++0x spec.

Adam


From greearb at candelatech.com  Mon Apr 26 10:12:20 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 26 Apr 2010 10:12:20 -0700
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD55CD7.7040202@incunabulum.net>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net>
	<4BD50C52.2050108@candelatech.com>
	<4BD55CD7.7040202@incunabulum.net>
Message-ID: <4BD5C974.7050705@candelatech.com>

On 04/26/2010 02:28 AM, Bruce Simpson wrote:
> Hi,
>
> Nothing like a good healthy rigorous technical debate on a caffeinated
> Monday morning.
>
> On 04/26/10 04:45, Ben Greear wrote:
>>
>> The ref-pointer logic might could be done better, but I don't think we
>> need
>> to include boost to do that. We could, for instance, use a 'RefCountable'
>> base class that stores a ref count, and a RefPointer objec that stores
>> a pointer
>> to RefCountable and manages the object lifetime. In general, I think we
>> should minimize ref-pointer usage where possible, but in some places,
>> it is quite useful.
>
> Thoroughly disagree,
> the above is more or less suggesting reinventing the Boost smart_ptr
> library.
>
> Why reinvent when you can reuse?

If I re-write it, I can optimize it exactly for my needs, including adding
any debugging logic or similar that I see fit.  And, I can read the entirety
of the code and know that it is exactly the same on all platforms and OSs,
regardless of what someone else might have installed on their OS.


> Do you honestly expect a developer under pressure to deliver rapidly,
> to not make the mistake of misreading a & symbol?

There are all sorts of ways to write broken code, and bugs will go into
the system, but we can fix the bugs..and can review the code as it goes
in to check for that sort of thing.

I do expect developers to know the difference in value v/s ref, but if
they don't, I'm more than happy to explain it to them and/or fix the
bugs myself.


>> Shared memory would require locking and/or message passing, and allows
>> one
>> app to corrupt another.
>
> We already implicitly lock on the socket buffers,
> this is in effect pushing the burden of synchronization onto the host OS.
>
> Shared memory allows "one app to corrupt another" if and only if page
> mappings fail a bounds check, this would either be due to software
> failure in the app's mappings, or a serious kernel security regression.

The data in the shared memory can be corrupted, and requires locking and/or
message passing to keep that from happening.  I prefer to keep the apps' memory completely
separate, or merge them completely into the same single-threaded binary.

>> I'd love to be able to reproduce this 14m v/s 1m BGP issue, but to date,
>> I haven't found a way to do that. If anyone can help set up such a test,
>> I am very interested in diagnosing it.
>
> Please try running a production XORP router in the Default-Free Zone, or
> see:
> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2009-July/003277.html
>
> PS I remember RIPE were very interested in XORP for collection --
> they switched to Quagga probably for performance reasons (pure
> speculation on my part)
>
> [Again see RIPE MRTd collection feeds I sent you off-list in the last 10
> days]

I haven't figured out how to feed that MRTD data into xorp to test this,
and I don't have a network where I can put xorp on a BGP network.

The one part of bgp/harness logic that seems like it could feed MRTD data uses
non-batched XRL commands, so it's definitely going to be slow.  But, I might could
load on one xorp, and then have it peer with another and test that peer sync.


>> Again, XRL may not be perfect, but it seems relatively fast as is,
>> and there are several easy memory new/delete optimizations waiting
>> for an hour or two of time to implement.
>
> "Relatively fast" -- have you benchmarked this in a real app?

I tested with the xorp XRL sender/receiver test.  I also looked
at code in bgp, and it all seems serialized (one XRL request at a
time outstanding).  That means select, send, (process wake on receiver, including
flushing cache), select, receive, process-data, send result for every XRL request.
The original sender does no further work until it gets the response back, and receiver does no
work until it gets the next request.
Batching would be a huge improvement here.

> I have no reason to doubt Sebastien's figures,
> and they converge with the experience of other former users such as
> Hasso Tepper.

Sure, but that doesn't mean it's the IPC transport that is to blame.

> Hasso was particularly critical of XORP's performance across the board,
> however he was always careful to point out his criticism was constructive
>
> If you want to tackle this point head on, feel free,
> but I speculate that ye may reach much the same conclusions as I did,
> when I was on the XORP, Inc. account.

I need to be able to reproduce the problem first.  I think anyone attempting
to tackle this needs the same..otherwise we may waste months optimizing something
that doesn't actually matter.

>> 1) It's a large, complex set of libraries that one would have to
>> understand well to
>> make good use of or even read boost-enabled xorp code. It doesn't seem
>> like
>> it would replace any sizeable amount of Xorp logic, so it's simply
>> more learning
>> curve to overcome for anyone who doesn't already know boost.
>
> On the contrary, it's clearly documented and well presented in "Beyond
> the C++ Template Library" -- Karlsson
> I encourage you to actually review the libraries and what they offer.

Clearly documented is nice, but doesn't mean it isn't a learning curve.

>
> It's also part of the emerging new C++ standards.

When it emerges, and 5 years later when most distributions have supported
it for a few years, then I'd have less complaints, though I still don't like
using large opaque packages unless I really have to.

I vote no, you vote yes.  Hopefully others will chime in as well.

Thanks,
Ben

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


From greearb at candelatech.com  Mon Apr 26 11:37:59 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 26 Apr 2010 11:37:59 -0700
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD55CD7.7040202@incunabulum.net>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net>
	<4BD50C52.2050108@candelatech.com>
	<4BD55CD7.7040202@incunabulum.net>
Message-ID: <4BD5DD87.7020101@candelatech.com>

On 04/26/2010 02:28 AM, Bruce Simpson wrote:
> Hi,
>
> Nothing like a good healthy rigorous technical debate on a caffeinated
> Monday morning.
>
> On 04/26/10 04:45, Ben Greear wrote:
>>
>> The ref-pointer logic might could be done better, but I don't think we
>> need
>> to include boost to do that. We could, for instance, use a 'RefCountable'
>> base class that stores a ref count, and a RefPointer objec that stores
>> a pointer
>> to RefCountable and manages the object lifetime. In general, I think we
>> should minimize ref-pointer usage where possible, but in some places,
>> it is quite useful.
>
> Thoroughly disagree,
> the above is more or less suggesting reinventing the Boost smart_ptr
> library.
>
> Why reinvent when you can reuse?

By the way, I just tried to understand that boost smart_ptr and weak_ptr
by looking at the boost code.  I personally find it basically unreadable,
but I have never been too good at templates.

If I make an attempt at re-doing the smart-ptr logic, I think I'll
use inheritance instead of templates, as I find that type of code
much easier to understand.  It's not as general purpose, since your ref-counted
objects must inherit from a common base class, but since I think ref-pointers
should be used sparingly anyway, that shouldn't be a problem.

Thanks,
Ben

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


From bms at incunabulum.net  Tue Apr 27 03:23:28 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue, 27 Apr 2010 11:23:28 +0100
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD5C974.7050705@candelatech.com>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net>
	<4BD50C52.2050108@candelatech.com>
	<4BD55CD7.7040202@incunabulum.net>
	<4BD5C974.7050705@candelatech.com>
Message-ID: <4BD6BB20.8030905@incunabulum.net>

Ben,

Suddenly very busy -- comments inline

On 04/26/10 18:12, Ben Greear wrote:
>
>> Why reinvent when you can reuse?
>
>
> If I re-write it, I can optimize it exactly for my needs, including 
> adding
> any debugging logic or similar that I see fit.  And, I can read the 
> entirety
> of the code and know that it is exactly the same on all platforms and 
> OSs,
> regardless of what someone else might have installed on their OS.

class libraries are a fact of any professional C++ developer's life--
if one does not value one's time well, or if one is looking to learn,
then reimplementing something makes sense--

but it's uneconomic, if solutions are there ready to go.

Glad you have found shared_ptr.hpp and started exploring it--
it is difficult to improve on the pattern which has already been realized,
and I for one researched this thoroughly before advocating it

>
>> Do you honestly expect a developer under pressure to deliver rapidly,
>> to not make the mistake of misreading a & symbol?
>
> There are all sorts of ways to write broken code, and bugs will go into
> the system, but we can fix the bugs..and can review the code as it goes
> in to check for that sort of thing.
>
> I do expect developers to know the difference in value v/s ref, but if
> they don't, I'm more than happy to explain it to them and/or fix the
> bugs myself.

So this use of XORP is largely an educational exercise,
vs delivering a production router suite?

That's cool and someone should do that,
but the new game plan needs to be made explicit if that is the case

I appreciate there are varying levels of C++ expertise in this group --
however am wary of lowering the bar too far--
and XORP Inc eng team's experience bears this out (they also had varying 
levels of C++)

Sadly XORP is to C++ as James Joyce is to a tabloid newspaper,
it is an epic work and tries to make use of the language fully.

As you know my views on this are strong,
that we should have been looking to limit necessary use of C++ from the 
outset,
where it isn't actually needed in the system--

Templates are not going away; they are not an automatic foot-shooting 
device,
as many may well believe. Think of C++ as a surgeon's scalpel

However time is always against us. My argument viz typo still stands

>
>> Shared memory allows "one app to corrupt another" if and only if page
>> mappings fail a bounds check, this would either be due to software
>> failure in the app's mappings, or a serious kernel security regression.
>
>
> The data in the shared memory can be corrupted, and requires locking 
> and/or
> message passing to keep that from happening.  I prefer to keep the 
> apps' memory completely
> separate, or merge them completely into the same single-threaded binary.

Sure,
any communications channel is subject to the possibility of protocol failure

Shared memory poses specific problems precisely because it is a shared 
medium;
serialization still happens, just further down in cache/TLB land;
this is what tokens / generation numbers / atomics are for

If you examine Boost.Interprocess you'll see the atomics are already there.

No getting away from it, Xen widely makes use of 'grant tables' -- same 
thing

but a widely deployed class library,
which encapsulates these operations, and is thoroughly tested,
is unlikely to suffer from what is called out here as a possible issue

A single-threaded binary is even less likely to scale to multicore--
this is in effect advocating ditching the architecture -- ain't gonna 
happen--

and event channels are subject to all sorts (some like to use lockless 
queues to do this)

>
> The one part of bgp/harness logic that seems like it could feed MRTD 
> data uses
> non-batched XRL commands, so it's definitely going to be slow.  But, I 
> might could
> load on one xorp, and then have it peer with another and test that 
> peer sync.

That is probably a better solution--
once again sorry that BGP harness couldn't be fixed on XORP Inc account,
my former client's focus shifted

>
>
>>> Again, XRL may not be perfect, but it seems relatively fast as is,
>>> and there are several easy memory new/delete optimizations waiting
>>> for an hour or two of time to implement.
>>
>> "Relatively fast" -- have you benchmarked this in a real app?
>
> I tested with the xorp XRL sender/receiver test.  I also looked
> at code in bgp, and it all seems serialized (one XRL request at a
> time outstanding).  That means select, send, (process wake on 
> receiver, including
> flushing cache), select, receive, process-data, send result for every 
> XRL request.
> The original sender does no further work until it gets the response 
> back, and receiver does no
> work until it gets the next request.
> Batching would be a huge improvement here.

Yes it should lead to some improvement
and was implemented on the XORP, Inc corporate branch to my knowledge

There's nothing fundamentally wrong with how libxipc interfaces to other 
code--
but what is an issue is that XRL is largely its own thing,
and was mend/make do at the time (before better alternatives came along)

Refactoring is still a change cost.

>
> Sure, but that doesn't mean it's the IPC transport that is to blame.

Cycle for cycle, "something is not quite right in the state of XRL" to 
borrow from Shakespeare

>
> Clearly documented is nice, but doesn't mean it isn't a learning curve.

The learning curve for something which is now established practice in a 
professional field,
is still substantially less than bespoke practice

>
> When it emerges, and 5 years later when most distributions have supported
> it for a few years, then I'd have less complaints, though I still 
> don't like
> using large opaque packages unless I really have to.

Toolchains are large opaque packages, and as above
class libraries are a fact of any professional C++ developer's life--
not building model airplanes in shed anymore

regards
BMS


From bms at incunabulum.net  Tue Apr 27 03:53:57 2010
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue, 27 Apr 2010 11:53:57 +0100
Subject: [Xorp-hackers] SCons 1.3.0 released
Message-ID: <4BD6C245.7010902@incunabulum.net>

FYI new SCons release: http://www.scons.org/
In upstream BSD, don't know re Linux yet.


From greearb at candelatech.com  Tue Apr 27 07:21:10 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 27 Apr 2010 07:21:10 -0700
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD6BB20.8030905@incunabulum.net>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>
	<4BD3B74F.9060709@incunabulum.net>
	<4BD50C52.2050108@candelatech.com>
	<4BD55CD7.7040202@incunabulum.net>
	<4BD5C974.7050705@candelatech.com>
	<4BD6BB20.8030905@incunabulum.net>
Message-ID: <4BD6F2D6.3020400@candelatech.com>

On 04/27/2010 03:23 AM, Bruce Simpson wrote:

>>> Do you honestly expect a developer under pressure to deliver rapidly,
>>> to not make the mistake of misreading a & symbol?
>>
>> There are all sorts of ways to write broken code, and bugs will go into
>> the system, but we can fix the bugs..and can review the code as it goes
>> in to check for that sort of thing.
>>
>> I do expect developers to know the difference in value v/s ref, but if
>> they don't, I'm more than happy to explain it to them and/or fix the
>> bugs myself.
>
> So this use of XORP is largely an educational exercise,
> vs delivering a production router suite?

I am merely offering to help review code and help explain mistakes
to people as I find them, regardless of their experience.

I would hope that others will review my code and return the favour,
as I still make mistakes too.

> As you know my views on this are strong,
> that we should have been looking to limit necessary use of C++ from the
> outset,
> where it isn't actually needed in the system--

It's never too late to start making things better, and adding something
like boost, which appears to use every C++ trick in the book isn't going
in the right direction in my opinion.

> Templates are not going away; they are not an automatic foot-shooting
> device,
> as many may well believe. Think of C++ as a surgeon's scalpel
>
> However time is always against us. My argument viz typo still stands

I'll use templates when needed, just don't prefer them when other techniques
are easily available.

W/regard to ref-ptr v/s boost, would there be any difference between passing
a boost smart pointer by ref v/s val and passing a xorp ref-ptr  by ref v/s val?
If I understood the boost logic, you get the same basic behaviour with both.

> A single-threaded binary is even less likely to scale to multicore--
> this is in effect advocating ditching the architecture -- ain't gonna
> happen--

Considering the current cost of IPC, you would be very likely to increase
performance by consolidating xorp processes into a single binary.  I'm
not suggesting to do this because I like that the individual modules are
relatively simple and easy to debug, but just adding more processes is not always
a performance gain.

>> The one part of bgp/harness logic that seems like it could feed MRTD
>> data uses
>> non-batched XRL commands, so it's definitely going to be slow. But, I
>> might could
>> load on one xorp, and then have it peer with another and test that
>> peer sync.
>
> That is probably a better solution--
> once again sorry that BGP harness couldn't be fixed on XORP Inc account,
> my former client's focus shifted

I now have it mostly sorted out in xorp.ct.  As soon as we get 1.7 out and I'm
cleared to submit, I'll push it upstream.  A few bugs crept into bgp since
the tests were disabled (or started being ignored), but I'm fixing them or working
around them as I find them and nothing huge so far.

>> I tested with the xorp XRL sender/receiver test. I also looked
>> at code in bgp, and it all seems serialized (one XRL request at a
>> time outstanding). That means select, send, (process wake on receiver,
>> including
>> flushing cache), select, receive, process-data, send result for every
>> XRL request.
>> The original sender does no further work until it gets the response
>> back, and receiver does no
>> work until it gets the next request.
>> Batching would be a huge improvement here.
>
> Yes it should lead to some improvement
> and was implemented on the XORP, Inc corporate branch to my knowledge
>
> There's nothing fundamentally wrong with how libxipc interfaces to other
> code--
> but what is an issue is that XRL is largely its own thing,
> and was mend/make do at the time (before better alternatives came along)

"Better" is all hand waving until someone posts some actual performance numbers
and/or shows a patch with significant code clean up.

In a volunteer project such as xorp has become, you cannot force people to use
a particular method of development.  If someone posts patches and such, then
whoever or whatever group is in charge can accept or decline the patches based
on merit.  I have ongoing plans to continue to post patches and improve xorp,
and I see no need for boost in my plans.  If you expect to make ongoing contributions
to xorp, then you can post patches that use boost and show the actual advantages.
But, if you do NOT have any plans to contribute in the near future, then don't
expect others to write code using _your_ preferred methodologies.

Thanks,
Ben

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


From kohler at cs.ucla.edu  Tue Apr 27 07:27:33 2010
From: kohler at cs.ucla.edu (Eddie Kohler)
Date: Tue, 27 Apr 2010 07:27:33 -0700
Subject: [Xorp-hackers] Boost use
In-Reply-To: <4BD6F2D6.3020400@candelatech.com>
References: <4BD1CD5F.3080603@candelatech.com>	<k2v84a612dd1004231010r782e0ef2o37a8b949c5b85915@mail.gmail.com>	<4BD3B74F.9060709@incunabulum.net>	<4BD50C52.2050108@candelatech.com>	<4BD55CD7.7040202@incunabulum.net>	<4BD5C974.7050705@candelatech.com>	<4BD6BB20.8030905@incunabulum.net>
	<4BD6F2D6.3020400@candelatech.com>
Message-ID: <4BD6F455.2090303@cs.ucla.edu>

Hey!

I am not a Xorp developer but I used to be.  For what it's worth, from the 
outside:

* Boost is a very well designed and respected library.  It isn't a fanboy 
library or like some jQuery plugin.  And well-designed C++ libraries are 
often, unfortunately, difficult to read -- try looking at an STL 
implementation.  So Ben's main objections don't really land for me.  But:

* Boost is a very LARGE library and using all of its parts would be a mistake. 
  I agree with Ben on improving XRL IPC being a better path than using Boost 
shard-memory magic.

* In my opinion, it seems that the most widely agreed upon parts of Boost 
include shared_ptr, Math, MPI, and Thread.  As someone suggested, using the 
parts of Boost accepted for C++0x would not be a bad path.

Eddie


Ben Greear wrote:
> On 04/27/2010 03:23 AM, Bruce Simpson wrote:
> 
>>>> Do you honestly expect a developer under pressure to deliver rapidly,
>>>> to not make the mistake of misreading a & symbol?
>>> There are all sorts of ways to write broken code, and bugs will go into
>>> the system, but we can fix the bugs..and can review the code as it goes
>>> in to check for that sort of thing.
>>>
>>> I do expect developers to know the difference in value v/s ref, but if
>>> they don't, I'm more than happy to explain it to them and/or fix the
>>> bugs myself.
>> So this use of XORP is largely an educational exercise,
>> vs delivering a production router suite?
> 
> I am merely offering to help review code and help explain mistakes
> to people as I find them, regardless of their experience.
> 
> I would hope that others will review my code and return the favour,
> as I still make mistakes too.
> 
>> As you know my views on this are strong,
>> that we should have been looking to limit necessary use of C++ from the
>> outset,
>> where it isn't actually needed in the system--
> 
> It's never too late to start making things better, and adding something
> like boost, which appears to use every C++ trick in the book isn't going
> in the right direction in my opinion.
> 
>> Templates are not going away; they are not an automatic foot-shooting
>> device,
>> as many may well believe. Think of C++ as a surgeon's scalpel
>>
>> However time is always against us. My argument viz typo still stands
> 
> I'll use templates when needed, just don't prefer them when other techniques
> are easily available.
> 
> W/regard to ref-ptr v/s boost, would there be any difference between passing
> a boost smart pointer by ref v/s val and passing a xorp ref-ptr  by ref v/s val?
> If I understood the boost logic, you get the same basic behaviour with both.
> 
>> A single-threaded binary is even less likely to scale to multicore--
>> this is in effect advocating ditching the architecture -- ain't gonna
>> happen--
> 
> Considering the current cost of IPC, you would be very likely to increase
> performance by consolidating xorp processes into a single binary.  I'm
> not suggesting to do this because I like that the individual modules are
> relatively simple and easy to debug, but just adding more processes is not always
> a performance gain.
> 
>>> The one part of bgp/harness logic that seems like it could feed MRTD
>>> data uses
>>> non-batched XRL commands, so it's definitely going to be slow. But, I
>>> might could
>>> load on one xorp, and then have it peer with another and test that
>>> peer sync.
>> That is probably a better solution--
>> once again sorry that BGP harness couldn't be fixed on XORP Inc account,
>> my former client's focus shifted
> 
> I now have it mostly sorted out in xorp.ct.  As soon as we get 1.7 out and I'm
> cleared to submit, I'll push it upstream.  A few bugs crept into bgp since
> the tests were disabled (or started being ignored), but I'm fixing them or working
> around them as I find them and nothing huge so far.
> 
>>> I tested with the xorp XRL sender/receiver test. I also looked
>>> at code in bgp, and it all seems serialized (one XRL request at a
>>> time outstanding). That means select, send, (process wake on receiver,
>>> including
>>> flushing cache), select, receive, process-data, send result for every
>>> XRL request.
>>> The original sender does no further work until it gets the response
>>> back, and receiver does no
>>> work until it gets the next request.
>>> Batching would be a huge improvement here.
>> Yes it should lead to some improvement
>> and was implemented on the XORP, Inc corporate branch to my knowledge
>>
>> There's nothing fundamentally wrong with how libxipc interfaces to other
>> code--
>> but what is an issue is that XRL is largely its own thing,
>> and was mend/make do at the time (before better alternatives came along)
> 
> "Better" is all hand waving until someone posts some actual performance numbers
> and/or shows a patch with significant code clean up.
> 
> In a volunteer project such as xorp has become, you cannot force people to use
> a particular method of development.  If someone posts patches and such, then
> whoever or whatever group is in charge can accept or decline the patches based
> on merit.  I have ongoing plans to continue to post patches and improve xorp,
> and I see no need for boost in my plans.  If you expect to make ongoing contributions
> to xorp, then you can post patches that use boost and show the actual advantages.
> But, if you do NOT have any plans to contribute in the near future, then don't
> expect others to write code using _your_ preferred methodologies.
> 
> Thanks,
> Ben
> 


From greearb at candelatech.com  Tue Apr 27 11:05:51 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 27 Apr 2010 11:05:51 -0700
Subject: [Xorp-hackers] scons question
Message-ID: <4BD7277F.4060500@candelatech.com>

I'm having troubles getting the bgp harness to pass 'scons check' properly.

I have code like this in bgp/harness/SConscript

if 'check' in COMMAND_LINE_TARGETS:
     for ss in script_srcs:
         env.Alias('check', env.Execute(Copy('%s' % ss, '../../../../bgp/harness/%s' %ss)))

     # Tests to run automatically with 'scons test'
     env.Alias('check', env.Execute(env.Action('./test_peering1.sh')))
     env.Alias('check', env.Execute(env.Action('./test_peering2.sh')))
     env.Alias('check', env.Execute(env.Action('./test_peering3.sh')))
     env.Alias('check', env.Execute(env.Action('./test_routing1.sh')))
     env.Alias('check', env.Execute(env.Action('./test_routing2.sh')))
     env.Alias('check', env.Execute(env.Action('./test_rib1.sh')))
     env.Alias('check', env.Execute(env.Action('./test_rib_fea1.sh')))
     env.Alias('check', env.Execute(env.Action('./test_path_attribute1.sh')))
     env.Alias('check', env.Execute(env.Action('./test_path_attribute2.sh')))
     env.Alias('check', env.Execute(env.Action('./test_path_attribute3.sh')))
     env.Alias('check', env.Execute(env.Action('./test_route_reflection1.sh')))
     env.Alias('check', env.Execute(env.Action('./test_route_reflection2.sh')))
     env.Alias('check', env.Execute(env.Action('./test_route_flap_damping1.sh')))
     env.Alias('check', env.Execute(env.Action('./test_terminate.sh')))

This all seems to work fine, as far as running the tests go.

But, then, scons throws a strange error:

...
[ 2010/04/27 10:48:33.821139 INFO xorp_bgp BGP ] EVENT: timers 3
[ 2010/04/27 10:48:33.821177 INFO xorp_bgp BGP ] xrl router still has pending operations
[ 2010/04/27 10:48:33.821192 INFO xorp_bgp BGP ] xrl router no more pending operations

******************* Command:     ../xorp_bgp         exited status: 0 10585
[ 2010/04/27 10:48:33.823299 WARNING xorp_finder LIBXORP ] read error: _fd: 17  offset: 0  total-len: 4 error: Connection reset by peer
./test_terminate.sh: Tests Succeeded
SIGTERM received. Exiting.
Leaving ./test_terminate.sh   -l -t test2

scons: warning: Two different environments were specified for target aspath.os,
	but they appear to have the same action: $SHCXX -o $TARGET -c $SHCXXFLAGS $SHCCFLAGS $_CCCOMCOM $SOURCES
File "/home/greearb/git/svn-xorp/dev-xorp/xorp.ct/bgp/SConscript", line 135, in <module>
scons: done reading SConscript files.
scons: Building targets ...
scons: *** [check] AttributeError : 'int' object has no attribute 'get_csig'
scons: building terminated because of errors.


line 135 of the bgp/SConscript is *THIS*:

if is_shared:
     libxorp_bgp = bgp_env.SharedLibrary(target = 'libxorp_bgp',
                                         source = libxorp_bgp_srcs,
  *THIS*                                       LIBS = '')

     if bgp_env['rtld_origin']:
         for obj in libxorp_bgp:
             bgp_env.AddPostAction(libxorp_bgp,
                 bgp_env.Symlink(obj.abspath,
                                 os.path.join(bgp_env['xorp_alias_libdir'], str(obj))))
else:
     libxorp_ospf = bgp_env.StaticLibrary(target = 'libxorp_bgp',
                                          source = libxorp_bgp_srcs,
                                          LIBS = '')


Anyone know what might be causing this error, or suggestions for improving the
bgp/harness scons logic?

Thanks,
Ben


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


From greearb at candelatech.com  Tue Apr 27 15:57:55 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 27 Apr 2010 15:57:55 -0700
Subject: [Xorp-hackers] scons question
In-Reply-To: <4BD7277F.4060500@candelatech.com>
References: <4BD7277F.4060500@candelatech.com>
Message-ID: <4BD76BF3.2070809@candelatech.com>

On 04/27/2010 11:05 AM, Ben Greear wrote:
> I'm having troubles getting the bgp harness to pass 'scons check' properly.

Looks like the problem wasn't on the line I thought it was.

The env.Execute logic I was trying to use to run the scripts
made scons exit with error if any test failed.  So, I'm using
call('./foo.sh') now.  That seems to work better.

I pushed these changes to xorp.ct.  If anyone has a chance to
build it and then run 'scons check', I'm interested to know how
it turns out.

Thanks,
Ben

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


From saurabh.pandya at elitecore.com  Wed Apr 28 07:37:04 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Wed, 28 Apr 2010 20:07:04 +0530
Subject: [Xorp-hackers] [Xorp-users] Xorp Router with ISP (RP discovery?) -
 ISP not supporting PIM
Message-ID: <4BD84810.3050206@elitecore.com>

Dear All,

I have two ISP for my multi-cast experiment

1) wireless broadband (eth3)
2) wired broadband (ppp0)

-ForWireless ISP I even can't see any IGMP/PIM message
over ppp0 interface (with tcpdump -i ppp0) after ppp0 get connected.

-with wired broadband: (eth3)
For Wired ISP I can't see any PIM message but I could see IGMP queries !
means ISP not running PIM-SM on their router.
They are not willing to provide information on their multicast setup !

I want my xorp router to act in behalf on underlaying networks to get
multi-cast data streams from Internet for their active mcast group
listeners ?
 
Do I need IGMP proxy for this purpose ? (any suggestion)
 
Current Xorp have any hack for such proxy-ing  ? Or it is in future
road-map ? 

Thanks in advance,
Saurabh


From greearb at candelatech.com  Wed Apr 28 08:10:35 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 28 Apr 2010 08:10:35 -0700
Subject: [Xorp-hackers] [Xorp-users] Xorp Router with ISP (RP
 discovery?) - ISP not supporting PIM
In-Reply-To: <4BD84810.3050206@elitecore.com>
References: <4BD84810.3050206@elitecore.com>
Message-ID: <4BD84FEB.3080805@candelatech.com>

On 04/28/2010 07:37 AM, saurabh wrote:
> Dear All,
>
> I have two ISP for my multi-cast experiment
>
> 1) wireless broadband (eth3)
> 2) wired broadband (ppp0)
>
> -ForWireless ISP I even can't see any IGMP/PIM message
> over ppp0 interface (with tcpdump -i ppp0) after ppp0 get connected.

Xorp isn't sending any messages at all on ppp0?  Maybe it only uses
mcast on broadcast interfaces (such as Ethernet).

> -with wired broadband: (eth3)
> For Wired ISP I can't see any PIM message but I could see IGMP queries !
> means ISP not running PIM-SM on their router.
> They are not willing to provide information on their multicast setup !

I think if the upstream won't run multicast routing, there isn't much you
could do locally to fix the problem.

Thanks,
Ben

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


From greearb at candelatech.com  Wed Apr 28 10:58:28 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 28 Apr 2010 10:58:28 -0700
Subject: [Xorp-hackers] RFC:  Patch to remove boost regex from xorp.
Message-ID: <4BD87744.5040609@candelatech.com>

This does not disable any other use of boost, but I think
it means that the users of pre-compiled xorp binaries
will no longer have to have boost installed on their system.

Folks wanting to compile xorp will still need at least
the template header files.

Passed build and 'scons check' on x86-64, Fedora 11.

It seems I'm the only one who really wants to get rid of the
boost dependency entirely, so we can go ahead and release
1.7 with the boost compile-time dependencies if no one
objects to this patch.

Thanks,
Ben

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorp_trunk_rm_boost_regex.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100428/95c33d59/attachment.ksh 

From a.greenhalgh at cs.ucl.ac.uk  Wed Apr 28 12:12:38 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Wed, 28 Apr 2010 20:12:38 +0100
Subject: [Xorp-hackers] RFC: Patch to remove boost regex from xorp.
In-Reply-To: <4BD87744.5040609@candelatech.com>
References: <4BD87744.5040609@candelatech.com>
Message-ID: <v2u4769af411004281212qa6d54c03m5aae31a654d6dc61@mail.gmail.com>

This looks reasonable to me given that it can be backed out for 1.8 ,
if we choose collectively to go with some version of boost.

Adam

On 28 April 2010 18:58, Ben Greear <greearb at candelatech.com> wrote:
> This does not disable any other use of boost, but I think
> it means that the users of pre-compiled xorp binaries
> will no longer have to have boost installed on their system.
>
> Folks wanting to compile xorp will still need at least
> the template header files.
>
> Passed build and 'scons check' on x86-64, Fedora 11.
>
> It seems I'm the only one who really wants to get rid of the
> boost dependency entirely, so we can go ahead and release
> 1.7 with the boost compile-time dependencies if no one
> objects to this patch.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>


From saurabh.pandya at elitecore.com  Thu Apr 29 03:44:58 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Thu, 29 Apr 2010 16:14:58 +0530
Subject: [Xorp-hackers] [Xorp-users] Xorp Router with ISP (RP
 discovery?) - ISP not supporting PIM
In-Reply-To: <4BD84FEB.3080805@candelatech.com>
References: <4BD84810.3050206@elitecore.com> <4BD84FEB.3080805@candelatech.com>
Message-ID: <4BD9632A.8090105@elitecore.com>

On 04/28/2010 08:40 PM, Ben Greear wrote:
> On 04/28/2010 07:37 AM, saurabh wrote:
>> Dear All,
>>
>> I have two ISP for my multi-cast experiment
>>
>> 1) wireless broadband (eth3)
>> 2) wired broadband (ppp0)
>>
>> -ForWireless ISP I even can't see any IGMP/PIM message
>> over ppp0 interface (with tcpdump -i ppp0) after ppp0 get connected.
>
> Xorp isn't sending any messages at all on ppp0?  Maybe it only uses
> mcast on broadcast interfaces (such as Ethernet).
Xorp is sending IGMP quries and PIM hellos, but these is no IGMP/PIM
movement from wireless ISP side!!
Its is EDGE broadband connection..
>
>> -with wired broadband: (eth3)
>> For Wired ISP I can't see any PIM message but I could see IGMP queries !
>> means ISP not running PIM-SM on their router.
>> They are not willing to provide information on their multicast setup !
>
> I think if the upstream won't run multicast routing, there isn't much you
> could do locally to fix the problem.
May IGMP proxies solve this issue, when ISP not running PIM but running
IGMP.
According to my knowledge these proxies forward IGMP join and leave
messages to
ISP router on behalf of underlaying network. So that IGMP based ISP then
able to
route multicast data to your router. 

I eager to know that If anybody had clubbed some IGMP proxy with xorp or
run them
independently with xorp? Any hint/point will be helpful .. :)

Thanks,
Saurabh



From greearb at candelatech.com  Thu Apr 29 12:28:03 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 29 Apr 2010 12:28:03 -0700
Subject: [Xorp-hackers] Fix for some bgp crashes (xorp.ct)
Message-ID: <4BD9DDC3.4060509@candelatech.com>

While playing around with xorp-bgp and our network emulator, I killed the
connection between two bgp peers for 10 seconds and restarted the network.

xorp_bgp asserted and crashed.  One of the crashes is below..the other was similar.

This patch appears to fix things.  I've committed these to xorp.ct, but posting
here for review in case I've made a mistake.

[greearb at ben-dt2 xorp.ct]$ git diff bf465857d2000f76fa5268e058c3f3617a3c1ee1
diff --git a/bgp/socket.cc b/bgp/socket.cc
index c0152e2..4c08188 100644
--- a/bgp/socket.cc
+++ b/bgp/socket.cc
@@ -243,6 +243,10 @@ SocketClient::connected(XorpFd s)

      XLOG_ASSERT(!get_sock().is_valid());
      XLOG_ASSERT(!_connecting);
+    // Clean up any old reader/writers we might have around.
+    // This can happen if you kill network connection between two peers
+    // for 10 seconds and then re-start it.
+    async_remove();
      set_sock(s);
      async_add(s);
  }
@@ -562,7 +566,6 @@ SocketClient::connect_socket_complete(XorpFd sock, IoEventType type,
  void
  SocketClient::connect_socket_break()
  {
-    XLOG_ASSERT(_connecting);
      _connecting = false;

      eventloop().remove_ioevent_cb(get_sock());



#0  0x0000003b07c332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0000003b07c34b20 in *__GI_abort () at abort.c:88
#2  0x00007fd5dc5fe6bd in xlog_fatal (module_name=0x7fd5ddfd1215 "BGP", line=<value optimized out>, file=<value optimized out>,
     function=<value optimized out>, fmt=0x7fd5dc61feac "Assertion (%s) failed") at libxorp/xlog.c:467
#3  0x00007fd5dc5fe75d in xlog_assert (module_name=0x4f62 <Address 0x4f62 out of bounds>, line=20322, file=0x6 <Address 0x6 out of bounds>,
     function=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>, failedexpr=<value optimized out>) at libxorp/xlog.c:480
#4  0x00007fd5ddfb5da2 in SocketClient::async_add (this=0x14937d0, sock=<value optimized out>) at bgp/socket.cc:577
#5  0x00007fd5ddfb5f05 in SocketClient::connected (this=0x14937d0, s=<value optimized out>) at bgp/socket.cc:247
#6  0x00007fd5ddf37da6 in BGPPeer::event_open (this=0x1494a10, sock=<value optimized out>) at bgp/peer.cc:1258
#7  0x00007fd5ddf384bf in AcceptSession::start (this=0x14d8ce0) at bgp/peer.cc:2293
#8  0x00007fd5ddf385cc in BGPPeer::connected (this=0x1494a10, sock=<value optimized out>) at bgp/peer.cc:1762
#9  0x00007fd5dded9a81 in BGPMain::connect_attempt (this=<value optimized out>, fd=<value optimized out>, type=<value optimized out>,
     laddr=<value optimized out>, lport=<value optimized out>) at bgp/bgp.cc:874
#10 0x00007fd5ddee12df in XorpMemberCallback2B2<void, BGPMain, XorpFd, IoEventType, std::string, unsigned short>::dispatch (this=0x14d9370,
     a1=<value optimized out>, a2=IOT_ACCEPT) at ./libxorp/callback_nodebug.hh:5226
#11 0x00007fd5dc61350d in SelectorList::Node::run_hooks (fd=<value optimized out>, m=<value optimized out>, this=<value optimized out>)
     at libxorp/selector.cc:198
#12 SelectorList::wait_and_dispatch (fd=<value optimized out>, m=<value optimized out>, this=<value optimized out>) at libxorp/selector.cc:533
#13 0x00007fd5dc602506 in EventLoop::do_work (this=0x7fff51e7e270, can_block=<value optimized out>) at libxorp/eventloop.cc:143
#14 0x00007fd5dc6025c8 in EventLoop::run (this=0x7fff51e7e270) at libxorp/eventloop.cc:96
#15 0x00007fd5dded8be5 in BGPMain::main_loop (this=0x7fff51e7e760) at bgp/bgp.cc:758
#16 0x00000000004015f8 in main (argv=0x7fff51e7ead8) at bgp/main.cc:93

Thanks,
Ben

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


From greearb at candelatech.com  Thu Apr 29 22:57:31 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 29 Apr 2010 22:57:31 -0700
Subject: [Xorp-hackers] How to go about doing an official release?
Message-ID: <4BDA714B.9020709@candelatech.com>

I've just updated the docs and release notes to version 1.7
instead of 1.7-WIP.

I think that we are ready to attempt an official 1.7 release.

At a minimum, I think we should:

*  Add a tag to SVN
*  Package up a tar.gz snapshot of the source code.
*  Build tar.gz of a binary install for each of the tinderbox machines.

*  Upload these things to sourceforge.


As soon as we get this done, I'll bump the rls to 1.8-WIP and start
merging my xorp.ct patches upstream (unless there are objections, of course).

Thanks,
Ben

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


From a.greenhalgh at cs.ucl.ac.uk  Fri Apr 30 02:55:31 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Fri, 30 Apr 2010 10:55:31 +0100
Subject: [Xorp-hackers] How to go about doing an official release?
In-Reply-To: <4BDA714B.9020709@candelatech.com>
References: <4BDA714B.9020709@candelatech.com>
Message-ID: <k2l4769af411004300255m1ea8b80eze23b6b72f5d37aa3@mail.gmail.com>

I'd like to try xorp + click to see if that works for this release.

Adam

On 30 April 2010 06:57, Ben Greear <greearb at candelatech.com> wrote:
> I've just updated the docs and release notes to version 1.7
> instead of 1.7-WIP.
>
> I think that we are ready to attempt an official 1.7 release.
>
> At a minimum, I think we should:
>
> * ?Add a tag to SVN
> * ?Package up a tar.gz snapshot of the source code.
> * ?Build tar.gz of a binary install for each of the tinderbox machines.
>
> * ?Upload these things to sourceforge.
>
>
> As soon as we get this done, I'll bump the rls to 1.8-WIP and start
> merging my xorp.ct patches upstream (unless there are objections, of course).
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Fri Apr 30 08:16:53 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 30 Apr 2010 08:16:53 -0700
Subject: [Xorp-hackers] How to go about doing an official release?
In-Reply-To: <k2l4769af411004300255m1ea8b80eze23b6b72f5d37aa3@mail.gmail.com>
References: <4BDA714B.9020709@candelatech.com>
	<k2l4769af411004300255m1ea8b80eze23b6b72f5d37aa3@mail.gmail.com>
Message-ID: <4BDAF465.1020102@candelatech.com>

On 04/30/2010 02:55 AM, Adam Greenhalgh wrote:
> I'd like to try xorp + click to see if that works for this release.

Please do post your results, including how to reproduce them.
I've never used click with xorp.

Thanks,
Ben

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


From a.greenhalgh at cs.ucl.ac.uk  Fri Apr 30 03:06:29 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Fri, 30 Apr 2010 11:06:29 +0100
Subject: [Xorp-hackers] Fwd: [Xorp-cvs] SF.net SVN: xorp:[11699] trunk/xorp
In-Reply-To: <u2y4769af411004300259sfbbfa73fm36d9407b60a45a4e@mail.gmail.com>
References: <E1O7j2J-0002I4-76@sfp-svn-1.v30.ch3.sourceforge.com> 
	<u2y4769af411004300259sfbbfa73fm36d9407b60a45a4e@mail.gmail.com>
Message-ID: <m2r4769af411004300306w61b0db72m8759a8872e59de3d@mail.gmail.com>

---------- Forwarded message ----------
From: Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk>
Date: 30 April 2010 10:59
Subject: Re: [Xorp-cvs] SF.net SVN: xorp:[11699] trunk/xorp
To: greear at users.sourceforge.net
Cc: xorp-cvs at xorp.org


I think this bit of the patch needs rolling back or changing something
that mentions a decreased compile time at the slight risk of
additional errors during the build process. Its rare I know, but I
have seen it, and those that have done any significant development
work will know about the -j flag anyway.

-scons
+scons -j4

adam

On 30 April 2010 06:45, ?<greear at users.sourceforge.net> wrote:
> Revision: 11699
> ? ? ? ? ?http://xorp.svn.sourceforge.net/xorp/?rev=11699&view=rev
> Author: ? greear
> Date: ? ? 2010-04-30 05:45:14 +0000 (Fri, 30 Apr 2010)
>
> Log Message:
> -----------
> release: ?Update release notes and similar, version to 1.7
>
> Signed-off-by: Ben Greear <greearb at candelatech.com>
>
> Modified Paths:
> --------------
> ? ?trunk/xorp/BUGS
> ? ?trunk/xorp/BUILD_NOTES
> ? ?trunk/xorp/ERRATA
> ? ?trunk/xorp/README
> ? ?trunk/xorp/RELEASE_NOTES
> ? ?trunk/xorp/TODO
> ? ?trunk/xorp/VERSION
> ? ?trunk/xorp/etc/templates/xorpsh.cmds
> ? ?trunk/xorp/rtrmgr/master_conf_tree.cc
>
> Modified: trunk/xorp/BUGS
> ===================================================================
> --- trunk/xorp/BUGS ? ? 2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/BUGS ? ? 2010-04-30 05:45:14 UTC (rev 11699)
> @@ -1,6 +1,3 @@
> -#
> -# $XORP$
> -#
>
> ?* Please report bugs using Trac: http://sourceforge.net/apps/trac/xorp/
>
>
> Modified: trunk/xorp/BUILD_NOTES
> ===================================================================
> --- trunk/xorp/BUILD_NOTES ? ? ?2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/BUILD_NOTES ? ? ?2010-04-30 05:45:14 UTC (rev 11699)
> @@ -1,6 +1,3 @@
> -#
> -# $XORP: xorp/BUILD_NOTES,v 1.116 2009/01/08 01:22:02 syedk Exp $
> -#
>
> ? ? ? ?Build Notes for XORP (eXtensible Open Router Platform)
>
> @@ -8,10 +5,9 @@
> ?0. Preface
> ?==========
>
> -As of September 2009, much of the information in this file may be outdated,
> -and should probably be moved to a Wiki. Some instructions refer to the
> -old GNU Autotools based build system, which is now deprecated. SNMP support
> -is currently deprecated and requires a rewrite.
> +XORP builds on Linux and BSD variants that support the 'scons' build
> +system and GNU g++ compiler toolset. ?Please ask on the xorp-hackers
> +mailing list if your preferred system is not currently supported.
>
> ?1. Compilation
> ?==============
> @@ -22,7 +18,8 @@
> ?To compile XORP, you must have SCons installed. Then just
> ?run the following commands in the top-level directory:
>
> -scons
> +scons -j4
> +scons install
>
> ?To change the default C and C++ compilers, then assign the binary
> ?names to the CC and CXX user environmental variables respectively.
> @@ -36,6 +33,9 @@
> ?those flags to the CFLAGS and CXXFLAGS environmental variables (for the
> ?C and C++ compiler respectively) before running "scons".
>
> +For various compile options use: ?scons --help
> +
> +
> ?1.2 Generating documentation
> ?============================
>
> @@ -303,44 +303,18 @@
> ?3.5. Linux
> ?==========
>
> - ?* Linux Red Hat-7.2 (kernel 2.4.18):
> - ? ?- The code compiles, but some of the internal tests fail dumping core.
> - ? ? ?The problem is attributable to exception handler failures caused by
> - ? ? ?the default compiler/binutils combination. ?More information is
> - ? ? ?available at:
> - ? ? ? http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=54724
> - ? ?- IGMP and PIM-SM appear to work.
> + ?* It is difficult to get distributions older than Fedora Core 5
> + ? ?to compile XORP 1.7, primarily due to scons and python dependencies.
>
> - ?* Linux Red Hat-7.3 (kernel 2.4-20):
> - ? ?- No known issues.
> - ? ?- The code should compile with the following versions of the
> - ? ? ?gcc/g++ compiler: 2.96 (default).
> -
> - ?* Linux Red Hat-9.2 (kernel 2.4.20-8smp):
> - ? ?- You must install the following RPMs (and all other RPMs they depend on):
> - ? ? ?- openssl-devel (e.g., openssl-devel-0.9.7a-5.i386.rpm)
> - ? ? ?- ncurses (e.g., ncurses-5.3-4.i386.rpm)
> - ? ?- The code compiles, and the internal tests appear to succeed.
> -
> ? * Linux Red Hat Enterprise Linux Server release 5 (Tikanga)
> ? ? (kernel 2.6.18-8.el5)
> ? ? - Optionally install the following packages:
> ? ? ? - libpcap-devel (e.g., libpcap-devel.x86_64)
> ? ? ? ? This package is needed for sending/receiving link layer data frames.
> - ? ? ?- net-snmp, net-snmp-utils, net-snmp-devel, net-snmp-perl
> - ? ? ? ?Those packages are needed for SNMP support.
> ? ? - The code compiles, and the internal tests appear to succeed.
> ? ? - gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52)
> ? ? - Tested on the following architectures: x86_64 (amd64)
>
> - ?* Linux Fedora Core2 (kernel 2.6.5-1.358):
> - ? ?- The code compiles, but some of the internal tests may fail.
> -
> - ?* Linux Fedora Core4 (kernel 2.6.11-1.1369_FC4smp):
> - ? ?- The code compiles, and the internal tests appear to succeed
> - ? ? ?with the following compilers: gcc-4.0.0 (default), gcc-4.0.1,
> - ? ? ?gcc-4.0.2.
> -
> ? * Linux Fedora Core5 (2.6.16-1.2080_FC5smp):
> ? ? - The code compiles, and the internal tests appear to succeed.
> ? ? - gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
> @@ -364,8 +338,6 @@
> ? ? - Optionally install the following packages:
> ? ? ? - libpcap-devel
> ? ? ? ? This package is needed for sending/receiving link layer data frames.
> - ? ?- The code compiles, and the internal tests appear to succeed
> - ? ? ?except test33 in "bgp/harness/test_peering1.sh"
> ? ? - gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
>
> ? * Linux Fedora 10 (2.6.27.5-117.fc10.i686):
> @@ -397,12 +369,6 @@
> ? ? ? Either create a link from gcc to gcc-3.3 and from g++ to g++-3.3,
> ? ? ? or set the CC and CXX environments to point to the binary names.
> ? ? ? E.g., in csh/tcsh: setenv CC gcc-3.3; setenv CXX g++-3.3
> - ? ?- If you see an error like the following when compiling with make/gmake:
> - ? ? ? ?python ../../xrl/scripts/tgt-gen -I../../xrl/interfaces finder.tgt
> - ? ? ? ?sh: line 1: cpp: command not found
> - ? ? ?then you would need to create a link from cpp to the C preprocessor.
> - ? ? ?E.g., if the C preprocessor is /usr/bin/cpp-3.3, then execute as root:
> - ? ? ? ?cd /usr/bin; ln -s cpp-3.3 cpp
> ? ? - The code compiles, and the internal tests appear to succeed.
> ? ? - gcc-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-13)
>
> @@ -448,11 +414,6 @@
>
> ? * Linux Ubuntu-7.04 (Server Edition, kernel 2.6.20-15-server):
> ? ? - You must install the following packages:
> - ? ? ?- make
> - ? ? ? ?Note that the installed binary name is "make" so you need
> - ? ? ? ?to run "make" instead of "gmake" to compile the source code.
> - ? ? ? ?Alternatively, add "gmake" as a symbolic link to "make":
> - ? ? ? ?cd /usr/bin; ln -s make gmake
> ? ? ? - libssl-dev (e.g., version 0.9.8c-4build1)
> ? ? ? - gcc (e.g., gcc-4.1)
> ? ? ? - g++ (e.g., g++-4.1)
> @@ -467,19 +428,12 @@
>
> ? * Linux Ubuntu-7.10 (Server Edition, kernel 2.6.22-14-server):
> ? ? - You must install the following packages:
> - ? ? ?- make
> - ? ? ? ?Note that the installed binary name is "make" so you need
> - ? ? ? ?to run "make" instead of "gmake" to compile the source code.
> - ? ? ? ?Alternatively, add "gmake" as a symbolic link to "make":
> - ? ? ? ?cd /usr/bin; ln -s make gmake
> ? ? ? - libssl-dev (e.g., version 0.9.8e-5ubuntu3.1)
> ? ? ? - gcc (e.g., gcc-4.1)
> ? ? ? - g++ (e.g., g++-4.1)
> ? ? - Optionally install the following packages:
> ? ? ? - libpcap0.8-dev
> ? ? ? ? This package is needed for sending/receiving link layer data frames.
> - ? ? ?- snmpd and libsnmp-dev
> - ? ? ? ?Those packages are needed for SNMP support.
> ? ? ? - iptables-dev
> ? ? ? ? This package is needed for configuring firewall rules using XORP.
> ? ? - The code compiles, and the internal tests appear to succeed.
> @@ -488,19 +442,12 @@
>
> ? * Linux Ubuntu-8.04.1 (Server Edition, kernel 2.6.24-19-server):
> ? ? - You must install the following packages:
> - ? ? ?- make
> - ? ? ? ?Note that the installed binary name is "make" so you need
> - ? ? ? ?to run "make" instead of "gmake" to compile the source code.
> - ? ? ? ?Alternatively, add "gmake" as a symbolic link to "make":
> - ? ? ? ?cd /usr/bin; ln -s make gmake
> ? ? ? - libssl-dev (e.g., version 0.9.8g-4ubuntu3.3)
> ? ? ? - gcc (e.g., gcc-4.2)
> ? ? ? - g++ (e.g., g++-4.2)
> ? ? - Optionally install the following packages:
> ? ? ? - libpcap0.8-dev
> ? ? ? ? This package is needed for sending/receiving link layer data frames.
> - ? ? ?- snmpd and libsnmp-dev
> - ? ? ? ?Those packages are needed for SNMP support.
> ? ? ? - iptables-dev
> ? ? ? ? This package is needed for configuring firewall rules using XORP.
> ? ? - The code compiles, and the internal tests appear to succeed.
> @@ -509,19 +456,12 @@
>
> ? * Linux Ubuntu-8.10 (Server Edition, kernel 2.6.27-7-server):
> ? ? - You must install the following packages:
> - ? ? ?- make
> - ? ? ? ?Note that the installed binary name is "make" so you need
> - ? ? ? ?to run "make" instead of "gmake" to compile the source code.
> - ? ? ? ?Alternatively, add "gmake" as a symbolic link to "make":
> - ? ? ? ?cd /usr/bin; ln -s make gmake
> ? ? ? - libssl-dev (e.g., 0.9.8g-10.1ubuntu2)
> ? ? ? - gcc (e.g., gcc-4.3)
> ? ? ? - g++ (e.g., g++-4.3)
> ? ? - Optionally install the following packages:
> ? ? ? - libpcap0.8-dev
> ? ? ? ? This package is needed for sending/receiving link layer data frames.
> - ? ? ?- snmpd and libsnmp-dev
> - ? ? ? ?Those packages are needed for SNMP support.
> ? ? ? - iptables-dev
> ? ? ? ? This package is needed for configuring firewall rules using XORP.
> ? ? - The code compiles, and the internal tests appear to succeed.
> @@ -558,6 +498,7 @@
>
> ?3.6. Mac OS X
> ?=============
> + ?* NOTE: ?I have no idea if XORP 1.7 on Mac OS X compiles at all. --Ben
>
> ? * All:
> ? ? - Unicast routing appears to work.
> @@ -583,495 +524,26 @@
>
> ?3.7 Microsoft Windows
> ?=====================
> + ?* Not supported any longer.
>
> - ?* All:
> - ? ?- We encourage users to try XORP on newer, unsupported versions of
> - ? ? ?Windows and report their results to the development team.
> -
> - ? ?- 64-bit versions of Windows are known not to support MinGW, and are
> - ? ? ?therefore not currently supported by XORP.
> -
> - ? ?- For instructions how to build the XORP Installer for Windows
> - ? ? ?see xorp/contrib/win32/installer/README.
> -
> - ? ?- NOTE WELL: If you are trying to build XORP with MinGW-current as of
> - ? ? ?31st July 2006, you will need to manually remove the
> - ? ? ?-Wmissing-declarations and -Wmissing-prototypes warning flags from
> - ? ? ?the CPARANOIDFLAGS variable in XORP's configure script in order
> - ? ? ?to build XORP without interruption.
> - ? ? ?This is due to the new way that MSVCRT inline functions are dealt
> - ? ? ?with in the mingw-runtime system headers. No other workaround
> - ? ? ?is known at this time.
> -
> - ?* Windows Server 2003 (Service Pack 1) (32-bit, x86):
> - ? ?- XORP is only supported on Windows Server 2003, and is targeted for
> - ? ? ?32-bit x86 systems.
> -
> - ? ?- If a Win32 support patch is shipped for your release, please apply
> - ? ? ?it before filing bug reports with the core team.
> -
> - ? ?- Unicast routing appears to work.
> - ? ?- All regression tests pass as of XORP 1.2.
> - ? ?- IPv6 is not supported.
> - ? ?- RTMv2 is not supported.
> - ? ?- Multicast is not supported.
> -
> - ? ?- The code compiles using the MinGW port of gcc 3.4.2, using the
> - ? ? ?MSYS shell environment.
> -
> - ? ?- Instructions for building XORP on Windows Server are identical
> - ? ? ?to those for building XORP on a UNIX platform. However, the
> - ? ? ?following caveats apply.
> -
> - ? ? ?* If you specify the --with-openssl option to configure, it may be
> - ? ? ? ?propagated to the libtecla build, causing the top-level make to break.
> -
> - ? ? ?* Any paths passed to the configure script must be in MinGW UNIX-style
> - ? ? ? ?format. Example: 'C:\XORP' becomes '/c/xorp'.
> -
> - ? ? ?A patch must be manually applied to the MinGW toolchain before
> - ? ? ?attempting to build XORP, as we use API functions which are present in
> - ? ? ?the Windows SDK but which are not yet present in the system headers
> - ? ? ?which ship with MinGW as of May 2006.
> -
> - ? ? ?You MAY need to bracket references to off_t in MinGW's <unistd.h>
> - ? ? ?header with '#if 0'.
> -
> - ? ? ?The patch may be found in the xorp/contrib/win32 directory.
> -
> - ? ? ?* Download the source for w32api-3.7 from mingw.org and untar it
> - ? ? ? ?into a writable location.
> - ? ? ?* Change into this directory.
> - ? ? ?* Apply the w32api-3.7-xorp.patch to this tree with 'patch -p1'.
> - ? ? ?* From within the w32api-3.7 directory, run ./configure --prefix=/usr
> - ? ? ? ?to ensure that the existing w32api binary installation will be
> - ? ? ? ?overwritten.
> - ? ? ? ?(The paths under the MinGW / are aliased under /usr too, but the
> - ? ? ? ?w32api makefiles are confused by a single slash in their PREFIX.)
> - ? ? ?* make && make install
> -
> - ? ? ?If you encounter any problems, please send the output of the command
> - ? ? ?"msysinfo all" and contact the XORP development team with this
> - ? ? ?information.
> -
> - ? ?- We recommend that you install MinGW, MSYS, and the required GNU/Win32
> - ? ? ?ports under the path C:\MinGW\, in that order.
> -
> - ? ?- We recommend that you initially use the Nullsoft Installer which
> - ? ? ?is now shipping on MinGW.org to install the 'current' version of
> - ? ? ?the base MinGW tools.
> -
> - ? ?- Once the base MinGW installation is complete, you should then
> - ? ? ?manually update the toolchain which this program installs by
> - ? ? ?downloading and untarring the following packages in the root of
> - ? ? ?your MinGW installation.
> -
> - ? ? ? * MSYS-1.0.11-2004
> - ? ? ? * binutils-2.15.91
> - ? ? ? * gcc-g++
> - ? ? ? * gcc-core
> - ? ? ? * gdb-6.3-1
> - ? ? ? * mingw-runtime
> - ? ? ? * mingw-utils
> - ? ? ? * mingw32-make
> - ? ? ? * msysDTK-1.0.0
> - ? ? ? * w32api-3.7
> -
> - ? ?- Make sure that symbolic links or copies of mingw32-make.exe as
> - ? ? ?make.exe and gmake.exe respectively in your MinGW path.
> -
> - ? ?- You must install the following GNU/Win32 ports:-
> -
> - ? ? ? * openssl-bin (Binaries)
> - ? ? ? * openssl-lib (Developer files)
> - ? ? ? * pcre-bin (Binaries)
> - ? ? ? * pcre-lib (Developer files)
> -
> - ? ? ?They may be found at: http://gnuwin32.sourceforge.net/packages.html
> -
> - ? ?- You must install Python for Windows if you intend to run the
> - ? ? ?regression tests. This may be found at: http://www.python.org/download/
> -
> - ? ? ?The path to the python.exe binary must either be present in PATH after
> - ? ? ?installation, or a symlink created in the MinGW environment.
> -
> - ? ?- In certain cases the compilation might try to use Python to
> - ? ? ?auto-generate some files. In that case, one possible work-around
> - ? ? ?solution would be install Python. However, if the compilation
> - ? ? ?fails with an error like:
> -
> -/c/python24/python ../../xrl/scripts/tgt-gen -I../../xrl/interfaces bgp.tgt
> -process_begin: CreateProcess((null), /c/python24/python ../../xrl/scripts/tgt-gen -I../../xrl/interfaces bgp.tgt, ...) failed.
> -make (e=3): The system cannot find the path specified.
> -
> - ? ? ?then try using the following command in the top-level XORP directory:
> -
> - ? ? ?env PYTHON=C:/dos/style/path/to/python.exe ./configure
> -
> - ? ?- The RunShellCommand class has a hard-coded path to the MSYS shell.
> - ? ? ?This is currently a no-op because the router manager no longer uses
> - ? ? ?this class for running XORP modules.
> -
> - ? ?- To take a full BGP route feed, a registry key must be updated:
> - ? ? ?HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
> - ? ? ?must be set to 0xFFFFFFFF. Be warned that this removes the upper
> - ? ? ?limit on use of nonpageable system memory for kernel FIB entries;
> - ? ? ?if the kernel FIB memory requirements ever exceed physical memory,
> - ? ? ?the NT kernel will panic.
> -
> - ? ? ?The XORP installer has a property page which allows this to be set
> - ? ? ?by the administrator, but it does not roll back these settings when
> - ? ? ?XORP is uninstalled.
> -
> - ? ?- If the Windows Routing and Remote Access (RRAS) service is running,
> - ? ? ?the XORP FEA process may not be able to update the Windows IPv4
> - ? ? ?routing tables. The FEA will detect when this service is running
> - ? ? ?and print a warning message to the XORP process log.
> -
> - ? ?- The XORP Shell (xorpsh.exe) should be run from within a native
> - ? ? ?Win32 command prompt. If run from within any other kind of shell,
> - ? ? ?it may not work.
> -
> - ?* Windows 'Longhorn' Server (Build 5384) (32-bit, x86):
> - ? ?- XORP is known to compile on this operating system, but is currently
> - ? ? ?unsupported, with the following caveats as they apply to the
> - ? ? ?instructions given for building under Windows Server 2003:
> -
> - ? ? ?* MinGW and MSYS must be installed in separate directories in order
> - ? ? ? ?to work.
> - ? ? ?* As such, MSYSROOT must be set to point to the MSYS root directory,
> - ? ? ? ?and links/copies of sh.exe and bash.exe made in the MinGW tree.
> - ? ? ?* The GnuWin32 utilities should be installed in the MinGW tree.
> - ? ? ?* The latest bleeding-edge MinGW toolchain is in use (g++ 3.4.5).
> - ? ? ?* ActiveState Python is known to install correctly; the open source
> - ? ? ? ?Python will not.
> -
> - ? ? ?The following points only apply to the use of the XORP tinderbox:
> - ? ? ?* A copy or link of sh.exe as bash.exe must be made for the BGP
> - ? ? ? ?regression tests to run.
> - ? ? ?* CopSSH does not install under Vista or Longhorn.
> - ? ? ?* SSH for Windows does not install under Vista or Longhorn.
> - ? ? ?* Subsystem for UNIX Applications (SUA), as an alternative means of
> - ? ? ? ?running sshd, is not ready as of this writing for Vista or Longhorn.
> -
> - ?* Windows Vista Ultimate Beta (Build 5384) (32-bit, x86):
> - ? ?- The binary snapshots for Windows Server 2003 are known to run on
> - ? ? ?this operating system, but are not officially supported.
> -
> ?3.8. Cross-compilation
> ?======================
> + ?* Not supported at this time, but may not be difficult to enable.
>
> - ?* All:
> - ? ?- Running the "gmake check" internal tests within the
> - ? ? ?cross-compilation environment will not work, unless the build
> - ? ? ?machine is capable of running the cross-compiled binaries for the
> - ? ? ?target architecture.
> -
> - ?* IA-64
> - ? ?- The code is known to cross-compile on Linux, but it is unknown
> - ? ? ?whether the internal tests succeed.
> - ? ? ?XORP itself hasn't been tested on IA-64 machine, so it is unknown
> - ? ? ?whether it will run properly.
> -
> - ?* MIPS (Broadcom for Linksys WRT54G)
> - ? ?- The code is known to cross-compile on Linux, but it is unknown
> - ? ? ?whether the internal tests succeed.
> - ? ? ?XORP itself hasn't been tested on Linksys WRT54, so it is unknown
> - ? ? ?whether it will run properly.
> -
> - ?* PowerPC-603
> - ? ?- The code is known to cross-compile on Linux, but it is unknown
> - ? ? ?whether the internal tests succeed.
> - ? ? ?XORP itself hasn't been tested on PowerPC-603 machine, so it is
> - ? ? ?unknown whether it will run properly.
> -
> - ?* Sparc64
> - ? ?- The code is known to cross-compile on Linux, but it is unknown
> - ? ? ?whether the internal tests succeed.
> - ? ? ?XORP itself hasn't been tested on Sparc64 machine, so it is unknown
> - ? ? ?whether it will run properly.
> -
> - ?* XScale
> - ? ?- The code is known to cross-compile on Linux, but it is unknown
> - ? ? ?whether the internal tests succeed.
> - ? ? ?XORP appears to run on Linux MontaVista-3.1, but it hasn't been
> - ? ? ?tested thoughtfully.
> -
> - ?* Instructions for installing crosstool-based cross-compilation tools.
> -
> - ? ?Use the following instructions to install cross-compilation tools
> - ? ?and use those tools to compile XORP:
> -
> - ? ?a) Download crosstool from http://kegel.com/crosstool/ and untar it:
> -
> - ? ? ? wget http://kegel.com/crosstool/crosstool-0.42.tar.gz
> - ? ? ? tar zxvf crosstool-0.42.tar.gz
> - ? ? ? cd crosstool-0.42
> -
> - ? ?b) Apply one of the following patches:
> -
> - ? ? ? - IA-64
> - ? ? ? ? patch < demo-ia64.sh.patch
> -
> -----------------------------------------------------------------------
> ---- demo-ia64.sh.org ? 2005-03-09 13:49:19.000000000 -0800
> -+++ demo-ia64.sh ? ? ? 2006-10-18 17:37:25.000000000 -0700
> -@@ -18,6 +18,7 @@
> - #eval `cat ia64.dat gcc-3.4.0-glibc-2.3.2.dat` ? ? ? ?sh all.sh --notest
> - #eval `cat ia64.dat gcc-3.4.1-glibc-2.3.2.dat` ? ? ? ?sh all.sh --notest
> - #eval `cat ia64.dat gcc-3.4.1-glibc-2.3.3.dat` ? ? ? ?sh all.sh --notest
> -- eval `cat ia64.dat gcc-3.4.2-glibc-2.3.3.dat` ? ? ? ?sh all.sh --notest
> -+# eval `cat ia64.dat gcc-3.4.2-glibc-2.3.3.dat` ? ? ? ?sh all.sh --notest
> -+ eval `cat ia64.dat gcc-3.4.5-glibc-2.3.6.dat` ? ? ? ?sh all.sh --notest
> -
> - echo Done.
> -----------------------------------------------------------------------
> -
> - ? ? ? - MIPS (Broadcom for Linksys WRT54G)
> - ? ? ? ? patch < demo-mipsel.sh.patch
> -
> -----------------------------------------------------------------------
> ---- demo-mipsel.sh.org 2005-03-07 16:34:34.000000000 -0800
> -+++ demo-mipsel.sh ? ? 2006-10-25 16:25:59.000000000 -0700
> -@@ -33,8 +33,9 @@
> - #eval `cat mipsel.dat gcc-3.4.0-glibc-2.3.2.dat` ? ? ? ?sh all.sh --notest
> - #eval `cat mipsel.dat gcc-3.4.1-glibc-2.2.5.dat` ? ? ? ?sh all.sh --notest
> - #eval `cat mipsel.dat gcc-3.4.1-glibc-2.3.2.dat` ? ? ? ?sh all.sh --notest
> -- eval `cat mipsel.dat gcc-3.4.2-glibc-2.2.5.dat` ? ? ? ?sh all.sh --notest
> -+# eval `cat mipsel.dat gcc-3.4.2-glibc-2.2.5.dat` ? ? ? ?sh all.sh --notest
> - #eval `cat mipsel.dat gcc-3.4.2-glibc-2.3.3.dat` ? ? ? ?sh all.sh --notest
> - #eval `cat mipsel.dat gcc-3.4.2-glibc-20040827.dat` ? ? ? ?sh all.sh --notest
> -+eval `cat mipsel.dat gcc-3.4.5-glibc-2.3.6.dat` ? ? ? ?sh all.sh --notest
> -
> - echo Done.
> -----------------------------------------------------------------------
> -
> - ? ? ? - PowerPC-603
> - ? ? ? ? cp -p demo-ppc604.sh demo-ppc603.sh
> - ? ? ? ? patch < demo-ppc603.sh.patch
> -
> -----------------------------------------------------------------------
> ---- demo-ppc603.sh.org 2005-03-07 16:34:34.000000000 -0800
> -+++ demo-ppc603.sh ? ? 2006-12-14 17:13:18.000000000 -0800
> -@@ -11,8 +11,9 @@
> - mkdir -p $RESULT_TOP
> -
> - # Build the toolchain. ?Takes a couple hours and a couple gigabytes.
> --#eval `cat powerpc-604.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --builduserland --notest
> -- eval `cat powerpc-604.dat gcc-3.4.1-glibc-2.3.3.dat` ?sh all.sh --notest
> --#eval `cat powerpc-604.dat gcc-3.4.1-glibc-20040827.dat` sh all.sh --notest
> -+#eval `cat powerpc-603.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --builduserland --notest
> -+# eval `cat powerpc-603.dat gcc-3.4.1-glibc-2.3.3.dat` ?sh all.sh --notest
> -+#eval `cat powerpc-603.dat gcc-3.4.1-glibc-20040827.dat` sh all.sh --notest
> -+eval `cat powerpc-603.dat gcc-4.1.0-glibc-2.3.6.dat` ?sh all.sh --notest
> -
> - echo Done.
> -----------------------------------------------------------------------
> -
> - ? ? ? - Sparc64
> - ? ? ? ? patch < demo-sparc64.sh.patch
> -
> -----------------------------------------------------------------------
> ---- demo-sparc64.sh.org ? ? ? ?2005-03-07 16:34:34.000000000 -0800
> -+++ demo-sparc64.sh ? ?2006-11-06 19:31:57.000000000 -0800
> -@@ -15,7 +15,8 @@
> - #eval `cat sparc64.dat gcc-3.3.2-glibc-2.3.2.dat` sh all.sh --notest
> - #eval `cat sparc64.dat gcc-3.3.3-glibc-2.3.2.dat` sh all.sh --notest
> - #eval `cat sparc64.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --notest
> -- eval `cat sparc64.dat gcc-3.4.2-glibc-2.3.3.dat` sh all.sh --notest --testlinux
> -+# eval `cat sparc64.dat gcc-3.4.2-glibc-2.3.3.dat` sh all.sh --notest --testlinux
> - #eval `cat sparc64.dat gcc-3.4.2-glibc-20040827.dat` sh all.sh --notest
> -+eval `cat sparc64.dat gcc-3.4.5-glibc-2.3.6.dat` sh all.sh --notest
> -
> - echo Done.
> -----------------------------------------------------------------------
> -
> - ? ? ? - XScale
> - ? ? ? ? patch < demo-armv5b-softfloat.sh.patch
> -
> -----------------------------------------------------------------------
> ---- demo-armv5b-softfloat.sh.org ? ? ? 2005-03-07 16:34:34.000000000 -0800
> -+++ demo-armv5b-softfloat.sh ? 2006-10-18 15:24:05.000000000 -0700
> -@@ -13,7 +13,8 @@
> - # Build the toolchain. ?Takes a couple hours and a couple gigabytes.
> -
> - #eval `cat armv5b-softfloat.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --notest
> -- eval `cat armv5b-softfloat.dat gcc-3.4.1-glibc-2.3.3.dat` sh all.sh --notest
> -+# eval `cat armv5b-softfloat.dat gcc-3.4.1-glibc-2.3.3.dat` sh all.sh --notest
> - #eval `cat armv5b-softfloat.dat gcc-3.4.1-glibc-20040827.dat` sh all.sh --notest
> -+ eval `cat armv5b-softfloat.dat gcc-3.4.5-glibc-2.3.6.dat` sh all.sh --notest
> -
> - echo Done.
> -----------------------------------------------------------------------
> -
> - ? ?c) Compile the toolchain and install it:
> -
> - ? ? ? sudo mkdir /opt/crosstool
> - ? ? ? sudo chown $USER /opt/crosstool
> -
> - ? ? ? # Unset the LD_LIBRARY_PATH environmetal variable
> - ? ? ? setenv _SAVE_LD_LIBRARY_PATH $LD_LIBRARY_PATH
> - ? ? ? unsetenv LD_LIBRARY_PATH
> -
> - ? ? ? # Perform the compilation (it tay take a while)
> -
> - ? ? ? - IA-64
> - ? ? ? ? sh demo-ia64.sh
> -
> - ? ? ? - MIPS (Broadcom for Linksys WRT54G)
> - ? ? ? ? sh demo-mipsel.sh
> -
> - ? ? ? - PowerPC-603
> - ? ? ? ? sh demo-ppc603.sh
> -
> - ? ? ? - Sparc64
> - ? ? ? ? sh demo-sparc64.sh
> -
> - ? ? ? - XScale
> - ? ? ? ? sh demo-armv5b-softfloat.sh
> -
> - ? ? ? # Restore the original LD_LIBRARY_PATH environmetal variable
> - ? ? ? cd ..
> - ? ? ? setenv LD_LIBRARY_PATH $_SAVE_LD_LIBRARY_PATH
> - ? ? ? unsetenv _SAVE_LD_LIBRARY_PATH
> -
> - ? ?d) Set some environmetal variables that will be used later.
> - ? ? ? The values need to be modified appropriately if the tools
> - ? ? ? are installed in different directory.
> -
> - ? ? ? - IA-64
> - ? ? ? ? setenv CROSS_ARCH ia64-unknown-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> - ? ? ? ? setenv CROSS_ROOT_ARCH ${CROSS_ROOT}/${CROSS_ARCH}
> -
> - ? ? ? - MIPS (Broadcom for Linksys WRT54G)
> - ? ? ? ? setenv CROSS_ARCH mipsel-unknown-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> - ? ? ? ? setenv CROSS_ROOT_ARCH ${CROSS_ROOT}/${CROSS_ARCH}
> -
> - ? ? ? - PowerPC-603
> - ? ? ? ? setenv CROSS_ARCH powerpc-603-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-4.1.0-glibc-2.3.6/${CROSS_ARCH}
> - ? ? ? ? setenv CROSS_ROOT_ARCH ${CROSS_ROOT}/${CROSS_ARCH}
> -
> - ? ? ? - Sparc64
> - ? ? ? ? setenv CROSS_ARCH sparc64-unknown-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> - ? ? ? ? setenv CROSS_ROOT_ARCH ${CROSS_ROOT}/${CROSS_ARCH}
> -
> - ? ? ? - XScale
> - ? ? ? ? setenv CROSS_ARCH armv5b-softfloat-linux
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> - ? ? ? ? setenv CROSS_ROOT_ARCH ${CROSS_ROOT}/${CROSS_ARCH}
> -
> - ? ?e) Download openssl from http://www.openssl.org/ and untar it:
> -
> - ? ? ? wget http://www.openssl.org/source/openssl-0.9.8d.tar.gz
> - ? ? ? tar zxvf openssl-0.9.8d.tar.gz
> - ? ? ? cd openssl-0.9.8d
> -
> - ? ?f) Add a line like the following to file "Configure" in the section
> - ? ? ? with other Linux targets. Note that the second field might need
> - ? ? ? to be modified to match the exact path name of the installed
> - ? ? ? cross-compiler.
> -
> - ? ? ? - IA-64
> -"ia64-unknown-linux-gnu", ? ? ?"/opt/crosstool/gcc-3.4.5-glibc-2.3.6/ia64-unknown-linux-gnu/bin/ia64-unknown-linux-gnu-gcc:-DL_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -
> - ? ? ? - MIPS (Broadcom for Linksys WRT54G)
> -"mipsel-unknown-linux-gnu", ? ?"/opt/crosstool/gcc-3.4.5-glibc-2.3.6/mipsel-unknown-linux-gnu/bin/mipsel-unknown-linux-gnu-gcc:-DL_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -
> - ? ? ? - PowerPC-603
> -"powerpc-603-linux-gnu", ? ? ? "/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc-603-linux-gnu/bin/powerpc-603-linux-gnu-gcc:-DB_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_RISC1 DES_UNROLL::${no_asm}::::::::::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -
> - ? ? ? - Sparc64
> -"sparc64-unknown-linux-gnu", ? ?"/opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc:-DB_ENDIAN -DTERMIOS -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -
> - ? ? ? - XScale
> -"armv5b-softfloat-linux", ? ? ?"/opt/crosstool/gcc-3.4.5-glibc-2.3.6/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-gcc:-DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -
> - ? ?g) Cross-compile openssl and install it:
> -
> - ? ? ? ./Configure $CROSS_ARCH
> - ? ? ? make INSTALL_PREFIX=$CROSS_ROOT_ARCH install
> -
> - ? ?h) Prepare the XORP cross-compilation environment.
> - ? ? ? The first three commands can be skipped if they were done in
> - ? ? ? step (d):
> -
> - ? ? ? - IA-64
> - ? ? ? ? setenv CROSS_ARCH ia64-unknown-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> -
> - ? ? ? - MIPS (Broadcom for Linksys WRT54G)
> - ? ? ? ? setenv CROSS_ARCH mipsel-unknown-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> -
> - ? ? ? - PowerPC-603
> - ? ? ? ? setenv CROSS_ARCH powerpc-603-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-4.1.0-glibc-2.3.6/${CROSS_ARCH}
> -
> - ? ? ? - Sparc64
> - ? ? ? ? setenv CROSS_ARCH sparc64-unknown-linux-gnu
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> -
> - ? ? ? - XScale
> - ? ? ? ? setenv CROSS_ARCH armv5b-softfloat-linux
> - ? ? ? ? setenv CROSS_ROOT /opt/crosstool/gcc-3.4.5-glibc-2.3.6/${CROSS_ARCH}
> -
> - ? ? ? setenv CROSS_ROOT_ARCH ${CROSS_ROOT}/${CROSS_ARCH}
> - ? ? ? setenv CC ${CROSS_ROOT}/bin/${CROSS_ARCH}-gcc
> - ? ? ? setenv CXX ${CROSS_ROOT}/bin/${CROSS_ARCH}-g++
> - ? ? ? setenv LD ${CROSS_ROOT}/bin/${CROSS_ARCH}-ld
> - ? ? ? setenv RANLIB ${CROSS_ROOT}/bin/${CROSS_ARCH}-ranlib
> - ? ? ? setenv NM ${CROSS_ROOT}/bin/${CROSS_ARCH}-nm
> -
> - ? ? ? [Optional]
> - ? ? ? setenv PATH ${PATH}:${CROSS_ROOT}/bin
> - ? ? ? rehash
> -
> - ? ?i) Cross-compile XORP:
> -
> - ? ? ? cd /path/to/xorp/source/code
> - ? ? ? ./configure --host=${CROSS_ARCH} --with-openssl=${CROSS_ROOT_ARCH}/usr/local/ssl
> - ? ? ? gmake
> -
> -
> ?4. Performance optimization
> ?===========================
>
> -[Note: this section is incomplete]
> -
> ?By default, XORP is compiled with compiler debug information enabled
> -and no optimization.
> +and moderate optimization.
>
> -Use the following command to disable the compiler debug information and
> -to enable optimization:
> +See 'scons --help' for more options.
>
> -./configure --enable-optimize --disable-debug
>
> -Remember that if XORP was compiled previously with different options,
> -it must be recompiled from scratch:
> -
> -gmake clean
> -gmake
> -
> -Additional compiler-related optimizations flags can be specified on
> -the command line by setting CFLAGS (the C compiler flags) and CXXFLAGS
> -(the C++ compiler flags). E.g., the following options can be used for
> -Intel PentiumPro CPU optimizations:
> -
> -./configure --enable-optimize --disable-debug \
> - ? ?"CFLAGS=-march=pentiumpro -O3 -fomit-frame-pointer" \
> - ? ?"CXXFLAGS=-march=pentiumpro -O3 -fomit-frame-pointer"
> -
> -Other flags that can be set on the command line are CPPFLAGS (the C/C++
> -pre-processor flags), and LDFLAGS (the linker flags).
> -
> -
> ?5. Setting-up Ubuntu for XORP Installation
> ?==========================================
>
> +[ This section is at least partially out-dated. ]
> +
> ?1)Install Ubuntu from Live CD - all default values hold good.
> ?2)Add your login name to the sudoers file
> ?3)Edit interfaces file
>
> Modified: trunk/xorp/ERRATA
> ===================================================================
> --- trunk/xorp/ERRATA ? 2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/ERRATA ? 2010-04-30 05:45:14 UTC (rev 11699)
> @@ -1,14 +1,10 @@
> -#
> -# $XORP: xorp/ERRATA,v 1.49 2008/12/19 00:35:26 abittau Exp $
> -#
>
> ? ? ? ? ? ? ? ?XORP ERRATA
>
> - ?ALL:
> - ? ?- Parallel building (e.g., "gmake -j 4") may fail on multi-CPU
> - ? ? ?machines. The simplest work-around is to rerun gmake or not to use
> - ? ? ?the -j flag.
> + ?See: ?https://sourceforge.net/apps/trac/xorp/report for current
> + ? ? bug list.
>
> + ?ALL:
> ? ? - The following compiler is known to be buggy, and should not be
> ? ? ? used to compile XORP:
> ? ? ? ? gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD]
> @@ -33,10 +29,8 @@
>
> ? RTRMGR:
> ? ? - There are several known issues, but none of them is considered
> - ? ? ?critical. The list of known issues is available from:
> + ? ? ?critical.
>
> - ? ? ? ?http://www.xorp.org/bugzilla/query.cgi
> -
> ? ? - Using the rtrmgr "-r" command-line option to restart processes
> ? ? ? that have failed does not work if a process fails while being
> ? ? ? reconfigured via xorpsh. If that happens, the rtrmgr itself may
> @@ -50,10 +44,8 @@
>
> ? XORPSH:
> ? ? - There are several known issues, but none of them is considered
> - ? ? ?critical. The list of known issues is available from:
> + ? ? ?critical.
>
> - ? ? ? ?http://www.xorp.org/bugzilla/query.cgi
> -
> ? FEA/MFEA:
> ? ? - On Linux with kernels prior to 2.6.24 and IPv6 support, interfaces
> ? ? ? fail to be reconfigured properly if brought down and up again.
> @@ -134,9 +126,7 @@
> ? ? ? may not work for the following OS-es because the kernel for those
> ? ? ? systems does not provide a mechanism for asynchronous notification
> ? ? ? of userland programs when the link status changes: FreeBSD-5.2 and
> - ? ? ?earlier and MacOS X (note: if the Windows kernel supports this
> - ? ? ?feature, it is not used yet in XORP). Though, for those systems
> - ? ? ?the link status should be read properly on startup.
> + ? ? ?earlier and MacOS X.
>
> ? ? - On Linux with kernel version linux-2.6.17 and older there is a
> ? ? ? kernel bug which prevents adding an IPv6 address to an interface
> @@ -195,10 +185,8 @@
> ? ? ? Eventually this limitation would be fixed in Linux kernel 2.6.28.
>
> ? RIB:
> - ? ?- In some rare cases, the RIB may fail to delete an existing route:
> + ? ?- In some rare cases, the RIB may fail to delete an existing route.
>
> - ? ? ? ?http://www.xorp.org/bugzilla/show_bug.cgi?id=62
> -
> ? ? ? We are aware of the issue and will attempt to fix it in the
> ? ? ? future.
>
> @@ -223,8 +211,6 @@
> ? ? - There are several other known issues, but none of them is
> ? ? ? considered critical. The list of known issues is available from:
>
> - ? ? ? ?http://www.xorp.org/bugzilla/query.cgi
> -
> ? BGP:
> ? ? - The BGP configuration mandates that an IPv4 nexthop must be
> ? ? ? supplied. Unfortunately it is necessary to provide an IPv4 nexthop
> @@ -360,55 +346,3 @@
>
> ? CLI:
> ? ? - No known issues.
> -
> - ?SNMP:
> - ? ?- On some versions of Linux, there are some bugs in net-snmp
> - ? ? ?versions 5.0.8 and 5.0.9, which prevent dynamic loading from
> - ? ? ?working. See the following URL for links to the net-snmp
> - ? ? ?patches that solve the problems:
> -
> - ? ? ? ?http://www.xorp.org/snmp.html
> -
> - ? ?- Version 5.1 of net-snmp requires a simple modification, otherwise
> - ? ? ?XORP will fail to compile.
> - ? ? ?See the following URL for a link to the net-snmp patch that solves
> - ? ? ?the problems:
> -
> - ? ? ? ? http://www.xorp.org/snmp.html
> -
> - ? ?- There might be a compilation error in the mibs directory on some
> - ? ? ?systems running on 64-bit machines (e.g., FreeBSD or Linux on amd64):
> -
> -g++ -shared ? xorpevents.lo -Wl,--whole-archive ../libxipc/.libs/libxipc.a ../libxorp/.libs/libxorp.a ../libcomm/.libs/libcomm.a -Wl,--no-whole-archive ?../libxipc/.libs/libxipc.a ../libxorp/.libs/libxorp.a ../libcomm/.libs/libcomm.a -lcrypto ?-Wl,-soname -Wl,libnetsnmpxorp.so -o .libs/libnetsnmpxorp.so
> -/usr/bin/ld: ../libxipc/.libs/libxipc.a(hmac_md5.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC
> -../libxipc/.libs/libxipc.a(hmac_md5.o): could not read symbols: Bad value
> -gmake[1]: *** [libnetsnmpxorp.la] Error 1
> -
> - ? ? In that case use the "--enable-shared" flag to "./configure", and
> - ? ? remove the previous compilation:
> -
> - ? ? ? ./configure --with-snmp --enable-shared
> - ? ? ? gmake clean
> - ? ? ? gmake
> -
> - ? ?- There might be a compilation error when running "gmake check"
> - ? ? ?in the mibs directory on some systems (e.g., Ubuntu Linux):
> -
> -g++ -DNETSNMP_NO_INLINE -g -Werror -W -Wall -Wwrite-strings -Wcast-qual
> --Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -o
> -.libs/test_xorpevents test_xorpevents.o -Wl,-Bsymbolic-functions -Wl,-E
> -../libxipc/.libs/libfinder.a ./.libs/libnetsnmpxorp.so -lpcap -lrt -L/usr/lib
> --L/usr/local/lib -L/usr/lib/perl/5.8/CORE /usr/lib/libnetsnmpmibs.so -lsensors
> -/usr/lib/libnetsnmphelpers.so /usr/lib/libnetsnmpagent.so -lwrap -lperl -ldl
> --lm -lpthread -lc -lcrypt /usr/lib/libnetsnmp.so -lcrypto -Wl,--rpath
> --Wl,/home/nithya/bug765/xorp/mibs/.libs -Wl,--rpath -Wl,/usr/local/xorp/mibs/.
> -/usr/local/bin/ld: cannot find -lperl
> -collect2: ld returned 1 exit status
> -make[2]: *** [test_xorpevents] Error 1
> -
> - ? ? ?A possible work around is to link /usr/lib/libperl to
> - ? ? ?/usr/lib/libperl.so.5.10 :
> -
> - ? ? ? ?su
> - ? ? ? ?cd /usr/lib
> - ? ? ? ?ln -s libperl.so.5.10 libperl.so
>
> Modified: trunk/xorp/README
> ===================================================================
> --- trunk/xorp/README ? 2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/README ? 2010-04-30 05:45:14 UTC (rev 11699)
> @@ -1,6 +1,3 @@
> -#
> -# $XORP: xorp/README,v 1.65 2009/01/09 19:20:58 jtc Exp $
> -#
>
> ? ? ? ? ? ? ? ?XORP: eXtensible Open Router Platform
>
> @@ -13,7 +10,9 @@
> ?developers from XORP, Inc., and members of the XORP.org community.
> ?It started life as a project at the ICSI Center for Open Networking (ICON)
> ?at the International Computer Science Institute in Berkeley, California,
> -USA, and is now owned and shepherded by the team at XORP, Inc.
> +USA, and spent some time with the team at XORP, Inc. ?It is now maintained
> +and improved on a volunteer basis by a core of long-term XORP developers
> +and some newer contributors.
>
> ?XORP's primary goal is to be an open platform for networking protocol
> ?implementations and an alternative to proprietary and closed networking
> @@ -55,7 +54,7 @@
> ?2. Status
> ?=========
>
> -This is XORP Release 1.7-WIP
> +This is XORP Release 1.7
> ?It is reasonably stable and can be used for routing, but there are known
> ?issues.
>
> @@ -65,29 +64,18 @@
> ? * FreeBSD
> ? * NetBSD
> ? * OpenBSD
> - ?* Linux
> - ?* Mac OS X
> - ?* Microsoft Windows
> + ?* Linux (x86-32, x86-64, Sparc)
>
> ?See ${XORP}/BUILD_NOTES for OS-specific details, compilation
> ?information, etc.
>
> ?Development platform:
>
> - ?* FreeBSD-7.0-RELEASE
> - ? ?- gcc/g++ version 4.2.1 (default)
> - ? ?- gmake (GNU make) version 3.81
> - ? ?- autoconf version 2.61
> - ? ?- automake version 1.10
> - ? ?- libtool version 1.5.24
> - ? ?- flex version 2.5.4
> - ? ?- yacc version default one that comes with the above OS
> + ?* Linux and FreeBSD
>
> -Other platforms can also be used for development, but the installed
> -version of autotools (autoconf/automake/libtool) should match the
> -information listed above.
> -For Microsoft Windows-based development see the corresponding
> -entry in ${XORP}/BUILD_NOTES.
> +Other platforms can also be used for development, perhaps with a bit
> +of effort. ?Ask on the xorp-hackers mailing list if your preferred
> +platform is not currently supported.
>
> ?See ${XORP}/ERRATA for the list of known problems.
>
> @@ -140,11 +128,10 @@
> ?3. Compilation, configuration and startup
> ?=========================================
>
> -To compile XORP, you must have GNU make (gmake) installed. Then just
> -run the following commands in the top-level directory:
> +To compile XORP, you must have a recent version of scons and g++
> +compiler toolset installed.
>
> -./configure
> -gmake
> +scons
>
> ?See ${XORP}/BUILD_NOTES for additional information of building XORP.
>
> @@ -258,7 +245,8 @@
> ? * contrib : various contributed code.
>
> ? ? * olsr : RFC 3626 Optimized Link State Routing implementation.
> - ? ? ?Generously funded by CenGen, Inc.
> + ? ? ?Generously funded by CenGen, Inc. ?(Does not compile in 1.7,
> + ? ? ?but will work in 1.8)
>
> ? ? * mld6igmp_lite : Implementation of the Lightweight IGMPv3/MLDv2
> ? ? ? protocols:
> @@ -267,8 +255,6 @@
> ?The directories listed below contain various information that are of
> ?limited interest, or are not relevant to the current release:
>
> - ?* config : autoconf/automake related files.
> -
> ? * devnotes : various notes for the XORP core members.
>
> ? * utils : Various XORP-related utilities.
> @@ -278,9 +264,10 @@
> ?===============
>
> ?In the short-term we plan to add:
> - ?* IS-IS
> - ?* Security
> - ?* Bi-directional PIM-SM
> + ?* Integrate changes found in 'xorp.ct' repository.
> + ?* Get regression tests working again.
> + ?* Implement batching and other performance improvements for BGP
> + ? ?and other protocols.
>
> ?In the long-term, we plan to add:
> ? * BGMP
> @@ -295,6 +282,7 @@
> ? * Andrea Bittau
> ? * Javier Cardona
> ? * Atanu Ghosh
> + ?* Ben Greear
> ? * Adam Greenhalgh
> ? * Mark Handley
> ? * Orion Hodson
> @@ -321,6 +309,7 @@
> ? ? - Microsoft
> ? ? - Vyatta
> ? ? - CenGen
> + ? ?- Candela Technologies (Sponsors Ben Greear)
>
> ? * Martin C. Shepherd for the libtecla library (used by the CLI).
>
>
> Modified: trunk/xorp/RELEASE_NOTES
> ===================================================================
> --- trunk/xorp/RELEASE_NOTES ? ?2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/RELEASE_NOTES ? ?2010-04-30 05:45:14 UTC (rev 11699)
> @@ -1,78 +1,24 @@
> -#
> -# $XORP: xorp/RELEASE_NOTES,v 1.235 2009/01/09 19:20:58 jtc Exp $
> -#
>
> ? ? ? ? ? ? ? ?XORP RELEASE NOTES
>
> ?This file contains XORP release notes (most recent releases first).
>
> -Release 2.0 (2010/??/??)
> +Release 1.7 ?May 1, 2010
> ?============================
> ? ALL:
> - ? ?-
> + ? ?- Compiles on Linux (x86-32, x86-64, Sparc, at least) and BSD variants.
> + ? ?- Replaced 'make' build system with 'scons'
> + ? ?- New installation layout.
> + ? ?- Footprint reduction.
> + ? ?- Bug fixes here an there, more queued for release 1.8.
> + ? ?- Support shared libraries.
>
> - ?CONFIGURATION:
> - ? ?-
> -
> - ?LIBXORP:
> - ? ?-
> -
> - ?LIBXIPC:
> - ? ?-
> -
> - ?LIBFEACLIENT:
> - ? ?-
> -
> - ?XRL:
> - ? ?-
> -
> - ?RTRMGR:
> - ? ?-
> -
> - ?XORPSH:
> - ? ?-
> -
> - ?POLICY:
> - ? ?-
> -
> - ?FEA/MFEA:
> - ? ?-
> -
> - ?RIB:
> - ? ?-
> -
> - ?RIP/RIPng:
> - ? ?-
> -
> ? OLSR:
> - ? ?-
> + ? ?- Currently broken in 1.7
>
> - ?OSPF:
> - ? ?-
> -
> - ?BGP:
> - ? ?-
> -
> - ?STATIC_ROUTES:
> - ? ?-
> -
> - ?MLD/IGMP:
> - ? ?-
> -
> - ?MLD/IGMP-Lite:
> - ? ?-
> -
> - ?PIM-SM:
> - ? ?-
> -
> - ?FIB2MRIB:
> - ? ?-
> -
> ? SNMP:
> - ? ?-
> + ? ?- Removed
>
> - ?VRRP:
> - ? ?-
>
> ?Release 1.6 (2009/01/07)
> ?============================
>
> Modified: trunk/xorp/TODO
> ===================================================================
> --- trunk/xorp/TODO ? ? 2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/TODO ? ? 2010-04-30 05:45:14 UTC (rev 11699)
> @@ -1,6 +1,3 @@
> -#
> -# $XORP: xorp/TODO,v 1.22 2008/01/13 06:01:45 pavlin Exp $
> -#
>
> ?* Add a list with acknowledgments for all people who have contributed:
> ? bug reports/fixes/etc. This list will go with the source code,
>
> Modified: trunk/xorp/VERSION
> ===================================================================
> --- trunk/xorp/VERSION ?2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/VERSION ?2010-04-30 05:45:14 UTC (rev 11699)
> @@ -1 +1 @@
> -1.7-WIP
> +1.7
>
> Modified: trunk/xorp/etc/templates/xorpsh.cmds
> ===================================================================
> --- trunk/xorp/etc/templates/xorpsh.cmds ? ? ? ?2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/etc/templates/xorpsh.cmds ? ? ? ?2010-04-30 05:45:14 UTC (rev 11699)
> @@ -6,6 +6,6 @@
> ?}
>
> ?show version {
> - ? ?%command: "echo Version 1.7-WIP" %help: HELP;
> + ? ?%command: "echo Version 1.7" %help: HELP;
> ? ? %tag: HELP "Display system version";
> ?}
>
> Modified: trunk/xorp/rtrmgr/master_conf_tree.cc
> ===================================================================
> --- trunk/xorp/rtrmgr/master_conf_tree.cc ? ? ? 2010-04-29 15:10:56 UTC (rev 11698)
> +++ trunk/xorp/rtrmgr/master_conf_tree.cc ? ? ? 2010-04-30 05:45:14 UTC (rev 11699)
> @@ -46,7 +46,7 @@
> ?#include "util.hh"
>
> ?#define XORP_CONFIG_FORMAT_VERSION ? ? ? ? ? ? "1.1"
> -#define XORP_CONFIG_XORP_VERSION ? ? ? ? ? ? ? "1.7-WIP"
> +#define XORP_CONFIG_XORP_VERSION ? ? ? ? ? ? ? "1.7"
>
> ?//
> ?// The strings that are used to add and delete a load or save file, to
>
>
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
>
> _______________________________________________
> Xorp-cvs mailing list
> Xorp-cvs at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs
>