[rancid] Ignoring (Boot)Flash Changes (IOS and IOS XE)

Discussion:

Mark Tinka

2014-07-23 15:02:44 UTC

Hi all.

I've been checking around and can't seem to find any current
solutionsk (most of the ones relate to earlier versions of
RANCID, and there have been some changes to the "rancid"
script since).

Would anyone know the currently accepted method to ignore
constant RANCID updates due to (Boot)flash changes on IOS
and IOS XE systems? Thanks.

Mark

Mark Tinka

2014-07-23 15:03:56 UTC

Permalink

Ah, and just to add, I'm running 2.3.8. Thanks.

Mark.

Post by Mark Tinka
Hi all.
I've been checking around and can't seem to find any
current solutionsk (most of the ones relate to earlier
versions of RANCID, and there have been some changes to
the "rancid" script since).
Would anyone know the currently accepted method to ignore
constant RANCID updates due to (Boot)flash changes on IOS
and IOS XE systems? Thanks.
Mark

Alan McKinnon

2014-07-23 15:15:35 UTC

Permalink

Post by Mark Tinka
Ah, and just to add, I'm running 2.3.8. Thanks.
Mark.

Hi Mark,

I made patches to deal with that exact thing. But, I'm no longer
employed at the company across the hallway from you so I can't look them
up right now. I still have friends there though and can call in a favour.

While we wait, you can give it a bash ourself, it's real easy. You edit
the script "rancid", look up the sub that's run for "show bootflash" and
add a check for the stuff to be ignored, something like:

next if <some regex>

--
Alan McKinnon
***@gmail.com

Mark Tinka

2014-07-23 15:29:03 UTC

Permalink

Post by Alan McKinnon
I made patches to deal with that exact thing. But, I'm no
longer employed at the company across the hallway from
you so I can't look them up right now.

That's too bad :-(...

Post by Alan McKinnon
I still have
friends there though and can call in a favour.

Always helps :-).

Post by Alan McKinnon
While we wait, you can give it a bash ourself, it's real
easy. You edit the script "rancid", look up the sub
that's run for "show bootflash" and add a check for the
next if <some regex>

-----

This is what we have:

sub ShowFlash {
# skip if this is 7000, 7200, 7500, or 12000; else we end up with
# redundant data from dir /all slot0:
print STDERR " In ShowFlash: $_" if ($debug);

while (<INPUT>) {
tr/\015//d;
last if (/^$prompt/);
next if (/^(\s*|\s*$cmd\s*)$/);
return(1) if ($type =~ /^(12[40]|7)/);
return(1) if ($ios eq "XE");
return(1) if (/^\s*\^\s*$/);
return(1) if (/Line has invalid autocommand /);
return(1) if (/(Invalid (input|command) detected|Type help or )/i);
return(-1) if (/command authorization failed/i);
# the pager can not be disabled per-session on the PIX
if (/^(<-+ More -+>)/) {
my($len) = length($1);
s/^$1\s{$len}//;
}

# Filter dhcp database
next if (/dhcp_[^. ]*\.txt/);

# /\s+(multiple-fs|nv_hdr|vlan\.dat)$/ && next;
/\s+(config.text|private-config.text|multiple-fs|nv_hdr|vlan\.dat)$/ && next;
ProcessHistory("FLASH","","","!Flash: $_");
}
ProcessHistory("","","","!\n");
return;
}

-----

I hacked it a little, changing:

/\s+(multiple-fs|nv_hdr|vlan\.dat)$/ && next;

... to:

/\s+(config.text|private-config.text|multiple-fs|nv_hdr|vlan\.dat)$/ &&

But couldn't get it to work. That tip said to disable
commands that run against checking of the file system,
but that was a couple of RANCID's a go and the script
has changed a great deal.

I can estimate what those commands would be for this tip,
but I'd rather ask here to be sure.

Mark.

Alan McKinnon

2014-07-23 15:50:24 UTC

Permalink

This post might be inappropriate. Click to display it.

Mark Tinka

2014-07-23 15:58:11 UTC

Permalink

Post by Alan McKinnon
I worked out a more general solution a while back as our
NetOps want to see that the file exists and want to see
huge changes in size. So I converted filesizes to
kilo-mega-giga byte form and diffed that. The noise
reduced cconsiderably. Check my postings for the last 3
months, the subject starts with [PATCH]

