installation and upgrade guide - nokia networks network services platform network resource...

NSPNetwork Services PlatformNetwork Resource Controller - Flow (NRC-F)Network Resource Controller - Packet (NRC-P)Network Resource Controller - Transport (NRC-T)Network Resource Controller - Cross domain (NRC-X)Network Services Director

Release 17.12

Installation and Upgrade Guide

3HE-13354-AAAC-TQZZA

Issue 1

December 2017

Nokia – Proprietary and ConfidentialUse pursuant to applicable agreements

Legal notice

Nokia is a registered trademark of Nokia Corporation. Other products and company names mentioned herein may be trademarks ortradenames of their respective owners.

The information presented is subject to change without notice. No responsibility is assumed for inaccuracies contained herein.

© 2017 Nokia.

Contains proprietary/trade secret information which is the property of Nokia and must not be made available to, or copied or used byanyone outside Nokia without its written authorization.

Not to be used or disclosed except in accordance with applicable agreements.

NSD | NRC



Release 17.12December 2017

2 Issue 1

Contents

About this document............................................................................................................................................6

1 Safety information..........................................................................................................................................7

1.1 Structure of safety statements ............................................................................................................7

2 Getting started................................................................................................................................................9

2.1 Introduction .........................................................................................................................................9

2.2 RHEL OS installation requirements.....................................................................................................9

2.3 Partitioning ........................................................................................................................................15

2.4 To configure the VSR-NRC ...............................................................................................................16

2.5 To port existing NSD and NRC users during an upgrade..................................................................20

3 Standalone installation and upgrade .........................................................................................................25

3.1 Introduction .......................................................................................................................................25

3.2 To install a standalone NSD and NRC system..................................................................................25

3.3 To upgrade a standalone NSD and NRC system..............................................................................29

4 Redundant installation and upgrade..........................................................................................................33

4.1 Introduction .......................................................................................................................................33

4.2 To install a redundant NSD and NRC system ...................................................................................33

4.3 To upgrade a redundant NSD and NRC system ...............................................................................36

4.4 To convert a standalone NSD and NRC system to a redundant NSD and NRC system ..................39

4.5 To migrate from an NSD and NRC system in HA mode to a redundant NSD and NRC system.......41

5 Post-installation activities...........................................................................................................................45

5.1 Introduction .......................................................................................................................................45

5.2 To add the NSD and NRC modules to an existing NFM-P system....................................................45

5.3 To add the NSD and NRC modules to an existing NFM-T system....................................................49

5.4 To retroactively add a license to the NSD and NRC .........................................................................54

5.5 To enable TCAs for NRC-F ...............................................................................................................55

5.6 To install required NFM-P templates .................................................................................................55

5.7 To disable websocket event notifications ..........................................................................................56

5.8 To uninstall an NSD and NRC system ..............................................................................................57

6 Security .........................................................................................................................................................59

6.1 Introduction .......................................................................................................................................59

6.2 To configure the NSP security statement ..........................................................................................59

6.3 To generate a keystore......................................................................................................................60

Contents NSD | NRC

Release 17.12December 2017Issue 1 3



6.4 To generate a Root CA......................................................................................................................61

6.5 To enable SSL communication to the NFM-P ...................................................................................62

6.6 To enable SSL communication to the NSD and NRC ......................................................................64

6.7 To enable SSL communication to the NFM-P using a non-custom certificate...................................66

6.8 To enable SSL communication to the NFM-T using a custom certificate ..........................................67

6.9 To retroactively enable SSL communication to the NFM-P ...............................................................67

7 Backup and restore......................................................................................................................................69

7.1 Introduction .......................................................................................................................................69

7.2 To manually backup the PostgreSQL and Neo4j databases .............................................................69

7.3 To restore the PostgreSQL and Neo4j databases.............................................................................70

Contents NSD | NRC




4 Issue 1

List of tablesTable 2-1 Required OS packages from default RHEL repository or ISO image.............................................11

Table 2-2 Required OS packages from RHEL optional package repository ..................................................13

Table 2-3 RHEL OS packages to remove ......................................................................................................14

Table 2-4 NSD and NRC live and lab partitioning scheme ............................................................................15

Table 3-1 NSD and NRC configuration file parameters .................................................................................27

List of tables NSD | NRC




About this document

Purpose

The NSP NSD and NRC Installation and Upgrade Guide provides detailed information regarding theinstallation and upgrade of both standalone and redundant NSD and NRC systems, including pre-and post-installation activities.

Safety information

For your safety, this document contains safety statements. Safety statements are given at pointswhere risks of damage to personnel, equipment, and operation may exist. Failure to follow thedirections in a safety statement may result in serious consequences.

Document support

Customer documentation and product support URLs:

• Customer Documentation Welcome Page

• Technical support

How to comment

Documentation feedback

• Documentation Feedback

About this document NSD | NRC




6 Issue 1

https://infoproducts.alcatel-lucent.com/cgi-bin/doc_welc.pl

http://support.alcatel-lucent.com

mailto:[email protected]

1 Safety information

1.1 Structure of safety statements

1.1.1 Overview

This topic describes the components of safety statements that appear in this document.

1.1.2 General structure

Safety statements include the following structural elements:

Item Structure element Purpose

1 Safety alert symbol Indicates the potential for personal injury(optional)

2 Safety symbol Indicates hazard type (optional)

3 Signal word Indicates the severity of the hazard

4 Hazard type Describes the source of the risk of damage orinjury

5 Safety message Consequences if protective measures fail

6 Avoidance message Protective measures to take to avoid the hazard

7 Identifier The reference ID of the safety statement(optional)

SAMPLELifting this equipment by yourself can result in injurydue to the size and weight of the equipment.

Always use three people or a lifting device to transportand position this equipment. [ABC123]

CAUTION

Lifting hazard

Safety informationStructure of safety statements

NSD | NRC




1.1.3 Signal words

The signal words identify the hazard severity levels as follows:

Signal word Meaning

DANGER Indicates an extremely hazardous situation which, if not avoided, willresult in death or serious injury.

WARNING Indicates a hazardous situation which, if not avoided, could result indeath or serious injury.

CAUTION Indicates a hazardous situation which, if not avoided, could result inminor or moderate injury.

NOTICE Indicates a hazardous situation not related to personal injury.

Safety informationStructure of safety statements

NSD | NRC




8 Issue 1

2 Getting started

2.1 Introduction

2.1.1 Overview

This chapter provides information and procedures that may need to be understood/performed priorto installing or upgrading an NSD and NRC system.

2.2 RHEL OS installation requirements

2.2.1 Introduction

This section describes the RHEL OS installation requirements for an NSD and NRC system.

Each NSD and NRC server requires the following:

• a specific RHEL Software Selection as the base environment

• the installation and removal of specific OS packages

Note: The RHEL rpm utility requires hardware driver files in binary format. If the RHEL driverfiles provided by your server hardware vendor are in source rpm format, you may need toinstall additional packages in order to compile the files into binary format. See the stationhardware documentation for information.

2.2.2 Using the yum utility

To simplify package management, it is recommended that you use the RHEL yum utility to installand remove OS packages.

The package installation syntax is the following:

yum -y install package_1 package_2 ... package_n ↵

The package removal syntax is the following:

yum -y remove package_1 package_2 ... package_n ↵

Note: Package installation using yum requires a yum repository. The following repositorytypes are available:

• local repository, which you can create during the RHEL OS installation

• Internet-based repository, which you can access after you register with the Red HatNetwork

See the RHEL documentation for information about setting up a yum repository.

Note: If a package has dependencies on one or more additional packages that are not listedin a table, the yum utility installs the additional packages.

Getting startedIntroduction

NSD | NRC




2.2.3 Description

During the RHEL OS installation for an NSD and NRC server, you must do the following.

• Specify “Minimal Install” as the Software Selection in the RHEL installer.

• Install specific OS packages, as described in 2.2.4 “RHEL OS packages to install” (p. 9)

• Remove specific OS packages, as described in 2.2.5 “ RHEL OS packages to remove” (p. 13)

2.2.4 RHEL OS packages to install

You must install a set of RHEL OS packages that are common to each NSD and NRC server. Mostof the common packages are available from the RHEL ISO disk image and the default RHELpackage repository. Such packages are listed in “Required packages, RHEL ISO image or defaultRHEL repository” (p. 9).

You must also install additional packages that are available only from the RHEL optional packagerepository. Such packages are listed in “Required packages, RHEL optional package repository”(p. 13).

Required packages, RHEL ISO image or default RHEL repository

The RHEL ISO image and default package repository each contain the following OS packages thatyou must install. To facilitate the installation, copy the following command block and paste it in aCLI:

yum -y install @base @gnome-desktop @legacy-x @x11

yum -y install autofs bc.x86_64 binutils.x86_64 compat-libcap1.x86_64

yum -y install dialog elfutils-libelf-devel.x86_64 elfutils.x86_64

yum -y install firefox.x86_64 ftp gcc.x86_64 gcc-c++.x86_64 glibc.i686

yum -y install glibc.x86_64 glibc-devel.i686 glibc-devel.x86_64

yum -y install libaio-devel.i686 libaio-devel.x86_64 libgcc.i686

yum -y install libgcc.x86_64 libibverbs.x86_64

yum -y install libstdc++.i686 libstdc++.x86_64 libstdc++-devel.i686

yum -y install libstdc++-devel.x86_64 libXi.i686 libXi.x86_64

yum -y install libXrender.i686 libXtst.i686 libXtst.x86_64 lshw.x86_64

yum -y install lsof.x86_64 make.x86_64 man net-snmp net-snmp-utils

yum -y install net-snmp-utils nfs-utils nspr-4.13.1-1.0.el7_3.x86_64

yum -y install nfs-utils ntp numactl-devel.i686 numactl-devel.x86_64

yum -y install nss-softokn-3.28.3-6.el7.x86_64

yum -y install nss-softokn-freebl-3.28.3-6.el7.i686

yum -y install nss-softokn-freebl-3.28.3-6.el7.x86_64

yum -y install nss-util-3.28.4-3.el7.x86_64

yum -y install openssh.x86_64 openssh-askpass.x86_64

yum -y install openssh-clients.x86_64 openssh-server.x86_64

yum -y install procps rsync.x86_64 tcpdump.x86_64 unzip.x86_64

yum -y install which xinetd.x86_64 zip.x86_64

Getting startedRHEL OS installation requirements

NSD | NRC




10 Issue 1

Table 2-1 Required OS packages from default RHEL repository or ISO image

Package name Description

@base Base package group

@gnome-desktop Gnome package group

@legacy-x Legacy X package group

@x11 X11 package group

autofs A tool for automatically mounting and unmounting filesystems

bc.x86_64 GNU's bc (a numeric processing language) and dc (a calculator)

binutils.x86_64 A GNU collection of binary utilities

compat-libcap1.x86_64 Library for getting and setting POSIX.1e capabilities

dialog A utility for creating TTY dialog boxes

elfutils.x86_64 A collection of utilities and DSOs to handle compiled objects

elfutils-libelf-devel.x86_64 Development support for libelf

