NSP

Network Services Platform

Release 22.6

Planning Guide

3HE-18161-AAAB-TQZZA
Issue 1
June 2022

© 2022 Nokia.
Use subject to Terms available at: www.nokia.com/terms
 NSP

Legal notice

Nokia is committed to diversity and inclusion. We are continuously reviewing our customer documentation and consulting with standards
bodies to ensure that terminology is inclusive and aligned with the industry. Our future customer documentation will be updated accordingly.

This document includes Nokia proprietary and confidential information, which may not be distributed or disclosed to any third parties without
the prior written consent of Nokia.

This document is intended for use by Nokia’s customers (“You”/”Your”) in connection with a product purchased or licensed from any
company within Nokia Group of Companies. Use this document as agreed. You agree to notify Nokia of any errors you may find in this
document; however, should you elect to use this document for any purpose(s) for which it is not intended, You understand and warrant that
any determinations You may make or actions You may take will be based upon Your independent judgment and analysis of the content of
this document.

Nokia reserves the right to make changes to this document without notice. At all times, the controlling version is the one available on
Nokia’s site.

No part of this document may be modified.

NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF
AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE, IS MADE IN RELATION TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE LIABLE FOR ANY
DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES,
SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA
THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR
OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT.

Copyright and trademark: Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be
trademarks of their respective owners.

© 2022 Nokia.

Disclaimer

Open Source Software and Red Hat Enterprise Linux Operating System

In case:
• (i) any “Open Source Software and Red Hat Enterprise Linux Operating System (“FOSS & RHEL”) is packaged separately or integrated
with any Nokia Software and to which third party license obligations apply; or,
• (ii) any FOSS & RHEL is directly licensed by Customer under a separate license or subscription agreement, and such FOSS & RHEL is
interacting or interoperating with any Nokia Software or Product:

information will be available either in the FOSS & RHEL itself or on the website from which the download is available indicating the license
under which such FOSS was released, and containing required acknowledgements, legends and/or notices.

It is hereby acknowledged and agreed by the Parties that any FOSS & RHEL is distributed on an “as is” basis under the respective FOSS &
RHEL license terms. Nokia will not warrant nor will be liable for, and will not defend, indemnify, or hold Customer harmless for any claims
arising out of, or in any case related to FOSS & RHEL and their use (or inability to use) by the Parties. This includes, but is not restricted to,
any and all claims for direct, indirect, incidental, special, exemplary, punitive or consequential damages in connection with FOSS & RHEL or
its components (whether included in the Nokia Software or not) and their use or inability to use. Also, this includes claims for or in
connection with the title in, the non-infringement of or interferences and damages caused to Customer or third parties by FOSS & RHEL.

CUSTOMER SHALL HAVE NO RIGHT TO RECEIVE FROM NOKIA ANY CARE (MAINTENANCE & SUPPORT SERVICES) ON FOSS &

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
2 3HE-18161-AAAB-TQZZA Issue 1
 NSP

RHEL LICENSED BY CUSTOMER UNDER A SEPARATE LICENSE AGREEMENT OR SUBSCRIPTION CONTRACT AND TO WHICH
THIRD PARTY LICENSE OBLIGATIONS APPLY WHETHER OR NOT IT INTERACTS WITH ANY NOKIA SOFTWARE OR PRODUCT.

The above shall also apply in case Customer requires - and Nokia accepts under the terms of this Disclaimer to use its reasonable
commercial effort to do so - certain installation services on FOSS & RHEL as directly licensed by Customer under a separate license or
subscription agreement; and, such FOSS & RHEL are interacting or interoperating with a Nokia Software or Product. For sake of clarity in
such a case the following shall also apply:
• Before starting any installation service, Customer must instruct Nokia to start such installation and must confirm in writing to Nokia that its
FOSS & RHEL license or subscription contract (for RHEL: Red Hat Enterprise Agreement) with Customer includes the right to use of the
specific FOSS & RHEL and the related support for all platforms running the FOSS & RHEL; that such subscription and support contract
is in force (not expired) and allows such installation activities.
• Nokia will not warrant nor will be liable for any cost, expense, damage, and will not defend, indemnify, or hold Customer or any third party
harmless for any claims arising out of, or in any case related to FOSS & RHEL (and in connection with the installation activities of such
FOSS & RHEL) and their use (or inability to use) by the Customer or by any third party, following the installation of such FOSS & RHEL.
This includes, but is not restricted to, any and all claims for direct, indirect, incidental, special, exemplary, punitive or consequential
damages in connection with FOSS & RHEL or its components and their use or inability to use.
• Nokia will not provide nor will have any liability or obligation to provide any support, maintenance, care service, warranty or indemnity
with respect to any (installed) FOSS & RHEL as licensed by the Customer under a separate license agreement or subscription contract.

Any Care service (maintenance and support service) on FOSS & RHEL licensed by Nokia as packaged separately or integrated with any
Nokia Software may be made available by Nokia under specific contractual terms to be agreed upon by the Parties.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 3
 NSP

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
4 3HE-18161-AAAB-TQZZA Issue 1
Contents NSP

Contents

About this document............................................................................................................................................7

1 NSP product overview ...................................................................................................................................9

1.1 The Network Services Platform...........................................................................................................9
1.2 NSP system architecture.....................................................................................................................9
1.3 Core NSP technologies .....................................................................................................................13
1.4 NSP deployment ...............................................................................................................................16
1.5 Including the NFM-P in an NSP deployment.....................................................................................20

2 NSP system requirements...........................................................................................................................31

2.1 NSP container environment requirements ........................................................................................31
2.2 NSP cluster requirements .................................................................................................................34
2.3 NFM-P Hardware platform requirements ..........................................................................................38
2.4 Hardware platform and resource requirements using virtualization ..................................................39
2.5 NFM-P minimum platform requirements ...........................................................................................43
2.6 NFM-P platform requirements for larger networks ............................................................................54
2.7 NFM-P storage ..................................................................................................................................55

3 Operating system specifications................................................................................................................59

3.1 Red Hat Enterprise Linux (RHEL) .....................................................................................................59
3.2 NFM-P on Microsoft Windows...........................................................................................................61
3.3 NFM-P on Apple macOS ...................................................................................................................61
3.4 NFM-P operating system summary...................................................................................................61
3.5 Third party software for NFM-P single-user client or client delegate server......................................62

4 Network requirements .................................................................................................................................63

4.1 NSP network requirements ...............................................................................................................63
4.2 NSP component network addressing requirements ..........................................................................63
4.3 Network requirements between NSP and other components ...........................................................63
4.4 Network requirements for redundancy, high-availability and NSP cluster nodes ..............................64
4.5 NFM-P network requirements ...........................................................................................................65
4.6 Network elements .............................................................................................................................65
4.7 NFM-P bandwidth requirements........................................................................................................66
4.8 Contributors to bandwidth requirements ...........................................................................................71
4.9 Network bandwidth............................................................................................................................74
4.10 Network latency.................................................................................................................................77
4.11 Network reliability ..............................................................................................................................79

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 5
Contents NSP

4.12 Network element specific requirements ............................................................................................80

4.13 Mechanism to maintain current state of network elements ...............................................................81

5 Scaling and performance ............................................................................................................................83

5.1 NSP scaling and performance...........................................................................................................83
5.2 Scale limits for NSP deployments .....................................................................................................83
5.3 Scale limits for applications...............................................................................................................86
5.4 Failover performance for HA and redundant deployments................................................................91
5.5 NFM-P Scalability guidelines.............................................................................................................92
5.6 Scaling guidelines for NFM-P XML API clients..................................................................................96
5.7 Scaling guidelines for statistics collection .........................................................................................96
5.8 Scaling guidelines for scheduled tests (STM) .................................................................................102
5.9 cflowd statistics collection ...............................................................................................................107
5.10 PCMD collection..............................................................................................................................109
5.11 CPAM and vCPAA ...........................................................................................................................110

6 Security .......................................................................................................................................................113
6.1 Introduction......................................................................................................................................113
6.2 Securing the NSP............................................................................................................................113
6.3 Operating system security for NSP stations ....................................................................................114
6.4 Communication between the NSP and external systems................................................................114
6.5 NSP Port Communications..............................................................................................................116
6.6 NSP Kubernetes Platform Communications ...................................................................................125
6.7 Securing the NFM-P........................................................................................................................127
6.8 NFM-P port information ...................................................................................................................130
6.9 FTP .................................................................................................................................................143
6.10 NFM-P firewall and NAT rules .........................................................................................................144

7 NSP deployment with multiple network interfaces and IP addresses ..................................................165

7.1 Support for multiple network interfaces...........................................................................................165
7.2 NSP Network Address Translation ..................................................................................................168
7.3 NFM-P multihoming.........................................................................................................................168
7.4 NFM-P Network Address Translation ..............................................................................................175
7.5 Use of hostnames for the NFM-P client ..........................................................................................177

8 Appendix A .................................................................................................................................................179
8.1 Storage-layer I/O performance tests ...............................................................................................179

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
6 3HE-18161-AAAB-TQZZA Issue 1
About this document NSP

About this document

Purpose
The NSP Planning Guide is intended for technology officers, network planners, and system
administrators who need the information required to plan a successful deployment of the Nokia
Network Services Platform, or NSP. The reader is encouraged to become familiar with the NSP
architecture, the relevant components for both IP and optical networks, and the virtualization,
system, and network requirements.

Scope
The scope of this document is limited to the planning of an NSP deployment. The guide provides an
overview of the NSP product and the components that comprise an NSP deployment, including the
NFM-P. The guide also describes operating-system specifications, and system resource and
network requirements for successful NSP system deployment. Scale limits and general information
about platform security recommendations are also included.

NFM-P only deployments

Starting in Release 22.3, NSP and NFM-P components in a greenfield deployment must be
deployed in shared mode; independent greenfield NFM-P installations are not supported. Support
remains unchanged for brownfield upgrades of independent NFM-P systems.
This document combines the previously issued NSP Planning Guide and the NFM-P Planning
Guide as one reference for planning an NSP or NFM-P deployment. Planning the upgrade of an
independent Release 22.3 or earlier NFM-P system requires a review of the NFM-P-specific
content, and content related to any NSP components, such as analytics servers, that your
deployment may include. In such a brownfield upgrade scenario, content specific to NSP cluster
deployment does not apply. For example, in an NFM-P-only deployment, you can safely use the
NFM-P scaling values, and ignore the NSP values.

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.

Document support
Customer documentation and product support URLs:
• Documentation Center
• Technical support

How to comment
Documentation feedback
• Documentation Feedback

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 7
About this document NSP

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
8 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
The Network Services Platform

1 NSP product overview

1.1 The Network Services Platform

1.1.1 NSP system overview
The Network Services Platform, or NSP, provides role-based network equipment, infrastructure,
service rollout, resource control, and FCAPS management within and among multiple network
domains.
The NSP management scope includes Nokia and multi-vendor network elements, or NEs, using a
variety of protocols and element-management mechanisms. The NSP has interfaces for functions
such as programmable multi-layer service provisioning, rollout, and activation.

1.2 NSP system architecture

1.2.1 Overview
The following topics describe the multiple interoperating components that comprise an NSP system.
The core of an NSP system is the NSP cluster, which hosts a central set of shared system
resources and controls operator access.
Depending on the management requirements; an NSP system may include additional components
that are hosted outside the NSP cluster, see 1.2.3 “Additional NSP components” (p. 10) for
information.

1.2.2 NSP cluster

The NSP cluster is the core element of an NSP system and the source of the common NSP
resource base, or nspOS. The nspOS enables system-wide functions such as Single Sign-On, or
SSO, centralized logging, and operator access to the NSP. The nspOS also includes common
services used by other NSP components.
The NSP cluster also hosts the central NSP management functions described below.

Model-driven Mediation (MDM)

MDM provides mediation between model-driven NSP applications and Nokia or third-party network
devices. MDM provides an adaptation layer which uses adaptors to convert NSP application
requests to device specific directives using standard protocols such as gRPC/gNMI, NETCONF,
SNMP and CLI over SSH or Telnet. MDM is an optional component in an NSP deployment and can
coexist with NFM-P and NFM-T.

Workflow Manager (WFM)

WFM allows for the creation and execution of workflows. A workflow consists of a sequence of
tasks to create an automated procedure. A workflow can be executed on demand, scheduled, or
triggered to run in response to a Kafka event notification. Some workflow examples include node

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 9
NSP product overview NSP
NSP system architecture

software upgrades, service activation tests, service fulfillment with pre- and post-deployment
workflows, and mass migration of services from one tunnel to another.

Baseline Analytics
Baseline Analytics monitors network traffic to establish baselines and flag anomalous traffic
patterns. Traffic patterns can be saved for analysis and comparison, and for automated corrective
action by other NSP applications.

IP resource control (IPRC)

The IPRC performs service provisioning and activation, plus MPLS path computation and traffic
flow management using flow-based protocols such as OpenFlow and BGP FlowSpec. IPRC
performs intelligent traffic steering, and automates policy-based redirection at the flow or route
level. IPRC also manages LSP creation, and supports RSVP and segment-routing LSP
technologies.
IPRC performs service provisioning using operator-defined policies.
An NSP deployment with IPRC requires the VSR-NRC; see 1.2.3 “Additional NSP components”
(p. 9) for information about the VSR-NRC..

Cross-domain resource control (CDRC)

The CDRC optimizes network resources across different layers in IP/MPLS and optical networks.
The CDRC discovers the entire transport topology, including the cross-layer links between IP
routers and optical switches.

1.2.3 Additional NSP components

An NSP system may also include one or more of the components described below, depending on
the NSP functions or applications that you need to enable. Each component supports deployment in
redundant, geographically separate data centers.

Simulation tool
The Simulation tool is a traffic-engineering function that network engineers can use for network
design or optimization. You can simulate failures in an existing network that you import to the tool
from the IPRC.

Virtual Service Router - Network Resource Controller (VSR-NRC)

The VSR-NRC is required in order for IPRC to interface with IP NEs for PCE-PCEP and OpenFlow
communication. The VSR-NRC is a virtual SROS instance that uses the same software image as
the vSIM of the same SROS release number; the VSR-NRC license enables additional interaction
with the NSP. The VSR-NRC software is supported in a Linux KVM environment, or on VMWare
ESXi versions 6.5, 6.7, and 7.0.
For VSR-NRC platform requirements and installation instructions, see the Virtualized 7750 SR and
7950 XRS Simulator (vSIM) Installation and Setup Guide.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
10 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
NSP system architecture

Network Functions Manager - Packet (NFM-P)

The NFM-P, an evolution of the former 5620 SAM product, provides IP/MPLS and mobile network
management using GUI, web, and OSS interfaces. See 1.2.4 “NFM-P architecture” (p. 11) for more
information.

Auxiliary database
An auxiliary database provides scalable, high-throughput storage capacity for specific data
collection functions. An auxiliary database can be deployed on one station, or distributed in a
cluster of at least three member nodes.

Note: BIOS CPU frequency scaling must be disabled on the NFM-P auxiliary database
platform.

NSP Flow Collectors and Flow Collector Controllers

An NSP Flow Collector collects application assurance (AA) Cflowd data and system Cflowd data
from managed NEs using protocols such as IPFIX, Netflow, and CGNAT. The collected flow data is
stored in an NSP database, or forwarded to a remote server.
An NSP Flow Collector Controller extracts the network data from the NFM-P in order to assign NEs
to the associated NSP Flow Collectors. Only one NSP Flow Collector Controller is active at any
time, but multiple Flow Collectors may be active..

NSP analytics servers

An NSP analytics server generates predefined and custom analytics reports in graphical or tabular
format. The reports are viewable from the NSP Analytics application.

Network Functions Manager—Transport (NFM-T)

The NFM-T is an evolution of the former 1350 OMS product that provides end-to-end optical
network management and operational support for all Nokia optical NEs.

1.2.4 NFM-P architecture

The NFM-P system architecture consists of the following components at a minimum:
• NFM-P main server—central network management processing engine
• NFM-P main database—relational database; repository of NFM-P network management data
• NFM-P GUI client—Java-based operator interface

Note: The NFM-P main server and main database support collocated installation on one
station, in addition to distributed installation on separate stations.

Note: IPv6 connectivity is supported between NFM-P components, with the following
exceptions:
• an NFM-P system that manages CMM or eNodeB NEs
• an NFM-P system that includes PCMD auxiliary servers
• NFM-P integration with another EMS

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 11
NSP product overview NSP
NSP system architecture

• dual-stack communication among NFM-P components other than GUI clients

Note: An NE can be managed by only one NFM-P system; multiple NFM-P systems
managing the same NE is not supported, and can cause unexpected behavior.

Additional NFM-P components

The NFM-P can optionally include the following:

• client delegate servers—enable the consolidation of multiple NFM-P GUI client installations on
one station; individual single-user clients can be installed on a client delegate server station, or
multiple users with unique user IDs can share one client installation
NFM-P client delegate server deployment is supported on the following:
− Windows Server 2012 R2
− Windows Server 2016
− Windows Server 2019
− RHEL 7 server x86-64
X.11 and native X are the supported client display-redirection mechanisms for a client delegate
server deployed on RHEL.
Note: Displaying GUI clients to computers running X-emulation software is not supported.
Windows Remote Desktop is the method used for client access to a client delegate server on
Windows Server.
See 2.5 “NFM-P minimum platform requirements” (p. 43) for information about NFM-P client
delegate server platform sizing.
• auxiliary servers—horizontally scalable processing engines on separate stations that distribute
the data-collection workload; each auxiliary server exclusively collects statistics, call-trace, or
PCMD data that is stored in the NFM-P main database, or in an auxiliary database
Auxiliary servers remove the statistics collection and processing load from the main server, and
enable additional collection capabilities.
Note: An NFM-P auxiliary server station must maintain consistent and accurate time using the
same synchronization mechanism as all other NSP components. The RHEL chronyd service is
strongly recommended. Because time variations can cause the NFM-P to stop collecting
statistics prematurely, the NFM-P raises an alarm if the main and auxiliary server times are not
within 30 seconds.
An NFM-P auxiliary server is configured during deployment as one of the following:
− statistics auxiliary server—collects and processes performance, accounting, AA
accounting, and PM statistics data, as well as OAM PM test results. Nokia recommends
deploying a statistics auxiliary server when collection is expected to exceed the NFM-P main
server capacity; see 2.3 “NFM-P Hardware platform requirements” (p. 38) for information
about NFM-P main-server scaling and auxiliary-server deployment dimensioning.
If no statistics auxiliary servers are deployed, the NFM-P main server performs the statistics
collection. Otherwise, a main server never collects statistics. If the NFM-P system includes
statistics auxiliary servers, at least one of the servers must be available in order for statistics
collection to occur.
If the collected statistics are stored in an auxiliary database, or retrieved using the NFM-P
XML API logToFile method, up to three statistics auxiliary servers can collect statistics

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
12 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
Core NSP technologies

concurrently; see 1.5.2 “NFM-P system redundancy” (p. 23) for information about the NFM-P
redundancy model that includes statistics auxiliary servers.
A statistics auxiliary server can be designated as Preferred, Reserved, or Remote for a main
server, depending on the primary or standby role of the main server. The designations enable
geographically redundant fault tolerance.
For PM statistics collection from eNodeB NEs, NTP is recommended for synchronizing the
NE and the auxiliary server to ensure successful statistics retrieval.
Note: NFM-P statistics auxiliary server deployment is supported only in an NFM-P system
that has a distributed main server and main database.
− call-trace auxiliary server— collects call-trace files from CMM and CMG NEs; you can
deploy up to two active call-trace auxiliary servers can be deployed to scale up the call-trace
data collection
In a redundant NFM-P deployment, each active call-trace auxiliary server is assigned to a
distributed or collocated redundant main server; the main servers synchronize the collected
call-trace data. Up to two call-trace auxiliary servers in a redundant deployment can collect
call-trace data; fault tolerance is achieved by configuring each redundant NFM-P call-trace
auxiliary server as the Preferred auxiliary server of the local primary main server, and as the
Reserved auxiliary server of the standby main server. Only one call-trace auxiliary server in a
redundant pair collects call-trace data at any time; the auxiliary server synchronizes the
collected data with the peer auxiliary server.
See 1.5.2 “NFM-P system redundancy” (p. 23) for information about the NFM-P redundancy
model that includes call-trace auxiliary servers.
− PCMD auxiliary server—collects PCMD data streams from SROS-based mobile gateways
that are configured to stream per-call measurement data to the NFM-P. The auxiliary server
uses the data to generate CSV files for transfer to a third-party application for post-
processing. PCMD auxiliary server deployment is supported in a distributed or collocated
NFM-P system, and is supported in a redundant deployment.

1.3 Core NSP technologies

1.3.1 Java Virtual Machine
The NSP, NFM-P and other components employ Java technology. The NSP installation software
includes a Java Virtual Machine, or JVM that is dedicated to the NSP and does not conflict with
other JVMs that may be installed on the same station.
The NSP uses OpenJDK 8; the NFM-P uses JVM 8 from Oracle and OpenJDK 8.

1.3.2 Databases
A NSP deployment has multiple databases. IPRC has a Neo4j database for network topology
information. The nspOS component has a PostgreSQL database for policy management and
common applications data, and a Neo4j database for topology data for the Map Server. Cross-
domain resource control contains a Neo4j database for network topology information.
A Neo4j database contains a graphical representation of the network topology and its elements in a
multi-layer graph. The installation of the Neo4j database is customized for, and must be dedicated
to, the NSP. Data redundancy and replication within an HA cluster is managed within the neo4j
instances.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 13
NSP product overview NSP
Core NSP technologies

The PostgreSQL database contains non-topological NSP information, including policies, templates,
and nspOS common model data. PostgreSQL is an open source database application.
PostgreSQL database redundancy is managed by the role-manager. In a redundant configuration of
the NSP, the active NSP cluster hosts the primary PostgreSQL database. The standby NSP cluster
hosts the standby PostgreSQL database.
In an HA NSP cluster deployment, one PostgreSQL database in the NSP cluster is selected as the
primary database and the other in the NSP cluster is standby. If the active pod fails, then the
standby member is promoted to primary database. In a redundant HA configuration of NSP, the
standby datacenter databases are updated as standby databases.
In an NSP cluster deployment where the customer provides the orchestration layer, each NSP
cluster has one PostgreSQL database instance. Data replication of PostgreSQL database needs to
be provided by the storage layer.

Note: Nokia does not support any PostgreSQL database configuration that deviates from the
NSP installation procedure.
Nokia does not support direct customer access to the Neo4j and PostgreSQL databases.

NFM-P Oracle database

The NFM-P database embeds an installation of Oracle 19c Enterprise Edition, which is installed
with the NFM-P database. This database is used to store information about the managed network.
The installation of Oracle is customized for use with the NFM-P application and must be dedicated
to NFM-P. NFM-P database redundancy uses Oracle DataGuard, and is configured in maximum
performance mode.
Nokia will not support any configuration deviations from the Oracle installation as performed by the
NFM-P database installation package, as it represents an NFM-P License Agreement Violation.
Modifying the Oracle installation can impact system performance, stability and upgrades. Customer
support agreements may be violated.
Access to the Oracle database is restricted to the NFM-P application. Direct user access to the
database is strictly forbidden.
The Oracle database is embedded with NFM-P and because of this, Oracle requires all licenses to
be purchased from Nokia. This applies to customers with Oracle Site licenses as well.
Oracle’s official support position for running Oracle database 19c, embedded within NFM-P, on
VMware hosted virtual environments is described in Oracle Support Note 249212.1. Oracle will
provide support for those running on VMware virtualized environments. In addition, VMware has a
public statement committing to assist with resolving Oracle database issues. Nokia will work with
Oracle and VMware to resolve any NFM-P database issues but problem resolution times may be
impacted in some cases.
Oracle's official support position for running Oracle Database 19c, embedded within NFM-P, on
RHEL KVM hosted virtual environments is that Oracle does not certify any of their products in this
environment. Nokia will work with Oracle and Red Hat to resolve any NFM-P database issues but
due to the lack of Oracle support, problem resolution times may be impacted in some cases.
Customers must be aware of and must accept this risk when choosing to run NFM-P in a RHEL
KVM virtualized environment.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
14 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
Core NSP technologies

Other NFM-P databases

Embedded within the NFM-P server is a Neo4j database and a PostgreSQL database and
embedded within the NFM-P auxiliary database is a Vertica database.
Similar to the Oracle support statement, Nokia will not support any configuration deviations from the
installation as performed by the installation package, as it represents an NFM-P License Agreement
Violation. Modifying the installation can impact system performance, stability and upgrades.
Customer support agreements may be violated..
Access to the PostgreSQL, Neo4j, and Vertica databases is restricted to the NFM-P application.
Direct user access to any of the databases is strictly forbidden.
In a redundant configuration, the active NFM-P server hosts the primary PostgreSQL and Neo4j
databases. The standby NFM-P server hosts the standby PostgreSQL and Neo4j databases.

1.3.3 Network mediation

The NSP application has southbound interfaces that consist of plug-ins that interact with the NFM-P
using CPROTO and HTTP protocols secured with TLS. The NFM-P manages IP network elements
using SNMP.
The NSP communicates with MDM using gRPC, and MDM communicates with network elements
using gRPC/gNMI, NETCONF, SNMP and CLI over SSH or Telnet.
For LSP management functions of the NSP, a VSR-NRC communicates with the PCC network
elements via PCEP, IGP, and BGPLS. For flow control functions, the VSR-NRC OpenFlow
Controller communicates with OpenFlow Switches using the OpenFlow protocol.
The NRC-T is installed with NFM-T to provide a TLS secured REST API for optical network
discovery and service provisioning. The NFM-T uses TL-1 and SNMP to manage optical switches.

1.3.4 Browser applications

NOTICE

View of network can be affected

Browser applications' view of the network can be affected whenever activities are drawing heavily
on CPU and memory usage.
This can happen when a large number of services are being created, modified, or deleted via the
NSP REST APIs.

The NSP provides functionality using browser-based NSP applications. These applications require
that WebGL be enabled and use standard REST security mechanisms for authentication and
authorization. All NSP applications are HTML-5 based and are supported on the following web
browsers:
• Latest version of Google Chrome
• Latest version of Chromium Edge for most applications (see the NSP Release Notice for
restrictions)
• Latest version of Mozilla Firefox

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 15
NSP product overview NSP
NSP deployment

• Latest version of Apple Safari

Additional Internet browsers and older versions may function with NSP applications but are not
supported by Nokia.

Note: You cannot switch browsers between clients or applications. You must always use the
system default browser.

Note: In order for the Safari web browser to open the Analytics application, you must ensure
that the following Safari privacy settings are configured, if present in your browser version:
• Safari Preferences page, Cookies And Website Data—Always Allow
• Prevent cross-site tracking—disabled

Note: If you are using Chrome or Firefox on Windows 8.1 or Windows Server 2012, it is
recommended that you enable ClearType Text for optimal viewing of fonts. To enable, open
the Display settings in Windows Control Panel and enable the Turn on ClearType parameter
under the Adjust ClearType text settings.

Localized language support

All NSP applications support localized language display. Localized language display, also known as
internationalization, displays GUI text in a specified language. The localized language setting
applies to most GUI objects, except system components and database objects. Contact Nokia
technical support for more information about localized language support.

Note: The NSP components support localized language settings using predefined strings, and
do not translate data to different languages.

1.3.5 APIs
The NSP applications provide northbound REST and RESTCONF APIs with Swagger-compliant
documentation. Each northbound API supports queries, service-creation requests, and other
functions. See the Network Developer Portal for information.

1.4 NSP deployment

1.4.1 NSP deployment types
An NSP deployment in a data center consists of the following, as outlined in 1.2 “NSP system
architecture” (p. 9):
• container environment in which a Kubernetes orchestration layer co-ordinates NSP service
deployment in the set of VMs called the NSP cluster
• RPM-based components on separate stations or VMs outside the NSP cluster

Production deployment
Figure 1-1, “NSP system, production deployment” (p. 17) shows a typical three-node NSP cluster
and a number of external RPM-based components. Depending on the specified NSP deployment
profile, a cluster may have additional nodes.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
16 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
NSP deployment

Figure 1-1 NSP system, production deployment

Customer-Provided K8s
(example of POD deployment
placement is done by K8S)

K8s Node K8s Node K8s Node

k8s master* k8s worker k8s master* k8s worker k8s worker

IM MDM RTA nsp-tomcat OAM MDM RTA nrcx-tomcat IM LSO MDM RTA
IM-tc app1-tc TSC ACT solr app2-tc ACT app3-tc mdm-tc ACT
kafka neo4j File server kafka neo4j nspos-tc kafka neo4j nspos-tc
Centralized Prometheus zookeeper Centralized Health zookeeper Centralized postgres zookeeper
Logging Grafana Logging monitor Logging

Common Storage

VM/BareMetal (X2 for DR)

VM VM VM VM VM

NFM-P Analytics Vertica FCC/FC VSR-NRC

XXX Docker images no replication for HA

XXX Docker images replication for HA
XXX RPM packages

36055

Lab deployment
A one-node NSP cluster is used in a lab deployment, as shown in Figure 1-2, “NSP system, lab
deployment” (p. 18).

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 17
NSP product overview NSP
NSP deployment

Figure 1-2 NSP system, lab deployment

Nokia Lab-Installed K8s

on VM/BareMetal

K8s Node

k8s master* k8s worker

VM

IM OAM MDM RTA WFM LSO TSC

IM-tc app1-tc ACT solr app2-tc app3-tc mdm-tc
deployer
node kafka neo4j File nsp-tomcat Health nspos-tc
server monitor
Centralized Prometheus zookeeper nrcx-tomcat postgres
Logging Grafana

VM/BareMetal

VM VM VM VM VM

NFM-P Analytics NFM-T FCC/FC VSR-NRC

XXX Docker images

XXX RPM packages
XXX QCOW image

36056

1.4.2 NSP system redundancy

The NSP components support standalone and redundant deployment as well as High Availability
(HA) deployment of NSP services in a fault-tolerant multi-node NSP cluster called an enhanced
cluster. HA is achieved using Kubernetes pod replicas. NSP service HA ensures minimal downtime
in the event of a primary instance failure, and avoids a system switchover to the redundant NSP
data center.
A NSP deployment can include the NFM-P and NFM-T, which also support redundant deployment.
When a NSP deployment includes the NFM-P or NFM-T, each system must use the same
redundancy model—standalone or redundant; mixed redundancy models are not supported.

Note: A redundant NSP deployment supports classic HA and fast-HA NFM-T deployment; see
the NSP 22.6 Release Notice for compatibility information.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
18 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
NSP deployment

In a redundant deployment of NSP that includes the NFM-P and NFM-T, the primary NSP cluster
operates independently of the primary NFM-P and NFM-T; if the NSP cluster undergoes an activity
switch, the new primary cluster connects to the primary NFM-P and NFM-T. Similarly, if the NFM-P
or NFM-T undergoes an activity switch, the primary NSP cluster connects to the new primary
NFM-P or NFM-T.
Figure 1-3, “Redundant NSP deployment including NFM-P and NFM-T” (p. 18) shows a fully
redundant NSP deployment that includes the NFM-P and NFM-T.

Figure 1-3 Redundant NSP deployment including NFM-P and NFM-T

Primary Standby
NSP NSP
cluster cluster

Primary Standby Primary standby

NFM-P NFM-P NRC-T/ NRC-T/
NFM-T NFM-T

Optical
Transport
Network
IP Network Elements
Elements
26495

VSR-NRC redundancy
The VSR-NRC also supports redundant deployment. A standalone NSP can be deployed with a
standalone or redundant VSR-NRC. When NSP is installed with a redundant VSR-NRC, if the
communication channel between NSP and primary VSR-NRC fails, then the NSP switches
communication to the standby VSR-NRC.
In a DR deployment of NSP, a redundant deployment of VSR-NRC is required. The primary NSP
will communicate to NEs through the primary VSR-NRC, but if the communication channel to
primary VSR-NRC fails, then the primary NSP can switch to the standby VSR-NRC.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 19
NSP product overview NSP
Including the NFM-P in an NSP deployment

Figure 1-4 Redundant NSP deployment with redundant VSR-NRC

Primary Standby
NSP NSP

Primary Standby
VSR-NRC VSR-NRC

27498

When an activity switch takes place between redundant NSP clusters, the new active NSP cluster
communicates with IP NEs through its corresponding VSR-NRC instance.

MDM redundancy and HA

The MDM is deployed within the NSP cluster. In an NSP cluster, only one MDM pod can be
deployed on each node within the cluster (eg. a 3 node cluster can deploy 3 MDM pods). In a
redundant NSP cluster deployment, each NSP cluster will have the same number of nodes and
MDM instances.
A single node NSP cluster can only deploy one MDM pod. HA of MDM will not be available in this
configuration.
In a multi-node NSP cluster, the MDM pods are deployed in a N+M deployment (where N+M equals
the number of nodes in the cluster), with N active MDM instances and M standby instances. If an
active MDM instance fails, a standby MDM instance in the active cluster will take over management
of the nodes that were managed by the failed MDM instance. When the failed instance recovers, it
becomes a standby instance (it will not automatically revert to active). When more than M active
MDM instances fail, a manual activity switch to the standby NSP cluster will be required. Each NSP
cluster must have the same N+M configuration of MDM.

1.5 Including the NFM-P in an NSP deployment

1.5.1 NFM-P deployment types
Figure 1-5, “Collocated standalone NFM-P deployment” (p. 21) is an example of a standalone
NFM-P deployment in which the NFM-P main server and main database are collocated on one
station.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
20 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
Including the NFM-P in an NSP deployment

Figure 1-5 Collocated standalone NFM-P deployment

Managed
network

NFM-P clients NFM-P server/

database
22675

Figure 1-6, “Distributed standalone NFM-P deployment” (p. 21) is an example of a standalone
NFM-P deployment in which the NFM-P main server and main database are hosted on separate
stations.

Figure 1-6 Distributed standalone NFM-P deployment

Managed
network

NFM-P clients NFM-P server

NFM-P database
22674

The following illustrates a typical deployment of NFM-P in standalone mode when the NFM-P
server and NFM-P database functions are collocated and an NFM-P auxiliary call-trace server is
used. The NFM-P auxiliary statistics server is not supported in this configuration.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 21
NSP product overview NSP
Including the NFM-P in an NSP deployment

Figure 1-7 NFM-P standalone deployment – collocated NFM-P server and NFM-P database
configuration and NFM-P auxiliary call-trace server

Managed
network

NFM-P clients NFM-P server\

database

NFM-P auxiliary
call trace collector(s)
22673

The following illustrates a typical deployment of NFM-P in standalone mode when the NFM-P
server and NFM-P database functions are in a distributed configuration and NFM-P auxiliary
servers are used. In this configuration there can be up to three active NFM-P auxiliary statistics
servers or it could be configured redundant, and there can be one or two NFM-P auxiliary call-trace
servers collecting call-trace data from the network.

Figure 1-8 NFM-P standalone deployment - distributed NFM-P server and NFM-P database
configuration and NFM-P auxiliary servers

Managed
network

NFM-P
NFM-P clients server

NFM-P NFM-P auxiliary NFM-P auxiliary

database statistics collector call trace collector(s)
22672

The following illustrates a deployment of NFM-P in standalone mode when the NFM-P server and
NFM-P database functions are in a distributed deployment and NFM-P auxiliary servers are
installed with statistics collection using the NFM-P auxiliary database. In this configuration, there
can be up to three preferred NFM-P auxiliary statistics servers. There can be one or two NFM-P
auxiliary call-trace servers collecting call-trace data from the network. The NFM-P auxiliary
database cluster comprises of either a single instance or a cluster of at least three instances.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
22 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
Including the NFM-P in an NSP deployment

Figure 1-9 NFM-P standalone deployment - distributed NFM-P server and NFM-P database
configuration and NFM-P auxiliary servers with statistics collection using the NFM-P
auxiliary database

Managed
network
NFM-P
NFM-P clients server

NFM-P NFM-P auxiliary NFM-P auxiliary NFM-P auxiliary

database database cluster statistics call trace
collector(s) collector(s)
24407

For bare metal installations, the NFM-P server, NFM-P auxiliary server, NSP Flow server, NSP Flow
Collector Controller, NFM-P auxiliary database, NSP analytics server, and NFM-P database are
supported on specific Intel x86 based HP and Nokia AirFrame stations.
The NFM-P client and client delegate server software may be installed on stations running different
operating systems from the NFM-P server, NFM-P auxiliary, NFM-P auxiliary database, NSP Flow
Collector, NSP Flow Collector Controller, NSP analytics server, and NFM-P database. The NFM-P
client can be installed on RHEL 7 server x86-64, Windows, or Mac OS where the NFM-P client
delegate server can be installed on RHEL 7 server x86-64, Windows Server 2012 R2, Windows
Server 2016, or Windows Server 2019. See 3.5 “Third party software for NFM-P single-user client
or client delegate server” (p. 62) for Operating System specifics.
All NFM-P stations in the NFM-P management complex must maintain consistent and accurate
time. The RHEL chronyd service is strongly recommended as the time-synchronization mechanism.

1.5.2 NFM-P system redundancy

NFM-P supports redundancy of the NFM-P server, NFM-P database, NFM-P auxiliary server, and
NSP analytics server stations. The NFM-P auxiliary statistics server supports 3+1 redundancy.

Redundancy between NFM-P server and database applications is used to ensure visibility of the
managed network is maintained when one of the following failure scenarios occur:
• Loss of physical network connectivity between NFM-P server and/or NFM-P database and the
managed network

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 23
NSP product overview NSP
Including the NFM-P in an NSP deployment

• Hardware failure on station hosting the NFM-P server and/or NFM-P database software
component

NFM-P supports redundancy of the NFM-P server and NFM-P database components in the
following configurations:
• NFM-P server and NFM-P database collocated configuration
• NFM-P server and NFM-P database distributed configuration
The following illustrates an NFM-P redundant installation when the NFM-P server and NFM-P
database components are installed in a collocated configuration.

Figure 1-10 NFM-P collocated server/database redundancy deployment

NFM-P
clients

NFM-P Oracle DataGuard NFM-P

server/ server/
database database
primary standby
Managed
network

22671

The following illustrates an NFM-P redundant installation when the NFM-P server and NFM-P
database components are located on different stations in a distributed configuration.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
24 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
Including the NFM-P in an NSP deployment

Figure 1-11 NFM-P distributed server/database redundancy deployment in a geographically

redundant setup.

NFM-P
clients

Geographic location A Geographic location B

NFM-P NFM-P
database database
active standby

NFM-P NFM-P
server server
active standby
Managed
network

22670

Redundancy and NFM-P auxiliaries and NSP Flow Collectors

