1. L4-L7 Unmanaged Go-Through Mode

L4-7 Unmanaged Go-Through Mode (Transparent FW)

I have been playing around with service graphs quite a bit and wanted to share my findings with deployment.  This lab deployment of service graphs using the ACI fabric (2.2(1n), an ASAv and CSR router.  Enjoy….

2018 04 12 17 36 47

Feature External BD Web BD
Hardware Proxy No No
ARP Flooding Yes Yes
Unicast Routing Yes No
Subnet Yes No
Subnet Check Yes No


This design is an unmanaged transparent mode deployment with routing provided by the ACI Fabric.  We will be using two bridge domains and the default gateway for the servers is the IP address of the subnet in the external bridge domain.  The table above shows the settings that each bridge domain needs for the configuration to work properly.


After our VRF, Bridge Domain and EPG’s are created we want to go ahead and create a L4-7 service.

Image 1


Now that we have our Cisco-ASA-1.2 Package installed we want to “Create an L4-L7 Device” within our tenant:

Image 2



Uncheck the “Managed” tick box and fill in the parameters below:

Image 3


Note: Device interfaces are the network adapters in vCenter and the Cluster interfaces are the concrete interfaces of the ASAv.

We are now required to build a service graph template:

Image 4


We want to drag the L4-L7 device we just created between our two EPG’s and name everything accordingly:

Image 5 1


After completion of the service graph template we need to apply this template for it to take effect (we can also reuse this template in the future if necessary):

Image 5


Applying this service graph requires us to select our EPG’s we are associating this with as well as creating a bogus contract that we can allow all traffic through:

Image 6


Now we just need to finish this off by stating what cluster/concrete interfaces we will be using:

Image 7


We can verify the contracts were created and applied correctly:

Image 8


Image 9


This is just external EPG but trust me Web was also applied correctly as well.

We can also verify in vCenter that the port-groups were automatically created and assigned to the correct interfaces:

Image 10


Now that the service graph looks good we still have a FW to configure since we decided to deploy this in unmanaged mode.  In my opinion, the benefit is still having access to our device and configuring it how we always have.  I will share this basic FW config and parse text so I don’t bore you to bad but notice the transparent parameters, bvi etc.:


ASA Version 9.4(4)


firewall transparent

hostname Jason-ASAv-Transparent!


interface GigabitEthernet0/0

nameif web

bridge-group 1

security-level 100


interface GigabitEthernet0/1

nameif external


bridge-group 1

security-level 0


interface Management0/0


nameif management

security-level 0

ip address x.x.x.x/24


interface BVI1

ip address

same-security-traffic permit inter-interface

access-list web-in extended permit ip any any

access-list external-in extended permit ip any any

logging enable

logging buffer-size 524288

logging console emergencies

logging monitor debugging

logging buffered debugging

logging trap notifications

logging asdm informational

mtu web 1500

mtu external 1500

mtu management 1500

no failover

no monitor-interface service-module

icmp unreachable rate-limit 1 burst-size 1

icmp permit any web

icmp permit any external

access-group web-in in interface web

access-group external-in in interface external

ssh management

ssh timeout 5

ssh version 2

Now that the FW is configured let’s try and test the communication from a VM that lives behind the FW to our gateway that lives in the External-BD:


Image 11

Web EPG:

Image 12


BD External:


Also notice the settings on the right side of the BD.  It is crucial you are flooding for communication to take place.  Settings are listed in table at top of post.

Image 13


Communication test:

Image 14


Perfect!!  We can reach the External BD Gateway through the FW.  Let’s also check the FW and see if we are seeing the same thing:

Show log:

Image 15

Awesome….the FW is verifying the same communication.


Now if you remember our design had an L3Out attached to the fabric so we can reach external hosts.  Time to build the L3Out (need to have a prior understanding of building L3Outs).

For this L3Out I will be using a CSR router and not using VMM Domain just simple connectivity to the fabric passing vlans.  Back to our tenant and right-click on external routed networks:

Image 16


Assuming you have experience with L3Outs configure the initial parameters.  We will be using OSPF in Area 0 for this example:

Image 17


Create our Node Profile, OSPF Int Profile and Network EPG:

Image 18


Image 19

Image 20


Now that’s completed we need a simple config on our CSR:

Image 21


Time to check for neighbors:


Image 22


Image 23


Perfect we have neighbors but do we have routes:


Image 24


Looks good.  We see the loopback from the CSR in our routing table.


Image 25


Okay, we are only getting loopbacks from ACI but shouldn’t we be receiving the that lives in our External-BD? These issues usually live inside the bridge domain settings.  Time to investigate:

Image 26

Our subnet is still set to private so we need to advertise externally and select the correct L3Out:

Image 27


L3Out within BD:

Image 27 2


With these changes verify the routes on the CSR:

Image 28


Perfect, we can now see the subnet on the external router.  Now can our host ping the loopback of the router:

Image 29


So, we still can’t hit the loopback of the router.  If we look at our design again you will notice we still need a contract between the L3Out and the EPG, just like any other EPG to EPG communication.

2018 04 12 17 36 47


If you remember when we created and applied the service-graph template contracts were created and applied on the Web EPG:

Image 30


We must use this same contract on the L3Out Network EPG.  If we apply correctly we should see communication take place:

Image 31


We can verify:

Web Host:

Image 32


Just what we want to see…. Now we can test CSR:

Image 33