5 Replies Latest reply on May 1, 2017 9:07 AM by rschroeder

    Monitor device that uses Solarwinds IPs internally

    Richard Phillips

      I've just installed a new device in my network that has an internal IP scheme (for internal traffic) that matches the IP range that our Solarwinds servers live on. I need a way to monitor that device - suggestions. I do have a secondary poller, but it is on the same network range as our primary server.


      Is there a way to put a secondary IP address on the polling server and force it to source from that IP for hitting this device (there will eventually be several on this range, but not nearly enough to justify an additional poller.


      For those of us that prefer pictures see below (Note, IPs shown are not the real ones, just ones I made up for illustration purposes)


        • Re: Monitor device that uses Solarwinds IPs internally

          Would it be possible to change the network connection to a trunk port and carry the network ranges as separate vlans?  Then you could have NPM poll on the 192.168.95.x network directly.  Just a thought, and you should take it with a grain of salt.

          • Re: Monitor device that uses Solarwinds IPs internally

            You'll need to do one of the following to successfully have Solarwinds monitor conflicting IP address ranges within your network:

            • Change the IP address scheme of the conflicting devices so they don't conflict with your main network
            • Change the address conflicts on your main network so there are none with those "special" devices
            • Provide a NAT router between your SW poller and the device(s) with conflicting addresses; then monitor the conflicting/problem devices via that NAT router
            • Install an additional NIC on the device with the conflicting address, and monitor the device via a different address on the NIC that does NOT conflict with your main network.


            In many organizations 192.168.0 and 192.168.1 networks are not allowed to be built, and are changed when they are discovered.  This is because SOHO/Consumer DHCP devices use those address ranges by default.  If/when someone buys a home router or wireless access point, brings it into work, and lets it start offering DHCP addresses to your internal network in ranges you're already using, that would be inconvenient to troubleshoot at best, and will cause a growing network outage to users' devices which start getting their DHCP requests served by that rogue DHCP service.


            It's better to use different address schemes so any rogue DHCP servers/AP's/Routers show up as red flags on the network.  If everyone is used to seeing 10.x.x.x or 172.16.x.x or a 192.168.x that isn't 0 or 1--and a 192.168.0 or 192.168.1 shows up, you know it's unauthorized, and it's easier to chase down and disable/remove.