In customer networks, where the statistics collection requirements exceed the scalability
capabilities of an NFM-P server, the NFM-P auxiliary statistics server can be used. As with other HA
components, the NFM-P auxiliary statistics server can be configured to be redundant. When
collecting statistics using the NFM-P database, each NFM-P server can be configured to have one
preferred and one reserved NFM-P auxiliary statistics server. When collecting statistics using the
NFM-P auxiliary database or using logToFile only, each NFM-P server can be configured with up to
three preferred and one reserved NFM-P auxiliary statistics server.
When call-trace information is being collected from CMM and CMG network elements in customer
networks, an NFM-P auxiliary call-trace server must be used. The NFM-P auxiliary call-trace server
can be installed in a redundant pair where up to two NFM-P auxiliary call-trace server redundant
pairs can be installed.
In customer networks where cflowd data is to be collected from network elements, an NSP Flow
Collector must be used. The NSP Flow Collector can only be installed in a standalone configuration.
To achieve data redundancy, network elements can be configured to forward cflowd data to multiple
NSP Flow Collectors. The NSP Flow Collector Controller can be installed in a standalone or
redundant configuration.
For the collection of per-call measurement data from SGW/PGW network elements, an NFM-P
auxiliary PCMD server must be used. The NFM-P auxiliary PCMD server can be installed in a
standalone or redundant configuration. Data collected by the NFM-P auxiliary PCMD server is not
replicated to the redundant server.
In Figure 1-12, “NFM-P distributed server/database redundant deployment with redundant NFM-P
auxiliaries that crosses geographic boundaries” (p. 27) there are NFM-P auxiliary servers
configured. In the example where redundancy is geographic, there can be up to four NFM-P

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 25
NSP product overview NSP
Including the NFM-P in an NSP deployment

auxiliary statistics servers and up to two NFM-P auxiliary call-trace server stations configured in
each geographic location. The Preferred/Reserved/Remote role of the NFM-P auxiliary statistics
server is dependent upon and configured, based on the NFM-P server that is active. When there
are more than one active auxiliary statistics server, local redundancy (Preferred/Reserved) of the
auxiliary statistics server must be used in conjunction with geographic redundancy, where the same
number of auxiliary statistics servers will be deployed in each geographic site. The NFM-P auxiliary
statistics servers in the opposite geographic location are configured to be Remote. In this scenario,
if one of the NFM-P auxiliary statistics servers for the active NFM-P server were no longer
available, the active NFM-P server would use the reserved NFM-P auxiliary statistics server in the
same geographic location to collect statistics. Figure 1-13, “NFM-P distributed server/database
redundant deployment with redundant NFM-P auxiliaries using the NFM-P auxiliary database for
statistics collection” (p. 28) shows the same redundant configuration but with statistics collection
using a geographically redundant NFM-P auxiliary database. Latency between geographic sites
must be less than 200 ms.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
26 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
Including the NFM-P in an NSP deployment

Figure 1-12 NFM-P distributed server/database redundant deployment with redundant NFM-P
auxiliaries that crosses geographic boundaries

NFM-P
clients

Geographic location A Geographic location B

Oracle DataGuard

NFM-P NFM-P
database database
active standby

NFM-P server NFM-P server

active standby

Resync of data files

NFM-P auxiliary NFM-P auxiliary

statistics collector statistics collector
preferred for the preferred for the
active server standby server
reserved for the reserved for the
standby server active server

Resync of data files

NFM-P auxiliary NFM-P auxiliary

call trace collector(s) call trace collector(s)
preferred for the preferred for the
active server standby server
reserved for the reserved for the
standby server active server
Managed
network

22669

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 27
NSP product overview NSP
Including the NFM-P in an NSP deployment

Figure 1-13 NFM-P distributed server/database redundant deployment with redundant NFM-P
auxiliaries using the NFM-P auxiliary database for statistics collection

NFM-P
clients

Geographic location A Geographic location B

Oracle DataGuard

NFM-P NFM-P
database database
active standby

NFM-P NFM-P
server server
active standby

Resync of data files

NFM-P auxiliary NFM-P auxiliary

statistics collector statistics collector
preferred for the preferred for the
active server standby server
reserved for the reserved for the
standby server active server

NFM-P auxiliary NFM-P auxiliary

database database
cluster cluster

Resync of data files

NFM-P auxiliary NFM-P auxiliary

call trace collector(s) call trace collector(s)
preferred for the preferred for the
active server standby server
reserved for the reserved for the
standby server active server
Managed
network

24405

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
28 3HE-18161-AAAB-TQZZA Issue 1
NSP product overview NSP
Including the NFM-P in an NSP deployment

Further information about NFM-P redundancy can be found in the NSP NFM-P User Guide.

Redundancy deployment considerations for NFM-P

When deploying NFM-P in a redundant configuration, the following items must be considered.
It is a best practice to keep the NFM-P server, NFM-P database, and NFM-P auxiliary servers in the
same geographic site to avoid the impact of network latency. When the NFM-P database or NFM-P
server switches sites, the NFM-P auto-align functionality will ensure the NFM-P server, and NFM-P
auxiliary servers are all aligned in the same geographic location. If the auto-align functionality is not
enabled, a manual switch of the stations is desirable.

Redundancy with collocated NFM-P server/database

Requirements:
• The operating systems installed on the primary and standby NFM-P server/database must be of
the same versions and at the same patch levels.
• The layout and partitioning of the disks containing the NFM-P software, the Oracle software and
the database data must be identical on the active and standby NFM-P server/database.
• The machine which will be initially used as the active NFM-P server/database must be installed
or upgraded before the machine that will initially be used as the standby.
• The stations hosting the NFM-P software should be connected in a way to prevent a single
physical failure from isolating the two stations from each other.
• Stations that host the NFM-P server/database software must be configured to perform name
service lookups on the local station before reverting to a name service database located on the
network such as NIS, NIS+, or DNS. A root user must inspect and modify the /etc/nsswitch.conf
file to ensure that files is the first entry specified for each database listed in the file.

Redundancy with distributed NFM-P server and NFM-P database

Requirements:
• The operating systems installed on the primary and standby NFM-P server as well as the
primary and standby NFM-P database must be of the same versions and at the same patch
levels.
• The layout and partitioning of the disks containing the NFM-P software, the Oracle software and
the database data must be identical on the primary and standby NFM-P database.
• The machines which are intended to be used as primary NFM-P server and NFM-P database
should be installed on the same LAN as one another with high quality network connectivity.
• The machines which are intended to be used as standby NFM-P server and standby NFM-P
database should be installed on the same LAN as one another with high quality network
connectivity.
• The pair of stations to be used as active NFM-P server and NFM-P database should be
connected to the pair of stations to be used as standby NFM-P server and NFM-P database in a
way that will prevent a single physical failure from isolating the two station pairs from each other.
• Stations that host the NFM-P server and NFM-P database software must be configured to

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 29
NSP product overview NSP
Including the NFM-P in an NSP deployment

perform name service database lookups on the local station before reverting to a name service
located on the network such as NIS, NIS+, or DNS. A root user must inspect and modify the /etc/
nsswitch.conf file to ensure that files is the first entry specified for each database listed in the file.

Redundancy with distributed NFM-P server and NFM-P database and NFM-P auxiliary
servers

In addition to the rules stated above for distributed NFM-P server and NFM-P database, the
following rules apply:
• The operating systems installed on the NFM-P auxiliary servers must be of the same versions
and patch levels as the NFM-P server and NFM-P database stations.
• If collecting statistics using the NFM-P auxiliary database, the operating systems installed on the
NFM-P auxiliary database stations must be of the same versions and patch levels as the NFM-P
server, NFM-P database, and NFM-P auxiliary statistics server stations.
• NFM-P auxiliary servers are intended to be on the same HA network as the NFM-P server and
NFM-P database. NFM-P auxiliary statistics, call-trace, and PCMD servers are intended to be
geographically collocated with the active and standby locations of the NFM-P server and NFM-P
database. The NSP Flow Collector typically resides in the managed network, closer to the
network elements.
• When the NFM-P auxiliary database is deployed in a cluster of at least three separate instances,
it can tolerate a single instance failure with no data loss. All NFM-P auxiliary database nodes in
the same cluster must be deployed in the same geographic site, with less than 1 ms of latency
between the nodes. A second cluster can be deployed to implement geographic redundancy and
must contain the same number of nodes as the primary cluster.
• When using more than one active NFM-P auxiliary statistics server in a geographic (greater than
1 ms latency) configuration, the active and reserved servers for a give NFM-P server must reside
in the same geographic site. The auxiliary statistics servers in the opposite geographic site
would be configured as Remote.
• Stations that host the NFM-P auxiliary server software must be configured to perform name
service database lookups on the local station before reverting to a name service database
located on the network such as NIS, NIS+, or DNS. A root user must inspect and modify the /etc/
nsswitch.conf file to ensure that files is the first entry specified for each database listed in the file.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
30 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NSP container environment requirements

2 NSP system requirements

2.1 NSP container environment requirements

2.1.1 Supported NSP cluster environments

An NSP cluster can be deployed in the following Kubernetes/Docker/Helm container environments:

• Nokia-provided
• customer-provided
The NSP environment requirements in this chapter are specific to Nokia container environments.
Nokia supports and recommends installing NSP components on VMs using VMWare ESXi or RHEL
KVM, including OpenStack. The guest OS must be a supported RHEL version.
Note: In NSP Release 22.6, NSP system deployment in a customer-provided environment is
Limited Availability; contact your Nokia representative for more information.

2.1.2 Supported Kubernetes, Docker, and Helm versions

The NSP is validated against a container environment that uses the following Kubernetes, Docker,
and Helm versions:

Table 2-1 Supported containerization element versions

Containerization element Supported version

kubeadm v1.20.7
Docker client 20.10.8
Docker server 20.10.8
Helm server v3.5.4

2.1.3 KVM virtualization

The NSP supports using RHEL 6, RHEL 7, and RHEL 8 based KVM on x86 based servers natively
supported by KVM. The Host Environment Compatibility Reference for NSP and CLM should be
consulted for up-to-date KVM compatibility along with requirements and restrictions. See the RHEL
Hardware Compatibility List (HCL) to determine specific hardware support.
Not all features offered by KVM are supported when using the NSP. For example, Snapshots, Live
Migration and HA are not supported. Contact Nokia to determine if a specific KVM feature is
supported with an installation of NSP.

KVM configuration
When you configure the KVM, set the parameters listed in the following table to the required values.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 31
NSP system requirements NSP
NSP container environment requirements

Table 2-2 KVM configuration parameters

Parameter Value
Disk Controller type virtio
Storage format raw
Cache mode none
I/O mode native
NIC device model virtio
Hypervisor type kvm

2.1.4 OpenStack virtualization

The NSP is tested in an open-source OpenStack environment. Nokia supports NSP deployment on
any OpenStack distribution that is based on the tested version. Any product issues deemed related
to a specific distribution must be pursued by the customer and OpenStack vendor. The supported
OpenStack versions include Newton, Queens and Train.
To ensure NSP compatibility with an OpenStack environment, you must follow the requirements in
the following topics.

Hypervisor
KVM is the only supported hypervisor for an OpenStack environment. For information about the
supported KVM hypervisor versions, see 2.1.3 “KVM virtualization” (p. 31).

CPU and memory resources

The required CPU and memory resources must be reserved and dedicated to each guest OS, and
cannot be shared or oversubscribed. You must set the following parameters to 1.0 in the
OpenStack Nova configuration on the control NE, or on each individual compute node that may
host an NSP VM”
• cpu_allocation_ratio
• ram_allocation_ratio

HyperThreading
The usage of CPUs with enabled HyperThreading must be consistent across all compute nodes. If
the CPUs do not support HyperThreading, you must disable HyperThreading at the hardware level
on each compute node that may host an NSP VM.

CPU pinning
CPU pinning is supported, but may restrict some OpenStack functions such as migration.

Availability zones/affinity/placement
Nokia does not provide recommendations for configuring VM placement in OpenStack.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
32 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NSP container environment requirements

Migration
The OpenStack environment supports only regular migration; live migration is not supported.

Networking
Basic Neutron functions using Open vSwitch with the ML2 plugin are supported in an NSP
deployment, as is the use of OpenStack floating IP addresses.

Storage
All storage must meet the throughput and latency performance criteria in the response to your NSP
Platform Sizing Request.

VM storage
The VM storage must be persistent block (Cinder) storage, and not ephemeral. In order to deploy
each VM, you must create a bootable Cinder volume. The volume size is indicated in the response
to your NSP Platform Sizing Request.

Flavors
Flavors must be created for each Station Type described in the response to your NSP Platform
Sizing Request.

Firewalls
You can enable firewalls using OpenStack Security Groups, or on the VMs using the firewalld
service, except as noted. If firewalld is enabled, an OpenStack Security Group that allows all
incoming and outgoing traffic must be used.

2.1.5 VMware virtualization

The NSP supports using VMware vSphere ESXi 6.5, 6.7 and 7.0 only, on x86 based servers
natively supported by ESXi. See the VMware Hardware Compatibility List (HCL) to determine
specific hardware support.
Not all features offered by ESXi are supported when using the NSP. For example, Fault Tolerant,
High Availability (HA), Memory Compression, Distributed Resource Scheduler (DRS), and vMotion
features are not supported. VM snapshots are not supported when using NSP. Contact Nokia to
determine if a specific ESXi feature is supported with an NSP installation.

Note: The system clocks of the NSP components must always be closely synchronized. The
RHEL chronyd service is strongly recommended as the time-synchronization mechanism to
engage on each NSP component during deployment.
Only one time-synchronization mechanism can be active in an NSP system. Before you
enable a service such as chronyd on an NSP component, you must ensure that no other time-
synchronization mechanism, for example, the VMWare Tools synchronization utility, is
enabled.
Virtual Machine Version 11 or above must be used. The deployer host OVA file provided in the NSP
software bundle is built using Virtual Machine Version 14.
See the following table for additional Virtual Machine setting requirements:

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 33
NSP system requirements NSP
NSP cluster requirements

Table 2-3 Additional Virtual Machine setting requirements

Resource type Parameter Setting

CPU Shares Set to High
Reservation Must be set to the number of
vCPUs * the CPU frequency.
For example, on a 2.4 GHz 8
vCPU configuration, the
reservation must be set to
(8*2400) = 19200 MHz.
Limit Check box checked for
unlimited
Memory Shares Set to High
Reservation Reserve all guest memory
Limit Check box checked for
unlimited
Disk Shares Set to High
Limit - IOPs set to Unlimited
Type Thick Provision Eager Zeroed
SCSI controller Type VMware Paravirtual
Network Adapter Type VMXNET 3

2.2 NSP cluster requirements

2.2.1 Cluster sizing criteria
An NSP cluster must be sized according to the requirements defined by the Nokia NSP Platform
Sizing Tool, which calculates the minimum platform requirements based on the specified installation
options.

The platform requirements for NSP cluster VMs and VMs that host additional components depend
on, but are not limited to, the following factors:
• number of managed LSPs and services
• number of managed NEs
• number of MDM learned services
• number of simultaneous operator and API sessions
• expected numbers of:
− flows
− monitored NEs
− AS

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
34 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NSP cluster requirements

− ports with real-time statistics collection

Note: The NSP cluster VMs require sufficient available user IDs to create system users for
NSP applications.

Note: The disk layout and partitioning of each VM in a multi-node NSP cluster, including DR
deployments, must be identical.

2.2.2 NSP VM hardware requirements

NSP deployments are server- and vendor-agnostic, but must meet all NSP component hardware
criteria and performance targets. Server-class hardware is required; desktop hardware is
inadequate. Processor support is limited to specific Intel Xeon-based x86-64 CPUs that have the
required minimum CPU core speed listed in Table 2-4, “VM processor requirements” (p. 34).

Table 2-4 VM processor requirements

Processor microarchitecture Minimum CPU core speed Supported deployments

Haswell or newer 2.4 GHz Supported for all NSP
deployments
Skylake or newer 2.0 GHz Supported on the following
components only
• NSP cluster VMs and
deployer host
• VSR-NRC

Note: In Release 22.6, the Skylake microarchitecture using a CPU speed of less than
2.4GHz, is supported for NSP deployments that do not use Multi-layer Discovery and
Visualization and Multi-layer Control Coordination Installation Options.
Defined CPU and Memory resources must be reserved for the individual Guest OSs and cannot be
shared or oversubscribed. This includes individual vCPUs which must be reserved for the VM.
Provisioned CPU resources are based upon threaded CPUs. The NSP Platform Requirements will
specify a minimum number of vCPUs to be assigned to the VM. VMs are recommended to be
configured with all vCPUs on one virtual socket.
A host system requires CPU, memory and disk resources after resources for NSP VMs have been
allocated. Contact the hypervisor provider for requirements and best practices related to the hosting
environment.
You must provide information about the provisioned VM to Nokia support. You can provide the
information through read-only hypervisor access, or make the information available upon request.
Failure to provide the information may adversely affect NSP support.

2.2.3 NSP cluster storage-layer performance

The storage layer of an NSP cluster requires a minimum read/write IOPS based on deployment
type and network size; each NSP cluster member requires the appropriate minimum IOPS listed in

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 35
NSP system requirements NSP
NSP cluster requirements

Table 2-5, “Minimum NSP cluster IOPS requirements” (p. 35); see Chapter 8, “Appendix A” for
information about how to determine the current storage-layer performance.

Table 2-5 Minimum NSP cluster IOPS requirements

Deployment Type and Network Size Minimum storage-layer read/write IOPS

Lab/trial 2000
Production: Fewer than 2000 NEs 2500
Production: More than 2000 NEs 3000

2.2.4 Minimum and production platform requirements

WARNING

Service Degradation Risk

The NSP deployer host is a crucial element of an NSP system that holds the required Docker and
Helm repositories for deployment to each NSP cluster VM. If the NSP deployer host is unavailable,
NSP cluster recovery in the event of a failure may be compromised.
Ensure that the NSP deployer host remains operational and reachable by the NSP cluster after the
cluster deployment.
A deployment of a container based NSP software component in a Nokia-provided container
environment will be sized according to the deployment type and the number of installation options
enabled. Each deployment requires a deployer node and one or more worker nodes. The worker
nodes require vCPU, memory and disk space as specified by the NSP Sizing Tool. These platform
requirements support the network dimensions described in Chapter 5, “Scaling and performance”.
The following table shows the NSP cluster deployment types with number of nodes in a Nokia
provided container environment.

Table 2-6 Platform requirements for NSP cluster deployment

Deployment Basic Medium/Standard Enhanced (HA)

Kubernetes node 1 node 3 or 4 nodes 7 nodes
count
Cluster deployer vCPU: 2 vCPU: 2 vCPU: 2
(upgrading from Memory: 4 GB Memory: 4 GB Memory: 4 GB
earlier release) Disk: 250 GB Disk: 250 GB Disk: 250 GB
Cluster deployer vCPU: 4 vCPU: 4 vCPU: 4
(new installations) Memory: 8 GB Memory: 8 GB Memory: 8 GB
Disk: 250 GB Disk: 250 GB Disk: 250 GB

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
36 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NSP cluster requirements

The NSP Sizing Tool specifies the overall vCPU, memory and disk space requirements; typically,
however, a Kubernetes worker node is a VM with the following specifications:
• vCPU: 24
• Memory: 64 GB
• Disk: 900 GB
A Basic NSP cluster deployment requires 32 vCPU and 80 GB of memory and supports the NSP
Platform feature package plus one additional feature package.
A lab/trial NSP cluster deployer node requires a minimum of 2 vCPU, 4 GB memory and 250 GB
disk.
The Simulation Tool NSP deployment must be deployed as type “lab” or “ip-mpls-sim”. Type “ip-
mpls-sim” uses higher minimum resources for CPU and memory. The Simulation Tool NSP cluster
deployer requires a minimum of 2 vCPU, 4 GB memory and 250 GB disk.

Note: The Kubernetes node count represents the number of nodes in a single NSP cluster. A
redundant NSP cluster requires that number of nodes at each datacenter.
The following table lists the minimum and production platform requirements for deployment of VSR-
NRC as described in the NSP Installation and Upgrade Guide.

Table 2-7 Platform requirements for a VSR-NRC deployment

Component Minimum platform Production platform

VSR-NRC CPU: 4 vCPU CPU: 4 vCPU
Memory: 4 GB Memory: 8 GB
Disk space: 5 GB Disk space: 5 GB

Note: Verify that the VSR-NRC platform specifications are consistent with the specifications
provided in the Virtualized 7750 SR and 7950 XRS Simulator (vSIM) Installation and Setup
Guide for this release.

2.2.5 VM memory
The virtual memory configuration of each NSP cluster VM requires a parameter change to support
Centralized Logging.
The following command entered as the root user displays the current setting:
sysctl -a | grep “vm.max_map_count”
If the setting is not at least 26 2144, you must enter the following command before you deploy the
NSP:
sysctl -w vm.max_map_count=262144

2.2.6 Time synchronization

The system clocks of the NSP components must always be closely synchronized. The RHEL
chronyd service is strongly recommended as the time-synchronization mechanism to engage on
each NSP component during deployment.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 37
NSP system requirements NSP
NFM-P Hardware platform requirements

Note: Only one time-synchronization mechanism can be active in an NSP system. Before you
enable a service such as chronyd on an NSP component, you must ensure that no other time-
synchronization mechanism, for example, the VMWare Tools synchronization utility, is
enabled.

2.2.7 Using hostnames

The hostname of an NSP component station must meet the following criteria:
• include only alphanumeric ASCII characters and hyphens
• not begin or end with a hyphen
• if an FQDN, FQDN components are delimited using periods
• hostname FQDN does not exceed 63 characters

Note: If you use hostnames or FQDNs to identify the NSP components in the NSP
configuration, the hostnames or FQDNs must be resolvable using DNS.

2.3 NFM-P Hardware platform requirements

2.3.1 Overview
For all bare metal installations, Nokia requires the use of supported HP or Nokia AirFrame Intel
based x86 stations running RHEL.
For optimal disk I/O performance, the read and write caches must be enabled for each disk /
volume. Specific HBA controllers may be required for certain platforms to ensure that the read and
write caches can be enabled. Contact the server vendor to determine the correct HBA controller for
creation of the correct number of volumes, and to enable the read and write caches.
Redundant installations of NFM-P can use different stations for the active and inactive platforms
provided that each of the servers meet the minimum requirements for the intended deployment. In
the case where different platforms are used, performance differences are expected depending upon
which server is active.
The hardware platforms do not support running applications that are not specifically identified for
that platform. For instance, an NFM-P client is not supported on the hardware platform for a
distributed or collocated NFM-P server as there is a significant memory requirement for the NFM-P
client that will impact the behavior of the NFM-P server platform.
In exceptional circumstances, a single NFM-P GUI client can be temporarily run from an NFM-P
server, but should only be used when remote clients are unavailable.
NFM-P supports the use of the Operating System SNMP agent for monitoring platform availability
and system resources. The number of OIDs retrieved must not exceed 100 per minute to ensure
NFM-P is not negatively impacted.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
38 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
Hardware platform and resource requirements using virtualization

2.4 Hardware platform and resource requirements using virtualization

2.4.1 Overview
Virtualization is supported using VMware vSphere ESXi, RHEL KVM, and OpenStack. All other
forms of virtualization or virtualization products are not supported.
For installations of the NFM-P server, NFM-P database, NFM-P auxiliary database, NSP Flow
Collector, NSP Flow Collector Controller, and NFM-P auxiliary collector on a Guest Operating
System of a virtualized installation, the Guest Operating System must be an NFM-P supported
version of RHEL 7 server x86-64. For installations of the NFM-P client and NFM-P client delegate
server on a Guest Operating System of a virtualized installation, the Guest Operating System can
be either an NFM-P supported version of RHEL 7 Server or Windows.
Defined CPU and Memory resources must be reserved and dedicated to the individual Guest OSs
and cannot be shared or oversubscribed. As a best practice, VMs should be configured with a
single virtual socket with all vCPUs assigned to it, if possible. Additional hardware resources should
be reserved for use by the host hypervisor installation to ensure that the resources assigned to the
Guest OSs is not impacted. Disk and Network resources should be managed appropriately to
ensure that other Guest OSs on the same physical server do not negatively impact the operation of
NFM-P.
Virtualized installations of NFM-P are server vendor agnostic but must meet specific hardware
criteria and performance targets to be used with NFM-P. Server class hardware must be used, not
desktops. Processor support is limited to specific Intel Xeon based x86-64 CPUs with a minimum
CPU core speed as outlined in the proceeding tables. The CPU must be from the Haswell
microarchitecture, or newer, where the CPU microarchitecture determines the minimum supported
CPU speed.
For best performance, storage should be either internal disks (10K or 15K RPM SAS), Fiber
Channel attached storage (array or SAN) with dedicated Fiber Channel connections between hosts
and Storage Arrays, or 10Gb iSCSI using non-shared infrastructure. All storage must meet the
performance metrics provided with NFM-P platform sizing responses. Performance must meet the
documented requirements for both throughput and latency.
You must provide information about the provisioned VM to Nokia support. You can provide the
information through read-only hypervisor access, or make the information available upon request.
Failure to provide the information may adversely affect NFM-P support.

2.4.2 VMware virtualization

NFM-P supports using VMware vSphere ESXi 5.5, 6.0, 6.5, 6.7, and 7.0 only, on x86 based servers
natively supported by ESXi. If using the NSP RHEL OS image, only VMware vSphere ESXi 6.5, 6.7,
and 7.0 are supported. See the VMware Hardware Compatibility List (HCL) to determine specific
hardware support. Not all features offered by ESXi are supported when using NFM-P. For example,
Memory Compression, or Storage vMotion are not supported. Nokia should be contacted to
determine if a specific ESXi feature is supported with an NFM-P installation.
Defined CPU and Memory resources must be reserved for the individual Guest OSs and cannot be
shared or oversubscribed. This includes individual vCPUs which must be reserved for the VM.
For new installations, it is recommended to use the latest Virtual Machine Hardware version
supported by all of the ESXi hosts in the cluster, from the supported versions. For existing

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 39
NSP system requirements NSP
Hardware platform and resource requirements using virtualization

installations, VMware’s best practices should be followed regarding Virtual Machine Hardware
version changes. Virtual Machine versions 10, 14, and 19 have been tested with NFM-P where the
minimum supported Virtual Machine Hardware version is 10 and the latest supported version is 19.
See the following table for additional VM setting requirements.

Note: The system clocks of the NSP components must always be closely synchronized. The
RHEL chronyd service is strongly recommended as the time-synchronization mechanism to
engage on each NSP component during deployment.
Only one time-synchronization mechanism can be active in an NSP system. Before you
enable a service such as chronyd on an NSP component, you must ensure that no other time-
synchronization mechanism, for example, the VMWare Tools synchronization utility, is
enabled.

Table 2-8 VMware VM settings

Resource Type Parameter Setting

CPU Shares Set to High

Reservation Must be set to the number of vCPUs * the CPU frequency. For
example, on a 2.4GHz 8 vCPU configuration, the reservation must be
set to (8*2400) 19200MHz

Limit Unlimited

Memory Shares set to High

Reservation Reserve all guest memory

Limit check box checked for Unlimited

Disk Shares set to High

Limit - IOPs set to Unlimited

Lab/trial 2000

Production: Less than Thick Provision Eager Zeroed

2000 NEs

Production: More than Type VMware Paravirtual

2000 NEs

Network Adapter Type VMXNET 3

2.4.3 VMware features

The following VMware features have been tested with NFM-P. To ensure NFM-P stability and
compatibility, the following recommendations should be noted for each feature:

vMotion
• Always follow VMware best practices
• Testing was performed with dedicated 10Gb connections between all hosts

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
40 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
Hardware platform and resource requirements using virtualization

• Not supported with the NFM-P auxiliary database

High Availability
• Always follow VMware best practices
• Do not use Application Monitoring
• Use Host or VM Monitoring only
• Enable NFM-P database alignment feature to keep active servers in same Data Center

Snapshots
• Always follow VMware best practices
• Do not include memory snapshots
• Always reboot all NFM-P VMs after reverting to snapshots
• NFM-P performance can be degraded by as much as 30% when a snapshot exists and therefore
NFM-P performance and stability is not guaranteed
• Snapshots should be kept for the least amount of time possible
• Snapshot deletion can take many hours and will pause the VM several times
• NFM-P database failover will occur when VMs are reverted to snapshots, requiring a re-
instantiation of the standby database
• Supported on all components except for the NFM-P auxiliary database

Distributed Resource Scheduler (DRS)

• Always follow VMware best practices
• Manual and partially automated DRS is supported
• Fully Automated DRS is not supported
• Supported on all components except for the NFM-P auxiliary database

2.4.4 KVM virtualization

NFM-P supports using RHEL 6, RHEL 7, and RHEL 8 based KVM on x86 based servers natively
supported by KVM. The Host Environment Compatibility Reference for NSP and CLM should be
consulted for up-to-date KVM compatibility along with requirements and restrictions. See the RHEL
Hardware Compatibility List (HCL) to determine specific hardware support. Not all features offered
by KVM are supported when using NFM-P. For example, Live Migration, Snapshots, or High
Availability are not supported. Nokia should be contacted to determine if a specific KVM feature is
supported with an NFM-P installation.
Defined CPU and Memory resources must be reserved for the individual Guest OSs and cannot be
shared or oversubscribed. This includes individual vCPUs which must be reserved for the VM.
The Disk Controller type must be set to “virtio”, the storage format must be configured as “raw”,
cache mode set to “none”, and the I/O mode set to “native”. The NIC device model must be “virtio”.
The hypervisor type must be set to “kvm”.

2.4.5 OpenStack
NFM-P tests on open source OpenStack and will support the application running on any OpenStack

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 41
NSP system requirements NSP
Hardware platform and resource requirements using virtualization

distribution that is based on the tested versions. Any product issues deemed to be related to the
specific OpenStack distribution will need to be pursued by the customer with their OpenStack
vendor. Supported OpenStack versions include Newton, Queens, and Train.
To ensure NFM-P stability and compatibility with OpenStack, the following recommendations should
be noted:

Hypervisor
• KVM is the only hypervisor supported within an OpenStack environment. See the preceding
section for supported versions.

CPU and Memory resources

• Defined CPU and Memory resources must be reserved and dedicated to the individual Guest
OSs and cannot be shared or oversubscribed. The OpenStack Nova configuration for cpu_
allocation_ratio and ram_allocation_ratio must both be set to 1.0 on either the control node or
each individual compute node where a VM hosting NFM-P could reside.

Hyperthreading
• Hyper-threaded CPU usage must be consistent across all compute nodes. If there are CPUs that
do not support hyper-threading, hyper-threading must be disabled on all compute nodes, at the
hardware level, where NFM-P components could be deployed.

CPU Pinning
• CPU pinning is supported but not recommended as it restricts the use of OpenStack migration.
See the 7701 CPAA Installation Guide for vCPAA CPU Pinning requirements

Availability zones / affinity / placement:

• Nokia does not provide recommendations on configuring OpenStack for VM placement.

Migration
• Only Regular migration is supported. Live migration is not supported.

Networking
• Basic Neutron functionality using Open vSwitch with the ML2 plugin can be used in an NFM-P
deployment. OpenStack floating IP address functionality can be used on specific interfaces used
by NFM-P that support the use of NAT. This would require a Neutron router using the neutron L3
agent.

Storage
• All storage must meet the performance metrics provided with NFM-P Platform Responses.
Performance must meet the documented requirements for both throughput and latency.

VM Storage
• VM storage must be persistent block (Cinder) storage and not ephemeral. For each VM to be

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
42 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P minimum platform requirements

deployed, a bootable Cinder volume must be created. The size of the volume is indicated in the
NFM-P Platform sizing response.

Flavors
• Flavors should be created for each “Station Type” indicated in the NFM-P platform sizing
response.

Firewalls
• Firewalls can be enabled using OpenStack Security Groups or on the VMs using firewalld. If
firewalld is used, an OpenStack Security Group that allows all incoming and outgoing traffic
should be used.

2.5 NFM-P minimum platform requirements

2.5.1 Minimum hardware platform requirements
The following tables specify the minimum hardware platform requirements necessary to
successfully operate the NFM-P application in a bare metal configuration.
The minimum platform requirements also represent the smallest configurations suitable for lab
evaluations and demonstrations of the NFM-P product.

2.5.2 Bare metal hardware configurations

Table 2-9 NFM-P bare metal minimum collocated platform

For networks not exceeding:

• 675 equivalent MDAs
• 1000 GNEs
• 5 simultaneous NFM-P clients (GUI or XML-API)
• 3000 elemental STM tests every 15 minutes
• 50 000 performance or 100 000 accounting statistics records every 15 minutes
• 50 000 TCAs

NFM-P application x86 architecture

NFM-P server and database (Collocated) 6* x86 CPU Cores (12 Hyper-threads), minimum 2.0GHz 1
64 GB RAM recommended (55 GB RAM minimum)
4*10K RPM SAS disk drives of at least 300 GB in size is required for performance and
storage capacity

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 43
NSP system requirements NSP
NFM-P minimum platform requirements

Table 2-10 NFM-P bare metal minimum distributed platform

For networks not exceeding:

• 1,875 equivalent MDAs and 5 simultaneous NFM-P clients (GUI or XML-API)
OR
• 1,275 equivalent MDAs and 25 simultaneous NFM-P clients (GUI or XML-API)
• Maximum of 5000 GNEs
• 6000 elemental STM tests every 15 minutes
• 150 000 performance or 200 000 accounting statistics records every 15 minutes
• 150 000 TCAs

NFM-P application x86 architecture

NFM-P server 6* x86 CPU Cores (12 Hyper-threads), minimum 2.0GHz 1

64 GB RAM recommended (56 GB RAM minimum).
2*10K RPM SAS disk drives of at least 300 GB each in size

NFM-P database 4* x86 CPU Cores (8 Hyper-threads), minimum 2.0GHz 1

32 GB RAM minimum.
4*10K RPM SAS disk drives of at least 300 GB in size is required for performance and
storage capacity

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz.

2.5.3 Minimum hardware resource requirements

The following tables list the minimum hardware resource requirements for deployments of NFM-P
using VMware vSphere ESXi or RHEL KVM.
The minimum platform requirements also represent the smallest configurations suitable for lab
evaluations and demonstrations of the NFM-P product.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
44 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P minimum platform requirements

2.5.4 VM minimum collocated resource requirements

Table 2-11 NFM-P VM minimum collocated configuration

For networks not exceeding:

• 675 equivalent MDAs
• 1000 GNEs
• 5 simultaneous NFM-P clients (GUI or XML-API)
• 3000 elemental STM tests every 15 minutes
• 50 000 performance or 100 000 accounting statistics records every 15 minutes
• 50 000 TCAs

NFM-P application VM Guest hardware resource requirements

NFM-P server and database (collocated) 12 vCPUs, minimum 2.0GHz 1

64 GB RAM recommended (55 GB RAM minimum)
800 GB disk space
I/O requirements found in 2.7 “NFM-P storage” (p. 55)

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz.
The minimum resource requirements above are also applicable in situations where the NFM-P
application is installed in a redundant configuration.

2.5.5 VM minimum distributed resource requirements

Table 2-12 NFM-P VM minimum distributed configuration

For networks not exceeding:

• 1,875 equivalent MDAs and 5 simultaneous NFM-P clients (GUI or XML-API)
OR
• 1,275 equivalent MDAs and 25 simultaneous NFM-P clients (GUI or XML-API)
• Maximum of 5000 GNEs
• 6000 elemental STM tests every 15 minutes
• 150 000 performance or 200 000 accounting statistics records every 15 minutes
• 150 000 TCAs

NFM-P application VM Guest hardware resource requirements

NFM-P server 12 vCPUs, minimum 2.0GHz 1

56 GB RAM minimum (64 GB recommended)
500 GB disk space
I/O throughput and latency as provided in NFM-P sizing response

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 45
NSP system requirements NSP
NFM-P minimum platform requirements

Table 2-12 NFM-P VM minimum distributed configuration (continued)

For networks not exceeding:

• 1,875 equivalent MDAs and 5 simultaneous NFM-P clients (GUI or XML-API)
OR
• 1,275 equivalent MDAs and 25 simultaneous NFM-P clients (GUI or XML-API)
• Maximum of 5000 GNEs
• 6000 elemental STM tests every 15 minutes
• 150 000 performance or 200 000 accounting statistics records every 15 minutes
• 150 000 TCAs

NFM-P application VM Guest hardware resource requirements

NFM-P database 8 vCPUs, minimum 2.0GHz 1

32 GB RAM minimum
1000 GB disk space
I/O throughput and latency as provided in NFM-P sizing response

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz.
All of the minimum hardware platforms above are also applicable in situations where the NFM-P
application is installed in a redundant configuration.

2.5.6 Scaling limits for collocated configurations

Collocated configurations have been capped at the maximums described in the following table.
Higher numbers may be achievable, but Nokia will only support the stated maximums. Note that all
stated maximums may not be achievable simultaneously.

Table 2-13 Scaling limits for collocated configurations

Scaling parameter Maximum

Number of MDAs 1,875

Number of Simultaneous NFM-P clients (GUI or XML-API) 25

Number of SAPs 600 000

Number of OAM tests per 10 minute interval 1000

Performance statistics per 15 minute interval 50 000

Accounting statistics per 15 minute interval 200 000

TCAs 50 000

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
46 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P minimum platform requirements

2.5.7 Minimum platform requirements for NFM-P auxiliary collectors

Table 2-14 NFM-P auxiliary platforms - Bare Metal

Architecture Supported NFM-P auxiliary Configuration

type

Bare Metal x86 statistics collector 4 * x86 CPU Cores (8 Hyper-threads), minimum 2.0GHz 1
12 GB RAM minimum. 16 GB RAM is recommended.
4*10K RPM SAS disk drives of at least 300 GB each in size

Bare Metal x86 call trace collector 4 * x86 CPU Cores (8 Hyper-threads), minimum 2.0GHz 1
32 GB RAM minimum - CMM call trace collection
42 GB RAM minimum - CMG or CMM+CMG call trace collection
4*10K RPM SAS disk drives of at least 300 GB each in size - CMM call
trace collection
7*10K RPM SAS disk drives of at least 300 GB each in size - CMM or
CMM+CMG call trace collection

Bare Metal x86 PCMD collector 12 * x86 CPU Cores (24 Hyper-threads), minimum 2.6GHz
64 GB RAM minimum.
2*10K RPM SAS disk drives of at least 300 GB each in size (RAID 1) +
6*0K RPM SAS disk drives of at least 300 GB each in size (RAID 0)
Minimum of two 1Gb network interfaces. One dedicated to PCMD data
collection.

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz

Table 2-15 NFM-P auxiliary platforms - VM

Architecture Supported NFM-P auxiliary Configuration

type

VMware/KVM statistics collector 8 vCPUs, minimum 2.0GHz 1

12 GB RAM minimum. 16 GB RAM is recommended.
600 GB disk space
I/O throughput and latency as provided in NFM-P sizing response

VMware/KVM call trace collector 8 vCPUs, minimum 2.0GHz 1

24 GB RAM minimum - CMM call trace collection
42 GB RAM minimum - CMG or CMM+CMG call trace collection
800 GB disk space - CMM call trace collection
1900 GB disk space - CMG or CMM+CMG call trace collection
I/O throughput and latency as provided in NFM-P sizing response

VMware/KVM PCMD collector 24 vCPUs, minimum 2.6GHz

64 GB RAM minimum.
2000 GB disk space
Dedicated network interface for PCMD data collection.
I/O throughput and latency as provided in NFM-P sizing response

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 47
NSP system requirements NSP
NFM-P minimum platform requirements

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz

2.5.8 Platform requirements for NSP Flow Collector and NSP Flow Collector
Controller

Table 2-16 NSP Flow Collector and NSP Flow Collector Controller platforms for labs

Architecture Type Configuration

Bare Metal x86 NSP Flow Collector 4 * x86 CPU Cores (8 Hyper-threads), minimum 2.0GHz 1
16 GB RAM minimum.
1*10K RPM SAS disk drives of at least 300 GB each in size

Bare Metal x86 NSP Flow Collector Controller 2 * x86 CPU Cores (4 Hyper-threads), minimum 2.0GHz 1
4 GB RAM minimum.
1*10K RPM SAS disk drives of at least 300 GB each in size

