Data Flow for ITNM Cross Domain discovery

Body

Use this information to follow the data flow for cross domain discovery.  

Before you start make sure you have discovered each domain at least twice.

(Source: http://www-01.ibm.com/support/knowledgecenter/SSSHRK_4.1.1/com.ibm.networkmanagerip.doc_4.1.1/itnm/ip/wip/disco/task/nmip_dsc_checkingcrossdomainlinks.html?cp=SSSHRK_4.1.1&lang=en )
 
The reason is explained below.   
 
The cross domain process was designed as a frame work so that it could be extended and customized easily with plugin stitchers.  
A number of stitchers are supplied with the product.  
 
The LinkDomains stitcher is called from the PopulateDNCIM.stch after discovery has populated its database with the elements and connections.  
The LinkDomainsDatabaseSetup stitcher creates an OQL database (linkDomains) to hold all the newly found connections.  
There are a lot of individual 'plugin' stitchers that try to find cross domain links based on different protocols.  
You can tell which does what from their name.   

http://www-01.ibm.com/support/knowledgecenter/SSSHRK_4.1.1/com.ibm.networkmanagerip.doc_4.1.1/itnm/ip/wip/disco/reference/nmip_dsc_crossdomainstitchers.html?lang=en
 
Each of the plugin stitcher is then run in turn.  
Plugin stitchers are enabled or disabled within the LinkDomains.stch.
See the section of the file under "USER-SERVICABLE CONFIGURATION"  
 
Each stitcher searches the current domain for an "a-to-z" connection where z is not in the current domain.  
Then it searches the other domain in the topology database for that z end entity.  
If it finds it, it calls the LinkDomainsAddInstruction stitcher to add an instruction into the linkDomains OQL database (linkDomains.instruction table).  

After all the links have been found, the instructions in the linkDomains database are acted upon and created as usual in the NCIM database.  
This is why you need to run discovery twice.   
Once to populate NCIM with elements from *all* the domains and once for the cross domain stitchers to find the far end (z) elements that link to the near end elements.  
 
So points to check.
Has cross domain discovery been enabled in all the domains?
    check that m_EnableCrossDomainProcessing = 1 and m_inferPEsUsingBGP = 0 in DiscoConfig.DOMAIN_1.cfg *and* DiscoConfig.DOMAIN_2.cfg
    * check whether you have a domain specific version of LinkDomainsPopulateDomainAdjacencies.stch?   
I think a domain specific version of this file should *not* exist since all domains need to use it. If domain specific versions of this stitcher do exit, then make sure
all the domains to be connected exist in both files.

 
Check that each interface exists in its respective domain.  

What plugin stitcher would you expect to find these connections.  
What protocols run over these connections?  
Check that that plugin stitcher is enabled in either LinkDomains.stch or in domain specific versions of the same.  
Identifying what protocols run over these connections is vital.  
Remember that each stitcher looks for an a-to-z where the z end is not in the current domain.  
So we need to know which stitcher could be failing to find that a-to-z connection.  
 
When run in debug, ncp_disco writes the start and stop for each stitcher called, (you can see entries like this in the stitcher file Log("debug",...) ).  
If a full discovery has been run twice in each domain, then run a new discovery in debug and check the log file for the start and stop of the plugin stitcher that you think should be creating the link.  
Check in between those times for debug data about what the stitcher is doing.  
You can reduce the amount of data in the log file by just running the restitching of the topology without capturing the full discovery from start to end.  
To restitch a topology make sure that ncp_disco has not been restarted since the last Discovery, otherwise all the memory resident databases will be empty.  
increase debug to 4 and messagelevel to debug using the kill USR1 and USR2 method
(http://www-01.ibm.com/support/knowledgecenter/SSSHRK_4.1.1/com.ibm.netw…)  

... then use ncp_oql to connect to ncp_disco for that domain and run
insert into stitchers.actions values ('Restitcher');
 
Check to see if you have any inserts into linkDomains.instruction for the problematic interfaces.  
 
Methods of last resort.
Links can be hardwired using LinkDomainsLoadPresetConnections.  
Do the interfaces have any other attributes that could be used to link them, such as interface description?  
If so they can be used by the LinkDomainsLoadInterfaceDescriptionMatches.stch (see the stitcher for examples).