Network configuration archiving
Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID. Some might say "it took ages to get rancid to do kinda what we want!", but not all software ages well. One might work in environments where archived configurations are needed to even start provisioning, one might desire a separation between actual config and transcient data. As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool. RANCID - http://www.shrubbery.net/rancid/ * Support for a wild variery of devices and operating systems * complex perl code base [1] * no central developer team, the internet is littered with forks Oxidized - https://github.com/ytti/oxidized * modern & sexy approach with queue & workers * RESTful API (example: can bump devices to the head of the queue) * small user & developer base * written in that ruby language Gerty - https://github.com/ssinyagin/gerty * Seems easier to extend than RANCID * perl... * small user & developer base punc - https://code.google.com/p/punc/ * written in python, based on notch [2] * no recent developments (although 2011 was a good wine year) [1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new-device-support-to... [2] - https://code.google.com/p/notch/ Kind regards, Job
On 10/24/13 17:25 , Job Snijders wrote:
Some might say "it took ages to get rancid to do kinda what we want!", but not all software ages well. One might work in environments where archived configurations are needed to even start provisioning, one might desire a separation between actual config and transcient data.
Rancid certainly has its warts, but other than needing to test, pull hair, and patch things for new OS/platform deployments, it still generally Just Works once you have it installed, IME... and references like http://www.shrubbery.net/rancid/SteveSmithFedora15.pdf that are a bit dated still work well as a guide for deployment on more recent server OSes.
As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool.
I can't claim any knowledge of its actual functionality, but I've also heard of NOC Project - http://nocproject.org/ From the docs, it seems like it's trying to be more of an all-in-one do-everything package than just an archiving tool, but it could be worth investigating. It claims support for a wide array of kit, and seems to have a non-trivial user base. I'm sure I'm not the only one who'd be interested to hear if your evaluation determines that there is a R,RAN*ID out there that we've been overlooking. -e
Rancid is known to crash cisco devices doing config backups. I've seen it on 7200/7500 routers multiple times Tammy Sent from my iPhone On Oct 24, 2013, at 21:05, Erik Muller <erikm@buh.org> wrote:
On 10/24/13 17:25 , Job Snijders wrote:
Some might say "it took ages to get rancid to do kinda what we want!", but not all software ages well. One might work in environments where archived configurations are needed to even start provisioning, one might desire a separation between actual config and transcient data.
Rancid certainly has its warts, but other than needing to test, pull hair, and patch things for new OS/platform deployments, it still generally Just Works once you have it installed, IME... and references like http://www.shrubbery.net/rancid/SteveSmithFedora15.pdf that are a bit dated still work well as a guide for deployment on more recent server OSes.
As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool.
I can't claim any knowledge of its actual functionality, but I've also heard of NOC Project - http://nocproject.org/ From the docs, it seems like it's trying to be more of an all-in-one do-everything package than just an archiving tool, but it could be worth investigating. It claims support for a wide array of kit, and seems to have a non-trivial user base.
I'm sure I'm not the only one who'd be interested to hear if your evaluation determines that there is a R,RAN*ID out there that we've been overlooking. -e
No it's not rancids fault :) Sent from my iPhone On Oct 24, 2013, at 21:25, Nick Hilliard <nick@foobar.org> wrote:
On 25/10/2013 11:19, Tammy Firefly wrote:
Rancid is known to crash cisco devices doing config backups. I've seen it on 7200/7500 routers multiple times
this isn't a rancid problem though.
Nick
On Thu, Oct 24, 2013 at 10:19 PM, Tammy Firefly <tammy-lists@wiztech.biz>wrote:
Rancid is known to crash cisco devices doing config backups. I've seen it on 7200/7500 routers multiple times
I don't doubt it, but since RANCID only uses show commands; I would suspect that any similar tool that uses similar show commands, could expose the same issue ---- which is obviously a router CLI bug not a RANCID bug.
Tammy--
-JH
Yes I 100% agree its a IOS bug. It had something to do with the way it ended a ssh session. That was one reason we got rid of cisco at our edges and use juniper which has config backup built into JunOS (via ssh/FTP) --Tammy Sent from my iPhone On Oct 24, 2013, at 21:29, Jimmy Hess <mysidia@gmail.com> wrote:
On Thu, Oct 24, 2013 at 10:19 PM, Tammy Firefly <tammy-lists@wiztech.biz> wrote:
Rancid is known to crash cisco devices doing config backups. I've seen it on 7200/7500 routers multiple times
I don't doubt it, but since RANCID only uses show commands; I would suspect that any similar tool that uses similar show commands, could expose the same issue ---- which is obviously a router CLI bug not a RANCID bug.
Tammy-- -JH
On (2013-10-24 23:05 -0400), Erik Muller wrote:
Rancid certainly has its warts, but other than needing to test, pull hair, and patch things for new OS/platform deployments, it still generally Just Works once you have it installed, IME... and references like
For us problem with rancid is that we're quite married to configuration backups, provisioning depends on them. And we have good number of devices in rancid and rancid runs take several hours. Now we may need refreshed configuration backup to satisfy some dependencies to complete some work, but if rancid is running we cannot, in worst case, we may need to postpone some work to next working day. We have 'one off' hack script for rancid, which fetches just one device right now, but we cannot run it if rancid proper is currently running. Other than that, rancid works very reliably and is highly robust. For style rancid does not get points as there is terrible amount of code duplication for different platforms. Philosophically speaking, configuration backups should be completely useless, full configuration to network should be generated from central place in fully automated manner. -- ++ytti
On Fri, 25 Oct 2013 10:07:49 +0300 Saku Ytti <saku@ytti.fi> wrote:
On (2013-10-24 23:05 -0400), Erik Muller wrote:
Rancid certainly has its warts, but other than needing to test, pull hair, and patch things for new OS/platform deployments, it still generally Just Works once you have it installed, IME... and references like
For us problem with rancid is that we're quite married to configuration backups, provisioning depends on them. And we have good number of devices in rancid and rancid runs take several hours. Now we may need refreshed configuration backup to satisfy some dependencies to complete some work, but if rancid is running we cannot, in worst case, we may need to postpone some work to next working day.
We have 'one off' hack script for rancid, which fetches just one device right now, but we cannot run it if rancid proper is currently running.
Have you tried running multiple rancid instances in parallel? (each talking to a different batch of devices)
Other than that, rancid works very reliably and is highly robust. For style rancid does not get points as there is terrible amount of code duplication for different platforms.
The main reason we're all stuck with rancid is that there is no standardized way to securely pull configurations and other information from devices built by all major vendors. Rancid, as horribly written as it may be, has over the years incorporated ways to deal with the quirks of pretty much every CLI out there. This is hard to duplicate.
Philosophically speaking, configuration backups should be completely useless, full configuration to network should be generated from central place in fully automated manner.
The diff-ed backups that rancid provides serve another purpose: verifying that what your NMS says should be configured matches the actual device configurations. Regards, Martin
On (2013-10-25 10:43 +0200), Martin Pels wrote:
The diff-ed backups that rancid provides serve another purpose: verifying that what your NMS says should be configured matches the actual device configurations.
Diffing one rancid config to another rancid config would not help with this at all. You'd need to diff provisiong system config to rancid config which is extremely complex problem, as your provisioning system is not creating 'post parser' config, it's creating config in completely different way than what it will be after parser. The hard/wrong solution the problem is to have per-platform parsing intelligence reimplemented in your provisioning system. The two easy solutions are a) when your provisioning system pushes change out, it saves the config it sends, and then it views what route stored and makes note of them being the same. If it has this logic, then rancid is not needed. b) before your provisioning system pushes change out, it checks timestamp on config, if timestamp is newer than its latest config push, it regenerates full configuration. In this scenario also, rancid is not needed. However going 100% of config is in systems is not really something many target, nor have I seen good products for it. It's not actually hard problem, not even when targeting multiple platforms. As platform specific intelligence can be kept very low with some design choices. -- ++ytti
There are companies like Tail-F who are trying to use things like YANG definitions to dynamically build a standardized CLI which is sort of cross-platform compatible. The CLI you connect to is external to any network equipment which records changes, does checking ahead of time, and records atomic changes to the network. The plugins underneath are there to translate the common CLI to Junos/NETCONF/XR CLI etc. This isn't a new idea, tools like Opsware tried to do this in the past and at least one provider I've worked for had their own common config language then translated to real device configurations. The idea is no one ever logs into a router to make a change, all changes are recorded by the system making the change for you. The same system generally takes care of committing the config to device, handling errors during provisioning, making sure configurations are synchronized between it and the device, etc. I'Ve been a couple places who had good home-grown RCS-based config management systems I wish they would have open sourced. -Phil On 10/25/13 8:32 AM, "Saku Ytti" <saku@ytti.fi> wrote:
On (2013-10-25 10:43 +0200), Martin Pels wrote:
The diff-ed backups that rancid provides serve another purpose: verifying that what your NMS says should be configured matches the actual device configurations.
Diffing one rancid config to another rancid config would not help with this at all. You'd need to diff provisiong system config to rancid config which is extremely complex problem, as your provisioning system is not creating 'post parser' config, it's creating config in completely different way than what it will be after parser.
The hard/wrong solution the problem is to have per-platform parsing intelligence reimplemented in your provisioning system.
The two easy solutions are
a) when your provisioning system pushes change out, it saves the config it sends, and then it views what route stored and makes note of them being the same. If it has this logic, then rancid is not needed.
b) before your provisioning system pushes change out, it checks timestamp on config, if timestamp is newer than its latest config push, it regenerates full configuration. In this scenario also, rancid is not needed.
However going 100% of config is in systems is not really something many target, nor have I seen good products for it. It's not actually hard problem, not even when targeting multiple platforms. As platform specific intelligence can be kept very low with some design choices.
-- ++ytti
I've been intrigued by the stuff going on with NetKit and Autonetkit ( http://www.autonetkit.org). See the preso from Pycon 2013 in Australia: http://www.youtube.com/watch?v=EGK5jjyUBCQ It seems like all the bits are available between the various efforts of applications but nothing that really ties everything together. I'll agree with Phil that the most comprehensive I've seen is from Tail-F, as far as off the shelf packages go. The problem with this space is one of agility and scale. If you have only a handful of pieces of gear, all different platforms, it's tough to get a system going that implements policy the way you want or need. It's also difficult to be agile and implement new platforms or capabilities without lots of work. If you have hundreds of routers it makes sense to put forth the effort but then becomes difficult to keep up with moves/add/changes with individual elements. A strict and rigorous change management process can help keep running config in sync with offline systems but can be difficult to manage in the heat of the moment while troubleshooting. I think this is some of the hope of "SDN", build standard ways of implementing config and policy that are consistent, easy to manage, yet agile, and comprehensive. However, I think it will be difficult to find a One Size Fits All application. Perhaps there can be some common enough ground where network kit implementation becomes as ubiquitous as system implementations. --chip On Fri, Oct 25, 2013 at 10:22 AM, Phil Bedard <bedard.phil@gmail.com> wrote:
There are companies like Tail-F who are trying to use things like YANG definitions to dynamically build a standardized CLI which is sort of cross-platform compatible. The CLI you connect to is external to any network equipment which records changes, does checking ahead of time, and records atomic changes to the network. The plugins underneath are there to translate the common CLI to Junos/NETCONF/XR CLI etc. This isn't a new idea, tools like Opsware tried to do this in the past and at least one provider I've worked for had their own common config language then translated to real device configurations.
The idea is no one ever logs into a router to make a change, all changes are recorded by the system making the change for you. The same system generally takes care of committing the config to device, handling errors during provisioning, making sure configurations are synchronized between it and the device, etc.
I'Ve been a couple places who had good home-grown RCS-based config management systems I wish they would have open sourced.
-Phil
On 10/25/13 8:32 AM, "Saku Ytti" <saku@ytti.fi> wrote:
On (2013-10-25 10:43 +0200), Martin Pels wrote:
The diff-ed backups that rancid provides serve another purpose: verifying that what your NMS says should be configured matches the actual device configurations.
Diffing one rancid config to another rancid config would not help with this at all. You'd need to diff provisiong system config to rancid config which is extremely complex problem, as your provisioning system is not creating 'post parser' config, it's creating config in completely different way than what it will be after parser.
The hard/wrong solution the problem is to have per-platform parsing intelligence reimplemented in your provisioning system.
The two easy solutions are
a) when your provisioning system pushes change out, it saves the config it sends, and then it views what route stored and makes note of them being the same. If it has this logic, then rancid is not needed.
b) before your provisioning system pushes change out, it checks timestamp on config, if timestamp is newer than its latest config push, it regenerates full configuration. In this scenario also, rancid is not needed.
However going 100% of config is in systems is not really something many target, nor have I seen good products for it. It's not actually hard problem, not even when targeting multiple platforms. As platform specific intelligence can be kept very low with some design choices.
-- ++ytti
-- Just my $.02, your mileage may vary, batteries not included, etc....
On (2013-10-25 10:22 -0400), Phil Bedard wrote:
There are companies like Tail-F who are trying to use things like YANG
Tail-F is very cool, but it needs support for both direction. Abstract data -> Vendor Config (easy problem, just agnostic ascii template) Vendor Config -> Abstract data (hard problem) I don't think the latter is needed, why verify what is wrong in the config, either it is what you want it to be or it's something else, in which case you make it what you want it to be. The price of knowing exactly what to fix to bring it up-to standard is very high. It's definitely nice thing to have and necessary thing to have unless 100% is from system. If 100% is from system, we can ommit the hard problem. To support new vendor, you just write simple new vendor-specific templates focusing on exactly just the subset of stuff your abstract data needs. Instead if you need to understand vendor config, you need to understand every nyance of it, vendors own parser gets it wrong, my chances are very small to get it right. -- ++ytti
The vendor config->abstract data (really structured data) is the point of YANG definitions. I think I'm correct but Tail-F's system works by importing the YANG definitions from the router and it builds the CLI interpreter based on those definitions. The trick is getting the standards bodies and vendors to support common definitions for common protocols like they sorta have with SNMP. So when I need to put a route on a router it's the same common definition and I guess the pie in the sky goal is then using common NETCONF syntax as well to do the configuration. So the router itself is doing the translation into whatever native format it uses, not someone having to write translation scripts which are a PITA when vendor syntax changes, or some new feature is added, etc. Phil On 10/25/13 11:03 AM, "Saku Ytti" <saku@ytti.fi> wrote:
On (2013-10-25 10:22 -0400), Phil Bedard wrote:
There are companies like Tail-F who are trying to use things like YANG
Tail-F is very cool, but it needs support for both direction.
Abstract data -> Vendor Config (easy problem, just agnostic ascii template) Vendor Config -> Abstract data (hard problem)
I don't think the latter is needed, why verify what is wrong in the config, either it is what you want it to be or it's something else, in which case you make it what you want it to be. The price of knowing exactly what to fix to bring it up-to standard is very high. It's definitely nice thing to have and necessary thing to have unless 100% is from system. If 100% is from system, we can ommit the hard problem. To support new vendor, you just write simple new vendor-specific templates focusing on exactly just the subset of stuff your abstract data needs. Instead if you need to understand vendor config, you need to understand every nyance of it, vendors own parser gets it wrong, my chances are very small to get it right.
-- ++ytti
On (2013-10-25 14:27 -0400), Phil Bedard wrote:
The vendor config->abstract data (really structured data) is the point of YANG definitions. I think I'm correct but Tail-F's system works by
interpreter based on those definitions. The trick is getting the standards bodies and vendors to support common definitions for common protocols like they sorta have with SNMP. So when I need to put a route
The idea is great, but I don't feel it's actually practical. Since already MIB standards lag features and getting MIB into vendor code lags further. So if you would only limit yourself deploying stuff that all your vendors support via common standard model like YANG, you'd be in clear competitive disadvantage in launching products. If you can avoid doing VendorConfig -> Abstract (Or structured as you say) Data. Things get just so much simpler. -- ++ytti
On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders < job.snijders@hibernianetworks.com> wrote:
Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Does the nature of the codebase and future development matter all that much? Not to dismiss it as a factor, but I think other criteria should be more important :) Nrmally when I would want to compare software ---- I would be concerned first and foremost, (1) What does it do/what makes it unique -- is something special about package X over package Y?; (2) Does it meet all the minimum needs I have right now to be a viable solution? Does it grab all my configs and put them in a permanent revision control system? :) (3) How reliable is it, can I trust it? Is it very secure and safe to use? It's no good if it breaks, fails, or does something dangerous. How much care and feeding will it need to keep working? If it needs complex repair work every few weeks, I don't like it. (4) How easy is it to get up and running, and to perform any required ongoing maintenance (5) What extra nice to have functionality does it have? (6) Maybe other stuff like what language its written in, if extra features need to be added -- -JH
Hiw about SolarWinds Config Mgmt software? On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia@gmail.com> wrote:
On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders < job.snijders@hibernianetworks.com> wrote:
Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Does the nature of the codebase and future development matter all that much? Not to dismiss it as a factor, but I think other criteria should be more important :)
Nrmally when I would want to compare software ---- I would be concerned first and foremost, (1) What does it do/what makes it unique -- is something special about package X over package Y?; (2) Does it meet all the minimum needs I have right now to be a viable solution? Does it grab all my configs and put them in a permanent revision control system? :)
(3) How reliable is it, can I trust it? Is it very secure and safe to use? It's no good if it breaks, fails, or does something dangerous. How much care and feeding will it need to keep working? If it needs complex repair work every few weeks, I don't like it.
(4) How easy is it to get up and running, and to perform any required ongoing maintenance (5) What extra nice to have functionality does it have?
(6) Maybe other stuff like what language its written in, if extra features need to be added
-- -JH
Puppet, Chef, cfEngine, etc... the list goes on and on, it's a matter of taste (no chef pun intended) and what you're familiar with as well as what works for your device configurations and the management team -----Original Message----- From: Kenneth McRae [mailto:kenneth.mcrae@dreamhost.com] Sent: Thursday, October 24, 2013 11:45 PM To: Jimmy Hess Cc: nanog@nanog.org Subject: Re: Network configuration archiving Hiw about SolarWinds Config Mgmt software? On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia@gmail.com> wrote:
On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders < job.snijders@hibernianetworks.com> wrote:
Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Does the nature of the codebase and future development matter all that much? Not to dismiss it as a factor, but I think other criteria should be more important :)
Nrmally when I would want to compare software ---- I would be concerned first and foremost, (1) What does it do/what makes it unique -- is something special about package X over package Y?; (2) Does it meet all the minimum needs I have right now to be a viable solution? Does it grab all my configs and put them in a permanent revision control system? :)
(3) How reliable is it, can I trust it? Is it very secure and safe to use? It's no good if it breaks, fails, or does something dangerous. How much care and feeding will it need to keep working? If it needs complex repair work every few weeks, I don't like it.
(4) How easy is it to get up and running, and to perform any required ongoing maintenance (5) What extra nice to have functionality does it have?
(6) Maybe other stuff like what language its written in, if extra features need to be added
-- -JH
Is that licensed per device or per user out of curiosity ? Sent from my iPhone On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae@dreamhost.com> wrote:
Hiw about SolarWinds Config Mgmt software? On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia@gmail.com> wrote:
On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders < job.snijders@hibernianetworks.com> wrote:
Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Does the nature of the codebase and future development matter all that much? Not to dismiss it as a factor, but I think other criteria should be more important :)
Nrmally when I would want to compare software ---- I would be concerned first and foremost, (1) What does it do/what makes it unique -- is something special about package X over package Y?; (2) Does it meet all the minimum needs I have right now to be a viable solution? Does it grab all my configs and put them in a permanent revision control system? :)
(3) How reliable is it, can I trust it? Is it very secure and safe to use? It's no good if it breaks, fails, or does something dangerous. How much care and feeding will it need to keep working? If it needs complex repair work every few weeks, I don't like it.
(4) How easy is it to get up and running, and to perform any required ongoing maintenance (5) What extra nice to have functionality does it have?
(6) Maybe other stuff like what language its written in, if extra features need to be added
-- -JH
By device or you can purchase an unlimited device count.. On Oct 24, 2013 8:59 PM, "Tammy Firefly" <tammy-lists@wiztech.biz> wrote:
Is that licensed per device or per user out of curiosity ?
Sent from my iPhone
On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae@dreamhost.com> wrote:
Hiw about SolarWinds Config Mgmt software? On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia@gmail.com> wrote:
On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders < job.snijders@hibernianetworks.com> wrote:
Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Does the nature of the codebase and future development matter all that much? Not to dismiss it as a factor, but I think other criteria should be more important :)
Nrmally when I would want to compare software ---- I would be concerned first and foremost, (1) What does it do/what makes it unique -- is something special about package X over package Y?; (2) Does it meet all the minimum needs I have right now to be a viable solution? Does it grab all my configs and put them in a permanent revision control system? :)
(3) How reliable is it, can I trust it? Is it very secure and safe to use? It's no good if it breaks, fails, or does something dangerous. How much care and feeding will it need to keep working? If it needs complex repair work every few weeks, I don't like it.
(4) How easy is it to get up and running, and to perform any required ongoing maintenance (5) What extra nice to have functionality does it have?
(6) Maybe other stuff like what language its written in, if extra features need to be added
-- -JH
Or use perfectly good (RANCID + cvsweb) free software. Hmm. On Thu, 24 Oct 2013, Kenneth McRae wrote:
By device or you can purchase an unlimited device count.. On Oct 24, 2013 8:59 PM, "Tammy Firefly" <tammy-lists@wiztech.biz> wrote:
Is that licensed per device or per user out of curiosity ?
Sent from my iPhone
On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae@dreamhost.com> wrote:
Hiw about SolarWinds Config Mgmt software? On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia@gmail.com> wrote:
On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders < job.snijders@hibernianetworks.com> wrote:
Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Does the nature of the codebase and future development matter all that much? Not to dismiss it as a factor, but I think other criteria should be more important :)
Nrmally when I would want to compare software ---- I would be concerned first and foremost, (1) What does it do/what makes it unique -- is something special about package X over package Y?; (2) Does it meet all the minimum needs I have right now to be a viable solution? Does it grab all my configs and put them in a permanent revision control system? :)
(3) How reliable is it, can I trust it? Is it very secure and safe to use? It's no good if it breaks, fails, or does something dangerous. How much care and feeding will it need to keep working? If it needs complex repair work every few weeks, I don't like it.
(4) How easy is it to get up and running, and to perform any required ongoing maintenance (5) What extra nice to have functionality does it have?
(6) Maybe other stuff like what language its written in, if extra features need to be added
-- -JH
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Rancid is great, we use it. It's hard to justify paying money for something that really isn't that complicated, especially stupid licensing fees. One of my problems with rancid though is that many of the commands it runs can be somewhat intrusive, and also smacks of trying to use a configuration management system as an active monitoring tool. Go into the commandtable entries for your various devices, and remove everything except the show running-config bits (or whatever your $vendor uses) and you'll run into a lot less risk of blowing a device up with rancid, also a lot quicker execution times. Or just remove rancid entirely, and just ssh show running-config (using rsa keys) on your devices and dump the output into cvs/svn/whatever. Not everything has ssh though. :( -chris 2013/10/24 Jon Lewis <jlewis@lewis.org>
Or use perfectly good (RANCID + cvsweb) free software. Hmm.
On Thu, 24 Oct 2013, Kenneth McRae wrote:
By device or you can purchase an unlimited device count..
On Oct 24, 2013 8:59 PM, "Tammy Firefly" <tammy-lists@wiztech.biz> wrote:
Is that licensed per device or per user out of curiosity ?
Sent from my iPhone
On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae@dreamhost.com> wrote:
Hiw about SolarWinds Config Mgmt software?
On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia@gmail.com> wrote:
On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders <
job.snijders@hibernianetworks.**com<job.snijders@hibernianetworks.com>> wrote:
Dear all,
I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Does the nature of the codebase and future development matter all that much? Not to dismiss it as a factor, but I think other criteria
should
be more important :)
Nrmally when I would want to compare software ---- I would be
concerned
first and foremost, (1) What does it do/what makes it unique -- is
something special about package X over package Y?; (2) Does it meet all the minimum needs I have right now to be a
viable
solution?
Does it grab all my configs and put them in a permanent revision control system? :)
(3) How reliable is it, can I trust it? Is it very secure and safe to use? It's no good if it breaks, fails, or does something dangerous. How much care and feeding will it need to keep working? If it needs complex repair work every few weeks, I don't like it.
(4) How easy is it to get up and running, and to perform any required ongoing maintenance (5) What extra nice to have functionality does it have?
(6) Maybe other stuff like what language its written in, if extra features need to be added
-- -JH
------------------------------**------------------------------**---------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/**pgp<http://www.lewis.org/~jlewis/pgp>for PGP public key_________
I know you said open source, but we're using Solarwinds Cattools with very good results. We also have Rancid running in the background.
________________________________ From: Job Snijders <job.snijders@hibernianetworks.com> To: nanog@nanog.org Sent: Thursday, October 24, 2013 2:25 PM Subject: Network configuration archiving
Dear all,
I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Some might say "it took ages to get rancid to do kinda what we want!", but not all software ages well. One might work in environments where archived configurations are needed to even start provisioning, one might desire a separation between actual config and transcient data.
As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool.
RANCID - http://www.shrubbery.net/rancid/ * Support for a wild variery of devices and operating systems * complex perl code base [1] * no central developer team, the internet is littered with forks
Oxidized - https://github.com/ytti/oxidized * modern & sexy approach with queue & workers * RESTful API (example: can bump devices to the head of the queue) * small user & developer base * written in that ruby language
Gerty - https://github.com/ssinyagin/gerty * Seems easier to extend than RANCID * perl... * small user & developer base
punc - https://code.google.com/p/punc/ * written in python, based on notch [2] * no recent developments (although 2011 was a good wine year)
[1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new-device-support-to... [2] - https://code.google.com/p/notch/
Kind regards,
Job
On Thu, Oct 24, 2013 at 11:25:26PM +0200, Job Snijders wrote:
As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool.
For the last ~8 years we've used a very simple in-house bash script that uses SNMP to tell the switch to write its config using tftp, and then does a wr mem. It then checks the configs into a subversion repository and e-mails out any diffs. One criteria we had was that our config backup system wasn't going to get CLI access to any routers if at all possible, and this turned out to be a good alternative. I can't think of many times when it's failed to work; occasionally the odd switch might not respond, but that's rare. The only possible issue being that we're 100% Cisco, so I don't know if other vendors support the same MIBs. I'll try and post the script (250 lines) somewhere if anyone's interested. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
SNMP is a good/ quick way to do it, however you should keep in mind that your configurations are not being sent securely if you're using tftp. Cisco devices do allow you to also use ftp, rcp, scp and sftp. As far as I'm aware (someone please correct me if I'm wrong), but Cisco is the only vendor that supports this. It's almost as easy to have a python/ perl script to do the exact same thing as Matthew described but with SSH instead of SNMP. Regards On Fri, Oct 25, 2013 at 9:59 PM, Matthew Newton <mcn4@leicester.ac.uk>wrote:
On Thu, Oct 24, 2013 at 11:25:26PM +0200, Job Snijders wrote:
As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool.
For the last ~8 years we've used a very simple in-house bash script that uses SNMP to tell the switch to write its config using tftp, and then does a wr mem. It then checks the configs into a subversion repository and e-mails out any diffs.
One criteria we had was that our config backup system wasn't going to get CLI access to any routers if at all possible, and this turned out to be a good alternative. I can't think of many times when it's failed to work; occasionally the odd switch might not respond, but that's rare.
The only possible issue being that we're 100% Cisco, so I don't know if other vendors support the same MIBs.
I'll try and post the script (250 lines) somewhere if anyone's interested.
Cheers,
Matthew
-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Fri, 25 Oct 2013 08:08:44 -0400, Michael Kehoe <michael.k.kehoe@gmail.com> wrote:
As far as I'm aware (someone please correct me if I'm wrong), but Cisco is the only vendor that supports this.
Ascend did as well. I used to backup the MAX-TNT's via snmp. (I've not researched the subject in over a decade.) --Ricky
From: Ricky Beam [mailto:jfbeam@gmail.com] On Fri, 25 Oct 2013 08:08:44 -0400, Michael Kehoe <michael.k.kehoe@gmail.com> wrote:
As far as I'm aware (someone please correct me if I'm wrong), but Cisco is the only vendor that supports this.
Ascend did as well. I used to backup the MAX-TNT's via snmp.
Made them easier to recover after they caught on fire? Jamie
On Oct 25, 2013, at 8:08 AM, Michael Kehoe <michael.k.kehoe@gmail.com> wrote:
As far as I'm aware (someone please correct me if I'm wrong), but Cisco is the only vendor that supports this.
It's almost as easy to have a python/ perl script to do the exact same thing as Matthew described but with SSH instead of SNMP.
You can do automation stuff like this with JunOS as well. NTT has talked about what they have done in the past here: http://www.nanog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf - Jared
On Fri, Oct 25, 2013 at 02:27:42PM +0200, Job Snijders wrote:
On Fri, Oct 25, 2013 at 12:59:48PM +0100, Matthew Newton wrote:
I'll try and post the script (250 lines) somewhere if anyone's interested.
It is almost always good to open source your tools, for others to learn and benefit from! :-)
As much as I totally agree with you, the problem is that if I spent all my time publishing each small script I wrote, I'd never have time to write small scripts :-) I've removed local config details and pushed it up to github. Hopefully there's enough info contained to enable someone else to make use of it / learn from it / improve it. https://github.com/mcnewton/cisco-config-backups When I wrote that, neither git or scp to switches were available. It's quite likely that there are at least two obvious improvements that can be made. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 10/25/13 07:59, Matthew Newton wrote:
For the last ~8 years we've used a very simple in-house bash script that uses SNMP to tell the switch to write its config using tftp, and then does a wr mem. It then checks the configs into a subversion repository and e-mails out any diffs.
One criteria we had was that our config backup system wasn't going to get CLI access to any routers if at all possible, and this turned out to be a good alternative. I can't think of many times when it's failed to work; occasionally the odd switch might not respond, but that's rare.
The only possible issue being that we're 100% Cisco, so I don't know if other vendors support the same MIBs.
I'll try and post the script (250 lines) somewhere if anyone's interested.
Cheers,
Matthew
I have a very similar home-grown script, however I did need a mix of tftp and telnet/CLI depending on the particular platform (for instance recently I couldn't get the tftp approach to work with remote devices running IOS-XR or IOS-XE). An overly simplified telnet module might look like: ----------------------- #!/bin/sh login="" passwd="" router="" timeout=1 # increase this for larger configs (sleep 1; echo $login; sleep 1; echo $passwd; sleep 1; echo term leng 0; sleep 1; echo "sh run"; sleep $timeout; echo exit; sleep 1; ) | telnet $router 2>&1 ----------------------- -Scott
How simple do you want to get? We do something like this: ! archive path tftp://1.2.3.4/$h- write-memory ! -----Original Message----- From: Job Snijders [mailto:job.snijders@hibernianetworks.com] Sent: Thursday, October 24, 2013 5:25 PM To: nanog@nanog.org Subject: Network configuration archiving Dear all, I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID. Some might say "it took ages to get rancid to do kinda what we want!", but not all software ages well. One might work in environments where archived configurations are needed to even start provisioning, one might desire a separation between actual config and transcient data. As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool. RANCID - http://www.shrubbery.net/rancid/ * Support for a wild variery of devices and operating systems * complex perl code base [1] * no central developer team, the internet is littered with forks Oxidized - https://github.com/ytti/oxidized * modern & sexy approach with queue & workers * RESTful API (example: can bump devices to the head of the queue) * small user & developer base * written in that ruby language Gerty - https://github.com/ssinyagin/gerty * Seems easier to extend than RANCID * perl... * small user & developer base punc - https://code.google.com/p/punc/ * written in python, based on notch [2] * no recent developments (although 2011 was a good wine year) [1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new-device-support-to... [2] - https://code.google.com/p/notch/ Kind regards, Job
I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.
Some people in this thread have been mentioning config generators. There is / was something called netomata. A web search brings up various references, but their main web site appears to be offline. Tweets stopped back in '10, freecode.com's last submission is Jan 2011, so I don't know if they are still alive. But seemed like an interesting tool then.
Some might say "it took ages to get rancid to do kinda what we want!", but not all software ages well. One might work in environments where archived configurations are needed to even start provisioning, one might desire a separation between actual config and transcient data.
As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool.
RANCID - http://www.shrubbery.net/rancid/ * Support for a wild variery of devices and operating systems * complex perl code base [1] * no central developer team, the internet is littered with forks
Oxidized - https://github.com/ytti/oxidized * modern & sexy approach with queue & workers * RESTful API (example: can bump devices to the head of the queue) * small user & developer base * written in that ruby language
Gerty - https://github.com/ssinyagin/gerty * Seems easier to extend than RANCID * perl... * small user & developer base
punc - https://code.google.com/p/punc/ * written in python, based on notch [2] * no recent developments (although 2011 was a good wine year)
[1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new- device-support-to-rancid/ [2] - https://code.google.com/p/notch/
Kind regards,
Job
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (22)
-
chip -
Christopher Rogers -
Edward Beheler -
Eric A Louie -
Erik Muller -
Jamie Bowden -
Jared Mauch -
Jimmy Hess -
Job Snijders -
Jon Lewis -
Kenneth McRae -
Martin Pels -
Matthew Newton -
Michael Kehoe -
Nick Hilliard -
Nolan Rollo -
Phil Bedard -
R. Scott Evans -
Raymond Burkholder -
Ricky Beam -
Saku Ytti -
Tammy Firefly