08-17-2020 09:40 PM
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 !
Solved! Go to Solution.
08-20-2020 03:06 AM
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!
08-20-2020 03:06 AM
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!
08-21-2020 06:19 AM
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,
08-21-2020 07:19 AM
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.
08-21-2020 01:39 PM
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,
08-24-2020 11:38 PM
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!
08-25-2020 12:01 AM
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,
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