SPECTRUM duplicate IP address functionality and best practices

Products

• CA Spectrum
• DX NetOps

Issue/Introduction

When SPECTRUM creates a new model, it checks the ip and mac addresses of the new model against the ip and mac addresses of existing models. If there is at least one duplicate ip and/or mac, SPECTRUM will assert a DUPLICATE MODEL DETECTED alarm.

SPECTRUM will not create a duplicate model when modeling by ip or AutoDiscovery if ALL the ip address of the new model are the same as an existing model in the database.

This is an important alarm because SPECTRUM has Redundancy intelligence it uses when a device has multiple ip address assigned. When SPECTRUM loses communication with one of the ip addresses, it will try to regain access with another known ip address. If it can, then an alarm is asserted letting you know SPECTRUM lost connection with the primary management ip address (the one used to model it in the database initially) but has regained connection using a different known ip address.

If there are more than two devices in the network that share the same ip, this redundancy intelligence can backfire. For example, device A and device B share a common ip address of 192.168.2.150. They both have other ip addresses configured and are modeled in the database initially with one of these other ip addresses.

Let's say device A goes down hard. It is off the network completely. SPECTRUM can no longer communicate with the primary address when it was first modeled so it tries to regain communication using a different ip address configured on the device. So it will try 192.168.2.150. SPECTRUM works at the application layer so it just send the snmp request down the wire. Since that ip address is configured on device B, device B will respond. SPECTRUM does not know it was device B that responded. All that SPECTRUM knows is it received a response from an snmp request. SPECTRUM asserts an alarm stating it changed the ip address for device A when in reality device A is off the network and it was device B that responded.

Environment

Release: Any
Component:

Resolution

There are a few ways to work around this.

1. You can updated the Preferred Address table on a model and tell it which ip addresses to use for redundancy and which one not to use. This is a good solution but requires manual administration. Please refer to the "Redundant Connections" section of the documentation for more information on disabling the redundancy intelligence.

2. You can disable the redundancy intelligence outright. The only drawback is if you lose connection with the primary, we might assert a lost contact when in reality, you just lost that ip. If redundancy were enabled, we might still be able to communicate using a different ip. 

3. You can manage using the loopback address and disable the redundancy by default for all existing models and all future models. This is probably the best solution. By managing with the loopback, the theory is if you lose connection with the loopback address, the device is down no matter what other ip address you try. 

4. You can disable the alarm using the Event Configuration Editor. Please refer to the "Event Configuration" section of the documentation for more information on how to change the alarming on an existing event.