Introduction

ACI is highly extensible. Through device packages, we can add several different devices to our environment, which is referred to (in ACI terms) as service insertion.

The packages themselves are small ZIP files. Some require certain permissions from the manufacturer before you can download them (such as Citrix), whereas others just require registering your e-mail address (A10, for example).

Inside the ZIP file, we have a few different files. Taking the A10 APIC package as the example here, we have five Python files, one XML file, and one GIF image in a folder called Images. The ZIP file's size is a mere 65 KB. The XML file is, for most, going to be the easiest to understand. This file is called device_specification.xml. It starts with defining the vendor (vnsMDev) along with a package name (which is one of the Python scripts) and the version details (vmsDevScript):

<vnsDevScript name="A10" packageName="device_script.py" ctrlrVersion="1.1" minorversion="1.0” versionExpr="4.[0-9]+.[-A-Za-z0-9]*"/>

Next, we define the device profiles (vnsDevProf), whether they are virtual or physical devices, and the number of Ethernet interfaces that they have (note that I have truncated the output):

<vnsDevProf name="vThunder" type="VIRTUAL" context="single-Context" pcPrefix="trunk ">
   <vnsDevInt name="ethernet 1" />
   <vnsDevInt name="ethernet 2" />
   <!—truncated ->
   <vnsDevInt name="ethernet 7" />
   <vnsDevInt name="ethernet 8" />
</vnsDevProf>
<vnsDevProf name="vThunder-ADP" type="VIRTUAL" context="multi-Context" pcPrefix="trunk ">
   <vnsDevInt name="ethernet 1" />
   <vnsDevInt name="ethernet 2" />
   <!—truncated ->
   <vnsDevInt name="ethernet 7" />
   <vnsDevInt name="ethernet 8" />
</vnsDevProf>
<vnsDevProf name="Thunder" type="PHYSICAL" context="single-Context" pcPrefix="trunk ">
   <vnsDevInt name="ethernet 1" />
   <vnsDevInt name="ethernet 2" />
   <!—truncated ->
   <vnsDevInt name="ethernet 19" />
   <vnsDevInt name="ethernet 20" />
</vnsDevProf>
<vnsDevProf name="Thunder-ADP" type="PHYSICAL" context="multi-Context" pcPrefix="trunk ">
   <vnsDevInt name="ethernet 1" />
   <vnsDevInt name="ethernet 2" />
   <!—truncated ->
   <vnsDevInt name="ethernet 19" />
   <vnsDevInt name="ethernet 20" />
</vnsDevProf>

After the interface declarations, we define some interface labels for “external” and “internal” (vnsMIfLbl) and some credentials (vnsMCred and vnsMCredSecret). The first big section we get to is next, which is the cluster configuration (vnsClusterConfig). This section covers core functionality, such as time, DNS, hostname, interface numbering, IPv4 and IPv6 functionality, and NTP. We then move to vnsMDevCfg, which is for network interface settings, including Virtual Router Redundancy Protocol (VRRP).

The vnsMFunc tag takes up the bulk of the XML file. These are device-specific entries, so the contents of this tag will vary considerably among the different vendors. However, they must all follow the same schema.

The final tags are vnsComposite (comparisons between two values, such as on or off, tcp or udp, and Yes or No) and vnsComparisons (match a-z and A-Z, or match 0-9, or "is it an IP address or subnet mask?").

<vnsComposite name="TrueFalse" comp="or">
   <vnsComparison name="True" cmp="eq" value="true"/>
   <vnsComparison name="False" cmp="eq" value="false"/>
</vnsComposite>
<vnsComposite name="EnableDisable" comp="or">
   <vnsComparison name="enable" cmp="match" value="enable"/>
   <vnsComparison name="disable" cmp="match" value="disable"/>
</vnsComposite>
<vnsComposite name="onOff" comp="or">
   <vnsComparison name="on" cmp="match" value="on"/>
   <vnsComparison name="off" cmp="match" value="off"/>
</vnsComposite>
<!-- Basic comparison Objects -->
<vnsComparison name="isAlpha" cmp="match" value="[a-zA-Z]+"/>
<vnsComparison name="isNumber" cmp="match" value="[0-9]+"/>
<vnsComparison name="isIPAddress"
               cmp="match"
               value="([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5])"/>
<vnsComparison name="isIPMask"
              cmp="match"
                 value="([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5])"/>

We also have tags that set the fault codes (vnsMDfcts) and function profiles (vnsAbsFuncProfContr). The function profiles are, again, device specific and, for the A10, specify whether the device is a web server or a web server with high availability.

While we, as engineers, do not need to be concerned with what the contents of these XML files are, they do serve as a good reminder of the declarative nature of ACI. The XML files are all based on a common schema, and if the vendor can fit what they need around this schema, then the appliance should run very happily within the ACI framework.

Let’s find out how to add a device package.