Differences

This shows you the differences between two versions of the page.

--- guides:reference:infoblox:ipam_tree [2019/12/23 16:48] – ↷ Page moved from guides:reference:infoblox:dns:ipam_tree to guides:reference:infoblox:ipam_tree yspeerte
+++ guides:reference:infoblox:ipam_tree [2024/07/03 12:31] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+{{indexmenu_n>2}}
+===== IPAM Tree =====
+To define the IPAM / DHCP tree for an ip-plan, the table ''NMS.Dhcp_tree'' must be created and filled. since this table is a "custom" table, it is for the customer to maintain it. Common SQL management tools can be used to create the tables and maintain them.
+The credentials to access the netYCE databases with read-write permissions: \\
+username: ''touchup'' \\
+password: ''mmtwga'' \\
+The credentials to access the netYCE databases with read-only permissions: \\
+username: ''justread'' \\
+password: ''gmngmhhw'' \\
+The 'root' user and password is generally not shared with customers, but for the purpose of creating and modifying tables in the NMS database a customer-specific 'root-like' user can be created on request.
+==== Custom DHCP Tables ====
+Three tables are required for the Infoblox DHCP / IPAM functionality that all reside in the ''NMS'' database.
+The ''**Dhcp_tree**'' table contains a tree definition per ip-plan. Each row in the table defines a container, network or scope and has columns that define its attributes and position in the hierarchy. It is maintained manually by the application manager.
+The ''**Dhcp_history**'' table contains the XML definition of a full supernet as it was last successfully used in an IPAM/DHCP create or update. It is used as a shadow administration of the Infoblox IPAM supernet configuration. This is a necessity because the Infoblox API is too slow to extract all relevant information in order to locate the differences between the life IPAM and the generated IPAM. This table is fully maintained by the NetYCE Infoblox integration module.
+The ''**Dhcp_clients**'' table contains many variables that are assigned in the various DHCP scopes and networks that are specific to a Client. Per ClientCode one row is added manually by the application manager.
+BASE TABLE: NMS.Dhcp_tree
+<code sql>
+CREATE TABLE `NMS`.`Dhcp_tree` (
+  `Dhcp_id` int(11) NOT NULL AUTO_INCREMENT,
+  `Plan_id` int(11) NOT NULL DEFAULT '0',
+  `Net_name` varchar(20) DEFAULT '',
+  `Net_offset` varchar(20) DEFAULT '',
+  `Net_mask` varchar(20) DEFAULT '',
+  `Net_size` int(11) DEFAULT '24',
+  `Net_tier` int(11) NOT NULL DEFAULT '1',
+  `Net_type` varchar(20) DEFAULT '',
+  `Net_index` int(11) DEFAULT '0',
+  `Scope_start` varchar(20) DEFAULT '',
+  `Scope_end` varchar(20) DEFAULT '',
+  `Dhcp_options` varchar(50) DEFAULT '',
+  `Features` varchar(200) DEFAULT '',
+  `Net_remark` varchar(100) DEFAULT '',
+  `Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+  PRIMARY KEY (`Dhcp_id`),
+  KEY `Net_index` (`Plan_id`,`Net_name`,`Net_index`),
+  KEY `Net_name` (`Plan_id`,`Net_name`)
+) ENGINE=MyISAM AUTO_INCREMENT=1000 DEFAULT CHARSET=utf8
+</code>
+BASE TABLE: NMS.Dhcp_history
+<code sql>
+CREATE TABLE `NMS`.`Dhcp_history` (
+  `Supernet` varchar(20) NOT NULL DEFAULT '',
+  `Xml_data` longtext,
+  `Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+  PRIMARY KEY (`Supernet`)
+) ENGINE=MyISAM DEFAULT CHARSET=utf8
+</code>
+BASE TABLE: NMS.Dhcp_clients
+<code sql>
+CREATE TABLE `NMS`.`Dhcp_clients` (
+  `ClientCode` varchar(30) NOT NULL DEFAULT '',
+  `Lease_time` int(11) NOT NULL DEFAULT '0',
+  `Ddns_enable` int(11) NOT NULL DEFAULT '0',
+  `Dhcpsrv1_feature` varchar(20) DEFAULT '',
+  `Dhcpsrv2_feature` varchar(20) DEFAULT '',
+  `Domain1_feature` varchar(50) DEFAULT '',
+  `Domain2_feature` varchar(50) DEFAULT '',
+  `Domain3_feature` varchar(50) DEFAULT '',
+  `Lease1_feature` int(11) NOT NULL DEFAULT '0',
+  `Lease2_feature` int(11) NOT NULL DEFAULT '0',
+  `Dns_pri` varchar(20) DEFAULT '',
+  `Dns_sec` varchar(20) DEFAULT '',
+  `Dns_tert` varchar(20) DEFAULT '',
+  `Wins_pri` varchar(20) DEFAULT '',
+  `Wins_sec` varchar(20) DEFAULT '',
+  `Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+  PRIMARY KEY (`ClientCode`)
+) ENGINE=MyISAM DEFAULT CHARSET=utf8
+</code>
+==== Tree Objects ====
+In an IPAM/DHCP tree three types of objects are used to build a structured, hierarchical representation of an ip-space called supernet. The tree consists of "containers", "networks" and "scopes".
+The "containers" serve no technical purpose but provide an elegant way to group network and scope objects. They are created to provide aggregation and therefore have an prefix and netmask.
+The "networks" form the actual IPAM ip-space allocation and are identical to subnets. They are the purpose of the IPAM. Multiple networks are usually grouped in a container'.
+The "scopes" objects form the DHCP ranges and are associated with a "network". Multiple scopes can exist in a network.
+The definition of a IPAM/DHCP tree is closely related to the definition of an IP-plan. The tree is structured around the subnets defined in the supernet's ip-plan. Where the ip-plan laid down the "networks", the IPAM tree will envelop them in appropriate hierarchical containers and add the scopes where desired.
+Along with structuring the ip-plan's supernet, the tree will therefore add the DHCP scopes and assign the DHCP options. These DHCP options can be assigned to both networks and scopes since Infoblox allows inheritance of most options.
+==== Tree Tiers ====
+To represent the hierarchy of each object in the tree, a "tier" is used. The supernet itself always has tier ''0'' assigned. For each level deeper the tier is increased by one. So a container grouping for example all 'user' subnets has tier ''1'' and those 'user' networks have tier ''2''. Any scopes for those 'user' subnets have tier ''3'' and so on. The tree can co as deep as circumstances demand.
+To allow supernets to be grouped the tier can also be made negative - but only for "containers". A tier of ''-1'' groups a certain level of aggregation of supernets in a container, which might itself be grouped in a higher level of aggregation using a container of level ''-2''.
+The example below shows how a simple tree is created using two groups of subnets, 'Users' and 'IPT'. The containers of the 'users' and the 'IPT' uses a /21 aggregation but start at different offsets from the starting-address of the supernet.
+^  Net_tier  ^  Net_index  ^ Net_type ^ Net_name ^ Net_offset ^  Net_size  ^
+|  -3  |  | container | Customer networks | 0.0.0.0 |  8  |
+|  -2  |  | container | Aggregation | 0.0.0.0 |  12  |
+|  -1  |  | container | Aggregation | 0.0.0.0 |  16  |
+|  0  |  | container | Supernet | 0.0.0.0 |  18  |
+|  1  |  | container | Users | 0.0.0.0 |  21  |
+|  2  |  0  | net | Users |  |  |
+|  3  |  0  | scope | Users |  |  |
+|  2  |  1  | net | Users |  |  |
+|  3  |  1  | scope | Users |  |  |
+|  2  |  2  | net | Users |  |  |
+|  3  |  2  | scope | Users |  |  |
+|  2  |  3  | net | Users |  |  |
+|  3  |  3  | scope | Users |  |  |
+|  1  |  | container | IPT | 0.0.8.0 |  21  |
+|  2  |  0  | net | IPT |  |  |
+|  3  |  0  | scope | IPT |  |  |
+|  2  |  1  | net | IPT |  |  |
+|  3  |  1  | scope | IPT |  |  |
+|  2  |  2  | net | IPT |  |  |
+|  3  |  2  | scope | IPT |  |  |
+|  2  |  3  | net | IPT |  |  |
+|  3  |  3  | scope | IPT |  |  |
+==== Network Index ====
+In the example above, the ''net'' and ''scope'' object types did not have their network offset or prefixes defined in the tree. But they do have an ''Index'' assigned.
+This "index" is what links the network object to the subnet of the ip-plan. Where the network name and index of the tree and ip-plan match, these details become automatically available for the tree.
+The example tree above was built around this (partial) ip-plan.
+^ Net_name ^ Net_index ^ Net_size ^ Net_offset ^ Net_range ^
+| Users |  0  |  25  | 0.0.0.0 | 0.0.0.127 |
+| Users |  1  |  25  | 0.0.0.128 | 0.0.0.255 |
+| Users |  2  |  25  | 0.0.1.0 | 0.0.1.127 |
+| Users |  3  |  25  | 0.0.1.128 | 0.0.1.255 |
+| IPT |  0  |  25  | 0.0.8.0 | 0.0.8.127 |
+| IPT |  1  |  25  | 0.0.8.128 | 0.0.8.255 |
+| IPT |  2  |  25  | 0.0.9.0 | 0.0.9.127 |
+| IPT |  3  |  25  | 0.0.9.128 | 0.0.9.255 |
+The tree can have subnets and scopes defined that are not part of the ip-plan. But then these details need to be added to the tree. Likewise, the tree does not need to have to include all subnets in the ip-plan. As in the case of a large range of Loopback /32 "subnets", the IPAM is better served with a container or a single aggregation subnet for all the loopbacks.
+==== Scope ranges ====
+The definition of the DHCP scopes is not complete until the dhcp range is added. The offsets for the first and the last ip-address of each scope must be added. Their values must reside within the subnet itself. If more than one scope is added to a subnet, their ranges may not overlap.
+If the Scope_start or Scope_end is missing default values will be calculated. The default Scope_start is ''0.0.0.2''. The default Scope_end is calculated by subtracting 2 addresses from the network range.
+^  Net_tier  ^  Net_index  ^ Net_type ^ Net_name ^ Net_offset ^  Net_size ^ Scope_start ^ Scope_end ^
+|  1  |    | container | IPT | 0.0.8.0 |  21  |  |  |
+|  2  |  0  | net  | IPT |    |    |    |   |
+|  3  |  0  | scope  | IPT |    |    | 0.0.0.6 | 0.0.0.126 |
+|  2  |  1  | net  | IPT  |    |    |    |   |
+|  3  |  1  | scope  | IPT |    |    | 0.0.0.6 | 0.0.0.126 |
+|  2  |  2  | net  | IPT |    |    |    |   |
+|  3  |  2  | scope  | IPT |    |    | 0.0.0.6 | 0.0.0.126 |
+|  2  |  3  | net  | IPT |    |    |    |   |
+|  3  |  3  | scope  | IPT |    |    | 0.0.0.6 | 0.0.0.126 |
+==== DHCP Options ====
+The final part of the tree definition is the assignment of the required DHCP options and their values. This is a complex topic in itself, requiring a separate article.
+> <color blue> See the detailed article on [[guides:reference:infoblox:dhcp_options|DHCP options]] configuration </color>
+//