- 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….
| 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.
Now that we have our Cisco-ASA-1.2 Package installed we want to “Create an L4-L7 Device” within our tenant:
Uncheck the “Managed” tick box and fill in the parameters below:
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:
We want to drag the L4-L7 device we just created between our two EPG’s and name everything accordingly:
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):
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:
Now we just need to finish this off by stating what cluster/concrete interfaces we will be using:
We can verify the contracts were created and applied correctly:
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:
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
management-only
nameif management
security-level 0
ip address x.x.x.x/24
!
interface BVI1
ip address 10.10.1.2 255.255.255.0
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 0.0.0.0 0.0.0.0 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:
Host:
Web EPG:
BD External:
Subnet 10.10.1.1/24
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.
Communication test:
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:
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:
Assuming you have experience with L3Outs configure the initial parameters. We will be using OSPF in Area 0 for this example:
Create our Node Profile, OSPF Int Profile and Network EPG:
Now that’s completed we need a simple config on our CSR:
Time to check for neighbors:
ACI:
CSR:
Perfect we have neighbors but do we have routes:
ACI:
Looks good. We see the loopback from the CSR in our routing table.
CSR:
Okay, we are only getting loopbacks from ACI but shouldn’t we be receiving the 10.10.1.0/24 that lives in our External-BD? These issues usually live inside the bridge domain settings. Time to investigate:
Our subnet is still set to private so we need to advertise externally and select the correct L3Out:
L3Out within BD:
With these changes verify the routes on the CSR:
Perfect, we can now see the 10.10.1.0/24 subnet on the external router. Now can our host ping the loopback of the router:
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.
If you remember when we created and applied the service-graph template contracts were created and applied on the Web EPG:
We must use this same contract on the L3Out Network EPG. If we apply correctly we should see communication take place:
We can verify:
Web Host:
Just what we want to see…. Now we can test CSR:
