Cisco ACI: A Practical Deep Dive into demystifying How Application-Centric is different from Network-Centric.

Cisco ACI: Application Centric vs Network Centric

From the first moment you get involved with Cisco ACI in order to design a Datacenter fabric, a big issue shows up in front of you, and that is making a choice between two completely different design methods include: Application-Centric and Network-Centric. Almost everybody asks this question right now that: When should we use application-centric? And when we shouldn't? this is a question all documents try to answer and I'm also going to clarify that based on my experiences and by giving a practical example during the rest of this article. Hence, I've got to say It actually depends on two parameters :

1. How familiar are you and your technical team with Cisco ACI? Going to the Application-Centric method really needs to master the "L4-L7 Service Insertion" section. You are absolutely required to have deep knowledge of ACI service graph, PBR, and especially how to deploy both L3 and L2 Firewalls, IPS, Load Balancer along with having L3Out and L2Out networks. If you think you are not ready for these challenges, then simply forget the Application-Centric approach.
2. If you don't have any information about the services more than just VLAN numbers, then again you should follow the network-centric model. In order to design your ACI fabric based on the App-centric approach, You need to basically have an overview of the structure, architecture, and requirements of your applications. But It's unlikely that you don't have this information already or not able to get it from your developers and sysadmins.

If both of the above are available, Then welcome to the Club!?You no longer have to think Traditional network-driven and do like you used to. Some deployments such as L2 Firewall have fundamentally different stories in Cisco ACI, and also some of the obstacles that led to increased complexity will be got out of your way.

Note: Some references and explanations that cover the differences between these two approaches in ACI, have only focused on how to create and design bridge domain and EPGs in App-Centric compared to Net-Centric while in my opinion, this is incomplete. Network-Centric is all bout just mapping a traditional network infrastructure to ACI Fabric by converting constructs and objects between these two and also by following all the rules and principles that existed in the previous environment. Of course, this mapping also includes the insertion and deployment model of service appliances. So, in terms of designing fabric based on Network-Centric approach, All deployments should be the same as before. In contrast, If we start talking about App-Centric design, we need to cover the new deployment model of firewalls in addition to BD and EPG changes.

Here is a practical example to show the differences between these two methods in Datacenter Fabric design. Let's assume, We have a traditional Network in which two services (SVC1 and SVC2) are running. Both of them have a 3-tier architecture in form of Database, Frontend App, and Backend App.

• We have one core switch appliance that has the default gateway for all servers and services. Thus, we need a Layer 2 firewall to enforce policies on intra-subnet east-west traffics through Vlan Stitching.
• There is also an L3 Firewall to control the north-south, as well as inter-subnet east-west traffics between DC and DMZ zones. Since both of these two zones are placed in the same switch appliance, we also have to create VRF instances to be able to pass traffic towards the L3 Firewall. (Concept known as VRF Sandwich)
• We have a one-arm Load balancer with VIP in the same subnet with servers. But the LB VIP is placed in the same VLAN as Gateway. This deploys the Load balancer in front of the L2 firewall. The logical diagram scheme associated with this network will be as follows.

Traffic flow from Outside (the Internet for instance) to SVC1's frontend App is shown in the following.

First Case: Network-Centric Approach

Let's design the ACI Fabric based on the Network-Centric approach.

As you can see, the pattern of this design is very similar to the traditional network in the example above.

• There are two VRF contexts same as before. It means we still have VRF sandwich to be able to deploy the L3 Firewall, while the default gateway of services is ACI fabric.
• For each VLAN in the given traditional network, we have one Bridge domain (BD) in the ACI Fabric. We also have to enable flooding in all these Bridge domains Otherwise, the Layer 2 firewall will not able to send and receive packets from or to the servers.
• Likewise, For each server VLAN such as VLAN 30 or 35, there are EPGs within ACI fabric with the same name as VLAN ids. Since there are no servers associated with Gateway VLAN in the traditional network, there are no EPGs associated with Bridge domains that have subnets in the ACI Fabric.
• The Layer 2 Firewall needs to be associated with one External Bridged Network for each Server or Gateway VLAN. Depends on how many service VLANs do you have in the traditional network, You have to create the same number of L2Out objects within the ACI fabric. I believe that it may be complicated!
• The Load Balancer may be required to be associated with more than only one VLAN in the VRF DMZ. that's because you might have more than one subnet and SVI in this VRF. In this case, we have to create L2Out objects in the same way we do for the L2 Firewall. The difference is that only Bridge domains have subnet need to be extended towards the load balancer using L2Out. On the other hand, If you definitely have only one Subnet in this VRF, You can imagine the Load Balancer just like a Bare Metal (BM) Server. In this case, It's possible to create an EPG with static deployment, instead of using L2Out.
• The Layer 3 Firewall is connected to ACI Fabric using External Routed Networks (L3Out) and this is how the ACI fabric can either learn the default route or advertise networks to this appliance.

