nanog mailing list archives
Re: Network configuration archiving
From: Phil Bedard <bedard.phil () gmail com>
Date: Fri, 25 Oct 2013 10:22:07 -0400
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
Current thread:
- Network configuration archiving Job Snijders (Oct 24)
- Re: Network configuration archiving Erik Muller (Oct 24)
- Re: Network configuration archiving Tammy Firefly (Oct 24)
- Re: Network configuration archiving Nick Hilliard (Oct 24)
- Re: Network configuration archiving Tammy Firefly (Oct 24)
- Re: Network configuration archiving Jimmy Hess (Oct 24)
- Re: Network configuration archiving Tammy Firefly (Oct 24)
- Re: Network configuration archiving Tammy Firefly (Oct 24)
- Re: Network configuration archiving Erik Muller (Oct 24)
- Re: Network configuration archiving Saku Ytti (Oct 25)
- Re: Network configuration archiving Martin Pels (Oct 25)
- Re: Network configuration archiving Saku Ytti (Oct 25)
- Re: Network configuration archiving Phil Bedard (Oct 25)
- Re: Network configuration archiving chip (Oct 25)
- Re: Network configuration archiving Saku Ytti (Oct 25)
- Re: Network configuration archiving Phil Bedard (Oct 25)
- Re: Network configuration archiving Saku Ytti (Oct 25)
- Re: Network configuration archiving Kenneth McRae (Oct 24)
- RE: Network configuration archiving Nolan Rollo (Oct 24)
- Re: Network configuration archiving Tammy Firefly (Oct 24)
- Re: Network configuration archiving Kenneth McRae (Oct 24)
- Re: Network configuration archiving Jon Lewis (Oct 24)