Support for multiple network interfaces

Introduction

The NSP and its associated components communicate with different entities that typically exist in different network spaces. Isolating different types of traffic to different networks provides better security and helps manage traffic volume on different networks.

NSP supports configuring different network interfaces to handle the following types of traffic in a multi-homed system.

• A client network interface can be used for connecting users to NSP GUI and to connect external OSS systems to NSP.

• An internal network interface can be used to handle traffic between NSP systems that does not need to be accessed by external systems or with managed network elements. Internal traffic includes, but is not limited to, resync of network topology information, security communications, application registration and data synchronization between redundant components.

• A mediation network interface can be used to communicate with network elements (provisioning, NE database backups, monitoring, operations, etc).

Component support and limitations

A NSP cluster can be configured with network interfaces for client traffic, for internal network management traffic, and for managed network traffic. In a multi-node NSP cluster, each node must have the same number of interfaces. Each node of the NSP cluster must have mediation network connectivity to all managed NE devices as MDM pods may be rescheduled on different nodes in the NSP cluster.

A deployer node must be available to the NSP cluster nodes on the internal network. The deployer node must also have access to the client network if ELB is enabled in the nsp-config.yml file.

A NSP cluster must communicate with a VSR-NRC using the BOF interface.

The NFM-P supports integrated deployment with NSP cluster using network interfaces for client, internal and managed network traffic.

An integrated deployment of multi-interface NSP cluster with an older release NFM-P is supported but a workaround procedure is required on the NFM-P system. The workaround will enable the separation of client and internal network traffic between NFM-P and NSP cluster. See the NSP Installation and Upgrade Guide for details on the integration procedure for older release NFM-P.

The following figure shows a multi network interface deployment of NSP cluster, deployer host and NFM-P.

Figure 7-1: Multi-interface NSP deployment

The NSP cluster can be deployed with one interface for all client, network management and NE traffic. The NSP cluster can be deployed with one interface for client and internal network traffic, and a second interface for NE traffic. All servers in an NSP deployment must support the same network configuration for client and internal networks. For example, an NSP cluster deployed with network interfaces for client and internal networks cannot be deployed with a NFMP server that is configured for one interface supporting client and internal communications.

When installing NSP components on stations with multiple network interfaces, each interface must reside on a separate subnet, with the exception of interfaces that are to be used in IP Bonding.

There is no requirement on the NSP cluster to use the first network interface (eg. eth0, bge0) to communicate with client applications.

Additional network interfaces can be configured on the NSP cluster, at the customer's discretion, for other operations such as archiving database backups or activity logs.

When an NSP cluster is deployed with WS-NOC , the separation of client and internal network traffic is not supported. NSP and WS-NOC must use a single network for client and internal communications.

When using custom TLS certificates in a multi-network configuration, the NSP server certificate requires the IP address or hostname or FQDN of the client network interface (or virtual IP) and the IP address or hostname or FQDN of the internal network interface (or virtual IP) in the certificate SAN field (ref parameters advertisedAddress and internalAdvertisedAddress in nsp-config.yml).

Multi-interface support in IPv4 and IPv6 networks

The NSP cluster can use IPv4 or IPv6 addressing on the client, internal and mediation network interfaces. In addition to the limitations and restrictions documented in section 4.2.1, the following conditions apply:

• The NSP cluster can only use IPv4 or IPv6 communications on the client network interface and on the internal network interface. The system network interfaces can have both IPv4 and IPv6 addresses assigned, but NSP communications on those interfaces can only use IPv4 or IPv6.

• The NSP cluster mediation interface supports IPv4 only, IPv6 only and IPv4 and IPv6 simultaneously. When NSP is configured with IPv4 and IPv6 mediation simultaneously, the NSP must have a dedicated mediation interface not shared with client and internal network communications.

• In an NSP deployment with separate network interfaces for client and internal communications, the client and internal networks must both use IPv4 or IPv6 addressing. Example, client communications on IPv4 and internal communications on IPv6 is not supported.

Multi-interface NSP deployment and firewalls

Customers can use firewall applications to protect NSP components but should be applied with care to ensure that NSP applications are not negatively impacted. NSP firewall rules are defined in Section 6.7 of this guide but need to be applied on the correct networks and network interfaces.

The following table summarizes the firewall rules for an NSP cluster deployment by each network or network interface.

Table 7-1: NSP cluster firewall communications by network interface

Network description	Permitted communications
Client network	Client communications as defined in Table 6-1, NSP Kubernetes virtual machine communications Kafka communications on ports 9092, 9093, 9094, 9192, 9193, 9194
Internal network	All communications with NFMP and with redundant datacenter All communications between cluster nodes and deployer node Kafka communications on ports 9292, 9293, 9294
Mediation network	Mediation communications as defined in Table 6-1, NSP Kubernetes virtual machine communications

The NSP cluster can communicate with some external components on any network interface, including

• remote authentication servers (LDAP, RADIUS, TACACS)

• VSR-NRC

• syslog server

• email server

Each node in an NSP cluster must allow the same traffic on each network interface.