From a.greenhalgh at cs.ucl.ac.uk  Tue Jun  5 01:56:53 2007
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Tue, 5 Jun 2007 09:56:53 +0100
Subject: [Xorp-hackers] heads up on autoconf names on ubuntu
Message-ID: <4769af410706050156w5a862c27u1836b59aa3daba4b@mail.gmail.com>

Hi

I've just set up an ubuntu box (7.04 server), and have installed the
autoconf/make tools to build xorp. The following diff is required to
get them to work. This raises the question about whether we should
have the tool version as part of the file name or not in the bootstrap
script.

Adam

cvs diff bootstrap
Index: bootstrap
===================================================================
RCS file: /usr/local/www/data/cvs/xorp/bootstrap,v
retrieving revision 1.28
diff -r1.28 bootstrap
15,18c15,18
< ACLOCAL=${ACLOCAL:-"aclocal110"}
< AUTOCONF=${AUTOCONF:-"autoconf261"}
< AUTOHEADER=${AUTOHEADER:-"autoheader261"}
< AUTOMAKE=${AUTOMAKE:-"automake110"}
---
> ACLOCAL=${ACLOCAL:-"aclocal"}
> AUTOCONF=${AUTOCONF:-"autoconf"}
> AUTOHEADER=${AUTOHEADER:-"autoheader"}
> AUTOMAKE=${AUTOMAKE:-"automake"}


From pavlin at icir.org  Tue Jun  5 11:06:13 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 05 Jun 2007 11:06:13 -0700
Subject: [Xorp-hackers] heads up on autoconf names on ubuntu
In-Reply-To: Message from "Adam Greenhalgh" <a.greenhalgh@cs.ucl.ac.uk> 
	of "Tue, 05 Jun 2007 09:56:53 BST."
	<4769af410706050156w5a862c27u1836b59aa3daba4b@mail.gmail.com> 
Message-ID: <200706051806.l55I6DSs089042@possum.icir.org>

> I've just set up an ubuntu box (7.04 server), and have installed the
> autoconf/make tools to build xorp. The following diff is required to
> get them to work. This raises the question about whether we should
> have the tool version as part of the file name or not in the bootstrap
> script.

Originally the names were without the version suffix. I added the
suffixes recently while updating the autotools support to work with
the most recent versions.

The suffix addition was primarily experimental: I wanted to see
whether explicitly encoding the recommended autotool versions in the
"bootstrap" file is preferred from other developers' perspective.
It seems the answer is "no" at least for you :)

If other folks don't have any preferences/opinion on the subject,
feel free to change the names.

Thanks,
Pavlin

> Adam
> 
> cvs diff bootstrap
> Index: bootstrap
> ===================================================================
> RCS file: /usr/local/www/data/cvs/xorp/bootstrap,v
> retrieving revision 1.28
> diff -r1.28 bootstrap
> 15,18c15,18
> < ACLOCAL=${ACLOCAL:-"aclocal110"}
> < AUTOCONF=${AUTOCONF:-"autoconf261"}
> < AUTOHEADER=${AUTOHEADER:-"autoheader261"}
> < AUTOMAKE=${AUTOMAKE:-"automake110"}
> ---
> > ACLOCAL=${ACLOCAL:-"aclocal"}
> > AUTOCONF=${AUTOCONF:-"autoconf"}
> > AUTOHEADER=${AUTOHEADER:-"autoheader"}
> > AUTOMAKE=${AUTOMAKE:-"automake"}
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From atanu at ICSI.Berkeley.EDU  Tue Jun  5 11:15:15 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Tue, 05 Jun 2007 11:15:15 -0700
Subject: [Xorp-hackers] heads up on autoconf names on ubuntu
In-Reply-To: Message from Pavlin Radoslavov <pavlin@icir.org> of "Tue,
	05 Jun 2007 11:06:13 PDT."
	<200706051806.l55I6DSs089042@possum.icir.org> 
Message-ID: <22503.1181067315@tigger.icir.org>

Hi,

My vote is that we leave the version numbers in (it makes it obvious
which tools are being used). Anyone running bootstrap is developing
code, it shouldn't be too burdensome to set the variables in the
environment.

      Atanu.

