Release Announcement: NSO 6.5 is now released.
Head to the release highlights to see what's new
LogoLogo
NSO DevCenterTry NSO
NSO 6.3
  • Get Started
  • User Guides
  • Developers
  • Release Info
NSO 6.3
  • Start
  • What's New
  • Administration
    • Get Started
    • Installation and Deployment
      • Local Install
      • System Install
      • Post-Install Actions
        • Explore the Installation
        • Start and Stop NSO
        • Create NSO Instance
        • Enable Development Mode
        • Running NSO Examples
        • Migrate to System Install
        • Modify Examples for System Install
        • Uninstall Local Install
        • Uninstall System Install
      • Containerized NSO
      • Deployment Example
      • Upgrade NSO
    • Management
      • System Management
        • Cisco Smart Licensing
        • Log Messages and Formats
        • Alarm Types
      • Package Management
      • High Availability
      • AAA Infrastructure
      • NED Administration
    • Advanced Topics
      • Locks
      • Compaction
      • IPC Ports
      • Service Manager Restart
      • Security Issues
      • Run NSO as Non-Privileged User
      • IPv6 on Northbound Interfaces
      • Layered Service Architecture
  • Operation & Usage
    • Get Started
    • CLI
      • Introduction to NSO CLI
      • CLI Commands
    • Web UI
      • Home
      • Devices
      • Services
      • Config Editor
      • Tools
    • Operations
      • Basic Operations
      • NEDs and Adding Devices
      • Manage Network Services
      • NSO Device Manager
      • SSH Key Management
      • Alarm Manager
      • Plug-and-Play Scripting
      • Compliance Reporting
      • Listing Packages
      • Lifecycle Operations
      • Network Simulator
  • Development
    • Get Started
    • Introduction to Automation
      • CDB and YANG
      • Basic Automation with Python
      • Develop a Simple Service
      • Applications in NSO
      • Develop and Deploy a Nano Service
    • Core Concepts
      • Services
      • Implementing Services
      • Templates
      • Nano Services
      • Packages
      • Using CDB
      • YANG
      • NSO Concurrency Model
      • Service Handling of Ambiguous Device Models
      • NSO Virtual Machines
        • NSO Python VM
        • NSO Java VM
        • Embedded Erlang Applications
      • API Overview
        • Python API Overview
        • Java API Overview
      • Northbound APIs
        • NSO NETCONF Server
        • RESTCONF API
        • NSO SNMP Agent
    • Advanced Development
      • Development Environment and Resources
      • Developing Services
        • Services Deep Dive
        • Service Development Using Java
        • NSO Developer Studio
      • Developing Packages
      • Developing NEDs
        • NETCONF NED Development
        • CLI NED Development
        • Generic NED Development
        • SNMP NED
        • NED Upgrades and Migration
      • Developing Alarm Applications
      • Kicker
      • Scaling and Performance Optimization
      • Progress Trace
      • Web UI Development
        • JSON-RPC API
    • Connected Topics
      • SNMP Notification Receiver
      • Web Server
      • Scheduler
      • External Logging
      • Encryption Keys
  • Resources
    • Manual Pages
      • Section 1
      • Section 3
      • Section 5
Powered by GitBook
LogoLogo

Site

  • Cisco.com
  • Documentation
  • Learning Labs
  • Sample Code

Connect

  • Feedback
  • Community
  • Blogs
  • Events

Follow Us

  • X/Twitter
  • Facebook
  • YouTube
  • LinkedIn

© Copyright 2025 Cisco Systems, Inc. | This site is part of the official Cisco Crosswork NSO documentation set.

On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. Administration
  2. Advanced Topics

IPC Ports

Connect client libraries to NSO with IPC Ports.

PreviousCompactionNextService Manager Restart

Was this helpful?

Client libraries connect to NSO using TCP. We tell NSO which address to use for these connections through the /ncs-config/ncs-ipc-address/ip (default value 127.0.0.1) and /ncs-config/ncs-ipc-address/port (default value 4569) elements in ncs.conf. It is possible to change these values, but it requires a number of steps to also configure the clients. Also, there are security implications, see .

Some clients read the environment variables NCS_IPC_ADDR and NCS_IPC_PORT to determine if something other than the default is to be used, others might need to be recompiled. This is a list of clients that communicate with NSO, and what needs to be done when ncs-ipc-address is changed.

Client
Changes required

Remote commands via the ncs command

Remote commands, such as ncs --reload, check the environment variables NCS_IPC_ADDR and NCS_IPC_PORT.

CDB and MAAPI clients

The address supplied to Cdb.connect() and Maapi.connect() must be changed.

Data provider API clients

The address supplied to Dp constructor socket must be changed.

ncs_cli

The Command Line Interface (CLI) client, ncs_cli, checks the environment variables NCS_IPC_ADDR and NCS_IPC_PORT. Alternatively the port can be provided on the command line (using the -P option).

Notification API clients

The new address must be supplied to the socket for the Nofif constructor.

To run more than one instance of NSO on the same host (which can be useful in development scenarios), each instance needs its own IPC port. For each instance, set /ncs-config/ncs-ipc-address/port in ncs.conf to something different.

There are two more instances of ports that will have to be modified, NETCONF and CLI over SSH. The netconf (SSH and TCP) ports that NSO listens to by default are 2022 and 2023 respectively. Modify /ncs-config/netconf/transport/ssh and /ncs-config/netconf/transport/tcp, either by disabling them or changing the ports they listen to. The CLI over SSH by default listens to 2024; modify /ncs-config/cli/ssh either by disabling or changing the default port.

Restricting Access to IPC port

By default, the clients connecting to the IPC port are considered trusted, i.e. there is no authentication required, and we rely on the use of 127.0.0.1 for /ncs-config/ncs-ipc-address/ip to prevent remote access. In case this is not sufficient, it is possible to restrict access to the IPC port by configuring an access check.

The access check is enabled by setting the ncs.conf element /ncs-config/ncs-ipc-access-check/enabled to true, and specifying a filename for /ncs-config/ncs-ipc-access-check/filename. The file should contain a shared secret, i.e., a random character string. Clients connecting to the IPC port will then be required to prove that they have knowledge of the secret through a challenge handshake before they are allowed access to the NSO functions provided via the IPC port.

The access permissions on this file must be restricted via OS file permissions, such that it can only be read by the NSO daemon and client processes that are allowed to connect to the IPC port. E.g. if both the daemon and the clients run as root, the file can be owned by root and have only "read by owner" permission (i.e. mode 0400). Another possibility is to have a group that only the daemon and the clients belong to, set the group ID of the file to that group, and have only "read by group" permission (i.e. mode 040).

To provide the secret to the client libraries and inform them that they need to use the access check handshake, we have to set the environment variable NCS_IPC_ACCESS_FILE to the full pathname of the file containing the secret. This is sufficient for all the clients mentioned above, i.e., there is no need to change the application code to support or enable this check.

The access check must be either enabled or disabled for both the daemon and the clients. E.g., if /ncs-config/ncs-ipc-access-check/enabled in ncs.conf is not set to true but clients are started with the environment variable NCS_IPC_ACCESS_FILE pointing to a file with a secret, the client connections will fail.

Security Issues