Question about HTTP POST to update node blocks in Switch Profile

[000node000]

I would like to use HTTP POST to update a Leaf Switch Profile under Fabric Policies.

If I add a new node block, 111-120, will ACI automatically join an existing block, 100-110, to the added block, to make a new larger block, 100-120?

Want to add new block:
{
      "fabricNodeBlk": {
        "attributes": {
          "annotation": "",
          "descr": "",
          "dn": "uni/fabric/leprof-MYPROFILE/leaves-MYPROFILE-typ-range/nodeblk-block111to120",
          "from_": "111",
          "name": "block111to120",
          "nameAlias": "",
          "to_": "120"
        }
      }
}

Existing block:
{
      "fabricNodeBlk": {
        "attributes": {
          "annotation": "",
          "descr": "",
          "dn": "uni/fabric/leprof-MYPROFILE/leaves-MYPROFILE-typ-range/nodeblk-554d6464a334",
          "from_": "100",
          "name": "554d6464a334",
          "nameAlias": "",
          "to_": "110"
        }
      }
}

The node blocks are children of fabricLeafS, as shown in moquery -c fabricLeafP -x 'rsp-subtree=full'.

When I used the APIC GUI, I added a new block 210-220 at the end of the blocks, and there was already an existing block 200-209. As expected, the GUI automatically refreshed the list to show 200-220. When I do moquery, I see the a new block 200-220, so ACI joined the old and added block to make a new larger block.

If I add a new block with HTTP POST, will the ACI do the same thing? Or do I have to first delete an existing block, and add a new block that contains the entire range?

Thanks!

[RedNectar]

Hi @000node000 ,

Firstly - thanks for formatting your question using <pre> tags. It makes it easier to read.

But I have to ask "What are you creating Fabric Leaf Profiles (fabricLeafP )for?"

Now, I know there is a use for them, (such as needing to use ZR transceivers between a leaf and a spine) , but in the 9+ years I've been working with ACI, I've never needed or wanted to create one.

So I'm really curious about YOUR use case. Please tell me.

---

But back to your question. The problem is that you didn't name the Leaf Selector - only referenced it in the dn. Here's what you said

{
      "fabricNodeBlk": {
        "attributes": {
          "annotation": "",
          "descr": "",
          "dn": "uni/fabric/leprof-MYPROFILE/leaves-MYPROFILE-typ-range/nodeblk-block111to120",
          "from_": "111",
          "name": "block111to120",
          "nameAlias": "",
          "to_": "120"
        }
      }
}

But the dn doesn't make good sense, because you have MYPROFILE twice - the first instance should be the name of the Leaf Switch Profile, and the the second occurrence is the name of the Leaf Selector. No rules about calling a Leaf Selector "MYPROFILE" - but a very confusing naming convention.

I'd suggest you use a different name for the Leaf Selector - such as Leaves111..120. If you are happy with this Leaf Selector name, posting the following should work:

{
    "fabricLeafS": {
        "attributes": {
            "annotation": "",
            "descr": "",
            "dn": "uni/fabric/leprof-MYPROFILE/leaves-Leaves111..120-typ-range",
            "name": "Leaves111..120"
        },
        "children": [
            {
                "fabricNodeBlk": {
                    "attributes": {
                        "annotation": "",
                        "descr": "",
                        "from_": "111",
                        "name": "block111to120",
                        "nameAlias": "",
                        "to_": "120"
                    }
                }
            }
        ]
    }
}

BUT IF you really want your Leaf Selector to be called "MYPROFILE" - use this instead:

{
    "fabricLeafS": {
        "attributes": {
            "annotation": "",
            "descr": "",
            "dn": "uni/fabric/leprof-MYPROFILE/leaves-MYPROFILE-typ-range",
            "name": "MYPROFILE"
        },
        "children": [
            {
                "fabricNodeBlk": {
                    "attributes": {
                        "annotation": "",
                        "descr": "",
                        "from_": "111",
                        "name": "block111to120",
                        "nameAlias": "",
                        "to_": "120"
                    }
                }
            }
        ]
    }
}

[000node000]

It's for various policies, like for Netflow. On this fabric, the LeafS name is the same as the LeafP name.

In the GUI, adding node blocks was like doing "switchport trunk allowed vlan add" and seeing IOS join and compact the list of new ranges. It's a helpful feature. Just wanted to see if anyone has done this, before I use the API to add a large number of node blocks.

[RedNectar]

Hi @000node000 ,

OK. I guess Netflow is a use case. Did the JSON work when you pushed it?

[000node000]

Not yet, in a future window.

I don't need the fabricLeafs if I specify the full dn in fabricNodeBlk, right? Just don't want ACI to delete the existing blocks/children, instead of just adding a new block. In the GUI, it seemed a little tricky to add a new block of node ID's without recreating the whole list.

[RedNectar]

Hi @000node000 

---

I don't need the fabricLeafs if I specify the full dn in fabricNodeBlk, right?

Yes you do.

[Edit: You MAY be able to can get away with specifying the full dn if you set the status to "modified" - I've just never tried to do it this way See 2nd attempt answer /Edit]

The block (fabricNodeBlk) is a child object of the selector (fabricLeafs), so you are modifying thefabricLeafs object - so it needs to be specified, just like when adding a Bridge Domain to a tenant - you can't add the BD without a construct that shows it is a child object of the tenant.

Just don't want ACI to delete the existing blocks/children, instead of just adding a new block. 

---

Thats exactly what the block I posted earlier will do. Here is is again (trimmed a little - this is all you need)

{
    "fabricLeafS": {
        "attributes": {
            "dn": "uni/fabric/leprof-MYPROFILE/leaves-MYPROFILE-typ-range",
            "name": "MYPROFILE"
        },
        "children": [
            {
                "fabricNodeBlk": {
                    "attributes": {
                        "from_": "111",
                        "name": "block111to120",
                        "to_": "120"
                    }
                }
            }
        ]
    }
}

Curiously, if leaves 100-110 exist already in the Leaf Selector called MYPROFILE - when you execute the above, it will look like this in the GUI:

You won't see the individual fabricNodeBlk objects unless you open that Leaf Selector called MYPROFILE in the Object Store Browser and view the children MOs

[RedNectar]

Hi @000node000 ,

Here is attempt #2 reply. I've left the original because I think it is a better answer - but here goes again! (Forgive me for contradicting my previous answer)

I don't need the fabricLeafs if I specify the full dn in fabricNodeBlk, right?

To do it that way, you'll need to tell ACI you are modifying the object

Just don't want ACI to delete the existing blocks/children, instead of just adding a new block.

---

Then post this:

{
      "fabricNodeBlk": {
        "attributes": {
          "status": "modified",
          "dn": "uni/fabric/leprof-MYPROFILE/leaves-MYPROFILE-typ-range/nodeblk-554d6464a334",
          "from_": "100",
          "name": "554d6464a334",
          "to_": "120"
        }
      }
}

[000node000]

Thanks. I just found out about Cisco Devnet ACI lab. I tested the json on devnetsandbox and it works fine. Yeah, I read that created,modified was the way to go. ACI joins the block ranges as expected. The GUI and API do things differently, but ACI presents the same either way.

{
  "fabricNodeBlk": {
    "attributes": {
      "annotation": "",
      "descr": "",
      "dn": "uni/fabric/leprof-MYPROFILE/leaves-MYPROFILE-typ-range/nodeblk-{{nodeblk}}",
      "from_": "{{nodestart}}",
      "name": "{{nodeblk}}",
      "nameAlias": "",
      "to_": "{{nodeend}}",
      "status": "created,modified"
    }
  }
}