Bare Metal x86 NSP Flow Collector and NSP Flow 4 * x86 CPU Cores (8 Hyper-threads), minimum 2.0GHz 1
Collector Controller (collocated) 16 GB RAM minimum.
1*10K RPM SAS disk drives of at least 300 GB each in siz

VMware/KVM NSP Flow Collector 8 vCPUs, minimum 2.0GHz 1

16 GB RAM minimum.
300 GB disk space
I/O throughput and latency as provided in NFM-P sizing
response

VMware/KVM NSP Flow Collector Controller 4 vCPUs, minimum 2.0GHz 1

4 GB RAM minimum.
300 GB disk space
I/O throughput and latency as provided in NFM-P sizing
response

VMware/KVM NSP Flow Collector and NSP Flow 8 vCPUs, minimum 2.0GHz 1
Collector Controller (collocated) 16 GB RAM minimum.
300 GB disk space
I/O throughput and latency as provided in NFM-P sizing
response

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz

Table 2-17 NSP Flow Collector and NSP Flow Collector Controller platforms for production deployments

Architecture Type Configuration

Bare Metal x86 NSP Flow Collector 12 * x86 CPU Cores (24 Hyper-threads), minimum 2.0GHz 1
64 GB RAM minimum.
2*10K RPM SAS disk drives of at least 300 GB each in size

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
48 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P minimum platform requirements

Table 2-17 NSP Flow Collector and NSP Flow Collector Controller platforms for production deployments
(continued)
Architecture Type Configuration

Bare Metal x86 NSP Flow Collector Controller 2 * x86 CPU Cores (4 Hyper-threads), minimum 2.0GHz 1
4 GB RAM minimum.
1*10K RPM SAS disk drives of at least 300 GB each in size

Bare Metal x86 NSP Flow Collector and NSP Flow 12 * x86 CPU Cores (24 Hyper-threads), minimum 2.0GHz 1
Collector Controller (collocated) 64 GB RAM minimum.
2*10K RPM SAS disk drives of at least 300 GB each in size

VMware/KVM NSP Flow Collector 24 vCPUs, minimum 2.0GHz 1

64 GB RAM minimum.
500 GB disk space
I/O throughput and latency as provided in NFM-P sizing
response

VMware/KVM NSP Flow Collector Controller 4 vCPUs, minimum 2.0GHz 1

8 GB RAM minimum.
300 GB disk space
I/O throughput and latency as provided in NFM-P sizing
response

VMware/KVM NSP Flow Collector and NSP Flow 24 vCPUs, minimum 2.0GHz 1
Collector Controller (collocated) 64 GB RAM minimum.
500 GB disk space
I/O throughput and latency as provided in NFM-P sizing
response

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz

2.5.9 Minimum platform requirements for NFM-P auxiliary database

Table 2-18 NFM-P auxiliary database platform - single node cluster

Architecture Configuration

Bare Metal x86 4 * x86 CPU Cores (8 Hyper-threads), minimum 2.4GHz

64 GB RAM minimum.
2 SAS 10K RPM disk drives of at least 300 GB each in size (RAID 1) + 4 SAS 10K
RPM disk drives of at least 1.2TB each in size (RAID 1+0) + 4 SAS 10K RPM
disks of at least 1.2TB each in size (RAID 5)

VMware/KVM 8 vCPUs, minimum 2.4GHz

64 GB RAM minimum.
500+ GB disk space
I/O throughput as measured with the vioperf utility

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 49
NSP system requirements NSP
NFM-P minimum platform requirements

Table 2-19 NFM-P auxiliary database platform - three+ node cluster

Architecture Configuration (for each node of the auxiliary database cluster 1)

Bare Metal x86 12 * x86 CPU Cores (24 Hyper-threads), minimum 2.6GHz
128 GB RAM minimum.
2 SAS 10K RPM disk drives of at least 300 GB each in size (RAID 1) + 12 SAS
10K RPM disk drives of at least 600 GB each in size (RAID 1+0) + 5 SAS 10K
RPM disks of at least 1.2TB each in size (RAID 5)
Minimum of two 1Gb network interfaces. One dedicated to inter-cluster
communication.

VMware/KVM 24 vCPUs, minimum 2.6GHz

128 GB RAM minimum.
Dedicated network interface for inter-cluster communication only.
500+ GB disk space
I/O throughput as measured with the vioperf utility simultaneously on all nodes in
the cluster

Notes:
1. Minimum of three nodes required in the cluster.

2.5.10 Minimum platform requirements for NSP analytics server

Table 2-20 NSP analytics server platform

Architecture Configuration

Bare Metal x86 4 * x86 CPU Cores (8 Hyper-threads), minimum 2.0GHz 1

8 GB RAM minimum (24 GB recommended)
1 SAS 10K RPM disk drive of at least 300 GB in size

VMware/KVM 8 vCPUs, minimum 2.0GHz 1

8 GB RAM minimum (24 GB recommended)
300 GB disk space
I/O throughput and latency as provided in the NFM-P sizing response

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz
Ad-hoc report design is a computationally intensive process. If it is expected that the ad-hoc feature
will be used on a regular basis, customers are strongly encouraged to meet the recommended
specifications.

2.5.11 Platform requirements for NFM-P client delegate server stations

NFM-P allows multiple clients to be installed on a single HP x86 or Nokia AirFrame station running
RHEL 7 server x86-64, or specific versions of Windows. This option enables customers to launch
multiple NFM-P clients from a single station. These GUI clients can be displayed using a Citrix
client/Server, or additionally in the case of RHEL, the X11 protocol to other desktops, or native X
displays.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
50 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P minimum platform requirements

The client delegate server platform provides an option to consolidate multiple installations of the
NFM-P client on a single station or the option of installing one instance of the NFM-P client run by
many users (with unique Operating System accounts). Regardless of the method of the client
installation, the platform requirements per client are the same.
The amount of memory listed includes the requirement for the NFM-P java UI and web browser.
Additional memory for each NFM-P client will be required for management of the network elements
described in 4.12 “Network element specific requirements” (p. 80) .
Management of certain network elements may include the cross-launch of additional software that
may not be compatible with certain operating systems. The information in Table 2-23, “Element
manager operating system support summary” (p. 53) lists these element managers and their
operating system support. See the element-manager documentation to determine current operating
system support.
The NFM-P client delegate server configuration is only supported on specific HP or Nokia AirFrame
x86 stations running RHEL server x86-64, or specific versions of Windows. Additionally, the NFM-P
client delegate server installation is supported on a Guest Operating System of a VMware vSphere
ESXi or RHEL KVM installation. The Guest OS must be one of those supported for GUI clients
found in 3.1.3 “NFM-P RHEL support” (p. 60). Table 2-21, “Minimum NFM-P client delegate server
resource requirements” (p. 50) describes resource requirements for this type of station.

Table 2-21 Minimum NFM-P client delegate server resource requirements

Architecture Configuration

Bare Metal x86 4* x86 CPU Cores (8 Hyper-threads), minimum 2.0GHz

28 GB RAM minimum, 36 GB for networks with greater than 15 000 NEs, 76 GB for
networks managing AirScale eNodeBs
1*10K RPM SAS disk drive, 146 GB in size

VMware/KVM 8 vCPUs, minimum 2.0GHz

28 GB RAM minimum, 36 GB for networks with greater than 15 000 NEs, 76 GB for
networks managing AirScale eNodeBs
70 GB disk space

The configurations in the preceding table will support up to 15 GUI clients. Additional GUI clients
can be hosted on the same platform provided that the appropriate additional resources found in
Table 2-22, “Additional client NFM-P client delegate server resource requirements” (p. 51) are
added to the platform.

Table 2-22 Additional client NFM-P client delegate server resource requirements

Architecture Additional resources per client

Bare Metal x86 1/4 * x86 CPU Core (1/2 Hyper-thread), minimum 2.0GHz
1.75 GB RAM, 2.25 GB for networks with greater than 15 000 NEs, 5 GB for networks
managing AirScale eNodeBs
1 GB Disk Space

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 51
NSP system requirements NSP
NFM-P minimum platform requirements

Table 2-22 Additional client NFM-P client delegate server resource requirements (continued)

Architecture Additional resources per client

VMware/KVM 1/2 vCPU, minimum 2.0GHz

1.75 GB RAM, 2.25 GB for networks with greater than 15.000 NEs, 5 GB for networks
managing AirScale eNodeBs
1 GB Disk Space

For situations where more than 60 simultaneous GUI sessions are required, Nokia recommends
deploying multiple NFM-P client delegate servers.
Displaying GUI clients to computers running X-emulation software is not currently supported. In
cases where the GUI client is to be displayed to a PC computer running Windows, Nokia supports
installing the GUI client directly on the PC.
NFM-P supports using Citrix for remote display of NFM-P clients. Supporting Citrix on the delegate
platform requires extra system resources that will need to be added to those that are required by
the NFM-P delegate. See the Citrix documentation to determine the additional Citrix resource
requirements.

The following Citrix software has been tested with the Windows client delegate server:
• Windows Server 2012 R2 — Citrix Server - XenApp Version 7.18
• Windows Server 2016 — Citrix Server - XenApp Version 7.18
• Windows Server 2019 — Citrix Server - XenApp Version 7.18
• Windows Server 2019 — Citrix Client - Receiver Version 4.1.2.0.18020
• Windows 10 — Citrix Client - Receiver Version 4.1.2.0.18020
Due to an incompatibility between 64-bit versions of the Firefox web browser and Citrix Server
XenApp, the default web browser must be set to either Google Chrome, if using a version of
XenApp older than 7.14.
The client delegate server can be published in XenApp by installing the delegate server on your
delivery controller and then publishing the <delegate install directory>\nms\bin\nmsclient.bat file as
a manually published application.

2.5.12 NFM-P client platform requirements

Nokia recommends having a minimum of 1.75 GB of dedicated RAM – regardless of the operating
system, for the NFM-P client which includes the java UI and web browser memory requirements. In
cases where other applications are running on the same platform as the NFM-P client, it is
important to ensure 1.75 GB RAM is available to meet the NFM-P client requirements.
Additional memory for each NFM-P client will be required for management of the network elements
described in 4.12 “Network element specific requirements” (p. 80) .
Management of certain network elements may include the cross-launch of additional software that
may not be compatible with certain operating systems. The information in the following table lists
these element managers and their operating system support. See the element-manager
documentation to determine current operating system support.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
52 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P minimum platform requirements

All platforms used to display NFM-P applications must have a WebGL compatible video card and
the corresponding drivers installed.

Table 2-23 Element manager operating system support summary

Element manager Node type RHEL 7 server support Microsoft Windows support

NEtO 9500 MPR / Wavence Not-supported Supported

SM

The following table provides the minimum requirement for the hardware that will host NFM-P GUI
client software. Additional memory and disk resources will be required by the Operating System.

Table 2-24 NFM-P client hardware platform requirements

NFM-P client hardware platform requirements

RHEL platforms Microsoft Windows

1 CPU (2 Hyper-threads)@ 2.0 GHz or higher 1 CPU (2 Hyper-threads)@ 2 GHz or higher

1.75 GB RAM dedicated to NFM-P client, 2 GB for networks with 1.75 GB RAM dedicated to NFM-P client, 2 GB for networks with
greater than 15 000 NEs, 5 GB for networks managing AirScale greater than 15 000 NEs, 5 GB for networks managing AirScale
eNodeBs eNodeBs
1 GB available disk space 1 GB available disk space
1280*1024 Display resolution for Java GUI (recommended) 1280*1024 Display resolution for Java GUI (recommended)
1280*720@72ppi Display resolution for NFM-P applications 1280*720@72ppi Display resolution for NFM-P applications
(minimum) (minimum)
1920*1080@72ppi Display resolution for NFM-P applications 1920*1080@72ppi Display resolution for NFM-P applications
(recommended) (recommended)
Example platform: DL380 Gen10

An NFM-P client installation is supported on a Guest Operating System of a VMware vSphere ESXi
or RHEL KVM installation. The Guest OS must be one of those supported for GUI clients found in
3.1.3 “NFM-P RHEL support” (p. 60).
The following table provides the dedicated NFM-P resource requirements for each Guest OS
running under VMware vSphere ESXi or RHEL KVM that will be used to host the NFM-P client GUI.
This does not include the specific operating system resource requirements which are in addition to
the hardware resources listed below. CPU and Memory resources must be reserved and dedicated
to the individual Guest OSs and cannot be shared or oversubscribed. Disk and network resources
should be managed appropriately to ensure that other Guest OSs on the same physical server do
not negatively impact the operation of the NFM-P GUI client.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 53
NSP system requirements NSP
NFM-P platform requirements for larger networks

Table 2-25 Virtualized NFM-P client resource requirements

VM resource requirements

RHEL Guest OS resources Microsoft Windows Guest OS resources

2 vCPUs @ 2GHz or higher 2 vCPUs @ 2 GHz or higher

1.75 GB dedicated RAM, 2 GB for networks with greater than 1.75 GB dedicated RAM, 2 GB for networks with greater than 15 000
15 000 NEs NEs
1 GB available disk space 1 GB available disk space
1280*1024 Display resolution for Java GUI (recommended) 1280*1024 Display resolution for Java GUI (recommended)
1280*720@72ppi Display resolution for NFM-P applications 1280*720@72ppi Display resolution for NFM-P applications
(minimum) (minimum)
1920*1080@72ppi Display resolution for NFM-P applications 1920*1080@72ppi Display resolution for NFM-P applications
(recommended) (recommended)

2.6 NFM-P platform requirements for larger networks

2.6.1 Determining platform requirements for larger networks

NFM-P may require larger stations in order to successfully manage networks that exceed any of the
dimensions supported by the minimum hardware platforms. In order to determine station
requirements to successfully manage larger networks, the following information is required:
• Expected number and types of network elements to be managed
• Expected number of MDAs in the network to be managed
• Expected number of services and SAPs in the network to be managed
• Expected number of Dynamic LSPs to be deployed in the network
• Maximum expected number of NFM-P clients (GUI) simultaneously monitoring the network
• Expected number of XML-API applications that will connect as clients to the XML API interface
• Expected number of subscribers, specifically for triple-play network deployments
• Expected statistics collection and retention
• Expected number of STM tests
• Expected number of managed GNEs
• Whether NFM-P redundancy is to be utilized
• Whether NEBS compliance is required
• Whether CPAM is required
• Whether RAID 1 is required
The information above must then be sent to an Nokia representative who can provide the required
hardware specifications.
Ensure that any projected growth in the network is taken into account when specifying the expected
network dimensioning attributes. For existing NFM-P systems, the user may determine the number
of MDAs deployed in the network using the help button on the GUI. It is also possible to determine
the number of statistics being handled by the system by looking at the “Statistics Collection”
information window. Select the “Tools”, then “Statistics”, then “Server Performance Statistics” menu.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
54 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P storage

List the “Statistics Collection” objects. From this list window, check the “Scheduled Polling Stats
Processed Periodic” and the “Accounting Stats Processed Periodic” columns for the performance
and accounting statistics that your system is currently processing within the time interval defined by
the collection policy (15 minutes by default).

2.7 NFM-P storage

2.7.1 Storage overview
This section provides information about configuring stations that will host NFM-P software.
Specific partition sizes and configuration procedures are available in the NSP Installation and
Upgrade Guide.
When using the RHEL server OS, ext4 is the required file system for all application specific mount
points. No other file systems are supported with NFM-P. OS specific mount points can be either xfs
or ext4 as the file system. Windows based clients must use a local file system for client files.
Network based files systems, including Samba are not supported.
While Nokia identifies areas of the disk that are not specifically required for NFM-P and are
partitionable for customer use, station resources are expected to be dedicated for NFM-P. As such,
these “Remainder” portions of the disks should only be used for static storage purposes.
Consideration should also be made to the expected growth of the network. If the “Remainder” is not
to be used, then it should not be created.
For all network sizes, Nokia requires the use of at least four disks on stations running the NFM-P
database. This disk configuration allows for better performance by distributing the database across
multiple disks. Customized disk configurations may be required for larger network deployments or
where large scale statistics collection is required. Request a formal platform sizing for further
details. NAS disk configurations are not supported.
Disk configurations for stations running the NFM-P database with less than four physical disks
greatly limits the NFM-P system performance, managed-network size, and data storage capacity,
and is therefore only supported for lab trials.
See 5.7 “Scaling guidelines for statistics collection” (p. 96) for statistics collection
recommendations.
In NFM-P upgrade scenarios, previous disk configurations may still be valid.

2.7.2 Using RAID technologies

In bare metal deployments, Nokia requires the use of RAID 0 (striping), unless otherwise specified,
provided by a hardware based RAID controller. Software based RAID 0 is not supported. Nokia will
provide disk layout and configuration details for customers requiring a Storage Array or layouts not
specified in the NSP Installation and Upgrade Guide. The increased disk I/O performance offered
by RAID 0 is required for all NFM-P deployments. The NSP Installation and Upgrade Guide
provides details of these configurations. A RAID 0 stripe size of 512 Kbytes is required for optimal
NFM-P disk performance. If a platform does not support a stripe size of 512 Kbytes, choose the
next largest stripe size, for example, 256 Kbytes. Specifying a smaller or larger stripe size may
result in degraded performance that compromises NFM-P network management.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 55
NSP system requirements NSP
NFM-P storage

Nokia supports the use of RAID 1 (Mirroring). Deployments requiring increased resiliency are
encouraged to use NFM-P platform redundancy. If RAID 1 is required, a platform providing
hardware RAID 1 and that has sufficient number of disk to meet the increased disk requirements
must be selected.
To reduce the chance of data loss or application down time, Nokia recommends using RAID 1, in a
RAID 1+0 configuration.
For specific applications, Nokia supports the use of RAID 5 to increase storage resiliency and
maximize available space. The NFM-P auxiliary database backup partition is supported with RAID
5.

Note: Nokia is not responsible for installation, administration or recovery of RAID on an

NFM-P platform.

2.7.3 Using SAN storage

Nokia supports the use of SAN storage. SAN connectivity must consist of 4Gb or faster optical
connections or 10Gb iSCSI connections. It is recommended that these connections are dedicated
connections between the hosts and storage arrays. The SAN must be available to NFM-P without
interruption in a low latency environment.
NFM-P platform sizing responses will provide the required performance targets when using NFM-P
with a SAN. Note that certain mount points may not be required due to deployment options. See the
NSP Installation and Upgrade Guide for required mount points based upon the type of NFM-P
stations deployed.

Note: Nokia is not responsible for installation, administration or recovery of SANs on an

NFM-P platform.

2.7.4 Virtualization I/O requirements

When using NFM-P on a guest operating system of a hosted virtualized installation, specific storage
requirements must be met. For optimal performance, storage should be either internal disks (10K or
15K RPM SAS), Fiber Channel attached storage (array or SAN) with dedicated fiber channel
connections between hosts and Storage Arrays, or 10Gb iSCSI using non-shared infrastructure. All
storage must meet the performance metrics provided with NFM-P platform sizing responses.
Storage I/O shares must be set to “High” and IOPs set to “Unlimited” for best performance and low
latency.
See Table 2-26, “Minimum collocated configuration throughput and latency” (p. 57) for the
minimum required throughput and latency for a collocated NFM-P configuration. Higher scale
networks and distributed configurations may require alternate throughput and latency targets that
will be provided with the NFM-P platform sizing response that is required for every NFM-P
deployment.
NFM-P includes a benchmarking utility to be used for determining the throughput and latency of the
storage device to be used with the virtual server hosting NFM-P. The utility is installed with an
NFM-P server in the /opt/nsp/nfmp/server/nms/bin/unsupported/IOTest directory and is called NSP_
IOTest.pl. If NFM-P has not yet been installed, the utility can be obtained from Nokia or from the
NFM-P software package.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
56 3HE-18161-AAAB-TQZZA Issue 1
NSP system requirements NSP
NFM-P storage

Executing the utility with the -h flag will present the user with a help menu, explaining different
options and presenting execution examples. Each mount point must be tested and must meet the
throughput and latency requirements for the specific deployment. These throughput and latency
requirements must be obtained from Nokia as they are specific to each deployment. The throughput
and latency targets must be met, irrespective of any other activity on the underlying storage device
and the targets must be achievable concurrently. For this reason, it is important to understand the
underlying storage configuration to ensure that the output of the benchmarking utility is interpreted
correctly. For example, each of the listed targets may be achievable using a single 10K RPM SAS
disk but concurrently, the listed targets would not be achievable using the same single 10K RPM
SAS disk. The performance of NFM-P would be degraded using this configuration.

Table 2-26 Minimum collocated configuration throughput and latency

Mount point Read (MB/s) Write (MB/s) Latency (ms)

/opt/nsp 37 15 < 1.0

/opt/nsp/os 15 15 < 1.0

/opt/nsp/nfmp/server/xml_output 37 15 < 1.0

/opt/nsp/nfmp/dbbackup 14 21 < 1.0

/opt/nsp/nfmp/db/tablespace 158 8 < 1.0

/opt/nsp/nfmp/server/nms/log 1 1 < 1.0

/opt/nsp/nfmp/db/archivelog 14 38 < 1.0

/opt/nsp/nfmp/nebackup 6 6 < 1.0

See the NSP Installation and Upgrade Guide for the recommended partition sizes.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 57
NSP system requirements NSP
NFM-P storage

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
58 3HE-18161-AAAB-TQZZA Issue 1
Operating system specifications NSP
Red Hat Enterprise Linux (RHEL)

3 Operating system specifications

3.1 Red Hat Enterprise Linux (RHEL)

3.1.1 NSP deployment on RHEL
The following topics define the OS requirements for deploying an NSP cluster and optional NSP
components.

3.1.2 RHEL version support

NSP Release 22.6 supports the following RHEL Server x86-64 versions in a NSP cluster
deployment.
• RHEL server 7 x86-64 - Update 7 (7.7)
• RHEL server 7 x86-64 - Update 8 (7.8)
• RHEL server 7 x86-64 - Update 9 (7.9)

Note: Each NSP cluster VM requires RHEL kernel version kernel-3.10.0-1075.el7 or later, and
must have the following kernel setting:
--args=cgroup.memory=nokmem
Previous releases, or other variants of Red Hat, and other Linux variants are not supported.
See the Host Environment Compatibility Reference for NSP and CLM for information about NSP
and RHEL OS compatibility.
The Nokia provided NSP RHEL OS image are based upon RHEL 7.9 and is only available for KVM
and Openstack hypervisors. The NSP RHEL OS image can be used only for the deployment of
NSP software, and not for the deployment of any other Nokia or third-party product.
The RHEL operating system must be installed as English.
The NSP does not necessarily support all functionality provided in RHEL. Network Manager is not
supported in NSP deployments. SELinux is supported in passive mode only. The RHEL chronyd
service is strongly recommended as the time-synchronization mechanism. The NSP also requires
that the server hostname is configured in the /etc/hosts file. RHEL must be installed in 64 bit mode
where NSP will be installed.
Nokia recommends installing any OS, driver, or firmware updates that the hardware vendor advises
for RHEL.
With the exception of documented Operating System parameter changes for NSP, all other settings
must be left at the RHEL default configuration.
The NSP Installation and Upgrade Guide provides detailed instructions for the RHEL OS
installation.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 59
Operating system specifications NSP
Red Hat Enterprise Linux (RHEL)

3.1.3 NFM-P RHEL support

NFM-P is supported on Red Hat Enterprise Linux (RHEL) 7, Server Edition x86-64. Previous
releases or other variants of Red Hat and other Linux variants are not supported.

NFM-P Release 22.6 supports the following base RHEL versions:

• RHEL server 7 x86-64 - Update 3 (7.3)
• RHEL server 7 x86-64 - Update 4 (7.4)
• RHEL server 7 x86-64 - Update 5 (7.5)
• RHEL server 7 x86-64 - Update 6 (7.6)
• RHEL server 7 x86-64 - Update 7 (7.7)
• RHEL server 7 x86-64 - Update 8 (7.8)
• RHEL server 7 x86-64 - Update 9 (7.9)
See the Host Environment Compatibility Reference for NSP and CLM for compatibility between
NFM-P releases and RHEL OS versions.
The Nokia provided NSP RHEL OS image is based upon RHEL 7.9 and is available for KVM and
OpenStack based deployments only.
The Red Hat Linux support of NFM-P is applicable to specific x86 Intel platforms provided by HP
and Nokia only, for bare metal installations, where some systems may require specific updates of
the RHEL operating system. See Red Hat’s Hardware Certification list on their website. NFM-P
does not necessarily support all functionality provided in RHEL 7.
NFM-P supports the use of the RHEL Logical Volume Manager (LVM) on all server types and is
limited to the resizing of logical volumes only. To ensure that disk throughput and latency of the
resized volume remains consistent, the procedure for testing NFM-P disk performance in the
NFM-P Administrator Guide must be followed.
The RHEL operating system must be installed in 64-bit mode where NFM-P software will be
installed.
The NFM-P server, NFM-P auxiliary collector, NSP Flow Collector, NSP Flow Collector Controller,
NFM-P auxiliary database, NSP analytics server, NFM-P client delegate server, and NFM-P
database RHEL operating system must be installed in English.
Nokia recommends installing any OS, driver, or firmware updates that the hardware vendor advises
for RHEL.
With the exception of NFM-P documented Operating System parameter changes, all other settings
must be left at the RHEL default configuration.

3.1.4 Red Hat support

For customers using the NSP_RHEL_OS image for NSP guest virtual machines, support for the
RHEL instance is available directly from Nokia, not Red Hat. For all other RHEL installations, Red
Hat support must be purchased for all platforms running RHEL server with NSP. It is strongly
recommended to purchase a support package from Red Hat that provides 24x7 support.
The NSP_RHEL OS image can only be used as a guest VM hosting an NSP component, and not
for the deployment of any other Nokia or third-party product.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
60 3HE-18161-AAAB-TQZZA Issue 1
Operating system specifications NSP
NFM-P on Microsoft Windows

3.1.5 Third-party applications

Applications that are not sanctioned by Nokia must not be running on any virtual instance running
NSP components. Nokia reserves the right to remove any applications that are suspected of
causing issues from stations running NSP components.

3.2 NFM-P on Microsoft Windows

3.2.1 NFM-P support
The Windows operating system is only supported for NFM-P clients and NFM-P client delegate
servers. The table below summarizes Microsoft Windows support.

Table 3-1 Windows operating system support summary

Microsoft Windows version NFM-P client NFM-P client delegate server

Windows 8 / 8.1 Enterprise Supported (64-bit) Not-supported

Windows 10 Professional Supported Not-supported

Windows Server 2012 R2 Supported Supported

Windows Server 2016 Supported Supported

Windows Server 2019 Supported Supported

When installing the NFM-P client on Windows, ensure that there is sufficient disk space as
identified in the NSP Deployment and Installation Guide for the software.

3.2.2 Microsoft support

Support for all installations of the Microsoft Windows operating system must be obtained from
Microsoft.

3.3 NFM-P on Apple macOS

3.3.1 NFM-P support
The Mac OS operating system is only supported for NFM-P clients. macOS 11 (Big Sur) has been
tested with NFM-P 22.6.

3.3.2 Apple support

Support for all installations of the Apple MacOS operating system must be obtained from Apple.

3.4 NFM-P operating system summary

3.4.1 Operating system summary
The following table summarizes the supported configurations for each of the Operating Systems
supported by NFM-P.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 61
Operating system specifications NSP
Third party software for NFM-P single-user client or client delegate server

Table 3-2 NFM-P operating system support summary

NFM-P application RHEL 7 server x86-64 Microsoft Windows Mac OS

NFM-P server 7.3 through 7.9 Not supported Not supported

NFM-P database 7.3 through 7.9 Not-supported Not supported

Collocated NFM-P 7.3 through 7.9 Not supported Not supported

server/database

NFM-P client 7.3 through 7.9 Supported Supported

NFM-P auxiliary 7.3 through 7.9 Not supported Not supported

NFM-P auxiliary database 7.3 through 7.9 Not supported Not supported

NSP analytics server 7.3 through 7.9 Not supported Not supported

NSP Flow Collector 7.3 through 7.9 Not supported Not supported

NSP Flow Collector 7.3 through 7.9 Not supported Not supported
Controller

NFM-P client delegate 7.3 through 7.9 Supported Not supported

server

3.5 Third party software for NFM-P single-user client or client

delegate server
3.5.1 NFM-P client or client delegate server software requirements
NFM-P clients are launched, installed and uninstalled through a web browser using either java
webstart or direct installer download. To use the java webstart functionality, each client platform
must have a system JRE (Java Runtime Environment) installed along with a supported web
browser. The NFM-P java webstart installer/launcher requires Oracle Java version 8, update 192 or
later, Oracle Java version 9, or Oracle Java version 10 (18.3) for the system JRE on all Windows,
RHEL, and Mac OS platforms. Since Oracle Java version 9 and Oracle Java version 10 are end-of-
life, it is strongly recommended to continue using Oracle Java 8 for the system JRE, to ensure
access to current security and functional updates. The system JRE needs to be already installed on
the client platform. The java webstart installation method will be removed in a future release. The
direct installer download does not require the client platform to have a system JRE installed.
The NEtO element manager that is cross launched from the NFM-P client UI requires binding to a
specific system port on an NFM-P client and therefore a client delegate server can only support a
single NEtO instance running amongst all clients connected to a client delegate server at any time.
To consolidate NFM-P client UIs to a single server when using the NEtO element manager, a
virtualized solution should be used instead, with each NFM-P client residing in a separate VM.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
62 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
NSP network requirements

4 Network requirements

4.1 NSP network requirements

4.1.1 Introduction
This chapter describes network bandwidth and latency requirements for an NSP deployment.

4.2 NSP component network addressing requirements

4.2.1 Using IPv4 and IPv6 in NSP deployments
The NSP supports IPv4 and IPv6 network connectivity with client applications and other
components in the NSP architecture.

Deploying NSP with IPv6 network communications has the following limitations and restrictions:
• The deployer host for an NSP cluster must have IPv4 connectivity to NSP cluster nodes. The
NSP cluster can be configured for IPv6 communications for NSP applications, but must have
IPv4 connectivity to the deployer node.
• Common web browser applications have security policies that may prevent the use of bracketed
IPv6 addresses in the URL browser bar. Customers that use IPv6 networking for client
communications to NSP must use hostname configuration for NSP components.
• All NSP components in an NSP deployment must use IPv4 or IPv6 for inter-component
communications. Different integrated components in an NSP deployment cannot communicate
between IPv4 and IPv6 interchangeably (example: if NSP is deployed with IPv6, then NFMP also
needs to be deployed with IPv6.).
• NFM-T does not support IPv6 deployment. An integrated deployment of NSP with NFM-T must
be deployed with IPv4 addressing.

Note: In Release 22.6, the VSR-NRC must be deployed with IPv4 addressing. A NSP
deployed with IPv6 can be deployed with a VSR-NRC using IPv4 addressing.
The NSP can be deployed with multiple network interfaces using IPv4 and IPv6 addressing.
Chapter 7 of this guide documents the requirements and limitations of a multiple network interface
NSP deployment.

4.3 Network requirements between NSP and other components

4.3.1 NSP and OSS clients
The bandwidth requirements between NSP and OSS clients depend on the number of concurrent
connections and on the type of transactions that are performed. For a single provisioning thread,
Nokia recommends providing 50 kbps of bandwidth from the OSS client to the NSP server (IP

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 63
Network requirements NSP
Network requirements for redundancy, high-availability and NSP cluster
nodes

resource control, cross-domain resource control, NSP cluster). An OSS client that performs
frequent query operations (for example, port or service inventory) must be provided additional
bandwidth.

4.3.2 NSP and GUI clients

The bandwidth requirements between NSP and GUI clients mostly depends on the size of the
network. A larger network with more nodes and services requires more data to download to GUI
clients. Optimal GUI performance is achieved with 10 Mbps of bandwidth with minimal network
latency. Nokia recommends providing a minimum of 2.5 Mbps of bandwidth.
High network latency between the NSP and GUI clients slows GUI performance. Nokia
recommends limiting the round-trip network latency time to 100 ms.

4.3.3 NSP and NFMP

The bandwidth requirements between NSP and NFM-P depends on the following factors:
• the number of NEs, LSPs, and services configured on the NFM-P
• the frequency of NE updates to the NSP
When an NSP system resynchronizes with NFM-P, optimal performance is achieved with 50 Mbps
of bandwidth between NSP and NFM-P. Nokia recommends providing a minimum of 25 Mbps of
bandwidth.
Network latency impacts the time it takes for the NSP to resynchronize a large amount of data from
the NFM-P. Nokia recommends limiting the round-trip network latency time to 100 ms.

4.4 Network requirements for redundancy, high-availability and NSP

cluster nodes
4.4.1 Redundant deployments
The network requirements between active/standby IP resource control servers, cross-domain
resource control servers, and NSP clusters depends on the network size (number of NEs and
configured services) and the rate of service provisioning activities. The peak bandwidth requirement
between redundant servers is 50 Mbps, with sustained bandwidth of 25 Mbps. Round-trip network
latency between the redundant pair must be limited to 100 ms.

4.4.2 IP resource control high-availability deployment

IP resource control can be deployed in a high availability cluster on virtual machines from the same
or different hosts and share a virtual IP address. Cluster members require connectivity with a
minimum of 50 Mbps bandwidth and less than 1 ms round trip latency. The bandwidth and network
latency requirements between active and standby high-availability clusters are the same as those in
a redundant deployment.

4.4.3 NSP cluster nodes

In a multi-node deployment of an NSP cluster, it is recommended that the nodes within the cluster
have 1Gbps ethernet connectivity with less than 1 ms round trip latency.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
64 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
NFM-P network requirements

4.5 NFM-P network requirements

4.5.1 Overview
The network interconnecting the NFM-P systems, network elements, and XML-API systems is of
significant importance to the effective management of the network. The following sections describe
the requirements for the network links between NFM-P stations and the connection to the network
being managed. Nokia recommends making sufficient bandwidth available to the NFM-P stations
within the Data Communication Network.
For SNMP management of Nokia network elements, all network segments that carry NFM-P
management traffic must allow the successful transmission of 9216 byte SNMP packets. The NSP
Troubleshooting Guide contains more information about packet fragmentation issues.
Be sure to consider the bandwidth required for statistics collection in the total bandwidth required
between the NFM-P components, as they are in separate tables.
The tables do not specify the underlying infrastructure required to support these bandwidth
requirements.
See 7.3 “NFM-P multihoming” (p. 168) for information about configuring the NFM-P components
with multiple interfaces.

4.6 Network elements

4.6.1 Network element connectivity support
NFM-P supports both IPv4 and IPv6 connectivity to network elements. The following network
elements may be managed by NFM-P using IPv6:
• 9500 MPR / Wavence SM
• 7950 XRS
• 7750 SR
• 7705 SAR
• 7705 SAR-Hm
• 7450 ESS
• 7250 IXR
• 7210 SAS
• OmniSwitch 6350, 6465, 6560, 6865
• vCPAA
• eNodeB: AirScale and FlexiZone
• 5G Classic
• 5G Cloud CU and 5G DU
• CMM

Note: Call trace data can only be retrieved from CMM and CMG network elements with IPv4
connectivity.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 65
Network requirements NSP
NFM-P bandwidth requirements

NFM-P supports the use of multiple interfaces for network element management communication. If
a network element uses both an in-band and out-of-band address for management, these
interfaces must reside on the same server interface.

4.7 NFM-P bandwidth requirements

4.7.1 Bandwidth requirements for collocated NFM-P installations
The following table lists the bandwidth requirements for the connections between the components
of an NFM-P collocated installation. It is a good practice to measure the bandwidth utilization
between the various components to determine a suitable bandwidth. There are a number of factors
that could require an increase above our bandwidth utilization recommendations, including: GUI
activity, XML-API activity, network events, number of network elements being managed.

Table 4-1 NFM-P collocated server/database bandwidth requirements

Available bandwidth required from primary NFM-P Recommended bandwidth: excluding statistics bandwidth
server/database station requirements

NFM-P client (GUI) 1 Mbps

XML API client (The bandwidth will depend on the XML-API 1 Mbps
application)

Between primary and standby NFM-P server/database station 5-10 Mbps (sustained)
NOTE: When network element database backup synchronization 16-26 Mbps (during re-instantiation or database backup
is enabled, the bandwidth requirement between the NFM-P synchronization)
servers will vary significantly depending on the size of the network
element backup file sizes.

4.7.2 Bandwidth requirements for distributed NFM-P installations

The following tables list the requirements for the connections between the components of an
NFM-P distributed installation. It is a good practice to measure the bandwidth utilization between
the various components to determine a suitable bandwidth. There are a number of factors that
could require an increase above our bandwidth utilization recommendations – including: GUI
activity, XML-API activity, network events, number of network elements being managed.

Table 4-2 NFM-P distributed server/database bandwidth requirements

Available bandwidth requirements for NFM-P Recommended bandwidth: excluding statistics and call trace
bandwidth requirements

NFM-P server to an NFM-P database 5 to 10 Mbps (3 Mbps minimum)

NOTE: This depends on GUI changes and lists, # of changes
occurring in the network, and network objects managed.

NFM-P server to an NFM-P client 1 Mbps

NFM-P server to an XML API client (The bandwidth will depend on 1 Mbps
the XML-API application)

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
66 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
NFM-P bandwidth requirements

Table 4-2 NFM-P distributed server/database bandwidth requirements (continued)

Available bandwidth requirements for NFM-P Recommended bandwidth: excluding statistics and call trace
bandwidth requirements

Between a primary and a standby NFM-P server 1 Mbps

NOTE: When network element database backup synchronization
is enabled, the bandwidth requirement between the NFM-P
servers will vary significantly depending on the size of the network
element backup file sizes.

NFM-P server to an NFM-P auxiliary statistics collector 1 Mbps

Between primary and standby NFM-P databases 6 Mbps (sustained)

NOTE: The higher bandwidth is required to handle re-instantiation 15-25 Mbps (during re-instantiation or database backup
and is also required immediately after a database backup when synchronization)
database backup synchronization is enabled. 3 Mbps (minimum)

Table 4-3 Additional bandwidth requirements for file accounting STM results collection

Bandwidth requirements for installations collecting file accounting Increased bandwidth per 50 000 file accounting STM records
STM results using the logToFile method only

NFM-P server to an XML API client if using registerLogToFile 3.5 Mbps

NOTE: a higher bandwidth may be desirable

NFM-P server to NFM-P database station 1.5 Mbps

Between the NFM-P database stations – required for sufficient 2 Mbps (sustained)
bandwidth for database re-instantiations 12 Mbps (during re-instantiation or database backup
NOTE: The higher bandwidth is required to handle re-instantiation synchronization)
during STM collection

4.7.3 Additional bandwidth requirements for statistics collection

The size of the network and the number of statistics that are collected will impact the recommended
bandwidth. The following tables should be used to determine how much additional bandwidth will be
required between the NFM-P stations when statistics collection is added to the system. The
collecting server, in the tables below, would be either the NFM-P auxiliary statistics collector or, in
the absence of the NFM-P auxiliary statistics collector, the NFM-P server. The additional bandwidth
requirements are per 200 000 collected records per interval. The bandwidths of connections not
listed do not change dramatically with the addition of statistics.
The registerLogToFile method of retrieving statistics can be compressed or uncompressed. Using
the compressed option requires additional CPU requirements on the station that is collecting the
statistics (either NFM-P server or NFM-P auxiliary statistics collector). In this case, the bandwidth
required will be reduced.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 67
Network requirements NSP
NFM-P bandwidth requirements

