Archived

This repository will be archived. It is superseeded by a newer, more simplified Easy ACI, based on a YAML Schema Model.

Easy ACI

This Module will be archived in September as I am no longer maintaining it. It is surperseeded above.

The two models were so different I didn't merge them here.

Easy ACI - Comprehensive example for ACI & NDO

There are two examples in this Repository. The first example is shown in the primary folders:

• access-policies/
• admin/
• fabric-policies/
• switch/
• system_settings/
• tenants/
• virtual-networking/

This is to show an example of how the module can be used with a single ACI Fabric.

The more complex example is shown in the ./RICH/ Folder Structure. This is what is being used for our lab in Richfield Ohio. In these examples there are four sub-folders.

• RICH/Asgard - The First ACI Fabric
• RICH/Wakanda - The Second ACI Fabric
• RICH/Odin - Nexus Dashboard Orchestrator managing the stretched Tenants Between the two Fabrics
• RICH/shared_settings - YAML Data that is the same between Asgard and Wakanda

The Structure of the YAML Files is very flexible. You can have all the YAML Data in a single file or you can have it in multiple individual folders like is shown in this module. The important part is that the data.utils_yaml_merge.model is configured to read the folders that you put the Data into. In the single Data Center example the data is read from all the folders in the root path described above (access-policies, admin, fabric-policies, switch, system-settings, tenants, virtual-networking). In comparison, the Asgard and Wakanda Fabrics, read files in their respective home directory plus they shared data found in the ./RICH/shared_settings folder.

Additionally because the ./RICH/Odin/ Nexus Dashboard Fabric Only supports pushing configuration with the tenants module, currently, only the built_in_tenants and tenants modules are defined. The additional function for Odin is that it is pulling in the switch_profiles, from both Asgard and Wakanda, to build EPG -> Static Path Bindings in NDO.

Modify variables.auto.tfvars to match environment

variables.auto.tfvars contains Terraform variables that I felt fit better outside of the YAML Data Model. These variables should be configured to be unique to the deployment environment, but examples are shown for the Richfield environemnt in the module.

Notes for the variables.auto.tfvars

• APIC Attributes: used if the controller_type is apic.
• NDO Attributes: used if the controller_type is ndo.
• management_epgs: necessary if you are using inband EPG's, and or the ooband EPG is not default. Both true for our use case.
• annotations: helpful, but not required. This is used on Tenant Objects that support the annotations attribute. You can customize this according to anything desired to add, but by default the use case is the version of the easy_aci module is being added.

Note 1: Modules can be added or removed dependent on the use case. The primary example shown is consuming/showing a full environment deployment. But in the ./RICH/Odin/ example, it is just using the tenant modules.

Note 2: The reason for the seperation of built_in_tenants vs tenants is to make sure objects are always created in common/mgmt first. So they can be consumed by user tenants or Admin/Fabric etc (management EPGs for example). If nothing is being configured in common/mgmt/infra the built_in_tenant is not necessary.

YAML Schema Notes for Autocompletion, Help, and Error Validation:

If you would like to enable Autocompletion, Help Context, and Error Validation, (HIGHLY RECOMMENDED) perform the following configuration in Visual Studio Code.

Install the YAML extension by Red Hat

Extensions: Search for YAML and Select the 'YAML Language Support by Red Hat'

Add the YAML Schema's below to the Visual Studio Code Settings

Settings » Settings: Search for YAML:Schemas.

Click: Edit in settings.json

Configure the following in yaml.schemas

"https://raw.githubusercontent.com/terraform-cisco-modules/easy-aci-complete/main/yaml_schemas/easy_aci.json": [
    "easy-aci-complete/*/*.yaml",
    "easy-aci-complete/*/*/*/*.yaml"
]

Environment Variables

Terraform Cloud/Enterprise - Workspace Variables

At a Minimum for APIC

• Add variable apic_password with the value of [your-apic-password] and sensitive set to true

At a Minimum for NDO

