ACI Per Port VLANs and Designing Physical Domains

[jbekk]

Hi guys,

Up until now I've had a very basic ACI deployment with everything I'd needed to do existing in a single physical domain and VLAN pool. Things have gotten a bit complicated.

Basics are:

1. I have attached untagged traffic (i.e. VLAN 1) on specific interfaces into a VLAN3040 EPG.

2. I need to attach a second port's untagged traffic into VLAN1502 EPG

I understand that I've now jumped outside what a single physical domain and VLAN pool can do and I need to look at using "Per Port VLAN" scope (as described here: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010001.html). I'm ok with this.

What I don't understand is how do I design physical domains and VLAN pools moving forward into meaningful groupings so the object design doesn't become a general mess and I don't end up having to change it again?

Should I just have a VLAN1502_NATIVE physical domain and a VLAN3040_NATIVE physical domain? Any general guidance appreciated here.

[richmond · Accepted solution]

The good news is you don't need per-port VLAN to do this.

For EPG3040 use a static path binding with encap of 3040 (assuming this is your usual VLAN used for binding to this EPG) and the Access(802.1p) configuration.

For EPG1502 use a static path binding with encap of 1502 and the Access(802.1p) configuration.

You would only need per-port VLAN and different Domains/Pools if you wanted to use the same encap for two different EPGs deployed to the same switch. In this case we have untagged traffic on two different ports in different EPGs. This will work fine with the Access(802.1p) setting.

Think of it like regular switching. We can have untagged traffic arriving at switches and put them in different VLANs no problems, just set the access VLAN. Here we use the VLAN to assign EPG and we set the Access VLAN in the same manner.

As a side note, the only difference is in ACI we need to use Access(802.1p) (which is effectively trunk native vlan) and not Access(Untagged) (which is access vlan) due to limitations in gen 1 hardware that are carried over in the policy model. If we try to deploy the same VLAN as tagged and Access(untagged) on the same switch we get an error. If you do it as tagged and Access(802.1p) then it works fine.

[jbekk]

Just got around to testing this today. Works a treat. For those that follow here's a good guide to explaining this is here:

Guidelines and Limitations for EPG Static Binding Modes
The following guidelines and limitations apply when using EPG static binding mode:

• If access policies associated with a domain have not been provisioned properly, the EPG will generate a fault when a static binding is applied.
• Faults indicating invalid path typically refer to some missing access policies given the defined path.
• Faults indicating VLAN issues typically refer to a missing VLAN association given the defined path.
• When a port is set to Untagged, that port can no longer be utilized as an untagged port in other EPGs.
  • For this to be accomplished, deploy the EPG instead as 802.1p.
• When utilizing 802.1p defined ports with other definitions on the same port as trunked, packets will egress this interface as VLAN-0, or as untagged in the case of EX switches.
  • Most devices process VLAN-0 as an untagged packet and have no issues.
  • For hosts that cannot VLAN-0 as an untagged packet, the setting must be Untagged.

There are some gotchas there.... but otherwise you can use this successfully.