cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
443
Views
1
Helpful
5
Replies

ACI: Automate EPG static port deployment

Johannes Luther
Level 4
Level 4

Hi ACI professionals,
I want to automate the provisioning (and removal) of EPG static ports using the REST-API.

My goal is, that the input parameter is the Leaf interface policy group name and the target encapsulation:

  • vPC: infraAccBndlGrp.name
  • Leaf access port: infraAccPortGrp.name

My script should find out, which Path (fabricPathEp) is currently used for this leaf interface policy group and attach it as a child element to the EPG (fvRsPathAtt).

Example: There is a vPC interface policy group (infraAccBndlGrp) with the name "VPC-serverA"
I thought it's as simple as query all fabricPathEp instances, which use this policy group:

moquery -c fabricPathEp -f 'fabric.PathEp.name=="VPC-serverA"'

However, when running this, I get three class instances.
One with the dn, which represents the vPC (containing both leaf nodes).
Example: dn: topology/pod-1/protpaths-1001-1002/pathep-[VPC-serverA]
=> This is the correct path, which I want to use

However, there is a path for each leaf switch as well:
Example:

  • dn : topology/pod-1/paths-1001/pathep-[VPC-serverA]
  • dn : topology/pod-1/paths-1002/pathep-[VPC-serverA]

When using the APIC GUI in the EPG static ports configuration ("Deploy Static EPG on PC, VPC, or Interface"), selecting the Path Type "Virtual Port Channel", there is only one entry for the leaf interface policy group "VPC-serverA" (the correct one, with both leaf switches).

So the APIC somehow knows the correct fabricPathEp instance for the configuration using the GUI. I just don't see how the APIC choses the correct one. The attributes within the three fabricPathEp instances are the same.

Any good hints on this?

1 Accepted Solution

Accepted Solutions

Marcel Zehnder
Spotlight
Spotlight

Hi

Correct, for a vPC there are three fabricPathEp's as you described. To get only the ones you're interested in, you can use the same filter as the UI. For moquery, this would look like this:

 

moquery -c fabricPathEp -f 'fabric.PathEp.lagT=="node" and fabric.PathEp.dn*"^topology/pod-[\d]*/protpaths-"'

 

For a specific policy group:

moquery -c fabricPathEp -f 'fabric.PathEp.lagT=="node" and fabric.PathEp.dn*"^topology/pod-[\d]*/protpaths-" and fabric.PathEp.name=="VPC-serverA"'

HTH

View solution in original post

5 Replies 5

Marcel Zehnder
Spotlight
Spotlight

Hi

Correct, for a vPC there are three fabricPathEp's as you described. To get only the ones you're interested in, you can use the same filter as the UI. For moquery, this would look like this:

 

moquery -c fabricPathEp -f 'fabric.PathEp.lagT=="node" and fabric.PathEp.dn*"^topology/pod-[\d]*/protpaths-"'

 

For a specific policy group:

moquery -c fabricPathEp -f 'fabric.PathEp.lagT=="node" and fabric.PathEp.dn*"^topology/pod-[\d]*/protpaths-" and fabric.PathEp.name=="VPC-serverA"'

HTH

Johannes Luther
Level 4
Level 4

Hey @Marcel Zehnder ,
This was exactely I was looking for. I were focussing on the fabricPathEp attributes values and didn't think about to look at the DN closely (protpaths vs. paths).

Happy I could help! Have a nice day.

Johannes Luther
Level 4
Level 4

Let me add a bonus question
Any clever idea how to get the paths (fabricPathEp) for a leaf access port policy group (infraAccPortGrp)?
Problem here is, that the path does not include the policy group name - instead the port IDs are used.
Currently playing around with the following approach:

  • Get port leaf interface policy group by name (infraAccPortGrp.name)
  • Get the child class infraRtAccBaseGrp (link to get the Port Selector infraHPortS)
  • And now I'm stuck, because the port selector does not necessarily resolve to a unique switch and port (in my example, one leaf interface profile is typically linked to two redundant leaf switches).

So basically I want to implement a function like "get_fabricPathEp_by_infraAccPortGrp"

Maybe there are more convinient MO classes to solve this ....
In the GUI Inventory under the leaf switch pysical interfaces (which I need), there is a field "Policy Group" - I wonder how this is looked up in the GUI.

Especially since I solve this using Ansible (using a self developed aci_lookup plugin)... but anyway - each lookup, iteration and filtering in Ansible is painful (at least for me). Some lines of Python code are sometimes easier

Marcel Zehnder
Spotlight
Spotlight

The GUI does the following (example is with one result only, there will be more results):

1) Get the node to interface profile mappings
moquery -c infraRsInterfacePolProfile | grep dn 
dn : uni/infra/nodecfgcont/node-311/rsinterfacePolProfile-[uni/infra/accportprof-311]

2.) Get all Port-Selectors, Port-Blocks and attached Interface Policy Groups for the interface profile found in 1)
icurl 'http://localhost:7777/api/mo/uni/infra/accportprof-311.json?query-target=subtree&target-subtree-class=infraHPortS,infraRsAccBaseGrp,infraPortBlk,infraSubPortBlk'

Based on the ouputs of 2) the UI is able to find the corresponding Policy Group on a specific node and port.

Seems like there is also a class (infraRtPathToAccBaseGrp) for the mappings policy group to fabricPath, however I don't get any MOs back in my fabrics for this class.

Review Cisco Networking for a $25 gift card

Save 25% on Day-2 Operations Add-On License