>>>>> "Pavlin" == Pavlin Radoslavov <pavlin at icir.org> writes:

    >> I've just set up an ubuntu box (7.04 server), and have installed
    >> the autoconf/make tools to build xorp. The following diff is
    >> required to get them to work. This raises the question about
    >> whether we should have the tool version as part of the file name
    >> or not in the bootstrap script.

    Pavlin> Originally the names were without the version suffix. I
    Pavlin> added the suffixes recently while updating the autotools
    Pavlin> support to work with the most recent versions.

    Pavlin> The suffix addition was primarily experimental: I wanted to
    Pavlin> see whether explicitly encoding the recommended autotool
    Pavlin> versions in the "bootstrap" file is preferred from other
    Pavlin> developers' perspective.  It seems the answer is "no" at
    Pavlin> least for you :)

    Pavlin> If other folks don't have any preferences/opinion on the
    Pavlin> subject, feel free to change the names.

    Pavlin> Thanks, Pavlin

    >> Adam
    >> 
    >> cvs diff bootstrap Index: bootstrap
    >> ===================================================================
    >> RCS file: /usr/local/www/data/cvs/xorp/bootstrap,v retrieving
    >> revision 1.28 diff -r1.28 bootstrap 15,18c15,18 <
    >> ACLOCAL=${ACLOCAL:-"aclocal110"} <
    >> AUTOCONF=${AUTOCONF:-"autoconf261"} <
    >> AUTOHEADER=${AUTOHEADER:-"autoheader261"} <
    >> AUTOMAKE=${AUTOMAKE:-"automake110"}
    >> ---
    >> > ACLOCAL=${ACLOCAL:-"aclocal"} >
    >> AUTOCONF=${AUTOCONF:-"autoconf"} >
    >> AUTOHEADER=${AUTOHEADER:-"autoheader"} >
    >> AUTOMAKE=${AUTOMAKE:-"automake"}
    >> 
    >> _______________________________________________ Xorp-hackers
    >> mailing list Xorp-hackers at icir.org
    >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

    Pavlin> _______________________________________________ Xorp-hackers
    Pavlin> mailing list Xorp-hackers at icir.org
    Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From a.greenhalgh at cs.ucl.ac.uk  Tue Jun  5 11:43:39 2007
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Tue, 5 Jun 2007 19:43:39 +0100
Subject: [Xorp-hackers] heads up on autoconf names on ubuntu
In-Reply-To: <22503.1181067315@tigger.icir.org>
References: <pavlin@icir.org> <200706051806.l55I6DSs089042@possum.icir.org>
	<22503.1181067315@tigger.icir.org>
Message-ID: <4769af410706051143q34c32aq1bcb1a66d81d4f34@mail.gmail.com>

But the issue is that the names aren't the same even with the version
numbers in them for example :

redhat : aclocal-1.6
gentoo : aclocal-1.10
ubuntu : aclocal-1.10
freebsd : aclocal110
solaris (local installation) : aclocal

Adam


On 6/5/07, Atanu Ghosh <atanu at icsi.berkeley.edu> wrote:
> Hi,
>
> My vote is that we leave the version numbers in (it makes it obvious
> which tools are being used). Anyone running bootstrap is developing
> code, it shouldn't be too burdensome to set the variables in the
> environment.
>
>       Atanu.
>
> >>>>> "Pavlin" == Pavlin Radoslavov <pavlin at icir.org> writes:
>
>     >> I've just set up an ubuntu box (7.04 server), and have installed
>     >> the autoconf/make tools to build xorp. The following diff is
>     >> required to get them to work. This raises the question about
>     >> whether we should have the tool version as part of the file name
>     >> or not in the bootstrap script.
>
>     Pavlin> Originally the names were without the version suffix. I
>     Pavlin> added the suffixes recently while updating the autotools
>     Pavlin> support to work with the most recent versions.
>
>     Pavlin> The suffix addition was primarily experimental: I wanted to
>     Pavlin> see whether explicitly encoding the recommended autotool
>     Pavlin> versions in the "bootstrap" file is preferred from other
>     Pavlin> developers' perspective.  It seems the answer is "no" at
>     Pavlin> least for you :)
>
>     Pavlin> If other folks don't have any preferences/opinion on the
>     Pavlin> subject, feel free to change the names.
>
>     Pavlin> Thanks, Pavlin
>
>     >> Adam
>     >>
>     >> cvs diff bootstrap Index: bootstrap
>     >> ===================================================================
>     >> RCS file: /usr/local/www/data/cvs/xorp/bootstrap,v retrieving
>     >> revision 1.28 diff -r1.28 bootstrap 15,18c15,18 <
>     >> ACLOCAL=${ACLOCAL:-"aclocal110"} <
>     >> AUTOCONF=${AUTOCONF:-"autoconf261"} <
>     >> AUTOHEADER=${AUTOHEADER:-"autoheader261"} <
>     >> AUTOMAKE=${AUTOMAKE:-"automake110"}
>     >> ---
>     >> > ACLOCAL=${ACLOCAL:-"aclocal"} >
>     >> AUTOCONF=${AUTOCONF:-"autoconf"} >
>     >> AUTOHEADER=${AUTOHEADER:-"autoheader"} >
>     >> AUTOMAKE=${AUTOMAKE:-"automake"}
>     >>
>     >> _______________________________________________ Xorp-hackers
>     >> mailing list Xorp-hackers at icir.org
>     >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>     Pavlin> _______________________________________________ Xorp-hackers
>     Pavlin> mailing list Xorp-hackers at icir.org
>     Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From pbg at cs.berkeley.edu  Fri Jun  8 02:34:31 2007
From: pbg at cs.berkeley.edu (Brighten Godfrey)
Date: Fri, 8 Jun 2007 02:34:31 -0700
Subject: [Xorp-hackers] Xorp for overlay routing
Message-ID: <1C160353-9042-41DF-8010-C949D7548235@cs.berkeley.edu>

