GUI vs. CLI - Where are the CLI AEP's?

[paulhieb1]

It's come to my attention today that AEP's defined in the GUI are not showing up in the APIC running config.

How would the GUI handle CLI configuration that would normally result from explicit AEP config....

Or conversely, without the ability to define AEP's in the shell, is it even possible to script an entire ACI environment from the CLI?

[gmonroy]

paulhieb1,

    Please reference the NXOS Style CLI User Guide for more information on your topic in question. Specifically, the sections that note the incompatibilities between the NXOS Style CLI and the Advanced GUI. In short, one should be decided on for configuration and stuck to throughout. The hidden inter-dependencies masked via the Python scripts called by the NXOS Style CLI leads to hidden objects when viewed from the advanced gui as well as objects that may be prepended with "__ui__". 

With that said, if you wanted to view existing instances of AEPs via the CLI, you could use the following moquery cmd:

moquery -c infraAttEntityP

However to directly answer your question, I believe AEPs are one of the constructs that are hidden within the masking due to the NXOS Style CLI. They will still exist from an MIT perspective (can be verified via moquery), but since there was no "AEP" in standalone NXOS, it wouldn't make sense to call it and configure it explicitly via the NXOS Style CLI.

-Gabriel

[paulhieb1]

---

-Gabriel

---

but since there was no "AEP" in standalone NXOS, it wouldn't make sense to call it and configure it explicitly via the NXOS Style CLI.

That seems like bad logic - there's no interface profile, fex profile, vlan-domain, tenant, bridge-domain and so on in standalone NX-OS CLI either.

[gmonroy]

paulhieb1,

    Some key differences between the constructs you mentioned and something like an AEP, is that Fexes, Interfaces and VLANs all exist in some form on NXOS. Tenants and BDs are the specific ACI logical constructs used to localy segment your policy (multi-tenancy being a key feature of ACI) and to define your flood space (at a high level anyways, NXOS hard tied a single VLAN to a flood domain so you didn't have this option).

AEPs are just an access policy construct that, at the end of the day, tie your switches/ints back towards your VLANs. On older versions, it used to be used for vswitch policies, but that has since been migrated to the VMM domain definition itself. You can refer to the attached diagram in this post for an Access Policy map.

History aside, the better question to ask would be what part of the AEP and it's associations are you looking to modify via the NXOS Style CLI, that isn't already taken care of for you automagically via the python scripts called by the CLI?

-Gabriel

[paulhieb1]

I'm trying to keep consistency between objects created in the GUI and CLI for purposes of legacy network integration in migration phase of a largely bare-metal environment. The main reason being the preference of multiple engineers of the tool used in programming the fabric. This caveat makes that an impossible task.

I'm hopeful that a solution exists that will allow the same AEP to be statically associated to EPG's via either the CLI or GUI.