Many of the following entries refer to this example data model, which models a list of "servers":
Example 154. The servers YANG model
module servers {
namespace "http://www.example.com/ns/servers";
prefix srv;
import ietf-inet-types {
prefix inet;
}
import dataTypes {
prefix dt;
}
container servers {
list server {
key "ip port";
max-elements 64;
leaf ip {
type inet:ip-address;
}
leaf port {
type inet:port-number;
}
leaf counters {
type dt:countersType;
mandatory true;
config false;
}
}
}
}AAA stands for authentication, authorization and accounting.
ConfD requires the data model defined by the namespace
http://tail-f.com/ns/aaa/VERSION to
be loaded. Currently valid values for
VERSION are 1.0 and 1.1. The data found
there is used to authenticate users and authorize access for
users. We usually refer to this namespace as the AAA
namespace.
Accounting refers to the tracking of the consumption of network resources by users. This information may be used for management, planning, billing, or other purposes. Typical information that is gathered in accounting is the identity of the user, the nature of the service delivered, when the service began, and when it ended.
See Also AAA.
See Management Agent.
When compiling a YANG module, it can be annotated with callpoints, actionpoints and validation elements from a separate annotation file. This is useful for example when implementing a standard YANG module, without modifying the original file.
Authentication refers to the confirmation that a user who is requesting services is a valid user of the network services requested. Authentication is accomplished via the presentation of an identity and credentials. Examples of types of credentials are passwords and digital certificates.
See Also AAA.
Authorization refers to the granting of specific types of service (including "no service") to a user, based on authentication, what services they are requesting, and the current system state. Authorization may be based on restrictions, for example time-of-day restrictions, or physical location restrictions, or restrictions against multiple logins by the same user. Authorization determines the nature of the service which is granted to a user.
In ConfD all actions are authorized by reading the
authorization data found in the AAA namespace http://tail-f.com/ns/aaa/version.
See Also AAA.
See Management Backplane.
The candidate datastore (or just candidate) is one of the three configuration datastores in ConfD. It holds changes to the configuration before they are committed to the running datastore.
CDB is the built-in configuration database provided by ConfD. It is possible to use an external database to store the configuration, or to use CDB, as well as a combination of both.
This is the C API towards CDB. It contains functions to read configuration data, read and write operational data, and subscribe to changes in configuration data.
A program which uses the CDB C API needs to establish CDB
sessions to read configuration data, or read/write
operational data. These are short-lived
sessions that are established through a call to
cdb_start_session().
The entire configuration part of CDB is locked for writing while any CDB read session is active.
An upgrade is the operation of adapting an existing configuration to a newer version of the configuration schemas.
Confspec is a Tail-f proprietary data modelling language. YANG is a better standards based technology to achieve the same thing. Confspecs are no longer supported.
A configuration is an instantiated data model. The data model defines the layout of the configuration. An example of a configuration which adheres to the data model in Example 154, “The servers YANG model” is:
<servers>
<server>
<name>www</name>
<ip>192.168.128.1</ip>
<port>80</port>
</server>
<server>
<name>pop</name>
<ip>0.0.0.0</ip>
<port>110</port>
</server>
</servers>The data model also defines "non-configuration" data, also known as statistical or operational data. This data is not part of the configuration.
A daemon is a UNIX process that runs in the background. In the ConfD documentation we refer to the "ConfD daemon" meaning the "confd" process. We also refer to external database processes as daemons. Typically in a deployment scenario, the programs implementing the external database callbacks will run as daemons.
Southbound of ConfD we may have several data providers. These can either be daemons implementing the ConfD "data callbacks" or the ConfD database CDB.
A data provider has the following responsibilities:
Read and return data when ConfD requests data to be read
Write data into its store when ConfD requests it to write data
Obey the two-phase commit protocol used by ConfD when writing data
See Data provider.
When a data model is compiled, it can be exported to selected northbound interfaces, instead of being visible to all.
We may choose to store all configuration data in an external database, or in plain configuration files. From ConfD's point of view, we then have the configuration in an external database and no data is kept in CDB. There can be multiple external databases simultaneously connected to ConfD. It is also possible to use a combination of CDB and external database(s).
The C or Java code which implements an "external database" must adhere strictly to the ConfD transaction protocol. This is done by implementing a specific set of callback C functions. This could be viewed as the equivalent of implementing instrumentation functions in an SNMP agent.
An XML file (with suffix .xml) used for initializing the part of the configuration which is stored in the CDB database.
This is the task of implementing data callback functions for an external database.
A keypath is a string that uniquely identifies a node in a Configuration. A keypath is an (older) alternative syntax for a YANG instance-identifier.
The following are examples of keypaths
/servers/server{www}/portwhich uniquely identifies the data element:
<port>80</port> in the first
server in Configuration.
/serverswhich identifies the top level
servers container element.
A keypath is a path down the XML tree. Which path to
choose down the tree, i.e. which list entry to choose, must be
indicated with a {key} notation.
The keypath /servers/server{www}/port is
equivalent to the instance-identifier
/servers/server[name="www"]/port.
We also have a different notation which is used in
the CDB C API to identify data elements. The CDB C API
contains a function
cdb_num_instances() which returns an
integer. In Configuration we
had two different servers, thus
cdb_num_instances() would return 2 and
the keypath /servers/server[1]/port would
uniquely identify the port element in the second
server element. A keypath that uses the
[index] notation in the path is only
valid for the current CDB session.
In the C callback APIs, keypaths in the form of hashed keypaths are represented by the C type confd_hkeypath_t.
A Management Agent, or simply Agent, is a software entity which terminates some management protocol and provides a view of the managed system. The Agents in ConfD are NETCONF, SNMP, CLI, and Web UI, and proprietary agents that utilize the MAAPI API.
This is the layer of software inside ConfD which sits between the northbound agent interfaces and the southbound data providers. The main task of the management backplane is to multiplex and format data between the northbound and the southbound interfaces through transactions.
MAAPI - The Management Agent API - is an API which is used to connect to the ConfD transaction system. ConfD provides MAAPI bindings for C and Java. MAAPI is a northbound interface API which can be used to perform all read and write operations towards ConfD. It is possible to implement any proprietary configuration Agent with MAAPI.
MAAPI is also used to implement CLI wizards and semantic validation of configuration data in C.
Path filters restrict the set of valid elements to a subtree. The value of an element with the type confd:objectRef is a pointer to another element, and the set of elements to which the value is allowed to point can be restricted by specifying a list of path filters, in XPath syntax.
Likewise, the CLI show command can be restricted by a path filter (as a space-separated list of path items).
The running datastore is one of the three configuration datastores in ConfD. It contains the currently active configuration.
A schema defines the structure of data. A schema in ConfD is represented by YANG modules, compiled to a schema file having the file name suffix ".fxs".
See CDB session or User session.
The startup datastore is one of the three configuration datastores in ConfD. It contains a configuration to be read by the device each time it reboots.
Programs communicating with ConfD using one of the APIs can ask to be notified of certain events, by setting up a subscription. Subscription functionality is available in the CDB C API for notification of CDB configuration changes and for the asynchronous events described in the "Notifications" chapter.
A tagpath is a string and it is similar to a keypath with the exception that there are no keys in a tagpath. For example the string /servers/server/mask is a tagpath whereas the string /servers/server{www}/mask is a keypath.
The keypath above uniquely identifies a single instance of a particular mask in a particular server, namely the server named "www", whereas the tagpath above identifies all masks in all servers in the configuration.
By target device, or just "device", we mean the entire embedded box that is being built, such as the physical router if it is a router that is being configured by ConfD.
ConfD implements all writes towards all three possible configuration stores, startup, running and the candidate as two-phase commit transaction.
A configuration may be stored in several databases. We can have some part of the configuration in CDB and other parts in several external databases. A commit operation may span over several databases and we always want to ensure that all participants, i.e., all involved databases are ready to commit. Thus the C API to implement an external database always requires the external database to implement several callback C functions which will be called during the different phases of the transaction.
A transaction is always associated with a corresponding user session.
A transformation is used when we have a data model which we do not want to expose through the northbound Agent interfaces. We hide the undesired data model, and expose another model which then must transform data to and from the hidden model.
A user session corresponds directly to an SSH/SSL session from a management station to ConfD. A user session is associated with such data as the IP address of the management station and the user name of the user who logged in to ConfD, whether through NETCONF, the CLI or the Web UI.
Validation is the process of ensuring the correctness of the input configuration data. Syntactic validation is the first phase and it ensures type correctness and all checks that are possible to express in the YANG model. Semantic validation is the second phase and it requires application specific knowledge. The programmer has to write C or Java code which performs the semantic validation.
XPath is a language for selecting parts of an XML document. ConfD uses XPath (version 1.0) in its full form in NETCONF requests, as well as a very restricted subset to specify path filters in elements of the confd:objectRef type.