From M.Handley at cs.ucl.ac.uk Mon Mar 1 03:55:39 2010 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Mon, 1 Mar 2010 11:55:39 +0000 Subject: [Xorp-hackers] Future Xorp development? In-Reply-To: <112362.22753.qm@web58708.mail.re1.yahoo.com> References: <4B884F89.4080507@candelatech.com> <112362.22753.qm@web58708.mail.re1.yahoo.com> Message-ID: <84a612dd1003010355s55cd084amd5f2470d4c105fd3@mail.gmail.com> On 27 February 2010 13:27, Li Zhao wrote: > I am curious. Because of that ex-Xorp Inc, there could not have been changes to xorp code? XORP Inc's focus had moved away from layer 3 routing, even prior to its demise. So here's where we stand. The XORP code is GPLed and on SourceForge. The demise of XORP Inc does not affect that. The mailing lists are still at ICSI, and also are unaffected. They're been administered by Atanu and Pavlin since long before XORP Inc existed. The DNS and Web servers were run out of XORP, Inc, but have since moved to safe harbour on some of my machines here at UCL in London. We have plenty of resources to maintain them here indefinitely. There is every intention that the XORP project will move forwards to greater things in the future. What we don't have at the moment are any full-time staff, but open source projects often don't have full time staff. There are however, many things in the codebase that would benefit from more active development and support. How to achieve that remains to be seen. Mark XORP project founder http://www.cs.ucl.ac.uk/staff/M.Handley/ From lizhaous2000 at yahoo.com Fri Mar 5 07:57:47 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 5 Mar 2010 07:57:47 -0800 (PST) Subject: [Xorp-hackers] VRRP error In-Reply-To: <519882.69985.qm@web58706.mail.re1.yahoo.com> Message-ID: <863485.47019.qm@web58707.mail.re1.yahoo.com> The way to fix assert crash I think is in the function prepare_advertisement to resize the data.size to VRRP_MAX_PACKET_SIZE because the last packet sending already resize it to some smaller size. Then the problem happened in fea because I always saw "NO I/O Link plugin to send a link raw packet ...". Anybody knows what this "I/O Link Plugin" means? Thanks. Li --- On Sat, 2/27/10, Li Zhao wrote: > From: Li Zhao > Subject: Re: [Xorp-hackers] VRRP error > To: "Ben Greear" > Cc: xorp-hackers at icir.org > Date: Saturday, February 27, 2010, 8:23 AM > I tried to remove those two assertion > before, but MAC wno't be updated and there were some other > problems. Now what I found was fea has some thing wrong. > During debugging, I will post any findings as soon as > possible. > > Thanks > > --- On Fri, 2/26/10, Ben Greear > wrote: > > > From: Ben Greear > > Subject: Re: [Xorp-hackers] VRRP error > > To: "Li Zhao" > > Cc: "Eric S. Johnson" , > xorp-hackers at icir.org > > Date: Friday, February 26, 2010, 4:59 PM > > On 02/26/2010 01:01 PM, Li Zhao > > wrote: > > > Actually the configuration is very simple to > reproduce > > the problem on Linux. > > > > I tried starting this on my system, and get an > assertion. > > > > I ran it with: > > /usr/local/xorp/bin/xorp_rtrmgr -b > /root/xorp_vrrp.conf > > > > The config file is exactly as you posted. > > > > [ 2010/02/26 13:53:35 WARNING xorp_fea FEA ] Clearing > > iftree: copy of user-config > > [ 2010/02/26 13:53:36? FATAL xorp_vrrp:13019 VRRP > > vrrp_packet.cc:173 finalize ] Assertion (_data.size() > == > > _data.capacity() && _data.size() == > > VRRP_MAX_PACKET_SIZE) failed > > [ 2010/02/26 13:53:36? ERROR xorp_rtrmgr:12925 > RTRMGR > > module_manager.cc:764 done_cb ] Command > > "/usr/local/xorp/vrrp/xorp_vrrp": terminated with > signal 6. > > > > I ran it again with the latest code (mostly changes > Eric > > has been testing), and > > now it crashes: > > > > [ 2010/02/26 13:57:34 WARNING xorp_fea XrlFeaTarget ] > > Handling method for ifmgr/0.1/create_mac failed: > XrlCmdError > > 102 Command failed Cannot add MAC address > 0:0:5e:0:1:64 on > > interface eth1: MAC already added > > [ 2010/02/26 13:57:34? FATAL xorp_vrrp:14729 VRRP > > vrrp_target.cc:362 xrl_cb ] XRL error: 102 Command > failed > > Cannot add MAC address 0:0:5e:0:1:64 on interface > eth1: MAC > > already added > > [ 2010/02/26 13:57:34? ERROR xorp_rtrmgr:14644 > RTRMGR > > module_manager.cc:764 done_cb ] Command > > "/usr/local/xorp/vrrp/xorp_vrrp": terminated with > signal 6. > > > > > > Looks like it's time to remove some asserts :P > > > > > > 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 Fri Mar 5 08:20:24 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 05 Mar 2010 08:20:24 -0800 Subject: [Xorp-hackers] VRRP error In-Reply-To: <863485.47019.qm@web58707.mail.re1.yahoo.com> References: <863485.47019.qm@web58707.mail.re1.yahoo.com> Message-ID: <4B912F48.2000606@candelatech.com> On 03/05/2010 07:57 AM, Li Zhao wrote: > The way to fix assert crash I think is in the function > prepare_advertisement to resize the data.size to VRRP_MAX_PACKET_SIZE > because the last packet sending already resize it to some smaller size. > > Then the problem happened in fea because I always saw "NO I/O Link plugin > to send a link raw packet ...". Anybody knows what this "I/O Link Plugin" > means? It means you don't have pcap support compiled in, probably. Are you still trying 1.6? What OS are you using? Thanks, Ben > > Thanks. > > Li > > --- On Sat, 2/27/10, Li Zhao wrote: > >> From: Li Zhao >> Subject: Re: [Xorp-hackers] VRRP error >> To: "Ben Greear" >> Cc: xorp-hackers at icir.org >> Date: Saturday, February 27, 2010, 8:23 AM >> I tried to remove those two assertion >> before, but MAC wno't be updated and there were some other >> problems. Now what I found was fea has some thing wrong. >> During debugging, I will post any findings as soon as >> possible. >> >> Thanks >> >> --- On Fri, 2/26/10, Ben Greear >> wrote: >> >>> From: Ben Greear >>> Subject: Re: [Xorp-hackers] VRRP error >>> To: "Li Zhao" >>> Cc: "Eric S. Johnson", >> xorp-hackers at icir.org >>> Date: Friday, February 26, 2010, 4:59 PM >>> On 02/26/2010 01:01 PM, Li Zhao >>> wrote: >>>> Actually the configuration is very simple to >> reproduce >>> the problem on Linux. >>> >>> I tried starting this on my system, and get an >> assertion. >>> >>> I ran it with: >>> /usr/local/xorp/bin/xorp_rtrmgr -b >> /root/xorp_vrrp.conf >>> >>> The config file is exactly as you posted. >>> >>> [ 2010/02/26 13:53:35 WARNING xorp_fea FEA ] Clearing >>> iftree: copy of user-config >>> [ 2010/02/26 13:53:36 FATAL xorp_vrrp:13019 VRRP >>> vrrp_packet.cc:173 finalize ] Assertion (_data.size() >> == >>> _data.capacity()&& _data.size() == >>> VRRP_MAX_PACKET_SIZE) failed >>> [ 2010/02/26 13:53:36 ERROR xorp_rtrmgr:12925 >> RTRMGR >>> module_manager.cc:764 done_cb ] Command >>> "/usr/local/xorp/vrrp/xorp_vrrp": terminated with >> signal 6. >>> >>> I ran it again with the latest code (mostly changes >> Eric >>> has been testing), and >>> now it crashes: >>> >>> [ 2010/02/26 13:57:34 WARNING xorp_fea XrlFeaTarget ] >>> Handling method for ifmgr/0.1/create_mac failed: >> XrlCmdError >>> 102 Command failed Cannot add MAC address >> 0:0:5e:0:1:64 on >>> interface eth1: MAC already added >>> [ 2010/02/26 13:57:34 FATAL xorp_vrrp:14729 VRRP >>> vrrp_target.cc:362 xrl_cb ] XRL error: 102 Command >> failed >>> Cannot add MAC address 0:0:5e:0:1:64 on interface >> eth1: MAC >>> already added >>> [ 2010/02/26 13:57:34 ERROR xorp_rtrmgr:14644 >> RTRMGR >>> module_manager.cc:764 done_cb ] Command >>> "/usr/local/xorp/vrrp/xorp_vrrp": terminated with >> signal 6. >>> >>> >>> Looks like it's time to remove some asserts :P >>> >>> >>> 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 >> > > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Fri Mar 5 10:31:19 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 5 Mar 2010 10:31:19 -0800 (PST) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4B912F48.2000606@candelatech.com> Message-ID: <629181.68790.qm@web58706.mail.re1.yahoo.com> Yes, i am still using 1.6 on the Linux. I have libpcap under /usr/lib and I also saw allocate_io_link_plugins called. I do not underdtand that part of code now. --- On Fri, 3/5/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Friday, March 5, 2010, 11:20 AM > On 03/05/2010 07:57 AM, Li Zhao > wrote: > > The way to fix assert crash I think is in the > function > > prepare_advertisement to resize the data.size to > VRRP_MAX_PACKET_SIZE > > because the last packet sending already resize it to > some smaller size. > > > > Then the problem happened in fea because I always saw > "NO I/O Link plugin > > to send a link raw packet ...". Anybody knows what > this "I/O Link Plugin" > > means? > > It means you don't have pcap support compiled in, > probably. > > Are you still trying 1.6? > > What OS are you using? > > Thanks, > Ben > > > > > Thanks. > > > > Li > > > > --- On Sat, 2/27/10, Li Zhao? > wrote: > > > >> From: Li Zhao > >> Subject: Re: [Xorp-hackers] VRRP error > >> To: "Ben Greear" > >> Cc: xorp-hackers at icir.org > >> Date: Saturday, February 27, 2010, 8:23 AM > >> I tried to remove those two assertion > >> before, but MAC wno't be updated and there were > some other > >> problems. Now what I found was fea has some thing > wrong. > >> During debugging, I will post any findings as soon > as > >> possible. > >> > >> Thanks > >> > >> --- On Fri, 2/26/10, Ben Greear > >> wrote: > >> > >>> From: Ben Greear > >>> Subject: Re: [Xorp-hackers] VRRP error > >>> To: "Li Zhao" > >>> Cc: "Eric S. Johnson", > >> xorp-hackers at icir.org > >>> Date: Friday, February 26, 2010, 4:59 PM > >>> On 02/26/2010 01:01 PM, Li Zhao > >>> wrote: > >>>> Actually the configuration is very simple > to > >> reproduce > >>> the problem on Linux. > >>> > >>> I tried starting this on my system, and get > an > >> assertion. > >>> > >>> I ran it with: > >>> /usr/local/xorp/bin/xorp_rtrmgr -b > >> /root/xorp_vrrp.conf > >>> > >>> The config file is exactly as you posted. > >>> > >>> [ 2010/02/26 13:53:35 WARNING xorp_fea FEA ] > Clearing > >>> iftree: copy of user-config > >>> [ 2010/02/26 13:53:36? FATAL > xorp_vrrp:13019 VRRP > >>> vrrp_packet.cc:173 finalize ] Assertion > (_data.size() > >> == > >>> _data.capacity()&&? _data.size() > == > >>> VRRP_MAX_PACKET_SIZE) failed > >>> [ 2010/02/26 13:53:36? ERROR > xorp_rtrmgr:12925 > >> RTRMGR > >>> module_manager.cc:764 done_cb ] Command > >>> "/usr/local/xorp/vrrp/xorp_vrrp": terminated > with > >> signal 6. > >>> > >>> I ran it again with the latest code (mostly > changes > >> Eric > >>> has been testing), and > >>> now it crashes: > >>> > >>> [ 2010/02/26 13:57:34 WARNING xorp_fea > XrlFeaTarget ] > >>> Handling method for ifmgr/0.1/create_mac > failed: > >> XrlCmdError > >>> 102 Command failed Cannot add MAC address > >> 0:0:5e:0:1:64 on > >>> interface eth1: MAC already added > >>> [ 2010/02/26 13:57:34? FATAL > xorp_vrrp:14729 VRRP > >>> vrrp_target.cc:362 xrl_cb ] XRL error: 102 > Command > >> failed > >>> Cannot add MAC address 0:0:5e:0:1:64 on > interface > >> eth1: MAC > >>> already added > >>> [ 2010/02/26 13:57:34? ERROR > xorp_rtrmgr:14644 > >> RTRMGR > >>> module_manager.cc:764 done_cb ] Command > >>> "/usr/local/xorp/vrrp/xorp_vrrp": terminated > with > >> signal 6. > >>> > >>> > >>> Looks like it's time to remove some asserts > :P > >>> > >>> > >>> 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 > >> > > > > > > > > > -- > Ben Greear > Candela Technologies Inc? http://www.candelatech.com > From bms at incunabulum.net Sat Mar 6 04:20:21 2010 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 06 Mar 2010 12:20:21 +0000 Subject: [Xorp-hackers] Recent developments and patch submission Message-ID: <4B924885.1090207@incunabulum.net> Hi all, Regardless of the current situation with XORP, Inc., it's important that contributors stick to a few ground rules regarding patch submissions. The workflow preferred is that patches intended for incorporation, should go to the Trac database on SourceForge in the first instance. This does require creating a SourceForge account. This workflow is no different from e.g. the Thrift project, which is hosted on Apache JIRA. It's great that folk are discussing patches on the lists, and trying to get issues addressed here, but from a maintenance point of view, we can't really use the mailing lists as a patch queue, and some basic procedures do need to be followed. This is especially important in the light of the current funding and organisation situation. Please do remember that any maintenance that happens on XORP, for the foreseeable future, will be performed on an unpaid volunteer basis. thanks, BMS From bms at incunabulum.net Sat Mar 6 04:30:50 2010 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 06 Mar 2010 12:30:50 +0000 Subject: [Xorp-hackers] Future Xorp development? In-Reply-To: <4B884F89.4080507@candelatech.com> References: <4B884F89.4080507@candelatech.com> Message-ID: <4B924AFA.6010907@incunabulum.net> On 02/26/10 22:47, Ben Greear wrote: > Considering Xorp.inc folded, I'm curious if anyone (with upstream commit privileges) > is planning any more significant changes to xorp? > > In particular, does anyone still care about using libboost? If not, I'm very tempted > to remove it to get rid of a big external dependency. > As discussed off-list: We are using Boost, and we're sticking to it. We don't use libboost, but we do use its regex. That is the state of the changes which went in up until the XORP, Inc. business failure. What people do in their own branches is their business, but any official or semi-official supported offering in future would continue to use it, as it's a requirement for the IPC refactoring which was long overdue. It seems reasonable that a large C++ system such as XORP, make use of C++ innovations such as Boost, and the change would have happened a long time ago, had it not been for organisational confusion, and a lack of developer traction. One big problem with XORP at the moment is that a number of organisations, it seems, have been using the code, but haven't publicly disclosed their interest, or participated in development process, fund-raising, etc. regards, BMS From bms at incunabulum.net Sat Mar 6 04:46:33 2010 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 06 Mar 2010 12:46:33 +0000 Subject: [Xorp-hackers] Show of hands on users please Message-ID: <4B924EA9.20802@incunabulum.net> Hi all, Given the recent XORP, Inc. business failure, it's understandable that people are concerned about the future of the open source work product ongoing. We really need a show of hands, on organisations who may be using XORP, in a commercial or semi-commercial capacity. I have received some leads in this regard, and will be following up as time permits. If you or your organisation are using XORP, please get in touch. There is a strategy which needs to be followed in order to get the project back to healthy status, however, this may not be 100% compatible with a volunteer-based way of doing things. An interim 1.7 release is a possibility. This has taken a long time because the release management process has been starved of resources. It is likely that not all of the boxes which we'd like for that release to be ticked, would be ticked. regards, BMS From greearb at candelatech.com Sat Mar 6 08:39:39 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 06 Mar 2010 08:39:39 -0800 Subject: [Xorp-hackers] Recent developments and patch submission In-Reply-To: <4B924885.1090207@incunabulum.net> References: <4B924885.1090207@incunabulum.net> Message-ID: <4B92854B.1000201@candelatech.com> On 03/06/2010 04:20 AM, Bruce Simpson wrote: > Hi all, > > Regardless of the current situation with XORP, Inc., it's important that > contributors stick to a few ground rules regarding patch submissions. > > The workflow preferred is that patches intended for incorporation, > should go to the Trac database on SourceForge in the first instance. > This does require creating a SourceForge account. This workflow is no > different from e.g. the Thrift project, which is hosted on Apache JIRA. > > It's great that folk are discussing patches on the lists, and trying to > get issues addressed here, but from a maintenance point of view, we > can't really use the mailing lists as a patch queue, and some basic > procedures do need to be followed. > > This is especially important in the light of the current funding and > organisation situation. Please do remember that any maintenance that > happens on XORP, for the foreseeable future, will be performed on an > unpaid volunteer basis. Especially with the demise of Xorp.inc, this is now an open-source project or nothing at all. If you can't get patches actively accepted or bug reports actively debugged, then no developer or user is going to stay active for long. So, unless you specifically ask me to stop posting to this list, I'm going to continue to try to accept patches that fix problems into my tree, even if they are not perfect, and I'm going to continue to talk about it on the mailing list. I'm using git for my source control, so it's trivial to view/extract each patch that goes in later should anyone ever want to accept it upstream. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sat Mar 6 08:42:52 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 06 Mar 2010 08:42:52 -0800 Subject: [Xorp-hackers] Show of hands on users please In-Reply-To: <4B924EA9.20802@incunabulum.net> References: <4B924EA9.20802@incunabulum.net> Message-ID: <4B92860C.9010809@candelatech.com> On 03/06/2010 04:46 AM, Bruce Simpson wrote: > Hi all, > > Given the recent XORP, Inc. business failure, it's understandable that > people are concerned about the future of the open source work product > ongoing. > > We really need a show of hands, on organisations who may be using XORP, > in a commercial or semi-commercial capacity. I have received some leads > in this regard, and will be following up as time permits. If you or your > organisation are using XORP, please get in touch. > > There is a strategy which needs to be followed in order to get the > project back to healthy status, however, this may not be 100% compatible > with a volunteer-based way of doing things. > > An interim 1.7 release is a possibility. This has taken a long time > because the release management process has been starved of resources. It > is likely that not all of the boxes which we'd like for that release to > be ticked, would be ticked. We (Candela Technologies) are using it for virtualized routing in our network testing tools. I have little interest in directly funding an outside organization to work on Xorp, but we use internal resources to develop and test it for our purposes, and might consider hiring contractors to work on xorp if we ever have need. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Sun Mar 7 08:21:47 2010 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 07 Mar 2010 16:21:47 +0000 Subject: [Xorp-hackers] Recent developments and patch submission In-Reply-To: <4B92854B.1000201@candelatech.com> References: <4B924885.1090207@incunabulum.net> <4B92854B.1000201@candelatech.com> Message-ID: <4B93D29B.1090705@incunabulum.net> Ben, With all due respect, I think the point is that it always has been, or at least, that has always been the intention, that the body of code, currently known as XORP, remain open source. On 03/06/10 16:39, Ben Greear wrote: > ... > Especially with the demise of Xorp.inc, this is now an open-source > project > or nothing at all. If you can't get patches actively accepted or bug > reports > actively debugged, then no developer or user is going to stay active for > long. I can't apologise enough for what has happened with XORP, Inc., even though it was neither my decision nor my responsibility. Ultimately, private investor's money, and a degree of credibility, has been lost. Unfortunately, this does affect the sustainability of any effort which follows. It is going to make it more difficult to attract investment on a commercial basis -- word gets around. I think I speak for the original instigators when I say that it was our shared hope that introducing a healthy commercial interest would vitalize development. Again, unfortunately, this hasn't happened, due to circumstances beyond my control. Having said all this, basic ground rules do need to be followed. It just makes life much easier for collaborative development if patches intended for submission go in an issue tracker. > > So, unless you specifically ask me to stop posting to this list, I'm > going to continue to try > to accept patches that fix problems into my tree, even if they are not > perfect, and I'm going to continue to talk about it on the mailing list. Anyone is free to re-use the XORP source code as per the terms of its license. However, solving more general issues with piecemeal patches in the here and now, is going to take more effort and thought. It is regrettable that your requirements for virtualization weren't part of the development roadmap. Had they been, and had we had a better platform for collaborative development from the outset, then there might not be the wide gap that exists between your private git tree, and SVN, now. > > I'm using git for my source control, so it's trivial to view/extract > each patch > that goes in later should anyone ever want to accept it upstream. I would argue that the use of git may make code sharing trivial for those who use git and are familiar with it, but probably not for the majority of the open source user base. Even for developers, hosting code separately from a main line of development makes things that much more difficult, even if they use the same source-code control technology. It would be fair to say that there's infinite demand for free goods. Unfortunately, sanity needs to prevail -- open source is a work product, not a free lunch. regards, BMS From greearb at candelatech.com Sun Mar 7 09:13:30 2010 From: greearb at candelatech.com (Ben Greear) Date: Sun, 07 Mar 2010 09:13:30 -0800 Subject: [Xorp-hackers] Recent developments and patch submission In-Reply-To: <4B93D29B.1090705@incunabulum.net> References: <4B924885.1090207@incunabulum.net> <4B92854B.1000201@candelatech.com> <4B93D29B.1090705@incunabulum.net> Message-ID: <4B93DEBA.3050307@candelatech.com> On 03/07/2010 08:21 AM, Bruce Simpson wrote: > Ben, > I can't apologise enough for what has happened with XORP, Inc., even > though it was neither my decision nor my responsibility. Ultimately, > private investor's money, and a degree of credibility, has been lost. As soon as xorp was made GPL, and xorp.inc made the decision not to publish their changes upstream as they made them, then it ceased to make much difference either way. So, I'm sorry for the folks that lost their jobs, but other than that, it doesn't seem to have made a large impact in the daily operations of xorp @ sourceforge. > Unfortunately, this does affect the sustainability of any effort which > follows. It is going to make it more difficult to attract investment on > a commercial basis -- word gets around. There are people offering cash on the mailing list for help debugging xorp configuration. If I weren't already running a company, I'd try to fill that need. For that matter, I might consider it anyway. It doesn't take a big company to do this..a single engineer who understood routing and understood xorp at least a little bit could do this on their own. > I think I speak for the original instigators when I say that it was our > shared hope that introducing a healthy commercial interest would > vitalize development. Again, unfortunately, this hasn't happened, due to > circumstances beyond my control. > > Having said all this, basic ground rules do need to be followed. It just > makes life much easier for collaborative development if patches intended > for submission go in an issue tracker. A project needs an active leader or set of leaders. As far as I know, only you have commit priv for the svn repo. If you are not actively picking stuff out of the tracker and fixing up any bugs and/or patches in there, then who is? If you are waiting for xorp.inc.2, then how long will you wait? What happens if no one ever funds a xorp.inc.2? Even while xorp.inc was active and had cash, there was no one else committing to the public svn repo. I think that xorp.inc missed the whole point of how to run an open-source project, but that is water under the bridge now. > However, solving more general issues with piecemeal patches in the here > and now, is going to take more effort and thought. > > It is regrettable that your requirements for virtualization weren't part > of the development roadmap. Had they been, and had we had a better > platform for collaborative development from the outset, then there might > not be the wide gap that exists between your private git tree, and SVN, > now. A great deal of my code is just making sure xorp handles interfaces coming and going w/out asserting and crashing. Nothing in my code should hurt any 'normal' use of xorp either. If it does, then it's a bug and I will fix it. I think that someone who has interest and at least enough time to commit patches should start actively doing so to the svn repo. I think that the patches committed do not have to be perfect, but they should be better than what exists. Performance is way less important than correctness. >> I'm using git for my source control, so it's trivial to view/extract >> each patch >> that goes in later should anyone ever want to accept it upstream. > > I would argue that the use of git may make code sharing trivial for > those who use git and are familiar with it, but probably not for the > majority of the open source user base. Anyone that can deal with xorp in any fashion can: * Install git and gitk * Clone a repository * run 'gitk' to view patches and history. * use gitk to export patches to text and apply them however they want. For that matter, one can directly import back into svn from a git repo. With commit privs, I could dump my entire tree back into svn and retain the history and individual patch sets. > Even for developers, hosting code separately from a main line of > development makes things that much more difficult, even if they use the > same source-code control technology. I'd love to get all of my patches upstream. Or, if you want to give me my own svn tree on source-forge, I'll happily push stuff there. But, as thing stand now, either I keep all my changes totally private like it seems other developers are, or I host my own tree since upstream is effectively blocked. > It would be fair to say that there's infinite demand for free goods. > Unfortunately, sanity needs to prevail -- open source is a work product, > not a free lunch. If you are implying that we should be offering cash for xorp.inc.2 instead of patches, I think you are wrong. I have written and made freely available more xorp code than xorp.inc (with the distinction being 'made freely available'). Lots of other users have also contributed small but critical bug fixes and testing efforts. These small bug fixes add up, and that is what makes an open source project successful. But, the project must be able to effectively absorb these patches in a timely manner. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Sun Mar 7 09:34:48 2010 From: bms at incunabulum.net (Bruce Simpson) Date: Sun, 07 Mar 2010 17:34:48 +0000 Subject: [Xorp-hackers] Recent developments and patch submission In-Reply-To: <4B93DEBA.3050307@candelatech.com> References: <4B924885.1090207@incunabulum.net> <4B92854B.1000201@candelatech.com> <4B93D29B.1090705@incunabulum.net> <4B93DEBA.3050307@candelatech.com> Message-ID: <4B93E3B8.4010404@incunabulum.net> Ben, I'd love to respond to your points in detail, however, I fear we have drifted off-topic here. My original message to you, was merely to point out that in order for any further work to happen on the XORP source tree, whilst we are in this period of uncertainty with the project, basic procedures still need to be followed. This is doubly important, given that there is currently no paid XORP support function. It's unreasonable to expect volunteers to wade through months of mailing list traffic looking for something to do. Whilst I'd agree mailing lists are great for sounding out ideas, or working through the details of a patch, they are not terribly useful for tracking ongoing issues with the source tree. In response to your points re "keeping all my changes totally private like it seems other developers are": that isn't happening, to the best of my knowledge, which is why I have asked for a show of hands in good faith. regards, BMS From greearb at candelatech.com Mon Mar 8 15:07:28 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 08 Mar 2010 15:07:28 -0800 Subject: [Xorp-hackers] Boost and Win32 update In-Reply-To: <4AFFCA23.2020209@incunabulum.net> References: <4AFD911A.307@incunabulum.net> <4AFFCA23.2020209@incunabulum.net> Message-ID: <4B958330.70002@candelatech.com> On 11/15/2009 01:30 AM, Bruce Simpson wrote: > Bruce Simpson wrote: > The only other change to date I've made in my private Boost branch is to > replace the use of pcreposix for regular expressions, with Boost's C > regex API. > It has a C++ API, although when I quickly hacked in its use, it didn't > function as expected, so I reverted to the C API. Sorry to dredge up an old email, but today I started looking closely at boost in xorp. Several things: 1) SConstruct calls api to check boost existence, but it then just ignores the return values. Just as well since it seems to require an ultra-modern version of boost. I relaxed that and older versions seem to work just fine. 2) As far as I can tell, there is no need for pcreposix. It seems that at least on Linux, all you need to do is include and link with standard libraries. I left the pcreposix logic in but commented out in case other platforms need it. 3) The boost::noncopyable is nice, but not worth requiring boost. So, I made boost optional in my tree. Unless the user specifically does enable_boost=yes and also has boost properly installed, my tree will build w/out boost. It uses the standard regex, and I made a small xorp_noncopyable class to replace boost::noncopyable. #ifdef logic determines which noncopyable logic is used. This will make it easier for me to deploy Xorp since boost doesn't come standard in Fedora (though it's easy enough to install if the user knows to do that). It also makes my live-cd smaller (no libboost), and might help others who are also constrained by space. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Tue Mar 9 07:30:16 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Tue, 9 Mar 2010 07:30:16 -0800 (PST) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4B912F48.2000606@candelatech.com> Message-ID: <555620.96974.qm@web58708.mail.re1.yahoo.com> You are right. In my build "HAVE_PCAP" is not defined. Do I need to turn on compile flag "HAVE_PCAP_SENDPACKET" too? Thanks. --- On Fri, 3/5/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Friday, March 5, 2010, 11:20 AM > On 03/05/2010 07:57 AM, Li Zhao > wrote: > > The way to fix assert crash I think is in the > function > > prepare_advertisement to resize the data.size to > VRRP_MAX_PACKET_SIZE > > because the last packet sending already resize it to > some smaller size. > > > > Then the problem happened in fea because I always saw > "NO I/O Link plugin > > to send a link raw packet ...". Anybody knows what > this "I/O Link Plugin" > > means? > > It means you don't have pcap support compiled in, > probably. > > Are you still trying 1.6? > > What OS are you using? > > Thanks, > Ben > > > > > Thanks. > > > > Li > > > > --- On Sat, 2/27/10, Li Zhao? > wrote: > > > >> From: Li Zhao > >> Subject: Re: [Xorp-hackers] VRRP error > >> To: "Ben Greear" > >> Cc: xorp-hackers at icir.org > >> Date: Saturday, February 27, 2010, 8:23 AM > >> I tried to remove those two assertion > >> before, but MAC wno't be updated and there were > some other > >> problems. Now what I found was fea has some thing > wrong. > >> During debugging, I will post any findings as soon > as > >> possible. > >> > >> Thanks > >> > >> --- On Fri, 2/26/10, Ben Greear > >> wrote: > >> > >>> From: Ben Greear > >>> Subject: Re: [Xorp-hackers] VRRP error > >>> To: "Li Zhao" > >>> Cc: "Eric S. Johnson", > >> xorp-hackers at icir.org > >>> Date: Friday, February 26, 2010, 4:59 PM > >>> On 02/26/2010 01:01 PM, Li Zhao > >>> wrote: > >>>> Actually the configuration is very simple > to > >> reproduce > >>> the problem on Linux. > >>> > >>> I tried starting this on my system, and get > an > >> assertion. > >>> > >>> I ran it with: > >>> /usr/local/xorp/bin/xorp_rtrmgr -b > >> /root/xorp_vrrp.conf > >>> > >>> The config file is exactly as you posted. > >>> > >>> [ 2010/02/26 13:53:35 WARNING xorp_fea FEA ] > Clearing > >>> iftree: copy of user-config > >>> [ 2010/02/26 13:53:36? FATAL > xorp_vrrp:13019 VRRP > >>> vrrp_packet.cc:173 finalize ] Assertion > (_data.size() > >> == > >>> _data.capacity()&&? _data.size() > == > >>> VRRP_MAX_PACKET_SIZE) failed > >>> [ 2010/02/26 13:53:36? ERROR > xorp_rtrmgr:12925 > >> RTRMGR > >>> module_manager.cc:764 done_cb ] Command > >>> "/usr/local/xorp/vrrp/xorp_vrrp": terminated > with > >> signal 6. > >>> > >>> I ran it again with the latest code (mostly > changes > >> Eric > >>> has been testing), and > >>> now it crashes: > >>> > >>> [ 2010/02/26 13:57:34 WARNING xorp_fea > XrlFeaTarget ] > >>> Handling method for ifmgr/0.1/create_mac > failed: > >> XrlCmdError > >>> 102 Command failed Cannot add MAC address > >> 0:0:5e:0:1:64 on > >>> interface eth1: MAC already added > >>> [ 2010/02/26 13:57:34? FATAL > xorp_vrrp:14729 VRRP > >>> vrrp_target.cc:362 xrl_cb ] XRL error: 102 > Command > >> failed > >>> Cannot add MAC address 0:0:5e:0:1:64 on > interface > >> eth1: MAC > >>> already added > >>> [ 2010/02/26 13:57:34? ERROR > xorp_rtrmgr:14644 > >> RTRMGR > >>> module_manager.cc:764 done_cb ] Command > >>> "/usr/local/xorp/vrrp/xorp_vrrp": terminated > with > >> signal 6. > >>> > >>> > >>> Looks like it's time to remove some asserts > :P > >>> > >>> > >>> 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 > >> > > > > > > > > > -- > Ben Greear > Candela Technologies Inc? http://www.candelatech.com > From greearb at candelatech.com Tue Mar 9 07:36:19 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 09 Mar 2010 07:36:19 -0800 Subject: [Xorp-hackers] VRRP error In-Reply-To: <555620.96974.qm@web58708.mail.re1.yahoo.com> References: <555620.96974.qm@web58708.mail.re1.yahoo.com> Message-ID: <4B966AF3.8050906@candelatech.com> On 03/09/2010 07:30 AM, Li Zhao wrote: > You are right. In my build "HAVE_PCAP" is not defined. Do I need to turn > on compile flag "HAVE_PCAP_SENDPACKET" too? You should figure out why it isn't defined by the configure logic. Probably it isn't installed or detected properly on your system. Likely this just works in SVN and/or my branch. Sticking with 1.6 is going to keep you from taking advantage of any bug fixes that other folks put into the new code. It seems several people are interested in VRRP, so if you move to the development branch, it's likely you can pool your efforts by posting patches and discussing bugs you're finding. I'll merge anything that looks useful into my tree in case you want to base off of it. If there are any technical reasons to not move to my tree or SVN, please let me know..maybe I can address them. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Tue Mar 9 07:36:46 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Tue, 9 Mar 2010 07:36:46 -0800 (PST) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4B884442.5000506@candelatech.com> Message-ID: <456208.55477.qm@web58702.mail.re1.yahoo.com> The problem is not those asserts. The problem is that VrrpPacket instance is used multiple times, so each time before another packet is sent, the _data in VrrpPacket should resize to default which is VRRP_MAX_PACKET_SIZE. I updated vrrp.cc, vrrp_packet.h, vrrp_packet.cc and that seems better now. I will post the change later. --- On Fri, 2/26/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: "Eric S. Johnson" , xorp-hackers at icir.org > Date: Friday, February 26, 2010, 4:59 PM > On 02/26/2010 01:01 PM, Li Zhao > wrote: > > Actually the configuration is very simple to reproduce > the problem on Linux. > > I tried starting this on my system, and get an assertion. > > I ran it with: > /usr/local/xorp/bin/xorp_rtrmgr -b /root/xorp_vrrp.conf > > The config file is exactly as you posted. > > [ 2010/02/26 13:53:35 WARNING xorp_fea FEA ] Clearing > iftree: copy of user-config > [ 2010/02/26 13:53:36? FATAL xorp_vrrp:13019 VRRP > vrrp_packet.cc:173 finalize ] Assertion (_data.size() == > _data.capacity() && _data.size() == > VRRP_MAX_PACKET_SIZE) failed > [ 2010/02/26 13:53:36? ERROR xorp_rtrmgr:12925 RTRMGR > module_manager.cc:764 done_cb ] Command > "/usr/local/xorp/vrrp/xorp_vrrp": terminated with signal 6. > > I ran it again with the latest code (mostly changes Eric > has been testing), and > now it crashes: > > [ 2010/02/26 13:57:34 WARNING xorp_fea XrlFeaTarget ] > Handling method for ifmgr/0.1/create_mac failed: XrlCmdError > 102 Command failed Cannot add MAC address 0:0:5e:0:1:64 on > interface eth1: MAC already added > [ 2010/02/26 13:57:34? FATAL xorp_vrrp:14729 VRRP > vrrp_target.cc:362 xrl_cb ] XRL error: 102 Command failed > Cannot add MAC address 0:0:5e:0:1:64 on interface eth1: MAC > already added > [ 2010/02/26 13:57:34? ERROR xorp_rtrmgr:14644 RTRMGR > module_manager.cc:764 done_cb ] Command > "/usr/local/xorp/vrrp/xorp_vrrp": terminated with signal 6. > > > Looks like it's time to remove some asserts :P > > > Thanks, > Ben > > -- Ben Greear > Candela Technologies Inc? http://www.candelatech.com > > From lizhaous2000 at yahoo.com Tue Mar 9 07:46:36 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Tue, 9 Mar 2010 07:46:36 -0800 (PST) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4B966AF3.8050906@candelatech.com> Message-ID: <194549.59830.qm@web58702.mail.re1.yahoo.com> Yes, I am looking into why HAVE_PCAP is not defined in the config stage. I changed the build process for xorp source files. Also I built a proto type linux embedded system so I want to keep it stable for a while. Thirdly I am a dumbo to use svn development branch at this time stage. But I will move to the main branch when I am ready soon. So temporarily now I will post the proper patches to this list. If i have too much patch to commit I will think about a better way. --- On Tue, 3/9/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Tuesday, March 9, 2010, 10:36 AM > On 03/09/2010 07:30 AM, Li Zhao > wrote: > > You are right. In my build "HAVE_PCAP" is not defined. > Do I need to turn > > on compile flag "HAVE_PCAP_SENDPACKET" too? > > You should figure out why it isn't defined by the configure > logic. > Probably it isn't installed or detected properly on your > system. > > Likely this just works in SVN and/or my branch. > > Sticking with 1.6 is going to keep you from taking > advantage of any bug fixes that other > folks put into the new code.? It seems several people > are interested in VRRP, > so if you move to the development branch, it's likely you > can pool your > efforts by posting patches and discussing bugs you're > finding. > > I'll merge anything that looks useful into my tree in case > you want to > base off of it. > > If there are any technical reasons to not move to my tree > or SVN, please > let me know..maybe I can address them. > > Thanks, > Ben > > -- Ben Greear > Candela Technologies Inc? http://www.candelatech.com > > From greearb at candelatech.com Tue Mar 9 07:59:46 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 09 Mar 2010 07:59:46 -0800 Subject: [Xorp-hackers] VRRP error In-Reply-To: <194549.59830.qm@web58702.mail.re1.yahoo.com> References: <194549.59830.qm@web58702.mail.re1.yahoo.com> Message-ID: <4B967072.9070509@candelatech.com> On 03/09/2010 07:46 AM, Li Zhao wrote: > Yes, I am looking into why HAVE_PCAP is not defined in the config stage. > > I changed the build process for xorp source files. Also I built a proto type > linux embedded system so I want to keep it stable for a while. Thirdly I > am a dumbo to use svn development branch at this time stage. I prefer git to svn, as far as source code mgt goes. If you want to try out git, I can help (there is an easy way to import svn into git). I don't know how to use svn itself though... I got rid of boost requirement in my tree, so that might help with a tight embedded system. But, I understand wanting to keep with a known quantity. > > But I will move to the main branch when I am ready soon. So temporarily now > I will post the proper patches to this list. If i have too much patch to commit I will think about a better way. Sounds good. I'll apply what I can to my tree, at least. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Tue Mar 9 13:14:36 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Tue, 9 Mar 2010 13:14:36 -0800 (PST) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4B966AF3.8050906@candelatech.com> Message-ID: <93057.29371.qm@web58705.mail.re1.yahoo.com> I figured it out. Actually it is very simple. After I checked config.log I found misssing header file pcap.h, so I installed libpcap-devel on my development machine and rebuilt the xorp. Vrrp is running much better than before. If I run vrrp only on one router, the default ip address and virtual MAC are propagated to the network. But when I tried to set "ip ", it seems not taken. I am investigating this now. Also I need to run vrrp on two routers to test failover. --- On Tue, 3/9/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Tuesday, March 9, 2010, 10:36 AM > On 03/09/2010 07:30 AM, Li Zhao > wrote: > > You are right. In my build "HAVE_PCAP" is not defined. > Do I need to turn > > on compile flag "HAVE_PCAP_SENDPACKET" too? > > You should figure out why it isn't defined by the configure > logic. > Probably it isn't installed or detected properly on your > system. > > Likely this just works in SVN and/or my branch. > > Sticking with 1.6 is going to keep you from taking > advantage of any bug fixes that other > folks put into the new code.? It seems several people > are interested in VRRP, > so if you move to the development branch, it's likely you > can pool your > efforts by posting patches and discussing bugs you're > finding. > > I'll merge anything that looks useful into my tree in case > you want to > base off of it. > > If there are any technical reasons to not move to my tree > or SVN, please > let me know..maybe I can address them. > > Thanks, > Ben > > -- Ben Greear > Candela Technologies Inc? http://www.candelatech.com > > From szjaguar at 163.com Thu Mar 11 00:39:01 2010 From: szjaguar at 163.com (szjaguar) Date: Thu, 11 Mar 2010 16:39:01 +0800 (CST) Subject: [Xorp-hackers] Building Xorp SVN on Linux Fedora 12 xrl error Message-ID: I check out the latesd release from SVN. When I try to build xorp , I have a error : >/home/Hubin/StudioNow/xorp/LastSourceCode/xrl/scripts/clnt-gen --output-dir obj/x86_64-unknown-linux-gnu/xrl/interfaces xrl/interfaces/finder.xif In Xrl starting at line 16 in xrl/interfaces/finder.xif: Method name "&class_name:txt" has chars other than [A-Za-z][A-z0-9/_-]? >scons: *** [obj/x86_64-unknown-linux-gnu/xrl/interfaces/finder_xif.cc] Error 1 >scons: building terminated because of errors. My GCC : 4.4.2 20091027 (Red Hat 4.4.2-7) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100311/b7e6cdb1/attachment.html From esj at cs.fiu.edu Thu Mar 11 08:13:18 2010 From: esj at cs.fiu.edu (Eric S. Johnson) Date: Thu, 11 Mar 2010 11:13:18 -0500 Subject: [Xorp-hackers] linux VRRP svn xorp Message-ID: <20100311161318.76FEFB8848A@cheetah.cs.fiu.edu> So I am kind feeling silly this morning. Ive been chasing a bug that nearly does not exist. On and off for the last two weeks I have been trying to debug why xorp svn (checked out 20100217, i dont think much has changed since then) VRRP didn't work. The behavior I saw was that when xorp became master for a router it would correctly change the mac address on the interface, but yet pinging the virtual IP would not work. I thought VRRP was broken and spent some time tracing through the code to figure out what was going on and going wrong. It was not until I was deep in the depths of vrrp/arpd.cc that I realized that the code was *mostly* working. Well, all the code I could find was working, but there is one behavior that is far from what I expected. I found that indeed I could ping THROUGH the xorp VRRP master router, just not ping the virtual address it self. And that seems to be the way the code is designed to work?!? Vrrp::become_master() { _state = MASTER; // my comments _vif.add_mac(_source_mac); // this changes the mac on the interface send_advertisement(); // start sending vrrp master announcements send_arps(); // send gratuitous arps setup_timers(); // start timers _arpd.start(); // start an pseudo arp deamon // that responds to arp requests for the virtual // IP address with the virtual mac } but no where does it seem to add the virtual IP as a IP on the interface/vif.. So a station sending a packet to the an address that is not the virtual IP but that has a next hop of the virtual IP will make a arp request for the Virtual IP, and get back (from the pseudo arp deamon) the virtual MAC and when that IP packet arrives at the xorp router, it is processed normally and forwarded. But an IP packet with a DESTINATION of the virtual IP address will get to the xorp router too. But the virtual router does not recognize the virtual IP as being one of it's IP address and doesn't accept it. soooo Is/was this just unfinished code? Am I missing somewhere the Virtual address would be added to the VIF and something is broken in the code I can't find? Or am I miss-understanding how VRRP should work (though EVERY other implementation I have seen (vendor C, J, and open source vrrpd) all accept IP packets destined for the virtual IP address?) Would a correct solution be to have xorp set the virtual IP as a secondary IP on that VIF? If so, what would be the correct way to do this.. IfTreeVif::add_addr method? Thoughts? linux centos 5 kernel 2.6.18-164.6.1.el5 E From greearb at candelatech.com Thu Mar 11 09:30:55 2010 From: greearb at candelatech.com (Ben Greear) Date: Thu, 11 Mar 2010 09:30:55 -0800 Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <20100311161318.76FEFB8848A@cheetah.cs.fiu.edu> References: <20100311161318.76FEFB8848A@cheetah.cs.fiu.edu> Message-ID: <4B9928CF.3070307@candelatech.com> On 03/11/2010 08:13 AM, Eric S. Johnson wrote: > Is/was this just unfinished code? > > Am I missing somewhere the Virtual address would be added to the > VIF and something is broken in the code I can't find? > > Or am I miss-understanding how VRRP should work (though EVERY other > implementation I have seen (vendor C, J, and open source vrrpd) all > accept IP packets destined for the virtual IP address?) > > > Would a correct solution be to have xorp set the virtual IP > as a secondary IP on that VIF? If so, what would be the correct > way to do this.. IfTreeVif::add_addr method? It does seem that the virtual IP should be added. The method above sounds right, but I haven't looked at the code. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Thu Mar 11 10:26:57 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Thu, 11 Mar 2010 10:26:57 -0800 (PST) Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <20100311161318.76FEFB8848A@cheetah.cs.fiu.edu> Message-ID: <231736.38409.qm@web58702.mail.re1.yahoo.com> I tested configuring virtual IP addr thr "... vrid 100 ip 10.0.0.100". What happened was not what I expected: 1. "show vrrp" did not use "10.0.0.100" as the master IP. 2. I can not ping 10.0.0.100 from a neighbor. This is different from cisco behavior as far as I can remember. Not only virtual IP can be a next-hop, it can be a destination too. So I guess this is bug. I traced Vrrp::add_ip once, but did not have any clue yet. I will try to do it again later. --- On Thu, 3/11/10, Eric S. Johnson wrote: > From: Eric S. Johnson > Subject: [Xorp-hackers] linux VRRP svn xorp > To: xorp-hackers at icir.org > Date: Thursday, March 11, 2010, 11:13 AM > > So I am kind feeling silly this morning. Ive been chasing a > bug > that nearly? does not exist. > > On and off for the last two weeks I have been trying to > debug > why xorp svn (checked out 20100217, i dont think much has > changed > since then) VRRP didn't work. > > The behavior I saw was that when xorp became master for a > router > it would correctly change the mac address on the interface, > but > yet pinging the virtual IP would not work. I thought VRRP > was > broken and spent some time tracing through the code to > figure > out what was going on and going wrong. > > It was not until I was deep in the depths of vrrp/arpd.cc > that I realized that the code was *mostly* working. Well, > all the code I could find was working, but there is one > behavior that is far from what I expected. > > I? found that indeed I could ping THROUGH the xorp > VRRP master > router, just not ping the virtual address it self. > > And that seems to be the way the code is designed to > work?!? > > Vrrp::become_master() > { > ? ? _state = MASTER; > ??? ??? ??? > ??? ??? // my comments > ? ? _vif.add_mac(_source_mac);??? > ??? // this changes the mac on the interface > ? ? send_advertisement();??? > ??? // start sending vrrp master > announcements > ? ? send_arps();??? > ??? ??? // send gratuitous > arps > ? ? setup_timers();??? > ??? ??? // start timers > ? ? _arpd.start();??? > ??? ??? // start an pseudo arp > deamon > ??? ??? ??? > ??? ??? // that responds to > arp requests for the virtual > ??? ??? ??? > ??? ??? // IP address with the > virtual mac > } > > > but no where does it seem to add the virtual IP as a IP on > the interface/vif.. > > So a station sending a packet to the an address that is not > the > virtual IP but that has a next hop of the virtual IP will > make a > arp request for the Virtual IP, and get back (from the > pseudo arp > deamon) the virtual MAC and when that IP packet arrives at > the xorp > router, it is processed normally and forwarded. > > But an IP packet with a DESTINATION of the virtual IP > address will get > to the xorp router too. But the virtual router does not > recognize the > virtual IP as being one of it's IP address and doesn't > accept it. > > > soooo > > Is/was this just unfinished code? > > Am I missing somewhere the Virtual address would be added > to the > VIF and something is broken in the code I can't find? > > Or am I miss-understanding how VRRP should work (though > EVERY other > implementation I have seen (vendor C, J, and open source > vrrpd) all > accept IP packets destined for the virtual IP address?) > > > > Would a correct solution be to have xorp set the virtual IP > > as a secondary IP on that VIF? If so, what would be the > correct > way to do this.. IfTreeVif::add_addr method? > > > Thoughts? > > linux centos 5 kernel 2.6.18-164.6.1.el5 > E > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From lizhaous2000 at yahoo.com Thu Mar 11 13:29:54 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Thu, 11 Mar 2010 13:29:54 -0800 (PST) Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <231736.38409.qm@web58702.mail.re1.yahoo.com> Message-ID: <451336.91287.qm@web58703.mail.re1.yahoo.com> 1. "show vrrp" did not use "10.0.0.100" as the master IP. This is the correct behavior actually. It is telling who is the master. But perhaps it is better to show the virtual IP address too. --- On Thu, 3/11/10, Li Zhao wrote: > From: Li Zhao > Subject: Re: [Xorp-hackers] linux VRRP svn xorp > To: xorp-hackers at icir.org, "Eric S. Johnson" > Date: Thursday, March 11, 2010, 1:26 PM > I tested configuring virtual IP addr > thr "... vrid 100 ip 10.0.0.100". What happened was not what > I expected: > 1. "show vrrp" did not use "10.0.0.100" as the master IP. > 2. I can not ping 10.0.0.100 from a neighbor. > > This is different from cisco behavior as far as I can > remember. Not only > virtual IP can be a next-hop, it can be a destination too. > So I guess this > is bug. > > I traced Vrrp::add_ip once, but did not have any clue yet. > I will try to > do it again later. > > --- On Thu, 3/11/10, Eric S. Johnson > wrote: > > > From: Eric S. Johnson > > Subject: [Xorp-hackers] linux VRRP svn xorp > > To: xorp-hackers at icir.org > > Date: Thursday, March 11, 2010, 11:13 AM > > > > So I am kind feeling silly this morning. Ive been > chasing a > > bug > > that nearly? does not exist. > > > > On and off for the last two weeks I have been trying > to > > debug > > why xorp svn (checked out 20100217, i dont think much > has > > changed > > since then) VRRP didn't work. > > > > The behavior I saw was that when xorp became master > for a > > router > > it would correctly change the mac address on the > interface, > > but > > yet pinging the virtual IP would not work. I thought > VRRP > > was > > broken and spent some time tracing through the code > to > > figure > > out what was going on and going wrong. > > > > It was not until I was deep in the depths of > vrrp/arpd.cc > > that I realized that the code was *mostly* working. > Well, > > all the code I could find was working, but there is > one > > behavior that is far from what I expected. > > > > I? found that indeed I could ping THROUGH the xorp > > VRRP master > > router, just not ping the virtual address it self. > > > > And that seems to be the way the code is designed to > > work?!? > > > > Vrrp::become_master() > > { > > ? ? _state = MASTER; > > ??? ??? ??? > > ??? ??? // my comments > > ? ? _vif.add_mac(_source_mac);??? > > ??? // this changes the mac on the interface > > ? ? send_advertisement();??? > > ??? // start sending vrrp master > > announcements > > ? ? send_arps();??? > > ??? ??? // send gratuitous > > arps > > ? ? setup_timers();??? > > ??? ??? // start timers > > ? ? _arpd.start();??? > > ??? ??? // start an pseudo arp > > deamon > > ??? ??? ??? > > ??? ??? // that responds to > > arp requests for the virtual > > ??? ??? ??? > > ??? ??? // IP address with the > > virtual mac > > } > > > > > > but no where does it seem to add the virtual IP as a > IP on > > the interface/vif.. > > > > So a station sending a packet to the an address that > is not > > the > > virtual IP but that has a next hop of the virtual IP > will > > make a > > arp request for the Virtual IP, and get back (from > the > > pseudo arp > > deamon) the virtual MAC and when that IP packet > arrives at > > the xorp > > router, it is processed normally and forwarded. > > > > But an IP packet with a DESTINATION of the virtual IP > > address will get > > to the xorp router too. But the virtual router does > not > > recognize the > > virtual IP as being one of it's IP address and > doesn't > > accept it. > > > > > > soooo > > > > Is/was this just unfinished code? > > > > Am I missing somewhere the Virtual address would be > added > > to the > > VIF and something is broken in the code I can't find? > > > > Or am I miss-understanding how VRRP should work > (though > > EVERY other > > implementation I have seen (vendor C, J, and open > source > > vrrpd) all > > accept IP packets destined for the virtual IP > address?) > > > > > > > > Would a correct solution be to have xorp set the > virtual IP > > > > as a secondary IP on that VIF? If so, what would be > the > > correct > > way to do this.. IfTreeVif::add_addr method? > > > > > > Thoughts? > > > > linux centos 5 kernel 2.6.18-164.6.1.el5 > > E > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > ? ? ? > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From lizhaous2000 at yahoo.com Fri Mar 12 07:37:10 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 12 Mar 2010 07:37:10 -0800 (PST) Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <20100311161318.76FEFB8848A@cheetah.cs.fiu.edu> Message-ID: <941439.98222.qm@web58703.mail.re1.yahoo.com> I observed same behavior. The virtual IP address was not accepted as a destination, but can be used as a nexthop. I would like this feature to be enhanced. --- On Thu, 3/11/10, Eric S. Johnson wrote: > From: Eric S. Johnson > Subject: [Xorp-hackers] linux VRRP svn xorp > To: xorp-hackers at icir.org > Date: Thursday, March 11, 2010, 11:13 AM > > So I am kind feeling silly this morning. Ive been chasing a > bug > that nearly? does not exist. > > On and off for the last two weeks I have been trying to > debug > why xorp svn (checked out 20100217, i dont think much has > changed > since then) VRRP didn't work. > > The behavior I saw was that when xorp became master for a > router > it would correctly change the mac address on the interface, > but > yet pinging the virtual IP would not work. I thought VRRP > was > broken and spent some time tracing through the code to > figure > out what was going on and going wrong. > > It was not until I was deep in the depths of vrrp/arpd.cc > that I realized that the code was *mostly* working. Well, > all the code I could find was working, but there is one > behavior that is far from what I expected. > > I? found that indeed I could ping THROUGH the xorp > VRRP master > router, just not ping the virtual address it self. > > And that seems to be the way the code is designed to > work?!? > > Vrrp::become_master() > { > ? ? _state = MASTER; > ??? ??? ??? > ??? ??? // my comments > ? ? _vif.add_mac(_source_mac);??? > ??? // this changes the mac on the interface > ? ? send_advertisement();??? > ??? // start sending vrrp master > announcements > ? ? send_arps();??? > ??? ??? // send gratuitous > arps > ? ? setup_timers();??? > ??? ??? // start timers > ? ? _arpd.start();??? > ??? ??? // start an pseudo arp > deamon > ??? ??? ??? > ??? ??? // that responds to > arp requests for the virtual > ??? ??? ??? > ??? ??? // IP address with the > virtual mac > } > > > but no where does it seem to add the virtual IP as a IP on > the interface/vif.. > > So a station sending a packet to the an address that is not > the > virtual IP but that has a next hop of the virtual IP will > make a > arp request for the Virtual IP, and get back (from the > pseudo arp > deamon) the virtual MAC and when that IP packet arrives at > the xorp > router, it is processed normally and forwarded. > > But an IP packet with a DESTINATION of the virtual IP > address will get > to the xorp router too. But the virtual router does not > recognize the > virtual IP as being one of it's IP address and doesn't > accept it. > > > soooo > > Is/was this just unfinished code? > > Am I missing somewhere the Virtual address would be added > to the > VIF and something is broken in the code I can't find? > > Or am I miss-understanding how VRRP should work (though > EVERY other > implementation I have seen (vendor C, J, and open source > vrrpd) all > accept IP packets destined for the virtual IP address?) > > > > Would a correct solution be to have xorp set the virtual IP > > as a secondary IP on that VIF? If so, what would be the > correct > way to do this.. IfTreeVif::add_addr method? > > > Thoughts? > > linux centos 5 kernel 2.6.18-164.6.1.el5 > E > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From lizhaous2000 at yahoo.com Fri Mar 12 08:16:40 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 12 Mar 2010 08:16:40 -0800 (PST) Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <941439.98222.qm@web58703.mail.re1.yahoo.com> Message-ID: <962219.64914.qm@web58706.mail.re1.yahoo.com> I use linux ip/ifconfig command to add virtual address on the interface, then it can be pingable. Without this, I see some REDIRECT ICMP messages. I will check RFC again and investigate this later. --- On Fri, 3/12/10, Li Zhao wrote: > From: Li Zhao > Subject: Re: [Xorp-hackers] linux VRRP svn xorp > To: xorp-hackers at icir.org, "Eric S. Johnson" > Date: Friday, March 12, 2010, 10:37 AM > I observed same behavior. The virtual > IP address was not accepted as a destination, but can be > used as a nexthop. I would like this feature to be > enhanced. > > --- On Thu, 3/11/10, Eric S. Johnson > wrote: > > > From: Eric S. Johnson > > Subject: [Xorp-hackers] linux VRRP svn xorp > > To: xorp-hackers at icir.org > > Date: Thursday, March 11, 2010, 11:13 AM > > > > So I am kind feeling silly this morning. Ive been > chasing a > > bug > > that nearly? does not exist. > > > > On and off for the last two weeks I have been trying > to > > debug > > why xorp svn (checked out 20100217, i dont think much > has > > changed > > since then) VRRP didn't work. > > > > The behavior I saw was that when xorp became master > for a > > router > > it would correctly change the mac address on the > interface, > > but > > yet pinging the virtual IP would not work. I thought > VRRP > > was > > broken and spent some time tracing through the code > to > > figure > > out what was going on and going wrong. > > > > It was not until I was deep in the depths of > vrrp/arpd.cc > > that I realized that the code was *mostly* working. > Well, > > all the code I could find was working, but there is > one > > behavior that is far from what I expected. > > > > I? found that indeed I could ping THROUGH the xorp > > VRRP master > > router, just not ping the virtual address it self. > > > > And that seems to be the way the code is designed to > > work?!? > > > > Vrrp::become_master() > > { > > ? ? _state = MASTER; > > ??? ??? ??? > > ??? ??? // my comments > > ? ? _vif.add_mac(_source_mac);??? > > ??? // this changes the mac on the interface > > ? ? send_advertisement();??? > > ??? // start sending vrrp master > > announcements > > ? ? send_arps();??? > > ??? ??? // send gratuitous > > arps > > ? ? setup_timers();??? > > ??? ??? // start timers > > ? ? _arpd.start();??? > > ??? ??? // start an pseudo arp > > deamon > > ??? ??? ??? > > ??? ??? // that responds to > > arp requests for the virtual > > ??? ??? ??? > > ??? ??? // IP address with the > > virtual mac > > } > > > > > > but no where does it seem to add the virtual IP as a > IP on > > the interface/vif.. > > > > So a station sending a packet to the an address that > is not > > the > > virtual IP but that has a next hop of the virtual IP > will > > make a > > arp request for the Virtual IP, and get back (from > the > > pseudo arp > > deamon) the virtual MAC and when that IP packet > arrives at > > the xorp > > router, it is processed normally and forwarded. > > > > But an IP packet with a DESTINATION of the virtual IP > > address will get > > to the xorp router too. But the virtual router does > not > > recognize the > > virtual IP as being one of it's IP address and > doesn't > > accept it. > > > > > > soooo > > > > Is/was this just unfinished code? > > > > Am I missing somewhere the Virtual address would be > added > > to the > > VIF and something is broken in the code I can't find? > > > > Or am I miss-understanding how VRRP should work > (though > > EVERY other > > implementation I have seen (vendor C, J, and open > source > > vrrpd) all > > accept IP packets destined for the virtual IP > address?) > > > > > > > > Would a correct solution be to have xorp set the > virtual IP > > > > as a secondary IP on that VIF? If so, what would be > the > > correct > > way to do this.. IfTreeVif::add_addr method? > > > > > > Thoughts? > > > > linux centos 5 kernel 2.6.18-164.6.1.el5 > > E > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > ? ? ? > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From aleksandar.cvjetic at gmail.com Sat Mar 13 13:10:52 2010 From: aleksandar.cvjetic at gmail.com (Aleksandar Cvjetic) Date: Sat, 13 Mar 2010 22:10:52 +0100 Subject: [Xorp-hackers] Help with BGP implementation Message-ID: <249ccfe91003131310i30542849oe4d8284b605dfc91@mail.gmail.com> Is there anyone active on the list who goes deeper into XORP BGP implementation? As part of an academical project, I'm trying to implement functionality of advertising multiple BGP routes in my AS for the same (exterior) destination prefix. This advertisement is to be conditional, not default behavior. I would not bother people with questions (although I already did before with no success) if no one from the list actively (or temporary) do deeper research of XORP BGP code. Thank you in advance, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100313/26132810/attachment.html From greearb at candelatech.com Sat Mar 13 18:14:32 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 13 Mar 2010 18:14:32 -0800 Subject: [Xorp-hackers] Anyone working on OSPFv3-MDR (with MANET extensions)? Message-ID: <4B9C4688.1060601@candelatech.com> I'm curious if anyone has any experience trying to implement OSPFv3-MDR (rfc 5614). Evidently there is a fairly old patch to Quagga from Boeing to implement this, but it doesn't seem like the Quagga project integrated the patch. Still, it might be a starting point to implement this in Xorp. There might be some funding behind this feature...but not sure about that yet... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Mon Mar 15 09:24:30 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Mon, 15 Mar 2010 16:24:30 +0000 Subject: [Xorp-hackers] problem compiling xorp - ubuntu In-Reply-To: <4B4C637B.40700@incunabulum.net> References: <249ccfe91001031443n35e13d30nf664ccf7cb7257be@mail.gmail.com> <4B462CB1.6010107@candelatech.com> <249ccfe91001080304h8ac5abaqba50d6e45e75ca86@mail.gmail.com> <4B476FAE.1060100@candelatech.com> <249ccfe91001100842h10892c67hfa79e26a7be314a7@mail.gmail.com> <4B4A6844.30909@candelatech.com> <249ccfe91001111037y1b78b05i1cc3d77759ab609@mail.gmail.com> <4B4B703A.60604@candelatech.com> <249ccfe91001111158k61890cddoe8c5b0e7e99315a1@mail.gmail.com> <4B4C637B.40700@incunabulum.net> Message-ID: <4769af411003150924x26c002cek32e8c195ff755eb0@mail.gmail.com> For me on ubuntu 9.10 i had to install boost1.4 to get things working, so apt-get install libboost-regex1.40-dev . adam On 12 January 2010 11:56, Bruce Simpson wrote: > On 11/01/2010 19:58, Aleksandar Cvjetic wrote: > > To save everyone's time striving to install XORP SVN version on Ubuntu9.10, > below is the list of packages that might be needed (among the rest) before > successful installation: > > - scons toolset? (apt-get install scons) > > - apt-get install libboost-regex-dev ( or apt-get install > libboost-regex1.40-dev for boost1.4) > > - apt-get install libssl-dev > - apt-get install libpcap-dev > > - apt-get install libncurses5-dev > > Thanks to you and Ben for this useful summary. When I committed the Boost > changes, I didn't realize that Boost-Regex was packaged separately in these > Linux distributions. > > best, > BMS > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > From greearb at candelatech.com Mon Mar 15 15:08:03 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 15 Mar 2010 15:08:03 -0700 Subject: [Xorp-hackers] [Xorp-users] Reducing Xorp binary setup size ? In-Reply-To: <000301cac44f$e8bfb9e0$1c0ea8c0@elitecore.com> References: <000001cac1f2$a718d7b0$1c0ea8c0@elitecore.com> <4B9A5703.3070405@candelatech.com> <4B9A89A3.1090208@candelatech.com> <4B9B1659.3090004@candelatech.com> <001301cac43c$dc0fdf30$1c0ea8c0@elitecore.com> <4B9E317C.10501@candelatech.com> <000301cac44f$e8bfb9e0$1c0ea8c0@elitecore.com> Message-ID: <4B9EAFC3.60304@candelatech.com> I just pushed a huge patch that conditionally compiles out much of the IPv6 code when 'disable_ipv6=yes' is used with scons. Full build, stripped goes from 20MB to 14MB on my Fedora 11 64-bit system. Still a bunch more to #ifdef HAVE_IPV6 away, I'm sure. This was a huge patch..mucking around all over, and hasn't been tested yet, so beware. I'll test it soon..but have to get back to taking care of business for a bit first. I'll be curious to know results if anyone tries it out. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue Mar 16 06:48:01 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 16 Mar 2010 06:48:01 -0700 Subject: [Xorp-hackers] [Xorp-users] Reducing Xorp binary setup size ? In-Reply-To: <000001cac50d$c4f15f00$1c0ea8c0@elitecore.com> References: <000001cac1f2$a718d7b0$1c0ea8c0@elitecore.com> <4B9A5703.3070405@candelatech.com> <4B9A89A3.1090208@candelatech.com> <4B9B1659.3090004@candelatech.com> <001301cac43c$dc0fdf30$1c0ea8c0@elitecore.com> <4B9E317C.10501@candelatech.com> <000301cac44f$e8bfb9e0$1c0ea8c0@elitecore.com> <4B9EAFC3.60304@candelatech.com> <000001cac50d$c4f15f00$1c0ea8c0@elitecore.com> Message-ID: <4B9F8C11.9060301@candelatech.com> On 03/16/2010 06:37 AM, saurabh wrote: > Hi Ben, > > I Pulled your changes and tested them out though its works for ipv4 > multicast, I wonder about the size, still being generated 39 MB stripped > (full xorp) on my Fedora-6 with gcc 4.1.1. > > I checked using git log, it is showing your all changes but 39MB size still > There. > > I may try to look in the fea code now, for removal of cli etc. If you haven't already, please try building with: disable_ipv6=yes disable_fw=yes That should get rid of IPv6 and firewall code from the build. That should save you several MB of disk at least. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Tue Mar 16 08:39:28 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Tue, 16 Mar 2010 15:39:28 +0000 Subject: [Xorp-hackers] Poll : Which OSs to use for buildbot for xorp svn ? Message-ID: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> Hi folks, We are looking into setting up an automatic build checker for xorp, we are probably only going to test against 3 OS/s initally. The current thinking is : - Linux (to be decided) - FreeBSD 8.0 - Linux (to be decided, sparc based) We don't have the resources to support many more initially so it would be very useful to know which of the current OS's people are actually using, this may well infulence which varaiant we choose to test against. I've setup a doodle poll here , so please vote : http://www.doodle.com/2tfa9962pba7uuk3 Many thanks Adam Greenhalgh From greearb at candelatech.com Tue Mar 16 09:19:01 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 16 Mar 2010 09:19:01 -0700 Subject: [Xorp-hackers] [Xorp-users] Poll : Which OSs to use for buildbot for xorp svn ? In-Reply-To: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> References: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> Message-ID: <4B9FAF75.5080407@candelatech.com> On 03/16/2010 08:39 AM, Adam Greenhalgh wrote: > Hi folks, > > We are looking into setting up an automatic build checker for xorp, we > are probably only going to test against 3 OS/s initally. The current > thinking is : > > - Linux (to be decided) > - FreeBSD 8.0 > - Linux (to be decided, sparc based) > > We don't have the resources to support many more initially so it would > be very useful to know which of the current OS's people are actually > using, this may well infulence which varaiant we choose to test > against. I've setup a doodle poll here , so please vote : > > http://www.doodle.com/2tfa9962pba7uuk3 That sounds good to me, though in reality, I doubt very many people will ever be using sparc. It does seem good at finding build bugs though :) If you have a third system, I'd vote for Ubuntu since many people are using it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Tue Mar 16 09:54:17 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Tue, 16 Mar 2010 16:54:17 +0000 Subject: [Xorp-hackers] [Xorp-users] Poll : Which OSs to use for buildbot for xorp svn ? In-Reply-To: <4B9FAF75.5080407@candelatech.com> References: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> <4B9FAF75.5080407@candelatech.com> Message-ID: <4769af411003160954l72974b22rd6c847d620d02cf6@mail.gmail.com> Yes, the sparc os was exactly for spotting byte ordering issues. Adam On 16 March 2010 16:19, Ben Greear wrote: > On 03/16/2010 08:39 AM, Adam Greenhalgh wrote: >> Hi folks, >> >> We are looking into setting up an automatic build checker for xorp, we >> are probably only going to test against 3 OS/s initally. The current >> thinking is : >> >> - Linux (to be decided) >> - FreeBSD 8.0 >> - Linux (to be decided, sparc based) >> >> We don't have the resources to support many more initially so it would >> be very useful to know which of the current OS's people are actually >> using, this may well infulence which varaiant we choose to test >> against. I've setup a doodle poll here , so please vote : >> >> http://www.doodle.com/2tfa9962pba7uuk3 > > That sounds good to me, though in reality, I doubt very many people > will ever be using sparc. ?It does seem good at finding build > bugs though :) > > If you have a third system, I'd vote for Ubuntu since many people > are using it. > > 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 Mar 16 10:33:50 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 16 Mar 2010 10:33:50 -0700 Subject: [Xorp-hackers] [Xorp-users] Poll : Which OSs to use for buildbot for xorp svn ? In-Reply-To: <4769af411003160954l72974b22rd6c847d620d02cf6@mail.gmail.com> References: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> <4B9FAF75.5080407@candelatech.com> <4769af411003160954l72974b22rd6c847d620d02cf6@mail.gmail.com> Message-ID: <4B9FC0FE.8020608@candelatech.com> On 03/16/2010 09:54 AM, Adam Greenhalgh wrote: > Yes, the sparc os was exactly for spotting byte ordering issues. Do you guys have any way to run any automated or semi-automated regression tests? As soon as we get our multiple-mcast-table patch pushed into the upstream kernel (looking promising, but not quite there yet), then I think I'll be able to automate virtual router testing using xorp.ct + LANforge + upated-linux-kernel. I'm thinking of fairly basic OSPF + mcast setup, with ability to test full path communication through multiple virtual routers. Any more advanced testing could probably not easily be automated (by me, at least). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Tue Mar 16 10:39:20 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Tue, 16 Mar 2010 17:39:20 +0000 Subject: [Xorp-hackers] [Xorp-users] Poll : Which OSs to use for buildbot for xorp svn ? In-Reply-To: <4B9FC0FE.8020608@candelatech.com> References: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> <4B9FAF75.5080407@candelatech.com> <4769af411003160954l72974b22rd6c847d620d02cf6@mail.gmail.com> <4B9FC0FE.8020608@candelatech.com> Message-ID: <4769af411003161039h61b84cfcx9efb29a7a92655e1@mail.gmail.com> On 16 March 2010 17:33, Ben Greear wrote: > On 03/16/2010 09:54 AM, Adam Greenhalgh wrote: >> >> Yes, the sparc os was exactly for spotting byte ordering issues. > > Do you guys have any way to run any automated or semi-automated > regression tests? > > As soon as we get our multiple-mcast-table patch pushed into the upstream > kernel (looking promising, but not quite there yet), then I think I'll > be able to automate virtual router testing using xorp.ct + LANforge > + upated-linux-kernel. > > I'm thinking of fairly basic OSPF + mcast setup, with ability to test > full path communication through multiple virtual routers. ?Any more > advanced testing could probably not easily be automated (by me, at least). > Currently we are only looking at running "scons tests" (assuming i have the target name correct). But any further suggestions are greatefully received, they are more greatfully received with code attached ;-) Adam From greearb at candelatech.com Tue Mar 16 10:43:24 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 16 Mar 2010 10:43:24 -0700 Subject: [Xorp-hackers] [Xorp-users] Poll : Which OSs to use for buildbot for xorp svn ? In-Reply-To: <4769af411003161039h61b84cfcx9efb29a7a92655e1@mail.gmail.com> References: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> <4B9FAF75.5080407@candelatech.com> <4769af411003160954l72974b22rd6c847d620d02cf6@mail.gmail.com> <4B9FC0FE.8020608@candelatech.com> <4769af411003161039h61b84cfcx9efb29a7a92655e1@mail.gmail.com> Message-ID: <4B9FC33C.1030403@candelatech.com> On 03/16/2010 10:39 AM, Adam Greenhalgh wrote: > On 16 March 2010 17:33, Ben Greear wrote: >> On 03/16/2010 09:54 AM, Adam Greenhalgh wrote: >>> >>> Yes, the sparc os was exactly for spotting byte ordering issues. >> >> Do you guys have any way to run any automated or semi-automated >> regression tests? >> >> As soon as we get our multiple-mcast-table patch pushed into the upstream >> kernel (looking promising, but not quite there yet), then I think I'll >> be able to automate virtual router testing using xorp.ct + LANforge >> + upated-linux-kernel. >> >> I'm thinking of fairly basic OSPF + mcast setup, with ability to test >> full path communication through multiple virtual routers. Any more >> advanced testing could probably not easily be automated (by me, at least). >> > > Currently we are only looking at running "scons tests" (assuming i > have the target name correct). But any further suggestions are > greatefully received, they are more greatfully received with code > attached ;-) I'll see what I can do. Will probably be a month or two before I get everything integrated with the new kernel. Either way, what I'm thinking about is going to package a lot of external stuff together (so we can actually do traffic generation & verification across the router cloud, for instance), so it won't be something that can really be checked into xorp proper. I might be able to create some scripts to do all the OS configuration and xorp config scripts though...will keep that in mind. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From vfaion at gmail.com Wed Mar 17 09:14:29 2010 From: vfaion at gmail.com (Victor Faion) Date: Wed, 17 Mar 2010 16:14:29 +0000 Subject: [Xorp-hackers] Getting XORP to report queue length Message-ID: <38f1dbe81003170914x723f1385n197ea773868701d4@mail.gmail.com> Hello, I am using the functions in XrlSocket4V0p1Client to send messages using TCP sockets between XORP routers. I was wondering if there was a way to check how much data is currently queued at each node in the network. I guess this function won't be exposed and I'll have to expose it, but I can't seem to find where this is in the XORP code. I am using XORP 1.6. Victor From greearb at candelatech.com Wed Mar 17 13:00:38 2010 From: greearb at candelatech.com (Ben Greear) Date: Wed, 17 Mar 2010 13:00:38 -0700 Subject: [Xorp-hackers] Getting XORP to report queue length In-Reply-To: <38f1dbe81003170914x723f1385n197ea773868701d4@mail.gmail.com> References: <38f1dbe81003170914x723f1385n197ea773868701d4@mail.gmail.com> Message-ID: <4BA134E6.9060106@candelatech.com> On 03/17/2010 09:14 AM, Victor Faion wrote: > Hello, > > I am using the functions in XrlSocket4V0p1Client to send messages > using TCP sockets between XORP routers. I was wondering if there was a > way to check how much data is currently queued at each node in the > network. I guess this function won't be exposed and I'll have to > expose it, but I can't seem to find where this is in the XORP code. I > am using XORP 1.6. You are looking for send/receive buffer sizes for the TCP sockets? Like what 'netstat' reports? I don't actually even know how to get this out of the kernel, but there must be a way... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Wed Mar 17 14:07:06 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Wed, 17 Mar 2010 14:07:06 -0700 (PDT) Subject: [Xorp-hackers] Getting XORP to report queue length In-Reply-To: <4BA134E6.9060106@candelatech.com> Message-ID: <357163.8961.qm@web58707.mail.re1.yahoo.com> does "cat /proc/net/tcp" help? --- On Wed, 3/17/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] Getting XORP to report queue length > To: "Victor Faion" > Cc: xorp-hackers at icir.org > Date: Wednesday, March 17, 2010, 4:00 PM > On 03/17/2010 09:14 AM, Victor Faion > wrote: > > Hello, > > > > I am using the functions in XrlSocket4V0p1Client to > send messages > > using TCP sockets between XORP routers. I was > wondering if there was a > > way to check how much data is currently queued at each > node in the > > network. I guess this function won't be exposed and > I'll have to > > expose it, but I can't seem to find where this is in > the XORP code. I > > am using XORP 1.6. > > You are looking for send/receive buffer sizes for the TCP > sockets? > > Like what 'netstat' reports? > > I don't actually even know how to get this out of the > kernel, but > there must be a way... > > 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 vfaion at gmail.com Wed Mar 17 17:27:35 2010 From: vfaion at gmail.com (Victor Faion) Date: Thu, 18 Mar 2010 00:27:35 +0000 Subject: [Xorp-hackers] Getting XORP to report queue length In-Reply-To: <357163.8961.qm@web58707.mail.re1.yahoo.com> References: <4BA134E6.9060106@candelatech.com> <357163.8961.qm@web58707.mail.re1.yahoo.com> Message-ID: <38f1dbe81003171727j7d979f8bldc6491851e10671e@mail.gmail.com> On Wed, Mar 17, 2010 at 21:07, Li Zhao wrote: > does "cat /proc/net/tcp" help? > Yes this is the information I want, but possibly getting it through XORP. >> >> You are looking for send/receive buffer sizes for the TCP >> sockets? >> >> Like what 'netstat' reports? >> Yeah basically, I guess backlog is the term for it. Also running tc -s qdisc gives the number of bytes and packets of backlog, but I don't really want to do it this way. >> I don't actually even know how to get this out of the >> kernel, but >> there must be a way... >> I thought there would be some protocol in XORP that gets this from the kernel and wanted to do something similar, but I couldn't find it. Also I thought XORP might have an interface to get this information uniformly from different kernels instead of doing something system dependent (and more expensive?) like using netstat or going in /proc. I'm not too familiar with the protocols in XORP, is there one that uses the backlog information for anything? I looked at the general purpose libproto, but couldn't find it in there. Victor From lizhaous2000 at yahoo.com Fri Mar 19 07:16:39 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 19 Mar 2010 07:16:39 -0700 (PDT) Subject: [Xorp-hackers] VRRP error Message-ID: <648966.12464.qm@web58706.mail.re1.yahoo.com> I am attaching my fix for vrrp abort. I have done quite a lot real time testing on my router. --- On Tue, 3/9/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Tuesday, March 9, 2010, 10:59 AM > On 03/09/2010 07:46 AM, Li Zhao > wrote: > > Yes, I am looking into why HAVE_PCAP is not defined in > the config stage. > > > > I changed the build process for xorp source files. > Also I built a proto type > > linux embedded system so I want to keep it stable for > a while. Thirdly I > > am a dumbo to use svn development branch at this time > stage. > > I prefer git to svn, as far as source code mgt goes.? > If you want to try out > git, I can help (there is an easy way to import svn into > git).? I don't > know how to use svn itself though... > > I got rid of boost requirement in my tree, so that might > help with > a tight embedded system. > > But, I understand wanting to keep with a known quantity. > > > > > But I will move to the main branch when I am ready > soon. So temporarily now > > I will post the proper patches to this list. If i have > too much patch to commit I will think about a better way. > > Sounds good.? I'll apply what I can to my tree, at > least. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc? http://www.candelatech.com > > -------------- next part -------------- A non-text attachment was scrubbed... Name: vrrp.patch Type: application/octet-stream Size: 1198 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20100319/041f93f8/attachment.obj From greearb at candelatech.com Fri Mar 19 08:35:11 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Mar 2010 08:35:11 -0700 Subject: [Xorp-hackers] VRRP error In-Reply-To: <648966.12464.qm@web58706.mail.re1.yahoo.com> References: <648966.12464.qm@web58706.mail.re1.yahoo.com> Message-ID: <4BA399AF.1070005@candelatech.com> On 03/19/2010 07:16 AM, Li Zhao wrote: > I am attaching my fix for vrrp abort. I have done quite a lot real time testing on my router. Thanks, looks good to me. I'll push it to xorp.ct in a bit. Do you have any notes on how to do at least minimal testing of vrrp using just xorp? (config-files, disconnect certain cables, etc?) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Fri Mar 19 11:34:31 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 19 Mar 2010 11:34:31 -0700 (PDT) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4BA399AF.1070005@candelatech.com> Message-ID: <307195.30589.qm@web58707.mail.re1.yahoo.com> This is probably you can do. 1. #create interfaces interface eth1 vif eth1 address 10.0.0.1 prefix-length 24. 2. #create protocols vrrp interface eth1 vif eth1 vrid 100 ip 10.0.0.100 3. #create protocols vrrp interface eth1 vif eth1 vrid 100 priority 200 >show vrrp You should see "State Master" + "Master IP 10.0.0.1" Then you can even do the following on a second router: 4. #create interfaces interface eth1 vif eth1 address 10.0.0.2 prefix-length 24. 5. #create protocols vrrp interface eth1 vif eth1 vrid 100 ip 10.0.0.100 6. #create protocols vrrp interface eth1 vif eth1 vrid 100 priority 100 >show vrrp You should see "State Backup" + "Master IP 10.0.0.1" 7. on two routers, use "ip addr add 10.0.0.100 dev eth1" to make kernel IP stack recognize 10.0.0.100 as local address. 8. From a third host to ping 10.0.0.100 Test switchover, you can do the following on the router-1 9. #create interfaces interface eth1 disable true 10.#create interfaces interface eth1 vif eth1 disable true Then ">show vrrp" and "ping 10.0.0.100" should show the switch over. Futher, you can test to use "10.0.0.100" as the endpoint of a ip tunnel to see tunnel protected... etc. Li --- On Fri, 3/19/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Friday, March 19, 2010, 11:35 AM > On 03/19/2010 07:16 AM, Li Zhao > wrote: > > I am attaching my fix for vrrp abort. I have done > quite a lot real time testing on my router. > > Thanks, looks good to me.? I'll push it to xorp.ct in > a bit. > > Do you have any notes on how to do at least minimal testing > of vrrp using > just xorp? (config-files, disconnect certain cables, etc?) > > Thanks, > Ben > > -- Ben Greear > Candela Technologies Inc? http://www.candelatech.com > From lizhaous2000 at yahoo.com Fri Mar 19 13:30:53 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 19 Mar 2010 13:30:53 -0700 (PDT) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4BA399AF.1070005@candelatech.com> Message-ID: <565004.40415.qm@web58704.mail.re1.yahoo.com> This is probably what you can do. 1. #create interfaces interface eth1 vif eth1 address 10.0.0.1 prefix-length 24. 2. #create protocols vrrp interface eth1 vif eth1 vrid 100 ip 10.0.0.100 3. #create protocols vrrp interface eth1 vif eth1 vrid 100 priority 200 >show vrrp You should see "State Master" + "Master IP 10.0.0.1" Then you can even do the following on a second router: 4. #create interfaces interface eth1 vif eth1 address 10.0.0.2 prefix-length 24. 5. #create protocols vrrp interface eth1 vif eth1 vrid 100 ip 10.0.0.100 6. #create protocols vrrp interface eth1 vif eth1 vrid 100 priority 100 >show vrrp You should see "State Backup" + "Master IP 10.0.0.1" 7. on two routers, use "ip addr add 10.0.0.100 dev eth1" to make kernel IP stack recognize 10.0.0.100 as local address. 8. From a third host to ping 10.0.0.100 Test switchover, you can do the following on the router-1 9. #create interfaces interface eth1 disable true 10.#create interfaces interface eth1 vif eth1 disable true Then ">show vrrp" and "ping 10.0.0.100" should show the switch over. Futher, you can test to use "10.0.0.100" as the endpoint of a ip tunnel to see tunnel protected... etc. Li --- On Fri, 3/19/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Friday, March 19, 2010, 11:35 AM > On 03/19/2010 07:16 AM, Li Zhao > wrote: > > I am attaching my fix for vrrp abort. I have done > quite a lot real time testing on my router. > > Thanks, looks good to me.? I'll push it to xorp.ct in > a bit. > > Do you have any notes on how to do at least minimal testing > of vrrp using > just xorp? (config-files, disconnect certain cables, etc?) > > Thanks, > Ben > > -- Ben Greear > Candela Technologies Inc? http://www.candelatech.com > From lizhaous2000 at yahoo.com Fri Mar 19 13:36:50 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Fri, 19 Mar 2010 13:36:50 -0700 (PDT) Subject: [Xorp-hackers] VRRP error In-Reply-To: <4BA399AF.1070005@candelatech.com> Message-ID: <627337.41179.qm@web58702.mail.re1.yahoo.com> This is probably what you can do. 1. #create interfaces interface eth1 vif eth1 address 10.0.0.1 prefix-length 24. 2. #create interfaces interface eth1 vif eth1 address 10.0.0.100 prefix-length 24. 3. #create protocols vrrp interface eth1 vif eth1 vrid 100 ip 10.0.0.100 4. #create protocols vrrp interface eth1 vif eth1 vrid 100 priority 200 >show vrrp You should see "State Master" + "Master IP 10.0.0.1" Then you can even do the following on a second router: 5. #create interfaces interface eth1 vif eth1 address 10.0.0.2 prefix-length 24. 6. #create interfaces interface eth1 vif eth1 address 10.0.0.100 prefix-length 24. 7. #create protocols vrrp interface eth1 vif eth1 vrid 100 ip 10.0.0.100 8. #create protocols vrrp interface eth1 vif eth1 vrid 100 priority 100 >show vrrp You should see "State Backup" + "Master IP 10.0.0.1" 9. From a third host to ping 10.0.0.100 Test switchover, you can do the following on the router-1 10. #create interfaces interface eth1 disable true 11. #create interfaces interface eth1 vif eth1 disable true or plug out the cable. I am using VM, so I used the above cli commands. Then ">show vrrp" and "ping 10.0.0.100" should show the switch over. Futher, you can test to use "10.0.0.100" as the endpoint of a ip tunnel to see tunnel protected... etc. Li --- On Fri, 3/19/10, Ben Greear wrote: > From: Ben Greear > Subject: Re: [Xorp-hackers] VRRP error > To: "Li Zhao" > Cc: xorp-hackers at icir.org > Date: Friday, March 19, 2010, 11:35 AM > On 03/19/2010 07:16 AM, Li Zhao > wrote: > > I am attaching my fix for vrrp abort. I have done > quite a lot real time testing on my router. > > Thanks, looks good to me.? I'll push it to xorp.ct in > a bit. > > Do you have any notes on how to do at least minimal testing > of vrrp using > just xorp? (config-files, disconnect certain cables, etc?) > > Thanks, > Ben > > -- Ben Greear > Candela Technologies Inc? http://www.candelatech.com > From greearb at candelatech.com Fri Mar 19 16:19:56 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Mar 2010 16:19:56 -0700 Subject: [Xorp-hackers] Anyone have the user-guide source? Message-ID: <4BA4069C.6000003@candelatech.com> If anyone has the user-guide source, could they post a link and/or add it to SVN? I'd like to make some edits as I notice bugs... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Mar 19 16:52:41 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Mar 2010 16:52:41 -0700 Subject: [Xorp-hackers] VRRP error In-Reply-To: <627337.41179.qm@web58702.mail.re1.yahoo.com> References: <627337.41179.qm@web58702.mail.re1.yahoo.com> Message-ID: <4BA40E49.7080407@candelatech.com> On 03/19/2010 01:36 PM, Li Zhao wrote: > > This is probably what you can do. > > 1. #create interfaces interface eth1 vif eth1 address 10.0.0.1 prefix-length 24. > 2. #create interfaces interface eth1 vif eth1 address 10.0.0.100 prefix-length 24. > 3. #create protocols vrrp interface eth1 vif eth1 vrid 100 ip 10.0.0.100 > 4. #create protocols vrrp interface eth1 vif eth1 vrid 100 priority 200 Ok, I have this integrated somewhat in my LANforge tool. I see vrrp starting, but then it crashes trying to set a MAC address. I'm using my xorp.ct tree on virtual interfaces, so maybe it's some bug I introduced or some issue with the type of virtual interfaces I'm using... [ 2010/03/19 16:42:29.326435 WARNING xorp_fea XrlFeaTarget ] Handling method for ifmgr/0.1/create_mac failed: XrlCmdError 102 Command failed Cannot add MAC address 0:0:5e:0:1:1 on interface rddVR2: Cannot set MAC address 0:0:5e:0:1:1 on interface rddVR2: cannot commit the transaction [ 2010/03/19 16:42:29.326789 FATAL xorp_vrrp:5148 VRRP +362 vrrp/vrrp_target.cc xrl_cb ] XRL error: 102 Command failed Cannot add MAC address 0:0:5e:0:1:1 on interface rddVR2: Cannot set MAC address 0:0:5e:0:1:1 on interface rddVR2: cannot commit the transaction [ 2010/03/19 16:42:29.329530 ERROR xorp_rtrmgr:5057 RTRMGR rtrmgr/module_manager.cc:755 done_cb ] Command "/usr/local/xorp/lib/xorp/sbin/xorp_vrrp": terminated with signal 6; aborted with a core dump. I'll have to dig into the code to see why it is trying to set a mac..and why it might be failing. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Mar 19 23:14:05 2010 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Mar 2010 23:14:05 -0700 Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <20100311161318.76FEFB8848A@cheetah.cs.fiu.edu> References: <20100311161318.76FEFB8848A@cheetah.cs.fiu.edu> Message-ID: <4BA467AD.8010007@candelatech.com> On 03/11/2010 08:13 AM, Eric S. Johnson wrote: > > So I am kind feeling silly this morning. Ive been chasing a bug > that nearly does not exist. > > On and off for the last two weeks I have been trying to debug > why xorp svn (checked out 20100217, i dont think much has changed > since then) VRRP didn't work. > > The behavior I saw was that when xorp became master for a router > it would correctly change the mac address on the interface, but > yet pinging the virtual IP would not work. I thought VRRP was > broken and spent some time tracing through the code to figure > out what was going on and going wrong. > > It was not until I was deep in the depths of vrrp/arpd.cc > that I realized that the code was *mostly* working. Well, > all the code I could find was working, but there is one > behavior that is far from what I expected. > > I found that indeed I could ping THROUGH the xorp VRRP master > router, just not ping the virtual address it self. > > And that seems to be the way the code is designed to work?!? > > Vrrp::become_master() > { > _state = MASTER; > // my comments > _vif.add_mac(_source_mac); // this changes the mac on the interface > send_advertisement(); // start sending vrrp master announcements > send_arps(); // send gratuitous arps > setup_timers(); // start timers > _arpd.start(); // start an pseudo arp deamon > // that responds to arp requests for the virtual > // IP address with the virtual mac Seems to me that if we put a second IP on the interface, then we can let the OS deal with arp and kill the arpd logic entirely. > Would a correct solution be to have xorp set the virtual IP > as a secondary IP on that VIF? If so, what would be the correct > way to do this.. IfTreeVif::add_addr method? Sounds good to me. I fixed the bug in xorp.ct that caused vrrp to crash early...now I'm seeing similar activity w/regard to the MAC addr being set but no IP visible. I'll poke at the add_addr logic and see what I can get to happen... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From esj at cs.fiu.edu Sat Mar 20 06:13:43 2010 From: esj at cs.fiu.edu (Eric S. Johnson) Date: Sat, 20 Mar 2010 09:13:43 -0400 Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: Your message of "Fri, 19 Mar 2010 23:14:05 PDT." <4BA467AD.8010007@candelatech.com> Message-ID: <20100320131343.9A22CB8843E@cheetah.cs.fiu.edu> >Seems to me that if we put a second IP on the interface, then we >can let the OS deal with arp and kill the arpd logic entirely. Yeah, I thought the same thing. In fact it looks like the pseudo arp deamon wont "start up" for IP's assigned to the interface, due to the Vrrp::check_ownership >> Would a correct solution be to have xorp set the virtual IP >> as a secondary IP on that VIF? If so, what would be the correct >> way to do this.. IfTreeVif::add_addr method? > >Sounds good to me. I fixed the bug in xorp.ct that caused vrrp >to crash early...now I'm seeing similar activity w/regard to >the MAC addr being set but no IP visible. > >I'll poke at the add_addr logic and see what I can get >to happen... Ive been on vacation this last week, but started this before I left. Below are the diff I have. Basicly I copied the logic for adding the mac, and got as far as vrrp_target where I think a XRL needs to be sent, but I hadn't figured out how/what yet, E -- diff -ur ../../xorp-svn-20100217.orig/vrrp/vrrp.cc ./vrrp.cc --- ../../xorp-svn-20100217.orig/vrrp/vrrp.cc 2010-02-17 10:25:11.000000000 -0500 +++ ./vrrp.cc 2010-03-11 17:14:50.000000000 -0500 @@ -125,9 +125,11 @@ void Vrrp::add_ip(const IPv4& ip) { +XLOG_WARNING("ESJ in Vrrp::add_ip before _ips.insert ip=%s\n",ip.str().c_str()); _ips.insert(ip); - +XLOG_WARNING("ESJ in Vrrp::add_ip after _ips.insert\n"); check_ownership(); +XLOG_WARNING("ESJ in Vrrp::add_ip after check_ownership()\n"); } void @@ -198,6 +200,27 @@ setup_intervals(); } +//ESJ +void +Vrrp::add_ips_to_vif() +{ + for (IPS::iterator i = _ips.begin(); i != _ips.end(); ++i) { + const IPv4& ip = *i; + XLOG_INFO ("ESJ adding %s as ip on virtual interface\n", ip.str().c_str() ); + _vif.add_ip (ip); + } +} + +void +Vrrp::del_ips_from_vif() +{ + for (IPS::iterator i = _ips.begin(); i != _ips.end(); ++i) { + const IPv4& ip = *i; + XLOG_INFO ("ESJ deleting %s as ip on virtual interface\n", ip.str().c_str() ); + _vif.add_ip (ip); + } +} + uint32_t Vrrp::priority() const { @@ -229,6 +252,7 @@ { _state = MASTER; + add_ips_to_vif(); _vif.add_mac(_source_mac); send_advertisement(); send_arps(); @@ -240,6 +264,7 @@ Vrrp::become_backup() { if (_state == MASTER) { + del_ips_from_vif(); _vif.delete_mac(_source_mac); _arpd.stop(); } diff -ur ../../xorp-svn-20100217.orig/vrrp/vrrp.hh ./vrrp.hh --- ../../xorp-svn-20100217.orig/vrrp/vrrp.hh 2010-02-17 10:25:11.000000000 -0500 +++ ./vrrp.hh 2010-03-11 17:12:24.000000000 -0500 @@ -264,6 +264,16 @@ void recv_advertisement(const IPv4& from, uint32_t priority); /** + * ESJ add ip to vif, used to add virtual IPs to vif when master + */ + void add_ips_to_vif(); + + /** + * ESJ delete ip from vif, used to delete virtual IPs from vif when not master + */ + void del_ips_from_vif(); + + /** * Check whether the IPs in the VRRP packet match those configured * * @return true on exact matches. diff -ur ../../xorp-svn-20100217.orig/vrrp/vrrp_interface.hh ./vrrp_interface.hh --- ../../xorp-svn-20100217.orig/vrrp/vrrp_interface.hh 2010-02-17 10:25:11.000000000 -0500 +++ ./vrrp_interface.hh 2010-03-11 17:24:37.000000000 -0500 @@ -85,6 +85,20 @@ */ virtual void leave_mcast() = 0; + /** ESJ + * Add a IP address to this interface. + * + * @param mac IP address to add. + */ + virtual void add_ip(const IPv4& ip) = 0; + + /** + * Delete a IP address from this interface. + * + * @param mac IP address to delete from this interface. + */ + virtual void delete_ip(const IPv4& ip) = 0; + /** * Add a MAC address to this interface. * diff -ur ../../xorp-svn-20100217.orig/vrrp/vrrp_target.cc ./vrrp_target.cc --- ../../xorp-svn-20100217.orig/vrrp/vrrp_target.cc 2010-02-17 10:25:11.000000000 -0500 +++ ./vrrp_target.cc 2010-03-11 17:43:20.000000000 -0500 @@ -332,6 +332,21 @@ _xrls_pending++; } +//ESJ +void +VrrpTarget::add_ip(const string& ifname, const IPv4& ip) +{ + XLOG_INFO("ESJ - nothing yet %s %s \n",ifname.c_str(), ip.str().c_str() ); +} + +void +VrrpTarget::del_ip(const string& ifname, const IPv4& ip) +{ + XLOG_INFO("ESJ - nothing yet %s %s \n",ifname.c_str(), ip.str().c_str() ); +} + + + void VrrpTarget::add_mac(const string& ifname, const Mac& mac) { diff -ur ../../xorp-svn-20100217.orig/vrrp/vrrp_target.hh ./vrrp_target.hh --- ../../xorp-svn-20100217.orig/vrrp/vrrp_target.hh 2010-02-17 10:25:11.000000000 -0500 +++ ./vrrp_target.hh 2010-03-11 17:36:48.000000000 -0500 @@ -112,6 +112,22 @@ */ void stop_arps(const string& ifname, const string& vifname); + /** ESJ + * add a IP address to the router. + * + * @param ifname the interface on which to add the ip. + * @param ip the ip address. + */ + void add_ip(const string& ifname, const IPv4& ip); + + /** ESJ + * del a IP address to the router. + * + * @param ifname the interface on which to add the ip. + * @param ip the ip address. + */ + void del_ip(const string& ifname, const IPv4& ip); + /** * Add a MAC address to the router. * diff -ur ../../xorp-svn-20100217.orig/vrrp/vrrp_vif.cc ./vrrp_vif.cc --- ../../xorp-svn-20100217.orig/vrrp/vrrp_vif.cc 2010-02-17 10:25:11.000000000 -0500 +++ ./vrrp_vif.cc 2010-03-12 12:10:24.000000000 -0500 @@ -258,6 +258,22 @@ } } +//ESJ +void +VrrpVif::add_ip(const IPv4& ip) +{ + XLOG_ASSERT(_ifname == _vifname); + _vt.add_ip(_vifname,ip); +} + +void +VrrpVif::delete_ip(const IPv4& ip) +{ + XLOG_ASSERT(_ifname == _vifname); + _vt.del_ip(_vifname,ip); +} + + void VrrpVif::add_mac(const Mac& mac) { diff -ur ../../xorp-svn-20100217.orig/vrrp/vrrp_vif.hh ./vrrp_vif.hh --- ../../xorp-svn-20100217.orig/vrrp/vrrp_vif.hh 2010-02-17 10:25:11.000000000 -0500 +++ ./vrrp_vif.hh 2010-03-11 17:18:18.000000000 -0500 @@ -132,6 +132,20 @@ */ void recv(const IPv4& from, const PAYLOAD& payload); + /** ESJ + * Add a IP address to this interface. + * + * @param IPv4 IP address to add. + */ + void add_ip(const IPv4& ip); + + /** + * Delete a IP address from this interface. + * + * @param IPv4 IP address to remove. + */ + void delete_ip(const IPv4& ip); + /** * Add a MAC address to this interface. * From greearb at candelatech.com Sat Mar 20 08:37:00 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 20 Mar 2010 08:37:00 -0700 Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <20100320131343.9A22CB8843E@cheetah.cs.fiu.edu> References: <20100320131343.9A22CB8843E@cheetah.cs.fiu.edu> Message-ID: <4BA4EB9C.4020504@candelatech.com> On 03/20/2010 06:13 AM, Eric S. Johnson wrote: >> Seems to me that if we put a second IP on the interface, then we >> can let the OS deal with arp and kill the arpd logic entirely. > > Yeah, I thought the same thing. In fact it looks like the pseudo arp > deamon wont "start up" for IP's assigned to the interface, due to > the Vrrp::check_ownership > >>> Would a correct solution be to have xorp set the virtual IP >>> as a secondary IP on that VIF? If so, what would be the correct >>> way to do this.. IfTreeVif::add_addr method? >> >> Sounds good to me. I fixed the bug in xorp.ct that caused vrrp >> to crash early...now I'm seeing similar activity w/regard to >> the MAC addr being set but no IP visible. >> >> I'll poke at the add_addr logic and see what I can get >> to happen... > > Ive been on vacation this last week, but started this before > I left. Below are the diff I have. Basicly I copied the logic > for adding the mac, and got as far as vrrp_target where I think > a XRL needs to be sent, but I hadn't figured out how/what yet, I think I know how to make XRL & FEA do it's thing...will have a patch this evening if all goes well. The work I did yesterday looks very close to your patch, so hopefully we're on the right track. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Sat Mar 20 09:03:08 2010 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 20 Mar 2010 16:03:08 +0000 Subject: [Xorp-hackers] Anyone have the user-guide source? In-Reply-To: <4BA4069C.6000003@candelatech.com> References: <4BA4069C.6000003@candelatech.com> Message-ID: <4BA4F1BC.9010501@incunabulum.net> On 03/19/10 23:19, Ben Greear wrote: > If anyone has the user-guide source, could they post a link and/or add it to SVN? > http://xorp.svn.sourceforge.net/viewvc/xorp/trunk/docs/ As part of the SourceForge move, I moved it to its own part of the tree, in its own directory. Largely because building the package from source didn't require the docs. And the docs require a full LaTeX toolchain. Installing Kile in KDE should be enough to pull in all required dependencies. From bms at incunabulum.net Sat Mar 20 09:07:03 2010 From: bms at incunabulum.net (Bruce Simpson) Date: Sat, 20 Mar 2010 16:07:03 +0000 Subject: [Xorp-hackers] XORP news Message-ID: <4BA4F2A7.10600@incunabulum.net> Hi all, I am in ongoing contact with both the academic founders, and the XORP, Inc. former management team. As of this week, the original XORP core team should now have commit access to the XORP repo on SourceForge. The IP auction closed yesterday (March 19th). We probably won't have a firm picture of the outcome until Monday. Discussions are in progress, about how to retain open access to XORP, whatever happens, and arrive at economic mechanisms which allow developers to be compensated for their time, whilst retaining free-at-point-of-distribution. Thanks to everyone for staying interested and contributing on the lists at this difficult time. thanks, BMS From greearb at candelatech.com Sat Mar 20 23:58:53 2010 From: greearb at candelatech.com (Ben Greear) Date: Sat, 20 Mar 2010 23:58:53 -0700 Subject: [Xorp-hackers] linux VRRP svn xorp In-Reply-To: <4BA4EB9C.4020504@candelatech.com> References: <20100320131343.9A22CB8843E@cheetah.cs.fiu.edu> <4BA4EB9C.4020504@candelatech.com> Message-ID: <4BA5C3AD.2050601@candelatech.com> On 03/20/2010 08:37 AM, Ben Greear wrote: > On 03/20/2010 06:13 AM, Eric S. Johnson wrote: >>> Seems to me that if we put a second IP on the interface, then we >>> can let the OS deal with arp and kill the arpd logic entirely. >> >> Yeah, I thought the same thing. In fact it looks like the pseudo arp >> deamon wont "start up" for IP's assigned to the interface, due to >> the Vrrp::check_ownership >> >>>> Would a correct solution be to have xorp set the virtual IP >>>> as a secondary IP on that VIF? If so, what would be the correct >>>> way to do this.. IfTreeVif::add_addr method? >>> >>> Sounds good to me. I fixed the bug in xorp.ct that caused vrrp >>> to crash early...now I'm seeing similar activity w/regard to >>> the MAC addr being set but no IP visible. >>> >>> I'll poke at the add_addr logic and see what I can get >>> to happen... >> >> Ive been on vacation this last week, but started this before >> I left. Below are the diff I have. Basicly I copied the logic >> for adding the mac, and got as far as vrrp_target where I think >> a XRL needs to be sent, but I hadn't figured out how/what yet, > > I think I know how to make XRL& FEA do it's thing...will have a patch > this evening if all goes well. The work I did yesterday looks very close > to your patch, so hopefully we're on the right track. Well, it took more work that I was hoping..but it seems to be adding the IP now. No idea if anything else works..and patch definitely needs some more cleanup, so I didn't commit it yet. You can find it here if you want to try it. It should apply clean on top of my xorp.ct tree. http://www.candelatech.com/~greearb/misc/patches/xorp_vrrp.patch I'll try to clean this up and do some better testing over the next few days. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sun Mar 21 11:03:11 2010 From: greearb at candelatech.com (Ben Greear) Date: Sun, 21 Mar 2010 11:03:11 -0700 Subject: [Xorp-hackers] More VRRP problems. Message-ID: <4BA65F5F.60009@candelatech.com> While testing VRRP I notice some more problems with the current code. I don't think these are something I introduced, but it's possible. 1) If xorp starts with the MAC of the vrrp interface as the 'real' MAC on the network device (ie, if vrrp was running and then xorp crashed or was killed hard and didn't revert the MAC), then the code cannot remove the MAC. To fix this problem, I am thinking about just setting a random MAC address in this case. 2) Perhaps related to 1: If you have two VRRP processes connected by a switch, network and disconnect cables (by leave link UP on the physical xorp ports), then the system goes into split-brain problem (both think they are the master). When re-enabling the cabling, at least my code isn't resolving back to a single master. I need to read the RFC on this to see what is supposed to happen... Anyway, I'll keep poking at this..but that is where I am currently. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From lizhaous2000 at yahoo.com Mon Mar 22 06:32:37 2010 From: lizhaous2000 at yahoo.com (Li Zhao) Date: Mon, 22 Mar 2010 06:32:37 -0700 (PDT) Subject: [Xorp-hackers] More VRRP problems. In-Reply-To: <4BA65F5F.60009@candelatech.com> Message-ID: <218713.98766.qm@web58703.mail.re1.yahoo.com> 1. The first problem, I have had many times now. The code did not have cleanup code to revert virtaul MAC, some signal handler function may be needed to fix this. But use random MAC is not what RFC want because RFC has restricted MAC format. If you use some random format there may be some router implementation which rejects to connect to you. 2. I am using virtual machines so I can not play with cables. But if I power off the master router, I did see the backup router is taking over like the following: admin at router-4> show vrrp Interface eth1 Vif eth1 VRID 100 State backup Master IP 10.0.0.5 admin at router-4> show vrrp Interface eth1 Vif eth1 VRID 100 State master Master IP 10.0.0.4 After I power on the master, I can see the switch back: admin at router-4> show vrrp Interface eth1 Vif eth1 VRID 100 State backup Master IP 10.0.0.5 [root at router-5 ~]# su admin Welcome to XORP on router-5 admin at router-5> show vrrp Interface eth1 Vif eth1 VRID 100 State master Master IP 10.0.0.5 So according to RFC, if the master stops sending heart beats, the backup should take over immediately. I guess playing with cables should have the same effect. --- On Sun, 3/21/10, Ben Greear wrote: > From: Ben Greear > Subject: [Xorp-hackers] More VRRP problems. > To: "xorp" > Date: Sunday, March 21, 2010, 2:03 PM > While testing VRRP I notice some more > problems with the current code. > I don't think these are something I introduced, but it's > possible. > > 1)? If xorp starts with the MAC of the vrrp interface > as the 'real' > ???MAC on the network device (ie, if vrrp > was running and then xorp > ???crashed or was killed hard and didn't > revert the MAC), then the > ???code cannot remove the MAC. > > ???To fix this problem, I am thinking about > just setting a random MAC > ???address in this case. > > 2)? Perhaps related to 1:? If you have two VRRP > processes connected by a switch, > ???network and disconnect cables (by leave > link UP on the physical xorp ports), then > ???the system goes into split-brain problem > (both think they are the master). > > ???When re-enabling the cabling, at least my > code isn't resolving back to > ???a single master.? I need to read the > RFC on this to see what is supposed > ???to happen... > > > Anyway, I'll keep poking at this..but that is where I am > currently. > > 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 Mon Mar 22 08:07:48 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Mar 2010 08:07:48 -0700 Subject: [Xorp-hackers] More VRRP problems. In-Reply-To: <218713.98766.qm@web58703.mail.re1.yahoo.com> References: <218713.98766.qm@web58703.mail.re1.yahoo.com> Message-ID: <4BA787C4.7010507@candelatech.com> On 03/22/2010 06:32 AM, Li Zhao wrote: > 1. The first problem, I have had many times now. The code did not have > cleanup code to revert virtaul MAC, some signal handler function may be > needed to fix this. But use random MAC is not what RFC want because RFC > has restricted MAC format. If you use some random format there may be some > router implementation which rejects to connect to you. We can be more careful about fixing up the MAC, but cannot in all cases guarantee we can restore it (kill -9 or fea crash, for instance). I'd use the random MAC for the 'original' MAC address, after removing the VRRP MAC. I would of course make sure the MAC is valid..an easy way being first octet is zero, rest are random. Other systems will quickly learn the new MAC because ARP will automatically start returning the new one..and we could promisc-arp to speed things up. > 2. I am using virtual machines so I can not play with cables. But if I > power off the master router, I did see the backup router is taking over > like the following: This was due to changes I made: I was adding the VRRP IP address..and then the routers thought they 'owned' the IPs. In split-brain, both 'owned' them. My preference is to ignore ownership of the IP and just go to backup mode as normal (immediately removing the IP). I think this is still OK with the RFC, though one could argue differently. I've got a few more changes to my LANforge code before I can properly test this, but hope to have a working patch later today. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Mar 22 09:46:21 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Mar 2010 09:46:21 -0700 Subject: [Xorp-hackers] Xorp project development. Message-ID: <4BA79EDD.9040807@candelatech.com> I came to xorp after the bulk of the (public) project had already been written, so I never really knew many of the original developers. With the latest churn, I have even less idea. I don't actually know who has the authority to discuss bigger changes (like what is found in my xorp.ct tree). I want to come to some sort of understanding with them before I put any real effort into breaking out small patches for upstream SVN. My own preference is to push all of xorp.ct to SVN, accept patches for another month or so, freeze a branch for release, and put out a snapshot 1.7. If no one complains in a week or two, call 1.7 done and start on 1.8. As long as useful work is going into the tree, do a release 2-4 times a year, with smaller updates more often as needed. If the project leaders do not want to merge at least most of xorp.ct, then I'll keep it going and merge what I can of upstream SVN into xorp.ct if/when any changes go upstream, but I will not be actively developing against the SVN tree. I would like to hear opinions on this from everyone involved in xorp, and especially from whoever is the project leader and can make such decisions for the SVN tree. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Mar 22 10:53:48 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Mar 2010 10:53:48 -0700 Subject: [Xorp-hackers] More VRRP problems. In-Reply-To: <218713.98766.qm@web58703.mail.re1.yahoo.com> References: <218713.98766.qm@web58703.mail.re1.yahoo.com> Message-ID: <4BA7AEAC.4010409@candelatech.com> On 03/22/2010 06:32 AM, Li Zhao wrote: > 1. The first problem, I have had many times now. The code did not have > cleanup code to revert virtaul MAC, some signal handler function may be > needed to fix this. But use random MAC is not what RFC want because RFC > has restricted MAC format. If you use some random format there may be some > router implementation which rejects to connect to you. I committed the code to support the secondary IP address. I need to do a small bit of kernel hacking to get arp working on secondary IPs (but this should only apply to my virtual-router configuration..not normal Linux) before I can fully test this with traffic. But, the IP appears to be moving properly, and a normally configured OS *should* answer the arp properly. Please let me know if any of you get a chance to try it. I'll work on the 'remove-mac-address' issue next. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From M.Handley at cs.ucl.ac.uk Mon Mar 22 11:14:10 2010 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Mon, 22 Mar 2010 18:14:10 +0000 Subject: [Xorp-hackers] Xorp project development. In-Reply-To: <4BA79EDD.9040807@candelatech.com> References: <4BA79EDD.9040807@candelatech.com> Message-ID: <84a612dd1003221114u413a1146i8fcef49b08b30cb4@mail.gmail.com> On 22 March 2010 16:46, Ben Greear wrote: > I don't actually know who has the authority to discuss bigger changes > (like what is found in my xorp.ct tree). ?I want to come to some sort > of understanding with them before I put any real effort into breaking > out small patches for upstream SVN. I guess the buck stops with me, but Atanu and Bruce have a better overview of the state of all of the code at this point than I do. So, in effect it's the three of us right now. We're working out new processes at the moment, as things settle down. The idea is certainly to be much more open to new committers than Xorp, Inc was. It's essential we use the energy in the Xorp community to best effect, something Xorp, Inc never figured out how to do. With regards to the xorp.ct tree, could you summarize the main differences between your tree and the sourceforge tree for the list. I'd like to give everyone a chance to comment on whether there are any issues with regards to merging the two trees. - Mark From greearb at candelatech.com Mon Mar 22 11:31:02 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Mar 2010 11:31:02 -0700 Subject: [Xorp-hackers] Xorp project development. In-Reply-To: <84a612dd1003221114u413a1146i8fcef49b08b30cb4@mail.gmail.com> References: <4BA79EDD.9040807@candelatech.com> <84a612dd1003221114u413a1146i8fcef49b08b30cb4@mail.gmail.com> Message-ID: <4BA7B766.6030006@candelatech.com> On 03/22/2010 11:14 AM, Mark Handley wrote: > On 22 March 2010 16:46, Ben Greear wrote: >> I don't actually know who has the authority to discuss bigger changes >> (like what is found in my xorp.ct tree). I want to come to some sort >> of understanding with them before I put any real effort into breaking >> out small patches for upstream SVN. > > I guess the buck stops with me, but Atanu and Bruce have a better > overview of the state of all of the code at this point than I do. So, > in effect it's the three of us right now. > > We're working out new processes at the moment, as things settle down. > The idea is certainly to be much more open to new committers than > Xorp, Inc was. It's essential we use the energy in the Xorp community > to best effect, something Xorp, Inc never figured out how to do. > > With regards to the xorp.ct tree, could you summarize the main > differences between your tree and the sourceforge tree for the list. > I'd like to give everyone a chance to comment on whether there are any > issues with regards to merging the two trees. Well, it's been 2-3 years since I started...but the basic ideas are below: * Allow OSPF, RIP, BGP, OSLR, and PIM to better handle interfaces being added to and deleted from a running xorp instance via the 'xorpsh' CLI tool. This involved removing a lot of asserts and assumptions that interfaces existed in the kernel at a specific time. For instance, there is no reason to assert if you are trying to remove an interface that doesn't exist. Other changes in FEA allow users to configure interfaces that don't yet exist..this 'configured' state is remembered in the case that interfaces later appear. I wrote this several years ago, so it's a bit fuzzy. Also, Pavlin committed some of these changes..but I think most of them are still in just my tree. I also optimized code to remove some 1-sec sleeps on 'commit' so that driving xorp from xorpsh programatically doesn't take nearly so long (about .1sec for most OSPF related commits that we do in our mobile network emulator). * PIM: Fix state-machine lockup due to failure to advance state machine in some error cases. * RIP, BGP, PIM: Allow binding the protocol sockets to specific interfaces. * FEA: Support binding to specific interfaces, including multicast protocols. Use Netlink (Linux only) to filter events so that a single instance of xorp pays attention to only it's interfaces. * FEA: Support experimental Linux kernel API to provide multiple multicast routing tables per kernel instance. This requires a patch to Linux as well. Please contact greearb at candelatech.com if you want to try using this. Xorp.ct is backwards compatible with normal kernels, so unless you specifically want this feature, you do not need any additional Linux patches. NOTE on mcast: I'm working with a kernel developer to get these changes into the linux kernel, probably 2.6.35. The API might change a bit. The current code in xorp.ct is backwards compat, so it could go in anyway and then I can re-work it proper when the linux API is finalized. * OLSR: Enable building OLSR (it is broken in upstream SVN), support binding to a specific interface. To build with OLSR: scons enable_olsr=yes * Support building IPv6 multicast support on Linux. Haven't tested functionality yet. Lately, I've added a large amount of relatively boring & repetitive changes to allow compiling out much of the IPv6 code in order to allow reduced footprint compiles for smaller systems. Also, enable building without boost. I know Bruce likes boost, but I'm not a big fan of the extra dependencies. Either way, my current changes allow one to compile with boost if they prefer. If someone ever puts in a large amount of boost code that I can't easily work around, then perhaps we can remove the option to NOT depend on boost. I can post a full diff, but it would be so huge it would not really be reviewable by any mortal! I can also break out individual diffs, but I have several years worth, and I doubt anyone has time or interest to review them all in detail either. Thanks, Ben > > - Mark -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Mar 22 16:24:32 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Mar 2010 16:24:32 -0700 Subject: [Xorp-hackers] More VRRP problems. In-Reply-To: <218713.98766.qm@web58703.mail.re1.yahoo.com> References: <218713.98766.qm@web58703.mail.re1.yahoo.com> Message-ID: <4BA7FC30.7050008@candelatech.com> On 03/22/2010 06:32 AM, Li Zhao wrote: > 1. The first problem, I have had many times now. The code did not have > cleanup code to revert virtaul MAC, some signal handler function may be > needed to fix this. But use random MAC is not what RFC want because RFC > has restricted MAC format. If you use some random format there may be some > router implementation which rejects to connect to you. xorp.ct now has a fix for this MAC problem committed. I'm still having arp issues..but I think it's a kernel issue...debugging that now. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Thu Mar 25 05:47:51 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Thu, 25 Mar 2010 12:47:51 +0000 Subject: [Xorp-hackers] Poll : Which OSs to use for buildbot for xorp svn ? In-Reply-To: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> References: <4769af411003160839h26fb38abt4717ed7b975fae2f@mail.gmail.com> Message-ID: <4769af411003250547l3cb6cce0ided870211f654781@mail.gmail.com> Thanks to all those who answered , I've setup the following as buildbot systems. Freebsd 8.0 i386 Fedora 12 i386 Ubuntu 9.10 i386 Debian 5.04 sparc Commits to the sourceforge subversion archive will trigger a rebuild on these targets. Adam On 16 March 2010 15:39, Adam Greenhalgh wrote: > Hi folks, > > We are looking into setting up an automatic build checker for xorp, we > are probably only going to test against 3 OS/s initally. The current > thinking is : > > - Linux (to be decided) > - FreeBSD 8.0 > - Linux (to be decided, sparc based) > > We don't have the resources to support many more initially so it would > be very useful to know which of the current OS's people are actually > using, this may well infulence which varaiant we choose to test > against. I've setup a doodle poll here , so please vote : > > http://www.doodle.com/2tfa9962pba7uuk3 > > Many thanks > > Adam Greenhalgh > From a.greenhalgh at cs.ucl.ac.uk Thu Mar 25 07:20:43 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Thu, 25 Mar 2010 14:20:43 +0000 Subject: [Xorp-hackers] buildbot Message-ID: <4769af411003250720x62531859l38e9c7e7909f1a06@mail.gmail.com> hi folks, we have the first version of the buildbot up, http://buildbot.cs.ucl.ac.uk:8010/ the current status is : debian_5.04_sparc : compile failed freebsd_8.0_i386 : build successful fedora_12_i386 : compile failed ubuntu_9.10_i386 : build successful Adam From greearb at candelatech.com Mon Mar 29 12:01:53 2010 From: greearb at candelatech.com (Ben Greear) Date: Mon, 29 Mar 2010 12:01:53 -0700 Subject: [Xorp-hackers] Fix for xorp.ct on older kernels. Message-ID: <4BB0F921.8020306@candelatech.com> One of the optimizations I added in xorp.ct was to only pull information for devices we are configured to use, instead of asking netlink for the entire tree. This saves a lot of work when you have 1000 interfaces and xorp only configured for a few of them. However, older kernels (2.6.18, when compile without CONFIG_NET_WIRELESS_RTNETLINK, for example) cannot get netlink info for a single device. So, I just pushed a patch to xorp.ct that adds a work-around that allows xorp to fall back to grab all interfaces for kernels that only support this method. Thanks to saurabh.pandya at elitecore.com for reporting this bug and giving me enough info to track it down. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue Mar 30 17:58:49 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 30 Mar 2010 17:58:49 -0700 Subject: [Xorp-hackers] Committed a fix for MTU and carrier detect on older systems. Message-ID: <4BB29E49.8080705@candelatech.com> This was pushed to the xorp.ct tree just now. I'm not sure how much of this exists in svn and/or 1.6, but likely a bit of it as I don't recall ever messing with the carrier-detect logic before in xorp.ct. fea: Fix link & MTU detection on funky systems. Older kernels did not include MTU in the netlink message, so add a work-around to look at /sys/class/net/[dev]/mtu file for MTU. If that fails too, default to 1500. Standard Carrier detection doesn't work on all NICs, especially not open-vz virtual NICs from 2.6.18-ish kernels. Add work-around to look at /sys/class/net/[dev]/carrier if all other methods fail. In addition, old code would return failure if any of several methods failed. This patch will try each method in series and only return failure if ALL of them fail. Big thanks to Dex Petkovic for giving me remote access to his open-vz system and helping me reproduce this. -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Tue Mar 30 22:55:24 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Wed, 31 Mar 2010 06:55:24 +0100 Subject: [Xorp-hackers] Committed a fix for MTU and carrier detect on older systems. In-Reply-To: <4BB29E49.8080705@candelatech.com> References: <4BB29E49.8080705@candelatech.com> Message-ID: Hi Ben I think we need to have a discussion about what the best way to take patches from you is. Without tagging in xorp.ct, i think its going to be tricky to take a full patch from you without making mistakes. I am not sure that tagging is the best approach certainly isn't. Perhaps we need to have a xorp patches mailing list or upload location where the raw diff can be posted. Does anyone have any views on this ? Adam On 31 March 2010 01:58, Ben Greear wrote: > This was pushed to the xorp.ct tree just now. ?I'm not sure how much of > this exists in svn and/or 1.6, but likely a bit of it as I don't recall > ever messing with the carrier-detect logic before in xorp.ct. > > ? ? fea: ?Fix link & MTU detection on funky systems. > > ? ? Older kernels did not include MTU in the netlink message, so > ? ? add a work-around to look at /sys/class/net/[dev]/mtu file for > ? ? MTU. ?If that fails too, default to 1500. > > ? ? Standard Carrier detection doesn't work on all NICs, especially > ? ? not open-vz virtual NICs from 2.6.18-ish kernels. ?Add work-around > ? ? to look at /sys/class/net/[dev]/carrier if all other methods fail. > > ? ? In addition, old code would return failure if any of several methods > ? ? failed. ?This patch will try each method in series and only return > ? ? failure if ALL of them fail. > > ? ? Big thanks to Dex Petkovic for giving me remote access to his open-vz > ? ? system and helping me reproduce this. > > -- > 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 Mar 30 23:06:29 2010 From: greearb at candelatech.com (Ben Greear) Date: Tue, 30 Mar 2010 23:06:29 -0700 Subject: [Xorp-hackers] Committed a fix for MTU and carrier detect on older systems. In-Reply-To: References: <4BB29E49.8080705@candelatech.com> Message-ID: <4BB2E665.1070701@candelatech.com> On 03/30/2010 10:55 PM, Adam Greenhalgh wrote: > Hi Ben > > I think we need to have a discussion about what the best way to take > patches from you is. Without tagging in xorp.ct, i think its going to > be tricky to take a full patch from you without making mistakes. I am > not sure that tagging is the best approach certainly isn't. Perhaps we > need to have a xorp patches mailing list or upload location where the > raw diff can be posted. Does anyone have any views on this ? I auto-generate email when I commit a patch. I can easily have it send mail to some mailing list. That said, unless you really understand xorp, you may have difficulty picking patches from my tree and making them work properly. I'm still hoping I can push everything upstream at once and then fix any bugs that pop up. I've found and fixed several recently for folks using xorp.ct on older kernels and such. I'm sure there are more bugs, but there have definitely been some successes too. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.greenhalgh at cs.ucl.ac.uk Wed Mar 31 03:04:19 2010 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Wed, 31 Mar 2010 11:04:19 +0100 Subject: [Xorp-hackers] Committed a fix for MTU and carrier detect on older systems. In-Reply-To: <4BB2E665.1070701@candelatech.com> References: <4BB29E49.8080705@candelatech.com> <4BB2E665.1070701@candelatech.com> Message-ID: On 31 March 2010 07:06, Ben Greear wrote: > On 03/30/2010 10:55 PM, Adam Greenhalgh wrote: >> Hi Ben >> >> I think we need to have a discussion about what the best way to take >> patches from you is. Without tagging in xorp.ct, i think its going to >> be tricky to take a full patch from you without making mistakes. I am >> not sure that tagging is the best approach certainly isn't. Perhaps we >> need to have a xorp patches mailing list or upload location where the >> raw diff can be posted. Does anyone have any views on this ? > > I auto-generate email when I commit a patch. ?I can easily have it send > mail to some mailing list. > > That said, unless you really understand xorp, you may have difficulty > picking patches from my tree and making them work properly. ?I'm > still hoping I can push everything upstream at once and then fix any bugs that > pop up. ?I've found and fixed several recently for folks using xorp.ct > on older kernels and such. ?I'm sure there are more bugs, but there have > definitely been some successes too. > Pushing your entire tree is certainly one way to go, I guess the key issue is maintaining FreeBSD support along side Linux since I understand that most of your changes and focus is Linux related. Adam From greearb at candelatech.com Wed Mar 31 07:53:59 2010 From: greearb at candelatech.com (Ben Greear) Date: Wed, 31 Mar 2010 07:53:59 -0700 Subject: [Xorp-hackers] Committed a fix for MTU and carrier detect on older systems. In-Reply-To: References: <4BB29E49.8080705@candelatech.com> <4BB2E665.1070701@candelatech.com> Message-ID: <4BB36207.3010408@candelatech.com> On 03/31/2010 03:04 AM, Adam Greenhalgh wrote: > On 31 March 2010 07:06, Ben Greear wrote: >> On 03/30/2010 10:55 PM, Adam Greenhalgh wrote: >>> Hi Ben >>> >>> I think we need to have a discussion about what the best way to take >>> patches from you is. Without tagging in xorp.ct, i think its going to >>> be tricky to take a full patch from you without making mistakes. I am >>> not sure that tagging is the best approach certainly isn't. Perhaps we >>> need to have a xorp patches mailing list or upload location where the >>> raw diff can be posted. Does anyone have any views on this ? >> >> I auto-generate email when I commit a patch. I can easily have it send >> mail to some mailing list. >> >> That said, unless you really understand xorp, you may have difficulty >> picking patches from my tree and making them work properly. I'm >> still hoping I can push everything upstream at once and then fix any bugs that >> pop up. I've found and fixed several recently for folks using xorp.ct >> on older kernels and such. I'm sure there are more bugs, but there have >> definitely been some successes too. >> > Pushing your entire tree is certainly one way to go, I guess the key > issue is maintaining FreeBSD support along side Linux since I > understand that most of your changes and focus is Linux related. Yes, but it should be at least no worse than existing svn. If anyone uses freebsd and finds bugs, I'm willing to take a try at fixing it. I'm not aware of anyone actually using xorp on BSD...perhaps they will speak up if they are! Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com