NBI in NEXT

Introduction

In today's world, automated tools are increasingly used to interact with network infrastructure elements. This approach helps avoid some errors in managing network elements, receive timely information about network problems, and generate data for further analysis.

Typically, these functions are distributed among information systems that must interact with each other. Software interfaces are actively used to facilitate interaction between these systems. This article describes the software interface used in the NEXT monitoring system.

Description

The structure of network element monitoring and management systems consists of three main layers:

  • NE layer;

  • NMS/EMS layer;

  • OSS/BSS layer.

NE layer

The NE layer represents the network infrastructure devices for which management and control tasks are performed. Various network protocols are used to interact with NEs. For example, NEXT uses the following protocols when interacting with NEs:

  • SNMP: retrieving device metric values;

  • ICMP: checking device network availability;

  • FTP: downloading/uploading configurations, uploading firmware files;

  • Telnet/SSH: pre-configuration, executing commands via CLI.

NMS/EMS layer

This layer includes systems that implement NE monitoring and management functions. Generally, a layer includes several EMSs and one NMS. Each EMS interacts with a group of NEs, and an NMS interacts with each EMS. NEs can be grouped in various ways, for example, by vendor.

The structure of this layer is not strict, and the following scenarios are often possible:

  • There is no EMS, the NMS interacts directly with the NE;

  • The EMS and NMS are combined and constitute a single information system. OSS/BSS Layer

This layer includes systems that map business requests to the technical layer. On one side, the BSS contains the business requirements that must be met when NEs are configured, while the OSS converts these requirements from the BSS into a set of technical operations and transfers them to the NMS. On the other side, the NMS provides the BSS with data on NE operation, which is used in system and business analysis.

Implementation of NBI in NEXT

Let's consider NEXT's position in the structure shown in the figure above. NEXT is an EMS system, therefore it belongs to the NMS/EMS layer and occupies a position between the NMS and NE (see figure).

If you place a compass next to the structural diagram, you'll see that the NMS is located to the north of NEXT and the NE is to the south. This analogy is the basis for the naming of the interaction interfaces:

  • NMS SBI is connected to NEXT NBI;

  • NEXT SBI is connected to NE.

Interaction via the SBI and NBI interfaces is not standardized and can be implemented in various ways. These terms are used only to describe the system architecture. For example, the presence of an NBI interface in an EMS indicates whether the EMS interacts with a higher-level system, such as an NMS or OSS/BSS.

The details of SBI implementation in NEXT are described in the "NE Layer" subsection. Let's consider the features of NBI in NEXT:

  1. NBI is implemented as an HTTP REST API.

  2. NBI supports the following operations on NEXT objects:

- Devices and device groups:

  • Getting a list of device groups;

  • Creating/deleting a device group;

  • Getting a list of devices;

  • Deleting a device from the NEXT database.

- Communication channels:

  • Getting a list of communication channels.

- Incidents and incident rules:

  • Getting a list of incident rules;

  • Getting a list of incidents.

- Jobs:

  • Creating a task to add devices, apply a configuration, update software, or apply a license;

  • Getting a list of tasks;

  • Starting/cancelling tasks.

- Software files:

  • Getting a list of software files;

  • Deleting a software file.

  1. NEXT contains built-in documentation for NBI.

  • Documentation is available at http://next_url:5555/en/, where next_url is the IP address or domain name of NEXT.

  1. NEXT supports the ability to control NBI status: enabled/disabled (NBI is disabled by default).

  2. Using NBI requires authentication and authorization: NEXT supports the ability to create multiple NBI users with different access rights to objects and methods.

NBI Usage Examples

Let's look at an example of implementing some scenarios using NEXT NBI. The examples will use:

  • Python v3.13.5 programming language;

  • NEXT v2.0;

  • The network contains three network devices with IP addresses 192.168.98.10 - 192.168.98.12;

  • NEXT configuration:

- IP address: 192.168.110.237;

- NBI status: enabled;

- NBI user 'python' has been created with read and write permissions for all objects.

NEXT Authorization

To use NBI in NEXT, you must log in to the system. NEXT authorization is performed using the login and key combination generated during NBI user creation.

After successful authorization, NEXT provides a token with a 10-minute lifetime. After the token expires, you must re-authorize.

To authorize, you must make a POST request of the following format:

The token received after successful authorization must be placed in the header of all requests. We'll use the 'head' variable for this:

Scenario 1: Adding Devices to the System

We'll break this scenario down into the following steps:

  1. Authorization in NEXT.

  2. Obtaining a list of device groups.

  3. Creating a task to add devices.

  4. Verifying the addition of devices.

Authorization in NEXT

The steps required for successful authorization are described in the "Authorization in NEXT" subsection.

Obtaining a list of device groups

To create a task to add devices, you'll need the following information:

  • IP ​​addresses of the devices;

  • Device group ID.

The IP addresses of the devices are known; we'll obtain the device group ID using a GET request:

The response to the query looks like this:

Creating a task to add devices

To add devices, we'll use the "Default group" with the ID "01GS7TRDVAE0B82YVM5M6V8GAC." Create a task to add devices using the following POST request:

Checking the addition of devices

Get a list of devices in the NEXT database using a GET request:

The response to the query looks like this:

The query result contains information about three devices with addresses 192.168.98.10 - 192.168.98.12, indicating that the task was successfully created and executed.

Code Listing

The code listing for Scenario 1 is as follows:

Scenario 2: Updating Software on Devices

We'll divide the scenario into the following steps:

  1. Authorization in NEXT.

  2. Selecting devices for software update.

  3. Uploading the software file.

  4. Creating a software update task.

Authorization in NEXT

The steps required for successful authorization are described in the "Authorization in NEXT" subsection.

Selecting devices for software update

Analysis of the device list in scenario 1 revealed that the following software versions are installed on the devices:

  • 192.168.98.10: TDMA v2.1.69

  • 192.168.98.11: TDMA v2.1.72

  • 192.168.98.12: TDMA v2.1.72

We'll select device 192.168.98.10 (host_id = 313659) for the update, as it has the following software versions. The firmware version on this device differs from the others.

Uploading the firmware file

The current version of NBI does not support uploading firmware files, so you must first upload them to NEXT. Verify that the firmware file has been uploaded using the following GET request:

The response to the query looks like this:

Creating a Software Update Task

Let's create a task to update the software for device 192.168.98.10 using the following POST request:

Let's check that the device's software has been successfully updated by requesting a list of devices using the following GET request (we'll add a filter to the request by the device identifier (host_id) for which the update task was created):

The response to the query looks like this:

Device 192.168.98.10 has TDMA v2.1.72 installed, meaning the firmware update task was successfully completed.

Code Listing

The code listing for Scenario 2 is as follows:

Scenario 3: Obtaining a list of incidents for the current day

We'll divide the scenario into the following steps:

  1. Authorization in NEXT.

  2. Obtaining a list of incidents.

Authorization in NEXT

The steps required for successful authorization are described in the "Authorization in NEXT" subsection.

Obtaining a list of incidents

We'll obtain a list of incidents created since midnight on August 4, 2025, using the following GET request (we'll add a filter by incident creation time (create_time) to the request):

The response to the query looks like this:

The response shows that two incidents were created for the device with host_id=313659 on August 4, 2025, and at the time the request was executed, they were in the Open status.

Code Listing

The code listing for Scenario 3 is as follows:

PreviousConfiguration example⁣⁣⁣NextCertificates

Last updated