...
The connection info hash inside each device/node tells opConfig how to connect to the device and what "language/personality" it has. An example connection_info hash:
Code Block | ||
---|---|---|
| ||
'connection_info' => { 'transport' => 'Telnet', 'credential_set' => 'set3', 'personality' => 'ios', 'node' => 'asgard', 'host' => '192.168.88.254', 'priveleged_credential_set' => 'set3' } |
...
The os_info hash describes a bit about the operating system used by the device/node. An example os_info hash:
Code Block | ||
---|---|---|
| ||
'os_info' => { 'featureset' => 'Unknown', 'version' => '12.4(25f)', 'platform' => '1841', 'train' => '12.4', 'major' => '12.4', 'os' => 'IOS', 'image' => 'C1841-ADVENTERPRISEK9-M' } |
...
When opConfig does it's own discovery, it maps the operating system into a personality, here is that map:
Code Block | ||
---|---|---|
| ||
my $os_personality_map = { 'AlterPath' => 'unknown', 'CatOS' => 'catos', 'Cat2820' => 'catos', 'Cat1900' => 'catos', 'Darwin' => 'bash', 'ExtremeXOS' => 'extremexos', 'FastHub' => 'unknown', 'Foundry' => 'foundry', 'HP' => 'hp', 'IOS' => 'ios', 'junos' => 'unknown', 'NAMOS' => 'unknown', 'NetScout' => 'unknown', 'Nokia' => 'unknown', 'nortel' => 'unknown', 'ONS' => 'unknown', 'PIX' => 'pixos', 'fwsm' =>'fwsm', 'fwsm3' => 'fwsm3', 'pixos7' => 'pixos7', 'Solaris' => 'bash', 'SwitchProbe' => 'unknown', 'Linux' => 'bash', 'VPN' => 'unknown', 'Windows' => 'unknown', 'Z_Unknown_Unix' => 'csh' }; |
...
Here is an example command set, I will break it down in the sections that follow:
Code Block | ||
---|---|---|
| ||
'IOS_DAILY' => { 'os_info' => { 'version' => '/12.2|12.4|15.0/', 'os' => 'IOS' }, 'aging_info' => { 'age' => 'forever' }, 'scheduling_info' => { 'run_commands_on_separate_connection' => 'false' }, commands => [ { 'tags' => 'config,version,troubleshooting, detect-change', 'command' => 'show version', 'privileged' => 'false', 'multipage' => 'true', 'run_command_on_separate_connection' => 'false', 'command_filters' => [ '/uptime is/' ] } }} |
...
Filtering by OS info
Code Block | ||
---|---|---|
| ||
#filter using a regular expression: 'os_info' => { 'version' => '/12.2|12.4|15.0/', 'os' => 'IOS' }, # or just the specific os and that's all: 'os_info' => { 'os' => 'Linux' }, |
...
Not all output is worthy of change detection, configuration information generally is while performance information generally is not. The configuration for a router, for example, is but the usage on an interface is not. Commands that have the tag detect-change will have change detection run on them by opConfig. If the output is different a new revision is stored along with the changes that were made. If it is not defined a new revision is stored (if the output is different) but no changes are tracked (and will not be reported in the GUI as a change).
Code Block | ||
---|---|---|
| ||
'tags' => 'detect-change', |
There is one more issue to resolve. Not all changes found may be considered important or relavent. To ignore unimportant changes a set of command filters can be added to a command:
Code Block | ||
---|---|---|
| ||
'command_filters' => [ '/uptime is/' ] |
...
If you would like to change the default behaviour and have opConfig run each command on it's own session/connection, opCommon.nmis can be modified:
Code Block | ||
---|---|---|
| ||
# to run each command in it's own session, change this to true 'opconfig_run_commands_on_separate_connection' => 'false', |
It makes a lot more sense to tell opConfig to run a set of commands on their own or, in most cases, just a single command on it's own. Running a command or set of commands on their own session/connection:
Code Block | ||
---|---|---|
| ||
#to run all commands in a command set define this key to be true 'scheduling_info' => { 'run_commands_on_separate_connection' => 'true' }, # to run just a specific command on it's own commands => [ { 'command' => 'show version', 'run_command_on_separate_connection' => 'true', }] |
...
Aging is not currently in use, look for more info about this in later versions
Usage
TBD