[Edit: I also made a video that explains some of this more clearly.]

You really could be forgiven if you thought that Cisco’s ACI moquery command was an acronym for Mysterious Obscure query. Read on and I’ll try and take some of the mystery and obscurity out of Cisco’s Managed Object query.

The final outcome will be that you will be equipped with the knowledge to write a script you can use to find what EPGs are linked to a particular Interface Policy Group. And to be able to adapt my script to suit your needs.

On the way, I’ll explain:

• What is moquery? Why would I use it?
• How to construct a simple query
• Coming to terms with classes and distinguished names
• Come and meet the family
• The rest is up to REST
• Putting moquery to work
• Appendix: Some geeky background on moquery

---

What is moquery? Why would I use it?

If you didn’t already know that moquery was a command line utility for  the Cisco ACI APIC, then you probably wouldn’t be reading this.

And in spite of my cynical introduction, you’ve also probably heard the term managed object, and know that ACI stores information using a Management Information Model (MIM), which can be represented in a hierarchical management information tree (MIT).

moquery is used to extract information from the MIM/MIT and display it on the console

There a lot of good reasons to NOT use moquery – Cisco ACI has a reasonably good set of show commands that allow detailed troubleshooting, not to mention the troubleshooting facilities available in the APIC GUI, and there is a far more friendly GUI equivalent to moquery called visore – and you can access that by right-clicking on any object and choosing Open in Object Store Browser.

But there will be times when you’d like to get some information but can’t just get it from the CLI or GUI, like the person why asked the Cisco Community Forum

How can I list all the EPGs that are associated to a particular Leaf Interface Policy Group on the ACI Fabric?

Or maybe you actually want to build a customised view using the APIC APIs, and need to explore the MIT.

For me, I started exploring moquery because I wanted to get a better understanding of the MIM/MIT.

These are all great cases to use moquery.

---

How to construct a simple query

You already knew that moquery is a command, but like many Unix commands, it is pretty useless without some parameters. Here’s a command to list all your tenants.

moquery -c fvTenant

The problem is, the output of the command is copious and contains fields that you don’t necessarily want. You can fix that to some degree in one of two ways

1. use the -o table option (which tabulates the most important fields)
2. use egrep to filter the output.

So try these as variations:

moquery -c fvTenant -o table
moquery -c fvTenant | egrep "^name "

The first ignores irrelevant fields like modTs (timestamp showing when the object was last modified) but includes some rubbish as well.  The second gives you more control but requires a better understanding of how to parse results using egrep.  (BTW – you could have used moquery -c fvTenant | awk '{if ($1=="name") print $3}' if you wanted to make it really complicated)

From here on, I’ll promise to keep the parsing via grep, egrep, awk or even sed as simple as possible.  But, in time you will see that it is necessary to get the most out of moquery.

Before I digress too far from the topic, I want to revisit the -c option I used above.  The example I used moquery -c fvTenant listed ALL tenants.  To see the details of just a particular tenant (say the mgmt tenant), I would have used the -d option, like:

moquery -d uni/tn-mgmt

which is a pretty boring output.

But to get anything more out of moquery, you’ll have to get used to a couple of concepts. In particular, classes and distinguished names (DNs). And then you’ll have to learn some of those classes and DNs so you can query them.

---

Coming to terms with classes and distinguished names

I’ve already mentioned that there are two key ways to use moquery.  You can use moquery to query the MIM about a specific distinguished name or to query every instance of a particular class.  Soon you’ll see that you can combine the two to query the MIM about all the instances of a particular class that exist for a particular DN.

Every device, node, interface, policy, endpoint or even user is represented by an object in ACI. Or more precisely, a managed object and will occupy a place in the Managed Object Tree (MIT). There are physical entities (switches, interfaces,…), logical entities (policy groups, profiles, vlan pools…) and even relationships, which are a little harder to explain.

Key Point:

Every object is an instance of a class, and has a unique distinguished name.

That statement is important. If you haven’t memorised it, keep re-reading it until you can.

For example, a tenant called, say Tenant1 has a relative distinguished name of tn‑Tenant1 and is an instance of the class fvTenant.

And just how did I pull those little gems of wisdom [the tn- prefix and fvTenant] from my brain?

How to find the distinguished name (DN) of an object

If you know how to find a particular object in the GUI, you can find its DN simply by looking at the URL of the page that shows you the object.

