Welcome back to our guide on Vector Packet Processing. In today’s post number three from our VPP series, we will take a look at Ligato and its VPP Agent.
Since the original version of this article, the Ligato project has consolidated. The VPP Agent and CN-Infra remain the two actively maintained foundational repositories (the latest stable VPP Agent is v3.5.0, and the
vpp-baseimage was last refreshed in late 2025), while several earlier sub-projects (notably the SFC Controller) have been deprecated. The quickstart and component list below have been updated accordingly.
Ligato is one of the multiple commercially supported technologies supported by PANTHEON.tech.
What is a VNF (or CNF)?
A Virtual Network Function is a software implementation of a function. It runs on single or multiple Virtual Machines or Containers, on top of a hardware networking infrastructure. Individual functions of this network may be implemented or combined together, in order to create a complete networking communication service. A VNF can be used as a standalone entity or part of an SDN architecture.
Its life-cycle is controlled by orchestration systems, such as Kubernetes. Cloud-native VNFs – often referred to today as Cloud-Native Network Functions (CNFs) – and their control/management plane can expose REST or gRPC APIs to external clients, communicate over a message bus, or provide a cloud-friendly environment for deployment and usage. They can also support high-performance data planes, such as VPP.
What is Ligato?
It is the open-source Go framework for building and wiring CNFs. Ligato provides infrastructure and libraries, code samples, and CI/CD processes to accelerate and improve the overall developer experience. It paves the way towards faster code reuse, reducing costs, and increasing application agility & maintainability. Being native to the cloud, Ligato has a minimal footprint, plus can be easily integrated, customized, and extended, deployed using Kubernetes.
The two foundational frameworks that together form Ligato are:
- CN-Infra – a Golang platform for developing cloud-native microservices. It can be used to develop any microservice, even though it was primarily designed for VNF management/control plane agents. It provides plugin lifecycle, dependency injection, KV-store connectors, REST and gRPC plumbing.
- VPP Agent – a set of VPP-specific plugins, built on top of CN-Infra, that exposes VPP functionality to client apps via a higher-level, model-driven API.
The Ligato organization on GitHub also maintains the supporting tools vpp-base (Docker images with VPP ready to run) and vpp-probe (a tool to examine VPP instances running anywhere).
The original 2019 version of this article also listed SFC Controller and BGP Agent as core components. Both have since been retired – the SFC Controller repository is officially deprecated, and the BGP Agent has been dormant for years. The functionality they prototyped is now generally addressed at the orchestration layer (e.g. Kubernetes + CNI, FRRouting alongside VPP) rather than inside Ligato itself.
The platform is modular – new plugins provide new functionality. These plugins can be set up in layers, where each layer can form a new platform with different services at a higher layer plane. This approach mainly aims to create a management/control plane for VPP, with the addition of the VPP Agent. (A short Ligato demonstration recorded by PANTHEON.tech is available here.)
What is the VPP Agent?
The VPP Agent is a set of VPP-specific plugins that use the CN-Infra framework to interact with other services/microservices in the cloud (e.g. a KV data store, messaging, log warehouse, etc.). It provides VPP functionality to client apps through a higher-level, model-driven API. Clients consuming this API can be either external (connecting via REST, gRPC, etcd or a message bus) or local apps and extension plugins running on the same CN-Infra framework in the same Linux process.
Each (northbound) VPP API – L2, L3, ACL, NAT, IPSec, … – is implemented by a specific VPP Agent plugin, which translates northbound calls into (southbound) low-level VPP Binary API calls. Northbound APIs are defined using Protocol Buffers, which allow the same functionality to be exposed over multiple transports (HTTP, gRPC, etcd, …). Plugins use the GoVPP library to talk to VPP itself.
Quick starting the VPP Agent
1. Pull the latest image from Docker Hub: ligato/vpp-agent (or ligato/vpp-agent-arm64 for ARM64), which bundles VPP + VPP Agent
Or clone the repository from the Ligato GitHub
2. Install ETCD (e.g. as a container) – this is the only external dependency for the basic quickstart. Note: Kafka is no longer required to run the VPP Agent from the image.
For this example, we will work with the pre-built Docker image.
Install & Run
1. Run the downloaded Docker image (note the --privileged flag, required for VPP to access network resources):
docker pull ligato/vpp-agent
docker run -it --rm --name agent1 --privileged ligato/vpp-agent
2. Manage the VPP Agent using agentctl:
docker exec -it agent1 agentctl --help
docker exec -it agent1 agentctl status
3. Check the configuration, using agentctl or the VPP console:
docker exec -it agent1 agentctl dump all
docker exec -it agent1 vppctl show interface
For a detailed rundown of the Quickstart, please refer to the Quickstart section in the VPP Agent README and the comprehensive documentation at docs.ligato.io.
We have shown you how to integrate and quickstart the VPP Agent, on top of Ligato.
Next up, we will introduce gRPC & REST, in the context of VPP.
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub. Follow us on LinkedIn.
Watch our YouTube Channel.