Table 4-4 Additional bandwidth requirements for accounting statistics collection

Record storage Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth

location between between between NFM-P between NFM-P between NFM-P between
collecting server collecting server databases auxiliary databases collecting
and NFM-P and NFM-P database during server and
database auxiliary clusters re-instantiation XML-API client
database

NFM-P 2.2 Mbps N/A 3.2 Mbps N/A 18 Mbps N/A

database

NFM-P auxiliary N/A 2.2 Mbps N/A 0.8 Mbps per N/A N/A
database NFM-P auxiliary
database node

logToFile N/A N/A N/A N/A N/A 3.5 Mbps

(NFM-P server
or NFM-P
auxiliary
statistics
collector)

findToFile N/A N/A N/A N/A N/A 3.5 Mbps

(NFM-P server)

Table 4-5 Additional bandwidth requirements for application assurance accounting statistics collection

Record storage Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth

location between between between NFM-P between NFM-P between NFM-P between
collecting server collecting server databases auxiliary databases collecting
and NFM-P and NFM-P database during server and
database auxiliary clusters re-instantiation XML-API client
database

NFM-P 3.1 Mbps N/A 4.2 Mbps N/A 20 Mbps N/A

database

NFM-P auxiliary N/A 3.1 Mbps N/A 0.8 Mbps per N/A N/A
database NFM-P auxiliary
database node

logToFile N/A N/A N/A N/A N/A 4.6 Mbps

(NFM-P server
or NFM-P
auxiliary
statistics
collector)

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
68 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
NFM-P bandwidth requirements

Table 4-6 Additional bandwidth requirements for performance statistics collection

Record storage Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth

location between between between NFM-P between NFM-P between NFM-P between
collecting server collecting server databases auxiliary databases collecting
and NFM-P and NFM-P database during server and
database auxiliary clusters re-instantiation XML-API client
database

NFM-P 5.4 Mbps N/A 14.4 Mbps N/A 72 Mbps N/A

database

NFM-P auxiliary 5.4 Mbps 5.4 Mbps 14.4 Mbps 0.8 Mbps per 72 Mbps N/A
database NFM-P auxiliary
database node

logToFile N/A N/A N/A N/A N/A 3.5 Mbps

(NFM-P server
or NFM-P
auxiliary
statistics
collector)

findToFile N/A N/A N/A N/A N/A 3.5 Mbps

(NFM-P server)

Table 4-7 Additional bandwidth requirements for LTE performance management statistics collection

Bandwidth requirements for installations collecting LTE Increased bandwidth per 200 000 LTE performance management
performance management statistics statistics records

Between a primary and a standby NFM-P server: 1.0 Mbps

If the NFM-P server is collecting the statistics:(NFM-P auxiliary
statistics collector is NOT installed)

Between a preferred and a reserved NFM-P auxiliary statistics 1.0 Mbps

collector if the NFM-P auxiliary statistics collector is collecting the
statistics

When an NFM-P auxiliary statistics collector is installed to collect statistics using the NFM-P
database, the bandwidth requirements between two geographic locations will need to reflect the
state where an NFM-P auxiliary statistics collector in geographic location A may send information to
the active NFM-P server in geographic location B which will, in turn, send information back to the
NFM-P database in geographic location A. For this reason, the bandwidth between geographic
location A and B must be the sum of the bandwidth requirements between the NFM-P auxiliary
statistics collector to NFM-P server and NFM-P server to NFM-P database. It is also a best practice
to ensure that the NFM-P auxiliary statistics collector, NFM-P server, and NFM-P database are all
collocated in the same geographic site.

4.7.4 NSP analytics server

When an NSP analytics server is deployed with NFM-P, the following bandwidth requirements
should be noted. The connections between the NSP analytics server and the NFM-P auxiliary
database(s) and NFM-P database(s) require minimal bandwidth.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 69
Network requirements NSP
NFM-P bandwidth requirements

Table 4-8 Additional bandwidth requirements for the NSP analytics server

Bandwidth requirements for installations with NSP analytics Recommended bandwidth

Between the NSP analytics server and the end user (web 2.5 Mbps minimum requirement, 10 Mbps optimal
browser)

Between the NSP analytics server and the server hosting nspOS 3 Mbps

Between the NSP analytics server and external FTP host (if used 3 Mbps
for sending results of scheduled reports)

4.7.5 NFM-P auxiliary call trace collectors

When an NFM-P auxiliary call trace collector is installed, there are a number of bandwidth
requirements listed below. Any bandwidths not listed are not impacted significantly by call trace
data collection.
To handle the redundant pairs appropriately, the bandwidth requirements between two geographic
locations will need to reflect the state where an NFM-P auxiliary call trace collector in geographic
location A may need to provide information to the API client in geographic location B. The
synchronization of call trace and debug trace files will be impacted by the number client application
ftp sessions retrieving call trace and debug trace files. To minimize this impact, it is recommended
to limit the number of ftp sessions.

Table 4-9 Additional bandwidth requirements for call trace collection

Bandwidth requirements for installations with call trace collection Bandwidth usage characterization

NFM-P server to an XML API client Low bandwidth XML-API requests and responses

XML API client to NFM-P auxiliary call trace collector station Higher bandwidth to retrieve via FTP the call trace files from the
NOTE: a higher bandwidth may be desirable NFM-P auxiliary

NFM-P auxiliary call trace collector Preferred station to it’s Higher bandwidth to ensure timely synchronization of call trace
Reserved redundant pair. files
NOTE: a higher bandwidth may be desirable

4.7.6 NFM-P auxiliary database

When an NFM-P auxiliary database is part of an NFM-P deployment, there are a number of
bandwidth requirements listed below. Any bandwidths not listed are not impacted significantly by
the use of the NFM-P auxiliary database for statistics collection.
When the auxiliary database cluster is deployed with a minimum of three nodes, the NFM-P
auxiliary database server requires a minimum of two network interfaces; one for communication to
the NFM-P management complex and one for internal data communication between each of the
NFM-P auxiliary database servers in the cluster. The interface for internal data communication
needs to be dedicated with a minimum interface speed of 1Gbps and part of a private network.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
70 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
Contributors to bandwidth requirements

Table 4-10 Additional bandwidth requirements for NFM-P auxiliary database

Bandwidth requirements for installations with NFM-P auxiliary Bandwidth usage characterization
database

NFM-P auxiliary statistics collector to NFM-P auxiliary database Higher bandwidth to write statistics data into the NFM-P auxiliary
cluster database cluster

NSP analytics server to NFM-P auxiliary database cluster Higher bandwidth to generate reports based upon raw and
NOTE: a higher bandwidth may be desirable aggregated data

NFM-P auxiliary database node to NFM-P auxiliary database High — must use a dedicated, minimum 1Gbps interface
node (intra-cluster)

NFM-P auxiliary database to NFM-P auxiliary database High — up to 500Mb

(redundant cluster)

4.8 Contributors to bandwidth requirements

4.8.1 NFM-P GUI clients
The bandwidth specifications provided above for NFM-P GUI clients are based on the fact that
information about changes in the network is forwarded to the NFM-P GUI clients. The NFM-P client
updates information visible to the user based on recent changes in the network.
A few examples of network changes which will be reported to NFM-P include status changes of
physical equipment, status changes of Layer 2 or Layer 3 interfaces, configuration of network
elements, provisioning of new equipment or services, status changes in services or any attributes
thereof, configuration changes of routing protocols and several others.
In situations where the frequency of changes sent to the NFM-P GUI is significant and exceeds the
bandwidth specification, the performance of the NFM-P client will degrade, and there is a possibility
that the connection to the server will be dropped. An NFM-P GUI restart will be required to
reconnect to the server to receive change notifications.

4.8.2 NFM-P GUI clients on X displays

NFM-P GUI clients can be displayed remotely on terminals using the X11 protocol for graphical
displays. In these cases, it is important to ensure the bandwidth availability between the station
running the NFM-P client and the host displaying the NFM-P client be at least 1024 Kbps. Also, it is
important to ensure the round-trip network latency between these two hosts is quite low (20-30
ms). To achieve acceptable performance on bandwidth limited links, X-compression should be
used by using the ssh -XC command. If not using compression, it is recommended that the
minimum bandwidth be higher than 1024 Kbps. Situations where the available bandwidth is lower
or the network latency is higher will result in poor usability of the NFM-P GUI client. A bandwidth of
1024 Kbps will impact GUI start time and will not meet the published time of less than 2 minutes.
Extra bandwidth may be required to support the network elements described in 4.12 “Network
element specific requirements” (p. 80)
Note that NFM-P GUI client startup may be impacted when using minimum bandwidth links.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 71
Network requirements NSP
Contributors to bandwidth requirements

4.8.3 XML API clients

There are two main factors affecting the bandwidth requirements between the NFM-P server and an
XML API client:
• Design and behavior of the application using the XML-API interface
• Rate of changes in the network
Applications which listen to network changes via the JMS interface provided by NFM-P XML API or
applications which retrieve large pieces of information via the API, such as statistics information or
network inventory information, require access to dedicated bandwidth from the machine hosting the
application to the NFM-P server according to the tables above. Applications which do not require
real time event and alarm notification may operate with acceptable performance when the
bandwidth between the machine hosting the application and the NFM-P server is less than the
quantity specified in the tables above.
It is a best practice to minimize event and alarm notifications using a JMS filter to reduce bandwidth
requirements and the possible effects of network latency.
In an environment where network changes are infrequent, it is possible to successfully operate an
application using the API when the bandwidth between the machine hosting this application and the
NFM-P server is less than the quantity specified in the tables above, possibly as little as 128 kbps.
However, in situations where the frequency of network changes increases, the performance or
responsiveness of the application will degrade.

4.8.4 NFM-P auxiliary statistics collector

The main factors impacting communication to and from the NFM-P auxiliary statistics collector are:
• Number of performance statistics being collected. The NFM-P server needs to tell the NFM-P
auxiliary statistics collector which statistics to collect every interval.
• Number of statistics collected from the network elements.
• Number of statistics written to the NFM-P database.
The more performance statistics are collected, the more significant the bandwidth utilization
between the NFM-P server and the NFM-P auxiliary statistics collector. Similarly, this requires more
significant bandwidth utilization between the NFM-P auxiliary statistics collector and the NFM-P
database stations. The bandwidth requirements are not dependent on network activity.

4.8.5 NFM-P call trace collector

The main factors impacting communication to and from the NFM-P auxiliary call trace collector are:
• Number of NEs where call traces are enabled.
• Size of files being retrieved by the NFM-P XML-API client requesting the call trace.
The more call traces that are enabled, the higher the bandwidth requirement from the CMM and
CMG network elements to the NFM-P auxiliary call trace collector. Enable and Disable messages
are sent to the NFM-P auxiliary call trace collector from the NFM-P server. NFM-P XML-API clients
can ask the NFM-P server for the list of NFM-P call trace collector stations, and ftp connect directly
to the NFM-P auxiliary call trace collector to retrieve the call trace log files.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
72 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
Contributors to bandwidth requirements

4.8.6 NSP Flow Collector and Flow Collector Controller

The main factors impacting communication to and from the NSP Flow Collector are:
• Size of the NFM-P managed network for the network extraction
• Size of generated IPDR files
• Number of network elements sending cflowd records

The main factors impacting communication to and from the NSP Flow Collector Controller are:
• Size of the NFM-P managed network for the network extraction
• Number of NSP Flow Collectors connected to the NSP Flow Collector Controller

Table 4-11 Additional bandwidth requirements for the NSP Flow Collector

Bandwidth requirements for NSP Flow Collector Bandwidth usage characterization

NSP Flow Collector Controller to an NSP Flow Collector Bandwidth requirement will depend upon network size, which
This is for Network Snapshot Transfer (FTP/SFTP) By default this determines the network extraction file size, and the desired time
operation should only occur weekly if the NFM-P server and NSP complete the file transfer from the NSP Flow Collector Controller
Flow Collector Controller remain in sync. The amount of to the NSP Flow Collector
bandwidth required is dependent on network size.

Managed Network to NSP Flow Collector 40 Mbps per 20 000 flows per second
In the case of Redundant NSP Flow Collectors, the amount of
dedicated bandwidth is required for each NSP Flow Collector.

NSP Flow Collector to IPDR file storage server Use the information on the left to calculate the amount of data
Approximate amount of Stats per a 1 MB IPDR Stats File: 2,560 generated for the expected statistics. Use this to calculate the
TCP PERF statistics (all counters) or, 3,174 RTP statistics (all time to transfer at a given bandwidth. The total time must be less
counters) or, 9,318 Comprehensive statistics (all counters) or than 50% of collection interval. For example – if 1 GB of IPDR
9,830 Volume statistics (all counters) In the case of Redundant files are expected per interval, and the collection interval is 5min,
NSP Flow Collectors, the amount of dedicated bandwidth a 45 Mbps connection will take 3min,2sec to transfer. This is more
calculated on the right is for each NSP Flow Collector to the than 50% and a larger network connection is required.
station where IPDR files are being transferred.

Table 4-12 Additional bandwidth requirements for the NSP Flow Collector Controller

Bandwidth requirements for NSP Flow Collector Controller Bandwidth usage characterization

NFM-P server to an NSP Flow Collector Controller Bandwidth requirement will depend upon network size, which
This is for Network Snapshot Transfer (FTP/SFTP) By default this determines the network extraction file size, and the desired time
operation should only occur weekly if the NFM-P server and NSP complete the file transfer from the NFM-P server to the NSP Flow
Flow Collector remain in sync. The amount of bandwidth required Collector Controller.
is dependent on network size.

4.8.7 NFM-P PCMD auxiliary collector

The main factors impacting communication to and from the NFM-P auxiliary PCMD auxiliary
collector are:
• Number of bearers.
• Number of and size of events per bearer.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 73
Network requirements NSP
Network bandwidth

• Size of files being retrieved by the NFM-P XML-API client requesting the PCMD files.
On average, each bearer will generate 100 events per hour where each event is approximately 250
bytes in size.

4.9 Network bandwidth

4.9.1 Bandwidth requirements
In order to effectively manage the network, NFM-P must have access to sufficient bandwidth
between the NFM-P server(s), NFM-P auxiliary(s) and the network elements.
This bandwidth will be used to carry the management traffic between NFM-P and the network
element. The following table describes the bandwidth requirements for a particular network
element.

Table 4-13 NFM-P server to network bandwidth requirements

Network element example Bandwidth requirement from NFM-P server(s)

to the network element

7950 XRS 2-4 Mbps

7750 SR-12E (fully loaded) 2 Mbps

7750 SR-12 (fully loaded) 2 Mbps

7750 SR-2s 2 Mbps

7750 SR-a4 1 Mbps

7750 SR-c12 (fully loaded) 600 kbps

7450 ESS-7 (fully loaded) 1 Mbps

7450 ESS-1 200 kbps

7705 SAR (fully loaded) 200 kbps – 400 kbps

7250 IXR-6 / 7250 IXR-R4 / 7250 IXR-R6 / 7250 IXR-x 800 kbps – 1000 kbps

7250 IXR-e 300 kbps

7210 SAS-E, 7210 SAS-M, 7210 SAS-K 200-300 kbps

7210 SAS-D, 7210 SAS-X, 7210 SAS-T, 7210 SAS-R, 7210 SAS-Mxp, 7210 500-600 kbps
SAS-Sx

7701 CPAA / vCPAA 250 kbps

9500 MPR / Wavence SM 200 kbps

OmniSwitch 6250, 6350 6400, 6450, 6465, 6560, 6850, 6855, 6865, 9000 Series 300 kbps

OmniSwitch 6860, 6860E, 6860N, 6900, 10K 400 kbps

CMM 200 kbps

1830 VWM OSU 400 kbps

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
74 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
Network bandwidth

4.9.2 Details on the bandwidth requirements

The recommended bandwidth described above is a conservative figure that is meant to ensure that
the performance of NFM-P and its ability to manage successfully each network element will not be
affected by unusual network conditions.
Specifically, the bandwidth recommendation ensures that NFM-P can fully discover (or
resynchronize) all of the objects contained in the network element, within a reasonable amount of
time, varying heavily based upon the specific network element type and configuration.

The following are the main operations that result in significant amounts of information being
exchanged between NFM-P and the network elements. These factors are therefore the principal
contributors to the bandwidth requirements.
• Network element discovery: Upon first discovery of the network element, a significant amount of
data is exchanged between NFM-P and the network element.
• SNMP traps: SNMP traps do not result directly in significant data being sent from the network
element to the NFM-P. Several of the SNMP traps however do not contain all of the information
required for NFM-P to completely represent the new status of the network element. As a result,
NFM-P will subsequently perform a poll of a certain number of the SNMP MIBs to obtain the
required information from the network element. Consequently, SNMP traps do result in a certain
quantity of data and therefore cause bandwidth utilization. The exact quantity of bandwidth
utilized will vary based on the number and the type of trap that is sent from the network element.
In the worst case however, this bandwidth utilization will be less than that utilized during a
network element discovery.
• SNMP polling: It is possible to configure NFM-P to poll the SNMP MIBs on the network elements
at various intervals. By default, NFM-P will perform a complete poll of the SNMP MIBs every 24
hours on non-SR–OS based network elements. During the polling cycle, the amount of data
transferred between NFM-P and the network element is equivalent to the amount of data
transferred during the network element discovery.
• Statistics collection: It is possible to configure NFM-P to poll the SNMP MIBs on the network
elements that contain performance statistics information. During the polling cycle, the amount of
data transferred between NFM-P and the network element is less than the amount of data
transferred during the network element discovery. With the configuration of an NFM-P auxiliary
statistics collector, the communication from and to the network elements will be distributed
between the NFM-P server and an NFM-P auxiliary statistics collector.
• Network element backup: It is possible to configure NFM-P to request a backup of the network
element at specified interval. During the NE backup cycle, the amount of data transferred
between NFM-P and the network element is less than half of the amount of data transferred
during the network element discovery.
• Provisioning of services and deployment of configuration changes: When network elements are
configured or when services are provisioned via the NFM-P GUI or via application using the API,
a small quantity of network bandwidth is utilized. The amount of data transferred is significantly
less than during the network element discovery.
• Initiation and collection of STM tests and their results: When STM tests are initiated, the NFM-P
server sends individual requests per elemental test to the network elements. Once the test is
complete, the network elements report back using a trap. The NFM-P server then requests the
information from the network element, and stores it in the database. This can result in a
significant increase in network traffic to the network elements.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 75
Network requirements NSP
Network bandwidth

• Software Downloads: The infrequent downloading of network element software loads is not
included in the bandwidth levels stated in Table 4-13, “NFM-P server to network bandwidth
requirements” (p. 74). Bandwidth requirements will depend upon the size of the network element
software load and the desired amount of time to successfully transfer the file to the NE.
For some network elements, management of the NE includes methods other than standard MIB/
SNMP management – for example web-based tools. These network elements may require
additional bandwidth above the bandwidth levels stated in Table 4-13, “NFM-P server to network
bandwidth requirements” (p. 74).

4.9.3 Possible consequences of insufficient bandwidth

In situations where there is less than the recommended bandwidth between the NFM-P and the
network element, the following are possible consequences:
• The length of time required to perform a network element discovery will increase
• The length of time required to perform a SNMP poll of the network element will increase
• The length of time required to retrieve statistics from the network element will increase
• The proportion of SNMP traps that will not reach NFM-P because of congestion will increase.
This is significant since NFM-P will detect it has missed traps from the network element and will
result in NFM-P performing additional SNMP polling to retrieve the missing information. This will
result in additional data being transferred, which will increase the bandwidth requirements,
possibly exacerbating the situation.

4.9.4 Determining total bandwidth requirements for NFM-P managed networks

The amount of bandwidth required for each of the network elements should be obtained from Table
4-13, “NFM-P server to network bandwidth requirements” (p. 74).
The total amount of bandwidth that is required for NFM-P to manage the complete network will vary
based on the topology of the infrastructure that is used to carry the management traffic. From NFM-
P’s perspective, there must be sufficient bandwidth (as per Table 4-13, “NFM-P server to network
bandwidth requirements” (p. 74)) between itself and each of the network elements that is under
management.

In cases where the management traffic is carried over physical point-to-point links between the
NFM-P server and NFM-P auxiliary network and each of the network elements, sufficient bandwidth
must be reserved on the physical links. The NFM-P server complex can simultaneously
communicate to several NEs for the following functions:
• NE discovery, NE resync, resyncing for trap processing
• NE backups, NE software downloading, and sending configurations to NEs
• Collecting performance statistics
• Collecting accounting statistics
• Initiating STM tests on NEs
• Retrieve STM Test Results - also via (s)FTP
• NE reachability checks and NE trap gap checks

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
76 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
Network latency

Rarely are all of the above performed simultaneously so it is recommended to assume for link
aggregation points that NFM-P can communicate with a minimum of 20-30 NEs simultaneously –
this can increase to 60-70 NEs on a 16 CPU core NFM-P server station. For Networks of over 1000
NEs or where an NFM-P auxiliary statistics collector is being used, that number should be
increased by 20-30 NEs. Higher bandwidth maybe required under special cases where above
average data is attempted to be transferred between NFM-P and the network elements. For
example, large statistics files, NE backups, or software images.

4.10 Network latency

4.10.1 Network latency considerations

Network latency can potentially impact the performance of NFM-P. The following are known impacts
of latency between the various NFM-P components:
• NFM-P server to NFM-P clients (GUI/XML-API): event notification rates of network changes
• NFM-P auxiliary statistics collector to the network elements: ftp connection for statistics
collection and SNMP stats collection
• NFM-P server to the network elements: resync times, provisioning, ftp connections for statistics
and network element backups, trap handling, and SNMP stats collection (See 5.7 “Scaling
guidelines for statistics collection” (p. 96) for more information about latency impact on SNMP
stats collection)
• NFM-P server and NFM-P auxiliary collectors to NFM-P database: NFM-P performance is
sensitive to latency in this area. The round trip latency between the active NFM-P components
(server, database, auxiliary) must be no longer than 1 ms., otherwise overall NFM-P
performance will be significantly impacted. The NFM-P auxiliary database can tolerate up to 200
ms of latency between it and the rest of the NFM-P management complex.
Since SNMP communication to a single network element is synchronous, the impact of latency is
directly related to the number of SNMP gets and responses. Operations to a network element with a
round trip latency of 50 ms will have the network transmission time increase by ten times compared
to a network element with a round trip latency of only 5 ms. For example, is a specific operation
required NFM-P to send 1000 SNMP gets to a single network element, NFM-P will spend a total of
5 seconds sending and receiving packets when the round trip latency to the network element if 5
ms. The time that NFM-P spends sending and receiving the same packets would increase to 50
seconds if the round trip latency were increased to 50 ms.
Network element re-sync can be especially sensitive to latency as the number of packets
exchanged can number in the hundreds of thousands. For example, if a re-sync consists of the
exchange of 100 000 packets (50 000 gets and 50 000 replies), 50 ms of round trip latency would
add almost 42 minutes to the overall re-sync time and 100 ms of round trip latency would add
almost 84 minutes to the overall re-sync time.

NFM-P can use a proprietary mechanism to discover and resync specific node types and versions,
that can dramatically reduce resync and discovery times to network elements with high network
latency. TCP Streaming is supported on the following network element types with a release of
11.0R5 or later:
• 7950 XRS

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 77
Network requirements NSP
Network latency

• 7750 SR
• 7450 ESS
• 7250 IXR

4.10.2 Geographical redundancy of NFM-P components

It is ideal to ensure that all NFM-P stations and the NFM-P XML-API clients are collocated within a
geographical site on a high availability network to avoid the impact of network latency.
In cases where geographic redundancy is configured, all active NFM-P stations (NFM-P server,
NFM-P auxiliaries, and NFM-P database) should be located within a geographical site on a high
availability network to avoid the impact of network latency between components, which must remain
at less than 1 ms. When an NFM-P component (server, auxiliary, or database) switchover or failover
occurs, manual intervention may be required to align the stations on the same geographical site to
minimize the performance impact of network latency. This task can be automated by enabling the
database alignment feature within NFM-P.
NFM-P has been tested with up to 250 ms of geographic latency. Specifically for the NFM-P
database, Oracle doesn't provide any guidance on latency, other than adjusting TCP socket buffer
sizes. If the NFM-P deployment includes the NFM-P auxiliary database, the latency between the
active NFM-P auxiliary statistics collectors and the NFM-P auxiliary database must be less than 200
ms, effectively reducing the tested geographic redundancy limit from 250 ms to 200 ms.

4.10.3 Optimizing throughput between NFM-P components

In high-speed, high-latency networks the TCP socket buffer size controls the maximum network
throughput that can be achieved. If the TCP socket buffer is too small it will limit the network
throughput, despite the fact that the available bandwidth might support much higher transfer rates.
Adjusting the TCP socket buffer size to achieve optimal network throughput may be necessary if the
network bandwidth is more than 10Mbps and round-trip latency is higher than 25 ms.
The optimal TCP socket buffer size is the bandwidth delay product (BDP). The bandwidth delay
product is a combination of the network bandwidth and the latency, or round-trip time (RTT);
basically, it is the maximum amount of data that can be in transit on the network at any given time.
For example, given a 20Mbps network with a RTT of 40 ms the optimal TCP socket buffer size
would be computed as follows:

BDP = 20 Mbps * 40ms = 20,000,000 bps * .04s = 800,000 bits / 8 = 100,000 bytes socket
buffer size = BDP = 100,000 bytes

See the RHEL documentation for information about how to modify the TCP socket buffer size and
ensure that the change is persistent.
It is important to note that increasing the TCP socket buffer size directly affects the amount of
system memory consumed by each socket. When tuning the TCP socket buffer size at the
operating system level, it is imperative to ensure the current amount of system memory can support
the expected number of network connections with the new buffer size.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
78 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
Network reliability

4.10.4 Additional NFM-P database throughput optimizations

In addition to the optimizations above, the NFM-P database station requires changes to the
sqlnet.ora and listener.ora files that are contained in the oracle/network/admin directory. The lines
with the SEND_BUF_SIZE and RECV_BUF_SIZE should be uncommented (delete the “#”
character), and set to 3 times the BDP value calculated above. The database should be shutdown
when this change is made.

4.11 Network reliability

4.11.1 Network reliability considerations
This section describes network reliability considerations.

4.11.2 Reliability between NFM-P components

The NFM-P requires reliable network communications between all the NFM-P components:
• NFM-P servers
• NFM-P databases
• NFM-P auxiliaries
• NSP Flow Collector
• NSP Flow Collector Controller
• NFM-P auxiliary databases
• NSP analytics server
• NFM-P clients and NFM-P client delegate server
• NFM-P XML API clients
The performance and operation of NFM-P can be significantly impacted if there is any measurable
packet loss between the NFM-P components. Significant packet loss can cause NFM-P reliability
issues.
Nokia supports the deployment of NFM-P using the RHEL IP Bonding feature. The support for IP
Bonding is intended only to provide network interface redundancy configured in active-backup
mode for IP Bonding on the OS instance hosting the application software. All other modes of IP
Bonding are not supported. See the RHEL documentation for information about configuring IP
Bonding.

4.11.3 NFM-P server to NE network reliability

The NFM-P server requires reliable network connectivity between the NFM-P server/Auxiliary to the
managed network elements. The mediation layer in NFM-P is designed to recover from lost packets
between the NFM-P server and the network elements; however, these mechanisms come with a
cost to performance. Any measurable packet loss will degrade performance of NFM-P's ability to
manage the network elements. The loss of packets between NFM-P and NE will have an impact on
(but not limited to):
• Any SNMP operations to the network elements:

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 79
Network requirements NSP
Network element specific requirements

• SNMP Trap processing performance

• Provisioning performance
• Provisioning failures
• Performance statistics collection (possibly to the point where statistics collection will be
incomplete)
• STM test operation (initiating test and collecting results retrieval)
• NE discovery and resync performance
• NE discovery and resync failures
• scheduled polling for reachability checks
• Accounting statistics retrieval (possibly to the point where statistics collection will be incomplete)
• CLI session operation
• NE backup retrieval and software download performance
The following example highlights the significant impact of lost packets. It only considers the SNMP
communication times with one network element. With the default mediation policy configured with
an SNMP retry time-out of 10 seconds, and an average round trip latency of 50 ms between NFM-P
server and the network element, NFM-P will spend a total of 25 seconds sending and receiving
1000 packets (500 SNMP gets and 500 SNMP responses). With a 0.1% packet loss (1 packet out
of the 1000) the NFM-P server will wait for the retry time-out (10 seconds) to expire before
retransmitting. This will cause the time to complete the 500 SNMP gets to increase by 10 seconds –
for a total of 35 seconds of communication time, or an increase of 40% over the time with no packet
loss. With 0.5% packet loss, the 500 SNMP gets would increase by 50 seconds – for a total of 75
seconds to complete or an increase of 200%.

4.12 Network element specific requirements

4.12.1 GNE, Nokia OmniSwitch, and 9500 / Wavence considerations
NFM-P clients support the web-based WebView functionality on OmniSwitch family of switches
which requires direct network connectivity to the network element from the NFM-P client.
NFM-P clients support web-based clients on Generic network elements (GNEs) but require direct
network connectivity between the NFM-P client and GNE.
9500 MPR / Wavence SM support includes the use of NEtO for specific management functions for
these network element types. NEtO is a separate application that is installed along with the NFM-P
client and launched through the NFM-P client UI. See the NE documentation for current memory
requirements that are in addition to the NFM-P client memory requirements. The 9500 MPR /
Wavence SM also uses a web interface for management.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
80 3HE-18161-AAAB-TQZZA Issue 1
Network requirements NSP
Mechanism to maintain current state of network elements

4.13 Mechanism to maintain current state of network elements

4.13.1 Overview

NFM-P uses several mechanisms to maintain and display the current state of the network elements
it manages. These mechanisms can include:
• IP connectivity (ping) verification
• SNMP connectivity verification
• SNMP traps
• SNMP trap sequence verification
• Scheduled SNMP MIB polling
These mechanisms are built into the Nokia 7950 XRS, 7750 SR, 7450 ESS, 7450 SR, 7210 SAS,
and 7705 SAR network elements and the NFM-P network element interaction layers.

4.13.2 IP connectivity (ping) verification

NFM-P can be configured to ping all network elements at a configurable interval to monitor IP
connectivity. If the network element is unreachable, an alarm will be raised against the network
element. Details of the alarm are the following:
• Severity: Critical
• Type: communicationsAlarm
• Name: StandbyCPMManagementConnectionDown, OutOfBandManagementConnectionDown or
InBandManagementConnectionDown
• Cause: managementConnectionDown.
Ping verification is disabled by default. IP connectivity checks using ping must be scheduled
through the default policy.

4.13.3 SNMP connectivity verification

NFM-P performs an SNMP communication check every 4 minutes. If NFM-P can not communicate
via SNMP with a network element, it will raise a communications alarm against that network
element. NFM-P will also color the network element red on the map to indicate the communication
problem. NFM-P will clear the alarm and color the network element as green once NFM-P detects
SNMP connectivity to the network is re-established. Details of the alarm are the following:
• Severity: Major
• Type: communicationsAlarm
• Name: SnmpReachabilityProblem
• Cause: SnmpReachabilityTestFailed
This behavior occurs by default and is not configurable.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 81
Network requirements NSP
Mechanism to maintain current state of network elements

4.13.4 SNMP traps

NFM-P listens to SNMP traps to receive changes from the network elements. NFM-P configures the
trap log ID on each network element when it is first discovered. The network element then uses that
trap log ID to send all configuration changes and updates to NFM-P. The NFM-P will react to the
traps it receives and make appropriate changes to the database, alarms and related object as
required.

4.13.5 SNMP trap sequence verification

NFM-P retrieves the last trap sequence number sent from all network elements at a configurable
interval. This interval is configurable on a per resource group basis. Resource groups allow the user
to configure the communications behavior of a group of network elements. By default, the core
resource group includes all network elements, and verifies the trap sequence number every 4
minutes. NFM-P compares that sequence number with the sequence number of the last trap it
received from that network element. If they do not match, NFM-P will request only the missing traps
from the network element. If at any point NFM-P realizes that it is missing more than 200 traps from
a network element, or if the network element no longer has the missed trap, NFM-P will request a
full resynchronization on that network element rather than just request the missing traps.
This behavior occurs by default and is not configurable.

4.13.6 Scheduled SNMP MIB polling

NFM-P can poll all data SNMP MIBs from the network elements at a configurable interval. The
Polling Policy is disabled by default. This behavior is configurable via the Polling tab of the network
elements properties form.

4.13.7 Network outages and recovery

When a Nokia 7x50 based network element loses visibility of the NFM-P, it is unable to send traps
to the network manager, and the traps are queued on the network element. 4.13.5 “SNMP trap
sequence verification” (p. 82) describes NFM-P behavior with regards to trap handling. When a
network outage occurs, the network element configuration in NFM-P will be made consistent with
the network element, but any event notifications, such as SNMP traps, that occurred during the
network outage will not have been processed. This will cause intermediate state change alarms to
not be reflected in NFM-P during the network outage.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
82 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
NSP scaling and performance

5 Scaling and performance

5.1 NSP scaling and performance

5.1.1 Introduction
The following sections present the network dimension parameters for the minimum and production
platforms described in section 2.2.4 “Minimum and production platform requirements” (p. 36).

5.2 Scale limits for NSP deployments

5.2.1 NSP deployment with classic and model-driven IP management
The following tables present key dimension details for an NSP deployment with classic and model-
driven IP management as described in the NSP Installation and Upgrade Guide.

Table 5-1 Dimensioning details for an NSP deployment with classic and model-driven IP
management

Key dimension Minimum platform Production platform

Number of IP services managed 3000 300 000
Number of L2 access interfaces 5000 500 000
Number of L3 access interfaces 300 30 000
Combined total of RSVP-TE and 400 40 000
SR-TE LSPs (non PCE controlled)
Number of service tunnels 600 60 000
Number of NFM-P managed services 17 000 1 700 000
Number of supported NEs 500 50 000

5.2.2 Control plane-only deployment

The following table presents key dimension details for a control plane-only deployment as
described in the NSP Installation and Upgrade Guide.

Table 5-2 Dimensioning details for control plane-only deployment

Key dimension Minimum platform Production platform

Total Number of LSPs 5000 120 000

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 83
Scaling and performance NSP
Scale limits for NSP deployments

Table 5-2 Dimensioning details for control plane-only deployment (continued)

Key dimension Minimum platform Production platform

Number of delegated RSVP-TE or 2000 50 000
SR-TE LSPs or both (PCE-Control,
PCE-Compute and PCE-Report)
Number of un-delegated RSVP-TE 3000 70 000
LSPs (only PCE-Report)
Number of IP NEs (PCEP) 1000 8000 (see Note)
Number of IP NEs (BGP-LS) 1000 8000
Number of IP links 2000 22 000
Number of SR Policy Segment Lists 1000 10 000

Notes:
1. Customers wishing to deploy more than 6000 PCEP IP NEs should contact Nokia for details on
timer configuration.
The following table presents key dimension details for a Simulation tool deployment.

Table 5-3 Dimensioning details for Simulation tool deployment

Key dimension Minimum platform Production platform

Total Number of LSPs 5000 20 000
Number of IP NEs 1000 3000
Number of IP links 3000 10 000

5.2.3 Intent Based Service Fulfillment Scaling Limits

The following tables presents scaling dimensions for Intent Based Service Fulfillment.

Key dimension Minimum platform Production platform

Number of services 3000 1 700 000
Number of intent aware 1500 500 000
services
Number of service endpoints 6000 3 400 000
Number of intent aware 3000 1 000 000
service endpoints

Notes:
1. Please consult with Nokia on the performance aspects of brownfield stitching and association.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
84 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scale limits for NSP deployments

5.2.4 Scale limits for WFM deployment

The following table presents scaling dimensions for deployment of WFM.

Table 5-4 Dimensioning details for WFM deployment

Key dimension Lab platform Production platform

Number of stored executions 500 000 1 000 000
(results)

5.2.5 Scale limits for Model Driven Mediation

The following table presents scaling dimensions for Model Driven Mediation application.

Key dimension Scale Limit

Network Infrastructure Management (nim) 4000
LLDP link discovery

5.2.6 Scale limits for Infrastructure Configuration Management

The following table presents scaling dimensions for Infrastructure Configuration Management.

Key dimension Scale Limit

Configuration templates within ICM 500
Configuration instances per configuration 20 000
template
Total number of configuration instances in ICM 500 000

Note: Customers should use caution when invoking bulk actions at the ICM template level
with many thousands of configuration instances as this may take many hours to complete.
Bulk operations will be optimized in a future NSP release.

5.2.7 Cross-domain resource control scaling within NSP classic and model-driven
IP + optical deployment
The following table presents key dimension details for cross-domain resource control in an NSP
classic and model-driven IP + optical deployment as described in the NSP Installation and Upgrade
Guide.

Table 5-5 Dimensioning details for cross-domain resource control in an NSP classic and
model-driven IP + optical deployment

Key dimension Minimum platform Production platform

IP NEs 100 3000
Optical NEs 100 3000

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 85
Scaling and performance NSP
Scale limits for applications

Table 5-5 Dimensioning details for cross-domain resource control in an NSP classic and
model-driven IP + optical deployment (continued)

Key dimension Minimum platform Production platform

Ports 2400 240 000
Links 250 25 000
CDLs 100 10 000
Optical services 200 20 000
LLI 50 5000
IP-optical correlation 100 10 000

5.3 Scale limits for applications

5.3.1 Concurrent session limits
The following table represents the concurrent session limit for applications in a deployment with
NSP.

Table 5-6 Concurrent session limits for NSP applications

Application Maximum number of concurrent sessions

Analytics 10
Fault Management 125
Network Supervision 50
Service Supervision 125
Network Health Dashboard 125

Note: The combined concurrent session limit for all applications is 125.
The NSP can support up to 100 concurrent NE sessions on NFMP managed nodes, and 100
concurrent NE sessions on MDM managed nodes. Users must have execute level access control
for a NE to create a NE session.

5.3.2 Scale limits for Kafka event notifications

Kafka event notifications supports a maximum of 200 OSS subscriptions.

5.3.3 Scale limits for Telemetry

Telemetry data collection is limited by the maximum OSS subscriptions supported by Kafka.
The maximum number of Telemetry notifications per second is 1500 per active MDM instance,
where one Telemetry record (a collection of statistics counters) update equals one Telemetry
notification.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
86 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scale limits for applications

The maximum number of rows uploaded to the database per minute is 90 000 per active MDM
instance, where one row equals one Telemetry record. This limit applies for Postgres and Auxiliary
database storage.
If NSP is deployed with multiple active MDM instances, the maximum collective upload rate to a
Postgres database is 180 000 rows per minute. When Telemetry data is stored in the Auxiliary
Database, the upload rate scales horizontally with more active MDM instances. Network activity,
database activity and latency can also affect database upload rates.

5.3.4 Event timeline limits for managed NEs and services

Some applications make use of historical data for managed NEs and services. The amount of
historical data is limited according to the mediation component and database storage.
NFM-P managed NEs and services have a default event timeline of 1 week for oracle database
storage and can be configured to a maximum of 1 month. For Auxiliary Database storage the event
timeline can be increased to a maximum of 1 year.
For NSP, MDM managed NEs and services have a default event timeline of 1 week for Postgres
database storage and can be configured to a maximum of 1 month. Auxiliary Database storage is
not supported for MDM managed NEs and services.

5.3.5 Scale limits for Fault Management