firefox.x86_64 Mozilla Firefox web browser

ftp The standard UNIX FTP client

gcc.x86_64 Various compilers, for example, C, C++, Objective-C, and Java

gcc-c++.x86_64 C++ support for GCC

glibc.i686 The GNU libc libraries

glibc.x86_64 The GNU libc libraries

glibc-devel.i686 Object files for development using standard C libraries

glibc-devel.x86_64 Object files for development using standard C libraries

gtk2.i686 The GIMP ToolKit (GTK+), a library for creating GUIs for X

hdparm.x86_64 Utility for displaying and/or setting hard disk parameters

irqbalance.x86_64 Daemon that evenly distributes IRQ load across multiple CPUs

ksh.x86_64 The Original ATT Korn Shell

libaio.i686 Linux-native asynchronous I/O access library

libaio.x86_64 Linux-native asynchronous I/O access library

libaio-devel.i686 Development files for Linux-native asynchronous I/O access

libaio-devel.x86_64 Development files for Linux-native asynchronous I/O access

libgcc.i686 GCC version 4.8 shared support library

libgcc.x86_64 GCC version 4.4 shared support library

libibverbs.x86_64 Core user space library that implements hardware abstracted verbs protocol

libstdc++.i686 GNU Standard C++ Library


NSD | NRC




Table 2-1 Required OS packages from default RHEL repository or ISO image (continued)


libstdc++.x86_64 GNU Standard C++ Library

libstdc++-devel.i686 Header files and libraries for C++ development

libstdc++-devel.x86_64 Header files and libraries for C++ development

libXi.i686 X.Org X11 libXi runtime library

libXi.x86_64 X.Org X11 libXi runtime library

libXrender.i686 X.Org X11 libXrender runtime library

libXtst.i686 X.Org X11 libXtst runtime library

libXtst.x86_64 X.Org X11 libXtst runtime library

lshw.x86_64 Hardware lister

lsof.x86_64 Provides a utility to list information about open files

make.x86_64 GNU tool which simplifies the build process for users

man A set of documentation tools: man, apropos and whatis

mcelog Tool to translate x86-64 CPU Machine Check Exception data

net-snmp The SNMP Agent Daemon and documentation

net-snmp-utils SNMP clients such as snmpget and snmpwalk

nfs-utils NFS utilities and supporting clients and daemons for the kernel

nspr-4.13.1-1.0.el7_3.x86_64 1 Netscape portable runtime

nss-softokn-3.28.3-6.el7.x86_64 1 Network Security Services SofToken module

nss-softokn-freebl-3.28.3-6.el7.i686 1 Freebl library for Network Security Services

nss-softokn-freebl-3.28.3-6.el7. x86_64 1

Freebl library the Network Security Services

nss-util-3.28.4-3.el7.x86_64 1 Network Security Services utilities

ntp The NTP daemon and utilities

numactl-devel.i686 Development package for building Applications that use numa

numactl-devel.x86_64 Development package for building Applications that use numa

openssh.x86_64 Open source implementation of SSH protocol versions 1 and 2

openssh-askpass.x86_64 Passphrase dialog for OpenSSH and X

openssh-clients.x86_64 Open-source SSH client application

openssh-server.x86_64 Open source SSH server daemon

procps OS utilities for /proc

rsync.x86_64 A program for synchronizing files over a network


NSD | NRC




12 Issue 1

Table 2-1 Required OS packages from default RHEL repository or ISO image (continued)


tcpdump.x86_64 Command-line packet analyzer and network traffic capture; used by technical support fordebugging

unzip.x86_64 A utility for unpacking zip files

which Displays where a particular program in your path is located

xinetd.x86_64 A secure replacement for inetd

zip.x86_64 A file compression utility

Notes:

1. The NSD and NRC modules require the indicated versions of these RHEL 7 packages, or later. RHEL 7.3installations may not have the correct package versions. In such a case, you must either upgrade eachpackage, as required, or upgrade to RHEL 7.4.

Required packages, RHEL optional package repository

The RHEL optional package repository contains the following OS packages that you must install. Tofacilitate the installation, copy the following command and paste it in a CLI:

yum -y install compat-libstdc++-33.i686 compat-libstdc++-33.x86_64

Table 2-2 Required OS packages from RHEL optional package repository


compat-libstdc++-33.i686 Compatibility standard C++ libraries

compat-libstdc++-33.x86_64 Compatibility standard C++ libraries

2.2.5 RHEL OS packages to remove

Table 2-3, “RHEL OS packages to remove” (p. 14) lists the OS packages that you must removeafter you install the required OS packages on a component station. To facilitate the packageremoval, copy the following command block and paste it in a CLI:

yum -y remove anaconda-core.x86_64 anaconda-gui.x86_64

yum -y remove anaconda-tui.x86_64 avahi.x86_64 biosdevname

yum -y remove dnsmasq.x86_64 dosfstools gnome-boxes.x86_64

yum -y remove initial-setup.x86_64 initial-setup-gui.x86_64 kexec-tools

yum -y remove libstoragemgmt.x86_64 libstoragemgmt-python.noarch

yum -y remove libvirt-daemon-config-network.x86_64

yum -y remove libvirt-daemon-driver-network.x86_64

yum -y remove libvirt-daemon-driver-qemu.x86_64

yum -y remove libvirt-daemon-kvm.x86_64 libvirt-gconfig.x86_64

yum -y remove libvirt-gobject.x86_64 NetworkManager.x86_64

yum -y remove NetworkManager-libreswan.x86_64

yum -y remove NetworkManager-libreswan-gnome.x86_64


NSD | NRC




yum -y remove NetworkManager-team.x86_64 NetworkManager-tui.x86_64

yum -y remove NetworkManager-wifi.x86_64 qemu-kvm.x86_64

yum -y remove qemu-kvm-common.x86_64 setroubleshoot.x86_64

yum -y remove setroubleshoot-plugins.noarch

yum -y remove setroubleshoot-server.x86_64

yum -y remove subscription-manager-initial-setup-addon.x86_64

Table 2-3 RHEL OS packages to remove


biosdevname Utility that provides an optional convention for naming network interfaces

NetworkManager.x86_64 Network connection manager and user applications

NetworkManager-libreswan.x86_64 NetworkManager VPN plugin for libreswan

NetworkManager-libreswan-gnome.x86_64

NetworkManager VPN plugin for libreswan - GNOME files

NetworkManager-team.x86_64 Team device plugin for NetworkManager

NetworkManager-tui.x86_64 NetworkManager curses-based UI

NetworkManager-wifi.x86_64 Wifi plugin for NetworkManager

anaconda-core.x86_64 Core of the Anaconda installer

anaconda-gui.x86_64 Graphical user interface for the Anaconda installer

anaconda-tui.x86_64 Textual user interface for the Anaconda installer

avahi.x86_64 Local network service discovery

dnsmasq.x86_64 A lightweight DHCP/caching DNS server

gnome-boxes.x86_64 A simple GNOME 3 application to access remote or virtual systems

initial-setup.x86_64 Initial system configuration utility

initial-setup-gui.x86_64 Graphical user interface for the initial-setup utility

libstoragemgmt.x86_64 Storage array management library

libstoragemgmt-python.noarch Python2 client libraries and plug-in support for libstoragemgmt

libvirt-daemon-config-network.x86_64 Default configuration files for the libvirtd daemon

libvirt-daemon-driver-network.x86_64 Network driver plugin for the libvirtd daemon

libvirt-daemon-driver-qemu.x86_64 Qemu driver plugin for the libvirtd daemon

libvirt-daemon-kvm.x86_64 Server side daemon & driver required to run KVM guests

libvirt-gconfig.x86_64 libvirt object APIs for processing object configuration

libvirt-gobject.x86_64 libvirt object APIs for managing virtualization hosts

qemu-kvm.x86_64 QEMU metapackage for KVM support

qemu-kvm-common.x86_64 QEMU common files needed by all QEMU targets

setroubleshoot.x86_64 Helps troubleshoot SELinux problem


NSD | NRC




14 Issue 1

Table 2-3 RHEL OS packages to remove (continued)


setroubleshoot-plugins.noarch Analysis plugins for use with setroubleshoot

setroubleshoot-server.x86_64 SELinux troubleshoot server

subscription-manager-initial-setup-addon.x86_64

Initial setup screens for subscription manager

2.3 Partitioning

2.3.1 Partitioning requirements

CAUTION

Service Disruption

Each disk partition described in this section must be a mounted partition and not a symbolic link.

The NSD and NRC modules do not support the use of symbolic links to represent partitions.

Table 2-4, “NSD and NRC live and lab partitioning scheme” (p. 15) lists the partitioningrequirements for NSD and NRC components in both live and lab deployments.

Note: See the NSP NSD and NRC Planning Guide for information about the supported disktypes.

Table 2-4 NSD and NRC live and lab partitioning scheme

Partition Content Size (Gbytes)

swap Swap space 16

/ Root 26

/home User home directories 0.5

/tmp Temporary files 6

/var System data 14

/var/log System logs 6

var/log/audit System audit logs 6

/opt/nsp NSD and NRC software,operating data and backups

100

/opt/nsp/os nspOS software, Operatingdata

90

Getting startedPartitioning

NSD | NRC




2.4 To configure the VSR-NRC

2.4.1 Description

Perform the following steps after installing the VSR-NRC in order to commission the device formanagement, configure its connection to the managed network, and prepare it for use with the NSDand NRC modules.

Note: Command lines use the # symbol to represent the RHEL CLI prompt for the root user.Do not type the leading # symbol when you enter a command.

2.4.2 Steps

To commission the VSR-NRC for management

1

Open a CLI session on the VSR-NRC device using one of the following methods.

a. Use a Telnet connection.

1. Enter the following.

# telnet device_IP port ↵

where

device_IP is the IP address of the VSR-NRC, as will be supplied in the sros section ofconfig.yml

port is the telnet port value, as will be supplied in the sros section of config.yml

2. Enter the following user credentials when prompted:• user—admin

• password—admin

b. Use an SSH connection.

1. # ssh -l admin device_IP ↵

Where device_IP is the IP address of the VSR-NRC, as will be supplied in the srossection of config.yml.

2. Enter admin when prompted for the user password.

2

Enter the following to configure a static route, if required:

bof static-route network_IP/mm next-hop next_hop_IP ↵

where

network_IP is the destination network IP address

mm is the subnet mask

next_hop_IP is the IP address of the next hop in the static route

Getting startedTo configure the VSR-NRC

NSD | NRC




16 Issue 1

3

Enter the following in sequence to complete the BOF configuration:

bof persist on ↵

bof save ↵

4

Enter the following to configure the VSR-NRC system address:

configure router interface system address system_interface_IP/mm ↵

where

system_interface_IP is the VSR-NRC system interface IP address

mm is the system interface subnet mask

5

Enter the following in sequence to complete the device commissioning:

configure system snmp no shutdown ↵

configure system snmp packet-size 9216 ↵

configure system security snmp community private rwa version both ↵

configure card 1 card-type iom-xp-b ↵

