Re: [Vyatta-users] Emergency Config paste? How do you prepare?
-BEGIN PGP SIGNED MESSAGE- On Fri, 18 Jan 2008, Justin Fletcher wrote: > There are a couple of choices. You can copy your configuration using > scp (it's /opt/vyatta/etc/config/config.boot) to another server. From a > blank slate/system, all you need to do is to configure an interface and > a default gateway, scp the configuration back, and load the restored > configuration. One caveat to anyone thinking about scp'ing config.boot files around: you need to make sure to change the interface hw-id parameters to represent the MAC address of the box it's running on, not the box from which it was copied. I once spent most of a day troubleshooting what I thought was a buggy NIC in my backup router after copying the config from my primary box. Couldn't for the life of me figure out why the interfaces kept disappearing on reboot. :) - -- Dave Pifke, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBR5FLKjuW2fOIQC3pAQET8QP/c8OvLK37T4j6PM/NlIopQpLxJgc8lsju X11B0ZpvYfZBo2FlE06tW53L7pviQaMDpKR3XNZnLrK+szl6VOXUJSLbcop+WN2H tHf7a0PyvH/DA44ud8F2JuU5U2G2ZzPpTCBXzqnn4beV4mlaMJcMvvKjTeHZgeMS BDeCLcc1Ngo= =mjeT -END PGP SIGNATURE- ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Emergency Config paste? How do you prepare?
Ken, This is great to hear. Sometimes people ask us, "What is different about Vyatta than simply getting a Linux distro and turning on some networking features?" The answer is that a Linux box manages like a bag of individual components, not like an integrated system. With Vyatta, much of the added value is in delivering something that acts more like an appliance (everything in a single config, integrated CLI with structure command set to view state and change configuration, etc.). But because it's also based on Linux at its core, you get the benefits of an open system. If you want to rsync your configs around, or add a different application, or even do custom development, the system is flexible enough to get you there. -- Dave _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Felix (C) Sent: Friday, January 18, 2008 11:34 AM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] Emergency Config paste? How do you prepare? I'm doing the same with scp and set keys for a automated backup in a script ran by cron. What's nice with vyatta vrs my current quagga/keepalived setup, is that vyatta allows for one "single config" file to be used to restore it's configuration. I had one of our junior administrator play around with this, and he was able to install vyatta on a virgin server and have it up in running in mins from "just" copying the config.boot to a USB thumb drive and performing a quick copy. Very nice ;) Once vyatta fixes some of the buggy issues that I've seen and installing better support for VRRP, I plan on deploying vyatta thru out the network core. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Waiting for xorp_rtrmgr...
> Sorry for the misunderstanding. I was under the impression > that it was 'only' in the supported version. Again, my apologies. No worries. ;-) Thanks for being part of the Vyatta Community and shooting straight with your feedback. We appreciate a frank conversation and we'll always strive to do the same thing. The short of it is that we're all in this revolution together. You want to replace your Cisco with Vyatta and we'd like the exact same thing. We think the time for near-monopoly domination of the networking market by proprietary, closed-source vendors has to come to an end. Today, Vyatta doesn't yet do everything we'd like it to and it can't satisfy every need out there. But the system is advancing every day, thanks to the dedication of some top-notch engineers and a growing community. Where we *do* have the functionality people need, I think Vyatta is a great solution. Open-source is sort of the Borg of IT industry: resistance is futile; you will be assimilated. It may not be today, or tomorrow, but we're relentless in our pursuit of improvement. As a community, managing through the rough spots and pushing things forward, we can bring about the end of near-monopoly rule in this industry. Of that, I have no doubt. You want it; we want it; it's good for the market. -- Dave ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] latency tool
You could possibly use a sniffer and then generate a data stream and then look at the difference between timestamps that the sniffer tacked on each packet. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Thompson Sent: Friday, January 18, 2008 1:28 PM To: Dave Roberts Cc: vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] latency tool On Jan 17, 2008, at 7:15 AM, Dave Roberts wrote: >> I am looking for a tool that is able to measure the (one-way) >> latency or delay. >>> From what i know ping or traceroute are only able to measure the >>> RTT. > > There is no widely-used, standard tool that I know of. I'm sure > there is > some code you could snarf from somewhere, though. > > I think the reason that a standard tool doesn't exist is that the > problem > of latency testing essentially degenerates to one of clock > synchronization > between the source and the destination. If you do RTT measurements, > the > transmitter and receiver are the same box, so the clocks are > automatically > synchronized. > > If you do one-way testing, you need to get clock synchronization > between > the source and dest nodes. If you need highly accurate measurements, > then > you might need something like GPS to help you synchronize (as > opposed to > NTP, which is great for basic date/time stuff, but won't help you much > with microsecond resolution timing). > > Once you have the clock synchronization issue nailed, the code to do > the > measurement is only about half a page of C on both the source and > test: > take a timestamp, transmit a UDP packet out, receive it sometime > later, > and take another timestamp. http://www.caida.org/workshops/isma/0312/slides/dveitch_bwest_probing.pdf http://www.cis.udel.edu/~mills/database/papers/history.pdf http://dast.nlanr.net/NPMT/ ... ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Emergency Config paste? How do you prepare?
I'm doing the same with scp and set keys for a automated backup in a script ran by cron. What's nice with vyatta vrs my current quagga/keepalived setup, is that vyatta allows for one "single config" file to be used to restore it's configuration. I had one of our junior administrator play around with this, and he was able to install vyatta on a virgin server and have it up in running in mins from "just" copying the config.boot to a USB thumb drive and performing a quick copy. Very nice ;) Once vyatta fixes some of the buggy issues that I've seen and installing better support for VRRP, I plan on deploying vyatta thru out the network core. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Waiting for xorp_rtrmgr...
Sorry for the misunderstanding. I was under the impression that it was 'only' available in the supported version. You guys are doing a great job with the Vyatta platform and I wish everyone the best. It looks like I am going to take one more stab at this. ;) Thanks, Shane McKinley Habersham EMC -Original Message- From: Dave Roberts [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 12:43 PM To: Shane McKinley; vyatta-users@mailman.vyatta.com Subject: RE: [Vyatta-users] Waiting for xorp_rtrmgr... > Is that how the Vyatta company operates? Leave bugs unpatched and hope > someone will pay for support? It would seem to make more sense to hold > features back instead of bugs. As one of the guys representing the business-side of our company, I'll weigh in here. As Justin rightly points out, the bugs are not unpatched, they are simply unreleased in a binary format. The code repositories are there and you're free to build from them directly if you want. It is not our policy to leave bugs in the community version so that people will buy the supported version. That said, each release of binaries does cost resources to build it, test it, package things up, prepare documention and release notes, etc. That's true on both the community side as well as the subscription side. Our policy is to do time-based binary releases of the community version, primarily driven around the introduction of new features, but also incorporating all bug fixes up until that point. Bugs that are fixed between the time-based Community releases are released with the next Community release cycle. Paying customers are, well, paying us to support them. That means that we do patches and fixes when required to address issues that are pressing for them. BTW, Red Hat has a similar model for Fedora vs. RHEL. While the Fedora community does update packages in Fedora on a regular basis, any given bug may remain unfixed in Fedora until the next release when a new version of a package is introduced. It certainly isn't Red Hat policy to take every patch from RHEL and apply it to Fedora as soon as it is applied in RHEL. So, I think our policies are rational and I have no problem defending them. We're definitely not being deliberately unfair to the community in any way. We *are* prioritizing paying customers over free community releases, but I think we're doing that in a reasonable way, not unlike any other commercial open source company. > I am more than willing to pay for support, but I wanted to make sure > the product would work for me first. Of course. I don't blame you for that. We'd like to help you with that as much as possible. You should note that the vyatta-users list has lots of participating from Vyatta employees who try to give you the best answer they can at any given time. It is not our policy to deliver anything but straight answers and the best support we can, whether to our paying customers or community. Many of our customers tell us that they felt comfortable with Vyatta because of the interactions they had with us *before* they became a customer. I would note that several times in the past few weeks, I have seen engineers posting to the vyatta-users mailing list with a small patch of code that a user could apply themselves if they required the fix before the next release. > I have a better idea -- Patch the bugs, and allow the software to be > functional for the purpose it was created. > Then we are talking. This is absolutely our policy, subject to the time-based release methodology that we follow. > Unfortunately it seems Vyatta is unlikely an acceptable replacement > for my Cisco 7500. That would be a bummer for us. We certainly want everybody to have a good experience with Vyatta. We would love to get you going and have you as a customer. I have been reading your blog about your Vyatta and enjoying your writing. > So far I have ran into 3 detrimental issues and the routing bugs bring > me just short of a dead end. > > 1. VRRP Limitations > 2. Policy System Limitations > 3. Routing Bugs The best I can tell you at this time is that these are all high-priority issues for us and are being addressed in the codebase right now. I would suggest you try to the upcoming Glendale Alpha ISO, which we are making available in about a week or so, to give the community some visibility into the things that are changing. There have been huge changes to all of these subsystems and I believe that all the issues you found have been removed. > I am still going to try to work around this issue, but maybe the > Vyatta company can re-think the bug-fix-holding for monetary purposes > philosophy. Again, it is not our philosophy or policy to withhold bugs from the community. The only policy we have is to allocate our release-oriented resources toward Vyatta Community releases on a time-based cycle. You're simply catching us between releases where a particular bug that you're interested in has not yet been released in
Re: [Vyatta-users] latency tool
On Jan 17, 2008, at 7:15 AM, Dave Roberts wrote: >> I am looking for a tool that is able to measure the (one-way) >> latency or delay. >>> From what i know ping or traceroute are only able to measure the >>> RTT. > > There is no widely-used, standard tool that I know of. I’m sure > there is > some code you could snarf from somewhere, though. > > I think the reason that a standard tool doesn’t exist is that the > problem > of latency testing essentially degenerates to one of clock > synchronization > between the source and the destination. If you do RTT measurements, > the > transmitter and receiver are the same box, so the clocks are > automatically > synchronized. > > If you do one-way testing, you need to get clock synchronization > between > the source and dest nodes. If you need highly accurate measurements, > then > you might need something like GPS to help you synchronize (as > opposed to > NTP, which is great for basic date/time stuff, but won’t help you much > with microsecond resolution timing). > > Once you have the clock synchronization issue nailed, the code to do > the > measurement is only about half a page of C on both the source and > test: > take a timestamp, transmit a UDP packet out, receive it sometime > later, > and take another timestamp. http://www.caida.org/workshops/isma/0312/slides/dveitch_bwest_probing.pdf http://www.cis.udel.edu/~mills/database/papers/history.pdf http://dast.nlanr.net/NPMT/ ... ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Waiting for xorp_rtrmgr...
Sorry for the misunderstanding. I was under the impression that it was 'only' in the supported version. Again, my apologies. Thanks, Shane McKinley Habersham EMC -Original Message- From: Dave Roberts [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 12:43 PM To: Shane McKinley; vyatta-users@mailman.vyatta.com Subject: RE: [Vyatta-users] Waiting for xorp_rtrmgr... > Is that how the Vyatta company operates? Leave bugs unpatched and hope > someone will pay for support? It would seem to make more sense to hold > features back instead of bugs. As one of the guys representing the business-side of our company, I'll weigh in here. As Justin rightly points out, the bugs are not unpatched, they are simply unreleased in a binary format. The code repositories are there and you're free to build from them directly if you want. It is not our policy to leave bugs in the community version so that people will buy the supported version. That said, each release of binaries does cost resources to build it, test it, package things up, prepare documention and release notes, etc. That's true on both the community side as well as the subscription side. Our policy is to do time-based binary releases of the community version, primarily driven around the introduction of new features, but also incorporating all bug fixes up until that point. Bugs that are fixed between the time-based Community releases are released with the next Community release cycle. Paying customers are, well, paying us to support them. That means that we do patches and fixes when required to address issues that are pressing for them. BTW, Red Hat has a similar model for Fedora vs. RHEL. While the Fedora community does update packages in Fedora on a regular basis, any given bug may remain unfixed in Fedora until the next release when a new version of a package is introduced. It certainly isn't Red Hat policy to take every patch from RHEL and apply it to Fedora as soon as it is applied in RHEL. So, I think our policies are rational and I have no problem defending them. We're definitely not being deliberately unfair to the community in any way. We *are* prioritizing paying customers over free community releases, but I think we're doing that in a reasonable way, not unlike any other commercial open source company. > I am more than willing to pay for support, but I wanted to make sure > the product would work for me first. Of course. I don't blame you for that. We'd like to help you with that as much as possible. You should note that the vyatta-users list has lots of participating from Vyatta employees who try to give you the best answer they can at any given time. It is not our policy to deliver anything but straight answers and the best support we can, whether to our paying customers or community. Many of our customers tell us that they felt comfortable with Vyatta because of the interactions they had with us *before* they became a customer. I would note that several times in the past few weeks, I have seen engineers posting to the vyatta-users mailing list with a small patch of code that a user could apply themselves if they required the fix before the next release. > I have a better idea -- Patch the bugs, and allow the software to be > functional for the purpose it was created. > Then we are talking. This is absolutely our policy, subject to the time-based release methodology that we follow. > Unfortunately it seems Vyatta is unlikely an acceptable replacement > for my Cisco 7500. That would be a bummer for us. We certainly want everybody to have a good experience with Vyatta. We would love to get you going and have you as a customer. I have been reading your blog about your Vyatta and enjoying your writing. > So far I have ran into 3 detrimental issues and the routing bugs bring > me just short of a dead end. > > 1. VRRP Limitations > 2. Policy System Limitations > 3. Routing Bugs The best I can tell you at this time is that these are all high-priority issues for us and are being addressed in the codebase right now. I would suggest you try to the upcoming Glendale Alpha ISO, which we are making available in about a week or so, to give the community some visibility into the things that are changing. There have been huge changes to all of these subsystems and I believe that all the issues you found have been removed. > I am still going to try to work around this issue, but maybe the > Vyatta company can re-think the bug-fix-holding for monetary purposes > philosophy. Again, it is not our philosophy or policy to withhold bugs from the community. The only policy we have is to allocate our release-oriented resources toward Vyatta Community releases on a time-based cycle. You're simply catching us between releases where a particular bug that you're interested in has not yet been released in binary form (but has been in source code form). -- Dave ___ Vyatta-users mailing list Vya
Re: [Vyatta-users] Emergency Config paste? How do you prepare?
Hi Aaron, The method that we have come up with and found to work great is using our internal workstation backup server which runs BackupPC (http://backuppc.sourceforge.net/). Since BackupPC supports backups of Linux systems (like most of our workstations), we just configured the Vyatta router as another backup client. BackupPC grabs a backup of the live config every 24 hours in our config, and archives them. In the BackupPC web interface, we can just browse the backups of the Vyatta system from any day, compare config changes with a Linux/Unix diff or by just reading it if the file isn't too huge, then initiate a restore of the config file from whatever day needed. Behind the curtain, BackupPC uses rsync to copy over the requested backup copy of the config file onto the Vyatta router. Then from the router shell, just load the restored copy of the config: # load /opt/vyatta/etc/config/config.boot and the desired config is restored. I can give more details if anyone wants, but that is the overview. Starting with a blank Vyatta config, we can get it fully re-configured with a backup config in less than 90 seconds. Without using backup software, one could have a script to scp/rsync the config files somewhere, and to restore an old config, scp the old config back on top of the live config and use the same "load" command from the router shell. Hope this helps. -Daniel [EMAIL PROTECTED] wrote: > All, > > Coming from a Cisco world, I could copy the config file to a tftp server and > once I have 1 interface open-- I could essentially paste in everything on a > blank router(or com port). This is helpful when I had to replace a failing > router with a backup one mid-day. How would I do the same with Vyatta? I was > thinking if I could SCP the config file and make it the config.boot file, I > could just do a reboot and it would all come back? > > Perhaps I'm a little confused on essentially doing a big 'paste' of all the > configs, particularly the firewall rules. > > If anyone else has some good backup strategies on vyatta router configs, > please share-- I'm a little new at this one. > > Thanks in advance, > > Aaron > ___ > Vyatta-users mailing list > Vyatta-users@mailman.vyatta.com > http://mailman.vyatta.com/mailman/listinfo/vyatta-users > -- Daniel Stickney - Linux Systems Administrator Email: [EMAIL PROTECTED] Cell: 720.422.2732 Work: 303.497.9369 ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Emergency Config paste? How do you prepare?
There are a couple of choices. You can copy your configuration using scp (it's /opt/vyatta/etc/config/config.boot) to another server. From a blank slate/system, all you need to do is to configure an interface and a default gateway, scp the configuration back, and load the restored configuration. You can also use ZipTie for configuration management; see http://www.ziptie.org. Justin On Jan 18, 2008 10:07 AM, <[EMAIL PROTECTED]> wrote: > All, > > Coming from a Cisco world, I could copy the config file to a tftp server and > once I have 1 interface open-- I could essentially paste in everything on a > blank router(or com port). This is helpful when I had to replace a failing > router with a backup one mid-day. How would I do the same with Vyatta? I was > thinking if I could SCP the config file and make it the config.boot file, I > could just do a reboot and it would all come back? > > Perhaps I'm a little confused on essentially doing a big 'paste' of all the > configs, particularly the firewall rules. > > If anyone else has some good backup strategies on vyatta router configs, > please share-- I'm a little new at this one. > > Thanks in advance, > > Aaron > ___ > Vyatta-users mailing list > Vyatta-users@mailman.vyatta.com > http://mailman.vyatta.com/mailman/listinfo/vyatta-users > ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Emergency Config paste? How do you prepare?
All, Coming from a Cisco world, I could copy the config file to a tftp server and once I have 1 interface open-- I could essentially paste in everything on a blank router(or com port). This is helpful when I had to replace a failing router with a backup one mid-day. How would I do the same with Vyatta? I was thinking if I could SCP the config file and make it the config.boot file, I could just do a reboot and it would all come back? Perhaps I'm a little confused on essentially doing a big 'paste' of all the configs, particularly the firewall rules. If anyone else has some good backup strategies on vyatta router configs, please share-- I'm a little new at this one. Thanks in advance, Aaron ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Waiting for xorp_rtrmgr...
> Is that how the Vyatta company operates? Leave bugs unpatched > and hope someone will pay for support? It would seem to make > more sense to hold features back instead of bugs. As one of the guys representing the business-side of our company, I'll weigh in here. As Justin rightly points out, the bugs are not unpatched, they are simply unreleased in a binary format. The code repositories are there and you're free to build from them directly if you want. It is not our policy to leave bugs in the community version so that people will buy the supported version. That said, each release of binaries does cost resources to build it, test it, package things up, prepare documention and release notes, etc. That's true on both the community side as well as the subscription side. Our policy is to do time-based binary releases of the community version, primarily driven around the introduction of new features, but also incorporating all bug fixes up until that point. Bugs that are fixed between the time-based Community releases are released with the next Community release cycle. Paying customers are, well, paying us to support them. That means that we do patches and fixes when required to address issues that are pressing for them. BTW, Red Hat has a similar model for Fedora vs. RHEL. While the Fedora community does update packages in Fedora on a regular basis, any given bug may remain unfixed in Fedora until the next release when a new version of a package is introduced. It certainly isn't Red Hat policy to take every patch from RHEL and apply it to Fedora as soon as it is applied in RHEL. So, I think our policies are rational and I have no problem defending them. We're definitely not being deliberately unfair to the community in any way. We *are* prioritizing paying customers over free community releases, but I think we're doing that in a reasonable way, not unlike any other commercial open source company. > I am more than willing to pay for support, but I wanted to > make sure the product would work for me first. Of course. I don't blame you for that. We'd like to help you with that as much as possible. You should note that the vyatta-users list has lots of participating from Vyatta employees who try to give you the best answer they can at any given time. It is not our policy to deliver anything but straight answers and the best support we can, whether to our paying customers or community. Many of our customers tell us that they felt comfortable with Vyatta because of the interactions they had with us *before* they became a customer. I would note that several times in the past few weeks, I have seen engineers posting to the vyatta-users mailing list with a small patch of code that a user could apply themselves if they required the fix before the next release. > I have a better idea -- Patch the bugs, and allow the > software to be functional for the purpose it was created. > Then we are talking. This is absolutely our policy, subject to the time-based release methodology that we follow. > Unfortunately it seems Vyatta is unlikely an acceptable > replacement for my Cisco 7500. That would be a bummer for us. We certainly want everybody to have a good experience with Vyatta. We would love to get you going and have you as a customer. I have been reading your blog about your Vyatta and enjoying your writing. > So far I have ran into 3 detrimental issues and the routing > bugs bring me just short of a dead end. > > 1. VRRP Limitations > 2. Policy System Limitations > 3. Routing Bugs The best I can tell you at this time is that these are all high-priority issues for us and are being addressed in the codebase right now. I would suggest you try to the upcoming Glendale Alpha ISO, which we are making available in about a week or so, to give the community some visibility into the things that are changing. There have been huge changes to all of these subsystems and I believe that all the issues you found have been removed. > I am still going to try to work around this issue, but maybe > the Vyatta company can re-think the bug-fix-holding for > monetary purposes philosophy. Again, it is not our philosophy or policy to withhold bugs from the community. The only policy we have is to allocate our release-oriented resources toward Vyatta Community releases on a time-based cycle. You're simply catching us between releases where a particular bug that you're interested in has not yet been released in binary form (but has been in source code form). -- Dave ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Waiting for xorp_rtrmgr...
I was less than couple in my previous answer :-)
I'll point out that unlike other router vendors, the source code and
build instructions
are available to everyone. One of the real benefits of open source
means that bug
fixes are available as soon as they're entered into the source code.
You also have access to package updates which include the most recent changes,
including this bug fix; it's just not in a formal release. See
http://www.vyatta.com/twiki/bin/view/Community/UnderstandingPackageArchives
for
details.
Best,
Justin
On Jan 18, 2008 5:36 AM, Shane McKinley <[EMAIL PROTECTED]> wrote:
> Is that how the Vyatta company operates? Leave bugs unpatched and hope
> someone will pay for support? It would seem to make more sense to hold
> features back instead of bugs.
>
> I am more than willing to pay for support, but I wanted to make sure the
> product would work for me first.
>
> I have a better idea -- Patch the bugs, and allow the software to be
> functional for the purpose it was created. Then we are talking.
>
> Unfortunately it seems Vyatta is unlikely an acceptable replacement for
> my Cisco 7500.
>
> So far I have ran into 3 detrimental issues and the routing bugs bring
> me just short of a dead end.
>
> 1. VRRP Limitations
> 2. Policy System Limitations
> 3. Routing Bugs
>
> I am still going to try to work around this issue, but maybe the Vyatta
> company can re-think the bug-fix-holding for monetary purposes
> philosophy.
>
> With all due respect,
>
> Shane McKinley
> Habersham EMC
>
> -Original Message-
> From: Justin Fletcher [mailto:[EMAIL PROTECTED]
>
> Sent: Thursday, January 17, 2008 9:01 PM
> To: Shane McKinley
> Cc: vyatta-users@mailman.vyatta.com
> Subject: Re: [Vyatta-users] Waiting for xorp_rtrmgr...
>
> I think you've hit bug 2390: RIB: xorp_rib crashed after a static route
> with a nextop through an unxisted interface or a route being configured
> and committed
>
> See https://bugzilla.vyatta.com/show_bug.cgi?id=2390 ; it's fixed in the
> supported version.
>
> Best,
> Justin
>
> On Jan 17, 2008 5:19 PM, Shane McKinley <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > #1 - No, but I do have a static interface-route with XX.128.128.0/20 -
>
> > the actual interface is XX.128.128.0/24 -- the reason I have this is
> > for proper BGP exporting
> > #2 - Invalid, my mistake
> > #3 - Dido to #1
> >
> > My interface-routes are last on my static routes list in the config
> > -- could this be the issue?
> >
> > -Shane
> >
> >
> >
> >
> > Are they all assigned to a system that's on a network that's directly
>
> > connected to the router?
> >
> > On Jan 17, 2008 3:59 PM, Shane McKinley <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > None of these next-hop addresses are assigned to an interface on
> > the router.
> > >
> > > Shane
> > >
> > >
> > > -Original Message-
> > > From: Justin Fletcher [mailto:[EMAIL PROTECTED] > Sent: Thu
> > 1/17/2008 6:46 PM > To: Shane McKinley > > Cc:
> > vyatta-users@mailman.vyatta.com > Subject: Re: [Vyatta-users]
> > Waiting for xorp_rtrmgr...
> > >
> > > Are the next hops directly connected? There was an issue with >
>
> > recursive route lookup -- > > On Jan 17, 2008 2:56 PM, Shane
> > McKinley <[EMAIL PROTECTED]> wrote:
> > > > I have found the static routes causing the issue:
> > > >
> > > > route XZ.85.142.64/26 {
> > > > next-hop: XX.128.129.18
> > > > metric: 1
> > > > }
> > > > route XX.128.136.216/29 {
> > > > next-hop: XZ.85.140.254
> > > > metric: 1
> > > > }
> > > > route XX.128.140.16/29 {
> > > > next-hop: XX.128.140.26
> > > > metric: 1
> > > > }
> > > >
> > > > Now, the question is why? How can I dig further to find out why
> > these > > are causing the rtrmgr to crash?
> > > >
> > > > Shane McKinley
> > > > Habersham EMC
> > > >
> > > > -Original Message-
> > > > From: Dave Roberts [mailto:[EMAIL PROTECTED] > > Sent:
> > Thursday, January 17, 2008 5:16 PM > > > > To: Shane McKinley;
> > vyatta-users@mailman.vyatta.com > > Subject: RE: [Vyatta-users]
> > Waiting for xorp_rtrmgr...
> > > >
> > > > > (SIDE NOTE: (No offense meant) Why should changing interface
> > notations > > > > > and static routes cause anything to crash?) >
>
> > > > > It shouldn't. That's one of the big things we're fixing in
> > Glendale.
> > The
> > > > Routermanager process did not handle errors well at all. It has
> > been > > eliminated entirely in Glendale.
> > > >
> > > > -- Dave
> > > >
> > > > ___
> > > > Vyatta-users mailing list
> > > > Vyatta-users@mailman.vyatta.com
> > > > http://mailman.vyatta.com/mailman/listinfo/vyatta-users
> > > >
> > >
> > >
> >
> >
> ___
> Vyatta-users mailing list
> Vyatta-users@mailman.vy
Re: [Vyatta-users] Waiting for xorp_rtrmgr...
Is that how the Vyatta company operates? Leave bugs unpatched and hope
someone will pay for support? It would seem to make more sense to hold
features back instead of bugs.
I am more than willing to pay for support, but I wanted to make sure the
product would work for me first.
I have a better idea -- Patch the bugs, and allow the software to be
functional for the purpose it was created. Then we are talking.
Unfortunately it seems Vyatta is unlikely an acceptable replacement for
my Cisco 7500.
So far I have ran into 3 detrimental issues and the routing bugs bring
me just short of a dead end.
1. VRRP Limitations
2. Policy System Limitations
3. Routing Bugs
I am still going to try to work around this issue, but maybe the Vyatta
company can re-think the bug-fix-holding for monetary purposes
philosophy.
With all due respect,
Shane McKinley
Habersham EMC
-Original Message-
From: Justin Fletcher [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 9:01 PM
To: Shane McKinley
Cc: vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] Waiting for xorp_rtrmgr...
I think you've hit bug 2390: RIB: xorp_rib crashed after a static route
with a nextop through an unxisted interface or a route being configured
and committed
See https://bugzilla.vyatta.com/show_bug.cgi?id=2390 ; it's fixed in the
supported version.
Best,
Justin
On Jan 17, 2008 5:19 PM, Shane McKinley <[EMAIL PROTECTED]> wrote:
>
>
>
> #1 - No, but I do have a static interface-route with XX.128.128.0/20 -
> the actual interface is XX.128.128.0/24 -- the reason I have this is
> for proper BGP exporting
> #2 - Invalid, my mistake
> #3 - Dido to #1
>
> My interface-routes are last on my static routes list in the config
> -- could this be the issue?
>
> -Shane
>
>
>
>
> Are they all assigned to a system that's on a network that's directly
> connected to the router?
>
> On Jan 17, 2008 3:59 PM, Shane McKinley <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > None of these next-hop addresses are assigned to an interface on
> the router.
> >
> > Shane
> >
> >
> > -Original Message-
> > From: Justin Fletcher [mailto:[EMAIL PROTECTED] > Sent: Thu
> 1/17/2008 6:46 PM > To: Shane McKinley > > Cc:
> vyatta-users@mailman.vyatta.com > Subject: Re: [Vyatta-users]
> Waiting for xorp_rtrmgr...
> >
> > Are the next hops directly connected? There was an issue with >
> recursive route lookup -- > > On Jan 17, 2008 2:56 PM, Shane
> McKinley <[EMAIL PROTECTED]> wrote:
> > > I have found the static routes causing the issue:
> > >
> > > route XZ.85.142.64/26 {
> > > next-hop: XX.128.129.18
> > > metric: 1
> > > }
> > > route XX.128.136.216/29 {
> > > next-hop: XZ.85.140.254
> > > metric: 1
> > > }
> > > route XX.128.140.16/29 {
> > > next-hop: XX.128.140.26
> > > metric: 1
> > > }
> > >
> > > Now, the question is why? How can I dig further to find out why
> these > > are causing the rtrmgr to crash?
> > >
> > > Shane McKinley
> > > Habersham EMC
> > >
> > > -Original Message-
> > > From: Dave Roberts [mailto:[EMAIL PROTECTED] > > Sent:
> Thursday, January 17, 2008 5:16 PM > > > > To: Shane McKinley;
> vyatta-users@mailman.vyatta.com > > Subject: RE: [Vyatta-users]
> Waiting for xorp_rtrmgr...
> > >
> > > > (SIDE NOTE: (No offense meant) Why should changing interface
> notations > > > > > and static routes cause anything to crash?) >
> > > > It shouldn't. That's one of the big things we're fixing in
> Glendale.
> The
> > > Routermanager process did not handle errors well at all. It has
> been > > eliminated entirely in Glendale.
> > >
> > > -- Dave
> > >
> > > ___
> > > Vyatta-users mailing list
> > > Vyatta-users@mailman.vyatta.com
> > > http://mailman.vyatta.com/mailman/listinfo/vyatta-users
> > >
> >
> >
>
>
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
