To this point you have only read objects from the fabric. In this section you are going to configure some network elements using this application framework. Due to limitations with the amount of equipment in the lab we are not going to configure this end to end. Yet it will be sufficient to give you an idea of how this would work if you decided to build such an application.
Some of the components of this section we have already coded due to time limitations. You are welcome to look at the code and use it as you would like. Our focus is going to show you how to add into this application the objects and then create them in APIC.
As we have shown, each configuration block in ACI is based on JSON or XML objects that are pushed
into the Management Information Tree (MIT). Each of these objects needs to be placed in their proper
place in the tree. For example, a bridge domain distinguished name is going to be under
a tenant. So for this reason it would look similar to uni/tn-aciproglab04/BD-[name]
You are going to create the structure of these objects in JavaScript with the addition that you will insert variables to the structure that will be passed from the web form to get the proper values to insert into the fabric. Let's quickly look at the object structure of an ACI bridge domain that I have trimmed down to simplify.
{
"fvBD": {
"attributes": {
"annotation": "",
"arpFlood": "no",
"descr": "POD04 Database Bridge Domain",
"dn": "uni/tn-aciproglab04/BD-database",
"mac": "00:22:BD:F8:19:FF",
"name": "",
"unicastRoute": "yes",
"unkMacUcastAct": "proxy",
"unkMcastAct": "flood",
},
"children": [
{
"fvSubnet": {
"attributes": {
"annotation": "",
"descr": "POD04 subnet for Database Bridge Domain",
"ip": "10.100.100.1/24",
"name": "aciproglab04_subnet1",
"scope": "private",
}
}
},
{
"fvRsCtx": {
"attributes": {
"annotation": "",
"tnFvCtxName": "POD04_vrf_1"
}
}
},
]
}
}
When you look at the ACI GUI and you create a bridge domain, an object similar to this is pushed from the JavaScript code that runs the ACI GUI and creates the object in the fabric. You are now going to create a series of JavaScript functions that will each have the capacity to build an object in the fabric.
The bridge domain is an interesting object as it has various relationships that we have to take into consideration when building the object. In the editor we have created for you a file called aci_objects.js. This is where you will be adding the directories.
In the editor open this file and start coding the JavaScript function as shown before.
function bridge_domain_object(tenant_name, vrf_name, bd_name, bd_subnet, status){
}
This function will accept:
These are the key parts that we need to know and the code itself will build the relationships based on this information.
To accomplish this, you will build the structure of the object and inject the variables into the proper locations and return that to the calling code. First you will build the attributes for the bridge domain itself.
function bridge_domain_object(tenant_name, vrf_name, bd_name, bd_subnet, status){
return {
"fvBD": {
"attributes": {
"name": bd_name,
"dn": "uni/tn-" + tenant_name + "/BD-" + bd_name,
"status": status
}
}
}
}
Now you are going to add the children for the fvBD object. In this case you will
add two specific children. The first is the fvSubnet child for the subnet definition
and the second will be the relationship back to the VRF that we will use. This will be provided
also via the interface that is built as the user will select an available VRF. On line, do ont forget to add the trailing comma.
function bridge_domain_object(tenant_name, vrf_name, bd_name, bd_subnet, status){
return {
"fvBD": {
"attributes": {
"name": bd_name,
"dn": "uni/tn-" + tenant_name + "/BD-" + bd_name,
"status": status,
},
"children": [
{
"fvSubnet": {
"attributes": {
"name": bd_name + "_subnet",
"descr": "POD subnet for " + bd_name,
"ip": bd_subnet,
"scope": "private",
"status": status
}
}
},{
"fvRsCtx": {
"attributes": {
"tnFvCtxName": vrf_name,
}
}
}
]
}
}
}
In the same file you will create a new function as follows:
function end_point_group(tenant_name, app_name, bd_name){
}
The primary relationship of an EPG is with an application profile and it's bridge domain. For the purpose of this example, we are going to name the EPG the same as the bridge domain such that it's a 1:1 relationship.
function end_point_group(tenant_name, app_name, bd_name, status){
return {
"fvAEPg": {
"attributes": {
"descr": "POD4" Database EPG",
"dn": "uni/tn-" + tenant_name + "/ap-" + app_name + "/epg-" + bd_name,
"name": bd_name,
"status": status,
}
}
}
}
Now you have to make some relationships via the children objects of the EPG. Do not forget the comman on line 39.
function end_point_group(tenant_name, app_name, bd_name, status){
return {
"fvAEPg": {
"attributes": {
"descr": "POD04 Database EPG",
"dn": "uni/tn-" + tenant_name + "/ap-" + app_name + "/epg-" + bd_name,
"name": bd_name,
"status": status,
},
"children": [
{
"fvRsBd": {
"attributes": {
"status": status,
"tnFvBDName": bd_name,
}
}
}
]
}
}
}