As a summary, we don't have ACI Service graph, nor do we have PBR, no device package is required for ACI prior to 5.2, therefore all L4-L7 service appliances are connected to ACI Fabric using either L3Out or L2Out (Which is called: EGP mode). The deployment model of these service boxes is exactly the same as a traditional network. Finally, we have the same pattern as the traditional networks for creating EPG and BD within the ACI fabric based on network-centric approach. Fast implementation, along with no need for deep knowledge in L4-L7 service insertion, are the most important advantages of this method.

Second Case: Application-Centric Approach

The Application-Centric design for the given example can be a little different depending on the version of the APIC. Let's kick off based on ACI prior to release 5.2

In this approach, we use the ACI Service graph along with PBR, So that we have a completely different model of deployment for Firewalls and the load balancer. More than that, The pattern of creating bridge domains (BDs) and EPGs is exactly in accordance with the layered architecture of our services, not based on VLAN numbers we've already had. As you can see, there are only two service-related bridge domains include 'App' and 'Db' that have subnet and all EPGs are within these two. Another big point about these bridge domains is that we no longer need to enable flooding, therefore the Forwarding option can be set as 'Optimize' during the creation of them.

If you want to separate the endpoints of each service, SVC1, and SVC2 from together, the first option is to put each of them into a dedicated EPG. Then according to the figure above, you may have multiple EPGs that have names exactly the same as application components. Another option is to use Micro-segmentation.

In this design, we have only one VRF named VRF General. That's because we no longer have to use VRF sandwich to deploy the L3 Firewall while the default gateway of services is ACI fabric. In the same way, we also no longer need to use the VLAN stitching pattern to deploy the Layer 2 Firewall while the default gateway of services is ACI fabric. Even as you can see, this firewall is not actually implemented as Layer 2, from the firewall configuration point of view. It's deployed as one-arm L3, But still receives traffic between intra-subnet endpoints (consumer and provider EPGs in the same subnet) and able to enforce the policies. We follow completely different deployment methods in the App-Centric approach. both firewalls and the load balancer are integrated with Cisco ACI and since we define these appliances within Service Graph, there is no need to use L3Out or L2Out unless it requires somehow. But another option that is used along with Service Graph, is Policy-based redirect (PBR). We no longer have to use VLAN stitching and VRF sandwich thanks to PBR, that's because It can change either L2 or L3 destination wherever a contract is enforced. Also using PBR, we don't need to do SNAT on the Load Balancer. ACI Fabric can redirect traffic back to the load balancer if a PBR is configured for that.

If you have more service-related bridge domains other than 'App' and 'Db' in your fabric, It's recommended to create separate bridge domains for each internal and external leg of the L3 firewall.

Important note: The L3 firewall also needs to have an L3Out connection with ACI Fabric for north-south traffics. But there is a limitation here. Prior to ACI 5.2, a PBR policy's destination interface could only be in a bridge domain not in an L3Out. This limitation prevents us to use the same interface on the firewall for both north-south and east-west traffic. In simple terms, we have to separate east-west and north-south firewalls. In this case, you don't have to integrate the L3 north-south only firewall with ACI fabric and can make your design simpler by only having an L3Out connection to the border Leaves. that's exactly what happened and you can see that in the figure above. But this situation has been changed after ACI 5.2 introduced.

Beginning with?Cisco APIC?release 5.2(1), the Layer 4 to Layer 7 services device that is used as a destination of the PBR policy can have the interfaces in an L3Out. This allows us to use the same firewall for both East-West and North-South traffic. Therefore, our design will be in accordance with the figure above.

Conclusion

The Application-Centric approach covers both EPG-BD and deployment of service appliances considerations. this approach is definitely the best choice for large-scale and complex Data Center fabrics. But it needs to be expert on ACI especially the L4-L7 service insertion, and have appropriate and comprehensive information on the architecture of the applications.