• Add variable ndo_password with the value of [your-ndo-password] and sensitive set to true

Add Other Variables as discussed below based on use cases

Cloud Posse tfenv

Command line utility to transform environment variables for use with Terraform. (e.g. HOSTNAME → TF_VAR_hostname)

Recently I adopted the tfenv runner to standardize environment variables with multiple orchestration tools. tfenv makes it so you don't need to add TF_VAR_ to the variables when you add them to the environment. But it doesn't work for windows would be the caveat.

In the export examples below, for the Linux Example, the 'TF_VAR_' is excluded because Cloud Posse tfenv is used to insert it during the run.

Aliases for .bashrc

Additionally to Save time on typing commands I use the following aliases by editing the .bashrc for my environment.

alias tfa='tfenv terraform apply main.plan'
alias tfap='tfenv terraform apply -parallelism=1 main.plan'
alias tfd='terraform destroy'
alias tff='terraform fmt'
alias tfi='terraform init'
alias tfp='tfenv terraform plan -out=main.plan'
alias tfu='terraform init -upgrade'
alias tfv='terraform validate'

IMPORTANT: ALL EXAMPLES BELOW ASSUME USING tfenv in LINUX

Minimum Sensitive Variables for ACI

Linux

Password Authentication

export apic_password='<your-apic-password>'

Certificate Authentication

export certificate_name='<your-certificate_name>'
export private_key='<your-private_key>'

Windows

$env:TF_VAR_apic_password='<your-apic-password>'

Minimum Sensitive Variables for NDO

Linux

export ndo_password='<your-ndo-password>'

Windows

$env:TF_VAR_ndo_password='<your-ndo-password>'

Sensitive Variables for the Access Module:

• MCP Instance Key: If Desire is to Password Protect MCP traffic.
• VMM Password: vCenter Password for VMM Integration.

Linux

export mcp_instance_key='<mcp_instance_key>'

export vmm_password='<vmm_password>'

Windows

$env:TF_VAR_mcp_instance_key='<mcp_instance_key>'

$env:TF_VAR_vmm_password='<vmm_password>'

Sensitive Variables for the Admin Module:

Configuration Backup Sensitive Variables

• remote_password: For Password based Authentication.
• ssh_key_contents and ssh_key_passphrase: for SSH Key Based Authentication.

Linux

export remote_password='<remote_password>'

export ssh_key_contents='<ssh_key_contents>'
export ssh_key_passphrase='<ssh_key_passphrase>'

Windows

$env:TF_VAR_remote_password='<remote_password>'

$env:TF_VAR_ssh_key_contents='<ssh_key_contents>'
$env:TF_VAR_ssh_key_passphrase='<ssh_key_passphrase>'

RADIUS Sensitive Variables

• radius_key: Key for Protecting RADIUS Server Communication.
• radius_monitoring_password: If Server Monitoring is Enabled, the Password to use with the test user account.

Linux

export radius_key='<radius_key>'

export radius_monitoring_password='<radius_monitoring_password>'

Windows

$env:TF_VAR_radius_key='<radius_key>'

$env:TF_VAR_radius_monitoring_password='<radius_monitoring_password>'

Smart Callhome Sensitive Variables

• smtp_password: Only Required if the SMTP Server Requires Authentication.

Linux

export smtp_password='<smtp_password>'

Windows

$env:TF_VAR_smtp_password='<smtp_password>'

TACACS+ Sensitive Variables

• tacacs_key: Key for Protecting TACACS Server Communication.
• tacacs_monitoring_password: If Server Monitoring is Enabled, the Password to use with the test user account.

Linux

export tacacs_key='<tacacs_key>'
export tacacs_monitoring_password='<tacacs_monitoring_password>'

Windows

$env:TF_VAR_tacacs_key='<tacacs_key>'
$env:TF_VAR_tacacs_monitoring_password='<tacacs_monitoring_password>'

Only Showing Linux Examples for the Rest for brevity

Sensitive Variables for the Fabric Module:

