2_x:datamodel:ip-addresses
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| 2_x:datamodel:ip-addresses [2023/10/03 13:42] – [Automation] cnaud | 2_x:datamodel:ip-addresses [2026/01/21 15:51] (current) – [Automation] cnaud | ||
|---|---|---|---|
| Line 35: | Line 35: | ||
| <note important> | <note important> | ||
| The attribute " | The attribute " | ||
| - | * **Allocated**: | + | * **Allocated**: |
| - | * **Released**: | + | * **Released**: |
| * **Reserved**: | * **Reserved**: | ||
| - | * **Unassigned**: | + | * **Unassigned**: |
| + | |||
| + | If [[extensions: | ||
| </ | </ | ||
| Line 79: | Line 81: | ||
| By definition, FQDNs are absolute domain names. They specify the exact location of domain names in the tree hierarchy of the Domain Name System (DNS). This is why they end up with a dot.\\ | By definition, FQDNs are absolute domain names. They specify the exact location of domain names in the tree hierarchy of the Domain Name System (DNS). This is why they end up with a dot.\\ | ||
| \\ | \\ | ||
| + | According to configuration parameter **Allow Duplicate Names**, unicity of the FQDN is checked: | ||
| + | * Duplicates may exist in different organizations, | ||
| + | * Within an organization, | ||
| + | * If parameter is set to: | ||
| + | * **No**, all other cases of duplicates are rejected, | ||
| + | * **Dual stack**, duplicates may exist between IPv4 and IPv6 spaces, | ||
| + | * **Yes**, unicity of FQDN is not verified. | ||
| + | |||
| According to configuration parameter **Compute FQDN when short name is empty**, the FQDN may be computed regardless the content of the Short Name and DNS Domain. | According to configuration parameter **Compute FQDN when short name is empty**, the FQDN may be computed regardless the content of the Short Name and DNS Domain. | ||
| </ | </ | ||
| Line 91: | Line 101: | ||
| For v6 IPs, a simple autocompletion mechanism is used to help typing the IP: its first 64 bits are copied from the subnet IP… which can, of course, be manually changed by the user. | For v6 IPs, a simple autocompletion mechanism is used to help typing the IP: its first 64 bits are copied from the subnet IP… which can, of course, be manually changed by the user. | ||
| </ | </ | ||
| - | ==== Modify | + | ==== Modifying |
| From the detailed view of an IP Address, click on the {{pen-icon.png? | From the detailed view of an IP Address, click on the {{pen-icon.png? | ||
| Line 176: | Line 186: | ||
| * IPs that are in state Allocated cannot be set as IP attribute unless IP setting **Allow attachment of already allocated IPs to CIs** is set to **Yes**, | * IPs that are in state Allocated cannot be set as IP attribute unless IP setting **Allow attachment of already allocated IPs to CIs** is set to **Yes**, | ||
| * Reserved IPs are... reserved, | * Reserved IPs are... reserved, | ||
| - | * Once a CI is created or updated, the status of its attached IP is automatically changed to Allocated, | + | * Once a CI is created or updated, the status of its attached IP is automatically changed to **Allocated**, |
| - | * If a Management IP is removed from the CI, its status becomes | + | * If a Management IP is removed from the CI, its status becomes |
| Some others CIs, like IP interfaces attached to routers, may host several IP addresses. For them: | Some others CIs, like IP interfaces attached to routers, may host several IP addresses. For them: | ||
| * One or more IPs (with no limitation of quantity) can be attached to them, | * One or more IPs (with no limitation of quantity) can be attached to them, | ||
| * An IP can be attached to them, regardless their status, | * An IP can be attached to them, regardless their status, | ||
| - | * Once an interface is created or updated, the status of its attached IPs is automatically changed to Allocated, | + | * Once an interface is created or updated, the status of its attached IPs is automatically changed to **Allocated**, |
| - | * If a link with an IP address is removed, status of IP moves back to Unassigned | + | * If a link with an IP address is removed, status of IP moves back to **Released** |
| <note important> | <note important> | ||
| Line 214: | Line 224: | ||
| ==== Releasing IPs ==== | ==== Releasing IPs ==== | ||
| - | When an IP is set to the status " | + | When an IP is set to the status " |
| ==== Automation ==== | ==== Automation ==== | ||
| When linking an IP together with a CI, one must insure that both the CI's and the IP's status are consistent. TeemIp may automatically and periodically check the status of IPs and their coherency with the CIs they are attached to, if any. This behaviour is driven by a set of parameters defined in [[2_x: | When linking an IP together with a CI, one must insure that both the CI's and the IP's status are consistent. TeemIp may automatically and periodically check the status of IPs and their coherency with the CIs they are attached to, if any. This behaviour is driven by a set of parameters defined in [[2_x: | ||
| - | * **Allocate IPs attached to production CIs** be set to **Yes**, TeemIp will make sure that IPs attached to CIs are " | + | * **Allocate IPs attached to production CIs** (*) be set to **Yes**, TeemIp will make sure that IPs attached to CIs are " |
| - | * **Release IPs from CIs that become obsolete** be set to **Yes**, TeemIp will release all IPs that are still allocated to obsolete CIs, | + | * **Release IPs from CIs that become obsolete** |
| + | * **Un-allocate IPs that are not attached to a CI** (*) be set to **Yes**, TeemIp will unassign the IPs that are not attached to a CI, | ||
| * **Release IPs from subnets that are released** be set to **Yes**, TeemIp will release all IPs that belong to released subnets, | * **Release IPs from subnets that are released** be set to **Yes**, TeemIp will release all IPs that belong to released subnets, | ||
| * **Allow attachment of already allocated IPs to CIs** be set to **Yes**, TeemIp will allow, from the CI details screen, the attachment of an allocated IP to a CI. | * **Allow attachment of already allocated IPs to CIs** be set to **Yes**, TeemIp will allow, from the CI details screen, the attachment of an allocated IP to a CI. | ||
| + | * **Detach released IPs from CIs** be set to **Yes**, TeemIp will detach IPs which status moves to " | ||
| - | These actions are handled by background tasks which default parameters can be overwritten in the configuration file. | + | The 3 first actions |
| < | < | ||
| ' | ' | ||
| ... | ... | ||
| - | 'ip_release_on_ci_status' => array ( | + | 'ip_allocate_on_ci_status' => array ( |
| ' | ' | ||
| ' | ' | ||
| ' | ' | ||
| ' | ' | ||
| - | 0 => 'obsolete', | + | 0 => 'implementation', |
| + | 1 => ' | ||
| ), | ), | ||
| ), | ), | ||
| - | 'ip_allocate_on_ci_status' => array ( | + | 'ip_release_on_ci_status' => array ( |
| ' | ' | ||
| ' | ' | ||
| ' | ' | ||
| ' | ' | ||
| - | 0 => 'implementation', | + | 0 => 'obsolete', |
| - | 1 => ' | + | |
| ), | ), | ||
| ), | ), | ||
| Line 264: | Line 276: | ||
| | target_status | Status of the IP once the action is done | | | target_status | Status of the IP once the action is done | | ||
| + | Please, refer to the [[2_x: | ||
2_x/datamodel/ip-addresses.1696340557.txt.gz · Last modified: by cnaud