Let's say you start a new network with ACI (design question)

[Vinny]

How would you design your network subnets in a zero-trust model approach ?

If you use an "application centric" architecture, subnetting and address aren't so important since you group servers by applications instead of vlans/subnets.

What would be your design? One big flat network for you whole DC ?

What would be the advantages of using several subnets since you can use EPG and contracts to seperate your applications/groups of server ?

I suppose broadcast can't go outside of an EPG so even a big flat network won't flood all your EPGs ?

thanks

[RedNectar · Accepted solution]

Hi Vinny,

The problem with a zero-trust model in today's networks is that it is very hard to force trust between servers on the same subnet.  ACI overcomes this to a large degree by designing trust around EPGs and if required, micro-segmentation within EPGs.

However, I need to make a couple of things clear.

1. ACI was never designed as a complete security tool in the sense of what you might expect from a stateful firewall or a deep content inspection device.  For instance, it has no application awareness of applications like VoIP or FTP that open random port numbers for continued communications, nor does it keep track of TCP sequence/acknowledgement numbers or detect other packet spoofing techniques.
2. Your assumption that "broadcast can't go outside of an EPG" is not true by default. Just like in a traditional network, broadcasts are flooded throughout the broadcast domain, in the case of ACI, this is the Bridge Domain. There is however two options that will change this behaviour:
   1. One option is to restrict ARP flooding, which is on by default.  In this case, ACI treats the ARP broadcast packet like an IP packet, and the ingress switch passes the ARP broadcast to the egress switch only rather than flooding throughout the Bridge Domain.
   2. The other option is that you can control Multi Destination Flooding (i.e. broadcasts and multicasts) so that they are dropped or flooded in their original encapsulation rather than flooded (the default).  Choosing the Flood in Encapsulation option would be closest to the action you describe - i.e. flooding in the EPG.

So, to answer the question:

 What would be your design? One big flat network for you whole DC ?

I'm going to have to take the cop-out answer of "It depends." But I'll give you a couple of examples.

The Warm and Fuzzy Approach

If you like dividing servers into subnets and even having every subnet in its own Broadcast/Bridge domain, then go ahead.  There is NOTHING WRONG with that approach, and it maps nicely with existing concepts, so you might find it more comfortable. You'll sometimes see this approach called a "Network Centric" design.

The Automated Infrastructure Approach

If you are planning on using any automation tools to run up servers, assign IP addresses and add them to the infrastructure, you will probably find it easier to allow the servers to be allocated the next IP address available from a pool. Your automation programming then doesn't have to use a different pool for every new server.  So, in this case, having all servers in one big subnet is probably the easier approach.  You'll sometimes see this approach referred to as "Application Centric".

Caveat

If you have servers in multiple VRFs/Tenants that need to communicate with each other, you will need to allocate subnets to EPGs to allow for route leaking. This may cause some headaches if you have different servers in different EPGs using the same subnet.

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.

---

[Vinny]

that's what I call a complete answer.

Thank you very much ! Now it's clear.

[RedNectar]

Glad it helped :)