The following table defines the alarm limits for the Fault Management application:

Key dimension Maximum number of alarms

Historical alarms from non-NFM-P systems 10 million
(eg. NFM-T, MDM, NSP)
Active alarms from NFM-P, NFM-T, and/or 500 thousand
MDM-managed nodes

Note: Alarm limits describe the aggregate number of alarms that can be handled by the NSP
Fault Management application but do not supersede individual datasource limits.
The following table defines the performance limits for the Fault Management application:

Key dimension Rate

Sustained alarm rate (combined from all 200/second
sources) (see Note)

Note: Alarm rate describes the aggregate volume that can be handled by the NSP Fault
Management application but does not supersede individual datasource limits.
The following table defines the squelching limits for the Fault Management application:

Key dimension Maximum number of objects

Port squelching 1000 ports

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 87
Scaling and performance NSP
Scale limits for applications

Key dimension Maximum number of objects

Network element squelching 1000 network elements
Resource group squelching 250 000 ports and/or network elements
combined

Note: Because the maximum size for a port group is currently 100k (100 000) ports, multiple
resource groups are needed to achieve the 250k squelching limit.

5.3.6 Scale limits for Network Supervision

The Network Supervision application supports up to 50 thousand monitored NEs.

• The maximum number of NEs per group is 2000.
• The maximum number of groups per view is 250.
The Link Utilization map view has limits on the number of supported endpoints and links that can
subscribe for stats simultaneously. The following table lists the recommended maximum number of
links per NE group for different NE types. These are not absolute maximum values but safe
recommended limits based on product testing.

Link Type Maximum

7750 SR physical link 500
7705 SAR / 7210 SAS physical link 200
7750 SR LAG link 160
7705 SAR / 7210 SAS LAG link 60

The size of the supervision group (number of NEs and links) may affect performance and topology
rendering time.

Multi-layer maps support a recommended maximum of 4000 objects. Users should expect the
following multi-layer map loading times with different numbers of NEs.
• For 250 NEs (125 physical links), approximately six seconds for the initial page loading and four
seconds to reload.
• For 500 NEs (250 physical links), approximately nine seconds for the initial page loading and six
seconds to reload.
• For 2000 NEs (1000 physical links), approximately 50 seconds for the initial page loading and 28
seconds to reload.

5.3.7 Scale limits for Service Supervision

The Service Supervision application supports up to 1.7 million services.

• Maximum number of services per group is 50 000
• Maximum number of groups per view is 5000.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
88 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scale limits for applications

5.3.8 Scale limits for Network Health Dashboard

Network Health Dashboard supports scaling limits defined for Fault Management, Network
Supervision and Service Supervision applications.

5.3.9 Scale limits of Group Manager

Where cross-domain resource control is deployed, the following scaling limits for Map Layout will
apply:
• Maximum number of nodes per region is 250.
• Maximum number of links per region is 1200.

Group directories have the following scaling limits.

• There is no limit on the number of directories for each directory type (network element, port,
service, analytics resource).
• Maximum number of groups per directory is 5000.
• Maximum number of objects per group is 100 000.

5.3.10 Scale limits of Help Center application

The maximum number of concurrent sessions for Help Center Application is 250.

5.3.11 Scale limits for NSP Baseline Analytics application

The NSP Baseline Analytics application can support collection storage in the Postgres database or
in the Auxiliary database. Baselines are supported on NFM-P and MDM managed nodes.

Key dimension Postgres database storage AuxDB storage

Number of baselines 10 000 100 000
Retention time 35 days 403 days
Window Duration 15 minutes 15 minutes

5.3.12 Scale limits for NSP Indicators application

The NSP Indicators application can support collection storage in the Postgres database or in the
Auxiliary database. Indicators are supported on NFM-P and MDM managed nodes.
The NSP Indicators application can only support up to a total of 20 Indicator rules.

Key dimension Postgres database storage AuxDB storage

Number of resources 10 000 100 000
Retention time 35 days 403 days

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 89
Scaling and performance NSP
Scale limits for applications

Key dimension Postgres database storage AuxDB storage

Collection Interval (Simple 900 seconds 900 seconds
Indicators) 15 minutes 15 minutes
Window Duration (Complex
Indicators)

5.3.13 Scale limits for Large Scale Operations

The Large Scale Operations feature has scaling limits for framework and for device operations.
The following table summarizes the framework limits.

Key dimension Maximum

Number of concurrent LSO executions 20
Number of stored operations (historical and 500
running)
Number of operation types 100
Number of targets per operation 2000
Number of phases per operation type 10

The following table summarizes the NE device operation limits.

Key dimension Maximum

Number of classic nodes for NE backup 10 000
Number of model-driven nodes for NE backup 4000
Disk space for software images for model 20 Gb
driven devices
Disk space for NE backups for model driven 100 Gb
devices

Note: Numbers are based on using enhanced profile disk availability for File Service.

Note: Role Based Access Control will not apply to LSO app user operations in this release.

5.3.14 Scale limits for ACT event processing

The following limits apply for ACT event processing.

Key dimension Standard NSP Enhanced NSP

deployment deployment
Maximum kafka source notifications per 2000 4000
second

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
90 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Failover performance for HA and redundant deployments

Key dimension Standard NSP Enhanced NSP

deployment deployment
Maximum kafka notifications per second 2000 3000
for a single kafka source topic

NSP supports a maximum of 300 ACT rules.

5.3.15 Scale limits for Zero Touch Provisioning

The following limits apply to Day 0 Zero Touch Provisioning (ZTP):

Key dimension Maximum

NE instances created per second 5
Simultaneous downloads from file server 10
ZTP instances in various provisioning states 1000

5.3.16 Scale limits for Generic Mediator

The Generic Mediator application has the following scaling limits:

Key dimension Maximum

Concurrent threads 10
Request queue size 50

5.3.17 Web application performance and User Access Control

In an NSP deployment with User Access Control enabled, and more than 10 user groups are
defined, in large networks (> 2000 NEs), NSP web application performance may be affected if the
resource groups contain a very large number of equipment and/or service objects.

5.4 Failover performance for HA and redundant deployments

5.4.1 Overview
NSP components in a redundant configuration will experience application down time during an
activity switch. NSP components in an HA configuration may experience application down time
when switching to a new cluster leader or during pod reselection.
In an NSP deployment with classic and model-driven IP management, the Service Fulfillment
application enables service provisioning. Operators will experience a service provisioning outage
during a leader switch within an HA cluster, or during an activity switch in an active/standby
deployment. The actual down time will vary based on network size.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 91
Scaling and performance NSP
NFM-P Scalability guidelines

Service Fulfillment
no MDM learned 65k services learned
services from MDM
60k PCEP LSPs 60k PCEP LSPs
3k NEs and 11k links 3k NEs and 11k
links
Down time for a switch of leader activity within 5 - 20 minutes 33 - 80 minutes
an HA cluster
Down time for an activity switch from active to 16- 30 minutes 45 - 90 minutes
standby (HA cluster or single node) in a
redundant deployment

Note: Performance assumes that NFM-P is running release 18.12 SP5 or later.
Users and client applications that need access to Launchpad and NSP applications will also
experience downtime during an activity switch and during pod re-selection in an enhanced
deployment. Once Launchpad has been restored to service, northbound clients can authenticate
and access applications.

Launchpad
Down time for pod reselection < 1s (see note)
Down time for an activity switch from active to 9 minutes
standby (enhanced or single node) in a
redundant deployment

Note: The Launchpad will remain available to users during a pod re-selection in an enhanced
deployment; some applications on Launchpad may be temporarily unavailable due to pod
rescheduling.

5.5 NFM-P Scalability guidelines

5.5.1 Scalability limits

Table 5-7, “NFM-P Release 22.6 scalability limits” (p. 93) represents the scalability limits for
Release 22.6. Note that:
• These limits require particular hardware specifications and a specific deployment architecture.
• Scale limits for all network elements assume a maximum sustained trap rate of 100 traps/
second for the entire network. NFM-P’s trap processing rate depends on many factors including
trap type, NE type, NE configuration, NE and network latency, network reliability as well as the
size and speed of the servers hosting the NFM-P application. NFM-P scalability testing runs at a
sustained trap rate exceeding 100 per second for the largest deployment and server
configurations.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
92 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
NFM-P Scalability guidelines

2.3 “NFM-P Hardware platform requirements” (p. 38) contains information about identifying the
correct platform for a particular network configuration. To achieve these scale limits, a distributed
NFM-P configuration is required, and may also require an NFM-P auxiliary statistics collector and a
storage array for the NFM-P database station.
Contact Nokia to ensure that you have the correct platform and configuration for your network size.

Table 5-7 NFM-P Release 22.6 scalability limits

Attribute of managed network Scaling limit

Maximum number of managed MDAs 60 000

Maximum number of network elements 50 000

1
Maximum number of GNEs 50 000

Maximum number of managed services 4 000 000

Maximum number of optical transport services 20 000

Maximum number of 1830 VWM RMUs 60 000

Maximum number of SAPs 12 000 000

Maximum number of simultaneous NFM-P GUI sessions 250

Maximum number of simultaneous web UI client sessions 4–250 Table 5-9, “NFM-P apps maximum number of concurrent
sessions” (p. 94)

Maximum number of simultaneous active XML API HTTP 30

applications

Maximum number of simultaneous active XML API JMS 20

applications

Maximum number of outstanding alarms 50 000

Maximum number of outstanding alarms - Distributed 250 000

Configuration

Maximum number of Historical Alarms 9 600 000

Maximum number of TCAs 250 000

Maximum number of monitored services in the Service 1 000 000

Supervision application

Maximum number of concurrent NSP analytics users 10

Notes:
1. The number of interfaces on a GNE and the traps that may arise from them is the key factor determining the
number of GNE devices that can be managed. As GNE devices are expected to be access devices the
sizing is based on an average of 10 interfaces of interest on each device (10 x 50 000 = 500 000 interfaces).
Processing of traps from interface types that are not of interest can be turned off in NFM-P. Under high trap
load, NFM-P may drop traps.
NFM-P uses the number of MDAs as the fundamental unit of network dimensioning. To determine
the current or eventual size of a network, the number of deployed or expected MDAs, as opposed
to the capacity of each router, must be calculated.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 93
Scaling and performance NSP
NFM-P Scalability guidelines

Table 5-8 Network element maximums and equivalency

Network element type Maximum number of MDA equivalency

network elements
supported

7750 SR, 7450 ESS, 7450 SR 50 000 1 MDA = 1 MDA 1 2

7705 SAR 50 000 50 000

7250 IXR-6 / 7250 IXR-10 / 7250 IXR-R4 / 7250 IXR-R6 50 000 1 MDA = 1MDA

7250 IXR-s / 7250 IXR-e 25 000 50 000

7210 SAS 50 000 50 000

OMNISwitch 6250, 6400, 6450, 6850, 6855 (each shelf in the stackable 50 000 50 000
chassis)

OMNISwitch 6350, 6465, 6560, 6865 (each shelf in the stackable chassis) 5000 5000

OMNISwitch 6860, 6860E, 6860N 5000 5000

OMNISwitch 6900 800 800

OMNISwitch 9600, 9700, 9700E, 9800, 9800E (each NI) 1000 1000

OMNISwitch 10K (each NI) 400 400

3
CMM 320
3
CMU 320

9500 MPR / Wavence SM 15 000 15 000

4
1830 VWM OSU 2000

VSC 1 N/A

Notes:
1. The IMM card has an MDA equivalency of 2 MDAs per card.
2. The CMA card has an MDA equivalency of 1 MDA per card.
3. The CMM has an MDA equivalency of 1 MDA per blade / VM.
4. The 1830 VWM OSU Card Slot has an MDA equivalency of 1/4 MDA per card to a maximum MDA
equivalency of 30 000

Table 5-9 NFM-P apps maximum number of concurrent sessions

NFM-P application Maximum number of concurrent sessions

Analytics 10

Fault Management 250

Help Center 250

Network Supervision 50

Service Supervision 250

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
94 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
NFM-P Scalability guidelines

Table 5-9 NFM-P apps maximum number of concurrent sessions (continued)

NFM-P application Maximum number of concurrent sessions

Wireless Supervision 50

Wireless NE Views 50

5.5.2 NFM-P performance targets

Table 5-10, “NFM-P Release 22 performance targets” (p. 95) represents the performance targets
for the NFM-P. Factors that may result in fluctuations of these targets include:
• NFM-P server and NFM-P database system resources
• network activity
• user/XML-API activity
• database activity
• network size
• latency

Table 5-10 NFM-P Release 22 performance targets

Performance item description Target

NFM-P client GUI performance

Time to launch an NFM-P client GUI 1 - 2 minutes

Time to launch an NFM-P client GUI configuration form ~5 seconds

Time to save an NFM-P client GUI configuration form ~2 seconds

NFM-P server performance

Time to restart the NFM-P server 15 - 30 minutes (subject to network dimensions)

NFM-P database Backup (without statistics) Up to 60 minutes (subject to network size)

NFM-P database Restore ~45 minutes

NFM-P server activity switch 10 - 30 minutes (subject to network dimensions)

NFM-P DB switchover (by invoking through the GUI) <10 minutes

NFM-P DB failover 30 minutes when managing maximum number of devices

Recovery of standby NFM-P database after failover <75 minutes

Upgrade Performance

NFM-P client Upgrade ~10 minutes

1
NFM-P complex upgrade (server, database, auxiliaries) <6 hours

NFM-P upgrade maximum visibility outage with NFM-P redundant 15 - 30 minutes

system 2

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 95
Scaling and performance NSP
Scaling guidelines for NFM-P XML API clients

Notes:
1. The target includes the installation of the software on the existing servers and NFM-P database conversion.
Operating System installation/upgrades, patching, pre/post-upgrade testing and file transfers are excluded
from the target.
2. Provided proper planning and parallel execution procedures were followed.

5.6 Scaling guidelines for NFM-P XML API clients

5.6.1 XML-API client limits
There can be a maximum of 20 NFM-P XML API JMS clients. Greater than 10 NFM-P XML API
JMS clients requires an NFM-P server with a minimum of 16 CPU Cores.
The number of NFM-P XML API HTTP clients supported by an NFM-P server station is 2 times the
number of CPU cores with at least 10 and at most 30 clients supported.
The maximum number of concurrent findToFile operations supported is five. The maximum number
of concurrent control script executions is five.

5.6.2 XML API JMS client messaging rates

Network latency between the NFM-P server and an NFM-P XML API client will reduce the JMS
message rate. For durable JMS clients, the Duplicate OK method will allow for a higher message
rate than the Auto Acknowledge method. See the NSP NFM-P XML API Developer Guide for more
information.
NFM-P is also able to deliver hundreds of messages per second to a non-durable NFM-P XML API
client.

Table 5-11 JMS durable messaging rates

JMS messaging Round-trip latency from the XML API client to the NFM-P server

0 ms 20 ms 40 ms

Durable connection with Auto-acknowledge 1000 692 349

(messages/s)

Durable connection with Duplicates-OK 1000 693 347

(messages/s)

5.7 Scaling guidelines for statistics collection

5.7.1 Statistics collection
NFM-P provides the ability to collect statistics information from the network elements. This section
provides guidelines that can be used to determine the extent to which statistics collection can be
retrieved from the network.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
96 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scaling guidelines for statistics collection

5.7.2 Statistics collection definitions

Performance statistics: These statistics are associated with various network objects such as ports,
interfaces, channels and network elements (routers). These statistics are retrieved by NFM-P using
SNMP polling according to the MIB policies that are configured by the user.
Accounting statistics: These statistics are associated with Services, Subscribers, and Network
Interfaces and contain data that can be used for accounting, billing and SLA management
purposes. These statistics are collected on the 7x50 and retrieved by NFM-P via a file that is
transferred via ftp/sftp.
Application Assurance Accounting statistics: These statistics are associated with Subscribers,
SAPs, and spoke SDP bindings and contain data related to traffic flows that can be used for QoS
and traffic management, and application aware reporting. These statistics are collected on the 7x50
ISA cards and retrieved by NFM-P via a file that is transferred via ftp/sftp.
Statistics Item: An individual statistics counter, such as RxOctets or TxFrames.
Statistics Record: A collection of statistics items which is retrieved from the router and stored in the
NFM-P database as an atomic operations. In the various statistics forms on the NFM-P GUI client,
a statistics record appears to the user as a single row which contains the collection or retrieval
timestamp and a set of individual statistics items. In the case of performance statistics, a statistics
record corresponds to a row in the MIB table.

5.7.3 Determining the number of statistics records that will be collected

Statistics can be collected and processed by the NFM-P server or by the NFM-P auxiliary statistics
collector for dedicated statistics handling. The NFM-P auxiliary statistics collector provides a
dedicated station for statistics collection. The following sections should be used to determine the
maximum performance and accounting statistics for different hardware setups.

5.7.4 Performance statistics

See the NSP NFM-P Statistics Management Guide to find the steps required to configure NFM-P to
retrieve and process performance statistics. Note that two steps are required to enable the
collection of performance statistics from the network. First, a policy is defined which specifies a set
of polling periods for various MIBs. Second, the policy is applied to a number of network elements.
In general, enabling the statistics collection of a MIB will result in one statistics record being
collected, at the specified polling period, for each network object to which the MIB applies.
For example, consider a policy is created with only the rtr.L2AccessDhcpRelayCfgStats MIB
enabled for collection at 15-minute intervals. That policy is assigned to only two network elements
which each contain 500 L2 Access Interfaces. As a result of this action, NFM-P will collect 1000
statistics records from the network every 15 minutes.
The quantity of resources which are allocated to the retrieval and processing of performance
statistics does not depend significantly on the number of CPU Cores available to the NFM-P server
or auxiliary statistics collector software. The tables below show the maximum number of
performance statistics that can be retrieved and processed by the NFM-P server and the NFM-P
auxiliary statistics collector every 15 minutes.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 97
Scaling and performance NSP
Scaling guidelines for statistics collection

Table 5-12 Maximum number of performance statistics records processed by an NFM-P server

Number of CPU cores on NFM-P Maximum number of performance statistics records per 15-minute interval
server stations
Collocated configuration Distributed configuration

6 or greater 50 000 150 000

Table 5-13 Maximum number of performance statistics records processed by an NFM-P statistics auxiliary

Number of active Maximum number of performance statistics records per 15-minute interval
auxiliary statistics
collectors Statistics collection with NFM-P Statistics collection Statistics collection logTofile only
database with single with three+ auxiliary
auxiliary database database cluster

8 CPU Cores, 32 12 CPU Cores, 8 CPU Cores, 32 12 CPU Cores, 32 12 CPU Cores,
GB RAM 32 GB RAM GB RAM GB RAM 32 GB RAM

1 500 000 2 000 000 500 000 2 000 000 2 000 000

2 500 000 2 000 000 500 000 4 000 000 4 000 000

3 500 000 2 000 000 500 000 4 000 000 4 000 000

In situations where NFM-P is asked to collect more performance statistics than it can process in the
specified polling period, the PollerDeadlineMissed alarms will start appearing. These alarms
indicate to the user that the polling mechanisms within NFM-P cannot retrieve the requested
information within the specified polling period. Should this situation arise, the polling period for
statistics should be increased or the number of objects that are applied to Statistics Poller Policies
should be reduced.

5.7.5 Performance statistics collection and network latency

NFM-P collection of performance statistics from a single network element may be limited due to the
round trip delay caused by network and network element latency. NFM-P collects performance
statistics records using SNMP. One record is collected at a time to limit the load on the network
element. Therefore, round trip latency will directly impact the maximum number of performance
statistics records collected. As an example, if the round trip latency is 100 ms, and we target a
completion time of 66% of the collection interval (to allow for processing variances and other
system impacts), the maximum number of performance statistics records that can be collected from
one network element in a 15 minute interval would be 6000 records (66% of 900 seconds divided
by 100 ms latency).

5.7.6 Accounting statistics

See the NSP NFM-P Statistics Management Guide to find the steps required to configure NFM-P to
retrieve and process accounting statistics.
The quantity of resources which are allocated to the retrieval and processing of accounting
statistics within the NFM-P server or auxiliary statistics collector are set at the installation time and
depend on the number of CPU Core available to the NFM-P server or auxiliary statistics collector
software. The number of CPU Cores available to the server depends on the number of CPU Cores
on the station and whether the NFM-P database software is collocated with the NFM-P server
software on the same station.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
98 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scaling guidelines for statistics collection

An accounting statistic record is the statistic for one queue for one SAP. For example, if 2 ingress
and 2 egress queues are configured per SAP, the “Combined Ingress/Egress” statistic represents 4
NFM-P accounting statistic records.
It is recommended that the Accounting Policy Interval and the File Policy Interval be aligned to the
same period. Misalignment of the policy periods can cause NFM-P resource contention for both
performance and accounting statistics processing.
The following tables provide the maximum number of accounting statistics records that can be
retrieved and processed by the NFM-P server or NFM-P auxiliary statistics collector in various
situations.
To reach the peak accounting statistics collection from the NFM-P auxiliary statistics collector
station, the NFM-P database station requires a customized configuration that can be obtained from
Nokia personnel.

Table 5-14 Maximum number of accounting statistics records processed by an NFM-P server
station

Number of CPU cores on Maximum number of accounting statistics records per 15-minute interval
NFM-P server stations
Collocated configuration Distributed configuration

6 100 000 200 000

8 or greater 200 000 400 000

Table 5-15 Maximum number of accounting statistics records processed by an NFM-P statistics auxiliary

Number of active Maximum number of accounting statistics records per 15-minute interval
auxiliary statistics
collectors Statistics collection with NFM-P database Statistics collection Statistics logToFile only
with single auxiliary collection with
database three+ auxiliary
database cluster

8 CPU cores, 32 GB 12 CPU cores, 32 8 CPU cores, 32 GB 12 CPU cores, 32 12 CPU cores,
RAM GB RAM RAM GB RAM 32 GB RAM

1 10 000 000 10 000 000 5 000 000 20 000 000 20 000 000

2 10 000 000 10 000 000 5 000 000 40 000 000 40 000 000

3 10 000 000 10 000 000 5 000 000 60 000 000 60 000 000

In situations where NFM-P is asked to collect more accounting statistics records than it can process
in the specified retrieval period, the extra statistics will not be retrieved from the network.
There are two methods to export accounting and performance statistics from NFM-
P; registerLogToFile, and findToFile. The registerLogToFile method is the preferred method and is
required for situations where more than 400 000 accounting statistics records are retrieved in 15
minutes or 500 000 performance statistics are retrieved in 15 minutes.

5.7.7 Application assurance accounting statistics

See the NSP NFM-P Statistics Management Guide to find the steps required to configure NFM-P to
retrieve and process application assurance accounting statistics.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 99
Scaling and performance NSP
Scaling guidelines for statistics collection

The quantity of resources which are allocated to the retrieval and processing of application
assurance accounting statistics within the NFM-P server are set at the installation time and depend
on the number of CPUs available to the NFM-P server software. The number of CPUs available to
the NFM-P server depends on the number of CPUs on the station and whether the NFM-P
database software is collocated with the NFM-P server software on the same station.
Scaling of application assurance collection is related to the number of objects configured for
collection as opposed to the number of records collected per interval.
The following tables provide the maximum number of application assurance objects that can be
configured for collection by the NFM-P server or NFM-P auxiliary statistics collector in various
situations.

Table 5-16 Maximum number of application assurance accounting objects configured for
collection by an NFM-P server station

Number of CPU cores on Maximum number of application assurance accounting objects configured for collection per
NFM-P server stations 15-minute interval

Collocated configuration Distributed configuration

6 50 000 100 000

8 or greater 100 000 200 000

Table 5-17 Maximum number of application assurance accounting objects configured for
collection by an NFM-P statistics auxiliary

Number of active Maximum number of application assurance accounting objects configured for collection per
auxiliary statistics 15-minute interval
collectors
Statistics collection with NFM-P database Statistics Statistics
collection with collection with
single auxiliary three+ auxiliary
database database cluster

8 CPU Cores, 32 GB RAM 12 CPU cores, 32 8 CPU cores, 32 12 CPU cores, 32

GB RAM GB RAM GB RAM

1 5 000 000 7 500 000 1 000 000 5 000 000

2 5 000 000 15 000 000 1 000 000 10 000 000

3 5 000 000 15 000 000 1 000 000 20 000 000

In situations where NFM-P is asked to collect more application assurance accounting records than
it can process in the specified retrieval period, the extra statistics will not be retrieved from the
network.

5.7.8 Exporting performance and accounting statistics records

There are two methods to export accounting and performance statistics from NFM-
P; registerLogToFile, and findToFile. The registerLogToFile method is the preferred method and is
required for situations where more than 400 000 accounting statistics records are retrieved in 15
minutes or 500 000 performance statistics are retrieved in 15 minutes. This recommendation also
minimizes collection latency and reduces system load.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
100 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scaling guidelines for statistics collection

5.7.9 NFM-P database hardware platform requirements

To collect large numbers of statistics using the NFM-P database, there are RAM and storage I/O
requirements for the NFM-P database station. The table below highlights these requirements.

Table 5-18 NFM-P database station hardware requirements for a distributed configuration

Maximum number of simultaneous statistics records per 15-minute interval NFM-P Requires the following NFM-P
auxiliary database station setup
Accounting statistics Application assurance Performance statistics statistics
records accounting objects configured records collec-
for collection tor(s)

400 000 0 0 No 4 CPU cores, minimum

2.0GHz 1
0 200 000 0
4 disks (RAID 0)
0 0 150 000 32 GB RAM

800 000 0 0 Yes 4 CPU cores, minimum

2.0GHz 1
0 400 000 0
4 disks (RAID 0)
0 0 200 000 48 GB RAM

10 000 000 0 500 000 Yes 8 CPU cores, minimum

2.0GHz 1
0 5 000 000 500 000 6 disks (RAID 0)
64 GB RAM

10 000 000 5 000 000 2 000 000 Yes 12 CPU cores, minimum
2.0GHz 1
0 15 000 000 0 6 disks (RAID 0)
64 GB RAM

Notes:
1. 2.0GHz only supported on Skylake and newer CPU microarchitecture. Minimum speed on CPUs older than
Skylake is 2.4GHz

5.7.10 Simultaneous collection of performance, application assurance accounting

and accounting statistics records
NFM-P can collect performance, application assurance, and accounting statistics records
simultaneously. However, it is important to consider that enabling the collection of one type of
statistics will reduce the capability of NFM-P to collect and process the other type of statistics. It is
therefore not possible to achieve the maximum stated limits for performance, application
assurance, and accounting statistics records simultaneously, in certain configurations. Table 5-18,
“NFM-P database station hardware requirements for a distributed configuration” (p. 101) shows an
example of simultaneous collection.

5.7.11 Determining the number of performance and accounting statistics records

being collected by NFM-P
To ensure the number of performance and accounting statistics records that NFM-P is asked to
collect and process every 15 minutes remains below the stated scalability guidelines, it is important

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 101
Scaling and performance NSP
Scaling guidelines for scheduled tests (STM)

to carefully assess the impact of creating and assigning statistics policies. Review the number of
objects that are assigned to statistics policies and ensure the polling and retrieval periods are set
such that the numbers will remain below the stated guidelines.
Using NFM-P server performance statistics, NFM-P can assist in determining how many polled and
accounting statistics are being collected.
NFM-P performance can be adversely affected by increasing the number of historical statistics
entries recorded by the NFM-P. NFM-P system impacts include increased time listing log records
from the GUI and XML API clients, increased database space, and increased database backups
times.

5.7.12 Statistics record retention

The table below shows the different retention rates that are achievable depending upon the
collection rate and statistic type.

Table 5-19 Maximum statistics interval retention - NFM-P database

Statistics type Total number of statistics Maximum number of

records to be stored in the retention intervals
database

Performance <40M 672

>40M 96

Accounting <40M 672

>40M 16

Table 5-20 Maximum statistics interval retention - auxiliary database

Statistics type Maximum number of retention intervals

Performance 35,040

Accounting 35,040

When using the logToFile method only, for collection, the maximum retention of data on the file
system is 600 minutes (10 hours).

5.8 Scaling guidelines for scheduled tests (STM)

5.8.1 Scheduled tests (STM)
NFM-P provides the ability to generate, manage and schedule STM tests within the network. This
section provides guidelines that can be used to determine the extent to which STM tests can be
scheduled and launched within a network.
There are a number of factors which will influence NFM-P’s ability to concurrently manage and
schedule a large number of tests. NFM-P keeps track of how many tests are running concurrently.
This is to limit the initiation of the tests, and the processing of the results without interfering with the
system’s other functions.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
102 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scaling guidelines for scheduled tests (STM)

To understand the STM guidelines, the following terminology is required:

Elemental Test: An OAM test to be sent to a router such as an LSP ping
Elemental Test Result: An OAM test result received from a network element
Accounting file Test: An OAM test that is initiated in the default manner, however, the test results
are retrieved from the network element via FTP on a periodic basis.
Test Policy: A definition or configuration that tells NFM-P the specifics about how to generate a test.
A test policy can contain multiple test definitions. The policies are used by test suites.
Test Suite: A collection of elemental tests that can be assigned to a specific schedule. There are
three defined sections in which tests can be placed within a test suite: First run, Generated and
Last run. The tests are executed in order by these sections. It is possible to configure the execution
order of tests within the First Run and Last Run sections to be parallel or sequential. The tests in
the Generated position are run by the system as concurrently as possible. If the Generated section
contains tests from several different test definitions, then all the tests belonging to one definition will
be executed before the tests of the next definition begin. Within a definition, the system will attempt
to execute the tests as concurrently as possible. This is important to note, as a test suite containing
a large number of tests in the Generated section (or in the First Run/Last Run sections set to
parallel) may tax the system. Part of the increased stress placed on the system by concurrent tests
is a result of the need for the system to use greater amounts of resources in order to initiate, wait
for and process many tests concurrently. As well, tests that result in a large amount data to be
returned from the routers will place increased demands on the NFM-P.
Schedule: A start time that can have a test suite or test suites assigned to it to produce scheduled
tasks. When the schedule's start time is reached, the suite or suites assigned to it will commence.
The schedule may be set to continuously repeat after a configurable period of time.
Scheduled Task: An instance of a test suite assigned to a schedule
Non -NE Schedulable STM Tests: NFM-P provides the ability to execute and process results for
non NE schedulable tests. Non NE schedulable tests are elemental tests which are not persistently
defined on network elements; rather, these tests are defined/configured from NFM-P per test
execution. Elemental test results from non-NE schedulable tests are always regular (SNMP
mediated) and share the same scale limits/considerations as regular scheduled STM tests.

Table 5-21 Maximum number of STM elemental test results

NFM-P platform Maximum regular STM Maximum accounting Maximum accounting

elemental test results file STM elemental test file STM elemental test
(SNMP mediated results in a 15–minute results in a 15–minute
schedulable/ non-NE period with results period using logToFile
schedulable) in a stored in the NFM-P only
15–minute period database or NFM-P
database and using
logToFile

Distributed NFM-P configuration with minimum 8 15 000 1 500 000 1 1 500 000 1
CPU Core NFM-P server

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 103
Scaling and performance NSP
Scaling guidelines for scheduled tests (STM)

Table 5-21 Maximum number of STM elemental test results (continued)

NFM-P platform Maximum regular STM Maximum accounting Maximum accounting

elemental test results file STM elemental test file STM elemental test
(SNMP mediated results in a 15–minute results in a 15–minute
schedulable/ non-NE period with results period using logToFile
schedulable) in a stored in the NFM-P only
15–minute period database or NFM-P
database and using
logToFile

Distributed NFM-P configuration 6000 22 500 60 000

NOTE: It may be possible to achieve higher
numbers depending on the NFM-P server activity
and hardware platform

Minimum Supported Collocated NFM-P 3000 1500 15 000

configuration
NOTE: It may be possible to achieve higher
numbers depending on the NFM-P server activity
and hardware platform

Notes:
1. may require a dedicated disk or striped disks for the xml_output partition

5.8.2 Guidelines for maximizing STM test execution

By default, NFM-P will only allow test suites with a combined weight of 80 000 to execute
concurrently. The test suite weights are identified in the NFM-P GUI’s Test Suites List window.
Running too many tests that start at the same time will cause the system to exceed the previously
mentioned limit, and the test will be skipped. Ensuring the successful execution of as many STM
tests as possible requires planning the schedules, the contents, and the configuration of the test
suites. The following guidelines will assist in maximizing the number of tests that can be executed
on your system:
• When configuring tests or test policies, do not configure more packets (probes) than necessary,
as they increase the weight of the test suite.
• Test suites with a smaller weight will typically complete more quickly, and allow other test suites
to execute concurrently. The weight of the test suite is determined by the number of tests in the
test suite, and the number of probes that are executed by each test. See Table 5-22, “OAM test
weight” (p. 105) for test weight per test type.
• Assign the time-out of the test suite in such a way that if one of the test results has not been
received it can be considered missed or failed without stopping other test suites from executing.
• Rather than scheduling a test suite to execute all tests on one network element, tests should be
executed on multiple network elements to allow for concurrent handling of the tests on the
network elements. This will allow the test suite results to be received from the network element
and processed by NFM-P more quickly freeing up available system weight more quickly.
• Rather than scheduling a test suite to run sequentially, consider duplicating the test suite and
running the test suites on alternating schedules. This allows each test suite time to complete or
time-out before the same test suite is executed again. Remember that this may cause double the
system weight to be consumed until the alternate test suite has completed.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
104 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
Scaling guidelines for scheduled tests (STM)

• Create test suites that contain less than 200 elemental tests. This way you can initiate the tests
at different times by assigning the test suites to different schedules thereby having greater
control over how many tests are initiated or in progress at any given time.
• Prioritize which tests you wish to perform by manually executing the test suite to determine how
long it will take in your network. Use that duration with some added buffer time to help determine
how much time to leave between schedules or repetitions of a schedule and how to configure
the test suite time-out.
• A test suite time-out needs to be configured to take effect before the same test suite is
scheduled to run again, or it will not execute if it does not complete before the time-out.
• NFM-P database backups can impact the performance of STM tests.

Table 5-22 OAM test weight

Test type Weight

Regular Elemental STM Test 10 per Test Packet

Accounting File Elemental STM Test 1

5.8.3 Accounting file STM test configuration

Accounting file collection of STM test results requires 7750 SR and 7450 ESS network elements
that are version 7.0 R4 and above. To take advantage of accounting file STM test execution, the
test policy must be configured to be NE schedulable with “Accounting file” selected. This will
produce STM tests that will be executed on the network element, while the test results are collected
by the NFM-P server by way of an accounting file in a similar way to accounting statistics.
Accounting file STM test results are collected by the NFM-P server only.
NFM-P supports the use of logToFile for file accounting STM results. When using this method only
for results, the number of tests that can be executed per 15 minute interval is increased. See Table
5-21, “Maximum number of STM elemental test results” (p. 103) for specific scaling limits. The
logToFile method for file accounting STM results supports a maximum of two JMS clients.

5.8.4 Examples of STM test configuration

The following examples describe the configuration of STM tests on different network configurations.

5.8.5 Example 1

Assume there is a network with 400 LSPs and that the objective is to perform LSP pings on each
LSP as frequently as possible. The following steps are to be followed:
1. Create 4 test suites each containing 100 elemental LSP ping tests
2. One at a time, execute each test suite and record the time each one took to complete. Assume
that the longest time for executing one of the test suites is 5 minutes.
3. Create a schedule that is ongoing and has a frequency of 15 minutes. This doubles the time
taken for the longest test suite and ensures that the test will complete before it is executed
again. Assign this schedule to the 4 test suites.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 105
Scaling and performance NSP
Scaling guidelines for scheduled tests (STM)

4. Monitor the test suite results to ensure that they are completing. If the tests are not completing
(for example getting marked as “skipped”), then increase the frequency time value of the
schedule.
5. In the above case, there are 200 elemental tests configured to be executed each 10 minutes.

5.8.6 Example 2
Assume there are eight test suites (T1, T2, T3, T4, T5, T6, T7 and T8), each containing 50
elemental tests. Assume the test suites individually take 5 minutes to run. Also, assume the
objective is to schedule them so that the guideline of having less than 200 concurrently running
elemental tests is respected.

The recommended approach for scheduling these tests suites is as follows:

• Test suites T1, T2, T3, T4 can be scheduled on the hour and repeat every 10 minutes
• Test suites T5, T6, T7, T8 can be scheduled on the hour + 5 minutes and repeated every 10
minutes
This will ensure no more than 200 elemental tests are scheduled to run concurrently.

5.8.7 Factors impacting the number of elemental tests that can be executed in a
given time frame

The following factors can impact the number of elemental tests that can be executed during a given
time frame:
• The type of tests being executed. Each type of elemental test takes varying quantities of time to
complete (for example, a simple LSP ping of an LSP that spans only two routers may take less
than 2 seconds; an MTU ping could take many minutes).
• The amount of data that is generated/updated by the test within the network elements. NFM-P
will have to obtain this information and store it in the NFM-P database. The quantity of data
depends on the type of tests being performed and the configuration of the objects on which the
tests are performed.
• The number of test suites scheduled at or around the same time
• The number of tests in a test suite
• The number of routers over which the tests are being executed; in general, a large number of
tests on a single router can be expected to take longer than the same number of tests distributed
over many routers.
• An NFM-P database backup may temporarily reduce the system’s ability to write test results into
the database.
• The station used to perform the tests will dictate how many physical resources NFM-P can
dedicate to executing elemental tests. On the minimum supported station (collocated NFM-P
server and NFM-P database on a single server), the number of concurrent tests must be limited
to 3 000.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
106 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
cflowd statistics collection

5.8.8 Possible consequences of exceeding the capacity of the system to perform

tests
NFM-P will exhibit the following symptoms if the number of scheduled tests exceeds the system’s
capacity.

5.8.9 Skipped tests

If a test suite is still in progress at the time that its schedule triggers again, then that scheduled task
will be marked as skipped and that test suite will not be attempted again until the next scheduled
time.

5.8.10 Failed tests (time-out)

Tests may time-out and get marked as failed. If any of the tests take more than 15 minutes it may
get purged from an internal current test list. For example, a test may be successfully sent to a
router and the system does not receive any results for 15 minutes. The system marks the test as
failed and purges its’ expectation of receiving a result. However, later, the system could still receive
the results from the router and update its result for the test to success.

5.8.11 Disk space requirements for STM test results

STM test results are stored in the tablespace DB partition. The STM database partitions start with a
total size of 300MB of disk space. When the maximum number of test results is configured at
20 000 000 (maximum), the disk space requirement for the STM tests may increase by up to 80
GB. A larger tablespace partition should be considered.
The maximum number of test results stored in the database reflects the sum of the aggregate
results, test results, and probe results.
Running 10 tests with 1 probe each versus 1 test with 10 probes consumes the same amount of
disk space.
When using logToFile for accounting file STM test results, the maximum time-to-live on the disk is
24 hours. At the maximum collection rate of 1 500 000 test results per 15 minutes, the storage
requirements on the NFM-P server in the xml_output directory is 600 GB per JMS client. The
storage requirements are doubled if using the maximum number of JMS clients for file accounting
STM results. The disk storage requirements can be decreased by using the compress option for
logToFile but will result in increased CPU utilization on the NFM-P server.

5.9 cflowd statistics collection

