Bratislava, Slovakia January 17th, 2018
FRINX UniConfig Framework
We are excited about the new components that we have added to our software. We call it the UniConfig Framework.
The purpose of the UniConfig Framework is to manage configuration of physical and virtual networking devices through a unified OpenConfig based interface. In addition, the UniConfig framework enables device and network wide transactions so that the network will always remain in a well-defined state without leftovers from failed configuration attempts.
The UniConfig framework consists of 3 layers that can be accessed individually or through the UniConfig manager API.
The lowest layer (Southbound layer) provides connectivity to the network devices through NETCONF and CLI via Telnet and SSH. It includes translation units that map data in OpenConfig format to vendor specific CLI implementations and vice versa. This translation unit library is open source and publicly available on GitHub (https://github.com/FRINXio/cli-units).
The middle layer (Unified layer) combines devices mounted under various protocols (e.g. NETCONF and CLI) and makes them accessible under a unified mount point to higher layers. This abstracts the type of southbound protocol used away from the user for regular device interaction. The unified layer also provides OpenConfig YANG to vendor specific YANG translation capabilities.
The top layer (UniConfig layer) provides the ability to read and write OpenConfig based configurations to and from devices. It also adds the capability to create configuration snapshots that can be committed and can be rolled back by the system if they have failed. The UniConfig layer also adds the capabilities to compare network intent (located in the configuration data store), analyze the diffs between intended state and actual state (located in the operational data store) and finally apply the new state to the devices connected through lower layers via atomic operations. This means that only configuration elements that were changed in the most recent operation need to be sent to the devices and not the complete configuration.
The UniConfig layer can be used by applications (e.g. L3VPN and L2VPN service modules provided by FRINX or customer applications by our customers) or by users directly through REST calls (e.g. via Postman collections or via the FrinxIT CLI).
Here are the key topics we had in mind when building the solution:
We decided to build a system that “understands” the configuration on each device that it is connected to. UniConfig is not just a simple, template based configuration system; rather it reads and interprets vendor specific device configurations and represents them internally via the OpenConfig data models. This allows us to reconcile between the device configuration and the operational data store in the UniConfig Framework, compare and create diffs between different platforms and migrate configurations between different vendor implementations.
Our customers expect highly available solutions hence we are using 3-node clustering technology based on Akka technology and the Raft algorithm that allows us to operate with the highest availability.
Open Source device libraries
The UniConfig Framework is based on open source projects like ODL and Honeycomb and publishes all translation units publicly under the Apache v2 license. Customers and integration partners can freely contribute and modify and create additional device models that work with the UniConfig Framework.
OpenConfig & IETF models
We support OpenConfig as our internal data model for our UniConfig modules. We have implemented IETF models on the northbound of our L2VPN and L3VPN service models. This simplifies configuration portability between network devices and allows FRINX to deliver a system that can be used out of the box for many applications without costly integration projects.
The UniConfig Framework stores the configuration of all network devices in OpenConfig JSON format which can be included in version control systems like Git. This allows users to commit new configuration elements via well known version control practice manually or programmatically. Network operators can integrate these commits and first test them in simulated environments before the changes are finally committed to the production network devices.
We built the UniConfig Framework with network professionals and software engineers in mind. We see that customers are using software development techniques and workflows to interact with the network. The UniConfig Framework introduces these capabilities to existing and new networks and enables far reaching automation.
+421 2 209 101 41