acilint is a static analysis tool for Cisco ACI fabrics. Some
example use cases for such a tool include the following:
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.
acilint can be run against the current running APIC configuration or a
previously saved set of configuration snapshot files.
Running using Live APIC configuration¶
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://184.108.40.206
admin is the APIC login username,
password is the APIC
https://220.127.116.11 is the URL used to login to the
Running using Configuration Snapshot files¶
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
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
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.
acilint, generate a configuration file with the
python acilint.py --generateconfigfile acilint.cfg
or even shorter:
python acilint.py -g acilint.cfg
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
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 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
|Tenant has no app profile
|Tenant has no context
|AppProfile has no EPGs
|Context has no BridgeDomain
|BridgeDomain has no EPGs assigned
|Contract is not provided at all
|Contract is not consumed at all
|EPG providing contracts but in a Context with no enforcement
|EPG providing contract but consuming EPG is in a different context
|Contract contains bi-directional TCP Subjects
|Contract contains bi-directional UDP Subjects
|Contract has no Subjects
|Contract has Subjects with no Filters
|BridgeDomain has no context
|EPG has no BD assigned
|Duplicate or overlapping subnets in Context
|ExternalNetwork Subnets duplicated in fabric
|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
- 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.
Additional checks can be added through new methods on the
class. If the method begins with
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.