configure card 1 mcm 1 mcm-type mcm-xp ↵

configure card 1 mda 1 mda-type m60-10/100eth-tx ↵

admin save ↵

admin reboot now ↵

The VSR-NRC reboots. After the reboot, the NFM-P can discover the VSR-NRC.

Note: The commands executed in this step are specific to the SR-c12 chassis type andmay need to be altered depending on the chassis type being used and the MDA typesconfigured in the VSR-NRC's domain.xml file.

To connect the VSR-NRC to the managed network

6

For managed network connectivity, and to establish peering sessions, the VSR-NRC VMrequires network interfaces, or vNICs. Depending on your network architecture, you may needto provision multiple vNICs, create an additional network bridge, and bind the vNICs to thebridge.

The first vNIC should be mapped to the CFM-A management port. The second vNIC isreserved for CFM-B. Additional vNICs that you create are sequentially assigned as networkports 1/1/1, 1/1/2, and so on.

Perform the following to create vNICs:


NSD | NRC




Note: You must choose “virtio” as the Device model of each interface. See the RHEL OSdocumentation for more information.

1. Open the RHEL Virtual Machine Manager, or virt-manager, tool.

2. Use the tool to add virtual network interfaces, as required.

3. When the creation of all interfaces is complete, restart the VSR-NRC VM.

After the VM restarts, the interfaces are shown as ports in the VSR-NRC configuration.

To configure the VSR-NRC for IP topology discovery

7

Connect the VSR-NRC to one or more area border routers (ABRs) in the network, ensuringvisibility to each area is possible.

8

Configure an interface for each area of the network connected to the ABRs. See the 7450 ESS,7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide for more information.

9

Configure OSPF or IS-IS for each link. See the 7450 ESS, 7750 SR, 7950 XRS, and VSRUnicast Routing Protocols Guide for more information.

10

Configure the router protocol to export topology database to NSP. Execute the followingcommands on the VSR-NRC:

configure router ospf traffic-engineering

configure router ospf database-export

Note: To discover multiple IS-IS Level-1 topologies via IGP discovery, the VSR-NRC mustbe configured with multiple IS-IS instances that are each connected to one portion of thetopology. Because the definition of a domain includes the instance number, each instancewill appear as a separate domain within NSP. To prevent this, configure each instancewith identical database-export identifier values. For example, on each instance, execute:configure router isis database-export identifier 1

To configure the VSR-NRC for BGP-LS topology discovery

11

Note: In order to perform BGP-LS topology discovery, the VSR-NRC must be installed ona 7750 SR running Release 0.0 I4787 or later.

Note: In order to perform BGP-LS topology discovery, the VSR-NRC requires BGPpeering (direct or via BGP Route Reflector) with at least one router in each IGP area.


NSD | NRC




18 Issue 1

Connect the VSR-NRC to one or more routers (preferably ABRs) in the network.

12

Configure one or more interfaces to the selected router. See the 7450 ESS, 7750 SR, 7950XRS, and VSR Unicast Routing Protocols Guide for more information.

13

Configure OSPF or IS-IS on the link so as to achieve full IP reachability to the selected router.See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide for moreinformation.

14

Configure the VSR-NRC to peer with the selected router. See the 7450 ESS, 7750 SR, 7950XRS, and VSR Unicast Routing Protocols Guide for more information.

15

Configure the VSR-NRC to export BGP-LS to the NSP. Execute the following commands on theVSR-NRC:

configure router ospf traffic engineering

configure router ospf no database-export

configure router bgp link-state-export-enable

configure router bgp family ivp4 bgp-ls

16

On each ABR peering with the VSR-NRC, execute:

configure router ospf traffic-engineering

configure router ospf database-export bgp-ls-identifier <custom id>

identifier <custom id>

configure router bgp link-state-import-enable

configure router bgp family ipv4 bgp-ls

Where custom id is an optional, user-specified number that will assist in identifying theadministrative domain.

To configure the VSR-NRC as a PCE

17

Enable PCE on the VSR-NRC. Execute the following commands:


NSD | NRC




configure router pcep pce local-address <management IP>

configure router pcep pce no shutdown

Where management IP is the IP address of the VSR-NRC .

To configure PCCs

18

Execute the following commands on all 7750 SR routers that will peer with the VSR-NRC(PCE):

configure router pcep pcc peer <vsr-nrc management IP> no shutdown

configure router pcep pcc no shutdown

Where vsr-nrc management IP is the IP address of the VSR-NRC with which the routers willpeer.

END OF STEPS

2.5 To port existing NSD and NRC users during an upgrade

2.5.1 Purpose

Use this procedure to port existing NSD and NRC users when upgrading from NSP Release 17.3 orearlier to NSP Release 17.6 or later.

2.5.2 Steps

1

Re-synchronize all user data with the Keystone server. On the primary NSD and NRC server,execute:

curl -vk https://<server address>:

8543/sdn/api/v3/tenants/resync/KEYSTONE -H 'Authorization: <keystone

token>’

where

server address is the IP address of the primary NSD and NRC server

keystone token is the Keystone token currently being used by the NSD and NRC user

Note: This can also be done from https://<server address>:8543/sdn/api/v3/tenants/resync/KEYSTONEWhere server address is the IP address of the primary NSD and NRC server.

Note: If the above command returns an error, execute the following command to triggeran automatic re-synchronization of the tenants:# systemctl restart nspos-tomcat

Getting startedTo port existing NSD and NRC users during an upgrade

NSD | NRC




20 Issue 1

2

Backup all user credentials from the Keystone server. On the primary NSD and NRC server.Execute:

curl -vk https://<server address>:8543/sdn/api/v3/users -H

'Authorization: <keystone token>’

where



Note: This data can also be retrieved from https://<server address>:8543/sdn/api/v3/users.Where server address is the IP address of the primary NSD and NRC server.

Save the output data.

3

Backup all tenant credentials from the Keystone server. On the primary NSD and NRC server,execute:

curl -vk https://<server address>:8543/sdn/api/v3/tenants -H

'Authorization: <keystone token>’

where



Note: This data can also be retrieved from https://<server address>:8543/sdn/api/v3/tenants.Where server address is the IP address of the primary NSD and NRC server.


4

Backup all users assigned to each tenant. On the primary NSD and NRC server, execute thefollowing for each user and tenant:

curl -vk https://<server address>:8543/sdn/api/v3/tenants/<tenant

UUID>/user/<user UUID> -H 'Authorization: <keystone token>’

where


tenant UUID is the UUID of the tenant to which the user is assigned

user UUID is the UUID of the user to be backed up



NSD | NRC




Note: This data can also be retrieved from https://<server address>:8543/sdn/api/v3/tenants/<tenant UUID>/user/<user UUID>whereserver address is the IP address of the primary NSD and NRC servertenant UUID is the UUID of the tenant to which the user is assigneduser UUID is the UUID of the user to be backed up


5

Backup all resources assigned to each tenant. On the primary NSD and NRC server, executethe following for each tenant:


UUID>/resources -H 'Authorization: <keystone token>’

where


tenant UUID is the UUID of the tenant to which the resources are assigned


Note: This data can also be retrieved from https://<server address>:8543/sdn/api/v3/tenants/<tenant UUID>/resourceswhereserver address is the IP address of the primary NSD and NRC servertenant UUID is the UUID of the tenant to which the resources are assigned


6

Backup all tenants assigned to each user. On the primary NSD and NRC server, execute thefollowing for each user:

curl -vk https://<server address>:8543/sdn/api/v3/users/<user

UUID>/tenants -H 'Authorization: <keystone token>’

where


user UUID is the UUID of the user to which the tenants are assigned


Note: This data can also be retrieved from https://<server address>:8543/sdn/api/v3/users/<user UUID>/tenantswhereserver address is the IP address of the primary NSD and NRC serveruser UUID is the UUID of the user to which the tenants are assigned



NSD | NRC




22 Issue 1

7

Perform 3.2 “To install a standalone NSD and NRC system” (p. 25) or 4.2 “To install aredundant NSD and NRC system” (p. 33), as required.

8

Create users and user groups that match the output data. On the primary NSD and NRCserver, execute:

curl -vk https://<server address>/user-management/rest/api/v1/users -X

POST -H 'Content-Type: application/json' -H "Authorization: Bearer

<NSP system token>" --data ' { "username":"<user name>","password":"

<password>","group":"<group name>"}'

where


NSP system token is token currently being used by the NSD and NRC system

user name is the name of the user being created

password is the password to be used by the user being created

group name is the name of group to which the user being created will belong

Note: It is recommended that the same name be provided for both the user and the usergroup.

9

Create matching NFM-P user groups. Perform the following:

1. Log in to an NFM-P GUI client as the admin user.

2. Navigate to Administration > Security > NFM-P User Security from the main menu. TheNFM-P User Security - Security Management (Edit) form opens.

3. Click on the Scope of Command tab and click Create > Profile. The Scope of CommandProfile (Create) form opens.

4. Configure the Profile Name parameter and click OK. The Scope of Command Profile(Create) form closes.

5. Click on the User Groups tab, then click Create. The User Group (Create) form opens.

6. Specify the matching NSD and NRC group name as the User Group parameter value.

7. Click Select in the Scope of Command panel and choose the Scope of Command Profilecreated in substep 4.

8. Click Select in the Span of Control panel and choose the default Span of Control.

9. Click OK to close the open forms and save your changes. The user group is created.

10

Assign user groups to same tenants as their users, based on the output data. On the primaryNSD and NRC server, perform one of the following:


NSD | NRC




a. Go to https://<server address>:8543/sdn/api/v3/tenants/<tenant UUID>/usergroup/<groupname>/role/<role type>

where


tenant UUID is the UUID of the tenant to which the user group will be assigned

group name is the name of the user group that will be assigned to the tenant

role type is the type of role that the users of the group will assume

b. Execute:


UUID>/usergroup/<group name>/role/<role type> -X POST --header

'Content-Type: application/json' --header 'Accept: application/json'

--header “Authorization: Bearer <NSP system token>"

where


tenant UUID is the UUID of the tenant to which the user group will be assigned

group name is the name of the user group that will be assigned to the tenant

role type is the type of role that the users of the group will assume

NSP system token is token currently being used by the NSD and NRC system

Note: The Tenant UUIDs are migrated as part of the upgrade executed in Step 7.

END OF STEPS


NSD | NRC




24 Issue 1

3 Standalone installation and upgrade

3.1 Introduction

3.1.1 Overview

This chapter describes the standalone NSD and NRC installation and upgrade processes, as wellas related operations.

Note: If changes were made to the NFM-P templates files, please contact Nokia support priorto upgrading your NSD and NRC or NFM-P system, as any customized values will beoverwritten.

3.2 To install a standalone NSD and NRC system

3.2.1 Purpose

Use this procedure to install a standalone NSD and NRC system.

Note: By supplying new values for the parameters within the configuration file, then executingthe installation commands, the capabilities of an existing NSD and NRC system can beupdated. See 3.3 “To upgrade a standalone NSD and NRC system” (p. 29) for moreinformation.

3.2.2 Before you begin

