what you wrote should work in the IPAM. Could you please send me diagnostics and the imported text (list of the subnets and masks) you are trying to import so we can quickly investigate your problem? My email is available through contact details on Thwack.
I can't get your e-mail info from your Contacts page. I think it has something to do with me, not you . . . anyhow, I can be reached at
I will work on putting together the stuff you need asap. I am running a SolarWinds support call in parallel on a CBQoS issue, so it may take me a little while, but I'll get there.
thanks for your help!
I found my problem. Little and stupid, but thought product development might want to know about it.
Here's my scenario:
A supernet subtree that looks like this:
IP Networks (group/folder)
From the supernet tree view pane I select the 10.160.0.0/16 entry.
Then from the Network View, I select Import | Bulk Add Subnets and dump the following list (yes, the word "subnet" is the first line in the list).
On clicking "Parse and Show Results Below", I obtain the result "20 subnet(s) parsed successfully.". I select all of them and click Next.
On the next page I verify that "Move new subnets into the smallest appropriate supernet" is checked, and enter a canary description "(to be loaded)", then click "Done".
None of the subnets were assigned to their correct supernet in this case.
However, when the first line "subnet" is removed from the paste text, all subnets are assigned to their correct supernet.
The "subnet" in my case was getting pasted in as i was performing a copy operation from an Access table into the text field. I have no problem taking that out, obviously . . . but thought you might want to know what it caused.
thanks for your help!
**** . . . I spoke too soon.
It was true, that when I added the first line "subnet" to the output, that my problems began. It is NOT true, however, that when I remove the line, the problems go away. When I remove the line, the Bulk Add Subnets refuses to get the supernet assignment right.
After testing my 10.160.0.0/16 case from above and finding that adding the "subnet" line creates the problem, I went and created a new 10.194.0.0/16 case. On every attempt to add subnets without the "subnet" line, the supernet assignments are still wrong (they are placed in the parent container).
Michal, if you are still watching, I'd love to hear from you.
I'll try to simulate your problem and let you know back!
we are not able to reproduce the issue you described. Could you please contact our support so we can investigate it further?