SPECTRUM Device Reconfiguration/Rediscovery recommended best practices.

Article Id: 52123

Status: Published

Updated On: 14-08-2020 11:14

Legacy Id: TEC518187

Products:

CA Spectrum

Issue/Introduction:

SPECTRUM Device Reconfiguration/Rediscovery recommended best practices.

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.