New with Open-AudIT 4.1.0, we have introduced Device Seed discoveries. This is another type of discovery, where you provide the IP of a "seed" device. This device is audited and any IPs it knows about are added to the list of IPs to be audited. And those devices are audited and any IPs they know of are also added to the IP list to be discovered. And on and on...
This is a good option if you know your network consists of a range of subnets, but you're unsure what they are. Point the discovery at a local router and watch the discovery fly!
But wait - we don't want it getting out of control, so what can we do to limit this craziness? Well, I'm glad you asked *.
We have several attributes available when you create this new type of discovery to limit it.
Obviously we need the Seed IP. We also ask you for a subnet. Along with this subnet, you have an option to restrict discovery to only that subnet. This works well when (for example) you know you have several subnets that are /24's but you're just not sure what they all are. Make the discovery subnet a /16 and restrict it to that subnet. Your discovery won't go crazy trying to discover every IP it finds. It will restrict itself to only those IP's (and hence subnets) that exist inside the /16.
We also have an option to restrict discovery to private IP addresses only. So you won't try to discover the internet 
. You can of course try to discover the internet, but you'll only get as far as a device with credentials you can talk to. Typically your gateway router. It will connect to your ISP, but you won't have credentials available for your IPS's device. Hence it won't find any more IPs and will stop there.
Discovery is smart enough to only add a new IP to the list if it hasn't already been found this discovery run. So you won't discover the same device multiple times.
One item to be aware of that I've experienced. My routers ARP cache is quite long lived. Using the standard "must respond to ping" option, everything works as expected. If I disable this (hence try to discover every IP, regardless of it responding to a ping) then devices that are in the routers ARP cache, but not actually connected at the time are added to the discovery. This is also the expected result, but may be "surprising" if you don't realise what's going on.
Along with those basic options, we also allow you to ping scan the defined subnet before running the discovery proper. Obviously I don't recommend doing this when you're using a /16, but for individual /24's it works great.
The usual discovery options are also present for SNMP, SSH testing, nmap rules, etc. Just like a regular discovery.
As an aside, from 4.1.0 onwards we allow more flexibility when creating a discovery regarding setting individual discovery scan options. You can now change individual options without having to create a "custom" discovery scan options entry. The Discovery Scan Options for a given discovery now function as the match rules. You choose an option set, but you can override individual options. They'll default to the discovery scan option chosen, if not explicitly set. Much more flexible and intuitive. These are still restricted to Enterprise licensed customers.
So, back to our new Device Seed discovery, how does it find "known IPs"? See below. In all cases you will need credentials to talk to the device.
- SNMP devices - SNMP OIDs for ipNetToMediaPhysAddress (1.3.6.1.2.1.4.22.1.2), ipNetToPhysicalPhysAddress (1.3.6.1.2.1.4.35.1.4.3.1.4) and atPhysAddress (1.3.6.1.2.1.3.1.1.2).
- SSH devices - "arp -an" and "netstat -rn" commands.
- Windows - "arp -a"
This gives us a reasonably good coverage. Obviously your switches and routers will see the most IPs, so it's important to have SNMP access to those.