Note: Multiple Instances.

Note that ntp_key, snmp_authorization, snmp_community, snmp_privacy_key have multiple instances. This is only in the event you need multiple values for each variable. If only one value is needed only define one value in the export.

• NTP Authentication Keys

export ntp_key_1='<ntp_key_1>'

export ntp_key_2='<ntp_key_2>'

export ntp_key_3='<ntp_key_3>'

export ntp_key_4='<ntp_key_4>'

export ntp_key_5='<ntp_key_5>'

• SNMP Communities

export snmp_community_1='<snmp_community_1>'

export snmp_community_2='<snmp_community_2>'

export snmp_community_3='<snmp_community_3>'

export snmp_community_4='<snmp_community_4>'

export snmp_community_5='<snmp_community_5>'

• SNMP Authorization Keys and Privacy Keys for SNMP Users

export snmp_authorization_key_1='<snmp_authorization_key_1>'

export snmp_authorization_key_2='<snmp_authorization_key_2>'

export snmp_authorization_key_3='<snmp_authorization_key_3>'

export snmp_authorization_key_4='<snmp_authorization_key_4>'

export snmp_authorization_key_5='<snmp_authorization_key_5>'

export snmp_privacy_key_1='<snmp_privacy_key_1>'

export snmp_privacy_key_2='<snmp_privacy_key_2>'

export snmp_privacy_key_3='<snmp_privacy_key_3>'

export snmp_privacy_key_4='<snmp_privacy_key_4>'

export snmp_privacy_key_5='<snmp_privacy_key_5>'

Sensitive Variables for the System Settings Module:

Global AES Passphrase Encryption Settings

• aes_passphrase: Used to Encrypt Configuration Backups to protect sensitive attributes.

export aes_passphrase='<aes_passphrase>'

Sensitive Variables for the Tenants Module:

NDO Secrets for AWS or Azure Site Authetnication

export aws_secret_key='<aws_secret_key>'

export azure_client_secret='<azure_client_secret>'

Routing Protocol Authentication

• bgp_password: Only requried for BGP Neighbor Authentication
• ospf_key: Only required for Neighbor Authentication

export bgp_password_1='<bgp_password_1>'

export bgp_password_2='<bgp_password_2>'

export bgp_password_3='<bgp_password_3>'

export bgp_password_4='<bgp_password_4>'

export bgp_password_5='<bgp_password_5>'

export ospf_key_1='<ospf_key_1>'

export ospf_key_2='<ospf_key_2>'

export ospf_key_3='<ospf_key_3>'

export ospf_key_4='<ospf_key_4>'

export ospf_key_5='<ospf_key_5>'

• vrf_snmp_community: Only required if the VRF Should use different Communities than the Global SNMP Values. These Communities, that need to be added to the SNMP client_groups, will only be usable by the VRF when configured.

export vrf_snmp_community_1='<vrf_snmp_community_1>'

export vrf_snmp_community_2='<vrf_snmp_community_2>'

export vrf_snmp_community_3='<vrf_snmp_community_3>'

export vrf_snmp_community_4='<vrf_snmp_community_4>'

export vrf_snmp_community_5='<vrf_snmp_community_5>'

Requirements

Providers

Modules

NOTE:

When the Data is merged from the YAML files, it will run through the modules using for_each loop(s). Sensitive Variables cannot be added to a for_each loop, instead use the variables below to add sensitive values for policies.

Inputs

list(object(
    {
      key   = string
      value = string
    }
  ))

[
  {
    "key": "orchestrator",
    "value": "terraform:easy-aci:v2.1.8"
  }
]

list(object(
    {
      name = string
      type = string
    }
  ))

[
  {
    "name": "default",
    "type": "oob"
  }
]

Outputs

Sub Modules

If you want to see documentation on Variables for Submodules use the links below:

access-policies

admin

fabric-policies

switch

system-settings

tenants

Terraform Registry

access-policies

admin

fabric-policies

switch

system-settings

tenants