Using Tenants to Ease Organization of BDs

[weylin.piegorsch]

I'm looking for feedback to decide between two approaches to using ACI to organize legacy VLANs/subnets.

I'm designing a higher-ed ACI deployment, migrating away from a FabricPath environment.  In legacy, we operate everything in a single N7k VRF / VDC. Moving forward, we're looking at a network-centric approach (though we're debating how to integrate the FW, whether by: BD Stitching across with VRF and all EPGs in Preferred-Group; or, L1/L2 PBR).

Something we always hated about the legacy environment is that, with having hundreds of VLANs/SVIs, it was forever difficult mapping a client to their set of VLANs, and mapping a set of VLANs to their clients, even with the 128 characters allowed in NX-OS's vlan-name.

In ACI, we have tenants as a policy container.  Ostensibly this allows for security separation so that a tenant can operate their own BDs/etc.  However, even though we will never ever ever cede control to anyone outside the network team, ACI's "Tenants" still hold a prospect that they also separate BDs/EPGs/etc.

The alternative my Director is trying to argue us to support, is simply to use a naming policy to map clients and their policy objects, and leave everything in a single tenant (not the common tenant, but still a single tenant).

• He's arguing that using tenants to aid in organizing policy objects breaks the intent of the tenant object, leading to side effects and future changes that we either don't know about or can't predict.
• The argument I'm pushing back with, is that we already have a naming policy for VLANs, and it's awful in that this provides a very brittle mapping, subject to people being absolutely perfect in how they apply the policy, which historically has been poorly adopted or enforced.

What I'd like to hear, is comments related to this approach?

I welcome any/all comments and feedback.

weylin

[weylin.piegorsch · Accepted solution]

I spoke with a number of people from different organizations about this.  To a person, I got basically the same response:
"Huh.  Interesting idea.  I've never heard about anyone else doing that.  But it's clever, and in theory should work."

Ok... so maybe, but if no one else is doing this, I don't want to be the sacrificial guinea pig to test this out, and find bugs or unknown issues a month after deployment; or, have a code upgrade come along and royally mess things up.  So, we'll put a pin in this and revisit sometime in the future.

What we're doing instead is grouping EPGs and wrapping them in individual Application Profiles per client.  This should still align to the specific intent of APs, so I'm comfortable here.  ESGs also show promise of something interesting, but that approach is a little less clear, so we're moving down the path of grouping via AP.

This still leaves BDs ungrouped... but at least this is a step in the right direction.

weylin