OK, how it works in NA is as follows:

When you have an ACI / APIC controller, as part of NA's management, the NA Module Status diagnostic will run.  

When that runs, a few things will happen with the result data:

1) It will learn of the controller peers (and add them in using the Inband IP of the controller - this can lead to duplicates if you add to NA with out of band IP - there is a work-around sort of).

2) It will learn of the leaf / spines (children)

Those leaf and spines will get added and the connection to each leaf / spine will be through controller #1 (parent) when certain tasks are run - so NA will first connect to controller #1, get some information while it is there, then connect to the child device and complete the task.  There will be data collected on the leaf / spine device.

You can tune this to a degree - go to a NA core URL and add: /tcdocs/en/DSD/DSD_CiscoAPIC.html or go Admin / Drivers and search for APIC and drill down....

Other thing to keep in mind:

If you have NNMi - do not allow NNMi to send leaf or spine devices to NA.  If you do this, it will not work.  You'll need to exclude them from the integration node group.  

Similarly, don't add them in manually - this won't work either.  

If you've done / do either, just stop, delete them and then run the NA Module Status diag on one of the controller #1 parents.  

Hopefully this helps, let me know if you have any follow up.

-Chris

Chris

I had allready added them in NNM Integration node group and it has populated in NA.

Do you mean to stop the integration from both NNM and NA and then delete Spine and leaf switches and then start discovering APIC.

I know if I delete spine or leaf in NA, it will delete them in NNM as well.

Please clarify.

Hi, 

I'm not familiar with your NNMi / NA configurations but will give you a perspective of how we are set up and how it works....

For us, in NNMi, nodes are added (or discovered).  As these are managed, NNMi will either add them or not add them to our NA Integration node group - mostly based on this:

Filter String
(isSnmpNode = true AND sysOidNode not in (.1.2.826.0.1.4616240.1.7.8050, .1.3.6.1.4.1.674.10892.5, .1.3.6.1.4.1.6889.1.45.103.8, .1.3.6.1.4.1.6889.1.8.1.58, .1.3.6.1.4.1.7779.1.1402, .1.3.6.1.4.1.7779.1.1404, .1.3.6.1.4.1.7779.1.1411, .1.3.6.1.4.1.7779.1.1413, .1.3.6.1.4.1.7779.1.1414, .1.3.6.1.4.1.7779.1.1421, .1.3.6.1.4.1.7779.1.1423, .1.3.6.1.4.1.7779.1.1504, .1.3.6.1.4.1.7779.1.1514, .1.3.6.1.4.1.8712.1.1, .1.3.6.1.4.1.9.1.1117, .1.3.6.1.4.1.9.1.1348, .1.3.6.1.4.1.9.1.1423, .1.3.6.1.4.1.9.1.1426, .1.3.6.1.4.1.9.1.1682, .1.3.6.1.4.1.9.1.2139, .1.3.6.1.4.1.9.1.2161, .1.3.6.1.4.1.9.1.2266, .1.3.6.1.4.1.2634.6.8, .1.3.6.1.4.1.6889.1.27.1.1, .1.3.6.1.4.1.6889.2.17.1, .1.3.6.1.4.1.9.1.2785, .1.3.6.1.4.1.12276.1.3.1.2, .1.3.6.1.4.1.10830.3.1) AND nodeName not in (bob, sam, tim) AND nodeName not in (frank, sally) AND NOT EXISTS (capability = nnm.capability.node.ciscoaci))

Focus on that last part.....this is how we ensure that no leaf or spines go across to NA.  (also, we do not allow non-SNMP devices to go to NA - if NNMi doesn't know what it is, it does not go to NA, in part for reasons like this).  

Here is an example of controller for us:

Here is a leaf switch:

So, with the controller, you see NA_ID - this guy went to NA and is fine (I blanked the number...but it is there).  The leaf switch - it did not go to NA.  

This, for us, means NA can do what NA needs to do in order to get leaf and spine switches working.  

Question for you will be, what can you do within the policies and procedures of your company to remove these contexts from NA.  There is a way to keep NA from telling NNMi to delete the nodes (admin / event notification & response rules / NA/NNMi Topology Synchronization for Device Deletion -> set to inactive) but this may be important for your processes and more difficult to change than removing the nodes in NNMi and re-adding them.  

I am not 100% on this, but you could try the following:

for each context you do not want in NA that is currently in NA

In NNMi:

add your version of the example filter to keep leaf and spines out of node group (to your NA Integration node group)

then specifically remove each node from the NA node group (if they still are members of group)

for each node, remove the NA_ID (Custom Attribute tab) (to make things clean)

If I recall, this will have the device in NA not show it is part of the integration - do you see the NNMi links at bottom of device home page?  At that point, you should be able to delete the device and NNMi would not do the same (because NA told it to).  

And then future leaf / spine switches will be added as part of controller #1's module diagnostic.  

Hope this helps.

-Chris