User Tools

Site Tools


2_x:datamodel:ip-addresses

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
2_x:datamodel:ip-addresses [2019/10/15 16:58] – [Links between IP Addresses and CIs] cnaud2_x:datamodel:ip-addresses [2021/03/24 16:05] – [Creating a new IP Address] 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 |
 +| History | History of all changes made to the IP |
  
  
Line 63: 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:
-  * "Allocation date" and "FQDN" (Fully Qualified Defined Name) are automatically calculated when the address is created. +  * "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" is computed according to a method defined, by default, at the FunctionalCI level - see [[2_x:datamodel:teemip-config-mgmt#functional_ci|CMDB Core]] chapter,
   * 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> </note>
  
Line 78: Line 83:
  
 At creation time, global settings “Allow Duplicate Names” and “Ping IP before assigning it ?” can be overwritten. Note that a change on these parameters, if any, only applies to the current creation and don’t affect the value of the global parameters. If it is required to change them globally, these can be changed through the [[2_x:datamodel:ip-settings|Global IP Settings]] menu of the Data Administration module. At creation time, global settings “Allow Duplicate Names” and “Ping IP before assigning it ?” can be overwritten. Note that a change on these parameters, if any, only applies to the current creation and don’t affect the value of the global parameters. If it is required to change them globally, these can be changed through the [[2_x:datamodel:ip-settings|Global IP Settings]] menu of the Data Administration module.
- 
-<note> 
-"Global IP Settings" being unique for each organization, the "Global Settings" tab will appear only if an organization has been selected at the top of the explorer menu. 
-</note> 
  
 <note tip> <note tip>
Line 119: Line 120:
 </note> </note>
 <note important> <note important>
-An IP can NOT be allocate to an IP interface that way.+An IP can NOT be allocated to an IP interface that way.
 </note> </note>
  
Line 139: 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 Management attribute and reserved IPs are... reserved,
-  * Reserved IPs are... 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 an 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 150: 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 CIs === +<note important> 
-When a CI becomes obsolete, its IPs can automatically be released from it, as described in the [[2_x:datamodel:teemip-cmdb#obsoleting_cis|related CMDB chapter]]. +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... 
 +</note> 
 + 
 +=== 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  CI is deleted == 
 +  * 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 CI becomes obsolete == 
 +  * Its IPs may automatically be released from it, as described in the related [[2_x:datamodel:teemip_cmdb#obsoleting_cis_with_ips|CMDB chapter]]. 
 + 
 + 
 +=== Releasing IPs === 
 +When an IP is set to the status "Released", it is automatically removed from all CIs and all interfaces. 
 + 
 +=== 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:datamodel:ip-settings|Global IP Settings]]. For any given organization, should the configuration parameter... : 
 +   * "Allocate IPs attached to production CIs" be set, TeemIp will make sure that IPs attached to CIs are "Allocated"
 +   * "Release IPs from CIs that become obsolete" be set, TeemIp will release all IPs that are still allocated to obsolete CIs, 
 +   * "Release IPs from subnets that are released" be set, TeemIp will release all IPs that belong to released subnets. 
2_x/datamodel/ip-addresses.txt · Last modified: 2024/01/26 17:27 by cnaud