Multi-interface configuration

Introduction

For greater security, you can configure multiple network interfaces to segregate the different types of NSP traffic.

When the NSP uses only one network for all communication, the NSP client traffic shares the same network as the NE mediation traffic and the internal communication between NSP components. Such a configuration may pose a considerable security risk.

You can segregate the NSP client, mediation, and internal traffic by configuring the NSP to use interfaces in separate networks for each traffic type.

Note: If you are deploying the NSP using multiple interfaces, the NSP deployer host must connect to the NSP cluster using the internal interface address specified in the NSP configuration file.

Traffic isolation

The multi-interface implementation isolates different traffic types to one or more of the following networks:

• client—for GUI, OSS, and other such northbound clients; for example, browser-based clients, REST clients, and Kafka subscribers.

• mediation—for direct communication with managed NEs

• internal—for communication such as the following:

  • traffic between NSP cluster members

  • communication with other NSP components or systems such as the VSR-NRC, NFM-P, and NSP analytics servers

  • traffic related to NSP DR functions such as data replication and keepalive messaging between data centers

Using separate networks enables you to apply additional security policies. For example, the NSP PostgreSQL service is an internal service only, and the only legitimate clients are NSP components, and not northbound browser or API clients. To help secure the PostgreSQL service from unintended access, you could apply a firewall rule to block the PostgreSQL port on the northbound client interface.

System conversion to multi-interface

You can convert an existing NSP system from a single-interface deployment to a multi-interface deployment, as described in Workflow for NSP system conversion to multi-interface.

NSP cluster multi-interface configuration

The platform section of the NSP configuration file has the following parameters for configuring multiple interfaces; see the descriptive text in the configuration file for more information:

Note: You must specify the client_address value, which is used as the default for any optional address parameter that you do not configure.

Note: If the client network uses IPv6, you must specify the NSP cluster hostname as the client_address value.

  advertisedAddress: "client_address"

  clusterHost: “cluster_host_address”

  mediationAdvertisedAddress: "IPv4_mediation_address"

  mediationAdvertisedAddressIpv6: "IPv6_mediation_address"

  internalAdvertisedAddress: "internal_cluster_address"

where

client_address is the public IPv4 address or hostname that is advertised to clients

cluster_host_address is the IPv4 address of a host with access to the Kubernetes cluster for management operations; typically cluster node1

internal_cluster_address is the optional IPv4 or IPv6 address, or internal hostname, for internal NSP communication

IPv4_mediation_address is the optional IPv4 address for NE management traffic

IPv6_mediation_addressIpv6 is the optional IPv6 address for NE management traffic

Multi-interface configuration for RPM-based components

If an NSP cluster is configured to use a separate internal interface, you must specify the internal interface address as the NSP cluster address in the configuration of other NSP components.

Note: The WS-NOC is an exception; you must specify the NSP client address as the NSP cluster address in the WS-NOC configuration, regardless of whether the internal interface is used by other components.