FRINX UniConfig

UniConfig reliably manages configurations and services in simple and complex communication networks.

  • Model-based

    YANG data models are used for device abstraction, CLI plain text can be translated into structured data by YANG and vice versa.

  • Intent-based networking

    Describe your intent in the UniConfig data store and have UniConfig commit it to network elements.

  • Open-source device library

    A library to connect to many networking devices. Open-source and extensible by customers, accessible on Github (https://github.com/FRINXio/cli-units).

  • State-aware

    Read config and operational state from network devices (brownfield & greenfield) and push atomic updates to the network.

  • Transactions

    Provides network-wide transaction capabilities within one or across multiple UniConfig clusters.

  • Agentless approach

    You can use them if you choose to, but you are not dependent on agents running on devices.

  • Horizontal scale

    Control millions of devices by sharding them across multiple UniConfig clusters.

  • High availability

    Deploy single nodes of UniConfig or dual nodes for redundancy.

FRINX UniConfig

Network engineers and developers use FRINX UniConfig to configure simple and complex network devices and automate network services. FRINX UniConfig reconciles and configures state from brownfield and greenfield networks alike. By using UniConfig, operators can leverage their existing network assets, while at the same time taking advantage of an open-source automation solution. FRINX UniConfig supports CLI automation, translation capabilities (CLI <-> YANG/OpenConfig) as well as NETCONF/YANG model-based automation.

FRINX UniConfig includes a data store that holds config and operational data and that is optimized for serving YANG data with high performance. FRINX UniConfig uses a layered design, where the functionality of the upper layers depends on functionality provided by the next lower layer. Each layer thus provides a higher level of abstraction from the network elements. Each layer can be accessed individually with a set of APIs.

the 3 layers are (from top to bottom):

  • UniConfig Layer
  • Unified layer
  • Southbound layer

The UniConfig layer provides APIs to create, read, update and delete atomic device configurations. The UniConfig layer stores device configurations based on their YANG models. The config data store contains intended configurations of all network devices of that UniConfig cluster, while operational data store contains all current configurations. Network transaction capabilities provide commit, snapshot and rollback functions across one or multiple devices.

The Unified layer combines devices connected via different transport protocols and different models into a common representation to upper layers.

The Southbound layer provides connectivity to devices via multiple protocols (NETCONF, SSH, Telnet, …). It includes an open-source device library to communicate with a broad range of network devices directly via CLI. The southbound layer also provides an optional translation library between CLI and OpenConfig data models.

FRINX UniConfig can be deployed as a container, binary executable and in a VM form factor. FRINX UniConfig can be deployed as a single node or in pairs for redundancy. The horizontal scale is achieved through sharding across multiple UniConfig clusters in conjunction with FRINX Machine.

UniConfig UI

All features and functions of UniConfig can be accessed via a RESTful API. In addition, FRINX provides client libraries in GO and Python to access OpenConfig models and UniConfig RPCs directly from user code.

Try out UniConfig for free

Try out UniConfig together with FRINX Machine here (see “Installation Guide” in the Readme section):

https://github.com/FRINXio/FRINX-machine

 

Download UniConfig stand-alone here (sign-in required):

https://frinx.io/downloads

 

Learn about UniConfig here:

https://docs.frinx.io/frinx-odl-distribution/oxygen/getting-started.html

Contribute: