Site icon

ACI NetCentric 2 AppCentric Using MicroSegmentation

Soumitra Mukherji

In this blog post, I’ll discuss a method of moving from Network Centric ACI Deployment to APP Centric ACI deployment using combination of ACI Features: MicroSegmentation/PrefferedGroups/ContractMasters.

When ACI Fabric is initially deployed, it is either deployed in a Greenfield or Brownfield method. Green Field means it’s a brand new deployment. Brown Field means that the Fabric is stood up and then the existing DC apps are moved to ACI.

Obviously Greenfield is simple. You can design the Fabric with Best Practices from Day 0. You don’t have to worry about interoprability. You could enable all the fancy features of ACI, such as using a large subnet in the BD and putting all the application tiers in different EPGs in that large subnet. Generally in a normal classical network we have learnt to keep subnets limited in size, i.e a /24 or maybe /23. Going to a /22 or smaller is not a good idea because it adversely effects compute CPU, since every compute node on the network will receive that arp traffic and will iterrupt it’s CPU to read it. ACI has the capability of turning off “Flood in BD”, which in essence means that arp is treated as unicast inside the fabric and just delivered to the real endpoint compute that needs to reply to it. Thus ARP traffic is no longer an issue in network segments with large subnets. Additionally there are options for turning on Hardware Proxy for L2 Unknown Unicast and Optimize Flooding for L3 Unknown Multicast Flooding.

If you deployed ACI in a Greenfield you have the luxory of moving endpoints from one EPG to another EPG with minimal disruption. Since all the endpoints (compute )are all in the subnets, this is not an issue. Once you move the application tier to the correct EPGs you can use contracts and go to APP Centric Mode easily.

BrownField is a different animal.  It’s more complex and requires the expertise and field knowlege of an experienced ACI practioneer (if you want minimal dowtime during migration, generally migration is done over a extended period of time vlan or groups of vlan at a time. Moving over Firewalls and Load Balancers gracefully makes it even more complex. 

For one thing, you can’t use the fancy features of ACI BD until everything has been migrated over.   You want to keep everything in Flood mode in the BD.  You also want to bring in each VLAN from the classical side into one EPG/BD. Rule of thumb for migration (to be on safe side) is 1 VLAN == I EPG/BD.  Ofcourse once all your endpoints are moved over to ACI Fabric,  the Fancy features can be turned on, but you are still in 1 BD/EPG mode per migrated Vlan.

Further going to Application Centric mode once migration is finished is not an easy task.  It requires careful planning and execution.  Generally in the classical network, the tiers of each application were not segmented based on Vlan but could reside all over.  As an example a web farm may have some web server members on vlan 10 and others on vlan 20.   Obviously no customer wants to change IP addresses of Production Servers (if they did it app centric migration would be easy, but that’s not even practical, highly disruptive and a fool’s task– works great on power point ofcourse)

Typical BD configuration during the migration would look like this:

What is Network Centric and What is Application Centric ?

In ACI, you can configure your endpoint groups (EPG) in either Network Centric Mode, or Application Centric Mode

Network Centric Mode is where Application Tiers are not clearly allocated to the different EPGs. So, ACI Contracts cannot be applied on the basis of Application Tiers

Application Centric Mode is where Application Tiers are clearly allocated, one tier per EPG. So, ACI Contracts can be applied on the basis of Application Tiers (white list model). Note that each EPG can still have workloads belonging to different IP subnets, but still belonging to the same application tier

Now that we’ve got the Basics covered, let’s talk about moving from Network Centric to Application Centric Mode.

 

Flood In Encap Method:

One rather neat way of achieving this goal is to use the “Flood in Encap Method”

This method can be used during Migration to prepare for App Centric mode later when you understand the application flows.

Instead of bringing in Vlans in 1 Vlan == 1 EPG/BD you put all the EPGs on the ACI Side in the same BD.  You put all your default gateways on the same BD.

Very Important:  If you are using this approach, you need to turn on “Flood in Encap” on the BD side before attempting this or else you will melt down your classical network.

 

Above Diagram shows the “Flood in Encap” setting on the BD
The above diagram is a simple depiction on how to do this sort of migration

Ofcourse there are some Caveats / Limitations to this method which you should be aware of and decide if you want to do this before you actually start on it.  To read more about this “Flood in Encap” feature and the Limitations please read the following:

Flood In Encap Feature on CCO

I’ll highlight the limitations of  “Flood in Encap” below.  (I’m ommitting the last one “pervasive gateway”, because it’s a depricated feature and hardly anyone uses it any more)

 

Now to the topic of this writeup.

Micro Segment Method Example ( a simplistic example)

Requirements:

So, logically they would look like the below.

The Below Setup is done in a lab using multiple vNics of a Pagent Router, each NIC emulating an application tier endpoint.  The reason we are using a Pagent Router instead of real servers is because we also want to do a convergence test and get a feel of how much downtime is expected during this move to APP Centric

Step 1:

Also, please make sure that in the above EPGs, when you do your VMM domain Binding , to attach the servers (VMs), you check the “Allow Micro-Segment” box (otherwise microSement will not work).  This part is often overlooked and people get frustrated.

Side Note:

What is Preffered Group:

Preferred Group is a feature that allows you enable on VRF and then apply to EPGs as needed (preferred Group Include).  All EPGs that are in preferred Group Include (regarless of BD memberships), can talk freely to each other.  This is a very useful feature, because it allows you to move to app centric in a granular fashion.

Prior to this feature being available folks used to turn off enforcement in the VRF level.   The problem with that is that  when you do want to go to APP Centric (say you got all your contracts applied between EPGs).  Now  when you apply the enforcement expecting your EPGs to follow the policy intent (by the contracts), it was a all or nothing approach. Meaning all EPGs in those VRFs would get affected.  That means it’s not a granular approach.  You have to do it all at one time and if you make a mistake in your contract filters you need to go back all the way. 

With Preferred Groups you could do this in a very granular fashion EPG at a time. 

Enabling Preferred Group in the VRF

Putting EPGs in “Preferred Group Include”

Results of putting all the EPGs (web, app, db) in our example:

All endpoints can reach each other…

Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

Results 1:

Results 2:

All Endpoints across EPGs can still communicate with each other even though they have been microsegmented.  That is because the uSeg EPGs also have Preferred Group Include at this point.

Step 6:

Step 7:

Convergence Testing Results:

How Much Traffic Loss is expected ?

In this test we’ve set up 2 running traffic streams (udp)

Stream 1: from WEB to APP

Stream 2: from APPP to DB

We enabled the streams after the initial step of migration was completed in Network Centric Mode (after step 1)

Now we complete Step 2 through 7 and measure for traffic Loss

Below you see that no packet drops are seen through this entire migration from Net Centric to App Centric !!!

Conclusion:

Things to Consider:

Exit mobile version