Before executing the NSD and NRC installer, ensure that your system meets the hardware andsoftware requirements described in the NSP NSD and NRC Planning Guide.

The NSD and NRC modules will not initialize without proper license files (NSD, NRC-F, NRC-P,NRC-T, NRC-X), which must be obtained from Nokia personnel.

Installation of the NSD and NRC modules requires IP reachability between their server any externalsystems with which the modules will integrate, such as NFM-P or NFM-T. For information aboutinstalling these components, see their respective documentation suites. In addition, installation ofthe NRC-X module requires IP reachability between its server and the server that will host the otherNSD and NRC modules.

3.2.3 Steps

1

Download the NSD and NRC installer bundle from OLCS and extract it on any system runninga supported version of RHEL 7. This does not have to be the system on which the NSD andNRC modules will be installed, as the installer is able to perform remote installations.

Note: When performing remote operations, SSH connections are used between thesystem where the NSD and NRC installer bundle was extracted and the system(s) on

Standalone installation and upgradeIntroduction

NSD | NRC




which it will execute its tasks. Therefore, SSH connections must be possible betweenthese systems without the use of passwords, which requires the configuration of SSHkeys, or the --ask-pass argument to be used when running the install.sh or uninstall.shutilities, which requires that all systems share the same root user SSH password.

2

Create a hosts file in the directory where the NSD and NRC installer bundle was extracted. Toinstall the NSP Common Applications and the nspOS, add the following entry:

[nspos]

<ip address>

Where ip address is the IP address of the server where the software will be installed.

3

If the NSD and NRC modules are being installed, add the following additional entry to thecreated hosts file:

[sdn]

<ip address>

Where ip address is the IP address of the server where the NSD and NRC software will beinstalled. This should be the same server specified in Step 2. This same interface will also beused by the NSD and NRC modules.

4

If the NRC-X module is being installed, add the following additional entry to the created hostsfile:

[nrcx]

<ip address>

Where ip address is the IP address of the server where the NRC-X software will be installed.

5

Create a YAML or JSON configuration file in the directory where the NSD and NRC installerbundle was extracted and add only the configuration blocks that apply to your deployment. Theexamples/ folder, which is bundled with the NSD and NRC installer, contains a sampleconfiguration file for reference purposes.

The configuration file parameters are defined in the table below:

Standalone installation and upgradeTo install a standalone NSD and NRC system

NSD | NRC




26 Issue 1

Table 3-1 NSD and NRC configuration file parameters

Parameter Definition

auto_start Specifies whether or not the NSD and NRCmodules will start once installation iscomplete

nfmp — Used when integrating with NFM-P

primary_ip The IP address of the primary NFM-P server

standby_ip The IP address of standby NFM-P server

cert_provided Specifies whether or not a custom SSLcertificate is to be used to connect to theNFM-P, true or false

nfmt — Used when integrating with NFM-T

primary_ip The IP address of the primary NFM-T server

standby_ip The IP address of standby NFM-T server

username The user name used to login to the NFM-T

password The password used to login to the NFM-T

cert_provided Specifies whether or not a custom SSLcertificate is to be used to connect to theNFM-T, true or false

sros — Used when integrating with vSROS

enabled Specifies whether or not to enableintegration with vSROS

ip The IP address of the vSROS

router_id The router ID of the vSROS

ssl — Used to customize SSL security

custom_keystore_path The path to the custom keystore

custom_truststore_path The path to the custom truststore

custom_keystore_password The password used to access the customkeystore

custom_truststore_password The password used to access the customtruststore

custom_key_alias The alias of the certificate used in thecustom keystore

custom_key_password The password used to access the key withinthe custom keystore


NSD | NRC




Table 3-1 NSD and NRC configuration file parameters (continued)

Parameter Definition

ean — External applications notifications parameters

max_subscribers The maximum number of subscribers whocan receive external applicationsnotifications

sso — Used to customize the single sign-on configuration

local Specifies whether or not local nspOSdatabase authentication is used

nfm-p Specifies whether or not authentication isdelegated to the NFM-P

ldap Allows for the configuration of base LDAPauthentication settings

radius Allows for the configuration of RADIUSauthentication settings

Note: If populating the sros block, use the IP address and router ID of the VSR-NRCconfigured in 2.4 “To configure the VSR-NRC” (p. 16).

Note: Parameters not being configured should be removed from the configuration fileentirely. Failing to provide a value for a parameter may have undesired consequences.

6

Copy the appropriate license file(s) into the license directory where the NSD and NRC installerbundle was extracted.

7

If the SSL block of the configuration file was populated in Step 5, copy the SSL certificates intothe installer directory. The folders are ssl/nfmp and ssl/nfmt.

8

If LDAP authentication settings were configured in Step 5, copy the LDAP server certificate intothe ssl/ldap directory.

9

Perform one of the following to install the NSD and NRC modules:

a. If the NRC-X module is being added to an existing NSD and NRC system, execute thefollowing commands as root user to install the NRC-X module individually:

cd bin


NSD | NRC




28 Issue 1

./install.sh –target<nrcx ip address>

Where nrcx ip address is the IP address of the server where the NRC-X software will bedeployed.

b. Otherwise, execute the following commands as root user to install all NSD and NRCmodules as specified in the hosts file:

cd bin

./install.sh

10

If the auto_start parameter was set to false in Step 5, execute the following commands to startthe system:

systemctl start nspos-nspd

nspdctl start

Note: If the NRC-X module was installed, these commands must also be performed onthe server where the NRC-X software is deployed.

END OF STEPS

3.3 To upgrade a standalone NSD and NRC system

3.3.1 Purpose

Use this procedure to upgrade a standalone NSD and NRC system. Upgrades are supported fromNSP Release 2.0 R1 and later. If you need to upgrade from NSP Release 1.1 R2 or earlier, pleasecontact your Nokia support representative.



The NRC-F, NRC-P, NRC-T, or NSD modules will not initialize without a proper license file, whichmust be obtained from Nokia personnel.

Installation of the NSD and NRC modules requires IP reachability between any external systemswith which the modules will integrate, such as NFM-P or NFM-T. For information about installingthese components, see their respective documentation suites.

Before performing an upgrade, all processes should be stopped on both the primary and standbyservers and a database backup should be taken.

Note: Use the database backup procedures available from the version of the NSP NSD andNRC Installation and Upgrade Guide that corresponds to the release from which you areupgrading.

Standalone installation and upgradeTo upgrade a standalone NSD and NRC system

NSD | NRC




If the NSD and NRC modules are being upgraded from an earlier release of NSP to NSP Release17.3 or later, and the NFM-P module will be part of the deployment, 6.2 “To configure the NSPsecurity statement” (p. 59) must be performed.

If the NSD and NRC modules are being upgraded from an earlier release of NSP to NSP Release17.6 or later, all existing user data will be lost unless 2.5 “To port existing NSD and NRC usersduring an upgrade” (p. 20) is performed.

3.3.3 Steps

1

Stop all processes. Execute:

nspdctl stop

systemctl stop nspos-nspd

2

Check the consistency of the graphdb. Perform one of the following:

a. On a system running NSP Release 2.0 R4 or earlier, execute:

su - nsp

cd /opt/nsp/server/tomcat/webapps/sdn/WEB-INF/

java -cp 'lib/*:system/lib/*' org.neo4j.consistency.

ConsistencyCheckTool /opt/nsp/server/tomcat/work/graph.db

b. On a system running NSD and NRC Release 17.3 or later, execute:

su - nsp

/opt/nsp/scripts/db/neo4j/bin/neo4j-admin check-consistency

3

Ensure the supported version of RHEL 7 is running, as specified in the NSP NSD and NRCPlanning Guide. As root user, execute the following command on both the primary and standbyNSD and NRC servers:

cat /etc/redhat-release

Note: Any server found to be running an unsupported version of RHEL 7 must beupgraded to a supported version.


NSD | NRC




30 Issue 1

4


Note: When performing remote operations, SSH connections are used between thesystem where the NSD and NRC installer bundle was extracted and the system(s) onwhich it will execute its tasks. Therefore, SSH connections must be possible betweenthese systems without the use of passwords, which requires the configuration of SSHkeys, or the --ask-pass argument must be used when running the install.sh or uninstall.shutilities, which requires that all systems share the same root user SSH password.

5

Create a hosts file in the directory where the NSD and NRC installer bundle was extracted. Theexamples/ folder, which is bundled with the NSD and NRC installer, contains a sample hosts filefor reference purposes. Add the following entries:

[nspos]

<ip address>

[sdn]

<ip address>

where

IP address is the IP address of the server where the NSD and NRC software will be deployed.This same interface will also be used by the NSD and NRC modules.

Note: The IP address of the server where a previous version of the NSD and NRCmodules are deployed must be used.

Note: A standalone NSD and NRC system can be upgraded and converted to aredundant NSD and NRC system simultaneously by populating the hosts file with the IPaddress of the NSD and NRC server that will serve as the standby site. See 4.4 “Toconvert a standalone NSD and NRC system to a redundant NSD and NRC system”(p. 39) for more information.

6


The parameters are defined in Table 3-1, “NSD and NRC configuration file parameters” (p. 27).

Note: The parameter values should be configured to align with your existing NSD andNRC system.


NSD | NRC






Note: If an NFM-P system is part of the NSD and NRC deployment, but will not beupgraded to Release 17.3 or later, then SSO authentication cannot be delegated to theNFM-P.

7


8


9


10

Install the NSD and NRC. As root user, execute the following commands:

cd bin

./install.sh

Note: Following the upgrade, the API certificates of all northbound platforms that areintegrated with the NSD and NRC system must be refreshed.

11

If the auto_start parameter was set to false in Step 5, execute the following commands to startthe NSD and NRC system:


nspdctl start

END OF STEPS


NSD | NRC




32 Issue 1

4 Redundant installation and upgrade

4.1 Introduction

4.1.1 Overview

CAUTION

Service Disruption

In a redundant system, a GUI client that uses a main server IP address to open a browserconnection to the NSD and NRC system may need to use the IP address of the peer main serverafter a main server communication failure.

To ensure GUI client access to the NSD and NRC in a redundant system, it is highly recommendedthat you do the following:

• Configure DNS for GUI clients to map each main server IP address to the same DNS name

• Configure each GUI client to use the DNS name for browser connections to the NSD and NRCsystem

• Use a client browser that caches multiple IP addresses associated with one hostname

This chapter describes the redundant NSD and NRC installation and upgrade processes, as well asrelated operations.

Note: If changes were made to the NFM-P templates files, please contact Nokia support priorto upgrading your NSD and NRC or NFM-P system, as any customized values will beoverwritten.

4.2 To install a redundant NSD and NRC system

4.2.1 Purpose

Use this procedure to install an NSD and NRC system with 1+1 redundancy, which requires theinstallation of both a master NSD and NRC instance, and a standby NSD and NRC instance. Seethe NSP NSD and NRC Planning Guide for more information about redundant deployments.

The NSD and NRC instances will not initialize without a redundant license, which must be obtainedfrom Nokia personnel.



