LMS 4.2 managed all devices by DFM

[KAROLY KOHEGYI]

Hi,

I would like to control what kind of devices will be managed by DFM.

In the "old" LMS 3.2 I was able to add/delete  devices to DFM database manually.

Now all DCR devices are managed by DFM automatically.

How can I control the DFM what kind of devices are covered by DFM??

thx.

[Vinod Arya]

There was a complete architecture overhaul from LMS 3.x to LMS 4.x. Previously in LMS 3.x each module was independent and hence has capability to add/delete devices and control management of devices accordingly.

With LMS 4.x the concept of Unified Device Manage (UDM) was introduced where LMS instead of a collection of modules was represented as a unified software. Unified Device Manager (UDM) provides centralized device management using a centralized policy configuration.

Hence you see modules name disappeared in LMS 4.x and are represented as features (config, inventory, monitor etc). Now devices get completely managed in DCR and we cannot remove them from module separately. 

You cannot delete any device from DFM. A device has to be managed by LMS or it can be suspended/deleted, which will be effective on all the modules.

-Thanks

Vinod

** Ecnourage Contributor for free. RATE them**

[KAROLY KOHEGYI]

Dear Vinod and Afroz,

Thank for you answers. It confirmed me about what i have known about DFM in LMS 4.2.

Unfortunetly the CLI Bulk method is very undocumented.

Where can i read about DMCTL command parameter?

I am very sad, that this opportunity ceased. 

br

[AFROJ AHMAD · Accepted solution]

Hi ,

Here are the Deatilsed steps ,hope this will help to achive your goal:

The only allowable modifications which furnished to be used by LMS users ,is Managing/Unmanaging the status for any component in the System . this involves (interfaces, ports, IP addresses, processors, and memory)

To achieve this you can know the parameters and class names needed only to
Manage/Unmanage these component as explained below .

#Depending on your platform, run one of the following scripts to create the
generated files that are necessary for the operation (these files contain
the data you want to know about Classes and parameters used in the dmctl
commands for the corresponding element in LMS):

Solaris\linux:

******

Interfaces/Ports   NMSROOT/objects/smarts/utils/getStateIntPort.ksh

IP Addresses          NMSROOT/objects/smarts/utils/getStateIP.ksh

Processor                NMSROOT/objects/smarts/utils/getStateProc.ksh

Memory                  NMSROOT/objects/smarts/utils/getStateMem.ksh

Windows

********

Interfaces/Ports   NMSROOT\objects\smarts\utils\getStateIntPort.bat

IP Addresses          NMSROOT\objects\smarts\utils\getStateIP.bat

Processor                NMSROOT\objects\smarts\utils\getStateProc.bat

Memory                  NMSROOT\objects\smarts\utils\getStateMem.bat

# The generated file for the above command will be located in the location below :

Solaris\linux:

*****

Interfaces            NMSROOT/objects/smarts/local/logs/expInterface.log

NMSROOT/objects/smarts/local/logs/expInterface1.log

Ports                     NMSROOT/objects/smarts/local/logs/expPort.log

NMSROOT/objects/smarts/local/logs/expPort1.log

IP Addresses     NMSROOT/objects/smarts/local/logs/expIP.log

                               NMSROOT/objects/smarts/local/logs/expIP1.log

Processor           NMSROOT/objects/smarts/local/logs/expProc.log

 
NMSROOT/objects/smarts/local/logs/expProc1.log

Memory             NMSROOT/objects/smarts/local/logs/expMem.log

                               NMSROOT/objects/smarts/local/logs/expMem1.log

Windows

*******

Interfaces        NMSROOT\objects\smarts\local\logs\expInterface.log

 
NMSROOT\objects\smarts\local\logs\expInterface1.log

Ports                  NMSROOT\objects\smarts\local\logs\expPort.log

                             NMSROOT\objects\smarts\local\logs\expPort1.log

IP Addresses   NMSROOT\objects\smarts\local\logs\expIP.log

                             NMSROOT\objects\smarts\local\logs\expIP1.log

Processor         NMSROOT\objects\smarts\local\logs\expProc.log

                             NMSROOT\objects\smarts\local\logs\expProc1.log

Memory           NMSROOT\objects\smarts\local\logs\expMem.log

                             NMSROOT\objects\smarts\local\logs\expMem1.log

# Edit the generated file where you want to manage/unmanage the component
to reflect one of the following states:

MANAGED_STATE:EXPLICITLY_MANAGED

MANAGED_STATE:EXPLICITLY_UNMANAGED

# Set and apply your state changes so DFM will collect the proper device information as below commands :

Solaris\linux:

******

Interfaces/Ports      NMSROOT/objects/smarts/utils/setStateIntPort.ksh

