[j-nsp] Config archive subtleties

Phil Mayers p.mayers at imperial.ac.uk
Thu Aug 8 03:40:45 EDT 2013

On 08/07/2013 08:25 PM, Phil Shafer wrote:
>> 7 aug 2013 kl. 18:03 skrev Phil Mayers <p.mayers at imperial.ac.uk>:
>> Recently this fell apart on us, as the SSH key on the server changed and the archival
>> transfers started to silently[1] fail.
> Ick.  Silence is deadly.  This (and the other issues) is now PR 910647.


>> All of which has me wondering if the feature is more trouble than it's worth.
> We definitely should be making it more robust and stable, but to
> me the value of catching each commit as a distinct delta is a win.
> It should also have the commit time, user, and commit comment, if
> given.  Having this in a repo means one can ask questions like "who
> has changed config in my network since last Friday?" or "when did
> this statement get added in the first place?".

Agreed; preserving the separate commits and metadata is a big win, IMO, 
and I really like the feature. It was surprising and disappointing to 
find it had hung up!

(To the many people who suggested RANCID - thanks, but we already have a 
config backup system. The question was specifically about strategies to 
integrate the JunOS commit archive feature with such systems *given* the 
failure modes I noted. This is a somewhat non-trivial problem to solve 
in the general case; sure you can have a scheduled "fetch hourly" 
belt&braces job, but that is both racy and discards data in some failure 

> What else can we do to make this more worthwhile?

Trigger a chassis minor alarm if archive has failed for >X minutes? 
(Configurable, of course). The PR may say that, but I can't see it yet ;o)

More information about the juniper-nsp mailing list