From seb at anet.fr Wed Jul 1 02:33:24 2009 From: seb at anet.fr (=?ISO-8859-1?Q?S=E9bastien_Nam=E8che?=) Date: Wed, 1 Jul 2009 11:33:24 +0200 Subject: [Xorp-users] How to AS prepend ? In-Reply-To: <4A44C8B0.4080603@incunabulum.net> References: <4A43A6AD.5000005@incunabulum.net> <833E46C9-53EE-4A36-B3E6-EF0B67EA25BF@nameche.fr> <4A44C8B0.4080603@incunabulum.net> Message-ID: Bruce, Le 26 juin 09 ? 15:10, Bruce Simpson a ?crit : > What is your desired as-path on the redistributed route(s), in the > output you'd expect to see in the BGP routing table ? .../... > So your intention is in fact to announce the same prefix X.Y.W.0/23, > from the XORP BGP router, but with your AS path prepended to the > existing AS path advertised by another BGP router which already > announces prefix X.Y.W.0/23? > > This isn't going to work if you're directly applying the policy to the > route redistributed from OSPF, as described earlier; it sounds as > though > you need to inject this prefix announcement manually, and/or specify > the > AS of your peer with the shortest path explicitly. Following is an exemple of what we would want to do : Big, wild, Internet / \ / \ |-----| |-----| (AS 123) peer2 | | | | peer1 (AS 456) |-----| |-----| | | prefered link to 1.2.3/23 | | prefered link to 4.5.6/23 | | |-----| |-----| (ASBR, OSPF area 0) st2rt1 | | AS 7890 | | st1rt1 (ASBR, OSPF area 0) 1.2.3/23 gw st1cr1 learned from OSPF |-----| |-----| 4.5.6/23 gw st1cr1 learned from OSPF => redistribute to BGP | | => redistribute to BGP 4.5.6/23 gw st1cr1 learned from OSPF | | 1.2.3/23 gw st1cr1 learned from OSPF => redistribute to BGP with AS prepend | | => redistribute to BGP with AS prepend | | |-----| ~400km |-----| (ABR, OSPF area 0 & 2) st2cr1 | |-------------| | st1cr1 (ABR, OSPF area 0 & 1) |-----| link0 |-----| /|\ /|\ / | \ / | \ (OSPF area 2) to 1.2.3/23 to 4.5.6/23 (OSPF area 1) st1rt1 and st2rt1 are our Xorp routers. The AS-path seen on BGP routing table should be : In normal state: 1.2.3/23 ... 123 7890 1.2.3/23 ... 456 7890 7890 7890 4.5.6/23 ... 456 7890 4.5.6/23 ... 123 7890 7890 7890 If link0 breaks: 1.2.3/23 ... 123 7890 4.5.6/23 ... 456 7890 If link to peer1 breaks: 1.2.3/23 ... 123 7890 4.5.6/23 ... 123 7890 7890 7890 If link to peer2 breaks: 1.2.3/23 ... 456 7890 7890 7890 4.5.6/23 ... 456 7890 Thanks, -- Seb From greearb at candelatech.com Wed Jul 1 11:16:08 2009 From: greearb at candelatech.com (Ben Greear) Date: Wed, 01 Jul 2009 11:16:08 -0700 Subject: [Xorp-users] Questions on multicast routing In-Reply-To: <4A495380.8040604@candelatech.com> References: <4A495380.8040604@candelatech.com> Message-ID: <4A4BA7E8.7090600@candelatech.com> On 06/29/2009 04:51 PM, Ben Greear wrote: > I am trying to figure out why multicast is taking the 'long' way through > the > network. > > My network diagram is attached. The xorp output below is from router 2 > (the top one). > > I am generating mcast traffic from Node2 interface to Node3. I would > expect it to > go through the link between R2 and R3, but instead it goes R2 -> R1 -> > R3. My traffic > flow is 64k, so I think it's using xorp user-space routing instead of > setting up > a kernel cache. > > I have hacked on multicast to support multiple routing tables, so it could > be my bug, but I'd still appreciate any pointers to what might be going > wrong > if anyone has any ideas! > > I'll be happy to send any other information, just ask. I think maybe I was confused on how multicast works..and I vaguely remember that this might have happened to me before :P Anyway, the real problem I was chasing was elsewhere, and the patch I sent to the mailing list yesterday fixed it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From william at losrios.edu Wed Jul 1 11:22:52 2009 From: william at losrios.edu (Williams, Mark) Date: Wed, 1 Jul 2009 11:22:52 -0700 Subject: [Xorp-users] Questions on multicast routing In-Reply-To: <4A4BA7E8.7090600@candelatech.com> References: <4A495380.8040604@candelatech.com> <4A4BA7E8.7090600@candelatech.com> Message-ID: <1B62E6082D9F034394DB2FBAC03D1A3860E9C8C744@lrccd-exch05.LRCCD.ad.losrios.edu> Well, looking at the diagram and details in the email, it looks like br1 on R1 was the rendezvous point for the multicast stream, and since you had a relatively high value of 1024000 (81 kbps with default interval value of 100) for switch-to-spt-threshold, a stream of only 64k would not trigger a switch to the shortest path. In any case, the register-stop message should have been sent from R1 to R2, but that didn't happen either. Was your fix related to this? -Mark Williams -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Ben Greear Sent: Wednesday, July 01, 2009 11:16 To: xorp-users at xorp.org Subject: Re: [Xorp-users] Questions on multicast routing On 06/29/2009 04:51 PM, Ben Greear wrote: > I am trying to figure out why multicast is taking the 'long' way through > the > network. > > My network diagram is attached. The xorp output below is from router 2 > (the top one). > > I am generating mcast traffic from Node2 interface to Node3. I would > expect it to > go through the link between R2 and R3, but instead it goes R2 -> R1 -> > R3. My traffic > flow is 64k, so I think it's using xorp user-space routing instead of > setting up > a kernel cache. > > I have hacked on multicast to support multiple routing tables, so it could > be my bug, but I'd still appreciate any pointers to what might be going > wrong > if anyone has any ideas! > > I'll be happy to send any other information, just ask. I think maybe I was confused on how multicast works..and I vaguely remember that this might have happened to me before :P Anyway, the real problem I was chasing was elsewhere, and the patch I sent to the mailing list yesterday fixed it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Wed Jul 1 11:30:05 2009 From: greearb at candelatech.com (Ben Greear) Date: Wed, 01 Jul 2009 11:30:05 -0700 Subject: [Xorp-users] Questions on multicast routing In-Reply-To: <1B62E6082D9F034394DB2FBAC03D1A3860E9C8C744@lrccd-exch05.LRCCD.ad.losrios.edu> References: <4A495380.8040604@candelatech.com> <4A4BA7E8.7090600@candelatech.com> <1B62E6082D9F034394DB2FBAC03D1A3860E9C8C744@lrccd-exch05.LRCCD.ad.losrios.edu> Message-ID: <4A4BAB2D.6010906@candelatech.com> On 07/01/2009 11:22 AM, Williams, Mark wrote: > Well, looking at the diagram and details in the email, it looks like br1 on R1 was the rendezvous point for the multicast stream, and since you had a relatively high value of 1024000 (81 kbps with default interval value of 100) for switch-to-spt-threshold, a stream of only 64k would not trigger a switch to the shortest path. > > In any case, the register-stop message should have been sent from R1 to R2, but that didn't happen either. Was your fix related to this? As soon as you remove an interface from pim, the task list would hang, and no further tasks would be processed. This included sending most (all?) packets to fea. Once I fixed this I was able to add/remove interfaces and have it all keep working fine. I think I'll make that switch-to-stp threshold smaller anyway though...seems a lot cleaner to put even moderately busy connections in the kernel. Thanks, Ben > > -Mark Williams > > -----Original Message----- > From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Ben Greear > Sent: Wednesday, July 01, 2009 11:16 > To: xorp-users at xorp.org > Subject: Re: [Xorp-users] Questions on multicast routing > > On 06/29/2009 04:51 PM, Ben Greear wrote: >> I am trying to figure out why multicast is taking the 'long' way through >> the >> network. >> >> My network diagram is attached. The xorp output below is from router 2 >> (the top one). >> >> I am generating mcast traffic from Node2 interface to Node3. I would >> expect it to >> go through the link between R2 and R3, but instead it goes R2 -> R1 -> >> R3. My traffic >> flow is 64k, so I think it's using xorp user-space routing instead of >> setting up >> a kernel cache. >> >> I have hacked on multicast to support multiple routing tables, so it could >> be my bug, but I'd still appreciate any pointers to what might be going >> wrong >> if anyone has any ideas! >> >> I'll be happy to send any other information, just ask. > > I think maybe I was confused on how multicast works..and I vaguely remember that this might > have happened to me before :P > > Anyway, the real problem I was chasing was elsewhere, and the patch I sent to the mailing > list yesterday fixed it. > > Thanks, > Ben > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Jul 1 11:47:45 2009 From: greearb at candelatech.com (Ben Greear) Date: Wed, 01 Jul 2009 11:47:45 -0700 Subject: [Xorp-users] OLSR on Linux? Message-ID: <4A4BAF51.7030902@candelatech.com> Has anyone ever used OLSR on Linux with more than one interface? I couldn't get it to work without the patch below, but maybe that's because of other patches I've added to xorp? With the below it starts, at least...not sure if it actually works yet. Thanks, Ben diff --git a/fea/data_plane/io/io_tcpudp_socket.cc b/fea/data_plane/io/io_tcpudp_socket.cc index bfa23bd..1dcefa1 100644 --- a/fea/data_plane/io/io_tcpudp_socket.cc +++ b/fea/data_plane/io/io_tcpudp_socket.cc @@ -777,6 +777,29 @@ IoTcpUdpSocket::udp_open_bind_broadcast(const string& ifname, // INADDR_ANY is used. struct in_addr local_in_addr; local_in_addr.s_addr = INADDR_ANY; +#if defined(HOST_OS_LINUX) + // Linux handles binding to local IP, and that allows more than one OLSR + // to run at a time. Try to bind to first useful IP address. + bool found_lip = false; + for (IfTreeVif::IPv4Map::const_iterator ai = vifp->ipv4addrs().begin(); + ai != vifp->ipv4addrs().end(); + ++ai) { + IfTreeAddr4& ar = *(ai->second); + if (ar.enabled() && ar.multicast()) { + //XLOG_WARNING("Binding to local IP: %s in udp_open_bind_broadcast on vif: %s/%s\n", + // ar.str().c_str(), ifname.c_str(), vifname.c_str()); + ar.addr().copy_out(local_in_addr); + found_lip = true; + break; + } + //else { + // XLOG_WARNING("Ignoring ip: %s\n", ar.str().c_str()); + //} + } + if (!found_lip) { + XLOG_WARNING("ERROR: Couldn't find local IP for vif: %s/%s\n", ifname.c_str(), vifname.c_str()); + } +#endif ret_value = comm_sock_bind4(_socket_fd, &local_in_addr, htons(local_port)); if (ret_value != XORP_OK) { -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Jul 1 13:31:50 2009 From: greearb at candelatech.com (Ben Greear) Date: Wed, 01 Jul 2009 13:31:50 -0700 Subject: [Xorp-users] OLSR on Linux? In-Reply-To: <4A4BAF51.7030902@candelatech.com> References: <4A4BAF51.7030902@candelatech.com> Message-ID: <4A4BC7B6.2000209@candelatech.com> On 07/01/2009 11:47 AM, Ben Greear wrote: > Has anyone ever used OLSR on Linux with more than one interface? I couldn't get it to work without > the patch below, but maybe that's because of other patches I've added > to xorp? > > With the below it starts, at least...not sure if it actually works yet. Actually, that patch is broken. This one seems to get me a bit farther: [greearb at ben-dt2 olsr]$ git diff diff --git a/fea/data_plane/io/io_tcpudp_socket.cc b/fea/data_plane/io/io_tcpudp_socket.cc index bfa23bd..d0174ae 100644 --- a/fea/data_plane/io/io_tcpudp_socket.cc +++ b/fea/data_plane/io/io_tcpudp_socket.cc @@ -754,6 +754,12 @@ IoTcpUdpSocket::udp_open_bind_broadcast(const string& ifname, comm_get_last_error_str()); return (XORP_ERROR); } + ret_value = comm_set_reuseaddr(_socket_fd, 1); + if (ret_value != XORP_OK) { + error_msg = c_format("Cannot enable address re-use: %s", + comm_get_last_error_str()); + return (XORP_ERROR); + } } // 2b. On Linux, bind socket to device (SO_BINDTODEVICE). -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Thu Jul 2 03:26:28 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 02 Jul 2009 11:26:28 +0100 Subject: [Xorp-users] OLSR on Linux? In-Reply-To: <4A4BC7B6.2000209@candelatech.com> References: <4A4BAF51.7030902@candelatech.com> <4A4BC7B6.2000209@candelatech.com> Message-ID: <4A4C8B54.6080902@incunabulum.net> Ben Greear wrote: > On 07/01/2009 11:47 AM, Ben Greear wrote: > >> Has anyone ever used OLSR on Linux with more than one interface? I couldn't get it to work without >> the patch below, but maybe that's because of other patches I've added >> to xorp? >> I was able to run OLSR just fine on Gentoo Linux 2008.0 with a two-armed router (one wifi i/f, one ethernet) during its development. What specific problem are you encountering, do you have error output? I'm curious why a REUSEADDR is needed, when BINDTODEVICE seemed to work just fine. OLSR currently isn't part of the XORP supported offering as such, so anything that happens with it is on a best-effort basis. Thanks for the patch, we can try to incorporate it once the community branch is re-opened. We are still waiting for legal clearance to do this. cheers BMS From greearb at candelatech.com Thu Jul 2 08:10:03 2009 From: greearb at candelatech.com (Ben Greear) Date: Thu, 02 Jul 2009 08:10:03 -0700 Subject: [Xorp-users] OLSR on Linux? In-Reply-To: <4A4C8B54.6080902@incunabulum.net> References: <4A4BAF51.7030902@candelatech.com> <4A4BC7B6.2000209@candelatech.com> <4A4C8B54.6080902@incunabulum.net> Message-ID: <4A4CCDCB.5040600@candelatech.com> Bruce Simpson wrote: > Ben Greear wrote: >> On 07/01/2009 11:47 AM, Ben Greear wrote: >> >>> Has anyone ever used OLSR on Linux with more than one interface? I >>> couldn't get it to work without >>> the patch below, but maybe that's because of other patches I've added >>> to xorp? >>> > > I was able to run OLSR just fine on Gentoo Linux 2008.0 with a > two-armed router (one wifi i/f, one ethernet) during its development. > What specific problem are you encountering, do you have error output? > I'm curious why a REUSEADDR is needed, when BINDTODEVICE seemed to > work just fine. The problem was that the kernel would not open sockets claiming that they were in-use already. I'm not sure exactly why that was, but when I added the reuse-addr logic, it worked fine. > > OLSR currently isn't part of the XORP supported offering as such, so > anything that happens with it is on a best-effort basis. > > Thanks for the patch, we can try to incorporate it once the community > branch is re-opened. We are still waiting for legal clearance to do this. No problem. After my patch (the second, working one), OLSR seemed to create routes properly. I haven't tested mobility (adding/removing links via xorp cli), but will get to that today or early next week. Thanks, Ben > > cheers > BMS -- Ben Greear Candela Technologies Inc http://www.candelatech.com From seb at anet.fr Fri Jul 3 03:35:03 2009 From: seb at anet.fr (=?ISO-8859-1?Q?S=E9bastien_Nam=E8che?=) Date: Fri, 3 Jul 2009 12:35:03 +0200 Subject: [Xorp-users] Why Xorp so slow ? Message-ID: Hi, We spent those last days experimenting Xorp, OpenBGP and Quagga. We found that Xorp takes a lot of time to construct the RIB and to inject all prefixes to the kernel routing tables. For example, for the same machine, same OS, this is the rough time needed to import the global routing table from a peer just after the opening of the BGP session : - OpenBGP: less than 1 minute ; - Quagga: between 2 and 3 minutes ; - Xorp: 14 minutes. This is a copy of the first lines of a "top" running while importing the global routing table : ----- last pid: 1055; load averages: 1.44, 0.82, 0.40 up 0+00:13:38 13:53:40 24 processes: 2 running, 22 sleeping CPU: 88.3% user, 0.0% nice, 10.5% system, 1.2% interrupt, 0.0% idle Mem: 74M Active, 21M Inact, 29M Wired, 252K Cache, 11M Buf, 1372M Free Swap: 3039M Total, 3039M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 545 root 1 103 0 47044K 44152K RUN 1:36 32.96% xorp_bgp 451 root 1 59 0 15424K 10676K select 0:58 22.17% xorp_fea 512 root 1 59 0 19268K 15924K select 0:51 18.26% xorp_rib ----- The CPU is 100% busy during 14 minutes. It's old hardware, in production we will use servers 2 ou 3 times faster. But still, I don't understand why there is so much differences between Xorp and the others. Regards, -- Seb From bms at incunabulum.net Fri Jul 3 04:51:52 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri, 03 Jul 2009 12:51:52 +0100 Subject: [Xorp-users] Why Xorp so slow ? In-Reply-To: References: Message-ID: <4A4DF0D8.1050603@incunabulum.net> Hi, Thanks for your message about XORP performance. There are reasons for this performance difference, and perhaps the most crucial is that XORP uses an intermediate RIB process; OpenBGPD doesn't, Quagga does do something like a RIB. The projects you're comparing also have vastly different goals. S?bastien Nam?che wrote: > ... > It's old hardware, in production we will use servers 2 ou 3 times > faster. But still, I don't understand why there is so much differences > between Xorp and the others. > What exactly is the specification of the hardware you're using, to give us a better feel for the slowdown? Did you perform these comparisons on the same hardware? The thing to be borne in mind is that for many years, XORP's goal was correctness and stability, not necessarily performance, and the design was aimed at non-embedded platforms in mind initially. So premature optimization wasn't a goal for the project. It is also worth pointing out that as a result of this focus, XORP hasn't suffered from issues in production deployment which have bitten the alternatives. Of course in using these other tools you make a trade-off -- the other alternatives don't support multicast routing, for example, or necessarily run cross-platform, or support all of the policy redistribution features, MANET protocols etc. The danger in informal benchmarks is that it's easy to trip up over things like the L2 cache being primed, kernel memory fragmentation, etc. Do you plan to deploy XORP? We can get performance up, however, it's also a community effort at the end of the day. thanks BMS From bms at incunabulum.net Fri Jul 3 05:05:10 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri, 03 Jul 2009 13:05:10 +0100 Subject: [Xorp-users] Why Xorp so slow ? In-Reply-To: References: Message-ID: <4A4DF3F6.8050106@incunabulum.net> S?bastien Nam?che wrote: > ... > last pid: 1055; load averages: 1.44, 0.82, 0.40 up 0+00:13:38 > 13:53:40 > 24 processes: 2 running, 22 sleeping > CPU: 88.3% user, 0.0% nice, 10.5% system, 1.2% interrupt, 0.0% idle > Mem: 74M Active, 21M Inact, 29M Wired, 252K Cache, 11M Buf, 1372M Free > Swap: 3039M Total, 3039M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 545 root 1 103 0 47044K 44152K RUN 1:36 32.96% > xorp_bgp > 451 root 1 59 0 15424K 10676K select 0:58 22.17% > xorp_fea > 512 root 1 59 0 19268K 15924K select 0:51 18.26% > xorp_rib > P.S. I should point out that we're well aware, as developers, of the contention on the BGP-RIB-FEA path. It's in my gunsights right now! But doing something about it is not going to happen overnight and we need all the help we can get. Again, this is nothing to be alarmed about -- the default configuration of XORP in the community branch is going to use TCP sockets out of the box for the IPC transport. This means lots of kernel-userland context switches. Using shared memory or pipes might help, however, this requires digging a little deeper into the code to see where the performance switches are. XORP's focus has been correctness and stability, rather than performance, so we have been more conservative about what we point users at in the documentation in terms of configuration switches. Performance optimization does however require a severe re-think of the architecture, and this is what I have on the table right now with XORP, Inc. -- I'm proposing that we rewrite a lot of the core XRL layer for a start. As this is an infrastructural project, it seems best that it takes place in the open. We're hamstrung in what we can do until the community branch re-opens for development, and this depends on legal clearance within XORP, Inc. But when the branch does re-open, any and all help will be very welcome -- *especially* if you or others have strong C++ and Boost background. thanks, BMS From seb at anet.fr Fri Jul 3 06:01:14 2009 From: seb at anet.fr (=?WINDOWS-1252?Q?S=E9bastien_Nam=E8che?=) Date: Fri, 3 Jul 2009 15:01:14 +0200 Subject: [Xorp-users] Why Xorp so slow ? In-Reply-To: <4A4DF0D8.1050603@incunabulum.net> References: <4A4DF0D8.1050603@incunabulum.net> Message-ID: Bruce, Thanks for this fast answer. Le 3 juil. 09 ? 13:51, Bruce Simpson a ?crit : > What exactly is the specification of the hardware you're using, to > give us a better feel for the slowdown? Did you perform these > comparisons on the same hardware? Yes, same hardware and same OS. We did it for FreeBSD and Linux (it seems an little faster under Linux). The hardware is an AMD Athlon XP at 1500 MHz (bus clock is 100 MHz) with 1,5 Gb RAM. For production, we plan to use a Pentium 4 at 2800 MHz (bus clock 800 MHz) with 1 Gb RAM. > The danger in informal benchmarks is that it's easy to trip up over > things like the L2 cache being primed, kernel memory fragmentation, > etc. Yes, this is not a real, full, formal benchmark. This is rather "informal". But the difference is huge. > Do you plan to deploy XORP? We can get performance up, however, it's > also a community effort at the end of the day. Yes. We want to deploy it. I like the way it is possible to filter in Xorp. We were able to dot things that were not possible with Quagga and OpenBGP/OpenOSPF. (The only thing we couldn't do is the AS prepending for OSPF injected procefixes.) OpenBGP/OpenOSPF are very fast and easy to configure, but have poor functionnalities. But OpenOSPF is young... Regards, -- Seb ?Un peuple pr?t ? sacrifier un peu de libert? pour un peu de s?curit? ne m?rite ni l?une ni l?autre, et finit par perdre les deux.? -- Thomas Jefferson. From seb at anet.fr Fri Jul 3 06:05:37 2009 From: seb at anet.fr (=?ISO-8859-1?Q?S=E9bastien_Nam=E8che?=) Date: Fri, 3 Jul 2009 15:05:37 +0200 Subject: [Xorp-users] Why Xorp so slow ? In-Reply-To: <4A4DF3F6.8050106@incunabulum.net> References: <4A4DF3F6.8050106@incunabulum.net> Message-ID: <4111B7B2-DAD2-44DD-8BE2-8EFFF4BB65F2@anet.fr> Bruce, all, Le 3 juil. 09 ? 14:05, Bruce Simpson a ?crit : > We're hamstrung in what we can do until the community branch re- > opens for development, and this depends on legal clearance within > XORP, Inc. So, the community branch development is now in standby as far as I understand ? > But when the branch does re-open, any and all help will be very > welcome -- *especially* if you or others have strong C++ and Boost > background. We can help for feedback. But, sadly, not for development. I can read C ++, but never wrote a single line of code. Regards, -- Seb From r.harbird at cs.ucl.ac.uk Fri Jul 3 10:17:27 2009 From: r.harbird at cs.ucl.ac.uk (Rae Harbird) Date: Fri, 3 Jul 2009 18:17:27 +0100 Subject: [Xorp-users] Config file error Message-ID: Hi Does anyone know what kind of configuration file error might cause this message or give me some hints about how to debug it? Please note: the rubi module depends on olsr which starts up successfully beforehand. [ 2009/07/03 18:03:28 ERROR xorp_rtrmgr:30310 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: Can't validate config ready of process rubi [ 2009/07/03 18:03:28 ERROR xorp_rtrmgr:30310 RTRMGR +261 master_conf_tree.cc config_done ] Configuration failed: Can't validate config ready of process rubi I have included the config, template, tgt and xif files below. Thanks Rae ==== config file: BEGIN ----> interfaces { interface eth1 { description: "xorp data interface" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } } protocols { rubi { advertisement_interval: 120 resource_timeout: 1800 max_resources: 50 forwarder: 10.10.1.1 } olsr4 { main-address: 192.168.1.100 interface eth1 { vif eth1 { address 192.168.1.100 { } } } traceoptions { flag all { disable: false } } } } END ----> Here is the template file: BEGIN ----> protocols { rubi { targetname: txt = "rubi"; advertisement_interval: u32 = 120; /* two minutes */ resource_timeout: u32 = 1800; /* half an hour */ max_resources: u32 = 50; my_resources: txt; forwarder: ipv4; proactive_routing: bool = true; reactive_routing: bool = true; /* Not yet .... dns_entry { name: txt; ip_address: ipv4; } */ } } protocols { rubi { %help: short "Distribute service information"; %modinfo: provides rubi; %modinfo: depends olsr4; %modinfo: path "contrib/rubi/xorp_rubi"; %modinfo: default_targetname "rubi"; %modinfo: status_method xrl "$(rubi.targetname)/common/0.1/get_status->status:u32&reason:txt"; %modinfo: shutdown_method xrl "$(rubi.targetname)/common/0.1/shutdown"; %mandatory: $(@.targetname); targetname { %user-hidden: "XRL target name"; %help: short "XRL target name"; %set:; } resource_timeout { %help: short "A resource is valid for this period."; %help: long "A resource is valid for this period, the resource will expire after this if it is not refreshed."; %set: xrl "$(rubi.targetname)/rubi/0.1/set_resource_timeout?resource_timeout:u32=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_resource_timeout->resource_timeout:u32"; } max_resources { %help: short "The maximum number of resource entries about which this node will maintain information."; %set: xrl "$(rubi.targetname)/rubi/0.1/set_max_resources?max_resources:u32=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_max_resources->max_resources:u32"; } my_resources { %help: short "The URL for a resource belonging to this node."; %set: xrl "$(rubi.targetname)/rubi/0.1/set_my_resource?my_resource:txt=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_my_resources?resource_url:txt->my_resources:list"; %delete: xrl "$(rubi.targetname)/rubi/0.1/delete_my_resource?my_resource:txt=$(@)"; %list: xrl "$(rubi.targetname)/rubi/0.1/list_my_resources->resources:list"; } /* Not yet ... domain_name { %help: short "A domain name and ip address tuple."; %set: xrl "$(rubi.targetname)/rubi/0.1/set_dns_entry?dns_entry?name:txt=$(@)?ip_address:ipv4=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_dns_entry->dns_entry?name:txt=$(@)?ip_address:ipv4=$(@)"; %delete: xrl "$(rubi.targetname)/rubi/0.1/delete_dns_entry->dns_entry?name:txt=$(@)?ip_address:ipv4=$(@)"; %list: xrl "$(rubi.targetname)/rubi/0.1/list_domain_names->domain_names:list"; } */ forwarder { %help: short "The IP address for a node willing to act as a forwarder."; %set: xrl "$(rubi.targetname)/rubi/0.1/set_forwarder?ip_address:ipv4=$(@)"; %delete: xrl "$(rubi.targetname)/rubi/0.1/delete_forwarder?in_ip_address:ipv4=$(@)"; %list: xrl "$(rubi.targetname)/rubi/0.1/list_forwarders->forwarders:list"; } advertisement_interval { %help: short "Resource information is advertised at this interval"; %set: xrl "$(rubi.targetname)/rubi/0.1/set_advertisement_interval?interval:u32=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_advertisement_interval->interval:u32"; } proactive_routing { %help: short "Flag indicating whether or not the node is operating in proactive mode"; %set: xrl "$(rubi.targetname)/rubi/0.1/set_proactive_routing_mode?enabled:bool=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_proactive_routing_mode->enabled:bool"; } reactive_routing { %help: short "Flag indicating whether or not the node is operating in reactive mode"; %set: xrl "$(rubi.targetname)/rubi/0.1/set_reactive_routing_mode?enabled:bool=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_reactive_routing_mode->enabled:bool"; } /* main_addr { %help: short "The main IP address for the node."; %set: xrl "$(rubi.targetname)/rubi/0.1/set_main_address?ip_address:ipv4=$(@)"; %get: xrl "$(rubi.targetname)/rubi/0.1/get_main_address->ip_address:ipv4"; }*/ } } END ----> And here is the xif file: BEGIN ----> /* ** RUBI v1 -- protocol XRL interface. */ interface rubi/0.1 { /* * Protocol variables. */ /** * Set the max number of resource entries. * * @param max_resources the maximum number of resources that the node can * hold information about. */ set_max_resources ? max_resources:u32 /** * Get the max number of resources entries. * * @param max_resources the maximum number of resources that the node can * hold information about. */ get_max_resources -> max_resources:u32 /* * RUBI process commands. */ /** * Clear service directory database. */ clear_database /* * RUBI Global protocol timers. */ /** * Set the SERVICE_TIMEOUT. * * @param interval the new SERVICE_TIMEOUT. */ set_resource_timeout ? resource_timeout:u32 /** * Get the SERVICE_TIMEOUT. */ get_resource_timeout -> resource_timeout:u32 /** * Set the ADVERTISEMENT_INTERVAL. * * @param interval the new ADVERTISEMENT_INTERVAL. */ set_advertisement_interval ? interval:u32 /** * Get the ADVERTISEMENT_INTERVAL. */ get_advertisement_interval -> interval:u32 /* * RUBI resources database state. */ /** * Get the list of resources owned and advertised by a node (my resources). * * Return a list of text values. Each value is a service URL that * can be advertised by the node. */ list_my_resources -> resources:list /** * Add a resource to the list of my resources that can be * advertised. * */ set_my_resource ? my_resource:txt /** * Find resources which match those in the list of my resources * */ get_my_resources ? resource_url:txt \ -> my_resources:list /** * Clear the list of my resources * **/ clear_my_resources /** * Delete a resource to the list of my resources * */ delete_my_resource ? my_resource:txt /** * Add a DNS entry */ set_dns_entry ? name:txt \ & ip_address:ipv4 /** * Get a DNS entry */ get_dns_entry ? name:txt \ -> ip_address:ipv4 /** * Delete a DNS entry */ delete_dns_entry ? name:txt /** * Get the list of dns entries owned and advertised by a node (my services). * Return a list of text values. Each value is a resource URL that can be * advertised by the node. */ list_dns_entries -> dns_entries:list /** * Add a forwarder */ set_forwarder ? ip_address:ipv4 /** * Get forwarder */ get_forwarder ? in_ip_address:ipv4 \ -> forwarder_ip_address:ipv4 /** * Delete forwarder */ delete_forwarder ? in_ip_address:ipv4 /** * List forwarders */ list_forwarders -> forwarders:list /** * Add a resource to the list of learned resources. */ set_learned_resource ? ip_address:ipv4 \ & resource_url:txt /** * Get the list of services which match a particular service name. * * Return a list of text values. Each value is a service URL. */ get_learned_resources ? resource_url:txt \ -> \ resources:list /** * Get the list of learned resources * * Return a list of text values. Each value is a resource URL. */ list_learned_resources -> resources:list /** * Delete a resource from the list of learned resources. */ delete_learned_resource ? ip_address:ipv4 \ & resource_url:txt /** * Clear the list of learned resources. */ clear_learned_resources /** * Set the routing mode which this node will use. * For the timebeing, a node may use either proactive or reactive * routing or both. */ set_proactive_routing_mode ? enabled:bool get_proactive_routing_mode -> enabled:bool set_reactive_routing_mode ? enabled:bool get_reactive_routing_mode -> enabled:bool /** * Receive an external message from a xorp module and parse it. * * @param external_message the message that must be parsed * */ process_message ? message_body:binary /** * Set/get the main address for the Rubi node. This is used in messages to represent the source. */ set_main_address ? ip_address:ipv4 get_main_address -> ip_address:ipv4 } END ----> rubi.tgt BEGIN ----> #include "../interfaces/common.xif" #include "../interfaces/rubi.xif" target rubi implements common/0.1, \ rubi/0.1 END ----> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090703/e0c53cd9/attachment-0001.html From greearb at candelatech.com Fri Jul 3 14:58:07 2009 From: greearb at candelatech.com (Ben Greear) Date: Fri, 03 Jul 2009 14:58:07 -0700 Subject: [Xorp-users] Why Xorp so slow ? In-Reply-To: References: Message-ID: <4A4E7EEF.5010606@candelatech.com> S?bastien Nam?che wrote: > Hi, > > We spent those last days experimenting Xorp, OpenBGP and Quagga. > > We found that Xorp takes a lot of time to construct the RIB and to > inject all prefixes to the kernel routing tables. For example, for the > same machine, same OS, this is the rough time needed to import the > global routing table from a peer just after the opening of the BGP > session : > - OpenBGP: less than 1 minute ; > - Quagga: between 2 and 3 minutes ; > - Xorp: 14 minutes. > Can you compile xorp with debugging and run this test with oprofile enabled? That should give a good idea of where the performance bottlenecks are. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From emuller at engineyard.com Mon Jul 6 15:28:39 2009 From: emuller at engineyard.com (Edward Muller) Date: Mon, 6 Jul 2009 15:28:39 -0700 Subject: [Xorp-users] ECMP/Route sharing Message-ID: I have 2 possible default routes getting advertised to me via OSPF, but xorp only adds one of them. Any way to get have xorp add/manage both of them? -- Edward Muller From bms at incunabulum.net Mon Jul 6 17:58:04 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 07 Jul 2009 01:58:04 +0100 Subject: [Xorp-users] ECMP/Route sharing In-Reply-To: References: Message-ID: <4A529D9C.1020107@incunabulum.net> Hi, Thanks for your question about ECMP... Edward Muller wrote: > I have 2 possible default routes getting advertised to me via OSPF, > but xorp only adds one of them. > Any way to get have xorp add/manage both of them? > Unfortunately, in the community branch, XORP's FEA does not currently support multiple winning routes. Some degree of refactoring would be needed to make this possible. Whilst there's no real reason why the RIB couldn't support it, some means of breaking the tie is needed when the metrics are equal. The FEA doesn't know about flows (yet). cheers, BMS From tafim at itinsideout.com Tue Jul 7 08:54:25 2009 From: tafim at itinsideout.com (Tafi Makamure) Date: Tue, 7 Jul 2009 16:54:25 +0100 Subject: [Xorp-users] [Not] Advertising Routes to BGP Message-ID: Dear fellow xorp_users We are trying to move to xorp as a routing platform. We have two public subnets we want to advertise. We currently bring up connections with our peers and accept routes from them, but we do not advertise our connected routes. Instead we advertise routes learned from other peers! Our config.boot file is attached - we have removed peer details to protect their privacy, but this seems to be an issue with policy only as we are connected to the peers correctly. Please Help! Thanks Tafi Makamure -------------- next part -------------- A non-text attachment was scrubbed... Name: config.boot Type: application/octet-stream Size: 4774 bytes Desc: config.boot Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090707/222a3b2c/attachment.obj From bms at incunabulum.net Tue Jul 7 09:47:12 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 07 Jul 2009 17:47:12 +0100 Subject: [Xorp-users] Announcement: End-of-life on Windows support in XORP community branch Message-ID: <4A537C10.2000204@incunabulum.net> Hi all, This is just to announce that Windows support will be cut from the next community release of XORP, effective immediately. There are no free [1] toolchains available for systems-level C/C++ development on the Windows platform at the moment, apart from MinGW. This is a big factor in this decision. Unfortunately, whilst I've personally raised the issue with both the SUA/Interix community, and the Microsoft technical leads for Windows Networking, I have received no replies from either of them. See here: http://www.suacommunity.com/forum/tm.aspx?m=16790 http://www.suacommunity.com/forum/Default.aspx http://www.surveymonkey.com/sr.aspx?sm=BTQe0euUEEB40X_2fdXg5mOtRGmb_2bcU2sVnn6cLg44Qxk_3d An official announcement about this matter from Microsoft is still pending. Whilst we chose MinGW as the toolchain for delivering XORP on Windows, and succesfully demonstrated it in Redmond handling a full BGP route feed on Windows Server 2003, way back in 2005, we have to ship toolchain patches with every XORP release, making it difficult for users to build from source. Maintaining binary releases requires engineering resource, which is probably best found within host organisations actually using this code -- one of the trade-offs of the open source model. The Windows port of XORP was experimental in nature, and was never fully integrated with the Windows Networking stack due to a lack of easily available and open information about how such integration might be performed. This is a great shame as I am sure you will all agree. Should we hear from someone within the XORP community who is willing to step up as developer and maintainer going forward, it will be possible to resurrect the Win32 port. However -- radical change will be necessary to meet users' present and future needs in the community, and for the time being, Windows support will not be possible to maintain during this time of radical change. The hope is that these changes will make it easier for future volunteers to maintain Win32 as a tier 1 platform. Once again, thanks for your ongoing support of XORP. best wishes, BMS [1] definition of free in this instance: freely redistributable, and patent and license unencumbered, with sufficient platform API support for networking/routing. From bms at incunabulum.net Tue Jul 7 10:26:21 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 07 Jul 2009 18:26:21 +0100 Subject: [Xorp-users] Announcement: end-of-life: Jam support in community branch Message-ID: <4A53853D.5090901@incunabulum.net> Hi all, This is just to announce that the Jamfiles will be going away in the community branch. The intention is to replace the use of GNU Autotools with SCons, another freely available build tool based on Python: www.scons.org Jam itself hasn't seen the wide uptake that many hoped for, despite having an excellent technical pedigree, written by Christopher Seiwald to build Sybase itself in '96. Motivation: I've had an experimental private branch where Boost.BuildV2 was in use. This is a very technically strong tool for C++ and Boost users, based on Boost's own fork of Jam, BJam. However, whilst it's as portable as Boost itself is, it suffers from poor uptake. This is mostly because the language within Boost.BuildV2 is unlike any other. The Boost team themselves have been seriously looking at a Python based rewrite, and code drops post-milestone 12 of Boost.BuildV2 are part of that rewrite. However, SCons itself is written in Python already, and offers most of its advantages. That, and GNU autotools is a serious impediment to large scale C++ development. XORP's scope puts it just inside the category of 'large scale C++'. Thanks for your ongoing support of XORP. regards, BMS From bms at incunabulum.net Tue Jul 7 10:36:45 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 07 Jul 2009 18:36:45 +0100 Subject: [Xorp-users] SNMP support has uncertain future Message-ID: <4A5387AD.2030501@incunabulum.net> Hi all, This is just to announce that SNMP support faces an uncertain future in the community branch. The SNMP implementation in community XORP is far from complete. It suffers from the following major limitations: * Only the basic BGP and interface mibs are actually supported. The OSPF MIB is only a stub. * It is completely tied to Net-SNMP. No other master SNMP agent may be used. This makes supporting other host platforms for XORP very difficult. * It requires shared library support. In operational deployment, this is a reasonable requirement, however it does add a dynamically-loaded component to the system SNMP master agent which may fail. Whilst I'm circumscribed in what I can say specifically, this entire model is being re-thought in the commercial product. A similar rethink is necessary for community XORP to succeed and continue to provide SNMP support. We'd like to make it easier for contributors to add support to the SNMP agent in community XORP too, and hopefully the changes being considered right now will help. bestest, BMS From jnebrera at eneotecnologia.com Wed Jul 8 04:55:48 2009 From: jnebrera at eneotecnologia.com (Jaime Nebrera) Date: Wed, 08 Jul 2009 13:55:48 +0200 Subject: [Xorp-users] SNMP support has uncertain future In-Reply-To: <4A5387AD.2030501@incunabulum.net> References: <4A5387AD.2030501@incunabulum.net> Message-ID: <1247054148.16022.4.camel@blas> Hi Bruce, I think would be clarifying if you explain what will come out of community edition but "go" in a professional version, and what just is going to disappear in both. Regards El mar, 07-07-2009 a las 18:36 +0100, Bruce Simpson escribi?: > Hi all, > > This is just to announce that SNMP support faces an uncertain future in the community branch. The SNMP implementation in community XORP is far from complete. > > It suffers from the following major limitations: > * Only the basic BGP and interface mibs are actually supported. > The OSPF MIB is only a stub. > * It is completely tied to Net-SNMP. > No other master SNMP agent may be used. This makes supporting other host platforms for XORP very difficult. > * It requires shared library support. > In operational deployment, this is a reasonable requirement, however it does add a dynamically-loaded component to the system SNMP master agent which may fail. > > Whilst I'm circumscribed in what I can say specifically, this entire model is being re-thought in the commercial product. A similar rethink is necessary for community XORP to succeed and continue to provide SNMP support. > > We'd like to make it easier for contributors to add support to the SNMP agent in community XORP too, and hopefully the changes being considered right now will help. > > bestest, > BMS > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- ?Jaime Nebrera - jnebrera at eneotecnologia.com Consultor TI - ENEO Tecnologia SL Pol. PISA - C/ Manufactura 6, P1, 3B Mairena del Aljarafe - 41927 - Sevilla Telf.- 955 60 11 60 / 619 04 55 18 From bms at incunabulum.net Wed Jul 8 07:57:24 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 08 Jul 2009 15:57:24 +0100 Subject: [Xorp-users] SNMP support has uncertain future In-Reply-To: <1247054148.16022.4.camel@blas> References: <4A5387AD.2030501@incunabulum.net> <1247054148.16022.4.camel@blas> Message-ID: <4A54B3D4.7030504@incunabulum.net> Jaime Nebrera wrote: > Hi Bruce, > > I think would be clarifying if you explain what will come out of > community edition but "go" in a professional version, and what just is > going to disappear in both. > At the moment, it is very likely that the MIBS will go away in the community branch. We would aim to replace the functionality somehow, hopefully via user contributions. I don't know about the commercial product. thanks, BMS From greearb at candelatech.com Thu Jul 9 12:09:26 2009 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Jul 2009 12:09:26 -0700 Subject: [Xorp-users] OLSR test results on Linux. Message-ID: <4A564066.9000608@candelatech.com> I've been doing a few preliminary tests of OLSR + pim-sm testing on Linux. With a patch to fea (posted previously on the xorp-hackers list), it works fine, including with virtual tables and multiple instances of Xorp. I had to add a policy to export connected and static routes into olsr to get it to act as I wanted, but that also worked fine as soon as I configured xorp properly. Normal UDP (unicast) traffic works fine. I can't get mcast working, but that may be some other problem on my end (it works fine with OSPF in the same configuration) Next, I tried dynamic changes (using xorpsh to add/remove interfaces). I had 3 virtual nodes, linked in a triangle. I was running traffic between N2 and N3. I dropped the link between N2 and N3 and traffic started flowing through N1 as expected. I re-added the link, and traffic quickly switched back to flowing directly between N2 and N3. So far, the only weird thing is that it seems to take even longer than ever to execute commands to add the interfaces. I'll need to do more testing to figure out if OLSR is to blame for this, or if it's something else: XORPsh-helper: Completed command: 8 successfully in 5296.577ms against router-id: 2, cmds: nice -17 xorpsh -c configure -c set interfaces interface 2.3.2 vif 2.3.2 address 10.2.3.2 prefix-length 24 -c commit -c set protocols olsr4 interface 2.3.2 vif 2.3.2 address 10.2.3.2 interface-cost 1 -c set protocols igmp interface 2.3.2 vif 2.3.2 disable false -c set protocols pimsm4 interface 2.3.2 vif 2.3.2 disable false -c set plumbing mfea4 interface 2.3.2 vif 2.3.2 disable false -c commit -c exit -c exit (This is on an 8-core nehalem box) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Thu Jul 9 12:25:14 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 09 Jul 2009 20:25:14 +0100 Subject: [Xorp-users] OLSR test results on Linux. In-Reply-To: <4A564066.9000608@candelatech.com> References: <4A564066.9000608@candelatech.com> Message-ID: <4A56441A.3060709@incunabulum.net> Ben Greear wrote: > ... > Normal UDP (unicast) traffic works fine. I can't get mcast working, but > that may be some other problem on my end (it works fine with OSPF in the > same configuration) > Multicasting isn't supported by XORP's OLSR implementation at the moment; that's likely to need kernel patches. Specifically what's needed for the MANET protocols, is a way to capture the socket layer memberships, and the way to do that is probably to redirect IGMP into one of the userland daemons, and take action accordingly. That makes the MANET stuff relatively transparent to multicast apps. FreeBSD 8.0 is about to be released soon, and IGMPv3 is in there -- I left placeholders for the hooks needed in comments, but it does mean tagging an interface as being exclusively for MANET use. Tunneling, in some way, with a histogram based duplicate detection, is pretty much the only choice, because convergence can't be relied upon for loop detection in an ad-hoc network -- the topology is too dynamic. Look for the stuff Joe Macker's group at US NRL were doing. Also, the tie-breaks for multiple links in XORP's OLSR isn't ideal -- it's strictly Dijkstra and the ETX stuff isn't in there. I would far rather the Boost refactoring happened first, before that, because it will streamline that code greatly. I think I left some comments in OLSR about Boost candidate uses. cheers, BMS From greearb at candelatech.com Thu Jul 9 12:45:02 2009 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Jul 2009 12:45:02 -0700 Subject: [Xorp-users] OLSR test results on Linux. In-Reply-To: <4A56441A.3060709@incunabulum.net> References: <4A564066.9000608@candelatech.com> <4A56441A.3060709@incunabulum.net> Message-ID: <4A5648BE.6020205@candelatech.com> On 07/09/2009 12:25 PM, Bruce Simpson wrote: > Ben Greear wrote: >> ... >> Normal UDP (unicast) traffic works fine. I can't get mcast working, but >> that may be some other problem on my end (it works fine with OSPF in the >> same configuration) > > Multicasting isn't supported by XORP's OLSR implementation at the > moment; that's likely to need kernel patches. Ahh, but if I run pimsim beside it, it seems to work. I had a lame bug in my previous xorp conf file that caused pim and the other multicast daemons to not start. Thanks, Ben > > Specifically what's needed for the MANET protocols, is a way to capture > the socket layer memberships, and the way to do that is probably to > redirect IGMP into one of the userland daemons, and take action > accordingly. That makes the MANET stuff relatively transparent to > multicast apps. > > FreeBSD 8.0 is about to be released soon, and IGMPv3 is in there -- I > left placeholders for the hooks needed in comments, but it does mean > tagging an interface as being exclusively for MANET use. > > Tunneling, in some way, with a histogram based duplicate detection, is > pretty much the only choice, because convergence can't be relied upon > for loop detection in an ad-hoc network -- the topology is too dynamic. > Look for the stuff Joe Macker's group at US NRL were doing. > > Also, the tie-breaks for multiple links in XORP's OLSR isn't ideal -- > it's strictly Dijkstra and the ETX stuff isn't in there. I would far > rather the Boost refactoring happened first, before that, because it > will streamline that code greatly. I think I left some comments in OLSR > about Boost candidate uses. > > cheers, > BMS -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Thu Jul 9 12:48:25 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 09 Jul 2009 20:48:25 +0100 Subject: [Xorp-users] OLSR test results on Linux. In-Reply-To: <4A5648BE.6020205@candelatech.com> References: <4A564066.9000608@candelatech.com> <4A56441A.3060709@incunabulum.net> <4A5648BE.6020205@candelatech.com> Message-ID: <4A564989.8040303@incunabulum.net> Ben Greear wrote: >> >> Multicasting isn't supported by XORP's OLSR implementation at the >> moment; that's likely to need kernel patches. > > Ahh, but if I run pimsim beside it, it seems to work. Please do NOT deploy this in a production network :-) There is no loop detection, and the non-tunneled multicast traffic may loop back, possibly causing meltdown. Of course, if you are just using it to receive multicasts at most 1 hop from the OLSR router, you might get away with it -- providing none of the OLSR nodes are enabled as multicast forwarders. But I strongly recommend not doing this in production, until there's at least histogram based duplicate detection, which does need help from the kernel. cheers, BMS From greearb at candelatech.com Thu Jul 9 14:25:10 2009 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Jul 2009 14:25:10 -0700 Subject: [Xorp-users] OLSR test results on Linux. In-Reply-To: <4A564989.8040303@incunabulum.net> References: <4A564066.9000608@candelatech.com> <4A56441A.3060709@incunabulum.net> <4A5648BE.6020205@candelatech.com> <4A564989.8040303@incunabulum.net> Message-ID: <4A566036.2040708@candelatech.com> On 07/09/2009 12:48 PM, Bruce Simpson wrote: > Ben Greear wrote: >>> >>> Multicasting isn't supported by XORP's OLSR implementation at the >>> moment; that's likely to need kernel patches. >> >> Ahh, but if I run pimsim beside it, it seems to work. > > Please do NOT deploy this in a production network :-) > There is no loop detection, and the non-tunneled multicast traffic may > loop back, possibly causing meltdown. Where is the loop detection lacking? Is this any different from running OSPF and pimsm beside it? > Of course, if you are just using it to receive multicasts at most 1 hop > from the OLSR router, you might get away with it -- providing none of > the OLSR nodes are enabled as multicast forwarders. Our use case is multiple OLSR (xorp) routers in a mobile mesh network. Anything transmitting or receiving multicast will be directly attached to a router in the normal case. We did the same thing with OSPF & multicast routing and it seems to basically work that way at least. From looking at the routes that OLSR generates (for a simple network, at least), it seems pretty similar to what OSPF does. > But I strongly recommend not doing this in production, until there's at > least histogram based duplicate detection, which does need help from the > kernel. I'm not afraid to hack the kernel :) Got any pointers to what you are talking about here? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Thu Jul 9 14:49:58 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 09 Jul 2009 22:49:58 +0100 Subject: [Xorp-users] OLSR test results on Linux. In-Reply-To: <4A566036.2040708@candelatech.com> References: <4A564066.9000608@candelatech.com> <4A56441A.3060709@incunabulum.net> <4A5648BE.6020205@candelatech.com> <4A564989.8040303@incunabulum.net> <4A566036.2040708@candelatech.com> Message-ID: <4A566606.3080705@incunabulum.net> Ben Greear wrote: > > Where is the loop detection lacking? Is this any different from running > OSPF and pimsm beside it? OSPF doesn't know anything about multicast; you still need to run PIM within an OSPF domain at each hop. PIM will protect against forwarding loops, either by tunneled unicasting to the RP, or forming a shared tree based on its discovered topology. PIM will generally use the unicast routes learned by OSPF by pulling them into the MRIB. OLSR doesn't know anything about multicast. Whilst you could configure PIM peerings to nodes inside the OLSR cloud, this is largely pointless, if the topology is highly dynamic. PIM's in-built detection mechanisms like Asserts are just not designed with cloud in mind -- they work, for the most part, within shared broadcast domains like Ethernet, but they're not relevant to something like ATM which is NBMA. So there is no protection against multicast storms / packet amplification if there is a forwarding loop, unless you use something like the SMF draft. Forwarding loops can, and do, form within clouds, and this is one reason why various tunables, like weights, willingness-to-forward etc., exist in OLSR. I guess what you could do, as a workaround, is to hack mbonetools or something to forcibly install a tunnel-to-the-rp style entry to the multicast forwarding cache on the OLSR nodes. This effectively means that any multicast traffic originating within the cloud is always tunneled to the RP as a unicast packet. > > Our use case is multiple OLSR (xorp) routers in a mobile mesh network. > Anything transmitting or receiving multicast will be directly attached > to a router in the normal case. You should be OK, providing you don't intend to forward multicast traffic within the OLSR cloud itself -- i.e. it only originates from outside the cloud, and does not cross more than 1 hop to the OLSR node(s). If the hop count at the OLSR domain gateway router ends up being greater than 1, and OLSR nodes are configured to forward multicast, you risk a packet storm. > > We did the same thing with OSPF & multicast routing and it seems to > basically work that way at least. From looking at the routes that OLSR > generates (for a simple network, at least), it seems pretty similar to > what OSPF does. > OLSR is conceptually similar, in some respects, to OSPF, but the similarities stop as soon as you get to Topology Control. HNA is a bit of a hack to put it bluntly. > > Got any pointers to what you are talking about here? http://tools.ietf.org/html/draft-ietf-manet-smf-08 cheers BMS From krasa at wia.cz Fri Jul 10 08:10:35 2009 From: krasa at wia.cz (Michal =?ISO-8859-1?Q?Kr=E1sa?=) Date: Fri, 10 Jul 2009 17:10:35 +0200 Subject: [Xorp-users] error when plumbing starting Message-ID: <1247238635.2925.44.camel@nazghul> Hi all, I have a problem with configuring multicast routing on xorp (i've tested 1.6 and 1.5 version). When I try to add an interface to section plumbing - mfea4, got a following error: when i running multicast4.boot from doc files by typing "xorp_rtrmgr -b multicast4.boot" in terminal: [ 2009/07/10 16:45:50 FATAL xorp_fea:28921 MFEA +539 mfea_node.cc vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed [ 2009/07/10 16:45:50 ERROR xorp_rtrmgr:28920 RTRMGR +754 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 6. [ 2009/07/10 16:45:50 INFO xorp_rtrmgr:28920 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: fea [ 2009/07/10 16:45:50 INFO xorp_rtrmgr:28920 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: firewall [ 2009/07/10 16:45:50 INFO xorp_rtrmgr:28920 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: interfaces [ 2009/07/10 16:45:50 INFO xorp_rtrmgr:28920 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: mfea4 [ 2009/07/10 16:45:50 ERROR xorp_rtrmgr:28920 RTRMGR +2003 task.cc task_fail ] Shutting down fatally wounded process (mfea4) [ 2009/07/10 16:45:50 ERROR xorp_rtrmgr:28920 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: Can't startup process mfea4 [ 2009/07/10 16:45:50 ERROR xorp_rtrmgr:28920 RTRMGR +261 master_conf_tree.cc config_done ] Configuration failed: Can't startup process mfea4 If i prepare simple config with interface eth0 as system-default and run xorp_rtrmgr, everything is ok. But when login to console by xorpsh and try to configure plumbing, but on commit get error: Welcome to XORP on trois root at trois> configure Entering configuration mode. There are no other users in configuration mode. [edit] root at trois# set plumbing mfea4 disable false [edit] root at trois# commit [ 2009/07/10 16:55:05 INFO xorp_rtrmgr:29862 RTRMGR +101 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2009/07/10 16:55:05 FATAL xorp_fea:29863 MFEA +539 mfea_node.cc vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed [ 2009/07/10 16:55:05 ERROR xorp_rtrmgr:29862 RTRMGR +2003 task.cc task_fail ] Shutting down fatally wounded process (mfea4) [ 2009/07/10 16:55:05 INFO xorp_rtrmgr:29862 RTRMGR +176 module_manager.cc terminate ] Terminating module: mfea4 [ 2009/07/10 16:55:05 ERROR xorp_rtrmgr:29862 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: Can't startup process mfea4 Commit Failed Can't startup process mfea4[edit] root at trois# edit plumbing mfea4 [edit plumbing mfea4] root at trois# set interface eth0 [edit plumbing mfea4] root at trois# edit interface eth0 [edit plumbing mfea4 interface eth0] root at trois# set vif eth0 disable false [edit plumbing mfea4 interface eth0] root at trois# commit [ 2009/07/10 16:56:12 INFO xorp_rtrmgr:29862 RTRMGR +101 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2009/07/10 16:56:12 WARNING xorp_rtrmgr:29862 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled. ... [ 2009/07/10 16:56:42 WARNING xorp_rtrmgr:29862 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled. [ 2009/07/10 16:56:42 ERROR xorp_rtrmgr:29862 RTRMGR +2003 task.cc task_fail ] Shutting down fatally wounded process (mfea4) [ 2009/07/10 16:56:42 INFO xorp_rtrmgr:29862 RTRMGR +176 module_manager.cc terminate ] Terminating module: mfea4 [ 2009/07/10 16:56:42 ERROR xorp_rtrmgr:29862 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: Can't validate start of process mfea4 Commit Failed Can't validate start of process mfea4 Did anyone know, what can by wrong? I'm trying to locate problem, but I still faul. Thanks for help, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090710/b8eec1ef/attachment-0001.html From appletrp at gmail.com Mon Jul 13 07:52:32 2009 From: appletrp at gmail.com (Robert Appleton) Date: Mon, 13 Jul 2009 10:52:32 -0400 Subject: [Xorp-users] Basic Setup Problems Message-ID: Hi All, I'm trying to set up a basic testing situation between 2 computers on different subnets, a computer that has xorp, and a switch that is connecting the 3 machines. I've emailed the list before but I still can't seem to get it to work. This is my Setup: Computer 1: IP: 192.168.1.110 Mask: 255.255.255.0 Gateway: 192.168.1.1 Computer 2: IP:192.168.2.120 Mask: 255.255.255.0 Gateway: 192.168.2.1 Xorp Computer: eth0 (is the NIC name) with 2 addresses 192.168.1.1 192.168.2.1 Computer only has 1 NIC (I'm using fedora 10, and configured 2 addresses on the NIC) I don't know if that is necessary or if it should only have one (Let me know) When I ping from one computer to the other (even with the router off) I get reply from 192.168.2.1 Destination Host Unavailable -or- reply from 192.168.1.1 Destination Host Unavailable I pasted my configuration file below, please let me know what I need to do so that I can get this basic setup to work. Thanks! - Robert Appleton interfaces { restore-original-config-on-shutdown: false interface "eth0" { disable: false address 192.168.1.1 { prefix-length: 24 broadcast: 192.168.1.255 disable: false } } interface "eth0" { disable: false address 192.168.2.1 { prefix-length: 24 broadcast: 192.168.1.255 disable: false } } } fea { unicast-forwarding4 { disable: false } } protocols { static { route 192.168.2.1/24 { next-hop: 192.168.2.120 } route 192.168.1.1/24 { next-hop: 192.168.1.110 } } } From bms at incunabulum.net Mon Jul 13 12:50:52 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 13 Jul 2009 20:50:52 +0100 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. Message-ID: <4A5B901C.60102@incunabulum.net> Hi all, I'd like to hear from people who have an interest in maintaining XORP on specific platforms; please contact me if your distribution / OS isn't listed below, and let me know if you're interested in platform maintainership. The aim is to remove GNU Autotools completely from the tree, before Boost, ASIO and Thrift are introduced, to support cross-language use of the XORP core, in a clean, consistent and maintainable way. This is going to be a majorly disruptive change. It is likely that we are going to have to focus on 3 or 4 core distributions, for the community branch, with the resources we have. [1] At the moment, my 'core distro' list boils down to:- * Ubuntu 9.04 / Linux * Fedora 10 / Linux * FreeBSD 7.2/8.0 * OpenSolaris 2009.06 [2] Limiting ourselves to a handful of key distributions, allows more intent focus on making sure the most up-to-date, and feature complete, versions of community XORP are available on those platforms. If your platform is not listed, please let us know. The work on converting XORP's use of GNU Autotools to SCons is nearing completion. Most of the Autoconf tests have been converted to their SCons/Python equivalents; the speed and conciseness are a vast improvement. It's likely, but not for sure, that JT at XORP may be able to support NetBSD. XORP, Inc. may be using other Linux targets for internal development, but I cannot comment further at this time. I have the source building, without regression tests, using SCons, on both FreeBSD 7.2 and Linux 2.6.27 (Gentoo Linux 2008.0). [3] My outstanding tasks for that drop are as follows: * get cross-builds working; * restore static library builds (SCons is doing shared libraries for most targets); * get the regression tests building again. [4] Windows support isn't on the radar, until someone comes forward to support it, but I don't plan on breaking the portability that is already there -- except where bulldozing is really needed. best regards, BMS [1] I am also considering moving docs/ into a separate SVN branch, as it's huge, and we can probably get away with tag slippage there when rolling a community release. [2] I've not ported the OpenSolaris tests yet. Can anyone who's using this platform suggest a good VMDK/VDI image for VirtualBox, which has the SFU gcc toolchain? [3] There is an issue with the IPTables headers, however, under Gentoo 2008.0 where gcc 4.1.2 complains about arithmetic on void * pointers. This is likely due to bit-rotted kernel headers. [4] There is an internal Buildbot at XORP, Inc. and I need to get some feedback from JT (who is currently on holiday) about how feasible it will be to maintain build coverage with the diverse range of platforms that XORP has been able to support to date, with the internal engineering resources. From jnebrera at eneotecnologia.com Mon Jul 13 23:19:00 2009 From: jnebrera at eneotecnologia.com (Jaime Nebrera) Date: Tue, 14 Jul 2009 08:19:00 +0200 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <4A5B901C.60102@incunabulum.net> References: <4A5B901C.60102@incunabulum.net> Message-ID: <1247552340.6172.6.camel@blas> Hi Bruce, > At the moment, my 'core distro' list boils down to:- > * Ubuntu 9.04 / Linux > * Fedora 10 / Linux > * FreeBSD 7.2/8.0 > * OpenSolaris 2009.06 [2] Just a humble opinion. Both Linux distributions could be considered a bit "over the edge". It might be feasible to consider RHEL or CentOS for those that like more calm life :) Regards -- ?Jaime Nebrera - jnebrera at eneotecnologia.com Consultor TI - ENEO Tecnologia SL Pol. PISA - C/ Manufactura 6, P1, 3B Mairena del Aljarafe - 41927 - Sevilla Telf.- 955 60 11 60 / 619 04 55 18 From greearb at candelatech.com Tue Jul 14 07:32:38 2009 From: greearb at candelatech.com (Ben Greear) Date: Tue, 14 Jul 2009 07:32:38 -0700 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <1247552340.6172.6.camel@blas> References: <4A5B901C.60102@incunabulum.net> <1247552340.6172.6.camel@blas> Message-ID: <4A5C9706.8010502@candelatech.com> Jaime Nebrera wrote: > Hi Bruce, > > >> At the moment, my 'core distro' list boils down to:- >> * Ubuntu 9.04 / Linux >> * Fedora 10 / Linux >> * FreeBSD 7.2/8.0 >> * OpenSolaris 2009.06 [2] >> > > Just a humble opinion. Both Linux distributions could be considered a > bit "over the edge". It might be feasible to consider RHEL or CentOS for > those that like more calm life :) > I'll be using current Fedora releases, so even if core xorp is on older releases, I can get some test coverage and compile fixes etc for modern releases. It shouldn't be hard to get xorp to compile/run on lots of different linux-es. For that matter, our target platforms are currently: Fedora Core 5 (with updated kernel headers), FC8 and F11. I also run the image I compile on FC8 on Ubuntu 9.04 (with a few library soft-links, it seems to work fine). Thanks, Ben > Regards > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Tue Jul 14 09:04:29 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 14 Jul 2009 17:04:29 +0100 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <1247552340.6172.6.camel@blas> References: <4A5B901C.60102@incunabulum.net> <1247552340.6172.6.camel@blas> Message-ID: <4A5CAC8D.1010700@incunabulum.net> Hi Jaime, Thanks for these two suggestions. As I understand it, CentOS is basically RHEL repackaged. I agree with your view that Ubuntu and Fedora are in rapid change. I think it's safe to say that Gentoo has tailed off for the time being. Jaime Nebrera wrote: > Just a humble opinion. Both Linux distributions could be considered a > bit "over the edge". It might be feasible to consider RHEL or CentOS for > those that like more calm life :) > A friendly organisation's choice of Ubuntu was interesting, because of how they approach packaging. They already have an existing relationship with Canonical to get their packages into position for Ubuntu releases. Is anyone in the XORP community going to be able to perform this role, for CentOS and RHEL? Could this be the same person or organisation -- is there enough overlap between the two? A quick sweep reveals CentOS 5.2 is available as a VDI image; so I'll try to get a bit more familiarity with it, as I'm primarily a FreeBSD guy. It's probably an idea to integrate RPM and DEB generation into the SCons build system. Once the community code is back online, there should be some means of introducing this support. Until now, here are some pointers: http://www.scons.org/doc/1.2.0.d20090223/HTML/scons-user/a8379.html http://www.qandr.org/quentin/writings/debscons ...this sort of thing helps, if there's a lag between a release being rolled, and being shipped upstream. thanks, BMS From bms at incunabulum.net Tue Jul 14 09:16:22 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 14 Jul 2009 17:16:22 +0100 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <4A5C9706.8010502@candelatech.com> References: <4A5B901C.60102@incunabulum.net> <1247552340.6172.6.camel@blas> <4A5C9706.8010502@candelatech.com> Message-ID: <4A5CAF56.1090401@incunabulum.net> Ben, Thanks for this. So, are you willing to be platform lead for Fedora? ;-) If I had to pin down one Fedora release for XORP community support, which one would you recommend? Ben Greear wrote: > I'll be using current Fedora releases, so even if core xorp is on > older releases, I can > get some test coverage and compile fixes etc for modern releases. It > shouldn't be > hard to get xorp to compile/run on lots of different linux-es. > > For that matter, our target platforms are currently: Fedora Core 5 > (with updated kernel headers), > FC8 and F11. I also run the image I compile on FC8 on Ubuntu 9.04 > (with a few library soft-links, > it seems to work fine). The Boost project ship a run.py script which automatically gathers everything, and submits an XML report upstream: http://www.boost.org/development/running_regression_tests.html http://www.boost.org/development/tests/release/developer/summary.html [FreeBSD ref8 is having problems...hmm] It might be good to integrate something like this into the tree, if diverse platform support means the wearing of hats by individuals outside of XORP, Inc. I believe it's realistic that XORP, Inc. may still be able to dedicate some resources to testing on the community branch, although this is more likely to be for their desktop systems, and the embedded targets for the commercial product. Participating in a BuildBot cluster does mean trusting outsiders with your computing resources, having infrastructure, etc. Not ruling out the continued use of BuildBot -- but the Boost community clearly identified that it isn't always possible to sustain cross-platform regression coverage in a community project, so they came up with a good solution -- self-service regression tests... cheers, BMS From greearb at candelatech.com Tue Jul 14 09:44:45 2009 From: greearb at candelatech.com (Ben Greear) Date: Tue, 14 Jul 2009 09:44:45 -0700 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <4A5CAF56.1090401@incunabulum.net> References: <4A5B901C.60102@incunabulum.net> <1247552340.6172.6.camel@blas> <4A5C9706.8010502@candelatech.com> <4A5CAF56.1090401@incunabulum.net> Message-ID: <4A5CB5FD.4020109@candelatech.com> On 07/14/2009 09:16 AM, Bruce Simpson wrote: > Ben, > > Thanks for this. So, are you willing to be platform lead for Fedora? ;-) I'm willing to help, and I'll keep (my) xorp compiling on whatever platforms we're using, but I don't necessarily have time to try to get xorp into official rpms or things like that. > If I had to pin down one Fedora release for XORP community support, > which one would you recommend? The latest (FC 11, currently). If you can get something building rpms for that, it's very likely someone else (perhaps me) can easily get it working on older systems for those who care. I can't necessarily test all releases, but I have lots of different build machines (FC2, FC5, FC8, FC8-64, F11-64, Ubuntu 9.04, etc). Please also understand: I am running fairly heavily patched xorp, and that will be my personal focus. I'll try to get as much of these patches accepted upstream as possible when the public tree opens again, but I'm not sure how much of that will actually be accepted. > The Boost project ship a run.py script which automatically gathers > everything, and submits an XML report upstream: > http://www.boost.org/development/running_regression_tests.html > http://www.boost.org/development/tests/release/developer/summary.html > [FreeBSD ref8 is having problems...hmm] > > It might be good to integrate something like this into the tree, if > diverse platform support means the wearing of hats by individuals > outside of XORP, Inc. I doubt I'd have time to do any significant work on something like this. I think it would be better to see what kind of user reports come in and then concentrate on fixing whatever bugs people find. > I believe it's realistic that XORP, Inc. may still be able to dedicate > some resources to testing on the community branch, although this is more > likely to be for their desktop systems, and the embedded targets for the > commercial product. I'm very interested to know how Xorp plans to handle the public tree v/s whatever else they have going. I see hints that outside developers will be given some sort of commit privileges, but it's my opinion that some Xorp person should be the gatekeeper (much as Linus is for Linux). Otherwise, there may be no one to keep me from dumping all of my virtualization patches upstream, which would obviously be great for me, but perhaps of questionable use for others ;) > Participating in a BuildBot cluster does mean trusting outsiders with > your computing resources, having infrastructure, etc. > Not ruling out the continued use of BuildBot -- but the Boost community > clearly identified that it isn't always possible to sustain > cross-platform regression coverage in a community project, so they came > up with a good solution -- self-service regression tests... If Xorp (.com) has resources to support this, it sounds good, but if not, then I think something minimal will be much better than something complex that is not actually maintained. In my experience, nothing rots faster than automated regression tests and builds. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From irmatov at gmail.com Wed Jul 15 00:13:23 2009 From: irmatov at gmail.com (Timur Irmatov) Date: Wed, 15 Jul 2009 12:13:23 +0500 Subject: [Xorp-users] xorpsh: cannot save configuration Message-ID: <241d382f0907150013y4e742adenebf2490478c7e1b4@mail.gmail.com> Hi, I am new to xorp and facing a problem with saving configuration file. I have installed xorp-1.6 on Debian server into /usr/local/xorp location. I have created xorp group, and started xorp_rtrmgr using command /usr/local/xorp/bin/xorp_rtrmgr -b /usr/local/xorp/etc/config.boot. config.boot file is empty. Then I tried to start xorpsh, but then fail to save configuration to that file: $ sudo -u xorp /bin/xorpsh Welcome to XORP on router xorp at router> configure Entering configuration mode. There are no other users in configuration mode. [edit] xorp at router# save /usr/local/xorp/etc/config.boot ERROR: Save failed. File /usr/local/xorp/etc/config.boot exists, but an error occured when trying to check that it was OK to overwrite it File was NOT overwritten xorp at router# save /usr/local/xorp/etc/config.boot2 Save done. xorp at router# Permissions: $ ls -la /usr/local/xorp/etc total 20 drwxrwsr-x 3 root xorp 40 2009-07-15 12:09 . drwxr-sr-x 19 root staff 4096 2009-07-09 13:10 .. -rw-rw-r-- 1 xorp xorp 0 2009-07-10 12:32 config.boot -rw-rw-r-- 1 xorp xorp 34 2009-07-15 12:09 config.boot2 drwxr-sr-x 2 root staff 4096 2009-07-09 13:10 templates I have searched google, but found nothing. Also I have tried to search for string 'OK to overwrite' in xorp source tree to find out exacty how this 'overwriteability' check is done, but only binaries match. I am puzzled. What am I doing wrong? Any hints are greatly appreciated! -- Timur Irmatov, xmpp:irmatov at jabber.ru From irmatov at gmail.com Wed Jul 15 00:18:10 2009 From: irmatov at gmail.com (Timur Irmatov) Date: Wed, 15 Jul 2009 12:18:10 +0500 Subject: [Xorp-users] xorpsh: cannot save configuration In-Reply-To: <241d382f0907150013y4e742adenebf2490478c7e1b4@mail.gmail.com> References: <241d382f0907150013y4e742adenebf2490478c7e1b4@mail.gmail.com> Message-ID: <241d382f0907150018h34d44cc0nf9a7f262b1d1041f@mail.gmail.com> On Wed, Jul 15, 2009 at 12:13 PM, Timur Irmatov wrote: > I am new to xorp and facing a problem with saving configuration file. > I have installed xorp-1.6 on Debian server into /usr/local/xorp > location. I have created xorp group, and started xorp_rtrmgr using > command /usr/local/xorp/bin/xorp_rtrmgr -b > /usr/local/xorp/etc/config.boot. config.boot file is empty. Then I > tried to start xorpsh, but then fail to save configuration to that > file: Arrgh, quickly after sending an email I have figured out that I wasn't able to overwrite config.boot because it was completely empty. Adding single line: /*XORP Configuration File, v1.0*/ solves the problem. Sorry for the noise. -- Timur Irmatov, xmpp:irmatov at jabber.ru From bms at incunabulum.net Wed Jul 15 12:55:16 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 15 Jul 2009 20:55:16 +0100 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <1247552340.6172.6.camel@blas> References: <4A5B901C.60102@incunabulum.net> <1247552340.6172.6.camel@blas> Message-ID: <4A5E3424.6090904@incunabulum.net> Jaime Nebrera wrote: > Just a humble opinion. Both Linux distributions could be considered a > bit "over the edge". It might be feasible to consider RHEL or CentOS for > those that like more calm life :) > Unfortunately all of the CentOS images I've tried (5.2 preinstalled VDIs, 5.2/5.3 net install ISOs) just hang in VirtualBox for me, even with the usual workarounds. I would give RHEL a try, but there doesn't seem to be much point, given that it's Fedora under the hood anyway -- and their releases seem to be quite old, and it costs $80/pop, or so it says here. It's probably best for me to just focus on Fedora 11 for the moment, and let Ben take care of the other Fedora distros, as he suggests: 'one RPM to rule them all' vs 'you have a build box anyway, right?' [1] As regards ongoing support of the kernel coupling to Linux: this is already mostly taken care of within the source tree, and the APIs/ABIs involved shouldn't change too much. Most of the issues involved in supporting a Linux distribution, on an ongoing basis, would be integration related anyway, which should not tie up too much of someone's time. It's just getting things rolling. If someone is already actively using/participating in a distribution, then that helps a lot. thanks, BMS From bms at incunabulum.net Wed Jul 15 16:45:24 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 00:45:24 +0100 Subject: [Xorp-users] OpenBSD scons breakage Message-ID: <4A5E6A14.2030307@incunabulum.net> Hi all, For all OpenBSD users: the build is broken in the SCons-ified community branch. This is on OpenBSD 5.0 with gcc 3.3.5 out-of-the-box, using scons from ports. Summary: * The header prerequisites are most likely incomplete in a number of places. * Fails check due to incomplete/incorrect prerequisite header list. * Need check on snprintf() in libc. * CLOCK_MONOTONIC is in there; check needs updating. It's a known issue with SCons that the confdefs.h file support, normally handled by the Check*() family of functions, is currently broken -- the file is not generated, therefore manual header prerequisites in xorp/site_scons/config/allconfig.py are needed. This would make dealing with the above issues much easier. Again, fixing the checks shouldn't be too difficult, and please feel free to contact me for advice once the branch re-opens. OpenBSD isn't a tier 1 platform for us, however we're more than happy to welcome a volunteer who can support OpenBSD for XORP on an ongoing basis. The OpenBSD port entry currently lacks a maintainer. thanks, BMS From bms at incunabulum.net Wed Jul 15 16:45:05 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 00:45:05 +0100 Subject: [Xorp-users] NetBSD scons breakage Message-ID: <4A5E6A01.70906@incunabulum.net> Hi all, For all NetBSD users: here is the scons log output from an attempted build with the SCons-ified community branch. This is on NetBSD 5.0 with gcc 4.1.3 out-of-the-box. Note that the SCons version in NetBSD pkgsrc is bitrotted, it will be necessary to manually install SCons for the time being on this platform. Finding and fixing these issues shouldn't be too difficult. %%% scons: Reading SConscript files ... Cross build is False Architecture is i386 Operating System is netbsd Release is public17 Build directory is /root/i386-netbsd-public17 Staging directory is /root/i386-netbsd-public17/stage Checking whether byte ordering is bigendian... (cached) no Checking for C header file stdint.h... (cached) yes Checking for C header file inttypes.h... (cached) yes Checking for C type uint64_t... (cached) yes Checking for C header file stddef.h... (cached) yes Checking for C header file stdarg.h... (cached) yes Checking for C header file stdlib.h... (cached) yes Checking for C header file strings.h... (cached) yes Checking for C header file string.h... (cached) yes Checking for C header file signal.h... (cached) yes Checking for C header file math.h... (cached) yes Checking for C header file memory.h... (cached) yes Checking for C function strftime()... (cached) yes Checking for C function strlcpy()... (cached) yes Checking for C function strlcat()... (cached) yes Checking whether va_copy is declared... (cached) yes Checking for C header file fcntl.h... (cached) yes Checking for C header file getopt.h... (cached) yes Checking for C header file glob.h... (cached) yes Checking for C header file grp.h... (cached) yes Checking for C header file pthread.h... (cached) yes Checking for C header file pwd.h... (cached) yes Checking for C header file mqueue.h... (cached) yes Checking for C header file regex.h... (cached) yes Checking for C header file syslog.h... (cached) yes Checking for C header file termios.h... (cached) yes Checking for C header file time.h... (cached) yes Checking for C header file unistd.h... (cached) yes Checking for C header file vfork.h... (cached) no Checking for C function readv()... (cached) yes Checking for C function strerror()... (cached) yes Checking for C function syslog()... (cached) yes Checking for C function uname()... (cached) yes Checking for C function writev()... (cached) yes Checking for C library xnet... (cached) no Checking for C function recvmsg()... (cached) yes Checking for C function sendmsg()... (cached) yes Checking for C library rt... (cached) yes Checking for C function clock_gettime()... (cached) yes Checking whether CLOCK_MONOTONIC is declared... (cached) yes Checking for C type struct timespec... (cached) yes Checking for C header file paths.h... (cached) yes Checking for C header file sysexits.h... (cached) yes Checking for C function realpath()... (cached) yes Checking for C function strptime()... (cached) yes Checking for C function sysctl()... (cached) yes Checking for C header file netdb.h... (cached) yes Checking for C library resolv... (cached) yes Checking for C function hstrerror()... (cached) yes Checking for C header file sys/cdefs.h... (cached) yes Checking for C header file sys/param.h... (cached) yes Checking for C header file sys/types.h... (cached) yes Checking for C header file sys/utsname.h... (cached) yes Checking for C header file sys/errno.h... (cached) yes Checking for C header file sys/wait.h... (cached) yes Checking for C header file sys/signal.h... (cached) no Checking for C header file sys/time.h... (cached) yes Checking for C header file sys/uio.h... (cached) yes Checking for C header file sys/ioctl.h... (cached) yes Checking for C header file sys/select.h... (cached) yes Checking for C header file sys/socket.h... (cached) yes Checking for C header file sys/sockio.h... (cached) yes Checking for C header file sys/un.h... (cached) yes Checking for C header file sys/mount.h... (cached) yes Checking for C header file sys/resource.h... (cached) yes Checking for C header file sys/stat.h... (cached) yes Checking for C header file sys/syslog.h... (cached) yes Checking for C header file sys/linker.h... (cached) no Checking for C header file sys/sysctl.h... (cached) yes Checking for C header file linux/types.h... (cached) no Checking for C header file linux/sockios.h... (cached) no Checking for C type struct iovec... (cached) yes Checking for C type struct msghdr... (cached) yes Checking for C type struct cmsghdr... (cached) yes Checking whether AF_INET is declared... (cached) yes Checking whether AF_INET6 is declared... (cached) yes Checking whether SOCK_STREAM is declared... (cached) yes Checking whether SOCK_DGRAM is declared... (cached) yes Checking whether SOCK_RAW is declared... (cached) yes Checking whether C type struct msghdr has member msg_control... (cached) yes Checking whether C type struct msghdr has member msg_iov... (cached) yes Checking whether C type struct msghdr has member msg_name... (cached) yes Checking whether C type struct msghdr has member msg_namelen... (cached) yes Checking whether C type struct sockaddr has member sa_len... (cached) yes Checking whether C type struct sockaddr_storage has member ss_len... (cached) yes Checking whether C type struct sockaddr_un has member sun_len... (cached) yes Checking for C header file net/ethernet.h... (cached) no Checking for C header file sys/ethernet.h... (cached) no Checking for C header file net/if.h... (cached) yes Checking for C header file net/if_arp.h... (cached) yes Checking for C header file net/if_dl.h... (cached) yes Checking for C header file net/if_ether.h... (cached) no Checking for C header file net/if_media.h... (cached) yes Checking for C header file net/if_var.h... (cached) no Checking for C header file net/if_types.h... (cached) yes Checking for C header file net/route.h... (cached) yes Checking for C header file ifaddrs.h... (cached) yes Checking for C header file stropts.h... (cached) no Checking for C header file linux/ethtool.h... (cached) no Checking for C header file linux/if_tun.h... (cached) no Checking for C header file linux/netlink.h... (cached) no Checking for C header file linux/rtnetlink.h... (cached) no Checking whether C type struct sockaddr_dl has member sdl_len... (cached) yes Checking whether C type struct ifreq has member ifr_hwaddr... (cached) no Checking whether C type struct ifreq has member ifr_ifindex... (cached) no Checking for C function ether_aton()... (cached) yes Checking for C function ether_aton_r()... (cached) no Checking for C function ether_ntoa()... (cached) yes Checking for C function ether_ntoa_r()... (cached) no Checking for C function getaddrinfo()... (cached) yes Checking for C function getifaddrs()... (cached) yes Checking for C function getnameinfo()... (cached) yes Checking for C function if_indextoname()... (cached) yes Checking for C function if_nametoindex()... (cached) yes Checking for C function inet_ntop()... (cached) yes Checking for C function inet_pton()... (cached) yes Checking for C type struct ether_addr... (cached) no Checking whether system has sysctl NET_RT_DUMP... (cached) yes Checking whether system has sysctl NET_RT_IFLIST... (cached) yes Checking whether SIOCGIFCONF is declared... (cached) yes Checking for C header file netinet/in.h... (cached) yes Checking for C header file netinet/in_systm.h... (cached) yes Checking for C header file netinet/in_var.h... (cached) no Checking for C header file netinet/ip.h... (cached) no Checking for C header file netinet/tcp.h... (cached) yes Checking for C header file netinet/igmp.h... (cached) yes Checking for C header file netinet/ether.h... (cached) no Checking for C header file netinet/if_ether.h... (cached) no Checking for C header file inet/nd.h... (cached) no Checking for C header file inet/ip.h... (cached) no Checking for C header file arpa/inet.h... (cached) yes Checking for C header file arpa/telnet.h... (cached) yes Checking whether C type struct sockaddr_in has member sin_len... (cached) yes Checking whether IP_MULTICAST_IF is declared... (cached) yes Checking whether IP_MULTICAST_TTL is declared... (cached) yes Checking whether IP_MULTICAST_LOOP is declared... (cached) yes Checking whether IP_ADD_MEMBERSHIP is declared... (cached) yes Checking whether IP_DROP_MEMBERSHIP is declared... (cached) yes Checking whether system has sysctl IPCTL_FORWARDING... (cached) yes Checking whether __KAME__ is declared... (cached) yes Checking whether inet6_opt_init is declared... (cached) yes Checking whether C type struct sockaddr_in6 has member sin6_len... (cached) yes Checking whether C type struct sockaddr_in6 has member sin6_scope_id... (cached) yes Checking for C header file netinet/ip6.h... (cached) yes Checking for C header file netinet/icmp6.h... (cached) yes Checking for C type struct mld_hdr... (cached) yes Checking for C header file netinet6/ip6_var.h... (cached) yes Checking for C header file netinet6/in6_var.h... (cached) no Checking for C header file netinet6/nd6.h... (cached) no Checking for C++ header file netinet6/nd6.h... (cached) no Checking whether system has sysctl IPV6CTL_FORWARDING... (cached) yes Checking whether system has sysctl IPV6CTL_ACCEPT_RTADV... (cached) yes Checking for C header file netinet/ip_mroute.h... (cached) no Checking for C header file net/ip_mroute/ip_mroute.h... (cached) no Checking for C header file linux/mroute.h... (cached) no Checking for C type struct mfcctl2... (cached) no Checking whether C type struct mfcctl2 has member mfcc_flags... (cached) no Checking whether C type struct mfcctl2 has member mfcc_rp... (cached) no Checking for C header file netinet/pim.h... (cached) yes Checking for C type struct pim... (cached) yes Checking whether C type struct pim has member pim_vt... (cached) no Checking for C header file netinet6/ip6_mroute.h... (cached) no Checking for C header file linux/mroute6.h... (cached) no Checking for C type struct mf6cctl2... (cached) no Checking whether C type struct mf6cctl2 has member mf6cc_flags... (cached) no Checking whether C type struct mf6cctl2 has member mf6cc_rp... (cached) no Checking for C header file netinet/ip_compat.h... (cached) yes Checking for C header file netinet/ip_fil.h... (cached) no Checking for C header file netinet/ip_fw.h... (cached) no Checking for C header file net/pfvar.h... (cached) no Checking for C++ header file linux/netfilter_ipv4/ip_tables.h... (cached) no Checking for C++ header file linux/netfilter_ipv6/ip6_tables.h... (cached) no Checking for C header file net/if_vlanvar.h... (cached) no Checking for C header file net/if_vlan_var.h... (cached) no Checking for C header file net/vlan/if_vlan_var.h... (cached) no Checking for C header file linux/if_vlan.h... (cached) no Checking for C header file pcre.h... (cached) no Checking for C header file pcreposix.h... (cached) no Checking for C library pcre... (cached) no Checking for C library pcreposix... (cached) no Checking for C header file openssl/md5.h... (cached) yes Checking for C library crypto... (cached) yes Checking for C function MD5_Init()... (cached) yes Checking for C header file dlfcn.h... (cached) yes Checking for C library dl... (cached) no Checking for C function dlopen()... (cached) yes Checking for C header file pcap.h... (cached) yes Checking for C library pcap... (cached) yes Checking for C function pcap_sendpacket()... (cached) yes scons: done reading SConscript files. scons: Building targets ... g++ -o /root/i386-netbsd-public17/libxipc/sockutil.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/libxipc/sockutil.cc cc1plus: warnings being treated as errors /root/i386-netbsd-public17/libxipc/sockutil.cc: In function 'void get_active_ipv4_addrs(std::vector >&)': /root/i386-netbsd-public17/libxipc/sockutil.cc:308: warning: deleting 'void*' is undefined /root/i386-netbsd-public17/libxipc/sockutil.cc:314: warning: deleting 'void*' is undefined /root/i386-netbsd-public17/libxipc/sockutil.cc:331: warning: deleting 'void*' is undefined scons: *** [/root/i386-netbsd-public17/libxipc/sockutil.os] Error 1 g++ -o /root/i386-netbsd-public17/libxorp/mac.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. /root/i386-netbsd-public17/libxorp/mac.cc /root/i386-netbsd-public17/libxorp/mac.cc: In member function 'size_t Mac::copy_in(const char*)': /root/i386-netbsd-public17/libxorp/mac.cc:129: error: 'ether_aton' was not declared in this scope /root/i386-netbsd-public17/libxorp/mac.cc: In member function 'std::string Mac::str() const': /root/i386-netbsd-public17/libxorp/mac.cc:176: error: 'ether_ntoa' was not declared in this scope scons: *** [/root/i386-netbsd-public17/libxorp/mac.os] Error 1 scons: `/root/i386-netbsd-public17/libfeaclient/libfeaclient.so' is up to date. g++ -o /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc cc1plus: warnings being treated as errors /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc: In member function 'int IfConfigGetIoctl::read_config(IfTree&)': /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc:162: warning: deleting 'void*' is undefined /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc:176: warning: deleting 'void*' is undefined /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc: In function 'bool ioctl_read_ifconf(int, ifconf*)': /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc:212: warning: deleting 'void*' is undefined /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc:218: warning: deleting 'void*' is undefined scons: *** [/root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_get_ioctl.os] Error 1 g++ -o /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc: In member function 'int IfConfigSetIoctl::add_addr(const std::string&, const std::string&, __uint32_t, const IPv4&, __uint32_t, bool, const IPv4&, bool, const IPv4&, std::string&)': /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc:733: error: aggregate 'in_aliasreq ifra' has incomplete type and cannot be defined /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc: In member function 'int IfConfigSetIoctl::add_addr(const std::string&, const std::string&, __uint32_t, const IPv6&, __uint32_t, bool, const IPv6&, std::string&)': /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc:963: error: aggregate 'in6_ifreq in6_ifreq' has incomplete type and cannot be defined scons: *** [/root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.os] Error 1 g++ -o /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc: In member function 'int IfConfigVlanGetBsd::read_config(IfTree&)': /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc:157: error: aggregate 'vlanreq vlanreq' has incomplete type and cannot be defined /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc:165: error: 'SIOCGETVLAN' was not declared in this scope scons: *** [/root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.os] Error 1 g++ -o /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc: In member function 'int IfConfigVlanSetBsd::add_vlan(const std::string&, const std::string&, __uint16_t, std::string&)': /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:205: error: aggregate 'vlanreq vlanreq' has incomplete type and cannot be defined /root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:299: error: 'SIOCSETVLAN' was not declared in this scope scons: *** [/root/i386-netbsd-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.os] Error 1 scons: `/root/i386-netbsd-public17/fea/data_plane/firewall/libxorp_firewall.so' is up to date. scons: `/root/i386-netbsd-public17/fea/data_plane/fibconfig/libxorp_fibconfig.so' is up to date. g++ -o /root/i386-netbsd-public17/fea/data_plane/io/io_ip_socket.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/fea/data_plane/io/io_ip_socket.cc /root/i386-netbsd-public17/fea/data_plane/io/io_ip_socket.cc: In member function 'virtual int IoIpSocket::send_packet(const std::string&, const std::string&, const IPvX&, const IPvX&, __int32_t, __int32_t, bool, bool, const std::vector >&, const std::vector >, std::allocator > > >&, const std::vector >&, std::string&)': /root/i386-netbsd-public17/fea/data_plane/io/io_ip_socket.cc:2115: error: 'IPVERSION' was not declared in this scope scons: *** [/root/i386-netbsd-public17/fea/data_plane/io/io_ip_socket.os] Error 1 g++ -o /root/i386-netbsd-public17/fea/data_plane/control_socket/click_socket.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/fea/data_plane/control_socket/click_socket.cc /usr/include/sys/mount.h: In member function 'int ClickSocket::mount_click_file_system(std::string&)': /usr/include/sys/mount.h:436: error: too few arguments to function 'int mount(const char*, const char*, int, void*, size_t)' /root/i386-netbsd-public17/fea/data_plane/control_socket/click_socket.cc:741: error: at this point in file scons: *** [/root/i386-netbsd-public17/fea/data_plane/control_socket/click_socket.os] Error 1 scons: `/root/i386-netbsd-public17/fea/data_plane/managers/libxorp_data_plane_managers.so' is up to date. scons: `/root/i386-netbsd-public17/mrt/libmrt.so' is up to date. g++ -o /root/i386-netbsd-public17/fea/fea_node.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/fea/fea_node.cc /root/i386-netbsd-public17/fea/fea_node.cc:280:2: error: #error "No data plane manager to load: unknown system" scons: *** [/root/i386-netbsd-public17/fea/fea_node.os] Error 1 g++ -o /root/i386-netbsd-public17/ospf/peer.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/ospf/peer.cc /root/i386-netbsd-public17/ospf/peer.cc: In member function '__uint16_t PeerOut::get_frame_size() const [with A = IPv4]': /root/i386-netbsd-public17/ospf/peer.cc:5500: instantiated from here /root/i386-netbsd-public17/ospf/peer.cc:172: error: invalid application of 'sizeof' to incomplete type 'ip' /root/i386-netbsd-public17/ospf/peer.cc:173: error: invalid application of 'sizeof' to incomplete type 'ip' /root/i386-netbsd-public17/ospf/peer.cc:173: error: invalid application of 'sizeof' to incomplete type 'ip' /root/i386-netbsd-public17/ospf/peer.cc:173: error: duplicate case value /root/i386-netbsd-public17/ospf/peer.cc:173: error: previously used here /root/i386-netbsd-public17/ospf/peer.cc: In member function '__uint16_t PeerOut::get_frame_size() const [with A = IPv6]': /root/i386-netbsd-public17/ospf/peer.cc:5501: instantiated from here /root/i386-netbsd-public17/ospf/peer.cc:172: error: invalid application of 'sizeof' to incomplete type 'ip' /root/i386-netbsd-public17/ospf/peer.cc:173: error: invalid application of 'sizeof' to incomplete type 'ip' /root/i386-netbsd-public17/ospf/peer.cc:173: error: invalid application of 'sizeof' to incomplete type 'ip' /root/i386-netbsd-public17/ospf/peer.cc:173: error: duplicate case value /root/i386-netbsd-public17/ospf/peer.cc:173: error: previously used here scons: *** [/root/i386-netbsd-public17/ospf/peer.os] Error 1 g++ -o /root/i386-netbsd-public17/pim/pim_proto_join_prune_message.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/pim/pim_proto_join_prune_message.cc /root/i386-netbsd-public17/pim/pim_proto_join_prune_message.cc: In member function 'int PimJpHeader::network_commit(PimVif*, const IPvX&, std::string&)': /root/i386-netbsd-public17/pim/pim_proto_join_prune_message.cc:715: error: 'IP_MAXPACKET' was not declared in this scope /root/i386-netbsd-public17/pim/pim_proto_join_prune_message.cc:715: error: invalid application of 'sizeof' to incomplete type 'ip' scons: *** [/root/i386-netbsd-public17/pim/pim_proto_join_prune_message.os] Error 1 g++ -o /root/i386-netbsd-public17/pim/pim_vif.os -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i386-netbsd-public17 /root/i386-netbsd-public17/pim/pim_vif.cc /root/i386-netbsd-public17/pim/pim_vif.cc: In member function 'int PimVif::pim_send(const IPvX&, const IPvX&, __uint8_t, buffer_t*, std::string&)': /root/i386-netbsd-public17/pim/pim_vif.cc:653: error: aggregate 'ip ip4_header' has incomplete type and cannot be defined scons: *** [/root/i386-netbsd-public17/pim/pim_vif.os] Error 1 scons: `/root/i386-netbsd-public17/policy/libpolicy.so' is up to date. scons: `/root/i386-netbsd-public17/bgp/libbgp.a' is up to date. scons: done building targets (errors occurred during build). %%% thanks, BMS From bms at incunabulum.net Wed Jul 15 17:25:43 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 01:25:43 +0100 Subject: [Xorp-users] SCons prerequisites for Linux targets Message-ID: <4A5E7387.6040501@incunabulum.net> Hi all, So, I have just removed GNU autotools in my private copy of the community XORP branch, and replaced it with SCons. Here's a summary of what's needed: [1] Building from source under ubuntu 9.04 desktop: # apt-get install libncurses5-dev g++ libssl-dev libpcre3-dev libpcap-dev scons Building from source under ubuntu 8.10 server: # apt-get install libncurses5-dev g++ libssl-dev libpcre3-dev libpcap-dev * SCons must be installed manually on this platform. Building from source under Fedora 11: [2] # yum install libpcap-devel # yum install scons cheers, BMS [1] I'm thinking we need a wiki for this sort of information. [2] Ben: I have axed #ident and sprinkled const_cast<> in the right places for GCC 4.4.0, for now. From bms at incunabulum.net Wed Jul 15 17:32:24 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 01:32:24 +0100 Subject: [Xorp-users] Move docs/ into own repo subdirectory Message-ID: <4A5E7518.6060004@incunabulum.net> Hi, I'd like to move docs/ out of the xorp/ source directory, and into its own part of the repo. Any objections? The reasoning behind the change: the docs directory contains a number of large document files, which are normally only updated when a point release is being rolled. Whilst it could be argued that keeping docs/ in the same place as the source is likely to encourage developers to update it, in practice, this makes little difference. It doesn't seem right to force users (or distributors) to download megabytes of data needlessly -- it also considerably slows down CVS and SVN checkouts because of the sheer size of the files. This is just my experience / opinion. So I would propose moving them further up. Distributions can then take another tarball, xorp-docs, if they need it. This just plain makes it easier on distributions and makes it easier to get XORP shipped e.g. in Fedora or Ubuntu. What say you all? thanks, BMS From greearb at candelatech.com Wed Jul 15 19:10:05 2009 From: greearb at candelatech.com (Ben Greear) Date: Wed, 15 Jul 2009 19:10:05 -0700 Subject: [Xorp-users] Move docs/ into own repo subdirectory In-Reply-To: <4A5E7518.6060004@incunabulum.net> References: <4A5E7518.6060004@incunabulum.net> Message-ID: <4A5E8BFD.4030704@candelatech.com> Bruce Simpson wrote: > Hi, > > I'd like to move docs/ out of the xorp/ source directory, and into its > own part of the repo. Any objections? > > The reasoning behind the change: the docs directory contains a > number of large document files, which are normally only updated when a > point release is being rolled. Whilst it could be argued that keeping > docs/ in the same place as the source is likely to encourage developers > to update it, in practice, this makes little difference. > > It doesn't seem right to force users (or distributors) to download > megabytes of data needlessly -- it also considerably slows down CVS and > SVN checkouts because of the sheer size of the files. This is just my > experience / opinion. > > So I would propose moving them further up. Distributions can then > take another tarball, xorp-docs, if they need it. This just plain makes > it easier on distributions and makes it easier to get XORP shipped e.g. > in Fedora or Ubuntu. > > What say you all? > Are the big files auto-generated from smaller source? If so, how about we just don't include the generated files in cvs/svn/whatever and let users build them if they want them. (Compiled packages could include the generated files, of course.) Thanks, Ben > thanks, > BMS > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Jul 15 19:12:47 2009 From: greearb at candelatech.com (Ben Greear) Date: Wed, 15 Jul 2009 19:12:47 -0700 Subject: [Xorp-users] SCons prerequisites for Linux targets In-Reply-To: <4A5E7387.6040501@incunabulum.net> References: <4A5E7387.6040501@incunabulum.net> Message-ID: <4A5E8C9F.9060900@candelatech.com> Bruce Simpson wrote: > Hi all, > > So, I have just removed GNU autotools in my private copy of the > community XORP branch, and replaced it with SCons. > > Here's a summary of what's needed: [1] > > Building from source under ubuntu 9.04 desktop: > # apt-get install libncurses5-dev g++ libssl-dev libpcre3-dev > libpcap-dev scons > > Building from source under ubuntu 8.10 server: > # apt-get install libncurses5-dev g++ libssl-dev libpcre3-dev > libpcap-dev > * SCons must be installed manually on this platform. > > Building from source under Fedora 11: [2] > # yum install libpcap-devel > # yum install scons > > cheers, > BMS > > [1] I'm thinking we need a wiki for this sort of information. > [2] Ben: I have axed #ident and sprinkled const_cast<> in the right > places for GCC 4.4.0, for now. > Sounds good. Hope you have better luck keeping spammers out of your wiki than we did :P A simple README_BUILD.txt would probably suffice as well. Ben > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From irmatov at gmail.com Wed Jul 15 23:36:52 2009 From: irmatov at gmail.com (Timur Irmatov) Date: Thu, 16 Jul 2009 11:36:52 +0500 Subject: [Xorp-users] simple xorp configuration Message-ID: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> Hi, I have successfully installed xorp and get it running. Configuration is almost empty: /*XORP Configuration File, v1.0*/ fea { unicast-forwarding4 { disable: false } unicast-forwarding6 { disable: true } } interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "" disable: false discard: false unreachable: false management: false } } When I start xorp_rtrmgr, I see two processes running: xorp_rtrmgr and xorp_fea. Then I just try to add vlan interface (this interfaces does not exits in the system at the moment): set vif eth0.333 vlan vlan-id 333 When I try to commit, I get a message that commit failed. # commit Commit Failed Reconfig of process caused process to fail.[edit] I see following in logs: Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 FATAL xorp_fea:8700 FEA +1607 iftree.cc insert_ifindex ] Assertion (iter->second == ifp) failed Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 ERROR xorp_rtrmgr:8699 RTRMGR +754 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 6. Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 INFO xorp_rtrmgr:8699 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: fea Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 INFO xorp_rtrmgr:8699 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: firewall Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 INFO xorp_rtrmgr:8699 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: interfaces Jul 16 11:30:20 router xorp_rtrmgr: [ 2009/07/16 11:30:20 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:21 router xorp_rtrmgr: [ 2009/07/16 11:30:21 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:22 router xorp_rtrmgr: [ 2009/07/16 11:30:22 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:23 router xorp_rtrmgr: [ 2009/07/16 11:30:23 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:24 router xorp_rtrmgr: [ 2009/07/16 11:30:24 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:25 router xorp_rtrmgr: [ 2009/07/16 11:30:25 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:26 router xorp_rtrmgr: [ 2009/07/16 11:30:26 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:27 router xorp_rtrmgr: [ 2009/07/16 11:30:27 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:28 router xorp_rtrmgr: [ 2009/07/16 11:30:28 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:29 router xorp_rtrmgr: [ 2009/07/16 11:30:29 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:30 router xorp_rtrmgr: [ 2009/07/16 11:30:30 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:31 router xorp_rtrmgr: [ 2009/07/16 11:30:31 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:32 router xorp_rtrmgr: [ 2009/07/16 11:30:32 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:33 router xorp_rtrmgr: [ 2009/07/16 11:30:33 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:34 router xorp_rtrmgr: [ 2009/07/16 11:30:34 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:35 router xorp_rtrmgr: [ 2009/07/16 11:30:35 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:36 router xorp_rtrmgr: [ 2009/07/16 11:30:36 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:38 router xorp_rtrmgr: [ 2009/07/16 11:30:38 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:39 router xorp_rtrmgr: [ 2009/07/16 11:30:39 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:40 router xorp_rtrmgr: [ 2009/07/16 11:30:40 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:41 router xorp_rtrmgr: [ 2009/07/16 11:30:41 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:42 router xorp_rtrmgr: [ 2009/07/16 11:30:42 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:43 router xorp_rtrmgr: [ 2009/07/16 11:30:43 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:44 router xorp_rtrmgr: [ 2009/07/16 11:30:44 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:45 router xorp_rtrmgr: [ 2009/07/16 11:30:45 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:46 router xorp_rtrmgr: [ 2009/07/16 11:30:46 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:47 router xorp_rtrmgr: [ 2009/07/16 11:30:47 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:48 router xorp_rtrmgr: [ 2009/07/16 11:30:48 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:49 router xorp_rtrmgr: [ 2009/07/16 11:30:49 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:50 router xorp_rtrmgr: [ 2009/07/16 11:30:50 WARNING xorp_rtrmgr:8699 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. Jul 16 11:30:50 router xorp_rtrmgr: [ 2009/07/16 11:30:50 ERROR xorp_rtrmgr:8699 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: Reconfig of process caused process to fail. At the end I see that eth0.333 interface is created in the system, and I don't see xorp_fea process anymore. What is the problem? System is Debian GNU/Linux, etch (oldstable), kernel 2.6.18, gcc-4.1.1. After compilation I did a 'make check' and I don't see any FAIL lines in output. -- Timur Irmatov, xmpp:irmatov at jabber.ru From bms at incunabulum.net Thu Jul 16 05:23:42 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 13:23:42 +0100 Subject: [Xorp-users] [Xorp-feedback] Hi In-Reply-To: References: Message-ID: <4A5F1BCE.8070707@incunabulum.net> Batgirl Ann wrote: > > The problem I have is: I don?t what OS is better to run the XORP on > (Linux, BSD, windows server 2003) so I would like you to sugest me > which one is better, also I wanted to know an easyer way to download > the code and documentation because i really find it a little hard to > click the links and open a bunch of tabs to download the code peace by > peace, or maybe I haven?t the correct link on your page. Whilst we're very grateful that you are considering working on XORP, you should be aware that XORP is going through a period of radical change at the moment. Implementing a graphical interface for XORP, with one of the community releases, would require an in-depth knowledge of C++. It is also highly probable that, if you started work on a graphical interface for an older release now, we would not be able to accept it as a contribution, as the system interfaces involved are definitely going to change. The last community release was version 1.6. Out of all of the platforms XORP supports, FreeBSD is probably your best choice for the previous community releases, as that was the main development platform. We are certainly not going to abandon FreeBSD, however, the reality of the situation is that many organisations which have an interest in XORP, are using some flavor of Linux. So there realistically has to be a support model in place, to focus on delivering something which works well, where it works. XORP should compile out of the box on most Linux systems. There is an Ubuntu/Debian binary package of the 1.5 release. You should be able to download the source tarball here: http://www.xorp.org/releases/1.6/xorp-1.6.tar.gz You can install XORP 1.6 as a FreeBSD port, which will download the source for you automatically. More information is available at this link: http://www.freshports.org/net/xorp/ As for the documentation -- you're right, there is no easy way of downloading all the documentation, in PDF format, or otherwise browing it. That is further down the task list. thanks, BMS From bms at incunabulum.net Thu Jul 16 05:36:21 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 13:36:21 +0100 Subject: [Xorp-users] Move docs/ into own repo subdirectory In-Reply-To: <4A5E8BFD.4030704@candelatech.com> References: <4A5E7518.6060004@incunabulum.net> <4A5E8BFD.4030704@candelatech.com> Message-ID: <4A5F1EC5.4090503@incunabulum.net> Ben Greear wrote: > Are the big files auto-generated from smaller source? If so, how > about we just don't > include the generated files in cvs/svn/whatever and let users build > them if they > want them. (Compiled packages could include the generated files, of > course.) * Ironically enough, we just got a feedback@ response from someone who's had problems downloading the documentation... my reply I have Cc'd to the list here. * The problem is not so much the fact that there are huge files, but the fact that a lot of this stuff is static content, which is of academic and background interest, being shipped around with the code, even though it's not actually used for a build. * The toolchain needed is significantly different, also. * Ubuntu/Debian ship XORP's documentation in a separate binary package. * It's not something that we can just hand-off to folk, and expect them to just pick up and start hacking, in its current state. Which is why it has to change. Whoah, that's 5 points in favour. I think that seals the fate of docs/ for me, I am going to move it out of the source. devnotes/ can stay for the time being. On an orthogonal note: kdoc needs to fall under the axe also. Doxygen was already implemented for the XORP/OLSR stack, as the client specifically requested it. I have tweaks for Doxygen under contrib/olsr/[D]oxy* for anyone who cares to look. cheers, BMS From bms at incunabulum.net Thu Jul 16 05:44:48 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 13:44:48 +0100 Subject: [Xorp-users] simple xorp configuration In-Reply-To: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> References: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> Message-ID: <4A5F20C0.7090006@incunabulum.net> Hi, Sorry for the delay in responding to your question. As you can probably tell, the project is in a state of change at the moment, this is going to affect community support for some time. I haven't been directly involved in the vlan code, perhaps someone else on the list is more familiar with this than I am, so I am afraid I can only offer very general pointers, as I'm currently tied up elsewhere. Timur Irmatov wrote: > When I start xorp_rtrmgr, I see two processes running: xorp_rtrmgr and > xorp_fea. Then I just try to add vlan interface (this interfaces does > not exits in the system at the moment): > > set vif eth0.333 vlan vlan-id 333 > > When I try to commit, I get a message that commit failed. > > # commit > Commit Failed > Reconfig of process caused process to fail.[edit] > > I see following in logs: > > Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 FATAL > xorp_fea:8700 FEA +1607 iftree.cc insert_ifindex ] Assertion > (iter->second == ifp) failed > Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 ERROR > xorp_rtrmgr:8699 RTRMGR +754 module_manager.cc done_cb ] Command > "/usr/local/xorp/fea/xorp_fea": terminated with signal 6. > Did you look at fea/iftree.cc line 1607? This assertion looks as though it's being triggered because you have more than one interface with the same interface index in this system. XORP's FEA will use the interface index as the primary key for learning about network interfaces in the system. I took a quick look on bugzilla.xorp.org and couldn't see anything about this, so I'm assuming it isn't a bug, for now. Have you tried creating the VLAN interface from outside of XORP? Do you see similar errors? This sounds similar to stuff other folk ran into, and the workaround was simple, off the top of my head, try the list archives. cheers, BMS From bms at incunabulum.net Thu Jul 16 06:13:42 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 14:13:42 +0100 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <4A5CB5FD.4020109@candelatech.com> References: <4A5B901C.60102@incunabulum.net> <1247552340.6172.6.camel@blas> <4A5C9706.8010502@candelatech.com> <4A5CAF56.1090401@incunabulum.net> <4A5CB5FD.4020109@candelatech.com> Message-ID: <4A5F2786.6050909@incunabulum.net> Ben Greear wrote: >> If I had to pin down one Fedora release for XORP community support, >> which one would you recommend? > > The latest (FC 11, currently). If you can get something building rpms > for that, it's very likely someone else (perhaps me) can easily get it > working on > older systems for those who care. OK. Fedora 11 it is. XORP's SCONS build seems to compile there. There is no regression test coverage at the moment. [Given there have been no functional changes to the code -- just the build system -- I am not going to be losing any sleep over having no regression test coverage.] > I can't necessarily test all releases, > but I have lots of different build machines (FC2, FC5, FC8, FC8-64, > F11-64, > buntu 9.04, etc). Ubuntu 9.04 I've touched. > > Please also understand: I am running fairly heavily patched xorp, and > that will be my personal focus. I'll try to get as much of these > patches accepted > upstream as possible when the public tree opens again, but I'm not sure > how much of that will actually be accepted. OK. Will need to consider on case-by-case basis. It's likely that the approach to a lot of stuff there will change radically. > >> The Boost project ship a run.py script which automatically gathers >> everything, and submits an XML report upstream: >> > > I doubt I'd have time to do any significant work on something like this. > > I think it would be better to see what kind of user reports come in > and then concentrate on fixing whatever bugs people find. As you can see from the traffic we get from this list, most of the queries are pretty basic, or concern problems configuring essential /basic features. I don't really have free time/energy to delve into every detail of what they run into at the moment, *and* fix what I'm trying to fix elsewhere, sadly. My hope would be that we could get folk within XORP, Inc. to play more of a role in this, say 1 hour on a Friday afternoon 'doing' community work, but of course this involves breathing life back into the community branch. One big concern of mine is that we get a lot of people wanting to use XORP, who have no clue about hacking C++ (And why should they...arguments abound), and either don't want to learn, or don't have time to. It is a hard tool to use, and hopefully, sorting out the middle tier will help. I need to stay focused on that goal. There's knowledge locked up in the minds of the original development team 'oh this assertion means that, etc'. which is pretty essential to debugging these issues. If I weren't hacking SVN and SCons* files, and setting up VMs like a mad axeman this week, I might have more time to deal with these issues... > > I'm very interested to know how Xorp plans to handle the public tree > v/s whatever else they have going. At the moment, our hands are tied. We're waiting for the legal dust to settle. I am working flat out to get GNU autotools axed and some sort of sanity into community releases. > I see hints that outside developers > will be given some sort of commit privileges, but it's my opinion that > some Xorp person should be the gatekeeper (much as Linus is for Linux). It's pretty much essential -- the XORP C++ code can be impenetrable to those who haven't spent years studying it. This should NOT be the case. The problem is that having one person as that gatekeeper effectively overloads them, and makes it difficult for them to do other stuff, if that's all they're doing. One of my hopes with Thrift + Boost is that we can lower the bar to entry in the XORP development community. It's 2009, we understand protocols need to run fast and be tightly coupled to the kernel, for embedded use. But it's feasible to embed scripting languages now -- it just depends how tightly you define 'embedded', embedded for what? For what it's worth, Macromedia had a similar situation on their hands with Flash and Shockwave. Those are also moderately large C++ systems. Folk from that org I've spoken to say it takes 12-18 months to get proficient in their code base. > > Otherwise, there may be no one to keep me from dumping all of my > virtualization patches upstream, which would obviously be great for me, > but perhaps of questionable use for others ;) Features are cool, but they need a test framework, especially if radical in nature. > In my experience, nothing rots faster than > automated regression tests and builds. They can also cry wolf, and are easy to ignore. cheers, BMS From bms at incunabulum.net Thu Jul 16 06:14:59 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 14:14:59 +0100 Subject: [Xorp-users] error when plumbing starting In-Reply-To: <1247238635.2925.44.camel@nazghul> References: <1247238635.2925.44.camel@nazghul> Message-ID: <4A5F27D3.20406@incunabulum.net> Michal Kr?sa wrote: > Hi all, > I have a problem with configuring multicast routing on xorp (i've > tested 1.6 and 1.5 version). > When I try to add an interface to section plumbing - mfea4, got a > following error: > > when i running multicast4.boot from doc files by typing > "xorp_rtrmgr -b multicast4.boot" in terminal: > > [ 2009/07/10 16:45:50 FATAL xorp_fea:28921 MFEA +539 mfea_node.cc > vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed > [ 2009/07/10 16:45:50 ERROR xorp_rtrmgr:28920 RTRMGR +754 > module_manager.cc done_cb ] Command > "/usr/local/xorp/fea/xorp_fea": terminated with signal 6 > Did you copy and edit multicast4.boot? It contains FreeBSD specific interface names. .... > > If i prepare simple config with interface eth0 as system-default > and run xorp_rtrmgr, everything is ok. But when login to console > by xorpsh and try to configure plumbing, but on commit get error: > > Welcome to XORP on trois > root at trois> configure > Entering configuration mode. > There are no other users in configuration mode. > [edit] > root at trois# set plumbing mfea4 disable false > [edit] > root at trois# commit > [ 2009/07/10 16:55:05 INFO xorp_rtrmgr:29862 RTRMGR +101 > module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) > [ 2009/07/10 16:55:05 FATAL xorp_fea:29863 MFEA +539 mfea_node.cc > vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed > ^^^^^ this is the key log line. The MFEA is getting confused because it sees an interface it doesn't know about there. Are you able to run other multicast routing daemons on this box? It sounds as though you just need to edit the multicast4.boot example for your own system. I'm afraid I can't be of further help with this issue at the moment. thanks, BMS From bms at incunabulum.net Thu Jul 16 06:21:13 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 14:21:13 +0100 Subject: [Xorp-users] Basic Setup Problems In-Reply-To: References: Message-ID: <4A5F2949.8050907@incunabulum.net> Robert, Sorry for the very brief reply, I am very tied up at the moment. Robert Appleton wrote: > interfaces { > restore-original-config-on-shutdown: false > interface "eth0" { > disable: false > address 192.168.1.1 { > prefix-length: 24 > broadcast: 192.168.1.255 > disable: false > } > } > > interface "eth0" { > disable: false > address 192.168.2.1 { > prefix-length: 24 > broadcast: 192.168.1.255 > disable: false > } > ^^^ usually address {} blocks for the same interface are grouped in the same interface {} block; you are missing a vif eth0 {} inner scope. > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > static { > route 192.168.2.1/24 { > ^^^^ the .1 here will be masked off by the /24 -- and ignored > next-hop: 192.168.2.120 > } > > route 192.168.1.1/24 { > ^^^^ the .1 here will be masked off by the /24 -- and ignored > next-hop: 192.168.1.110 > } > ^^ both these route prefixes will already be covered by the interface routes in your interfaces {} block. The static {} block above looks unnecessary. If you delete it, what happens? From greearb at candelatech.com Thu Jul 16 09:45:43 2009 From: greearb at candelatech.com (Ben Greear) Date: Thu, 16 Jul 2009 09:45:43 -0700 Subject: [Xorp-users] Call for feedback/volunteers: Build system, platform tier support. In-Reply-To: <4A5F2786.6050909@incunabulum.net> References: <4A5B901C.60102@incunabulum.net> <1247552340.6172.6.camel@blas> <4A5C9706.8010502@candelatech.com> <4A5CAF56.1090401@incunabulum.net> <4A5CB5FD.4020109@candelatech.com> <4A5F2786.6050909@incunabulum.net> Message-ID: <4A5F5937.9060000@candelatech.com> On 07/16/2009 06:13 AM, Bruce Simpson wrote: > One big concern of mine is that we get a lot of people wanting to use > XORP, who have no clue about hacking C++ (And why should > they...arguments abound), and either don't want to learn, or don't have > time to. It is a hard tool to use, and hopefully, sorting out the middle > tier will help. I need to stay focused on that goal. They shouldn't need to know anything about c++ to use it, only to hack on it. For me, the biggest problem was figuring out the code paths since you have interprocess communication through an opaque middle layer. There is little you can grep for or otherwise follow in order to see what calls go where. After several years, I have less trouble. Not every project can be simple, an a distributed multi-process router daemon might just be one of those that will always be a bit tricky :) > There's knowledge locked up in the minds of the original development > team 'oh this assertion means that, etc'. which is pretty essential to > debugging these issues. The more asserts that are removed (replaced with better error handling and/or detailed error messages to the users) the better, as far as I'm concerned. >> I see hints that outside developers >> will be given some sort of commit privileges, but it's my opinion that >> some Xorp person should be the gatekeeper (much as Linus is for Linux). > > It's pretty much essential -- the XORP C++ code can be impenetrable to > those who haven't spent years studying it. This should NOT be the case. > > The problem is that having one person as that gatekeeper effectively > overloads them, and makes it difficult for them to do other stuff, if > that's all they're doing. That is true. If Xorp.com wants to harness the energy of the community, the cost is likely going to be paying a very good engineer to act as gatekeeper and integrator. If xorp.com is going to use the community tree similar to how RedHat uses Fedora, then it is beneficial to have good engineers hacking on it, with the idea that the stable code will be integrated into xorp's commercial offerings. If they are not going to put any energy into it, then the first person that cares will probably fork it. Since the code is GPL, it seems xorp.com has nothing to gain by letting the community branch hang in the wind. > One of my hopes with Thrift + Boost is that we can lower the bar to > entry in the XORP development community. It's 2009, we understand > protocols need to run fast and be tightly coupled to the kernel, for > embedded use. But it's feasible to embed scripting languages now -- it > just depends how tightly you define 'embedded', embedded for what? Lets get a community tree up and functional and then see what the patches look like. >> Otherwise, there may be no one to keep me from dumping all of my >> virtualization patches upstream, which would obviously be great for me, >> but perhaps of questionable use for others ;) > > Features are cool, but they need a test framework, especially if radical > in nature. My LANforge product basically is a test framework for Xorp. For the more complex things (adding/removing network interfaces dynamically, in large OSPF meshes, etc), you can't really do it manually, and you surely can't do it with a simple script. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Thu Jul 16 10:00:26 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Thu, 16 Jul 2009 22:30:26 +0530 (IST) Subject: [Xorp-users] Cross Compilation:Unable to find demo-armv5b-softfloat.sh.patch Message-ID: <238971.41987.qm@web94811.mail.in2.yahoo.com> Hi , I am trying to cross-compile xorp with build environment: intel PC with ubuntu 8.04 and target environment is XScale.I am following the steps as said in BUILD_NOTES of xorp-1.6.In step (b),it is said to add patch demo-armv5b-softfloat.sh.patch,I am unable to find the patch in the downloaded crosstool-0.42.tar.gz Where to find the patch? Thanks, Naresh. See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090716/e01c24aa/attachment-0001.html From bms at incunabulum.net Thu Jul 16 10:13:06 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 18:13:06 +0100 Subject: [Xorp-users] Cross Compilation:Unable to find demo-armv5b-softfloat.sh.patch In-Reply-To: <238971.41987.qm@web94811.mail.in2.yahoo.com> References: <238971.41987.qm@web94811.mail.in2.yahoo.com> Message-ID: <4A5F5FA2.7040909@incunabulum.net> naresh raga wrote: > Hi , > I am trying to cross-compile xorp with build environment: intel PC > with ubuntu 8.04 and target environment is XScale.I am following the > steps as said in BUILD_NOTES of xorp-1.6.In step (b),it is said to add > patch demo-armv5b-softfloat.sh.patch,I am unable to find the patch in > the downloaded crosstool-0.42.tar.gz > Where to find the patch? > Please refer to crosstool, as documented above in the BUILD_NOTES. thanks, BMS From bms at incunabulum.net Thu Jul 16 10:15:29 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 18:15:29 +0100 Subject: [Xorp-users] Cross Compilation:Unable to find demo-armv5b-softfloat.sh.patch In-Reply-To: <238971.41987.qm@web94811.mail.in2.yahoo.com> References: <238971.41987.qm@web94811.mail.in2.yahoo.com> Message-ID: <4A5F6031.60508@incunabulum.net> P.S. It is very likely that cross-builds will be left broken in the first SCons spin. We'll be relying on community participation to fix them, until cross-builds catch up in the work plan (after refactoring). Please bear with the branch as it is migrated to SCons -- once it re-opens. I am currently working on fixing the install targets to match up with what's in shipping distributions at the moment. After that, I will probably not do any further work on restoring the regression tests in the SCons build. JT says he's moved them into their own directories, so I'd prefer we pick up on that, before the big Boost + Thrift hammer comes out. thanks, BMS From naresh_raga at yahoo.co.in Thu Jul 16 11:44:22 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 17 Jul 2009 00:14:22 +0530 (IST) Subject: [Xorp-users] FAIL condition during validation part of building xorp-1.6 Message-ID: <773329.71488.qm@web94806.mail.in2.yahoo.com> Hello friends, I am trying to build xorp-1.6 on Debian-sarge 2.4.27 kernel on i686 machine..I have installed gcc-4.1 ,g++-4.1,libssl,libssl-dev0.9.8 as said in BUILD_NOTES.While executing make check,9 out of 28 tests got failed.They are FAIL:test_run_command.sh FAIL:test_sched FAIL:test_task FAIL:test_time_slice FAILtest_timer FAIL:test_observers FAIL:test_profile FAIL:test_asyncio. I am also attaching the output file generated by the command make check for your reference. What's the problem?Should I need to install any extra libraries or utilities or it is the problem with the lower version kernel 2.4.27. Thanks, Naresh Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/ff2f8472/attachment.html From naresh_raga at yahoo.co.in Thu Jul 16 11:55:19 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 17 Jul 2009 00:25:19 +0530 (IST) Subject: [Xorp-users] Cross Compilation:Unable to find demo-armv5b-softfloat.sh.patch In-Reply-To: <4A5F5FA2.7040909@incunabulum.net> Message-ID: <112236.59121.qm@web94801.mail.in2.yahoo.com> --- On Thu, 16/7/09, Bruce Simpson wrote: From: Bruce Simpson Subject: Re: [Xorp-users] Cross Compilation:Unable to find demo-armv5b-softfloat.sh.patch To: "naresh raga" Cc: xorp-users at xorp.org Date: Thursday, 16 July, 2009, 10:43 PM naresh raga wrote: > Hi , > I am trying to cross-compile xorp with build environment: intel PC with ubuntu 8.04 and target environment is XScale.I am following the steps as said in BUILD_NOTES of xorp-1.6.In step (b),it is said to add patch demo-armv5b-softfloat.sh.patch,I am unable to find the patch in the downloaded crosstool-0.42.tar.gz > Where to find the patch? > Please refer to crosstool, as documented above in the BUILD_NOTES. thanks, BMS I am unable to find the patch in the crosstool See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/7682db6f/attachment.html From bms at incunabulum.net Thu Jul 16 11:57:51 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 19:57:51 +0100 Subject: [Xorp-users] FAIL condition during validation part of building xorp-1.6 In-Reply-To: <773329.71488.qm@web94806.mail.in2.yahoo.com> References: <773329.71488.qm@web94806.mail.in2.yahoo.com> Message-ID: <4A5F782F.3040102@incunabulum.net> Is this a slow machine? No config.log from you. From bms at incunabulum.net Thu Jul 16 12:08:20 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 20:08:20 +0100 Subject: [Xorp-users] Cross Compilation:Unable to find demo-armv5b-softfloat.sh.patch In-Reply-To: <112236.59121.qm@web94801.mail.in2.yahoo.com> References: <112236.59121.qm@web94801.mail.in2.yahoo.com> Message-ID: <4A5F7AA4.4040006@incunabulum.net> naresh raga wrote: > > > Please refer to crosstool, as documented above in the BUILD_NOTES. > > I am unable to find the patch in the crosstool > There are a number of toolchain patches in crosstool, and this seems to refer to but one of them. They may have slightly different names, and you may need to follow the crosstool instructions in detail. I don't normally use crosstool myself, and it may well not be up-to-date for the latest GCC compilers. It is also a community open source project; Dan Kegel is responsive to email and will probably accept good patches. Sorry we can't be of further help on this at the moment; you might wish to try a mailing list which is geared towards supporting the cross-compilation use of gcc as a general purpose toolchain: http://sources.redhat.com/ml/crossgcc/ XORP, Inc. are using SCons internally, however, they cannot offer general support on cross-compilation. We'd welcome user feedback on cross-compiling XORP, and we will be needing help on making SCons work for cross-compilation. thanks! BMS From bms at incunabulum.net Thu Jul 16 12:14:39 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 20:14:39 +0100 Subject: [Xorp-users] SCons confdefs In-Reply-To: <4A5E6A14.2030307@incunabulum.net> References: <4A5E6A14.2030307@incunabulum.net> Message-ID: <4A5F7C1F.6040302@incunabulum.net> Bruce Simpson wrote: > It's a known issue with SCons that the confdefs.h file support, > normally handled by the Check*() family of functions, is currently > broken -- the file is not generated, therefore manual header > prerequisites in xorp/site_scons/config/allconfig.py are needed. This > would make dealing with the above issues much easier. I've opened a ticket for SCons on tigris about this: http://scons.tigris.org/issues/show_bug.cgi?id=2455 It's a known issue that config.h itself is not visible from the tests. One of the issues here is that every SCons test has its own little sandbox -- which we like, but for compound feature tests (e.g. do we have sys/socket.h and routing sockets) it's a pain in the behind. It may well just be easier to pull in the results of the tests to the SCons environment object ('env') -- it is only really an issue if we split the network stack tests in SCons up like we did for GNU m4/autoconf. I am rushing to get SCons to replace gmake/autotools for install right now. This is almost ready and will be live once the community branch re-opens. cheers BMS From naresh_raga at yahoo.co.in Thu Jul 16 12:19:37 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 17 Jul 2009 00:49:37 +0530 (IST) Subject: [Xorp-users] FAIL condition during validation part of building xorp-1.6 In-Reply-To: <4A5F782F.3040102@incunabulum.net> Message-ID: <638879.85697.qm@web94802.mail.in2.yahoo.com> - Is this a slow machine????No config.log from you. Hello Bruce, I am attaching config.log file.The machine I am working on is having Pentium 4 processor (1.7GHz) and 512+256MB RAM and 40GB hard drive. Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/97bf9898/attachment.html From naresh_raga at yahoo.co.in Thu Jul 16 12:23:12 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 17 Jul 2009 00:53:12 +0530 (IST) Subject: [Xorp-users] Cross Compilation:Unable to find demo-armv5b-softfloat.sh.patch In-Reply-To: <4A5F7AA4.4040006@incunabulum.net> Message-ID: <856451.50777.qm@web94815.mail.in2.yahoo.com> Thanks Bruce for your valubale suggestion,I will look into them. See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/8d029e80/attachment.html From irmatov at gmail.com Fri Jul 17 02:15:57 2009 From: irmatov at gmail.com (Timur Irmatov) Date: Fri, 17 Jul 2009 14:15:57 +0500 Subject: [Xorp-users] simple xorp configuration In-Reply-To: <4A5F20C0.7090006@incunabulum.net> References: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> <4A5F20C0.7090006@incunabulum.net> Message-ID: <241d382f0907170215o15990ab4v272a994ecc73a93d@mail.gmail.com> On Thu, Jul 16, 2009 at 5:44 PM, Bruce Simpson wrote: > ? Sorry for the delay in responding to your question. As you can probably > tell, the project is in a state of change at the moment, this is going to > affect community support for some time. Thank you for responding! > Timur Irmatov wrote: >> >> When I start xorp_rtrmgr, I see two processes running: xorp_rtrmgr and >> xorp_fea. Then I just try to add vlan interface (this interfaces does >> not exits in the system at the moment): >> >> set vif eth0.333 vlan vlan-id 333 >> >> When I try to commit, I get a message that commit failed. >> >> # commit >> Commit Failed >> Reconfig of process ?caused process to fail.[edit] >> >> I see following in logs: >> >> Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 ?FATAL >> xorp_fea:8700 FEA +1607 iftree.cc insert_ifindex ] Assertion >> (iter->second == ifp) failed >> Jul 16 11:30:19 router xorp_rtrmgr: [ 2009/07/16 11:30:19 ?ERROR >> xorp_rtrmgr:8699 RTRMGR +754 module_manager.cc done_cb ] Command >> "/usr/local/xorp/fea/xorp_fea": terminated with signal 6. >> > > ? ? Did you look at fea/iftree.cc line 1607? This assertion looks as though > it's being triggered because you have more than one interface with the same > interface index in this system. XORP's FEA will use the interface index as > the primary key for learning about network interfaces in the system. Uhm, I don't quite understand what that means. I don't assign interface indexes, it is done by Linux itself, I guess? > Have you tried creating the VLAN interface from outside of XORP? Do you see > similar errors? Yes, I am fully able to create and configure VLAN interfaces through vconfig and ip tools, so there is no problem with VLANs outside of XORP. > This sounds similar to stuff other folk ran into, and the workaround was > simple, off the top of my head, try the list archives. I have tried to search archives but found nothing. By the way, I tried to install XORP 1.6 on fresh stable Debian lenny system, I have the same problem with creation of vlans through xorp. I could create them outside of xorp for now. Did anyone had success with creating vlans on Linux through xorp, not through system networking scripts? -- Timur Irmatov, xmpp:irmatov at jabber.ru From greearb at candelatech.com Fri Jul 17 08:46:14 2009 From: greearb at candelatech.com (Ben Greear) Date: Fri, 17 Jul 2009 08:46:14 -0700 Subject: [Xorp-users] simple xorp configuration In-Reply-To: <241d382f0907170215o15990ab4v272a994ecc73a93d@mail.gmail.com> References: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> <4A5F20C0.7090006@incunabulum.net> <241d382f0907170215o15990ab4v272a994ecc73a93d@mail.gmail.com> Message-ID: <4A609CC6.2040901@candelatech.com> Timur Irmatov wrote: >> This sounds similar to stuff other folk ran into, and the workaround was >> simple, off the top of my head, try the list archives. >> > > I have tried to search archives but found nothing. By the way, I tried > to install XORP 1.6 on fresh stable Debian lenny system, I have the > same problem with creation of vlans through xorp. I could create them > outside of xorp for now. Did anyone had success with creating vlans on > Linux through xorp, not through system networking scripts? > I create them outside of xorp, and that works, at least. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Fri Jul 17 10:14:32 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 17 Jul 2009 22:44:32 +0530 (IST) Subject: [Xorp-users] FAIL condition during validation part of building xorp-1.6 In-Reply-To: <4A5F7FE4.6010501@incunabulum.net> Message-ID: <949871.30759.qm@web94814.mail.in2.yahoo.com> Hai, I am trying to send ouput of gmake check by attaching the output file. There seems a limit on the size of mail being sent to the xorp-users group. Mails that have attachments and size larger than 40 KB are asking for moderator approval.I have looked into archives for my previous mails having attachments.The attachment was being scrubbed.So What should I do now? Thanks in advance, Naresh. Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/540a776f/attachment.html From bms at incunabulum.net Fri Jul 17 16:10:10 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 18 Jul 2009 00:10:10 +0100 Subject: [Xorp-users] FAIL condition during validation part of building xorp-1.6 In-Reply-To: <949871.30759.qm@web94814.mail.in2.yahoo.com> References: <949871.30759.qm@web94814.mail.in2.yahoo.com> Message-ID: <4A6104D2.1090607@incunabulum.net> naresh raga wrote: > Hai, > I am trying to send ouput of gmake check by attaching the output file. > There seems a limit on the size of mail being sent to the xorp-users > group. Mails that have attachments and size larger than 40 KB are > asking for moderator approval.I have looked into archives for my > previous mails having attachments.The attachment was being scrubbed.So > What should I do now? > You could try pastebin.ca or similar. thanks, BMS From bms at incunabulum.net Sat Jul 18 08:33:38 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 18 Jul 2009 16:33:38 +0100 Subject: [Xorp-users] SCons prerequisites for Linux targets In-Reply-To: <4A5E8C9F.9060900@candelatech.com> References: <4A5E7387.6040501@incunabulum.net> <4A5E8C9F.9060900@candelatech.com> Message-ID: <4A61EB52.2050908@incunabulum.net> Ben Greear wrote: > Sounds good. Hope you have better luck keeping spammers out of your > wiki than we did :P I think it's reasonable that people need to sign up, in order to contribute to a Wiki. Captcha-like systems can only go so far. I'd rather we didn't have to vet people who just wander in wanting to contribute their own support information. I'm surprised that XORP does not already have an independent Wiki. We are still waiting for the legal go-ahead to deploy the community code on SourceForge. I can't apologise enough for this, this is pretty much out of my hands at the moment. I have suggested Google Code as an alternative venue, which is possibly more viable given the constraints we're under here for a community release. SourceForge is in a period of change itself at the moment. Whilst I don't like the idea of putting all our eggs in the Google basket -- and there are good arguments on both sides -- SourceForge have withdrawn their Wiki service, Google Code have not. > > A simple README_BUILD.txt would probably suffice as well. The thing is, whilst it's all well and good shipping BUILD_NOTES in the release tarballs as we already do, we probably need to move to a more fluid model. The information in those files gets outdated easily, and XORP has been shipping them around year after year. Shipping community releases is time consuming, and when the engineering resource isn't there, it's difficult to pull off without serious personal commitment on the part of the original instigators, and that doesn't come without its own costs. It is always best to have the host organisation directly involved. One approach, which seems to work well in one local software company I'm in the loop with, is to designate Friday afternoon as 'open source time', and this is something will be recommending to XORP, Inc. The community branch is, after all, pretty much an essential sales opportunity, that can't be ignored. thanks, BMS From bms at incunabulum.net Sat Jul 18 08:39:40 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 18 Jul 2009 16:39:40 +0100 Subject: [Xorp-users] simple xorp configuration In-Reply-To: <241d382f0907170215o15990ab4v272a994ecc73a93d@mail.gmail.com> References: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> <4A5F20C0.7090006@incunabulum.net> <241d382f0907170215o15990ab4v272a994ecc73a93d@mail.gmail.com> Message-ID: <4A61ECBC.8040008@incunabulum.net> Timur Irmatov wrote: > >> Did you look at fea/iftree.cc line 1607? This assertion looks as though >> it's being triggered because you have more than one interface with the same >> interface index in this system. XORP's FEA will use the interface index as >> the primary key for learning about network interfaces in the system. >> > > Uhm, I don't quite understand what that means. I don't assign > interface indexes, it is done by Linux itself, I guess? > That's right. Have you tried putting an inner vif eth0 {} block into your initial configuration? It seemed to be missing in the config you posted. I believe vifs were originally intended to mirror some of the multiple virtual interface stuff that's possible in ATM and other more layered network transports. However they persist in community XORP's configuration model, and need to be present in order for your configuration to work. [I think the original vlan problem had something to do with interface naming, but I could be thinking of FreeBSD here, which is what I normally do work on.] > I have tried to search archives but found nothing. By the way, I tried > to install XORP 1.6 on fresh stable Debian lenny system, I have the > same problem with creation of vlans through xorp. The VLAN support code is still relatively recent in terms of XORP's development history, it is entirely something possible is broken there. Unfortunately, I can't look into it in detail at the moment. There is a binary package for Ubuntu/Debian, however I don't know what version 'lenny' refers to, the package may be available for your version. Are you using the binary package, or building XORP from source? We would like to support Ubuntu as a 'tier 1' platform, and could use all the help we can get. thanks, BMS From vommwa at yahoo.com Sun Jul 19 01:40:10 2009 From: vommwa at yahoo.com (victor omwando) Date: Sun, 19 Jul 2009 01:40:10 -0700 (PDT) Subject: [Xorp-users] BGP settings In-Reply-To: <4A609CC6.2040901@candelatech.com> References: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> <4A5F20C0.7090006@incunabulum.net> <241d382f0907170215o15990ab4v272a994ecc73a93d@mail.gmail.com> <4A609CC6.2040901@candelatech.com> Message-ID: <990510.61357.qm@web56605.mail.re3.yahoo.com> This is a bit of a misuse of the mailing list, but due to the lack of any faster options, I am obliged to direct my question here. When setting up the bgp protocol peers section, in general (not just limited to XORP configuration), should the local-ip be the same as the BGP ID, or can it be just about any IP address that has been configured on my router? I found the explanation on the xorp manual to be a bit unclear on this point. Thanks. ________________________________ From: Ben Greear To: Timur Irmatov Cc: xorp-users at xorp.org Sent: Friday, July 17, 2009 11:46:14 AM Subject: Re: [Xorp-users] simple xorp configuration Timur Irmatov wrote: >> This sounds similar to stuff other folk ran into, and the workaround was >> simple, off the top of my head, try the list archives. >> > > I have tried to search archives but found nothing. By the way, I tried > to install XORP 1.6 on fresh stable Debian lenny system, I have the > same problem with creation of vlans through xorp. I could create them > outside of xorp for now. Did anyone had success with creating vlans on > Linux through xorp, not through system networking scripts? > I create them outside of xorp, and that works, at least. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090719/0da13275/attachment.html From bms at incunabulum.net Sun Jul 19 09:39:08 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 19 Jul 2009 17:39:08 +0100 Subject: [Xorp-users] OpenBSD scons breakage In-Reply-To: <4A5E6A14.2030307@incunabulum.net> References: <4A5E6A14.2030307@incunabulum.net> Message-ID: <4A634C2C.7010604@incunabulum.net> Bruce Simpson wrote: > For all OpenBSD users: the build is broken in the SCons-ified community > branch. > > This is on OpenBSD 5.0 with gcc 3.3.5 out-of-the-box, using scons from > ports. > This was of course meant to read OpenBSD 4.5. > Summary: > * The header prerequisites are most likely incomplete in a number of > places. Who volunteers? best BMS From bms at incunabulum.net Sun Jul 19 10:47:29 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 19 Jul 2009 18:47:29 +0100 Subject: [Xorp-users] BGP settings In-Reply-To: <990510.61357.qm@web56605.mail.re3.yahoo.com> References: <241d382f0907152336s5fd17467wbe61678f87a66a53@mail.gmail.com> <4A5F20C0.7090006@incunabulum.net> <241d382f0907170215o15990ab4v272a994ecc73a93d@mail.gmail.com> <4A609CC6.2040901@candelatech.com> <990510.61357.qm@web56605.mail.re3.yahoo.com> Message-ID: <4A635C31.3010704@incunabulum.net> victor omwando wrote: > This is a bit of a misuse of the mailing list, but due to the lack of > any faster options, I am obliged to direct my question here. When > setting up the bgp protocol peers section, in general (not just > limited to XORP configuration), should the local-ip be the same as the > BGP ID, or can it be just about any IP address that has been > configured on my router? I found the explanation on the xorp manual to > be a bit unclear on this point. Thanks. I believe it should be the IP of the interface which you expect to use for outgoing connections to the remote peer. If you can suggest a better wording in the manual, that would be great. cheers, BMS From emixp at gmx.net Mon Jul 20 00:30:55 2009 From: emixp at gmx.net (Emi) Date: Mon, 20 Jul 2009 09:30:55 +0200 Subject: [Xorp-users] Disabling OSPF LSA flooding in XORP Message-ID: <0C5D8B8FECD545F3843E85E117C89A27@darkside> Hello I am currently trying out xorp for routing in a very mission critical envirorment with many bottlenecks. Bandwidth is very critical in my network, therefore I was wondering about how I could disable OSPF LSA flooding (paranoid updates) in xorp to save some bandwith? I am familiar with OSPF and other routing protocols, but I am not able to find the command to disable LSA flooding. with best regards and thanks, Emi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090720/0f48ec22/attachment.html From bms at incunabulum.net Mon Jul 20 01:20:39 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 20 Jul 2009 09:20:39 +0100 Subject: [Xorp-users] Disabling OSPF LSA flooding in XORP In-Reply-To: <0C5D8B8FECD545F3843E85E117C89A27@darkside> References: <0C5D8B8FECD545F3843E85E117C89A27@darkside> Message-ID: <4A6428D7.3030603@incunabulum.net> Emi wrote: > ... > how I could disable OSPF LSA flooding (paranoid updates) in xorp to > save some bandwith? > I am familiar with OSPF and other routing protocols, but I am not able > to find the command to disable LSA flooding. I'm not familiar with a Cisco or Juniper command to do this. Can you provide an example? There is no such command in XORP at the moment. We'd happily accept a patch to do this. The place to start looking is the AreaRouter class in the OSPF implementation. best regards, BMS From emixp at gmx.net Mon Jul 20 01:52:16 2009 From: emixp at gmx.net (Emi) Date: Mon, 20 Jul 2009 10:52:16 +0200 Subject: [Xorp-users] Disabling OSPF LSA flooding in XORP References: <0C5D8B8FECD545F3843E85E117C89A27@darkside> <4A6428D7.3030603@incunabulum.net> Message-ID: <04C83CF123AC44E8A8070547451423BE@darkside> Hi An equivalent cisco command is Router(config-if)#ip ospf flood-reduction. A description can be found here: http://www.cisco.com/en/US/docs/ios/12_1t/12_1t2/feature/guide/dt_ospff.html#wp1015363 If I understand this command correctly, it causes the router to send all LSAs with the DoNotAge bit set. Thanks for your fast reply. ----- Original Message ----- From: "Bruce Simpson" To: "Emi" Cc: Sent: Monday, July 20, 2009 10:20 AM Subject: Re: [Xorp-users] Disabling OSPF LSA flooding in XORP > Emi wrote: >> ... >> how I could disable OSPF LSA flooding (paranoid updates) in xorp to save >> some bandwith? >> I am familiar with OSPF and other routing protocols, but I am not able to >> find the command to disable LSA flooding. > > I'm not familiar with a Cisco or Juniper command to do this. Can you > provide an example? > > There is no such command in XORP at the moment. We'd happily accept a > patch to do this. The place to start looking is the AreaRouter class in > the OSPF implementation. > > best regards, > BMS From bms at incunabulum.net Mon Jul 20 05:39:41 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 20 Jul 2009 13:39:41 +0100 Subject: [Xorp-users] Disabling OSPF LSA flooding in XORP In-Reply-To: <04C83CF123AC44E8A8070547451423BE@darkside> References: <0C5D8B8FECD545F3843E85E117C89A27@darkside> <4A6428D7.3030603@incunabulum.net> <04C83CF123AC44E8A8070547451423BE@darkside> Message-ID: <4A64658D.2080205@incunabulum.net> Hi, Emi wrote: > An equivalent cisco command is > Router(config-if)#ip ospf flood-reduction. > > A description can be found here: > http://www.cisco.com/en/US/docs/ios/12_1t/12_1t2/feature/guide/dt_ospff.html#wp1015363 > > If I understand this command correctly, it causes the router to send > all LSAs with the DoNotAge bit set. This sounds like a useful feature. Can you please raise an enhancement request at http://bugzilla.xorp.org/ ? Thank you, BMS From bms at incunabulum.net Wed Jul 22 05:37:00 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 22 Jul 2009 13:37:00 +0100 Subject: [Xorp-users] NetBSD scons breakage In-Reply-To: <4A5E6A01.70906@incunabulum.net> References: <4A5E6A01.70906@incunabulum.net> Message-ID: <4A6707EC.6040307@incunabulum.net> Bruce Simpson wrote: > Hi all, > > For all NetBSD users: here is the scons log output from an attempted > build with the SCons-ified community branch. > J.T. Conklin from XORP, Inc. has volunteered to fix NetBSD, when the community branch re-opens. Hopefully the version of SCons in pkgsrc will be more up-to-date. We'd like to avoid shipping SCons with XORP itself if that's possible; both Ubuntu and FreeBSD have up-to-date versions of SCons available in their packaging systems. thanks, BMS From bms at incunabulum.net Wed Jul 15 16:45:41 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 16 Jul 2009 00:45:41 +0100 Subject: [Xorp-users] OpenSolaris scons breakage Message-ID: <4A5E6A25.6010802@incunabulum.net> Hi all, So, it looks like XORP doesn't compile out of the box under OpenSolaris, with the Scons, build at the moment. It looks like the port was unfinished anyway, but wanted to be sure that I wasn't breaking anything with the Autotools replacement. There are a few issues which need to be dealt with for OpenSolaris compiles to work. As I'm not running XORP on OpenSolaris anywhere, I'm going to leave it for now, as I need to focus on finishing the main SCons job. Summary: * sig_t not defined in base headers * ifreq doesn't have ifr_mtu * bsd paths.h isn't present * there is no vlan support (yet) * there is no SOL_IP * Not 100% sure why it can't find the 'queue' template; stl headers are present. I've attached the log, if someone wants to help out, very cool. g++ is 3.4.3. Some packages you're likely to need: SUNWPython26, SUNWbison, SUNWflexlex, SUNWgcc, SUNWflexruntime, SUNWlibm, SUNWlibpcap, SUNWpcre, SUNWsvn. scons is available from jucr.opensolaris.org as an OpenSolaris 'pending' package. %%% scons: Reading SConscript files ... Cross build is False Architecture is i86pc Operating System is sunos Release is public17 Build directory is /root/i86pc-sunos-public17 Staging directory is /root/i86pc-sunos-public17/stage Checking whether byte ordering is bigendian... (cached) no Checking for C header file stdint.h... (cached) yes Checking for C header file inttypes.h... (cached) yes Checking for C type uint64_t... (cached) yes Checking for C header file stddef.h... (cached) yes Checking for C header file stdarg.h... (cached) yes Checking for C header file stdlib.h... (cached) yes Checking for C header file strings.h... (cached) yes Checking for C header file string.h... (cached) yes Checking for C header file signal.h... (cached) yes Checking for C header file math.h... (cached) yes Checking for C header file memory.h... (cached) yes Checking for C function strftime()... (cached) yes Checking for C function strlcpy()... (cached) yes Checking for C function strlcat()... (cached) yes Checking whether va_copy is declared... (cached) yes Checking for C header file fcntl.h... (cached) yes Checking for C header file getopt.h... (cached) yes Checking for C header file glob.h... (cached) yes Checking for C header file grp.h... (cached) yes Checking for C header file pthread.h... (cached) yes Checking for C header file pwd.h... (cached) yes Checking for C header file mqueue.h... (cached) yes Checking for C header file regex.h... (cached) yes Checking for C header file syslog.h... (cached) yes Checking for C header file termios.h... (cached) yes Checking for C header file time.h... (cached) yes Checking for C header file unistd.h... (cached) yes Checking for C header file vfork.h... (cached) no Checking for C function readv()... (cached) yes Checking for C function strerror()... (cached) yes Checking for C function syslog()... (cached) yes Checking for C function uname()... (cached) yes Checking for C function writev()... (cached) yes Checking for C library xnet... (cached) yes Checking for C function recvmsg()... (cached) yes Checking for C function sendmsg()... (cached) yes Checking for C library rt... (cached) yes Checking for C function clock_gettime()... (cached) yes Checking whether CLOCK_MONOTONIC is declared... (cached) yes Checking for C type struct timespec... (cached) yes Checking for C header file paths.h... (cached) no Checking for C header file sysexits.h... (cached) yes Checking for C function hstrerror()... (cached) no Checking for C function realpath()... (cached) yes Checking for C function strptime()... (cached) yes Checking for C function sysctl()... (cached) no Checking for C header file sys/cdefs.h... (cached) no Checking for C header file sys/param.h... (cached) yes Checking for C header file sys/types.h... (cached) yes Checking for C header file sys/utsname.h... (cached) yes Checking for C header file sys/errno.h... (cached) yes Checking for C header file sys/wait.h... (cached) yes Checking for C header file sys/signal.h... (cached) yes Checking for C header file sys/time.h... (cached) yes Checking for C header file sys/uio.h... (cached) yes Checking for C header file sys/ioctl.h... (cached) yes Checking for C header file sys/select.h... (cached) yes Checking for C header file sys/socket.h... (cached) yes Checking for C header file sys/sockio.h... (cached) yes Checking for C header file sys/un.h... (cached) no Checking for C header file sys/mount.h... (cached) yes Checking for C header file sys/resource.h... (cached) yes Checking for C header file sys/stat.h... (cached) yes Checking for C header file sys/syslog.h... (cached) yes Checking for C header file sys/linker.h... (cached) no Checking for C header file sys/sysctl.h... (cached) no Checking for C header file linux/types.h... (cached) no Checking for C header file linux/sockios.h... (cached) no Checking for C type struct iovec... (cached) yes Checking for C type struct msghdr... (cached) yes Checking for C type struct cmsghdr... (cached) yes Checking whether AF_INET is declared... (cached) yes Checking whether AF_INET6 is declared... (cached) yes Checking whether SOCK_STREAM is declared... (cached) yes Checking whether SOCK_DGRAM is declared... (cached) yes Checking whether SOCK_RAW is declared... (cached) yes Checking whether C type struct msghdr has member msg_control... (cached) no Checking whether C type struct msghdr has member msg_iov... (cached) yes Checking whether C type struct msghdr has member msg_name... (cached) yes Checking whether C type struct msghdr has member msg_namelen... (cached) yes Checking whether C type struct sockaddr has member sa_len... (cached) no Checking whether C type struct sockaddr_storage has member ss_len... (cached) no Checking whether C type struct sockaddr_un has member sun_len... (cached) no Checking for C header file net/ethernet.h... (cached) no Checking for C header file sys/ethernet.h... (cached) no Checking for C header file net/if.h... (cached) yes Checking for C header file net/if_arp.h... (cached) yes Checking for C header file net/if_dl.h... (cached) yes Checking for C header file net/if_ether.h... (cached) no Checking for C header file net/if_media.h... (cached) no Checking for C header file net/if_var.h... (cached) no Checking for C header file net/if_types.h... (cached) yes Checking for C header file net/route.h... (cached) yes Checking for C header file netdb.h... (cached) yes Checking for C header file ifaddrs.h... (cached) no Checking for C header file stropts.h... (cached) yes Checking for C header file linux/ethtool.h... (cached) no Checking for C header file linux/if_tun.h... (cached) no Checking for C header file linux/netlink.h... (cached) no Checking for C header file linux/rtnetlink.h... (cached) no Checking whether C type struct sockaddr_dl has member sdl_len... (cached) no Checking whether C type struct ifreq has member ifr_hwaddr... (cached) no Checking whether C type struct ifreq has member ifr_ifindex... (cached) no Checking for C function ether_aton()... (cached) no Checking for C function ether_aton_r()... (cached) no Checking for C function ether_ntoa()... (cached) no Checking for C function ether_ntoa_r()... (cached) no Checking for C function getaddrinfo()... (cached) yes Checking for C function getifaddrs()... (cached) no Checking for C function getnameinfo()... (cached) yes Checking for C function if_indextoname()... (cached) yes Checking for C function if_nametoindex()... (cached) yes Checking for C function inet_ntop()... (cached) yes Checking for C function inet_pton()... (cached) yes Checking for C type struct ether_addr... (cached) no Checking whether system has sysctl NET_RT_DUMP... (cached) no Checking whether system has sysctl NET_RT_IFLIST... (cached) no Checking whether SIOCGIFCONF is declared... (cached) yes Checking for C header file netinet/in.h... (cached) yes Checking for C header file netinet/in_systm.h... (cached) yes Checking for C header file netinet/in_var.h... (cached) no Checking for C header file netinet/ip.h... (cached) yes Checking for C header file netinet/tcp.h... (cached) yes Checking for C header file netinet/igmp.h... (cached) yes Checking for C header file netinet/ether.h... (cached) no Checking for C header file netinet/if_ether.h... (cached) no Checking for C header file inet/nd.h... (cached) yes Checking for C header file inet/ip.h... (cached) yes Checking for C header file arpa/inet.h... (cached) yes Checking for C header file arpa/telnet.h... (cached) yes Checking whether C type struct sockaddr_in has member sin_len... (cached) no Checking whether IP_MULTICAST_IF is declared... (cached) yes Checking whether IP_MULTICAST_TTL is declared... (cached) yes Checking whether IP_MULTICAST_LOOP is declared... (cached) yes Checking whether IP_ADD_MEMBERSHIP is declared... (cached) yes Checking whether IP_DROP_MEMBERSHIP is declared... (cached) yes Checking whether system has sysctl IPCTL_FORWARDING... (cached) no Checking whether __KAME__ is declared... (cached) no Checking whether inet6_opt_init is declared... (cached) yes Checking whether C type struct sockaddr_in6 has member sin6_len... (cached) no Checking whether C type struct sockaddr_in6 has member sin6_scope_id... (cached) yes Checking for C header file netinet/ip6.h... (cached) yes Checking for C header file netinet/icmp6.h... (cached) yes Checking for C type struct mld_hdr... (cached) yes Checking for C header file netinet6/ip6_var.h... (cached) no Checking for C header file netinet6/in6_var.h... (cached) no Checking for C header file netinet6/nd6.h... (cached) no Checking for C++ header file netinet6/nd6.h... (cached) no Checking whether system has sysctl IPV6CTL_FORWARDING... (cached) no Checking whether system has sysctl IPV6CTL_ACCEPT_RTADV... (cached) no Checking for C header file netinet/ip_mroute.h... (cached) yes Checking for C header file net/ip_mroute/ip_mroute.h... (cached) no Checking for C header file linux/mroute.h... (cached) no Checking for C type struct mfcctl2... (cached) no Checking whether C type struct mfcctl2 has member mfcc_flags... (cached) no Checking whether C type struct mfcctl2 has member mfcc_rp... (cached) no Checking for C header file netinet/pim.h... (cached) no Checking for C type struct pim... (cached) no Checking whether C type struct pim has member pim_vt... (cached) no Checking for C header file netinet6/ip6_mroute.h... (cached) no Checking for C header file linux/mroute6.h... (cached) no Checking for C type struct mf6cctl2... (cached) no Checking whether C type struct mf6cctl2 has member mf6cc_flags... (cached) no Checking whether C type struct mf6cctl2 has member mf6cc_rp... (cached) no Checking for C header file netinet/ip_compat.h... (cached) no Checking for C header file netinet/ip_fil.h... (cached) no Checking for C header file netinet/ip_fw.h... (cached) no Checking for C header file net/pfvar.h... (cached) no Checking for C++ header file linux/netfilter_ipv4/ip_tables.h... (cached) no Checking for C++ header file linux/netfilter_ipv6/ip6_tables.h... (cached) no Checking for C header file net/if_vlanvar.h... (cached) no Checking for C header file net/if_vlan_var.h... (cached) no Checking for C header file net/vlan/if_vlan_var.h... (cached) no Checking for C header file linux/if_vlan.h... (cached) no Checking for C header file pcre.h... (cached) no Checking for C header file pcreposix.h... (cached) no Checking for C library pcre... (cached) yes Checking for C library pcreposix... (cached) yes Checking for C header file openssl/md5.h... (cached) no Checking for C library crypto... (cached) yes Checking for C function MD5_Init()... (cached) yes Checking for C header file dlfcn.h... (cached) yes Checking for C library dl... (cached) yes Checking for C function dlopen()... (cached) yes Checking for C header file pcap.h... (cached) yes Checking for C library pcap... (cached) yes Checking for C function pcap_sendpacket()... (cached) yes Checking for C library resolv... (cached) yes scons: done reading SConscript files. scons: Building targets ... gcc -o /root/i86pc-sunos-public17/libxorp/daemon.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wbad-function-cast -Wmissing-prototypes -Wcast-qual -Wmissing-declarations -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. /root/i86pc-sunos-public17/libxorp/daemon.c /root/i86pc-sunos-public17/libxorp/daemon.c:45:19: paths.h: No such file or directory scons: *** [/root/i86pc-sunos-public17/libxorp/daemon.pic.o] Error 1 gcc -o /root/i86pc-sunos-public17/libxorp/xlog.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wbad-function-cast -Wmissing-prototypes -Wcast-qual -Wmissing-declarations -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. /root/i86pc-sunos-public17/libxorp/xlog.c /root/i86pc-sunos-public17/libxorp/xlog.c: In function `xlog_record_va': /root/i86pc-sunos-public17/libxorp/xlog.c:602: error: `sig_t' undeclared (first use in this function) /root/i86pc-sunos-public17/libxorp/xlog.c:602: error: (Each undeclared identifier is reported only once /root/i86pc-sunos-public17/libxorp/xlog.c:602: error: for each function it appears in.) /root/i86pc-sunos-public17/libxorp/xlog.c:602: error: syntax error before "sigpipe_handler" /root/i86pc-sunos-public17/libxorp/xlog.c:627: error: `sigpipe_handler' undeclared (first use in this function) scons: *** [/root/i86pc-sunos-public17/libxorp/xlog.pic.o] Error 1 scons: `/root/i86pc-sunos-public17/libfeaclient/libfeaclient.so' is up to date. g++ -o /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc: In member function `int IfConfigSetIoctl::set_interface_mtu(const std::string&, uint32_t, std::string&)': /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc:703: error: 'struct ifreq' has no member named 'ifr_mtu' /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc: In member function `int IfConfigSetIoctl::add_addr(const std::string&, const std::string&, uint32_t, const IPv6&, uint32_t, bool, const IPv6&, std::string&)': /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.cc:963: error: aggregate `in6_ifreq in6_ifreq' has incomplete type and cannot be defined scons: *** [/root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_set_ioctl.pic.o] Error 1 g++ -o /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc: In member function `int IfConfigVlanGetBsd::read_config(IfTree&)': /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc:157: error: aggregate `vlanreq vlanreq' has incomplete type and cannot be defined /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc:165: error: `SIOCGETVLAN' undeclared (first use this function) /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.cc:165: error: (Each undeclared identifier is reported only once for each function it appears in.) scons: *** [/root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_get_bsd.pic.o] Error 1 g++ -o /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc: In member function `int IfConfigVlanSetBsd::add_vlan(const std::string&, const std::string&, uint16_t, std::string&)': /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:205: error: aggregate `vlanreq vlanreq' has incomplete type and cannot be defined /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:220: error: `SIOCIFCREATE' undeclared (first use this function) /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:220: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:274: error: incompatible types in assignment of `char[16]' to `char[1]' /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:299: error: `SIOCSETVLAN' undeclared (first use this function) /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc: In member function `int IfConfigVlanSetBsd::delete_vlan(const std::string&, const std::string&, std::string&)': /root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.cc:324: error: `SIOCIFDESTROY' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/fea/data_plane/ifconfig/ifconfig_vlan_set_bsd.pic.o] Error 1 scons: `/root/i86pc-sunos-public17/fea/data_plane/firewall/libxorp_firewall.so' is up to date. scons: `/root/i86pc-sunos-public17/fea/data_plane/fibconfig/libxorp_fibconfig.so' is up to date. g++ -o /root/i86pc-sunos-public17/fea/data_plane/io/io_ip_socket.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/fea/data_plane/io/io_ip_socket.cc /root/i86pc-sunos-public17/fea/data_plane/io/io_ip_socket.cc: In member function `virtual int IoIpSocket::send_packet(const std::string&, const std::string&, const IPvX&, const IPvX&, int32_t, int32_t, bool, bool, const std::vector >&, const std::vector >, std::allocator > > >&, const std::vector >&, std::string&)': /root/i86pc-sunos-public17/fea/data_plane/io/io_ip_socket.cc:2089: error: `SOL_IP' undeclared (first use this function) /root/i86pc-sunos-public17/fea/data_plane/io/io_ip_socket.cc:2089: error: (Each undeclared identifier is reported only once for each function it appears in.) scons: *** [/root/i86pc-sunos-public17/fea/data_plane/io/io_ip_socket.pic.o] Error 1 scons: `/root/i86pc-sunos-public17/fea/data_plane/control_socket/libxorp_control_socket.so' is up to date. scons: `/root/i86pc-sunos-public17/fea/data_plane/managers/libxorp_data_plane_managers.so' is up to date. scons: `/root/i86pc-sunos-public17/mrt/libmrt.so' is up to date. g++ -o /root/i86pc-sunos-public17/fea/fea_node.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/fea/fea_node.cc /root/i86pc-sunos-public17/fea/fea_node.cc:280:2: #error "No data plane manager to load: unknown system" scons: *** [/root/i86pc-sunos-public17/fea/fea_node.pic.o] Error 1 g++ -o /root/i86pc-sunos-public17/ospf/peer_manager.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/ospf/peer_manager.cc In file included from /root/i86pc-sunos-public17/ospf/peer_manager.cc:52: /root/i86pc-sunos-public17/ospf/peer.hh:533: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/ospf/peer.hh:533: error: expected `;' before '<' token scons: *** [/root/i86pc-sunos-public17/ospf/peer_manager.pic.o] Error 1 g++ -o /root/i86pc-sunos-public17/ospf/peer.pic.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -fPIC -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/ospf/peer.cc In file included from /root/i86pc-sunos-public17/ospf/peer.cc:68: /root/i86pc-sunos-public17/ospf/peer.hh:533: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/ospf/peer.hh:533: error: expected `;' before '<' token scons: *** [/root/i86pc-sunos-public17/ospf/peer.pic.o] Error 1 scons: `/root/i86pc-sunos-public17/policy/libpolicy.so' is up to date. g++ -o /root/i86pc-sunos-public17/bgp/damping.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/damping.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/damping.cc:32: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/damping.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/next_hop_resolver.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/next_hop_resolver.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/next_hop_resolver.cc:35: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/next_hop_resolver.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/path_attribute.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/path_attribute.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/path_attribute.cc:44: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/path_attribute.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/peer.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/peer.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/peer.cc:42: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/peer.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/peer_handler.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/peer_handler.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/peer_handler.cc:28: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/peer_handler.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/plumbing.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/plumbing.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/plumbing.cc:36: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/plumbing.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/rib_ipc_handler.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/rib_ipc_handler.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/rib_ipc_handler.cc:31: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/rib_ipc_handler.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/route_table_aggregation.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/route_table_aggregation.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/route_table_aggregation.cc:28: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/route_table_aggregation.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/route_table_cache.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/route_table_cache.cc In file included from /root/i86pc-sunos-public17/bgp/route_table_cache.cc:28: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.cc: At global scope: /root/i86pc-sunos-public17/bgp/route_table_cache.cc:32: error: `typename DeleteAllNodes::RouteTables DeleteAllNodes::_route_tables' is not a static member of `class DeleteAllNodes' /root/i86pc-sunos-public17/bgp/route_table_cache.cc:32: error: template definition of non-template `typename DeleteAllNodes::RouteTables DeleteAllNodes::_route_tables' /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In instantiation of `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*) [with A = IPv4]': /root/i86pc-sunos-public17/bgp/route_table_cache.cc:64: instantiated from `void CacheTable::flush_cache() [with A = IPv4]' /root/i86pc-sunos-public17/bgp/route_table_cache.cc:473: instantiated from here /root/i86pc-sunos-public17/bgp/route_table_cache.hh:142: warning: unused parameter 'route_table' /root/i86pc-sunos-public17/bgp/route_table_cache.hh:142: warning: unused parameter 'route_table' /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In instantiation of `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*) [with A = IPv6]': /root/i86pc-sunos-public17/bgp/route_table_cache.cc:64: instantiated from `void CacheTable::flush_cache() [with A = IPv6]' /root/i86pc-sunos-public17/bgp/route_table_cache.cc:474: instantiated from here /root/i86pc-sunos-public17/bgp/route_table_cache.hh:142: warning: unused parameter 'route_table' /root/i86pc-sunos-public17/bgp/route_table_cache.hh:142: warning: unused parameter 'route_table' scons: *** [/root/i86pc-sunos-public17/bgp/route_table_cache.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/route_table_damping.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/route_table_damping.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/route_table_damping.cc:28: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/route_table_damping.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/route_table_filter.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/route_table_filter.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/route_table_filter.cc:30: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/route_table_filter.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/route_table_ribin.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/route_table_ribin.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/rib_ipc_handler.hh:29, from /root/i86pc-sunos-public17/bgp/route_table_ribin.cc:30: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/route_table_ribin.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/xrl_target.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/xrl_target.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/xrl_target.cc:41: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/xrl_target.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/bgp.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/bgp.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/bgp.cc:40: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/bgp.o] Error 1 g++ -o /root/i86pc-sunos-public17/bgp/main.o -c -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -D_FORTIFY_SOURCE=0 -I/usr/sfw/include -I/opt/local/include -I/usr/local/include -I. -I/root/i86pc-sunos-public17 /root/i86pc-sunos-public17/bgp/main.cc In file included from /root/i86pc-sunos-public17/bgp/plumbing.hh:36, from /root/i86pc-sunos-public17/bgp/bgp.hh:35, from /root/i86pc-sunos-public17/bgp/main.cc:33: /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: ISO C++ forbids declaration of `queue' with no type /root/i86pc-sunos-public17/bgp/route_table_cache.hh:139: error: expected `;' before '<' token /root/i86pc-sunos-public17/bgp/route_table_cache.hh:194: error: `RouteTables' does not name a type /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In constructor `DeleteAllNodes::DeleteAllNodes(const PeerHandler*, RefTrie >*)': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh:144: error: (Each undeclared identifier is reported only once for each function it appears in.) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In member function `bool DeleteAllNodes::delete_some_nodes()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:164: error: `_route_tables' undeclared (first use this function) /root/i86pc-sunos-public17/bgp/route_table_cache.hh: In static member function `static bool DeleteAllNodes::running()': /root/i86pc-sunos-public17/bgp/route_table_cache.hh:191: error: `_route_tables' undeclared (first use this function) scons: *** [/root/i86pc-sunos-public17/bgp/main.o] Error 1 scons: done building targets (errors occurred during build). %%% thanks, BMS From naresh_raga at yahoo.co.in Thu Jul 16 11:47:33 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 17 Jul 2009 00:17:33 +0530 (IST) Subject: [Xorp-users] FAIL condition during validation part of building xorp-1.6-attached output file Message-ID: <604960.66599.qm@web94807.mail.in2.yahoo.com> Sorry I have not attached the output file in the previous mail,but I have done in this. Hello friends, I am trying to build xorp-1.6 on Debian-sarge 2.4.27 kernel on i686 machine..I have installed gcc-4.1 ,g++-4.1,libssl,libssl-dev0.9.8 as said in BUILD_NOTES.While executing make check,9 out of 28 tests got failed.They are FAIL:test_run_command.sh FAIL:test_sched FAIL:test_task FAIL:test_time_slice FAILtest_timer FAIL:test_observers FAIL:test_profile FAIL:test_asyncio. I am also attaching the output file generated by the command make check for your reference. What's the problem?Should I need to install any extra libraries or utilities or it is the problem with the lower version kernel 2.4.27. Thanks, Naresh Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. http://downloads.yahoo.com/in/internetexplorer/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/fbfd8bcb/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: error Type: application/octet-stream Size: 29338 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/fbfd8bcb/attachment-0001.obj From naresh_raga at yahoo.co.in Thu Jul 16 12:24:53 2009 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 17 Jul 2009 00:54:53 +0530 (IST) Subject: [Xorp-users] Fw: Re: FAIL condition during validation part of building xorp-1.6 Message-ID: <518216.35528.qm@web94803.mail.in2.yahoo.com> - Is this a slow machine????No config.log from you. Hello Bruce, I am attaching config.log file.The machine I am working on is having Pentium 4 processor (1.7GHz) and 512+256MB RAM and 40GB hard drive. Looking for local information? Find it on Yahoo! Local Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. http://downloads.yahoo.com/in/internetexplorer/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/58ce4d62/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 574981 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090717/58ce4d62/attachment-0001.obj From bms at incunabulum.net Thu Jul 23 06:43:38 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 23 Jul 2009 14:43:38 +0100 Subject: [Xorp-users] FAIL condition during validation part of building xorp-1.6-attached output file In-Reply-To: <604960.66599.qm@web94807.mail.in2.yahoo.com> References: <604960.66599.qm@web94807.mail.in2.yahoo.com> Message-ID: <4A68690A.6020302@incunabulum.net> naresh raga wrote: > > > > Sorry I have not attached the output file in the previous mail,but > I have done in this. > Thanks for the log. The most likely causes of these regression test failures, are being run on a slow machine, or timer aliasing in a virtual machine. The test failures reported in this log are not fully instrumented. The output from all of the commands is not there; did you remember to log stderr by redirecting it? e.g. in tcsh: gmake check |& tee log in bash: gmake check 2>&1 | tee log The specific tests which have failed are all time-contingent, and in libxorp. Without the full output, it's difficult to tell exactly what has gone wrong. However, all of the other regression tests pass. test_asyncio, for example, should print a series of numbers. thanks BMS From bms at incunabulum.net Thu Jul 23 06:49:31 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 23 Jul 2009 14:49:31 +0100 Subject: [Xorp-users] [Not] Advertising Routes to BGP In-Reply-To: References: Message-ID: <4A686A6B.7020201@incunabulum.net> Hi there, Sorry for the long delay in responding to your message. Tafi Makamure wrote: > Dear fellow xorp_users > > We are trying to move to xorp as a routing platform. We have two public subnets we want to advertise. We currently bring up connections with our peers and accept routes from them, but we do not advertise our connected routes. Instead we advertise routes learned from other peers! It looks like term 90 in your export policy is doing this. I see your AS path prepend, but this term is effectively going to redistribute all routes known to BGP. What happens if you remove this term in test? term 100 looks as though it should redistribute the connected routes you wish to redistribute. thanks BMS > Our config.boot file is attached - we have removed peer details to protect their privacy, but this seems to be an issue with policy only as we are connected to the peers correctly. > > Please Help! > > Thanks > > Tafi Makamure > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From bms at incunabulum.net Thu Jul 23 07:06:41 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 23 Jul 2009 15:06:41 +0100 Subject: [Xorp-users] Config file error In-Reply-To: References: Message-ID: <4A686E71.2060608@incunabulum.net> Hi, Sorry for the long delay in my response, I've been tied up with other tasks. Development questions, which involve walking the code like this can and do fall by the wayside; I apologise. Rae Harbird wrote: > Does anyone know what kind of configuration file error might cause > this message or give me some hints about how to debug it? Please note: > the rubi module depends on olsr which starts up successfully beforehand. * I'm not too familiar with the Router Manager internals, but I'll give this my best shot. * I'm going to assume that the XIF was parsed by clnt-gen.py and tgt-gen.py OK. * The configuration file, and template file, look sane on a first reading. > > [ 2009/07/03 18:03:28 ERROR xorp_rtrmgr:30310 RTRMGR +691 > master_conf_tree.cc commit_pass2_done ] Commit failed: Can't validate > config ready of process rubi > [ 2009/07/03 18:03:28 ERROR xorp_rtrmgr:30310 RTRMGR +261 > master_conf_tree.cc config_done ] Configuration failed: Can't validate > config ready of process rubi Looking at the code, it appears that the error message is triggered in rtrmgr/task.cc, Task::step2_3_done(). This callback is invoked in response to _config_validation->validate() in that class. I see a bunch of state machines in there, which seem to be there to deal with asynchronous process startup, in a fairly generic, non-UNIX-specific, way. The most likely explanation is that the xorp_rubi executable cannot be run. To my mind, the error messages in task.cc are obtuse, and difficult to understand. If the process can't be run, the Router Manager should be much smarter about diagnosis. Questions: * Is runtime linkage for the rubi process OK? * Verify this with ldd. It's entirely possible that if you have LD_RUN_PATH or LD_LIBRARY_PATH set, or if you are running with shared libraries (possibly missing or misdirected), or if there is some other runtime linker problem (e.g. 32 bit vs 64 bit thunks) when the executable is invoked. * Have you tried writing a shell script wrapper to profile the process invocation? * Typically I would use this technique for doing valgrind runs for leak testing 'in place'. * If you look at olsr4.tp in the shipping XORP 1.6 tarball, you'll see a commented out reference to such a shell script wrapper. Please let us know what platform you're working with when reporting problems like this, it greatly helps us to pin down possible causes. thanks, BMS From yangqqh at gmail.com Sat Jul 25 13:51:35 2009 From: yangqqh at gmail.com (Qihua Yang) Date: Sat, 25 Jul 2009 16:51:35 -0400 Subject: [Xorp-users] install problem Message-ID: Hi, I got some problem when I tried to install xorp. I always got some information sounds like there is some kind of problem about router manager. Below is the log information. Is there anybody can give me? Thanks a lot. root at yangqqh-desktop:/home/yangqqh/Desktop/xorp-1.6# xorpsh Waiting for xorp_rtrmgr... [ 2009/07/25 16:43:54 ERROR xorpsh:10046 RTRMGR +91 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2009/07/25 16:43:54 ERROR xorpsh:10046 RTRMGR +908 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager Thanks, Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090725/720fd767/attachment.html From bms at incunabulum.net Sat Jul 25 14:24:23 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 25 Jul 2009 22:24:23 +0100 Subject: [Xorp-users] install problem In-Reply-To: References: Message-ID: <4A6B7807.9020909@incunabulum.net> Qihua Yang wrote: > Hi, > > I got some problem when I tried to install xorp. I always got some > information sounds like there is some kind of problem about router > manager. Below is the log information. Is there anybody can give me? > Thanks a lot. > > root at yangqqh-desktop:/home/yangqqh/Desktop/xorp-1.6# xorpsh > Waiting for xorp_rtrmgr... > [ 2009/07/25 16:43:54 ERROR xorpsh:10046 RTRMGR +91 xorpsh_main.cc > wait_for_xrl_router_ready ] XrlRouter failed. No Finder? > [ 2009/07/25 16:43:54 ERROR xorpsh:10046 RTRMGR +908 xorpsh_main.cc > main ] xorpsh exiting due to an init error: Failed to connect to the > router manager Have you written a configuation file for XORP, and is the Router Manager process (xorp_rtrmgr) actually running? There are init scripts for various distributions (Debian, FreeBSD etc) which will start the Router Manager like any other UNIX daemon or service, however all of them require you to write a configuration file first. Without a Router Manager process running, the xorpsh will not run. Usually, the xorpsh tries to connect to the Router Manager over local TCP loopback sockets, so you may wish to check the output of 'netstat -an' to be sure that it is listening on port 19999. In Linux, the 'ss' command is also useful for this. thanks, BMS From yangqqh at gmail.com Sun Jul 26 03:37:42 2009 From: yangqqh at gmail.com (Qihua Yang) Date: Sun, 26 Jul 2009 06:37:42 -0400 Subject: [Xorp-users] install problem In-Reply-To: <4A6B7807.9020909@incunabulum.net> References: <4A6B7807.9020909@incunabulum.net> Message-ID: Hi, I wrote a configuration file. And I checked online. Someone suggest to use empty config.boot. I tried both of them. They didn't work. I still got that information I showed you last email. I tried the command you suggest me to do. There is no process listen on port 19999. How to fix it? Thanks a lot. And after I installed xorp, I ran xorp_rtrmgr, it showed "Failed to open config file: /usr/lib/xorp/config.boot". There is no any configure file in there. Is that configure file you mentioned? I put my configure file into there. It can run. but stop in "No more tasks to run". root at yangqqh-desktop:/home/yangqqh/Desktop/xorp-1.6# xorp_rtrmgr [ 2009/07/25 17:03:31 INFO xorp_rtrmgr:10318 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: [ 2009/07/25 17:03:31 INFO xorp_rtrmgr:10318 RTRMGR +2228 task.cc run_task ] No more tasks to run Thanks a lot for anybody's help. Below is the configure file I used. interfaces { interface dc0 { vif dc0 { address 10.10.10.10 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false } } protocols { static { route 10.30.0.0/16 { next-hop: 10.10.10.20 } } } Thanks, Yang On Sat, Jul 25, 2009 at 5:24 PM, Bruce Simpson wrote: > Qihua Yang wrote: > >> Hi, >> >> I got some problem when I tried to install xorp. I always got some >> information sounds like there is some kind of problem about router manager. >> Below is the log information. Is there anybody can give me? Thanks a lot. >> >> root at yangqqh-desktop:/home/yangqqh/Desktop/xorp-1.6# xorpsh >> Waiting for xorp_rtrmgr... >> [ 2009/07/25 16:43:54 ERROR xorpsh:10046 RTRMGR +91 xorpsh_main.cc >> wait_for_xrl_router_ready ] XrlRouter failed. No Finder? >> [ 2009/07/25 16:43:54 ERROR xorpsh:10046 RTRMGR +908 xorpsh_main.cc main >> ] xorpsh exiting due to an init error: Failed to connect to the router >> manager >> > > Have you written a configuation file for XORP, and is the Router Manager > process (xorp_rtrmgr) actually running? > > There are init scripts for various distributions (Debian, FreeBSD etc) > which will start the Router Manager like any other UNIX daemon or service, > however all of them require you to write a configuration file first. > > Without a Router Manager process running, the xorpsh will not run. Usually, > the xorpsh tries to connect to the Router Manager over local TCP loopback > sockets, so you may wish to check the output of 'netstat -an' to be sure > that it is listening on port 19999. In Linux, the 'ss' command is also > useful for this. > > thanks, > BMS > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090726/9f620918/attachment.html From bms at incunabulum.net Sun Jul 26 09:13:46 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 26 Jul 2009 17:13:46 +0100 Subject: [Xorp-users] install problem In-Reply-To: References: <4A6B7807.9020909@incunabulum.net> Message-ID: <4A6C80BA.9060506@incunabulum.net> Qihua Yang wrote: > Hi, > > I wrote a configuration file. And I checked online. Someone suggest to > use empty config.boot. I tried both of them. They didn't work. I still > got that information I showed you last email. > I tried the command you suggest me to do. There is no process listen > on port 19999. How to fix it? Thanks a lot. Which platform(s) are you attempting to run XORP on? Are you building from source, or using a distribution's package or port? Are you trying to run XORP from the compilation directory? Does your system have a dc0 interface? From yangqqh at gmail.com Sun Jul 26 09:53:30 2009 From: yangqqh at gmail.com (Qihua Yang) Date: Sun, 26 Jul 2009 12:53:30 -0400 Subject: [Xorp-users] install problem In-Reply-To: <4A6C80BA.9060506@incunabulum.net> References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> Message-ID: I tried again, to run xorp_rtrmgr first. Close that terminal. And open another terminal to run xorpsh. It can work. I saw "Welcome to XORP on yangqqh-desktop" Is it correct process? But one more question. I cannot use configure mode.... BTW, the system doesn't have dc0 interface. I have changed it to eth0. Thanks a lot. Thanks, Yang On Sun, Jul 26, 2009 at 12:13 PM, Bruce Simpson wrote: > Qihua Yang wrote: > >> Hi, >> >> I wrote a configuration file. And I checked online. Someone suggest to use >> empty config.boot. I tried both of them. They didn't work. I still got that >> information I showed you last email. >> I tried the command you suggest me to do. There is no process listen on >> port 19999. How to fix it? Thanks a lot. >> > > Which platform(s) are you attempting to run XORP on? > Are you building from source, or using a distribution's package or port? > Are you trying to run XORP from the compilation directory? > Does your system have a dc0 interface? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090726/acd577f9/attachment.html From yangqqh at gmail.com Sun Jul 26 10:29:38 2009 From: yangqqh at gmail.com (Qihua Yang) Date: Sun, 26 Jul 2009 13:29:38 -0400 Subject: [Xorp-users] install problem In-Reply-To: References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> Message-ID: I have joined the group xorp. But I still cannot run in configure mode. Is there anybody help me? yangqqh at yangqqh-desktop:~$ whoami yangqqh yangqqh at yangqqh-desktop:~$ groups yangqqh xorp yangqqh at yangqqh-desktop:~$ xorpsh Welcome to XORP on yangqqh-desktop yangqqh at yangqqh-desktop> configure ERROR: You do not have permission for this operation. yangqqh at yangqqh-desktop> Thanks, Yang On Sun, Jul 26, 2009 at 12:53 PM, Qihua Yang wrote: > I tried again, to run xorp_rtrmgr first. Close that terminal. And open > another terminal to run xorpsh. It can work. I saw "Welcome to XORP on > yangqqh-desktop" > Is it correct process? > But one more question. I cannot use configure mode.... > BTW, the system doesn't have dc0 interface. I have changed it to eth0. > Thanks a lot. > > Thanks, > > Yang > > > > On Sun, Jul 26, 2009 at 12:13 PM, Bruce Simpson wrote: > >> Qihua Yang wrote: >> >>> Hi, >>> >>> I wrote a configuration file. And I checked online. Someone suggest to >>> use empty config.boot. I tried both of them. They didn't work. I still got >>> that information I showed you last email. >>> I tried the command you suggest me to do. There is no process listen on >>> port 19999. How to fix it? Thanks a lot. >>> >> >> Which platform(s) are you attempting to run XORP on? >> Are you building from source, or using a distribution's package or port? >> Are you trying to run XORP from the compilation directory? >> Does your system have a dc0 interface? >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090726/17dd5643/attachment.html From bms at incunabulum.net Sun Jul 26 10:42:43 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 26 Jul 2009 18:42:43 +0100 Subject: [Xorp-users] install problem In-Reply-To: References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> Message-ID: <4A6C9593.4040800@incunabulum.net> Qihua Yang wrote: > I have joined the group xorp. But I still cannot run in configure > mode. Is there anybody help me? > You need to add yourself to group 'xorp' if it does not already exist on your system, please refer to the documentation: http://www.xorp.org/getting_started.html http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-August/000751.html If you use a pre-packaged build of XORP (e.g. for Debian or FreeBSD) the packaging system will do this for you. thanks, BMS From emixp at gmx.net Mon Jul 27 00:32:14 2009 From: emixp at gmx.net (=?iso-8859-1?Q?=22Emanuel_J=F6bstl=22?=) Date: Mon, 27 Jul 2009 09:32:14 +0200 Subject: [Xorp-users] configure round-robin load balancing Message-ID: <20090727073214.78970@gmx.net> Hey there Is it possible to configure some sort of round-robin load balancing in XORP? for example that if there are two routes with the metrics 11 and 15, the router should forward the traffic two times to the route with the low cost and one time to the high-cost route? cheers, Emanuel -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser From bms at incunabulum.net Mon Jul 27 07:43:47 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 27 Jul 2009 15:43:47 +0100 Subject: [Xorp-users] configure round-robin load balancing In-Reply-To: <20090727073214.78970@gmx.net> References: <20090727073214.78970@gmx.net> Message-ID: <4A6DBD23.8080907@incunabulum.net> Emanuel J?bstl wrote: > Hey there > > Is it possible to configure some sort of round-robin load balancing in XORP? > > for example that if there are two routes with the metrics 11 and 15, the router should forward the traffic two times to the route with the low cost and one time to the high-cost route? > The FEA and RIB currently does not support equal-cost multi-hop. Patches for this would be gratefully accepted. thanks BMS From bms at incunabulum.net Mon Jul 27 08:03:48 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 27 Jul 2009 16:03:48 +0100 Subject: [Xorp-users] configure round-robin load balancing In-Reply-To: <4A6DBD23.8080907@incunabulum.net> References: <20090727073214.78970@gmx.net> <4A6DBD23.8080907@incunabulum.net> Message-ID: <4A6DC1D4.6010401@incunabulum.net> Bruce Simpson wrote: > Emanuel J?bstl wrote: > >> Hey there >> >> Is it possible to configure some sort of round-robin load balancing in XORP? >> >> for example that if there are two routes with the metrics 11 and 15, the router should forward the traffic two times to the route with the low cost and one time to the high-cost route? >> >> > > The FEA and RIB currently does not support equal-cost multi-hop. > Patches for this would be gratefully accepted. > Sorry: let me rephrase; This level of interaction between the RIB, FEA and host forwarding plane isn't supported. It is a function of the forwarding plane. Whilst the RIB supports metrics in the final table(s) pushed to the FEA, it would be necessary to add some platform-independent means of configuring this round-robining behaviour to the FEA. This class of feature is congruent with the changes which would be necessary to support ECMP. thanks BMS From bms at incunabulum.net Mon Jul 27 08:13:22 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 27 Jul 2009 16:13:22 +0100 Subject: [Xorp-users] install problem In-Reply-To: <4A6C9593.4040800@incunabulum.net> References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> <4A6C9593.4040800@incunabulum.net> Message-ID: <4A6DC412.2030601@incunabulum.net> Bruce Simpson wrote: > Qihua Yang wrote: > >> I have joined the group xorp. But I still cannot run in configure >> mode. Is there anybody help me? >> >> > > You need to add yourself to group 'xorp' if it does not already exist on > your system, please refer to the documentation: Sorry, it sounds like you've already done that. Please remember that most UNIX systems require you log out and log back in for changes to the group database to be seen in the current session. Have you looked at the code which contains the error message about permissions, to see where the permission check is implemented? I'm not too familiar with the Router Manager internals. I'm sure the answer is probably an FAQ, so you might wish to check the mailing list archives. Sorry I can't be of more help with your issue at the moment. FWIW I usually run both xorpsh and xorp_rtrmgr as root, just for convenience during development. I believe xorpsh as a normal user should work, however you may run into issues with path permissions for 'save', 'load' etc. thanks, BMS From greearb at candelatech.com Mon Jul 27 08:37:09 2009 From: greearb at candelatech.com (Ben Greear) Date: Mon, 27 Jul 2009 08:37:09 -0700 Subject: [Xorp-users] install problem In-Reply-To: <4A6C9593.4040800@incunabulum.net> References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> <4A6C9593.4040800@incunabulum.net> Message-ID: <4A6DC9A5.9040306@candelatech.com> Bruce Simpson wrote: > Qihua Yang wrote: > >> I have joined the group xorp. But I still cannot run in configure >> mode. Is there anybody help me? >> >> > > You need to add yourself to group 'xorp' if it does not already exist on > your system, please refer to the documentation: > http://www.xorp.org/getting_started.html > Any reason to keep this requirement? If they have OS user permissions to do routing stuff, shouldn't they just be allowed to run? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Mon Jul 27 08:59:06 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon, 27 Jul 2009 16:59:06 +0100 Subject: [Xorp-users] install problem In-Reply-To: <4A6DC9A5.9040306@candelatech.com> References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> <4A6C9593.4040800@incunabulum.net> <4A6DC9A5.9040306@candelatech.com> Message-ID: <4A6DCECA.9050706@incunabulum.net> Ben Greear wrote: > Any reason to keep this requirement? If they have OS user permissions > to do routing > stuff, shouldn't they just be allowed to run? My best guess is that a group ID check was chosen, as this is the most portable means, between UNIX-like systems, of ensuring a user has appropriate privileges. Most systems will only allow root to manipulate the routing table, so the use of group xorp seems reasonable. thanks BMS From greearb at candelatech.com Mon Jul 27 09:25:56 2009 From: greearb at candelatech.com (Ben Greear) Date: Mon, 27 Jul 2009 09:25:56 -0700 Subject: [Xorp-users] install problem In-Reply-To: <4A6DCECA.9050706@incunabulum.net> References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> <4A6C9593.4040800@incunabulum.net> <4A6DC9A5.9040306@candelatech.com> <4A6DCECA.9050706@incunabulum.net> Message-ID: <4A6DD514.8090506@candelatech.com> On 07/27/2009 08:59 AM, Bruce Simpson wrote: > Ben Greear wrote: >> Any reason to keep this requirement? If they have OS user permissions >> to do routing >> stuff, shouldn't they just be allowed to run? > > My best guess is that a group ID check was chosen, as this is the most > portable means, between UNIX-like systems, of ensuring a user has > appropriate privileges. Most systems will only allow root to manipulate > the routing table, so the use of group xorp seems reasonable. This only checks the client process, right? If so, is there anything that would keep a user from running xorpsh on a separate machine (or VM) and connecting to the main xorp processes remotely? Thanks, Ben > > thanks > BMS -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Tue Jul 28 10:09:49 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue, 28 Jul 2009 18:09:49 +0100 Subject: [Xorp-users] install problem In-Reply-To: <4A6DD514.8090506@candelatech.com> References: <4A6B7807.9020909@incunabulum.net> <4A6C80BA.9060506@incunabulum.net> <4A6C9593.4040800@incunabulum.net> <4A6DC9A5.9040306@candelatech.com> <4A6DCECA.9050706@incunabulum.net> <4A6DD514.8090506@candelatech.com> Message-ID: <4A6F30DD.5080800@incunabulum.net> Ben Greear wrote: > ... > This only checks the client process, right? > > If so, is there anything that would keep a user from running xorpsh on > a separate machine (or VM) > and connecting to the main xorp processes remotely? I don't recall the specifics -- I haven't had to work with the Router Manager code itself in that level of depth since the Windows port, where the xorpsh didn't actually run on Windows natively due to the libtecla dependencies. However, you can run the xorpsh on a separate host, this was the original motivation behind splitting up security model checks on client vs server. The ultimate reference is, of course, the code... Most likely, in the XRL respin, this behaviour may be broken to begin with. The primary use case is xorpsh + processes on same box. I am agnostic about the value of this kind of para-virtualization, given that full system image virtualization is now commodified; but I can see why people would want to do it. It's just difficult to support with the resources currently available, and where people's interest lies. thanks, BMS From tafim at itinsideout.com Wed Jul 29 04:06:50 2009 From: tafim at itinsideout.com (Tafi Makamure) Date: Wed, 29 Jul 2009 12:06:50 +0100 Subject: [Xorp-users] XORP Crash Message-ID: Hi All, I recently had a crash/fail on me in a live system and am trying to find out what the cause was. Restarting XORP resolved the issue however I am trying to get to the bottom of cause. I got the following events in the xorp logs. [ 2009/07/29 02:14:23 FATAL xorp_bgp:4665 BGP +200 socket.cc connect ] Assertion (!get_sock().is_valid()) failed [ 2009/07/29 02:14:23 ERROR xorp_rib:4662 LIBXORP +226 buffered_asyncio.cc io_event ] read error 104 [ 2009/07/29 02:14:23 ERROR xorp_rib:4662 XRL +169 xrl_pf_stcp.cc read_event ] Read failed (error = 104) [ 2009/07/29 02:14:23 ERROR xorp_rib:4662 XRL +378 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error [ 2009/07/29 02:14:23 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp EGP next table = Merged:(ebgp)+(ibgp) [ 2009/07/29 02:14:23 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp EGP next table = Merged:(ebgp)+(ibgp) [ 2009/07/29 02:14:23 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp EGP next table = Merged:(ebgp)+(ibgp) [ 2009/07/29 02:14:23 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp EGP next table = Merged:(ebgp)+(ibgp) I subsequently got the following errors continually. [ 2009/07/29 10:20:44 INFO xorp_rtrmgr:4653 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp [ 2009/07/29 10:20:44 WARNING xorp_rtrmgr:4653 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "bgp" does not exist or is not enabled. [ 2009/07/29 10:20:44 WARNING xorp_rtrmgr:4653 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "bgp" does not exist or is not enabled. [ 2009/07/29 10:20:45 INFO xorp_rtrmgr:4653 RTRMGR +176 module_manager.cc terminate ] Terminating module: bgp [ 2009/07/29 10:20:45 INFO xorp_rtrmgr:4653 RTRMGR +199 module_manager.cc terminate ] Killing module: bgp [ 2009/07/29 10:20:47 INFO xorp_rtrmgr:4653 RTRMGR +238 module_manager.cc terminate_with_prejudice ] Killing module with prejudice: bgp [ 2009/07/29 10:20:49 INFO xorp_rtrmgr:4653 RTRMGR +1024 task.cc shutdown ] Shutting down module: static_routes [ 2009/07/29 10:20:50 WARNING xorp_rtrmgr:4653 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "static_routes" does not exist or is not enabled. [ 2009/07/29 10:20:51 INFO xorp_rtrmgr:4653 RTRMGR +176 module_manager.cc terminate ] Terminating module: static_routes [ 2009/07/29 10:20:51 INFO xorp_rtrmgr:4653 RTRMGR +199 module_manager.cc terminate ] Killing module: static_routes [ 2009/07/29 10:20:53 INFO xorp_rtrmgr:4653 RTRMGR +238 module_manager.cc terminate_with_prejudice ] Killing module with prejudice: static_routes [ 2009/07/29 10:20:55 INFO xorp_rtrmgr:4653 RTRMGR +1024 task.cc shutdown ] Shutting down module: policy [ 2009/07/29 10:20:55 INFO xorp_rtrmgr:4653 XRL +448 xrl_router.cc get_sender ] Sender died (protocol = "stcp", address = "127.0.0.1:39145") [ 2009/07/29 10:20:55 ERROR xorp_rtrmgr:4653 LIBXORP +714 asyncio.cc complete_transfer ] Write error 111 [ 2009/07/29 10:20:55 ERROR xorp_rtrmgr:4653 XRL +720 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: write failed [ 2009/07/29 10:20:56 INFO xorp_rtrmgr:4653 RTRMGR +176 module_manager.cc terminate ] Terminating module: policy [ 2009/07/29 10:20:56 INFO xorp_rtrmgr:4653 RTRMGR +199 module_manager.cc terminate ] Killing module: policy [ 2009/07/29 10:20:58 INFO xorp_rtrmgr:4653 RTRMGR +238 module_manager.cc terminate_with_prejudice ] Killing module with prejudice: policy [ 2009/07/29 10:21:00 INFO xorp_rtrmgr:4653 RTRMGR +1024 task.cc shutdown ] Shutting down module: rib [ 2009/07/29 10:21:01 WARNING xorp_rtrmgr:4653 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does not exist or is not enabled. [ 2009/07/29 10:21:02 INFO xorp_rtrmgr:4653 RTRMGR +176 module_manager.cc terminate ] Terminating module: rib [ 2009/07/29 10:21:02 INFO xorp_rtrmgr:4653 RTRMGR +199 module_manager.cc terminate ] Killing module: rib [ 2009/07/29 10:21:04 INFO xorp_rtrmgr:4653 RTRMGR +238 module_manager.cc terminate_with_prejudice ] Killing module with prejudice: rib [ 2009/07/29 10:21:09 INFO xorp_rtrmgr:4653 RTRMGR +176 module_manager.cc terminate ] Terminating module: fea [ 2009/07/29 10:21:12 INFO xorp_rtrmgr:4653 RTRMGR +176 module_manager.cc terminate ] Terminating module: firewall [ 2009/07/29 10:21:12 INFO xorp_rtrmgr:4653 RTRMGR +1024 task.cc shutdown ] Shutting down module: interfaces [ 2009/07/29 10:21:12 INFO xorp_fea MFEA ] CLI stopped [ 2009/07/29 10:21:12 INFO xorp_fea MFEA ] CLI stopped [ 2009/07/29 10:21:13 WARNING xorp_rtrmgr:4653 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2009/07/29 10:21:14 INFO xorp_rtrmgr:4653 RTRMGR +176 module_manager.cc terminate ] Terminating module: interfaces [ 2009/07/29 10:21:14 INFO xorp_rtrmgr:4653 RTRMGR +199 module_manager.cc terminate ] Killing module: interfaces [ 2009/07/29 10:21:16 INFO xorp_rtrmgr:4653 RTRMGR +238 module_manager.cc terminate_with_prejudice ] Killing module with prejudice: interfaces [ 2009/07/29 10:21:18 INFO xorp_rtrmgr:4653 RTRMGR +2233 task.cc run_task ] No more tasks to run Any ideas? Regards Tafi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090729/410fa427/attachment.html From bms at incunabulum.net Wed Jul 29 09:42:27 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 29 Jul 2009 17:42:27 +0100 Subject: [Xorp-users] XORP Crash In-Reply-To: References: Message-ID: <4A707BF3.3040103@incunabulum.net> Tafi Makamure wrote: > > Hi All, > > > > I recently had a crash/fail on me in a live system and am trying to > find out what the cause was. Restarting XORP resolved the issue > however I am trying to get to the bottom of cause. > > > > I got the following events in the xorp logs. > > > > /[ 2009/07/29 02:14:23 FATAL xorp_bgp:4665 BGP +200 socket.cc connect > ] Assertion (!get_sock().is_valid()) failed/ > BGP is the only XORP routing process which directly manages its own sockets. Something has caused one of the live sockets in the BGP process to die. This error message pins down the assertion failure to line 200 in socket.cc; SocketClient::connect(). XORP was initially developed on FreeBSD, which is a UNIX-like system, so it is very possible that some of the code in BGP which directly uses sockets, is assuming that the file descriptor(s) can be recycled. Checking svn annotate, this change is one of mine, from the Win32 merge 3 years ago. We've formally dropped Windows support now -- the recycling of sockets in BGP was an issue with the Winsock socket library, and the paranoid assertion on line 200 to catch this is being triggered somehow. It would be good to get a root cause analysis on the condition. Points to consider: * Do you have any other logs from the BGP process? * A core dump or GDB backtrace would be really helpful. * Was BGP trying to re-establish a dropped connection with a remote BGP peer at the time? * Can you please try commenting out line 200 of bgp/socket.cc with the C++ '//' one-line comment? That would be the best workaround for now. > // > > /[ 2009/07/29 02:14:23 ERROR xorp_rib:4662 LIBXORP +226 > buffered_asyncio.cc io_event ] read error 104/ > The BufferedAsyncReader class isn't actually used anywhere outside of XRL. The following messages are fallout from the RIB, which BGP interacts directly with, noticing that BGP has disappeared. > // > > /[ 2009/07/29 02:14:23 ERROR xorp_rib:4662 XRL +169 xrl_pf_stcp.cc > read_event ] Read failed (error = 104)/ > The remaining messages are just fallout from the RIB picking up that BGP has died, followed by the Router Manager. thanks BMS From bms at incunabulum.net Wed Jul 29 09:51:12 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 29 Jul 2009 17:51:12 +0100 Subject: [Xorp-users] XORP Crash In-Reply-To: <4A707BF3.3040103@incunabulum.net> References: <4A707BF3.3040103@incunabulum.net> Message-ID: <4A707E00.6030107@incunabulum.net> Bruce Simpson wrote: > BGP is the only XORP routing process which directly manages its own > sockets. > Something has caused one of the live sockets in the BGP process > to die. Sorry, this should read: a socket is already opened by BGP for communication with a remote peer, and an assertion to catch this condition is being triggered: > This error message pins down the assertion failure to line 200 > in socket.cc; SocketClient::connect(). > The condition may be benign on UNIX platforms, the paranoid assertion only existed to catch problems with Winsock, where we map each socket directly onto a Win32 'Event' object. Leaking Events is really bad, it is a non-issue for other platforms, because they don't have 'Event' objects. thanks BMS From bms at incunabulum.net Wed Jul 29 11:27:35 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed, 29 Jul 2009 19:27:35 +0100 Subject: [Xorp-users] Announcement: End-of-life on Windows support in XORP community branch In-Reply-To: <4A537C10.2000204@incunabulum.net> References: <4A537C10.2000204@incunabulum.net> Message-ID: <4A709497.90001@incunabulum.net> Bruce Simpson wrote: > ... > There are no free [1] toolchains available for systems-level C/C++ > development on the Windows platform at the moment, apart from MinGW. > This is a big factor in this decision. > > Unfortunately, whilst I've personally raised the issue with both the > SUA/Interix community, and the Microsoft technical leads for Windows > Networking, I have received no replies from either of them. See here: > http://www.suacommunity.com/forum/tm.aspx?m=16790 > http://www.suacommunity.com/forum/Default.aspx > > http://www.surveymonkey.com/sr.aspx?sm=BTQe0euUEEB40X_2fdXg5mOtRGmb_2bcU2sVnn6cLg44Qxk_3d > > An official announcement about this matter from Microsoft is still pending. > If you check the SUA Community site again now, it seems Microsoft have given them something of a reprieve -- for now. Again, for how long Microsoft's support of SUA will continue, is undecided and unknown, and they have not formalized that commitment beyond what SUA Community themselves have heard. Regardless, our decision to end-of-life Windows support still stands. It would be ideal if we could get patches pushed back to MinGW, or otherwise see the XORP code build with a well-supported C++ compiler on the Windows platform. The work to do this, in community XORP's current state, isn't too difficult; it just needs someone to step up and do it. However, it is very likely that Windows support will be broken by future changes to the XORP stack. Portability is an issue which would have to be revisited by any interested party after the refactoring, and ongoing participation would be essential to such an effort. Should a user or client come forward, who is willing to take on the work of Windows platform support, or otherwise sponsor or conduct such work, then this decision may be re-considered. thanks, BMS From appletrp at gmail.com Thu Jul 30 06:09:40 2009 From: appletrp at gmail.com (Robert Appleton) Date: Thu, 30 Jul 2009 09:09:40 -0400 Subject: [Xorp-users] Virtualizing Xorp Message-ID: I am trying to run Xorp in a VM on my network. I'm using a basic static route between computers on a switch (this is still just for testing purposes). The VM can ping the other computers on the network. When I start the router it replys from the gateway (192.168.1.1 // 192.168.2.1) but says destination host unavailable when it tries to reach the actual computer it's pinging. Is there anything I need to change for running xorp in a VM? (I have this setup working when it is running on a physical machine outside the VM) Thanks. - Robert Appleton appletrp at gmail.com From bms at incunabulum.net Thu Jul 30 11:30:04 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu, 30 Jul 2009 19:30:04 +0100 Subject: [Xorp-users] Virtualizing Xorp In-Reply-To: References: Message-ID: <4A71E6AC.40104@incunabulum.net> Robert Appleton wrote: > I am trying to run Xorp in a VM on my network. I'm using a basic > static route between computers on a switch (this is still just for > testing purposes). The VM can ping the other computers on the network. > When I start the router it replys from the gateway (192.168.1.1 // > 192.168.2.1) but says destination host unavailable when it tries to > reach the actual computer it's pinging. Is there anything I need to > change for running xorp in a VM? (I have this setup working when it is > running on a physical machine outside the VM) Thanks. > Not knowing the nature of the VM in use, it's difficult to say. Nothing in XORP should fundamentally change when running in a virtual machine, however VMs can and do vary in how they implement layer 2, as well as the mapping of the VM's network to the host network stack. Some use NAT, others use more low level forms of bridging. It sounds as though you are using a bridged LAN, in which case I would expect to see some issues like this. tcpdump and inspection of the ARP cache (arp -a) are probably the places to start looking, be sure that the VM is sending and receiving ARP traffic for the neighbor it's trying to reach. thanks, BMS > - Robert Appleton > appletrp at gmail.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >