Internal NSP communication

Introduction

Communication among NSP components in a data center is performed over the internal network. Each internal interface is secured using TLS.

Note: TLS is also applied to the communication among internal NSP system services and processes. For additional robustness, the system-level communication uses a certificate from an internal root CA that is inaccessible to external agents.

Each NSP cluster member has a unique IP address; however, the cluster members share one virtual IP address.(VIP) that is assigned to the cluster for access by other components.

Figure 7-3: Internal NSP interfaces
Internal NSP interfaces

The following table describes each interface shown in Figure 7-3, Internal NSP interfaces.

Table 7-3: Internal NSP connections

Interface

Endpoints

Traffic type

1

NFM-P

NSP cluster

SSO authentication. Zookeeper registration, Kafka messaging, NFM-P API

2

NSP cluster

VSR-NRC (BOF interface)

Data connection – CROTO (non-secure)

3

WS-NOC

NSP cluster

SSO authentication, Zookeeper registration (non-secure), REST over HTTPS, proprietary WS-NOC HTTP communication

4

NSP cluster

Analytics hosts

SSO authentication, Zookeeper registration, Kafka messaging, PostgreSQL transactions

5

NFM-P

Analytics hosts

TLS-secured JDBC and REST

6

NFM-P

NSP Flow Collectors / Flow Collector Controllers

HTTPS, JMS

Communication between redundant data centers

NSP geographic redundancy, sometimes called geo-redundancy, uses a disaster-recovery (DR) mechanism to engage an identical NSP cluster at a standby site to support service continuity in the event that the primary site suffers an unrecoverable failure. To effectively support a DR NSP deployment, the NSP clusters at the geo-redundant sites require robust, secure communication.

The following NSP components perform DR communication over the internal NSP network:

For more information about DR deployments, see Chapter 8, System redundancy and fault tolerance.