Hi,

I'd like to employ Xorp as a router in an overlay network in  
userspace.  This is similar to what VINI does, but VINI uses User- 
Mode Linux (UML) so that Xorp can talk directly to (virtual) network  
devices.  I'd like to get away without that complexity if possible.   
Can anyone comment on whether there is an easy way to do this in  
Xorp?  Or quagga, perhaps?

Thanks for your time,
~Brighten Godfrey
UC Berkeley


From pavlin at icir.org  Fri Jun  8 03:52:28 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 08 Jun 2007 03:52:28 -0700
Subject: [Xorp-hackers] Xorp for overlay routing
In-Reply-To: Message from Brighten Godfrey <pbg@cs.berkeley.edu> of "Fri,
	08 Jun 2007 02:34:31 PDT."
	<1C160353-9042-41DF-8010-C949D7548235@cs.berkeley.edu> 
Message-ID: <200706081052.l58AqS8E069250@possum.icir.org>

> I'd like to employ Xorp as a router in an overlay network in  
> userspace.  This is similar to what VINI does, but VINI uses User- 
> Mode Linux (UML) so that Xorp can talk directly to (virtual) network  
> devices.  I'd like to get away without that complexity if possible.   
> Can anyone comment on whether there is an easy way to do this in  
> Xorp?  Or quagga, perhaps?

What kind of (virtual) network devices are you going to use in your
overlay? Most likely you need to create them before starting XORP,
because currently XORP can configure only devices that are already
in the kernel.

