Building Framework

Overview

Ligato is an open source Go framework for building and developing solutions for managing and controlling CNFs. Reusable software components, protobuf-modelled APIs, dependency injection, and logging/REST/CLI visibility are provided. Documentation, tutorials and examples are supplied to facilitate development.

A set of VPP and Linux plugins, including a transaction-based configuration scheduler, are implemented in the VPP agent, enabling agile and resilient deployments. Infrastructure plugins offer K8s lifecycle management, health care checking, notifications, data store/database integration, and logging for cloud-native operational affinities.

Ligato is written in Golang for the performance, concurrency, scale, readability, and broad community support necessary for developing and implementing cloud-native network solutions.

Plugins

The VPP agent and cn-infra are the two constituent frameworks that, together, form the foundation of the Ligato framework. With Ligato, each management / control plane application utilizes one or modules called plugins. Each plugin supports a specific function or functions. Some plugins come with the cn-infra framework; Others come with the VPP agent; Yet others created by app developers can be applied to perform custom tasks.

Plugins can be assembled in any combination to build solutions ranging from simple configuration tasks, to larger more complex operations such as managing configuration state across multiple nodes in a network. The plugin definition is standardized in the Ligato framework, and startup plugin behavior is adjustable through the use of configuration files.

VPP Agent

The VPP agent provides configuration and monitoring services for the VPP data plane.

• Supplies VPP and Linux plugins
• VPP agent and VPP packaged up in single container
• Dependency handling between related configuration items
• Transaction-based configuration processing and tracking
• Failover synchronization mechanisms, also known as resync
• Stateless configuration management based on a KV data store “watch” paradigm
• Direct access via REST or gRPC
• Component health checks

VPP Agent Plugins

The VPP Agent includes VPP and Linux plugins for network configuration and visibility. CNFs and cloud-native network applications can be developed using VPP agent plugins to interact with other services/microservices in a cloud-native environment.

                            
vpp-agent/plugins/vpp
├── abfplugin // ACL-based forewarding
├── aclplugin // ACL
├── ifplugin // Interfaces
├── ipsecplugin // IPsec
├── ipfixplugin // IPFix
├── l2plugin // L2 including bridge domain, x-connect and FIB
├── l3plugin // routes, VRFs, arps, l3-xc
├── natplugin // NAT
├── puntplugin // Punt to Host
├── srplugin // segment routing
├── stnplugin // steal the nic

vpp-agent/plugins/linux

├── ifplugin // host interface
├── iptablesplugin // Linux IP tables
├── l3plugin // routing, arp
└── nsplugin // namespace

cn-infra Plugins

cn-infra supplies a variety of plugins including ones for logging, health checks, process management, messaging, KV data store connectivity, and REST/gRPC APIs. Developers can implement a mix of cn-infra plugins, together with VPP agent and/or custom plugins, to define CNF functionality.

cn-infra plugin types:

• Infra for logging, messaging, process management, status checking and service label
• Database for external data store connectivity and database integration
• RPC connections supporting gRPC/REST APIs

Models / Protobufs / Keys

Model abstractions, protobufs, key identifiers and KV data stores are fundamental concepts in Ligato. The application of models and protobuf definitions define northbound APIs for managing and controlling configuration objects in a CNF.

Models

The model represents an abstraction of an object that can be managed through northbound APIs exposed by the VPP agent. It consists of a model specification and a proto.Message.

Here is a snippet of model.Spec code for a VPP L3 route:

        
// ModuleName is the module name used for models.
const ModuleName = "vpp"
...
	ModelRoute = models.Register(&Route{}, models.Spec{
		Module:  ModuleName,
		Type:    "route",
		Version: "v2",
	}, models.WithNameTemplate(
		`{{if .OutgoingInterface}}{{printf "if/%s/" .OutgoingInterface}}{{end}}`+
			`vrf/{{.VrfId}}/`+
			`{{with ipnet .DstNetwork}}{{printf "dst/%s/%d/" .IP .MaskSize}}`+
			`{{else}}{{printf "dst/%s/" .DstNetwork}}{{end}}`+
			`{{if .NextHopAddr}}gw/{{.NextHopAddr}}{{end}}`,
	))
...
        
    

Proto

Protobufs is a method for defining the structure and serialized format of data associated with an object. Ligato implements a .proto definition for each configuration object.

Here is a snippet of the .proto file for a VPP L3 route:

        
syntax = "proto3";
package ligato.vpp.l3;
option go_package = “go.ligato.io/vpp-agent/v3/proto/ligato/vpp/l3;vpp_l3”;
message Route {
enum RouteType {
// Forwarding is being done in the specified vrf_id only, or according to
// the specified outgoing interface.
INTRA_VRF = 0;
// Forwarding is being done by lookup into a different VRF,
…
INTER_VRF = 1;
// Drops the network communication designated for specific IP address.
DROP = 2;
}
RouteType type = 10;
// VRF identifier, field required for remote client. This value should be
// consistent with VRF ID in static route key. 
...
uint32 vrf_id = 1;
// Destination network defined by IP address and prefix.
string dst_network = 3;
// Next hop address.
string next_hop_addr = 4;
// Interface name of the outgoing interface.
string outgoing_interface = 5;
// Weight is used for unequal cost load balancing.
uint32 weight = 6;
// Preference defines path preference. Lower preference is preferred.
uint32 preference = 7;
// Specifies VRF ID for the next hop lookup / recursive lookup
uint32 via_vrf_id = 8;
}

Keys

Keys are used to identify objects controlled and managed by Ligato-built CNFs.

The VPP L3 route key is:

/vnf-agent/vpp1/config/vpp/v2/route/vrf/<vrf_id>/dst/<dst_network>/gw/<next_hop_addr>

This key is used to PUT L3 route values into a KV data store:

agentctl kvdb put /vnf-agent/vpp1/config/vpp/v2/route/vrf/0/dst/10.1.1.3/32/gw/192.168.1.13 
{  
    "type": "INTRA_VRF",
    "dst_network":"10.1.1.3/32",
    "next_hop_addr":"192.168.1.13",
    "outgoing_interface":"tap1",
    "weight":6
}

KV Data Store

• Used by the VPP agent to store VPP/Linux configuration and stats
• Watches and reacts to events created by changes within the datastore
• Uses a watched key value and microservice label to distinguish its own config from that of another VPP
• Microservice label enables a single data store to service multiple VPP agents

KV Scheduler

The runtime configuration of a CNF must accurately reflect the desired network function. One configuration item could be dependent on the successful configuration of another item. Example: a route cannot be configured without an interface, therefore we say the interface is a dependency configuration item of the route. And these dependencies must be tracked and coordinated to ensure the proper configuration sequence.

The KV Scheduler is a plugin that works with VPP and Linux plugins on the SB side; It works with orchestrators, external data sources such as KV data stores, and RPC clients on the NB side. In a nutshell, it keeps track of the correct configuration order and associated dependencies.

Agentctl

Agenctl is a CLI command line tool for managing and interacting with the software components of the Ligato framework. The CLI enables the developer or operator to check status, manage VPP configurations, view models, dump KV data store and KV Scheduler contents and print transaction logs.

REST API

Ligato offers a comprehensive suite of REST APIs for managing VPP agent network configurations including those interfaces, L2, L3, IPsec and NAT. In addition, there are REST APIs available to retrieve information such as transaction logs and runtime dumps from the KV Scheduler.