This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
2_x:datamodel:ip-addresses [2020/08/12 19:25] – [Links between IP Addresses and CIs] cnaud | 2_x:datamodel:ip-addresses [2024/01/26 17:27] – [Modify an IP Address] cnaud | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== IP Addresses ====== | ====== IP Addresses ====== | ||
- | {{classicon_ipv4address.png }} | + | {{icons8-rj45-48.png }} |
- | {{classicon_ipv6address.png }} | + | {{icons8-rj45v6-48.png }} |
Obviously, IP Address objects in TeemIp modelize addresses of the Internet Protocol. Both version 4 and version 6 are supported. | Obviously, IP Address objects in TeemIp modelize addresses of the Internet Protocol. Both version 4 and version 6 are supported. | ||
Line 19: | Line 19: | ||
| **DNS Information** ||| | | **DNS Information** ||| | ||
| Short Name | Alphanumeric string | No | | | Short Name | Alphanumeric string | No | | ||
- | | Domain | + | | DNS Domain | Foreign key to a(n) Domain |
+ | | DNS View | Foreign key to a(n) View \\ Brought by the [[extensions: | ||
| FQDN | Alphanumeric string | No | | | FQDN | Alphanumeric string | No | | ||
| Aliases | Array of alphanumeric strings | No | | | Aliases | Array of alphanumeric strings | No | | ||
Line 26: | Line 27: | ||
| Range | Foreign key to a(n) IP Range | No | | | Range | Foreign key to a(n) IP Range | No | | ||
| Address | Alphanumeric string | | Address | Alphanumeric string | ||
+ | | **Discovery Information** ||| | ||
+ | | Set of attributes brought by the [[extensions: | ||
<note tip> | <note tip> | ||
- | IP Address Usages are typology elements defined in the Data Administration module. One set of IP Adress Usage needs to be defined per organization. | + | IP Address Usages are typology elements defined in the Data Administration module. One set of IP Address Usages |
</ | </ | ||
<note important> | <note important> | ||
The attribute " | The attribute " | ||
- | * allocated: IP is in use and potentially allocated to a CI. It cannot be re-allocated to another CI without being released or unassigned first. | + | * **Allocated**: IP is in use and potentially allocated to a CI. It cannot be allocated to another CI without being released or unassigned first unless the IP Setting **Allow attachement of already allocated IPs to CIs** is set to **Yes**. |
- | * released: IP is not in use anymore and can be re-allocated if required | + | * **Released**: IP is not in use anymore and can be re-allocated if required |
- | * reserved: IP is not in use yet but will be allocated (activated) at a point in time. It can be allocated from the IP detail menu but is invisible from the CI edition menu. | + | * **Reserved**: IP is not in use yet but will be allocated (activated) at a point in time. It can be allocated from the IP detail menu but is invisible from the CI edition menu. |
- | * unassigned: IP exists in TeemIp without any clear status and can be allocated or reserved. | + | * **Unassigned**: IP exists in TeemIp without any clear status and can be allocated or reserved. |
</ | </ | ||
Line 45: | Line 48: | ||
| NAT IPs | All other IPs linked to this IP in a NAT relationship | | | NAT IPs | All other IPs linked to this IP in a NAT relationship | | ||
| CIs | All the configuration items configured with the IP | | | CIs | All the configuration items configured with the IP | | ||
- | | History | + | | Activity panel | History of all changes made to the IP | |
==== Listing IP Addresses ==== | ==== Listing IP Addresses ==== | ||
- | The IP Addresses shortcuts of the IP Management module on the explorer menu display all the IPv4 or IPv6 Addresses of the selected organization or all IPv4 or IPv6 Addresses if no organization is selected. | + | The IP Addresses shortcuts of the **IP Management** module on the explorer menu display all the IPv4 or IPv6 Addresses of the selected organization or all IPv4 or IPv6 Addresses if no organization is selected. |
- | {{ classlist_ipv4address.png }} | + | {{ classlist_ipv4address-3x.png }} |
- | {{ classlist_ipv6address.png }} | + | {{ classlist_ipv6address-3x.png }} |
<note tip> | <note tip> | ||
The Search tab will shorten the list according to the filtering elements you'll define in it. | The Search tab will shorten the list according to the filtering elements you'll define in it. | ||
</ | </ | ||
+ | |||
==== Creating a new IP Address ==== | ==== Creating a new IP Address ==== | ||
- | From the listing view, click on the “New…” menu to display the creation form. | + | From the listing view or from any create action of an IP Address badge, click on the {{plus-button.png? |
- | {{ classcreate_ipv4address.png }} | + | {{ classcreate_ipv4address-3x.png }} |
An implicit but intuitive set of rules are followed when an IP address is created: | An implicit but intuitive set of rules are followed when an IP address is created: | ||
- | * "Allocation date" | + | * **Allocation date** and **FQDN** (Fully Qualified Defined Name) are automatically calculated when the address is created, |
* If no Subnet is selected, the IP can be any IP of the IPv4 (or IPv6) space, | * If no Subnet is selected, the IP can be any IP of the IPv4 (or IPv6) space, | ||
* If a Subnet and no Range are selected, the address must be included into the Subnet, | * If a Subnet and no Range are selected, the address must be included into the Subnet, | ||
* If a Subnet and a Range are selected, the address must be included into the Range as well, | * If a Subnet and a Range are selected, the address must be included into the Range as well, | ||
- | * When attached to a CI, the "Short Name" | + | * When attached to a CI, the **Short Name** is computed according to a method defined, by default, at the FunctionalCI level - see [[2_x: |
* An IP can be linked to any other registered IP address through the NAT tab. | * An IP can be linked to any other registered IP address through the NAT tab. | ||
<note important> | <note important> | ||
- | 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 **Compute FQDN when short name is empty**, the FQDN may be computed regardless the content of the Short Name and DNS Domain. | ||
</ | </ | ||
<note important> | <note important> | ||
- | Though aliases are linked to FQDNs, they can be created through the IP address creation screen. The "Aliases" | + | Though aliases are linked to FQDNs, they can be created through the IP address creation screen. The **Aliases** box allows IP administrators to create as many aliases |
</ | </ | ||
- | At creation time, global settings | + | At creation time, global settings |
<note tip> | <note tip> | ||
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 “Modify” | + | From the detailed view of an IP Address, click on the {{pen-icon.png? |
Basically, all parameters can be changed here but, of course, the IP address itself. | Basically, all parameters can be changed here but, of course, the IP address itself. | ||
+ | ==== Navigating between adjacent IPs ==== | ||
+ | TeemIp provides an easy and efficient way to navigate between adjacent IPs. If the action is enabled, the left and rights arrows of the object menu {{navigate-icon.png? | ||
+ | |||
+ | < | ||
+ | ' | ||
+ | ... | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ), | ||
+ | ... | ||
+ | ), | ||
+ | |||
+ | </ | ||
+ | |||
+ | ^ Parameter | ||
+ | | enabled| Enable or disable the function | | ||
+ | | within_subnet_only| Limit the navigation to the subnet that the IP belongs to or not | | ||
==== Other Actions ==== | ==== Other Actions ==== | ||
- | Next to standard actions, a set of specific actions can be applied to IP Addresses. These can be found in the “Other Actions” menu available from the details page. | + | Next to standard actions, a set of specific actions can be applied to IP Addresses. These can be found in the **Other Actions** menu available from the details page. |
- | {{details-popup-menu-ipaddressotheractions.png }} | + | {{details-popup-menu-ipaddressotheractions-3x.png }} |
- | {{details-popup-menu-ipaddressotheractions2.png}} | + | {{details-popup-menu-ipaddressotheractions2-3x.png}} |
These specific actions are described in below chapters. | These specific actions are described in below chapters. | ||
- | ==== Allocate | + | ==== Allocate |
This action applies to IP Addresses that are released, reserved or unassigned. Its purpose is to allocate the address to a CI without having to open the modification form of the targeted CI. | This action applies to IP Addresses that are released, reserved or unassigned. Its purpose is to allocate the address to a CI without having to open the modification form of the targeted CI. | ||
- | {{ classallocateip1_ipaddress.png }} | + | {{ classallocateip1_ipaddress-3x.png }} |
Three parameters control the action: | Three parameters control the action: | ||
Line 110: | Line 134: | ||
| IP Attribute | IP attribute of the CI that the IP should be allocate to | Yes | | | IP Attribute | IP attribute of the CI that the IP should be allocate to | Yes | | ||
- | These parameters are automatically computed and may differ from one data model to another. For instance, a server may have only one IP address (it's management IP, like in the standard data model) or multiple ones (a management and a backup IP). Once the CI is selected, TeemIp confirms the operation | + | These parameters are automatically computed and may differ from one data model to another. For instance, a server may have only one IP address (it's management IP, like in the standard data model) or multiple ones (a management and a backup IP). Once the parameters are set and the Apply button |
- | {{ classallocateip2_ipaddress.png }} | + | {{ classallocateip2_ipaddress-3x.png }} |
< | < | ||
Line 121: | Line 145: | ||
</ | </ | ||
- | ==== Un-allocate address from all CI ==== | + | ==== Un-allocate address from all CIs ==== |
- | This action simply | + | This action simply |
- | {{ classunallocateip_ipaddress.PNG }} | + | {{ classunallocateip_ipaddress-3x.PNG }} |
< | < | ||
Line 131: | Line 155: | ||
+ | ==== Management of DNS RRS ==== | ||
+ | <note tip> | ||
+ | The management of the DNS resource records is available if the [[extensions: | ||
+ | </ | ||
+ | === Create / Update DNS RRs === | ||
+ | This action will create the **A / AAAA**, **PTR** and **CNAME** DNS resource records that may be linked to the IP. A few criteria need to be met for this to happen: | ||
+ | * A zone corresponding to the IP's **DNS Domain** and belonging to the right **DNS view** must exist to create the A or AAAA records, | ||
+ | * A reverse zone corresponding to the IP must exist to create the PTR record, | ||
+ | * Each alias must belong to an existing zone in order to create a CNAME record. | ||
+ | |||
+ | === Delete DNS RRs === | ||
+ | This action will just delete all resource records linked to the IP. | ||
- | ==== Links between IP Addresses and CIs ==== | + | ====== Links between IP Addresses and CIs ====== |
TeemIp has been designed to provide a comprehensive modelization and documentation of the link(s) that a CI and an IP address may share together. | TeemIp has been designed to provide a comprehensive modelization and documentation of the link(s) that a CI and an IP address may share together. | ||
Line 138: | Line 174: | ||
* A unique IP can be attached to them, | * A unique IP can be attached to them, | ||
* An IP address must be in the status Released or Unassigned to be attached to a CI, | * An IP address must be in the status Released or Unassigned to be attached to a CI, | ||
- | * IPs that are in state Allocated cannot be set as IP Management attributes, | + | * 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 CI is created or updated, status of attached IP is automatically changed to Allocated, | + | * Once a CI is created or updated, |
- | * If an Management IP is removed from the CI, its status becomes Unassigned unless it is still linked to another CI. | + | * If a Management IP is removed from the CI, its status becomes Unassigned unless it is still linked to another CI. |
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 CI is created or updated, status of attached | + | * Once an interface |
* If a link with an IP address is removed, status of IP moves back to Unassigned unless it is still linked to another CI. | * If a link with an IP address is removed, status of IP moves back to Unassigned unless it is still linked to another CI. | ||
Line 153: | Line 189: | ||
</ | </ | ||
- | === Obsoleting | + | ==== Impact of CIs' life cycle to IPs ==== |
- | When a CI becomes obsolete, its IPs can automatically be released from it, as described in the related | + | Changes on CIs may have an impact on IPs. Here is what happens when... |
+ | === - A Functional CI is created === | ||
+ | * It is checked if the CI has IP Attributes, | ||
+ | * For each of these that do point to an IP: | ||
+ | * Status is set to allocated, | ||
+ | * Short name attribute is computed. | ||
+ | |||
+ | === - A Functional CI is updated === | ||
+ | * It is checked if the CI has IP Attributes, | ||
+ | * For each of these: | ||
+ | * Status of IP is updated if IP has changed (new IP is set to allocated and previous one is set to released), | ||
+ | * Short name is changed if the CI name has changed. | ||
+ | |||
+ | === - A Functional | ||
+ | * It is checked if the CI had IP Attributes, | ||
+ | * For each of these that do point to an IP: | ||
+ | * Status is set to released, | ||
+ | * Short name attribute is reset to empty string. | ||
+ | |||
+ | === - A functional | ||
+ | * Its IPs may automatically be released from it, if IP Setting **Release IPs from CIs that become obsolete** is set. | ||
+ | |||
+ | |||
+ | ==== Releasing IPs ==== | ||
+ | When an IP is set to the status " | ||
+ | |||
+ | ==== 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: | ||
+ | |||
+ | * **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, | ||
+ | * **Un-allocate IPs that are not attached to a CI** (*) be set to **Yes**, TeemIp will unassign the IPs that are no longer 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, | ||
+ | * **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. | ||
+ | |||
+ | The 3 first actions (*) are handled by background tasks which default parameters can be overwritten in the configuration file. | ||
+ | |||
+ | < | ||
+ | ' | ||
+ | ... | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | 0 => ' | ||
+ | 1 => ' | ||
+ | ), | ||
+ | ), | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | 0 => ' | ||
+ | ), | ||
+ | ), | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ' | ||
+ | ), | ||
+ | ... | ||
+ | ), | ||
+ | |||
+ | </ | ||
- | === IP status coherency check === | + | ^ Parameter |
- | 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: | + | | enabled| Enable or disable |
- | * " | + | | debug | Add verbosity |
- | * " | + | | periodicity | Periodicity of the background task | |
- | * " | + | | status_list | List of status |
+ | | target_status | Status of the IP once the action is done | | ||
+ | Please, refer to the [[2_x: |