From happymonkey@gmx.de Wed Feb 2 03:45:24 2005 From: happymonkey@gmx.de (Monkey) Date: Wed, 02 Feb 2005 04:45:24 +0100 Subject: [Xorp-hackers] Re: Welcome to the "Xorp-hackers" mailing list In-Reply-To: <200502020323.j123N1Ip009855@fruitcake.ICSI.Berkeley.EDU> References: <200502020323.j123N1Ip009855@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200502020445.24750.happymonkey@gmx.de> xorp-hackers-request@icir.org schrieb am Mittwoch, 2. Februar 2005 04:23: > Welcome to the Xorp-hackers@icir.org mailing list! > > To post to this list, send your email to: > > xorp-hackers@icir.org > > General information about the mailing list is at: > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > > http://mailman.ICSI.Berkeley.EDU/mailman/options/xorp-hackers/happymonkey%4 >0gmx.de > > > You can also make such adjustments via email by sending a message to: > > Xorp-hackers-request@icir.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > punto > > If you forget your password, don't worry, you will receive a monthly > reminder telling you what all your icir.org mailing list passwords > are, and how to unsubscribe or change your options. There is also a > button on your options page that will email your current password to > you. > > You may also have your password mailed to you automatically off of the > Web page noted above. From jmorillo@ac.upc.edu Wed Feb 2 17:37:33 2005 From: jmorillo@ac.upc.edu (=?iso-8859-1?q?Juli=E1n=20David=20=20Morillo=20Pozo?=) Date: Wed, 2 Feb 2005 18:37:33 +0100 Subject: [Xorp-hackers] Problems with flat IP addressing in XORP+Click Message-ID: <200502021837.33123.jmorillo@ac.upc.edu> Hello, We are currently working with XORP+Click for building a router for a wireless ad-hoc environment, that means that we are using flat address (/32). Because of this, we were having some problems and now we think that we understood what is happening. It seems that XORP does not take into consideration this particular case when all addresses are /32. In our scenario we had 2 nodes directly connected (A and B) and a simple protocol running over XORP that exchanges information between them and create the needed routes for them to communicate. We also used a KernelTun element to capture every packet generated by the node and route it according to the Click routing table (since every node in the network is supposed to act as a router and as a host at the same time). Well, the problem arises when we try to ping one node from the other. If we ping node B from node A, node B replies the ping but also sends ICMP redirect error messages. We think that the problem is that when we configure nodes to a flat IP (e.g., 10.0.0.1/32), XORP creates a "connected" route like the one below: Network 10.0.0.1/32 Nexthop := 10.0.0.1 Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 Then, this route is added into the LinearIPLookup click element overwriting the original rule (generated by the awk script) to 10.0.0.1/32 (which is the local delivey). Originally we had: -> _xorp_rt :: LinearIPLookup(10.0.0.1/32 1) // Output 1 is local delivery We suppose that the rule shown above will add a rule telling that 10.0.0.1/32 should go to the output 0 (that represents eth0). As a consequence, the rule above is useless and a ping packet that arrives to this node is sent to the host through Linux (we use userlevel click) and a copy is directed to eth0 (and, since it comes from eth0, an ICMP Redirect Error is generated). We know that in the case of a wireless environment, there is no sense on sending redirect errors, but even though, we think that in the case of /32 IP addresses, this route should not be added to _xorp_rt. Are we right? Cheers, -- ============================================= Julián David Morillo Pozo PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnical University of Catalonia (UPC) Phone: +34-934017182 Fax: +34-934017055 URL: http://people.ac.upc.edu/jmorillo ============================================= From pavlin@icir.org Wed Feb 2 20:18:47 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 02 Feb 2005 12:18:47 -0800 Subject: [Xorp-hackers] Re: Network interface naming In-Reply-To: Message from "G. Paul Ziemba" of "Sun, 30 Jan 2005 13:11:43 GMT." Message-ID: <200502022018.j12KIl8C081619@possum.icir.org> > Kurt J. Lidl wrote: > > While the "renaming" of devices like the example I gave might be nice, > > it might be sufficient to have a interface mapping section of the > > configuration file, where you could map: > > > > device name -> interface "label" > > fxp0 -> fxp000 > > fxp1 -> fxp010 > > fxp2 -> fxp011 > > Others have commented on the difficulty of figuring out the > physical layout _automatically_, so some kind of hand-crafted > mapping makes sense. > > I'd like to see a map file separate from the configuration file; > in this way, it would be possible to for vendors [i.e., anyone > who distributes xorp + hardware] to supply it as part of the system. > > For vendors who have design control over the hardware, they could > always invent some automatic way of generating the mapping. Others > who merely have "selection control" would have the system choose from > a (possibly 1-element) set of mappings. > > Having a map file separate from the config file would keep the > network admins from mistakenly believing that the mapping was free to > be tinkered with (at least to the same degree that the rest of the > configuration is). Interesting. If I understand you correctly, then from XORP perspective the behavior should be: * On startup (or reconfiguration) XORP attempts to read the interface map file from a pre-configured location (or just a default location). * If the map file is there, XORP uses it to figure out the interface naming. Otherwise, it uses the naming as provided by the kernel (in case of UNIX). * The creation of the map file is left to the OS vendors and the vendors who distribute XORP+hardware. I like this idea, because on one hand it gives the flexibility that Kurt described, and on the other hand it doesn't lock us with solving the physical layout problem. About the format of the map file we could try to design a common format of the map file that will be used by the protocol stacks and the OS/hardware vendors. For example, we could start with a simple 1-1 mapping such as (format taken from Kurt's example): -> If we want more flexibility, we may want a format like: [attributes] -> Any takers to design the format? Thanks, Pavlin From pavlin@icir.org Wed Feb 2 21:52:27 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 02 Feb 2005 13:52:27 -0800 Subject: [Xorp-hackers] Problems with flat IP addressing in XORP+Click In-Reply-To: Message from =?iso-8859-1?q?Juli=E1n=20David=20=20Morillo=20Pozo?= of "Wed, 02 Feb 2005 18:37:33 +0100." <200502021837.33123.jmorillo@ac.upc.edu> Message-ID: <200502022152.j12LqRaA082618@possum.icir.org> Julian, Please replace inside fea/fticonfig_entry_set_click.cc all instances of: if (fte.is_connected_route()) ; // XXX: accept directly-connected routes with: if (fte.is_connected_route()) return true; // XXX: don't add/remove directly-connected routes [There should be 4 of them] Apparently, the original xorp_fea_click_config_generator itself also initializes the routing table lookup element with the directly connected routes, and they point to the local-delivery output port. Please let me know if this fixes the problem for you, and then I will apply the change to the code in the CVS repository. Thanks, Pavlin > We are currently working with XORP+Click for building a router for a wireless > ad-hoc environment, that means that we are using flat address (/32). Because > of this, we were having some problems and now we think that we understood > what is happening. It seems that XORP does not take into consideration this > particular case when all addresses are /32. > > In our scenario we had 2 nodes directly connected (A and B) and a simple > protocol running over XORP that exchanges information between them and create > the needed routes for them to communicate. We also used a KernelTun element > to capture every packet generated by the node and route it according to the > Click routing table (since every node in the network is supposed to act as a > router and as a host at the same time). > > Well, the problem arises when we try to ping one node from the other. If we > ping node B from node A, node B replies the ping but also sends ICMP redirect > error messages. We think that the problem is that when we configure nodes to > a flat IP (e.g., 10.0.0.1/32), XORP creates a "connected" route like the one > below: > > Network 10.0.0.1/32 > Nexthop := 10.0.0.1 > Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 > > Then, this route is added into the LinearIPLookup click element overwriting > the original rule (generated by the awk script) to 10.0.0.1/32 (which is the > local delivey). > > Originally we had: > > -> _xorp_rt :: LinearIPLookup(10.0.0.1/32 1) // Output 1 is local delivery > > We suppose that the rule shown above will add a rule telling that 10.0.0.1/32 > should go to the output 0 (that represents eth0). As a consequence, the rule > above is useless and a ping packet that arrives to this node is sent to the > host through Linux (we use userlevel click) and a copy is directed to eth0 > (and, since it comes from eth0, an ICMP Redirect Error is generated). > > We know that in the case of a wireless environment, there is no sense on > sending redirect errors, but even though, we think that in the case of /32 IP > addresses, this route should not be added to _xorp_rt. Are we right? From theo29_1@hotmail.com Wed Feb 9 11:51:17 2005 From: theo29_1@hotmail.com (theo29 the29) Date: Wed, 09 Feb 2005 11:51:17 +0000 Subject: [Xorp-hackers] Questions on the architecture Message-ID: I have two questions on the XORP architecture which I hope someone can answer: 1. The architecture is based on a single threaded event loop, that divides its time doing a select() on all its file descriptors (in the selector list), and executing expired timer events. A select() is one of the more expensive things you can do in the kernel, so I was wondering if you had thought something about the scalability of that approach (for example in terms of number of protocols communicating with the finder server). Did you not consider asynchronous IO? 2. What is the purpose of the SocketServer class. Should protocols not open their own sockets, but rather deligate that to the XRL target implementing the socket4.xif (which I belive is executed in the FEA process now)? Why deligate this task? Best regards Halldor Isak _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From bms@spc.org Wed Feb 9 14:43:40 2005 From: bms@spc.org (Bruce M Simpson) Date: Wed, 9 Feb 2005 14:43:40 +0000 Subject: [Xorp-hackers] Questions on the architecture In-Reply-To: References: Message-ID: <20050209144340.GB10706@empiric.icir.org> On Wed, Feb 09, 2005 at 11:51:17AM +0000, theo29 the29 wrote: > > I have two questions on the XORP architecture which I hope someone can > answer: > > 1. The architecture is based on a single threaded event loop, that divides > its time doing a select() on all its file descriptors (in the selector > list), and executing expired timer events. A select() is one of the more > expensive things you can do in the kernel, so I was wondering if you had > thought something about the scalability of that approach (for example in > terms of number of protocols communicating with the finder server). Did you > not consider asynchronous IO? It entirely depends on what one is doing. Sure, select() can be expensive, but it depends on how one implements it. There are other techniques which fill a similar niche (e.g. BSD's kqueue, SVR4's poll(), Linux/Solaris /dev/poll and so on). In the case of XORP, we aren't dealing with potentially thousands of file descriptors, so the usual performance speed-bumps encountered when dealing with select() and poll() (preparing the file descriptor sets, scanning them, et cetera) aren't an issue. We dont't push gigabytes of data at a time through the control plane, so I don't see how POSIX.1 Asynchronous I/O could help. I should also point out that POSIX.1 AIO implementations vary greatly in their scalability. FreeBSD 5's, for example, all takes place on a single kernel thread shared amongst all AIO client processes. Whilst XORP's EventLoop code could certainly be rewritten to use kqueue() or some other native event multiplexing mechanism, this seems on the face of it to be a micro-optimization, unless one is in a situation where it's totally necessary (e.g. Windows, various RTOS or embedded operating systems). > 2. What is the purpose of the SocketServer class. Should protocols not open > their own sockets, but rather deligate that to the XRL target implementing > the socket4.xif (which I belive is executed in the FEA process now)? Why > deligate this task? Protocols should not open their own sockets. A deliberate design decision was made to delegate socket operations to the FEA in order to make the framework more portable between platforms. In the case of the Windows platform, the use of the SocketServer is going to be important, because of the subtle differences between Winsock 2 and BSD-derived socket implementations which are there to trip you up. There's also the case where XORP could run in an environment which does not support sockets at all, or even kernel-space TCP/UDP, in which case it would be necessary for the FEA to do this work. Regards, BMS From theo29_1@hotmail.com Wed Feb 9 17:18:44 2005 From: theo29_1@hotmail.com (Halldor Isak Gylfason) Date: Wed, 09 Feb 2005 17:18:44 +0000 Subject: [Xorp-hackers] Questions on the architecture In-Reply-To: <20050209144340.GB10706@empiric.icir.org> Message-ID: It's true that XORP would hardly be dealing with thousands of open file descriptor, so this is probably not an issue. It's also true that it the cost of select depends on the implementation, however the interface itself is a limit to how effective an implementation can be. An effective select-like implementation would of course keep the set of file descriptors in kernel space, so you wouldn't have to copy all of them to the kernel on each call and perform the scan. The select interface however kind of insists on this copying and scanning. Having the sockets opened only in FEA makes sense in light of what you are trying to accomplish design-wise. You could of course accomplish the same thing through a generic shared library, which would avoid the cost of the indirection of the FEA, but as you pointed out you are not pushing gigabytes of data, so this hardly matters. Thanks for your answers, Halldor isak >From: Bruce M Simpson >To: theo29 the29 >CC: xorp-hackers@icir.org >Subject: Re: [Xorp-hackers] Questions on the architecture >Date: Wed, 9 Feb 2005 14:43:40 +0000 > >On Wed, Feb 09, 2005 at 11:51:17AM +0000, theo29 the29 wrote: > > > > I have two questions on the XORP architecture which I hope someone can > > answer: > > > > 1. The architecture is based on a single threaded event loop, that >divides > > its time doing a select() on all its file descriptors (in the selector > > list), and executing expired timer events. A select() is one of the more > > expensive things you can do in the kernel, so I was wondering if you had > > thought something about the scalability of that approach (for example in > > terms of number of protocols communicating with the finder server). Did >you > > not consider asynchronous IO? > >It entirely depends on what one is doing. > >Sure, select() can be expensive, but it depends on how one implements it. >There are other techniques which fill a similar niche (e.g. BSD's kqueue, >SVR4's poll(), Linux/Solaris /dev/poll and so on). > >In the case of XORP, we aren't dealing with potentially thousands >of file descriptors, so the usual performance speed-bumps encountered >when dealing with select() and poll() (preparing the file descriptor sets, >scanning them, et cetera) aren't an issue. > >We dont't push gigabytes of data at a time through the control plane, >so I don't see how POSIX.1 Asynchronous I/O could help. > >I should also point out that POSIX.1 AIO implementations vary greatly >in their scalability. FreeBSD 5's, for example, all takes place on a >single kernel thread shared amongst all AIO client processes. > >Whilst XORP's EventLoop code could certainly be rewritten to use >kqueue() or some other native event multiplexing mechanism, this >seems on the face of it to be a micro-optimization, unless one is >in a situation where it's totally necessary (e.g. Windows, various >RTOS or embedded operating systems). > > > 2. What is the purpose of the SocketServer class. Should protocols not >open > > their own sockets, but rather deligate that to the XRL target >implementing > > the socket4.xif (which I belive is executed in the FEA process now)? Why > > deligate this task? > >Protocols should not open their own sockets. A deliberate design decision >was made to delegate socket operations to the FEA in order to make the >framework more portable between platforms. > >In the case of the Windows platform, the use of the SocketServer is going >to be important, because of the subtle differences between Winsock 2 and >BSD-derived socket implementations which are there to trip you up. > >There's also the case where XORP could run in an environment which does >not support sockets at all, or even kernel-space TCP/UDP, in which case >it would be necessary for the FEA to do this work. > >Regards, >BMS >_______________________________________________ >Xorp-hackers mailing list >Xorp-hackers@icir.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From pavlin@icir.org Wed Feb 9 19:05:34 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 09 Feb 2005 11:05:34 -0800 Subject: [Xorp-hackers] Questions on the architecture In-Reply-To: Message from "Halldor Isak Gylfason" of "Wed, 09 Feb 2005 17:18:44 GMT." Message-ID: <200502091905.j19J5YE5016322@possum.icir.org> > Having the sockets opened only in FEA makes sense in light of what you are > trying to accomplish design-wise. You could of course accomplish the same > thing through a generic shared library, which would avoid the cost of the > indirection of the FEA, but as you pointed out you are not pushing gigabytes > of data, so this hardly matters. Another reason for opening the sockets via the FEA is if you are in the space of building distributed routers where you have a farm of machines. For example, one or several of them would be used for forwarding by running the FEA only, and the rest of the machines would be used only for computations by running the protocol instances. In that case, you may want the protocol control messages to be transmitted and received via the machines running the FEA, which will act as a proxy for opening the sockets. Regards, Pavlin From a.greenhalgh@cs.ucl.ac.uk Wed Feb 9 19:09:38 2005 From: a.greenhalgh@cs.ucl.ac.uk (Adam Greenhalgh) Date: Wed, 09 Feb 2005 19:09:38 +0000 Subject: [Xorp-hackers] Questions on the architecture In-Reply-To: <200502091905.j19J5YE5016322@possum.icir.org> References: <200502091905.j19J5YE5016322@possum.icir.org> Message-ID: <1107976178.24825.381.camel@cellini.cs.ucl.ac.uk> On Wed, 2005-02-09 at 11:05 -0800, Pavlin Radoslavov wrote: > > Having the sockets opened only in FEA makes sense in light of what you are > > trying to accomplish design-wise. You could of course accomplish the same > > thing through a generic shared library, which would avoid the cost of the > > indirection of the FEA, but as you pointed out you are not pushing gigabytes > > of data, so this hardly matters. > > Another reason for opening the sockets via the FEA is if you are > in the space of building distributed routers where you have a farm > of machines. For example, one or several of them would be used for > forwarding by running the FEA only, and the rest of the machines > would be used only for computations by running the protocol > instances. In that case, you may want the protocol control messages > to be transmitted and received via the machines running the FEA, > which will act as a proxy for opening the sockets. > Using the FEA to allocate sockets makes the task of sand boxing protocols easier, since it is possible through the FEA to rate limit messages to a particular protocol or examine the information passing to a protocol for abnormalities. Adam From jmorillo@ac.upc.edu Wed Feb 16 15:45:43 2005 From: jmorillo@ac.upc.edu (=?iso-8859-1?q?Juli=E1n=20David=20=20Morillo=20Pozo?=) Date: Wed, 16 Feb 2005 16:45:43 +0100 Subject: [Xorp-hackers] Problems linking XORP modifications Message-ID: <200502161645.43202.jmorillo@ac.upc.edu> Hello, First of all, I want to say that what I really have is a linking related problem and not an XORP one, but probably somebody can help me. I'm trying to modify XORP in order to support QoS routing, more precisely, per-flow routing. For this purpose, as a first step, I'm modifying the RIB (the next step will be to modify the FEA). Well, I have added three new files: - xorp/xrl/interfaces/QoS_rib.xif - xorp/rib/QoS_rib.hh - xorp/rib/QoS_rib.cc And I have modified the next ones: - xorp/xrl/targets/rib.tgt - xorp/rib/xrl_target.hh - xorp/rib/xrl_target.cc - xorp/rib/rib_manager.hh - xorp/rib/rib_manager.cc When I run gmake I get linking error messages. The first of them is (I have a lot of them): ====================================================== ./.libs/librib.a(rib_manager.o)(.text+0x12e): In function `RibManager::RibManager[not-in-charge](EventLoop&, XrlStdRouter&, std::basic_string, std::allocator > const&)': /usr/include/g++/bits/stl_tree.h:1002: undefined reference to `RIB_QoS::RIB_QoS[in-charge](RibManager&, EventLoop&)' ====================================================== Following this line is the beginning of my rib_manager.cc file that includes the part of code that I guess is issuing this first error message: =========================================== #include "rib_module.h" #include "libxorp/xorp.h" #include "libxorp/xlog.h" #include "libxorp/debug.h" #include "libxorp/utils.hh" #include "libxipc/xrl_error.hh" #include "xrl/interfaces/finder_event_notifier_xif.hh" #include "rib_manager.hh" #include "redist_xrl.hh" #include "redist_policy.hh" #include "profile_vars.hh" RibManager::RibManager(EventLoop& eventloop, XrlStdRouter& xrl_std_router, const string& fea_target) : _status_code(PROC_NOT_READY), _status_reason("Initializing"), _eventloop(eventloop), _xrl_router(xrl_std_router), _register_server(&_xrl_router), _urib4(UNICAST, *this, _eventloop), _mrib4(MULTICAST, *this, _eventloop), _urib6(UNICAST, *this, _eventloop), _mrib6(MULTICAST, *this, _eventloop), _QoSSrib(*this, _eventloop), // _QoSrib6(*this, _eventloop), _vif_manager(_xrl_router, _eventloop, this, fea_target), _xrl_rib_target(&_xrl_router, _urib4, _mrib4, _urib6, _mrib6, _QoSSrib, _vif_manager, this), _fea_target(fea_target) { _urib4.initialize(_register_server); _mrib4.initialize(_register_server); _urib6.initialize(_register_server); _mrib6.initialize(_register_server); _QoSrib.initialize(_register_server); _QoSrib6.initialize(_register_server); PeriodicTimerCallback cb = callback(this, &RibManager::status_updater); _status_update_timer = _eventloop.new_periodic(1000, cb); initialize_profiling_variables(_profile); } =========================================================== I was thinking on problems with the compiler version but the fact is that XORP without my modifications compiles perfectly so I guess that the problem is on my code but I don't see it. I have tried to do the same for the new QoS_rib that is done for the normal rib. If you need more information, please feel free in asking for it. Any idea or suggestion??? Thanks in advance. -- ============================================= Julián David Morillo Pozo PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnical University of Catalonia (UPC) Phone: +34-934017182 Fax: +34-934017055 URL: http://people.ac.upc.edu/jmorillo ============================================= From pavlin@icir.org Thu Feb 17 01:18:18 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 16 Feb 2005 17:18:18 -0800 Subject: [Xorp-hackers] Problems linking XORP modifications In-Reply-To: Message from =?iso-8859-1?q?Juli=E1n=20David=20=20Morillo=20Pozo?= of "Wed, 16 Feb 2005 16:45:43 +0100." <200502161645.43202.jmorillo@ac.upc.edu> Message-ID: <200502170118.j1H1IIjX053882@possum.icir.org> > Hello, > > First of all, I want to say that what I really have is a linking related > problem and not an XORP one, but probably somebody can help me. > I'm trying to modify XORP in order to support QoS routing, more precisely, > per-flow routing. For this purpose, as a first step, I'm modifying the RIB > (the next step will be to modify the FEA). > Well, I have added three new files: > - xorp/xrl/interfaces/QoS_rib.xif > - xorp/rib/QoS_rib.hh > - xorp/rib/QoS_rib.cc > And I have modified the next ones: > - xorp/xrl/targets/rib.tgt > - xorp/rib/xrl_target.hh > - xorp/rib/xrl_target.cc > - xorp/rib/rib_manager.hh > - xorp/rib/rib_manager.cc > > When I run gmake I get linking error messages. The first of them is (I have a > lot of them): > ====================================================== > ./.libs/librib.a(rib_manager.o)(.text+0x12e): In function > `RibManager::RibManager[not-in-charge](EventLoop&, XrlStdRouter&, > std::basic_string, std::allocator > > const&)': > /usr/include/g++/bits/stl_tree.h:1002: undefined reference to > `RIB_QoS::RIB_QoS[in-charge](RibManager&, EventLoop&)' > ====================================================== Have you defined somewhere the RIB_QoS class, such that one of its constructors should have the appropriate arguments? E.g. template class RIB_QoS { public: RIB_QoS(RibManager& rib_manager, EventLoop& eventloop); ... }; Regards, Pavlin > > Following this line is the beginning of my rib_manager.cc file that includes > the part of code that I guess is issuing this first error message: > > =========================================== > #include "rib_module.h" > > #include "libxorp/xorp.h" > #include "libxorp/xlog.h" > #include "libxorp/debug.h" > #include "libxorp/utils.hh" > > #include "libxipc/xrl_error.hh" > > #include "xrl/interfaces/finder_event_notifier_xif.hh" > > #include "rib_manager.hh" > #include "redist_xrl.hh" > #include "redist_policy.hh" > #include "profile_vars.hh" > > RibManager::RibManager(EventLoop& eventloop, XrlStdRouter& xrl_std_router, > const string& fea_target) > : _status_code(PROC_NOT_READY), > _status_reason("Initializing"), > _eventloop(eventloop), > _xrl_router(xrl_std_router), > _register_server(&_xrl_router), > _urib4(UNICAST, *this, _eventloop), > _mrib4(MULTICAST, *this, _eventloop), > _urib6(UNICAST, *this, _eventloop), > _mrib6(MULTICAST, *this, _eventloop), > _QoSSrib(*this, _eventloop), // > _QoSrib6(*this, _eventloop), > _vif_manager(_xrl_router, _eventloop, this, fea_target), > _xrl_rib_target(&_xrl_router, _urib4, _mrib4, _urib6, _mrib6, _QoSSrib, > _vif_manager, this), > _fea_target(fea_target) > { > _urib4.initialize(_register_server); > _mrib4.initialize(_register_server); > _urib6.initialize(_register_server); > _mrib6.initialize(_register_server); > _QoSrib.initialize(_register_server); > _QoSrib6.initialize(_register_server); > PeriodicTimerCallback cb = callback(this, &RibManager::status_updater); > _status_update_timer = _eventloop.new_periodic(1000, cb); > initialize_profiling_variables(_profile); > } > =========================================================== > > I was thinking on problems with the compiler version but the fact is that XORP > without my modifications compiles perfectly so I guess that the problem is on > my code but I don't see it. I have tried to do the same for the new QoS_rib > that is done for the normal rib. > If you need more information, please feel free in asking for it. > > Any idea or suggestion??? > Thanks in advance. > > -- > ============================================= > Julián David Morillo Pozo > PhD Student - Computer Networking Group > Department of Computer Architecture (DAC) > Polytechnical University of Catalonia (UPC) > Phone: +34-934017182 Fax: +34-934017055 > URL: http://people.ac.upc.edu/jmorillo > ============================================= > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From jmorillo@ac.upc.edu Thu Feb 17 09:13:57 2005 From: jmorillo@ac.upc.edu (=?iso-8859-15?q?Juli=E1n=20David=20=20Morillo=20Pozo?=) Date: Thu, 17 Feb 2005 10:13:57 +0100 Subject: [Xorp-hackers] Problems linking XORP modifications In-Reply-To: <200502170118.j1H1IIjX053882@possum.icir.org> References: <200502170118.j1H1IIjX053882@possum.icir.org> Message-ID: <200502171013.58009.jmorillo@ac.upc.edu> Hello Pavlin, I have defined it on file "rib_QoS.hh" in this way: ========================================================= template class RIB_QoS { public: /** * RIB_QoS Constructor. * * @param rib_manager the main RIB manager process holding stuff * that's common to all the individual RIBs. * @param eventloop the main event loop. */ RIB_QoS(RibManager& rib_manager, EventLoop& eventloop); ========================================================== And I include this file on the "rib_manager.hh" file, but something doesn't work. Do you (or anybody alse ;-) ) have any other idea? Thanks, El Jueves, 17 de Febrero de 2005 02:18, Pavlin Radoslavov escribió: > > Hello, > > > > First of all, I want to say that what I really have is a linking related > > problem and not an XORP one, but probably somebody can help me. > > I'm trying to modify XORP in order to support QoS routing, more > > precisely, per-flow routing. For this purpose, as a first step, I'm > > modifying the RIB (the next step will be to modify the FEA). > > Well, I have added three new files: > > - xorp/xrl/interfaces/QoS_rib.xif > > - xorp/rib/QoS_rib.hh > > - xorp/rib/QoS_rib.cc > > And I have modified the next ones: > > - xorp/xrl/targets/rib.tgt > > - xorp/rib/xrl_target.hh > > - xorp/rib/xrl_target.cc > > - xorp/rib/rib_manager.hh > > - xorp/rib/rib_manager.cc > > > > When I run gmake I get linking error messages. The first of them is (I > > have a lot of them): > > ====================================================== > > ./.libs/librib.a(rib_manager.o)(.text+0x12e): In function > > `RibManager::RibManager[not-in-charge](EventLoop&, XrlStdRouter&, > > std::basic_string, std::allocator > > > const&)': > > /usr/include/g++/bits/stl_tree.h:1002: undefined reference to > > `RIB_QoS::RIB_QoS[in-charge](RibManager&, EventLoop&)' > > ====================================================== > > Have you defined somewhere the RIB_QoS class, such that one of its > constructors should have the appropriate arguments? > > E.g. > > template > class RIB_QoS { > public: > RIB_QoS(RibManager& rib_manager, EventLoop& eventloop); > ... > }; > > Regards, > Pavlin > > > Following this line is the beginning of my rib_manager.cc file that > > includes the part of code that I guess is issuing this first error > > message: > > > > =========================================== > > #include "rib_module.h" > > > > #include "libxorp/xorp.h" > > #include "libxorp/xlog.h" > > #include "libxorp/debug.h" > > #include "libxorp/utils.hh" > > > > #include "libxipc/xrl_error.hh" > > > > #include "xrl/interfaces/finder_event_notifier_xif.hh" > > > > #include "rib_manager.hh" > > #include "redist_xrl.hh" > > #include "redist_policy.hh" > > #include "profile_vars.hh" > > > > RibManager::RibManager(EventLoop& eventloop, XrlStdRouter& > > xrl_std_router, const string& fea_target) > > > > : _status_code(PROC_NOT_READY), > > > > _status_reason("Initializing"), > > _eventloop(eventloop), > > _xrl_router(xrl_std_router), > > _register_server(&_xrl_router), > > _urib4(UNICAST, *this, _eventloop), > > _mrib4(MULTICAST, *this, _eventloop), > > _urib6(UNICAST, *this, _eventloop), > > _mrib6(MULTICAST, *this, _eventloop), > > _QoSSrib(*this, _eventloop), // > > _QoSrib6(*this, _eventloop), > > _vif_manager(_xrl_router, _eventloop, this, fea_target), > > _xrl_rib_target(&_xrl_router, _urib4, _mrib4, _urib6, _mrib6, > > _QoSSrib, _vif_manager, this), > > _fea_target(fea_target) > > { > > _urib4.initialize(_register_server); > > _mrib4.initialize(_register_server); > > _urib6.initialize(_register_server); > > _mrib6.initialize(_register_server); > > _QoSrib.initialize(_register_server); > > _QoSrib6.initialize(_register_server); > > PeriodicTimerCallback cb = callback(this, > > &RibManager::status_updater); _status_update_timer = > > _eventloop.new_periodic(1000, cb); > > initialize_profiling_variables(_profile); > > } > > =========================================================== > > > > I was thinking on problems with the compiler version but the fact is that > > XORP without my modifications compiles perfectly so I guess that the > > problem is on my code but I don't see it. I have tried to do the same for > > the new QoS_rib that is done for the normal rib. > > If you need more information, please feel free in asking for it. > > > > Any idea or suggestion??? > > Thanks in advance. > > > > -- > > ============================================= > > Julián David Morillo Pozo > > PhD Student - Computer Networking Group > > Department of Computer Architecture (DAC) > > Polytechnical University of Catalonia (UPC) > > Phone: +34-934017182 Fax: +34-934017055 > > URL: http://people.ac.upc.edu/jmorillo > > ============================================= > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- ============================================= Julián David Morillo Pozo PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnical University of Catalonia (UPC) Phone: +34-934017182 Fax: +34-934017055 URL: http://people.ac.upc.edu/jmorillo ============================================= From pavlin@icir.org Thu Feb 17 19:23:03 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 17 Feb 2005 11:23:03 -0800 Subject: [Xorp-hackers] Problems linking XORP modifications In-Reply-To: Message from =?iso-8859-15?q?Juli=E1n=20David=20=20Morillo=20Pozo?= of "Thu, 17 Feb 2005 10:13:57 +0100." <200502171013.58009.jmorillo@ac.upc.edu> Message-ID: <200502171923.j1HJN3dn061875@possum.icir.org> > I have defined it on file "rib_QoS.hh" in this way: > ========================================================= > template > class RIB_QoS { > public: > /** > * RIB_QoS Constructor. > * > * @param rib_manager the main RIB manager process holding stuff > * that's common to all the individual RIBs. > * @param eventloop the main event loop. > */ > RIB_QoS(RibManager& rib_manager, > EventLoop& eventloop); > > ========================================================== > And I include this file on the "rib_manager.hh" file, but something doesn't > work. > Do you (or anybody alse ;-) ) have any other idea? Please confirm that you have the above RIB_QoS constructor implemented in rib_QoS.cc (or somewhere else), and that this file is linked appropriately. Also, at the end of rib_QoS.cc you may want to add the following two lines: template class RIB_QoS; template class RIB_QoS; If this still doesn't help, then please send me an URL with the tarball with your source code and I will have a look at it. Regards, Pavlin From jmorillo@ac.upc.edu Fri Feb 18 14:47:13 2005 From: jmorillo@ac.upc.edu (=?iso-8859-15?q?Juli=E1n=20David=20=20Morillo=20Pozo?=) Date: Fri, 18 Feb 2005 15:47:13 +0100 Subject: [Xorp-hackers] Problems linking XORP modifications In-Reply-To: <200502171923.j1HJN3dn061875@possum.icir.org> References: <200502171923.j1HJN3dn061875@possum.icir.org> Message-ID: <200502181547.13417.jmorillo@ac.upc.edu> For the moment, the problem is solved. (There was a bug on my Makefile). Thanks for the help (probably I will need more in the near future;-) ). El Jueves, 17 de Febrero de 2005 20:23, Pavlin Radoslavov escribió: > > I have defined it on file "rib_QoS.hh" in this way: > > ========================================================= > > template > > class RIB_QoS { > > public: > > /** > > * RIB_QoS Constructor. > > * > > * @param rib_manager the main RIB manager process holding stuff > > * that's common to all the individual RIBs. > > * @param eventloop the main event loop. > > */ > > RIB_QoS(RibManager& rib_manager, > > EventLoop& eventloop); > > > > ========================================================== > > And I include this file on the "rib_manager.hh" file, but something > > doesn't work. > > Do you (or anybody alse ;-) ) have any other idea? > > Please confirm that you have the above RIB_QoS constructor > implemented in rib_QoS.cc (or somewhere else), and that this file is > linked appropriately. Also, at the end of rib_QoS.cc you may want to > add the following two lines: > > template class RIB_QoS; > template class RIB_QoS; > > If this still doesn't help, then please send me an URL with the > tarball with your source code and I will have a look at it. > > Regards, > Pavlin > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- ============================================= Julián David Morillo Pozo PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnical University of Catalonia (UPC) Phone: +34-934017182 Fax: +34-934017055 URL: http://people.ac.upc.edu/jmorillo =============================================