5.9.1 Scaling guidelines for cflowd statistics collection
The table below shows the scaling limits for an NSP Flow Collector in its ability to process cflowd
flow records from the network and produce IPDR formatted files. The guidelines are divided into the
NSP Flow Collector collecting in a residential/mobile deployment and the NSP Flow Collector
collecting in a business deployment.
For residential and mobile deployments, the only statistics types that should be in use are Volume,
Comprehensive, Unknown and corresponding Special Study types. TCP and RTP are not
supported in mobile, and although the statistics types are available for Residential deployments, the

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 107
Scaling and performance NSP
cflowd statistics collection

use case is not, and there are no reports for this data. Additionally, even for residential, the only
reports available are for Comprehensive. Comprehensive statistics have a fixed 60min aggregation
interval. Due to the amount of data generated in a mobile deployment, Volume statistics require an
aggregation interval of 60 minutes. As an alternative, Volume Special Study statistics on specific
subscribers can be used. The only key factor of difference is whether or not additional counters are
enabled for Comprehensive statistics.

Table 5-23 cflowd statistics scaling limits for residential and mobile deployments

NSP Flow Collector Counter selection 1 Maximum number of unique Packet loss per hour 3

processing rate in flows per objects in memory 2

second

100 000 FPS Default two counters 100M Objects <= 2%

All counters 60M Objects <= 1%

Notes:
1. Default: two counters. Volume: total bytes/total packets. Comp-volume: total bytes StoC/CtoS sum unknown.
Only one counter exists. Vol SS: should be minuscule. All counters: Comp-volume has a total of ten counters
that can be enabled.
2. Number of aggregated output requests that are sent to the server every 60 minutes. Assumes transfer has
sufficient bandwidth to complete in a timely manner.
3. Packet loss may increase if communication between the NSP Flow Collector and target file server is
interrupted.
For business deployments, in addition to the statistics types with a small number of records;
Comprehensive, Volume, Unknown, and Volume Special Study, there are also statistics types with a
larger number of records; TCP Performance, and RTP (Voice/Audio/Video). The main distinction is
whether or not the TCP/RTP statistics types use the default enabled counters, or if all counters
have been enabled. Enabling all of the TCP/RTP counters increases the amount of memory used
by the NSP Flow Collector. Aside from the incoming FPS (Flows Per Second) that the NSP Flow
Collector can process, the other main factor putting pressure on the NSP Flow Collector is the
memory used by the number of unique objects/records (or unique routes, that is the # of output
records the NSP Flow Collector produces in the IPDR files) in NSP Flow Collector memory at any
one time. And finally the interval size – the smaller the aggregation interval, the greater percentage
of the next interval time will overlap with the transfer time of the previous interval – during this time
the NSP Flow Collector must store objects in memory from two different intervals. Comprehensive
statistics types are fixed at 60 minute intervals.
A unique object/route for TCP/Volume records in the business context is:
SAP, App/AppGroup, Interval ID, Src Group ID, Source Interface ID, Dest Group ID, Dest Interface
ID
A Volume record will also have a direction field. Volume records coming from the router to the NSP
Flow Collector will result in two output records in the IPDR files (one for each direction). For TCP,
two incoming records from the NSP Flow Collector (one for each direction) will be combined by the
NSP Flow Collector into a single output TCP record in the IPDR files.
A unique object/route for COMPREHENSIVE record in the business context is:

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
108 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
PCMD collection

SAP, App/AppGroup, Interval ID, Src Group ID, Source Interface ID, Dest Group ID, Dest Interface
ID
and either a hostname field, or three device identification fields.
A unique object/route for RTP is defined as:
Every single flow into the NSP Flow Collector is a unique route and an equal number of flow
records are produced in the IPDR file. The expected number of RTP records sent from 7750 SR
Routers is expected to be a small percentage of the total flows (for example, <5% total flows TCP/
VOL/RTP)

Table 5-24 cflowd statistics scaling limits for business deployments

3
NSP Flow Collector Statistic types used and counters Maximum number of unique Packet loss per hour
processing rate in flows per used 1 objects in memory 2
second

100 000 FPS Comprehensive/Volume/ Unknown/Vol 60M objects <= 1%

S.S Only All Counters

TCP/TCP S.S Only: Default Counter 25M objects <= 1%

TCP/TCP S.S Only: All Counters 15M objects <= 1%

RTP Only: Default Counters 10M objects <= 1%

RTP Only: All Counters 3M objects <= 1%

Combined Comprehensive/Volume/ 20M Comp/Volume/ <= 1%

Unknown/TCP/RTP (including Special Unknown + 5M TCP (All Cnt)
Study) + 0.5 RTP (All Cnt)

Notes:
1. Comprehensive/Volume/ Unknown/Volume SS: All Counters RTP/TCP/TCP S.S Counter Selection Default
Counters: Leaving default enabled counters on All Counters: Enabling all available counters for given stat
type. There are 40-60 total counters available for TCP and RTP types.
2. Number of aggregated output requisitions that are sent to the server every 60 seconds. Assumes transfer
has sufficient bandwidth to complete in a timely manner.
3. Packet loss may increase if communication between the NSP Flow Collector and target file server is
interrupted

5.10 PCMD collection

5.10.1 Scaling guidelines for PCMD collection
LTE management networks support the collection of per call measurement data (PCMD) from
SGW, PGW, and ePDG network elements when using the NFM-P auxiliary PCMD collector. A single
NFM-P auxiliary PCMD collector can process up to 18 million records per minute where multiple
auxiliary PCMD collectors can be deployed to increase overall scaling limits. The scaling limits for a
single auxiliary PCMD collector represents approximately 10M Bearers.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 109
Scaling and performance NSP
CPAM and vCPAA

5.11 CPAM and vCPAA

5.11.1 Scaling guidelines for CPAM and vCPAA
The following section outlines the tested limits for the CPAM component of NFM-P.

Note: All CPAAs monitoring a contiguous network must belong to the same administrative
domain.
The scalability of 7701 CPAA Hardware revision 2 and vCPAA is described in the following table.

Table 5-25 7701 CPAA Hardware revision 2 and vCPAA scalability

Item description NFM-P 22.6

Maximum Number of Routers Supported with both IGP and BGP 500
turned-on in the same 7701 CPAA (larger node count must use two
separate 7701 CPAAs for IGP and BGP) with 2 200 000 BGP combined
routes

Maximum Number of IGP Routers per 7701 CPAA if BGP is deployed on 700
separate 7701 CPAA
(routers can all be in one or multiple areas and count includes Nokia
P/PE & 3rd party routers)

Maximum Number of OSPF Domains/Areas per 7701 CPAA One Administrative Domain per 7701 CPAA
Up to 50 areas per 7701 CPAA

Maximum Number of ISIS regions/area IDs per 7701 CPAA One Administrative Domain per 7701 CPAA
Up to 32 L1s + L2 per 7701 CPAA

Maximum Number of iBGP Peers mesh/RR 170

BGP/ MP-BGP Route Count 4 000 000 combined

Maximum Number of IPv4/VPN IPv4 Monitored Prefixes (combined) 2000 configured

2000 monitored

Maximum number of Sub-ASes 1

BGP stats 48 000/5 minutes

144 000/15 minutes

IP (LDP LSP, GRE, IP) Path Monitor – Configured 20 000

The scalability of CPAM is described in the following table.

Table 5-26 CPAM scalability

Item description NFM-P 22.6

Maximum number of routers per admin domain 4000

Maximum Active 7701 CPAAs 40

Maximum Number of IGP Routers 12 000

Maximum Number of OSPF Domains/Areas 150

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
110 3HE-18161-AAAB-TQZZA Issue 1
Scaling and performance NSP
CPAM and vCPAA

Table 5-26 CPAM scalability (continued)

Item description NFM-P 22.6

Maximum Number of ISIS regions/area IDs 50

Maximum Number of BGP/MP-BGP Routes 4 000 000 combined

Maximum number of Sub-ASes 40

BGP stats 48 000/5 minutes

144 000/15 minutes

Combined IP and LSP path monitors configured The numbers below can be combined
(60 000)

RSVP LSP Path Monitored – Configured 60 000

IP (LDP LSP, GRE, IP) Path Monitor – Configured 20 000

Recommended LSP Path monitor statistics polling interval 15 min

Maximum NFM-P database space allocated for IGP Checkpoints 10 GB

Maximum number of supported paths (IP / LSP) that can be imported into 20 000
Simulated Impact Analysis simultaneously

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 111
Scaling and performance NSP
CPAM and vCPAA

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
112 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
Introduction

6 Security

6.1 Introduction
6.1.1 Overview
This chapter provides general information about platform security for a deployment of NSP and
NFM-P. Recommendations in this section apply to NSP and its optional components except where
indicated.
The NSP implements a number of safeguards to ensure the protection of private data. Additional
information can be found in the NSP Data Privacy section of the NSP System Architecture Guide.

6.2 Securing the NSP

6.2.1 Overview

Nokia recommends performing the following steps to achieve station security for the NSP:
• Install the latest recommended patch cluster from Red Hat (not supported on RHEL OS images)
• NSP has no ingress or egress requirements to access the public internet and should be isolated
with properly configured firewalls.
• Implement firewall rules to control access to ports on NSP systems, as detailed in this section
• Use SSL certificates with strong hashing algorithms.
• Enforce minimum password requirements and password renewal policies on user accounts that
access the NSP applications.
• Configure a warning message in the Launchpad Security Statement.
• Configure login throttling to prevent denial of service attacks (see NSP Installation and Upgrade
Guide).
• Configure maximum session limits for administrators and users (see NSP Installation and
Upgrade Guide).
• Configure user lockout after a threshold of consecutive failed login attempts (see NSP
Installation and Upgrade Guide).
• When using custom TLS certificates for NSP deployment, ensure that the server private key file
is protected when not in use by nsp configurator.
• Optional: Revoke world permission on compiler executables (see NSP Installation and Upgrade
Guide).
See the NSP System Architecture Guide for NSP RHEL OS compliance with CIS Benchmarks. The
supported CIS Benchmark best practices are already implemented on NSP RHEL OS images.

6.2.2 TLS communications

Communications of the NSP is secured using TLS. The NSP supports TLS version TLSv1.2.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 113
Security NSP
Operating system security for NSP stations

The NSP supports the use of custom TLS certificates for client communications with NSP
applications. Internal communications between NSP components can be secured with the use of a
PKI server which can create, sign and distribute certificates. The NSP cluster software package
provides a PKI server that can be used to simplify the TLS certificate distribution to NSP
components.
A NSP cluster will check the expiry date of TLS certificates every 24h and raise an alarm in the
Fault Management application if the certificate is expired or nearing expiry. See the NSP System
Administrator Guide for further information.
See the NSP Installation and Upgrade Guide for instructions on the configuration of custom TLS
certificates and the provided PKI server application.

6.3 Operating system security for NSP stations

6.3.1 RHEL patches
Nokia supports customers applying RHEL patches provided by Red Hat which include security fixes
as well as functional fixes. If a patch is found to be incompatible with the NSP, the patch may need
to be removed until a solution to the incompatibility is provided by Red Hat or Nokia. See the NSP
Release Notice for up-to-date information about the recommended RHEL maintenance update and
patch levels.
Operating system patches of NSP RHEL OS images must be obtained from the NSP product group.

6.3.2 Platform hardening

Additional efforts to secure the system could impact NSP operation or future upgrades of the
product. Customers must perform some level of basic testing to validate additional platform
hardening does not impact the operation of the NSP. The NSP Product Group makes no
commitment to make the NSP compatible with a customer's hardening requirements.

6.4 Communication between the NSP and external systems

6.4.1 Overview
The following diagrams illustrate the various components of the NSP and its internal
communications, as well as communications with external systems.
The following figure shows a standalone NSP deployment and its communications with external
systems.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
114 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
Communication between the NSP and external systems

Figure 6-1 Standalone NSP deployment

GUI/REST
client

NSP cluster

remote
Tomcat Kafka Zookeeper 11 authentication
server

email
12 server

Neo4J nsp- PostgreSQL syslog

Database tomcat Database 9 server

external
10 controller

MDM nrcx- WFM

tomcat

2 4 5 7

3 6 8

NFM-P IP NEs vSR-NRC NRC-T/NFM-T Optical NEs

27697

Connection Usage
1 Web Client/REST API client connections.
REST over HTTPS secured with TLS
2 SSO authentication (secure), zookeeper
registration (secure), neo4j database
(non-secure), kafka (secure), NFM-P API
(secure), Data connection – CPROTO protocol
secured with TLS
3 NE mediation using SNMP and FTP/SCP
4 NE mediation using gRPC/gNMI, SNMP,
NETCONF, SSH
5 Data connection – CPROTO (non-secure)
6 BGP (supports GTSM), PCEP (secured by
TLS), OpenFlow communications (secured by
TLS) * Note

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 115
Security NSP
NSP Port Communications

Connection Usage
7 SSO authentication (secure), zookeeper
registration (secure), REST over HTTPS
secured with TLS, proprietary HTTP with
NFM-T
8 NE mediation with SNMP and TL-1
9 SSO authentication (secure), zookeeper
registration (secure), kafka (secure),
PostgreSQL (secure), gRPC (secure), REST
over HTTPS secured with TLS
10 syslog notifications secured with TLS
11 Mediator communications with external
controller, REST/RESTCONF secured with
TLS
12 SMTP, SMTPS, STARTTLS communication
with email server
13 LDAP, RADIUS, TACACS communications
with remote authentication servers

Note: VSR-NRC supports secure PCEP and OpenFlow communications in specific releases.
See the SR OS documentation for details.

6.5 NSP Port Communications

6.5.1 Overview
This section will document network communications between components in a NSP deployment.
These tables can be used by customers to design firewall rules based on their NSP deployment.
A complete listing of network communications for NFM-P and associated components can be found
in section 6.11 of this guide.

Following are the port changes for NSP in Release 22.6:

• Remove NSP cluster ports 5601 and 8555
• Updated ports 5433 and 7299-7309

Table notes:
• Each table identifies network communications based on the destination component.
• Each communication link defines traffic from the originating component and port to the
destination component and port. When firewall rules are applied in both directions of
communication, the return path must also be permitted.
• In a multi-node NSP cluster deployment, communications originating from NSP to a destination

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
116 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NSP Port Communications

must allow a firewall rule for each node of that NSP cluster to the destination component. Traffic
destined to a multi-node NSP cluster will require a firewall rule for the virtual IP address of the
NSP cluster.
• For NSP deployments with multiple network interfaces, the communications matrix will define on
which network interface the communications will be received.
• Where multiple components may be communicating with a destination component and port,
each source component with source port range is listed.
• A system administrator will require SSH access to components in the NSP deployment for
installation and maintenance purposes. For this purpose, tables will list a source component of
System administration server.
• Any ports that are optional, or are required only for unsecure communications, are identified at
the bottom of each table.

Note: The ephemeral port range of different server types may vary. Many Linux kernels use
the port range 32768 - 61000. To determine the ephemeral port range of a server, execute
cat /proc/sys/net/ipv4/ip_local_port_range

Note: Some NSP operations require idle TCP ports to remain open for long periods of time.
Therefore, a customer firewall that closes idle TCP connections should adjust OS TCP keep-
alives to ensure that the firewall will not close sockets that are in use by the NSP.

Note: The use of firewalld is not supported on NSP cluster virtual machines. Nokia
recommends using Calico policies to control traffic to an NSP cluster deployment. (Kubernetes
networking relies on calico rules added to iptables. Using firewalld changes the order of those
calico rules and can disrupt traffic flow in the NSP cluster.)

Table 6-1 NSP Kubernetes virtual machine communications

Source Source Port NSP Trans- Net- Description/Purpose

component(s) Desti- port work
nation Proto- Inter-
Port col face
System any 22 TCP any Administrator SSH
administration access, software
server installation
remote DR NSP >32768
cluster
Network element any 162 UDP me- SNMP traps
dia-
tion

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 117
Security NSP
NSP Port Communications

Table 6-1 NSP Kubernetes virtual machine communications (continued)

Source Source Port NSP Trans- Net- Description/Purpose

component(s) Desti- port work
nation Proto- Inter-
Port col face
browser/OSS any 443 TCP client, HTTPS
clients inter- communications for
nal Launchpad, REST API,
Analytics, >32768
session management
redundant NSP,
Simulation Tool
NFM-P, NFM-P >15000
Auxiliary
NFM-T >49192
Analytics >32768 2281 TCP inter- Secure Zookeeper
nal communications
NFM-P, NFM-P >15000
Auxiliary
NFM-T >49192
Analytics >32768 2391 TCP inter- NSP PKI server
nal
NFM-P >15000
NFM-T >49192
remote DR NSP >32768 5000, TCP inter- nspos-neo4j (DR only)
cluster 5001 nal
remote DR NSP >32768 5002 TCP inter- nspos-neo4j (HA/DR
cluster nal only)
remote DR NSP >32768 5100, TCP inter- nsp-tomcat neo4j (DR
cluster 5101 nal only)
remote DR NSP >32768 5102 TCP inter- nsp-tomcat neo4j
cluster nal (HA/DR only)
remote DR NSP >32768 5200, TCP inter- nrcx-tomcat neo4j (DR
cluster 5201 nal only)
remote DR NSP >32768 5202 TCP inter- nrcx-tomcat neo4j
cluster nal (HA/DR only)
remote DR NSP >32768 6000, TCP inter- nspos-neo4j (DR only)
cluster 6001 nal
remote DR NSP >32768 6002 TCP inter- nspos-neo4j (HA/DR
cluster nal only)

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
118 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NSP Port Communications

Table 6-1 NSP Kubernetes virtual machine communications (continued)

Source Source Port NSP Trans- Net- Description/Purpose

component(s) Desti- port work
nation Proto- Inter-
Port col face
remote DR NSP >32768 6100, TCP inter- nsp-tomcat neo4j (DR
cluster 6101 nal only)
remote DR NSP >32768 6102 TCP inter- nsp-tomcat neo4j
cluster nal (HA/DR only)
remote DR NSP >32768 6200, TCP inter- nrcx-tomcat neo4j (DR
cluster 6201 nal only)
remote DR NSP >32768 6202 TCP inter- nrcx-tomcat neo4j
cluster nal (HA/DR only)
Analytics, >32768 6432 TCP inter- Postgres database
redundant NSP nal
NFM-P >15000
NFM-T >49192
remote DR NSP >32768 7000, TCP inter- nspos-neo4j (DR only)
cluster 7001 nal
remote DR NSP >32768 7002 TCP inter- nspos-neo4j (HA/DR
cluster nal only)
remote DR NSP >32768 7100, TCP inter- nsp-tomcat neo4j (DR
cluster 7101 nal only)
remote DR NSP >32768 7102 TCP inter- nsp-tomcat neo4j
cluster nal (HA/DR only)
remote DR NSP >32768 7200, TCP inter- nrcx-tomcat neo4j (DR
cluster 7201 nal only)
remote DR NSP >32768 7202 TCP inter- nrcx-tomcat neo4j
cluster nal (HA/DR only)
NetAct NEs >32768 7443 TCP me- REST event forwarder
dia- for NetAct NEs
tion
remote DR NSP >32768 8001 TCP inter- NSP Role Manager (DR
cluster nal only)
browser/OSS any 8182 TCP client HTTPS port for
clients Analytics
external controller any 8185 TCP inter- REST trap forwarder
nal port

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 119
Security NSP
NSP Port Communications

Table 6-1 NSP Kubernetes virtual machine communications (continued)

Source Source Port NSP Trans- Net- Description/Purpose

component(s) Desti- port work
nation Proto- Inter-
Port col face
browser/OSS any 8543 TCP client nsp-tomcat GUI and
clients REST API
Simulation Tool >32768
browser/OSS any 8544 TCP client app1-tomcat
clients applications
Analytics >32768
NFM-P >15000
browser/OSS any 8545 TCP client MDM applications
clients
browser/OSS any 8546 TCP client WFM GUI and REST
clients API
browser/OSS any 8547 TCP client mdtTomcat
clients
browser/OSS any 8548 TCP client mdmTomcat
clients
browser/OSS any 8549 TCP client TSC application
clients
browser/OSS any 8560 TCP client nrcx-tomcat GUI and
clients REST API
browser/OSS any 8565 TCP client file service SFTP
clients
remote DR NSP >32768 8566 TCP inter- File synchronization
cluster nal with redundant NSP
NE any 8567 TCP me- File transfer with Nokia
dia- NEs.
tion
NFM-P >15000 8575 TCP inter- system token for
nal components external to
NSP

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
120 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NSP Port Communications

Table 6-1 NSP Kubernetes virtual machine communications (continued)

Source Source Port NSP Trans- Net- Description/Purpose

component(s) Desti- port work
nation Proto- Inter-
Port col face
browser/OSS any 9192 TCP client, Kafka
clients inter-
nal
Analytics >32768
NFM-P, NFM-P >15000
Auxiliary
browser/OSS any 9193, TCP client, Kafka - enhanced NSP
clients 9194 inter- only
nal
Analytics >32768
NFM-P, NFM-P >15000
Auxiliary
Analytics >32768 9292 TCP inter- Kafka
nal
NFM-P, NFM-P >15000
Auxiliary
NFM-T >49192
Analytics >32768 9293, TCP inter- Kafka - enhanced NSP
9294 nal only
NFM-P, NFM-P >15000
Auxiliary
NFM-T >49192
browser/OSS any 9543 TCP client Simulation Tool GUI
clients (only for Simulation Tool
deployment)
browser/OSS any 80 TCP client Redirects to 443 - use
clients only where required
Analytics >32768 2181 TCP inter- unsecure Zookeeper -
nal use only where required
NFM-P, NFM-P >15000
Auxiliary
NFM-T >49192

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 121
Security NSP
NSP Port Communications

Table 6-1 NSP Kubernetes virtual machine communications (continued)

Source Source Port NSP Trans- Net- Description/Purpose

component(s) Desti- port work
nation Proto- Inter-
Port col face
browser/OSS any 9092 TCP client, unsecure Kafka - use
clients inter- only where required
nal
Analytics >32768
NFM-P, NFM-P >15000
Auxiliary
NFM-T >49192
browser/OSS any 9093, TCP client, unsecure Kafka
clients 9094 inter- (enhanced deployment
nal only) - use only where
Analytics >32768
required
NFM-P, NFM-P >15000
Auxiliary
NFM-T >49192

Table 6-2 Network Element Communications

Source Source NE Transport Description

component port Destina- Protocol
tion Port
System any 22 TCP Administrator SSH access, SFTP
administration
server
NSP kubernetes >32768
VM
NSP kubernetes >32768 161 UDP SNMP mediation
VM
NSP kubernetes >32768 830 TCP NETCONF mediation
VM
NSP kubernetes >32768 57400 TCP gRPC
VM
NSP kubernetes >32768 21 TCP telnet, FTP access - use only where
VM required

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
122 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NSP Port Communications

Table 6-3 VSR-NRC Communications

Source Source VSR-NRC Transport Description

component port Destina- Protocol
tion Port
NSP kubernetes >32768 4199 TCP Network topology information, service
VM management

Refer to section 6.11 of this guide for a complete list of firewall rules for NFM-P and associated
components.

Table 6-4 NFM-P Main Server Communications

Source Source NFM-P Transport Network Description

component port Destina- Protocol Interface
tion Port
NSP >32768 7879 TCP internal CPROTO port
kubernetes
VM
NSP >32768 8087 TCP client web applications
kubernetes communications
VM
NSP >32768 8089 TCP client web applications
kubernetes communications
VM
NSP >32768 8443 TCP client XML API
kubernetes
VM
NSP >32768 8543 TCP client NFM-P web applications,
kubernetes REST API
VM

Table 6-5 Analytics Server Communications

Source Source Analytics Transport Network Description

Component Port Destina- Protocol Interface
tion Port
NSP >32768 8080 TCP internal HTTP web user interface
kubernetes
VM
NSP >32768 8443 TCP internal HTTPS web user interface
kubernetes
VM

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 123
Security NSP
NSP Port Communications

Table 6-6 Auxiliary Database Server Communications

Source Source AuxDB Transport Network Description

Component Port Destina- Protocol Interface
tion Port
NSP >32768 5433 TCP internal
kubernetes
VM
NSP >32768 7299 TCP internal
kubernetes (secure=
VM true)
7299-
7309
(secure=
false)

Refer to NFM-T documentation for a complete list of NFM-T application communications.

Table 6-7 NFM-T Communications

Source Source NFM-T Transport Network Description

Component Port Destina- Protocol Interface
tion Port
NSP >32768 443 TCP client
kubernetes
VM
NSP >32768 8443 TCP client GUI
kubernetes
VM
NSP >32768 8543 TCP client NRC-T REST API
kubernetes
VM

Table 6-8 Syslog Server Communications

Source Source Destina- Destina- Transport Description

Component Port tion tion Port Protocol
Compo-
nent
NSP >32768 Syslog 514 TCP syslog notifications
kubernetes server
VM

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
124 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NSP Kubernetes Platform Communications

Table 6-9 Mail Server Communications

Source Source Destina- Destina- Transport Description

Component Port tion tion Port Protocol
Compo-
nent
NSP >32768 Mail 25 TCP SMTP mail server
kubernetes Server (unsecure)
VM
NSP >32768 Mail 465 TCP SMTPS mail server (secure)
kubernetes Server
VM
NSP >32768 Mail 587 TCP STARTTLS mail server
kubernetes Server (secure)
VM

Table 6-10 Remote Authentication Server Communications

Source Source Destina- Destina- Transport Description

Component Port tion tion Port Protocol
Compo-
nent
NSP >32768 LDAP 389 TCP LDAP (unsecure)
kubernetes server
VM
NSP >32768 LDAP 636 TCP LDAP (secure)
kubernetes server
VM
NSP >32768 RADIUS 1812 TCP RADIUS
kubernetes server
VM
NSP >32768 TACACS 49 TCP TACACS
kubernetes server
VM

6.6 NSP Kubernetes Platform Communications

6.6.1 Overview
The tables provided in this section identify the listening ports on a deployer node and on worker
nodes for an NSP cluster deployment. These ports must be accessible between the deployer and
worker nodes within a NSP deployment. The SSH ports on all servers must be accessible by a
system administrator for installation and maintenance functions.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 125
Security NSP
NSP Kubernetes Platform Communications

Table 6-11 Ports used by deployer node

Default port(s) Type Application

22 TCP SSH
111 TCP rpcbind
443 TCP HTTPS
6443 TCP kubernetes API server
8443 TCP helm repo, docker registry
10250 TCP kubelet metrics
30000-32767 TCP kube proxy

Table 6-12 Ports used by worker nodes

Default Port(s) Type Application

22 TCP sshd
53 TCP node-cache
111 TCP rpcbind
179 TCP bird
2375 TCP dockerd
2379 TCP etcd
2380 TCP etcd
6443 TCP kubernetes API server
8081 TCP nginx
9100 TCP node exporter
9253 TCP node cache
9254 TCP node cache
9353 TCP node-cache
10250 TCP kubelet metrics
10251 TCP kube-scheduler
10256 TCP kube-proxy
10257 TCP kube controller
10259 TCP kube scheduler
30000-32767 TCP kube-proxy

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
126 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
Securing the NFM-P

6.7 Securing the NFM-P

6.7.1 Overview
Nokia recognizes the importance of deploying important software such as the NFM-P in secure
environments and, as such, supports the use of security techniques to enhance the security of the
NFM-P.
NFM-P communications is secured using TLS 1.2 by default, SNMPv3 and HTTPS. See the NSP
Installation and Upgrade Guide for configuration information.
NFM-P implements a number of safeguards to ensure protection of private data. Additional
information can be found in the Security section of the NSP Installation and Upgrade Guide.

Nokia recommends performing the following steps to achieving NFM-P station security:
• Install a clean operating system environment with the minimum required packages documented
in the NSP Installation and Upgrade Guide.
• Install the latest Recommended Patch Cluster from Red Hat (not supported on NSP RHEL OS
images)
• Harden the RHEL operating system installation based upon the CIS Benchmarks best practices.
Reference the NSP System Architecture Guide for the Recommendations and Compliance
statements. The supported CIS Benchmark best practices are already implemented on the NSP
RHEL OS images.
• If installing RHEL, disable the mDNS Service.
• Implement firewall rules for NFM-P to control access to ports on NFM-P platforms as described
in 6.7.5 “Deploying NFM-P with firewalls” (p. 129) . NFM-P systems have no ingress or egress
requirements to access the public internet and should be isolated with properly configured
firewalls.
• If installing RHEL, enable the RHEL firewall filter rules lists. See 6.10 “NFM-P firewall and NAT
rules” (p. 144) for more details
• Installation of NFM-P with a secure configuration described in 6.7.3 “Installing the NFM-P
components” (p. 128)
• Network element connection configuration as described in 6.7.4 “NFM-P network element
communication” (p. 128)
• Configure NFM-P to run at runlevel 3 as opposed to the default runlevel 5
• Update the supported TLS versions and ciphers to remove older versions, if not required
• Consider using a Certificate Authority signed certificate instead of self-signed certificates
• Use TLS certificates signed with stronger hashing algorithms
• Enable SELinux in permissive/enforcing mode for the components that support it
• Enable Federal Information Processing Standards (FIPS) security. Note that using FIPS and
SNMPv3 algorithms larger than SHA1/AES128 will add CPU load and NE response times may
be diminished.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 127
Security NSP
Securing the NFM-P

6.7.2 Operating system installation for NFM-P stations

Nokia supports customers applying RHEL or Windows patches provided by Red Hat or Microsoft
which include security and functional fixes. If a patch is found to be incompatible with NFM-P, the
patch may need to be removed until a solution to the incompatibility is provided by Red Hat,
Microsoft, or Nokia. See the NSP Release Notice for potential changes to the recommended RHEL
maintenance update and patch levels. Operating system patches of NSP RHEL OS images must
be obtained from the NSP product group.
NFM-P is supported on RHEL installed with the list of required RHEL Packages documented in the
NSP Installation and Upgrade Guide. SELinux is supported in permissive and enforcing mode on
the NFM-P server, NFM-P database, and NFM-P statistics auxiliary only. All other NSP components
support SELinux in permissive mode only.
Additional efforts to secure the system could impact NFM-P's operation or future upgrades of the
product. Customers should perform some level of basic testing to validate additional platform
hardening does not impact NFM-P's operation. The NFM-P Product Group makes no commitment
to make NFM-P compatible with a customer's hardening requirements.

6.7.3 Installing the NFM-P components

Nokia recommends performing the following steps when installing the NFM-P components:
• Configure the NFM-P server IP validation during the NFM-P database installation to ensure that
only the specified IP address can communicate with the NFM-P database. This is documented in
the NSP Installation and Upgrade Guide.
• Maintain secure communication between the NFM-P server and NFM-P clients (XML-API and
UI) as documented in the NSP Installation and Upgrade Guide. This is enabled by default.

Nokia also recommends the configuration (as documented in the NSP NFM-P User Guide) of the
following options to secure communication with the NFM-P client UI and the NFM-P client XML API
interfaces:
• Password history count
• Password expiry periods
• Client time-outs
• Security statements
• Scope of command and span of control
• Client IP validation

6.7.4 NFM-P network element communication

The following configurations are documented in the NSP NFM-P User Guide, and help secure
communication between the network elements and NFM-P server installations:
• SNMPv3
• SSH for remote access to the network elements
• SCP/SFTP for secure file transfer
• NETCONF

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
128 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
Securing the NFM-P

6.7.5 Deploying NFM-P with firewalls

A firewall can be deployed to protect the NFM-P server from the managed network and to protect
the server from the network hosting the NFM-P clients. The diagrams below illustrate this and show
the communications services that are required through the firewalls. Installations of NFM-P can
make use of the RHEL built in firewall using firewalld. Standalone Firewall products must not be
collocated on servers hosting NFM-P components. Only the built-in RHEL firewall used to enable
filter rules lists can be collocated with NFM-P components. See 6.10 “NFM-P firewall and NAT
rules” (p. 144) for more details.
Some NFM-P operations require idle TCP ports to remain open for longer periods of time.
Therefore, customers using a firewall that closes idle TCP connections should adjust Operating
System TCP keepalives to a value that ensures that the firewall will not close sockets in use by
NFM-P.
For some of the network elements described in 4.12 “Network element specific requirements”
(p. 80) there is a requirement for the NFM-P GUI client to communicate directly with the network
element using specialized configuration tools.

Figure 6-2 Firewalls and NFM-P standalone deployments

NFM-P
server
SNMP traps
JMS
FTP
Managed
EJB/HTTP network
SNMP/SSH/
NFM-P Telnet
clients
NFM-P
auxiliary
22668

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 129
Security NSP
NFM-P port information

Figure 6-3 Firewalls and NFM-P redundant deployments

ftp/tftp

SNMP Active

NFM-P
Managed auxiliary
network
SNMP/SSH/ JMS
Telnet

ftp/tftp TCP
(Oracle)
SNMP traps

NFM-P NFM-P
server database

JMS
JMS TCP (Oracle)
EJB/HTTP

NFM-P
clients
Standby

NFM-P
auxiliary

JMS

TCP
(Oracle)

NFM-P NFM-P
server database
22667

6.8 NFM-P port information

6.8.1 Default ports
The following table describes the listening ports on the various NFM-P applications.

Table 6-13 NFM-P firewall requirements

Default port Type Encryption Description

NFM-P server and NFM-P auxiliary (statistics, call trace, and PCMD)

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
130 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

N/A ICMP N/A ICMP Ping

The active NFM-P server will periodically ping the NFM-P delegate
server to ensure reachability.

21 TCP None FTP (Passive)

Ports from 1023 - See SCP and SFTP as This port is used to enable ftp communication from a XML API client
65536 secure alternatives. to either the NFM-P server or auxiliary. Ftp is used by the XML API
client to retrieve logToFile statistics or findToFile results. (See
6.9 “FTP” (p. 143))

22 TCP Dynamic Encryption SSH/SCP/SFTP

Cipher Suite and strength as This port is used for remote access, rsync between NFM-P servers,
per RFC 4253. rsync between the NFM-P databases, and scp/sftp to NFM-P XML
API clients.

69 UDP None
See SFTP for a secure
alternative.

80 TCP None HTTP

See port 443 for secure This port redirects to port 443.
communications.

162 UDP Static Encryption SNMP traps

When SNMPv3 is configured. By default, this port on the NFM-P server receives SNMP traps from
Cipher and strength is NE the network elements. This item is specified during the installation of
dependant. the server and can be changed.
(Not required by the NFM-P auxiliary)

443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS interface for the Web Applications
Strong ciphers are supported through the Launchpad. Also provides a WebDav Server for
using various CBC and AES snapshots and workorders
ciphers provided by TLS.

758 TCP Dynamic Encryption nlogin

Encryption provided by TLS. Secure port used for connection to and from the 1830 SMS HSM
Strong ciphers are supported server
using various CBC and AES
ciphers provided by TLS.

1095 TCP None Internal system communications protocol (JBoss messaging)

These ports are used by commands on the NFM-P auxiliary station
to adjust the NFM-P auxiliary behavior. (Example: adjusting log
levels, shutting down the auxiliary server, etc)

1097 TCP None Internal system communications protocol (JMS naming/messaging

service)
Used by the NFM-P client (GUI and XML API) and NFM-P server
and NFM-P auxiliary applications to register for JMS notifications
and messages. This is used to ensure that the client, server, and
auxiliary are aware of system events (for example: database
changes or alarm notifications, etc)

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 131
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

1099 TCP None Internal system communications protocol (JBoss Naming Service
-JNDI)
This port is required to ensure the NFM-P GUI, XML API clients,
auxiliaries and standby NFM-P server properly initialize with the
active NFM-P server.
When initially logging into the NFM-P server, NFM-P GUI and XML
API clients use this port to find the various services that are
available. This port is also used by the NFM-P GUI and XML API
clients to register with the NFM-P server to receive notification of
network changes.

1664 TCP None LTE NWI3 Corba Service Port

This port is required to communicate with OMS for Flexi MR BTS
management.

2181 TCP None Java ZooKeeper client connections

See port 2281 for secure
communications.

2281 TCP Dynamic Encryption Java ZooKeeper client connections

Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

2390 TCP Dynamic Encryption nspdctl

Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

3528 TCP None JBoss jacorb LTE NWI3 Corba Service Port
This port is required to communicate with OMS for Flexi MR BTS
management.

3529 TCP Dynamic Encryption JBoss jacorb-ssl LTE NWI3 Corba Service Port
Encryption provided by TLS. This port is required to communicate with OMS for Flexi MR BTS
Strong ciphers are supported management.
using various CBC and AES
ciphers provided by TLS.

4447 TCP Dynamic Encryption JBoss messaging port for JMS

Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

5007 TCP None Neo4j cluster control

6007 TCP None Neo4j cluster data

6362 TCP None Used by the Web Server

This is a local port to the host.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
132 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

6363 TCP None Neo4j database backup port

This is a local port to the host.

6432 TCP Dynamic Encryption postgresql communications port

Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

6633 TCP None OpenFlow

Used to exchange openflow protocol messages with 7x50 NEs.

7473 TCP Dynamic Encryption (if TLS is Neo4j https web server
configured)
Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

7474 TCP None Neo4j web server

This is a local port to the host. NFM-P server only

7687 TCP None Neo4j bolt connector

7879 TCP Dynamic Encryption (if TLS is RPC Layer

configured) Used for FM correlation engine to NFM-P server communications.
Encryption provided by TLS. Used for CPROTO communication with the NSP Flow Collector
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

7889 TCP None telemetry monitor connection for kpi-engine

This is a local port to the host..

8080 TCP None HTTP

See port 8443 for secure This port provides an HTTP interface for XML API clients to access
communications the NFM-P server.

8085 TCP None HTTP

See port 8444 for secure This port provides an HTTP interface for NFM-P client. The NFM-P
communications. client uses this port to verify the existence of the server.

8086 TCP None HTTP

See port 8445 for secure This port provides an HTTP interface to the WebDav Server for
communications. WTA. This port is only required on the CallTrace auxiliary.

8087 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. Servlet connector used for communication between tomcat and
Strong ciphers are supported NFM-P server to handle requests with a normal processing time.
using various CBC and AES
ciphers provided by TLS.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 133
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

8088 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. Webapp services such as correlation.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

8089 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. Servlet connector used for communication between tomcat and
Strong ciphers are supported NFM-P server to handle requests with a long processing time.
using various CBC and AES
ciphers provided by TLS.

8093 TCP Dynamic Encryption This port provides an HTTPS interface for Ne3s communication
Encryption provided by TLS. NFM-P server only
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

8094 TCP Dynamic Encryption This port provides an HTTPS interface for Ne3s communication.
Encryption provided by TLS. NFM-P statistics auxiliary only
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

8195 TCP None Tomcat shutdown port

This is a local port to the host.

8196 TCP None Tomcat (app1-tomcat) shutdown port

This is a local port to the host.

8197 TCP None Tomcat (app2-tomcat) shutdown port

This is a local port to the host.

8400 TCP None HTTP

This port redirects to port 443.

8443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) interface for XML API
Strong ciphers are supported clients that wish to use this protocol to access the NFM-P server
using various CBC and AES
ciphers provided by TLS.

8444 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) interface for the
Strong ciphers are supported NFM-P client. This is a secure version of port 8085. Used only if the
using various CBC and AES NFM-P client is connecting via TLS.
ciphers provided by TLS.

8445 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) interface to the
Strong ciphers are supported WebDav Server for WTA. This is a secure version of port 8086.
using various CBC and AES Used only if the WTA is connecting via TLS. This port is only
ciphers provided by TLS. required on the Call Trace auxiliary.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
134 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

8483 TCP None JBoss RMI port for WebServices

This is a local port to the host.

