Cisco ACI Seperating Backup/Restore Traffic from Production Traffic

[S. B]

Hi,

I am looking for what are the documents/Best Practices and Recommendations for :

1- Using a shared ACI network infrastructure for the "production" and "backup/restore" traffic

2- 1- Using a dedicated ACI network infrastructure for the "production" and "backup/restore" traffic

Which one is recommended?

In any case, what are the considerations on ACI Fabric?

In case of separate networks, Can a server port be excluded from the fabric and only be dedicated for a separate "backup" network? what should be considered in ACI?

In case of shared networks,  what should be considered in ACI?

Thanks

[Robert Burns]

There's no special guide specifically for backup traffic.  Your backup solution vendor will likely have recommendations that can be implemented, but it's the backup solution that should dictate the design more than the infrastructure. 

There's no need to run a separate external backup network outside of ACI - that's exactly what ACI is for - traffic segmentation & security.  With ACI you have some options which come down to your existing design.

There would be some questions to be answered:

• Are all clients & targets directly attached to ACI?
• How many user Tenants do you have?  If all your application profiles & EPGs are using a single tenant, then there's no issue putting a "BackupClient_EPG" and "BackupServer_EPG" in that same tenant.  I would put them in their own Bridge Domain.  If the backup clients and targets use non-overlapping IPs (unused elsewhere in your environment) then you can even use the same VRF in your user tenant.   If you have multiple Tenants (ie. QA, Prod, Dev etc), then you can optionally locate these EPGs in the Common tenant, which would allow you to have clients across multiple EPGs be able to backup to the shared target.  

From an endpoint connectivity perspective, typically your backup clients will have a dedicated physical or virtual interface for backup traffic.  This would be attached to the corresponding "BackupClient_EPG".   To harden the security of this EPG I'd suggest enabling "IntraEPG Isolation" on this EPG - which will prevent your backup clients from communicating with each other (only allow them to communicate with the target).  Your backup server/target would have its backup network interface(s) attached to the "BackupServer_EPG" (no need for isolation on this EPG).  Then you'd add a contract between the Client & Server EPGs allowing whatever traffic you wish - you can limit this to the specific ports & protocols used by your backup solution software.  

Having your backup traffic contained within it's own EPG is the equivalent of separating the traffic in a legacy network by VLAN.  If you really need QoS, that can also be implemented, but ACI is typically far more robust from a capacity perspective (40G/100G fabric Uplinks) that we don't see too many customer need to worry about QoS for backup/restore traffic.

Whatever backup design you would implement in your legacy environment, ACI can replicate it.

Robert