ASAv Service Graph – Cloud Orchestrator Package


Introduced in ACI 3.1, the Cloud Orchestrator Package greatly simplifies the configuration of Service Graphs. Intended for use with an Orchestrator such as Microsoft Azure for a generic configuration of any L4-L7 device.


  • ACI 3.1
  • Supported Device Package
  • Supported L4-L7 Device
  • BD Configuration to match the Service Insertion configuration
    • Since this is routed mode FW both Consumer and Provider BD need to be L2 (all flood)
  • VMM integration

Components Used

  • ASAv 9.6.4
  • ASA Device Package 1.3(10)



Basic ASAv config

no firewall transparent
int m0/0
ip add x.x.x.x s.s.s.s
nameif management
no shut
route management
http server enable
http management
user apic password PW priv 15
copy run start

The configuration above adds an IP address to the management interface of the ASAv, this is typically the virtual machine “network adapter 1”, this should be in the port-group for management access. A username is also created with privilege level 15 for the connection from the APIC to the ASAv

Network Diagram

Screen Shot 2018-04-09 at 10.41.12 PM.png
Network Diagram

ACI Configurations

High level configuration has not changed

  1. Create L4-L7 device
  2. Create L4-L7 service graph template
  3. Apply L4-L7 service graph template

In 3.0 and above, the GUI has changed. TO create L4-L7 device, navigate to Tenant > Services > L4-L7 > Device


Screen Shot 2018-04-09 at 10.41.35 PM.png
Create L4-L7 Devices


Fill in the information required in the new wizard. For this article we are using an ASAv in GoTo (Routed) mode. Select HTTPS as the management port.

Screen Shot 2018-04-09 at 10.34.05 PM.png
ASA in GoTo (Routed Mode)

Device Interfaces is used to create a relationship to the logical ASAv gigabit interfaces to a vmWare virtual machine network interface. The cluster interfaces is a bit misleading if using a single node but is a required field. This section makes an ACI mapping from logical ASAv interface to ACI provider/consumer model.

Click “Next” and “Submit”

NOTE – During testing, I had two faults that were raised. F1565 (config failed, device validate operation failed) and F0324 (config failed, major script error port 80 max retries connection timed out). The resolution was to use 443/HTTPS.

Next step is to create the Service Graph template.

Screen Shot 2018-04-09 at 10.42.02 PM.png
Service Graph Template Creation

The most important things to check here are that you actually have a svcType: FW, the firewall type of config (Routed in this case) and the Function Profile. Ensure that it says “Cloud” at the end.

Screen Shot 2018-04-09 at 10.36.00 PM.png
Device Package



Finally, its time for the longest step (has three sections!) applying the service graph!

Right-Click on the newly created template and select “Apply L4-L7 Service Graph Template”

Screen Shot 2018-04-09 at 10.36.36 PM.png

First step in this wizard it so select the Consumer/External EPG and the Provider/Internal EPG then configure an ACI contract if needed. More on this later

In the filters for this example, i have used HTTP port 80 as well as ICMP to be allowed.

Screen Shot 2018-04-09 at 10.37.17 PM.png
Service Graph

Click “Next” to continue

In the “Graph” step, ensure the BDs are correct and click “Next”

This final step gets a little trick but is the wonderful new configuration of the Cloud Package

Screen Shot 2018-04-09 at 10.37.43 PM.png
Cloud Package


There are only three sections to configure! No more Folders, sub-folders, nor device specific configuration. With the cloud package, the same wizard can be used for all types of Firewalls taking only the minimum required parameters in a generic format.

Input the gateway for the Consumer/External EPG and the Provider/Internal EPG

Under ACL, click the + symbol to open a new wizard

Screen Shot 2018-04-09 at 10.38.12 PM
ACL Entry


Fill in the information as needed. Source in this case is the consumer/external side whereas Destination is provider/internal side.

Screen Shot 2018-04-09 at 10.38.34 PM.png
ACL Entry


Click “Submit” and then “Finish”

NOTE: I had a lot of trouble with this section. Everytime I hit finish at the template, I had a 400 ERROR INPUT FIELD LONGER THAN EXPECTED. After a lot of trial and error, my mistake was using a default filter or the “no filter” option earlier on. This was preventing me from creating any ACL under the template as it was not expecting an ACL.

The resolution here was to match the filters to the ACL. As seen in the article, there are two filter entries; one for HTTP and one for ICMP. The ACL in the template also has two entries 10 and 20. one for HTTP and one for ICMP.


That’s it! Lets verify!


First and foremost, lets make sure the ASAv interfaces have the correct IP addresses on them.

Screen Shot 2018-04-09 at 10.38.55 PM

Now lets take a look at what ACLs were programmed

Screen Shot 2018-04-09 at 10.39.25 PM.png

Now our actual dataplane

Screen Shot 2018-04-09 at 10.39.50 PM


Here we see HTTP is working as well as a ping from external device to internal device


Screen Shot 2018-04-09 at 10.40.17 PM.png


Device Package logs can be found on the APIC under


specifically, the debug.log shows the config that was sent. For this techzone, we can see the following logs:

2018-03-13 08:40:08.766725 INFO Thread-19 1495 [, 85120] POST
<?xml version="1.0" encoding="ISO-8859-1"?>
<config-data config-action="merge" errors="continue">
<cli id="0">interface GigabitEthernet0/0</cli>
<cli id="1">no shutdown</cli>
<cli id="2">interface GigabitEthernet0/1</cli>
<cli id="3">no shutdown</cli>
<cli id="4">object network NetworkObject_192.168.4.0_24</cli>
<cli id="5">subnet</cli>
<cli id="6">object network NetworkObject_10.10.4.0_24</cli>
<cli id="7">subnet</cli>
<cli id="8">access-list AccessList_test6 extended permit tcp object NetworkObject_192.168.4.0_24 object NetworkObject_10.10.4.0_24 eq www</cli>
<cli id="9">access-list AccessList_test6 extended permit icmp object NetworkObject_192.168.4.0_24 object NetworkObject_10.10.4.0_24</cli>
<cli id="10">interface GigabitEthernet0/1</cli>
<cli id="11">nameif Interface_192.168.4.254_24</cli>
<cli id="12">ip address</cli>
<cli id="13">security-level 50</cli>
<cli id="14">access-group AccessList_test6 in interface Interface_192.168.4.254_24</cli>
<cli id="15">interface GigabitEthernet0/0</cli>
<cli id="16">nameif Interface_10.10.4.254_24</cli>
<cli id="17">ip address</cli>
<cli id="18">security-level 100</cli>


The entire POST from the GUI can also be seen higher up in the debug.log.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.