Discussion:
[rancid] "show env all" vs. "show env" on Cisco IOS
Terry Kennedy
2015-09-03 07:11:03 UTC
Permalink
I'm trying to monitor power supply / fan status on assorted Cisco gear.
However, the Cisco CLI is inconsistent (so, what else is new?) across the
various platforms.

Here is a brief summary (all running their respective latest IOS - 15
for everything except the 4948, 3750 and 2651XM, which are running 12).
"Expected output" indicates a full (for that platform) report, while any-
thing else is the error message or one-line status:

Platform "show env all" "show env"
--------------------- ------------------------ --------------------
Catalyst 4500X-16SFP+ "Invalid input detected" Expected output
Catalyst 4948-10GE "Invalid input detected" Expected output
Catalyst 3750-48TS Expected output "Incomplete command"
3845 Expected output Expected output
7206VXR / NPE-1 Expected output "All measured values
are normal"
ASR1000 Expected output Expected output
2651XM Expected output Expected output
ASA5506 "Invalid input detected" Expected output

Some platforms only accept "show env all", some only accept "show env",
some accept both and produce identical output and some accept both and
produce different output.

It seems that "the right thing" would be to try the "show env all" and
only if that reports an error, try "show env". Simply sending both com-
mands would seem to risk duplicate lines in the RANCID file for the cases
where the device returns the same data for both commands, or a spurious
"All measured values are normal" if it accepts both commands but returns
different data.

I could clone the cisco device from rancid.types.base into multiple
different sub-device types in rancid.types.conf, but that means a lot
of extra work dealing with new RANCID versions. But that has the advan-
tage of not having to parse wildly different output types in the same
routine.

What would be great is if rancid.types.conf had an "inherit" state-
ment that would let me include a device type from rancid.types.base
and then let me add (or possibly remove) commands, something like this:

cisco-env;inherit;cisco
cisco-env;command;ios_local::ShowEnv_local;show env

cisco-no-env;inherit;cisco
cisco-no-env;nocommand;;show env all

Has anybody waded through this morass previously and come up with a
good solution?

Terry Kennedy http://www.tmk.com
***@tmk.com New York, NY USA
heasley
2015-09-03 20:48:15 UTC
Permalink
Post by Terry Kennedy
I'm trying to monitor power supply / fan status on assorted Cisco gear.
However, the Cisco CLI is inconsistent (so, what else is new?) across the
various platforms.
Here is a brief summary (all running their respective latest IOS - 15
for everything except the 4948, 3750 and 2651XM, which are running 12).
"Expected output" indicates a full (for that platform) report, while any-
Platform "show env all" "show env"
--------------------- ------------------------ --------------------
Catalyst 4500X-16SFP+ "Invalid input detected" Expected output
Catalyst 4948-10GE "Invalid input detected" Expected output
Catalyst 3750-48TS Expected output "Incomplete command"
3845 Expected output Expected output
7206VXR / NPE-1 Expected output "All measured values
are normal"
ASR1000 Expected output Expected output
2651XM Expected output Expected output
ASA5506 "Invalid input detected" Expected output
Some platforms only accept "show env all", some only accept "show env",
some accept both and produce identical output and some accept both and
produce different output.
It seems that "the right thing" would be to try the "show env all" and
only if that reports an error, try "show env". Simply sending both com-
mands would seem to risk duplicate lines in the RANCID file for the cases
where the device returns the same data for both commands, or a spurious
"All measured values are normal" if it accepts both commands but returns
different data.
there is code in ShowEnv to skip a second copy of the output if the first
succeeded.
Post by Terry Kennedy
I could clone the cisco device from rancid.types.base into multiple
different sub-device types in rancid.types.conf, but that means a lot
of extra work dealing with new RANCID versions. But that has the advan-
tage of not having to parse wildly different output types in the same
routine.
What would be great is if rancid.types.conf had an "inherit" state-
ment that would let me include a device type from rancid.types.base
cisco-env;inherit;cisco
cisco-env;command;ios_local::ShowEnv_local;show env
cisco-no-env;inherit;cisco
cisco-no-env;nocommand;;show env all
Has anybody waded through this morass previously and come up with a
good solution?
thats an interesting idea. more grammar would be needed for commands that
are order dependant.
Terry Kennedy
2015-09-05 23:23:13 UTC
Permalink
Post by heasley
Post by Terry Kennedy
What would be great is if rancid.types.conf had an "inherit" state-
ment that would let me include a device type from rancid.types.base
cisco-env;inherit;cisco
cisco-env;command;ios_local::ShowEnv_local;show env
cisco-no-env;inherit;cisco
cisco-no-env;nocommand;;show env all
thats an interesting idea. more grammar would be needed for commands that
are order dependant.
Perhaps numbering the lines in the rancid.types.base file, similar to the
way IOS numbers entries in access lists to allow insertions?

It would probably make sense to add this to the end of each command and
make it optional so existing local rancid.types.conf files wouldn't break
due to the syntax change. Something like:

# Cisco IOS device & Allied Telesis AW+
cisco;script;rancid -t cisco
cisco;login;clogin
cisco;module;ios
cisco;inloop;ios::inloop
cisco;command;ios::ShowVersion;show version;100
cisco;command;ios::ShowRedundancy;show redundancy secondary;110
cisco;command;ios::ShowIDprom;show idprom backplane;120
cisco;command;ios::ShowInstallActive;show install active;130
cisco;command;ios::ShowEnv;show env all;140
cisco;command;ios::ShowRSP;show rsp chassis-info;150
cisco;command;ios::ShowGSR;show gsr chassis;160
cisco;command;ios::ShowGSR;show diag chassis-info;170
...

and then rancid.types.conf would have:

# Replace sequence 140
cisco-env;inherit;cisco
cisco-env;command;ios_local::ShowEnv_local;show env;140

# Add new sequence 145
cisco-add-env;inherit;cisco
cisco-add-env;command;ios_local::ShowEnv_local;show env;145

# Delete sequence 140
cisco-no-env;inherit;cisco
cisco-no-env;nocommand;140

Alternatively, if some device require the use of semicolons in their
commands, the syntax could be:

cisco;command:100;ios::ShowVersion;show version;
cisco;command:110;ios::ShowRedundancy;show redundancy secondary
cisco;command:120;ios::ShowIDprom;show idprom backplane
cisco;command:130;ios::ShowInstallActive;show install active
cisco;command:140;ios::ShowEnv;show env all
cisco;command:150;ios::ShowRSP;show rsp chassis-info
cisco;command:160;ios::ShowGSR;show gsr chassis
cisco;command:170;ios::ShowGSR;show diag chassis-info

The use of colons to indicate the command sequence should still keep old
files compatible - if there is no colon in the command, simply execute them
in the order found (the old way).

Terry Kennedy http://www.tmk.com
***@tmk.com New York, NY USA

Loading...