How to automate Switch Selector with REST API

[YanL]

We are building scripts to configure the basics when we bring a fabric online. Using API Inspector I can see data in the payload (in bold) that I don't understand how it's generated and online examples don't clarify. We are creating switch profiles and assigning switches with the Leaf Selectors in the GUI.

(GUI/Fabric/Access Policies/Switch Policies/Profiles/Leaf Profiles). Can we randomly assign a alphanumeric code in our REST API payload?

switch selector payload:

{"infraLeafS":{"attributes":{"dn":"uni/infra/nprof-Leaf_1031-1032_SwPro/leaves-Leaf_1031-1032_SwSel-typ-range","type":"range","name":"Leaf_1031-1032_SwSel","status":"created","rn":"leaves-Leaf_1031-1032_SwSel-typ-range"},"children":[{"infraNodeBlk":{"attributes":{"dn":"uni/infra/nprof-Leaf_1031-1032_SwPro/leaves-Leaf_1031-1032_SwSel-typ-range/nodeblk-45a7fc1b61510b7c","from_":"1031","to_":"1032","name":"45a7fc1b61510b7c","rn":"nodeblk-45a7fc1b61510b7c","status":"created"},"children":[]}}]}}

Cisco examples:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/rest_cfg/2_1_x/b_Cisco_APIC_REST_API_Configuration_Guide/b_Cisco_APIC_REST_API_Configuration_Guide_chapter_01101.html

[gmonroy]

Yan Lafrance,

    I have a few questions based on your payload:

1. Where in the GUI did we create the switch selector and its children policies? (any wizard used?)
   1. The reason I ask, as the dn (distinguished name) is built using the assigned "name" value which is why it exists in multiple attributes of the infraNodeBlk. 
   2. From what I can see in man lab, you can't actually specify a name for the infraNodeBlk via the GUI. For me, it named them "block1", "block2" and so on.
2. For your question around whether or not we can use "45a7fc1b61510b7c" as a name for an infraNodeBlk object within ACI, the answer is yes. I was able to manually test it with my example json below.

In summary:

To create a switch selector via the API (and the two children you showed), you can POST to the following URL:

• https://a.p.i.c/api/node/mo/.json   (or .xml depending on your payload)

and the following can be referenced as a "minimum required" payload:

{
	"infraNodeP": {
		"attributes": {
			"descr": "",
			"dn": "uni/infra/nprof-GMM-SwProfile101",
			"status": "created"
		},
		"children": [{
			"infraLeafS": {
				"attributes": {
					"name": "Leaf101-LeafSelector",
					"status": "created",
					"type": "range"
				},
				"children": [{
					"infraNodeBlk": {
						"attributes": {
							"status": "created",
							"from_": "101",
	                   		                "name": "45a7fc1b61510b7c",
							"to_": "101"
						}
					}
				}]
			}
		}]
	}
}

infraNodeP = Leaf Profile

infraLeafS = Leaf Selector

infraNodeBlk = Block (leaf ID selection)

-Gabriel

[YanL]

Thank you for the reply, we run version 3.0(2h)

1- I right click 'Leaf Profiles' and click 'Create Leaf Profile'. see att

         a- I name it something like Leaf_1033_SwPro

         b- I click the Leaf Selectors + sign

         c- I name it something like Leaf_1033_SwSel

         d- I click Blocks and put a check mark beside 1033 and click Update

         e- I click Next then Finish

2- If I skip step b, c and d and I right click an existing switch profile and click 'Create Switch Association' then the payload contains"block1", "block2" and so on.

3- I tried your code and yes it works but if I take into consideration 4 spines and 4 leafs in my basic setup that requires 24 of these "unique identifiers". Also I might end up with a multipod/multisite topology so do these "unique identifiers" need to be unique across multipods and multisites?

Leaf_1031_SwPro

Leaf_1032_SwPro

Leaf_1031-1032_SwPro

...

Spine_101_SwPro

Spine_102_SwPro

Spine_101-102_SwPro

...

My concern is how to deal with multiple Switch Selector creation?  Seems I would need a program to randomly generate those "unique identifiers. So far I've been impressed by the REST API but this time I'm a little lost? I wish I could leave it blank and let ACI assign them just like in the GUI or I use the "Create Switch Association" payload and go with "block1", "block2" and so on but I don't understand what determines if it starts at block1 or block2, it seems inconsistent when I look at API Inspector. Sometime it uses block1 and other times block2 with no reason I can figure out.

Example:

