There are a few areas in Discovery that are also quite powerful, and misusing them can have some unhappy consequences (though nothing so horrible as, say, a misused shotgun!). There's one such area in particular that folks have stumbled into several times, so it's worth a brief discussion.
That "dangerous" area is the Discovery IP Ranges, which I've posted about before. The thing to watch out for is specifying a range that's too large (this is especially easy when specifying IP Ranges and IP Networks). To illustrate, I'll use a memorable example that someone tried a few months ago.
This fellow said to himself (as he told me later):
"Hmmm... I want to discover everything on our network, and we use 10-dot IP addresses for everything, so I'll make this easy on myself — I'll just enter a single IP Network range of 10.0.0.0/8!"
What could possibly be wrong with that, right? Well, for starters let's consider the sheer size of that range: 16,777,214 IP addresses (that's 2^24 - 2, for the mathematically inclined). It takes a couple of seconds to ping each IP address, so to ping that entire range would take just over a year — probably not the desired result. With our new chunky ping feature, as devices were found they'd be explored — but unless your organization is awfully big, very few of those 16 million IP addresses are going to be in use. Most of that pinging will be just wasted time, because the reality (almost certainly) is that your actual devices occupy a well-defined (and much smaller!) piece of that IP address space. You would be much better served by defining IP address ranges that actually correspond to where your devices are.
There's another problem as well, one that you need to know just a bit about networking to understand. This problem is caused by specifying IP ranges that cross subnet boundaries. Every organization I've ever seen that uses the private 10-dot IP address space subnets it, meaning that they divide the giant class "A" 10-dot into many smaller sub-networks. Most common (but by no means universal) is to divide the 10-dot space into many class "C" networks (/24s, or masks of 255.255.255.0); this is convenient and easy to understand. But here's the important bit: each of those subnets will have its own broadcast and network addresses, and pinging one of these addresses can have … interesting … consequences.
For example, suppose your organization used the 10-dot space, but subnetted to /24s. You might then have a subnet defined as 10.0.100.0/24. That subnet's network address is 10.0.100.0, and its broadcast address is 10.0.100.255. Now suppose you defined an IP range for discovery of 10.0.0.0/24, as in my example above. Eventually the MID server would get around to pinging 10.0.100.0, and later, 10.0.100.255. When it does, every device on that entire subnet will respond to the broadcast address (and many will also respond to the ping of the network address). Discovery will then believe there is a device at that address, and begin exploring it with other probes. Once again, as it works, every device on that entire subnet will listen and respond, producing some really strange results. For example, an SNMP query to a broadcast address will cause every SNMP device on that subnet to respond — and Discovery will think there's a very strange device out there! Bottom line: don't include broadcast or network addresses for subnets within your Discovery IP ranges.
With power comes responsiblity… Discovery's IP ranges don't have sharp edges, bullets, or bombs — but it's still worthwhile being very careful when you specify them, lest you end up with (a) very long-lasting discoveries, or (b) very odd devices in your CMDB!