Also, what mechanism can be used to talk to those devices?
If none of the existing UNIX mechanisms can be used (e.g., ioctl(),
Linux's netlink, etc), then you need to write a plugin at the bottom
of the FEA (XORP's Forwarding Engine Abstraction) that will allow
XORP to talk to those devices. Drop me an email for details if you
need to write such plugin.

There are probably some other issues that might need to be
considered, but I cannot address them without knowing the technical
details of your overlay.

In any case, given your physical proximity to ICSI feel free to stop
by to discuss in details any issues you might have.

Regards,
Pavlin

> Thanks for your time,
> ~Brighten Godfrey
> UC Berkeley
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From euan.harris at cl.cam.ac.uk  Thu Jun 14 09:49:38 2007
From: euan.harris at cl.cam.ac.uk (Euan Harris)
Date: Thu, 14 Jun 2007 17:49:38 +0100
Subject: [Xorp-hackers] Bug in route_table_decision::find_winner
Message-ID: <C18595A2-3308-470B-8711-A896EA4ED81C@cl.cam.ac.uk>

Hi,

I think I've found a bug in the path attribute comparisons in the  
route selection algorithm.   In some circumstances the loop that is  
supposed to select the routes with the best values of a particular  
attribute will also select one or more routes which have poorer  
values for that attribute.

Here is an example from the local preference stage; the same loop is  
replicated for all the other attributes except MED:

route_table_decision::find_winner

>     int test_pref = local_pref(alternatives.front().route(),
> 			       alternatives.front().peer_handler());
>     i = alternatives.begin(); i++;
>     while(i!=alternatives.end()) {
> 	int lp = local_pref(i->route(), i->peer_handler());
> 	XLOG_ASSERT(lp >= 0);
> 	//prefer higher preference
> 	if (lp < test_pref) {
> 	    i = alternatives.erase(i);
> 	} else if (lp > test_pref) {
> 	    test_pref = lp;
> 	    alternatives.pop_front();
> 	    i++;
> 	} else {
> 	    i++;
> 	}
>     }

The loop is supposed to select the routes with the highest local  
preference values.   If alternatives has three routes with local  
preference values [100, 100, 200] at the start then after the loop  
finishes it should only contain [200].   However the actual result is  
[100, 200] - the loop does not delete the second 100 preference route.

Another example:  a starting list of [50, 50,  
50,100,100,100,100,200,100,200,200] should be [200, 200, 200] after  
filtering but will instead be [50, 100, 100, 100, 100, 200, 200,  
200].   In this case the loop encountered new maximum values twice  
and so popped off the top two 50 pref routes but none of the 100s.

The problem is that when the loop finds a new maximum preference  
value it only pops the first route from the list:

> 	} else if (lp > test_pref) {
> 	    test_pref = lp;
> 	    alternatives.pop_front();
> 	    i++;
> 	} else {

If more than one route with that preference value has been seen all  
the others will be left on the list.   To be correct the loop should  
erase all routes from the beginning of the list to the new maximum:

> 	} else if (lp > test_pref) {
> 	    test_pref = lp;
> 	    alternatives.erase(alternatives.begin(), i);
> 	    i++;
> 	} else {

This bug would cause the wrong route to be selected if, for  
instance,  a route with lower local preference erroneously passed  
through local preference filtering and then beat a route with higher  
local preference on AS path length.

I've attached a patch against CVS HEAD which fixes the 7 filter loops  
like this in route_table_decision::find_winner and adds a test  
demonstrating the bug to test_decision{.cc,.reference}.   Apply with  
patch -p0 in the toplevel directory.

Thanks,
Euan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: decision-bug.patch.gz
Type: application/x-gzip
Size: 1447 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070614/a590fd5b/attachment.gz 

From M.Handley at cs.ucl.ac.uk  Thu Jun 14 15:00:22 2007
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Thu, 14 Jun 2007 23:00:22 +0100
Subject: [Xorp-hackers] Bug in route_table_decision::find_winner
In-Reply-To: <C18595A2-3308-470B-8711-A896EA4ED81C@cl.cam.ac.uk>
References: <C18595A2-3308-470B-8711-A896EA4ED81C@cl.cam.ac.uk>
Message-ID: <84a612dd0706141500u50310109j73df4ae180bd764f@mail.gmail.com>

Thanks Euan - from reading the code, I agree with your analysis - this
does indeed appear to be a problem.  Mea culpa.  Your fix looks good
to me too.

 - Mark

On 6/14/07, Euan Harris <euan.harris at cl.cam.ac.uk> wrote:
> Hi,
>
> I think I've found a bug in the path attribute comparisons in the
> route selection algorithm.   In some circumstances the loop that is
> supposed to select the routes with the best values of a particular
> attribute will also select one or more routes which have poorer
> values for that attribute.
>
> Here is an example from the local preference stage; the same loop is
> replicated for all the other attributes except MED:
>
> route_table_decision::find_winner
>
> >     int test_pref = local_pref(alternatives.front().route(),
> >                              alternatives.front().peer_handler());
> >     i = alternatives.begin(); i++;
> >     while(i!=alternatives.end()) {
> >       int lp = local_pref(i->route(), i->peer_handler());
> >       XLOG_ASSERT(lp >= 0);
> >       //prefer higher preference
> >       if (lp < test_pref) {
> >           i = alternatives.erase(i);
> >       } else if (lp > test_pref) {
> >           test_pref = lp;
> >           alternatives.pop_front();
> >           i++;
> >       } else {
> >           i++;
> >       }
> >     }
>
> The loop is supposed to select the routes with the highest local
> preference values.   If alternatives has three routes with local
> preference values [100, 100, 200] at the start then after the loop
> finishes it should only contain [200].   However the actual result is
> [100, 200] - the loop does not delete the second 100 preference route.
>
> Another example:  a starting list of [50, 50,
> 50,100,100,100,100,200,100,200,200] should be [200, 200, 200] after
> filtering but will instead be [50, 100, 100, 100, 100, 200, 200,
> 200].   In this case the loop encountered new maximum values twice
> and so popped off the top two 50 pref routes but none of the 100s.
>
> The problem is that when the loop finds a new maximum preference
> value it only pops the first route from the list:
>
> >       } else if (lp > test_pref) {
> >           test_pref = lp;
> >           alternatives.pop_front();
> >           i++;
> >       } else {
>
> If more than one route with that preference value has been seen all
> the others will be left on the list.   To be correct the loop should
> erase all routes from the beginning of the list to the new maximum:
>
> >       } else if (lp > test_pref) {
> >           test_pref = lp;
> >           alternatives.erase(alternatives.begin(), i);
> >           i++;
> >       } else {
>
> This bug would cause the wrong route to be selected if, for
> instance,  a route with lower local preference erroneously passed
> through local preference filtering and then beat a route with higher
> local preference on AS path length.
>
> I've attached a patch against CVS HEAD which fixes the 7 filter loops
> like this in route_table_decision::find_winner and adds a test
> demonstrating the bug to test_decision{.cc,.reference}.   Apply with
> patch -p0 in the toplevel directory.
>
> Thanks,
> Euan
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>
>


From atanu at ICSI.Berkeley.EDU  Mon Jun 18 16:31:33 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 18 Jun 2007 16:31:33 -0700
Subject: [Xorp-hackers] Bug in route_table_decision::find_winner
In-Reply-To: Message from Euan Harris <euan.harris@cl.cam.ac.uk> of "Thu,
	14 Jun 2007 17:49:38 BST."
	<C18595A2-3308-470B-8711-A896EA4ED81C@cl.cam.ac.uk> 
Message-ID: <26140.1182209493@tigger.icir.org>

Hi,

Thanks for the fix, it is now checked in.

       Atanu.

>>>>> "Euan" == Euan Harris <euan.harris at cl.cam.ac.uk> writes:

    Euan> Hi, I think I've found a bug in the path attribute comparisons
    Euan> in the route selection algorithm.  In some circumstances the
    Euan> loop that is supposed to select the routes with the best
    Euan> values of a particular attribute will also select one or more
    Euan> routes which have poorer values for that attribute.

    Euan> Here is an example from the local preference stage; the same
    Euan> loop is replicated for all the other attributes except MED:

    Euan> route_table_decision::find_winner

    >> int test_pref = local_pref(alternatives.front().route(),
    >> alternatives.front().peer_handler()); i = alternatives.begin();
    >> i++; while(i!=alternatives.end()) { int lp =
    >> local_pref(i->route(), i->peer_handler()); XLOG_ASSERT(lp >= 0);
    >> //prefer higher preference if (lp < test_pref) { i =
    >> alternatives.erase(i); } else if (lp > test_pref) { test_pref =
    >> lp; alternatives.pop_front(); i++; } else { i++; } }

    Euan> The loop is supposed to select the routes with the highest
    Euan> local preference values.  If alternatives has three routes
    Euan> with local preference values [100, 100, 200] at the start then
    Euan> after the loop finishes it should only contain [200].  However
    Euan> the actual result is [100, 200] - the loop does not delete the
    Euan> second 100 preference route.

    Euan> Another example: a starting list of [50, 50,
    Euan> 50,100,100,100,100,200,100,200,200] should be [200, 200, 200]
    Euan> after filtering but will instead be [50, 100, 100, 100, 100,
    Euan> 200, 200, 200].  In this case the loop encountered new maximum
    Euan> values twice and so popped off the top two 50 pref routes but
    Euan> none of the 100s.

    Euan> The problem is that when the loop finds a new maximum
    Euan> preference value it only pops the first route from the list:

    >> } else if (lp > test_pref) { test_pref = lp;
    >> alternatives.pop_front(); i++; } else {

    Euan> If more than one route with that preference value has been
    Euan> seen all the others will be left on the list.  To be correct
    Euan> the loop should erase all routes from the beginning of the
    Euan> list to the new maximum:

    >> } else if (lp > test_pref) { test_pref = lp;
    >> alternatives.erase(alternatives.begin(), i); i++; } else {

    Euan> This bug would cause the wrong route to be selected if, for
    Euan> instance, a route with lower local preference erroneously
    Euan> passed through local preference filtering and then beat a
    Euan> route with higher local preference on AS path length.

    Euan> I've attached a patch against CVS HEAD which fixes the 7
    Euan> filter loops like this in route_table_decision::find_winner
    Euan> and adds a test demonstrating the bug to
    Euan> test_decision{.cc,.reference}.  Apply with patch -p0 in the
    Euan> toplevel directory.

    Euan> Thanks, Euan

    Euan> _______________________________________________ Xorp-hackers
    Euan> mailing list Xorp-hackers at icir.org
    Euan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers