Have you ever come across an invalid-vlan or invalid-path error in an ACI Endpoint Group, L3Out or Tenant?

invalid-vlan error

The chances are, there is a problem in your Access Policy Chain – i.e. the collection of Access Policies that you created before adding a static mapping in an EPG.

If you follow my foolproof method, you are guaranteed to find the problem! So here is…

RedNectar’s Foolproof Validation Process for an Access Policy Chain

TLDR Version

1. Locate the Leaf Profile for leaf 2201 and 2202
2. In the work pane, double-click the listed Associated Interface Selector Profile (which will actually be a Leaf Profile – there is NO SUCH OBJECT IN ACI CALLED Interface Selector Profile)
3. When the Interface Profile opens, locate the Interface Selector that represents your port-channel, and double-click it. This will take you to the Access Port Selector page (don’t you just love Cisco’s naming consistency?)
4. In the Access Port Selector page, locate the Policy Group, and click the external link button
5. This will open a pop-up for your VPC Interface Policy group. On this screen, verify:
   1. The Link Aggregation Type is indeed Virtual Port Channel (VPC)
   2. The Port Channel Policy is a policy that sets LACP to Active (use the external link button to check)
   3. There is indeed a value in the Attached Entity Profile (even though there is NO SUCH OBJECT IN ACI CALLED Attached Entity Profile – instead what you SHOULD see there is an Attachable Access Entity Profile)
6. Click on the external-link button next to the Attachable Access Entity Profile name. This will open a pop-up page for the  Attachable Access Entity Profile
7. In the Attachable Access Entity Profile page, locate your Physical Domain in the list of Domains for this AAEP.
8. In the L3 Domain Profile page, locate the VLAN Pool and click the external-link icon next to it. This will open a pop-up page showing your VLAN Pool values
9. In the VLAN Pool page, validate that
   1. The Allocation Method is Static (although with v5.2 onwards it doesn’t matter)
   2. The VLANs you wish to use are listed.

Oh – and there is a great shortcut method too, but for that you’ll need to jump to the end of the full article

 /TLDR

The Full Version – with worked example

I’ll begin with an example – I want to statically map VLAN 2194 on my VPC configured on ports Ethernet 1/48 or switches 2201 and 2202 to my WebServers_EPG

Let’s assume I’ve done the mapping and found the invalid-vlan error illustrated above, so I need to ensure a VPC has been configured in an Access Policy Chain that includes ports Ethernet 1/48 or switches 2201 and 2202 as well as vlan-2194

The generic view for an Access Policy Chain is of course:

Generic Access Policy Chain

So for the example above, I’d expect it to be configured as:

Access Policy Chain for scenario

To validate this chain, I’ll begin with the Leaf Profile.  If I have followed Best Practices then I’ll find a single Leaf Profile that has both Leaf 2201 and Leaf 2202

And sure enough, here it is – in my lab it is called Shared:L2201..2202_LeafProf

Step 1-Check the Leaf Profile

Check Leaf Profile

With the Leaf Profile opened I’ll check

1. That the Leaf Selector does include Leaves 2201 and 2202 – and from the illustration, it appears that it does
2. That an Interface Profile is linked to the Leaf Profile. Again from the illustration, I can see it is lined to the Shared:L2201..2202_IntProf

Step1-Checked

Step 2-Check the Interface Profile

From the Leaf Profile,  if I have followed Best Practices then I’ll find a single Interface Profile so I can double-click the Linked Interface Profile called (in this case Shared:L2201..2202_IntProf) to open it

Check Interface Profile

From here,

1. Note that the Interface Profile is automatically selected in the Navigation Pane and the interface selectors expanded
2. Check that the Interface Selector
   1. is correctly named (It’s called MINT:1:48, reflecting the interface number)
   2. points to the correct interface (1/48 is correct for our example)
   3. is linked to the correct Interface Policy Group (I can see it is linked to a policy group called MINT:L2201..2:1:48.l2sw_VPCIPG)
3. Double-click on the Interface Selector to to continue…

Step2-Checked

Step 3-Check the Interface Selector

