Ligato

VPP Agent

The VPP Agent is a Go implementation of a control/management plane for VPP based cloud-native Virtual Network Functions (VNFs). The VPP Agent is built on top of CN Infra, a framework for developing cloud-native VNFs (CNFs).

The VPP Agent can be used as-is as a management/control agent for VNFs based on off-the-shelf VPP (e.g. a VPP-based vswitch), or as a framework for developing management agents for VPP-based CNFs. An example of a custom VPP-based CNF is the Contiv-VPP vswitch.

Please note that the content of this repository is currently WORK IN PROGRESS!

Status

Releases

Release Release Date Info

latest release

Have a look at the release notes for a complete list of changes.

Branches

Branch Info Last Commit

has switched to v3 ⚠️

has been DEPRECATED

provides legacy v2

All development is done against master branch.

Images

Image Image Size/Layers

Info

with minimal footprint

prepared for developers

Quickstart

For a quick start with the VPP Agent, you can use the pre-built Docker images on DockerHub that contain the VPP Agent and VPP: ligato/vpp-agent (or for ARM64: ligato/vpp-agent-arm64).

1. Start ETCD on your host (e.g. in Docker as described here).

   Note: for ARM64 see the information for etcd.

2. Run VPP + VPP Agent in a Docker container:

docker run -it --rm --name agent1 --privileged ligato/vpp-agent

1. Manage VPP agent using agentctl:

docker exec -it agent1 agentctl --help
docker exec -it agent1 agentctl status

1. Check the configuration (via agentctl or in VPP console):

docker exec -it agent1 agentctl dump all
docker exec -it agent1 vppctl show interface

Next Steps

See README of development docker image for more details.

Documentation

Extensive documentation for the VPP Agent can be found at docs.ligato.io.

Architecture

The VPP Agent is basically 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.). The VPP Agent exposes VPP functionality to client apps via a higher-level model-driven API. Clients that consume this API may be either external (connecting to the VPP Agent via REST, gRPC API, Etcd or message bus transport), or local Apps and/or Extension plugins running on the same CN-Infra framework in the same Linux process.

The VNF Agent architecture is shown in the following figure:

Each (northbound) VPP API - L2, L3, ACL, ... - is implemented by a specific VNF Agent plugin, which translates northbound API calls/operations into (southbound) low level VPP Binary API calls. Northbound APIs are defined using protobufs, which allow for the same functionality to be accessible over multiple transport protocols (HTTP, gRPC, Etcd, ...). Plugins use the GoVPP library to interact with the VPP.

The following figure shows the VPP Agent in context of a cloud-native VNF, where the VNF's data plane is implemented using VPP/DPDK and its management/control planes are implemented using the VNF agent:

Contributing

If you are interested in contributing, please see the contribution guidelines.

License

Modified 3rd party tools included

• protoc-gen-jsonschema (code location in this repository)