From greearb at candelatech.com Fri May 2 10:28:31 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 02 May 2008 10:28:31 -0700 Subject: [Xorp-hackers] Patch to support creating .deb packages for xorp Message-ID: <481B4F3F.9030100@candelatech.com> These two files, when place in the xorp directory (ie, where you type 'make'), will allow you to build debian packages on Fedora Core machines, and probably others as well. The install scripts do some soft-links that are probably specific to compiling xorp on FC5 and installing it on Ubuntu 8.0.4. I'm not sure if this will work on others, though obviously the script that creates the links could be made smarter... Please add this to xorp CVS if you like it. Once they are added, build xorp normally, then run: sudo make -f Makefile.deb create_deb Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: deb_hand.mak Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080502/3a6ff208/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.deb Type: application/x-deb Size: 2330 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080502/3a6ff208/attachment.bin From greearb at candelatech.com Fri May 2 11:48:33 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 02 May 2008 11:48:33 -0700 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. Message-ID: <481B6201.8080309@candelatech.com> For anyone interested in my patch to improve performance of xorp when used with lots of xorp instances on a single machine, I have just merged with the latest cvs and uploaded it here: http://www.candelatech.com/oss/ben_xorp.patch This patch contains other changes as well..they work well for me, but it's possible they would be detrimental to other uses. Please let me know how it works for you if any of you try it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From psandhya81 at yahoo.com Tue May 6 00:29:10 2008 From: psandhya81 at yahoo.com (Sandhya Puppala) Date: Tue, 6 May 2008 00:29:10 -0700 (PDT) Subject: [Xorp-hackers] multicast routing entry Message-ID: <776353.27144.qm@web52908.mail.re2.yahoo.com> Hai Pavlin, All routing entries are stored in RIB ,which are given by RIP,OSPF, and BGP. I want to know which protocol is giving multicast routing entries to RIB .Is it BGP ?.And , how it is forming MRIB? Thanking you, waiting for ur reply. regards -Sandhya --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080506/db2054a5/attachment.html From pavlin at ICSI.Berkeley.EDU Tue May 6 09:23:16 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 06 May 2008 09:23:16 -0700 Subject: [Xorp-hackers] multicast routing entry In-Reply-To: <776353.27144.qm@web52908.mail.re2.yahoo.com> References: <776353.27144.qm@web52908.mail.re2.yahoo.com> Message-ID: <200805061623.m46GNG91027373@fruitcake.ICSI.Berkeley.EDU> > All routing entries are stored in RIB ,which are given by > RIP,OSPF, and BGP. > I want to know which protocol is giving multicast routing entries > to RIB .Is it BGP ?.And , how it is forming MRIB? In principle, the unicast routing protocols should populate directly the MRIB (e.g., by using configuration statements when needed so). In fact, all "add_route" XRLs from those protocols have two flags: unicast and multicast; if the multicast flag is set then the route will be added to the MRIB. Currently we don't have the configuration statement support to set the multicast flag and populate directly the MRIB (we intend to add that in the future). For now we use the help of the fib2mrib module which gets the unicast routes from the kernel (via the FEA) and injects them into the MRIB. This is why if you need multicast routing in XORP you must enable fib2mrib. Hope that helps, Pavlin From psandhya81 at yahoo.com Wed May 7 00:42:33 2008 From: psandhya81 at yahoo.com (Sandhya Puppala) Date: Wed, 7 May 2008 00:42:33 -0700 (PDT) Subject: [Xorp-hackers] Fib2Mrib requests Message-ID: <3470.52441.qm@web52909.mail.re2.yahoo.com> Hi Pavlin, Fib2Mrib process register with both RIB and FEA,and it(fib2mrib) sent some register interest requests to those processes(RIB and FEA).I want to know , how these processes(FEA and RIB) receive these requests?. Regards -Sandhya --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080507/99056931/attachment.html From bms at incunabulum.net Wed May 7 02:55:08 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Wed, 07 May 2008 10:55:08 +0100 Subject: [Xorp-hackers] Fib2Mrib requests In-Reply-To: <3470.52441.qm@web52909.mail.re2.yahoo.com> References: <3470.52441.qm@web52909.mail.re2.yahoo.com> Message-ID: <48217C7C.2000203@incunabulum.net> Sandhya Puppala wrote: > Hi Pavlin, > > Fib2Mrib process register with both RIB and FEA,and it(fib2mrib) > sent some register interest requests to those processes(RIB and FEA).I > want to know , how these processes(FEA and RIB) receive these requests?. Look at the XRL target classes for both the RIB and the FEA. These are generally named xrl_*_target.cc/.hh and derive from the XRL target base class wrappers found in the xrl/targets directory. From bms at incunabulum.net Fri May 9 02:17:51 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 09 May 2008 10:17:51 +0100 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. In-Reply-To: <481B6201.8080309@candelatech.com> References: <481B6201.8080309@candelatech.com> Message-ID: <482416BF.3020903@incunabulum.net> Ben, Thanks for this. I'm afraid we can't take it as is, but, Pavlin has made some changes to the FEA which fix a number of bugs, and which may address some of the issues you were seeing. The RTA_TABLE stuff looks interesting and useful, do you plan to forward port this to the HEAD revision? Ben Greear wrote: > For anyone interested in my patch to improve performance of xorp > when used with lots of xorp instances on a single machine, I have > just merged with the latest cvs and uploaded it here: > > http://www.candelatech.com/oss/ben_xorp.patch > > This patch contains other changes as well..they work well for me, > but it's possible they would be detrimental to other uses. Please > let me know how it works for you if any of you try it. > The RIB shouldn't really be setting the admin distance for static_routes at all. Please see OLSR for an example of a protocol which registers its admin distance with the RIB using an XRL during startup. cheers BMS P.S. __PRETTY_FUNCTION__ is gcc specific. I've been looking at it for some debugging stuff, but we would discourage its use in the main code base -- it really needs to be guarded with a macro. From bms at incunabulum.net Fri May 9 02:36:37 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 09 May 2008 10:36:37 +0100 Subject: [Xorp-hackers] Patch to support creating .deb packages for xorp In-Reply-To: <481B4F3F.9030100@candelatech.com> References: <481B4F3F.9030100@candelatech.com> Message-ID: <48241B25.2080805@incunabulum.net> Ben, Thanks for the Debian patches. We already appear to have some Debian packaging support in xorp/contrib/packages/debian. I don't normally use any of the operating systems you mention. It is entirely possible the existing support has bit-rotted, or doesn't work on newer distros using ipkg -- I'd like to check your stuff in if it's needed, however, we'd also like to avoid repo churn. Could you possibly give the existing stuff a try and let us know if it isn't working for you? cheers BMS From greearb at candelatech.com Fri May 9 05:47:50 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 09 May 2008 05:47:50 -0700 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. In-Reply-To: <482416BF.3020903@incunabulum.net> References: <481B6201.8080309@candelatech.com> <482416BF.3020903@incunabulum.net> Message-ID: <482447F6.60102@candelatech.com> Bruce M Simpson wrote: > Ben, > > Thanks for this. > > I'm afraid we can't take it as is, but, Pavlin has made some changes > to the FEA which fix a number of bugs, and which may address some of > the issues you were seeing. > > The RTA_TABLE stuff looks interesting and useful, do you plan to > forward port this to the HEAD revision? Yes, I plan to port everything to HEAD, and drop whatever is fixed by Pavlin's fixes. When I get something working again, I'll post it. > Ben Greear wrote: >> For anyone interested in my patch to improve performance of xorp >> when used with lots of xorp instances on a single machine, I have >> just merged with the latest cvs and uploaded it here: >> >> http://www.candelatech.com/oss/ben_xorp.patch >> >> This patch contains other changes as well..they work well for me, >> but it's possible they would be detrimental to other uses. Please >> let me know how it works for you if any of you try it. >> > > The RIB shouldn't really be setting the admin distance for > static_routes at all. > > Please see OLSR for an example of a protocol which registers its admin > distance with the RIB using an XRL during startup. My hack works for me (and is small and easy to keep merged)..but I'll gladly drop it if someone adds the ability to do it right. > > P.S. __PRETTY_FUNCTION__ is gcc specific. I've been looking at it for > some debugging stuff, but we would discourage its use in the main code > base -- it really needs to be guarded with a macro. It would be easy enough to #define it to something similar for non-gcc compilers...no need to remove useful functionality for the majority of the target platforms just because some don't support a feature... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Fri May 9 08:50:42 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 09 May 2008 16:50:42 +0100 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. In-Reply-To: <482447F6.60102@candelatech.com> References: <481B6201.8080309@candelatech.com> <482416BF.3020903@incunabulum.net> <482447F6.60102@candelatech.com> Message-ID: <482472D2.3080306@incunabulum.net> Ben Greear wrote: >> >> The RTA_TABLE stuff looks interesting and useful, do you plan to >> forward port this to the HEAD revision? > Yes, I plan to port everything to HEAD, and drop whatever is fixed by > Pavlin's fixes. When I get something > working again, I'll post it. Excellent, look forward to it. >> The RIB shouldn't really be setting the admin distance for >> static_routes at all. > My hack works for me (and is small and easy to keep merged)..but I'll > gladly drop it if someone adds the ability to do it right. The infrastructure's all already there; the protocol(s) just need to be taught to send a "set_protocol_admin_distance" XRL to the RIB before they try to register their OriginTable(s). It should only be done once and specify the RIBs which the process plans to add routes to. OLSR only ever originates unicast IPv4 routes at the moment; see XrlIO::register_rib(). I had some snafus during development because I'd left in a call to register a multicast table, but didn't include it in set_protocol_admin_distance, which used to cause an error in the RIB; this has since been demoted to a warning. It isn't possible to do this for *all* of the protocols, particularly the "connected" table which has special meaning to the RIB. Also, the RIB does not yet handle changing admin distance for a running process, because this involves blowing away of a lot of RIB and FEA state; the code path to do it hasn't been written yet. It has to be done though as the admin distance gets embedded in every OriginTable which a routing protocol instantiates. >> >> P.S. __PRETTY_FUNCTION__ is gcc specific. > > It would be easy enough to #define it to something similar for non-gcc > compilers...no need to remove useful functionality > for the majority of the target platforms just because some don't > support a feature... No need to cause breakage when gcc is not being used for an equally good but unspecified reason :-) I've been looking at doing some logging code related to the very specific needs of routing processes -- __PRETTY_FUNCTION__ is useful, as it produces a fully qualified, undecorated name, including the class name, which you can then strsep() on "::" as a delimiter; but because it's non-standard, it breaks with anything which isn't gcc. If you look around there's a proposal from an ex-Apple guy to add __class__ to the C99 and C++0x specs, it might be good to give him some political support somehow. cheers BMS From greearb at candelatech.com Fri May 9 11:36:28 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 09 May 2008 11:36:28 -0700 Subject: [Xorp-hackers] CVS diff in the automated email? Message-ID: <482499AC.7070807@candelatech.com> Any chance you'd like to add a cvs diff to each of the auto-generated CVS checkin emails? That would help keep track of what patches are going into the kernel... I can dig out my scripts to do this if you want some. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri May 9 12:53:48 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 09 May 2008 12:53:48 -0700 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. In-Reply-To: <482472D2.3080306@incunabulum.net> References: <481B6201.8080309@candelatech.com> <482416BF.3020903@incunabulum.net> <482447F6.60102@candelatech.com> <482472D2.3080306@incunabulum.net> Message-ID: <4824ABCC.8030906@candelatech.com> Bruce M Simpson wrote: > Ben Greear wrote: >>> >>> The RTA_TABLE stuff looks interesting and useful, do you plan to >>> forward port this to the HEAD revision? >> Yes, I plan to port everything to HEAD, and drop whatever is fixed by >> Pavlin's fixes. When I get something >> working again, I'll post it. > > Excellent, look forward to it. The new patch is at: http://www.candelatech.com/oss/xorp_080509.patch It is compile tested only at this point, but I should get some testing done on it early next week. I'm happy to notice that it's some 30k smaller, mainly because Pavlin's changes to fea interface and xrl handling were very close to mine. My patch still contains at least these features: * ifconfig::system_config() is created lazily, and only things in user_config are pulled from the system in normal use. * Pull config is optimized to pull single interfaces when possible. Should be backwards compat with any APIs that do not allow pulling single interface information. * The RTA_TABLE logic is identical to the previous patch: We only care about our configured routing table. * FEA can bind to only it's configured devices instead of ALL... * Some misc core changes to the main event loop to decrease calls to gettimeofday (or equiv), and some work to make the event loop more fair (in my opinion and/or work-load). * Lots of debugging code in OSPF..don't think there is anything important in there. I'd be happy to see any/all of this in Xorp CVS under whatever license you deem fit. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kristian at spritelink.net Sat May 10 03:53:00 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Sat, 10 May 2008 12:53:00 +0200 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. In-Reply-To: <482472D2.3080306@incunabulum.net> References: <481B6201.8080309@candelatech.com> <482416BF.3020903@incunabulum.net> <482447F6.60102@candelatech.com> <482472D2.3080306@incunabulum.net> Message-ID: <20080510105300.GE60664@spritelink.se> On Fri, May 09, 2008 at 04:50:42PM +0100, Bruce M Simpson wrote: > Ben Greear wrote: > >> > >> The RTA_TABLE stuff looks interesting and useful, do you plan to > >> forward port this to the HEAD revision? > > Yes, I plan to port everything to HEAD, and drop whatever is fixed by > > Pavlin's fixes. When I get something > > working again, I'll post it. > > Excellent, look forward to it. > > >> The RIB shouldn't really be setting the admin distance for > >> static_routes at all. > > My hack works for me (and is small and easy to keep merged)..but I'll > > gladly drop it if someone adds the ability to do it right. > > The infrastructure's all already there; the protocol(s) just need to be > taught to send a "set_protocol_admin_distance" XRL to the RIB before > they try to register their OriginTable(s). It should only be done once > and specify the RIBs which the process plans to add routes to. > > OLSR only ever originates unicast IPv4 routes at the moment; see > XrlIO::register_rib(). I had some snafus during development because I'd > left in a call to register a multicast table, but didn't include it in > set_protocol_admin_distance, which used to cause an error in the RIB; > this has since been demoted to a warning. > > It isn't possible to do this for *all* of the protocols, particularly > the "connected" table which has special meaning to the RIB. > > Also, the RIB does not yet handle changing admin distance for a running > process, because this involves blowing away of a lot of RIB and FEA > state; the code path to do it hasn't been written yet. It has to be done > though as the admin distance gets embedded in every OriginTable which a > routing protocol instantiates. Will it be possible to set administrative distance per route? This is _very_ useful for having floating static routes. -K -- Kristian Larsson KLL-RIPE Network Engineer & Peering Coordinator SpriteLink [AS39525] +46 704 910401 kll at spritelink.net From bms at incunabulum.net Sat May 10 12:10:53 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat, 10 May 2008 20:10:53 +0100 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. In-Reply-To: <20080510105300.GE60664@spritelink.se> References: <481B6201.8080309@candelatech.com> <482416BF.3020903@incunabulum.net> <482447F6.60102@candelatech.com> <482472D2.3080306@incunabulum.net> <20080510105300.GE60664@spritelink.se> Message-ID: <4825F33D.2070107@incunabulum.net> Kristian Larsson wrote: > Will it be possible to set administrative distance > per route? This is _very_ useful for having > floating static routes. > OK, I just spent some moments reading code. If someone writes a patch to implement floating statics, I'm happy to review it, it's not on my plate at the moment. It's certainly possible, as the admin distance is part of each route entry in the RIB; the per-route admin distance is used in comparisons whenever a route table change happens, when the RIB is deciding which route to replace. It is gnarly in that it means manipulating the admin distance on a per-route basis, which is a use case which neither the XRLs nor the static_routes syntax are set up to deal with. The code to do this would need to be added. The XRLs to add/replace routes are specialized for interface routes, I see no reason why they couldn't be specialized for adding/changing a route with admin distance. cheers BMS [P.S. The thing with floating statics is: there's something of a case for implementing them in the host's forwarding plane too, as they are very useful for folk who are hot swapping network interfaces and don't have a need to run a full routing daemon. I've been thinking about doing same for FreeBSD. The disadvantage for XORP in doing it that way, however, is that the FEA would need to be taught to look for host based floating statics and update its state appropriately.] From pavlin at ICSI.Berkeley.EDU Sun May 11 15:16:45 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Sun, 11 May 2008 15:16:45 -0700 Subject: [Xorp-hackers] CVS diff in the automated email? In-Reply-To: <482499AC.7070807@candelatech.com> References: <482499AC.7070807@candelatech.com> Message-ID: <200805112216.m4BMGjO9012415@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > Any chance you'd like to add a cvs diff to each of the > auto-generated CVS checkin emails? That would help > keep track of what patches are going into the kernel... The model for our CVS log messages is based on the FreeBSD/NetBSD/OpenBSD model. Including all the diffs is going to add too much overhead to the mailing list. Typically people want to follow what kind of changes are happening (based on the commit messages), and only if they care about the implemenation details they run "cvs diff". Personally I do "cvs diff" for every changed file and I still rather do it by hand instead of reading a potentially very long email. If you'd like I can send you the simple but unpolished shell script that prints the last cvs diff for a file. Nothing fancy but it does the job. Pavlin > I can dig out my scripts to do this if you want some. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Sun May 11 20:36:29 2008 From: greearb at candelatech.com (Ben Greear) Date: Sun, 11 May 2008 20:36:29 -0700 Subject: [Xorp-hackers] CVS diff in the automated email? In-Reply-To: <200805112216.m4BMGjO9012415@fruitcake.ICSI.Berkeley.EDU> References: <482499AC.7070807@candelatech.com> <200805112216.m4BMGjO9012415@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4827BB3D.2020509@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Any chance you'd like to add a cvs diff to each of the >> auto-generated CVS checkin emails? That would help >> keep track of what patches are going into the kernel... >> > > The model for our CVS log messages is based on the > FreeBSD/NetBSD/OpenBSD model. > > Including all the diffs is going to add too much overhead to the > mailing list. > Typically people want to follow what kind of changes are happening > (based on the commit messages), and only if they care about the > implemenation details they run "cvs diff". > > Personally I do "cvs diff" for every changed file and I still rather > do it by hand instead of reading a potentially very long email. > If you'd like I can send you the simple but unpolished shell script > that prints the last cvs diff for a file. Nothing fancy but it does > the job. > It's nice to see a complete changeset at once... Maybe something automated in the email to give the cvs command to see the entire changeset? Might could base it off of date since cvs doesn't handle changesets over multiple files so well? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at ICSI.Berkeley.EDU Mon May 12 00:20:32 2008 From: bms at ICSI.Berkeley.EDU (Bruce M. Simpson) Date: Mon, 12 May 2008 08:20:32 +0100 Subject: [Xorp-hackers] CVS diff in the automated email? In-Reply-To: <4827BB3D.2020509@candelatech.com> References: <482499AC.7070807@candelatech.com> <200805112216.m4BMGjO9012415@fruitcake.ICSI.Berkeley.EDU> <4827BB3D.2020509@candelatech.com> Message-ID: <4827EFC0.3010502@icsi.berkeley.edu> Ben Greear wrote: > It's nice to see a complete changeset at once... Maybe something > automated in > the email to give the cvs command to see the entire changeset? Might could > base it off of date since cvs doesn't handle changesets over multiple > files so well? > The way I handle this is to deploy Mercurial with Tailor. Tailor imports CVS into Mercurial on a regular cron job. In turn, Mercurial's web interface provides an RSS feed. That feed contains links which let you view changesets as unified diffs. I continue to use Mercurial a lot for temporary branches. The XORP development model is still such that we use CVS as "the authoritative repository" and there are still compelling reasons for this, a switch to Mercurial is very much dependent on required features e.g. obliterate being there. Having said that, I strongly feel we should be moving with the times and I'd like to see the deployment of a public Mercurial repository for helping people outside the project to make and contribute changes. cheers BMS From bms at ICSI.Berkeley.EDU Mon May 12 00:41:05 2008 From: bms at ICSI.Berkeley.EDU (Bruce M. Simpson) Date: Mon, 12 May 2008 08:41:05 +0100 Subject: [Xorp-hackers] CVS diff in the automated email? In-Reply-To: <4827BB3D.2020509@candelatech.com> References: <482499AC.7070807@candelatech.com> <200805112216.m4BMGjO9012415@fruitcake.ICSI.Berkeley.EDU> <4827BB3D.2020509@candelatech.com> Message-ID: <4827F491.8020807@icsi.berkeley.edu> Ben, If doing something like tailor+hg is too much for you: http://www.freshports.org/mail/cvsmail/ ...is a FreeBSD port which acts as a mail filter and adds web links to FreeBSD commit mail. cheers BMS From greearb at candelatech.com Mon May 12 16:44:31 2008 From: greearb at candelatech.com (Ben Greear) Date: Mon, 12 May 2008 16:44:31 -0700 Subject: [Xorp-hackers] OSPF stuck in Loading state Message-ID: <4828D65F.3040302@candelatech.com> I seem to have a repeatable OSPF problem where it gets stuck in loading state. The general scenario is that there is a dense mesh of 10 nodes that slowly pull apart and drop connections. Near the end, node 4 is connected to node 9 and node-9 connects to most of the rest of the network. Two nodes (2 and 7) are in their own group and not reachable from the main group. Both router 4 and router 9 show each other as peers and in the Loading state. Nothing obviously wrong in the log files, but the OSPF traffic between them seems to be stuck in some sort of loop. A pcap capture is here: http://www.candelatech.com/oss/ospf_loading.pcap I'm going to try this all again with the latest CVS (this build is a few weeks old) and will enable debugging in OSPF if still no luck. Please let me know if you have any suggestions or need more debugging info. # Router 9: lanforge at a440-qc> show ospf4 neighbor created new heap in find_heap, ptr: 0x811ec30 created new heap in find_heap, ptr: 0x8120580 Address Interface State ID Pri Dead 10.3.9.3 3.9.9/3.9.9 Full 127.1.0.3 128 39 10.4.9.4 4.9.9/4.9.9 Loading 127.1.0.4 128 35 lanforge at a440-qc> show interfaces created new heap in find_heap, ptr: 0x814bd10 created new heap in find_heap, ptr: 0x8150698 3.9.9/3.9.9: Flags: mtu 1500 inet 10.3.9.9 subnet 10.3.9.0/24 broadcast 10.3.9.255 physical index 95 ether 0:26:50:3e:60:49 4.9.9/4.9.9: Flags: mtu 1500 inet 10.4.9.9 subnet 10.4.9.0/24 broadcast 10.4.9.255 physical index 187 ether 0:4:13:84:8d:2e br9/br9: Flags: mtu 1500 inet 10.9.9.9 subnet 10.9.9.0/24 broadcast 10.9.9.255 physical index 44 ether 0:44:c3:f0:2f:46 my_discard/my_discard: Flags: mtu 0 physical index 0 lanforge at a440-qc> [lanforge at a440-qc ~]$ tail -40 xorp-log-vr10009.txt [ 2008/05/12 16:31:28 WARNING xorp_ospfv2:13291 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:31:49 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed Error while sending to vif: 3.9.9:3.9.9 src: 10.3.9.9 dest: 224.0.0.5: sendmsg failed, error: Network is down socket: 57 [ 2008/05/12 16:31:49 ERROR xorp_ospfv2:13291 OSPF xrl_io.cc:188 send_cb ] Cannot send a packet on interface 3.9.9 vif 3.9.9: 102 Command failed Error while sending to vif: 3.9.9:3.9.9 src: 10.3.9.9 dest: 224.0.0.5: sendmsg failed, error: Network is down socket: 57 [ 2008/05/12 16:31:49 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed Error while sending to vif: 3.9.9:3.9.9 src: 10.3.9.9 dest: 224.0.0.5: sendmsg failed, error: Network is down socket: 57 [ 2008/05/12 16:31:49 ERROR xorp_ospfv2:13291 OSPF xrl_io.cc:188 send_cb ] Cannot send a packet on interface 3.9.9 vif 3.9.9: 102 Command failed Error while sending to vif: 3.9.9:3.9.9 src: 10.3.9.9 dest: 224.0.0.5: sendmsg failed, error: Network is down socket: 57 [ 2008/05/12 16:31:56 WARNING xorp_ospfv2:13291 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:32:35 WARNING xorp_ospfv2:13291 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:33:09 WARNING xorp_ospfv2:13291 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:33:17 WARNING xorp_ospfv2:13291 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:33:45 WARNING xorp_ospfv2:13291 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 # Router 4 root at a440-qc> show interfaces created new heap in find_heap, ptr: 0x814bd10 created new heap in find_heap, ptr: 0x8150698 4.9.4/4.9.4: Flags: mtu 1500 inet 10.4.9.4 subnet 10.4.9.0/24 broadcast 10.4.9.255 physical index 185 ether 0:93:b5:69:ca:c4 br4/br4: Flags: mtu 1500 inet 10.4.4.4 subnet 10.4.4.0/24 broadcast 10.4.4.255 physical index 24 ether 0:cc:d8:98:fa:2b my_discard/my_discard: Flags: mtu 0 physical index 0 root at a440-qc> show ospf4 neighbor created new heap in find_heap, ptr: 0x811ec30 created new heap in find_heap, ptr: 0x8120580 Address Interface State ID Pri Dead 10.4.9.9 4.9.4/4.9.4 Loading 127.1.0.9 128 36 root at a440-qc> [root at a440-qc lanforge]# tail -40 xorp-log-vr10004.txt LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:29:10 WARNING xorp_ospfv2:13215 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:31:27 WARNING xorp_ospfv2:13215 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:31:30 WARNING xorp_ospfv2:13215 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:32:06 WARNING xorp_ospfv2:13215 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:32:33 WARNING xorp_ospfv2:13215 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 [ 2008/05/12 16:32:49 WARNING xorp_ospfv2:13215 OSPF area_router.cc:5759 routing_router_link_transitV2 ] LSA in database MaxAge Network-LSA: LS age 3600 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.2.5.5 Advertising Router 127.1.0.5 LS sequence number 0x80000001 LS checksum 0x3581 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.5 Attached Router 127.1.0.2 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon May 12 18:52:30 2008 From: greearb at candelatech.com (Ben Greear) Date: Mon, 12 May 2008 18:52:30 -0700 Subject: [Xorp-hackers] OSPF stuck in Loading state In-Reply-To: <4828D65F.3040302@candelatech.com> References: <4828D65F.3040302@candelatech.com> Message-ID: <4828F45E.8090309@candelatech.com> Ben Greear wrote: > I seem to have a repeatable OSPF problem where it gets stuck in > loading state. > As an update to this, I checked back after a few hours, and it is in the 'Full' state and the routes seem to have converged. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon May 12 18:56:04 2008 From: greearb at candelatech.com (Ben Greear) Date: Mon, 12 May 2008 18:56:04 -0700 Subject: [Xorp-hackers] CVS diff in the automated email? In-Reply-To: <4827F491.8020807@icsi.berkeley.edu> References: <482499AC.7070807@candelatech.com> <200805112216.m4BMGjO9012415@fruitcake.ICSI.Berkeley.EDU> <4827BB3D.2020509@candelatech.com> <4827F491.8020807@icsi.berkeley.edu> Message-ID: <4828F534.5000100@candelatech.com> Bruce M. Simpson wrote: > Ben, > > If doing something like tailor+hg is too much for you: > http://www.freshports.org/mail/cvsmail/ > > ...is a FreeBSD port which acts as a mail filter and adds web links to > FreeBSD commit mail. I'm trying to import the xorp repo into a local git repo now. It seems to be working..but may take a while. If anyone is interested, I'll figure out how to host it so others can do a normal git checkout. Thanks, Ben > > cheers > BMS -- Ben Greear Candela Technologies Inc http://www.candelatech.com From libin020989 at gmail.com Tue May 13 19:30:34 2008 From: libin020989 at gmail.com (=?GB2312?B?wO6x8g==?=) Date: Wed, 14 May 2008 10:30:34 +0800 Subject: [Xorp-hackers] how to distribute a new XORP release Message-ID: <200805141030161092393@gmail.com> I'm a student from Beijing University of Posts and Telecommunications.Huawei company submited a LightWeight-IGMPv3/MLDv2 draft,it was accepted by IETF.IETF hopes Huawei distribute the source code.The development of the source code was done by us.We modified the IGMPv3/MLDv2 module which is in the XORP release 1.4.I want to know whether we can distribute it on the XORP website as a new XORP release and how to distribute it. ?? 2008-05-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080514/3c38810b/attachment.html From rae.harbird at gmail.com Wed May 14 08:28:39 2008 From: rae.harbird at gmail.com (Rae Harbird) Date: Wed, 14 May 2008 16:28:39 +0100 Subject: [Xorp-hackers] Getting started with Jam and xorp modules Message-ID: Hi Can someone give me some assistance with jam and a new xorp module I'm writing? What's the process generally used? For example, taking the olsr module as an example: if I type: jam -t olsr at the top level, nothing is built If I type the same in the contrib directory I get: ../olsr/tools/Jamfile: No such file or directory ...patience... don't know how to make external.cc don't know how to make face.cc don't know how to make face_manager.cc don't know how to make link.cc don't know how to make message.cc don't know how to make neighbor.cc don't know how to make neighborhood.cc don't know how to make olsr.cc don't know how to make olsr_types.cc don't know how to make policy_varrw.cc don't know how to make route_manager.cc don't know how to make topology.cc don't know how to make twohop.cc don't know how to make xrl_io.cc don't know how to make xrl_queue.cc don't know how to make xrl_port.cc don't know how to make xrl_target.cc don't know how to make debug_io.cc don't know how to make emulate_net.cc etc ... Regards Rae From greearb at candelatech.com Wed May 14 15:50:21 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 14 May 2008 15:50:21 -0700 Subject: [Xorp-hackers] New consolidated Xorp performance improvement patch uploaded. In-Reply-To: <4824ABCC.8030906@candelatech.com> References: <481B6201.8080309@candelatech.com> <482416BF.3020903@incunabulum.net> <482447F6.60102@candelatech.com> <482472D2.3080306@incunabulum.net> <4824ABCC.8030906@candelatech.com> Message-ID: <482B6CAD.6000407@candelatech.com> There were some bugs in my earlier merge. I have just uploaded a new patch that should patch cleanly against latest CVS. This has been tested and seems to be mostly working. No new functionality in this since last time I sent the consolidated patch. This patch is from 'git' (I imported xorp cvs into a local git repository), but I believe it will apply directly to a cvs tree as well with patch -p1 < foo.patch http://www.candelatech.com/oss/xorp-2008-05-14.patch Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Wed May 14 17:48:08 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 14 May 2008 17:48:08 -0700 Subject: [Xorp-hackers] Trivial fix In-Reply-To: <200803150520.m2F5KSPD008869@fruitcake.ICSI.Berkeley.EDU> References: <689692.69944.qm@web31513.mail.mud.yahoo.com> <200803150520.m2F5KSPD008869@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200805150048.m4F0m8ha019453@fruitcake.ICSI.Berkeley.EDU> Pavlin Radoslavov wrote: > Jonathan Day wrote: > > > Hi, > > > > I'll get the Windows patches sorted out as a single > > unit. For now, however, there's a trivial fix needed > > in strptime.c. It includes strings.h automatically, > > whether or not configure found it. This needs to be > > replaced with the following: > > > > #ifdef HAVE_STRINGS_H > > #include > > #else > > #include > > #endif For the record, now is guarded with #ifdef HAVE_STRINGS_H. The fix is applied in the following CVS commit: Revision Changes Path 1.17 +5 -2; commitid: b0d2482b86cd41a7; xorp/libxorp/strptime.c Thanks, Pavlin > What OS (and OS version) are you using? > If it is Windows, currently XORP works on only few Windows versions, > and even then you need to install more things (see file BUILD_NOTES, > Section 3.7). > > About the above patch, unfortunately it won't work the way it is, > because the story with the include files in strptime.c in particular > is slightly complicated (see the comments where _XOPEN_SOURCE is > defined. > Also, note that "config.h" is included after and > therefore the "#ifdef HAVE_STRINGS_H" statement won't > matter. > > The correct solution would be to try to move #include "config.h" > before and then use something like: > > #ifdef HAVE_STRINGS_H > #include > #endif > #ifdef HAVE_STRING_H > #include > #endif > > Unfortunately, given the fragile situation with the header file > inclusion in strptime.c, doing even something like this needs to be > carefully tested that it doesn't break the compilation on all > platforms supported currently by XORP. > > Thanks, > Pavlin > > > There seem to be some issues with POSIX vs. ISO C99 > > calls vs. secure alternatives to standard functions, > > but I'm still trying to figure out the "best" solution > > to this as this would touch a lot of source. I need to > > come up with a solution, as Windows complains bitterly > > about older calls, but it would be better if any > > version submitted into the main source tree was agreed > > on as the (nominally) best solution. > > > > Jonathan Day > > > > Jonathan > > > > > > ____________________________________________________________________________________ > > Be a better friend, newshound, and > > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From libin020989 at gmail.com Thu May 15 00:19:35 2008 From: libin020989 at gmail.com (=?gb2312?B?wO6x8g==?=) Date: Thu, 15 May 2008 15:19:35 +0800 Subject: [Xorp-hackers] how to distribute a new XORP release Message-ID: <200805151519332657764@gmail.com> I have writed an E-mail to ask whether we can distribute the new XORP release on the XORP website,noone answer me yet,I want to know the answer as soon as possible,and how to distribute it. ?? 2008-05-15 Message: 1 Date: Wed, 14 May 2008 10:30:34 +0800 From: " ?? " Subject: [Xorp-hackers] how to distribute a new XORP release To: "xorp-hackers" Message-ID: <200805141030161092393 at gmail.com> Content-Type: text/plain; charset="gb2312" I'm a student from Beijing University of Posts and Telecommunications.Huawei company submited a LightWeight-IGMPv3/MLDv2 draft,it was accepted by IETF.IETF hopes Huawei distribute the source code.The development of the source code was done by us.We modified the IGMPv3/MLDv2 module which is in the XORP release 1.4.I want to know whether we can distribute it on the XORP website as a new XORP release and how to distribute it. ?? 2008-05-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080515/9e666af4/attachment.html From bms at incunabulum.net Thu May 15 01:45:37 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 15 May 2008 09:45:37 +0100 Subject: [Xorp-hackers] how to distribute a new XORP release In-Reply-To: <200805151519332657764@gmail.com> References: <200805151519332657764@gmail.com> Message-ID: <482BF831.2080105@incunabulum.net> ???? wrote: > I have writed an E-mail to ask whether we can distribute the new XORP > release on the XORP website,noone answer me yet,I want to know the > answer as soon as possible,and how to distribute it. Hi there, Probably the best way to go about getting IGMPv3-Lite included in XORP is to: 1. create a Bugzilla entry at bugzilla.xorp.org 2. include a brief summary of the changes you made 3. attach a diff against the release of XORP which you modified in "unified diff" format. Then we can review the changes for inclusion in a future release. Having a test suite for new code makes it more likely that the code can be included. thanks BMS From bms at incunabulum.net Thu May 15 01:45:47 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 15 May 2008 09:45:47 +0100 Subject: [Xorp-hackers] Getting started with Jam and xorp modules In-Reply-To: References: Message-ID: <482BF83B.801@incunabulum.net> Rae Harbird wrote: > Can someone give me some assistance with jam and a new xorp module I'm > writing? What's the process generally used? > Although I pushed the new code into GNU make, I forgot to update the Jamfiles when relocating olsr into contrib, during the merge to the main line of development. This should now be fixed in CVS. cheers BMS From atanu at ICSI.Berkeley.EDU Thu May 15 08:05:54 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 15 May 2008 08:05:54 -0700 Subject: [Xorp-hackers] how to distribute a new XORP release In-Reply-To: Message from "=?GB2312?B?wO6x8g==?=" of "Wed, 14 May 2008 10:30:34 +0800." <200805141030161092393@gmail.com> Message-ID: <72133.1210863954@tigger.icir.org> Hi, If you can package up your changes so they can be placed in the contrib directory (olsr should serve as an example of how this is done) then we would consider hosting your changes. Atanu. >>>>> "libin020989" == libin020989 writes: libin020989> I'm a student from Beijing University of Posts and libin020989> Telecommunications.Huawei company submited a libin020989> LightWeight-IGMPv3/MLDv2 draft,it was accepted by libin020989> IETF.IETF hopes Huawei distribute the source code.The libin020989> development of the source code was done by us.We libin020989> modified the IGMPv3/MLDv2 module which is in the XORP libin020989> release 1.4.I want to know whether we can distribute it libin020989> on the XORP website as a new XORP release and how to libin020989> distribute it. libin020989> libin020989> _________________________________________________________________ libin020989> ???? libin020989> 2008-05-14 libin020989> _______________________________________________ libin020989> Xorp-hackers mailing list Xorp-hackers at icir.org libin020989> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From cevhers at gmail.com Thu May 15 13:31:55 2008 From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=) Date: Thu, 15 May 2008 16:31:55 -0400 Subject: [Xorp-hackers] pointer to ospf area router instance ? Message-ID: <803a75c30805151331p2f4985e5l48ea6d17ba7eedcf@mail.gmail.com> Hi All, I am trying to access one of the member functions of current AreaRouter instance from within xrl_target.cc in xorp/ospf folder. (ospfv2) By the way, it seems like every ospf router is created as an area router (?) I try to use following command within a function in xrl_target.cc to get a reference to the current AreaRouter instance: _ospf.get_peer_manager().get_area_router(area); However, how can I find the area router ID (area) to give get_area_router() function as a parameter ? or Is there any other way to do that ? Thanks. Selcuk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080515/66dd9f6d/attachment.html From atanu at ICSI.Berkeley.EDU Thu May 15 14:02:58 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 15 May 2008 14:02:58 -0700 Subject: [Xorp-hackers] pointer to ospf area router instance ? In-Reply-To: Message from "=?ISO-8859-1?Q?Sel=E7uk_Cevher?=" of "Thu, 15 May 2008 16:31:55 EDT." <803a75c30805151331p2f4985e5l48ea6d17ba7eedcf@mail.gmail.com> Message-ID: <10625.1210885378@tigger.icir.org> Hi, Comments inline. Sel?uk Cevher wrote: > Hi All, > > > > I am trying to access one of the member functions of current > AreaRouter instance from within xrl_target.cc in xorp/ospf folder. > (ospfv2) > In general all accessing of internal OSPF state should be performed through the OSPF class, although this principle is violated in a few places in xrl_target.cc. > > By the way, it seems like every ospf router is created as an area > router (?) > OSPF partitions its world into areas, the name of the class happens to be AreaRouter, this does not imply that the router is an area border router. > I try to use following command within a function in xrl_target.cc to > get a reference to the current AreaRouter instance: > > > > _ospf.get_peer_manager().get_area_router(area); > > > > However, how can I find the area router ID (area) to give > get_area_router() function as a parameter ? > Provide the area ID for the area that you are interested in, if you are adding an interface that requires an area ID then provide it as an argument to the XRL. The PeerManager class has a method "get_area_list" that will provide a list of all the configured areas. > > or > > > > Is there any other way to do that ? > > > > Thanks. > > Selcuk > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers Atanu. From greearb at candelatech.com Tue May 20 10:02:27 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 20 May 2008 10:02:27 -0700 Subject: [Xorp-hackers] Multiple multicast routing table support Message-ID: <48330423.6070600@candelatech.com> Hello! I'm considering adding multiple multicast routing table support to xorp. I believe this will require Linux kernel changes and possibly some API changes when talking to the kernel. The end goal is to support multiple virtual multicast routers, which each of these multicast routers using only a subset of the interfaces on a particular machine. This is already working for normal routing tables and OSPF (at least) on Linux. If someone with more multicast knowledge could let me know what kind of changes would be needed, I would much appreciate it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Wed May 21 04:18:27 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 21 May 2008 12:18:27 +0100 Subject: [Xorp-hackers] Multiple multicast routing table support In-Reply-To: <48330423.6070600@candelatech.com> References: <48330423.6070600@candelatech.com> Message-ID: <48340503.9070002@incunabulum.net> Ben Greear wrote: > Hello! > > I'm considering adding multiple multicast routing table support to > xorp. I believe this will > require Linux kernel changes and possibly some API changes when talking > to the kernel. > To be honest there are other issues in the multicast area which would need to be resolved before multiple MFIB support is worth considering. If you look at the Linux implementation, it more or less follows the MROUTING code from BSD Net/3 pretty closely. Both Linux and FreeBSD have these issues. One of the issues there is that there is a 32 vif limit. The limit is tied to the API and the implementation. There are also other issues with multicast-specific socket options being handled in the raw socket path, when they belong elsewhere. There is also a case for moving multicast route handling into the unicast FIB code, but keeping the MFIB(s) logically distinct from the unicast FIB(s). From greearb at candelatech.com Wed May 21 08:33:47 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 21 May 2008 08:33:47 -0700 Subject: [Xorp-hackers] Multiple multicast routing table support In-Reply-To: <48340503.9070002@incunabulum.net> References: <48330423.6070600@candelatech.com> <48340503.9070002@incunabulum.net> Message-ID: <483440DB.5030209@candelatech.com> Bruce M Simpson wrote: > Ben Greear wrote: >> Hello! >> >> I'm considering adding multiple multicast routing table support to >> xorp. I believe this will >> require Linux kernel changes and possibly some API changes when >> talking to the kernel. >> > > To be honest there are other issues in the multicast area which would > need to be resolved before multiple MFIB support is worth considering. > > If you look at the Linux implementation, it more or less follows the > MROUTING code from BSD Net/3 pretty closely. Both Linux and FreeBSD > have these issues. > > One of the issues there is that there is a 32 vif limit. The limit is > tied to the API and the implementation. There are also other issues > with multicast-specific socket options being handled in the raw socket > path, when they belong elsewhere. > > There is also a case for moving multicast route handling into the > unicast FIB code, but keeping the MFIB(s) logically distinct from the > unicast FIB(s). I'm guessing there may need to be some new API to support multiple kernel routing tables anyway, so it might be a good time to clean up cruft from the old API. For my particular need, 32 VIF per xorp instance will not be a problem, but I'm certainly willing to help remove this limitation while working on the rest of the virtualization. I, or someone working with me, can do the Linux kernel portion, and of course I can probably muck with Xorp as well. But, if someone else wants to help lead the xorp issue, or at least poke me in the right direction and review patches, that will free up more of my time to deal with the kernel. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From rbrasil07 at gmail.com Wed May 21 14:58:33 2008 From: rbrasil07 at gmail.com (Rodrigo Brasil) Date: Wed, 21 May 2008 18:58:33 -0300 Subject: [Xorp-hackers] New QMA feature Message-ID: <21948cf0805211458w3bf451ek3550a39767db1b6c@mail.gmail.com> Hi, I'm a computer science student and I'm doing my master of computer science at Federal University of Rio de Janeiro, Brazil. The theme of my thesis is how to create a real test environment to work with *queue management algorithms.* I would like to know if someone is working within this theme in XORP. I didn't find any information about this subject inside the documentation. It would be interesting if the network administrator can choose the type of QMA to be implemented within the router. E.g.: RED, BLUE, FRED, etc. ... I would like to deploy this functionality and work with the team. Someone could introduce me and pass some information about the source code, how to submit new versions, etc. ... Regards, Rodrigo Brasil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080521/06726fe9/attachment.html From pavlin at ICSI.Berkeley.EDU Thu May 22 13:31:47 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 22 May 2008 13:31:47 -0700 Subject: [Xorp-hackers] how to distribute a new XORP release In-Reply-To: <200805141030161092393@gmail.com> References: <200805141030161092393@gmail.com> Message-ID: <200805222031.m4MKVlJc006544@fruitcake.ICSI.Berkeley.EDU> ?? wrote: > I'm a student from Beijing University of Posts and > Telecommunications.Huawei company submited a > LightWeight-IGMPv3/MLDv2 draft,it was accepted by IETF.IETF hopes > Huawei distribute the source code.The development of the source > code was done by us.We modified the IGMPv3/MLDv2 module which is > in the XORP release 1.4.I want to know whether we can distribute > it on the XORP website as a new XORP release and how to distribute > it. We looked into the source code with the modifications that was submitted to Bugzilla: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=756 As you know already, XORP has the full IGMPv1,2,3/MLDv1,2 implementation. The Lightweight IGMPv3/MLDv2 version of the spec (I-D draft-ietf-mboned-lightweight-igmpv3-mldv2-02) actually removes functionalities from the full IGMPv3/MLDv2, therefore it has little practical value for XORP. We understand however, that someone looking specifically for a reference implementation of "Lightweight IGMPv3/MLDv2" might benefit from your code. For that reason, we could add a copy of your code to the xorp/contrib subdirectory. However, the tarball in Bugzilla as-is cannot be added to the CVS tree. If you would like your code to be added to xorp/contrib/mld6igmp_lite you should do the following: * You need to apply your changes to the latest XORP code from CVS: http://www.xorp.org/cvs.html What you are using right now is XORP-1.4 and there have been a number of modifications since them. If you do "diff -ur mld6igmp contrib/mld6igmp_lite" you should see only those changes that are related to the Lite version of the protocol with no side effects (e.g., no line formatting, leftover temporary comments, etc). In fact, this will be the command we will be using to evaluate the next tarball from you. * Cleanup the code. Right now there are a number of leftover XLOG messages like the following that should be removed: XLOG_WARNING("RX kakalong 333333333333322++++...") If you want to have log messages that can be enabled in run-time then you should use XLOG_TRACE(). If you want to have log messages that can be enabled in compile-time, then you should use the debug_msg() mechanism. Regardless what mechanism you use, the text of the log message should be clear and meaningful. Comments like the following should be removed as well: //Modified by ... 06-13. mark:not needed modification There are other comments with modification summaries that don't need to be in the final code: /* * modified verion: 1 * ********************************************************************** * modified Summaries: delete _dont_forward_source_list relevant variables * There is a local logging implementation inside your code (class LocalTrace and friends) that should be removed. There is no obvious reason why this should be there instead of using the existing XORP XLOG mechanism. * It doesn't seem that the modified code is following the XORP coding style (available from xorp/devnotes/coding-style.txt). E.g., lack of space after "," argument separator, long lines without a break in the appropriate place, etc. * If the code is added to xorp/contrib/mld6igmp_lite, there should be instructions (in your own README that will be included with the code) how someone would use it instead of the full IGMP/MLD implementation from XORP. For example, if you provide your own *.tp or *.cmds rtrmgr/xorpsh template files, there should be instructions how someone would use them to replace the existing IGMP/MLD-related templates. Also, obviously, there should be instructions how someone to compile it (e.g., using "./configure --enable-mld6igmp-lite" configuration switch). * In your README there should be contact information for those of you who will support the code (dealing with bug issues and updates, major compilation issues, etc). As a policy, if a third-party module no longer builds against the current XORP code or has significant bugs and has not been updated in 6 months, then the code will be moved to a separate "obsoleted code" repository. Please let us know if you have any questions. Thank you, The XORP team From rae.harbird at gmail.com Fri May 23 05:06:13 2008 From: rae.harbird at gmail.com (Rae Harbird) Date: Fri, 23 May 2008 13:06:13 +0100 Subject: [Xorp-hackers] Configuration file Message-ID: Hi I am writing a service discovery module which uses the olsr module to distribute service information. I want to initialise the service discovery module with some configuration values and I can see this is done using a .tp file. Is there a way of configuring a multi-valued attribute? I want to load the service information (urls) that the service discovery node will be advertising. These service-related parameters are really user-level configuration, what do you suggest? Regards Rae From steweg at ynet.sk Fri May 23 10:16:40 2008 From: steweg at ynet.sk (=?ISO-8859-2?Q?=A9tefan_Gula?=) Date: Fri, 23 May 2008 19:16:40 +0200 Subject: [Xorp-hackers] BGP MED attributes Message-ID: Hi, In current implementation I believe that it is not possible to send MED attribute to IBGP neighbors for routes learned from EBGP neighbors. For example: We have got 3 routers: R1, R2, R3 R1 is in AS 100 R2 and R3 are in AS 200 they are connected through links L1, L2, L3 like this: L1: R1 <->R2 L2: R2 <->R3 L3: R3 <->R1 Now want I want to achieve is set MED attribute for routes in AS100 on R1 for link L1 to 100 and for link L2 to 200. This can be accomplished without problems. The problem is that routers R2 and R3 doesn't send MED attribute in their updates about the routes learned from R1. According to RFC 1771 MED is optional non-transitive and "If received over external links, the MULTI_EXIT_DISC attribute may be propagated over internal links to other BGP speakers within the same AS". So why not enable to sending this attribute to other IBGP neighbors? There is also one other limitation about NEXT_HOP attribute. In current implementation every router changes NEXT_HOP attribute to itself (or the IP set in configuration). Sometimes this behaviour is not required and I would like to see the option to disable this behavior. Best regards. -- Stefan Gula, CCNP From M.Handley at cs.ucl.ac.uk Fri May 23 10:48:54 2008 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Fri, 23 May 2008 18:48:54 +0100 Subject: [Xorp-hackers] BGP MED attributes In-Reply-To: References: Message-ID: <84a612dd0805231048k1701abd7v81971501f3f6acf@mail.gmail.com> Stefan, I've looked at the code, and the relevant line is in bgp/plumbing.cc: /* 3. Configure MED filter. Remove old MED and add new one on transmission to EBGP peers. */ /* Note: this MUST come before the nexthop rewriter */ filter_out->add_med_removal_filter(); if (peer_type == PEER_TYPE_EBGP) { filter_out->add_med_insertion_filter(); } So we add a MED removal filter, and then add a MED insertion filter if the peering is EBGP. I think this is probably a bug - unconditionally removing MED on IBGP peerings is not what is required. It is required that it can be removed, but not that it must always be removed. Simply moving the line add_med_removal_filter() line inside the if statement will probably have the desired behaviour. I'm about to go away on vacation, so I won't get a chance to make this change in CVS and run the regression tests before leaving. Can you file a bugzilla bug report on this please, so we don't lose track of it. Thanks, Mark On Fri, May 23, 2008 at 6:16 PM, ?tefan Gula wrote: > Hi, > > In current implementation I believe that it is not possible to send > MED attribute to IBGP neighbors for routes learned from EBGP > neighbors. For example: > We have got 3 routers: R1, R2, R3 > R1 is in AS 100 > R2 and R3 are in AS 200 > they are connected through links L1, L2, L3 like this: > L1: R1 <->R2 > L2: R2 <->R3 > L3: R3 <->R1 > > Now want I want to achieve is set MED attribute for routes in AS100 on > R1 for link L1 to 100 and for link L2 to 200. This can be accomplished > without problems. The problem is that routers R2 and R3 doesn't send > MED attribute in their updates about the routes learned from R1. > According to RFC 1771 MED is optional non-transitive and "If received > over external links, the MULTI_EXIT_DISC attribute may be propagated > over internal links to other BGP speakers within the same AS". So why > not enable to sending this attribute to other IBGP neighbors? > > There is also one other limitation about NEXT_HOP attribute. In > current implementation every router changes NEXT_HOP attribute to > itself (or the IP set in configuration). Sometimes this behaviour is > not required and I would like to see the option to disable this > behavior. > > Best regards. > > -- > Stefan Gula, CCNP > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From rae.harbird at gmail.com Tue May 27 02:38:58 2008 From: rae.harbird at gmail.com (Rae Harbird) Date: Tue, 27 May 2008 10:38:58 +0100 Subject: [Xorp-hackers] Configuration file In-Reply-To: References: Message-ID: Hi Rainy bank holidays are a marvelous thing; I have worked out what to do, I think. Regards Rae 2008/5/23 Rae Harbird : > Hi > > I am writing a service discovery module which uses the olsr module to > distribute service information. I want to initialise the service > discovery module with some configuration values and I can see this is > done using a .tp file. > > Is there a way of configuring a multi-valued attribute? I want to load > the service information (urls) that the service discovery node will be > advertising. These service-related parameters are really user-level > configuration, what do you suggest? > > > > Regards > > > > Rae > From cevhers at gmail.com Thu May 29 09:28:20 2008 From: cevhers at gmail.com (=?ISO-8859-1?Q?Sel=E7uk_Cevher?=) Date: Thu, 29 May 2008 12:28:20 -0400 Subject: [Xorp-hackers] ../ospf/vertex.hh:31 operator< ] Assertion (get_version() == other.get_version()) failed Message-ID: <803a75c30805290928p4e9b16c6o7e01f496c1974f6d@mail.gmail.com> Hi All, I have a problem regarding ospf/vertex.hh which I use within the main file of a process I created in xorp. With pname be the process name, the problem appears when I call a member function of xrl_pname_node class (inherited from target base class) right after instantiating an object of xrl_pname_node and right before the while loop (eventloop). Before making this call, I also define some variables using Vertex and Node data structures. In this case, when I run rtrmgr, I get the error message saying that : [ 2008/05/29 08:00:04 FATAL xorp_pname:12240 pname ../ospf/vertex.hh:31 operator< ] Assertion (get_version() == other.get_version()) failed [ 2008/05/29 08:00:04 ERROR xorp_rtrmgr:12239 RTRMGR module_manager.cc:757 done_cb ] Command "/home/scevher/xorp.deneme/pname/xorp_pname": terminated with signal 6. [ 2008/05/29 08:00:04 INFO xorp_rtrmgr:12239 RTRMGR module_manager.cc:294 module_exited ] Module abnormally killed: pname Apparently, it did not like the overloaded operator < defined in Vertex class (I do not use this overloaded operator explicitly by the way). Any idea how to fix this ? Thanks. Selcuk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080529/60204cad/attachment.html From atanu at ICSI.Berkeley.EDU Thu May 29 15:17:49 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 29 May 2008 15:17:49 -0700 Subject: [Xorp-hackers] ../ospf/vertex.hh:31 operator< ] Assertion (get_version() == other.get_version()) failed In-Reply-To: Message from "=?ISO-8859-1?Q?Sel=E7uk_Cevher?=" of "Thu, 29 May 2008 12:28:20 EDT." <803a75c30805290928p4e9b16c6o7e01f496c1974f6d@mail.gmail.com> Message-ID: <43034.1212099469@tigger.icir.org> Hi, The _version field in the Vertex class is an enumerated type that can have the values OspfTypes::V2 or OspfTypes::V3. The assertion is telling you that you have mixed OSPFv2 with OSPFv3. Use set_version to set the type for all Vertex objects. Atanu. Sel?uk Cevher wrote: > > Hi All, > > > > I have a problem regarding ospf/vertex.hh which I use within the main > file of a process I created in xorp. > > > > With pname be the process name, the problem appears when I call a > member function of xrl_pname_node class (inherited from target base > class) right after instantiating an object of xrl_pname_node and right > before the while loop (eventloop). Before making this call, I > also define some variables using Vertex and Node data structures. > > > > In this case, when I run rtrmgr, I get the error message saying that : > > > > [ 2008/05/29 08:00:04 FATAL xorp_pname:12240 pname > ../ospf/vertex.hh:31 operator< ] Assertion (get_version() == > other.get_version()) failed > [ 2008/05/29 08:00:04 ERROR xorp_rtrmgr:12239 RTRMGR > module_manager.cc:757 done_cb ] Command > "/home/scevher/xorp.deneme/pname/xorp_pname": terminated with signal > 6. > [ 2008/05/29 08:00:04 INFO xorp_rtrmgr:12239 RTRMGR > module_manager.cc:294 module_exited ] Module abnormally killed: pname > > Apparently, it did not like the overloaded operator < defined in > Vertex class (I do not use this overloaded operator explicitly by the > way). > > > > Any idea how to fix this ? > > > > Thanks. > > Selcuk > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers