CONFD INTEGRATION with QUAGGA Table of Contents

CONFD INTEGRATION WITH QUAGGA Table of Contents

1. Introduction...... 3

2. Background...... 3

3. Architecture...... 4

4. YANG Data Model...... 5

5. Subscribers...... 6

6. Data Providers...... 6

7. Validators...... 7

8. Alternative Implementation Approaches...... 7

9. Limitations...... 8

10. Additional Management Interfaces...... 8

11. Conclusion...... 9

2 ConfD Integration with Quagga

1. Introduction

This application note describes an approach of how to integrate ConfD with a networking (routing) application using subscribers for configuration and data providers for operational values. For this application note, the Quagga open source routing suite has been chosen. The description is based on an existing Quagga-ConfD Application Demo, which is available to ConfD Premium customers upon request from their Tail-f Solutions Architect. Additionally, a video of a demonstration of this integration in action is available on the Tail-f website.

2. Background

ConfD is a data model driven embedded management software framework that enables network element providers (NEPs) to quickly and inexpensively deliver world-class management functionality for their products. The network elements can be physical devices or virtual devices (VNFs, virtual routers, etc.). ConfD is data model-driven and provides automatic rendering of all northbound interfaces including NETCONF, RESTCONF, CLI, JSON-RPC, and SNMP as well as C, Python, JAVA, and Erlang APIs for application development and integration.

Quagga Quagga is an open source routing software suite, providing implementations of OSPFv2, OSPFv3, RIP v1 and v2, RIPng, and BGP-4 for Unix platforms, particularly FreeBSD, Linux, Solaris and NetBSD.

The Quagga architecture consists of a core daemon called “zebra”, which acts as an abstraction layer to the underlying UNIX kernel and presents the Zserv API over a UNIX or TCP stream to Quagga clients. It is these Zserv clients which typically implement a routing protocol and communicate routing updates to the zebra daemon.

A system with Quagga installed acts as a dedicated router. With Quagga, your system exchanges routing information with other routers using routing protocols.

Quagga-ConfD Application This application links ConfD and Quagga daemons. It communicates with ConfD using the standard C API and with Quagga via a telnet CLI connection.

When configuration changes in the ConfD database (CDB) are detected by the ConfD subscriber, these changes are analyzed and corresponding Quagga CLI commands are created and sent to the Quagga daemons. In this way, the Quagga daemons are configured.

3 ConfD Integration with Quagga

When operational data is requested by ConfD (e.g. to be displayed), the ConfD data provider application connects to the Quagga CLI, performs a Quagga CLI show command, and parses the output to return the corresponding YANG data model values. The data is returned to ConfD and displayed as is or formatted using CLISPEC show templates (a ConfD feature).

For even more detailed description see Quagga Demo README file which is delivered with the demo.

3. Architecture

4 ConfD Integration with Quagga

• ConfD

−− Northbound interfaces (auto generated from the YANG data model)

−− ConfD Core engine

−− ConfD CDB (configuration database)

• Quagga-ConfD Application

−− Subscribers - Quagga configuration

−− Data providers - read operational data from Quagga

−− Validators - validate configuration before sending it to Quagga

−− Communication with ConfD is done via the standard C API

−− Communication with Quagga is done over a telnet connection to the Quagga CLI (one CLI telnet session for each Quagga routing daemon)

• Quagga

−− Quagga core (zebra daemon)

−− Quagga routing daemons (ospfd, ripd, bgpd, etc)

• Linux kernel

4. YANG Data Model

The Quagga-ConfD Application YANG data models are designed in a way to contain:

• Configuration values of the Quagga daemons

• Operational data values provided by the Quagga daemons

• Validation and constraint statements based on the Quagga semantics (must, when)

• Tail-f annotations to prettify the commands, hide or change the order of the commands, namings, etc. Some of the annotations help the developer to make a CLI that has a Cisco or a Juniper flavor.

5 ConfD Integration with Quagga

The Quagga-ConfD Application communicates with Quagga daemons through the Quagga CLI via telnet. When designing the YANG data models, this was taken into consideration so that the transformation of the YANG data model values to and from Quagga CLI strings are easier to implement. Since the application processes configuration changes and operational data requests itself (i.e. constructs Quagga CLI configuration strings and parses Quagga CLI output strings), it is not necessary for the YANG data model to strictly follow the Quagga CLI structure. Also, see the section “Alternative Implementation Approaches”.

5. Subscribers

A CDB subscriber function is called when there is a configuration change. The CDB subscriber function processes processes configuration changes for its registered subscription points.

• The subscriber starts a CDB read session

• For each subscription point, it invokes a function which iterates CDB changes (for given subscription point)

• The iterating function processes the subscription in such a way that changes in the CDB are transformed into corresponding Quagga CLI command strings

• Quagga CLI command strings are sent to the Quagga CLI engine and performed in the running Quagga as if an operator entered the commands to the CLI

6. Data Providers

Data provider callback functions are invoked when operational data is requested by ConfD (e.g. to be displayed in the ConfD CLI via a “show” command).

The operational data provider:

• Fills in internal data cache with operational values during an initial operational data request

−− Clears the internal data cache if not empty

−− Invokes Quagga CLI show command commands to get output text

−− Parses the output text and picks the required values

−− Stores value data into cache

6 ConfD Integration with Quagga

• Searches for the requested values (according to the YANG data model) in the cache and returns them to ConfD

• If the last value was returned for the request, the internal data cache is cleared

7. Validators

ConfD provides several levels of protection against misconfiguration which you can leverage in your product. The validation can be done in the YANG data model or by using code called a validation callback. An advantage of declaring validation constraints in the YANG data model via statements such as “must” is that ConfD will automatically enforce the validation constraints without the need to write any code. In the Quagga- ConfD Application, several validation callbacks have been implemented for those cases where the YANG validation was not enough or it was not an option.

The YANG data model constraints and the validation callbacks are executed prior the prepare and commit phases of the transaction and can prevent the configuration from being committed if the validation conditions are not fulfilled. A validation callback can also give a warning, allowing the operator to decide to still commit the command sequence. It is not possible to issue a validation warning via YANG data model constraints.

8. Alternative Implementation Approaches

As described previously, the Quagga-ConfD Application uses the Quagga CLI to configure the Quagga daemons and to read operational data from the Quagga daemons. For demonstration purposes, this approach is sufficient.

Another approach would be to use another Quagga API (e.g. C API) to configure the Quagga daemons and to read operational data from the Quagga daemons.

The configuration changes are processed by the Quagga-ConfD application and corresponding Quagga CLI commands are assembled. If the YANG data models were designed to follow the exact structure of the Quagga CLI, the implementation can be simplified in a way that the configuration changes are directly sent to the Quagga CLI as ConfD CLI change strings which are available from ConfD while processing subscriptions via cdb_get_modifications_cli(). In this case, the Quagga CLI configuration strings would be created directly by ConfD and not by the Quagga-ConfD application.

7 ConfD Integration with Quagga

9. Limitations

Only a subset of the routing protocols are implemented; OSPF and RIP. The integration can be extended to include all existing Quagga routing protocols for both ipv4 and ipv6.

There are 3 show commands implemented for displaying information about the routing protocols and the routing table, but many more can be made using the same steps.

One specific limitation is that the solution is not transactional because Quagga doesn’t support transactionality.

10. Additional Management Interfaces

NETCONF NETCONF is an IETF standard, XML-based protocol used for configuration and monitoring of the elements in the network. It provides mechanisms to install, manipulate, and delete the configuration of the network elements. One of the advantages of doing this integration is that it also provides a NETCONF interface for the Quagga daemon, making an old routing stack up to date to handle the new demanding challenges that the networking/telecom world faces (automation, SDN, programmability, etc.).

WebUI The WebUI is another management interface that allows you to change the configuration of the device and see the operational data. The Quagga-ConfD Application uses ConfD’s JSON-RPC Web API to implement a WebUI which is automatically generated from the YANG data model. This is the same YANG data model that is used to define the CLI command structure and the NETCONF interface. Below is a screenshot of a WebUI session. To see the WebUI in action watch the Quagga-ConfD integration demonstration video.

8 ConfD Integration with Quagga

11. Conclusion

This application note has discussed an architectural approach to integrating ConfD with a third party software package. Integration with Quagga was shown, but the techniques discussed can be applied to other third party software packages. A couple advantages of using ConfD is to provide one common set of northbound management interfaces across multiple proprietary and third party applications and to also provide additional management interfaces which may not be included in the individual third party applications.

For more information about ConfD, visit http://www.tail-f.com

For more information about NETCONF, visit https://tools.ietf.org/html/rfc6241

For more information about YANG, visit https://tools.ietf.org/html/rfc7950

For more information about Quagga, visit http://www.nongnu.org/quagga/

To view the Quagga integration demonstration video, visit http://www.tail-f.com

9 www.tail-f.com [email protected]

Corporate Headquarters Sveavagen 25 111 34 Stockholm Sweden +46 8 21 37 40