Apache,
There are a bunch of resources. Have you seen the following:
http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-735428.pdf
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-731686.html
Each customer has unique requirements. What we can do is detail some of the options available to you.
Let's look at your existing setup:
-Endpoints (Prod servers) are in multiple subnets
-Endpoints currently freely communicate with each other
Now you could simply slap everything into a single huge EPG and you'd have exactly what you have today. That obviously doesn't take advantage of any of the security and/or policy feature advantages ACI offers. Where I would start is by thinking about how you'd like to improve above.
Ex.
-Web servers should be able to communicate with each other freely
-External Users should be able to communicate to Web Servers only via HTTP/HTTPS
- Web servers but should be restricted on how they communicate with Application servers. (Only allow TCP Port xxx-yyy)
- Web Servers should have no ability to communicate directly with DB servers.
If you approach the design of your applications like this, you're not only tightening security, but you're also building your ACI policies at the same time (EPGs, Contracts etc)
The EPG design is how ACI applies policies. If you have groups of endpoints you'd like to share a similar policy (such as allowing HTTP/HTTPS services) it makes sense to group them into their own EPG. Remember that an EPG not only defines "how" endpoints communicate (Protocol & Ports), but they also define "who" they can communicate (which other EPGs). Once you have a plan for EPGs, creating the policies (contracts) is the next step. Inter-EPG communication is based on a whitelist, so you need to know which protocols & ports need to be allowed. This can present a challenge to some folks as they need to know which protocols & ports their systems need to access. You could blankly open up TCP, or you can tighten it to each single protocol/port.
When all your EPGs have been created, and the contracts between them configured, you need to get your existing endpoints into them. The easiest way to do this is to connect your legacy endpoints directly to ACI (attach to a Leaf). This gives us the power map each endpoint into the EPG it should belong to. Same If they are virtual endpoints, then you need to map the Port Group or VLAN into it's respective EPG.
Where the challenge lies is how to get to that point. This can be done by connecting ACI with your legacy network during the migration period. In order to funnel traffic from endpoints in your legacy network into an ACI EPG requires that we map via IP Subnet, by VLAN, or by specific Leaf interface.
At a very high level, what I would suggest is you configure your EPGs, then create an external L2/L3 network (aka External EPG in ACI) to connect ACI with your legacy systems. Each EPG will need access to communicate to the external network (to facilitate migration). This will allow you to swing over (reconnect) endpoints directly to your leaf switches one by one while maintaining connectivity. After all your endpoints are migrated, then you can tighten down the External L2/L3 contract and only let what "needs" to communicate with endpoints external to ACI.
Hope this helps.
Robert