After double-clicking the Interface Selector, the Access Port Selector page opens (Don’t you just love Cisco’s consistency with naming :-J)

Check Interface Selector

You’ve already checked that there is a Policy group linked, so all you need do here is click on the external link to open up the configuration page for the VPC, in this case the VPC is named MINT:L2201..2:1:48.l2sw_VPCIPG with the name reflecting the leaf switch IDs and the port number used for the VPC.

Step3-Checked

Step 4-Check the Interface Policy Group

Once the Interface Policy Group window opens (be patient, there’s a LOT of fields to update) there are three main things you want to check (for a VPC)

Check Interface Policy Group

1. Check that the Link Aggregation Type is correct
2. Check that the Port Channel Policy is correct
3. Check that the Policy Group is indeed linked to the AAEP – in this case the AAEP is called MINT:HostLinks_AAEP so we’ll assume that it is correct for now.

Click on the link icon to open the linked AAEP window…

Step4-Checked

Step 5-Check the Attachable Access Entity Profile

Check AAEP

All you need to do here is verify that the AAEP is linked to the correct Physical Domain, in this case, I can see that there is a L3Domain and a Physical Domain involved, but since we are troubleshooting a static mapping for an EPG, the Physical Domain is the correct one to choose. If the original error had been on a L3Out, I’d be choosing the L3 Domain.

Double-click on the Physical Domain name – in this example MINT:MappedVLANs_PhysDom to open the Physical Domain window.

Step5-Checked

Step 6-Check the Physical Domain

With the Physical Domain window opened, all you need to check is that it is indeed linked to a VLAN Pool, and in this case, I can see that it is linked to a VLAN Pool called MINT:MappedVLANs_VLAN.Pool – suggesting the the Best Practice of having one VLAN Pool Per Domain has been followed.

Check Physical Domain

Click on the link icon to open the linked VLAN Pool window…

Step6-Checked

Step 7-Check the VLAN Pool

With the VLAN Pool window opened, there are two things to check

1. That the allocation mode is static (or at least has a static range added for the relevant VLANS)
2. That the VLAN ID  you are checking actually exists

Check VLAN Pool

In our example, if you recall, an invalid-vlan error was raised when we statically mapped VLAN 2194 on my VPC configured on ports Ethernet 1/48 or switches 2201 and 2202 to my WebServers_EPG

So at last we have found the cause of the error.

Step8-FAILED Check

If we now add vlan-2194 to the VLAN Pool, the error will go away.

VLAN 2194 Added

Take a breath…

OK. you now have a few windows to close, but if you have been following my progress diagrams along the way, you’ll notice that we’ve checked all part of the Access Policy Chain.  This is a foolproof method for finding breaks or mis-aligned policies, policies accidentally linked to the wrong object ect.

And now that I’ve put you through all that pain, I’ll tell you the Not-so-foolproof-but-much-quicker way of checking the access policy chain!

RedNectar’s Not-so-foolproof-but-much-quicker way of checking the access policy chain

Start at the VLAN Pool, and in the work pane (after checking the correct VLANs are in the VLAN pool, and the Allocation Mode is correct) click the Show Usage button

Not So Foolproof Method

The fact that both leaves appear here shows that there IS a chain from the VLAN Pool back to both leaves – and to validate that the correct ports have been assigned, click the Click to Show Detail links.

The Usage Details window validates that the VLAN pool is mapped via the correct interfaces to the leaf switch for this articular Access Policy Chain.

Why – Not-so-foolproof?

This is a really great method to ensure that all the connections are valid, but it does NOT show you exactly which AAEP or Policy group is used, but even MORE importantly, if there IS a break in the chain somewhere, say between the Policy Group and AAEP, or between the Interface Selector and the Policy Group, you’ll see nothing here. Literally. Nothing. And you’ll have no idea where the break is, so you’ll go back to the Foolproof Method

So, if you are just sanity checking, I’d always recommend that you start here – at the VLAN Pool.  IF everything looks good here you can probably rest peacefully. BUT if you are troubleshooting a problem, then you will end up having to traverse the foolproof method – although if you’ve followed best practices of only having one Interface Profile per Switch Profile, you can usually begin at Step 2

RedNectar