8543 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) interface for the
Strong ciphers are supported Launchpad, Web Applications, and online help.
using various CBC and AES
ciphers provided by TLS.

8544 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) interface for Web
Strong ciphers are supported Applications.
using various CBC and AES
ciphers provided by TLS.

8545 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) interface for
Strong ciphers are supported RESTCONF.
using various CBC and AES
ciphers provided by TLS.

8617 TCP Dynamic Encryption auxdb-agent

Encryption provided by TLS. Communication port from nspdctl
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

8889 TCP None Notification port used by TAO (CORBA Notification)

This is a local port to the host.

9000 TCP None gRPC server used by the ts-model-app in app1-tomcat.

This is a local port to the host.

9010 TCP Dynamic Encryption This port is used for file synchronization between redundant NFM-P
Encryption provided by TLS. servers and redundant auxiliary collectors (statistics and call trace).
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

9092 TCP None Kafka server

See port 9192 for secure
communication.

9192 TCP Dynamic Encryption Kafka server

Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

9400 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port redirects to port 443.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 135
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

9443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. HTTPS port for providing access to the HSM server through
Strong ciphers are supported swagger web interface
using various CBC and AES
ciphers provided by TLS.

9736 TCP None TAO Orb port

This is a local port to the host.

9990 TCP Dynamic Encryption JBoss Management Console

Encryption provided by TLS. Used to access the JBoss management console for the main server
Strong ciphers are supported process.
using various CBC and AES
ciphers provided by TLS.

9999 TCP Dynamic Encryption JMX

Encryption provided by TLS. Used to access the JMX console for the main server process.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

10090 TCP Dynamic Encryption JBoss Management Console

Encryption provided by TLS. Used to access the JBoss management console for the JMS server
Strong ciphers are supported process.
using various CBC and AES
ciphers provided by TLS.

10099 TCP Dynamic Encryption JMX

Encryption provided by TLS. Used to access the JMX console for the JMS server process.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

10190 TCP Dynamic Encryption JBoss Management Console

Encryption provided by TLS. Used to access the JBoss management console for the auxiliary
Strong ciphers are supported server process.
using various CBC and AES
ciphers provided by TLS.

10199 TCP Dynamic Encryption JMX

Encryption provided by TLS. Used to access the JMX console for the auxiliary server process.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

10290 TCP Dynamic Encryption HTTPs

Encryption provided by TLS. HTTPs interface port between the NFM-P server process and HSM
Strong ciphers are supported server process
using various CBC and AES
ciphers provided by TLS.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
136 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

11800 TCP Static Encryption Internal system communications protocol (JBoss Clustering)
Encryption provided by AES This port is required to ensure that redundant NFM-P servers can
Cipher Algorithm with 128 bit monitor each other.
Cipher Strength.

12010 TCP Dynamic Encryption This port is used for Warm standby Cache Sync communication
Encryption provided by TLS. between redundant NFM-P servers
Strong ciphers are supported This port is not used on the NFM-P auxiliary.
using various CBC and AES
ciphers provided by TLS.

12300 - 12307 TCP None These ports are used for detecting communication failures between
NFM-P server clusters (primary / secondary / auxiliaries)

12800 TCP Static Encryption Internal system communications protocol (JBoss clustering)
Encryption provided by AES During run-time operations, the NFM-P auxiliary uses this port to
Cipher Algorithm with 128 bit send and receive information to and from the NFM-P server.
Cipher Strength. The number of required ports depends on the number of NFM-P
auxiliary stations that are installed.
Note that NFM-P can be configured to use a different port for this
purpose. The procedure is available from Nokia personnel.

29780 UDP None Used to stream UDP PCMD data from SGW and PGW network
elements
Auxiliary PCMD collector only

47100 - 47199 TCP Dynamic Encryption Session-Manager ignite cache communication spi
Encryption provided by TLS. Only required on the NFM-P server when hosting the nspOS
Strong ciphers are supported components. Communication to external hosts is not required.
using various CBC and AES
ciphers provided by TLS.

47500 - 47599 TCP Dynamic Encryption Session-Manager ignite cache discovery spi
Encryption provided by TLS. Only required on the NFM-P server when hosting the nspOS
Strong ciphers are supported components. Communication to external hosts is not required.
using various CBC and AES
ciphers provided by TLS.

48500 - 48599 TCP Dynamic Encryption Session-Manager ignite cache communication spi
Encryption provided by TLS. Only required on the NFM-P server when hosting the nspOS
Strong ciphers are supported components. Communication to external hosts is not required.
using various CBC and AES
ciphers provided by TLS.

48600 - 48699 TCP Dynamic Encryption Session-Manager ignite cache discovery spi
Encryption provided by TLS. Only required on the NFM-P server when hosting the nspOS
Strong ciphers are supported components. Communication to external hosts is not required.
using various CBC and AES
ciphers provided by TLS.

NSP Flow Collector

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 137
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

21 TCP None FTP (Passive)

Ports from 1023 - See SCP and SFTP as This port is used to enable ftp communication between the NSP
65536 secure alternatives Flow Collector and the NFM-P server or dedicated ftp server for
retrieving IPDR files.

22 TCP Dynamic Encryption SSH/SCP/SFTP

Cipher Suite and strength as This port is used to enable SSH (SFTP/SCP) communication
per RFC 4253 between the NSP Flow Collector and the NFM-P server or dedicated
ftp server for retrieving IPDR files.

2205 UDP None CGNAT / IPFIX cflowd records from 7750 SR routers to NSP Flow
Collector

4739 UDP None cflowd records from 7750 SR routers to NSP Flow Collector

7899 TCP None CPROTO

8080 TCP None HTTP

See port 8443 for secure This port provides an HTTP Web User interface for the NSP Flow
communications. Collector

8083 TCP None JBoss Socket for dynamic class and resource loading.

8443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTP Web User interface for the NSP Flow
Strong ciphers are supported Collector
using various CBC and AES This is a secure version of port 8080.
ciphers provided by TLS.

9443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) NSP Flow Collector
Strong ciphers are supported management interface. This is a secure version of port 9990. Used
using various CBC and AES only if the NSP Flow Collector is TLS secured.
ciphers provided by TLS.

9990 TCP None HTTP

See port 9443 for secure This port provides an HTTP NSP Flow Collector management
communications. interface.
This is a local port to the host.

9999 TCP Dynamic Encryption JMX

Encryption provided by TLS. Used to access the JMX console.
Strong ciphers are supported This is a local port to the host.
using various CBC and AES
ciphers provided by TLS.

44444 TCP None RMI server port

NSP Flow Collector Controller

21 TCP None FTP (Passive)

Ports from 1023 - See SCP and SFTP as This port is used to enable ftp communication between the NSP
65536 secure alternatives Flow Collector Controller and the NFM-P server or dedicated ftp
server for retrieving IPDR files.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
138 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

22 TCP Dynamic Encryption SSH/SCP/SFTP

Cipher Suite and strength as This port is used to enable SSH (SFTP/SCP) communication
per RFC 4253 between the NSP Flow Collector Controller and the NFM-P server or
dedicated ftp server for retrieving IPDR files.

1090 TCP None JBoss RMI/JRMP socket for connecting to the JMX MBeanServer.
Used for NFM-P server to NSP Flow Collector Controller
communication.

1098 TCP None JBoss Socket Naming service used to receive RMI request from
client proxies.
Used for NFM-P server to NSP Flow Collector Controller
communication.

1099 TCP None JBoss The listening socket for the Naming service.
Used for Jboss communication between NFM-P and NSP Flow
Collector Controller.

4444 TCP None JBoss Socket for the legacy RMI/JRMP invoker.
Used for Jboss communication between NFM-P to NSP Flow
Collector Controller.

4445 TCP None JBoss Socket for the legacy Pooled invoker.
Used for Jboss communication between NFM-P to NSP Flow
Collector Controller.

4446 TCP None JBoss Socket for the JBoss Remoting Connected used by Unified
Invoker.
Used for Jboss communication between NFM-P to NSP Flow
Collector Controller.

4447 TCP None JBoss Socket for JBoss Remoting Connections.

This is a local port to the host.

4457 TCP Dynamic Encryption JBoss Socket for JBoss Messaging 1.x
Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

7879 TCP None CPROTO

8080 TCP None HTTP

See port 8443 for secure This port provides an HTTP Web User interface for the NSP Flow
communications. Collector Controller.

8083 TCP None JBoss Socket for dynamic class and resource loading.

8443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTP Web User interface for the NSP Flow
Strong ciphers are supported Collector Controller.
using various CBC and AES This is a secure version of port 8080.
ciphers provided by TLS.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 139
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

9443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides an HTTPS (secure HTTP) NSP Flow Collector
Strong ciphers are supported Controller management interface. This is a secure version of port
using various CBC and AES 9990. Used only if the NSP Flow Collector Controller is TLS
ciphers provided by TLS. secured.

9990 TCP None HTTP

See port 9443 for secure This port provides an HTTP NSP Flow Collector Controller
communications. management interface.
This is a local port to the host.

22222 TCP Dynamic Encryption SFTP

Cipher Suite and strength as SFTP connection from NSP Flow Collector.
per RFC 4253

44444 TCP None RMI server port

NSP analytics server

8080 TCP None HTTP

See port 8443 for secure This port provides an HTTP Web User interface for the NSP
communications. analytics server. It's used by the NFM-P server and web based
clients for HTTP requests.

8443 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. This port provides a secure HTTP Web User interface for the NSP
Strong ciphers are supported analytics server. It's used by the NFM-P server and web based
using various CBC and AES clients for HTTPS requests
ciphers provided by TLS. This is a secure version of port 8080.

10990 TCP Dynamic Encryption HTTPS

Encryption provided by TLS. Used to access the JMX console for the analytics process.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

NFM-P auxiliary database

22 TCP Dynamic Encryption SSH / SFTP

Cipher Suite and strength as Vertica Administration Tools.
per RFC 4253 Inter-node and inter-cluster communication

4803 TCP None Spread

Client connections
Inter-node communication only.

4803 UDP None Spread

Daemon to Daemon connections
Inter-node communication only.

4804 UDP None Spread

Daemon to Daemon connections
Inter-node communication only.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
140 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

5433 TCP Dynamic Encryption (if JDBC

secure=true) Client communication port (NFM-P server, statistics auxiliary, Flow
Encryption provided by TLS. Collector, analytics server)
Strong ciphers are supported
using various AES ciphers
provided by TLS.

5433 UDP None Vertica

Vertica spread monitoring
Inter-node communication only.

5434 TCP None Vertica

Intra and inter cluster communication
Inter-node communication only.

6543 TCP None Spread

Monitor to Daemon connections
Inter-node communication only.

7299 TCP Dynamic Encryption (if RMI

secure=true) NFM-P auxiliary database proxy port.
Encryption provided by TLS.
Strong ciphers are supported
using various CBC and AES
ciphers provided by TLS.

7300–7309 TCP None RMI

NFM-P auxiliary database proxy ports. Not used if secure=true.

50000 TCP None Rsync

Inter-node and inter-cluster communication

32768-60999 TCP None Vertica - Zygote

Inter-node communication only

32768-60999 UDP None Vertica - Spread

Inter-node communication only

Managed devices

21 TCP None FTP (Passive)

Ports from 1023 - This port is used to enable ftp communication between the NFM-P
65536 server and the managed routers. Ftp occurs to transfer information
from the routers to the NFM-P server such as accounting statistics.
See 6.9 “FTP” (p. 143) for a more detailed description of ftp
requirements.

22 TCP Dynamic Encryption SSH / SFTP

Cipher Suite and strength as This port used by clients to request a SSH session to a managed
per RFC 4253 router.

23 TCP None Telnet

This port used by clients to request a telnet session to a managed
router.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 141
Security NSP
NFM-P port information

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

80 TCP None HTTP

This port is required for the NFM-P client to communicate with the
network element Web GUIs. See 4.12 “Network element specific
requirements” (p. 80) for the network elements that require this port.

161 UDP Static Encryption SNMP

When SNMPv3 is configured. By default, NFM-P server sends SNMP messages, such as
Cipher and strength is NE configuration requests and service deployments, to this port on the
dependant. network elements.

830 TCP Dynamic Encryption SSHv2 for CMM

Cipher Suite and strength as This port is used by the CMM network elements for NetConf
per RFC 4253 management.

1491 TCP Static Encryption SNMP Streaming

When SNMPv3 is configured. Used for TCP Streaming during NE discovery and resync. Only
Cipher and strength is NE applicable to 7950 XRS, 7750 SR, 7450 ESS, 11.0R5+.
dependant.

5001 TCP None Proprietary Java socket connection

This port is used by CPAM to communicate with the 7701 CPAA to
obtain control plane information.

5010 UDP None Trap

Trap port used by 9500 MPR / Wavence SM devices to send traps
to NFM-P clients running the NetO manager.

11500 TCP None Equipment View

Used while managing 9500 MPR / Wavence SM(MSS-1C, MPR-e,
MSS-8) NEs using the Equipment View function as part of NetO

N/A ICMP N/A ICMP

Only used if the Ping Policy is enabled as part of network element
mediation.

NFM-P database

22 TCP Dynamic Encryption SSH

Cipher Suite and strength as This port is used by NFM-P for an optional rsync feature between
per RFC 4253 NFM-P databases

1523 TCP Static Encryption Oracle SQL*Net Listener

Encryption provided by RC4 This port is used by the NFM-P server to connect to and
Cipher Algorithm with 128 bit communicate with the NFM-P database. When there are redundant
Cipher Strength. databases, this port is also used by Oracle DataGuard to keep the
databases in sync. The data on this port is encrypted.

9002 TCP Dynamic Encryption NFM-P database Proxy

Encryption provided by TLS. This port is used by the NFM-P server to monitor disk usage on a
Strong ciphers are supported remote NFM-P database. When there are redundant databases, it is
using various CBC and AES also allows the NFM-P server to initiate database switchovers and
ciphers provided by TLS. failovers.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
142 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
FTP

Table 6-13 NFM-P firewall requirements (continued)

Default port Type Encryption Description

9003 TCP None Database file transfer Port

This port is used by the NFM-P database stations in a redundant
station configuration. This port allows database transfers between
the primary and standby databases. For example: when the standby
database is reinstantiated, or when the standby database is
installed for the first time.

NFM-P client and client delegate server

20 TCP None FTP

Active FTP port for 9500 MPR / Wavence SM software download
from NEtO.

21 TCP None FTP

Ports from 1023 - 9500 MPR / Wavence SM software download from NEtO.
65535

22 TCP Dynamic Encryption sFTP

Cipher Suite and strength as 9500 MPR / Wavence SM software download from NEtO
per RFC 4253

162 UDP None Trap

Trap port used by 9500 MPR / Wavence SM (MPR-e, MSS-8)
devices to send traps to NFM-P clients running the NetO manager.

5010 UDP None Trap

Trap port used by 9500 MPR / Wavence SM devices to send traps
to NFM-P clients running the NetO manager.

6.9 FTP
6.9.1 FTP between the NFM-P server and NFM-P auxiliary statistics collector and
the managed network
NFM-P server and NFM-P auxiliary statistics collector may use FTP for several purposes.
The NFM-P server may use FTP, if configured, to receive backup images of managed devices, to
send new software images to the managed devices and to receive accounting statistics from the
managed devices.
If an NFM-P auxiliary statistics collector station is installed, FTP will be used, if configured, to
retrieve accounting statistics from managed devices.
If STM Accounting tests are being executed, the NFM-P server will retrieve the test results from the
managed devices by FTP, if configured.
The FTP communication is configured as an extended passive FTP connection, with the managed
devices serving as the FTP servers and the NFM-P server and NFM-P auxiliary acting as the FTP
client.
Extended passive FTP connections use dynamically-allocated ports on both sides of the
communication channel, and are ephemeral in nature. As such, the data sent from the managed

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 143
Security NSP
NFM-P firewall and NAT rules

devices will be sent from a port in the range of 1024-65536. This data will be sent to the NFM-P
server on a port in the range of 1024-65536. Support for EPSV/EPRT ftp commands (commands
that can replace PASV/PORT commands) must be enabled for connections to the 7x50 family of
routers.

6.10 NFM-P firewall and NAT rules

6.10.1 Overview
Firewall rules are applied to the incoming network interface traffic of the NFM-P stations. As a rule,
firewall rules are not applied to the outgoing network interface traffic.
For NFM-P installations using RHEL as the Operating System, the RHEL supplied firewall can be
used to filter network traffic using filter rules lists. Only experienced system administrators with
extensive knowledge of the RHEL firewall should attempt to implement the filter rules lists provided
with each NFM-P component. All others should disable the RHEL firewall.
The installation of each NFM-P component will include the filter rules lists to be applied for
successful communication between different NFM-P components, XML API clients, and network
elements. The table below defines the location

Table 6-14 Sample firewalld filter rules lists file locations

Component Protocol File location

NFM-P server IPv4/IPv6 /opt/nsp/nfmp/server/nms/sample/firewall/

NFM-P database IPv4/IPv6 /opt/nsp/nfmp/db/install/sample/firewall/

NFM-P Statistics/call IPv4/IPv6 /opt/nsp/nfmp/auxserver/nms/sample/firewall/

trace/PCMD auxiliary

NSP Flow Collector IPv4/IPv6 /opt/nsp/flow/fcc/sample/firewalld/

Controller

NSP Flow Collector IPv4/IPv6 /opt/nsp/flow/fc/sample/firewalld/

NFM-P auxiliary IPv4 /opt/nsp/nfmp/auxdb/install/config/sample/firewall/

database

NFM-P client IPv4/IPv6 <base client install dir>/nms/sample/firewall/

NFM-P client IPv4/IPv6 <base client install dir>/nms/sample/firewall/

delegate server

It is imperative that all rules are considered completely for the NFM-P systems to interoperate
correctly. The following tables will define the rules to be applied to each NFM-P station. Within the
section there will be a number of conditions that indicate whether or not that particular table needs
to be applied.
See 7.4 “NFM-P Network Address Translation” (p. 175) for supported NAT configurations.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
144 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

6.10.2 NFM-P server firewall and NAT rules

When there is a firewall at the NFM-P server(s) interface that reaches the managed network (NIC 2
on Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)), the following firewall rules need to be applied.

Table 6-15 SNMP firewall rules for traffic between the NFM-P server(s) and the managed network

Protocol From port On To port On Notes

UDP Any Managed network 162 Server(s) SNMP trap initiated from
the NE

UDP >15000 Server(s) 161 Managed network SNMP request

UDP 161 Managed network >15000 Server(s) SNMP response

TCP >15000 Server(s) 1491 Managed network SNMP TCP Streaming

TCP 1491 Managed network >15000 Server(s) SNMP TCP Streaming

Note: Due to the size of SNMP packets, IP fragmentation may occur in the network. Ensure
the firewall will allow fragmented packets to reach the server(s).

Table 6-16 Telnet / FTP firewall rules for traffic between the NFM-P server(s) and the managed network

Protocol From port On To port On Notes

TCP >15000 Server(s) 23 Managed network Telnet request

TCP 23 Managed network >15000 Server(s) Telnet response

TCP Any Server(s) 21 Managed network FTP requests (example:

STM, Accounting
statistics, NE backups)

TCP 21 Managed network Any Server(s) FTP responses

TCP > 1023 Managed network > 1023 Server(s) Passive FTP ports for
data transfer

Table 6-17 SSH / SFTP / SCP firewall rules for traffic between the NFM-P server(s) and the managed network

Protocol From port On To port On Notes

TCP Any Server(s) 22 Managed network NFM-P SSH request

TCP 22 Managed network Any Server(s) NFM-P SSH response

TCP >15000 Server(s) 830 Managed network SSHv2 request for MME

TCP 830 Managed network >15000 Server(s) SSHv2 response for

MME

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 145
Security NSP
NFM-P firewall and NAT rules

Table 6-18 Other firewall rules for traffic between the NFM-P server(s) and the managed network

Protocol From port On To port On Notes

ICMP N/A Managed network N/A NFM-P server(s) Only used if Ping Policy
is enabled.

TCP >15000 NFM-P server(s) 5001 7701 CPAA Elements –

TCP >15000 Managed network 6633 NFM-P server(s) Openflow data

TCP >15000 NFM-P server(s) 57400 Managed network Telemetry data

Table 6-19 Firewall rules for traffic between the NFM-P server(s) and OMS for Flexi MR BTS management

Protocol From port On To port On Notes

TCP Any OMS 1664 NFM-P server(s) Corba

TCP Any OMS 3528 NFM-P server(s) Corba

TDP Any OMS 3529 NFM-P server(s) Corba

Table 6-20 Firewall rules for traffic between the NFM-P server(s) and the LTE BTS

Protocol From port On To port On Notes

TCP Any LTE BTS 8093 NFM-P server(s) NE3S

Table 6-21 Firewall rules for traffic between the NFM-P server(s) and the 1830 SMS HSM

Protocol From port On To port On Notes

TCP 758 NFM-P server 5552 1830 SMS HSM Two way
communication

Table 6-22 Firewall rules for remote user authentication

Protocol From port On To port On Notes

TCP/UDP Any NFM-P server 49 TACACS server For TACACS

authentication

TCP/UDP Any NFM-P server 389 LDAP server For LDAP authentication

TCP/UDP Any NFM-P server 636 LDAP server For LDAP authentication
(TLS)

UDP Any NFM-P server 1812 RADIUS server For RADIUS

authentication

When there is a firewall at the interface that reaches the NFM-P client(s) (NIC 3 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)) the
following rules need to be applied.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
146 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

Table 6-23 Firewall rules for traffic coming into the NFM-P server(s) from the NFM-P client(s) (GUI/XML
API/JMS/Web/Kafka)

Protocol From port On To port On Notes

TCP Any XML API client 21 Server(s) If FTP is required

TCP Any XML API client 22 Server(s) If SFTP/SCP is required

TCP Any NFM-P GUI client 443 Server(s) HTTPS

TCP > 1023 XML API client > 1023 Server(s) If (passive) FTP is
required

TCP Any XML API/NFM-P GUI 1097 Server(s) JMS

client

TCP Any XML API/NFM-P GUI 1099 Server(s) JNDI

client

TCP Any XML API/NFM-P GUI 4447 Server(s) JMS

client

UDP Any NFM-P GUI client 6100-6119 Server(s) NEM Proxy

TCP Any XML API client 8080 Server(s) HTTP

TCP Any NFM-P GUI client 8085 Server(s) HTTP

TCP Any NFM-P GUI client 8087 Server(s) HTTP(S)

TCP Any NFM-P GUI client 8088 Server(s) HTTP(S)

TCP Any NFM-P GUI client 8089 Server(s) HTTP(S)

TCP Any XML API client 8443 Server(s) HTTPS

TCP Any NFM-P GUI client 8444 Server(s) HTTPS

TCP Any NFM-P GUI / Web client 8543 Server(s) HTTPS

TCP Any NFM-P GUI / Web client 8544 Server(s) HTTPS

TCP Any RESTCONF client 8545 Server(s) HTTPS

TCP Any kafka client 9092 Server(s) kafka

TCP Any kafka client 9192 Server(s) kafka Secure

TCP Any Web client 9443 Server(s) HSM

When there is a firewall configured, and there are redundant NFM-P auxiliary station(s), the
following rules need to be applied to the appropriate interface.

Table 6-24 Firewall rules for traffic coming into the NFM-P server(s) from the NFM-P auxiliary statistics / call
trace / PCMD collector(s)

Protocol From port On To port On

TCP Any Auxiliary server(s) 1097 Server(s)

TCP Any Auxiliary server(s) 1099 Server(s)

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 147
Security NSP
NFM-P firewall and NAT rules

Table 6-24 Firewall rules for traffic coming into the NFM-P server(s) from the NFM-P auxiliary statistics / call
trace / PCMD collector(s) (continued)

Protocol From port On To port On

TCP Any Auxiliary server(s) 2181 Server(s)

(statistics)

TCP Any Auxiliary server(s) 2281 Server(s)

(statistics)

TCP Any Auxiliary server(s) 4447 Server(s)

Table 6-25 Firewall rules for traffic coming into the NFM-P server(s) from the NSP Flow Collector Controller(s)

Protocol From port On To port On

TCP Any NSP Flow Collector 21 Server(s)

Controller

TCP Any NSP Flow Collector 22 Server(s)

Controller

TCP >1023 NSP Flow Collector >1023 Server(s)

Controller

TCP Any NSP Flow Collector 1099 Server(s)

Controller

TCP Any NSP Flow Collector 2181 Server(s)

Controller

TCP Any NSP Flow Collector 2281 Server(s)

Controller

TCP Any NSP Flow Collector 7879 Server(s)

Controller

TCP Any NSP Flow Collector 8080/8443 Server(s)

Controller

Table 6-26 Firewall rules for traffic coming into the NFM-P server(s) from the NSP Flow Collector(s)

Protocol From port On To port On

TCP Any NSP Flow Collector 2181 Server(s)

Controller

TCP Any NSP Flow Collector 2281 Server(s)

Controller

When a firewall and NAT are configured to the NFM-P server at the NFM-P client interface (NIC 3
on Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)) the following rules need to be applied to allow the XML API clients to retrieve the logToFile
accounting statistics information. Services require the use of public addresses.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
148 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

Table 6-27 Additional firewall rules required to allow services on the NFM-P client(s) to communicate with the
NFM-P server if NAT is used

Protocol From port On To port On

TCP Any Server Public Address 21 Server Private Address

TCP 21 Server Public Address Any Server Private Address

TCP > 1023 Server Public Address > 1023 Server Private Address

When there is a firewall at the interface that reaches the NFM-P management network (NIC 1 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)), the following rules apply.

Table 6-28 Firewall rules for traffic coming into the NFM-P server(s) from the NFM-P database server(s)

Protocol From port On To port On

TCP 1523 Database server(s) Any Server(s)

TCP 9002 Database server(s) Any Server(s)

When there is a firewall at the NFM-P management interface (NIC 1 on Figure 7-3, “Distributed
NFM-P server/database deployment with multiple network interfaces” (p. 170)) and NFM-P server
redundancy is configured, then the following rules need to be applied. Configuration needs to be in
both directions to handle an activity switch.

Table 6-29 Firewall rules for setups with redundant NFM-P servers

Protocol From port On To port On

TCP Any Servers 22 Servers

TCP 22 Servers Any Servers

TCP Any Server 1099 Server

TCP 1099 Server Any Server

TCP Any Server 2390 Server

TCP 2390 Server Any Server

TCP Any Server 5007 Server

TCP 5007 Server Any Server

TCP Any Server 6007 Server

TCP 6007 Server Any Server

TCP >15000 Server 6432 Server

TCP 6432 Server >15000 Server

TCP >15000 Server 7879 Server

TCP 7879 Server >15000 Server

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 149
Security NSP
NFM-P firewall and NAT rules

Table 6-29 Firewall rules for setups with redundant NFM-P servers (continued)

Protocol From port On To port On

TCP >15000 Servers 8087 Servers

TCP 8087 Servers >15000 Servers

TCP >15000 Servers 8543 Servers

TCP 8543 Servers >15000 Servers

TCP >15000 Servers 9010 Servers

TCP 9010 Servers >15000 Servers

TCP >15000 Servers 11800 Servers

TCP 11800 Servers >15000 Servers

TCP >15000 Servers 12010 Servers

TCP 12010 Servers >15000 Servers

TCP >15000 Servers 12300-12307 Servers

TCP 12300-12307 Servers >15000 Servers

When there is a firewall at the NFM-P management interface (NIC 1 on Figure 7-3, “Distributed
NFM-P server/database deployment with multiple network interfaces” (p. 170)) and NFM-P auxiliary
statistics / call trace / PCMD collectors are configured, then the following rules need to be applied:

Table 6-30 Firewall rules for traffic coming into the NFM-P server(s) from the NFM-P auxiliary statistics / call
trace server(s)

Protocol From port On To port On

TCP Any Auxiliary server(s) 12300-12307 Server(s)

TCP 12300-12307 Auxiliary server(s) Any Server(s)

TCP Any Auxiliary server(s) 12800 Server(s)

TCP 12800 Auxiliary server(s) Any Server(s)

If NFM-P is not deployed with NSP, the following rules need to be applied to the NFM-P server if
there is a firewall on the NFM-P management interface (NIC 1 on Figure 7-3, “Distributed NFM-P
server/database deployment with multiple network interfaces” (p. 170))

Table 6-31 Firewall rules for inter-process communication on the NFM-P server(s)

Protocol From port On To port On

TCP >15000 NFM-P server(s) 443 NFM-P server(s)

TCP 443 NFM-P server(s)) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 2181 NFM-P server(s)

TCP 2181 NFM-P server(s) >15000 NFM-P server(s)

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
150 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

Table 6-31 Firewall rules for inter-process communication on the NFM-P server(s) (continued)

Protocol From port On To port On

TCP >15000 NFM-P server(s) 2281 NFM-P server(s)

TCP 2281 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 2390 NFM-P server(s)

TCP 2390 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 5007 NFM-P server(s)

TCP 5007 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 6007 NFM-P server(s)

TCP 6007 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 6432 NFM-P server(s)

TCP 6432 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 7473 NFM-P server(s)

TCP 7473 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 7687 NFM-P server(s)

TCP 7687 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 8087 NFM-P server(s)

TCP 8087 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 8617 NFM-P server(s)

TCP 8617 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 9092 NFM-P server(s)

TCP 9092 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 9192 NFM-P server(s)

TCP 9192 NFM-P server(s) >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 10290 NFM-P server(s)

TCP 10290 NFM-P server(s) >15000 NFM-P server(s)

If NFM-P is deployed with NSP, the following rules need to be applied to the NFM-P server if there
is a firewall on the NFM-P management interface (NIC 1 on Figure 7-3, “Distributed NFM-P server/
database deployment with multiple network interfaces” (p. 170))

Table 6-32 Firewall rules for communication between the NFM-P server(s) and NSP

Protocol From port On To port On

TCP >15000 NFM-P server(s) 443 NSP

TCP 443 NSP >15000 NFM-P server(s)

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 151
Security NSP
NFM-P firewall and NAT rules

Table 6-32 Firewall rules for communication between the NFM-P server(s) and NSP (continued)

Protocol From port On To port On

TCP >15000 NFM-P server(s) 2181 NSP

TCP 2181 NSP >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 2281 NSP

TCP 2281 NSP >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 2390 NSP

TCP 2390 NSP >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 6432 NSP

TCP 6432 NSP >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 7473 NSP

TCP 7473 NSP >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 7687 NSP

TCP 7687 NSP >15000 NFM-P server(s)

TCP >15000 NSP 7879 NFM-P server(s)

TCP 7879 NFM-P server(s) >15000 NSP

TCP >15000 NFM-P server(s) 8087 NSP

TCP 8087 NSP >15000 NFM-P server(s)

TCP >15000 NSP 8089 NFM-P server(s)

TCP 8089 NFM-P server(s) >15000 NSP

TCP >15000 NFM-P server(s) 9092 NSP

TCP 9092 NSP >15000 NFM-P server(s)

TCP >15000 NFM-P server(s) 9192 NSP

TCP 9192 NSP >15000 NFM-P server(s)

Table 6-33 Firewall rules for communication between the NFM-P statistics auxiliary and NSP

Protocol From port On To port On

TCP >15000 NFM-P statistics 2181 NSP

auxiliary

TCP 2181 NSP >15000 NFM-P statistics

auxiliary

TCP >15000 NFM-P statistics 2281 NSP

auxiliary

TCP 2281 NSP >15000 NFM-P statistics

auxiliary

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
152 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

6.10.3 NFM-P database firewall and NAT rules

When there is a firewall at the interface that reaches the NFM-P management network (NIC 1 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)), the following rules apply.

Table 6-34 Firewall rules for traffic coming into the NFM-P database server(s) from the NFM-P server(s),
NFM-P auxiliary statistics / call trace / PCMD collector(s), and NSP analytics server

Protocol From port On To port On

TCP Any Server(s), auxiliary 1523 Database server(s)

server(s), & analytics
server

TCP Any Server(s) & auxiliary 9002 Database server(s)

server(s)

TCP >15000 Server(s) & auxiliary 9003 Database server(s)

server(s)

When there is a firewall at the interface that reaches the NFM-P management network (NIC 1 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)) and redundancy is configured, the following rules apply. Configuration needs to be in both
directions to handle an activity switch.

Table 6-35 Firewall rules for traffic between the NFM-P database servers (redundant only)

Protocol From port On To port On

TCP Any Database servers 22 Database servers

TCP 22 Database servers Any Database servers

TCP Any Database servers 1523 Database servers

TCP 1523 Database servers >15000 Database servers

TCP 9002 Database servers 9002 Database servers

TCP 9003 Database servers 9003 Database servers

6.10.4 NFM-P auxiliary server and NSP Flow Collector firewall and NAT rules
When there is a firewall at the interface that reaches the managed network (NIC 2 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)), the
following rules apply.

Table 6-36 SNMP firewall rules for traffic coming into the NFM-P auxiliary statistics collector server(s) from the
managed network

Protocol From port On To port On Notes

UDP >32768 Auxiliary server(s) 161 Managed network SNMP request

UDP 161 Managed network >32768 Auxiliary server(s) SNMP response

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 153
Security NSP
NFM-P firewall and NAT rules

Note: Due to the size of SNMP packets, IP fragmentation may occur in the network. Ensure
the firewall will allow fragmented packets to reach the server(s).

Table 6-37 SSH / Telnet firewall rules for traffic coming into the NFM-P auxiliary statistics collector server(s)
from the managed network

Protocol From port On To port On Notes

TCP >32768 Auxiliary server(s) 22-23 Managed network SSH/SCP/Telnet

request

TCP 22-23 Managed network > 32768 Auxiliary server(s) SSH/SCP/Telnet

response

Table 6-38 FTP firewall rules for traffic coming into the NFM-P auxiliary statistics collector(s) from the
managed network

Protocol From port On To port On Notes

TCP Any Auxiliary server(s) 21 Managed network FTP requests (example:

STM, accounting
statistics, NE backups)

TCP 21 Managed network Any Auxiliary server(s) FTP responses

TCP > 1023 Managed network > 1023 Auxiliary server(s) Passive FTP ports for
data transfer (See
6.9 “FTP” (p. 143))

Table 6-39 Firewall rules for traffic coming into the NFM-P auxiliary statistics collector(s) from the LTE BTS

Protocol From port On To port On Notes

TCP Any LTE BTS 8094 NFM-P auxiliary NE3S

server(s)

Note: FTP access is only required for the NFM-P auxiliary statistics collector.

Table 6-40 SNMP firewall rules for traffic coming into the NFM-P auxiliary call trace collector(s) from the
managed network

Protocol From port On To port On Notes

UDP >32768 Auxiliary server(s) 161 Managed network SNMP request

UDP 161 Managed network > 32768 Auxiliary server(s) SNMP response

Note: Due to the size of SNMP packets, IP fragmentation may occur in the network. Ensure
the firewall will allow fragmented packets to reach the server(s).

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
154 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

Table 6-41 Firewall rules for traffic coming into the NFM-P auxiliary PCMD collector(s) from the managed
network

Protocol From port On To port On Notes

UDP Any Managed network 29780 Auxiliary server(s) PCMD records from
SGW / PGW to NFM-P
PCMD auxiliary
collector

Table 6-42 Firewall rules for traffic coming into the NSP Flow Collector(s) from the managed network

Protocol From port On To port On Notes

UDP Any Managed network 2205 NSP Flow Collector CGNAT / IPFIX cflowd
records

UDP Any Managed network 4739 NSP Flow Collector cflowd records from
7750 SR routers to NSP
Flow Collector

When there is a firewall at the interface that reaches the NFM-P client(s) (NIC 3 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)), the
following rules apply for FTP access to the NFM-P auxiliary by the XML-API client.

Table 6-43 Firewall rules for XML API client communication to the NFM-P auxiliary collector(s)

Protocol From port On To port On Notes

TCP Any XML API client 21/22 auxiliary collector(s) (S)FTP requests
(logToFile statistics, and
call trace information)

TCP 21/22 XML API client Any auxiliary collector(s) (S)FTP responses

TCP > 1023 XML API client Any auxiliary collector(s) Passive (S)FTP ports
for data transfer (See
6.9 “FTP” (p. 143))

Only for NFM-P auxiliary call trace collectors

TCP Any XML API client 8086 auxiliary collector(s) HTTP interface for
WebDAV for WTA

TCP Any XML API client 8445 auxiliary collector(s) HTTPS interface for
WebDAV for WTA

Table 6-44 FTP/SFTP firewall rules for the NSP Flow Collector(s)

Protocol From port On To port On Notes

TCP Any NSP Flow Collector(s) 21/22 Target file server (S)FTP requests

TCP 21/22 Target file server Any NSP Flow Collector(s) (S)FTP responses

TCP > 1023 Target file server Any NSP Flow Collector(s) Passive (S)FTP ports for
data transfer (See
6.9 “FTP” (p. 143))

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 155
Security NSP
NFM-P firewall and NAT rules

Table 6-45 FTP/SFTP firewall rules for the NSP Flow Collector Controllers(s)

Protocol From port On To port On Notes

TCP Any NSP Flow Collector(s) 21/22 NFM-P server (S)FTP requests

TCP 21/22 NFM-P server Any NSP Flow Collector(s) (S)FTP responses

TCP > 1023 NFM-P server Any NSP Flow Collector(s) Passive (S)FTP ports for
data transfer (See
6.9 “FTP” (p. 143))

TCP Any NSP Flow Collector 22222 NSP Flow Collector SFTP requests
Controller

TCP 22222 NSP Flow Collector Any NSP Flow Collector SFTP responses
Controller

When there is a firewall at the interface that communicates with the NFM-P servers, the following
rules apply for inter process communication.

Table 6-46 Firewall rules for inter-process communication on the NFM-P auxiliary statistics / call trace
collector(s)

Protocol From port On To port On

TCP Any Auxiliary server(s) 1095 Auxiliary server(s)

TCP Any Auxiliary server(s) 12300-12307 Auxiliary server(s)

TCP 12300-12307 Auxiliary server(s) Any Auxiliary server(s)

TCP Any Auxiliary server(s) 12800 Auxiliary server(s)

TCP 12800 Auxiliary server(s) Any Auxiliary server(s)

Table 6-47 Firewall rules for inter-process communication on the NSP Flow Collector Controller(s)

Protocol From port On To port On

TCP Any NSP Flow Collector(s) 1090 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 1098 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 1099 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 4444 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 4445 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 4446 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 4457 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 8083 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 9443 NSP Flow Collector(s)

TCP Any NSP Flow Collector(s) 44444 NSP Flow Collector(s)

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
156 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

Table 6-48 Firewall rules for inter-process communication on the NSP Flow Collector(s)

Protocol From port On To port On

TCP Any NSP Flow Collector(s) 44444 NSP Flow Collector(s)

When there is a firewall at the interface that communicates with the NFM-P servers, the following
rules apply.

Table 6-49 Firewall rules for traffic coming into the NFM-P auxiliary statistics / call trace / PCMD collector(s)
from the NFM-P server(s)

Protocol From port On To port On

TCP 1097 NFM-P server(s) Any Auxiliary server(s)

TCP 1099 NFM-P server(s) Any Auxiliary server(s)

TCP 4447 NFM-P server(s) Any Auxiliary server(s)

Table 6-50 Firewall rules for traffic between the NSP Flow Collector Controller(s) from the NFM-P server(s) or
NSP

Protocol From port On To port On

TCP Any NSP Flow Collector 2181 NFM-P server(s) / NSP

