SPECTRUM Device Reconfiguration/Rediscovery recommended best practices.

Products

CA Spectrum

Issue/Introduction

Environment

Release: Any
Component:

Resolution

If_IsAutoCnfgActive (0x11dd4) - Determines if SPECTRUM should automatically update it's modeling of a device's interfaces when a change is detected. If "Automatically Reconfigure Interfaces" is set to Yes, the SpectroSERVER will poll the ifNumber, ifTableLastChange and ifStackLastChange attributes every poll cycle. If SPECTRUM detects any of these attributes have changes since the last poll, it will trigger device model reconfiguration. Device model reconfiguration will read attributes from the Systems MIB, IP MIB, ifMIB, Interfaces MIB, and in some instances, Frame Relay, ATM and vendor specific mibs. Default value "Yes/True".

DeviceDiscAfterReconfig (0x11d27) - Determines if SPECTRUM should update its knowledge of connections off a device's interfaces after a reconfiguration occurs. If "Discovery After Reconfigure" is set to Yes/True, it will trigger device connectivity mapping after the device model is reconfigured. Device discovery will read information from the IP MIB, Bridge MIB, and in some instances, vendor specific mibs such as the Cisco Discovery Protocol MIB. Default value "No/False".

DiscoverConnectionsAfterUpLinkEvent (0x11d25) - Setting this option to TRUE will cause SPECTRUM to discover connections on this device whenever the device sends a LINK UP trap. If "Discover Connections After Link Up Events" is set to Yes/True, a linkup trap sent from device will trigger device model?s connectivity mapping the same as DeviceDiscoveryAfterReconfig. Default value "no/False".

Additional Information

It should be noted the DeviceDiscoveryAfterReconfig and DiscoverConnectionsAfterUpLinkEvent should be used with caution and may affect device and/or SpectroSERVER performance in the following ways:

1. A device with a large IP Route Table or Forwarding Table may not be able to handle the amount of snmp required from SPECTRUM to retrieve the layer 2 and/or layer 3 data to be able to determine connectivity.

2. If the device has a flapping interface where it is sending multiple link up/down traps per minute, it could cause the SpectroSERVER to continuously try to rediscover the connections.

3. Hardware issues have been reported where the device recorded a change to the ifTableLastChange and/or ifStackLastChange but did not actually have a change in the configuration. This caused a Device Reconfigure / Rediscovery in SPECTRUM.

4. When the rediscovery and/or reconfiguration is run Spectrum needs to determine what the device supports as there are different discovery tables and information that Spectrum uses. There is internal code and database attributes that are used in this determination. During this process Spectrum will query mibs that may be outside the scope of the vendor. If the device responds with a NoSuchName, then Spectrum moves on. If the device were to respond with data, then Spectrum would run further queries in that table to see what the device knows and Spectrum may use it accordingly. These code does not run on a normal poll, only when rediscover and/or reconfigurations are done. This cannot be disabled or changed as it could potentially cause major issues with either the db itself or how models are created and updated in Spectrum.

NOTE - in 10.3.2 and up, Spectrum now has "Self-Health Monitoring" feature to keep track of high CPU and MEM use - it also has 'Auto-handle of Excessive Reconfigurations" so that, for the above performance problems mentioned due to excessive reconfigs, the Self-Health Monitor option will allow Spectrum to be aware of and manage the scenario in the background.

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/spectrum/10-4-3/administrating/spectroserver-performance-administration/self-health-monitoring.html