cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
220
Views
5
Helpful
2
Replies
Highlighted
Beginner

Move to Application Centric from Network Centric

Hello all, 

 

for a customer project we need to plan the move from a network centric approach to application centric. The following are the facts: 
- Customer has currently 4 tenants and want to merge them to two tenants

- The migration to application centric should be step by step (application by application) 

- Each new tenant got it's own new L3Out to the given firewall 

 

Our approach is: 

  1. Analyse the application for building later the contracts
  2. Create the new tenants with one VRF per tenant enforced 
  3. Move the first application two one of the new tenants (depends on the application) 
  4. the new app got different EPGs (depends on the app tier design
  5. The EPGs are connected first through contracts w/o filter -> allow any! 

With this approach there are different discussions: 

  1. Assume the Application/Systems should keep the IP addresses, what about the reachability between the new and old tenants? Is there a solution where we can extend the L2 domain from old tenants to the new tenants? 
  2. If we can change the IP Design then it these traffic will be routed to the the L3Out and it's fine

Example: 
In the old tenant there is a mapping BD=EPG=VLAN ID. Let's say we need to move for one application different systems from different EPGs to the new tenant and Application Profile. These systems need L2 reachability to the existing systems in the old network centric Tenant. 

 

I hope that I have explained it reasonably well and there are some tips from you! 

 

Thanks 

Udo 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: Move to Application Centric from Network Centric

Hi Udo.  Here is my personal opinion on the matter.

I always cringe a little bit when talking NetCentric vs AppCentric because we (Cisco) did not do a very good job articulating what it means from the very beginning.  This is to say we made it sound a whole lot more complicated than I think it really is. 

In my mind, Net vs App are really just two ways to describe how you prefer to group and organize your EPGs.  That's it.  They are both valid approaches, and in fact, you can use both in tandem across your tenants.

The analogy I use is to imagine a filing cabinet with three drawers.  In each drawer you might choose to organize things alphabetically or numerically.  Each drawer can use a different system. The result is the same in that you have organized things in a way you both prefer and understand.  What we failed to explain well is that by giving them names like "network centric" we were only trying to give a hint that one way of organization tries to mimic your legacy understanding of vlans and subnets, versus organizing by app tiers that need to talk to each other. 

So, what most people thing of as "net-centric" is one BD maps to one VLAN in one EPG.  App centric is only different in that you can have many encaps (note my change in terms, but I mostly mean VLANs) mapping to a BD via multiple EPGs.  That sounded kinda confusing.  Put another way, in App-centric, you would naturally have more than one EPG mapping to the same BD. The EPG is what matters most because that is where you apply policy for endpoints.

So getting to your design.  I will caveat that I don't have all the details of your setup, but I will try to give you my opinion. 

First question:  Do you absolutely require that each tenant has its own VRF? 

Let me qualify that.  ACI has no issue with lots of VRFs and we can do route leaking all day long.  However, I often find people think of VRFs as a tool to segment things.  It is a large hammer of a tool in that case, when other tools may be more suitable.  IMO, multiple VRFs are usually most useful when you have overlapping subnets you need to address.  Using VRFs for quick and dirty segmentation is not that way to go, IMO.  I say that because it means you will now always have to configure and track route leaking and be sure you know what you have leaking at any given time. It is operational overhead that you might not actually want.  I usually challenge customers to justify why they think they need many VRFs.  In 90% of the cases, they realize they don't. 

If you can put all your tenants in one VRF, that is going to make your migration that much easier.  It would mean you would only have to create new EPGs under existing BDs that organize and apply policy to your app tiers.  Migration could be as easy as moving the EPs to the new EPG when you are ready, and still allow communication to "legacy EPGs" via contracts where you wanted.  No need to change IP addresses/gateways on the hosts.  You would not have to worry about hair-pinning in and out to reach the legacy stuff outside.  You would not have to worry about route leaking or overlapping subnets.  Less is more, IMO. 

This is just one man's opinion and I don't speak for Cisco, but you might re-think your approach to see if you can simplify things much like the examples I gave above.  I also understand that I have oversimplified things to try and highlight general concepts.  Your environment will undoubtedly have complexities I am unaware of that you will need to think around.  Hope that helps. 

View solution in original post

2 REPLIES 2
Highlighted
Cisco Employee

Re: Move to Application Centric from Network Centric

Hi Udo.  Here is my personal opinion on the matter.

I always cringe a little bit when talking NetCentric vs AppCentric because we (Cisco) did not do a very good job articulating what it means from the very beginning.  This is to say we made it sound a whole lot more complicated than I think it really is. 

In my mind, Net vs App are really just two ways to describe how you prefer to group and organize your EPGs.  That's it.  They are both valid approaches, and in fact, you can use both in tandem across your tenants.

The analogy I use is to imagine a filing cabinet with three drawers.  In each drawer you might choose to organize things alphabetically or numerically.  Each drawer can use a different system. The result is the same in that you have organized things in a way you both prefer and understand.  What we failed to explain well is that by giving them names like "network centric" we were only trying to give a hint that one way of organization tries to mimic your legacy understanding of vlans and subnets, versus organizing by app tiers that need to talk to each other. 

So, what most people thing of as "net-centric" is one BD maps to one VLAN in one EPG.  App centric is only different in that you can have many encaps (note my change in terms, but I mostly mean VLANs) mapping to a BD via multiple EPGs.  That sounded kinda confusing.  Put another way, in App-centric, you would naturally have more than one EPG mapping to the same BD. The EPG is what matters most because that is where you apply policy for endpoints.

So getting to your design.  I will caveat that I don't have all the details of your setup, but I will try to give you my opinion. 

First question:  Do you absolutely require that each tenant has its own VRF? 

Let me qualify that.  ACI has no issue with lots of VRFs and we can do route leaking all day long.  However, I often find people think of VRFs as a tool to segment things.  It is a large hammer of a tool in that case, when other tools may be more suitable.  IMO, multiple VRFs are usually most useful when you have overlapping subnets you need to address.  Using VRFs for quick and dirty segmentation is not that way to go, IMO.  I say that because it means you will now always have to configure and track route leaking and be sure you know what you have leaking at any given time. It is operational overhead that you might not actually want.  I usually challenge customers to justify why they think they need many VRFs.  In 90% of the cases, they realize they don't. 

If you can put all your tenants in one VRF, that is going to make your migration that much easier.  It would mean you would only have to create new EPGs under existing BDs that organize and apply policy to your app tiers.  Migration could be as easy as moving the EPs to the new EPG when you are ready, and still allow communication to "legacy EPGs" via contracts where you wanted.  No need to change IP addresses/gateways on the hosts.  You would not have to worry about hair-pinning in and out to reach the legacy stuff outside.  You would not have to worry about route leaking or overlapping subnets.  Less is more, IMO. 

This is just one man's opinion and I don't speak for Cisco, but you might re-think your approach to see if you can simplify things much like the examples I gave above.  I also understand that I have oversimplified things to try and highlight general concepts.  Your environment will undoubtedly have complexities I am unaware of that you will need to think around.  Hope that helps. 

View solution in original post

Highlighted
Beginner

Re: Move to Application Centric from Network Centric

Thanks @joezersk ! 

This is a great explanation for that and it really helps not only for the current setup, also for further discussions..;-) 

 

BR 

Udo 

CreatePlease to create content
Content for Community-Ad

Cisco COVID-19 Survey