An NRC-F, NRC-P, NRC-T, or NSD license must be obtained from Nokia personnel and placed inthe license folder. The modules will not initialize without a valid license file in this folder.

Installation of the NSD and NRC modules requires IP reachability between the modules and any

Redundant installation and upgradeIntroduction

NSD | NRC




external systems with which the modules will integrate, such as NFM-P or NFM-T. For informationabout installing these components, see their respective documentation suites.

4.2.3 Steps

1


Note: When performing remote operations, SSH connections are used between thesystem where the NSD and NRC installer bundle was extracted and the system(s) onwhich it will execute its tasks. Therefore, SSH connections must be possible betweenthese systems without the use of passwords. Otherwise, the --ask-pass argument must beused when running the install.sh or uninstall.sh utilities, which will require that all systemsshare the same root user SSH password.

2

Create a hosts file in the directory where the NSD and NRC installer bundle was extracted. Toinstall the NSP Common Applications and the nspOS, add the following entry:

[nspos]

<primary server address> dc=<location>

<standby server address> dc=<location>

where

primary server address is the IP address of the primary common applications/nspOS server

standby server address is the IP address of the standby common applications/nspOS server

location is the datacenter in which the given server resides. This string must be unique to eachserver in the redundant deployment

3

If the NSD and NRC modules are being installed, add the following additional entry to thecreated hosts file:

[sdn]



where

primary server address is the IP address of the primary NSD and NRC server

standby server address is the IP address of the standby NSD and NRC server

Redundant installation and upgradeTo install a redundant NSD and NRC system

NSD | NRC




34 Issue 1


Note: The primary server address and standby server address should be the same asthose specified in Step 2.

4

If the NRC-X module is being installed, add the following additional entry to the created hostsfile:

[nrcx]



where

primary server address is the IP address of the primary NRC-X server

standby server address is the IP address of the standby NRC-X server


5





6


7

Install the NSD and NRC. Execute the following commands:

cd bin

./install.sh

The NSD and NRC modules are automatically deployed on both servers.

Redundant installation and upgradeTo install a redundant NSD and NRC system

NSD | NRC




8



nspdctl start

END OF STEPS

4.3 To upgrade a redundant NSD and NRC system

4.3.1 Purpose

Use this procedure to upgrade an NSD and NRC system with 1+1 redundancy, which requires theinstallation of both a master NSD and NRC instance, and a standby NSD and NRC instance. TheNSD and NRC instances will not initialize without a redundant license, which must be obtained fromNokia personnel. Redundant deployments are only available in NSD and NRC Release 17.3 andlater. See the NSP NSD and NRC Planning Guide for more information about redundantdeployments.

Upgrades are supported from NSP Release 2.0 R1 and later. If you need to upgrade from NSPRelease 1.1 R2 or earlier, please contact your Nokia support representative.




Installation of the NSD and NRC modules requires IP reachability between the modules and anyexternal systems with which the modules will integrate, such as NFM-P or NFM-T. For informationabout installing these components, see their respective documentation suites.

Before performing an upgrade, all processes should be stopped on both the primary and standbyservers and a database backup should be taken.

Note: Use the database backup procedures available from the version of the NSP NSD andNRC Installation and Upgrade Guide that corresponds to the release from which you areupgrading.

If the NSD and NRC modules are being upgraded from an earlier release of NSP to NSP Release17.3 or later, and the NFM-P module will be part of the deployment, 6.2 “To configure the NSPsecurity statement” (p. 59) will need to be performed.


Redundant installation and upgradeTo upgrade a redundant NSD and NRC system

NSD | NRC




36 Issue 1

4.3.3 Steps

1

Stop all processes. Execute the following command on both the primary and standby NSD andNRC servers:

nspdctl stop


2

Check the consistency of the graphdb. Perform one of the following on the primary NSD andNRC server:

a. On a system running NSP Release 2.0 R4 or earlier, execute:

su - nsp

cd /opt/nsp/server/tomcat/webapps/sdn/WEB-INF/

java -cp 'lib/:system/lib/' org.neo4j.consistency.

ConsistencyCheckTool /opt/nsp/server/tomcat/work/graph.db

b. On a system running NSD and NRC Release 17.3 or later, execute:

su - nsp

/opt/nsp/scripts/db/neo4j/bin/neo4j-admin check-consistency

3

Ensure the supported version of RHEL 7 is running, as specified in the NSP NSD and NRCPlanning Guide. As root user, execute the following command on both the primary and standbyNSD and NRC servers:

cat /etc/redhat-release

Note: Any server found to be running an unsupported version of RHEL 7 must beupgraded to a supported version.

4


Note: When performing remote operations, SSH connections are used between thesystem where the NSD and NRC installer bundle was extracted and the system(s) onwhich it will execute its tasks. Therefore, SSH connections must be possible betweenthese systems without the use of passwords. Otherwise, the --ask-pass argument must be


NSD | NRC




used when running the install.sh or uninstall.sh utilities, which will require that all systemsshare the same root user SSH password.

5

Create a hosts file in the directory where the NSD and NRC installer bundle was extracted. Theexamples/ folder, which is bundled with the NSD and NRC installer, contains a sample hosts filefor reference purposes. Add the following entries:

[nspos]



[sdn]



where




Note: The IP addresses of the servers where a previous version of the NSD and NRCmodules are deployed must be used.

6



Note: The parameter values should be configured to align with your existing NSD andNRC system.




NSD | NRC




38 Issue 1

Note: If an NFM-P system is part of the NSD and NRC deployment, but will not beupgraded to Release 17.3 or later, then SSO authentication cannot be delegated to theNFM-P.

7


8


9


10

Install the NSD and NRC. Execute the following commands:

cd bin

./install.sh

The NSD and NRC modules are automatically deployed on both servers.

Note: Following the upgrade, the API certificates of all northbound platforms that areintegrated with the NSD and NRC system must be refreshed.

11



nspdctl start

END OF STEPS

4.4 To convert a standalone NSD and NRC system to a redundantNSD and NRC system

4.4.1 Purpose

Use this procedure to convert a previously-installed standalone NSD and NRC system to aredundant NSD and NRC system.

Redundant installation and upgradeTo convert a standalone NSD and NRC system to a redundant NSD and NRCsystem

NSD | NRC




Note: Upon converting to a redundant NSD and NRC system, SSL communicationconfigurations must be updated so that the IP addresses of both the active and standby NSDand NRC servers are included in the SAN entries.

Note: If this NSD and NRC system will be deployed alongside an NFM-P system, thatsystems must also be deployed in a redundant configuration. See the NSP NFM-P Installationand Upgrade Guide for more information.

4.4.2 Steps

1

Modify the existing hosts file in the directory where the NSD and NRC installer bundle wasextracted as follows:

[nspos]



[sdn]



where




2

Copy the appropriate license file(s) into the license/ folder where the NSD and NRC installerbundle was extracted.

3

In the config.yml file, configure the auto_start parameter with a value of false.

4

Shutdown all the active processes on the active, standalone NSD and NRC system. Execute:

nspdctl stop


Redundant installation and upgradeTo convert a standalone NSD and NRC system to a redundant NSD and NRCsystem

NSD | NRC




40 Issue 1

5

Install the NSD and NRC. Execute the following commands on one of the servers:

cd bin

./install.sh

The NSD and NRC modules are automatically deployed to both servers.

6

On what was previously the active, standalone NSD and NRC system, execute:


nspdctl start

7

On the standby NSD and NRC system, execute:


nspdctl start

END OF STEPS

4.5 To migrate from an NSD and NRC system in HA mode to aredundant NSD and NRC system

4.5.1 Purpose

Use this procedure to convert a previously-installed NSD and NRC system in HA mode to aredundant NSD and NRC system.

Note: External systems that had been configured to interact with the NSD and NRC system inHA mode will need to be reconfigured so as to be aware of the IP addresses for both theprimary and standby NSD and NRC servers.

Note: If the deployment includes an NFM-P module that will be upgraded to Release 17.3 orlater, and a single SSL certificate will be used for both the NFM-P and the NSD and NRCmodules, that certificate must be generated with the appropriate values populated in the SANsection. See 6.3 “To generate a keystore” (p. 60) for more information.




Redundant installation and upgradeTo migrate from an NSD and NRC system in HA mode to a redundant NSDand NRC system

NSD | NRC




Installation of the NSD and NRC modules requires IP reachability between the modules and anyexternal systems with which the modules will integrate, such as NFM-P or NFM-T. For informationabout installing these components, see their respective documentation suites.

Before performing an upgrade, all processes should be stopped and a database backup should betaken.


4.5.3 Steps

Reduce the HA cluster from three servers to two servers

1

Shutdown all NSD and NRC instances. Execute:

/opt/nsp/scripts/nsp-control stop

2

In the hosts file that corresponds to the installed NSD and NRC version (such as 2.0.R4), insertonly the IP address of the server to be removed.

Note: If this is an HA disaster recovery deployment, the removed server should be one ofthe two in the primary site.

3

Remove the software from that server. Execute:

cd bin

./uninstall.sh

Install the two remaining servers that will form the redundant NSD and NRCsystem

4

In the 17.6 config.yml file, configure the auto_start parameter with a value of false.

5



NSD | NRC




42 Issue 1

6

If the NSD and NRC deployment will include an NFM-P, the corresponding templates must beupdated. See 5.6 “To install required NFM-P templates” (p. 55) for more information.

7

Execute:

bin/install.sh

8

On the server that will serve as the primary server, execute:


9

Monitor the nsp.log file to ensure that the upgrade script completes.

10

Connect to the system and perform a basic sanity check.

11

On the standby server, execute:


END OF STEPS


NSD | NRC





NSD | NRC




44 Issue 1

5 Post-installation activities

5.1 Introduction

5.1.1 Overview

This chapter contains procedures that may need to be performed after installing or upgrading anNSD and NRC system.

5.2 To add the NSD and NRC modules to an existing NFM-P system


Use this procedure to add the NSD and NRC modules to an existing NFM-P system, creating amulti-module scenario.

In multi-module scenarios, it is recommended that a common root CA is used, to ensure trustbetween the modules. See Chapter 6, “Security” for more information about configuring securityacross NSP modules, including the generation of a common Root CA.

5.2.2 Steps

CAUTION

Service Disruption

Performing this procedure involves stopping and starting each NFM-P main server, which isservice-affecting.

This procedure must only be performed during a maintenance period of low network activity.

Note: The following user privileges are required:

• on each NFM-P main server station — root, nsp

• on each NSD and NRC server station — root

Note: The following RHEL CLI prompts in command lines denote the active user, and are notto be included in typed commands:

• # —root user

• bash$ —nsp user

Note: When performing remote operations, SSH connections are used between the systemwhere the NSD and NRC installer bundle was extracted and the system(s) on which it willexecute its tasks. Therefore, SSH connections must be possible between these systemswithout the use of passwords, which requires the configuration of SSH keys, or the --ask-passargument to be used when running the db-restore.sh utilities, which requires that all systemsshare the same root user SSH password.

Post-installation activitiesIntroduction

NSD | NRC




1

