IBM Support

Tivoli Network Manager 4.1.1 MergeLayers.stch change (advanced control over topology resolution)

Technical Blog Post


Abstract

Tivoli Network Manager 4.1.1 MergeLayers.stch change (advanced control over topology resolution)

Body

Note: This post is not going to be a tutorial on how and why you'd want to change the way Network Manager resolves topology. Neither is it a recommendation or general tip; changing the order of topology merging can cause more topology issues than it fixes. The intention of this post is really just to pre-warn those who have altered topology resolution in earlier releases.
 

Topology Layer Merge Change

In 4.1.1 there was a change to the way in which the MergeLayers stitcher is given information as to what topologies to merge and how.
Tweaking this information via stitcher modification has in the past given advanced control over topology resolution.
This tweaking is still possible in 4.1.1; we've just moved the information from the stitcher and into a configuration file.
 

Old approach:

 
The old way topology merge requirements were fed to the MergeLayers stitcher was via stitcher arguments passed by the calling stitcher (i.e.CreateAndSendTopology.stch).
For example the following basically meant, 'merge these topology tables (stated in order of preference) into 'fullTopology' table;
 
   ExecuteStitcher('MergeLayers', 1,
                    'passportTopology', 'RPRLayer',
                    'ilmiLayer', 'pnniLayer', 'FddiLayer', 'SRPLayer','SONMPLayer',
                    'stpTopology', 'switchTopology', 'hubTopology',
                    'CollectorSwitchLayer', 'CollectorLagLayer',
                    'CDPLayer', 'CabletronLayer', 'CMTSLayer', 'LLDPLayer', 'CiscoSerialInterfaceLayer',
                    'AdjustedIPLayer', 'AdtranLayer2', 'IPLayer', 'SerialLinkLayer',
                    'fullTopology');
 

New approach:

 
The stitcher argument approach above wouldn't work so well in 4.1.1 as our Layer 1 support meant we needed to 'merge layers' more than once.
It is for this reason that we moved the merge requirements to a new database table, disco.convergedTopologies, which MergeLayers.stch (still called just once) reads.
 
DiscoSchema.cfg defined the disco.convergedTopologies table and it is populated via an INSERT statement in DiscoConfig.cfg, for example the one equivalent to the above is;
 
    insert into disco.convergedTopologies
    (
        m_TopologyName,
        m_Order,
        m_SourceTopologies,
        m_RetainOverride,
        m_UseContainment
    )
    values
    (
        'fullTopology',
        2,
        [ 'passportTopology', 'RPRLayer',
            'ilmiLayer', 'pnniLayer', 'FddiLayer', 'SRPLayer','SONMPLayer',
            'stpTopology', 'switchTopology', 'hubTopology',
            'CollectorSwitchLayer', 'CollectorLagLayer',
            'CDPLayer', 'CabletronLayer', 'CMTSLayer', 'LLDPLayer',
            'CiscoSerialInterfaceLayer', 'AdjustedIPLayer', 'AdtranLayer2',
            'IPLayer', 'SerialLinkLayer' ],
        1,
        1
    );
 

Remember: Although the topology merge info is now technically held in the 'configuration files' care should be taken should you decide you really need to change the standard settings.

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]

UID

ibm11082241