One important concept to understand from the ACI object model tree (MIT) is the distinction between
what is a class
and what is a dn
. Let's take a look at this
from a couple of different examples.
In the last example, you did a query into the APIC to list the endpoints that the fabric
has learned. The object that contains this information in the fabric is called fvCEp
. If
you wanted to find out all the endpoints in the fabric, you would ask the APIC to list you
all the objects of type fvCEp
. You can do the for many different object types.
fvTenant
fvAp
fvAEPg
fvBD
fvSubnet
In the tree of objects that is ACI, you would see this as follows:
When you do a class
query into the fabric you are asking the fabric to
provide all the objects that are of the type you are requesting. Therefore, if you are to
query the ACI fabric for the class
of type fvTenant
then
the query would return all the objects of type fvTenant
:
Let's use this knowledge to create a request to the API with the following URL:
https://10.0.226.41/api/node/class/fvTenant.json
As you can see in the block of code above, this browser made a request to the APIC to the class
fvTenant
and the APIC responded with all the objects that match that class.
This of course is telling it to get all the tenants configured.
The APIC also allows for filters which can be used to trim down the results and simplify
any code you are writting. One of the available URL parameters to make the query is called
query-target-filter
. This can be used to filter on attributes of the objects.
Let's use this knowledge to create a request to the API with the following URL:
https://10.0.226.41/api/node/class/fvTenant.json?query-target-filter=eq(fvTenant.name,"aciproglab04")
And now you can see that the APIC responded only with the object that matched the filter wich in this case is the tenant for this lab pod. Filters are very powerful when doing class queries. When you think about searching for endpoints in the fabric, this capability would allow flexibility that would reduce the
So as you have seen we are using in the URL a call to the class level. What if you just want to hit a specific object? Then you will use the MO level.
{http | https}://host [:port] /api/mo/dn. {json | xml} [?options]
{http | https}://host [:port] /api/class/className. {json | xml} [?options]
While the preceding examples use /api/mo and /api/class in the URI string, the APIC UI and Visore also use the /api/node/mo and /api/node/class syntax in the URI string. Both formats are valid and are used interchangeably.
When you would want to query the fabric to retrieve a specific object then the focus moves to requesting the specific DN via the URL request. Using the same example as we did before, we can invoke the specific DN of this pod tenant.
Each object in the tree has a specific DN or a relation to a specific DN. For the tenant that we
have been testing the dn would be uni/tn-aciproglab04
. So the
URL to request this would be:
https://10.0.226.41/api/mo/uni/tn-aciproglab04.json
One thing you may have noticed and wondering is, why is the tenant so short? The reason is because this request is asking the fabric to return a specific object on the tree as we see in the diagram above. If you would want to get all the data from a specific point in the tree and below you have to tell the APIC controller that you want to get what is known is the subtree.
The previous diagram attempts to depict this in a simple way. A tenant configuration with L3 Outs,
different Application profiles could be enourmous. So how do we query this? The parameter
to pass in the URL would be rsp-subtree=children
. Let's give that a try
https://10.0.226.41/api/mo/uni/tn-aciproglab04.json?rsp-subtree=children
And as you can see now the whole tenant configuration is displayed.
One trick that is done to help with working with ACI is to request of the fabric to only send back the parameters
of the objects that are configured. This simplifies the structure of the data returning to be more correlated with
what the user has configured. This extra parameter is called rsp-subtree=modified
.
https://10.0.226.41/api/mo/uni/tn-aciproglab04.json?rsp-subtree=children&rsp-subtree=modified
You can compare the two separate responses done above. One that has all the chidren objects and parameters and the second that is requesting only the ones that have been modified. This is an easy way to catch all the changes made in the fabric configuration.