Everything to the right of the vertical bar | character in the URL defines the distinguished name.  Like a directory structure, the DN can be several levels deep. Remember, we are talking about a Managed Object TREE after all.

Note:

The distinguished name is made up of a series of relative names separated by /. So the relative name ap-2Tier_AP in the URL above may appear in another DN, such as uni/tn-Tenant2/ap-2Tier_AP. In other words, different objects can have the same RN (relative name) but the whole DN (distinguished name) will always define a single object.

Armed with a DN, you can now query the MIT using moquery with the -d or –dn options:

admin@apic1:~>  moquery --dn uni/tn-Tenant1
Total Objects shown: 1

# fv.Tenant
name         : Tenant1
<...omitted...>
dn           : uni/tn-Tenant1
<...omitted...>
rn           : tn-Tenant1
status       :
uid          : 15374

and

admin@apic1:~> moquery --dn uni/tn-Tenant1/ap-2Tier_AP/epg-AppServers_EPG
Total Objects shown: 1

# fv.AEPg
name                 : AppServers_EPG
<...omitted...>
dn                   : uni/tn-Tenant1/ap-2Tier_AP/epg-AppServers_EPG
<...omitted...>
rn                   : epg-AppServers_EPG
s<...omitted...>
uid                  : 15374

Note:

Oh – that’s curious. Did you notice that both uni/tn‑Tenant1 and uni/tn‑Tenant1/ap‑2Tier_AP/epg‑AppServers_EPG have the same uid? That tells me that both objects were created by the same user. In fact, uid 15374 is always the user admin.

But remember, querying a DN is only going to yield a single result – after all, a DN is defined as the name that distinguishes an object, and is therefore unique. Ergo one result per DN.

Which brings us to a great point to discuss classes

How to find the class of an object

If an object is an instance of a class, there must be a way of finding out which class defines the attributes of an object.   Once you have found the class of an object, you can easily find all instances of that class using moquery. In ACI, there are several strategies to find the class of an object.

Probably the easiest way is to again start with the GUI, where you can right-click on an object and select Open in Object Store Browser.  This will show you the object with its class name shown clearly at the top. Here’s an example using uni/tn‑Tenant1

If you’ve noticed that the class name (fvTenant) looks kind of similar to the line…

# fv.Tenant

…that came from the moquery on the DN of Tenant1, you can guess the second method.  Just remove the dot between the fv and Tenant and you have it.

The third method is rather obscure, and you’ll need your grandma’s glasses to be able to read it, but if you (in the ACI GUI) click the Settings cog wheel in the top RH corner of the screen and select Show Debug Info, you will see some information in the browser footer in print about 2pt font. Let me magnify it a bit and point you to what you are looking for. Note you can also see the DN here, but no point in straining your eyes when the same information is in the URL above.

So great. Now you have a class name. How is that useful?  Well, before, when you had the DN of a single object, you could use moquery to query that single object. Now you can use the ‑c or ‑‑klass option¹  to get all objects of a class.  So, a command of  moquery ‑c fvTenant will show ALL tenants (like the very first example I gave above). My example below uses egrep to show only lines that begin with # OR begin with name followed by <space> OR begin with dn OR begin with uid

admin@apic1:~> moquery -c fvTenant | egrep "^#|^name\ |^dn|^uid"
# fv.Tenant
name         : Tenant5
dn           : uni/tn-Tenant5
uid          : 15374
# fv.Tenant
name         : common
dn           : uni/tn-common
uid          : 0
# fv.Tenant
name         : Tenant3
dn           : uni/tn-Tenant3
uid          : 15374
# fv.Tenant
name         : mgmt
dn           : uni/tn-mgmt
uid          : 0
# fv.Tenant
name         : infra
dn           : uni/tn-infra
uid          : 0

The words listed on the left-hand side on the output of moquery (like name and dn) are the attributes of a given object.  The attributes of an object are be defined by the class of an object, and that class may even inherit some of those attributes from a parent class, in which case the objects of that class will also inherit attributes from a parent object.  If that sounds like gobbledygook, don’t worry, there are more practical examples later.

For now, make sure you are familiar with the key concepts that: You can use moquery to query a single object You can use moquery to query return a list of every object of a given class

If I were teaching a course right now, I’d be asking

• Which moquery option would you use to return a single instance of an object?
  Select this line to see answer: moquery -d
• Which moquery option would you use to return a all instances of a class?
  Select this line to see answer: moquery -c
• Is fvAEPg an example of a Distinguished Name (DN), an object or a class?
  Select this line to see answer: fvAEPg is an example of a class

---

Come and meet the family

In the previous section, I showed examples of querying a DN and a class. That’s about as simple as it gets as far as the construction of the syntax goes, but to actually work with ACI you are going to have to learn some key classes and the structure of some DNs.

Since the objects are arranged in a tree, every object has a class and a parent class (except topRoot), and therefore many classes have child classes, which means it is very much a family affair.

So come and meet the family! Learn these to begin with:

Class/DN	Description
topRoot	you probably won’t ever use it, but it is the only class that doesn’t have a parent class.
infraInfra	wierd name, but is the parent class for all objects in the Access Policy Chain
fvTenant	the parent class that defines all Tenant attributes
/uni/tn-tenantName	The format of the DN of tenant tenantName
fvAEPg	the parent class for Application End Point Groups. Not to be confused with fvEPg
/uni/tn-tenantName/ap-appProfileName/epg-epgName	The format of the DN of epg epgName within Application Profile appProfileName
fvEPg	an abstract class that includes all varieties of EPGs, including fvAEPg, l3extInstP (L3 EPG), and possibly others you didn’t even know about.

So from the previous section you should be comfortable constructing a query to list all instances of the above classes.  If you practice this now on the classes listed above, you’ll notice that some of these classes have many instances – for instance, a query of …

moquery -c fvEPg

… will list ALL EPGs across all tenants.

But say you wanted to list just the EPGs of one particular tenant?

Well, to do that, you can start combining ‑c and ‑d options, so the following query will list the EPGs for tenant Tenant5

moquery -c fvEPg -d /uni/tn-Tenant5

Get the idea?

Now, if you understand the tree structure of a tenant, you can take this concept a little further.  What do you think the following would list?

moquery -c fvBD -d /uni/tn-Tenant5

And if the above query revealed that the tenant named Tenant5 had two Bridge Domains called App_BD and Web_BD, can you work out what the difference between the following two queries would show?

moquery -c fvSubnet -d /uni/tn-Tenant5/BD-App_BD
moquery -c fvSubnet -d /uni/tn-Tenant5

If you wanted to see what subnet had been configured in the same tenant on an EPG called AppServers_EPG within an Application Profile called 2Tier_AP, do you think you could construct the query?  I’ll give you the start below. [Select the whole line to reveal the answer]

moquery -c fvSubnet -d /uni/tn-Tenant5/ap-2Tier_AP/epg-AppServers_EPG

So far, I’ve kept you within the bounds of the fabric virtualisation space of the tenant, where many objects are child objects of a Tenant, so when you look at a diagram of a Tenant, it’s easy to see that VRFs, Bridge Domains and Application Profiles are child objects of a Tenant, and EPGs are child objects of an Application Profile.

Looking at the diagram, it’s not so hard to relate the path of the DN of say an EPG (like /uni/tn‑Tenant5/ap‑2Tier_AP/epg‑AppServers_EPG) to the object model. It’s also not hard to see a pattern in the names of the classes that sit in the fabric virtualisation space of the tenant.

Things get a bit more interesting though when you start querying the Access Policy Chain, which lives under the parent object infraInfra.  But a query of the infraInfra class is very boring. I won’t even waste space here showing you – try it yourself. moquery ‑c infraInfra

Unlike where you might have many tenant objects, there is only one infraInfra object. What you need to learn if you want to query the Access Policy Chain, is the equivalent classes for the stucture you are probably already familiar with:

If you are already familiar with the diagram above, all you need to do now is learn the classes of each of these elements of the Access Policy Chain, and the format of the DN of each instance. But there is a twist…

Notice that in the diagram there are very few parent-child relationships – most of the relationships are links – and the twist is that the links are also objects. And important ones too.

[Note: I’ve taken a bit of licence with the diagram. The relationship arrows are actually child objects of the object they point away from.  For the official diagrams, refer to the APIC Management Information Model Reference website]

Time Out!  Are you confident that you could use the diagram above to produce a query to: List all Physical Domains for an ACI fabric? moquery -c physDomP List all Interface Selectors for the Interface Profile with DN=uni/infra/accportprof-T5:L102_IntProf ? moquery -c infraHPortS -d uni/infra/accportprof-T5:L102_IntProf [Select the blank spaces to see the answers]

OK. If you could not answer the questions above, spend some more time re-reading and experimenting at the command line before continuing.

Here’s a problem for you.

Assume you have figured out that you can list all Interface Selectors for the Interface Profile with DN=uni/infra/accportprof-T5:L102_IntProf  by using a query of:

moquery -c infraHPortS -d uni/infra/accportprof-T5:L102_IntProf

How do you find what Interface Policy Group each Interface Selector is linked to? 

To answer that question, you need to know that the relationship between the Interface Selector and the Interface Policy Group is stored in the class infraRsAccBaseGrp as shown in the diagram.

Just query the DN asking for instances of that class to be listed.  The query is almost the same as above, but with at different class-  infraRsAccBaseGrp

admin@apic1:~> moquery -c infraRsAccBaseGrp -d uni/infra/accportprof-T5:L102_IntProf
Total Objects shown: 1

# infra.RsAccBaseGrp
<...omitted...>
dn           : uni/infra/accportprof-T5:L102_IntProf/hports-1:20-typ-range/rsaccBaseGrp
<...omitted...>
rn           : rsaccBaseGrp
<...omitted...>
tCl          : infraAccPortGrp
tDn          : uni/infra/funcprof/accportgrp-T5:SA.Host_APPG
<...omitted...>

This presents you with a number of new concepts

Firstly, the class itself has a particular naming structure. The letters Rs in infraRsAccBaseGrp indicate that this class is a Relationship source – so you are querying the Interface Profile T5:L102_IntProf for it Relationship sources for “AccBaseGrp” – in this case “AccBaseGrp” could be either of class infraAccPortGrp or infraAccBndlGrp

And the answer to exactly which object is found for each “AccBaseGrp” is found in the tDn (=target Distinguished name) field, and in the example above that DN is an instance of the class infraAccPortGrp as shown be the value of the tCl (=target Class).  Here they are again in case you too lazy to look back.

tCl : infraAccPortGrp 
tDn : uni/infra/funcprof/accportgrp-T5:SA.Host_APPG

That is a lot of information to digest. And I didn’t even mention that there is another named relationship class called infraRtAccBaseGrp (where the Rt=Relationship target) that is a child object class of  infraAccPortGrp pointing back to the interface selector. Nor did I mention that the Interface Selector has child objects that define the actual blocks of ports that are defined for each Interface Selector!

Must be time for another diagram to encapsulate all that.

Now I have to admit that I’ve skipped one little detail while taking you through the journey from infraHPortS to infraAccPortGrp

Recall I said above

“you need to know that the relationship between the Interface Selector and the Interface Policy Group is stored in the class infraRsAccBaseGrp as shown in the diagram. “

If you are astute, you’d be asking “How did I know that the class was called infraRsAccBaseGrp ?”

If I have a starting point of class of infraHPortS  then there must be some way of querying that class to reveal its child objects, including infraRsBaseGrp (and for that matter, infaPortBlk as well).

The query will start with moquery -c infraHPortS – but the rest of the query, well…, the rest of the query is up to the Cisco REST API.

---

The rest is up to REST

If you have issued a command of moquery --help you would have seen that one of the options is described as…

  -x [OPTIONS [OPTIONS ...]], --options [OPTIONS [OPTIONS ...]]
                        Extra options to the query

which is not very helpful.

But those -x options are the key to getting the most out of moquery.  But to get a description of what those options are, you will have to go to some documentation for the REpresentational State Transfer (REST) documentation for ACI.

In particular, you’ll want to know about these options:

Filter Type	Syntax	Description
query‑target	{self | children | subtree}	Define the scope of a query
rsp‑subtree	{no | children | full}	Specifies child object level included in the response

So back to the problem – “How did I know that the class was called infraRsAccBaseGrp ?”

I used a query of

admin@apic1:~> moquery -c infraHPortS -x query-target=children
Total Objects shown: 2

# infra.RsAccBaseGrp
<...omitted...>
  dn           : uni/infra/accportprof-T5:L102_IntProf/hports-1:20-typ-range/rsaccBaseGrp
<...omitted...>
  rn           : rsaccBaseGrp
<...omitted...>
  tCl          : infraAccPortGrp
  tDn          : uni/infra/funcprof/accportgrp-T5:SA.Host_APPG
