12-11-2018 03:39 AM - edited 03-01-2019 05:43 AM
Hi board,
I'm pretty new to ACI and I'm struggling with a very basic problem: How to properly configure an leaf access port?
From my point of view there are too many ways to do it and I'm interested what's the right way to go.
Let's assume the following:
- 2 Application EPGs: EPG-A (enc-VLAN 11) and EPG-B (enc-VLAN 12)
- Access port types:
-- Bare metal servers: Untagged traffic
-- Non-VMM (vSwitch) hypervisors with tagged traffic
When I'm following some very good documents like the link below, the strategy for the vSwitch integration is:
vSwitch (vPC):
Create a generic AEP with a physical VLAN pool and the following mapping:
EPG-A: encap-vlan11 (trunk)
EPG-B: encap-vlan12 (trunk)
Create a leaf access policy group, attach the AEP to it and define settings like port-channel, storm-control etc.
Assign the leaf access policy group to an interface profile (which is assigned to a switch profile)
==> Done
If I want to have an untagged EPG-A port to a baremetal server, I cannot follow the same rules, because the generic AEP from above consists of multiple EPGs (EPG-A und EPG-B) and the mode is trunk.
Question: What is the correct way to configure an untagged access port?
Option 1:
- Do not create an AEP
- Create a leaf access policy group for baremetal servers (without AEP)and define settings like port-channel, storm-control etc.
- Assign the leaf access policy group to an interface profile (which is assigned to a switch profile)
- Static port assignment under the EPG configuration (mode access)
Option 2:
- Create a dedicated AEP for EPG-A access ports (mode access)
- Create a dedicated AEP for EPG-B access ports (mode access)
- Follow the same guidelines as for the trunk server ports configuration
12-11-2018 05:09 AM
Hi Johannes,
From my point of view there are too many ways to do it and I'm interested what's the right way to go.
You are not wrong there - VERY confusing.
Question: What is the correct way to configure an untagged access port?
Option 1:
- Do not create an AEP
DEFINATELY NOT AN OPTION - You need the AEP (or AAEP) to link the physical interface configuration to the VLAN config - via the Physical Domain
Option 2:
- Create a dedicated AEP for EPG-A access ports (mode access)
- Create a dedicated AEP for EPG-B access ports (mode access)
- Follow the same guidelines as for the trunk server ports configuration
That creates more AEPs than you need - and I'm not sure what guidelines you mean
How about Option #3 - use 802.1P
I think you actually have got the idea, but the following statement gives away the missing bit
If I want to have an untagged EPG-A port to a baremetal server, I cannot follow the same rules, because the generic AEP from above consists of multiple EPGs (EPG-A und EPG-B) and the mode is trunk.
Yes you can follow the same rules - you just configure the untagged EPG-A port to a baremetal server using 802.1P encapsulation instead of Untagged
Now although you didn't precisely say it, I suspect what you are trying to do is combine untagged traffic from some Bare Metal Servers with tagged traffic comming from VMs (on VLAN 11 & 12). To do this in ACI is a piece of cake (when you know the secret)
The secret is to UNLEARN everything you ever knew about VLANs :) People get too hung up about what VLAN a server is on because the imagine that servers will only be able to communicate with other serves in the same VLAN. In ACI, we are not so fussy if our servers are spread across multiple VLANs. So long as the servers are in the same EPG, they can talk to each other no matter what VLAN they are on.
So if my assumption above is correct, let's try Option #3, which would be:
In the Access Policies area
Now in the Tenant
==> Done
There is the expectation of course that for any given port that's expecting untagged traffic, it will all be for the same EPG - in other words you can't have untagged traffic arriving on a port from both EPG-A and EPG-B servers on the same port. (Although it will be possible - in fact may already be possible in 4.0 or 4.1 - to classify traffic into EPGs based on IP address rather than VLAN tag)
And glad you found the blog useful, even if didn't give you all the information.
[After though - I may have made this more complicated than needed. Maybe the only step you really need to take is the secret step (UNLEARN VLANs) and just add your Bare Metal Hosts as untagged using any spare VLAN vlan that exists in the VLAN Pool - and if you Bare Metal Hosts are directly attached and not attached via a L2 switch, this is definately the case, although I'd advise using 802.1P instead of untagged anyway - untagged makes the port an access port, 802.1P makes the port a trunk port with a native VLAN]
I hope this helps
Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem
12-11-2018 05:57 AM
Hi Chris,
thank you for the very detailed answer. And yes, your blog was very useful when I got started. I still don't agree with some parts (like creating an interface selector for each port etc.), but I think I'll have to learn it the hard way going in a wrong direction first and finally follow your advise in a couple of month when I screwed everything up :D
Back to the original question:
If I got you right, you don't do an EPG to encapsulation VLAN ID mapping within the AAEP.
The only purpose of the AEP is to link the domain (VLAN pool) with the leaf interface policy groups.
The mapping of the EPG to the local encapsulation VLAN is done via static port mapping per port.
My understanding was/is, that I have a global EPG to encap-VLAN "database" (the AEP) and don't have to handle the EPG to encap-VLAN mappings per port.
Basic idea: Just assign an ESXi port to a template (leaf interface policy group) and all the EPGs and correct VLAN mappings are there. This reduces operational human faults like a missing EPG towards one ESXi host.
I'm aware of the fact, that my problem is subject to VMM and DVS ... but just for fun - let's assume we have a big environment with standard vSwitches :)
12-17-2018 01:21 AM
Hi,
You do need to watch out how you configure the interface policies for port-channels and vPC's.
When u build a policy for both of them, it will consider that policy to be the name of your port-channel/vPC, so when u try to bundle certain interfaces in this interface policy group, they'll be sending out of the same PDU's. So you cannot have 1 standard vPC/PC interface policy group for all of your hosts that are connecting via that way, you'd be creating 1 giant channel when you do that and it won't work.
So when u are talking about configuring vPC from the leaf to the host, you'll need define an interface policy group for each host that needs to be connected this way.
Another tip is to use the same port on both leafs when you are doing vPC, it makes your interface selector configuration a lot easier and you'll have more insight.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide