Cloud native network functions (CNFs) are a hot topic today. In this blog post, I will take a stab at explaining why and also present the Ligato framework, which allows you to build your custom CNFs.
Why do we need CNFs when we have VNFs?
We started talking about Virtual Network Functions (VNFs) a few years ago when the concept of Network Function Virtualization (NFV) appeared. In short, it is that network functions can be deployed as virtual machines (VMs) instead of being delivered on dedicated hardware offered by vendors. Over time, telco operators and service providers launched their first field trials and then roll-outs of network functions based on this paradigm.
It was certainly a fundamental change in the way network functionality was delivered. What's more, it was one of the important aspects of the digital transformation that started in the network industry a few years ago and continues to this day. It largely consists in incorporating certain techniques, tools and methodologies from the IT world. And because here the challenges and related technological trends also change from time to time, it naturally has an impact on the network industry as well.
For example, today one of the very important aspects of building software solutions is to ensure that they can be easily deployed in the cloud environment. This paradigm is called “cloud native”. The Cloud Native Computing Foundation (CNCF) 
provides the following definition of a “cloud native” approach: “Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. ”
VNFs are not as hot a topic today as they were two or three years ago. As they are based on virtual machines, they often have too much "weight" or consume too much computing resources. Depending on their internal design, there may also be issues with their scalability and portability in different virtual environments. Instead, more and more attention is being given to the CNFs that use containers rather than VMs and by default have to be adapted to be deployed in clouds.
What is Ligato?
In short, Ligato is an open source Golang framework for building CNFs. The Ligato platform enables two important goals to be accomplished:
- create a CNF to meet the requirements of the cloud-native paradigm
- provide a requested network function within the defined CNF, while taking into account the requirements for its high performance
To understand how Ligato achieves these goals, let's take a look at its high-level functional architecture.
In a nutshell, the Ligato framework is a set of plugins. In general, plugins can be understood as modules that provide specific functions or perform specific tasks. The platform offers out of the box a whole range of different plugins that can be assembled in various combinations to create target solutions, i.e. CNFs of different flavours.
Moreover, developers can create completely custom plugins because Ligato is an open and extensible framework. It also comes with plugin lifecycle management, i.e. the initialization and graceful shutdown of plugins is standardized and handled appropriately. The initial configuration of each plugin is defined in the relevant configuration file.
Each CNF that we build using the Ligato platform is supposed to offer a number of network functions. The maximum set of these functions is determined by what Vector Packet Processor (VPP) capabilities in that area are since this is the main dataplane considered in Ligato. VPP is an open-source, packet-processing stack that can run as a standard Linux user-space process. It is a high-performance solution and it offers a rich network feature set. Additionally, if there is such a need, you can also use native Linux network functionality. To manage and control network functions offered by VPP and Linux altogether, VPP plugins and Linux plugins have been implemented within Ligato.
What is also very important, CNFs developed in the Ligato framework are adapted to interact with other microservices in the cloud e.g. with external services that use various remote procedure call (RPC) clients, with key-value (KV) data stores, with log warehouses, and so on. Ligato-based CNFs also offer high-level observability as they can generate an extensive set of telemetry data and various types of statistics that can be retrieved by monitoring system such as Prometheus. All this is possible thanks to the use of appropriate plugins provided by the Ligato platform. Such CNFs can also be easily and quickly started up by a container-orchestration system such as Kubernetes.
Combining the functionalities provided by individual plugins into a larger whole allows you to create the so-called software agents that manage and control underlying network functions. Ligato comes with a standard implementation of such an agent called vpp-agent. It is a production-ready solution that comprehensively controls VPP dataplane thanks to a wide range of plugins used and thus offers a rich suite of network functions. It has been used in Contiv-VPP and Network Service Mesh (NSM) projects.
An overview of Ligato plugins
The VPP plugins group contains the following plugins: Interface, L2, L3, ACL, ABF, IPFIX, IPSec, NAT, Punt, Segment Routing, STN, Telemetry, and Wireguard. To give you a rough idea of what exact configuration parts example plugins are responsible for, we’ll have a look at a few below:
- Interface—allows you to create and manage various types of interfaces available on VPP (the protobuf definition corresponding to this plugin contains different interface types, e.g. SOFTWARE_LOOPBACK, TAP, MEMIF, AF_PACKET, VXLAN_TUNNEL and many more). When creating an interface of a given type, you can configure its basic parameters, such as MAC address, IP address, etc., as well as interface-specific parameters.
- L2—deals with the mechanisms related to the Layer 2 of the underlying VPP dataplane. L2 plugin makes it possible to create bridge domains (containing interfaces that belong to the same flooding or broadcast domain), add static entries to L2 forwarding tables or configure xconnects (which switch packets from a given interface to another in one direction).
- L3—This multifunctional plugin allows you to configure ARP entries, ARP proxy, L3 routes and cross connects, IP neighbor scanning, VRFs, and VRRP
- NAT—supports configuration of NAT44, including more advanced options such as static mappings and load balancing for DNAT mode
- ACL and ABF—allow you to create new access-lists (ACL plugin) and use them as a traffic classification mechanism in the forwarding process, instead of standard IP prefixes. This approach is called ACL-based forwarding (ABF plugin)
- Finally, Telemetry is quite a specific plugin compared to the others in this group because it is not responsible for the configuration of the VPP dataplane in any aspect. Instead, it exports telemetry statistics from VPP to Prometheus.
The Linux plugins are the following:
- Linux Interface—It manages Linux-based VETH and TAP interfaces.
- Namespace—It handles Linux network namespace configuration.
- L3—This plugin supports the configuration of Linux ARP entries and Linux L3 routes.
- IP Table—It manages the Linux iptables utility.
It isn’t only plugins related to dataplane management and control that Ligato offers. The functionality offered by the other plugins is quite diverse and concerns other functional aspects of the Ligato platform. The most representative non-VPP/Linux plugins are classified and introduced below.
-
Connection plugins:
- gRPC allows external applications and clients to communicate using the gRPC API when interacting with other Ligato components.
- REST provides a general purpose HTTP server that can be used by plugins to expose a REST API to external clients and applications
-
Database plugins:
- etcd communicates with an external etcd KV data store.
- Consul acts as a KV data store adapter for Consul.
-
Infra plugins:
- Status Check collects and aggregates the status information of other plugins. This information can then be reported to external clients.
- Log Manager allows you to configure the log levels for individual plugins. The different log level choices such as DEBUG, INFO, ERROR and the like are available.
- Process Manager allows you to create processes through which you can manage and monitor other plugins.
- Kafka is an adapter to Kafka message bus
How to start
You can get started with the Ligato platform by following the quickstart guide . It contains information on how to run the vpp-agent instance as a docker container locally (e.g. on your laptop). It also shows different methods on how the vpp-agent can be configured, i.e. using the agentctl utility, through the REST API and with an external etcd instance. If you are a developer, going through a series of tutorials to help you understand how the Ligato framework works is worth your time. In addition, the official documentation is recommended for anyone wishing to deepen their knowledge of this solution. It is really extensive and covers a lot of issues such as an overview of plugins, configuration files, available APIs, etc.
Summary
Providing network functionality in the form of CNFs is in line with today's way of building a range of modern applications. The Ligato framework is a mature solution that allows you to design CNFs that not only offer the required network functionality, but are also able to interact with other microservices deployed in a given cloud environment.
