07-14-2016 07:35 AM
When I look at the WAPI documentation, it informs me that the Network object is a DHCP construct, while I feel it should be more of an IPAM construct. Perhaps this is a misprint, or maybe I'm just looking at it improperly.
My rationale/isue is as follows:
1) It behooves an organization to track ALL of their IP address usage from one place, regardless of whether or not given subnets, ranges or scopes utilize DHCP or not. (Captain Obvious on the job!)
2) Given this above goal, my approach for an organization would be to catalog all of the publicly assigned IP space, both IPv4 and IPv6, as well as any RFC 1918 address space, and create them as IPAM networks. At present, this type of data is kept in in a flat file somewhere, which I believe most people would agree, is not optimal or scalable. (Smaller shops may disagree. Fine. Try to manage multiple /16s and/or a /8 with Excel.)
3) Once ALL IP space is created, then individual networks can be cut into subnets and ranges, etc, and some of those might be utilized for DHCP. (But what about the yet-to-be allocated?)
4) This all seems to flow via the GUI, in that I have an IPAM view AND a DHCP view, and one can ascertain visually a great deal of context from the GUI.
5) The context is much less clear if I wish to employ a CLI, API, or CSV Import. For instance, I'd like to create a network and assign an "owner" to the network at an IPAM level. While I understand that the actual fields needed could be created as extensible attributes to an object, the fact remains that the documentation states that the network object is a DHCP-based object and not an IPAM-based object.
My use case would involve such mundane tasks as:
1) Identifying one or more (all?) networks owned by a certain individual, or having a particular status, such as UNALLOCATED, UNUSED, FREE, AVAILABLE, etc.
2) Identifying an IP address to be assigned to a host
3) Identifying a span of available IP addresses from a subnet. (I wont use the word "range" here, as "range" has special DHCP meaning to me, and the API, as far as I can tell.
I'd like to be able to perform these tasks via API, but the API, as documented, does not appear to operate on networks that are NOT DHCP oriented.
I believe all of the above is workable, but the documentation, as I view it, doesn't really state as much. Can somebody correct or clarify my way of looking at things here?
In a perfect world, my preferred view would be to enter in my networks as ARIN assigned them. In my current role, this would entail two /16s of public space. It would also include several smaller public blocks as assigned by ARIN and various ISPs, as well as the 10/8 network, 172.16/12, and 192.168/16, and a couple of IPv6 blocks.
Under that umbrella, I'd be able to break the networks up into individual subnets, and this would be recursive. Thus, 10/8 would be a root container. 10.0.0.0/12 might be "US Network", 10.0.0.0/16 might be "US Site 4", and 10.0.0.0/20 "might be "US Site 4 Web Farm", and so on... All of these various levels could be reported upon, and this hierarchical structure could be readily viewed graphically. I do not believe this is possible with the current product set (7.3), which includes Network Insight.
Can somebody provide me with some guidance?
Solved! Go to Solution.
07-14-2016 10:50 AM
TL;DR - create a DHCP network, but don't assign it to any grid members. That will create an IPAM network.
All objects in NIOS have to relate to one of the protocol engines (DNS,DHCP,File, etc) so networks are fundamentally DHCP objects, and zones are fundamentally DNS objects.
The IPAM view is just a synthetic overlay to the protocol level data, it was added as a way to see all objects that relate an address, but it is logically a ReadOnly view to the DNS & DHCP data.
So your steps 2 & 3 are correct, and what you should do to create an IPAM database, it's just the creation of the object that is indirect.
If you want an 'IPAM only' network, you just need to create a DHCP network that isn't participating in DHCP.
The best way to do that is to create a network that isn't assigned to any members. This will remove it from any DHCP configurations and it will just linger in the IPAM view.