Controller(s)

TCP Any NSP Flow Collector 2281 NFM-P server(s) / NSP

Controller(s)

TCP Any NFM-P server(s) / NSP 7879 NSP Flow Collector

Controller(s)

Table 6-51 Firewall rules for traffic between the NSP Flow Collector(s) from the NFM-P server(s) or NSP

Protocol From port On To port On

TCP Any NSP Flow Collector(s) 2181 NFM-P server(s) / NSP

TCP Any NSP Flow Collector(s) 2281 NFM-P server(s) / NSP

TCP Any NFM-P server(s) / NSP 7899 NSP Flow Collector(s)

When there is a firewall at the interface that reaches the NFM-P client(s) (NIC 3 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)) and
NAT is used on the NFM-P auxiliary server(s), the following rules apply to allow the XML API clients
to collect the logToFile accounting statistics files. Services require the use of public addresses.

Table 6-52 Additional firewall rules required to allow services on the NFM-P client(s) to communicate with the
NFM-P auxiliary(s) if NAT is used on the auxiliary server(s)

Protocol From port On To port On

TCP Any Auxiliary server public 21 Auxiliary server private

address address

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 157
Security NSP
NFM-P firewall and NAT rules

Table 6-52 Additional firewall rules required to allow services on the NFM-P client(s) to communicate with the
NFM-P auxiliary(s) if NAT is used on the auxiliary server(s) (continued)

Protocol From port On To port On

TCP 21 Auxiliary server public Any Auxiliary server private

address address

TCP > 1023 Auxiliary server public > 1023 Auxiliary server private
address address

When there is a firewall at the interface that reaches the NFM-P management network (NIC 1 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)), the following rules apply.

Table 6-53 Firewall rules for traffic coming into the NFM-P auxiliary collector(s) from the NFM-P database(s)

Protocol From port On To port On

TCP 1523 NFM-P database Any NFM-P auxiliary

collector(s)

TCP 9002 NFM-P database Any NFM-P auxiliary

collector(s)

When there is a firewall at the interface that reaches the NFM-P management network (NIC 1 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)), the following rules apply.

Table 6-54 Firewall rules for traffic coming into the NFM-P auxiliary collector(s) from the NFM-P server(s)

Protocol From port On To port On

TCP Any NFM-P server(s) 12300-12307 NFM-P auxiliary

collector(s)

TCP 12300-12307 NFM-P server(s) Any NFM-P auxiliary

collector(s)

TCP Any NFM-P server(s) 12800 NFM-P auxiliary

collector(s)

TCP 12800 NFM-P server(s) Any NFM-P auxiliary

collector(s)

Table 6-55 Firewall rules for traffic between redundant NFM-P auxiliary statistics collectors

Protocol From port On To port On

TCP Any NFM-P auxiliary 22 NFM-P auxiliary

statistics collector statistics collector

TCP Any NFM-P auxiliary 9010 NFM-P auxiliary

statistics collector statistics collector

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
158 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

Table 6-56 Firewall rules for traffic between redundant NFM-P auxiliary call trace collectors

Protocol From port On To port On

TCP Any NFM-P auxiliary call 22 NFM-P auxiliary call

trace collector trace collector

TCP Any NFM-P auxiliary call 9010 NFM-P auxiliary call

trace collector trace collector

6.10.5 NFM-P auxiliary database firewall rules

Apply the following firewall rules to the connection between the NFM-P auxiliary database and
various NFM-P components. Note that all connections are bi-directional. Since the inter-node
communication should traverse a private LAN, it is not recommended to implement a firewall on this
interface.

Table 6-57 Firewall rules for traffic between the NFM-P server and the NFM-P auxiliary database

Protocol From port On To port On Notes

TCP >32768 NFM-P server(s) 5433 NFM-P auxiliary JDBC

database(s)

TCP >32768 NFM-P server(s) 7299 (secure=true) NFM-P auxiliary RMI

7299-7309 database(s)
(secure=false)

Table 6-58 Firewall rules for traffic between the NFM-P auxiliary database(s) and NSP

Protocol From port On To port On

TCP >32768 NSP 5433 NFM-P auxiliary database(s)

TCP >32768 NSP 7299 (secure=true) NFM-P auxiliary database(s)

7299-7309 (secure=false)

Table 6-59 Firewall rules for traffic between the NFM-P auxiliary statistics collector and the NFM-P auxiliary
database

Protocol From port On To port On Notes

TCP >32768 Statistics 5433 NFM-P auxiliary JDBC

auxiliary(s) database(s)

Table 6-60 Firewall rules for traffic between the NSP Flow Collector and the NFM-P auxiliary database

Protocol From port On To port On Notes

TCP >32768 NSP Flow 5433 NFM-P auxiliary JDBC

Collector(s) database(s)

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 159
Security NSP
NFM-P firewall and NAT rules

Table 6-61 Firewall rules for traffic between the NSP analytics server and the NFM-P auxiliary database

Protocol From port On To port On Notes

TCP >32768 NSP analytics 5433 NFM-P auxiliary JDBC

server database(s)

Table 6-62 Firewall rules for traffic between NFM-P auxiliary database clusters

Protocol From port On To port On Notes

TCP >32768 NFM-P auxiliary 22 NFM-P auxiliary SFTP

database database(s)

TCP >32768 NFM-P auxiliary 50000 NFM-P auxiliary Rsync

database database(s)

6.10.6 NSP analytics server firewall rules

Apply the following firewall rules to the connection between the NSP analytics server and NFM-P
server / NFM-P client. Note that all connections are bi-directional.

Table 6-63 Firewall rules for traffic between the NFM-P server(s) and NSP analytics server

Protocol From port On To port On Notes

TCP >32768 NSP analytics 2181 NFM-P server(s) ZooKeeper

server(s)

TCP >32768 NSP analytics 2281 NFM-P server(s) ZooKeeper

server(s)

TCP >32768 NFM-P server(s) 8080 NSP analytics HTTP

server

TCP >32768 NFM-P server(s) 8443 NSP analytics HTTPS

server

Table 6-64 Firewall rules for traffic between the NFM-P client and NSP analytics server

Protocol From port On To port On Notes

TCP >32768 Client 8080 NSP analytics HTTP

server(s)

TCP >32768 Client 8443 NSP analytics HTTPS

server(s)

Apply the following firewall rules to the connection between the NSP analytics server and NSP
server when NFM-P is integrated with NSP. Note that all connections are bi-directional.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
160 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

Table 6-65 Firewall rules for traffic between the NSP analytics server and NSP

Protocol From port On To port On Notes

TCP >32768 NSP analytics 2181 NSP ZooKeeper

server(s)

TCP >32768 NSP analytics 2281 NSP ZooKeeper Secure

server(s)

6.10.7 NFM-P server to NFM-P client delegate server

Ensure that ICMP protocol traffic from the NFM-P server can reach the NFM-P client delegate
server.

6.10.8 NFM-P client to managed network communications

Apply the following changes to the connection between the NFM-P client and the managed
network. Note that all connections are bi-directional.

Table 6-66 Firewall rules for traffic between the NFM-P client and GNEs

Protocol From port On To port On Notes

TCP Any NFM-P client(s) 80 Managed network HTTP (See GNE vendor
for specifics)

TCP Any NFM-P client(s) 443 Managed network HTTPS (See GNE
vendor for specifics)

Table 6-67 Firewall rules for traffic between the NFM-P client (NEtO) and 9500 MPR / Wavence SM
(MSS-8/4/1)

Protocol From port On To port On Notes

TCP 20 NFM-P client(s) Any Managed network Active FTP

TCP Any NFM-P client(s) 21 Managed network FTP

TCP 21 NFM-P client Any Managed network FTP

TCP 22 NFM-P client Any Managed network sFTP

TCP Any NFM-P client 22 Managed network sFTP

TCP Any NFM-P client(s) 23 Managed network Telnet

TCP Any NFM-P client(s) 80 Managed network HTTP

UDP Any NFM-P client(s) 161 Managed network SNMP

TCP >1023 NFM-P client(s) >1023 Managed network Passive FTP

UDP 5010 NFM-P client(s) 5010 Managed network SNMP

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 161
Security NSP
NFM-P firewall and NAT rules

Table 6-68 Firewall rules for traffic between the NFM-P client (NEtO) and 9500 MPR / Wavence SM (MSS-1C /
MPR-e / MSS-8)

Protocol From port On To port On Notes

TCP 20 NFM-P client(s) Any Managed network Active FTP

TCP 21 NFM-P client Any Managed network FTP

TCP Any NFM-P client(s) 23 Managed network Telnet

UDP Any NFM-P client(s) 161 Managed network SNMP

TCP >1023 NFM-P client(s) >1023 Managed network Passive FTP

UDP 5010 NFM-P client Any Managed network SNMP

UDP Any NFM-P client 11500 Managed network Equipment View (GUI)

Table 6-69 Firewall rules for traffic between the NFM-P client (NEtO) and 9400 AWY

Protocol From port On To port On Notes

TCP Any NFM-P client(s) 21 Managed network FTP

TCP 21 NFM-P client Any Managed network FTP

TCP Any NFM-P client(s) 23 Managed network Telnet

TCP Any NFM-P client(s) 80 Managed network HTTP

UDP Any NFM-P client(s) 161 Managed network SNMP

TCP >1023 NFM-P client(s) >1023 Managed network Passive FTP

UDP 5010 NFM-P client Any Managed network SNMP

Table 6-70 Firewall rules for traffic between the NFM-P client and OmniSwitches

Protocol From port On To port On Notes

TCP Any NFM-P client(s) 80 Managed network HTTP

TCP Any NFM-P client(s) 443 Managed network HTTPS

6.10.9 NFM-P client to NSP

If NFM-P is integrated with NSP, the following firewall rules must be implemented on the NFM-P
client. Note that all connections are bi-directional.

Table 6-71 Firewall rules for traffic between the NFM-P client and NSP

Protocol From port On To port On Notes

TCP Any NFM-P client(s) 80 NSP HTTP

TCP Any NFM-P client(s) 443 NSP HTTPS

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
162 3HE-18161-AAAB-TQZZA Issue 1
Security NSP
NFM-P firewall and NAT rules

6.10.10 NFM-P to pki-server

If the pki-server is used for TLS certificate generation, the NFM-P server, NFM-P auxiliary servers,
NSP analytics server, and NSP Flow Collector require the following firewall rules:

Table 6-72 Firewall rules for traffic between NFM-P and the server hosting the pki-server

Protocol From port On To port On Notes

TCP Any NFM-P 2391 Server hosting default port

pki-server

TCP 2391 Server hosting Any NFM-P default port

pki-server

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 163
Security NSP
NFM-P firewall and NAT rules

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
164 3HE-18161-AAAB-TQZZA Issue 1
NSP deployment with multiple network interfaces and IP addresses NSP
Support for multiple network interfaces

7 NSP deployment with multiple network interfaces

and IP addresses

7.1 Support for multiple network interfaces

7.1.1 Introduction
The NSP and its associated components communicate with different entities that typically exist in
different network spaces. Isolating different types of traffic to different networks provides better
security and helps manage traffic volume on different networks.

NSP supports configuring different network interfaces to handle the following types of traffic in a
multi-homed system.
• A client network interface can be used for connecting users to NSP GUI and to connect external
OSS systems to NSP.
• An internal network interface can be used to handle traffic between NSP systems that does not
need to be accessed by external systems or with managed network elements. Internal traffic
includes, but is not limited to, resync of network topology information, security communications,
application registration and data synchronization between redundant components.
• A mediation network interface can be used to communicate with network elements (provisioning,
NE database backups, monitoring, operations, etc).

7.1.2 Component support and limitations

A NSP cluster can be configured with network interfaces for client traffic, for internal network
management traffic, and for managed network traffic. In a multi-node NSP cluster, each node must
have the same number of interfaces. A deployer node must be available to the NSP cluster nodes
on the internal network.
A NSP cluster must communicate with a VSR-NRC using the BOF interface.
The NFM-P supports integrated deployment with NSP cluster using network interfaces for client,
internal and managed network traffic.
An integrated deployment of multi-interface NSP cluster with an older release NFM-P is supported
but a workaround procedure is required on the NFM-P system. The workaround will enable the
separation of client and internal network traffic between NFM-P and NSP cluster. See the NSP
Installation and Upgrade Guide for details on the integration procedure for older release NFM-P.
The following figure shows a multi network interface deployment of NSP cluster, deployer host and
NFM-P.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 165
NSP deployment with multiple network interfaces and IP addresses NSP
Support for multiple network interfaces

Figure 7-1 Multi-interface NSP deployment

Client

NSP NFM-P Deployer

Network
elements

client network
internal network
managed network nic1 nic2 nic3 nic

36809

The NSP cluster can be deployed with one interface for all client, network management and NE
traffic. The NSP cluster can be deployed with one interface for client and internal network traffic,
and a second interface for NE traffic. All servers in an NSP deployment must support the same
network configuration for client and internal networks. For example, an NSP cluster deployed with
network interfaces for client and internal networks cannot be deployed with a NFMP server that is
configured for one interface supporting client and internal communications.
When installing NSP components on stations with multiple network interfaces, each interface must
reside on a separate subnet, with the exception of interfaces that are to be used in IP Bonding.
There is no requirement on the NSP cluster to use the first network interface (eg. eth0, bge0) to
communicate with client applications.
Additional network interfaces can be configured on the NSP cluster, at the customer's discretion, for
other operations such as archiving database backups or activity logs.
When an NSP cluster is deployed with NFM-T, the separation of client and internal network traffic is
not supported. NSP and NFM-T must use a single network for client and internal communications.
When using custom TLS certificates in a multi-network configuration, the NSP server certificate
requires the IP address or hostname or FQDN of the client network interface (or virtual IP) and the
IP address or hostname or FQDN of the internal network interface (or virtual IP) in the certificate
SAN field (ref parameters advertisedAddress and internalAdvertisedAddress in nsp-config.yml).

7.1.3 Multi-interface support in IPv4 and IPv6 networks

The NSP cluster can use IPv4 or IPv6 addressing on the client, internal and mediation network
interfaces. In addition to the limitations and restrictions documented in section 4.2.1, the following
conditions apply:
• The NSP cluster can only use IPv4 or IPv6 communications on the client network interface and

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
166 3HE-18161-AAAB-TQZZA Issue 1
NSP deployment with multiple network interfaces and IP addresses NSP
Support for multiple network interfaces

on the internal network interface. The system network interfaces can have both IPv4 and IPv6
addresses assigned, but NSP communications on those interfaces can only use IPv4 or IPv6.
• The NSP cluster mediation interface supports IPv4 only, IPv6 only and IPv4 and IPv6
simultaneously. When NSP is configured with IPv4 and IPv6 mediation simultaneously, the NSP
must have a dedicated mediation interface not shared with client and internal network
communications.
• In an NSP deployment with separate network interfaces for client and internal communications,
the client and internal networks must both use IPv4 or IPv6 addressing. Example, client
communications on IPv4 and internal communications on IPv6 is not supported.

7.1.4 Multi-interface NSP deployment and firewalls

Customers can use firewall applications to protect NSP components but should be applied with care
to ensure that NSP applications are not negatively impacted. NSP firewall rules are defined in
Section 6.7 of this guide but need to be applied on the correct networks and network interfaces.
The following table summarizes the firewall rules for an NSP cluster deployment by each network or
network interface.

Table 7-1 NSP cluster firewall communications by network interface

Network description Permitted communications

Client network Client communications as defined in Table 6-1, “NSP Kubernetes virtual
machine communications” (p. 117)
Kafka communications on ports 9092, 9093, 9094, 9192, 9193, 9194
Internal network All communications with NFMP and with redundant datacenter
All communications between cluster nodes and deployer node
Kafka communications on ports 9292, 9293, 9294
Mediation network Mediation communications as defined in Table 6-1, “NSP Kubernetes
virtual machine communications” (p. 117)

The NSP cluster can communicate with some external components on any network interface,
including
• remote authentication servers (LDAP, RADIUS, TACACS)
• VSR-NRC
• syslog server
• email server
Each node in an NSP cluster must allow the same traffic on each network interface.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 167
NSP deployment with multiple network interfaces and IP addresses NSP
NSP Network Address Translation

7.2 NSP Network Address Translation

7.2.1 Overview

NSP supports the use of Network Address Translation (NAT) between the following components:
• NSP cluster and clients (web application users, REST API clients)
• NSP cluster and network elements
• NSP cluster and other components in the NSP deployment (eg. NFM-P)
NSP does not support the use of NAT between nodes within an NSP cluster deployment, including
the deployer host.

7.3 NFM-P multihoming

7.3.1 Overview
The NFM-P server and NFM-P auxiliary collector components of the application communicate with
very different entities: a managed network, a collection of clients (GUIs and XML API), and between
each other. Since the entities may exist in very different spaces, Nokia recognizes the importance of
separating these different types of traffic. Nokia therefore supports configuring the NFM-P server
and NFM-P auxiliary such that it uses different network interfaces (IP addresses) to manage the
network and to service the requirements of the NFM-P clients.
The NFM-P server uses an internal communications system (JGroups/JMS) to handle bi-directional
access to the NFM-P server for the NFM-P clients and the NFM-P auxiliary collectors. In NFM-P,
this communication system can be configured to allow the NFM-P clients and NFM-P auxiliary
collectors to communicate using different network interfaces on the NFM-P server. This adds
significant flexibility when isolating the different types of traffic to the NFM-P server. If using this
mode, special attention must be paid to the firewall rules on the network interfaces on the NFM-P
server and NFM-P auxiliary collectors (NICs 1 and NICs 3 on Figure 7-3, “Distributed NFM-P
server/database deployment with multiple network interfaces” (p. 170)).
It is a security requirement that all IP communications from an NFM-P auxiliary collector to the
NFM-P main server use only one IP address. This IP Address must be the same IP address as the
auxiliary collector IP address configured when installing the main server. Any other IP
communications originating from a different IP address on the auxiliary collector will be rejected by
the NFM-P main server.
When installing NFM-P components on stations with multiple interfaces, each interface must reside
on a separate subnet, with the exception of interfaces that are to be used in IP Bonding.
Figure 7-2, “Collocated NFM-P server/database deployment with multiple network interfaces”
(p. 169) illustrates a collocated NFM-P server/database deployment where the NFM-P is configured
to actively use more than one network interface.
It is not necessary to use the first network interface on the NFM-P server station (for example ce0,
bge0) to communicate with the NFM-P GUI clients.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
168 3HE-18161-AAAB-TQZZA Issue 1
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P multihoming

Figure 7-2 Collocated NFM-P server/database deployment with multiple network interfaces

bge0

NFM-P server/
database NFM-P Clients
bge1

Managed
network

22666

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 169
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P multihoming

Figure 7-3 Distributed NFM-P server/database deployment with multiple network interfaces

NFM-P
clients

NIC 3 Switch/ Switch/ NIC 3

Router Router
NFM-P NFM-P
NIC 2 server NIC 1 NIC 1 server NIC 2
active standby
NIC 4 NIC 4

NFM-P NFM-P
database NIC 1 NIC 1 database
active standby

NFM-P auxiliary database cluster

NIC 5
NIC 5

NIC 5
NIC 1

NIC 3 NIC 3
NSP flow NSP flow
collector
controller
NIC 1 NIC 1 collector
controller
active standby

NIC 3 NIC 3
NSP flow NSP flow
NIC 2 collector NIC 1 NIC 1 collector NIC 2

NIC 4 NIC 4

NIC 3 NIC 3
NFM-P NFM-P
NIC 2 auxiliary NIC 1 NIC 1 auxiliary NIC 2

NIC 4 NIC 4

Switch/ IPv4 Managed Switch/

Router network Router

Switch/ IPv6 Managed Switch/

Router network Router
36722

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
170 3HE-18161-AAAB-TQZZA Issue 1
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P multihoming

Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170) illustrates a distributed, redundant NFM-P deployment where the NFM-P components are
configured to actively use more than one network interface.
Due to limitations with the inter-process and inter-station communication mechanisms, a specific
network topology and the use of hostnames is required (see 7.5 “Use of hostnames for the NFM-P
client” (p. 177)). Contact an Nokia representative to obtain further details.

7.3.2 NFM-P server multiple IP addresses deployment scenarios

The NFM-P server supports the configuration of different IP addresses for the following purposes:
• One or multiple network interfaces can be used to manage the network. (NIC 2 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)) This
network interface contains the IP address that the managed devices will use to communicate
with the NFM-P server and NFM-P auxiliary. If managing a network element with both an in-band
and out-of-band connection, the same network interface on the NFM-P server must be used for
both communication types.
• One network interface can be used to service the requirements of the NFM-P clients (GUIs and
XML API) (NIC 3 on Figure 7-3, “Distributed NFM-P server/database deployment with multiple
network interfaces” (p. 170)). This network interface contains the IP address that all clients (GUIs
and XML API) will use to communicate with the NFM-P server. All clients (GUIs and XML API)
must be configured to use the same IP address to communicate to the NFM-P server. This IP
address can be different from the one used by the managed devices to communicate with the
NFM-P server. Each client can use the hostname to communicate with the NFM-P server, where
the hostname could map to different IP addresses on the NFM-P server - for example, some
clients could connect over IPv4 and some over IPv6. In this scenario, the NFM-P server must be
configured for clients to use hostname and not IP.
• One network interface can be used to communicate with the NFM-P database, NFM-P auxiliary
database, and NFM-P auxiliary collectors as well as any redundant NFM-P components should
they be present (NIC 1 on Figure 7-3, “Distributed NFM-P server/database deployment with
multiple network interfaces” (p. 170)). This network interface contains the IP address that the
NFM-P database, NFM-P auxiliary database, and redundant NFM-P components will use to
communicate with the NFM-P server. This IP address can be different from the addresses used
by the NFM-P clients and the managed devices to communicate with the NFM-P server.
• In a redundant NFM-P installation, the NFM-P servers and NFM-P auxiliary collectors must have
IP connectivity to the NFM-P server peer.
• Additional network interfaces may be configured on the NFM-P server station, at the customer’s
discretion, to perform maintenance operations such as station backups.
• IPv4 and IPv6 network elements can be managed from the same interface or from separate
interfaces. (NIC2 and/or NIC4 on Figure 7-3, “Distributed NFM-P server/database deployment
with multiple network interfaces” (p. 170)).

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 171
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P multihoming

7.3.3 NFM-P auxiliary statistics collector multiple IP addresses deployment

scenarios

The NFM-P auxiliary statistics collector supports the configuration of different IP addresses for the
following purposes:
• One or multiple network interfaces can be used to retrieve information from the managed
network. (NIC 2 on Figure 7-3, “Distributed NFM-P server/database deployment with multiple
network interfaces” (p. 170)) This network interface contains the IP address that the managed
devices will use to retrieve the accounting statistics files, and performance statistics from the
network elements.
• One network interface can be used to service the requirements of the XML API clients (NIC 3 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)). This network interface contains the IP address that all XML API clients will use to
communicate with the NFM-P auxiliary statistics collector. XML API clients will use this IP
address to retrieve the logToFile statistics collection data from the NFM-P auxiliary statistics
collector.
• One network interface can be used to communicate with the NFM-P server, NFM-P database,
NFM-P auxiliary database cluster as well as any redundant NFM-P components should they be
present (NIC 1 on Figure 7-3, “Distributed NFM-P server/database deployment with multiple
network interfaces” (p. 170)). This network interface contains the IP address that the NFM-P
server, NFM-P database, NFM-P auxiliary database, and redundant NFM-P components will use
to communicate with the NFM-P auxiliary statistics collector. This IP address can be different
from the addresses used by the NFM-P XML API clients and the managed devices to
communicate with the NFM-P auxiliary statistics collector.
• In a redundant NFM-P installation, the NFM-P auxiliary statistics collector must have IP
connectivity to the NFM-P server peer.
• Additional network interfaces may be configured on the NFM-P auxiliary statistics collector
station, at the customer’s discretion, to perform maintenance operations such as station
backups.
• IPv4 and IPv6 network elements can be managed from the same interface or from separate
interfaces. (NIC2 and/or NIC4 on Figure 7-3, “Distributed NFM-P server/database deployment
with multiple network interfaces” (p. 170)).

7.3.4 NFM-P auxiliary call trace collector multiple IP addresses deployment

scenarios
The NFM-P auxiliary call trace collector supports the configuration of different IP addresses for the
following purposes:
• One network interface can be used to retrieve information from the managed network. (NIC 2 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)) This network interface contains the IP address that the managed devices will use to
send the call trace messages from the network elements.
• One network interface can be used to service the requirements of the 9958 WTA client (NIC 3 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)). This network interface contains the IP address that all clients will use to communicate

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
172 3HE-18161-AAAB-TQZZA Issue 1
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P multihoming

with the NFM-P auxiliary call trace collector. 9958 WTA will use this IP address to retrieve the call
trace data from the NFM-P auxiliary call trace collector.
• One network interface can be used to communicate with the NFM-P management complex as
well as any redundant NFM-P components should they be present (NIC 1 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)). This
network interface contains the IP address that the NFM-P management complex components
will use to communicate with the NFM-P auxiliary call trace collector. If a redundant NFM-P
auxiliary call trace collector is present, this network interface will also be used to sync call trace
and debug trace data collected from the network, with the peer NFM-P auxiliary call trace
collector. This IP address can be different from the addresses used by the 9958 WTA clients and
the managed devices to communicate with the NFM-P server.
• In a redundant NFM-P installation, the NFM-P auxiliary call trace collector must have IP
connectivity to the NFM-P server peer.
• Additional network interfaces may be configured on the NFM-P auxiliary call trace collector
station, at the customer’s discretion, to perform maintenance operations such as station
backups.

7.3.5 NSP Flow Collector Controller multiple IP addresses deployment scenarios

The NSP Flow Collector supports the configuration of different IP addresses for the following
purposes:
• One network interface can be used to communicate with the NFM-P management complex as
well as any redundant NFM-P components, should they be present (NIC 1 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)) This
network interface contains the IP address that the NFM-P management complex components
will use to communicate with the NSP Flow Collector Controller. This IP address can be different
from the addresses used by the clients and the managed devices to communicate with the
NFM-P server. If the NSP deployment includes NSP, this is the network interface that would be
used for communication.
• One network interface can be used to communicate with the clients (NIC 3 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)) This
network interface contains the IP address that the user will connect to with the web management
interface.
• In a redundant NFM-P installation, the NSP Flow Collector Controller must have IP connectivity
to the NFM-P server peer.
• Additional network interfaces may be configured on the NSP Flow Collector Controller station, at
the customer’s discretion, to perform maintenance operations such as station backups.

7.3.6 NSP Flow Collector multiple IP addresses deployment scenarios

The NSP Flow Collector supports the configuration of different IP addresses for the following
purposes:
• One network interface can be used to communicate with the NSP Flow Collector Controller (NIC
1 on Figure 7-3, “Distributed NFM-P server/database deployment with multiple network
interfaces” (p. 170)) This network interface contains the IP address that the NSP Flow Collector
Controller and NFM-P server will use to communicate with the NSP Flow Collector(s). This IP

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 173
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P multihoming

address can be different from the addresses used by the clients and the managed devices to
communicate with the NFM-P server. If the NSP deployment includes either NSP, this is the
network interface that would be used for communication.
• One network interface can be used to retrieve information from the managed network. (NIC 2
and/or NIC 4 on Figure 7-3, “Distributed NFM-P server/database deployment with multiple
network interfaces” (p. 170)). This network interface contains the IP address that the managed
devices will use to send the cflowd flow data from the network elements.
• One network interface can be used to communicate with the clients (NIC 3 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)) This
network interface contains the IP address that the user will connect to with the web management
interface.
• One network interface can be used to send the formatted IPDR files to the target file server (NIC
4 on Figure 7-3, “Distributed NFM-P server/database deployment with multiple network
interfaces” (p. 170)). This network interface contains the IP address that all clients will use to
communicate with the NSP Flow Collector.
• In a redundant NFM-P installation, the NSP Flow Collector must have IP connectivity to the
NFM-P server peer.
• Additional network interfaces may be configured on the NSP Flow Collector station, at the
customer’s discretion, to perform maintenance operations such as station backups.

7.3.7 NFM-P auxiliary PCMD collector multiple IP addresses deployment scenarios

The NFM-P auxiliary PCMD collector supports the configuration of different IP addresses for the
following purposes. To meet scaling targets a minimum of two separate interfaces must be used —
one for management traffic and one for PCMD data collection:
• One network interface can be used to retrieve information from the managed network. (NIC 2 on
Figure 7-3, “Distributed NFM-P server/database deployment with multiple network interfaces”
(p. 170)) This network interface contains the IP address that the managed devices will use to
send the PCMD data from the network elements.
• One network interface can be used for retrieval of the formatted PCMD files by the target file
server (NIC 3 on Figure 7-3, “Distributed NFM-P server/database deployment with multiple
network interfaces” (p. 170)). This network interface contains the IP address that all clients will
use to communicate with the NFM-P auxiliary PCMD collector.
• One network interface can be used to communicate with the NFM-P management complex as
well as any redundant NFM-P components should they be present (NIC 1 on Figure 7-3,
“Distributed NFM-P server/database deployment with multiple network interfaces” (p. 170)). This
network interface contains the IP address that the NFM-P management complex components
will use to communicate with the NFM-P auxiliary PCMD collector. This IP address can be
different from the addresses used by the clients and the managed devices to communicate with
the NFM-P server.
• In a redundant NFM-P installation, the NFM-P auxiliary PCMD collector must have IP
connectivity to the NFM-P server peer.
• Additional network interfaces may be configured on the NFM-P auxiliary PCMD collector station,
at the customer’s discretion, to perform maintenance operations such as station backups.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
174 3HE-18161-AAAB-TQZZA Issue 1
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P Network Address Translation

7.4 NFM-P Network Address Translation

7.4.1 Network Address Translation deployment scenarios

NFM-P supports the use of Network Address Translation (NAT) between the following components:
• The NFM-P server and NFM-P clients (GUIs or XML API)
• The NFM-P auxiliary server and NFM-P XML API clients
• The NFM-P server and the managed network
• The NFM-P auxiliary statistics collector and the managed network
• The NFM-P auxiliary PCMD collector and the managed network
The figure below illustrates a deployment of NFM-P where NAT is used between the NFM-P server
and the managed network.

Figure 7-4 NFM-P server deployments with NAT between the server and the managed network

Private Public
NFM-P network network
server

Managed
NFM-P network
auxiliary NAT-Enabled
firewall

NFM-P
database 22664

Note: Network Address Translation is not supported between the NFM-P auxiliary call trace
collector and the managed network.
The following two figures illustrates a deployment of NFM-P where NAT is used between the
NFM-P server and the NFM-P clients (GUIs, XML API or client delegate servers). In Figure 7-5,
“NFM-P server deployment using NAT with IP Address communication” (p. 176), NFM-P clients on
the private side and public side of the NAT-Enabled Firewall must connect to the public IP address
of the NFM-P server. A routing loopback from the NFM-P server private IP address to the NFM-P
server public IP address must be configured in this scenario as all NFM-P clients must
communicate to the NFM-P server through the NFM-P server public IP address.
The NFM-P auxiliary will need to be able to connect to the public IP address of the NFM-P server.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 175
NSP deployment with multiple network interfaces and IP addresses NSP
NFM-P Network Address Translation

Figure 7-5 NFM-P server deployment using NAT with IP Address communication

Routing loopback
required for NFM-P
server

Private Public
network network

NFM-P
server

NFM-P client
must connect
to NFM-P server
NAT-Enabled public IP address
NFM-P client firewall
must connect
to NFM-P server
public IP address
22663

Figure 7-6 NFM-P server deployment using NAT with name resolution based communication

No routing loopback
required for NFM-P
server

Private Public
network network

NFM-P
server

NFM-P client
must connect
to NFM-P server
NAT-Enabled by hostname
NFM-P client firewall
must connect
to NFM-P server
by hostname
22662

In Figure 7-6, “NFM-P server deployment using NAT with name resolution based communication”
(p. 176), a name resolution service on the public side of the NAT-Enabled Firewall is configured to
resolve the NFM-P server hostname to the public IP address of the NFM-P server. Name resolution
service on the private side of the NAT-Enabled Firewall is configured to resolve the NFM-P server
hostname to the private IP address of the NFM-P server. clients on both sides of the NAT-Enabled
Firewall are configured to communicate with the NFM-P server via hostname where the NFM-P
server hostname must be the same on both sides of the NAT-Enabled Firewall.
The figure below illustrates a deployment of NFM-P where NAT is used between the NFM-P
complex, NFM-P clients, and the managed network.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
176 3HE-18161-AAAB-TQZZA Issue 1
NSP deployment with multiple network interfaces and IP addresses NSP
Use of hostnames for the NFM-P client

Figure 7-7 NFM-P deployment with NAT

NFM-P
client

Active NAT-Enabled firewall Standby

NFM-P Private NFM-P

server network server

NFM-P NFM-P
auxiliary auxiliary

NFM-P NAT-Enabled firewall NFM-P

database database

Managed
network
22661

For installations using NAT between the NFM-P server and NFM-P client, a reverse DNS look-up
mechanism must be used for the client, to allow proper startup.
NAT rules must be in place before NFM-P installation can occur, since the installation scripts will
access other systems for configuration purposes.

Note: Network Address Translation is not supported between the NFM-P auxiliary call trace
collector and the managed network.

7.5 Use of hostnames for the NFM-P client

7.5.1 Hostnames usage scenarios

The following scenarios identify situations where it is necessary for the NFM-P client to be
configured to use a hostname rather than a fixed IP address to reach the NFM-P server:
• When CA signed TLS certificates are used, the FQDN must be used for client communication.

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 177
NSP deployment with multiple network interfaces and IP addresses NSP
Use of hostnames for the NFM-P client

• When NFM-P clients can connect to the NFM-P server over multiple interfaces on the NFM-P
server. For example, when clients can connect over both IPv4 and IPv6 interfaces.
• When NAT is used between NFM-P clients and the NFM-P server.
• For situations where the NFM-P client and the NFM-P auxiliary (and/or NFM-P peer server) are
using different network interfaces to the NFM-P server, the NFM-P client must use a hostname to
reach the NFM-P server.

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
178 3HE-18161-AAAB-TQZZA Issue 1
Appendix A NSP
Storage-layer I/O performance tests

8 Appendix A

8.1 Storage-layer I/O performance tests

8.1.1 Introduction
Use the commands in this section to determine if the storage-layer performance meets the NSP
cluster deployment recommendations.

8.1.2 Determine disk speed

In this example, the /test directory is on the same disk where etcd runs.
Enter the following as the root user to run the test:
# fio --rw=write --ioengine=sync --fdatasync=1 --directory=/var/lib/test
--size=22m --bs=2300 --name=mytest ↵
The command produces output like the following:
Starting 1 process
mytest: Laying out IO file (1 file / 22MiB)
Jobs: 1 (f=1)
mytest: (groupid=0, jobs=1): err= 0: pid=40944: Mon Jun 15 10:23:23 2020
write: IOPS=7574, BW=16.6MiB/s (17.4MB/s)(21.0MiB/1324msec)
clat (usec): min=4, max=261, avg= 9.50, stdev= 4.11
lat (usec): min=4, max=262, avg= 9.67, stdev= 4.12
clat percentiles (nsec):
| 1.00th=[ 5536], 5.00th=[ 5728], 10.00th=[ 5920], 20.00th=[
6176],
| 30.00th=[ 7584], 40.00th=[ 8896], 50.00th=[ 9408], 60.00th=[
9792],
| 70.00th=[10432], 80.00th=[11584], 90.00th=[12864], 95.00th=
[14528],
| 99.00th=[20352], 99.50th=[23168], 99.90th=[28800], 99.95th=
[42752],
| 99.99th=[60672]
bw ( KiB/s): min=16868, max=17258, per=100.00%, avg=17063.00,
stdev=275.77, samples=2
iops : min= 7510, max= 7684, avg=7597.00, stdev=123.04,
samples=2

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 179
Appendix A NSP
Storage-layer I/O performance tests

lat (usec) : 10=64.21%, 20=34.68%, 50=1.08%, 100=0.02%, 500=0.01%

In the second block of output, which is shown below, the 99th percentile durations must be less
than 10 ms. In this block, each durations is less than 1 ms.
fsync/fdatasync/sync_file_range:
sync (usec): min=39, max=1174, avg=120.71, stdev=63.89
sync percentiles (usec):
| 1.00th=[ 42], 5.00th=[ 45], 10.00th=[ 46], 20.00th=[
48],
| 30.00th=[ 52], 40.00th=[ 71], 50.00th=[ 153], 60.00th=[
159],
| 70.00th=[ 167], 80.00th=[ 178], 90.00th=[ 192], 95.00th=[
206],
| 99.00th=[ 229], 99.50th=[ 239], 99.90th=[ 355], 99.95th=[
416],
| 99.99th=[ 445]
cpu : usr=2.95%, sys=29.93%, ctx=15663, majf=0, minf=35
IO depths : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued rwts: total=0,10029,0,0 short=10029,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1

8.1.3 Determine read / write IOPS

To run this test, first change to the directory where the test is to be performed. The test will create a
local file. The output from the command contains read and write IOPS values.
Enter the following as the root user to run the test:
# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1
--name=test --filename=random_read_write.fio --bs=4k --iodepth=64
--size=4G --readwrite=randrw --rwmixread=50 ↵
The command produces output like the following:
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T)
4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 process

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
180 3HE-18161-AAAB-TQZZA Issue 1
Appendix A NSP
Storage-layer I/O performance tests

test: Laying out IO file (1 file / 4096MiB)

Jobs: 1 (f=1): [m(1)][100.0%][r=22.1MiB/s,w=22.2MiB/s][r=5645,w=5674
IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=32439: Mon Sep 21 10:25:11 2020
read: IOPS=6301, BW=24.6MiB/s (25.8MB/s)(2049MiB/83252msec)
bw ( KiB/s): min=13824, max=39088, per=99.57%, avg=25098.60,
stdev=5316.27, samples=166
iops : min= 3456, max= 9772, avg=6274.49, stdev=1329.11,
samples=166
write: IOPS=6293, BW=24.6MiB/s (25.8MB/s)(2047MiB/83252msec)
bw ( KiB/s): min=13464, max=40024, per=99.56%, avg=25062.73,
stdev=5334.65, samples=166
iops : min= 3366, max=10006, avg=6265.57, stdev=1333.67,
samples=166
cpu : usr=5.13%, sys=18.63%, ctx=202387, majf=0, minf=26
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%,
>=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%,
>=64=0.0%
issued rwts: total=524625,523951,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=24.6MiB/s (25.8MB/s), 24.6MiB/s-24.6MiB/s (25.8MB/s-25.
8MB/s), io=2049MiB (2149MB), run=83252-83252msec
WRITE: bw=24.6MiB/s (25.8MB/s), 24.6MiB/s-24.6MiB/s (25.8MB/s-25.
8MB/s), io=2047MiB (2146MB), run=83252-83252msec
Disk stats (read/write):
vda: ios=523989/526042, merge=0/2218, ticks=3346204/1622070,
in_queue=4658999, util=96.06%

Release 22.6 © 2022 Nokia.

June 2022 Use subject to Terms available at: www.nokia.com/terms
Issue 1 3HE-18161-AAAB-TQZZA 181
Appendix A NSP
Storage-layer I/O performance tests

© 2022 Nokia. Release 22.6

Use subject to Terms available at: www.nokia.com/terms
June 2022
182 3HE-18161-AAAB-TQZZA Issue 1