method: POST
url: https://{{apic}}/api/node/mo/uni/infra/nprof-Leaf_1033-1034_SwPro.json
payload{"infraNodeP":{"attributes":{"dn":"uni/infra/nprof-Leaf_1033-1034_SwPro","name":"Leaf_1033-1034_SwPro","rn":"nprof-Leaf_1033-1034_SwPro","status":"created,modified"},"children":[]}}
response: {"totalCount":"0","imdata":[]}
timestamp: 20:31:53 DEBUG
method: POST
url: https://{{apic}}/api/node/mo/uni/infra/nprof-Leaf_1033-1034_SwPro/leaves-Leaf_1033-1034_SwSel-typ-range.json
payload{"infraLeafS":{"attributes":{"dn":"uni/infra/nprof-Leaf_1033-1034_SwPro/leaves-Leaf_1033-1034_SwSel-typ-range","name":"Leaf_1033-1034_SwSel","rn":"leaves-Leaf_1033-1034_SwSel-typ-range","status":"created"},"children":[{"infraNodeBlk":{"attributes":{"dn":"uni/infra/nprof-Leaf_1033-1034_SwPro/leaves-Leaf_1033-1034_SwSel-typ-range/nodeblk-block2","from_":"1033","to_":"1034","name":"block2","rn":"nodeblk-block2","status":"created"},"children":[]}}]}}
response: {"totalCount":"0","imdata":[]}

[gmonroy · Accepted solution]

Yan Lafrance,

    I think I understand your confusion now, so let me attempt to address it.

The MO in question is of class infraNodeBlk (Node Block) which is a child of infraLeafS (Leaf selector). In your example you are concerned with the definition of the name attribute of infraNodeBlk, specifically that it was assigned the seemingly random value of "45a7fc1b61510b7c".

Your questions (I think) boil down to the following:

1. Is the APIC is enforcing some convention when it comes to the name attribute, and by extension the dn attribute of these MOs?
2. If so, how can I account for this if I push a Switch profile with multiple Leaf selectors?

Answers:

1. The APIC is only enforcing the name attribute due to the need for unique dns (distinguished name) per MO throughout the fabric. Similar to a linux filesystem, two files of the same name (MOs for ACI) cannot exist within the same directory (child of the same parent for ACI).

Examples:

uni/infra/nprof-GMM-SwProfile102/leaves-Leaf102-LeafSelector-typ-range/nodeblk-testname
uni/infra/nprof-GMM-SwProfile102/leaves-Leaf101-LeafSelector-typ-range/nodeblk-testname

Having the two above objects is acceptable and will not be rejected. You may notice from the end of the DN that the two nodeblocks share the same name, however since they have different parents, the DN remains unique. If you had attempted to push a new "testname" to "Leaf102-LeafSelector", it would have either been rejected by the API, or accepted as a modification (depending on your status attribute).

 2. Some options:

• Push a single Leaf Profile with multiple Leaf selectors and a single infraNodeBlk per Leaf selector. This will allow you to re-use the same infraNodeBlk name attribute which ensures the DNs are unique.
• Push a single Leaf Profile with a single Leaf Selector and create a single infraNodeBlk that defines the range of used nodes (The following attributes: "from_"=101, "to_"=102). Then you will only have one DN and you would not need to worry about name overlaps.
• Push a single Leaf Profile with a single Leaf Selector and create a single infraNodeBlk per node. This would force you to need a unique name per infraNodeBlk.

 Example of Single Leaf Profile, Multiple Leaf Selectors, single infraNodeBlk per leaf selector:

{
    "infraNodeP": {
      "attributes": {
        "dn": "uni/infra/nprof-GMM-SwProfile101-102",
        "status": "created"
      },
      "children": [{
        "infraLeafS": {
          "attributes": {
            "name": "Leaf101-LeafSelector",
            "status": "created",
            "type": "range"
          },
          "children": [{
            "infraNodeBlk": {
              "attributes": {
                "status": "created",
                "from_": "101",
                "name": "anyname",
                "to_": "101"
              }
            }
          }]
        }
      },
      {
        "infraLeafS": {
          "attributes": {
            "name": "Leaf102-LeafSelector",
            "status": "created",
            "type": "range"
          },
          "children": [{
            "infraNodeBlk": {
              "attributes": {
                "status": "created",
                "from_": "102",
                "name": "anyname",
                "to_": "102"
              }
            }
          }]
        }
      }]
    }
  }

You can see that I re-used "anyname" for both infraNodeBlks name attribute. I can do this since they have unique parents, so their DNs will still be unique. As far as what to name it, it can really be anything as long as the resulting DN is unique given the above explanation.

-Gabriel