<...omitted...>
# infra.PortBlk
  name         : block
<...omitted...>
  dn           : uni/infra/accportprof-T5:L102_IntProf/hports-1:20-typ-range/portblk-block
<...omitted...>
  rn           : portblk-block
<...omitted...>

and found the child object classes listed – infra.RsAccBaseGrp and infra.PortBlk. All I had to do was remove the separating period.

Another approach would have been to use the ‑x query‑target=subtree, or ‑x rsp‑subtree=children options, but these options also show the parent class as well.  In theory, I should have also been able to use the same options on a DN, but unfortunately moquery gives only one result when using these options with distinguished names. (Probably due to a bug)

Key Point:

Use the -x query-target=children option to find child classes of a class.

Exercise:

If you have a configured APIC you can query, you should try starting at a Switch Profile (moquery -c infraNodeP) and work your way through until you have mapped the entire access policy chain. (And if you DON’T have access to a configured APIC, book yourself a session with the ACI Simulator at https://devnetsandbox.cisco.com – login required)

Here’s one example of how I put moquery to work, similar to the challenge I’ve given you above.

---

Putting moquery to work

I mentioned earlier that I had been challenged with a question in the Cisco Community Forum

How can I list all the EPGs that are associated to a particular Leaf Interface Policy Group on the ACI Fabric?

Before I show you how I solved the problem, here’s a picture of what was being asked. I’ve duplicated the diagram below with the class names to make it easier for you to follow my logic.

And now the details:

Task 1:

To begin, I needed to find the child object that showed me which AAEP the Interface Policy Group is linked to.

Similar to my previous example, I used moquery to query the particular policy group and added the -x query-target=children option. On my system, Interface Policy Group names have the format TenantID:Name_APPG (if it is an Access Port Policy Group) or TenantID:Leaves:slot:port_VPCIPG) if it is a VPC Interface Policy Group².  In my case I used an Access Port Policy Group called T5:SA.Host_APPG, and I looked at the URL of the page that showed me the object to find the DN.

The URL was #c:d|uni/infra/funcprof/accportgrp-T5:SA.Host_APPG so my moquery to find the class of the child object that links was:

apic1# moquery -d  uni/infra/funcprof/accportgrp-T5:SA.Host_APPG -x query-target=children
Total Objects shown: 1

# infra.RsAttEntP
annotation     :
childAction    :
dn             : uni/infra/funcprof/rsattEntP
extMngdBy      :
forceResolve   : yes
isUsingConnSel : no
lcOwn          : local
modTs          : 2020-03-27T13:21:41.043
monPolDn       : uni/fabric/monfab-default
rType          : mo
rn             : rsattEntP
state          : formed
stateQual      : none
status         :
tCl            : infraAttEntityP
tDn            : uni/infra/attentp-T5:HostLinks_AAEP
tType          : mo
uid            : 15374

[About 20+ MORE object should have appeared. I was just lucky that
the one that did appear was the one I wanted]

Now to be honest, I was expecting many more child objects, but due to what I believe is a bug in moquery³, I only got one – and by sheer luck, it happened to be the correct one.  If this had have failed, I would have had to resort to querying the class
moquery -c infraAccPortGrp -x query-target=children

Armed with the information that the class of the link to the AAEP is infraRsAttEntP, I can now create a more specific query to give me ONLY the child object that point to the AAEP, and not the 20+ I SHOULD have got from the above query.  I also started by storing the name of the Interface Policy Group in a variable called ipgName so that the process can be more repeatable.

admin@apic1:~> ipgName=T5:SA.Host_APPG
admin@apic1:~> moquery -d  uni/infra/funcprof/accportgrp-$ipgName -c infraRsAttEntP
Total Objects shown: 1

# infra.RsAttEntP
annotation     :
childAction    :
dn             : uni/infra/funcprof/accportgrp-T5:SA.Host_APPG/rsattEntP
extMngdBy      :
forceResolve   : yes
isUsingConnSel : no
lcOwn          : local
modTs          : 2020-03-27T13:21:41.043
monPolDn       : uni/fabric/monfab-default
rType          : mo
rn             : rsattEntP
state          : formed
stateQual      : none
status         :
tCl            : infraAttEntityP
tDn            : uni/infra/attentp-T5:HostLinks_AAEP
tType          : mo
uid            : 15374

Great! I’d found the target DN for the AAEP

