Using hostnames in the management network

Introduction

The topology of an NFM-P management network may be sufficiently complex to benefit from or require the use of hostnames, rather than fixed IP addresses, for communication between NFM-P components. Hostname resolution is of even greater benefit when NAT is used between NFM-P clients and a main server.

Also, some CA signing authorities accept only hostnames, and not IP addresses, in the SAN field of a signed TLS certificate.

Note: If the SAN field of a signed certificate includes only hostnames, when you use the samconfig utility to configure client access on a main server, you must specify a hostname, rather than an IP address.

Note: In the client section of samconfig on the NFM-P main servers, if the address for client access is set using the hostname parameter, the primaryIp and standbyIp values in the nfmp section of the NSP configuration file, nsp-config.yml, must be set to hostnames.

Likewise, if the public-ip parameter in the client section is configured on the main server, the primaryIp and standbyIp values in the nsp-config.yml file must be set to IP addresses.

Note: If a TLS certificate to be signed by a public CA includes a hostname, the hostname must be an FQDN and not a short hostname. A self-signed certificate can use an FQDN or a short hostname.

Hostname configuration requirements

Only local hostname lookup is supported for NFM-P and NSP component hostname resolution. You can use a DNS server to resolve the addresses of non-NSP components such as OSS or external systems.

To enable hostname resolution in an NFM-P management network, you must do the following:

• Configure the /etc/hosts file on each component to ensure that each hostname translates to the correct IP address; the hostname must:

  • contain only ASCII alphanumeric and hyphen characters.

  • not begin or end with a hyphen.

  • not begin with a number.

  • comply with the format defined in IETF RFC 1034.

  • use period characters to delimit the FQDN components.

  • not exceed 63 characters.

• During component deployment, specify hostnames instead of IP addresses.

Note: A hostname is case-sensitive.

Note: A component hostname that you specify in an /etc/hosts file must be the exact hostname returned by the following command:

hostname

If the command returns localhost.localdomain, the hostname is not set; you must set the hostname using the following command as the root user:

hostnamectl set-hostname hostname

where hostname is the short hostname or FQDN, depending on your requirement

Component-specific hostname configuration

When two server components use hostnames to communicate, the /etc/hosts file must contain the following:

• on a main server:

  • an entry for each auxiliary server that maps the auxiliary server hostname to the IP address of the auxiliary server interface that is used for main server communication

  • an entry for each database that maps the database hostname to the IP address of the database interface that is used for main server to database communication

• on an auxiliary server:

  • an entry for each main server that maps the main server hostname to the IP address of the main server interface that is used for auxiliary server communication

  • an entry for each auxiliary server that maps the auxiliary server hostname to the IP address of the auxiliary server interface that is used for main server communication

  • an entry for each database that maps the database hostname to the IP address of the database interface that is used for database communication

Note: Each main server must map an auxiliary server hostname to the same IP address.

Note: Each main and auxiliary server must have a network route to each address in the TLS certificate.

Note: When the NFM-P clients and the auxiliary or peer main servers use different main server interfaces to communicate with a main server, the clients must use a hostname to reach the main server. See the NSP Planning Guide for more information.

Note: When using hostname configuration of NSP components, the hostnames must be resolvable by DNS.

Note: Depending on the management network topology, the hosts files of various components may map the same main server hostname to different IP addresses in order to reach the correct main server interface.

Management network configuration example

The following is a configuration example for hostname resolution in a moderately complex NFM-P management network that may or may not include a NAT configuration. In the example, each main server communicates with multiple networks using separate interfaces, as shown in Figure 13-1, Management network topology.

Figure 13-1: Management network topology

The client IP addresses are in the 192.168.1 subnet, and the internal management IP addresses are in the 192.168.2 subnet.

The component hostnames in the example are the following:

• main servers—main_a and main_b

• main databases—db_a and db_b

• auxiliary servers—aux_a and aux_b

The same configuration methodology must be applied to all components in the internal management network. The following are the configuration requirements for each component in the 192.168.2 subnet.

The /etc/hosts file on station main_a requires the following entries:

192.168.2.1 main_a

192.168.2.2 main_b

192.168.2.5 aux_a

192.168.2.6 aux_b

192.168.2.3 db_a

192.168.2.4 db_b

127.0.0.1 localhost

The /etc/hosts file on station aux_a requires the following entries:

192.168.2.5 aux_a

192.168.2.6 aux_b

192.168.2.1 main_a

192.168.2.2 main_b

192.168.2.3 db_a

192.168.2.4 db_b

127.0.0.1 localhost

The /etc/hosts file on station db_a requires the following entries:

192.168.2.3 db_a

192.168.2.4 db_b

127.0.0.1 localhost