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 [2019/12/05 16:19] – [Creating a new IP Address] cnaud | 2_x:datamodel:ip-addresses [2022/10/26 14:33] – [Links between IP Addresses and CIs] cnaud | ||
---|---|---|---|
Line 42: | Line 42: | ||
| Contacts | All the contacts for this IP | | | Contacts | All the contacts for this IP | | ||
| Documents | All the documents linked to this IP | | | Documents | All the documents linked to this IP | | ||
+ | | Notifications | List of related notifications - Present if a notification trigger exists for that class | | ||
| 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 | | ||
Line 64: | Line 65: | ||
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: | ||
- | * " | + | * " |
- | * 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" 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 " | ||
</ | </ | ||
Line 116: | Line 120: | ||
</ | </ | ||
<note important> | <note important> | ||
- | An IP can NOT be allocate | + | An IP can NOT be allocated |
</ | </ | ||
Line 136: | Line 140: | ||
* 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 and reserved |
- | * Reserved | + | |
* Once CI is created or updated, status of attached IP is automatically changed to Allocated, | * Once CI is created or updated, status of attached IP is automatically changed to Allocated, | ||
- | * If an IP 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: | ||
Line 147: | Line 150: | ||
* 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. | ||
- | === Obsoleting | + | <note important> |
- | When a CI becomes obsolete, its IPs can automatically be released from it, as described in the [[2_x: | + | You may alter this default datamodel through an extension and add, for instance, a backup IP to your servers. There is no limitation to what you can do here... |
+ | </ | ||
+ | |||
+ | === Impact of CIs' life cycle to IPs === | ||
+ | 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 has 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, as described in the related | ||
+ | |||
+ | |||
+ | === Releasing IPs === | ||
+ | When an IP is set to the status " | ||
+ | |||
+ | === Continuous IP status coherency check === | ||
+ | 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: | ||
+ | * " | ||
+ | * " | ||
+ | * " |