Ask Me Anything- Migrating Existing Networks to Cisco ACI

[ciscomoderator]

This topic is a chance to discuss more about the migration options from existing network designs to Cisco Application Centric Infrastructure (ACI). In this session the expert will discuss and answer questions that helps to understand the design considerations associated to the different migrating options.

In addition, Tuan will help to clarify and extend Cisco’s ACI main concepts such as Tenant, BD, EPG, Service Graph, L2Out and L3Out among others.

To participate in this event, please use the button below to ask your questions

Ask questions from Monday 11th to Friday 22th of November, 2019

Featured expert

Tuan Nguyen is a technical instructor has over 20 years of experience as a consultant, systems engineer and Certified Cisco Systems Instructor. He is a Technical Instructor at Sunset Learning Institute and teaches courses across routing and switching, security, service provider, Dara Center and Voice curricula. Tuan specializes in Cisco routers and Cisco IOS. He has extensive knowledge in all aspects from LAN and WAN technologies, including design, implementation and support of Cisco IP Unified communication, IP Multicasting, MPLS, Frame Relay, Routing and Switching, Cisco ISP and Cisco Security. He is also proficient in interconnectivity, data communications, network and analyzing, base lining and troubleshooting, router configuration, Multi-Protocol routing, protocol analysis, security and firewall configuration. Prior joining Sunset Learning Institute, he worked as a Senior Internetwork Engineer and Cisco technical instructor at TBN Consulting providing technical and consulting services. He also worked as a Senior Network Engineer at the Defense Information System Agency (DISA) designing, developing, testing and evaluating Data Center and Networking technologies. Tuan holds a Bachelor of Science degree in Electrical Engineering from the University of Colorado at Denver. He holds different certifications, CCDA, CCDP, CCNAs, CCNPs, CCIP, CCSP, CCVP, CCSI and a CCIE R&S (#2135).

Tuan might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Application Centric Infrastructure community.

Find further events on https://community.cisco.com/t5/custom/page/page-id/Events?categoryId=technology-support

**Helpful votes Encourage Participation! **
Please be sure to rate the Answers to Questions

[bolamiposi]

What will be your initial consideration for information gathering stage, while planning Migration of existing traditional 3 tiered Network infrastructure to Cisco ACI?

We are in the process of racking up all our ACI gears and this topic coming up at a good time to have experts to share the experience with.

[tuanguyen1]

Initial consideration for information gathering to migrate to ACI:

- Starting from a traditional network (Your current traditional 3 tiered Network)

- Your current traditional 3 tiered network could be built leveraging vPC, STP, FabricPath, VXLAN or even 3rd party devices

- Assumption is also that network services are connected in traditional fashion (routed mode at the aggregation layer)

- Default gateway in this case could be at the spine or on a pair of Border Leaf nodes

- Creating a L2 connectivity path between your current traditional 3 tiered aggregation layer devices to a pair of Border Leaf nodes

- No connectivity between leaf switches and no connectivity between spine switches for loop prevention mechanisms.  Only leaf switches connect to spine switches.

Additional references related to Migrating Existing Network to ACI:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/migration_guides/migrating_existing_networks_to_aci.html

[zher163]

I have a ACI fabric in my main DC, and a remote leaf somewhere else. What do I need to do to move the remote leaf to the main DC? just lift and shift? Will the remote leaf be added into the main fabric as local leaf when it's connected in the main DC? Can I preserve the IP schema? 

[tuanguyen1]

Hello,

Yes, just lift and shift if you want your remote to be physically move to the main DC.  When the remote physically moved to the main DC, just connect the remote leaf(s) that just moved to the Spine(s) and the fabric will automatically discover the new leaf(s) and add them to the fabric.  The IP schema should be preserved assuming they are not in conflict with the current main DC ACI. 

[Jerome Tissieres]

This document recommends, for the migration phase, to associate each VLAN with a corresponding EPG. Let's take a real use-case: If we have a traditional 3 tiered network (vPC, STP, FabricPath) with around 300 VLANs, that will be 300 EPG at the beginning of the migration. And if each of these VLANs has a L3 ACL at the L3 spines/border nodes. I don't talk about any L4-L7 network service, only L3 ACL at the spines/border nodes of the brownfield network. During the migration, we need to "translate" theses ACL into filters and contracts into the ACI. How do we calculate this? Is there a scalability calculation method, and what are the maximum limit of EPG, filters and contracts for ACI? Thank you, Jerome

[tuanguyen1]

Hello,
ACI doesn't filter between IP addresses, but between EPGs.
An example of ACL from the Brownfield:
permit tcp 192.168.50.77 0.0.0.0 172.16.30.21 0.0.0.0 eq 37
So this is what you need to do (I've assumed /24 subnets and default gateway addresses of x.x.x.1):
Create a Bridge Domain - let's call it 192.168.50.0-BD

* Add an IP address to the BD - make it the default gateway for the 192.168.50.0/24 network, presumably 192.168.50.1/24
Create another Bridge Domain - let's call it 172.16.30.0-BD

* Add an IP address to the BD - make it the default gateway for the 172.16.30.0/24 network, presumably172.16.30.1/24
Create an EPG - let's call it 192.168.50-EPG

* and put host 192.168.50.77 in that EP
Create another EPG - let's call it 172.16.30-EPG

* and put hosts 172.16.30.21 in that EPG
Create a filter for TCP Port 37
Create a contract

* Add a subject to the contract
* Add a filter to the subject
Apply the contract between the two EPGs, presumably with 172.16.30-EPG providing the contract and 192.168.50-EPG consuming the contract.
I am not aware of a scalability calculation method available.
the maximum limit of EPG, filters and contracts for ACI:
For EPG, the maximum limit is 15,000
For Filter, the maximum limit is 10,000
For Contract, the maximum limit is 10,000

[spreed]

Hello,

Thanks for having this event.  Really appreciate these opportunities.

When migrating applications into ACI it may be that all the various required flows are not known.  For example an application may need a flow to destination port 15000, but the applications team may not be aware of that requirement.  Can the ACI policy model be queried to find out what flows are in use between endpoints that have a default contract between them? (For example querying for what src/dest IPs  src/dest TCP/UDP/ports?)

Thanks again,

Simon

[tuanguyen1]

Hello,
Yes, the ACI policy model can be queried to find out what flows are in use between endpoints that have a default contract between them. An administrator uses a contract to select the type(s) of traffic that can pass between EPGs, including the protocols and ports allowed. If there is no contract, inter-EPG communication is disabled by default. There is no contract required for intra-EPG communication; intra-EPG communication is always implicitly allowed.
Thanks,
Tuan Nguyen

[spreed]

Ok thanks.  Can you provide an example of how the policy model can be queried for that info, either through the command line on the APIC or through an API rest call?  

[tuanguyen1]

Hello,

The example of how the policy model can be queried for that info through the GUI on the APIC.

Before creating the contract, we’ll start by creating filters, being the protocols we’re using to allow traffic between two EPGs. For this example we will create a filter for a contract that will go between a Database EPG and an Application EPG. In this example, the database EPG (DB-EPG) will be providing database services to the Application EPG (App-EPG), using port 1433 as a common MS SQL port.

Create Filter:

• Log in to your APIC
• Click Tenants and make sure to select the tenant you’re going to use
• Expand Security Policies on the Left Navigation Tree
• Select Filters
• Right click on Filters and select Create Filter
• In the pop-up give it a name such as “DB-Filter”
• You can put in an optional description
• Click the + sign next to Entries to add a new filter
• Put in a name such as MSSQL
• The configurations here will depend on what you’re trying to do. You may want to speak with your firewall administrator to see what is recommended. For this example I will use IP as my Ethertype.
• I will select TCP as my IP Protocol
• For my destination ports I’ll type in 1433. Notice I can use the pull down to select ports that are already available, but I don’t have to. I can enter anything I want, just be careful that you don’t hit TAB or it will change the value in this field
• Click Update
• Click Submit
• Now that we have the Filter created we can create a Contract in which to put it. Keep in mind, I’m assuming you already have two EPGs, in this case we’re using DB-EPG and App-EPG.
• Create contract:
• While still in your tenant expand Security Policies
• Select Contracts
• Right click on Contracts and click Create Contract.
• Give it a name such as DB-Contract-MSSQL
• Give it an optional description
• Click the + sign next to subjects (remember a subject contains a filter, object, and optional label)
• Give the subject a name, such as MSSQL-Subject
• We can leave the two check boxes checked as they will allow for bidirectionality. However, if we only want to apply these filters unidirectionally from provider to consumer we can uncheck these.
• Click the + Sign next to Filters and select the filter we created in the last step (DB-Filter)
• Click Update
• Click OK
• Click Submit

• We have an App-EPG and a DB-EPG, we also have a contract created, so to complete our Application Network Profile, we need to attach our contract between the EPGs.

  Create and Application Network Profile:

  1. Right click on your DB-EPG
  2. Select Add Provided Contract
  3. In the pull-down menu select the contract you just created
  4. Click Submit
  5. Now right click on your App-EPG
  6. Select Add Consumer Contract
  7. In the pull-down menu select the contract you just created
  8. Click Submit

  9. Now if you click on the Application Profile that contains these to EPGs and Contract we see the topology where DB-EPG allows App-EPG to see traffic over port 1433.

[spreed]

Hi Tuan,

Thanks for providing the details for the process of creating filters, contracts, and applying them.

However my question had a different focus.  I was asking whether the fabric policy model can be queried about an existing flow between two endpoints with a default (open) contract between them in order to determine what TCP ports are actually in use.  This would be helpful when the required TCP ports are not known in advance by the applications team.

Once the required ports are known, then a matching contract could be built to allow the traffic.

Thank you Tuan; sorry about the confusion on this question.

[BasavarajNingappa6558]

Hi Team,

I'm having a question regarding multi-site configurations

The IPN switch we use to connect to the spine and IPN switch, in all of the document its mentioned, configure sub interface using VLAN 4, is it mandatory to use sub interface only or can we also use layer 3 VLAN 4 interface to configure instead of subinterface?

Thanks

Basavaraj

[tuanguyen1]

Hello,
You can use layer 3 VLAN 4 interface to configure instead of subinterface. The use of subinterfaces on the links connecting the IPN devices is optional and only required when multiple VRFs need to be connected over the same physical interface.

[spreed]

Hi Tuan, do you have a comment on this question posted earlier?  Thank you.

"

Thanks for providing the details for the process of creating filters, contracts, and applying them.

However my question had a different focus.  I was asking whether the fabric policy model can be queried about an existing flow between two endpoints with a default (open) contract between them in order to determine what TCP ports are actually in use.  This would be helpful when the required TCP ports are not known in advance by the applications team.

Once the required ports are known, then a matching contract could be built to allow the traffic.

Thank you Tuan; sorry about the confusion on this question.

"