/
Domain and Host Name Patterns
Document toolboxDocument toolbox

Domain and Host Name Patterns

Owned by Jyothi KP
Last updated: Aug 01, 2022

This includes the following EAs:

  • Default Domain Name Pattern: This EA is used to control how domain names for IP address allocations are determined. Typically this pattern is used for private networks (not external), but if External Domain Name Pattern is not set, it applies to all network types. This EA can be set to a fixed string, or can use patterns to generate unique zone names. For example, you may set this to cloud.example.com to have all DNS entries within that domain. Or, you can use substitution patterns: {tenant_name}.cloud.example.com would place IPs associated with each tenant in their own domain.
    For domain names, the following patterns are supported:
    — {network_name} is replaced with the OpenStack Network Name.
    — {network_id} is replaced with the OpenStack Network ID.
    — {tenant_name} is replaced with the OpenStack Tenant Name. Note that for this to work, the Tenant Name Persistence EA must be set to True.
    — {tenant_id} is replaced with the OpenStack Tenant ID.
    — {subnet_name} is replaced with the OpenStack Subnet Name.
    — {subnet_id} is replaced with the OpenStack Subnet ID.
    Note that if the Default Domain Name Pattern external attribute includes {tenant_name}, {network_name} or {subnet_name}, you must not change the names of the corresponding objects in OpenStack after they are created. Changing them can result in data synchronization issue.

    The DNS zones are created under a DNS View, the name of which is constructed using the DNS View EA.

  • External Domain Name Pattern: This EA is used to control how domain names for IP address allocations are determined for external networks. If this EA is not set, then Default Domain Name Pattern is used for external networks. The same patterns as those of Default Domain Name Pattern extensible attribute are supported.

  • Default Host Name Pattern: This EA controls host names in a manner similar to the way Default Domain Name Pattern controls domain names. In addition to the patterns supported for domain names, the EA supports:
    — {port_id}. The port ID of the port associated with the IP address.
    — {instance_id}. The Nova instance ID of the VM associated with the port.
    — {instance_name}. The Nova instance name of the VM associated with the port. Note that special characters are not allowed in the instance name.

    — {ip_address}. The IP address for this port or host, with dots replaced by dashes.
    — {ip_address_octet{n}} where n is a number 1-4. This is for IPv4 addresses only. For example, if the pattern is host-{ip_address_octet2}-{ip_address_octet3} and the IP is 10.1.2.3, then the resulting hostname is host-1-2.
    Note that if the host name pattern is set to {instance_name.constant}, then you should not create two instances with the same name in OpenStack as this will create the same DNS host record for both instances.

  • External Host Name Pattern: This EA controls host names in the same way as Default Host Name Pattern, but applies only to hosts allocated in the external network. If External Host Name Pattern EA is not set, Default Host Name Pattern is used for external networks.
    Per NIOS restriction, the domain label must not be longer than 63 characters.

  • Tenant Name Persistence: Since Neutron does not have direct access to tenant names (they are part of Keystone), the Infoblox IPAM agent can cache those names it receives from the message bus. This reduces the Keystone API calls needed to retrieve tenant name. This EA controls this behavior; it must be set to True for tenant name support in domain or host names.

  • IPAM and DHCP/DNS Support: IPAM and DHCP/DNS support can be configured by tuning DHCP Support and DNS Support extensible attributes, which are:

  • DHCP Support: When DHCP support is set to False, and Enable DHCP on Openstack is set to True, dnmasq-based DHCP is used.
    For NIOS DHCP service to function, you should disable the OpenStack DHCP agent using the following command:
    $ openstack network agent set --disable <OpenStack DHCP Agent ID>

  • DNS Support: When set to False, DNS support is disabled. Enabling it allows DNS record generation and DNS protocol. The default value is False.

Currently, the following configurations are supported:

IPAM Only:

  • DNS Support = False
  • DHCP Support = False

Full DHCP/DNS Support:

  • DNS Support = True
  • DHCP Support = True

Creating multiple network views with specific Default Network View Scope EA:

  • DNS Support = True
  • DHCP Support = False/True
    — If the DHCP Support EA is set to False:
    • When the Default Network View Scope EA is set to “Single”, the Grid Master or Grid member are not assigned to the network and multiple networks are created in the default or custom network view.
    • When the Default Network View Scope is set to “Tenant”/”Network”/”Subnet”/”Address Scope”, the Grid Master or Grid member are not assigned to the network, and a network view is added in NIOS for each new network.
    — If the DHCP Support EA is set to True:
    • When the Default Network View Scope is set to “Single”, the Grid Master is assigned to multiple networks in the default or custom network view.
    • When the Grid is standalone and the Default Network View Scope is set to “Tenant”/”Network”/”Subnet”, you can add only one network with the member assigned.
    • When the Grid is standalone with a member and the Default Network View Scope is set to “Tenant”/”Network”/”Subnet”, you can add only two networks: one to the Grid Master and another to the Grid member.

Related content