Introduction
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.
Prerequisites
- 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)
Configure
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 0.0.0.0 0.0.0.0 gw.gw.gw.gw
http server enable
http 0.0.0.0 0.0.0.0 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
ACI Configurations
High level configuration has not changed
- Create L4-L7 device
- Create L4-L7 service graph template
- 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
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.
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”
Next step is to create the Service Graph template.
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.
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”
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.
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
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
Fill in the information as needed. Source in this case is the consumer/external side whereas Destination is provider/internal side.
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!
Verify
First and foremost, lets make sure the ASAv interfaces have the correct IP addresses on them.
Now lets take a look at what ACLs were programmed
Now our actual dataplane
Here we see HTTP is working as well as a ping from external device 192.168.4.100 to internal device 10.10.4.250
Troubleshoot
Device Package logs can be found on the APIC under
/data/devicescript/CISCO.ASA.1.3/logs
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 [10.29.198.250, 85120] POST https://10.29.198.250:443/admin/config
Request:
<?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 192.168.4.0 255.255.255.0</cli>
<cli id="6">object network NetworkObject_10.10.4.0_24</cli>
<cli id="7">subnet 10.10.4.0 255.255.255.0</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 192.168.4.254 255.255.255.0</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 10.10.4.254 255.255.255.0</cli>
<cli id="18">security-level 100</cli>
</config-data>
The entire POST from the GUI can also be seen higher up in the debug.log.