Perform 3.2 “To install a standalone NSD and NRC system” (p. 25) or 4.2 “To install aredundant NSD and NRC system” (p. 33).

Note: During installation, the auto_start parameter in the config.yml file must be set tofalse, so that the NSD and NRC system does not start upon completion.

Note: Ensure that a common Root CA is used when installing the NSD and NRC system.

Perform NFM-P data migration

2

Stop the NFM-P system as described in the NSP NFM-P Installation and Upgrade Guide. If theNFM-P was deployed in a redundant configuration, both the primary and standby servers mustbe stopped.

3

Start the nspOS services on the primary NFM-P server. As the nsp user, execute:

bash$ nspdctl start ↵

4

Monitor the startup. Execute:

bash$ nspdctl logs ↵

Monitor the console output until services are in the “active” state.

Note: Press CTRL+C to stop the output of nspdctl logs.

5

Begin the data backup operation. Execute:

bash$ nspdctl backup -d nspos_migration -f ↵

6

Execute:

bash$ nspdctl backup status ↵

Output similar to the following is displayed:

Last-known backup status : status

Last-known backup time : time

Last-known backup files : /opt/nsp/backup/nspos_

migration/nspos-neo4j_backup_timestamp.tar.gz

Ensure that the status value is success, and that the time value is current.

Post-installation activitiesTo add the NSD and NRC modules to an existing NFM-P system

NSD | NRC




46 Issue 1

7

Execute:

bash$ nspdctl stop ↵

8

As nsp user, transfer the backup files located in the /opt/nsp/backup/nspos_migration/ directoryto the /tmp/nspos_migration/ directory on the NSD and NRC server.

Note: The nsp user must have FTP access privileges in order to complete this step.

9

Execute the following commands to ensure that the NSD and NRC systems' services are in the“inactive” state:

bash$ nspdctl status

bash$ systemctl status nspos-nspd

If the services are in the “active” state, execute the following commands:

bash$ sudo systemctl stop nspos-nspd

bash$ nspdctl stop

Note: If the NSD and NRC system has been deployed in a redundant configuration, theabove commands should be executed on both the active and standby servers.

Restore Neo4j backup

10

To restore the neo4j backup, as root user, perform the following steps on a standalone NSDand NRC server, or on the designated primary server in a redundant deployment:

a. Execute the following commands:

cd/<NSD and NRC installation directory>/tools/database

./db-restore.sh

Where NSD and NRC installation directory is the directory in which the NSD and NRCsystem was installed, such as opt/NSP-17.12.

b. When prompted for a backup file, enter the complete path of the neo4j backup file:

/tmp/nspos_migration/nspos-neo4j_backup_<timestamp>.tar.gz

Where time stamp is the date and time at which the backup was performed.


NSD | NRC




Restore PostgreSQL database

11

To restore the PostgeSQL backup, as root user, perform the following steps on a standaloneNSD and NRC server, or on the designated primary server in a redundant deployment:



./db-restore.sh


b. When prompted for a backup file, enter the complete path of the PostgreSQL backup file:

/tmp/nspos_migration/nspos-postgresql_backup_<timestamp>.tar.gz


Start the NSD and NRC server(s)

12

Execute the following command to start a standalone NSD and NRC server, or the designatedprimary server in a redundant deployment:

bash$ sudo systemctl start nspos-nspd

13

Execute the following command to see the status of the services:

Bash$ nspdctl status

Confirm that nspos-neo4j and nspos-postgresql are both in the “active (master)” state.

14

If the NSD and NRC system was deployed in a redundant configuration, execute the followingcommand to start the standby NSD and NRC server:

# sudo systemctl start nspos-nspd ↵

15

The NFM-P registry entry must be modified to include the NSD and NRC system IPaddress(es). Any references to the loopback address or the NFM-P system IP address(es) mustbe removed. The NFM-P system must then be restarted. See the NSP NFM-P Installation andUpgrade Guide for specific instructions.

END OF STEPS


NSD | NRC




48 Issue 1

5.3 To add the NSD and NRC modules to an existing NFM-T system

5.3.1 Pupose

Use this procedure to add the NSD and NRC modules to an existing NFM-T system, creating amulti-module scenario.

In multi-module scenarios, it is recommended that a common root CA is used, to ensure trustbetween the modules. See Chapter 6, “Security” for more information about configuring securityacross NSP modules, including the generation of a common Root CA.

CAUTION

Service Disruption

Performing this procedure requires stopping and starting NFM-T systems, which is service-affecting.

This procedure should only be performed during a maintenance period of low network activity.

5.3.2 Steps

Note: The root and nsp user privileges are required on each NFM-T host server station andeach NSD and NRC server station. The following RHEL CLI prompts in command lines denotethe active user, and are not to be included in typed commands:

• # - root user

• bash$ - nsp user

Note: When performing remote operations, SSH connections are used between the systemwhere the NSD and NRC installer bundle was extracted and the system(s) on which it willexecute its tasks. Therefore, SSH connections must be possible between these systemswithout the use of passwords, which requires the configuration of SSH keys, or the --ask-passargument to be used when running the db-restore.sh utilities, which requires that all systemsshare the same root user SSH password.

1

Perform 3.2 “To install a standalone NSD and NRC system” (p. 25) or 4.2 “To install aredundant NSD and NRC system” (p. 33).

Note: During installation, the auto_start parameter in the config.yml file must be set tofalse, so that the NSD and NRC system does not start upon completion.

Note: Ensure that a common Root CA is used when installing the NSD and NRC system.

Post-installation activitiesTo add the NSD and NRC modules to an existing NFM-T system

NSD | NRC




Perform NFM-T data migration

2

If the NFM-T system was deployed in a redundant configuration, execute the followingcommand on the standby NFM-T server to stop nspOS services:


3

Execute the following command on the standalone/primary NFM-T server and ensure nspOSservices are running:

bash$ nspdctl status ↵

4

Begin the data backup operation. Execute:

bash$ nspdctl backup -d nspos_migration -f ↵

5

Execute:

bash$ nspdctl backup status ↵

Output similar to the following is displayed:

Last-known backup status : status

Last-known backup time : time

Last-known backup files : /opt/nsp/backup/nspos_

migration/nspos-neo4j_backup_timestamp.tar.gz

Ensure that the status value is success, and that the time value is current.

6

Execute:


7

As nsp user, transfer the backup files located in the /opt/nsp/backup/nspos_migration/ directoryto the /tmp/nspos_migration/ directory on the NSD and NRC server.

8

Execute the following commands to ensure that the NSD and NRC systems' services are in the“inactive” state:


bash$ systemctl status nspos-nspd

If the services are in the “active” state, execute the following commands:

bash$ sudo systemctl stop nspos-nspd


NSD | NRC




50 Issue 1

bash$ nspdctl stop

Note: If the NSD and NRC system has been deployed in a redundant configuration, theabove commands should be executed on both the active and standby servers.

Restore Neo4j backup

9

To restore the neo4j backup, as root user, perform the following steps on a standalone NSDand NRC server, or on the designated primary server in a redundant deployment:



./db-restore.sh


b. When prompted for a backup file, enter the complete path of the neo4j backup file:

/tmp/nspos_migration/nspos-neo4j_backup_<timestamp>.tar.gz


Restore PostgreSQL database

10

To restore the PostgeSQL backup, as root user, perform the following steps on a standaloneNSD and NRC server, or on the designated primary server in a redundant deployment:



./db-restore.sh


b. When prompted for a backup file, enter the complete path of the PostgreSQL backup file:

/tmp/nspos_migration/nspos-postgresql_backup_<timestamp>.tar.gz



NSD | NRC




Start the NSD and NRC server(s)

11

Execute the following command to start a standalone NSD and NRC server, or the designatedprimary server in a redundant deployment:

bash$ sudo systemctl start nspos-nspd

12

Execute the following command to see the status of the services:


Confirm that nspos-neo4j and nspos-postgresql are both in the “active (master)” state.

13

If the NSD and NRC system was deployed in a redundant configuration, execute the followingcommand to start the standby NSD and NRC server:

# sudo systemctl start nspos-nspd ↵

14

Log in to the NFM-T host server and execute the following commands using the existing RootCA certificate to generate SSL certificates for NFM-T:

1. mkdir /opt/ssl

cd /opt/ssl

2. Transfer the ROOT CA certificate created in 6.4 “To generate a Root CA” (p. 61), includingthe ca.jks and ca-cert.pem files, to the /opt/ssl directory on the NFM-T host server.

3. Execute the following command to create the nfmtKeystore.jks file:

keytool -genkeypair -keyalg RSA -keystore nfmtKeystore.jks -alias

nfmt -storepass <keystore password> -keypass <key password> -dname

CN=NSP,O=Nokia -validity 7300

4. Execute the following command to create the nfmt.csr file:

keytool -certreq -keystore nfmtKeystore.jks -alias nfmt -file

nfmt.csr -storepass <keystore password> -ext san=IP:127.0.0.1,IP:

<NFMT server address>[IP:<standby NFMT server address>]

5. Execute the following command to create the nfmt.public file:

keytool -gencert -storepass <ca store password> -keystore ca.jks

-keypass <key password> -alias nspca -ext ku:c=digitalSignature,

keyEnchiperment -ext eku:c=serverAuth,clientAuth -rfc -ext

honored=all -infile nfmt.csr -outfile nfmt.public

6. Execute the following command to create the nfmtKeystore.jks.p12 file:

keytool -importkeystore -noprompt -srckeystore nfmtKeystore.jks

-destkeystore nfmtKeystore.jks.p12 -deststoretype PKCS12


NSD | NRC




52 Issue 1

-deststorepass <keystore password> -destkeypass <key password>

-srcstorepass <keystore password> -srckeypass <key password> -alias

nfmt

7. Execute the following commands to create the nfmt.private file:

openssl pkcs12 -in nfmtKeystore.jks.p12 -passin pass:<key password>

-nodes -nocerts -out nfmt.private

Where key password is the password used with the key.

15

In the NFM-T host server, under the /opt/ssl directory, run the following command:

# cp ca-cert.pem nspOS.public

16

In the same directory, create the ssl.info file and populate it with the following information:

• custom_certificate_path=/opt/ssl/nfmt.public

• custom_private_key_path=/opt/ssl/nfmt.private

• nspOS_public_key=/opt/ssl/nspOS.public

17

In the NFM-T system, execute the following command:

Note: If the NFM-T system was deployed in a redundant configuration, this commandmust be executed on both the primary and standby NFM-T servers.

ssh-copy-id <NSD and NRC server address>

where NSD and NRC server address is the IP address of the primary/standalone NSD andNRC server

Note: If the NSD and NRC system was deployed in a redundant configuration, executethe above command again using the standby NSD and NRC server's IP address.

18

In the NFM-T host server, execute the following commands:

cd /var/autoinstall/R17.12

./utilities/nfmt-ext-nspOS-Integration.sh bench=<nfmt bench name>

ssl=/opt/ssl/ssl.info nspOS=<primary NSD and NRC IPv4 address>,

[<standby NSD and NRC IPv4 address>]

./utilities/execOnBench.sh <nfmt bench name> complete start