Time Out!  I’m sure you see that the output of the last two commands is the same.  The second one is specific to the precise class I’m interested in. The first one SHOULD have produced a lot more output and would have been a lot harder to parse. And should Cisco ever fix the bug, it will be different.

The final step of this task then is to keep that target DN of the AAEP in a variable.  I used awk to extract the string uni/infra/attentp-T5:HostLinks_AAEP and store it in a variable I named aaepDn⁴

admin@apic1:~> aaepDn=$(moquery -d  uni/infra/funcprof/accportgrp-$ipgName -c infraRsAttEntP | awk '{if ($1=="tDn") print $3}')
admin@apic1:~> echo $aaepDn
uni/infra/attentp-T5:HostLinks_AAEP

Task 2:

Next, I needed to find the child object that shows me which Domains the AAEP is linked to.  Using the same logic, I found the class of the object that links the AAEP to the Domains is infraRsDomP  – only this time I was not so lucky as to have the query revealing this information from the DN work.  I.e. I SHOULD have been able to use moquery ‑d $aaepDn ‑x query‑target=children but instead had to use moquery ‑c infraAttEntityP ‑x query‑target=children

Again, following the same logic, I created a variable called domainList to store the output of the query on infraRsDomP, only this time, life was a little more difficult because an AAEP can be linked to multiple Domains, and on my system that indeed was the case.  That meant that I could process the list of Domains more easily as an array.

Here’s the query I used to do that

admin@apic1:~> declare -a domainList=($(moquery -d $aaepDn -c infraRsDomP | awk '{if ($1=="tDn") print $3}'))
admin@apic1:~> for i in "${domainList[@]}"; do echo $i; done
uni/phys-T5:MappedVLANs_PhysDom
uni/vmmp-VMware/dom-T5:vC_VMM.Dom

Task 3:

Finally, I needed to find the child object that shows me which EPGs the Domains are linked to.  Using the same logic, (i.e., running moquery ‑c physDomP ‑x query‑target=children) I found the class of the object that links a Domain to the EPG is  infraRtDomAtt  by observing the output!

This time of course the process is a bit trickier, because I have to process multiple Domains – and again the result might be multiple EPGs.  I used a simple for loop to process the Domain list, but came up with a small cosmetic problem in the output.  If it doesn’t worry you – you’re done!

admin@apic1:~> for i in "${domainList[@]}"; do moquery -d $i -c infraRtDomAtt | awk '{if ($1=="tDn") print $3}'; done
uni/tn-Tenant5/ap-2Tier_AP/epg-AppServers_EPG
uni/tn-Tenant5/ap-2Tier_AP/epg-WebServers_EPG
uni/tn-Tenant5/ap-2Tier_AP/epg-AppServers_EPG
uni/tn-Tenant5/ap-2Tier_AP/epg-WebServers_EPG

Note that some of the EPGs are repeated? Since your APIC bash shell has the normal linux command set, I decided to tidy up using Linux’s sort and uniq utilities.

Here’s version #2 of the above:

admin@apic1:~> declare -a epgList=($(for i in "${domainList[@]}"; do moquery -d $i -c infraRtDomAtt | awk '{if ($1=="tDn") print $3}'; done | sort | uniq))
admin@apic1:~> for i in "${epgList[@]}"; do echo $i; done
uni/tn-Tenant5/ap-2Tier_AP/epg-AppServers_EPG
uni/tn-Tenant5/ap-2Tier_AP/epg-WebServers_EPG

Task 4: Bonus task

With all that work put into creating the list, you’ll want to be able to use it again. Since the APIC runs Linux, you can turn the above into a bash script that will take any Interface Policy Group name as a parameter and produce a list of EPGs that use that Policy Group.  The script below is very basic, with virtually no parameter parsing, but if you cut and paste it to your APIC, you’ll be able to run it any time you want (until you wipe the APIC).  It also checks to see if the Policy Group is a VPC or PC, whereas my example above only checked for an Access Port Policy Group. The script has some other limitations too which I’ll list in this footnote.⁵

Here’s the script:

#!/bin/bash
if [ "$1" == "" ] ; then
    echo "Usage: $0 InterfacePolicyGroupName"
    exit 1
else
    ipgName=$1
