Nokia is a registered trademark of Nokia Corporation. Other products and company names mentioned herein may be trademarks or
tradenames of their respective owners.
The information presented is subject to change without notice. No responsibility is assumed for inaccuracies contained herein.
About this document............................................................................................................................................8
Part I: Getting started...........................................................................................................................................9
1Before you begin ..........................................................................................................................................11
3RHEL OS configuration ...............................................................................................................................39
3.8To deploy the RHEL OS for NFM-P using a qcow2 image ................................................................46
Manual RHEL OS installation......................................................................................................................52
3.9Manual RHEL OS installation requirements......................................................................................52
3.10Required RHEL environment and OS packages...............................................................................53
3.11Required additional OS packages, auxiliary database......................................................................65
Release 20.9
September 2020
Issue 133HE-16029-AAAC-TQZZA
Contents
NFM-P
4RHEL disk configuration .............................................................................................................................67
Standalone NFM-P system installation ....................................................................................................132
6.3Standalone system installation workflow.........................................................................................132
6.4To install a standalone NFM-P system............................................................................................133
Redundant NFM-P system installation.....................................................................................................158
6.5Redundant system installation workflow .........................................................................................158
6.6To install a redundant NFM-P system .............................................................................................159
Auxiliary server installation ......................................................................................................................213
6.7Auxiliary server installation workflow...............................................................................................213
6.8To install an NFM-P auxiliary server................................................................................................214
6.9To add auxiliary servers to an NFM-P system.................................................................................220
8.9Redundant system upgrade workflow .............................................................................................305
8.10To upgrade a redundant NFM-P system .........................................................................................310
Release 20.9
September 2020
Issue 153HE-16029-AAAC-TQZZA
Contents
NFM-P
Auxiliary server upgrade ...........................................................................................................................348
8.11To upgrade an NFM-P auxiliary server............................................................................................348
11.3NFM-P system uninstallation workflow............................................................................................472
11.4To uninstall an auxiliary server ........................................................................................................473
11.5To uninstall an auxiliary database ...................................................................................................475
11.6To uninstall a collocated main server and database .......................................................................476
11.7To uninstall a distributed main server or main database .................................................................479
Part III: NFM-P client deployment....................................................................................................................483
13.2Client delegate server deployment..................................................................................................516
Client delegate server installation............................................................................................................518
13.3To add a client delegate server to an NFM-P system......................................................................518
13.4To install an NFM-P client delegate server using the binary installer..............................................521
13.5To install an NFM-P client delegate server using the JNLP installer ...............................................527
Client delegate server upgrade.................................................................................................................538
13.6To upgrade an NFM-P client delegate server..................................................................................538
Client delegate server uninstallation .......................................................................................................544
13.7To uninstall a client delegate server installed using the binary installer ..........................................544
13.8To uninstall a client delegate server installed using the JNLP installer ...........................................545
NFM-P
Release 20.9
September 2020
Issue 173HE-16029-AAAC-TQZZA
About this document
About this document
Purpose
The NSP NFM-P Installation and Upgrade Guide describes NFM-P installation, upgrade, and
platform modification operations such as system conversion to redundancy and system conversion
to IPv6.
Scope
The scope of this document is limited to the NFM-P application. Many configuration, monitoring,
and assurance functions that can be accomplished from the NFM-P Java GUI are also delivered in
NSP web-based applications accessible from the NSP Launchpad. Readers of this NFM-P guide
should familiarize themselves with the capabilities of the NSP applications, which often offer more
efficient and sophisticated features for network and service management. Help for all installed NSP
applications is available in the NSP Help Center.
Safety information
For your safety, this document contains safety statements. Safety statements are given at points
where risks of damage to personnel, equipment, and operation may exist. Failure to follow the
directions in a safety statement may result in serious consequences.
NFM-P
Document support
Customer documentation and product support URLs:
Documentation Center
•
• Technical support
How to comment
Documentation feedback
Release 20.9
September 2020
8Issue 1
3HE-16029-AAAC-TQZZA
Getting started
Part I:Getting started
Overview
Purpose
This part describes how to prepare for NFM-P system or system component deployment, and
includes important requirements, restrictions, and platform configuration procedures.
Contents
Chapter 1, Before you begin11
Chapter 2, Using samconfig31
Chapter 3, RHEL OS configuration39
Chapter 4, RHEL disk configuration67
NFM-P
Chapter 5, TLS configuration and management85
Release 20.9
September 2020
Issue 193HE-16029-AAAC-TQZZA
Getting started
NFM-P
Release 20.9
September 2020
10Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
Overview
1Before you begin
1.1Overview
1.1.1Purpose
This chapter describes the requirements and restrictions that apply to NFM-P system deployment,
and contains other important information that you must read and understand before you attempt to
deploy an NFM-P component.
1.1.2Contents
1.1 Overview11
General deployment information12
1.2 Introduction12
NFM-P
1.3 To obtain the UUID of a station14
1.4 Using hostnames in the management network15
1.5 Deployment in a VM18
1.6 GUI client deployment20
NFM-P deployment requirements and restrictions23
1.7 NFM-P deployment requirements23
1.8 NFM-P deployment restrictions26
Release 20.9
September 2020
Issue 1113HE-16029-AAAC-TQZZA
Before you begin
General deployment information
Introduction
General deployment information
1.2Introduction
1.2.1Description
CAUTION
Service Disruption
An NFM-P system upgrade, conversion to redundancy, or conversion to IPv6 requires a thorough
understanding of NFM-P system administration and platform requirements, and is supported only
under the conditions described in this guide, the NSP NFM-P Planning Guide, and the NFM-P
Release Notice.
Such an operation must be planned, documented, and tested in advance on a trial system that is
representative of the target live network. Contact technical support to assess the requirements of
your NFM-P deployment, and for information about the upgrade service, which you are strongly
recommended to engage for any type of deployment.
NFM-P
This chapter describes the general conditions that apply to NFM-P deployment. Before you attempt
to deploy or configure an NFM-P component, you must comply with the conditions in this chapter
and ensure that the NFM-P platform is configured as described in the remaining chapters of
“Getting started”
Part III: “NFM-P client deployment” contains OS-specific information about single-user GUI client
and client delegate server deployment.
Guide conventions
This guide uses the following terminology:
• station—a discrete processing entity, such as a physical or virtual computer
• peer—an equivalent component in the same system. For example, the peer main server of the
primary main server in a redundant system is the standby main server. The term peer is
irrespective of the primary or standby role.
The procedures in this guide include default parameter values, when appropriate. A default value is
acceptable in most deployment environments, but must be validated against specific requirements,
for example, firewall constraints. For more information, see the NSP NFM-P Planning Guide and the
current NFM-P Release Notice, or contact technical support.
Platform support
You can deploy NFM-P components in a virtual machine, or VM. See the NSP NFM-P Planning
Guide for VM host system requirements, and
deployment requirements and restrictions.
.
1.5 “Deployment in a VM” (p. 18) for general
Part I:
An NFM-P system has the following required components:
• one standalone main server, or two in a redundant deployment
Release 20.9
September 2020
12Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
General deployment information
Introduction
• one standalone main database, or two in a redundant deployment
• one or more single-user GUI clients or client delegate servers
An NFM-P deployment can include the following optional components:
• auxiliary servers
• an auxiliary database
An NFM-P system may interwork with the following, which are former NFM-P components:
• NSP Flow Collectors
• NSP analytics servers
Note: For NSP Flow Collectors, the NSP NFM-P Installation and Upgrade Guide describes
only an upgrade from Release 18.
The NSP Deployment and Installation Guide describes the following NSP Flow Collector
deployment operations:
•installation
•upgrade from Release 19 or later
•uninstallation
NFM-P
Note: The NSP NFM-P Installation and Upgrade Guide describes only the upgrade of an
NFM-P analytics server to an NSP analytics server.
The NSP Deployment and Installation Guide describes the following NSP analytics server
deployment operations:
•installation
•upgrade
•uninstallation
Note: CPAM functions in an NFM-P system are enabled only when the system includes one
or more operational 7701 CPAA devices. See the 7701 CPAA and vCPAA Setup andInstallation Guide for 7701 CPAA deployment information.
The following table lists the supported platforms for each NFM-P component type.
Table 1-1 NFM-P platform support by component
NFM-P componentMac OS XMicrosoft WindowsRHEL
Main server✓
Main database✓
Auxiliary server✓
Auxiliary database✓
Client delegate server✓✓
Single-user client✓✓✓
Release 20.9
September 2020
Issue 1133HE-16029-AAAC-TQZZA
Before you begin
General deployment information
To obtain the UUID of a station
nsp user account
NFM-P system operation and management require a RHEL user account called nsp in the nsp user
group.
• The initial installation of any of the following components on a station creates the group and
account:
− main server
− auxiliary server
• The nsp user owns all NFM-P server processes; only the nsp user can start or stop a server, or
run a server script.
• The nsp home directory is /opt/nsp.
• The initial nsp password is randomly generated, and must be changed by the root user.
• The root user owns some files in the /opt/nsp/nfmp/server directory for low-level installation and
support functions.
• Server uninstallation does not remove the nsp user account, user group, or home directory.
• Root user privileges are required only for component installation or upgrade, and for low-level
support functions.
NFM-P
1.2.2Integration with other products or NSP components
For information about NFM-P integration with other products or NSP components, see the NSP
Deployment and Installation Guide.
1.3To obtain the UUID of a station
1.3.1Description
An NFM-P license is specific to the UUID of a main server station, and must be provided in a
license request. The following steps describe how to obtain the UUID of a station that is to host an
NFM-P main server.
Note: If you are using an Integrated Lights Out Management system, ensure that you obtain
the UUID of the intended blade and not the UUID of the ILO module.
Note: You must perform this procedure on each station that is to host a main server.
Note: A leading # character in a command line represents the root user prompt, and is not to
be included in a typed command.
1.3.2Steps
1
Log in to the main server station as the root user.
Release 20.9
September 2020
14Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
General deployment information
Using hostnames in the management network
2
Open a console window.
3
Enter the following:
# cat /sys/devices/virtual/dmi/id/product_uuid ↵
The UUID is displayed; for example:
35F59783-2258-11E1-BBDA-38B41F432C41
4
Record the value for use when you request the NFM-P license for the main server.
END OF STEPS
1.4Using hostnames in the management network
NFM-P
1.4.1Overview
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 include 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.
Description
This section provides a configuration example for hostname resolution in a moderately complex
NFM-P management network that may or may not include a NAT configuration.
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 NFM-P Planning Guide for more information.
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.
Release 20.9
September 2020
Issue 1153HE-16029-AAAC-TQZZA
Before you begin
General deployment information
Using hostnames in the management network
Note: Only local hostname resolution is supported. The use of a DNS server for NFM-P
hostname resolution is not supported.
To enable hostname resolution in an NFM-P management network, you must do the following:
• Configure the local /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 delimit the FQDN components.
− not exceed 63 characters.
• During component deployment, specify hostnames instead of IP addresses.
Note: Hostnames are case-sensitive.
Hostname usage requirements and restrictions
NFM-P
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: 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
where hostname is the short hostname or FQDN, depending on your requirement
hostname
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.
Release 20.9
September 2020
16Issue 1
3HE-16029-AAAC-TQZZA
...2.1
192.168.1.1
Main server
main_a
NIC 1
NIC 3
192.168.4.1
...2.5
...2.3...2.4
Switch/
Router
Switch/
Router
Switch/
Router
NFM-P
clients
IPv6 Managed
Network
...2.6
Switch/
Router
Switch/
Router
Switch/
Router
2001:0DB8::0001
NIC 4
192.168.4.2
192.168.1.2
...2.2
NIC 2
25709
2001:0DB8::0002
Auxiliary
server aux_a
NIC 1
NIC 3
NIC 4
NIC 2
Main database
db_a
NIC 1
NIC 4
Main server
main_b
NIC 2
NIC 3
NIC 4
NIC 1
Auxiliary
server aux_b
NIC 2
NIC 3
NIC 4
NIC 1
Main database
db_b
NIC 1
NIC 4
IPv4 Managed
Network
Before you begin
General deployment information
Using hostnames in the management network
Note: Each main and auxiliary server must have a network route to each address provided in
a TLS certificate.
Management network configuration example
The following example provides guidance about configuring local hostname resolution for NFM-P
components in a relatively complex management network. In the example, each main server
communicates with multiple networks using separate interfaces, as shown in
“Management network topology” (p. 16)
Figure 1-1 Management network topology
NFM-P
Figure 1-1,
.
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:
Release 20.9
September 2020
Issue 1173HE-16029-AAAC-TQZZA
Before you begin
General deployment information
Deployment in a VM
• 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
NFM-P
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
1.5Deployment in a VM
1.5.1Description
The requirements and restrictions below apply to NFM-P component deployment in a virtual
machine, or VM. VM deployment is supported in the following environments:
• KVM
• Openstack
• VMware
Release 20.9
September 2020
18Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
General deployment information
Deployment in a VM
Note: The requirements and restrictions in “NFM-P deployment requirements and
restrictions” (p. 23)
Note: Before you deploy an NFM-P component in a VMware VM, you must install the latest
VMware Tools software.
See the NSP NFM-P Planning Guide for the hardware virtualization requirements, and for the
specific configuration requirements of a supported environment.
also apply to VM deployments.
1.5.2VM deployment using qcow images
You can use qcow2 disk images to deploy the following:
• RHEL OS, for subsequent component installation; see
• NFM-P system; see Chapter 7, “ NFM-P qcow deployment”
1.5.3NFM-P server and database virtualization
The following conditions apply to main server, auxiliary server, client delegate server, or database
deployments in VMs.
• The guest OS must be an NFM-P-supported version of RHEL 7 Server x86-64.
• A RHEL deployment on VMware requires VMXNET 3 NIC adapters; see the VMware
documentation for information.
NFM-P
“RHEL OS deployment in a VM” (p. 46)
1.5.4Client virtualization
The following conditions apply to NFM-P single-user GUI client deployment in a VM.
• You can deploy a VM client in a live network environment only if the client resources are
dedicated to the guest OS, and not shared or oversubscribed.
• The guest OS must be a supported OS version; see the NSP NFM-P Planning Guide.
• The supported connection application for a VMware ESXi Windows platform is Windows Remote
Desktop.
Additional EMS requirements and restrictions
The following conditions apply to an NFM-P single-user GUI client or client delegate server in a VM
that requires the installation of an additional element manager on the same platform, or is to use an
additional NE management interface.
• You can use two or more NICs to isolate network traffic between the client VM and the managed
NEs. Such a configuration may be required when an additional element manager, for example,
NEtO, must share the client resources, or when web-based NE management is to be performed
from the client station.
• Additional RAM, disk space, and CPU resources are required to accommodate an element
manager that shares a client platform; see the NSP NFM-P Planning Guide.
Release 20.9
September 2020
Issue 1193HE-16029-AAAC-TQZZA
Before you begin
General deployment information
GUI client deployment
1.6GUI client deployment
1.6.1Single-user GUI client and client delegate server deployment
The following NFM-P GUI client deployment scenarios are supported:
• separate single-user client installations
• remote user connections to a common client instance on a client delegate server
You can install multiple single-user GUI clients on one station, or on separate stations. The multiple
clients installed on one station can be at various releases and associated with the different NFM-P
systems.
You can also configure one single-user client to connect to multiple NFM-P systems. For
information , see
(p. 490)
A client delegate server allows NFM-P access to multiple remote clients using one client software
instance. If multiple client delegate servers are required, they are deployed on separate stations.
The installation or upgrade of an NFM-P single-user GUI client or client delegate server is a
software push from a main server that you initiate using a browser on the client or client delegate
server station. The main server must be installed and fully initialized before you can install or
upgrade the client software.
.
12.4 “To configure a GUI client login form to list multiple NFM-P systems”
NFM-P
The software push mechanism enables centralized client software management. During startup, an
existing single-user client or client delegate server checks for available software updates on the
main server. Any available client configuration updates are also automatically applied.
See the following for client installation and upgrade information:
Chapter 13, “Client delegate server deployment” —client delegate server deployment
1.6.2Client delegate servers
A client delegate server supports multiple simultaneous GUI sessions using one client software
installation. A client delegate server can host local and remote user sessions, and supports the use
of a third-party remote access tool such as a Citrix gateway. Client delegate server deployment is
supported on multiple platforms.
A GUI session that is opened through a client delegate server is functionally identical to a singleuser client GUI session. The client delegate server locally stores the files that are unique to each
user session, such as the client logs and GUI preference files, using a directory structure that
includes the RHEL or Windows username.
Figure 1-2, “Client delegate servers” (p. 21) shows two client delegate servers in an NFM-P
management network. Multiple local users log in to a client delegate server directly, and remote
users log in through a client delegate server that hosts a third-party access tool, for example, a
Citrix gateway. Another local user opens a session on a single-user client station.
Release 20.9
September 2020
20Issue 1
3HE-16029-AAAC-TQZZA
20165
Remote GUI users
Client delegate
server and
third-party access
server
Local GUI
users
Single-user
GUI client
Client delegate
server
main server and
database
Managed
network
Before you begin
General deployment information
GUI client deployment
Figure 1-2 Client delegate servers
NFM-P
If a client delegate server becomes unreachable, the NFM-P raises an alarm and changes the color
of the associated session entries in the GUI. The alarm clears when the server is again reachable.
You can use the client software on a client delegate server from the local console. It is
recommended that you install a client delegate server, rather than a single-user client, to facilitate
the deployment of additional clients.
A main server monitors the registered client delegate servers and displays information about them
in the GUI. To register a client delegate server, you specify the client delegate server IP address
and installation location during main server installation, upgrade, or configuration.
You can use a client GUI to list the following:
• registered client delegate servers and the availability of each
Release 20.9
September 2020
Issue 1213HE-16029-AAAC-TQZZA
Before you begin
General deployment information
GUI client deployment
• active client delegate server sessions
• active client sessions on a specific client delegate server
• active client sessions for a specific NFM-P user
The number of allowed NFM-P client sessions on a client delegate server is configurable as a
threshold using the client GUI. If a user tries to open a client session that reaches or exceeds the
threshold, the session proceeds and the client delegate server raises an alarm. This thresholdcrossing function can help to balance the session load across multiple client delegate servers. You
require the Update user permission on the Server package to configure the threshold.
The following restrictions apply to client delegate servers.
• The installation of only one client delegate server on a station is supported.
• You cannot change a single-user client to a client delegate server.
• A client delegate server connects to one release of main server; multiple main servers to which
the client delegate server connects must be at the same release.
• Depending on the platform type, specific deployment requirements and restrictions may apply;
see the NSP NFM-P Installation and Upgrade Guide for information.
NFM-P
1.6.3Software upgrades
After an NFM-P main server upgrade, a single-user GUI client or client delegate server that
connects to the main server automatically detects the release mismatch and attempts an upgrade
to the main server release level.
During a software upgrade, an NFM-P client downloads and installs only the files required for the
upgrade. The upgrade process removes previously downloaded local files that are not required by
the updated client software.
1.6.4Configuration updates
When the single-user GUI clients or client delegate servers that connect to a main server require a
configuration update, an administrator updates the global client configuration stored on a main
server. Each client instance detects and applies the update at the start of the next client session.
See “System component configuration procedures” in the NSP NFM-P Administrator Guide for
information about globally updating client configurations.
Note: A client backs up the existing configuration files as part of a configuration update.
Release 20.9
September 2020
22Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment requirements
NFM-P deployment requirements and restrictions
1.7NFM-P deployment requirements
1.7.1Network requirements
CAUTION
Service Disruption
The use of hostname resolution for GUI and XML API client communication with an NFM-P main
server in a NAT environment is strongly recommended.
When IP addresses are used in a NAT environment, the following conditions apply:
• All client communication with the main server must use the public IP address of the main server.
• The NAT firewall must be configured to allow the main server to communicate with itself using
the public IP address.
NFM-P
CAUTION
Service Disruption
In a redundant system, a GUI client that opens a browser connection to the primary NFM-P main
server may need to use the IP address or hostname of the peer main server after a main server
communication failure.
To resolve the two IP addresses or hostnames, a GUI client can use a common DNS name which
maps each main server IP address provided by the DNS server to the primary main server.
• Configure a DNS server for GUI clients to map each main server IP address to a common DNS
name.
• Configure each GUI client to use the common DNS name for browser connections to the NFM-P.
• Use a client browser that caches multiple IP addresses associated with one hostname.
The NFM-P network requirements apply to the following:
• management network—the network in which the NFM-P components communicate with each
other
• managed network and external systems—the managed NEs, and external management systems
that are integrated with the NFM-P
Management network
The following requirements apply to the NFM-P management network.
• During a main server installation or upgrade, you must use hostnames to identify the main server
interfaces under the following conditions:
− when the XML API and GUI clients communicate with a main server using multiple IP
addresses for the main server
Release 20.9
September 2020
Issue 1233HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment requirements
− when the XML API and GUI clients use different addresses to communicate with a main
server through one interface on the main server
• A standalone auxiliary server must be accessible to each main server and database in a
redundant NFM-P system. Optimally, all components in a deployment are in the same LAN and
have high-quality network interconnection.
• Each station in an auxiliary database cluster must be on the same side of the management LAN,
and not geographically dispersed.
• The internal communication among the stations in an auxiliary database cluster must be isolated
to a dedicated private network. Each station IP address used for internal communication must be
associated with an interface connected to the private network, and must be the only IP address
of the interface.
• When two components use hostnames to communicate, the /etc/hosts file on each component
station must contain the following:
− an entry that maps the hostname assigned to the interface on the other component to the IP
address used to reach the other component
− an entry that maps the hostname of the other component station to each IP address used to
reach the other component
• Specifying a TCP or UDP port other than the default during an installation or upgrade can affect
component communication through a firewall. Ensure that you record any changes to default
port numbers and make the ports available through the firewall.
NFM-P
Hostname usage in an NFM-P system has special configuration requirements. See
hostnames in the management network” (p. 15)
3.4.2 “Network-level OS configuration requirements” (p. 41) for specific configuration
and
information.
Managed network and external systems
for an example management network configuration,
1.4 “Using
CAUTION
Management Disruption
If an NFM-P system that is to be upgraded manages a device as a GNE, and the new NFM-P
release supports native management of the device, you must unmanage the device and delete it
from the main database before the upgrade.
After the upgrade, you can use the NFM-P to discover and manage the device natively, rather than
as a GNE.
Note: Before you upgrade an NFM-P system that manages 7705 SAR, 7705 SAR-Hm, or
VSR NEs using NGE, you must observe the following:
•7705 SAR - Release 8.0 R3 and earlier support only NGE version 1; Release 8.0 R4 and
later support only NGE version 2.
•7705 SAR-Hm and VSR - Release 15.0 R3 and earlier support only NGE version 1;
Release 15.0 R4 and later support only NGE version 2.
If you want to manage such devices after the NFM-P upgrade using NGE version 2, you must
do the following:
Release 20.9
September 2020
24Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment requirements
1. Upgrade each device to a release that supports NGE version 2.
2. Use the NFM-P to specify NGE version 2 for each device.
The following requirements apply to the network of NFM-P-managed devices, and to the external
systems with which the NFM-P is integrated.
• Before you upgrade an NFM-P system, you must confirm that the new NFM-P software release
supports the release of each managed NE. If this is not true, you must perform one of the
following before you attempt the upgrade, or service disruption may occur.
− Upgrade the NE to a release that the new NFM-P release supports.
− Use an NFM-P client to unmanage the device, remove the device from the managed network,
and remove the discovery rule element for the device.
• Before you upgrade an NFM-P system, you must ensure that the new NFM-P software is
compatible with the software release of each integrated external system. Contact technical
support for information about external system compatibility.
• An NFM-P system that manages LTE RAN devices has special disk partitioning requirements.
Chapter 4, “RHEL disk configuration” for information.
See
• An NFM-P system upgrade does not preserve 9500 MPR device software images. If you want to
retain the images, you must export the images to a remote file system before the upgrade, and
import the images to the NFM-P after the upgrade.
• Before the NFM-P can manage some LTE RAN devices, functions such as PM statistics
transfers and network snapshots require configuration.
NFM-P
1.7.2Platform requirements
Note: For optimal storage performance on a supported Nokia AirFrame server, set the default
write cache policy for each created storage volume to Write Through. See the NokiaAirFrame
server documentation for information about verifying, configuring, and setting the write cache
policy for a volume.
The following are the NFM-P platform requirements.
• The platform must meet the minimum requirements described in the NSP NFM-P PlanningGuide.
• The OS release and patch level of all main server, main database, and optional component
stations in an NFM-P system must be identical unless NFM-P OS support restrictions exist.
• The platform must be dedicated to the NFM-P only; sharing the platform is not supported.
System operation may be adversely affected by the activity of other software on the same
station.
• Before you install or upgrade a redundant NFM-P system, you must enable SSH on each main
server, auxiliary server, and main database station in the system.
• If the NFM-P is to collect statistics on a large scale, as defined in the NSP NFM-P PlanningGuide, you must use a disk array with the main database to increase performance. See
4, “RHEL disk configuration”
• The NFM-P XML API and GUI client real-time clocks must always be synchronized with the main
server real-time clock. The use of NTP or an equivalent time protocol is strongly recommended.
Chapter
for information.
Release 20.9
September 2020
Issue 1253HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment restrictions
• The Bash shell is the supported command shell for RHEL CLI operations.
1.7.3Security requirements
Note: The use of sudo to gain root user privileges is supported for NFM-P installation, and for
any other operation in this guide that requires root user privileges.
The following are the NFM-P security requirements.
• The Oracle management user requires full read and write permissions on the main database
installation directory, /opt/nsp/nfmp/db, and any specifically created partitions, for example, /opt/
nsp/nfmp/dbbackup.
• The user that installs an NFM-P single-user GUI nt requires local user privileges only, but must
have full access permissions on the client installation directory. The user that opens the client
installer must have sufficient file permissions to create the installation directory, or the installation
fails.
1.7.4Software requirements
NFM-P
The following are the NFM-P software requirements.
• An NFM-P system deployment requires a license file in compressed format with a .zip extension.
A license file has the following characteristics.
− The UUID of the host station is required to generate the license.
station” (p. 14)
− The file can accommodate two system IDs, which enables the use of the same file on
redundant main servers, and is recommended.
− Renaming the compressed file has no effect on the validity of the contained license file, but
renaming the contained XML license file renders it invalid.
− The main server configuration utility copies the license file content to a backup location; a
change to the license file content or location after an installation or upgrade does not affect
the main server operation.
• You must ensure that you have sufficient time to complete a main database upgrade. The time
required for an upgrade depends on the platform resources, database complexity, and
tablespace configuration. See the NSP NFM-P Planning Guide for database upgrade time
estimates.
describes how to obtain a station UUID.
1.8NFM-P deployment restrictions
1.8.1Network restrictions
Note: The use of NAT between NFM-P server and database components is not supported.
The NFM-P supports NAT only between the following:
•main server and single-user client or client delegate server
•main or auxiliary server and XML API client
•main or auxiliary server and managed network
1.3 “To obtain the UUID of a
Release 20.9
September 2020
26Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment restrictions
Note: Before you attempt to deploy an NFM-P system, or add a component to a system, you
must ensure that any firewalls between the components allow the required traffic to pass
between the components, or are disabled. The NSP NFM-P Planning Guide lists the open
ports required by each component, and provides information about using NFM-P templates to
create RHEL Firewalld rules.
Note: If you use SSH X forwarding to perform a procedure in this guide, the “su - oracle”
command fails. In such a scenario, you must log in directly as the Oracle management user to
perform the required actions.
The following restrictions apply to the network environment in which an NFM-P system or
component is deployed.
• DNS or NIS name resolution is not supported between NFM-P components, and a pre-existing
name service must not conflict with NFM-P address resolution. The restriction also applies to
XML API client communication with the NFM-P.
• You cannot use “localhost” or an alias IP address to identify a component.
• An NFM-P main server listens for GUI and XML API client communication on only one interface
unless you specify a hostname for the main server during an installation or upgrade.
• You cannot use a hostname to identify a main database station; NFM-P components can use
only an IP address to reach a database.
• All IP communication from an NFM-P auxiliary server to an NFM-P main server must originate
from one IP address, which is the auxiliary server address specified during the main server
configuration. A main server rejects communication from an auxiliary server if the auxiliary server
uses a source address other than the configured address.
• During a single-user client installation, you can specify a hostname instead of an IP address to
identify a main server. A client upgrade occurs automatically through a connection to a main
server named in the client configuration.
NFM-P
IPv4 and IPv6
• NFM-P components communicate with other NFM-P components and external entities using
IPv4 or IPv6 exclusively, with the following exceptions:
− You can configure an NFM-P system to concurrently manage IPv4 and IPv6 networks.
− An NFM-P GUI or browser-based application client can connect to the NFM-P using IPv4 or
IPv6, regardless of the protocol version in use between the NFM-P server and database
components.
Note: If the GUI or application clients are to connect to the NFM-P using IPv4 and IPv6, when
you use the samconfig utility to configure client access on a main server, you must specify a
hostname rather than an IP address.
• Before you can specify an IPv6 address for an NFM-P component, the IPv6 interface must be
plumbed and operational. See the OS documentation for information about enabling and
configuring an IPv6 interface.
• Before you attempt to perform a procedure in
Chapter 10, “NFM-P conversion to IPv6”, the
NFM-P system must be at the software release described in this guide; you cannot combine an
upgrade and a conversion to IPv6 in one operation.
Release 20.9
September 2020
Issue 1273HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment restrictions
1.8.2Platform restrictions
The following are the NFM-P platform restrictions.
• An NFM-P single-user client or client delegate server cannot be installed on the same station as
an NFM-P server or database.
• An NFM-P single-user client and client delegate server cannot be installed on the same station.
• An optional system component requires a dedicated station. The sharing of a station by optional
components is not supported; attempts to deploy multiple components on one station fail.
• If you plan to convert a standalone NFM-P system to a redundant system, and also plan to
upgrade the system, you must perform the upgrade before the conversion.
• An NFM-P system conversion from IPv4 to IPv6 is not supported during an upgrade or
conversion to redundancy.
1.8.3Security restrictions
The following are the NFM-P security restrictions.
• The user that starts an NFM-P client must be the user that installs the client software, or another
user that has read, write, and execute privileges on the client files and directories.
• An NFM-P domain name defines the network-management domain to which an NFM-P
component belongs, and must be unique to a network. An NFM-P component can interact only
with other NFM-P components in the same NFM-P domain. During system installation, you must
specify the same domain name for each component in the system.
NFM-P
1.8.4General software restrictions
The following are general NFM-P software deployment restrictions. See also the NFM-P Release
Notice, which contains important release-specific information, before you attempt an operation
described in this guide.
• You cannot share an existing Oracle installation with the NFM-P, and no other application can
use the NFM-P Oracle software.
• You can specify the installation directory for a single-user client or client delegate server, but not
for any other type of component.
• You can deploy a main server without specifying a license file. However, if you do not specify a
license file, you cannot start the main server until you import a license. See “Software and
license configuration procedures” in the NSP NFM-P Administrator Guide for information about
importing licenses.
Release 20.9
September 2020
28Issue 1
3HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment restrictions
Upgrade-specific restrictions
CAUTION
Service Disruption
An NFM-P upgrade does not preserve all non-default settings in configuration files such as nmsserver.xml.
If an NFM-P configuration file contains non-default settings that you want to retain after an upgrade,
contact technical support for assistance before the upgrade.
CAUTION
Data Loss
At the beginning of a main server upgrade, specific NFM-P configuration and log files are copied to
a time-stamped directory in the installation directory, and specific directories below the installation
directory are deleted.
NFM-P
If you create or modify a file under the main server installation directory, you risk losing the file
during an upgrade unless you first back up the file to a location that is unaffected by the upgrade.
CAUTION
Upgrade failure
An NFM-P main server upgrade fails if each main server in the system is not fully initialized and
functional before the upgrade.
Before you attempt to upgrade a main server, you must ensure that the initialization of each main
server in the NFM-P system is complete.
Note: An NFM-P server upgrade applies a default set of file permissions to each directory
below the main server installation directory. If you change the file permissions of a directory
below the main server installation directory and want the permissions to be in effect after an
upgrade, you must re-apply the permissions after the upgrade.
Note: After an analytics server upgrade:
•Scheduled report creation continues, but uses the new report versions, which may differ
from the former versions.
•Saved reports remain available, but lack any new features of the upgraded report versions;
it is recommended that you recreate and save the reports.
•If a report changes significantly between releases, the report may no longer function. See
the NFM-P Release Notice for limitations regarding specific reports.
• You can upgrade an NFM-P component that is no more than two major releases older than the
current release. For example, you can upgrade a Release 18 or 19 NFM-P system to Release
20, but you cannot upgrade a Release 17 system directly to Release 20; you must first perform
an intermediate upgrade to at least Release 18.
Release 20.9
September 2020
Issue 1293HE-16029-AAAC-TQZZA
Before you begin
NFM-P deployment requirements and restrictions
NFM-P deployment restrictions
• After an upgrade to an intermediate release, for example, an upgrade from Release 17 to
Release 18 in preparation for a final upgrade to Release 20, you must allow each main server to
initialize fully before the final upgrade, or the upgrade fails.
• A redundant system upgrade requires a network-management outage and must be performed
only during a scheduled maintenance period of sufficient duration.
NFM-P
Release 20.9
September 2020
30Issue 1
3HE-16029-AAAC-TQZZA
Loading...
+ 518 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.