where

primary NSD and NRC IPv4 address is the IPv4 address of the primary/standalone NSD andNRC server


NSD | NRC




standby NSD and NRC IPv4 address is the IPv4 address of the standby NSD and NRC server

nfmt bench name is the bench name used when creating/instantiating the NFM-T instance

Note: the execution will be traced in standard output and in: /var/autoinstall/R17.12/trace/<bench name>/ NFMT-nspOS-int_OTNE_<ID>_<IP address>_<start_date>.trace

19

Launch the NFM-T from the NSP Launchpad. Perform the following:

Note: If the NFM-T was deployed in a redundant configuration, these steps must beperformed on both the primary and standby NFM-T servers.

1. From the NFM-T dashboard, choose ADMINISTER > Schedule > Scheduler from thedrop-down menu to open the Scheduler GUI.

2. From the Scheduler GUI, select SDN-DR-Monitor, right click, and select Activate fromthe contextual menu.

END OF STEPS

5.4 To retroactively add a license to the NSD and NRC

5.4.1 Purpose

Use this procedure to add a license file to an NSD and NRC server after the install script has beenrun.

5.4.2 Steps

1


2

Run the install script to re-configure the NSD and NRC with the new license(s). Execute:

cd bin

./install.sh

3

Restart the Tomcat instance to activate the new license file. As root user, execute:

systemctl restart nsp-tomcat

Post-installation activitiesTo retroactively add a license to the NSD and NRC

NSD | NRC




54 Issue 1

Note: For redundant NSD and NRC systems, this step must be performed on bothservers.

END OF STEPS

5.5 To enable TCAs for NRC-F

5.5.1 Purpose

If using NRC-F functionality, use this procedure to enable Threshold Crossing Alarms (TCAs). TCAsallow the NRC-F to receive port utilization information.

5.5.2 Steps

1

After completing NSD and NRC installation, execute the following command to stop the SDNand nspOS services:

nspdctl stop

2

In the /opt/nsp/configure/config/nrcf.conf file, set the value of the tca parameter to true.

3

Restart the SDN and nspOS services. Execute:

nspdctl start

END OF STEPS

5.6 To install required NFM-P templates

5.6.1 Purpose

Use this procedure to install required NFM-P templates on an NFM-P server that is being used withthe NSD and NRC modules.

5.6.2 Steps

1

Navigate to /opt/nsp/configure in the Linux host environment.

2

Copy the entire samTemplates directory at this location to the NFM-P server that is being usedwith the NSD and NRC modules. If the systems have been deployed in a redundantconfiguration, this directory must be copied to the designated primary NFM-P server.

Post-installation activitiesTo enable TCAs for NRC-F

NSD | NRC




3

On the NFM-P server, navigate to the samTemplates directory and follow the instructions in theREADME file to install the required NFM-P Templates.

END OF STEPS

5.7 To disable websocket event notifications

5.7.1 Purpose

Websocket-based events are used by the NSD and NRC applications and are exposed only to thetenant who owns the resource in question, as well as to the admin GUI. This procedure can beused to disable websocket event notifications.

Note: The websocket connection used by the NSD and NRC modules may not work if thebrowser, or any client, is behind a proxy. Websocket communication through any entity that ispositioned between the websocket client and server (such as proxies, firewalls, or loadbalancers) is dependent on how those entities are configured.

5.7.2 Steps

1

As nsp user, navigate to the following directory: /opt/nsp/configure/config

2

Open the wsc-security.conf file.

3

Modify the section below as follows:

websocket{

enableEvents=false

}

4

Restart the NSD and NRC modules. Execute:

systemctl restart nsp-tomcat

END OF STEPS

Post-installation activitiesTo disable websocket event notifications

NSD | NRC




56 Issue 1

5.8 To uninstall an NSD and NRC system

5.8.1 Purpose

Use this procedure to uninstall either a standalone NSD and NRC system, or a redundant NSD andNRC system.

5.8.2 Steps

1

Perform one of the following:

a. Modify the hosts file in the installer directory so as to contain the IP addresses of thesystems from which the NSD and NRC software will be uninstalled.

b. Create a new hosts file, as described in 3.2 “To install a standalone NSD and NRC system”(p. 25), that contains the IP addresses of the systems from which the NSD and NRCsoftware will be uninstalled.

2

Execute the following commands:

cd bin/

./uninstall.sh

The NSD and NRC software is removed from all hosts declared in the hosts file.

END OF STEPS

Post-installation activitiesTo uninstall an NSD and NRC system

NSD | NRC




Post-installation activitiesTo uninstall an NSD and NRC system

NSD | NRC




58 Issue 1

6 Security

6.1 Introduction

6.1.1 Overview

This chapter describes various tasks related to security that may need to be performed following aninstallation or upgrade of an NSD and NRC system.

Note: A certificate from a certification authority, or CA, is strongly recommended for a liveNFM-P deployment.

6.2 To configure the NSP security statement

6.2.1 Purpose

Use this procedure to configure the security statement that is displayed on the NSP login page.

6.2.2 Steps

Preserve the system security statement

1

Perform the following steps if upgrading an NSP deployment that includes both the NFM-Pmodules and the NSD and NRC modules from an earlier release of NSP to NSP Release 17.3or later.

Note: These steps do not have to be performed if upgrading from 5620 SAM Release14.0 R7 to NSP Release 17.6 or later.

1. Copy the existing security statement from the NFM-P Java client.

2. Paste the copied statement into an empty file, and save the file in text format.

3. Copy the file to a secure location that is unaffected by the system upgrade activity.

Upgrade or install the NSD and NRC and start the nspOS

2


• Upgrade or install your standalone NSD and NRC system, as described in 3.2 “To install astandalone NSD and NRC system” (p. 25).

• Upgrade or install your redundant NSD and NRC system, as described in 4.2 “To install aredundant NSD and NRC system” (p. 33).

3

SecurityIntroduction

NSD | NRC




Start the nspOS.

Configure the NSP security message

4

Log in to the NSP server as the admin user.

5

From the launchpad, go to More > Settings > NSP System Settings > Security Statement.

6


a. Paste the security statement that was copied in Step 1

b. Add the appropriate security statement.

Note: The security statement will not be displayed the first time that the NSP login page isaccessed.

END OF STEPS

6.3 To generate a keystore

6.3.1 Purpose

Keystores provide identity verification and encryption on all northbound and internal interfaces. Akeystore is automatically generated by the NSD and NRC installer, however, this procedure can beused to manually generate a keystore. Keystores are required to be in the Java KeyStore (JKS)format. A keystore that contains a self-signed security certificate can be generated using the JavaKeytool that ships with any Java Development Kit (JDK) or Java Runtime Environment (JRE).

6.3.2 Steps

1

Execute the following Keytool command:

./keytool –genkeypair –keystore <file name> –keypass <key password>

-storepass <store password> –keyalg rsa –alias <alias name> –dname

“CN=<common name>, OU=<organizational unit>, O=<organization>,

L=<location>, ST=<state>, C=<country>” –validity <days> -ext

bc=ca:true -ext san=<SAN string>

where

file name is the absolute path to the Java KeyStore file that will hold the public/private key pairthat is generated

key password is the password that is used to access the private key stored within the keystore

SecurityTo generate a keystore

NSD | NRC




60 Issue 1

store password is the password to access the contents of the keystore

alias name is the human-readable identifier for the key pair that is used to differentiate betweendifferent keys in a keystore

common name is the name of the keystore owner

organizational unit is the name of the organizational unit to which the keystore owner belongs

organization is the name of the organization to which the keystore owner belongs

location is the name of the city in which the keystore owner resides

state is the name of the state or province in which the keystore owner resides

country is the name of the country in which the keystore owner resides

days is the integer value for the number of days for which the keys should be considered valid

SAN string is a list of all interfaces on the NSD and NRC server(s), pre-pended with the “IP:”string. This list must contain the loopback (127.0.0.1) interface.For example, a redundant NSDand NRC deployment with 2 servers having the IPs 10.0.0.1 and 10.0.0.2 would use: -extsan=IP:127.0.0.1,IP:10.0.0.1,IP:10.0.0.2. If hostnames were used during installation, they mustbe included, pre-pended with the “DNS:” string. For example, -extsan=IP:127.0.0.1,DNS:<hostname>.nokia.com.

2

Use the custom_keystore_path parameter, under the ssl section, to point to the generatedkeystore file. You should also set the other ssl values to match the parameters specified in thecommand listed above.

END OF STEPS

6.4 To generate a Root CA

6.4.1 Purpose

Use this procedure to generate a Root CA for the NSP system.

Note: This procedure should only be executed once per NSP system. The generated Root CAartifacts must be used to configure all modules in the deployment.

The NSP should only be used as a certificate authority, or CA, for other NSP modules.

6.4.2 Steps

1

Log in to a primary NSP server as the nsp user.

2

Execute the following command to generate the ca.jks Root CA keystore:

keytool -genkeypair -keyalg RSA -keystore ca.jks -alias nspca -ext

bc:c=ca:true -storepass <ca store password> -keypass <ca key password>

SecurityTo generate a Root CA

NSD | NRC




-dname CN=NSPCA,O=Nokia -validity 7300

where

ca store password is the password to be used with the CA keystore

ca key password is the password to be used with the CA key

Note: All passwords used in this procedure should be recorded for future use.

3

Execute the following command to generate the ca-cert.pem Root CA certificate:

keytool -exportcert -keystore ca.jks -storepass <ca store password>

-alias nspca -rfc -file ca-cert.pem

Where ca store password is the password to be used with the CA store.

4

Store the generated Root CA artifacts in a central, persistent location. A backup should bemade. These artifacts will be required each time an additional module is added to the NSPsystem.

END OF STEPS

6.5 To enable SSL communication to the NFM-P

6.5.1 Purpose

Use this procedure to enable SSL communication to a standalone/primary NFM-P server using acustom SSL certificate. For a redundant NFM-P deployment, this procedure must also beperformed on the standby server.

To enable SSL communication to the NFM-P using a non-custom SSL certificate, see 6.7 “Toenable SSL communication to the NFM-P using a non-custom certificate” (p. 66).

6.5.2 Steps

1

If a Root CA keystore and certificate have not already been generated, perform 6.4 “Togenerate a Root CA” (p. 61) and copy the generated Root CA artifacts to a directory named/opt/ssl on the NFM-P server.

2

Log in to the NFM-P server and execute the following commands as the nsp user:

cd /opt/ssl

keytool -genkeypair -keyalg RSA -keystore server.jks -alias <server

alias> -storepass <keystore password> -keypass <key password> -dname

SecurityTo enable SSL communication to the NFM-P

NSD | NRC




62 Issue 1


keytool -certreq -keystore server.jks -alias <server alias> -file

server.csr -storepass <keystore password> -ext san=IP:127.0.0.1,IP:

<server address>[,IP:<standby server address>]



keyEncipherment -ext eku:c=serverAuth,clientAuth -rfc -ext honored=all

-infile server.csr -outfile server.pem

cat ca-cert.pem server.pem | keytool -importcert -noprompt -alias