Andrew Ohnstad

2014-07-24 16:23:48 UTC

Permalink

I found this:
http://www.shrubbery.net/pipermail/rancid-discuss/2014-June/007677.html

But I need the solution for Nexus/nxrancid. Alan, can you post that one
too?

Also, a more fundamental question... how does rancid fit in with the
specialized scripts like nxrancid, cat5rancid, etc... Specifically, if I
was using only Nexus gear in my Rancid-monitored network, would I need to
make changes in rancid _and_ nxrancid, or just the latter?

Thanks,
Andrew

Post by Mark Tinka

Yes, this would be a better approach, as the RANCID output
is useful to know whether disk space will become an issue,
but capturing all the small changes creates too much noise.
Large changes in MB (instead of KB) deltas is acceptable.
Let me hunt for your patch and revert.
Mark.
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

Alan McKinnon

2014-07-24 18:06:03 UTC

Permalink

Post by Andrew Ohnstad
http://www.shrubbery.net/pipermail/rancid-discuss/2014-June/007677.html
But I need the solution for Nexus/nxrancid. Alan, can you post that one
too?

that's the very thread I was thinking of in my reply to Mark

Post by Andrew Ohnstad
Also, a more fundamental question... how does rancid fit in with the
specialized scripts like nxrancid, cat5rancid, etc... Specifically, if
I was using only Nexus gear in my Rancid-monitored network, would I need
to make changes in rancid _and_ nxrancid, or just the latter?

The names of the various *rancid scripts are a historical artifact:

Once upon a time long long ago, Cisco was the only player. This may even
have been in the days of CatOS. Anyway, there was only 1 major script
that did all the heavy lifting and it was naturally called "rancid". It
got other wrapper scripts to co-ordinate activities, like rancid-run to
wrap everything, par to manage firing off several parallel threads,
clogin and so on and so on.

After a while, the word got out that rancid was truly awesome[1] so
folks adapted the "rancid" worker script to deal with other OSes are
prepended an initial to the name to tell them apart, hence names like
"jrancid" and "xrancid".

Enter the confusion: almost everyone nowadays logically assumes that
"rancid" must be the main controller and launcher and the script for IOS
would be named something else. Not so: "rancid" deals with IOS only[2]

To find out what script you need to edit, get the device's type from
router.db and look it up in the rancid-fe script, it's a perl hash-key.
The corresponding value is the name of the parser script used.

So, for Nexus you will edit either rancid or nxrancid depending on what
you use in router.db. rancid actually does a reasonable job of dealing
with Nexus although nxrancid is better at it.

[1] Really Awesome New Cisco cOnfig Differ is not just a cute name, it's
factually accurate :-)

[2] Ignore for the moment that many router OSes are sufficiently
IOS-like that rancid can actually do a mostly-decent job of dealing with
them.

Post by Andrew Ohnstad
Thanks,
Andrew

--
Alan McKinnon
***@gmail.com

Mark Tinka

2014-07-25 06:39:36 UTC

Permalink

Post by Alan McKinnon
that's the very thread I was thinking of in my reply to
Mark

That's the one :-).

I'll test it today and let you know.

Mark.

Mark Tinka

2014-07-28 13:11:10 UTC

Permalink

This post might be inappropriate. Click to display it.

Mark Tinka

2014-08-01 06:28:22 UTC

Permalink

Post by Mark Tinka
I now need to quiet down the "tracelogs" noise.

Managed to sort this out.

I created another section dedicated to "harddisk", since the
existing one only handles "bootflash", and the "tracelogs"
are coming from the "harddisk":

-----

# filter frequently changing files from IOX harddisk
if ($dev =~ /harddisk/) {
next if (/temp_cont\s*$/);
next if (/uptime_cont\s*$/);
next if (/tracelogs\s*$/);
}

-----

Cheers,

Mark.

Mark Tinka

2014-07-25 06:39:12 UTC

Permalink

Post by Andrew Ohnstad
http://www.shrubbery.net/pipermail/rancid-discuss/2014-Ju
ne/007677.html

Many thanks, Andrew.

Mark.