I'm trying to do a bit of tune up for the DFM where I need to make a lot of discovered IP addresses on the managed routers as unmanaged IPs (so DFM does not try to probe them and does not fire up interface/reachability alarms). Some time ago Cisco had a perl script for the previous versions of DFM where one could specify a range of IPs that have to be unmanaged and the script in CLI would modify the state for those IPs. Apparently this script still works with the DFM from LMS 3.0, however there is a problem:
the command that script executes is /opt/CSCOpx/objects/smarts/bin/dmctl with some parameters. One parameter (getInstance IP) is suppose to list all the discovered IP addresses and it does list a lot BUT not all. I still have routers in DFM the IP addresses of which are not shown via this cli command and the script cannot make these missing IP addresses as unmanaged, as a result I'm still getting the unreachable alarms. To manually go via DFM's GUI and unmanaged IPs one by one is not really an option for about a thousand of IPs (could this be the CSCsg29309?)
Maybe the new DFM has some new option where a range of IPs can be specified as managed only and the rest of the discovered IP addresses will be ignored?
And as a side note, the c3500XL switches (the ancient but still in production) are reported as OperationallyDown for their management VLANs (could be another BUG?)
There are now two DfmServers in LMS 3.0 and higher (DfmServer and DfmServer1 or instances DFM and DFM1 respectively). Each is designed to manage half of the network. That said, this script really shouldn't be used with DFM 3.0. Instead, new scripts and a new procedure were added to DFM 3.0 (and 2.0.10) to allow for bulk management operations.
Open up the Detailed Device View for any device, and you should see a button for getting instructions on performing bulk management operations. Use the Korn shell scripts in those instructions to do what you want.
Joe, if you do mind, just out of curiosity what is the difference between the EXPLICITLY_UNMANAGED and just UNMANAGED. These new scripts do pretty much the same as the old one, they are a bit more convenient in terms of specifing the IPs instead of the octets
MANAGED and UNMANAGED are the initial states used by DFM when it discovers a device. Anytime settings are saved via Detailed Device View, the states are overwritten with explicit managed states (i.e. EXPLICITLY_MANAGED and EXPLICITLY_UNMANAGED). They indicate that the user has manually requested the management state of the object to be a certain way, regardless of what the DFM default is.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...