<server alias> -keystore server.jks -storepass <keystore password>

keytool -importcert -noprompt -file ca-cert.pem -alias nspca -keystore

truststore.jks -storepass <truststore password>


server.jks -storepass <keystore password>

where

server alias is the alias used by the NFM-P server

keystore password is the password used with the keystore

key password is the password used with the key

server address is the IP address of the NFM-P server

standby server address is the IP address of the standby NFM-P server

ca store password is the password used with the Root CA artifacts

truststore password is the password used with the truststore

Note: “DNS:myhostname.domain.com” may be included in the san string if hostnameswere used during installation.

3

The following files are created, and will be used to reconfigure the NFM-P server(s) usingsamconfig:

• /opt/ssl/server.jks

• /opt/ssl/truststore.jks

4

Follow the “SSL Configuration workflow” in the NSP NFM-P Installation and Upgrade Guide toreconfigure SSL for the NFM-P server with the newly-generated keystore and truststore.

END OF STEPS

SecurityTo enable SSL communication to the NFM-P

NSD | NRC




6.6 To enable SSL communication to the NSD and NRC

6.6.1 Purpose

Use this procedure to enable SSL communication to a standalone/primary NSD and NRC server.

For a redundant NSD and NRC deployment, this procedure must also be performed on the standbyserver.

For an NSD and NRC deployment that includes NRC-X, this procedure must also be performed onthe server where the NRC-X software is deployed

6.6.2 Steps

1

If a Root CA keystore and certificate have not already been generated, perform 6.4 “Togenerate a Root CA” (p. 61) and copy the generated Root CA artifacts to a directory named/opt/ssl on the NSD and NRC, or NRC-X server.

2

Log in to the NSD and NRC, or NRC-X server and execute the following commands as the nspuser:

cd /opt/ssl

keytool -genkeypair -keyalg RSA -keystore server.jks -alias <server

alias> -storepass <keystore password> -keypass <key password> -dname


keytool -certreq -keystore server.jks -alias <server alias> -file

server.csr -storepass <keystore password> -ext san=IP:127.0.0.1,IP:

<server address>[,IP:<standby server address>]



keyEncipherment -ext eku:c=serverAuth,clientAuth -rfc -ext honored=all

-infile server.csr -outfile server.pem

cat ca-cert.pem server.pem | keytool -importcert -noprompt -alias

<server alias> -keystore server.jks -storepass <keystore password>


truststore.jks -storepass <truststore password>

where

server alias is the alias used by the NSD and NRC server

keystore password is the password used with the keystore

key password is the password used with the key

SecurityTo enable SSL communication to the NSD and NRC

NSD | NRC




64 Issue 1

server address is the IP address of the NSD and NRC server


ca store password is the password used with the Root CA artifacts

truststore password is the password used with the truststore

Note: “DNS:myhostname.domain.com” may be included in the san string if hostnameswere used during installation.

3

The following files are created, and will be used to reconfigure the server(s):

• /opt/ssl/server.jks

• /opt/ssl/truststore.jks

4

Add the following configuration block to the configuration file in the directory where the NSDand NRC installer bundle was extracted:

ssl:

custom_keystore_path: “/opt/ssl/server.jks”

custom_truststore_path: “/opt/ssl/truststore.jks”

custom_keystore_password: “<keystore_password>”

custom_truststore_password: “<truststore_password>”

custom_key_alias: “<server_alias>”

custom_key_password: “<key_password>”

5

If using SSL to communicate with an NFM-P, perform the following:

1. Add the following configuration block to the configuration file in the directory where the NSDand NRC installer bundle was extracted:

nfmp:

cert_provided:true

2. Copy the Root CA certificate to the installer. Execute:

cp /opt/ssl/ca-cert.pem <installer_bundle_dir>/ssl/nfmp

6

If using SSL to communicate with an NFM-T, perform the following:

1. Add the following configuration block to the configuration file in the directory where the NSDand NRC installer bundle was extracted:

SecurityTo enable SSL communication to the NSD and NRC

NSD | NRC




nfmt:

cert_provided:true

2. Copy the Root CA certificate to the installer. Execute:

cp /opt/ssl/ca-cert.pem <installer_bundle_dir>/ssl/nfmt

7

Stop the NSD and NRC services. If this is a redundant NSD and NRC deployment, the servicesmust be stopped on both the primary and standby servers. As the nsp user, execute:

nspdctl stop

8

Reconfigure the NSD and NRC. From the directory where the NSD and NRC installer bundlewas extracted, execute the following commands as the root user:

cd bin

./install.sh

END OF STEPS

6.7 To enable SSL communication to the NFM-P using a non-customcertificate

6.7.1 Purpose

Use this procedure to enable SSL communication to an NFM-P system using a non-custom SSLcertificate.

6.7.2 Steps

1

Retrieve the cacerts.trustStore file from the /opt/nsp/nfmp/server/nms/config/ssl/trustStore/directory on the NFM-P server.

2

Extract the certificate in from the trustStore using the java keytool utility. Execute the followingcommand:

/opt/nsp/os/jre/bin/keytool keytool -exportcert -keystore cacerts.

trustStore -alias <cert_alias> -storepass <trustStore_password> -rfc

-file nfmp.pem

where

cert_alias is the alias of the certificate in the NFM-P trustStore

SecurityTo enable SSL communication to the NFM-P using a non-custom certificate

NSD | NRC




66 Issue 1

truststore_password is the password for the trustStore container

3

Place the generated nfmp.pem file in the ssl/nfmp/ folder where the NSD and NRC installerbundle was extracted.

END OF STEPS

6.8 To enable SSL communication to the NFM-T using a customcertificate

6.8.1 Purpose

Use this procedure to enable SSL communication to an NFM-T system using a custom SSLcertificate.

6.8.2 Steps

1

Retrieve the server.crt file from the /usr/Systems/Global_Instance/APACHE/conf/ssl.crtdirectory on the NFM-T server.

2

Place the server.crt file in the ssl/nfmt/ folder where the NSD and NRC installer bundle wasextracted.

END OF STEPS

6.9 To retroactively enable SSL communication to the NFM-P

6.9.1 Purpose

Use this procedure to enable SSL communication to the NFM-P after NSD and NRC installation hasbeen completed.

6.9.2 Steps

1

Copy the NFM-P certificate into the ssl/nfmp/ folder where the NSD and NRC installer bundlewas extracted.

2

Ensure that your NSD and NRC configuration file has been modified so as to enable SSL onNFM-P. For example:

SecurityTo enable SSL communication to the NFM-T using a custom certificate

NSD | NRC




nfmp:

cert_provided: true

3

Run the install script to re-configure the NSD and NRC with NFM-P SSL configured. Execute:

cd bin

./install.sh

END OF STEPS

SecurityTo retroactively enable SSL communication to the NFM-P

NSD | NRC




68 Issue 1

7 Backup and restore

7.1 Introduction

7.1.1 Overview

This chapter describes the procedures that must be performed in order to preserve crucial systemdata in the case of a catastrophic failure.

7.2 To manually backup the PostgreSQL and Neo4j databases

7.2.1 Purpose

Use this procedure to manually backup the contents of the PostgreSQL and Neo4j databases.

Note: backups of these databases are taken automatically each day through a cron job andstored in the /opt/nsp/backup/scheduled directory for up to seven days. A maximum of fourbackups taken on Wednesdays can be saved for up to one month. The /opt/nsp/scripts/db/nsp-backup.conf file can be modified in order to customize this automated backup schedule.

7.2.2 Steps

1

Log in to the primary NSD and NRC server as the nsp user.

2

Execute:

nspdctl backup nspos_migration -f

3

Verify that the backup has completed successfully. Execute:

nspdctl backup status

4

As nsp user, transfer the backup files from /opt/nsp/backup/nspos_migration/ to the /tmp/nspos_migration directory within the NSD and NRC server.

Note: If the NSD and NRC system was deployed in a redundant configuration, the backupfiles must be transferred to the active NSD and NRC server.

END OF STEPS

Backup and restoreIntroduction

NSD | NRC




7.3 To restore the PostgreSQL and Neo4j databases

7.3.1 Purpose

Use this procedure to restore the PostgreSQL and Neo4j databases from backups following acatastrophic system failure.

Note: All commands presented in this procedure must be executed as nsp user.


Prior to restoring the databases, backups must be created using the nspdctl backup CLIcommand, or using the POST /backup/trigger/ REST API method. See the NSP Developer portal formore information.

7.3.3 Steps

1

Backup the PostgreSQL and Neo4j databases as described in 7.2 “To manually backup thePostgreSQL and Neo4j databases” (p. 69).

2

Stop the SDN and nspOS services. Execute the following command:

nspdctl stop

Note: This command should be executed on both servers in a redundant NSD and NRCdeployment.

3

To restore the PostgreSQL database, perform the following steps on a standalone NSD andNRC server, or on the primary server in a redundant deployment:

1. Extract the nsp-postgresql backup set. As nsp user, execute:

mkdir /tmp/nspos-postgresql_backup

tar -xv -C /tmp/nspos-postgresql_backup -f /tmp/nspos_

migration/nspos-postgresql_backup_<time stamp>.tar.gz


2. Run the database restore. Execute:

/opt/nsp/os/pgsql/scripts/pg-restore.sh -f /tmp/nspos-postgresql_

backup/nspdb.custom

Confirm your intention to drop and recreate the NSP database.

4

If the NSD and NRC system was deployed in a redundant configuration, execute the followingcommands to restore the PostgreSQL database on the standby server:

Backup and restoreTo restore the PostgreSQL and Neo4j databases

NSD | NRC




70 Issue 1

/opt/nsp/os/pgsql/scripts/repmgr-standby-bootstrap.sh

5

To restore the Neo4j database, perform the following:

1. Extract the nspos-neo4j backup set. Execute:

mkdir /tmp/nspos-neo4j-backup

tar -xv -C /tmp/nspos-neo4j_backup -f /tmp/nspos_

migration/nspos-neo4j_backup_<time stamp>.tar.gz


2. Restore the nspos-neo4j backup set. Execute:

/opt/nsp/os/neo4j/bin/neo4j-admin restore --from=/tmp/nspos-neo4j_

backup/graph.db --database=graph.db --force

3. Extract the nsp-tomcat backup set. Execute:

mkdir /tmp/nsp-tomcat-backup

tar -xv -C /tmp/nsp-tomcat_backup -f /tmp/nspos_

migration/nsp-tomcat_backup_<time stamp>.tar.gz


4. Restore the nsp-tomcat backup set. Execute:

/opt/nsp/scripts/db/neo4j/bin/neo4j-admin restore --from=

/tmp/nsp-tomcat_backup/graph.db --database=graph.db --force

Note: These commands should be executed on both servers in a redundant NSD andNRC deployment.

6

Restart the nspd agent. Execute:

nspdctl start

Note: This command should be executed on both servers in a redundant NSD and NRCdeployment.

END OF STEPS


NSD | NRC





NSD | NRC




72 Issue 1

installation and upgrade guide - nokia networks network services platform network resource...

Documents