Are you evaluating or have you purchased? If you have purchased, I would recommend opening a support case as I have not seen this before.
Where do you see the information about the scans timing out? In the event log? How large are your subnets in general? Are you scanning large /8s or standard /24s? Is it just the DHCP jobs or the normal subnets scan (ICMP and SNMP scans against endpoints)?
Im scanning /24's (but alot of them) and its using both ICMP or SNMP...but this just started happening
We have purchased.
Hi twing--
When you open a support ticket, would you:
--Reference this thread to Support.
--Post back here with a case number.
--Post any solutions you get from Support.
Many thx,
M
Following a recent upgrade to the latest version (IPAM 2.0.1), I am now suffering a similar fate.
It appears that there is a hard-code 10 minute timeout on IPAM subnet scans that you can't get to.
And once the subnet gets timed-out the system puts it back into the queue again, which doesn't seem an entirely logical thing to do, as it's likely to continue to timeout. Worse, when it gets put back in the queue it gets prioritised (i.e. its raised to the next job) meaning that you get grid locked once you have 2 failed jobs in succession. Only manual intervention, canceling looping failed jobs will help. You can't re-schedule the job nor (apart from manually failing it) can you send it to the bottom of the queue....grrrrrr.
I've played with the settings and by un-checking "Enable SNMP neighbor scanning" together with reducing the number of scans to 1, and reducing the "Pings per address" to 3 I seem to be getting some subnets through again.
The problem seems to manifests itself with larger subnets, slow devices or a large, highly utilised device (like a stack of 7 Cisco 3750's) .
I've been given a suggestion that breaking the bigger subnet up into smaller logical groups within IPAM might work.
For me it's the next logical thing to try - it's not ideal but would be better than nothing.
Good luck,
Dog
Thanks for a feedbeck.
Does the splitting of large subnets to smaller groups resolve your problem?
Michal Hrncirik, I have deleted all the pre-upgrade subnet details and re-created a smaller set of subnet ranges but I am still getting issues.
Dog
***Subnet Scan Update***
Following the deletion of all pre-ugrade subnet scans and re-creation of a smaller selection of scans (see post above) the issue did not appear to resolve.
However, soon after this change Orion stopped writing to the database requiring me to restart all the Orion services (several times in fact).
Since then all the subnet scans have been processing correctly, albeit with minimally configured scan settings (1 Simultaneous Scans, 1 Pings per Address, 10ms Delay between Pings, 1000ms Ping Timeout, no SNMP scanning, no ).
<edit> Forgot to add, we have deleted all the DHCP servers and as yet have to add them back.
Dog
