servers migration to ACI Fabric

[Omar3891]

hello,

i'm planning to migrate 30 servers having different services and communicating to each other using L2 network inside N5K to ACI Fabric, each server dual homed to switches with concept leg A and B, my plan is to configure the Fabric with exact Configuration in N5K by creating EPGs and BD representing current VLans and map the ports to those EPGs and set the policy for the VRF to be unforced so its allow servers to communicate between different EPGs my questions is :

- do i need to configure Contract for all EPGs even though i will disable the policy enforcement ? 

- what is the best practice in terms of  moving servers connections legs for example if i move all connections in leg A to ACI is     that will cause connections disruptive or i need to move one leg a time for each servers but that will cause disconnection         with other servers i think ?

- can setup all EPGs under one bridge domain or the best practice is to have them back to back EPG1 BD1 ?

- what i need to put in consideration for this L2 type migrations  ?

thank you Cisco Community         

[Robert Burns · Accepted solution]

"- do i need to configure Contract for all EPGs even though i will disable the policy enforcement ?"

Robert - Contracts will not be effective unless Policy Enforcement on the VRF is enabled.  Think longer term - if you ever want to apply security between EPGs, you'll need contracts at some point.  There's also options such as vzAny, Preferred Groups and Endpoint Security Groups (ESGs) to consider.

"- can setup all EPGs under one bridge domain or the best practice is to have them back to back EPG1 BD1 ?"

Robert - Depends on your design.  In a traditional 'Network Centric" deployment, that usually mimics as close to a legacy design as possible, each EPG maps to a single BD.  For a more advanced Application Centric approach, you can put all EPGs into a single BD.

"- what i need to put in consideration for this L2 type migrations  ?"

Robert - One other consideration is to ensure the BDs are set to "Flood" for Unknown unicast.  This is a best practice when connecting/migrating endpoints from legacy to ACI, and the GW still resides in the legacy network.  Once you migrate the GW for that VLAN to ACI, you can switch Unknown Unicast handling back to HW Proxy mode.  

Regards,

Robert

[Walker1]

There are several current and future trends happening concurrently in the DC space, described as follows. Operations evolution: Moving from the use of CLI to orchestration tools to manage and operate the DC network. PFMLogin

Policy evolution: Evolving from standard IP subnet FW-based access control to advanced, policy-based access control, which allows deploying new applications into an ACI Greenfield environment in a more “application-centric” manner.

Component evolution: Interconnecting existing DC network infrastructure to newly deployed ACI fabrics in order to allow applications to be gradually migrated from one infrastructure to another, ideally in a non-disruptive manner