fi
aaepDn=$(moquery -d uni/infra/funcprof/accportgrp-$ipgName -c infraRsAttEntP | awk '{if ($1=="tDn") print $3}')
if [ "$aaepDn" == "" ] ; then
    aaepDn=$(moquery -d uni/infra/funcprof/accbundle-$ipgName -c infraRsAttEntP | awk '{if ($1=="tDn") print $3}')
    if [ "$aaepDn" == "" ] ; then
        echo "Interface Policy Group $ipgName not found"
        exit 1
    fi
fi
declare -a domainList=($(moquery -d $aaepDn -c infraRsDomP | awk '{if ($1=="tDn") print $3}'))
declare -a epgList=($(for i in "${domainList[@]}"; do moquery -d $i -c infraRtDomAtt | awk '{if ($1=="tDn") print $3}'; done | sort | uniq))
echo "Tenant               Application Profile  EPG"
echo "-------------------------------------------------------------------------"
for i in "${epgList[@]}"
do
    declare -a j=($(echo $i | sed 's:uni/tn-::; s:/ap-: :; s:/epg-: :'))
    printf "%-20s %-20s %-20s" ${j[0]} ${j[1]} ${j[2]}
    echo ""
done

To create the script with a name of say epgsforipg.sh , prepare yourself by making sure you have the entire script from above copied into your paste buffer, then start at the apic1# prompt, and enter the emphasised commands below

apic1# bash
admin@apic1:~> touch epgsforipg.sh
admin@apic1:~> chmod +x epgsforipg.sh
admin@apic1:~> vim epgsforipg.sh

When the VIM editor opens, follow these steps precisely

1. Press the letter i              [You will see — INSERT — in the bottom LH corner]
2. Paste the buffer
3. Press the <Esc> key      [– INSERT — will disappear]
4. Press : [the <colon> key]   [A : prompt will appear in the bottom LH corner]
5. Type wq
6. Press <Enter>

Here’s the output of a test run from my system:

admin@apic1:~> ./epgsforipg.sh T5:SA.Host_APPG
Tenant               Application Profile  EPG
-------------------------------------------------------------------------
Tenant5              2Tier_AP             AppServers_EPG
Tenant5              2Tier_AP             WebServers_EPG

Enjoy your moquerying – I’ve added an Appendix with some background stuff you may find interesting.

RedNectar

---

Appendix: Some geeky background on moquery

Did you know that moquery is actually NOT an NX-OS ACI command, but operates from the underlying unix os?

This can be easily seen from the bash prompt, or “Object Model CLI” as it is officially known as.

apic1# which moquery
moquery: aliased to _exec_legacy_cmd "/controller/bin/moquery" "$@"
apic1# bash
admin@apic1:~> which moquery
/controller/bin/moquery
admin@apic1:~>

In fact, ACI didn’t have a NX-OS command line until version 1.2, which his why you will not find any reference to moqurey in the Cisco APIC NX-OS Style Command-Line Interface Configuration Guide.  To get the (totally inadequate) official guide to moquery, you have to find the Cisco APIC Object Model Command-Line Interface User Guide, which has not been updated since ACI v1.1.

The upshot of this is that moquery is not restricted to just the APIC. You can run moquery from:

• The APIC NS-OX prompt
• The APIC bash prompt
• The bash prompt on leaves and spines

Of course, when used on Spines and Leaves, you will only have access to the objects that are configured on the said leaf or spine.

Another interesting titbit is that the moquery program is written in python – you can see it right there on the APIC. Just type (from the bash prompt) cat $(which moquery) to see the source code.

More Mojo, mobrowser, modelete …

There are other mo commands on the APIC too.  Although, like moquery, the documentation is a bit sparse.  There is

mo utility	Description
mobrowser	My favourtie. Try it.
moconfig	Usually in the form moconfig commit to commit changes made by other commands
mocreate	Create an object. Better know what you are doing. Must follow with moconfig commit
modelete	Also requires moconfig commit
moprint	You can use this to turn the output files displayed using the cat command into json or xml
moquery	You know this one now
moset	You can set MO values directly
mostats	Set up periodic sampling

---

If documentation for the mo-utilities is sparse, the opposite is true for the Manage Information Model itself. You can browse the docs for the entire model for wany version of sotware at https://developer.cisco.com/site/apic-mim-ref-api/ and you APIC has a local copy for the installed version, although it can loose diagram at times. You can reach your local copy of course from the APIC GUI by selecting the cog-wheel settings icon and navigating to Documentation > API Documentation.