Logical Node does not appear on GUI

[Sig Nine]

Hi, guys.

When I create a Logical Node or Logical Interface in Cisco ACI from the APIC NX-OS style CLI, it works, but it does not appear on the GUI. To begin with, you cannot set the name of a Logical Node or Logical Interface when setting it from the APIC NX-OS style CLI.

tenant Tenant1
  vrf context Vrf1
    exit
  l3out L3Out1
    vrf member Vrf1
    exit
  external-l3 epg Epg99 l3out L3Out1
    vrf member Vrf1
    exit
  exit
!
leaf 101
  vrf context tenant Tenant1 vrf Vrf1 l3out L3Out1
    router-id 10.99.99.101
    route-map L3Out1_in
      scope global
      exit
    route-map L3Out1_out
      scope global
      match bridge-domain Bd1
        exit
      exit
    route-map L3Out1_shared
      scope global
      exit
    exit
  interface vlan 1001
    vrf member tenant Tenant1 vrf Vrf1
    ip address 10.0.0.254/24
    mtu 1500
    exit
  interface ethernet 1/1
    switchport trunk allowed vlan 1001 tenant Tenant1 external-svi l3out L3Out1
    exit
  exit
!

In fact, it creates a MO like "__un_node_1001". But this is not displayed on the GUI.

How can I set up a Logical Node or Logical Interface created from the APIC NX-OS style CLI to be reflected on the GUI?

Regards,

[joezersk · Accepted solution]

I would like to answer but perhaps not in the way you expect.  First let's peak behind the covers of how ACI is built.  At its core, ACI is purely an object-model, front ended by a REST API.  This is a very big evolution from the earlier days of binary operating systems like NX-OS, IOS, etc.  With it, we effectively open the door to allow anyone to do anything they like with the system through this API, even using tools not devised by Cisco.  It is actually quite liberating, IMO. 

With this understanding, let's now consider your situation.  You are using the NX-OS CLI, but I will define CLI not as "command line interface" but as "command line interpreter".  In ACI, NX-OS is not NX-OS in the way you would think.  The "cli" is really just a management application that looks like and feels like NX-OS, but in the background it is simply making REST calls to create objects and associations.  The thing is, it is impossible to expose every object via the CLI, with all of its attributes and associations to other objects and not make a huge mess of it.  This is where you sometimes get those oddly named MOs like you wrote in your original post.  Without getting too much into the weeds, here is my recommendation (in fact TAC makes the same recommendation).  Ready?

Don't use the CLI to make config, but only use it to troubleshoot

To make config, as I mentioned a bit earlier, you can use any number of useful tools.  You could use the UI, of course, and many do....but you could argue (and I would agree) that the UI method is often too slow, and comes with lots of clicks and screens, etc.  So, what most customers seem to evolve to (and it is a positive evolution) is to begin or continue the journey to automation and orchestration.  You can use popular opensource tools like Ansible, Puppet, Chef, Terraform.  You can use scripting and programming languages like Python, and Powershell, or C or javascript.  You can buy commercial orchestration systems (from Cisco and any other vendor that uses REST).  The choices are many.  I used the word 'liberating' earlier and this is what I mean.  This is the power of an API driven approach.  Sorry if I got too preachy, but I really enjoy what I've learned to do with automation tools and APIs. 

I still use the UI a lot in my lab, but I find that when I do the same things over and over, I start writing Ansible playbooks, or using POSTMAN to build some collections. 

Hope that helps!

[Sig Nine]

Hi, joezersk.

I agree with you. However, I thought it would be good if I could use the CLI to the extent possible, as it can be useful for creating a simple verification environment.

Ansible is also a great option, but not all modules exist for all of ACI's features. So we're having fun building Ansible modules!

Thank you for your reply.

Regards,

[joezersk]

Please allow me to introduce you to the Ansible module called aci_rest.  With that module, you can do everything and anything to ACI with JSON and/or XML in the body of the task.  It is effectively a catch-all module when there is not a more specific module already.  So, you might be thinking "Where would I go get the correct JSON or XML for any given config?"  The answer lies in another useful tool built right into APIC, the API Inspector.  Think of it like an API Sniffer.  Any config you do once through the GUI, you can capture the exact JSON config via the Inspector.

I am among the first to tell you that I suck at JSON and XML formatting, but I don't need to care about that when I can just copy-paste it from the inspector. 

From the APIC GUI, in the upper right, click the gear icon and launch the API inspector.  Some tips (you can see me use them in the image below) are to filter by POST, otherwise you will see all your 100s of GETs too.

See below...I just made a new tenant and VRF.  I can then copy that into my aci_rest task, and even use {{ jinja2 }} substitution to make as many tenants as I want with unique names and values. 

[Sig Nine]

Hi, joezersk.

Thanks for your kindness.

Yes, the non-existent functionality of the Ansible module makes use of the aci_rest module. However, as aci_rest is not very convenient, I will create my own required module.

Thank you for the introduction of API Inspector. I also use API Inspector and Visore in some cases.

Your kindness is helpful to the community!

Regards,

[joezersk]

I admire that you have the skill to write your own modules.  I do not have this skill.  You ought to also consider posting them publicly with Ansible.

I do have one minor point to add about working with aci_rest.  I agree that when you have a long, complicated body of JSON config, the playbook looks very ugly.  There is an option with aci_rest to point to an external file where the JSON/XML code is.  That way your playbooks stay neat and compact and your code is referenced elsewhere.

Good luck!

[Sig Nine]

Hi, joezersk.

I have registered several Ansible Modules for ACI in the past.

Thanks for the advice on the aci_rest module as well. I will make use of it.

Regards,