Skip to main content

Overview

Structure​

The APIC configuration is divided into six high level sections:

  • fabric_policies: Configurations applied at the fabric level (e.g., fabric BGP route reflectors)
  • access_policies: Configurations applied to external facing (downlink) interfaces (e.g., VLAN pools)
  • pod_policies: Configurations applied at the pod level (e.g., TEP pool addresses)
  • node_policies: Configurations applied at the node level (e.g., OOB node management address)
  • interface_policies: Configurations applied at the interface level (e.g., assigning interface policy groups to physical ports)
  • tenants: Configurations applied at the tenant level (e.g., VRFs and Bridge Domains)

The data model is organized in a way that configurations are grouped around where the actual configuration (policy) is applied. Given the following example:

apic:
  node_policies:
    nodes:
      - id: 101
        pod: 1
        role: leaf
        serial_number: SN-1-101
        name: leaf-101
        oob_address: 10.51.77.94/24
        oob_gateway: 10.51.77.254
        update_group: MG1
        fabric_policy_group: all-leafs
        access_policy_group: all-leafs

All the configurations that are applied at the node level can be found under apic -> node_policies -> nodes. This includes configurations typically found in different places in the ACI object tree, like for example the OOB node management address, which is configured under the mgmt tenant. Consolidating all node level configurations in a single place eases maintenance, as for example we only have to update this single section when adding a new node.

IPv6 Addresses​

Whenever IPv6 addresses are being used, APIC normalizes them according to RFC 5952. Therefore the same format should be used when defining IPv6 addresses in YAML files. Otherwise Terraform for example might detect a configuration drift when comparing the configured IPv6 address with the one defined in the YAML file.

Access Policies​

A number of profiles and selectors can either be auto-generated by providing a naming convention or can be defined explicitly. We typically recommend to auto-generate them as it simplifies the configuration tremendously and leaves less room for error. To auto-generate profiles and selectors the following option needs to be enabled:

apic:
  auto_generate_switch_pod_profiles: true

Once this is enabled we can either rely on the naming conventions defined in defaults.yaml or can configure our own conventions:

apic:
  access_policies:
    leaf_switch_profile_name: "leaf-\\g<id>"
    leaf_interface_profile_name: "leaf-\\g<id>"
    leaf_switch_selector_name: "leaf-\\g<id>"
    leaf_interface_selector_name: "eth-\\g<mod>-\\g<port>"
    leaf_interface_selector_sub_port_name: "eth-\\g<mod>-\\g<port>-\\g<sport>"
    fex_profile_name: "leaf-\\g<id>-fex-    \\g<fex>"
    fex_interface_selector_name: "eth-\\g<mod>-\\g<port>"
    spine_switch_profile_name: "spine-\\g<id>"
    spine_interface_profile_name: "spine-\\g<id>"
    spine_switch_selector_name: "spine-\\g<id>"
    spine_interface_selector_name: "eth-\\g<mod>-\\g<port>"
    vpc_group_name: "vpc-\\g<switch1_id>-\\g<switch2_id>"

We can use the following placeholders to ensure unique object names:

  • \\g<id>: gets replaced by the respective leaf node ID
  • \\g<name>: gets replaced by the respective leaf hostname
  • \\g<fex>: gets replaced by the respective FEX ID
  • \\g<mod>: gets replaced by the respective module number
  • \\g<port>: gets replaced by the respective port number
  • \\g<sport>: gets replaced by the respective sub port number
  • \\g<switch1_id>: gets replaced by the first leaf node ID (vPC pair)
  • \\g<switch2_id>: gets replaced by the second leaf node ID (vPC pair)

After this, there is no need to worry about any of the profiles and selectors as they will be added/deleted automatically according to the node and interface configuration. As we add nodes under apic -> node_policies -> nodes the corresponding profiles will be created automatically. Once we add interface configurations under apic -> interface_policies -> nodes -> interfaces the corresponding interface selectors will be created automatically according to the predefined naming convention.

apic:
  interface_policies:
    nodes:
      - id: 101
        interfaces:
          - port: 1
            description: Linux Server 1
            policy_group: linux-servers

If desired, we can also create profiles and selectors manually:

apic:
  access_policies:
    leaf_interface_profiles:
      - name: leaf-101
        selectors:
          - name: selector-1
            policy_group: linux-servers
            port_blocks:
              - name: block-1
                description: Linux Server 1
                from_port: 1

Fabric Policies​

A similar model like above (for Access Policies) is also applied to Fabric Policies with the following configurable naming conventions:

apic:
  fabric_policies:
    leaf_switch_profile_name: "leaf-\\g<id>"
    leaf_interface_profile_name: "leaf-\\g<id>"
    leaf_switch_selector_name: "leaf-\\g<id>"
    leaf_interface_selector_name: "eth-\\g<mod>-\\g<port>"
    spine_switch_profile_name: "spine-\\g<id>"
    spine_interface_profile_name: "spine-\\g<id>"
    spine_switch_selector_name: "spine-\\g<id>"
    spine_interface_selector_name: "eth-\\g<mod>-\\g<port>"
    pod_profile_name: "pod-\\g<id>"
    pod_profile_pod_selector_name: "pod-\\g<id>"

Additional Resources​

The ACI Data Model describes how to create resources but not what functional purpose they serve within ACI. For more information about ACI please visit ACI Developer Docs or the ACI Fundamentals Guide.