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

 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:

 Image 11

Web EPG:

 Image 12

 

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.

 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:

ACI:

 Image 22

CSR:

 Image 23

 

Perfect we have neighbors but do we have routes:

ACI:

 Image 24

 

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

CSR:

 Image 25

 

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:

 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 10.10.1.0/24 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

There you have it.  A working unmanaged service graph within ACI.  Again, this is a simple implementation of the service graph.  In a real-world scenario, you would have very granular rules within your FW.  These implementations can vary in many ways. You could also include a one-arm load-balancer in this model with an additional bridge domain….so on and so on

@_JBANK

Go to top