ACI Lint¶
acilint
is a static analysis tool for Cisco ACI fabrics. Some
example use cases for such a tool include the following:
Configuration Analysis
In this purpose, it can be used to examine the APIC configuration and determine whether any of the configuration could be possibly problematic or suspicious. It examines the configuration much like static code analysis tools such as the original lint checker did for software development in C or pylint for Python. It generates Warnings and Errors that give indications that the configuration should be examined. Often these Warnings are not problems, but incomplete or stale configuration that is not currently in use.
Compliance, Governance, and Auditing
In this purpose, it can be used to determine whether the configuration meets higher level goverance and compliance rules. These rules are similar to lint style rules but exploit the APIC ability to provide additional classification tags on objects. Tags provide a simple and flexible way to classify any APIC object in one or more user-defined groups.
For example, EPGs can be tagged as secure and non-secure. A compliance rule can be defined that specifies that secure EPGs cannot consume a contract from a non-secure EPG. Upon violation of this rule, a warning or an error can be raised.
Usage¶
acilint
can be run against the current running APIC configuration or a
previously saved set of configuration snapshot files.
Running using Live APIC configuration¶
When acilint
collects the configuration directly from the APIC, it
needs the proper login credentials. These can be passed via the command
line arguments, a credentials.py
file, environment variables, or if none of
these, the user will be directly queried.
The following example shows how to run using the command line arguments for credentials:
python acilint.py -l admin -p password -u https://1.2.3.4
where admin
is the APIC login username, password
is the APIC
password, and https://1.2.3.4
is the URL used to login to the
APIC.
Running using Configuration Snapshot files¶
The snapback
application provides the ability to save snapshots of
the APIC configuration into JSON files. acilint
can use these snapshot
files as input rather than connecting to a live APIC.
This can be useful in debugging as it lets the user compare the acilint
output of the live APIC to the output of a previous configuration snapshot.
acilint
can also be used to perform some “What If” scenarios. A single
configuration snapshot actually consists of multiple snapshot files. These
configuration files are then fed as input into acilint
. These snapshot
files fed into acilint
can actually be from different configuration
snapshot versions creating an entirely new configuration that may have never
existed on the APIC, but we can run acilint
against this configuration to
check for possible errors and warnings that would occur if this configuration
were to be deployed.
The following example shows how to run with configuration snapahot files as input:
python acilint.py --snapshotfiles infra.json tenant-cisco.json fabric.json
Customization¶
By default, all checks will be performed. However, like many static
code analysis tools, acilint
is customizable and only the desired
warnings and errors can be issued.
To customize acilint
, generate a configuration file with the
following command:
python acilint.py --generateconfigfile acilint.cfg
or even shorter:
python acilint.py -g acilint.cfg
where acilint.cfg
is the filename you wish to create.
The generated configuration file will contain a list of all of the current checks being performed.
An example config file is shown below:
# acilint configuration file
# Remove or comment out any warnings or errors that you no longer wish to see
error_001
error_002
warning_001
warning_002
warning_003
To remove checks, either:
- Delete the line containing the check, or
- Comment it out by prepending a
#
in front of the check
Errors and Warnings¶
The following list of Errors and Warnings are performed by
acilint
. Since acilint
is written on top of the
acitoolkit
package, the checks are limited to the functionality
exposed by that package. However as the acitoolkit
expands, so
shall acilint
.
Warnings¶
warning_001 | Tenant has no app profile |
warning_002 | Tenant has no context |
warning_003 | AppProfile has no EPGs |
warning_004 | Context has no BridgeDomain |
warning_005 | BridgeDomain has no EPGs assigned |
warning_006 | Contract is not provided at all |
warning_007 | Contract is not consumed at all |
warning_008 | EPG providing contracts but in a Context with no enforcement |
warning_010 | EPG providing contract but consuming EPG is in a different context |
warning_011 | Contract contains bi-directional TCP Subjects |
warning_012 | Contract contains bi-directional UDP Subjects |
warning_013 | Contract has no Subjects |
warning_014 | Contract has Subjects with no Filters |
Errors¶
error_001 | BridgeDomain has no context |
error_002 | EPG has no BD assigned |
error_005 | Duplicate or overlapping subnets in Context |
error_006 | ExternalNetwork Subnets duplicated in fabric |
Critical¶
critical_001 | Compliance check example |
critical_001 is a compliance check example that will perform the following:
- Ensure that all of the EPGs in the system have been classified as
secure and nonsecure using the tagging capability provided by
the
acitoolkit
. - Ensures that none of the secure EPGs can communicate with the nonsecure EPGs by checking that no contract provided by secure EPGs is consumed by nonsecure EPGs.
Developing Checks¶
Additional checks can be added through new methods on the Checker
class. If the method begins with warning_
or error_
or
critical_
, it will automatically be executed as part of the
acilint
execution. The new checks will also automatically inherit
the customization capability through the usage of the configuration
file. Some familiarity with the acitoolkit
object model is
necessary to write additional checks.