Difference between ACI network centric mode and application centric mode

[rachmatadhie]

hai guys,

I have deploy ACI infrastructure on my customer, currently using network centric mode. Later, it will be converted to application centric mode. but i still confuse about the difference between network centric mode and application centric mode. Is there any significant difference between network centric mode and application centric mode??

regards,

adhie

[RedNectar]

Hi Adhie,

Did you read this answer yet?

https://supportforums.cisco.com/t5/application-centric/bridge-domain-approach/m-p/3341662/highlight/true#M4318

or this one

https://supportforums.cisco.com/t5/application-centric/let-s-say-you-start-a-new-network-with-aci-design-question/m-p/3361486/highlight/true#M4534

Let us know if they don't help

I hope this helps

---

Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

---

[jryski1620]

I often hear this question about "mode". It's a misnomer.

The easiest way to explain it is this.

In network centric design, you have a 3 tiered application. Web (vlan 10), App(vlan 20), and DB(vlan 30),

You create 3 Application profiles, one for each tier.

You create3 Bridge domains

bd-vlan10

bd-vlan20

bd-vlan30

And 3 EPG's

EPG-vlan10

EPG-vlan20

EPG-vlan30

In application centric design

You create an Application Profile (AP-application1) with 3 EPG's

epg-Web_AP1

epg-APP_AP1

epg-DB_AP1

And 1 Bridge domain.

BD_app1

There is no mode to switch, it's a design consideration.

[mvknl]

I would argue that it goes even further. It's a way of thinking about your network. The Network centric mode is thinking about your network as you've always done. You have your vlans, subnets, vrfs etc.

Application centric is another way of thinking. Instead of having the network lead the application leads. This results into a network 'bubble' (for lack of another word) round the application in which policy is defined around the application. The network follows the application.

You can already see this way of thinking within ACI, you have to define a Application Network Profile before you can define an EPG. All policy related to the application is contained in this ANP. This includes all EPGs, contracts etc.

[msmith508]

I love the reply and find ACI to be needlessly convoluted and frustrating, but I want to add to this that in the dcloud aci 6.0 getting started lab, they went with 1 app profile, 3 EPGs & 3 BDs (1, 3, 3), instead of 3, 3, 3 or 1, 3, 1.

They used 3 BDs and 3 EPGs, so it's network-centric, yet they went with just a single app profile, which is more for application-centric design. Sort of confusing for the intended audience in my view:

application network-segments (app profile)
description ''
epg 192.168.20.0_24 (epg)
bridge-domain member 192.168.20.0_24 (bridge domain)
description ''
set qos-class level3
vmware-domain member ACI-dvSwitch encap auto primary-encap auto deploy on-demand push immediate allow-micro-segmentation
switching-mode native
encap-mode auto
no flow monitor enable
flow direction both
exit
no isolation enforce
no vrf-blacklist-mode
no flood-in-encapsulation
shutdown
exit
epg 192.168.21.0_24 (epg)
bridge-domain member 192.168.21.0_24 (bridge domain)
description ''
set qos-class level3
vmware-domain member ACI-dvSwitch encap auto primary-encap auto deploy on-demand push immediate allow-micro-segmentation
switching-mode native
encap-mode auto
no flow monitor enable
flow direction both
exit
no isolation enforce
no vrf-blacklist-mode
no flood-in-encapsulation
shutdown
exit
epg 192.168.22.0_24 (epg)
bridge-domain member 192.168.22.0_24 (bridge domain)
description ''
set qos-class level3
vmware-domain member ACI-dvSwitch encap auto primary-encap auto deploy on-demand push immediate allow-micro-segmentation
switching-mode native
encap-mode auto
no flow monitor enable
flow direction both
exit
no isolation enforce
no vrf-blacklist-mode
no flood-in-encapsulation
shutdown
exit
set qos-class unspecified
exit

I tried to also include the other endpoint security group configs here, but the portion which links the ESG with the EPGs just doesn't appear in a show run all on an apic in the simulator.

I'll try exporting the xml/json to see if it appears in there.

[jbekk]

Everything everyone is replying to you with is correct. The difference is just the mindset of "which way are we architecting/designing the object model to achieve the actual requirements". The actual object model used for both is the same... it just gets more/less complicated depending upon which way you are pushing it.

In network mode, you are basically saying "my life revolves around deploying and securing VLANs... just like the good old days! I have a trusted VLAN and a untrusted VLAN that I need to plumb things into... and maybe secure using an old firewall". In application mode you are basically saying "I don't care about the actual network underneath. App dev cycle is where its at! I have a couple of front end servers and a database that I need to deploy and secure using ACI". Both need broadcast domains to work at the OS level... it's just in app-centric mode you can basically fudge it all to have front end and backend boxes all live within one giant subnet at their OS level (i.e. trusted and untrusted devices) but in different EPGs within ACI (note: you don't have to do this in app-centric mode). Regardless of the fact that OS's are in the same subnet you still have complete confidence you can control all access between them (kind of like private VLANs in old networks) and could even redirect access between some boxes to go through some extra filters (i.e. service chaining). In network-centric mode you are stuck applying security at the subnet level only... or you are stuck securing it using an external firewall device of some sort that isn't integrated with ACI. 

My basic rule of thumb has become:

- Network Centric = subnet level EPGs (i.e. per VLAN)

- Application Centric = EPGs at whatever granularity you like (per MAC, per VM-port-group, per subnet, per port, per VLAN... or a mixture of these)

Remember that an "EPG" is basically your granularity of control at applying policy within ACI. i.e. ACI security = EPG-to-EPG access rules.

This is all a bit of a generalization but I hope it helps...

Disclaimer: I am still pretty green.... so take this with a grain of salt.

[msmith508]

I would boil it down to this:
Network-centric design simply means having 1 bridge-domain per subnet and strives for 1 EPG per BD, so having many small BDs each mapped to a small subnet. So many BDs.
Application-centric design strives for 1 large supernet mapped to 1 BD. So just 1 BD or comparatively very few BDs.

As far as application profiles and endpoint groups:
With a network-centric design, you're probably best off going with 1 app profile per BD, since an EPG lives under an app profile and can be mapped to only 1 BD, if you already have an EPG1 mapped to a BD1 under an app profile, you can't then create another EPG1 in order to map it to a another, different BD2 (and subnet) under that same app profile. But you can do this across separate app profiles, say app profile 1, EPG1 to BD1 and app profile 2, EPG1, to BD2, though they are not the same EPG, they at least have the same names, though this is probably a non-issue in network-centric design, since for clarity in reading the configs, you'll probably want to put the subnets into the EPG names anyway, but it's good to know that you can duplicate EPG names across app profiles for mixed-use subnets if you really want or need to. This would technically be application-centric design but I view it as more of a hybrid in between pure 1BD to 1Subnet to 1EPG network-centric design and the full application-centric design. Or you could add a new vlan subnet to an existing BD, in order to add those new endpoints to the existing EGP. Or you could still add the new subnet under a new BD and new EPG, but group the EPGs under an endpoint security group, which will allow those EPGs to communicate to each other without any contracts, and migrate and apply EPG contracts to the ESG level to allow communication between that EPG group and other EPGs. Again, technically application-centric but to me the lines are blurry.

Some downsides to running network-centric design include smaller subnets that will run out of available IP space, thus needing to create new BDs and new app profiles and vlan pools for those BDs. and if you're using contracts, you'll want to duplicate any existing contracts from the similar older app profile EPGs into the new app profile EPG. You'll also probably run into some firewall problems as they'll probably already block access to the new BD's subnet for whatever access the older BDs have access to. And also sometimes you'll run into weird application dependencies such as the new servers can't cross layer 3 to talk to the older servers, purely out of application limitations, regardless of the network switch configuration.

With an application-centric design, every EPG is in a single BD supernet, so there's no need to worry about which subnet an EPG will map to. You don't need to create new or duplicate EPGs all the time across new and BDs and subnets. You don't need to create lots of app profiles, one per BD. App profiles can be created per application, not per BD. So fewer subnets, BDs, EPGs and app profiles to deal with. Automation is also streamlined since spinning up new enpoints is simplified with not needing to figure out which subnet and BD to use.

Some downsides to application-centric's 1 giant BD subnet are it's alot of work to almost impossible to migrate in legacy subnetted things over from a legacy datacenter, especially things that are being funneled through firewalls to filter traffic or serve as a security choke-point, since that would mean changing all the object IP addressing in the firewall configs to match the new ACI supernet that the hosts will migrate over to, not to mention all the other unknown configs and dependencies in all other deployed commercial applications, custom in-house applications, web filters, IPS, remote management tools, AAA server configs, etc. This is probably why most who plan to migrate old things into ACI deploy ACI in network-centric design vs. application-centric.