Recommendation on mapping leaf switches/ports in multi-tenancy fabric?

[SIMMN]

Say I will have 6 compute leaf switches (101-106) in the ACI fabric which will have three tenants (T-A, T-B and T-C). I do not have any VLAN overlap between tenants.

To keep the post simple, I would do the static port binding for EPGs/VLANs to ports.

So what would be the best practices to map/assign leaf switch(es) and/or port(s) to individual tenant? Or do I even need to care about the mapping/assignments?

Whatif I do have VLAN overlapping between Tenants?

Thanks in advance!

[AshSe]

---

So what would be the best practices to map/assign leaf switch(es) and/or port(s) to individual tenant? Or do I even need to care about the mapping/assignments?

Map as you like.

Whatif I do have VLAN overlapping between Tenants?

---

VLANs in ACI have local significance. Different Tenants can use the same VLAN IDs without any confliction. So no worries here too.

Check:

[SIMMN]

So will these VLAN overlapping scenarios work? I got VLAN 100 in both Tenant A and Tenant B with 2nd gen or newer leaf switches.

#1, can I have Leaf 101 Port eth1/1 trunk for VLAN 100 under Tenant A and Leaf 101 port eth1/10 trunk for VLAN 100 under Tenant B?

#2, can I have Leaf 101 Port eth1/1 trunk for VLAN 100 under Tenant A and Leaf 101 port eth1/10 access for VLAN 100 under Tenant B?

#3, can I have Leaf 101 Port eth1/1 access for VLAN 100 under Tenant A and Leaf 101 port eth1/10 access for VLAN 100 under Tenant B?

[RedNectar · Accepted solution]

Hi @SIMMN ,

So will these VLAN overlapping scenarios work? I got VLAN 100 in both Tenant A and Tenant B with 2nd gen or newer leaf switches.

#1, can I have Leaf 101 Port eth1/1 trunk for VLAN 100 under Tenant A and Leaf 101 port eth1/10 trunk for VLAN 100 under Tenant B?

#2, can I have Leaf 101 Port eth1/1 trunk for VLAN 100 under Tenant A and Leaf 101 port eth1/10 access for VLAN 100 under Tenant B?

#3, can I have Leaf 101 Port eth1/1 access for VLAN 100 under Tenant A and Leaf 101 port eth1/10 access for VLAN 100 under Tenant B?

---

The answer to all 3 of these questions is:

YES - but you'll need to configure the Interface Policy for put ports to include a L2 Interface Policy that enables Port Local Scope. And also remember that if any port is configured as an access port, it cannot carry tagged traffic as well. Should you require an access port to carry tagged traffic, configure it as an 802.1p port.

[SIMMN]

Thanks for the info but why? Is it just because the overlapping VLAN between Tenants is on the same Leaf? I guess I am just too familiar with the use case of Port Local Scope.

[RedNectar]

Hi @SIMMN ,

I'm struggling to remember the reason why per=port VLAN scope is NOT the default - but I suspect it has something to do with either

1. the way VLANs were implemented on 1st generation switches (the feature wasn't available until v1.1 oe 1.2 - can't remember)
2. the way ACI floods BPDUs. In fact, even today, if you are using MST, "Per Port VLAN is not supported on interfaces configured with Multiple Spanning Tree (MST), which requires VLAN IDs to be unique on a single leaf switch, and the VLAN scope to be global." - see the Layer 2 Config guide

[AshSe]

VLAN Scope: Port Local scope

As per Cisco APIC Online Help:

Port Local scope—Allows allocation of separate (Port, Vlan) translation entries in both ingress and egress directions. This configuration is not valid when the EPGs belong to a single bridge domain.

From the Search:

In Cisco Application Centric Infrastructure (ACI) and specifically within the Application Policy Infrastructure Controller (APIC), configuring the VLAN scope as "Port Local" has a specific meaning and purpose.

Meaning of VLAN Scope: Port Local

When you configure a VLAN with a "Port Local" scope, it means that the VLAN is only significant and unique to the specific port (or interface) on which it is configured. In other words, the VLAN ID is only locally significant to that particular port and does not need to be unique across the entire fabric or even across other ports on the same switch.

Purpose of VLAN Scope: Port Local

The primary purpose of using a "Port Local" VLAN scope is to provide flexibility and simplify VLAN management in scenarios where VLAN IDs do not need to be globally unique across the entire ACI fabric. This can be particularly useful in the following scenarios:

1. Simplified VLAN Management: By using port-local VLANs, you can reuse the same VLAN ID on different ports without worrying about VLAN ID conflicts across the fabric. This can simplify the configuration and management of VLANs, especially in large environments.

2. Support for Overlapping VLANs: In multi-tenant environments or when integrating with legacy networks, you might encounter overlapping VLAN IDs. Port-local VLANs allow you to handle these overlaps without requiring a global VLAN ID renumbering.

3. Ease of Migration: When migrating from a traditional network to ACI, you might have existing VLAN configurations that you want to preserve. Using port-local VLANs can make this transition smoother by allowing you to maintain the same VLAN IDs on specific ports.

4. Enhanced Security and Isolation: By limiting the scope of a VLAN to a specific port, you can enhance security and isolation. Traffic within a port-local VLAN is confined to that port, reducing the risk of VLAN hopping attacks and unintended traffic leakage.

Example Use Case

Consider a scenario where you have multiple tenants, each with their own VLANs, and you want to ensure that the VLAN IDs used by one tenant do not interfere with those used by another tenant. By configuring VLANs with a port-local scope, you can assign the same VLAN ID to different tenants on different ports without any conflict.

Configuration

In Cisco ACI, you typically configure VLAN scope as part of the EPG (Endpoint Group) configuration. When defining the VLAN for an EPG, you can specify the scope as "Port Local" to achieve the desired behavior.

Summary

Configuring VLAN scope as "Port Local" in Cisco ACI APIC allows VLAN IDs to be locally significant to individual ports, providing flexibility, simplifying management, and supporting scenarios with overlapping VLANs or multi-tenant environments. This approach can be particularly beneficial in large-scale deployments, migrations, and environments requiring enhanced security and isolation.