This tool allows the operator to create and update the Infoblox IPAM and DHCP configuration for one or multiple Clients. Two main prerequisites have to be met to accomplish this automatic IPAm and DHCP configuration.
First the Client must use subnets / vlans that were assigned using the NetYCE internal IPAM using Supernets. These supernets may or may not be “owned” (i.e. assigned to) the Client, or may be “shared” across many Clients.
Second, for each of the Supernets that must result in Infoblox IPAM / DHCP entries, a corresponding IPAM “tree” for the Ip-plan of that Supernet must be defined. These IPAM trees are defined in the database table
NMS.DHCP_tree and consists of a hierarchical ordering of the supernet's subnets, grouped using “containers” and extended with DHCP “scopes” (or “ranges” as they are named by Infoblox). The IPAM tree's subnets are “network” components that can be mapped to the supernet's subnets, but are not necessarily limited to these subnets.
See the detailed article on IPAM Tree construction
Apart of the IPAM tree configuration and supernet mapping, the operator can also assign DHCP options that need to be configured. DHCP options can be assigned to both “networks” and “scopes” using inheritance. These option are assigned appropriate DHCP option names and values and can be manipulated using several methods. Client-specific values can be defined in the
See the detailed article on DHCP options configuration
The Infoblox integration is setup using the configuration file “YCE Infoblox integration” available through the “Admin - System - Edit configs” tool and uses the file
This configuration file defines:
The IPAM DHCP tool will after selection of the desired Supernets create a highly detailed IPAM and DHCP tree for each of these supernets and configure that tree in the Infoblox Gridmaster's IPAM. This detailed data-structure contains ALL information to be stored in that tree: Containers, Networks, Ranges, DHCP Options, Grid Members, Extended Attributes, Custom DHCP Options, etc. In itself that data-structure is IPAM-vendor agnostic and can be applied to another vendor given the proper API and code to translate and provision it. So far, we support Infoblox only.
The first step in the process is selecting the Clients, Sites or Supernets. The operator can select ClientCodes using the
« buttons. This will result in selecting the Supernets of those clients - but only those for which exists a corresponding IPAM tree in the
NMS.DHCP_tree table (and the supernet prefix is < 30).
Alternatively, the operator can type the ClientCodes directly in the textbox and append the entries to the list using the
Add list button. When entering a SiteCode the corresponding Client is being added. But, when an Supernet address is typed, only the Supernet is added (although all ClientCodes that use that supernet are shown in the selection list)
By selecting the ClientCodes in the selection list, the next step will set the initial values of the checkboxes for those clients and their supernets. Otherwise the operator will have set those selections manually.
By default the checkbox for the Client is unset. Only when this checkbox is set will those of the supernets of that client be enabled. Then the supernets can individually be included or excluded by setting their checkboxes.
Select all clients will set the checkboxes for all clients. The individual supernet checkboxes will be (re-)enabled and keep their settings. Only those clients where the no supernet was checked will now have all their supernets reactivated.
Should a client have no supernets (with an associated dhcp-tree), its client checkbox will be permanently disabled.
By default the IPAM/DHCP tree action is
Update. It requires “Manager” level privileges to change the action to
Renew. Where the “Update” will update all variables for the IPAM tree of that supernet, the “Renew” can rebuild the tree from scratch. The Update is much faster since it will not create containers or networks, only update their variables. But is will add “Scopes” because that action is required to activate newly allocated and activated subnets.
The “Renew” first deletes the entire supernet IPAM tree in the GridMaster. It does so by creating a new container using the supernet's address and prefix and then deleting it. Once gone, the new tree is built from scratch, adding containers, networks and scopes. Because of this higher risk of unanticipated data loss requires this option the higher privileges.
The “Restart DHCP service” checkbox controls the resynchronization and restarting of the DHCP service on the designated DHCP GridMembers. When checked, the new scopes and/or updated variables (along with all their options!) are pushed to the dhcp servers and their process restarted. Although repeated use of this options is valid and safe, it is considered costly in terms of processing. When an operator is aware many additional DHCP updates will follow this job, he should consider deselecting this checkbox.
For similar reasons can the ip-address of the GridMaster not be changed unless the operator has “Engineer” privileges.
For each supernet the Prefix is shown and the description of the Ip-plan the supernet is assigned to. The column “Shared” will be blank for the common supernet as it is uniquely assigned to a client. Only when a supernet is assigned to multiple clients will the
shared column show the number of clients that share it.
When the IPAM tree information is created for a supernet, it uses the indicated client as the default context, i.e. it uses the client-specific variables from that client. But in case of a shared supernet where each subnet may be assigned to another client, that would result in the wrong settings. So when collecting the superent data, the context will be adjusted to the client it was assigned to. Only where no assignment was made will de default client take precedence.
The resulting IPAM data structure is therefore in essence independent of the client the IPAM/DHCP job is created for. Including a supernet more than one in such a job will only result in updating (or creating) the same IPAM tree multiple times.
When the DHCP/IPAM front-end tool detects a shared supernet it will only include checkboxes for the first client it is included in. All subsequent entries for that supernet will have their checkboxes removed.
So, should the operator wish to update or renew the IPAM tree for a shared supernet, it will suffice create a IPAM/DHCP job for one client with the shared supernets checked. The tool with then update all the clients' supernets and update the complete shared superent as well.
Or, the operator can type the shared supernets directly in the text box and create a job that will only update the shared supernets.
The resulting selection shows all clients involved, but only one entry per supernet can be enabled. Selecting only the top client or all clients makes no difference in the executed job.
It is allowed to mix supernets, clientcodes and sitecodes when typing entries in the text box.
Two distinct modes to execute a job are available: directly on screen or scheduled. Where previously only the direct method was supported, we now have included all the scheduler options as well.
The 'direct on screen' option is available as the
View now button. It will perform in real time and on-screen the data collection (using a NetYCE API transaction) and then execute the actions on the GridMaster using the Infoblox API.
A “Change-id” may be visible, optional or mandatory depending on the tool-setup. This same setup also controls whether the job will require an Approval or not.
Currently, the “Verbose” flag has no effect, the job log contains full details only. The logging information is identical in the “View now” or “Scheduled” mode.