Forum Discussion

teppotahkapaa's avatar
teppotahkapaa
Contributor III
29 days ago

Overlapping IP addresses

This might be an oldie...

How should we manage devices which have multiple overlapping IP addresses. For example Layer3 switches or router HA pairs can have same IP addresses set up to two or multiple devices for routing high availability or management reasons. This then makes SL1 see same IP addresses in multiple devices. And that then generates events into System organization, events like:

 A Message Collector is managing multiple devices with an overlapping secondary IP address: Secondary IP address overlap on devices managed by Message Collector: 101 | Collector Groups: 44 | IP Address: 128.0.0.127 | Device IDs: 70999, 70998, 71001, 71009, 71005, 71003, 71006, 71004, 71007, 71002, 71013, 71012, 71015, 71010, 71014, 71008, 71016

Ok, that IP address can be deleted from database, but the nightly discovery again brings up the same issue next day. And because those are network devices where every now and then are some changes done in interfaces I believe we just have to have the Auto-Update enabled for those devices.

So:

  • is there a way to tell that please do not discover all IP addresses for this device
  • is there a way to make SL1 accept that, some other way than creating pretty interesting regexes into event policies
  • event policy is for system level so that not easily be just suppressed for some devices
  • are there some other ideas how to manage this situation
sciencelogic platform
  • JohnProctor's avatar
    JohnProctor
    Icon for Moderator rankModerator
    4 hours ago

    Today, interface inventory is all (default) or nothing (alternate). Interface inventory can be bypassed during onboarding via the unguided discovery workflow or after a device has been added using the device settings or templates. As mention, this stops all interface inventory, which might work if the interface configuration does not change or the changes are infrequent and known.

    A potential change in behavior would be to identify these virtual addresses and exclude them from the "overlapping address" alert. With VRRP, the routers or L3 switches in the redundancy group also have unique physical addresses. The assumption would be that the devices in the redundancy group would always sent traps and message using the physical address and never the virtual (shared or duplicate) address. 

    The only remaining concern would be how to handle a message or trap if a device used the virtual address as the source address in the trap or message header. If it did, we would want to include a default or fail safe behavior so that we do not fail to process a trap or message.

    • Does identifying the virtual addresses and excluding them from the "overlapping address" alert seem palatable?
    • Will the traps and message always come from the physical address?
    • What should the fail safe behavior be if we receive a message or trap where the virtual address is the source? 

  • SaraLeslieAdmin's avatar
    SaraLeslieAdmin
    Icon for Community Manager rankCommunity Manager
    18 days ago

    Thanks for your question - I am working on getting an expert to assist you with this. Thanks for your patience. 

    Sara