cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4322
Views
5
Helpful
3
Replies

Leaf access port configuration strategy

Johannes Luther
Level 4
Level 4

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:

https://rednectar.net/2015/12/28/cisco-aci-tutorial-4-all-about-access-policies-the-new-interface-range-command/

 

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

3 Replies 3

RedNectar
VIP
VIP

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

  • Create a Generic Static VLAN Pool with VLAN 11 and 12 AND at least two other spare VLANs - let's say 13 and 14
  • Create a Generic Physical Domain linked to the Generic VLAN Pool
  • Create a Generic AAEP linked to the Generic Physical Domain
  • Create as many Interface Policy Groups as you need - you'll need one for every VPC, one for every PC, and probably one is enough for any Single-Attached Hosts collectively. Link evey Policy Group you create to the Generic AAEP (Important Step - easy to miss)
  • Hopefully you already have one Interface Profile per Leaf Switch, and one Switch Profile per Switch. Plus one more Interface Profile per VPC Pair of Leaf Switches, and one more corresponding Switch Profile per VPC Switch pair.
    • If not, create them and link them.
  • Add Interface Selectors to the appropriate Interface Profiles, and make each Interface Selector link to the appropriate Interface Polcy Group

Now in the Tenant

 

  • Create an Applicaiton Profile and add EPG-A and EPG-B
  • Link both EPGs to the Generic Physical Domain mentioned above.  This then gives you permission to use any of the ports and VLANs that are in that Domain's Access Policy Chain in a Static Mapping
  • Create Static mappings for the ports connected to the ESXi hosts where you are expecting tagged traffic so that
    • EPG-A: encap-vlan11 (Trunk)
    • EPG-B: encap-vlan12 (trunk)
  • Create Static mappings for the ports connected to the Bare Metal hosts where you are expecting UNTAGGED traffic so that
    • EPG-A: encap-vlan13 (802.1P encapsulation)
    • EPG-B: encap-vlan14 (802.1P encapsulation)

==> 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


RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

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 :)

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.

Save 25% on Day-2 Operations Add-On License