From adam@hiddennet.net Mon Jan 3 18:49:04 2005 From: adam@hiddennet.net (Adam Greenhalgh) Date: Mon, 03 Jan 2005 18:49:04 +0000 Subject: [Xorp-hackers] Re: [Xorp-feedback] Question In-Reply-To: <1104776561.41d98d7109c7f@webmail.unb.ca> References: <1104776561.41d98d7109c7f@webmail.unb.ca> Message-ID: <1104778144.17780.4.camel@localhost> Xorp 1.0 does compile and run on Fedora Core 2 with a linux 2.6.x kernel. Some of the features aren't supported on linux because the linux kernel doesn't have all the features freebsd does. So you should be fine. I suggest you use the latest developement version of xorp. rather than the release version as things have improved at lot since xorp 1.0 , for more details check http://www.xorp.org/cvs.html . For future reference it is probably best if you post similar questions to xorp-hackers@xorp.org Adam On Mon, 2005-01-03 at 14:22 -0400, Chen, Albert wrote: > Dear Sir, > I am using Fedora Core 2 on my machine. Does your XORP 1.0 run on Linux 2.6.x? > thank you very much! > > regards, > > Albert Chen > MCS > UNB Fredericton > > > > _______________________________________________ > Xorp-feedback mailing list > Xorp-feedback@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-feedback -- Adam Greenhalgh From ren@sandmail.sandburst.com Thu Jan 6 13:32:43 2005 From: ren@sandmail.sandburst.com (Yonghong Ren) Date: Thu, 6 Jan 2005 08:32:43 -0500 Subject: [Xorp-hackers] simple syntax error in fea/ifconfig_parse_ifreq.cc Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F3F4.336E2C4B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Missing a semicolon at fea/ifconfig_parse_ifreq.cc#61 =20 The code was fetched from the CVS DB around middle of December. =20 ------_=_NextPart_001_01C4F3F4.336E2C4B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Missing a semicolon at = fea/ifconfig_parse_ifreq.cc#61

 

The code was fetched from the CVS DB around middle of = December.

 

=00 ------_=_NextPart_001_01C4F3F4.336E2C4B-- From atanu@ICSI.Berkeley.EDU Thu Jan 6 17:51:51 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 06 Jan 2005 09:51:51 -0800 Subject: [Xorp-hackers] simple syntax error in fea/ifconfig_parse_ifreq.cc In-Reply-To: Message from "Yonghong Ren" of "Thu, 06 Jan 2005 08:32:43 EST." Message-ID: <81536.1105033911@tigger.icir.org> Thanks. Fixed in CVS. Atanu. >>>>> "Yonghong" == Yonghong Ren writes: Yonghong> Missing a semicolon at fea/ifconfig_parse_ifreq.cc#61:p> Yonghong> The code was fetched from the CVS DB around middle of Yonghong> December. From pavlin@icir.org Wed Jan 12 23:26:33 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 12 Jan 2005 15:26:33 -0800 Subject: [Xorp-hackers] simple syntax error in fea/ifconfig_parse_ifreq.cc In-Reply-To: Message from "Yonghong Ren" of "Thu, 06 Jan 2005 08:32:43 EST." Message-ID: <200501122326.j0CNQX85086137@possum.icir.org> > Missing a semicolon at fea/ifconfig_parse_ifreq.cc#61 > The code was fetched from the CVS DB around middle of December. Yonghong, Just curious, what OS did you use. The reason that we didn't seen this compilatione error so far was because it was hidden by "#ifndef HAVE_IOCTL_SIOCGIFCONF", and so far all OS versions we have tried do have ioctl(SIOCGIFCONF). If your OS also has ioctl(SIOCGIFCONF), then there must be a bug in the "configure" detection code. Thanks, Pavlin From pavlin@icir.org Wed Jan 12 23:38:50 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 12 Jan 2005 15:38:50 -0800 Subject: [Xorp-hackers] xorp on FreeBSD 5.3 on Sparc64 In-Reply-To: Message from Ong Beng Hui of "Tue, 28 Dec 2004 16:00:36 +0800." <41D112A4.8040701@ispworkshop.com> Message-ID: <200501122338.j0CNcook086236@possum.icir.org> Ong, Unfortunately we don't have access to a Sparc64 box to fix the problem. If you (or someone else) can provide us with a temporary guest account we can try to fix the compilation errors. Thanks, Pavlin > Hi, > > Has anyone tried to compile xorp on FreeBSD 5.3 on Sparc64 ? > > Got this error... > > make[3]: Entering directory `/usr/local/src/xorp/libxorp' > source='asyncio.cc' object='asyncio.lo' libtool=yes \ > depfile='.deps/asyncio.Plo' tmpdepfile='.deps/asyncio.TPlo' \ > depmode=gcc3 /usr/local/bin/bash ../config/depcomp \ > /usr/local/bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. > -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror > -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 > -pipe -c -o asyncio.lo `test -f asyncio.cc || echo './'`asyncio.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > -ftemplate-depth-22 -pipe -c asyncio.cc -MT asyncio.lo -MD -MP -MF > .deps/asyncio.TPlo -o asyncio.o > > asyncio.cc: In member function `void AsyncFileWriter::write(int, > SelectorMask)': > asyncio.cc:255: warning: int format, different type arg (arg 2) > make[3]: *** [asyncio.lo] Error 1 > make[3]: Leaving directory `/usr/local/src/xorp/libxorp' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/usr/local/src/xorp/libxorp' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src/xorp' > make: *** [all] Error 2 > bash-2.04# > > any tips for a fix ? xorp is from CVS. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ren@sandmail.sandburst.com Thu Jan 13 09:06:59 2005 From: ren@sandmail.sandburst.com (Yonghong Ren) Date: Thu, 13 Jan 2005 04:06:59 -0500 Subject: [Xorp-hackers] simple syntax error in fea/ifconfig_parse_ifreq.cc Message-ID: Hi Pavlin, This was on an embedded Linux system (from ELDK). You are right, the syntax error would not be exposed unless SIOCGIFCONF is not defined. I manually added HAVE_IOCTL_SIOCGIFCONF in config.h to continue the compilation. SIOCGIFCONF detection didn't work. I didn't investigate why. Thanks for replying. -- Yonghong Ren -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Wednesday, January 12, 2005 6:27 PM To: Yonghong Ren Cc: xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] simple syntax error in fea/ifconfig_parse_ifreq.cc > Missing a semicolon at fea/ifconfig_parse_ifreq.cc#61 > The code was fetched from the CVS DB around middle of December. Yonghong, Just curious, what OS did you use. The reason that we didn't seen this compilatione error so far was because it was hidden by "#ifndef HAVE_IOCTL_SIOCGIFCONF", and so far all OS versions we have tried do have ioctl(SIOCGIFCONF). If your OS also has ioctl(SIOCGIFCONF), then there must be a bug in the "configure" detection code. Thanks, Pavlin From rafael.guimaraes@ac.upc.edu Mon Jan 17 12:42:52 2005 From: rafael.guimaraes@ac.upc.edu (Rafael Paoliello Guimaraes) Date: Mon, 17 Jan 2005 13:42:52 +0100 Subject: [Xorp-hackers] Problems with new versions of XORP Message-ID: <41EBB2CC.3090502@ac.upc.edu> Hello, I have migrated a routing protocol successfully to the XORP platform. However, now I am intending to use this routing protocol along with XORP and Click as the forwading engine. Well, I have downloaded a recent version of XORP (which supports click) and I have noticed some changes regarding adding new routes. Now, I am supposed to provide an additional argument for the XRL call, which is the a list of policies (XrlAtomList object). What does it represent? Since my original protocol does not care about this, what I did was to send an "empty" object (created with default constructor), but now my protocol calls the XRL to add a route but does not receive a reply (through callback) from XORP. How can I do this in the right way? What I did: void XrlTestNode::send_rib_route_change() { bool success = true; XrlAtomList _xrl_atom_list; (...) ---> Code to get next route from the list and check if routing tables were registered // // Send the appropriate XRL // if (test_route.is_add_route()) { if (test_route.is_ipv4()) { if (test_route.is_interface_route()) { success = _xrl_rib_client.send_add_interface_route4( _rib_target.c_str(), TestProtocolNode::protocol_name(), true /* unicast */, false /* multicast */, test_route.network().get_ipv4net(), test_route.nexthop().get_ipv4(), test_route.ifname(), test_route.vifname(), test_route.metric(), _xrl_atom_list, callback(this, &XrlTestNode::send_rib_route_change_cb)); if (success) return; } else { (...) Should this work? Why is this not working? Cheers, -- =========================================== Rafael Paoliello Guimaraes PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnic University of Catalonia (UPC) Phone: +34-934017187 Fax: +34-934017055 URL: http://people.ac.upc.es/rpaoliel =========================================== From pavlin@icir.org Mon Jan 17 19:09:39 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Jan 2005 11:09:39 -0800 Subject: [Xorp-hackers] Problems with new versions of XORP In-Reply-To: Message from Rafael Paoliello Guimaraes of "Mon, 17 Jan 2005 13:42:52 +0100." <41EBB2CC.3090502@ac.upc.edu> Message-ID: <200501171909.j0HJ9dXh058040@possum.icir.org> > I have migrated a routing protocol successfully to the XORP platform. > However, now I am intending to use this routing protocol along with XORP > and Click as the forwading engine. Well, I have downloaded a recent > version of XORP (which supports click) and I have noticed some changes > regarding adding new routes. Now, I am supposed to provide an additional > argument for the XRL call, which is the a list of policies (XrlAtomList > object). What does it represent? > Since my original protocol does not care about this, what I did was to > send an "empty" object (created with default constructor), but now my > protocol calls the XRL to add a route but does not receive a reply > (through callback) from XORP. How can I do this in the right way? It is fine for the list of policies to be empty (as you have done in your code). E.g., see the corresponding code in static_routes (method XrlStaticRoutesNode::send_rib_route_change() inside file static_routes/xrl_static_routes_node.cc). If that code is working for static_routes, then the callback problem you have is somewhere else. Try to debug the problem by adding printf() to the appropriate RIB XRL handler. Regards, Pavlin > > What I did: > > > void > XrlTestNode::send_rib_route_change() > { > bool success = true; > XrlAtomList _xrl_atom_list; > > (...) ---> Code to get next route from the list and > check if routing tables were registered > > // > // Send the appropriate XRL > // > if (test_route.is_add_route()) { > if (test_route.is_ipv4()) { > if (test_route.is_interface_route()) { > success = _xrl_rib_client.send_add_interface_route4( > _rib_target.c_str(), > TestProtocolNode::protocol_name(), > true /* unicast */, > false /* multicast */, > test_route.network().get_ipv4net(), > test_route.nexthop().get_ipv4(), > test_route.ifname(), > test_route.vifname(), > test_route.metric(), > _xrl_atom_list, > callback(this, > &XrlTestNode::send_rib_route_change_cb)); > if (success) > return; > } else { > (...) > > Should this work? Why is this not working? From ren@sandmail.sandburst.com Tue Jan 18 16:17:07 2005 From: ren@sandmail.sandburst.com (Yonghong Ren) Date: Tue, 18 Jan 2005 11:17:07 -0500 Subject: [Xorp-hackers] Large Number of Interfaces Message-ID: Atanu and Pavlin, Thank you very much for replying to my questions on fea/ interface compilation questions. I would like to set the compilation issues aside for a moment and discuss a different aspect, namely the best way to support large number of interfaces. A system may have say 40 physical interfaces, with X number of logical interfaces (virtual router interface for example). The current design choice appears to be leveraging the native OS Ethernet interface mechanism. In other words, every interface would appears as a native OS interface. What are the pros and cons (if there is any :)) of this approach? Some questions I have are: 1) Is this scalable? That is, would say 100 interfaces cause problems to the OS? 2) The interfaces may be added and removed dynamically. Would this be OK? 3) What assumptions and requirements does XORP stack requires each interface? For example, the routing protocols would be assuming socket library access through the interfaces and therefore the interface has to provide socket access. So, that would be a big advantage to make each interface a network interface at the OS level so to leverage the TCP/IP stack and socket mechanism. 4) I wonder how this is typically done in a large commercial router. Thanks and look forward to some enlightening responses. Yonghong Ren From rpaoliel@ac.upc.edu Tue Jan 18 15:13:56 2005 From: rpaoliel@ac.upc.edu (rpaoliel@ac.upc.edu) Date: Tue, 18 Jan 2005 16:13:56 +0100 Subject: [Xorp-hackers] Problems with last versions of XORP Message-ID: <1106061236.41ed27b48b7f2@www.ac.upc.edu> Hello, I am currently testing a routing protocol that I have just migrated to XORP (as you may have noticed through other messages). I am using a version of XORP that I have downloaded from the CVS server around December, 13th. Well, first of all I am testing it with linux as the forwarding engine and I am having some problems. Everything seems to work fine until I leave my protocol working for a while. In the test scenario I have two computers running XORP and my protocol and they exchange periodic information about the routes they know, so that each one of them may update their routing table according to the received information. The problem is that if I leave it working for some time, the system becomes stable and no more route updates are done. So, when I shutdown my routing protocol, everything gets messed up. I get a lot of error messages from the router manager on the computer where I have shutdown my protocol, and also in the other computer, when it tries to delete some routes (due to the fact that it no longer receives the periodic messages from the first computer). If I shutdown my protocol after just a while after it becomes stable (let's say 1 minute or something in this magnitude), everything runs well. I have transcripted below the error messages I have got from both computers. COMPUTER 1 (Where the protocol was shutdown) ========== [ 2005/01/18 13:18:18 INFO xorp_rtrmgr:2969 RTRMGR +166 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, static_routes [ 2005/01/18 13:18:18 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] Running module: interfaces (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/18 13:18:20 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] Running module: fea (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/18 13:18:26 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] Running module: rib (/root/XORP/xorp/rib/xorp_rib) [ 2005/01/18 13:18:28 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] Running module: static_routes (/root/XORP/xorp/static_routes/xorp_static_routes) [ 2005/01/18 13:18:30 INFO xorp_rtrmgr:2969 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/18 13:18:32 ERROR xorp_rib:2971 RIB +133 rib.cc admin_distance ] Administrative distance of "test" unknown. [ 2005/01/18 13:21:29 INFO xorp_rtrmgr:2969 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/18 13:23:35 ERROR xorp_rib:2971 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:35 ERROR xorp_fea:2970 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:35 ERROR xorp_rtrmgr:2969 LIBXORP +271 asyncio.cc complete_transfer ] Write error 104 - Connection reset by peer [ 2005/01/18 15:49:35 INFO xorp_rib RIB ] Received death event for protocol test shutting down ------- OriginTable: test IGP next table = Redist:test [ 2005/01/18 15:49:35 FATAL xorp_fea:2970 FEA +466 fticonfig_entry_set_netlink.cc delete_entry ] Assertion (ii != it.ifs().end()) failed [ 2005/01/18 15:49:35 ERROR xorp_static_routes:2972 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:35 INFO xorp_rtrmgr:2969 RTRMGR +549 module_manager.cc killed ] Module abnormally killed: interfaces [ 2005/01/18 15:49:35 INFO xorp_rtrmgr:2969 RTRMGR +549 module_manager.cc killed ] Module abnormally killed: fea [ 2005/01/18 15:49:35 ERROR xorp_rtrmgr:2969 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:35 ERROR xorp_rib:2971 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:35 ERROR xorp_rib:2971 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:35 ERROR xorp_rib:2971 XifRedistTransaction6 +902 redist_xrl.cc dispatch_complete ] Fatal error during commit transaction "210 Transport failed" [ 2005/01/18 15:49:43 INFO xorp_rtrmgr:2969 RTRMGR +570 task.cc shutdown ] Shutting down module: static_routes [ 2005/01/18 15:49:43 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 ./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. [ 2005/01/18 15:49:43 ERROR xorp_rib:2971 RIB +1306 rib.cc delete_origin_table ] Got delete_origin_table for wrong target name [ 2005/01/18 15:49:43 WARNING xorp_rib XrlRibTarget ] Handling method for rib/0.1/delete_igp_table4 failed: XrlCmdError 102 Command failed Could not delete unicast IPv4 igp table "static" [ 2005/01/18 15:49:43 ERROR xorp_static_routes:2972 STATIC_ROUTES +308 xrl_static_routes_node.cc rib_client_send_delete_igp_table4_cb ] Failed to deregister IPv4 IGP table with the RIB: 102 Command failed Could not delete unicast IPv4 igp table "static". Will give up. [ 2005/01/18 15:49:43 INFO xorp_rtrmgr:2969 RTRMGR +523 module_manager.cc normal_exit ] Module normal exit: static_routes [ 2005/01/18 15:49:43 ERROR xorp_rtrmgr:2969 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:44 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 ./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. [ 2005/01/18 15:49:45 INFO xorp_rtrmgr:2969 RTRMGR +570 task.cc shutdown ] Shutting down module: rib [ 2005/01/18 15:49:45 INFO xorp_rtrmgr:2969 RTRMGR +523 module_manager.cc normal_exit ] Module normal exit: rib [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:49:45 INFO xorp_rtrmgr:2969 XRL +331 xrl_router.cc send_resolved ] Sender died (protocol = "stcp", address = "127.0.0.1:33022") [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 IPC +271 sockutil.cc create_connected_ip_socket ] failed to connect to 127.0.0.1 port 33022: Connection refused [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 XRL +55 xrl_pf_factory.cc create_sender ] XrlPFSenderFactory::create failed: XrlPFConstructorError from line 578 of xrl_pf_stcp.cc: Could not connect to 127.0.0.1:33022 [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 XRL +342 xrl_router.cc send_resolved ] Could not create XrlPFSender for protocol = "stcp" address = "127.0.0.1:33022" [ 2005/01/18 15:49:45 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 ./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. [ 2005/01/18 15:49:49 INFO xorp_rtrmgr:2969 RTRMGR +570 task.cc shutdown ] Shutting down module: interfaces [ 2005/01/18 15:49:49 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 ./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. [ 2005/01/18 15:49:49 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 ./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. [ 2005/01/18 15:49:50 INFO xorp_rtrmgr:2969 RTRMGR +1372 task.cc run_task ] No more tasks to run COMPUTER 2 (tries to delete some routes after computer 1 shutdowns) ========== [ 2005/01/18 13:24:32 INFO xorp_rtrmgr:2888 RTRMGR +166 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, static_routes [ 2005/01/18 13:24:32 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] Running module: interfaces (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/18 13:24:34 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] Running module: fea (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/18 13:24:40 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] Running module: rib (/root/XORP/xorp/rib/xorp_rib) [ 2005/01/18 13:24:42 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] Running module: static_routes (/root/XORP/xorp/static_routes/xorp_static_routes) [ 2005/01/18 13:24:44 INFO xorp_rtrmgr:2888 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/18 13:24:47 ERROR xorp_rib:2891 RIB +133 rib.cc admin_distance ] Administrative distance of "test" unknown. [ 2005/01/18 15:55:53 FATAL xorp_fea:2889 FEA +466 fticonfig_entry_set_netlink.cc delete_entry ] Assertion (ii != it.ifs().end()) failed [ 2005/01/18 15:55:53 ERROR xorp_rib:2891 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:55:53 ERROR xorp_static_routes:2892 XRL +628 xrl_pf_stcp.cc die] XrlPFSTCPSender died: end of file [ 2005/01/18 15:55:53 INFO xorp_rtrmgr:2888 RTRMGR +549 module_manager.cc killed ] Module abnormally killed: interfaces [ 2005/01/18 15:55:53 INFO xorp_rtrmgr:2888 RTRMGR +549 module_manager.cc killed ] Module abnormally killed: fea [ 2005/01/18 15:55:53 ERROR xorp_rtrmgr:2888 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:55:53 ERROR xorp_rib:2891 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file [ 2005/01/18 15:55:53 ERROR xorp_rib:2891 XifRedistTransaction6 +902 redist_xrl.cc dispatch_complete ] Fatal error during commit transaction "210 Transport failed" Cheers, Rafael Paoliello Guimaraes From rafael.guimaraes@ac.upc.edu Tue Jan 18 20:16:47 2005 From: rafael.guimaraes@ac.upc.edu (Rafael Paoliello Guimaraes) Date: Tue, 18 Jan 2005 21:16:47 +0100 Subject: [Xorp-hackers] Problems when adding a static route Message-ID: <41ED6EAF.7030905@ac.upc.edu> Hello, Here I am again with more problems... I am starting to think that I am being very boring... Well, let's go to the problem: Whenever I try to add a static route where the nexthop is an IP address for which there is more than one route, I get an error message telling that the route could not be added because the nexthop is not directly connected to the host. Well, in my case the route I was trying to add was: 10.0.1.1/32 nexthop 10.0.0.4 and I had the following pre-existing routes: 10.0.0.0/24 nexthop 10.0.0.1 (connected) 10.0.0.4/32 nexthop 0.0.0.0 (test) It seemed to me that the RIB was searching for a route to the nexthop not only in the connected routes, and than it had a match with the second route (which comes from the test protocol) and it though that the desired nexthop was not directly connected. In order to solve this, I changed my test protocol to add every 1-hop route as if it were the connected protocol (just by changing the protocol name parameter in the XRL call). Well, with this changes I had the following routing table: 10.0.0.0/24 nexthop 10.0.0.1 (connected) 10.0.0.4/32 nexthop 0.0.0.0 (connected) But I still get the same error (nexthop is not directly connected). When I don't have the second route in the table, everything goes fine... Does anybody know how to solve this? Am I doing something wrong? Cheers, -- =========================================== Rafael Paoliello Guimaraes PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnic University of Catalonia (UPC) Phone: +34-934017187 Fax: +34-934017055 URL: http://people.ac.upc.es/rpaoliel =========================================== From pavlin@icir.org Tue Jan 18 21:07:39 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 18 Jan 2005 13:07:39 -0800 Subject: [Xorp-hackers] Large Number of Interfaces In-Reply-To: Message from "Yonghong Ren" of "Tue, 18 Jan 2005 11:17:07 EST." Message-ID: <200501182107.j0IL7d87090381@possum.icir.org> > I would like to set the compilation issues aside for a moment and > discuss a different aspect, namely the best way to support large number > of interfaces. > > A system may have say 40 physical interfaces, with X number of logical > interfaces (virtual router interface for example). > > The current design choice appears to be leveraging the native OS > Ethernet interface mechanism. In other words, every interface would > appears as a native OS interface. A clarification: we can deal with every interface that appears in the kernel and is visible by "ifconfig -a" (including virtual interfaces, etc). We wanted to use what is already in the system rather than inventing our own virtual interface space. On the other hand, if you want to use, say, a virtual tunnel, currently that tunnel cannot be created by XORP itself; the tunnel must be created externally (by user-level UNIX program, etc). > What are the pros and cons (if there is any :)) of this approach? Some > questions I have are: > > 1) Is this scalable? That is, would say 100 interfaces cause problems to > the OS? For a number of reasons there are some places inside the FEA where we use linear processing when some of the interface-related info has changed. Obviously, this is scalable up to a point, but I doubt the CPU overhead will be notable with hundreds of interfaces. > 2) The interfaces may be added and removed dynamically. Would this be > OK? If you want to use a network interface in XORP, you must explicitly tell XORP about it, otherwise XORP doesn't know it is suppose to use it. At least, you must tell XORP the name of the interface. Then, the design allows to dynamically track the state of that interface (e.g., if an IP address is added/deleted, if the interface itself is enabled/disabled/deleted, etc). Though, admittably, the dynamic tracking functionality hasn't been tested well. > 3) What assumptions and requirements does XORP stack requires each > interface? For example, the routing protocols would be assuming socket > library access through the interfaces and therefore the interface has to > provide socket access. So, that would be a big advantage to make each > interface a network interface at the OS level so to leverage the TCP/IP > stack and socket mechanism. Probably I don't understand this question, but all interfaces used by XORP are at the OS level, hence we always use the TCP/IP stack and socket mechanism provided by the system. > 4) I wonder how this is typically done in a large commercial router. I don't know. Given that we use the UNIX kernel, we leverage on the functionalities it provides already. The downside is that an interface may be modified on-the-fly by user-level commands (outside of XORP), hence we need to consider this scenario. I guess that in commercial routers the configuration is controlled via the router startup configuration or the CLI, hence everything is explicit. Regards, Pavlin From pavlin@icir.org Tue Jan 18 21:26:54 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 18 Jan 2005 13:26:54 -0800 Subject: [Xorp-hackers] Problems with last versions of XORP In-Reply-To: Message from rpaoliel@ac.upc.edu of "Tue, 18 Jan 2005 16:13:56 +0100." <1106061236.41ed27b48b7f2@www.ac.upc.edu> Message-ID: <200501182126.j0ILQsp9090567@possum.icir.org> > I am currently testing a routing protocol that I have just migrated to XORP (as > you may have noticed through other messages). I am using a version of XORP that > I have downloaded from the CVS server around December, 13th. Well, first of all > I am testing it with linux as the forwarding engine and I am having some > problems. > > Everything seems to work fine until I leave my protocol working for a while. In > the test scenario I have two computers running XORP and my protocol and they > exchange periodic information about the routes they know, so that each one of > them may update their routing table according to the received information. The > problem is that if I leave it working for some time, the system becomes stable > and no more route updates are done. So, when I shutdown my routing protocol, > everything gets messed up. I get a lot of error messages from the router > manager on the computer where I have shutdown my protocol, and also in the > other computer, when it tries to delete some routes (due to the fact that it no > longer receives the periodic messages from the first computer). If I shutdown my > protocol after just a while after it becomes stable (let's say 1 minute or > something in this magnitude), everything runs well. I have transcripted below > the error messages I have got from both computers. Majority of the error messages during shutdown on the first computer are kind of normal. Well, ideally you shouldn't see them, but they don't hurt; nevertheless, they should be fixed in the future. Few of the errors you get are unusual and problematic. See inlined comments. > COMPUTER 1 (Where the protocol was shutdown) > ========== > > [ 2005/01/18 13:18:18 INFO xorp_rtrmgr:2969 RTRMGR +166 master_conf_tree.cc > execute ] Changed modules: interfaces, fea, rib, static_routes > [ 2005/01/18 13:18:18 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] > Running module: interfaces (/root/XORP/xorp/fea/xorp_fea) > [ 2005/01/18 13:18:20 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] > Running module: fea (/root/XORP/xorp/fea/xorp_fea) > [ 2005/01/18 13:18:26 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] > Running module: rib (/root/XORP/xorp/rib/xorp_rib) > [ 2005/01/18 13:18:28 INFO xorp_rtrmgr:2969 RTRMGR +403 module_manager.cc run ] > Running module: static_routes (/root/XORP/xorp/static_routes/xorp_static_routes) > [ 2005/01/18 13:18:30 INFO xorp_rtrmgr:2969 RTRMGR +1372 task.cc run_task ] No > more tasks to run > [ 2005/01/18 13:18:32 ERROR xorp_rib:2971 RIB +133 rib.cc admin_distance ] > Administrative distance of "test" unknown. To get rid of this error, you may want to add an admin distance for your protocol "test". E.g., add a like like to rib/rib.cc _admin_distances["fib2mrib"] = 220; along other hard-coded admin distances inside the RIB::RIB() constructor. > [ 2005/01/18 13:21:29 INFO xorp_rtrmgr:2969 RTRMGR +1372 task.cc run_task ] No > more tasks to run > [ 2005/01/18 13:23:35 ERROR xorp_rib:2971 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:35 ERROR xorp_fea:2970 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:35 ERROR xorp_rtrmgr:2969 LIBXORP +271 asyncio.cc > complete_transfer ] Write error 104 - Connection reset by peer > [ 2005/01/18 15:49:35 INFO xorp_rib RIB ] Received death event for protocol test > shutting down ------- > OriginTable: test > IGP > next table = Redist:test The above errors can be ignored. > [ 2005/01/18 15:49:35 FATAL xorp_fea:2970 FEA +466 > fticonfig_entry_set_netlink.cc delete_entry ] Assertion (ii != it.ifs().end()) > failed This assert is not normal. Somehow, the FEA is told to delete a forwarding entry, and the corresponding interface name doesn't exist inside the FEA. To debug the problem, please add some printf right before the XLOG_ASSERT() on line 466 (file fea/fticonfig_entry_set_netlink.cc), and print the fte.ifname(), and the ifnames of all interfaces inside the "IfTree& it". This may give you a clue about the mismatch. E.g., it could be that the XLOG_ASSERT() there is not appropriate. > [ 2005/01/18 15:49:35 ERROR xorp_static_routes:2972 XRL +628 xrl_pf_stcp.cc die > ] XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:35 INFO xorp_rtrmgr:2969 RTRMGR +549 module_manager.cc > killed ] Module abnormally killed: interfaces > [ 2005/01/18 15:49:35 INFO xorp_rtrmgr:2969 RTRMGR +549 module_manager.cc > killed ] Module abnormally killed: fea > [ 2005/01/18 15:49:35 ERROR xorp_rtrmgr:2969 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:35 ERROR xorp_rib:2971 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:35 ERROR xorp_rib:2971 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:35 ERROR xorp_rib:2971 XifRedistTransaction6 +902 > redist_xrl.cc dispatch_complete ] Fatal error during commit transaction "210 > Transport failed" > [ 2005/01/18 15:49:43 INFO xorp_rtrmgr:2969 RTRMGR +570 task.cc shutdown ] > Shutting down module: static_routes > [ 2005/01/18 15:49:43 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 > ./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. > [ 2005/01/18 15:49:43 ERROR xorp_rib:2971 RIB +1306 rib.cc delete_origin_table > ] Got delete_origin_table for wrong target name > [ 2005/01/18 15:49:43 WARNING xorp_rib XrlRibTarget ] Handling method for > rib/0.1/delete_igp_table4 failed: XrlCmdError 102 Command failed Could not > delete unicast IPv4 igp table "static" > [ 2005/01/18 15:49:43 ERROR xorp_static_routes:2972 STATIC_ROUTES +308 > xrl_static_routes_node.cc rib_client_send_delete_igp_table4_cb ] Failed to > deregister IPv4 IGP table with the RIB: 102 Command failed Could not delete > unicast IPv4 igp table "static". Will give up. > [ 2005/01/18 15:49:43 INFO xorp_rtrmgr:2969 RTRMGR +523 module_manager.cc > normal_exit ] Module normal exit: static_routes > [ 2005/01/18 15:49:43 ERROR xorp_rtrmgr:2969 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:44 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 > ./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. > [ 2005/01/18 15:49:45 INFO xorp_rtrmgr:2969 RTRMGR +570 task.cc shutdown ] > Shutting down module: rib > [ 2005/01/18 15:49:45 INFO xorp_rtrmgr:2969 RTRMGR +523 module_manager.cc > normal_exit ] Module normal exit: rib > [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:49:45 INFO xorp_rtrmgr:2969 XRL +331 xrl_router.cc > send_resolved ] Sender died (protocol = "stcp", address = "127.0.0.1:33022") > [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 IPC +271 sockutil.cc > create_connected_ip_socket ] failed to connect to 127.0.0.1 port 33022: > Connection refused > [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 XRL +55 xrl_pf_factory.cc > create_sender ] XrlPFSenderFactory::create failed: XrlPFConstructorError from > line 578 of xrl_pf_stcp.cc: Could not connect to 127.0.0.1:33022 > > [ 2005/01/18 15:49:45 ERROR xorp_rtrmgr:2969 XRL +342 xrl_router.cc > send_resolved ] Could not create XrlPFSender for protocol = "stcp" address = > "127.0.0.1:33022" > [ 2005/01/18 15:49:45 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 > ./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. > [ 2005/01/18 15:49:49 INFO xorp_rtrmgr:2969 RTRMGR +570 task.cc shutdown ] > Shutting down module: interfaces > [ 2005/01/18 15:49:49 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 > ./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. > [ 2005/01/18 15:49:49 WARNING xorp_rtrmgr:2969 XrlFinderTarget +406 > ./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. > [ 2005/01/18 15:49:50 INFO xorp_rtrmgr:2969 RTRMGR +1372 task.cc run_task ] No > more tasks to run The above errors are "kind of normal". > COMPUTER 2 (tries to delete some routes after computer 1 shutdowns) > ========== > > [ 2005/01/18 13:24:32 INFO xorp_rtrmgr:2888 RTRMGR +166 master_conf_tree.cc > execute ] Changed modules: interfaces, fea, rib, static_routes > [ 2005/01/18 13:24:32 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] > Running module: interfaces (/root/XORP/xorp/fea/xorp_fea) > [ 2005/01/18 13:24:34 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] > Running module: fea (/root/XORP/xorp/fea/xorp_fea) > [ 2005/01/18 13:24:40 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] > Running module: rib (/root/XORP/xorp/rib/xorp_rib) > [ 2005/01/18 13:24:42 INFO xorp_rtrmgr:2888 RTRMGR +403 module_manager.cc run ] > Running module: static_routes (/root/XORP/xorp/static_routes/xorp_static_routes) > [ 2005/01/18 13:24:44 INFO xorp_rtrmgr:2888 RTRMGR +1372 task.cc run_task ] No > more tasks to run > [ 2005/01/18 13:24:47 ERROR xorp_rib:2891 RIB +133 rib.cc admin_distance ] > Administrative distance of "test" unknown. > [ 2005/01/18 15:55:53 FATAL xorp_fea:2889 FEA +466 > fticonfig_entry_set_netlink.cc delete_entry ] Assertion (ii != it.ifs().end()) > failed This assert is not normal. See my comments above about the same assert in the first computer. The rest of the errors are "kind of normal". Regards, Pavlin > [ 2005/01/18 15:55:53 ERROR xorp_rib:2891 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:55:53 ERROR xorp_static_routes:2892 XRL +628 xrl_pf_stcp.cc > die] XrlPFSTCPSender died: end of file > [ 2005/01/18 15:55:53 INFO xorp_rtrmgr:2888 RTRMGR +549 module_manager.cc > killed ] Module abnormally killed: interfaces > [ 2005/01/18 15:55:53 INFO xorp_rtrmgr:2888 RTRMGR +549 module_manager.cc > killed ] Module abnormally killed: fea > [ 2005/01/18 15:55:53 ERROR xorp_rtrmgr:2888 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:55:53 ERROR xorp_rib:2891 XRL +628 xrl_pf_stcp.cc die ] > XrlPFSTCPSender died: end of file > [ 2005/01/18 15:55:53 ERROR xorp_rib:2891 XifRedistTransaction6 +902 > redist_xrl.cc dispatch_complete ] Fatal error during commit transaction "210 > Transport failed" From pavlin@icir.org Tue Jan 18 21:36:01 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 18 Jan 2005 13:36:01 -0800 Subject: [Xorp-hackers] Problems when adding a static route In-Reply-To: Message from Rafael Paoliello Guimaraes of "Tue, 18 Jan 2005 21:16:47 +0100." <41ED6EAF.7030905@ac.upc.edu> Message-ID: <200501182136.j0ILa1lF090661@possum.icir.org> > Whenever I try to add a static route where the nexthop is an IP address > for which there is more than one route, I get an error message telling > that the route could not be added because the nexthop is not directly > connected to the host. > > Well, in my case the route I was trying to add was: > > 10.0.1.1/32 nexthop 10.0.0.4 > > and I had the following pre-existing routes: > > 10.0.0.0/24 nexthop 10.0.0.1 (connected) > 10.0.0.4/32 nexthop 0.0.0.0 (test) > > It seemed to me that the RIB was searching for a route to the nexthop > not only in the connected routes, and than it had a match with the > second route (which comes from the test protocol) and it though that the > desired nexthop was not directly connected. In order to solve this, I > changed my test protocol to add every 1-hop route as if it were the > connected protocol (just by changing the protocol name parameter in the > XRL call). Well, with this changes I had the following routing table: > > 10.0.0.0/24 nexthop 10.0.0.1 (connected) > 10.0.0.4/32 nexthop 0.0.0.0 (connected) > > But I still get the same error (nexthop is not directly connected). When > I don't have the second route in the table, everything goes fine... Does > anybody know how to solve this? Am I doing something wrong? First, I believe that you cannot explicitly add the directly-connected routes to RIB. Those come from the network interface information received by RIB from the REA. To get around the problem, have you tried to use the rib/0.1/add_interface_route4 XRL to explicitly specify the network interface name toward the destination. No guarantee it will work, but you can give it a try. If this still doesn't work, please include the particular error messages you receive, so this can help locate the code that rejects the "add route" command. Regards, Pavlin From bms@spc.org Wed Jan 19 16:24:36 2005 From: bms@spc.org (Bruce M Simpson) Date: Wed, 19 Jan 2005 16:24:36 +0000 Subject: [Xorp-hackers] Minor build issue with p4 and other cvs-a-likes Message-ID: <20050119162435.GA1033@empiric.icir.org> This is probably only of interest to people using Perforce or considering using it. I've noticed a minor issue with XORP when using Perforce as a secondary repository. When rebuilding the xrl subdirectory targets, Python complains that the .XIF files are read-only, and the build fails. Currently I'm using Perforce to allow the changes I'm working on in XORP to be merged more cleanly back to the main line of development in CVS, and to allow the work on my laptop to be regularly checked in. I traced this back to the Perforce client's default behaviour, which is to check out files read-only if they are not currently open for editing using 'p4 edit'. Applying the 'allwrite' option to the P4 client view for my XORP tree is a workaround I'm now using. Adding the 'clobber' option to allow 'p4 sync' to overwrite such files adds convenience when doing integrates but risks changes which haven't been 'p4 submit'-ted being lost. Hope this helps, BMS From pavlin@icir.org Thu Jan 20 02:45:31 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 19 Jan 2005 18:45:31 -0800 Subject: [Xorp-hackers] Problems with last versions of XORP In-Reply-To: Message from Pavlin Radoslavov of "Tue, 18 Jan 2005 13:26:54 PST." <200501182126.j0ILQsp9090567@possum.icir.org> Message-ID: <200501200245.j0K2jVgS004717@possum.icir.org> > > [ 2005/01/18 15:49:35 FATAL xorp_fea:2970 FEA +466 > > fticonfig_entry_set_netlink.cc delete_entry ] Assertion (ii != it.ifs().end()) > > failed > > This assert is not normal. > Somehow, the FEA is told to delete a forwarding entry, and the > corresponding interface name doesn't exist inside the FEA. > To debug the problem, please add some printf right before the > XLOG_ASSERT() on line 466 (file fea/fticonfig_entry_set_netlink.cc), > and print the fte.ifname(), and the ifnames of all interfaces inside > the "IfTree& it". This may give you a clue about the mismatch. > E.g., it could be that the XLOG_ASSERT() there is not appropriate. FYI, I was able to replicate the above assert. There was a bug in the code around that assert. The bug is now fixed in the CVS repository. Regards, Pavlin From ren@sandmail.sandburst.com Thu Jan 20 16:00:24 2005 From: ren@sandmail.sandburst.com (Yonghong Ren) Date: Thu, 20 Jan 2005 11:00:24 -0500 Subject: [Xorp-hackers] Large Number of Interfaces Message-ID: Pavlin, >On the other hand, if you want to use, say, a virtual tunnel, >currently that tunnel cannot be created by XORP itself; the tunnel >must be created externally (by user-level UNIX program, etc). As long as I can create and delete interfaces dynamically from XORP, it would be fine. Like in a commercial router, I just want to be able to create and delete interfaces without doing this through OS, in other words, the interface will be added into or removed from UNIX kernel programmatically through XORP. >If you want to use a network interface in XORP, you must explicitly >tell XORP about it, Is this done statically from a configuration file? Again, I just want to be able to do it on the fly inside XORP. Thanks! Regards, Yonghong Ren -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Tuesday, January 18, 2005 4:08 PM To: Yonghong Ren Cc: atanu@ICSI.Berkeley.EDU; Pavlin Radoslavov; xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] Large Number of Interfaces > I would like to set the compilation issues aside for a moment and > discuss a different aspect, namely the best way to support large number > of interfaces. > > A system may have say 40 physical interfaces, with X number of logical > interfaces (virtual router interface for example). > > The current design choice appears to be leveraging the native OS > Ethernet interface mechanism. In other words, every interface would > appears as a native OS interface. A clarification: we can deal with every interface that appears in the kernel and is visible by "ifconfig -a" (including virtual interfaces, etc). We wanted to use what is already in the system rather than inventing our own virtual interface space. On the other hand, if you want to use, say, a virtual tunnel, currently that tunnel cannot be created by XORP itself; the tunnel must be created externally (by user-level UNIX program, etc). > What are the pros and cons (if there is any :)) of this approach? Some > questions I have are: > > 1) Is this scalable? That is, would say 100 interfaces cause problems to > the OS? For a number of reasons there are some places inside the FEA where we use linear processing when some of the interface-related info has changed. Obviously, this is scalable up to a point, but I doubt the CPU overhead will be notable with hundreds of interfaces. > 2) The interfaces may be added and removed dynamically. Would this be > OK? If you want to use a network interface in XORP, you must explicitly tell XORP about it, otherwise XORP doesn't know it is suppose to use it. At least, you must tell XORP the name of the interface. Then, the design allows to dynamically track the state of that interface (e.g., if an IP address is added/deleted, if the interface itself is enabled/disabled/deleted, etc). Though, admittably, the dynamic tracking functionality hasn't been tested well. > 3) What assumptions and requirements does XORP stack requires each > interface? For example, the routing protocols would be assuming socket > library access through the interfaces and therefore the interface has to > provide socket access. So, that would be a big advantage to make each > interface a network interface at the OS level so to leverage the TCP/IP > stack and socket mechanism. Probably I don't understand this question, but all interfaces used by XORP are at the OS level, hence we always use the TCP/IP stack and socket mechanism provided by the system. > 4) I wonder how this is typically done in a large commercial router. I don't know. Given that we use the UNIX kernel, we leverage on the functionalities it provides already. The downside is that an interface may be modified on-the-fly by user-level commands (outside of XORP), hence we need to consider this scenario. I guess that in commercial routers the configuration is controlled via the router startup configuration or the CLI, hence everything is explicit. Regards, Pavlin From ren@sandmail.sandburst.com Thu Jan 20 16:02:39 2005 From: ren@sandmail.sandburst.com (Yonghong Ren) Date: Thu, 20 Jan 2005 11:02:39 -0500 Subject: [Xorp-hackers] "gmake check" failure - test_xrl_atom says "xrlatom bad type" Message-ID: ./test_xrl_atom InvalidString from line 430 of xrl_atom.cc -> xrlatom bad type: "%/1€iso8859-15ÏÜbinarya" Aborted (gdb) bt #0 0x0fbdfaa0 in kill () from /lib/libc.so.6 #1 0x0fbdf868 in raise () from /lib/libc.so.6 #2 0x0fbe0f78 in abort () from /lib/libc.so.6 #3 0x0fe783e0 in __cxxabiv1::__terminate(void (*)()) () from /usr/lib/libstdc++.so.5 #4 0x0fe78434 in __cxxabiv1::__unexpected(void (*)()) () from /usr/lib/libstdc++.so.5 #5 0x0fe78604 in __cxa_rethrow () from /usr/lib/libstdc++.so.5 #6 0x1000afa8 in XrlAtom (this=0x7ffff970, serialized=0x1003d83c "\020\003%/1€iso8859-15Ïì\020binary\201a") at xrl_atom.cc:430 #7 0x10002e74 in ascii_test (a=@0x7ffffa20) at test_xrl_atom.cc:52 #8 0x100037cc in test_atom (a=@0x7ffffa20) at test_xrl_atom.cc:122 #9 0x100044a8 in test () at test_xrl_atom.cc:225 #10 0x100045f4 in main (argc=1, argv=0x7ffffb74) at test_xrl_atom.cc:252 #11 0x0fbc9ed8 in __libc_start_main () from /lib/libc.so.6 (gdb) x/256x 0x1003d83c 0x1003d83c: 0x10 0x03 0xcf 0xec 0x10 0x62 0x69 0x6e 0x1003d844: 0x61 0x72 0x79 0x81 0x61 0x00 0xdd 0xbf 0x1003d84c: 0xa8 0x10 0x44 0xef 0x00 0x00 0x00 0x00 0x1003d854: 0x00 0x00 0x00 0x29 0x0f 0xfe 0x99 0x78 0x1003d85c: 0x00 0x00 0x00 0x04 0x0f 0xfe 0x99 0x8c 0x1003d864: 0x0f 0xfe 0x99 0xac 0x0f 0xfe 0x99 0xe8 0x1003d86c: 0x0f 0xfe 0x9a 0x08 0x02 0xc0 0x4f 0xff 0x1003d874: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x28 0x1003d87c: 0x00 0x00 0x07 0x19 0x10 0x03 0xd8 0xf8 0x1003d884: 0x00 0x00 0x00 0x16 0xff 0xff 0xff 0xff 0x1003d88c: 0x25 0x44 0x37 0x25 0x43 0x41 0x25 0x43 0x1003d894: 0x44 0x68 0x21 0x25 0x46 0x38 0x25 0x30 0x1003d89c: 0x43 0x25 0x30 0x38 0x33 0x31 0x00 0x39 0x1003d8a4: 0x34 0x53 0x00 0xe7 0x10 0x03 0xd9 0x20 0x1003d8ac: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff 0x1003d8b4: 0x45 0x6d 0x70 0x74 0x79 0x5f 0x73 0x74 0x1003d8bc: 0x72 0x69 0x6e 0x67 0x5f 0x6f 0x66 0x5f 0x1003d8c4: 0x6d 0x69 0x6e 0x65 0x00 0x00 0x37 0x31 0x1003d8cc: 0x00 0x00 0x00 0x00 0x10 0x03 0xd8 0xa8 0x1003d8d4: 0x96 0x8f 0x38 0x5c 0x2a 0xec 0xb0 0x3b 0x1003d8dc: 0xfb 0x32 0xaf 0x3c 0x54 0xec 0x18 0xdb 0x1003d8e4: 0x5c 0x02 0x1a 0xfe 0x43 0xfb 0xfa 0xaa 0x1003d8ec: 0x3a 0xfb 0x29 0xd1 0xe6 0x05 0x3c 0x7c 0x1003d8f4: 0x3d 0x00 0x00 0x00 0x10 0x03 0xd8 0xd0 0x1003d8fc: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff 0x1003d904: 0x25 0x44 0x37 0x25 0x43 0x41 0x25 0x43 0x1003d90c: 0x44 0x68 0x21 0x25 0x46 0x38 0x25 0x30 0x1003d914: 0x43 0x25 0x30 0x38 0x00 0x31 0x00 0x39 0x1003d91c: 0x34 0x00 0x00 0x00 0x10 0x03 0xd9 0x48 0x1003d924: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff 0x1003d92c: 0x45 0x6d 0x70 0x74 0x79 0x5f 0x73 0x74 0x1003d934: 0x72 0x69 0x6e 0x67 0x5f 0x6f 0x66 0x5f (gdb) x/256c 0x1003d83c 0x1003d83c: 16 '\020' 3 '\003' -49 '%/1€Œiso8859-15Ï' -20 '%/1€Œiso8859-15ì' 16 '\020' 98 'b' 105 'i' 110 'n' 0x1003d844: 97 'a' 114 'r' 121 'y' -127 '\201' 97 'a' 0 '\0' -35 '%/1€Œiso8859-15Ý' -65 '%/1€Œiso8859-15¿' 0x1003d84c: -88 '%/1€Œiso8859-15¨' 16 '\020' 68 'D' -17 '%/1€Œiso8859-15ï' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0x1003d854: 0 '\0' 0 '\0' 0 '\0' 41 ')' 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' 120 'x' 0x1003d85c: 0 '\0' 0 '\0' 0 '\0' 4 '\004' 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' -116 '\214' 0x1003d864: 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' -84 '%/1€Œiso8859-15¬' 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' -24 '%/1€Œiso8859-15è' 0x1003d86c: 15 '\017' -2 '%/1€Œiso8859-15þ' -102 '\232' 8 '\b' 2 '\002' -64 '%/1€Œiso8859-15À' 79 'O' -1 '%/1€Œiso8859-15ÿ' 0x1003d874: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 40 '(' 0x1003d87c: 0 '\0' 0 '\0' 7 '\a' 25 '\031' 16 '\020' 3 '\003' -40 '%/1€Œiso8859-15Ø' -8 '%/1€Œiso8859-15ø' 0x1003d884: 0 '\0' 0 '\0' 0 '\0' 22 '\026' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' 0x1003d88c: 37 '%' 68 'D' 55 '7' 37 '%' 67 'C' 65 'A' 37 '%' 67 'C' 0x1003d894: 68 'D' 104 'h' 33 '!' 37 '%' 70 'F' 56 '8' 37 '%' 48 '0' 0x1003d89c: 67 'C' 37 '%' 48 '0' 56 '8' 51 '3' 49 '1' 0 '\0' 57 '9' 0x1003d8a4: 52 '4' 83 'S' 0 '\0' -25 '%/1€Œiso8859-15ç' 16 '\020' 3 '\003' -39 '%/1€Œiso8859-15Ù' 32 ' ' 0x1003d8ac: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' 0x1003d8b4: 69 'E' 109 'm' 112 'p' 116 't' 121 'y' 95 '_' 115 's' 116 't' 0x1003d8bc: 114 'r' 105 'i' 110 'n' 103 'g' 95 '_' 111 'o' 102 'f' 95 '_' 0x1003d8c4: 109 'm' 105 'i' 110 'n' 101 'e' 0 '\0' 0 '\0' 55 '7' 49 '1' 0x1003d8cc: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -40 '%/1€Œiso8859-15Ø' -88 '%/1€Œiso8859-15¨' 0x1003d8d4: -106 '\226' -113 '\217' 56 '8' 92 '\\' 42 '*' -20 '%/1€Œiso8859-15ì' -80 '%/1€Œiso8859-15°' 59 ';' 0x1003d8dc: -5 '%/1€Œiso8859-15û' 50 '2' -81 '%/1€Œiso8859-15¯' 60 '<' 84 'T' -20 '%/1€Œiso8859-15ì' 24 '\030' -37 '%/1€Œiso8859-15Û' 0x1003d8e4: 92 '\\' 2 '\002' 26 '\032' -2 '%/1€Œiso8859-15þ' 67 'C' -5 '%/1€Œiso8859-15û' -6 '%/1€Œiso8859-15ú' -86 '%/1€Œiso8859-15ª' 0x1003d8ec: 58 ':' -5 '%/1€Œiso8859-15û' 41 ')' -47 '%/1€Œiso8859-15Ñ' -26 '%/1€Œiso8859-15æ' 5 '\005' 60 '<' 124 '|' 0x1003d8f4: 61 '=' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -40 '%/1€Œiso8859-15Ø' -48 '%/1€Œiso8859-15Ð' 0x1003d8fc: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' 0x1003d904: 37 '%' 68 'D' 55 '7' 37 '%' 67 'C' 65 'A' 37 '%' 67 'C' 0x1003d90c: 68 'D' 104 'h' 33 '!' 37 '%' 70 'F' 56 '8' 37 '%' 48 '0' 0x1003d914: 67 'C' 37 '%' 48 '0' 56 '8' 0 '\0' 49 '1' 0 '\0' 57 '9' 0x1003d91c: 52 '4' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -39 '%/1€Œiso8859-15Ù' 72 'H' 0x1003d924: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' 0x1003d92c: 69 'E' 109 'm' 112 'p' 116 't' 121 'y' 95 '_' 115 's' 116 't' 0x1003d934: 114 'r' 105 'i' 110 'n' 103 'g' 95 '_' 111 'o' 102 'f' 95 '_' (gdb) From pavlin@icir.org Thu Jan 20 19:06:14 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 20 Jan 2005 11:06:14 -0800 Subject: [Xorp-hackers] Large Number of Interfaces In-Reply-To: Message from "Yonghong Ren" of "Thu, 20 Jan 2005 11:00:24 EST." Message-ID: <200501201906.j0KJ6Exv018351@possum.icir.org> > >On the other hand, if you want to use, say, a virtual tunnel, > >currently that tunnel cannot be created by XORP itself; the tunnel > >must be created externally (by user-level UNIX program, etc). > > As long as I can create and delete interfaces dynamically from XORP, it > would be fine. Like in a commercial router, I just want to be able to > create and delete interfaces without doing this through OS, in other > words, the interface will be added into or removed from UNIX kernel > programmatically through XORP. No, unfortunately currently you cannot use XORP to create the interfaces inside the kernel, and you have to use the OS. Adding this functionality is on our TODO list. > >If you want to use a network interface in XORP, you must explicitly > >tell XORP about it, > > Is this done statically from a configuration file? Again, I just want to > be able to do it on the fly inside XORP. Currently, after the interface is created in the kernel by the OS, you still have to tell XORP about it (e.g., in the config file, or on the fly by xorpsh), so XORP can use it. In the future, you will have to tell only XORP about it (in config file or on the fly by xorpsh), and XORP will create it for you. I believe this is the desired behavior you describe. BTW, can you be a bit more specific about the type of dynamic interfaces you want to create/use, This can help defining the solution. Regards, Pavlin From pavlin@icir.org Thu Jan 20 19:09:57 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 20 Jan 2005 11:09:57 -0800 Subject: [Xorp-hackers] "gmake check" failure - test_xrl_atom says "xrlatom bad type" In-Reply-To: Message from "Yonghong Ren" of "Thu, 20 Jan 2005 11:02:39 EST." Message-ID: <200501201909.j0KJ9vYc018428@possum.icir.org> Yonghong, What OS version and compiler do you use? Also, is this problem always repeatable? Thanks, Pavlin > ./test_xrl_atom > InvalidString from line 430 of xrl_atom.cc -> xrlatom bad type: "%/1‚iso8859-15ÏÓbinarya" > Aborted > > (gdb) bt > #0 0x0fbdfaa0 in kill () from /lib/libc.so.6 > #1 0x0fbdf868 in raise () from /lib/libc.so.6 > #2 0x0fbe0f78 in abort () from /lib/libc.so.6 > #3 0x0fe783e0 in __cxxabiv1::__terminate(void (*)()) () from /usr/lib/libstdc++.so.5 > #4 0x0fe78434 in __cxxabiv1::__unexpected(void (*)()) () from /usr/lib/libstdc++.so.5 > #5 0x0fe78604 in __cxa_rethrow () from /usr/lib/libstdc++.so.5 > #6 0x1000afa8 in XrlAtom (this=0x7ffff970, serialized=0x1003d83c "\020\003%/1‚iso8859-15Ïì\020binary\201a") at xrl_atom.cc:430 > #7 0x10002e74 in ascii_test (a=@0x7ffffa20) at test_xrl_atom.cc:52 > #8 0x100037cc in test_atom (a=@0x7ffffa20) at test_xrl_atom.cc:122 > #9 0x100044a8 in test () at test_xrl_atom.cc:225 > #10 0x100045f4 in main (argc=1, argv=0x7ffffb74) at test_xrl_atom.cc:252 > #11 0x0fbc9ed8 in __libc_start_main () from /lib/libc.so.6 > (gdb) x/256x 0x1003d83c > 0x1003d83c: 0x10 0x03 0xcf 0xec 0x10 0x62 0x69 0x6e > 0x1003d844: 0x61 0x72 0x79 0x81 0x61 0x00 0xdd 0xbf > 0x1003d84c: 0xa8 0x10 0x44 0xef 0x00 0x00 0x00 0x00 > 0x1003d854: 0x00 0x00 0x00 0x29 0x0f 0xfe 0x99 0x78 > 0x1003d85c: 0x00 0x00 0x00 0x04 0x0f 0xfe 0x99 0x8c > 0x1003d864: 0x0f 0xfe 0x99 0xac 0x0f 0xfe 0x99 0xe8 > 0x1003d86c: 0x0f 0xfe 0x9a 0x08 0x02 0xc0 0x4f 0xff > 0x1003d874: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x28 > 0x1003d87c: 0x00 0x00 0x07 0x19 0x10 0x03 0xd8 0xf8 > 0x1003d884: 0x00 0x00 0x00 0x16 0xff 0xff 0xff 0xff > 0x1003d88c: 0x25 0x44 0x37 0x25 0x43 0x41 0x25 0x43 > 0x1003d894: 0x44 0x68 0x21 0x25 0x46 0x38 0x25 0x30 > 0x1003d89c: 0x43 0x25 0x30 0x38 0x33 0x31 0x00 0x39 > 0x1003d8a4: 0x34 0x53 0x00 0xe7 0x10 0x03 0xd9 0x20 > 0x1003d8ac: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff > 0x1003d8b4: 0x45 0x6d 0x70 0x74 0x79 0x5f 0x73 0x74 > 0x1003d8bc: 0x72 0x69 0x6e 0x67 0x5f 0x6f 0x66 0x5f > 0x1003d8c4: 0x6d 0x69 0x6e 0x65 0x00 0x00 0x37 0x31 > 0x1003d8cc: 0x00 0x00 0x00 0x00 0x10 0x03 0xd8 0xa8 > 0x1003d8d4: 0x96 0x8f 0x38 0x5c 0x2a 0xec 0xb0 0x3b > 0x1003d8dc: 0xfb 0x32 0xaf 0x3c 0x54 0xec 0x18 0xdb > 0x1003d8e4: 0x5c 0x02 0x1a 0xfe 0x43 0xfb 0xfa 0xaa > 0x1003d8ec: 0x3a 0xfb 0x29 0xd1 0xe6 0x05 0x3c 0x7c > 0x1003d8f4: 0x3d 0x00 0x00 0x00 0x10 0x03 0xd8 0xd0 > 0x1003d8fc: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff > 0x1003d904: 0x25 0x44 0x37 0x25 0x43 0x41 0x25 0x43 > 0x1003d90c: 0x44 0x68 0x21 0x25 0x46 0x38 0x25 0x30 > 0x1003d914: 0x43 0x25 0x30 0x38 0x00 0x31 0x00 0x39 > 0x1003d91c: 0x34 0x00 0x00 0x00 0x10 0x03 0xd9 0x48 > 0x1003d924: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff > 0x1003d92c: 0x45 0x6d 0x70 0x74 0x79 0x5f 0x73 0x74 > 0x1003d934: 0x72 0x69 0x6e 0x67 0x5f 0x6f 0x66 0x5f > (gdb) x/256c 0x1003d83c > 0x1003d83c: 16 '\020' 3 '\003' -49 '%/1‚Œiso8859-15Ï' -20 '%/1‚Œiso8859-15ì' 16 '\020' 98 'b' 105 'i' 110 'n' > 0x1003d844: 97 'a' 114 'r' 121 'y' -127 '\201' 97 'a' 0 '\0' -35 '%/1‚Œiso8859-15Ý' -65 '%/1‚Œiso8859-15¿' > 0x1003d84c: -88 '%/1‚Œiso8859-15¨' 16 '\020' 68 'D' -17 '%/1‚Œiso8859-15ï' 0 '\0' 0 '\0' 0 '\0' 0 '\0' > 0x1003d854: 0 '\0' 0 '\0' 0 '\0' 41 ')' 15 '\017' -2 '%/1‚Œiso8859-15þ' -103 '\231' 120 'x' > 0x1003d85c: 0 '\0' 0 '\0' 0 '\0' 4 '\004' 15 '\017' -2 '%/1‚Œiso8859-15þ' -103 '\231' -116 '\214' > 0x1003d864: 15 '\017' -2 '%/1‚Œiso8859-15þ' -103 '\231' -84 '%/1‚Œiso8859-15¬' 15 '\017' -2 '%/1‚Œiso8859-15þ' -103 '\231' -24 '%/1‚Œiso8859-15è' > 0x1003d86c: 15 '\017' -2 '%/1‚Œiso8859-15þ' -102 '\232' 8 '\b' 2 '\002' -64 '%/1‚Œiso8859-15Â' 79 'O' -1 '%/1‚Œiso8859-15ÿ' > 0x1003d874: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 40 '(' > 0x1003d87c: 0 '\0' 0 '\0' 7 '\a' 25 '\031' 16 '\020' 3 '\003' -40 '%/1‚Œiso8859-15Ü' -8 '%/1‚Œiso8859-15ø' > 0x1003d884: 0 '\0' 0 '\0' 0 '\0' 22 '\026' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' > 0x1003d88c: 37 '%' 68 'D' 55 '7' 37 '%' 67 'C' 65 'A' 37 '%' 67 'C' > 0x1003d894: 68 'D' 104 'h' 33 '!' 37 '%' 70 'F' 56 '8' 37 '%' 48 '0' > 0x1003d89c: 67 'C' 37 '%' 48 '0' 56 '8' 51 '3' 49 '1' 0 '\0' 57 '9' > 0x1003d8a4: 52 '4' 83 'S' 0 '\0' -25 '%/1‚Œiso8859-15ç' 16 '\020' 3 '\003' -39 '%/1‚Œiso8859-15Ä' 32 ' ' > 0x1003d8ac: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' > 0x1003d8b4: 69 'E' 109 'm' 112 'p' 116 't' 121 'y' 95 '_' 115 's' 116 't' > 0x1003d8bc: 114 'r' 105 'i' 110 'n' 103 'g' 95 '_' 111 'o' 102 'f' 95 '_' > 0x1003d8c4: 109 'm' 105 'i' 110 'n' 101 'e' 0 '\0' 0 '\0' 55 '7' 49 '1' > 0x1003d8cc: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -40 '%/1‚Œiso8859-15Ü' -88 '%/1‚Œiso8859-15¨' > 0x1003d8d4: -106 '\226' -113 '\217' 56 '8' 92 '\\' 42 '*' -20 '%/1‚Œiso8859-15ì' -80 '%/1‚Œiso8859-15°' 59 ';' > 0x1003d8dc: -5 '%/1‚Œiso8859-15û' 50 '2' -81 '%/1‚Œiso8859-15¯' 60 '<' 84 'T' -20 '%/1‚Œiso8859-15ì' 24 '\030' -37 '%/1‚Œiso8859-15À' > 0x1003d8e4: 92 '\\' 2 '\002' 26 '\032' -2 '%/1‚Œiso8859-15þ' 67 'C' -5 '%/1‚Œiso8859-15û' -6 '%/1‚Œiso8859-15ú' -86 '%/1‚Œiso8859-15ª' > 0x1003d8ec: 58 ':' -5 '%/1‚Œiso8859-15û' 41 ')' -47 '%/1‚Œiso8859-15À˜' -26 '%/1‚Œiso8859-15æ' 5 '\005' 60 '<' 124 '|' > 0x1003d8f4: 61 '=' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -40 '%/1‚Œiso8859-15Ü' -48 '%/1‚Œiso8859-15Ð' > 0x1003d8fc: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' > 0x1003d904: 37 '%' 68 'D' 55 '7' 37 '%' 67 'C' 65 'A' 37 '%' 67 'C' > 0x1003d90c: 68 'D' 104 'h' 33 '!' 37 '%' 70 'F' 56 '8' 37 '%' 48 '0' > 0x1003d914: 67 'C' 37 '%' 48 '0' 56 '8' 0 '\0' 49 '1' 0 '\0' 57 '9' > 0x1003d91c: 52 '4' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -39 '%/1‚Œiso8859-15Ä' 72 'H' > 0x1003d924: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' -1 '%/1‚Œiso8859-15ÿ' > 0x1003d92c: 69 'E' 109 'm' 112 'p' 116 't' 121 'y' 95 '_' 115 's' 116 't' > 0x1003d934: 114 'r' 105 'i' 110 'n' 103 'g' 95 '_' 111 'o' 102 'f' 95 '_' > (gdb) > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ren@sandmail.sandburst.com Thu Jan 20 19:45:54 2005 From: ren@sandmail.sandburst.com (Yonghong Ren) Date: Thu, 20 Jan 2005 14:45:54 -0500 Subject: [Xorp-hackers] Large Number of Interfaces Message-ID: >BTW, can you be a bit more specific about the type of dynamic >interfaces you want to create/use, This can help defining the >solution. By "dynamic", I meant the ability to create/delete interfaces on the fly (inside of xorpsh for example), as you said. I didn't mean "dynamic interface" as a different type of interfaces. That is, it's just a plain interface, which could be for example a plain Ethernet interface or a logical interface on a physical interface. Sorry for the confusion. In any case, your explanation is helpful for me to understand what XORP can or can't do at the moment. >Adding this functionality is on our TODO list. Adding this would be very nice. Obviously one could build something that add/delete interfaces to/from OS via a different path, but I hope that xorpsh will be the interface that one does everything. This would be a keen to CLI of any switch/router. Is XORP-sh extensible? In other words, could I add my own commands and interfaces? The platform I am working with has capabilities other than routing such as Ethernet switching (including VLAN), MPLS, etc. It would be nice that I could use xorpsh to integrate my Ethernet switching and MPLS commands. I have barely looked into XORP. Hopefully I am not asking too many uneducated questions. I really ought to study xorp first. Thanks! Regards, Yonghong Ren -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Thursday, January 20, 2005 2:06 PM To: Yonghong Ren Cc: Pavlin Radoslavov; atanu@ICSI.Berkeley.EDU; xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] Large Number of Interfaces > >On the other hand, if you want to use, say, a virtual tunnel, > >currently that tunnel cannot be created by XORP itself; the tunnel > >must be created externally (by user-level UNIX program, etc). > > As long as I can create and delete interfaces dynamically from XORP, it > would be fine. Like in a commercial router, I just want to be able to > create and delete interfaces without doing this through OS, in other > words, the interface will be added into or removed from UNIX kernel > programmatically through XORP. No, unfortunately currently you cannot use XORP to create the interfaces inside the kernel, and you have to use the OS. Adding this functionality is on our TODO list. > >If you want to use a network interface in XORP, you must explicitly > >tell XORP about it, > > Is this done statically from a configuration file? Again, I just want to > be able to do it on the fly inside XORP. Currently, after the interface is created in the kernel by the OS, you still have to tell XORP about it (e.g., in the config file, or on the fly by xorpsh), so XORP can use it. In the future, you will have to tell only XORP about it (in config file or on the fly by xorpsh), and XORP will create it for you. I believe this is the desired behavior you describe. BTW, can you be a bit more specific about the type of dynamic interfaces you want to create/use, This can help defining the solution. Regards, Pavlin From ren@sandmail.sandburst.com Thu Jan 20 19:51:33 2005 From: ren@sandmail.sandburst.com (Yonghong Ren) Date: Thu, 20 Jan 2005 14:51:33 -0500 Subject: [Xorp-hackers] "gmake check" failure - test_xrl_atom says "xrlatom bad type" Message-ID: Pavlin, OS: LINUX 2.4.21, from ELDK package. Compiler: gcc 3.2.2 It's repeatable: cd libxipc ./test_xrl_atom - gives the error every time. If you have suggestions on ways to look into this, please let me know. Thanks! Regards, Yonghong Ren -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Thursday, January 20, 2005 2:10 PM To: Yonghong Ren Cc: xorp-hackers@xorp.org Subject: Re: [Xorp-hackers] "gmake check" failure - test_xrl_atom says "xrlatom bad type" Yonghong, What OS version and compiler do you use? Also, is this problem always repeatable? Thanks, Pavlin > ./test_xrl_atom > InvalidString from line 430 of xrl_atom.cc -> xrlatom bad type: "%/1€iso8859-15ÏÃÅ“binarya" > Aborted > > (gdb) bt > #0 0x0fbdfaa0 in kill () from /lib/libc.so.6 > #1 0x0fbdf868 in raise () from /lib/libc.so.6 > #2 0x0fbe0f78 in abort () from /lib/libc.so.6 > #3 0x0fe783e0 in __cxxabiv1::__terminate(void (*)()) () from /usr/lib/libstdc++.so.5 > #4 0x0fe78434 in __cxxabiv1::__unexpected(void (*)()) () from /usr/lib/libstdc++.so.5 > #5 0x0fe78604 in __cxa_rethrow () from /usr/lib/libstdc++.so.5 > #6 0x1000afa8 in XrlAtom (this=0x7ffff970, serialized=0x1003d83c "\020\003%/1€iso8859-15Ïì\020binary\201a") at xrl_atom.cc:430 > #7 0x10002e74 in ascii_test (a=@0x7ffffa20) at test_xrl_atom.cc:52 > #8 0x100037cc in test_atom (a=@0x7ffffa20) at test_xrl_atom.cc:122 > #9 0x100044a8 in test () at test_xrl_atom.cc:225 > #10 0x100045f4 in main (argc=1, argv=0x7ffffb74) at test_xrl_atom.cc:252 > #11 0x0fbc9ed8 in __libc_start_main () from /lib/libc.so.6 > (gdb) x/256x 0x1003d83c > 0x1003d83c: 0x10 0x03 0xcf 0xec 0x10 0x62 0x69 0x6e > 0x1003d844: 0x61 0x72 0x79 0x81 0x61 0x00 0xdd 0xbf > 0x1003d84c: 0xa8 0x10 0x44 0xef 0x00 0x00 0x00 0x00 > 0x1003d854: 0x00 0x00 0x00 0x29 0x0f 0xfe 0x99 0x78 > 0x1003d85c: 0x00 0x00 0x00 0x04 0x0f 0xfe 0x99 0x8c > 0x1003d864: 0x0f 0xfe 0x99 0xac 0x0f 0xfe 0x99 0xe8 > 0x1003d86c: 0x0f 0xfe 0x9a 0x08 0x02 0xc0 0x4f 0xff > 0x1003d874: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x28 > 0x1003d87c: 0x00 0x00 0x07 0x19 0x10 0x03 0xd8 0xf8 > 0x1003d884: 0x00 0x00 0x00 0x16 0xff 0xff 0xff 0xff > 0x1003d88c: 0x25 0x44 0x37 0x25 0x43 0x41 0x25 0x43 > 0x1003d894: 0x44 0x68 0x21 0x25 0x46 0x38 0x25 0x30 > 0x1003d89c: 0x43 0x25 0x30 0x38 0x33 0x31 0x00 0x39 > 0x1003d8a4: 0x34 0x53 0x00 0xe7 0x10 0x03 0xd9 0x20 > 0x1003d8ac: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff > 0x1003d8b4: 0x45 0x6d 0x70 0x74 0x79 0x5f 0x73 0x74 > 0x1003d8bc: 0x72 0x69 0x6e 0x67 0x5f 0x6f 0x66 0x5f > 0x1003d8c4: 0x6d 0x69 0x6e 0x65 0x00 0x00 0x37 0x31 > 0x1003d8cc: 0x00 0x00 0x00 0x00 0x10 0x03 0xd8 0xa8 > 0x1003d8d4: 0x96 0x8f 0x38 0x5c 0x2a 0xec 0xb0 0x3b > 0x1003d8dc: 0xfb 0x32 0xaf 0x3c 0x54 0xec 0x18 0xdb > 0x1003d8e4: 0x5c 0x02 0x1a 0xfe 0x43 0xfb 0xfa 0xaa > 0x1003d8ec: 0x3a 0xfb 0x29 0xd1 0xe6 0x05 0x3c 0x7c > 0x1003d8f4: 0x3d 0x00 0x00 0x00 0x10 0x03 0xd8 0xd0 > 0x1003d8fc: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff > 0x1003d904: 0x25 0x44 0x37 0x25 0x43 0x41 0x25 0x43 > 0x1003d90c: 0x44 0x68 0x21 0x25 0x46 0x38 0x25 0x30 > 0x1003d914: 0x43 0x25 0x30 0x38 0x00 0x31 0x00 0x39 > 0x1003d91c: 0x34 0x00 0x00 0x00 0x10 0x03 0xd9 0x48 > 0x1003d924: 0x00 0x00 0x00 0x14 0xff 0xff 0xff 0xff > 0x1003d92c: 0x45 0x6d 0x70 0x74 0x79 0x5f 0x73 0x74 > 0x1003d934: 0x72 0x69 0x6e 0x67 0x5f 0x6f 0x66 0x5f > (gdb) x/256c 0x1003d83c > 0x1003d83c: 16 '\020' 3 '\003' -49 '%/1€Œiso8859-15Ï' -20 '%/1€Œiso8859-15ì' 16 '\020' 98 'b' 105 'i' 110 'n' > 0x1003d844: 97 'a' 114 'r' 121 'y' -127 '\201' 97 'a' 0 '\0' -35 '%/1€Œiso8859-15Ý' -65 '%/1€Œiso8859-15¿' > 0x1003d84c: -88 '%/1€Œiso8859-15¨' 16 '\020' 68 'D' -17 '%/1€Œiso8859-15ï' 0 '\0' 0 '\0' 0 '\0' 0 '\0' > 0x1003d854: 0 '\0' 0 '\0' 0 '\0' 41 ')' 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' 120 'x' > 0x1003d85c: 0 '\0' 0 '\0' 0 '\0' 4 '\004' 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' -116 '\214' > 0x1003d864: 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' -84 '%/1€Œiso8859-15¬' 15 '\017' -2 '%/1€Œiso8859-15þ' -103 '\231' -24 '%/1€Œiso8859-15è' > 0x1003d86c: 15 '\017' -2 '%/1€Œiso8859-15þ' -102 '\232' 8 '\b' 2 '\002' -64 '%/1€Œiso8859-15À' 79 'O' -1 '%/1€Œiso8859-15ÿ' > 0x1003d874: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 40 '(' > 0x1003d87c: 0 '\0' 0 '\0' 7 '\a' 25 '\031' 16 '\020' 3 '\003' -40 '%/1€Œiso8859-15ÃËÂœ' -8 '%/1€Œiso8859-15ø' > 0x1003d884: 0 '\0' 0 '\0' 0 '\0' 22 '\026' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' > 0x1003d88c: 37 '%' 68 'D' 55 '7' 37 '%' 67 'C' 65 'A' 37 '%' 67 'C' > 0x1003d894: 68 'D' 104 'h' 33 '!' 37 '%' 70 'F' 56 '8' 37 '%' 48 '0' > 0x1003d89c: 67 'C' 37 '%' 48 '0' 56 '8' 51 '3' 49 '1' 0 '\0' 57 '9' > 0x1003d8a4: 52 '4' 83 'S' 0 '\0' -25 '%/1€Œiso8859-15ç' 16 '\020' 3 '\003' -39 '%/1€Œiso8859-15Ãâ„¢' 32 ' ' > 0x1003d8ac: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' > 0x1003d8b4: 69 'E' 109 'm' 112 'p' 116 't' 121 'y' 95 '_' 115 's' 116 't' > 0x1003d8bc: 114 'r' 105 'i' 110 'n' 103 'g' 95 '_' 111 'o' 102 'f' 95 '_' > 0x1003d8c4: 109 'm' 105 'i' 110 'n' 101 'e' 0 '\0' 0 '\0' 55 '7' 49 '1' > 0x1003d8cc: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -40 '%/1€Œiso8859-15ÃËÂœ' -88 '%/1€Œiso8859-15¨' > 0x1003d8d4: -106 '\226' -113 '\217' 56 '8' 92 '\\' 42 '*' -20 '%/1€Œiso8859-15ì' -80 '%/1€Œiso8859-15°' 59 ';' > 0x1003d8dc: -5 '%/1€Œiso8859-15û' 50 '2' -81 '%/1€Œiso8859-15¯' 60 '<' 84 'T' -20 '%/1€Œiso8859-15ì' 24 '\030' -37 '%/1€Œiso8859-15Û' > 0x1003d8e4: 92 '\\' 2 '\002' 26 '\032' -2 '%/1€Œiso8859-15þ' 67 'C' -5 '%/1€Œiso8859-15û' -6 '%/1€Œiso8859-15ú' -86 '%/1€Œiso8859-15ª' > 0x1003d8ec: 58 ':' -5 '%/1€Œiso8859-15û' 41 ')' -47 '%/1€Œiso8859-15Ñ' -26 '%/1€Œiso8859-15æ' 5 '\005' 60 '<' 124 '|' > 0x1003d8f4: 61 '=' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -40 '%/1€Œiso8859-15ÃËÂœ' -48 '%/1€Œiso8859-15Ð' > 0x1003d8fc: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' > 0x1003d904: 37 '%' 68 'D' 55 '7' 37 '%' 67 'C' 65 'A' 37 '%' 67 'C' > 0x1003d90c: 68 'D' 104 'h' 33 '!' 37 '%' 70 'F' 56 '8' 37 '%' 48 '0' > 0x1003d914: 67 'C' 37 '%' 48 '0' 56 '8' 0 '\0' 49 '1' 0 '\0' 57 '9' > 0x1003d91c: 52 '4' 0 '\0' 0 '\0' 0 '\0' 16 '\020' 3 '\003' -39 '%/1€Œiso8859-15Ãâ„¢' 72 'H' > 0x1003d924: 0 '\0' 0 '\0' 0 '\0' 20 '\024' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' -1 '%/1€Œiso8859-15ÿ' > 0x1003d92c: 69 'E' 109 'm' 112 'p' 116 't' 121 'y' 95 '_' 115 's' 116 't' > 0x1003d934: 114 'r' 105 'i' 110 'n' 103 'g' 95 '_' 111 'o' 102 'f' 95 '_' > (gdb) > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Thu Jan 20 20:23:01 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 20 Jan 2005 12:23:01 -0800 Subject: [Xorp-hackers] Large Number of Interfaces In-Reply-To: Message from "Yonghong Ren" of "Thu, 20 Jan 2005 14:45:54 EST." Message-ID: <200501202023.j0KKN10x019114@possum.icir.org> > >BTW, can you be a bit more specific about the type of dynamic > >interfaces you want to create/use, This can help defining the > >solution. > > By "dynamic", I meant the ability to create/delete interfaces on the fly > (inside of xorpsh for example), as you said. I didn't mean "dynamic > interface" as a different type of interfaces. That is, it's just a plain > interface, which could be for example a plain Ethernet interface or a > logical interface on a physical interface. Sorry for the confusion. A small clarification. On UNIX, you cannot from add from useland, say, an Ethernet interface if the hardware is not in the machine. The creation of such hardware-associated interfaces is done automatically by the kernel. > >Adding this functionality is on our TODO list. > > Adding this would be very nice. Obviously one could build something that > add/delete interfaces to/from OS via a different path, but I hope that > xorpsh will be the interface that one does everything. This would be a > keen to CLI of any switch/router. Is XORP-sh extensible? In other words, ~~~~~~~~~~~~~~~~~~~~~~ XORP (the eXtensible Open Router Platform) is suppose to be extensible by definition :) > could I add my own commands and interfaces? The platform I am working > with has capabilities other than routing such as Ethernet switching > (including VLAN), MPLS, etc. It would be nice that I could use xorpsh to > integrate my Ethernet switching and MPLS commands. Yes, you could extend xorpsh to run external commands from within the CLI. Currently, you can use the operational commands mode to do that (those are the "show"-like commands before you type "configure"). For example, the xorpsh "ping" and "traceroute" commands are implemented by running the external OS command. Please have a look in the "etc/templates/misc.cmds" and "etc/templates/host.cmds" files for examples of how to add your own external commands. Also, please have a look at Section 4.1 "Operational Commands and xorpsh" in the "XORP Router Manager Process (rtrmgr)" design document. You can use same mechanism to add the appropriate OS commands (e.g., ifconfig) to create the network interfaces you need. However, I would not recommend sticking with this hack for creating the network interfaces as a long-term solution. Configurating the system should be done within the configurational mode only. Hence, you should have it in mind that what you do now should be refactored to some more appropriate solution once XORP has the support for it. Regards, Pavlin From rafael.guimaraes@ac.upc.edu Thu Jan 20 20:27:11 2005 From: rafael.guimaraes@ac.upc.edu (Rafael Paoliello Guimaraes) Date: Thu, 20 Jan 2005 21:27:11 +0100 Subject: [Xorp-hackers] Problems when adding a static route In-Reply-To: <200501182136.j0ILa1lF090661@possum.icir.org> References: <200501182136.j0ILa1lF090661@possum.icir.org> Message-ID: <41F0141F.7070300@ac.upc.edu> >>Whenever I try to add a static route where the nexthop is an IP address >>for which there is more than one route, I get an error message telling >>that the route could not be added because the nexthop is not directly >>connected to the host. >> >>Well, in my case the route I was trying to add was: >> >> 10.0.1.1/32 nexthop 10.0.0.4 >> >>and I had the following pre-existing routes: >> >> 10.0.0.0/24 nexthop 10.0.0.1 (connected) >> 10.0.0.4/32 nexthop 0.0.0.0 (test) >> >>It seemed to me that the RIB was searching for a route to the nexthop >>not only in the connected routes, and than it had a match with the >>second route (which comes from the test protocol) and it though that the >>desired nexthop was not directly connected. In order to solve this, I >>changed my test protocol to add every 1-hop route as if it were the >>connected protocol (just by changing the protocol name parameter in the >>XRL call). Well, with this changes I had the following routing table: >> >> 10.0.0.0/24 nexthop 10.0.0.1 (connected) >> 10.0.0.4/32 nexthop 0.0.0.0 (connected) >> >>But I still get the same error (nexthop is not directly connected). When >>I don't have the second route in the table, everything goes fine... Does >>anybody know how to solve this? Am I doing something wrong? > > > First, I believe that you cannot explicitly add the > directly-connected routes to RIB. Those come from the network > interface information received by RIB from the REA. Ok. I was just trying to solve the problem (in a non-elegant way, for sure!). I have made a Ctrl+Z in my code and everything is back to normal. > To get around the problem, have you tried to use the > rib/0.1/add_interface_route4 XRL to explicitly specify the network > interface name toward the destination. No guarantee it will work, > but you can give it a try. What do you mean by this? I am not dealing directly with XRL calls in this case. I am trying to add a static route through static_routes. Is there anyway to indicate the interface of a static route? The command line I am using is: create protocol static route4 10.0.1.1/32 nexthop 10.0.0.4 If, instead, you are talking about my routing protocol, all routes it adds to the RIB are interface routes (added through rib/0.1/add_interface_route4). > If this still doesn't work, please include the particular error > messages you receive, so this can help locate the code that rejects > the "add route" command. The error I get is the following: [ 2005/01/20 19:54:06 INFO xorp_rtrmgr:2123 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/20 19:54:06 ERROR xorp_rib:2128 RIB +698 rib.cc add_route ] Attempting to add IGP route to table "static" (prefix 10.0.0.1/32 next-hop 10.0.0.4): no directly connected interface toward the next-hop router [ 2005/01/20 19:54:06 WARNING xorp_rib XrlRibTarget ] Handling method for rib/0.1/add_route4 failed: XrlCmdError 102 Command failed Could not add IPv4 route net 10.0.0.1/32, nexthop: 10.0.0.4 to unicast RIB [ 2005/01/20 19:54:06 INFO xorp_rtrmgr:2123 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/20 19:54:54 ERROR xorp_rtrmgr:2123 XRL +628 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: end of file Cheers, =========================================== Rafael Paoliello Guimaraes PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnic University of Catalonia (UPC) Phone: +34-934017187 Fax: +34-934017055 URL: http://people.ac.upc.es/rpaoliel =========================================== From pavlin@icir.org Sat Jan 22 09:45:49 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 22 Jan 2005 01:45:49 -0800 Subject: [Xorp-hackers] Problems when adding a static route In-Reply-To: Message from Rafael Paoliello Guimaraes of "Thu, 20 Jan 2005 21:27:11 +0100." <41F0141F.7070300@ac.upc.edu> Message-ID: <200501220945.j0M9jnKq028587@possum.icir.org> > >>Whenever I try to add a static route where the nexthop is an IP address > >>for which there is more than one route, I get an error message telling > >>that the route could not be added because the nexthop is not directly > >>connected to the host. > >> > >>Well, in my case the route I was trying to add was: > >> > >> 10.0.1.1/32 nexthop 10.0.0.4 > >> > >>and I had the following pre-existing routes: > >> > >> 10.0.0.0/24 nexthop 10.0.0.1 (connected) > >> 10.0.0.4/32 nexthop 0.0.0.0 (test) > The error I get is the following: > > [ 2005/01/20 19:54:06 INFO xorp_rtrmgr:2123 RTRMGR +1372 task.cc > run_task ] No more tasks to run > [ 2005/01/20 19:54:06 ERROR xorp_rib:2128 RIB +698 rib.cc add_route ] > Attempting to add IGP route to table "static" (prefix 10.0.0.1/32 > next-hop 10.0.0.4): no directly connected interface toward the next-hop > router > [ 2005/01/20 19:54:06 WARNING xorp_rib XrlRibTarget ] Handling method > for rib/0.1/add_route4 failed: XrlCmdError 102 Command failed Could not > add IPv4 route net 10.0.0.1/32, nexthop: 10.0.0.4 to unicast RIB > [ 2005/01/20 19:54:06 INFO xorp_rtrmgr:2123 RTRMGR +1372 task.cc > run_task ] No more tasks to run > [ 2005/01/20 19:54:54 ERROR xorp_rtrmgr:2123 XRL +628 xrl_pf_stcp.cc > die ] XrlPFSTCPSender died: end of file Rafael, There was a bug in the RIB which is now fixed. Please checkout the lastest CVS code and try if you still have the same problem. While on the subject. As you may know already, a route that is added to the kernel should either: (a) has a next-hop IP address that is directly connected OR (b) specifies the outgoing interface toward the destination. [Note that you cannot (at least on FreeBSD-4.9 and Linux-2.4.18) add a route to the kernel that specifies both the next-hop IP router address and the outgoing interface.] Previously the XORP static routes configuration supported only (a). Now there is support for (b) as well. The new configuration looks like: interface-route4 10.10.0.0/16 { next-hop-interface: "eth2" next-hop-vif: "eth2" } The corresponding IPv6 and multicast-related statements are "interface-route6", "mrib-interface-route4", and "mrib-interface-route6". Note that both "next-hop-interface" and "next-hop-vif" are mandatory. Also, the configuration statement "nexthop" in static_routes is now renamed to "next-hop" for consistency with the rest of the XORP configuration and the configuration of other router vendors. If you forget to rename "nexthop" to "next-hop" in your configuration file, the rtrmgr will tell you that "nexthop" is deprecated and will return an error. Regards, Pavlin From pavlin@icir.org Sat Jan 22 20:38:42 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 22 Jan 2005 12:38:42 -0800 Subject: [Xorp-hackers] Network interface naming Message-ID: <200501222038.j0MKcgm6000353@possum.icir.org> All, Below I am including an email from "Kurt J. Lidl" with some very interesting thoughts on the subject of network interface naming (email included with author's permission). This is definitely something that has to be considered, hence I am forwarding his email to the list to start a discussion on the subject. Thanks, Pavlin ------- Forwarded Message Date: Thu, 20 Jan 2005 22:00:58 -0500 From: "Kurt J. Lidl" To: Pavlin Radoslavov Subject: Re: [Xorp-hackers] Large Number of Interfaces On Thu, Jan 20, 2005 at 03:58:23PM -0800, Pavlin Radoslavov wrote: > > One of the things that most modern routers "get right" is that the > > interfaces present have consistant names, more or less based on > > slot number/interface number. And these names don't change if you > > put more hardware into the router/switch. > > > > Back in the bad old days at UUNET (I was one of the early ones there), > > we used Cisco AGS routers. These are multibus based computers, with > > either a 68030 or 68040 based CPU board, with or without flash to boot > > from, and various multibus based interfaces (2E2T, 4T, 4S, 2E), etc. > > > > The IOS code from that decade just attached interfaces as it found > > them, scanning from one slot to the next. (Similar to the way that > > unix machines do it today.) If slot 1 had a 2E2T card, you had > > ethernet0, ethernet1, serial0, serial1. If you skipped a slot, > > and then had a 4T card, you got additional interfaces - serial2..serial5. > > If you inserted a 4S card into the empty slot, the router would > > come up with ethernet0, ethernet1 and serial0..serial9. Of course, > > serial2..serial5 are now on the 4S card, not the 4T card! > > > > So, you'd have to furiously delete and move configurations from > > serial interface to serial interface many times when you changed > > the hardware. This sucked majorly. > > > > On modern cisco/juniper machines, you have a slot number/interface > > number scheme, so you might have gigabitethernet 0/1 or 0/2, and > > the interfaces don't go changing names out from under you, just > > because a new one got installed in the machine. > > > > This problem is more or less ingrained into BSD style networking > > stacks -- they just attach each instance of each driver type as > > it is probed and attached. > > > > One notable exception to this is the modified version of BSD/OS > > that Ascend changed for the GRF router. They had interfaces that > > had slot and unit numbers encoded in them, so the first ethernet > > on the machine might be ge000, and the second g001, etc. > > Where the unit numbers where 0XY and X==board, and Y==interface. > > > > There's going to be a understanding mis-match with XORP on unix > > machines and the router folks that expect interface names to remain > > consistant, even if hardware is added. And it will cause problems. > > It's not an XORP problem, but rather a fundemental difference in how > > BSD-ish systems attach interfaces. > > > > It might be interesting to figure out how hard it would be to > > change the interface probe and attach stuff to have things > > reordered/renamed by xorp. ie, the system attaches the following > > cards: > > fxp0 (single port pci card), > > fxp1 (first port on a dual-port PCI card), > > fxp2 (second port on a dual-port PCI card), > > fxp3 (single port pci card), > > > > but XORP could rename them to be fxp00,fxp10,fxp11,fxp20 > > > > Something to think about, at any rate... > > Very interesting, indeed. > I will inform the rest of the core team, and we will think about it. If you need/want to discuss this with me, I'd be happy to participate in email discussions about it. One other thing that strikes me, since the difficulty of getting the BSD systems (let alone any of the other unix-like platforms XORP runs on) to change to make them operate more like "routers" is large, you probably need to address this inside of XORP. 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 fxp3 -> fxp020 I realized, from a completely addressibility issue, you really want to have names like aaaXYZ: where aaa = interface driver, X = bus #, Y = slot, Z = instance Having the bus number brought out might be overkill, but it would matter on really big machines where there are multiple busses, such as many multiprocessor machines today. If you had a mapping section like that, the rest of the configuration could just use the "label" (eg fxp000) for what routing protocols need to attached to what interfaces later in the configuration. It's an idea, but I don't know if it will work in all instances. I'm not sure how you do completely virtual interfaces, such as vlans (although I guess they are tied to particular physical interfaces), or say async ppp... - -Kurt ------- End of Forwarded Message From ongbh@ispworkshop.com Sun Jan 23 04:43:21 2005 From: ongbh@ispworkshop.com (Ong Beng Hui) Date: Sun, 23 Jan 2005 12:43:21 +0800 Subject: [Xorp-hackers] Network interface naming In-Reply-To: <200501222038.j0MKcgm6000353@possum.icir.org> References: <200501222038.j0MKcgm6000353@possum.icir.org> Message-ID: <41F32B69.8050800@ispworkshop.com> Hi, Pavlin Radoslavov wrote: > All, ... > This is definitely something that has to be considered, hence I am > forwarding his email to the list to start a discussion on the > subject. Having work in Cisco for a while, I don't think there is any good way of naming interfaces. I think the best is to keep it simple, ie... interface 0, interface 1, and so on... and having a platform specific layer to handle the translation of bus, slot, port, sub-interface, etc. :) From bms@spc.org Sun Jan 23 05:08:16 2005 From: bms@spc.org (Bruce M Simpson) Date: Sun, 23 Jan 2005 05:08:16 +0000 Subject: [Xorp-hackers] Network interface naming In-Reply-To: <41F32B69.8050800@ispworkshop.com> References: <200501222038.j0MKcgm6000353@possum.icir.org> <41F32B69.8050800@ispworkshop.com> Message-ID: <20050123050816.GF37217@dhcp120.icir.org> On Sun, Jan 23, 2005 at 12:43:21PM +0800, Ong Beng Hui wrote: > Having work in Cisco for a while, I don't think there is any > good way of naming interfaces. I think the best is to keep it > simple, ie... interface 0, interface 1, and so on... and having > a platform specific layer to handle the translation of bus, slot, > port, sub-interface, etc. I've come to the conclusion that where geographic addressing of network interfaces and desktop PCs is concerned, there really isn't a reliable way of doing it unless you have design control over the platform. This would certainly be the case for a router chassis specifically designed to run XORP, probably incorporating a bus which complies with a more recent version of CompactPCI. There are hacks which can be attempted with off-the-shelf PC hardware, but they aren't reliable or guaranteed to be supported across a wide variety of such hardware. Regards, BMS From rafael.guimaraes@ac.upc.edu Wed Jan 26 12:39:41 2005 From: rafael.guimaraes@ac.upc.edu (Rafael Paoliello Guimaraes) Date: Wed, 26 Jan 2005 13:39:41 +0100 Subject: [Xorp-hackers] XORP, Click and its configuration... Message-ID: <41F78F8D.4070509@ac.upc.edu> This is a multi-part message in MIME format. --------------060504090302010507020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I was trying to use the click element KernelTun in my click configuration in order to allow packets generated by the same computer to be routed through click. In order to do this, I have changed the xorp_fea_click_config_generator script. This new script (which I am attaching to this email) works fine, it creates a new TUN interface (tun0) with 172.16.0.1 as its address. Finally, I have to create a default route to this new interface and delete every other route (so that all generated packets go through tun0) and configured linux not to do forwarding (in order to let this functionality to click). By doing this, I am able to ping to every node and almost everything goes fine. The only problem is that, whenever I create a new route (I tried through static_routes), the TUN interfaces changes from tun0 to tun1. And if I create another route (or delete an existant one), it goes from tun0 to tun1. Why is this happening? Does XORP reinitiate Click after each route change? How can I avoid this? Cheers, -- =========================================== Rafael Paoliello Guimaraes PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnic University of Catalonia (UPC) Phone: +34-934017187 Fax: +34-934017055 URL: http://people.ac.upc.es/rpaoliel =========================================== --------------060504090302010507020407 Content-Type: text/plain; name="xorp_fea_click_config_generator" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xorp_fea_click_config_generator" #!/usr/bin/awk -f # # $XORP: xorp/fea/xorp_fea_click_config_generator,v 1.9 2004/12/18 02:03:21 pavlin Exp $ # # # A sample script to generate Click configuration from XORP configuration. # The first argument is the XORP configuration file name. # # Currently, the script is called on-demand by the FEA whenever # the network interface information changes. # # Requirements: # 1. The Click lookup element name must be "_xorp_rt". # That element must support interface similar to element LinearIPLookup() # for adding and removing forwarding entries. # 2. The first network interface/vif must be connected to _xorp_rt[0], # the second network interface/vif must be connected to _xorp_rt[1], # and so-on. # # Note that if both kernel-level and user-level Click are enabled # (which is allowed), this script will print the kernel-level Click # configuration. # BEGIN { # Various constants ipv4_addr_bitlen = 32; # IPv4 address bitmask length ipv6_addr_bitlen = 128; # IPv6 address bitmask length iftree_interfaces_max = 0; iftree_vifs_max = 0; is_click_enabled = 0; is_kernel_click = 0; is_user_click = 0; is_debug = 0; xorp_ip = "_xorp_ip"; xorp_rt = "_xorp_rt"; xorp_arpt = "_xorp_arpt"; xorp_toh = "_xorp_toh"; # TODO: XXX: fix ether_encap if necessary ether_encap = "EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2)"; statement = ""; in_comment = 0; is_syntax_error = 0; is_internal_error = 0; config_level = 0; ignore_level[0] = 1; is_level0_interfaces = 0; is_level0_fea = 0; is_level0_fea_level1_click = 0; is_level0_fea_level1_click_level2_kernel_click = 0; is_level0_fea_level1_click_level2_user_click = 0; is_ipv4_address = 0; is_ipv6_address = 0; max_xorp_rt_port = 0; iftree_interfaces_targetname = "fea"; fea_targetname = "fea"; # KernelTun Initializations: rafael # kerneltun_ip_addr = "192.168.254.1" # kerneltun_ip_prefix = "24" # kerneltun_port = 0; } function calculate_state() { iftree_vifs_max = 0; xorp_rt_port = 0; # # Clear-up some temporary state # At the same time, compute the value of iftree_vifs_max # for (ii = 0; ii < iftree_interfaces_max; ii++) { ifaces_chosen[ii] = 0; for (vi = 0; vi < iftree_interfaces_vifs_max[ii]; vi++) { ifaces_vifs_chosen[ii,vi] = 0; iftree_vifs_max++; } } # # Select the interfaces and vifs by using string comparison: # the "smaller" name first. # for (ci = 0; ci < iftree_interfaces_max; ci++) { best_ii = -1; for (ii = 0; ii < iftree_interfaces_max; ii++) { if (ifaces_chosen[ii]) continue; if (best_ii == -1) { best_ii = ii; continue; } best_ifname = iftree_interfaces_ifname[best_ii]; if (iftree_interfaces_ifname[ii] < best_ifname) { best_ii = ii; } } if (best_ii < 0) { internal_error("Internal error: cannot sort the interface names\n"); } ifaces_chosen[best_ii] = 1; for (cv = 0; cv < iftree_interfaces_vifs_max[best_ii]; cv++) { best_vi = -1; for (vi = 0; vi < iftree_interfaces_vifs_max[best_ii]; vi++) { if (ifaces_vifs_chosen[best_ii,vi]) continue; if (best_vi == -1) { best_vi = vi; continue; } best_vifname = iftree_interfaces_vifs_vifname[best_ii,best_vi]; if (iftree_interfaces_vifs_vifname[best_ii,vi] < best_vifname) { best_vi = vi; } } if (best_vi < 0) { internal_error("Internal error: cannot sort the vif names\n"); } ifaces_vifs_chosen[best_ii,best_vi] = 1; iftree_interfaces_vifs_port[best_ii,best_vi] = xorp_rt_port++; } # KernelTun: rafael # kerneltun_port = xorp_rt_port++; } max_xorp_rt_port = xorp_rt_port; } function check_state() { for (ii = 0; ii < iftree_interfaces_max; ii++) { ifname = iftree_interfaces_ifname[ii]; if (iftree_interfaces_has_mac[ii] != 1) { message = "Missing MAC address configuration for interface " ifname; syntax_error(message); } if (iftree_interfaces_has_mtu[ii] != 1) { message = "Missing MTU configuration for interface " ifname; syntax_error(message); } } } function generate_click_config_header() { printf("//\n"); printf("// Generated by XORP FEA\n"); printf("//\n"); } function generate_kerneltun() { printf("\nelementclass FixChecksums {\n"); printf(" input -> SetIPChecksum\n"); printf(" -> ipc :: IPClassifier(tcp, udp, -)\n"); printf(" -> SetTCPChecksum\n"); printf(" -> output;\n"); printf(" ipc[1] -> SetUDPChecksum -> output;\n"); printf(" ipc[2] -> output\n"); printf("}\n\n"); printf("tun :: KernelTun(172.16.0.1/24) -> Paint(0) -> _xorp_rt;\n\n"); } function generate_click_shared_ip_input() { check_ip_header = "CheckIPHeader(INTERFACES"; local_ip_routes = ""; is_first_address = 1; for (ii = 0; ii < iftree_interfaces_max; ii++) { for (vi = 0; vi < iftree_interfaces_vifs_max[ii]; vi++) { for (ai4 = 0; ai4 < iftree_interfaces_vifs_addresses4_max[ii,vi]; ai4++) { addr4 = iftree_interfaces_vifs_addresses4_addr[ii,vi,ai4]; prefix4 = iftree_interfaces_vifs_addresses4_prefix[ii,vi,ai4]; check_ip_header = check_ip_header " " addr4 "/" prefix4; route = addr4 "/" ipv4_addr_bitlen " " max_xorp_rt_port; if (is_first_address) { local_ip_routes = route; is_first_address = 0; } else { local_ip_routes = local_ip_routes ", " route; } } } } check_ip_header = check_ip_header ")"; printf("\n"); printf("// Shared IP input path and routing table\n"); printf("%s :: Strip(14)\n", xorp_ip); printf(" -> %s\n", check_ip_header); printf(" -> %s :: LinearIPLookup(%s);\n", xorp_rt, local_ip_routes); } function generate_click_arp_responses() { printf("\n"); printf("// ARP responses are copied to each ARPQuerier and the host.\n"); printf("%s :: Tee(%u);\n", xorp_arpt, iftree_vifs_max + 1); } function generate_click_input_output_paths() { port = 0; for (ii = 0; ii < iftree_interfaces_max; ii++) { for (vi = 0; vi < iftree_interfaces_vifs_max[ii]; vi++) { xorp_c = "_xorp_c" port; xorp_out = "_xorp_out" port; xorp_to_device = "_xorp_to_device" port; xorp_ar = "_xorp_ar" port; xorp_arpq = "_xorp_arpq" port; if (! iftree_interfaces_vifs_enabled[ii,vi]) { from_device = "NullDevice"; } else { # # TODO: XXX: we should find a way to configure polling # devices. Such devices should use "PollDevice" instead # of "FromDevice". # from_device = "FromDevice(" iftree_interfaces_vifs_vifname[ii,vi] ")"; } if (! iftree_interfaces_vifs_enabled[ii,vi]) { to_device = "Discard"; } else { to_device = "ToDevice(" iftree_interfaces_vifs_vifname[ii,vi] ")"; } arp_responder = "ARPResponder("; mac = iftree_interfaces_mac[ii]; is_begin = 1; for (ai4 = 0; ai4 < iftree_interfaces_vifs_addresses4_max[ii,vi]; ai4++) { addr4 = iftree_interfaces_vifs_addresses4_addr[ii,vi,ai4]; if (is_begin) arp_responder = arp_responder addr4; else arp_responder = arp_responder " " addr4; is_begin = 0; } arp_responder = arp_responder " " mac ")"; first_addr4 = "0.0.0.0"; if (iftree_interfaces_vifs_addresses4_max[ii,vi] > 0) { first_addr4 = iftree_interfaces_vifs_addresses4_addr[ii,vi,0]; } arp_querier = "ARPQuerier(" first_addr4 ", " mac ")"; paint = "Paint(" port + 1 ")"; print_non_ip = "Print(\"" iftree_interfaces_vifs_vifname[ii,vi] " non-IP\")"; printf("\n"); printf("// Input and output paths for %s\n", iftree_interfaces_vifs_vifname[ii,vi]); printf("%s :: Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -);\n", xorp_c); printf("%s -> %s;\n", from_device, xorp_c); printf("%s :: Queue(200) -> %s :: %s;\n", xorp_out, xorp_to_device, to_device); printf("%s[0] -> %s :: %s -> %s;\n", xorp_c, xorp_ar, arp_responder, xorp_out); printf("%s :: %s -> %s;\n", xorp_arpq, arp_querier, xorp_out); printf("%s[1] -> %s;\n", xorp_c, xorp_arpt); printf("%s[%u] -> [1]%s;\n", xorp_arpt, port, xorp_arpq); printf("%s[2] -> %s -> %s;\n", xorp_c, paint, xorp_ip); printf("%s[3] -> %s -> Discard;\n", xorp_c, print_non_ip); port++; } } # KernelTun ARPResponder configuration: rafael } function generate_click_send_packets_to_host() { printf("\n"); printf("// Local delivery\n"); # TODO: XXX: Fix the Local delivery for *BSD and/or user-level Click if (is_kernel_click) { # # XXX: Note that if both kernel-level and user-level Click are enabled # (which is allowed), this script will print the kernel-level Click # configuration. # printf("%s[%u] -> ToHost;\n", xorp_arpt, iftree_vifs_max); # XXX: last port in xorp_rt is reserved for local delivery printf("%s[%u] -> %s -> ToHost;\n", xorp_rt, max_xorp_rt_port, ether_encap); } else { printf("%s[%u] -> Discard;\n", xorp_arpt, iftree_vifs_max); # XXX: last port in xorp_rt is reserved for local delivery printf("%s[%u] -> Discard;\n", xorp_rt, max_xorp_rt_port); } } function generate_click_forwarding_paths() { # # Forwarding paths for each interface # port = 0; for (ii = 0; ii < iftree_interfaces_max; ii++) { for (vi = 0; vi < iftree_interfaces_vifs_max[ii]; vi++) { xorp_cp = "_xorp_cp" port; paint_tee = "PaintTee(" port + 1 ")"; xorp_gio = "_xorp_gio" port; xorp_dt = "_xorp_dt" port; xorp_fr = "_xorp_fr" port; xorp_arpq = "_xorp_arpq" port; xorp_sw = "_xorp_sw" port; ipgw_options = "IPGWOptions("; is_begin = 1; for (ai4 = 0; ai4 < iftree_interfaces_vifs_addresses4_max[ii,vi]; ai4++) { addr4 = iftree_interfaces_vifs_addresses4_addr[ii,vi,ai4]; if (is_begin) ipgw_options = ipgw_options addr4; else ipgw_options = ipgw_options ", " addr4; is_begin = 0; } ipgw_options = ipgw_options ")"; first_addr4 = "0.0.0.0"; if (iftree_interfaces_vifs_addresses4_max[ii,vi] > 0) { first_addr4 = iftree_interfaces_vifs_addresses4_addr[ii,vi,0]; } fix_ip_src = "FixIPSrc(" first_addr4 ")"; mtu = iftree_interfaces_mtu[ii]; ip_fragmenter = "IPFragmenter(" mtu ")"; printf("\n"); printf("// Forwarding path for %s\n", iftree_interfaces_vifs_vifname[ii,vi]); xorp_rt_port = iftree_interfaces_vifs_port[ii,vi]; printf("%s[%u] -> DropBroadcasts -> %s :: PaintSwitch();\n", xorp_rt, xorp_rt_port, xorp_sw); printf("%s :: %s\n", xorp_gio, ipgw_options); printf(" -> %s\n", fix_ip_src); printf(" -> %s :: DecIPTTL\n", xorp_dt); printf(" -> %s :: %s\n", xorp_fr, ip_fragmenter); printf(" -> [0]%s;\n\n", xorp_arpq); printf("%s[0] -> StoreIPAddress(%s,12) -> FixChecksums -> %s;\n", xorp_sw, first_addr4, xorp_fr); for (jj = 0; jj < iftree_interfaces_max; jj++) { for (vj = 0; vj < iftree_interfaces_vifs_max[jj]; vj++) { xorp_rt_port2 = iftree_interfaces_vifs_port[jj,vj]; if (jj == ii && vj == vi) { printf("%s[%u] -> %s :: Tee(2) -> ICMPError(%s, redirect, host) -> %s;\n", xorp_sw, xorp_rt_port2+1, xorp_cp, first_addr4, xorp_rt); } else { printf("%s[%u] -> %s;\n", xorp_sw, xorp_rt_port2+1, xorp_gio); } } } printf("%s[1] -> %s\n", xorp_cp, xorp_gio); printf("%s[1] -> ICMPError(%s, timeexceeded) -> %s;\n", xorp_dt, first_addr4, xorp_rt); printf("%s[1] -> ICMPError(%s, unreachable, needfrag) -> %s;\n", xorp_fr, first_addr4, xorp_rt); printf("%s[1] -> ICMPError(%s, parameterproblem) -> %s;\n", xorp_gio, first_addr4, xorp_rt); port++; } } } function is_end_of_statement(token) { # Get the last character l = length(token); s = substr(token, l, 1); if (s == ";") return 1; else return 0; } function is_end_of_string(token) { # Get the last character l = length(token); s = substr(token, l, 1); if (s == "\"") return 1; else return 0; } function is_begin_of_comment(token) { # Get the first two characters l = length(token); if (l < 2) return 0; s = substr(token, 1, 2); if (s == "/*") return 1; else return 0; } function is_end_of_comment(token) { # Get the last two characters l = length(token); if (l < 2) return 0; s = substr(token, l-1, 2); if (s == "*/") return 1; else return 0; } function process_statement(statement) { if (is_debug) printf("Statement: %s\n", statement); tokens_n = split(statement, tokens); for (i = 1; i <= tokens_n; i++) { # printf("Token: %s\n", tokens[i]); } # TODO: need to deal with strings for (i = 1; i <= tokens_n; i++) { if (tokens[i] == "{") { config_level++; continue; } if (tokens[i] == "}") { config_level--; if (config_level < 0) syntax_error("Too many }"); continue; } if (config_level == 0) { ignore_level[0] = 1; is_level0_interfaces = 0; is_level0_fea = 0; is_level0_fea_level1_click = 0; is_level0_fea_level1_click_level2_kernel_click = 0; is_level0_fea_level1_click_level2_user_click = 0; if (tokens[i] == "interfaces") { ignore_level[0] = 0; is_level0_interfaces = 1; } if (tokens[i] == "fea") { ignore_level[0] = 0; is_level0_fea = 1; is_level0_fea_level1_click = 0; is_level0_fea_level1_click_level2_kernel_click = 0; is_level0_fea_level1_click_level2_user_click = 0; } } if (ignore_level[0]) continue; # # Configuration section: "interfaces {}" # if (is_level0_interfaces && (config_level == 1)) { if (tokens[i] == "targetname:") { if (i == tokens_n) syntax_error("Missing target name"); i++; v = tokens[i]; iftree_interfaces_targetname = v; continue; } if (tokens[i] == "interface") { if (i == tokens_n) syntax_error("Missing interface name"); i++; # TODO: check that the interface name is valid v = tokens[i]; iftree_interfaces_max++; iftree_interfaces_ifname[iftree_interfaces_max - 1] = v; # XXX: by default each interface is enabled iftree_interfaces_enabled[iftree_interfaces_max - 1] = 1; continue; } syntax_error("Invalid keyword"); } if (is_level0_interfaces && (config_level == 2)) { if (tokens[i] == "enabled:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; if (v == "true") iftree_interfaces_enabled[iftree_interfaces_max - 1] = 1; else iftree_interfaces_enabled[iftree_interfaces_max - 1] = 0; continue; } if (tokens[i] == "discard:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; iftree_interfaces_discard[iftree_interfaces_max - 1] = v; continue; } if (tokens[i] == "description:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; while (! is_end_of_string(v)) { if (i == tokens_n) syntax_error("Missing end-of-string"); i++; v = v " " tokens[i]; } iftree_interfaces_description[iftree_interfaces_max - 1] = v; continue; } if (tokens[i] == "mac:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; iftree_interfaces_mac[iftree_interfaces_max - 1] = v; iftree_interfaces_has_mac[iftree_interfaces_max - 1] = 1; continue; } if (tokens[i] == "mtu:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; iftree_interfaces_mtu[iftree_interfaces_max - 1] = v; iftree_interfaces_has_mtu[iftree_interfaces_max - 1] = 1; continue; } if (tokens[i] == "vif") { if (i == tokens_n) syntax_error("Missing vif name"); i++; # TODO: check that the vif name is valid v = tokens[i]; p = iftree_interfaces_max - 1; iftree_interfaces_vifs_max[p]++; q = iftree_interfaces_vifs_max[p] - 1; iftree_interfaces_vifs_vifname[p,q] = v; # XXX: by default each vif is enabled iftree_interfaces_vifs_enabled[p,q] = 1; continue; } syntax_error("Invalid keyword"); } if (is_level0_interfaces && (config_level == 3)) { if (tokens[i] == "enabled:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (v == "true") iftree_interfaces_vifs_enabled[p,q] = 1; else iftree_interfaces_vifs_enabled[p,q] = 0; continue; } if (tokens[i] == "address") { if (i == tokens_n) syntax_error("Missing address value"); i++; # TODO: check that the address value is valid v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; is_ipv4_address = 0; is_ipv6_address = 0; if (split(v, tmp_array, ".") == 4) is_ipv4_address = 1; if (split(v, tmp_array, ":") > 1) is_ipv6_address = 1; if (!( is_ipv4_address || is_ipv6_address)) syntax_error("Invalid address value"); if (is_ipv4_address) { iftree_interfaces_vifs_addresses4_max[p,q]++; r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; iftree_interfaces_vifs_addresses4_addr[p,q,r] = v; } if (is_ipv6_address) { iftree_interfaces_vifs_addresses6_max[p,q]++; r = iftree_interfaces_vifs_addresses6_max[p,q] - 1; iftree_interfaces_vifs_addresses6_addr[p,q,r] = v; } continue; } syntax_error("Invalid keyword"); } if (is_level0_interfaces && (config_level == 4)) { if (tokens[i] == "prefix-length:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (is_ipv4_address) { r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; iftree_interfaces_vifs_addresses4_prefix[p,q,r] = v; } if (is_ipv6_address) { r = iftree_interfaces_vifs_addresses6_max[p,q] - 1; iftree_interfaces_vifs_addresses6_prefix[p,q,r] = v; } continue; } if (tokens[i] == "broadcast:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (is_ipv4_address) { r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; iftree_interfaces_vifs_addresses4_destination[p,q,r] = v; } if (is_ipv6_address) { syntax_error("Invalid keyword"); } continue; } if (tokens[i] == "destination:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (is_ipv4_address) { r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; iftree_interfaces_vifs_addresses4_destination[p,q,r] = v; } if (is_ipv6_address) { r = iftree_interfaces_vifs_addresses6_max[p,q] - 1; iftree_interfaces_vifs_addresses6_destination[p,q,r] = v; } continue; } if (tokens[i] == "multicast-capable:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (is_ipv4_address) { r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; iftree_interfaces_vifs_addresses4_multicast[p,q,r] = v; } if (is_ipv6_address) { r = iftree_interfaces_vifs_addresses6_max[p,q] - 1; iftree_interfaces_vifs_addresses6_multicast[p,q,r] = v; } continue; } if (tokens[i] == "point-to-point:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (is_ipv4_address) { r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; iftree_interfaces_vifs_addresses4_p2p[p,q,r] = v; } if (is_ipv6_address) { r = iftree_interfaces_vifs_addresses6_max[p,q] - 1; iftree_interfaces_vifs_addresses6_p2p[p,q,r] = v; } continue; } if (tokens[i] == "loopback:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (is_ipv4_address) { r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; iftree_interfaces_vifs_addresses4_loopback[p,q,r] = v; } if (is_ipv6_address) { r = iftree_interfaces_vifs_addresses6_max[p,q] - 1; iftree_interfaces_vifs_addresses6_loopback[p,q,r] = v; } continue; } if (tokens[i] == "enabled:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; p = iftree_interfaces_max - 1; q = iftree_interfaces_vifs_max[p] - 1; if (is_ipv4_address) { r = iftree_interfaces_vifs_addresses4_max[p,q] - 1; if (v == "true") iftree_interfaces_vifs_addresses4_enabled[p,q,r] = 1; else iftree_interfaces_vifs_addresses4_enabled[p,q,r] = 0; } if (is_ipv6_address) { r = iftree_interfaces_vifs_addresses6_max[p,q] - 1; if (v == "true") iftree_interfaces_vifs_addresses6_enabled[p,q,r] = 1; else iftree_interfaces_vifs_addresses6_enabled[p,q,r] = 0; } continue; } syntax_error("Invalid keyword"); } # # Configuration section: "fea {}" # if (is_level0_fea && (config_level == 1)) { if (tokens[i] == "targetname:") { if (i == tokens_n) syntax_error("Missing target name"); i++; v = tokens[i]; fea_targetname = v; continue; } if (tokens[i] == "click") { is_level0_fea_level1_click = 1; is_level0_fea_level1_click_level2_kernel_click = 0; is_level0_fea_level1_click_level2_user_click = 0; continue; } # XXX: ignore the rest of the configuration continue; } if (is_level0_fea && is_level0_fea_level1_click && (config_level == 2)) { if (tokens[i] == "enabled:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; if (v == "true") is_click_enabled = 1; else is_click_enabled = 0; continue; } if (tokens[i] == "kernel-click") { is_level0_fea_level1_click_level2_kernel_click = 1; is_level0_fea_level1_click_level2_user_click = 0; continue; } if (tokens[i] == "user-click") { is_level0_fea_level1_click_level2_kernel_click = 0; is_level0_fea_level1_click_level2_user_click = 1; continue; } # XXX: ignore the rest of the configuration continue; } if (is_level0_fea && is_level0_fea_level1_click && is_level0_fea_level1_click_level2_kernel_click && (config_level == 3)) { if (tokens[i] == "enabled:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; if (v == "true") { is_kernel_click = 1; } else { is_kernel_click = 0; } continue; } # XXX: ignore the rest of the configuration continue; } if (is_level0_fea && is_level0_fea_level1_click && is_level0_fea_level1_click_level2_user_click && (config_level == 3)) { if (tokens[i] == "enabled:") { if (i == tokens_n) syntax_error("Missing value"); i++; v = tokens[i]; if (v == "true") { is_user_click = 1; } else { is_user_click = 0; } continue; } # XXX: ignore the rest of the configuration continue; } } } function syntax_error(message) { is_syntax_error = 1; printf("Syntax error (file %s line %d): %s\n", FILENAME, FNR, message); exit(1); } function internal_error(message) { is_internal_error = 1; printf("Internal error (file %s): %s\n", FILENAME, message); exit(1); } { for (i = 1; i <= NF; i++) { token = $i; # Filter-out the comments if (is_begin_of_comment(token)) { if (in_comment) syntax_error("Nested comments"); in_comment = 1; } if (in_comment) { if (is_end_of_comment(token)) in_comment = 0; continue; } if (is_end_of_comment(token)) syntax_error("Missing begin-of-comment"); statement = statement " " token; if (is_end_of_statement(token)) { process_statement(statement); statement = ""; } } process_statement(statement); statement = ""; } END { # # Initialize internal state # calculate_state(); check_state(); # # Check for syntax and internal errors # if (is_syntax_error || is_internal_error) exit(1); # # Check if Click is enabled and whether it is user-level or kernel Click # if (! is_click_enabled) exit(0); # XXX: don't print any Click configuration if ((! is_user_click) && (! is_kernel_click)) exit(0); # XXX: don't print any Click configuration generate_click_config_header(); generate_click_shared_ip_input(); generate_kerneltun(); generate_click_arp_responses(); generate_click_input_output_paths(); generate_click_send_packets_to_host(); generate_click_forwarding_paths(); # # Check again for syntax and internal errors # if (is_syntax_error || is_internal_error) exit(1); exit(0); } # Local Variables: # mode: AWK # sh-indentation: 4 # End: --------------060504090302010507020407-- From rafael.guimaraes@ac.upc.edu Wed Jan 26 15:50:53 2005 From: rafael.guimaraes@ac.upc.edu (Rafael Paoliello Guimaraes) Date: Wed, 26 Jan 2005 16:50:53 +0100 Subject: [Xorp-hackers] More problems with XORP+Click... Message-ID: <41F7BC5D.5040201@ac.upc.edu> Hello again, We are having some problems here with XORP using click as the forwarding engine. We are able to add new routes with our test routing protocol but, whenever it tries to delete routes although our process receives a confirmation from XORP telling that the route was deleted (through a callback), it does not delete the route (we get some error messages in the router manager telling the the operation could not be commited). We have tried the same by using static routes and we get the same problem. Below there is the transcription of the errors we have got for out test protocol, then the commands we used to test the same situation with static routes and finally the errors we have got with the static routes procedure. Thank you! TEST PROTOCOL ============= [ 2005/01/26 16:15:22 INFO xorp_rtrmgr:2220 RTRMGR +166 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, static_routes [ 2005/01/26 16:15:22 INFO xorp_rtrmgr:2220 RTRMGR +403 module_manager.cc run ] Running module: interfaces (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/26 16:15:24 INFO xorp_rtrmgr:2220 RTRMGR +403 module_manager.cc run ] Running module: fea (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/26 16:15:30 INFO xorp_rtrmgr:2220 RTRMGR +403 module_manager.cc run ] Running module: rib (/root/XORP/xorp/rib/xorp_rib) [ 2005/01/26 16:15:32 INFO xorp_rtrmgr:2220 RTRMGR +403 module_manager.cc run ] Running module: static_routes (/root/XORP/xorp/static_routes/xorp_static_routes) [ 2005/01/26 16:15:34 INFO xorp_rtrmgr:2220 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/26 16:15:41 ERROR xorp_rib:2247 RIB +133 rib.cc admin_distance ] Administrative distance of "test" unknown. [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +346 fticonfig_entry_set_click.cc delete_entry ] Cannot find outgoing port number for the Click forwarding table element to delete entry net = 147.83.34.82/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +70 fti_transaction.cc operation_result ] FTI transaction commit failed on DeleteEntry4: net = 147.83.34.82/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +346 fticonfig_entry_set_click.cc delete_entry ] Cannot find outgoing port number for the Click forwarding table element to delete entry net = 192.168.242.2/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +346 fticonfig_entry_set_click.cc delete_entry ] Cannot find outgoing port number for the Click forwarding table element to delete entry net = 10.0.0.1/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:16:13 WARNING xorp_fea XrlFeaTarget ] Handling method for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 Command failed DeleteEntry4: net = 147.83.34.82/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:16:13 ERROR xorp_rib:2247 XifRedistTransaction6 +896 redist_xrl.cc dispatch_complete ] Failed to commit transaction SEQUENCE OF COMMANDS FOR STATIC ROUTES ====================================== XORP> create protocols static route4 10.0.0.1/32 nexthop 10.0.0.4 [edit] XORP> commit OK [edit] XORP> delete protocols static route4 10.0.0.1/32 Deleting: nexthop: 10.0.0.4 metric: 1 OK [edit] XORP> commit OK [edit] XORP> STATIC ROUTES ============= [ 2005/01/26 16:39:57 INFO xorp_rtrmgr:2471 RTRMGR +166 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, static_routes [ 2005/01/26 16:39:57 INFO xorp_rtrmgr:2471 RTRMGR +403 module_manager.cc run ] Running module: interfaces (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/26 16:39:59 INFO xorp_rtrmgr:2471 RTRMGR +403 module_manager.cc run ] Running module: fea (/root/XORP/xorp/fea/xorp_fea) [ 2005/01/26 16:40:05 INFO xorp_rtrmgr:2471 RTRMGR +403 module_manager.cc run ] Running module: rib (/root/XORP/xorp/rib/xorp_rib) [ 2005/01/26 16:40:07 INFO xorp_rtrmgr:2471 RTRMGR +403 module_manager.cc run ] Running module: static_routes (/root/XORP/xorp/static_routes/xorp_static_routes) [ 2005/01/26 16:40:09 INFO xorp_rtrmgr:2471 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/26 16:42:06 INFO xorp_rtrmgr:2471 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/26 16:42:06 INFO xorp_rtrmgr:2471 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/26 16:42:26 INFO xorp_rtrmgr:2471 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/26 16:42:26 INFO xorp_rtrmgr:2471 RTRMGR +1372 task.cc run_task ] No more tasks to run [ 2005/01/26 16:42:26 ERROR xorp_fea:2473 FEA +346 fticonfig_entry_set_click.cc delete_entry ] Cannot find outgoing port number for the Click forwarding table element to delete entry net = 10.0.0.1/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:42:26 ERROR xorp_fea:2473 FEA +70 fti_transaction.cc operation_result ] FTI transaction commit failed on DeleteEntry4: net = 10.0.0.1/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:42:26 WARNING xorp_fea XrlFeaTarget ] Handling method for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 Command failed DeleteEntry4: net = 10.0.0.1/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2005/01/26 16:42:26 ERROR xorp_rib:2498 XifRedistTransaction6 +896 redist_xrl.cc dispatch_complete ] Failed to commit transaction Cheers, -- =========================================== Rafael Paoliello Guimaraes PhD Student - Computer Networking Group Department of Computer Architecture (DAC) Polytechnic University of Catalonia (UPC) Phone: +34-934017187 Fax: +34-934017055 URL: http://people.ac.upc.es/rpaoliel =========================================== From pavlin@icir.org Wed Jan 26 23:14:31 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 26 Jan 2005 15:14:31 -0800 Subject: [Xorp-hackers] XORP, Click and its configuration... In-Reply-To: Message from Rafael Paoliello Guimaraes of "Wed, 26 Jan 2005 13:39:41 +0100." <41F78F8D.4070509@ac.upc.edu> Message-ID: <200501262314.j0QNEVKd058156@possum.icir.org> > This is a multi-part message in MIME format. > --------------060504090302010507020407 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Hello, > > I was trying to use the click element KernelTun in my click > configuration in order to allow packets generated by the same computer > to be routed through click. In order to do this, I have changed the > xorp_fea_click_config_generator script. This new script (which I am > attaching to this email) works fine, it creates a new TUN interface > (tun0) with 172.16.0.1 as its address. Finally, I have to create a > default route to this new interface and delete every other route (so > that all generated packets go through tun0) and configured linux not to > do forwarding (in order to let this functionality to click). > > By doing this, I am able to ping to every node and almost everything > goes fine. The only problem is that, whenever I create a new route (I > tried through static_routes), the TUN interfaces changes from tun0 to > tun1. And if I create another route (or delete an existant one), it goes > from tun0 to tun1. Why is this happening? Does XORP reinitiate Click > after each route change? How can I avoid this? Rafael, The only time the script should be invoked is when something about the network interfaces has changed. Creating a new route (I guess you used xorpsh in your test, correct?) should not trigger an execution of the generator script. Could you confirm that you are running a very recent code from the CVS repository. The reason I ask is because approximately a month ago the following bug was fixed in the rtrmgr: http://www.xorp.org/bugzilla/show_bug.cgi?id=72 Prior to that fix, the Click generator script may have been executed (as a side effect of the bug) whenever you change the config via xorpsh. Regards, Pavlin From pavlin@icir.org Thu Jan 27 00:33:57 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 26 Jan 2005 16:33:57 -0800 Subject: [Xorp-hackers] More problems with XORP+Click... In-Reply-To: Message from Rafael Paoliello Guimaraes of "Wed, 26 Jan 2005 16:50:53 +0100." <41F7BC5D.5040201@ac.upc.edu> Message-ID: <200501270033.j0R0Xv1f061160@possum.icir.org> Rafael, See my comments inline. > We are having some problems here with XORP using click as the forwarding > engine. We are able to add new routes with our test routing protocol > but, whenever it tries to delete routes although our process receives a > confirmation from XORP telling that the route was deleted (through a > callback), it does not delete the route (we get some error messages in > the router manager telling the the operation could not be commited). We > have tried the same by using static routes and we get the same problem. > Below there is the transcription of the errors we have got for out test > protocol, then the commands we used to test the same situation with > static routes and finally the errors we have got with the static routes > procedure. Thank you! > > > TEST PROTOCOL > ============= > [ 2005/01/26 16:15:22 INFO xorp_rtrmgr:2220 RTRMGR +166 > master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, > static_routes > [ 2005/01/26 16:15:22 INFO xorp_rtrmgr:2220 RTRMGR +403 > module_manager.cc run ] Running module: interfaces > (/root/XORP/xorp/fea/xorp_fea) > [ 2005/01/26 16:15:24 INFO xorp_rtrmgr:2220 RTRMGR +403 > module_manager.cc run ] Running module: fea (/root/XORP/xorp/fea/xorp_fea) > [ 2005/01/26 16:15:30 INFO xorp_rtrmgr:2220 RTRMGR +403 > module_manager.cc run ] Running module: rib (/root/XORP/xorp/rib/xorp_rib) > [ 2005/01/26 16:15:32 INFO xorp_rtrmgr:2220 RTRMGR +403 > module_manager.cc run ] Running module: static_routes > (/root/XORP/xorp/static_routes/xorp_static_routes) > [ 2005/01/26 16:15:34 INFO xorp_rtrmgr:2220 RTRMGR +1372 task.cc > run_task ] No more tasks to run > [ 2005/01/26 16:15:41 ERROR xorp_rib:2247 RIB +133 rib.cc > admin_distance ] Administrative distance of "test" unknown. To get rid of this error message, you would have to add a line like: _admin_distance["test"] = ; to rib/rib.cc (inside the RIB::RIB() constructor). Though, if you don't do apply this change then things should still work. Sigh, making the RIB admin distances configurable is one very old TODO item... > [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +346 > fticonfig_entry_set_click.cc delete_entry ] Cannot find outgoing port > number for the Click forwarding table element to delete entry net = > 147.83.34.82/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 > admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = > false is_connected_route = false > [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +70 fti_transaction.cc > operation_result ] FTI transaction commit failed on DeleteEntry4: net = > 147.83.34.82/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 > admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = > false is_connected_route = false > [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +346 > fticonfig_entry_set_click.cc delete_entry ] Cannot find outgoing port > number for the Click forwarding table element to delete entry net = > 192.168.242.2/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 > admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = > false is_connected_route = false > [ 2005/01/26 16:16:13 ERROR xorp_fea:2221 FEA +346 > fticonfig_entry_set_click.cc delete_entry ] Cannot find outgoing port > number for the Click forwarding table element to delete entry net = > 10.0.0.1/32 nexthop = 0.0.0.0 ifname = vifname = metric = 0 > admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = > false is_connected_route = false > [ 2005/01/26 16:16:13 WARNING xorp_fea XrlFeaTarget ] Handling method > for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 > Command failed DeleteEntry4: net = 147.83.34.82/32 nexthop = 0.0.0.0 > ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false > is_deleted = false is_unresolved = false is_connected_route = false > [ 2005/01/26 16:16:13 ERROR xorp_rib:2247 XifRedistTransaction6 +896 > redist_xrl.cc dispatch_complete ] Failed to commit transaction All errors and warnings above are triggered by the same bug inside the FEA. This bug should be fixed now in the CVS repository. Make sure that your fea/fticonfig_entry_set_click.cc file has revision 1.19 (or newer). Thanks, Pavlin From paul+usenet@w6yx.stanford.edu Sun Jan 30 13:11:43 2005 From: paul+usenet@w6yx.stanford.edu (G. Paul Ziemba) Date: Sun, 30 Jan 2005 13:11:43 +0000 (UTC) Subject: [Xorp-hackers] Re: Network interface naming Message-ID: 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). -- G. Paul Ziemba FreeBSD unix: 4:56AM up 23 days, 5:43, 8 users, load averages: 0.16, 0.11, 0.09