search

ansible-network / network-engine

This role provides the foundation for building network roles by providing modules and plugins that are common to all Ansible Network roles.
GNU General Public License v3.0
112 stars 53 forks source link

Feature request new lookup plugin - report on not allowed configuration #212

Closed nohir0 closed 2 years ago

nohir0 commented 5 years ago

ISSUE TYPE

ANSIBLE VERSION

ansible 2.7.5
ansible-network.network-engine, v2.7.2

Network OS

ios
ios-xe
ios-xr
nxos

SUMMARY

The current implementation of the netcfg_diff lookup plugin allows to create a diff based on a "have" and a "want" configuration - the result is basically the lines that are missing in the "have" configuration.

Network engineers also need to make sure, that certain configurations/features are never configured/active on certain network devices. It would be great to extend the scope if this plugin (or create a new one) that allow to compare a network configuration against a set of config parameters that should never occur in a network device configuration.

EXPECTED RESULTS

Compare a "have" configuration to a "must not" template and if the "have" configuration contains any of the "must not" parameters, generate a "no parameter" template as a report.

EXAMPLES FOR "MUST NOT" TEMPLATES

E.g. these global configurations should never be activated on any Cisco device:

service config           
service tcp-small-servers
service udp-small-servers
service pad
service finger

Also on interfaces, there are some configurations, that should never occur on certain important ports e.g. if they are uplink interfaces or Server ports:

interface range <RANGE>
 no logging event link-status
 no snmp trap link-status

Another simple example, only ssh should be enabled on any network device - never telnet

line vty 0 15
 transport input telnet
Qalthos commented 5 years ago

This does not seem to be a good fit for the netcfg_diff plugin, as this doesn't do anything with generating diffs. This could probably be done with a new plugin to blacklist config entries, though it is not clear to me exactly what would happen if an offending line is found.

nohir0 commented 5 years ago

I try to summarize our ideas below, anyway I think you may be right - a new plugin/module could be more appropriate - if that is the case and you do not see this fitting into the whole network-engine environment maybe we start a module/plugin contribution from our side...

Indeed creating diffs is only the foundation of further processing of such plugin. It would be in fact a compliance feature for network configurations, which would be a perfect fit for Ansible because of its basic functionality to touch lots of devices...

Because of the nature of e.g. Cisco IOS devices and its "config blocks with idents" it should be possible to identify any global configuration parts (without idents) but also configuration blocks (like interfaces, routing processes a.s.o) in a task and compare based on config lines and/or blocks in the play. So the module or plugin could have input parameters for "search start" and "search end" of a block in the play task. This enables the possibility to only compare parts of the whole config (e.g. only interfaces) or create multiple tasks in a play using the compliance plugin multiple times to compare several parts of a configuration source.

Input is either a complete configuration file or live configuration collected from a device. This input (filtered based on the defined match start and end) is then compared against j2 template files (also a input parameter of the playbook task) that represent the expected config parts of this configuration source (again, the config matching between "block start" and "block end")

Output would be e.g. in a file on local directory - a whitelist file containing matched lines/blocks, a blacklist file containing missing lines in the configuration compared to the template and maybe also a remaining config with all the rest of the configuration that has not be compared at all (outside of match start and match end parameters)

Unfortunately it will not be easily possible to create an automated "remediation" template to automatically remove the blacklisted config entries from devices, because just putting a "no" before that lines will not work in all cases as we know - again an IOS cli restriction - but we have at least a detailed compliance report in a directory which is a good foundation for further processing...

trishnaguha commented 5 years ago

cc @cidrblock @ikhan2010

cidrblock commented 2 years ago

network engine is no longer being actively developed, closing this one out.