From awalton at wires3.net Wed May 5 13:11:29 2010 From: awalton at wires3.net (AWalton) Date: Wed, 05 May 2010 21:11:29 +0100 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 Message-ID: <4BE1D0F1.5000508@wires3.net> Hi, I am having a problem upgrading from xorp1.4 to 1.6. I have 4 production routers that have been running 1.4 since 2007ish, but recently I started to have the xorp bgp process crash when peering with a routerOS board that had been upgraded to the latest version of the routerOS code. Anyhow I have a test system with the same hardware and kernel as the production devices. They are all running 2.6.18-5-486 on VIA 800Mhz 486 clones. The test system seems to compile 1.6 without problems apart from some warnings about 'soprint' command or something, but I think I have seen this 'way back when' and it was never a problem. However when I run the test suite it fails. make[3]: Entering directory `/mnt/usbdisk/xorp-1.6/rip' PASS: test_auth PASS: test_packets PASS: test_request PASS: test_route_walk FAIL: test_timers PASS: test_update_queue PASS: test_outputs ================================== 1 of 7 tests failed Please report to feedback at xorp.org ================================== If I ignore the failure and try running xorp1.6 anyway I get these outputs from rtrmgr: test-dsl-gw:/mnt/usbdisk/xorp-1.6/rtrmgr# ./xorp_rtrmgr [ 2010/05/05 20:59:31 INFO xorp_rtrmgr:29751 RTRMGR +249 master_conf_tree.cc execute ] Changed modules: interfaces [ 2010/05/05 20:59:31 INFO xorp_rtrmgr:29751 RTRMGR +101 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2010/05/05 20:59:32 ERROR xorp_fea:29752 LIBCOMM +101 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] MFEA enabled [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI enabled [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI started [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] MFEA enabled [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI enabled [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI started [ 2010/05/05 20:59:33 INFO xorp_rtrmgr:29751 RTRMGR +2233 task.cc run_task ] No more tasks to run [ 2010/05/05 21:00:34 ERROR xorp_rtrmgr:29751 RTRMGR +654 xrl_rtrmgr_interface.cc client_updated ] Failed to notify client that config changed: Bad argument(s) [ 2010/05/05 21:00:34 ERROR xorp_rtrmgr:29751 RTRMGR +654 xrl_rtrmgr_interface.cc client_updated ] Failed to notify client that config changed: Bad argument(s) and then xorpsh hangs with this: test-dsl-gw:/mnt/usbdisk/xorp-1.6# xorpsh [ 2010/05/05 21:00:34 WARNING xorpsh RTRMGR ] [Operational Command File: /usr/local/xorp/etc/templates/misc.cmds line 39]: Executable file not found: traceroute6 [ 2010/05/05 21:00:34 ERROR xorpsh:29755 XrlXorpshTarget +310 xorpsh_base.cc handle_rtrmgr_client_0_2_module_status ] Argument not found [ 2010/05/05 21:00:34 ERROR xorpsh:29755 XrlXorpshTarget +284 xorpsh_base.cc handle_rtrmgr_client_0_2_config_changed ] Argument not found Any ideas what's going wrong? Thanks Aidan From greearb at candelatech.com Wed May 5 20:34:52 2010 From: greearb at candelatech.com (Ben Greear) Date: Wed, 05 May 2010 20:34:52 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE1D0F1.5000508@wires3.net> References: <4BE1D0F1.5000508@wires3.net> Message-ID: <4BE238DC.8060001@candelatech.com> On 05/05/2010 01:11 PM, AWalton wrote: > Hi, > I am having a problem upgrading from xorp1.4 to 1.6. I have 4 production > routers that have been running 1.4 since 2007ish, but recently I started > to have the xorp bgp process crash when peering with a routerOS board > that had been upgraded to the latest version of the routerOS code. > > Anyhow I have a test system with the same hardware and kernel as the > production devices. They are all running 2.6.18-5-486 on VIA 800Mhz 486 > clones. > > The test system seems to compile 1.6 without problems apart from some > warnings about 'soprint' command or something, but I think I have seen > this 'way back when' and it was never a problem. If you can reproduce the bgp issues on xorp.ct (which should become xorp 1.8-WIP release as soon as we can get 1.7 out the door), I am interested in seeing logs, core-files, etc and will attempt to fix them. I don't have interest in messing with 1.6, however. I fixed a few crashes in bgp lately in xorp.ct, and it mostly passes the test harness scripts, but there could be more issues for sure. http://www.candelatech.com/oss/xorp-ct.html Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From awalton at wires3.net Thu May 6 00:17:42 2010 From: awalton at wires3.net (AWalton) Date: Thu, 06 May 2010 08:17:42 +0100 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE238DC.8060001@candelatech.com> References: <4BE1D0F1.5000508@wires3.net> <4BE238DC.8060001@candelatech.com> Message-ID: <4BE26D16.6070905@wires3.net> Hi Ben, I can in fact help here, as it is simple for me to re-produce, however getting logs from my xorp1.4 install is not easy. It never worked. In fact I have tried repeatedly to get logging working but each time it would start logging and then stop suddenly never to resume. So here's a few questions: What is xorp.ct? What do I need to do to get logging working correctly on 1.4 This bug crashes my network, so I will need to do this in the early hours of the morning otherwise I will upset my customers, so we need to get this right first time. Please help me to help you. BTW, why the lack of interest in 1.6. Is there some major change that has occurred architecturally. Are you telling me that xorp1.6 is on a different code tree? Why are you wishing to bug fix the old release? Thanks Aidan Ben Greear wrote: > On 05/05/2010 01:11 PM, AWalton wrote: >> Hi, >> I am having a problem upgrading from xorp1.4 to 1.6. I have 4 production >> routers that have been running 1.4 since 2007ish, but recently I started >> to have the xorp bgp process crash when peering with a routerOS board >> that had been upgraded to the latest version of the routerOS code. >> >> Anyhow I have a test system with the same hardware and kernel as the >> production devices. They are all running 2.6.18-5-486 on VIA 800Mhz 486 >> clones. >> >> The test system seems to compile 1.6 without problems apart from some >> warnings about 'soprint' command or something, but I think I have seen >> this 'way back when' and it was never a problem. > > If you can reproduce the bgp issues on xorp.ct (which should become > xorp 1.8-WIP release as > soon as we can get 1.7 out the door), I am interested in seeing logs, > core-files, etc > and will attempt to fix them. I don't have interest in messing with > 1.6, however. > > I fixed a few crashes in bgp lately in xorp.ct, and it mostly passes the > test harness scripts, but there could be more issues for sure. > > http://www.candelatech.com/oss/xorp-ct.html > > Thanks, > Ben > From awalton at wires3.net Thu May 6 00:27:59 2010 From: awalton at wires3.net (AWalton) Date: Thu, 06 May 2010 08:27:59 +0100 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE238DC.8060001@candelatech.com> References: <4BE1D0F1.5000508@wires3.net> <4BE238DC.8060001@candelatech.com> Message-ID: <4BE26F7F.5090908@wires3.net> Hi Ben, OK now I see what you xorp-ct is. I thought you referred to the older code mainline xorp. Look as much as I would like to help, I can not easily get the problem re-produced with xorp-ct. It is no joke to upgrade core router code on a production (paying customer) network. If you are not interested in the BGP bug and the logs I may get from xorp1.4 then thank you for the suggestions. I will just have to try somewhere else. Sorry about that. Thanks Aidan Ben Greear wrote: > On 05/05/2010 01:11 PM, AWalton wrote: >> Hi, >> I am having a problem upgrading from xorp1.4 to 1.6. I have 4 production >> routers that have been running 1.4 since 2007ish, but recently I started >> to have the xorp bgp process crash when peering with a routerOS board >> that had been upgraded to the latest version of the routerOS code. >> >> Anyhow I have a test system with the same hardware and kernel as the >> production devices. They are all running 2.6.18-5-486 on VIA 800Mhz 486 >> clones. >> >> The test system seems to compile 1.6 without problems apart from some >> warnings about 'soprint' command or something, but I think I have seen >> this 'way back when' and it was never a problem. > > If you can reproduce the bgp issues on xorp.ct (which should become > xorp 1.8-WIP release as > soon as we can get 1.7 out the door), I am interested in seeing logs, > core-files, etc > and will attempt to fix them. I don't have interest in messing with > 1.6, however. > > I fixed a few crashes in bgp lately in xorp.ct, and it mostly passes the > test harness scripts, but there could be more issues for sure. > > http://www.candelatech.com/oss/xorp-ct.html > > Thanks, > Ben > From greearb at candelatech.com Thu May 6 07:56:05 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 07:56:05 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE26F7F.5090908@wires3.net> References: <4BE1D0F1.5000508@wires3.net> <4BE238DC.8060001@candelatech.com> <4BE26F7F.5090908@wires3.net> Message-ID: <4BE2D885.3020408@candelatech.com> On 05/06/2010 12:27 AM, AWalton wrote: > Hi Ben, > OK now I see what you xorp-ct is. > I thought you referred to the older code mainline xorp. Look as much as > I would like to help, I can not easily get the problem re-produced with > xorp-ct. It is no joke to upgrade core router code on a production > (paying customer) network. > > If you are not interested in the BGP bug and the logs I may get from > xorp1.4 then thank you for the suggestions. I will just have to try > somewhere else. Likely the code has changed too much for me to debug your 1.4 traces in 1.7 code. If you have a scenario that we could reproduce somehow, then I'll try to do that. Can you maybe put a secondary development xorp box in a similar place in the network (but not handling actual customer traffic) to reproduce the problem? Or, can you configure a stand-alone RouterOS box and xorp by itself to reproduce the problem? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu May 6 07:59:43 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 07:59:43 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE26D16.6070905@wires3.net> References: <4BE1D0F1.5000508@wires3.net> <4BE238DC.8060001@candelatech.com> <4BE26D16.6070905@wires3.net> Message-ID: <4BE2D95F.5090309@candelatech.com> On 05/06/2010 12:17 AM, AWalton wrote: > Hi Ben, > I can in fact help here, as it is simple for me to re-produce, however > getting logs from my xorp1.4 install is not easy. It never worked. In > fact I have tried repeatedly to get logging working but each time it > would start logging and then stop suddenly never to resume. > > So here's a few questions: > What is xorp.ct? > What do I need to do to get logging working correctly on 1.4 > This bug crashes my network, so I will need to do this in the early > hours of the morning otherwise I will upset my customers, so we need to > get this right first time. > > Please help me to help you. > > BTW, why the lack of interest in 1.6. Is there some major change that > has occurred architecturally. Are you telling me that xorp1.6 is on a > different code tree? Why are you wishing to bug fix the old release? As you noticed, xorp.ct is newer than 1.7 even..contains lots of my fixes especially related to virtualization and bugs I found while implementing our network emulator and virtual router system. I know my code pretty well, can test it, and feel comfortable debugging it. I don't have nearly that confidence on older xorp code, which is the main reason why I don't offer to debug or fix it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Thu May 6 10:37:19 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Thu, 6 May 2010 18:37:19 +0100 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE1D0F1.5000508@wires3.net> References: <4BE1D0F1.5000508@wires3.net> Message-ID: Aidan, There have been some fairly significant changes in how xorp is run since 1.4, and its back being a community project again. A number of changes have occured to the stack. The current svn on sourceforge is going to be the basis of the 1.7 release, it isn't a huge change over 1.6 , with the major change being the adoption of scons. Ben has been porting some of his basic changes back from his xorp.ct tree into sourceforge svn to fix bugs and a few other things. The idea is to roll the 1.7 release fairly shortly because of the inclusion of scons . 1.8 will follow fairly shortly after and be an adotpion of a lot more ben's tree (maybe all). My suggestion would be for you to try the sourceforge svn code on a test box and see if that works for you, and help us iron any bugs out in it before we roll the 1.7 release. Adam On 5 May 2010 21:11, AWalton wrote: > Hi, > I am having a problem upgrading from xorp1.4 to 1.6. I have 4 production > routers that have been running 1.4 since 2007ish, but recently I started > to have the xorp bgp process crash when peering with a routerOS board > that had been upgraded to the latest version of the routerOS code. > > Anyhow I have a test system with the same hardware and kernel as the > production devices. They are all running 2.6.18-5-486 on VIA 800Mhz 486 > clones. > > The test system seems to compile 1.6 without problems apart from some > warnings about 'soprint' command or something, but I think I have seen > this 'way back when' and it was never a problem. > > However when I run the test suite it fails. > > make[3]: Entering directory `/mnt/usbdisk/xorp-1.6/rip' > PASS: test_auth > PASS: test_packets > PASS: test_request > PASS: test_route_walk > FAIL: test_timers > PASS: test_update_queue > PASS: test_outputs > ================================== > 1 of 7 tests failed > Please report to feedback at xorp.org > ================================== > > If I ignore the failure and try running xorp1.6 anyway I get these > outputs from rtrmgr: > > test-dsl-gw:/mnt/usbdisk/xorp-1.6/rtrmgr# ./xorp_rtrmgr > [ 2010/05/05 20:59:31 ?INFO xorp_rtrmgr:29751 RTRMGR +249 > master_conf_tree.cc execute ] Changed modules: interfaces > [ 2010/05/05 20:59:31 ?INFO xorp_rtrmgr:29751 RTRMGR +101 > module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) > [ 2010/05/05 20:59:32 ?ERROR xorp_fea:29752 LIBCOMM +101 comm_sock.c > comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = > 0): Address family not supported by protocol > [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] MFEA enabled > [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI enabled > [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI started > [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] MFEA enabled > [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI enabled > [ 2010/05/05 20:59:32 INFO xorp_fea MFEA ] CLI started > [ 2010/05/05 20:59:33 ?INFO xorp_rtrmgr:29751 RTRMGR +2233 task.cc > run_task ] No more tasks to run > [ 2010/05/05 21:00:34 ?ERROR xorp_rtrmgr:29751 RTRMGR +654 > xrl_rtrmgr_interface.cc client_updated ] Failed to notify client that > config changed: Bad argument(s) > [ 2010/05/05 21:00:34 ?ERROR xorp_rtrmgr:29751 RTRMGR +654 > xrl_rtrmgr_interface.cc client_updated ] Failed to notify client that > config changed: Bad argument(s) > > > and then xorpsh hangs with this: > > test-dsl-gw:/mnt/usbdisk/xorp-1.6# xorpsh > [ 2010/05/05 21:00:34 WARNING xorpsh RTRMGR ] [Operational Command File: > /usr/local/xorp/etc/templates/misc.cmds line 39]: Executable file not > found: traceroute6 > [ 2010/05/05 21:00:34 ?ERROR xorpsh:29755 XrlXorpshTarget +310 > xorpsh_base.cc handle_rtrmgr_client_0_2_module_status ] Argument not found > [ 2010/05/05 21:00:34 ?ERROR xorpsh:29755 XrlXorpshTarget +284 > xorpsh_base.cc handle_rtrmgr_client_0_2_config_changed ] Argument not found > > > Any ideas what's going wrong? > > Thanks > Aidan > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From greearb at candelatech.com Thu May 6 11:04:22 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 11:04:22 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: References: <4BE1D0F1.5000508@wires3.net> Message-ID: <4BE304A6.1070506@candelatech.com> On 05/06/2010 10:37 AM, Adam Greenhalgh wrote: > Aidan, > > There have been some fairly significant changes in how xorp is run > since 1.4, and its back being a community project again. A number of > changes have occured to the stack. The current svn on sourceforge is > going to be the basis of the 1.7 release, it isn't a huge change over > 1.6 , with the major change being the adoption of scons. Ben has been > porting some of his basic changes back from his xorp.ct tree into > sourceforge svn to fix bugs and a few other things. The idea is to > roll the 1.7 release fairly shortly because of the inclusion of scons > . 1.8 will follow fairly shortly after and be an adotpion of a lot > more ben's tree (maybe all). > > My suggestion would be for you to try the sourceforge svn code on a > test box and see if that works for you, and help us iron any bugs out > in it before we roll the 1.7 release. I am certain there are some un-caught exceptions in 1.7 BGP, because I hit them while fixing up the harness code in xorp.ct, and also reproduced some of them when configuring bgp as virtual routers. But, fixing the harness was a good bit of patches and also includes some logic that depends on other xorp.ct patches, so I'm not sure if it's worth trying to backport it into 1.7. From what I understand about 1.7 changes, it's likely those same BGP exception issues exist in 1.6. I'm not sure if these are the same issues that Aidan is hitting or not. If we're going to attempt to release 1.7 with as few changes as possible, I think we should just go ahead and release, and pour all effort into 1.8. If I am allowed to push most or all of xorp.ct into 1.8, then I can give developers ( and non-profits, students, etc) licenses to our virtual-router software so people can easily configure large virtual router networks using xorp. This makes it trivial to test many large network scenarios that would otherwise take lots of effort and/or hardware (like two clouds of OSPF routers joined by two BGP routers, etc). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From awalton at wires3.net Thu May 6 11:15:49 2010 From: awalton at wires3.net (AWalton) Date: Thu, 06 May 2010 19:15:49 +0100 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE304A6.1070506@candelatech.com> References: <4BE1D0F1.5000508@wires3.net> <4BE304A6.1070506@candelatech.com> Message-ID: <4BE30755.6070505@wires3.net> I have to say you have me somewhat confused now. Which version shall I try? What makes you think that either xorp-ct or svn of the official xorp tree will actually compile and run especially as 1.6 did not. Dont forget this is a 486 VIA fanless processor that I must compile on. It takes a long time to try anything. Aidan Ben Greear wrote: > On 05/06/2010 10:37 AM, Adam Greenhalgh wrote: >> Aidan, >> >> There have been some fairly significant changes in how xorp is run >> since 1.4, and its back being a community project again. A number of >> changes have occured to the stack. The current svn on sourceforge is >> going to be the basis of the 1.7 release, it isn't a huge change over >> 1.6 , with the major change being the adoption of scons. Ben has been >> porting some of his basic changes back from his xorp.ct tree into >> sourceforge svn to fix bugs and a few other things. The idea is to >> roll the 1.7 release fairly shortly because of the inclusion of scons >> . 1.8 will follow fairly shortly after and be an adotpion of a lot >> more ben's tree (maybe all). >> >> My suggestion would be for you to try the sourceforge svn code on a >> test box and see if that works for you, and help us iron any bugs out >> in it before we roll the 1.7 release. > > I am certain there are some un-caught exceptions in 1.7 BGP, because > I hit them while fixing up the harness code in xorp.ct, and also > reproduced > some of them when configuring bgp as virtual routers. > > But, fixing the harness was a good bit of patches and also includes > some logic that depends on other xorp.ct patches, so I'm not sure if > it's worth trying to backport it into 1.7. From what I understand > about 1.7 changes, it's likely those same BGP exception issues exist > in 1.6. > > I'm not sure if these are the same issues that Aidan is hitting or not. > > If we're going to attempt to release 1.7 with as few changes as possible, > I think we should just go ahead and release, and pour all effort into > 1.8. > > If I am allowed to push most or all of xorp.ct into 1.8, then I can > give developers ( and non-profits, students, etc) licenses to our > virtual-router > software so people can easily configure large virtual router networks > using xorp. > This makes it trivial to test many large network scenarios that would > otherwise > take lots of effort and/or hardware (like two clouds of OSPF routers > joined > by two BGP routers, etc). > > Thanks, > Ben > From greearb at candelatech.com Thu May 6 11:29:04 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 11:29:04 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE30755.6070505@wires3.net> References: <4BE1D0F1.5000508@wires3.net> <4BE304A6.1070506@candelatech.com> <4BE30755.6070505@wires3.net> Message-ID: <4BE30A70.7050402@candelatech.com> On 05/06/2010 11:15 AM, AWalton wrote: > I have to say you have me somewhat confused now. Which version shall I > try? What makes you think that either xorp-ct or svn of the official > xorp tree will actually compile and run especially as 1.6 did not. What OS are you using? *My* preference is that you try xorp.ct because I have a better chance of fixing any bugs you find with it. But, the official 1.7 tree is also better than 1.6, and if the bugs are similar to what I found in xorp.ct, I might be able to help fix them. > Dont forget this is a 486 VIA fanless processor that I must compile on. > It takes a long time to try anything. Hopefully we can duplicate your OS image on faster hardware to develop there... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From awalton at wires3.net Thu May 6 11:33:47 2010 From: awalton at wires3.net (AWalton) Date: Thu, 06 May 2010 19:33:47 +0100 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE30A70.7050402@candelatech.com> References: <4BE1D0F1.5000508@wires3.net> <4BE304A6.1070506@candelatech.com> <4BE30755.6070505@wires3.net> <4BE30A70.7050402@candelatech.com> Message-ID: <4BE30B8B.9090608@wires3.net> Actually that's just what I was thinking of doing. I have a dual core machine that is what I am using right now. I just compiled 1.6 on it in under 15mins. So I was going to try lifting the drive out of the VIA board. Its actually a 2Gb flash IDE disc and loading it up on the dual core machine. Trouble is you never know quite what will happen. The underlying distribution is Debian etch as I said. What I really want to know, is how I can do the compile on the dual core machine but using the kernel headers etc and build environment to match the VIA. Which is a 486 kernel. Ben Greear wrote: > On 05/06/2010 11:15 AM, AWalton wrote: >> I have to say you have me somewhat confused now. Which version shall I >> try? What makes you think that either xorp-ct or svn of the official >> xorp tree will actually compile and run especially as 1.6 did not. > > What OS are you using? > > *My* preference is that you try xorp.ct because I have a better chance > of fixing any bugs you find with it. But, the official 1.7 tree is also > better than 1.6, and if the bugs are similar to what I found in > xorp.ct, I > might be able to help fix them. > >> Dont forget this is a 486 VIA fanless processor that I must compile on. >> It takes a long time to try anything. > > Hopefully we can duplicate your OS image on faster hardware to develop > there... > > Thanks, > Ben > From greearb at candelatech.com Thu May 6 11:45:02 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 11:45:02 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE30B8B.9090608@wires3.net> References: <4BE1D0F1.5000508@wires3.net> <4BE304A6.1070506@candelatech.com> <4BE30755.6070505@wires3.net> <4BE30A70.7050402@candelatech.com> <4BE30B8B.9090608@wires3.net> Message-ID: <4BE30E2E.6050605@candelatech.com> On 05/06/2010 11:33 AM, AWalton wrote: > Actually that's just what I was thinking of doing. I have a dual core > machine that is what I am using right now. I just compiled 1.6 on it in > under 15mins. So I was going to try lifting the drive out of the VIA > board. Its actually a 2Gb flash IDE disc and loading it up on the dual > core machine. > > Trouble is you never know quite what will happen. > > The underlying distribution is Debian etch as I said. > > What I really want to know, is how I can do the compile on the dual core > machine but using the kernel headers etc and build environment to match > the VIA. Which is a 486 kernel. copy the CF image using dd onto a new CF disk..then boot your dual-core from usb -> CF adapter Or, dd the CF image directly onto a hard-drive and boot the HD. Or get an IDE <-> CF adapter and boot a copy of the CF image that way. Hard to say which would be easier...but in the end, you should be able to get the exact image running on your dual-core (perhaps using a single core, but still much faster). The kernel headers shouldn't care what CPU they are compiled for or running on, so I don't think that will be a problem. Thanks, Ben > > Ben Greear wrote: >> On 05/06/2010 11:15 AM, AWalton wrote: >>> I have to say you have me somewhat confused now. Which version shall I >>> try? What makes you think that either xorp-ct or svn of the official >>> xorp tree will actually compile and run especially as 1.6 did not. >> >> What OS are you using? >> >> *My* preference is that you try xorp.ct because I have a better chance >> of fixing any bugs you find with it. But, the official 1.7 tree is also >> better than 1.6, and if the bugs are similar to what I found in >> xorp.ct, I >> might be able to help fix them. >> >>> Dont forget this is a 486 VIA fanless processor that I must compile on. >>> It takes a long time to try anything. >> >> Hopefully we can duplicate your OS image on faster hardware to develop >> there... >> >> Thanks, >> Ben >> -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Thu May 6 13:34:30 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 7 May 2010 02:04:30 +0530 (IST) Subject: [Xorp-users] Redistributing the system kernel route table into OSPF Message-ID: <152988.6766.qm@web94803.mail.in2.yahoo.com> Hello, I have configured Xorp OSPF on my system.I want the static routes added with ip route add command(from terminal)to be redistributed(advertised) using OSPF protocol of Xorp.I have gone through a mail in xorp-users archive with similiar doubt. http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-April/001185.html Is the solution proposed in the above link is still applicable for xorp-1.6.(current version).I am talking about the patch.Is it applicable for xorp-1.6 cvs files. Thanks in advance.. T.Raga Naresh Kumar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100507/c00808e3/attachment.html From greearb at candelatech.com Thu May 6 13:58:38 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 13:58:38 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <152988.6766.qm@web94803.mail.in2.yahoo.com> References: <152988.6766.qm@web94803.mail.in2.yahoo.com> Message-ID: <4BE32D7E.1030000@candelatech.com> On 05/06/2010 01:34 PM, naresh raga wrote: > Hello, > I have configured Xorp OSPF on my system.I want the static routes added > with ip route add command(from terminal)to be redistributed(advertised) > using OSPF protocol of Xorp.I have gone through a mail in xorp-users > archive with similiar doubt. > > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-April/001185.html > > Is the solution proposed in the above link is still applicable for > xorp-1.6.(current version).I am talking about the patch.Is it applicable > for xorp-1.6 cvs files. The patch isn't in upstream SVN, but probably it would apply without too much trouble. Likely to 1.6 as well. Looks like a neat trick..think I'll add it to xorp.ct too..but might be a day or two. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From peirce at maine.edu Thu May 6 17:51:09 2010 From: peirce at maine.edu (Garry Peirce) Date: Thu, 6 May 2010 20:51:09 -0400 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <4BE32D7E.1030000@candelatech.com> References: <152988.6766.qm@web94803.mail.in2.yahoo.com> <4BE32D7E.1030000@candelatech.com> Message-ID: <048501caed7f$6215b620$26412260$@edu> I've run into this same issue in the past, wanting to be able to see kernel known routes from other sources and then be available for redistribution within XORP. Although the fibtomrib workaround may work, I'm just wondering if this is the 'right' way to do so ultimately as the notes state that other changes must be made to the patch to redistribute the routes to protocols other than OSPF. Cannot the same underlying process be used within the fibtomrib module be used to grab the kernel known unicast routes? > -----Original Message----- > From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] > On Behalf Of Ben Greear > Sent: Thursday, May 06, 2010 4:59 PM > To: naresh raga > Cc: xorp-users at xorp.org > Subject: Re: [Xorp-users] Redistributing the system kernel route table > into OSPF > > On 05/06/2010 01:34 PM, naresh raga wrote: > > Hello, > > I have configured Xorp OSPF on my system.I want the static routes > added > > with ip route add command(from terminal)to be > redistributed(advertised) > > using OSPF protocol of Xorp.I have gone through a mail in xorp-users > > archive with similiar doubt. > > > > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006- > April/001185.html > > > > Is the solution proposed in the above link is still applicable for > > xorp-1.6.(current version).I am talking about the patch.Is it > applicable > > for xorp-1.6 cvs files. > > The patch isn't in upstream SVN, but probably it would apply without > too much trouble. Likely to 1.6 as well. > > Looks like a neat trick..think I'll add it to xorp.ct too..but might be > a day or two. > > Thanks, > Ben > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Thu May 6 19:45:11 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 19:45:11 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <048501caed7f$6215b620$26412260$@edu> References: <152988.6766.qm@web94803.mail.in2.yahoo.com> <4BE32D7E.1030000@candelatech.com> <048501caed7f$6215b620$26412260$@edu> Message-ID: <4BE37EB7.9070004@candelatech.com> On 05/06/2010 05:51 PM, Garry Peirce wrote: > I've run into this same issue in the past, wanting to be able to see kernel > known routes from other sources and then be available for redistribution > within XORP. Although the fibtomrib workaround may work, I'm just wondering > if this is the 'right' way to do so ultimately as the notes state that other > changes must be made to the patch to redistribute the routes to protocols > other than OSPF. > > Cannot the same underlying process be used within the fibtomrib module be > used to grab the kernel known unicast routes? The patch changes looked like additions to the policy logic and some small patches to each protocol to relax the checks on what it would accept. I'm not sure if it's the right way, but it didn't look too intrusive. I haven't looked at the code in question in detail yet, however. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu May 6 23:00:25 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 06 May 2010 23:00:25 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <4BE32D7E.1030000@candelatech.com> References: <152988.6766.qm@web94803.mail.in2.yahoo.com> <4BE32D7E.1030000@candelatech.com> Message-ID: <4BE3AC79.4000904@candelatech.com> On 05/06/2010 01:58 PM, Ben Greear wrote: > On 05/06/2010 01:34 PM, naresh raga wrote: >> Hello, >> I have configured Xorp OSPF on my system.I want the static routes added >> with ip route add command(from terminal)to be redistributed(advertised) >> using OSPF protocol of Xorp.I have gone through a mail in xorp-users >> archive with similiar doubt. >> >> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-April/001185.html >> >> Is the solution proposed in the above link is still applicable for >> xorp-1.6.(current version).I am talking about the patch.Is it applicable >> for xorp-1.6 cvs files. > > The patch isn't in upstream SVN, but probably it would apply without > too much trouble. Likely to 1.6 as well. > > Looks like a neat trick..think I'll add it to xorp.ct too..but might be > a day or two. I added it to xorp.ct. Passes 'scons check', but I didn't actually try the export statement yet, so not sure if it works fully. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri May 7 13:25:08 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 07 May 2010 13:25:08 -0700 Subject: [Xorp-users] Anyone used bgp with ipv6 lately? Message-ID: <4BE47724.1080707@candelatech.com> I'm having all sorts of issues trying to get bgp working with ipv6. Has anyone successfully tried this with 1.6 onwards? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sat May 8 09:31:15 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 08 May 2010 09:31:15 -0700 Subject: [Xorp-users] [Xorp-hackers] Anyone used bgp with ipv6 lately? In-Reply-To: <4BE47724.1080707@candelatech.com> References: <4BE47724.1080707@candelatech.com> Message-ID: <4BE591D3.5010503@candelatech.com> On 05/07/2010 01:25 PM, Ben Greear wrote: > I'm having all sorts of issues trying to get bgp working with ipv6. > > Has anyone successfully tried this with 1.6 onwards? To follow up...I had forgotten to set the ipv6 nexthop, and that got my system in an endless loop of adding and deleting routes (which caused show-routes to crash, which slowed me down for a bit too.) I fixed the show-routes bug in xorp.ct, and opened a bug to track the next-hop6 issue. Once I set the next-hop6 for the peer, things worked fine. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Sat May 8 13:34:40 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Sun, 9 May 2010 02:04:40 +0530 (IST) Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <4BE3AC79.4000904@candelatech.com> Message-ID: <885924.44177.qm@web94801.mail.in2.yahoo.com> >I added it to xorp.ct.???Passes 'scons check', but I didn't actually try >the export statement yet, so not sure if it works fully. Hello Ben, ?? I will make a try and I will post the results here.I am trying to checkout your repository. I am running $git clone git://dmz1.candelatech.com/xorp.ct ???? on my terminal.It is giving an error: dmz1.candelatech.com[0: 70.89.124.250]: errno=Connection refused fatal: unable to connect a socket (Connection refused) What could be the problem? But before that,I have already tried on Quagga which has the option for redistribution of kernel routes into OSPF.I am facing a problem (regarding multicast groups) here which I will post as separate query in the xorp-users group now. Thank you, T.Raga Naresh Kumar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100509/5ab139a0/attachment.html From greearb at candelatech.com Sat May 8 13:44:51 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 08 May 2010 13:44:51 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <885924.44177.qm@web94801.mail.in2.yahoo.com> References: <885924.44177.qm@web94801.mail.in2.yahoo.com> Message-ID: <4BE5CD43.708@candelatech.com> On 05/08/2010 01:34 PM, naresh raga wrote: > >I added it to xorp.ct. Passes 'scons check', but I didn't actually try > >the export statement yet, so not sure if it works fully. > > Hello Ben, > I will make a try and I will post the results here.I am trying to > checkout your repository. > I am running > $git clone git://dmz1.candelatech.com/xorp.ct > on my terminal.It is giving an error: > dmz1.candelatech.com[0: 70.89.124.250]: errno=Connection refused > fatal: unable to connect a socket (Connection refused) > > What could be the problem? It seems to be working for me, and I don't see any errors (or attempts) in the logs. Please let me know what IP you are connecting from. Can you ping dmz1.candelatech.com and/or hit it's web page (it's just the standard Fedora greeting page...but it should at least load). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Sat May 8 14:04:20 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Sun, 9 May 2010 02:34:20 +0530 (IST) Subject: [Xorp-users] How to add/join a router to a specific multicast address in Xorp. In-Reply-To: <4BE3AC79.4000904@candelatech.com> Message-ID: <524069.56801.qm@web94805.mail.in2.yahoo.com> Hello, I am working on Xorp.Actually I have connected my Xorp router (PC2)to another system running Quagga routing suite(PC1).On both routing suites i.e. XORP and Quagga ,OSPF has been configured. PC1----PC2 Quagga(PC1)is sending OSPF Hello packets destined to 224.0.0.5.Xorp(PC2) is also sending OSPF Hello packets to 224.0.0.5.Both systems are receiving other systems' Hello packets.But there is no initiation of Database Description ,Link State request/update packets. I am thinking the problem is:PC2(Xorp) has not been joined into the multicast group 224.0.0.5.So Hello packets are not accepted by PC2(sent by PC1),even though PC2 is receiving them.Is this the right reason(problem) for the above said situation? For this I have configured IGMP in my protocols(Xorp configuration).But the problem I am facing is how can I add/join Xorp router into the specific multicast group 224.0.0.5,so that my PC2 can accept packets destined to 224.0.0.5. Any help would be really grateful... Thank you, T.Raga Naresh Kumar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100509/49c8a572/attachment.html From greearb at candelatech.com Sat May 8 14:57:42 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 08 May 2010 14:57:42 -0700 Subject: [Xorp-users] How to add/join a router to a specific multicast address in Xorp. In-Reply-To: <524069.56801.qm@web94805.mail.in2.yahoo.com> References: <524069.56801.qm@web94805.mail.in2.yahoo.com> Message-ID: <4BE5DE56.6040607@candelatech.com> On 05/08/2010 02:04 PM, naresh raga wrote: > Hello, > I am working on Xorp.Actually I have connected my Xorp router (PC2)to > another system running Quagga routing suite(PC1).On both routing suites > i.e. XORP and Quagga ,OSPF has been configured. > PC1----PC2 > Quagga(PC1)is sending OSPF Hello packets destined to 224.0.0.5.Xorp(PC2) > is also sending OSPF Hello packets to 224.0.0.5.Both systems are > receiving other systems' Hello packets.But there is no initiation of > Database Description ,Link State request/update packets. > > I am thinking the problem is:PC2(Xorp) has not been joined into the > multicast group 224.0.0.5.So Hello packets are not accepted by PC2(sent > by PC1),even though PC2 is receiving them.Is this the right > reason(problem) for the above said situation? > > For this I have configured IGMP in my protocols(Xorp configuration).But > the problem I am facing is how can I add/join Xorp router into the > specific multicast group 224.0.0.5,so that my PC2 can accept packets > destined to 224.0.0.5. > > Any help would be really grateful... Maybe post your xorp log file and config file? Thanks, Ben > > Thank you, > T.Raga Naresh Kumar. > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Sat May 8 16:50:56 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Sun, 9 May 2010 05:20:56 +0530 (IST) Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <4BE5CD43.708@candelatech.com> Message-ID: <896230.98295.qm@web94802.mail.in2.yahoo.com> Hi Ben, ?I was unable to checkout xorp.ct. But I have applied patch for xorp-1.6 as in http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-April/001185.html It's working.I am adding routes to the kernel using ip route add command and they are being advertised by OSPF. Thanks to Pavlin for the patch. Thank you Ben, T.Raga Naresh Kumar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100509/7802d884/attachment.html From naresh_raga at yahoo.co.in Sat May 8 16:59:40 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Sun, 9 May 2010 05:29:40 +0530 (IST) Subject: [Xorp-users] How to add/join a router to a specific multicast address in Xorp. Message-ID: <393421.52360.qm@web94805.mail.in2.yahoo.com> >Maybe post your xorp log file and config file? >Thanks, >Ben Here is the config file of PC2 having Xorp connected to PC1(Quagga). PC1(eth0)---------(eth2)PC2 PC1(eth0) address is 10.64.25.10/16 interfaces { ??? interface eth2 { ??? vif eth2 { ??? ??? address 10.64.25.77{ ??? ??? prefix-length: 16 ??? ??? } ??? } ??? } ? } fea { ??? unicast-forwarding4 { ??? disable: false ??? } } plumbing { ? mfea4 { ??? disable: false ??? interface eth2 { ????? vif eth2 { ??????? disable:false ????? } ??? } ??? interface register_vif { ????? vif register_vif { ??????? disable: false ????? } ??? } ? ? } } protocols { ??? ospf4 { ??? router-id: 10.64.25.77 ???????? area 0.0.0.0 { ??????????? interface eth2 { ??? ??? ???????? link-type:"p2m" ??? ????????????????????? vif eth2 { ????????????????? ??? ?address 10.64.25.77 { ???????????????????????? interface-cost: 10 ????????????????????????????? neighbor 10.64.25.10{ ?????????????????????????????????? router-id:10.64.25.10 ???????????????????????????????????????? } ????????????????????????????????? } ??? ??? ??? ?? } ????????????????????? } ???????????????? } ??????????? } ? igmp { ??? interface eth2 { ????? vif eth2 { ????????? version: 3 ??????????? } ??????? } ???? } } I have also tried in this fashion.Both PC1 and PC2 with Xorp.Then there is successful exchange of Link State update/request packets.The config file of PC1 is: interfaces { ??? interface eth0 { ??? vif eth0 { ??? ??? address 10.64.25.10 { ??? ??? prefix-length: 16 ??? ??? } ??? } ??? } ? } fea { ??? unicast-forwarding4 { ??? disable: false ??? } } protocols { ?ospf4 { ????? router-id: 10.64.25.10 ?? area 0.0.0.0 { ??? ??? interface eth0 { ??? ??? ?link-type:"p2m" ??? ??? vif eth0 { ??? ??? ??? address 10.64.25.10 { ??????????????????????? interface-cost: 11 ???????????????????????? neighbor 10.64.25.77 { ??? ??? ??? ??? ?? router-id: 10.64.25.77 ?????????????????????????????????????????? } ???????????????????????????????????? }? ??? ??? ??? ????? } ??????????????????????? }? ????????????????? } ??? } }?? ??? ? I also experimented a situation when both PC1 and PC2 had Xorp and their config files don't have neighbor section.At this time,both PC1 and PC2 are generating Hello packets with destination 224.0.0.5.In this case,there is no exchange of Link State Update/Request packets. My conclusion is when there is neighbor section(as shown in above config files),Hello packets are destined to unicast address(neighbor's address) and hence the other PC is accepting it.But when there is no neighbor section,Hello packets are destined to multicast group(224.0.0.5). In case of Quagga also,it is generating Hello packets destined to 224.0.0.5.So,now I need a solution for adding PC2? to the group 224.0.0.5 or a solution such that Quagga can generate? Hello packets to unicast address(neighbor's address 10.64.25.77). Thanks in advance, T.Raga Naresh Kumar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100509/00289c2f/attachment-0001.html From greearb at candelatech.com Mon May 10 15:17:05 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 10 May 2010 15:17:05 -0700 Subject: [Xorp-users] How to add/join a router to a specific multicast address in Xorp. In-Reply-To: <393421.52360.qm@web94805.mail.in2.yahoo.com> References: <393421.52360.qm@web94805.mail.in2.yahoo.com> Message-ID: <4BE885E1.60706@candelatech.com> On 05/08/2010 04:59 PM, naresh raga wrote: > >Maybe post your xorp log file and config file? > > >Thanks, > >Ben > Here is the config file of PC2 having Xorp connected to PC1(Quagga). > > PC1(eth0)---------(eth2)PC2 > PC1(eth0) address is 10.64.25.10/16 It looks like you are configuring multicast routing. You don't need to do that just to get OSPF to talk multicast packets to other OSPF routers, as far as I know. Are your OSPF routers directly connected by a LAN? Why are you using 'p2m' for the link type? From reading through the xorp manual briefly, it seems that if you are using p2m type connection, you do need to specify the neighbor. Probably OSPF doesn't open a multicast listening socket for this type of interface. I don't know if that is correct behaviour or not. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon May 10 15:18:07 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 10 May 2010 15:18:07 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE30B8B.9090608@wires3.net> References: <4BE1D0F1.5000508@wires3.net> <4BE304A6.1070506@candelatech.com> <4BE30755.6070505@wires3.net> <4BE30A70.7050402@candelatech.com> <4BE30B8B.9090608@wires3.net> Message-ID: <4BE8861F.5060400@candelatech.com> On 05/06/2010 11:33 AM, AWalton wrote: > Actually that's just what I was thinking of doing. I have a dual core > machine that is what I am using right now. I just compiled 1.6 on it in > under 15mins. So I was going to try lifting the drive out of the VIA > board. Its actually a 2Gb flash IDE disc and loading it up on the dual > core machine. Did you have any luck with this? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue May 11 09:03:08 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 11 May 2010 09:03:08 -0700 Subject: [Xorp-users] What shall we do before releasing xorp 1.7? Message-ID: <4BE97FBC.2050809@candelatech.com> I'm hoping to get a concrete list of things that we need to finish before calling xorp 1.7 done and releasing it. I'm asking any and all to speak up now with your wish list. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Tue May 11 09:18:09 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Tue, 11 May 2010 17:18:09 +0100 Subject: [Xorp-users] [Xorp-hackers] What shall we do before releasing xorp 1.7? In-Reply-To: <4BE97FBC.2050809@candelatech.com> References: <4BE97FBC.2050809@candelatech.com> Message-ID: My list is clear, I don't want to delay 1.7 for the click work. Adam On 11 May 2010 17:03, Ben Greear wrote: > > I'm hoping to get a concrete list of things that we need to finish before calling > xorp 1.7 done and releasing it. > > I'm asking any and all to speak up now with your wish list. > > 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 peirce at maine.edu Tue May 11 10:18:02 2010 From: peirce at maine.edu (Garry Peirce) Date: Tue, 11 May 2010 13:18:02 -0400 Subject: [Xorp-users] What shall we do before releasing xorp 1.7? In-Reply-To: <4BE97FBC.2050809@candelatech.com> References: <4BE97FBC.2050809@candelatech.com> Message-ID: <087401caf12d$e928ada0$bb7a08e0$@edu> Do I recall correctly that 1.7 will include some of xorp.ct work with 1.8 to include all of it? Any insight on what features/fixes will still separate xorp.ct and 1.7? > -----Original Message----- > From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] > On Behalf Of Ben Greear > Sent: Tuesday, May 11, 2010 12:03 PM > To: xorp; xorp-users at xorp.org > Subject: [Xorp-users] What shall we do before releasing xorp 1.7? > > > I'm hoping to get a concrete list of things that we need to finish > before calling > xorp 1.7 done and releasing it. > > I'm asking any and all to speak up now with your wish list. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Tue May 11 10:26:17 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 11 May 2010 10:26:17 -0700 Subject: [Xorp-users] What shall we do before releasing xorp 1.7? In-Reply-To: <087401caf12d$e928ada0$bb7a08e0$@edu> References: <4BE97FBC.2050809@candelatech.com> <087401caf12d$e928ada0$bb7a08e0$@edu> Message-ID: <4BE99339.3020405@candelatech.com> On 05/11/2010 10:18 AM, Garry Peirce wrote: > Do I recall correctly that 1.7 will include some of xorp.ct work with 1.8 to > include all of it? > Any insight on what features/fixes will still separate xorp.ct and 1.7? I do not have any current plans to put any more of xorp.ct into 1.7. I have already previously submitted some patches to 1.7, but not the bulk of xorp.ct. Basically, my view is that 1.7 will be similar to 1.6 with a few bug fixes and a conversion to scons (and with some boost template tweaks thrown in). 1.8 will include all of xorp.ct if I have my way, and I would expect to start working on a 1.8 release candidate soon after I merge in xorp.ct. If I can merge all of xorp.ct into upstream xorp in the 1.8 timeframe, then I'll keep xorp.ct as a staging area for my development work, but would expect to keep it and upstream very close in sync. Thanks, Ben > > > >> -----Original Message----- >> From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] >> On Behalf Of Ben Greear >> Sent: Tuesday, May 11, 2010 12:03 PM >> To: xorp; xorp-users at xorp.org >> Subject: [Xorp-users] What shall we do before releasing xorp 1.7? >> >> >> I'm hoping to get a concrete list of things that we need to finish >> before calling >> xorp 1.7 done and releasing it. >> >> I'm asking any and all to speak up now with your wish list. >> >> Thanks, >> Ben >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Ben Greear Candela Technologies Inc http://www.candelatech.com From Tom.McMillan at l-3com.com Tue May 11 12:18:32 2010 From: Tom.McMillan at l-3com.com (Tom.McMillan at l-3com.com) Date: Tue, 11 May 2010 12:18:32 -0700 Subject: [Xorp-users] PIM-SM: disabling Join Suppession? Message-ID: This question concerns PIM-SM routing. Is there any way to disable join suppression in Xorp? If there's any mention of it in the User's Guide, I've yet to find it. >From rfc4601: o OptionType 2: LAN Prune Delay 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Propagation_Delay | Override_Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LAN Prune Delay option is used to tune the prune propagation delay on multi-access LANs. The T bit specifies the ability of the sending router to disable joins suppression. I'm connecting to several Juniper routers, which do allow one to enable or disable Join Suppression (reset-tracking-bit). During testing, we'd like to disable this behavior on all of our XORP routers, too. I'm currently building and using v1.7 ~ Tom McMillan, L3 Linkabit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100511/9df32550/attachment.html From M.Handley at cs.ucl.ac.uk Tue May 11 13:57:12 2010 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Tue, 11 May 2010 21:57:12 +0100 Subject: [Xorp-users] [Xorp-hackers] What shall we do before releasing xorp 1.7? In-Reply-To: <4BE97FBC.2050809@candelatech.com> References: <4BE97FBC.2050809@candelatech.com> Message-ID: I'm not worried about adding any features - my main wish list item is that we get back to similar test coverage to previous releases, so we're confident we know about any regressions that happened. - Mark On 11 May 2010 17:03, Ben Greear wrote: > > I'm hoping to get a concrete list of things that we need to finish before calling > xorp 1.7 done and releasing it. > > I'm asking any and all to speak up now with your wish list. > > 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 Tue May 11 14:02:47 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 11 May 2010 14:02:47 -0700 Subject: [Xorp-users] [Xorp-hackers] What shall we do before releasing xorp 1.7? In-Reply-To: References: <4BE97FBC.2050809@candelatech.com> Message-ID: <4BE9C5F7.9020005@candelatech.com> On 05/11/2010 01:57 PM, Mark Handley wrote: > I'm not worried about adding any features - my main wish list item is > that we get back to similar test coverage to previous releases, so > we're confident we know about any regressions that happened. So do you want me to backport the bgp test harness fixups and bgp code to fix the bugs I found before we release 1.7? I don't have a good way to test actual functionality of such backported code aside from the test harness, though the risk isn't too bad. Backporting code isn't the most fun thing to do in the world, but probably not too difficult, so I'll do it if you want. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From M.Handley at cs.ucl.ac.uk Tue May 11 14:51:32 2010 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Tue, 11 May 2010 22:51:32 +0100 Subject: [Xorp-users] [Xorp-hackers] What shall we do before releasing xorp 1.7? In-Reply-To: <4BE9C5F7.9020005@candelatech.com> References: <4BE97FBC.2050809@candelatech.com> <4BE9C5F7.9020005@candelatech.com> Message-ID: On 11 May 2010 22:02, Ben Greear wrote: > On 05/11/2010 01:57 PM, Mark Handley wrote: >> >> I'm not worried about adding any features - my main wish list item is >> that we get back to similar test coverage to previous releases, so >> we're confident we know about any regressions that happened. > > So do you want me to backport the bgp test harness fixups and > bgp code to fix the bugs I found before we release > 1.7? ?I don't have a good way to test actual functionality of such > backported code aside from the test harness, though the risk isn't > too bad. > > Backporting code isn't the most fun thing to do in the world, > but probably not too difficult, so I'll do it if you want. If you can do so, that would be ideal. Even though this is very much an interim release, we do need coverage to ensure it's of adequate quality and to see if anything else needs fixing. Buildbot certainly indicates your tree has much better test coverage at the moment than the sourceforge tree. - Mark From greearb at candelatech.com Tue May 11 14:53:18 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 11 May 2010 14:53:18 -0700 Subject: [Xorp-users] [Xorp-hackers] What shall we do before releasing xorp 1.7? In-Reply-To: References: <4BE97FBC.2050809@candelatech.com> <4BE9C5F7.9020005@candelatech.com> Message-ID: <4BE9D1CE.1010901@candelatech.com> On 05/11/2010 02:51 PM, Mark Handley wrote: > On 11 May 2010 22:02, Ben Greear wrote: >> On 05/11/2010 01:57 PM, Mark Handley wrote: >>> >>> I'm not worried about adding any features - my main wish list item is >>> that we get back to similar test coverage to previous releases, so >>> we're confident we know about any regressions that happened. >> >> So do you want me to backport the bgp test harness fixups and >> bgp code to fix the bugs I found before we release >> 1.7? I don't have a good way to test actual functionality of such >> backported code aside from the test harness, though the risk isn't >> too bad. >> >> Backporting code isn't the most fun thing to do in the world, >> but probably not too difficult, so I'll do it if you want. > > If you can do so, that would be ideal. Even though this is very much > an interim release, we do need coverage to ensure it's of adequate > quality and to see if anything else needs fixing. Buildbot certainly > indicates your tree has much better test coverage at the moment than > the sourceforge tree. Ok, I'll get on that. Shouldn't take too long. Thanks, Ben > > - Mark -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed May 12 09:36:28 2010 From: greearb at candelatech.com (Ben Greear) Date: Wed, 12 May 2010 09:36:28 -0700 Subject: [Xorp-users] [Xorp-hackers] What shall we do before releasing xorp 1.7? In-Reply-To: References: <4BE97FBC.2050809@candelatech.com> <4BE9C5F7.9020005@candelatech.com> Message-ID: <4BEAD90C.2080101@candelatech.com> On 05/11/2010 02:51 PM, Mark Handley wrote: > On 11 May 2010 22:02, Ben Greear wrote: >> On 05/11/2010 01:57 PM, Mark Handley wrote: >>> >>> I'm not worried about adding any features - my main wish list item is >>> that we get back to similar test coverage to previous releases, so >>> we're confident we know about any regressions that happened. >> >> So do you want me to backport the bgp test harness fixups and >> bgp code to fix the bugs I found before we release >> 1.7? I don't have a good way to test actual functionality of such >> backported code aside from the test harness, though the risk isn't >> too bad. >> >> Backporting code isn't the most fun thing to do in the world, >> but probably not too difficult, so I'll do it if you want. > > If you can do so, that would be ideal. Even though this is very much > an interim release, we do need coverage to ensure it's of adequate > quality and to see if anything else needs fixing. Buildbot certainly > indicates your tree has much better test coverage at the moment than > the sourceforge tree. NOTE: This is a resend...first one didn't make it through the list because the attachment was too big. You can now find the patch at: http://www.candelatech.com/~greearb/misc/patches/xorp_bgp_harness_backport.patch 'scons check' passes as good as it does in xorp.ct, so I'm pushing this. If there are any suggestions for improvement I'll be happy to consider them. This patch: * Makes bgp compile with shared libraries. * Fixes up some utils and libxipc stuff to compile for the bgp harness. * Fixes bgp harness logic to work with new path layout. * Runs xorp bgp harness logic when 'scons check' is requested. * Fixes some BGP asserts I found in xorp.ct testing. Thanks, Ben > > - Mark -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue May 11 16:19:46 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 11 May 2010 16:19:46 -0700 Subject: [Xorp-users] [Xorp-hackers] What shall we do before releasing xorp 1.7? In-Reply-To: References: <4BE97FBC.2050809@candelatech.com> <4BE9C5F7.9020005@candelatech.com> Message-ID: <4BE9E612.4020704@candelatech.com> On 05/11/2010 02:51 PM, Mark Handley wrote: > On 11 May 2010 22:02, Ben Greear wrote: >> On 05/11/2010 01:57 PM, Mark Handley wrote: >>> >>> I'm not worried about adding any features - my main wish list item is >>> that we get back to similar test coverage to previous releases, so >>> we're confident we know about any regressions that happened. >> >> So do you want me to backport the bgp test harness fixups and >> bgp code to fix the bugs I found before we release >> 1.7? I don't have a good way to test actual functionality of such >> backported code aside from the test harness, though the risk isn't >> too bad. >> >> Backporting code isn't the most fun thing to do in the world, >> but probably not too difficult, so I'll do it if you want. > > If you can do so, that would be ideal. Even though this is very much > an interim release, we do need coverage to ensure it's of adequate > quality and to see if anything else needs fixing. Buildbot certainly > indicates your tree has much better test coverage at the moment than > the sourceforge tree. The 'scons check' hasn't completed..but this is at least close. If 'scons check' passes..any objections to this patch going into 1.7? This patch: * Makes bgp compile with shared libraries. * Fixes up some utils and libxipc stuff to compile for the bgp harness. * Fixes bgp harness logic to work with new path layout. * Runs xorp bgp harness logic when 'scons check' is requested. * Fixes some BGP asserts I found in xorp.ct testing. Thanks, Ben > > - Mark -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp_bgp_harness_backport.patch Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100511/985fc5e2/attachment-0001.ksh From awalton at wires3.net Thu May 13 12:51:08 2010 From: awalton at wires3.net (Aidan) Date: Thu, 13 May 2010 20:51:08 +0100 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BE8861F.5060400@candelatech.com> References: <4BE1D0F1.5000508@wires3.net> <4BE304A6.1070506@candelatech.com> <4BE30755.6070505@wires3.net> <4BE30A70.7050402@candelatech.com> <4BE30B8B.9090608@wires3.net> <4BE8861F.5060400@candelatech.com> Message-ID: <4BEC582C.3000504@wires3.net> Sorry Ben Work has been getting in the way time wise... I have been struggling actually, sorry to say its all rather basic stuff. I'm no expert like you guys and so even the most basic tasks can burn hours. I have been trying to get a dd generated image of the actual live router up on running on a partition on my dual core machine, so that I could compile on this. I finally managed this but the strangest thing.... I cant login? Weird. I boot of the partition containing the image and sure enough the kernel loads the system comes up, I watch the drivers load and all the associated errors of course as the hardware set-up is totally different, but finally when I get to a login prompt. I cant login, As soon as I enter 'root' as a username and hit return, I get 5 repeated login failures and I'm back where I started being asked for a username. I don't even get prompted for a password. So I can not even login to the system to even try and compile. So that was the weekend gone. Anyway I have been reading your comments regarding xorp.ct. I think it makes sense if I try this. The question I have now is just how much do I care which kernel is running on the machine I use to compile xorp? I think you mentioned something about Xorp not needing the kernel headers? So if I compile Xorp on a Lenny distribution (2.6.26) will I be able to take the binaries and run them on the system with 2.6.18? What dependencies are there on the final resultant binaries and the system on which they are intended to run? Whichever way you advise I think I will attempt to compile xorp.ct as you suggested. There is definitely a problem with xorp1.4 as I was forced to downgrade the code running on the routerOS board and as soon as I did this Xorp stopped crashing so it's repeatable. I have no doubt you would all like to know what is happening. Weekend is almost upon us so time again soon, just need to fly back into the UK first. I'm stuck in Athens at the moment. Thanks Aidan On 10/05/2010 23:18, Ben Greear wrote: > On 05/06/2010 11:33 AM, AWalton wrote: >> Actually that's just what I was thinking of doing. I have a dual core >> machine that is what I am using right now. I just compiled 1.6 on it in >> under 15mins. So I was going to try lifting the drive out of the VIA >> board. Its actually a 2Gb flash IDE disc and loading it up on the dual >> core machine. > > Did you have any luck with this? > > Thanks, > Ben > From greearb at candelatech.com Thu May 13 13:48:37 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 13 May 2010 13:48:37 -0700 Subject: [Xorp-users] xorp1.6 fails to run on Debian Etch 2.6.18-5-486 In-Reply-To: <4BEC582C.3000504@wires3.net> References: <4BE1D0F1.5000508@wires3.net> <4BE304A6.1070506@candelatech.com> <4BE30755.6070505@wires3.net> <4BE30A70.7050402@candelatech.com> <4BE30B8B.9090608@wires3.net> <4BE8861F.5060400@candelatech.com> <4BEC582C.3000504@wires3.net> Message-ID: <4BEC65A5.9010809@candelatech.com> On 05/13/2010 12:51 PM, Aidan wrote: > Sorry Ben > Work has been getting in the way time wise... I have been struggling > actually, sorry to say its all rather basic stuff. I'm no expert like > you guys and so even the most basic tasks can burn hours. I have been > trying to get a dd generated image of the actual live router up on > running on a partition on my dual core machine, so that I could compile > on this. I finally managed this but the strangest thing.... I cant > login? Weird. I boot of the partition containing the image and sure > enough the kernel loads the system comes up, I watch the drivers load > and all the associated errors of course as the hardware set-up is > totally different, but finally when I get to a login prompt. I cant login, > > As soon as I enter 'root' as a username and hit return, I get 5 repeated > login failures and I'm back where I started being asked for a username. > I don't even get prompted for a password. So I can not even login to the > system to even try and compile. So that was the weekend gone. > > Anyway I have been reading your comments regarding xorp.ct. I think it > makes sense if I try this. The question I have now is just how much do I > care which kernel is running on the machine I use to compile xorp? I > think you mentioned something about Xorp not needing the kernel headers? > > So if I compile Xorp on a Lenny distribution (2.6.26) will I be able to > take the binaries and run them on the system with 2.6.18? What > dependencies are there on the final resultant binaries and the system on > which they are intended to run? It should work. If it doesn't, likely we can fix it easily enough. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jmitchell at ll.mit.edu Wed May 19 10:57:19 2010 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Wed, 19 May 2010 13:57:19 -0400 Subject: [Xorp-users] Problem adding routes to custom devices Message-ID: <4BF4267F.6070706@ll.mit.edu> Hello Xorpies (Xorpers?), I'm having a problem that I have narrowed down to a bug either in XORP or in some custom software we have. Our custom software creates a special kind of networking device, similar in concept to a tun device. (The device allows us to do things like packet delay/jitter/etc. mangling, while being in-kernel for fast speeds.) I have two configurations for XORP that are identical with the one difference being the device name. In the working configuration the device is named eth0.701; in the non-working configuration the device is named something similar to abcd0. What happens is that when using this device, my defined static routes fail to be added to the Linux routing table. It's a simple configuration: static { disable: false route 192.168.0.0/16 { next-hop: 192.168.71.1 metric: 1 } mrib-route 192.168.0.0/16 { next-hop: 192.168.71.1 metric: 1 } } XORP does correctly add the configured IP address to the interface, and I can ping from the interface to a neighbor; it is only the static route that seems to be misbehaving. So either there is some problem in XORP keeping it from adding these static routes (but I'm not sure how to find out if this is the case) or some problem in the custom software; however, since I can use "ip route" to add the route to the custom software's interface manually, I am guessing this is a XORP issue. N.B.: I'm using Ben Greear's xorp.ct branch. Any help appreciated! Thanks, Jeff From greearb at candelatech.com Wed May 19 11:16:35 2010 From: greearb at candelatech.com (Ben Greear) Date: Wed, 19 May 2010 11:16:35 -0700 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF4267F.6070706@ll.mit.edu> References: <4BF4267F.6070706@ll.mit.edu> Message-ID: <4BF42B03.5070205@candelatech.com> On 05/19/2010 10:57 AM, Jeff Mitchell wrote: > Hello Xorpies (Xorpers?), > > I'm having a problem that I have narrowed down to a bug either in XORP > or in some custom software we have. > > Our custom software creates a special kind of networking device, similar > in concept to a tun device. (The device allows us to do things like > packet delay/jitter/etc. mangling, while being in-kernel for fast speeds.) > > I have two configurations for XORP that are identical with the one > difference being the device name. In the working configuration the > device is named eth0.701; in the non-working configuration the device is > named something similar to abcd0. It could indeed be a bug. You might try poking around in the fea logic, adding debugging statements and such to see if you can figure out what is happening. If you can get a reproducible test case that uses standard linux kernels and no special software harness, I'll see if I notice anything. Also, any errors of note in the xorp logs? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jmitchell at ll.mit.edu Wed May 19 12:47:00 2010 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Wed, 19 May 2010 15:47:00 -0400 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF42B03.5070205@candelatech.com> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> Message-ID: <4BF44034.1020602@ll.mit.edu> On 05/19/2010 02:16 PM, Ben Greear wrote: > It could indeed be a bug. You might try poking around in > the fea logic, adding debugging statements and such to see > if you can figure out what is happening. > > If you can get a reproducible test case that uses standard > linux kernels and no special software harness, I'll see > if I notice anything. I can try, creating a dummy or tun device and see if that happens. > Also, any errors of note in the xorp logs? Man, I'm an idiot. I expected to find ways to view xorp debugging information from within xorpsh; I actually looked through the user manual trying to find out how to view the debugging that I was turning on. Until you said this I didn't realize that it was probably in /var/log. I'll have to look at it and get back to you. Thanks, Jeff From jmitchell at ll.mit.edu Wed May 19 14:38:22 2010 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Wed, 19 May 2010 17:38:22 -0400 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF444C9.30808@candelatech.com> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> Message-ID: <4BF45A4E.4070301@ll.mit.edu> On 05/19/2010 04:06 PM, Ben Greear wrote: > On 05/19/2010 12:47 PM, Jeff Mitchell wrote: >> On 05/19/2010 02:16 PM, Ben Greear wrote: >>> It could indeed be a bug. You might try poking around in >>> the fea logic, adding debugging statements and such to see >>> if you can figure out what is happening. >>> >>> If you can get a reproducible test case that uses standard >>> linux kernels and no special software harness, I'll see >>> if I notice anything. >> >> I can try, creating a dummy or tun device and see if that happens. >> >>> Also, any errors of note in the xorp logs? >> >> Man, I'm an idiot. I expected to find ways to view xorp debugging >> information from within xorpsh; I actually looked through the user >> manual trying to find out how to view the debugging that I was turning >> on. Until you said this I didn't realize that it was probably in /var/log. >> >> I'll have to look at it and get back to you. > > When starting xorp rtrmgr, you can specify a log file. That's probably > the preferred way to get logs. I don't see anything in the log files of note, grepping for things like the interface name and the route I'm trying to add. Here is "ip route" and "show route table ipv4 unicast final" when it works, with eth0.701: 192.168.71.0/24 dev eth0.701 proto kernel scope link src 192.168.71.11 192.168.81.0/24 dev eth0.801 proto kernel scope link src 192.168.81.1 172.18.8.0/24 dev eth0 proto kernel scope link src 172.18.8.143 169.254.0.0/16 dev eth0 scope link 192.168.0.0/16 via 192.168.71.1 dev eth0.701 proto xorp metric 1 notify default via 172.18.8.1 dev eth0 192.168.0.0/16 [static(1)/1] > to 192.168.71.1 via eth0.701/eth0.701 192.168.71.0/24 [connected(0)/0] > via eth0.701/eth0.701 192.168.81.0/24 [connected(0)/0] > via eth0.801/eth0.801 Here is the same when it doesn't work, with abcd0: 192.168.71.0/24 dev abcd0 proto kernel scope link src 192.168.71.11 192.168.81.0/24 dev eth0.801 proto kernel scope link src 192.168.81.1 172.18.8.0/24 dev eth0 proto kernel scope link src 172.18.8.143 169.254.0.0/16 dev eth0 scope link default via 172.18.8.1 dev eth0 show route table ipv4 unicast final 192.168.81.0/24 [connected(0)/0] > via eth0.801/eth0.801 I have a suspicion as to what may be wrong...here's the relevant output of "ip link": 4: eth0.801 at eth0: mtu 1500 qdisc noqueue link/ether 00:50:56:9e:1f:7f brd ff:ff:ff:ff:ff:ff 6: abcd0: mtu 1500 qdisc pfifo_fast qlen 100 link/void 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00 7: pimreg at NONE: mtu 1472 qdisc noqueue link/pimreg Note the type of "link/void" -- is it possible that XORP refuses to set routes pertaining to this link because of the link type, even though it will give the interface an IP address? If so, is there a way to disable this/fix this/prevent this? Or any other idea what's going wrong? Thanks, Jeff From greearb at candelatech.com Wed May 19 15:04:40 2010 From: greearb at candelatech.com (Ben Greear) Date: Wed, 19 May 2010 15:04:40 -0700 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF45A4E.4070301@ll.mit.edu> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> <4BF45A4E.4070301@ll.mit.edu> Message-ID: <4BF46078.2080000@candelatech.com> On 05/19/2010 02:38 PM, Jeff Mitchell wrote: > On 05/19/2010 04:06 PM, Ben Greear wrote: >> On 05/19/2010 12:47 PM, Jeff Mitchell wrote: >>> On 05/19/2010 02:16 PM, Ben Greear wrote: >>>> It could indeed be a bug. You might try poking around in >>>> the fea logic, adding debugging statements and such to see >>>> if you can figure out what is happening. >>>> >>>> If you can get a reproducible test case that uses standard >>>> linux kernels and no special software harness, I'll see >>>> if I notice anything. >>> >>> I can try, creating a dummy or tun device and see if that happens. >>> >>>> Also, any errors of note in the xorp logs? >>> >>> Man, I'm an idiot. I expected to find ways to view xorp debugging >>> information from within xorpsh; I actually looked through the user >>> manual trying to find out how to view the debugging that I was turning >>> on. Until you said this I didn't realize that it was probably in /var/log. >>> >>> I'll have to look at it and get back to you. >> >> When starting xorp rtrmgr, you can specify a log file. That's probably >> the preferred way to get logs. > > I don't see anything in the log files of note, grepping for things like > the interface name and the route I'm trying to add. > > Here is "ip route" and "show route table ipv4 unicast final" when it > works, with eth0.701: > > 192.168.71.0/24 dev eth0.701 proto kernel scope link src 192.168.71.11 > 192.168.81.0/24 dev eth0.801 proto kernel scope link src 192.168.81.1 > 172.18.8.0/24 dev eth0 proto kernel scope link src 172.18.8.143 > 169.254.0.0/16 dev eth0 scope link > 192.168.0.0/16 via 192.168.71.1 dev eth0.701 proto xorp metric 1 notify > default via 172.18.8.1 dev eth0 > > > 192.168.0.0/16 [static(1)/1] > > to 192.168.71.1 via eth0.701/eth0.701 > 192.168.71.0/24 [connected(0)/0] > > via eth0.701/eth0.701 > 192.168.81.0/24 [connected(0)/0] > > via eth0.801/eth0.801 > > > Here is the same when it doesn't work, with abcd0: > > 192.168.71.0/24 dev abcd0 proto kernel scope link src 192.168.71.11 > 192.168.81.0/24 dev eth0.801 proto kernel scope link src 192.168.81.1 > 172.18.8.0/24 dev eth0 proto kernel scope link src 172.18.8.143 > 169.254.0.0/16 dev eth0 scope link > default via 172.18.8.1 dev eth0 > > > show route table ipv4 unicast final > 192.168.81.0/24 [connected(0)/0] > > via eth0.801/eth0.801 > > > I have a suspicion as to what may be wrong...here's the relevant output > of "ip link": > > 4: eth0.801 at eth0: mtu 1500 qdisc noqueue > link/ether 00:50:56:9e:1f:7f brd ff:ff:ff:ff:ff:ff > 6: abcd0: mtu 1500 qdisc > pfifo_fast qlen 100 > link/void 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd > ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00 > 7: pimreg at NONE: mtu 1472 qdisc noqueue > link/pimreg > > Note the type of "link/void" -- is it possible that XORP refuses to set > routes pertaining to this link because of the link type, even though it > will give the interface an IP address? If so, is there a way to disable > this/fix this/prevent this? Or any other idea what's going wrong? I'd say that's likely. Can you just fix your network driver so that it claims to be Ethernet? That's what other virtual drivers, such as 'veth' do... You might look though the logs in detail, maybe searching for 'static', to see if that module is complaining and not even attempting to set the route through fea. Thanks, Ben > > Thanks, > Jeff > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jmitchell at ll.mit.edu Thu May 20 07:35:26 2010 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Thu, 20 May 2010 10:35:26 -0400 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF46078.2080000@candelatech.com> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> <4BF45A4E.4070301@ll.mit.edu> <4BF46078.2080000@candelatech.com> Message-ID: <4BF548AE.7030203@ll.mit.edu> On 05/19/2010 06:04 PM, Ben Greear wrote: >> I have a suspicion as to what may be wrong...here's the relevant output >> of "ip link": >> >> 4: eth0.801 at eth0: mtu 1500 qdisc noqueue >> link/ether 00:50:56:9e:1f:7f brd ff:ff:ff:ff:ff:ff >> 6: abcd0: mtu 1500 qdisc >> pfifo_fast qlen 100 >> link/void 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd >> ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00 >> 7: pimreg at NONE: mtu 1472 qdisc noqueue >> link/pimreg >> >> Note the type of "link/void" -- is it possible that XORP refuses to set >> routes pertaining to this link because of the link type, even though it >> will give the interface an IP address? If so, is there a way to disable >> this/fix this/prevent this? Or any other idea what's going wrong? > > I'd say that's likely. Can you just fix your network driver so that > it claims to be Ethernet? That's what other virtual drivers, such as 'veth' > do... From what I hear, the answer is "maybe" -- in that they do have that option but it's not working right :-( One thing the guys here told me is that void is a legit link type in the kernel with a configurable link layer address size. The address size above is 128-bit; however from poking around at the XORP source code it seems that it makes assumptions all over the place that the link layer addresses are 48 bit. However, maybe that's not always the case. I still don't know why it successfully sets IP addresses to those interfaces, but won't set a route. I suspect that code handling the interfaces is written and/or behaving differently in different parts of XORP. Does this sound like it could be the culprit, and if it's something that might be able to be fixed/made consistent? If so, could someone point me to where might be a good place to look? > You might look though the logs in detail, maybe searching for 'static', to > see if that module is complaining and not even attempting to set the route > through fea. I actually compared logs from running with a normal interface vs. our custom interface and they were basically identical. I did see this: [ 2010/05/19 17:19:21.86898 INFO xorp:3702 RTRMGR rtrmgr/module_manager.cc:94 execute ] Executing module: static_routes (xorp_static_routes) [ 2010/05/19 17:19:21.98138 WARNING xorp:3702 XrlFinderTarget obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 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. But, they appeared in *both* logs, including using the normal interface where the routes were successfully set. --Jeff From jmitchell at ll.mit.edu Thu May 20 07:51:09 2010 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Thu, 20 May 2010 10:51:09 -0400 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF548AE.7030203@ll.mit.edu> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> <4BF45A4E.4070301@ll.mit.edu> <4BF46078.2080000@candelatech.com> <4BF548AE.7030203@ll.mit.edu> Message-ID: <4BF54C5D.40604@ll.mit.edu> On 05/20/2010 10:35 AM, Jeff Mitchell wrote: > On 05/19/2010 06:04 PM, Ben Greear wrote: >>> I have a suspicion as to what may be wrong...here's the relevant output >>> of "ip link": >>> >>> 4: eth0.801 at eth0: mtu 1500 qdisc noqueue >>> link/ether 00:50:56:9e:1f:7f brd ff:ff:ff:ff:ff:ff >>> 6: abcd0: mtu 1500 qdisc >>> pfifo_fast qlen 100 >>> link/void 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd >>> ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00 >>> 7: pimreg at NONE: mtu 1472 qdisc noqueue >>> link/pimreg >>> >>> Note the type of "link/void" -- is it possible that XORP refuses to set >>> routes pertaining to this link because of the link type, even though it >>> will give the interface an IP address? If so, is there a way to disable >>> this/fix this/prevent this? Or any other idea what's going wrong? >> >> I'd say that's likely. Can you just fix your network driver so that >> it claims to be Ethernet? That's what other virtual drivers, such as 'veth' >> do... > > From what I hear, the answer is "maybe" -- in that they do have that > option but it's not working right :-( > > One thing the guys here told me is that void is a legit link type in the > kernel with a configurable link layer address size. The address size > above is 128-bit; however from poking around at the XORP source code it > seems that it makes assumptions all over the place that the link layer > addresses are 48 bit. > > However, maybe that's not always the case. I still don't know why it > successfully sets IP addresses to those interfaces, but won't set a > route. I suspect that code handling the interfaces is written and/or > behaving differently in different parts of XORP. Looks like I spoke a bit too soon on that point. If I change the address type: 6: abcd0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff then still no dice. It's possible that XORP doesn't like the all-zeros address in this situation -- or the problem lies elsewhere, perhaps in some unsupported call being used when trying to set the routing information? --Jeff From greearb at candelatech.com Thu May 20 09:26:49 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 May 2010 09:26:49 -0700 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF54C5D.40604@ll.mit.edu> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> <4BF45A4E.4070301@ll.mit.edu> <4BF46078.2080000@candelatech.com> <4BF548AE.7030203@ll.mit.edu> <4BF54C5D.40604@ll.mit.edu> Message-ID: <4BF562C9.1020904@candelatech.com> On 05/20/2010 07:51 AM, Jeff Mitchell wrote: > On 05/20/2010 10:35 AM, Jeff Mitchell wrote: >> On 05/19/2010 06:04 PM, Ben Greear wrote: >>>> I have a suspicion as to what may be wrong...here's the relevant output >>>> of "ip link": >>>> >>>> 4: eth0.801 at eth0: mtu 1500 qdisc noqueue >>>> link/ether 00:50:56:9e:1f:7f brd ff:ff:ff:ff:ff:ff >>>> 6: abcd0: mtu 1500 qdisc >>>> pfifo_fast qlen 100 >>>> link/void 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd >>>> ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00 >>>> 7: pimreg at NONE: mtu 1472 qdisc noqueue >>>> link/pimreg >>>> >>>> Note the type of "link/void" -- is it possible that XORP refuses to set >>>> routes pertaining to this link because of the link type, even though it >>>> will give the interface an IP address? If so, is there a way to disable >>>> this/fix this/prevent this? Or any other idea what's going wrong? >>> >>> I'd say that's likely. Can you just fix your network driver so that >>> it claims to be Ethernet? That's what other virtual drivers, such as 'veth' >>> do... >> >> From what I hear, the answer is "maybe" -- in that they do have that >> option but it's not working right :-( >> >> One thing the guys here told me is that void is a legit link type in the >> kernel with a configurable link layer address size. The address size >> above is 128-bit; however from poking around at the XORP source code it >> seems that it makes assumptions all over the place that the link layer >> addresses are 48 bit. >> >> However, maybe that's not always the case. I still don't know why it >> successfully sets IP addresses to those interfaces, but won't set a >> route. I suspect that code handling the interfaces is written and/or >> behaving differently in different parts of XORP. > > Looks like I spoke a bit too soon on that point. If I change the address > type: > > 6: abcd0: mtu 1500 qdisc > pfifo_fast qlen 100 > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff > > then still no dice. It's possible that XORP doesn't like the all-zeros > address in this situation -- or the problem lies elsewhere, perhaps in > some unsupported call being used when trying to set the routing information? There may indeed be issues with > 48 byte 'MAC' addresses, but I'm not sure that would show up in routing table issues. The logic that actually sets such stuff in Linux should be in the netlink related logic. Setting interface logic is in fea/ifconfig/*set_netlink*, and the routing stuff is in fea/fibconfig/*netlink* Some other logic will actually tell fea to add/delete routes, and it's possible the error lies there. I'd add logging to the route setting logic to see what it tries to set. Thanks, Ben > > --Jeff > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu May 20 09:54:58 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 May 2010 09:54:58 -0700 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF548AE.7030203@ll.mit.edu> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> <4BF45A4E.4070301@ll.mit.edu> <4BF46078.2080000@candelatech.com> <4BF548AE.7030203@ll.mit.edu> Message-ID: <4BF56962.8080101@candelatech.com> On 05/20/2010 07:35 AM, Jeff Mitchell wrote: > On 05/19/2010 06:04 PM, Ben Greear wrote: >>> I have a suspicion as to what may be wrong...here's the relevant output >>> of "ip link": >>> >>> 4: eth0.801 at eth0: mtu 1500 qdisc >>> noqueue >>> link/ether 00:50:56:9e:1f:7f brd ff:ff:ff:ff:ff:ff >>> 6: abcd0: mtu 1500 qdisc >>> pfifo_fast qlen 100 >>> link/void 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd >>> ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00 >>> 7: pimreg at NONE: mtu 1472 qdisc noqueue >>> link/pimreg >>> >>> Note the type of "link/void" -- is it possible that XORP refuses to set >>> routes pertaining to this link because of the link type, even though it >>> will give the interface an IP address? If so, is there a way to disable >>> this/fix this/prevent this? Or any other idea what's going wrong? >> >> I'd say that's likely. Can you just fix your network driver so that >> it claims to be Ethernet? That's what other virtual drivers, such as >> 'veth' >> do... > > From what I hear, the answer is "maybe" -- in that they do have that > option but it's not working right :-( > > One thing the guys here told me is that void is a legit link type in the > kernel with a configurable link layer address size. The address size > above is 128-bit; however from poking around at the XORP source code it > seems that it makes assumptions all over the place that the link layer > addresses are 48 bit. Patches to make that code more flexible are welcome :) > I actually compared logs from running with a normal interface vs. our > custom interface and they were basically identical. > > I did see this: > > [ 2010/05/19 17:19:21.86898 INFO xorp:3702 RTRMGR > rtrmgr/module_manager.cc:94 execute ] Executing module: static_routes > (xorp_static_routes) > > [ 2010/05/19 17:19:21.98138 WARNING xorp:3702 XrlFinderTarget > obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 > 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. I don't know exactly why these log messages appear, but they have always been there as far as I know, and doesn't seem to cause any harm. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jmitchell at ll.mit.edu Thu May 20 11:16:11 2010 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Thu, 20 May 2010 14:16:11 -0400 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF56962.8080101@candelatech.com> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> <4BF45A4E.4070301@ll.mit.edu> <4BF46078.2080000@candelatech.com> <4BF548AE.7030203@ll.mit.edu> <4BF56962.8080101@candelatech.com> Message-ID: <4BF57C6B.1070002@ll.mit.edu> On 05/20/2010 12:54 PM, Ben Greear wrote: >> I actually compared logs from running with a normal interface vs. our >> custom interface and they were basically identical. >> >> I did see this: >> >> [ 2010/05/19 17:19:21.86898 INFO xorp:3702 RTRMGR >> rtrmgr/module_manager.cc:94 execute ] Executing module: static_routes >> (xorp_static_routes) >> >> [ 2010/05/19 17:19:21.98138 WARNING xorp:3702 XrlFinderTarget >> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 >> 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. > > I don't know exactly why these log messages appear, but they have always > been there as far as I know, and doesn't seem to cause any harm. The plot thickens a little bit... If I look at the interface with "ip link" (or ifconfig) it shows the interface to be up. And, indeed, I can pass traffic over it. However, if I do a "show interfaces" in XORP, it shows NO-CARRIER for those interfaces. I did a quick grep for it and found that it's dependent upon a no_carrier boolean function...so next I guess I need to find out where that's being set to true, and why. I'll grep through, but if anyone can point me quickly to the right spot, bonus. Thanks, Jeff From greearb at candelatech.com Thu May 20 11:20:23 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 May 2010 11:20:23 -0700 Subject: [Xorp-users] Problem adding routes to custom devices In-Reply-To: <4BF57C6B.1070002@ll.mit.edu> References: <4BF4267F.6070706@ll.mit.edu> <4BF42B03.5070205@candelatech.com> <4BF44034.1020602@ll.mit.edu> <4BF444C9.30808@candelatech.com> <4BF45A4E.4070301@ll.mit.edu> <4BF46078.2080000@candelatech.com> <4BF548AE.7030203@ll.mit.edu> <4BF56962.8080101@candelatech.com> <4BF57C6B.1070002@ll.mit.edu> Message-ID: <4BF57D67.5070809@candelatech.com> On 05/20/2010 11:16 AM, Jeff Mitchell wrote: > On 05/20/2010 12:54 PM, Ben Greear wrote: >>> I actually compared logs from running with a normal interface vs. our >>> custom interface and they were basically identical. >>> >>> I did see this: >>> >>> [ 2010/05/19 17:19:21.86898 INFO xorp:3702 RTRMGR >>> rtrmgr/module_manager.cc:94 execute ] Executing module: static_routes >>> (xorp_static_routes) >>> >>> [ 2010/05/19 17:19:21.98138 WARNING xorp:3702 XrlFinderTarget >>> obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 >>> 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. >> >> I don't know exactly why these log messages appear, but they have always >> been there as far as I know, and doesn't seem to cause any harm. > > The plot thickens a little bit... > > If I look at the interface with "ip link" (or ifconfig) it shows the > interface to be up. And, indeed, I can pass traffic over it. > > However, if I do a "show interfaces" in XORP, it shows NO-CARRIER for > those interfaces. > > I did a quick grep for it and found that it's dependent upon a > no_carrier boolean function...so next I guess I need to find out where > that's being set to true, and why. I'll grep through, but if anyone can > point me quickly to the right spot, bonus. fea/data_plane/ifconfig/ifconfig_media.cc There are some hacks in the code that calls this to fake carrier up in some cases, but best would probably be to get your driver to implement the minimal ethtool ioctls to report the carrier status. Thanks, Ben > > Thanks, > Jeff -- Ben Greear Candela Technologies Inc http://www.candelatech.com From tzury.by at gmail.com Fri May 21 09:51:50 2010 From: tzury.by at gmail.com (Tzury Bar Yochay) Date: Fri, 21 May 2010 19:51:50 +0300 Subject: [Xorp-users] a certain type of tunneling with xorp- is it possible Message-ID: dears, I wonder if the following feature is available with xorp --- I need to be able to transform a multicast packet into a unicast one owe to network lack of support for multicast (satellite). That is, I have a network service which uses multicast, and when installing it on a remote site (lan) which connected to satellite, I must convert those packets before sending them on the air. For instance, say I have a packet that its destination is 230.0.0.3, I'd like to turn it into a unicast packet per destination, that is, if destinations are 10.0.0.1 and 10.0.0.2 I'd like the router to re-generate two packets each with the appropriate destination - needles to say, MAC address also should be transformed accordingly. In an optimal case, those destinations are to be "learned" by the router, however, if not possible I would set them all manually before-head. thanks in advance, / Tzury bar Yochay (@tzury) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100521/3f833a74/attachment.html From greearb at candelatech.com Fri May 21 10:42:40 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 21 May 2010 10:42:40 -0700 Subject: [Xorp-users] a certain type of tunneling with xorp- is it possible In-Reply-To: References: Message-ID: <4BF6C610.7070508@candelatech.com> On 05/21/2010 09:51 AM, Tzury Bar Yochay wrote: > dears, I wonder if the following feature is available with xorp --- > I need to be able to transform a multicast packet into a unicast one owe > to network lack of support for multicast (satellite). > That is, I have a network service which uses multicast, and when > installing it on a remote site (lan) which connected to satellite, I > must convert those packets before sending them on the air. > > For instance, say I have a packet that its destination is 230.0.0.3, I'd > like to turn it into a unicast packet per destination, that is, if > destinations are 10.0.0.1 and 10.0.0.2 I'd like the router to > re-generate two packets each with the appropriate destination - needles > to say, MAC address also should be transformed accordingly. > In an optimal case, those destinations are to be "learned" by the > router, however, if not possible I would set them all manually before-head. It sounds to me like you would probably have to write a stand-alone application that joined the multicast and made a normal tcp or udp unicast connection to your unicast target(s), and bridged the packets in software. It probably wouldn't be hard to do that translation like that. I don't think it would be easy to add that functionality directly into xorp though. Thanks, Ben > > thanks in advance, > > / Tzury bar Yochay (@tzury) > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Ben Greear Candela Technologies Inc http://www.candelatech.com From galaxy-huang at 163.com Sun May 23 20:47:03 2010 From: galaxy-huang at 163.com (xorp-users) Date: Mon, 24 May 2010 11:47:03 +0800 (CST) Subject: [Xorp-users] error when running xorpsh Message-ID: hello, xorpers I am a newer to to xorp, i've successfully install xorp on my ubuntu, but when i tried to run "xorpsh" in the rtrmgr directory, something is wrong as follow: ..... [ 2010/05/24 11:43:04 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc complete_transfer ] Write error 111 [ 2010/05/24 11:43:04 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc complete_transfer ] Write error 111 [ 2010/05/24 11:43:05 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc complete_transfer ] Write error 111 [ 2010/05/24 11:43:05 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc complete_transfer ] Write error 111 [ 2010/05/24 11:43:05 ERROR xorpsh:11836 RTRMGR +96 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2010/05/24 11:43:05 ERROR xorpsh:11836 RTRMGR +906 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager Could anyone please tell me what the problem is or offer me some hints to solve this problem, thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100524/d0c8cb63/attachment.html From lorenl at north-winds.org Mon May 24 19:18:17 2010 From: lorenl at north-winds.org (Loren M. Lang) Date: Mon, 24 May 2010 19:18:17 -0700 Subject: [Xorp-users] Xorp 1.6 LiveCD fails to run RIP Message-ID: <4BFB3369.1000609@north-winds.org> I am using the Xorp 1.6 LiveCD inside VirtualBox 3.1.8 to test out some network configurations using both RIP and OSPF. I have successfully gotten OSPF to peer with other routers running Quagga, but I cannot seem to make Xorp use RIP. I am running other routers with RIPv2 multicast and no authentication. When I startup a fresh Xorp router with the following configuration, I see zero RIP traffic coming from the Xorp router. When I first commit the changes, all I see is an IGMP join to group 224.0.0.9 followed by an IGMP leave from group 224.0.0.9. show rip peers shows no peers, however, other Quagga RIPv2 routers have no trouble seeing each other. protocols { fib2mrib { } rip { interface em1 { vif em1 { address 192.168.10.11 { } } } export: "connected-routes" } } policy { policy-statement "connected-routes" { term export { from { protocol: "connected" } } } } fea { unicast-forwarding4 { } } interfaces { interface em1 { description: "Ethernet" vif em1 { address 192.168.10.11 { prefix-length: 29 broadcast: 192.168.10.15 } } } interface lo0 { description: "Loopback interface" vif lo0 { } } } -- Loren M. Lang lorenl at north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B From sportero at cica.es Tue May 25 02:54:50 2010 From: sportero at cica.es (Samuel Portero Bolanos) Date: Tue, 25 May 2010 11:54:50 +0200 Subject: [Xorp-users] IPv6 multicast routing not supported Message-ID: <4BFB9E6A.7030902@cica.es> Hi all, I have a problem with multicast and IPv6. I have a RHEL5 with kernel 2.6.31.5 compipled with these options: -->Networking option -->IP: multicasting -->The IPv6 protocol -->IPv6: Multiple Routing Tables -->IPv6: source address based routing -->IPv6: multicast routing (EXPERIMENTAL) -->IPv6: PIM-SM version 2 support (EXPERIMENTAL) When I set pimsm6 protocol on interface bond1.27, I have the following messages: [ 2010/05/25 10:48:16 INFO xorp:30721 RTRMGR +101 module_manager.cc execute ] Executing module: mfea6 (fea/xorp_fea) [ 2010/05/25 10:48:16 INFO xorp_fea MFEA ] Interface added: Vif[bond1.27] pif_index: 74 vif_index: 3 addr: 2001:720:X:X::1 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: 2001:720:X:X::3 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: fe80::204:23ff:fee6:47d subnet: fe80::/64 broadcast: :: peer: :: Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2010/05/25 10:48:16 ERROR xorp_fea:30786 MFEA +720 mfea_mrouter.cc start_mrt ] start_mrt() failed: IPv6 multicast routing not supported [ 2010/05/25 10:48:16 INFO xorp_fea MFEA ] MFEA started [ 2010/05/25 10:48:16 INFO xorp:30721 RTRMGR +101 module_manager.cc execute ] Executing module: mld (mld6igmp/xorp_mld) [ 2010/05/25 10:48:16 WARNING xorp:30721 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MLD" does not exist or is not enabled. [ 2010/05/25 10:48:16 INFO xorp_mld MLD6IGMP ] Protocol enabled [ 2010/05/25 10:48:16 INFO xorp_mld MLD6IGMP ] CLI enabled [ 2010/05/25 10:48:16 INFO xorp_mld MLD6IGMP ] CLI started [ 2010/05/25 10:48:17 INFO xorp_mld MLD6IGMP ] Protocol started [ 2010/05/25 10:48:17 INFO xorp_mld MLD6IGMP ] Interface added: Vif[bond1.27] pif_index: 74 vif_index: 3 addr: 2001:720:X:X::1 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: 2001:720:X:X::3 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: fe80::204:23ff:fee6:47d subnet: fe80::/64 broadcast: :: peer: :: Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2010/05/25 10:48:18 INFO xorp:30721 RTRMGR +101 module_manager.cc execute ] Executing module: pimsm6 (pim/xorp_pimsm6) [ 2010/05/25 10:48:18 WARNING xorp:30721 XrlFinderTarget +407 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "PIMSM_6" does not exist or is not enabled. [ 2010/05/25 10:48:18 INFO xorp_pimsm6 PIM ] Protocol enabled [ 2010/05/25 10:48:18 INFO xorp_pimsm6 PIM ] CLI enabled [ 2010/05/25 10:48:18 INFO xorp_pimsm6 PIM ] CLI started [ 2010/05/25 10:48:19 INFO xorp_pimsm6 PIM ] Interface added: Vif[bond1.27] pif_index: 74 vif_index: 3 addr: 2001:720:X:X::1 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: 2001:720:c10:X::X subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: fe80::204:23ff:fee6:47d subnet: fe80::/64 broadcast: :: peer: :: Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2010/05/25 10:48:19 INFO xorp_pimsm6 PIM ] Protocol started [ 2010/05/25 10:48:20 INFO xorp_pimsm6 PIM ] Interface enabled: Vif[bond1.27] pif_index: 74 vif_index: 3 addr: 2001:720:X:X::1 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: 2001:720:X::X subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: fe80::204:23ff:fee6:47d subnet: fe80::/64 broadcast: :: peer: :: Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv6 ENABLED [ 2010/05/25 10:48:20 INFO xorp_pimsm6 PIM ] Interface started: Vif[bond1.27] pif_index: 74 vif_index: 3 addr: 2001:720:X:X::1 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: 2001:720:X:X::3 subnet: 2001:720:X:X::/64 broadcast: :: peer: :: addr: fe80::204:23ff:fee6:47d subnet: fe80::/64 broadcast: :: peer: :: Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv6 ENABLED [ 2010/05/25 10:48:20 INFO xorp:30721 RTRMGR +2233 task.cc run_task ] No more tasks to run [ 2010/05/25 10:48:20 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/register_protocol6 failed: XrlCmdError 102 Command failed Cannot start PIM processing: start_pim() failed: IPv6 multicast routing not supported [ 2010/05/25 10:48:20 FATAL xorp_pimsm6:11635 PIM +1332 xrl_pim_node.cc mfea_client_send_register_unregister_protocol_cb ] Cannot register protocol with the MFEA: 102 Command failed Cannot start PIM processing: start_pim() failed: IPv6 multicast routing not supported [ 2010/05/25 10:48:20 ERROR xorp:30721 RTRMGR +754 module_manager.cc done_cb ] Command "/usr/libexec/xorp/pim/xorp_pimsm6": terminated with signal 6. [ 2010/05/25 10:48:20 INFO xorp:30721 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: pimsm6 The config: pimsm6 { interface "bond1.27" { vif "bond1.27" { } } static-rps { rp 2001:720:Y:Y::1 } } For IPv4, XORP works fine. Does anyone know what happen? I have installed XORP 1.6 version. Thanks!! -- Samuel F. Portero Bola?os T?cnico de Comunicaciones y Seguridad Inform?tica Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n y Ciencia Junta de Andaluc?a -------------------------------------------------- Este mensaje esta firmado digitalmente. Para poder reconocer la firma desde su cliente debera tener instalado el certificado raiz de la F.N.M.T. -------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3755 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100525/353b4c8e/attachment.bin From ladybass at gmail.com Tue May 25 06:33:27 2010 From: ladybass at gmail.com (Shaila Jimenez) Date: Tue, 25 May 2010 15:33:27 +0200 Subject: [Xorp-users] multicast pimsm4 question Message-ID: Hi all, When I run xorp 1.6 I always get a message related to pimsm4: WARNING xorp pimsm4 PIM ] JoinDesired(*,G)=true; RP for group 239.255.255.250: not found. I read that the multicast address 239.255.255.250 is used the Simple Service Discovery Protocol (SSDP) protocol to discover network services. I'm trying to config this scenary: Source -> XORP1(RP) -> XORP2 -> XORP3 -> XORP4 -> Member Source(eth0): 192.168.2.10/24 Xorp1(eth0): 192.168.2.20/24 Xorp1(eth1): 192.168.3.10 (RP) Xorp2(eth0): 192.168.3.20/24 Xorp2(eth1): 192.168.4.10 Xorp3(eth0): 192.168.4.20/24 Xorp3(eth1): 192.168.5.10/24 Xorp4(eth0): 192.168.5.20/24 Xorp4(eth1): 192.168.6.10/24 Member(eth0): 192.168.6.20/24 Routes - Xorp1 has one static route to destination 4.0 and next-hop 3.20. - Xorp2 has one static route to destination 5.0 and next-hop 4.20. - Xorp3 has one static route to destination 6.0 and next-hop 5.20. - Xorp4 has one static route to destination 6.0 and next-hop 6.20. Xorp has enabled: igmpv3,pimsm4,mfea,fib2mrib and one static route in each xorp. Each xorp have in their config the static RP part (192.168.3.10). do I need to be worried about the warning or the config is fine? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100525/4ab0978d/attachment.html From greearb at candelatech.com Tue May 25 13:01:53 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 25 May 2010 13:01:53 -0700 Subject: [Xorp-users] IPv6 multicast routing not supported In-Reply-To: <4BFB9E6A.7030902@cica.es> References: <4BFB9E6A.7030902@cica.es> Message-ID: <4BFC2CB1.5020502@candelatech.com> On 05/25/2010 02:54 AM, Samuel Portero Bolanos wrote: > Hi all, > > I have a problem with multicast and IPv6. I have a RHEL5 with kernel > 2.6.31.5 compipled with these options: > > -->Networking option > -->IP: multicasting > -->The IPv6 protocol > -->IPv6: Multiple Routing Tables > -->IPv6: source address based routing > -->IPv6: multicast routing (EXPERIMENTAL) > -->IPv6: PIM-SM version 2 support (EXPERIMENTAL) > > > When I set pimsm6 protocol on interface bond1.27, I have the following > messages: Please try xorp.ct, I think it will work for you, but there may yet be problems with multicast ipv6 traffic. I plan to test and/or fix this in the near future, but my time is going to be a bit limitted for a few weeks. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue May 25 13:08:28 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 25 May 2010 13:08:28 -0700 Subject: [Xorp-users] error when running xorpsh In-Reply-To: References: Message-ID: <4BFC2E3C.506@candelatech.com> On 05/23/2010 08:47 PM, xorp-users wrote: > hello, xorpers > I am a newer to to xorp, i've successfully install xorp on my ubuntu, > but when i tried to run "xorpsh" in the rtrmgr directory, something is > wrong as follow: > ..... > [ 2010/05/24 11:43:04 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc > complete_transfer ] Write error 111 > [ 2010/05/24 11:43:04 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc > complete_transfer ] Write error 111 > [ 2010/05/24 11:43:05 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc > complete_transfer ] Write error 111 > [ 2010/05/24 11:43:05 ERROR xorpsh:11836 LIBXORP +714 asyncio.cc > complete_transfer ] Write error 111 > [ 2010/05/24 11:43:05 ERROR xorpsh:11836 RTRMGR +96 xorpsh_main.cc > wait_for_xrl_router_ready ] XrlRouter failed. No Finder? > [ 2010/05/24 11:43:05 ERROR xorpsh:11836 RTRMGR +906 xorpsh_main.cc main > ] xorpsh exiting due to an init error: Failed to connect to the router > manager > Could anyone please tell me what the problem is or offer me some hints > to solve this problem, thanks in advance! You haven't started the xorp_rtrmgr process. You need to create at least a minimal config file and start the rtrmgr before xorpsh is useful. Thanks, Ben > > > ------------------------------------------------------------------------ > ?????????????????????????????????????????? > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue May 25 13:14:43 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 25 May 2010 13:14:43 -0700 Subject: [Xorp-users] Xorp 1.6 LiveCD fails to run RIP In-Reply-To: <4BFB3369.1000609@north-winds.org> References: <4BFB3369.1000609@north-winds.org> Message-ID: <4BFC2FB3.3040201@candelatech.com> On 05/24/2010 07:18 PM, Loren M. Lang wrote: > I am using the Xorp 1.6 LiveCD inside VirtualBox 3.1.8 to test out some network configurations using both RIP and OSPF. I have successfully gotten OSPF to peer with other routers running Quagga, but I cannot seem to make Xorp use RIP. I am running other routers with RIPv2 multicast and no authentication. When I startup a fresh Xorp router with the following configuration, I see zero RIP traffic coming from the Xorp router. When I first commit the changes, all I see is an IGMP join to group 224.0.0.9 followed by an IGMP leave from group 224.0.0.9. show rip peers shows no peers, however, other Quagga RIPv2 routers have no trouble seeing each other. Can you try our live-cd with xorp.ct on it? Just ignore the LANforge stuff (it won't be running by default) and use the xorp installed in /usr/local/xorp http://www.candelatech.com/private/downloads/r5.1.5/Ubuntu-Live-9.10-LANforge.iso (user: guest, password: guest) If it doesn't work with adding the rip config dynamically, try starting xorp with the RIP config already in the config file. I'm curious to know how it works if you try this. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From wubaochuan at seu.edu.cn Thu May 27 08:01:16 2010 From: wubaochuan at seu.edu.cn (wubaochuan) Date: Thu, 27 May 2010 23:01:16 +0800 Subject: [Xorp-users] help, about OSPF configuration Message-ID: <474972474.19170@seu.edu.cn> hello everyone, When I configure OSPF, I have the following problems. All the following four machine run Fedora 12, and the first one and the fourth one run as hosts, the second and the third run as routers. eth0 eth0 eth1 eth0 eth1 eth0 |------| |----------| |------------| |-------| | | | | | | | | | |----------------| |---------------------| |----------------------------| | |------| |----------| |------------| |-------| hostA routerA routerB hostB eth0 10.10.10.2/24 eth0 10.10.10.1/24 eth0 10.10.11.2/24 eth0 10.10.12.2/24 eth1 10.10.11.1/24 eth1 10.10.12.1/24 routerA is configured with the following file: //routeA config.boot interfaces { interface eth0 { vif eth0 { address 10.10.10.1 { prefix-length: 24 } } } interface eth1 { vif eth1 { address 10.10.11.1 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 10.10.10.1 area 0.0.0.0 { interface eth0 { /* link-type: "broadcast" */ vif eth0 { address 10.10.10.1 { } } } } area 0.0.0.1 { /* area-type: "normal" */ interface eth1 { vif eth1 { address 10.10.11.1 { } } } } } } and routerB is configured with the following file: //routerB config.boot interfaces { interface eth0 { vif eth0 { address 10.10.11.2 { prefix-length: 24 } } } interface eth1 { vif eth1 { address 10.10.12.1 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false /*enable ipv4 forwarding*/ } } protocols { ospf4 { router-id: 10.10.11.2 area 0.0.0.1 { interface eth0 { /* link-type: "broadcast" */ vif eth0 { address 10.10.11.2 { } } } } area 0.0.0.2 { /* area-type: "normal" */ interface eth1 { vif eth1 { address 10.10.12.1 { } } } } } } When I run `show ospf4 neighbor` in routerB's xorpsh, the following lines appear: Address Interface State ID Pri Dead 10.10.11.1 eth0/eth0 Full 10.10.10.1 128 34 but when I run `show route table ipv4 unicast ospf` in xorpsh nothing appears, I want to know, why there is nothing in the route table? how can I fix this problem? thanks Chuan From greearb at candelatech.com Thu May 27 10:14:57 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 27 May 2010 10:14:57 -0700 Subject: [Xorp-users] help, about OSPF configuration In-Reply-To: <474972474.19170@seu.edu.cn> References: <474972474.19170@seu.edu.cn> Message-ID: <4BFEA891.7070704@candelatech.com> On 05/27/2010 08:01 AM, wubaochuan wrote: > hello everyone, > When I configure OSPF, I have the following problems. > > All the following four machine run Fedora 12, and the first one and the > fourth one run as hosts, the second and > the third run as routers. I think you just need to add a policy to export connected routes to OSPF. I'll post an example later today if you don't find something sooner. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From wubaochuan at seu.edu.cn Thu May 27 18:23:08 2010 From: wubaochuan at seu.edu.cn (wubaochuan) Date: Fri, 28 May 2010 09:23:08 +0800 Subject: [Xorp-users] Xorp-users Digest, Vol 50, Issue 17 In-Reply-To: <474986996.08628@seu.edu.cn> References: <474986996.08628@seu.edu.cn> Message-ID: <475009787.08496@seu.edu.cn> Ben, thank you, I will try. thanks Chuan ? 2010-5-28 3:00, xorp-users-request at xorp.org ??: > Send Xorp-users mailing list submissions to > xorp-users at xorp.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > or, via email, send a message with subject or body 'help' to > xorp-users-request at xorp.org > > You can reach the person managing the list at > xorp-users-owner at xorp.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Xorp-users digest..." > > > Today's Topics: > > 1. help, about OSPF configuration (wubaochuan) > 2. Re: help, about OSPF configuration (Ben Greear) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 27 May 2010 23:01:16 +0800 > From: wubaochuan > Subject: [Xorp-users] help, about OSPF configuration > To: xorp-users at xorp.org > Message-ID:<474972474.19170 at seu.edu.cn> > Content-Type: text/plain; charset=GB2312 > > hello everyone, > When I configure OSPF, I have the following problems. > > All the following four machine run Fedora 12, and the first one and the > fourth one run as hosts, the second and > the third run as routers. > > eth0 eth0 eth1 eth0 eth1 eth0 > |------| |----------| |------------| |-------| > | | | | | | | | > | |----------------| |---------------------| > |----------------------------| | > |------| |----------| |------------| |-------| > > hostA routerA routerB hostB > eth0 10.10.10.2/24 eth0 10.10.10.1/24 eth0 10.10.11.2/24 eth0 10.10.12.2/24 > eth1 10.10.11.1/24 eth1 10.10.12.1/24 > > routerA is configured with the following file: > //routeA config.boot > interfaces { > interface eth0 { > vif eth0 { > address 10.10.10.1 { > prefix-length: 24 > } > } > } > interface eth1 { > vif eth1 { > address 10.10.11.1 { > prefix-length: 24 > } > } > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > ospf4 { > router-id: 10.10.10.1 > > area 0.0.0.0 { > interface eth0 { > /* link-type: "broadcast" */ > vif eth0 { > address 10.10.10.1 { > } > } > } > } > area 0.0.0.1 { > /* area-type: "normal" */ > > interface eth1 { > vif eth1 { > address 10.10.11.1 { > } > } > } > } > } > } > > > and routerB is configured with the following file: > //routerB config.boot > interfaces { > interface eth0 { > vif eth0 { > address 10.10.11.2 { > prefix-length: 24 > } > } > } > interface eth1 { > vif eth1 { > address 10.10.12.1 { > prefix-length: 24 > } > } > } > } > > fea { > unicast-forwarding4 { > disable: false /*enable ipv4 forwarding*/ > } > } > > protocols { > ospf4 { > router-id: 10.10.11.2 > > area 0.0.0.1 { > interface eth0 { > /* link-type: "broadcast" */ > vif eth0 { > address 10.10.11.2 { > } > } > } > } > > area 0.0.0.2 { > /* area-type: "normal" */ > > interface eth1 { > vif eth1 { > address 10.10.12.1 { > } > } > } > } > } > } > > When I run `show ospf4 neighbor` in routerB's xorpsh, > the following lines appear: > Address Interface State ID Pri Dead > 10.10.11.1 eth0/eth0 Full 10.10.10.1 128 34 > > but when I run `show route table ipv4 unicast ospf` in xorpsh > nothing appears, > I want to know, why there is nothing in the route table? > how can I fix this problem? > > > thanks > Chuan > > > > ------------------------------ > > Message: 2 > Date: Thu, 27 May 2010 10:14:57 -0700 > From: Ben Greear > Subject: Re: [Xorp-users] help, about OSPF configuration > To: wubaochuan > Cc: xorp-users at xorp.org > Message-ID:<4BFEA891.7070704 at candelatech.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 05/27/2010 08:01 AM, wubaochuan wrote: > >> hello everyone, >> When I configure OSPF, I have the following problems. >> >> All the following four machine run Fedora 12, and the first one and the >> fourth one run as hosts, the second and >> the third run as routers. >> > I think you just need to add a policy to export connected routes > to OSPF. I'll post an example later today if you don't find something > sooner. > > Thanks, > Ben > > From wubaochuan at seu.edu.cn Fri May 28 01:45:09 2010 From: wubaochuan at seu.edu.cn (wubaochuan) Date: Fri, 28 May 2010 16:45:09 +0800 Subject: [Xorp-users] Xorp-users Digest, Vol 50, Issue 17 In-Reply-To: <474986996.08628@seu.edu.cn> References: <474986996.08628@seu.edu.cn> Message-ID: <475036307.12740@seu.edu.cn> Hi Ben, could you post an example? I do not figure it out how to use policy in OSPF configuration. Thanks Chuan ? 2010-5-28 3:00, xorp-users-request at xorp.org ??: > Send Xorp-users mailing list submissions to > xorp-users at xorp.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > or, via email, send a message with subject or body 'help' to > xorp-users-request at xorp.org > > You can reach the person managing the list at > xorp-users-owner at xorp.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Xorp-users digest..." > > > Today's Topics: > > 1. help, about OSPF configuration (wubaochuan) > 2. Re: help, about OSPF configuration (Ben Greear) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 27 May 2010 23:01:16 +0800 > From: wubaochuan > Subject: [Xorp-users] help, about OSPF configuration > To: xorp-users at xorp.org > Message-ID:<474972474.19170 at seu.edu.cn> > Content-Type: text/plain; charset=GB2312 > > hello everyone, > When I configure OSPF, I have the following problems. > > All the following four machine run Fedora 12, and the first one and the > fourth one run as hosts, the second and > the third run as routers. > > eth0 eth0 eth1 eth0 eth1 eth0 > |------| |----------| |------------| |-------| > | | | | | | | | > | |----------------| |---------------------| > |----------------------------| | > |------| |----------| |------------| |-------| > > hostA routerA routerB hostB > eth0 10.10.10.2/24 eth0 10.10.10.1/24 eth0 10.10.11.2/24 eth0 10.10.12.2/24 > eth1 10.10.11.1/24 eth1 10.10.12.1/24 > > routerA is configured with the following file: > //routeA config.boot > interfaces { > interface eth0 { > vif eth0 { > address 10.10.10.1 { > prefix-length: 24 > } > } > } > interface eth1 { > vif eth1 { > address 10.10.11.1 { > prefix-length: 24 > } > } > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > protocols { > ospf4 { > router-id: 10.10.10.1 > > area 0.0.0.0 { > interface eth0 { > /* link-type: "broadcast" */ > vif eth0 { > address 10.10.10.1 { > } > } > } > } > area 0.0.0.1 { > /* area-type: "normal" */ > > interface eth1 { > vif eth1 { > address 10.10.11.1 { > } > } > } > } > } > } > > > and routerB is configured with the following file: > //routerB config.boot > interfaces { > interface eth0 { > vif eth0 { > address 10.10.11.2 { > prefix-length: 24 > } > } > } > interface eth1 { > vif eth1 { > address 10.10.12.1 { > prefix-length: 24 > } > } > } > } > > fea { > unicast-forwarding4 { > disable: false /*enable ipv4 forwarding*/ > } > } > > protocols { > ospf4 { > router-id: 10.10.11.2 > > area 0.0.0.1 { > interface eth0 { > /* link-type: "broadcast" */ > vif eth0 { > address 10.10.11.2 { > } > } > } > } > > area 0.0.0.2 { > /* area-type: "normal" */ > > interface eth1 { > vif eth1 { > address 10.10.12.1 { > } > } > } > } > } > } > > When I run `show ospf4 neighbor` in routerB's xorpsh, > the following lines appear: > Address Interface State ID Pri Dead > 10.10.11.1 eth0/eth0 Full 10.10.10.1 128 34 > > but when I run `show route table ipv4 unicast ospf` in xorpsh > nothing appears, > I want to know, why there is nothing in the route table? > how can I fix this problem? > > > thanks > Chuan > > > > ------------------------------ > > Message: 2 > Date: Thu, 27 May 2010 10:14:57 -0700 > From: Ben Greear > Subject: Re: [Xorp-users] help, about OSPF configuration > To: wubaochuan > Cc: xorp-users at xorp.org > Message-ID:<4BFEA891.7070704 at candelatech.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 05/27/2010 08:01 AM, wubaochuan wrote: > >> hello everyone, >> When I configure OSPF, I have the following problems. >> >> All the following four machine run Fedora 12, and the first one and the >> fourth one run as hosts, the second and >> the third run as routers. >> > I think you just need to add a policy to export connected routes > to OSPF. I'll post an example later today if you don't find something > sooner. > > Thanks, > Ben > > From naresh_raga at yahoo.co.in Fri May 28 03:52:44 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 28 May 2010 03:52:44 -0700 (PDT) Subject: [Xorp-users] Need Definition for BGP damping parameters Message-ID: <254122.77376.qm@web94812.mail.in2.yahoo.com> Hello, In the Xorp User Manual,BGP damping parameters? in the configuration syntax have not been defined.Also their default values and the ranges to be used have not been mentioned in the manual. 1)? half-life: int 2) max-suppress: int 3)reuse: int 4)suppress: int Can someone please define what are their definitions and the range of values to be used in the configuration. Thanks, Naresh. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100528/984f7c9d/attachment.html From naresh_raga at yahoo.co.in Fri May 28 09:33:19 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 28 May 2010 22:03:19 +0530 (IST) Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <896230.98295.qm@web94802.mail.in2.yahoo.com> Message-ID: <383440.24329.qm@web94806.mail.in2.yahoo.com> >Hi Ben, > I was unable to checkout xorp.ct. >But I have applied patch for xorp-1.6 as in http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-April/001185.html >It's working.I am adding routes to the kernel using ip route add command >and they are being advertised by OSPF. >Thanks to Pavlin for the patch. >Thank you Ben, >T.Raga Naresh Kumar. Hi Ben, I just want to inform you that the patch provided by Pavlin is not working properly.I have tried to insert some 1000 routes into kernel routing table and all the routes were not being advertised by OSPF. This is for your information as you have added this patch to your xorp.ct. Thank you, T.Raga Naresh Kumar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100528/9f7fa44a/attachment.html From greearb at candelatech.com Fri May 28 10:01:16 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 28 May 2010 10:01:16 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <383440.24329.qm@web94806.mail.in2.yahoo.com> References: <383440.24329.qm@web94806.mail.in2.yahoo.com> Message-ID: <4BFFF6DC.6020007@candelatech.com> On 05/28/2010 09:33 AM, naresh raga wrote: > >Hi Ben, > > I was unable to checkout xorp.ct. > >But I have applied patch for xorp-1.6 as in > > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2006-April/001185.html > >>It's working.I am adding routes to the kernel using ip route add command >>and they are being advertised by OSPF. > >>Thanks to Pavlin for the patch. > >>Thank you Ben, >>T.Raga Naresh Kumar. > > > Hi Ben, > I just want to inform you that the patch provided by Pavlin is not working > properly.I have tried to insert some 1000 routes into kernel routing table > and all the routes were not being advertised by OSPF. > This is for your information as you have added this patch to your xorp.ct. Can you explain your test case in detail so that I might try to reproduce it in xorp.ct? For instance, how are you adding the routes? How many of the routes *do* show up in OSPF? Same routes show up each time? Any errors in xorp logs, perhaps netlink overflow errors? Thanks, Ben > > > Thank you, > T.Raga Naresh Kumar. > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Fri May 28 10:44:49 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Fri, 28 May 2010 23:14:49 +0530 (IST) Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <4BFFF6DC.6020007@candelatech.com> Message-ID: <678956.22896.qm@web94810.mail.in2.yahoo.com> >Can you explain your test case in detail so that I might try to reproduce it in >xorp.ct?? For instance, how are you adding the routes?? How many of the >routes *do* show up in OSPF?? Same routes show up each time?Any errors in >xorp logs, perhaps netlink overflow errors? >Thanks, >Ben. PC1(Xorp with patch)------PC2(Xorp standard build). Initially I have added routes in PC1 to kernel routing table? using ip route add command.Then I have started xorp on both PC's.Finally I have verified routes on PC2(using xorpsh).Many routes are missing.On PC1 using wireshark,I have seen whether PC1 have advertised all routes in the kernel routing table.PC1 having Xorp with patch is not advertising all routes itself. I have tested this by adding 1000 routes into PC1 kernel routing table.Nearly 50% of the routes in kernel were not advertised by OSPF. Thank you, T.Raga Naresh Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100528/32bc6715/attachment.html From greearb at candelatech.com Fri May 28 11:08:14 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 28 May 2010 11:08:14 -0700 Subject: [Xorp-users] Xorp-users Digest, Vol 50, Issue 17 In-Reply-To: <475036307.12740@seu.edu.cn> References: <474986996.08628@seu.edu.cn> <475036307.12740@seu.edu.cn> Message-ID: <4C00068E.7050006@candelatech.com> On 05/28/2010 01:45 AM, wubaochuan wrote: > Hi Ben, could you post an example? I do not figure it out how to use > policy in OSPF configuration. > > Thanks > Chuan > > ? 2010-5-28 3:00, xorp-users-request at xorp.org ??: >> Send Xorp-users mailing list submissions to >> xorp-users at xorp.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> or, via email, send a message with subject or body 'help' to >> xorp-users-request at xorp.org >> >> You can reach the person managing the list at >> xorp-users-owner at xorp.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Xorp-users digest..." >> >> >> Today's Topics: >> >> 1. help, about OSPF configuration (wubaochuan) >> 2. Re: help, about OSPF configuration (Ben Greear) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 27 May 2010 23:01:16 +0800 >> From: wubaochuan >> Subject: [Xorp-users] help, about OSPF configuration >> To: xorp-users at xorp.org >> Message-ID:<474972474.19170 at seu.edu.cn> >> Content-Type: text/plain; charset=GB2312 >> >> hello everyone, >> When I configure OSPF, I have the following problems. >> >> All the following four machine run Fedora 12, and the first one and the >> fourth one run as hosts, the second and >> the third run as routers. >> >> eth0 eth0 eth1 eth0 eth1 eth0 >> |------| |----------| |------------| |-------| >> | | | | | | | | >> | |----------------| |---------------------| >> |----------------------------| | >> |------| |----------| |------------| |-------| >> >> hostA routerA routerB hostB >> eth0 10.10.10.2/24 eth0 10.10.10.1/24 eth0 10.10.11.2/24 eth0 10.10.12.2/24 >> eth1 10.10.11.1/24 eth1 10.10.12.1/24 >> >> routerA is configured with the following file: >> //routeA config.boot >> interfaces { >> interface eth0 { >> vif eth0 { >> address 10.10.10.1 { >> prefix-length: 24 >> } >> } >> } >> interface eth1 { >> vif eth1 { >> address 10.10.11.1 { >> prefix-length: 24 >> } >> } >> } >> >> } >> >> fea { >> unicast-forwarding4 { >> disable: false >> } >> } >> >> protocols { >> ospf4 { >> router-id: 10.10.10.1 >> >> area 0.0.0.0 { >> interface eth0 { >> /* link-type: "broadcast" */ >> vif eth0 { >> address 10.10.10.1 { >> } >> } >> } >> } >> area 0.0.0.1 { >> /* area-type: "normal" */ >> >> interface eth1 { >> vif eth1 { >> address 10.10.11.1 { >> } >> } >> } >> } >> } >> } >> >> >> and routerB is configured with the following file: >> //routerB config.boot >> interfaces { >> interface eth0 { >> vif eth0 { >> address 10.10.11.2 { >> prefix-length: 24 >> } >> } >> } >> interface eth1 { >> vif eth1 { >> address 10.10.12.1 { >> prefix-length: 24 >> } >> } >> } >> } >> >> fea { >> unicast-forwarding4 { >> disable: false /*enable ipv4 forwarding*/ >> } >> } >> >> protocols { >> ospf4 { >> router-id: 10.10.11.2 >> >> area 0.0.0.1 { >> interface eth0 { >> /* link-type: "broadcast" */ >> vif eth0 { >> address 10.10.11.2 { >> } >> } >> } >> } >> >> area 0.0.0.2 { >> /* area-type: "normal" */ >> >> interface eth1 { >> vif eth1 { >> address 10.10.12.1 { >> } >> } >> } >> } >> } >> } >> >> When I run `show ospf4 neighbor` in routerB's xorpsh, >> the following lines appear: >> Address Interface State ID Pri Dead >> 10.10.11.1 eth0/eth0 Full 10.10.10.1 128 34 >> >> but when I run `show route table ipv4 unicast ospf` in xorpsh >> nothing appears, >> I want to know, why there is nothing in the route table? >> how can I fix this problem? Actually, I think I was wrong about the export policy. I don't have the policy in my configs and yet it seems to be working fine. One thing: Could you try putting everything in the same OSPF area (0.0.0.0) and see if that works? Also, can you check the interfaces in xorpsh to make sure they are reported as enabled and with link up? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri May 28 12:41:11 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 28 May 2010 12:41:11 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <678956.22896.qm@web94810.mail.in2.yahoo.com> References: <678956.22896.qm@web94810.mail.in2.yahoo.com> Message-ID: <4C001C57.1070000@candelatech.com> On 05/28/2010 10:44 AM, naresh raga wrote: > >Can you explain your test case in detail so that I might try to > reproduce it in >xorp.ct? For instance, how are you adding the routes? > How many of the >routes *do* show up in OSPF? Same routes show up each > time?Any errors in >xorp logs, perhaps netlink overflow errors? > >Thanks, > >Ben. > > PC1(Xorp with patch)------PC2(Xorp standard build). > > Initially I have added routes in PC1 to kernel routing table using ip > route add command.Then I have started xorp on both PC's.Finally I have > verified routes on PC2(using xorpsh).Many routes are missing.On PC1 > using wireshark,I have seen whether PC1 have advertised all routes in > the kernel routing table.PC1 having Xorp with patch is not advertising > all routes itself. > > I have tested this by adding 1000 routes into PC1 kernel routing > table.Nearly 50% of the routes in kernel were not advertised by OSPF. I'll see if I can reproduce this on xorp.ct. We've a new baby, so my time is spotty for the next few weeks, but I'll hopefully have some results in a day or two. From your description, I suspect netlink buffer overflows. If you are able to test again and add some sleeps between your calls to the 'ip route add', I'm interested to know the results. I optimized xorp.ct to handle more netlink messages some time back, so I'm hopeful it will just work... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lorenl at north-winds.org Sat May 29 00:53:36 2010 From: lorenl at north-winds.org (Loren M. Lang) Date: Sat, 29 May 2010 00:53:36 -0700 Subject: [Xorp-users] Xorp 1.6 LiveCD fails to run RIP In-Reply-To: <4BFB3369.1000609@north-winds.org> References: <4BFB3369.1000609@north-winds.org> Message-ID: <20100529075335.GA15133@alzatex.com> On Mon, May 24, 2010 at 07:18:17PM -0700, Loren M. Lang wrote: > I am using the Xorp 1.6 LiveCD inside VirtualBox 3.1.8 to test out some network configurations using both RIP and OSPF. I have successfully gotten OSPF to peer with other routers running Quagga, but I cannot seem to make Xorp use RIP. I am running other routers with RIPv2 multicast and no authentication. When I startup a fresh Xorp router with the following configuration, I see zero RIP traffic coming from the Xorp router. When I first commit the changes, all I see is an IGMP join to group 224.0.0.9 followed by an IGMP leave from group 224.0.0.9. show rip peers shows no peers, however, other Quagga RIPv2 routers have no trouble seeing each other. I took a look at the log file /var/log/xorp_rtrmgr.log and it looks like the RIP process is failing to send multicast messages: [ 2010/05/28 14:26:59 WARNING xorp_fea XrlFeaTarget ] Handling method for socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 Command failed Socket not found [ 2010/05/28 14:26:59 ERROR xorp_rip:1420 RIP +557 port.cc port_io_send_completion ] Send failed I have downloaded the ISO containing xorp.ct and will test it shortly. > > protocols { > fib2mrib { > } > rip { > interface em1 { > vif em1 { > address 192.168.10.11 { > } > } > } > export: "connected-routes" > } > } > policy { > policy-statement "connected-routes" { > term export { > from { > protocol: "connected" > } > } > } > } > fea { > unicast-forwarding4 { > } > } > interfaces { > interface em1 { > description: "Ethernet" > vif em1 { > address 192.168.10.11 { > prefix-length: 29 > broadcast: 192.168.10.15 > } > } > } > interface lo0 { > description: "Loopback interface" > vif lo0 { > } > } > } > > > > -- > Loren M. Lang > lorenl at north-winds.org > http://www.north-winds.org/ > > > Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc > Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Loren M. Lang lorenl at north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100529/f083f5e7/attachment.bin From greearb at candelatech.com Sun May 30 11:24:09 2010 From: greearb at candelatech.com (Ben Greear) Date: Sun, 30 May 2010 11:24:09 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <4C001C57.1070000@candelatech.com> References: <678956.22896.qm@web94810.mail.in2.yahoo.com> <4C001C57.1070000@candelatech.com> Message-ID: <4C02AD49.2000601@candelatech.com> On 05/28/2010 12:41 PM, Ben Greear wrote: > On 05/28/2010 10:44 AM, naresh raga wrote: >> >Can you explain your test case in detail so that I might try to >> reproduce it in>xorp.ct? For instance, how are you adding the routes? >> How many of the>routes *do* show up in OSPF? Same routes show up each >> time?Any errors in>xorp logs, perhaps netlink overflow errors? >> >Thanks, >> >Ben. >> >> PC1(Xorp with patch)------PC2(Xorp standard build). >> >> Initially I have added routes in PC1 to kernel routing table using ip >> route add command.Then I have started xorp on both PC's.Finally I have >> verified routes on PC2(using xorpsh).Many routes are missing.On PC1 >> using wireshark,I have seen whether PC1 have advertised all routes in >> the kernel routing table.PC1 having Xorp with patch is not advertising >> all routes itself. >> >> I have tested this by adding 1000 routes into PC1 kernel routing >> table.Nearly 50% of the routes in kernel were not advertised by OSPF. > > I'll see if I can reproduce this on xorp.ct. We've a new baby, so > my time is spotty for the next few weeks, but I'll hopefully have > some results in a day or two. Just to let you know: I think I have a proper configuration set up now, but I'm not seeing any routes exported. I'm using xorp.ct branch. I'm going to debug this in more detail as soon as I get time. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From naresh_raga at yahoo.co.in Sun May 30 14:40:38 2010 From: naresh_raga at yahoo.co.in (naresh raga) Date: Mon, 31 May 2010 03:10:38 +0530 (IST) Subject: [Xorp-users] Definition for BGP damping parameters are not defined in user manual Message-ID: <278740.86054.qm@web94805.mail.in2.yahoo.com> Hello Ben, In the Xorp User Manual,BGP damping parameters? in the configuration syntax have not been defined.Also their default values and the ranges to be used have not been mentioned in the manual. 1)half-life: int 2) max-suppress: int 3)reuse: int 4)suppress: int Can you please suggest me other options (if you have idea)where I can get the definitions of the above parameters.Any xorp related documents or links that would be helpful. Thank you, T.Raga Naresh. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100531/7d94f5a6/attachment.html From greearb at candelatech.com Sun May 30 16:21:54 2010 From: greearb at candelatech.com (Ben Greear) Date: Sun, 30 May 2010 16:21:54 -0700 Subject: [Xorp-users] Definition for BGP damping parameters are not defined in user manual In-Reply-To: <278740.86054.qm@web94805.mail.in2.yahoo.com> References: <278740.86054.qm@web94805.mail.in2.yahoo.com> Message-ID: <4C02F312.3070207@candelatech.com> On 05/30/2010 02:40 PM, naresh raga wrote: > Hello Ben, > In the Xorp User Manual,BGP damping parameters in the configuration > syntax have not been defined.Also their default values and the ranges to > be used have not been mentioned in the manual. > > 1)half-life: int > 2) max-suppress: int > 3)reuse: int > 4)suppress: int > > Can you please suggest me other options (if you have idea)where I can > get the definitions of the above parameters.Any xorp related documents > or links that would be helpful. The answer is probably somewhere in the bgp/* code, but I don't have time right now to look closer. You might try some recursive greps to see if you can find anything. You might try google as well...likely that info is defined in RFCs somewhere and hopefully xorp already adheres to that. I'll take a closer look later this evening if I get a chance. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon May 31 11:04:28 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 31 May 2010 11:04:28 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <4BFFF6DC.6020007@candelatech.com> References: <383440.24329.qm@web94806.mail.in2.yahoo.com> <4BFFF6DC.6020007@candelatech.com> Message-ID: <4C03FA2C.6070809@candelatech.com> On 05/28/2010 10:01 AM, Ben Greear wrote: >> Hi Ben, >> I just want to inform you that the patch provided by Pavlin is not working >> properly.I have tried to insert some 1000 routes into kernel routing table >> and all the routes were not being advertised by OSPF. >> This is for your information as you have added this patch to your xorp.ct. > > Can you explain your test case in detail so that I might try to reproduce > it in xorp.ct? For instance, how are you adding the routes? How many > of the routes *do* show up in OSPF? Same routes show up each time? I just tested this with xorp.ct. I was able to create 2000 routes in a tight loop and have them properly propagated to a peer OSPF router. This is on an embedded Atom processor system running two Xorp instances peered through a 1.5Mbps emulated connection. I added a script: tests/add_routes.pl to xorp.ct to generate these routes. It could easily be tweaked to work with other configs, but right now it's hard-coded to my specific setup. So, if you can reproduce the error in xorp.ct, then I'm interested to know more about how you are creating routes, but it appears to work fine in xorp.ct. I'm going to put xorp.ct on github today if all goes well, so even if you can't check it out from our dmz.candelatech.com machine, you should be able to get it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com