IP Addresses             NMSROOT/objects/smarts/utils/setStateIP.ksh

Processor                   NMSROOT/objects/smarts/utils/setStateProc.ksh

Memory                     NMSROOT/objects/smarts/utils/setStateMem.ksh

Windows

********

Interfaces/Ports     NMSROOT\objects\smarts\utils\setStateIntPort.bat

IP Addresses            NMSROOT\objects\smarts\utils\setStateIP.bat

Processor                  NMSROOT\objects\smarts\utils\setStateProc.bat

Memory                    NMSROOT\objects\smarts\utils\setStateMem.bat

The following example shows a session in which you can perform a bulk unmanage on interfaces.

# /opt/CSCOpx/objects/smarts/utils/getStateIntPort.ksh (you will get
something like the below in cmd)

Get Managed state for interfaces from DfmServer

MAIN-N-Closing this log file at 13-Jan-2014 19:05:45; continuing in

    /opt/CSCOpx/objects/smarts/local/logs/expInterface.log

Get Managed state for Ports from DfmServer

MAIN-N-Closing this log file at 13-Jan-2014 19:05:49; continuing in

    /opt/CSCOpx/objects/smarts/local/logs/expPort.log

# Then open the generated file by cd /opt/CSCOpx/objects/smarts/local/logs

You can open the exp.Interface.log file and locate the interfaces to be
unmanaged:

INTERFACE:IF-1.9.150.46/2 MANAGED_STATE:MANAGED

INTERFACE:IF-1.9.150.76/5 MANAGED_STATE:MANAGED

INTERFACE:IF-1.9.150.63/2 MANAGED_STATE:MANAGED

...

You can change the MANAGED_STATE value:

INTERFACE:IF-1.9.150.46/2 MANAGED_STATE:EXPLICITLY_UNMANAGED

INTERFACE:IF-1.9.150.76/5 MANAGED_STATE:EXPLICITLY_UNMANAGED

INTERFACE:IF-1.9.150.63/2 MANAGED_STATE:EXPLICITLY_UNMANAGED

...

# then Apply the changes in these files to the system by run the set command
: /opt/CSCOpx/objects/smarts/utils/setStateIntPort.ksh (you will get
something like the below output)

Set Managed state for interfaces for DfmServer

MAIN-N-Closing this log file at 13-Jan-2014 19:12:18; continuing in

    /opt/CSCOpx/objects/smarts/local/logs/intfOut.log

Set Managed state for Ports for DfmServer

MAIN-N-Closing this log file at 13-Jan-2014 19:12:22; continuing in

    /opt/CSCOpx/objects/smarts/local/logs/portOut.log

Apply changes and reconfigure on DfmServer

MAIN-N-Closing this log file at 13-Jan-2014 19:12:33; continuing in

    /opt/CSCOpx/objects/smarts/local/logs/apply.log

Thanks-

Afroz

****Ratings Encourages Contributors ****

[KAROLY KOHEGYI]

Hi,

Thanks for the detailed explanation.

It means if we do not want to control devices by DFM , we have to set EXPLICITLY_UNMANAGED state for all of parameters of given devices.

what happens if one of routers will have new interface?

will I have to run the scripts again?

The totally unmanaged state in earlier version of LMS gave a simple solution for this situation.

Now i have to always check the new components ( new interface) status of devices!?

br,

Now we want to unmanage all ACE module in LMS. ( 6 pcs, 10 content / ACE, more than 100 VLAN interface )

[Vinod Arya]

Yes the new interfaces discovered would need to be unmanaged again.

You can either do it from running script by finding the Interface index with DFM or you can simply unmanage one port/interface from Fault Manager GUI from :

Monitor > Fault Settings > Setup > Fault Device Details

Though this feature is missed by all of us and our customer's, it was required to support some new features and also to make this tool more unified.

If you have to unmanage ACE from LMS completely, you can suspend the device for now. Only for Fault Manager unmanaging components is the only options.

-Thanks

Vinod

** Encourage Contributor. RATE them :) **

[AFROJ AHMAD]

Hi,

As my fried vinod said " UDM was introduced from LMS 4.x onwards.where LMS instead of a collection of modules was represented as a unified software.

You can't manage devices in DFM ,however you can unmange the device interfaces from DFM , you can still use the CLI to do that the same way we use to do it in LMS 3.2 :

http://www.cisco.com/c/en/us/td/docs/net_mgmt/ciscoworks_lan_management_solution/4-2/user/guide/lms_monitor/lms_mnt/mnt-fault.html#wp1587045

Also  you can go to this from GUI " Monitor > Fault Settings > Setup > Fault Device Details"

Thanks-

Afroz

***Ratings Encourages Contributors ****