netconfd-pro

Multi-Protocol Network Management Server Toolkit

Overview

The YumaPro Server tool-kit provides developers with a powerful framework for rapidly creating protocol-independent management interfaces for any kind of device that has configuration parameters to set, operational data to monitor, and/or notifications to send.

Easy to use tools, including 100% source code!

The YumaPro Server source code is written entirely in POSIX compliant C. It is well-documented and easy to customize and integrate into embedded systems. The source license includes all server source code used at run-time.

Simple Development Process!

Creating new management interfaces for your products is easy with YumaPro Server tools:

  • Start with a service or product component that needs to be managed, and decide what parameters, operational data, and notifications are needed.
  • Write a YANG module to represent the data model for this new feature.
  • Make sure the YANG module compiles correctly with the yangdump-pro YANG compiler.
  • Create all the C stub code for the server instrumentation library (SIL) with the make_sil_dir_pro script.
  • Fill in the SIL C functions that set configuration values, get operational data values, and/or generate notification events.
  • Run make to compile your SIL code and make install to install it.
  • That’s it! The module and the SIL code can be loaded into YumaPro Server at run-time with no service interruption with the special load operation!

 


Database Validation

Only the nodes that are modified get checked!

The database validation engine has been improved to provide much faster commit validation.

Step 1: YANG modules are analyzed

When the server loads a YANG module all the objects are analyzed to track changes to affected objects. All objects referenced by XPath expressions (YANG must/when/path statements) are automatically tracked. There are no YANG extensions or CLI parameters to configure.

Step 2: Object modified flags are maintained

The server keeps track of which objects have changed since the last commit
if the candidate is the target database, or the last edit-config if the running is the target database.

Step 3: Commit validation tests skip unmodified objects

Only validation tests that reference modified objects get invoked.
All other objects are quickly skipped, saving a lot of time and CPU.

Step 4: Optimized XPath evaluation for modified nodes

The XPath expression evaluation engine has been optimized to skip
over “false AND” expressions and “true OR” expressions, so XPath
evaluation can be much faster.

 


Concurrent Sessions

YumaPro sessions can be concurrent, using multiple CPU cores!

The YumaPro server can be built to use pthreads in order to support concurrent client sessions. Data replies can be streamed concurrently.

Without pthreads a server is completely serialized so a message has to be sent to the client and completely finish before the next message can be started. Slow links or other client issues could completely block all other sessions from running.

The new YumaPro server with pthreads allows each client session to be run independently so multiple messages can be processed concurrently without blocking.

 


Transaction Performance

 

YumaPro SDK Transactions Up To 700 Times Faster Than Open Source!

TestDescriptionYumaPro (entries per second)ConfdOpenYuma (entries per second)YumaPro X times faster than OpenYuma
1Edit 50,000 entries, target=running74,963???636118
2Config load 50,000 entries, target=running147,495???514287
3Create container with 50,000 rows, target=running134,338???658204
4Delete 50,000 rows with delete240,511???344699

??? – if companies prohibit you from measuring the performance of their products, it is because they already know they won’t compare well.

 

Runtime Edit Transaction Performance

 

Edit transaction performance is critical for provisioning applications. One of the most thorough tests possible is to create a lot of the same type of list entries, since that is how a typical provisioning application works.

Test 1 measures how many entries per second can be inserted by the server. The test uses a config edit that creates a container and then adds a /myModule top-level list entry followed by a commit 50,000 times.

All the tests have the server starting with its factory default configuration and using the –target=running server configuration parameters.

The YumaPro SDK server transaction engine has been completely rewritten so it is now much faster, even if the candidate database is used. Only the nodes affected by a commit or edit operation on the running configuration need to be processed during a transaction. Performance enhancements and new feature development bring continued performance improvements to the netconfd-pro server.

Boot-time Load Configuration Performance

 

Another critical measure of database performance is how long it takes to load and validate the running configuration from non-volatile storage. A device that takes a long time loading its configuration after a power outage can have a severe impact on network availability.

Test 2 measures how many entries a second the server can load and validate from a startup configuration file at boot-time that contains 50,000 /myModule list entries. A highly optimized algorithm is used to validate, apply, and commit the entire database with just one pass through the configuration. Sub-trees that do not need validation testing are pruned automatically.

Test 3 measures how many entries a second can be added after a container is created using 50,000 /myModule list entries and then a commit after all the entries have been added.

Test 4 measures how many entries a second can be deleted from the database using a config edit that deletes 50,000 rows one at a time.

YANG module used in the test

myModule

These tests demonstrate that the YumaPro Server significantly outperforms OpenYuma in terms of transaction performance, but YumaPro SDK provides many other advantages over Open Source tools as well. See the difference between Open Source and YumaPro SDK.

 


YP-HA

Full Active/Standby High Availability for YumaPro Servers

High availability is crucial for modern networks to meet their uptime goals. YumaPro SDK 16.10 includes the YP-HA Protocol to provide High Availability (HA) for netconfd-pro servers.

Any number of servers are configured into an HA server pool. The servers start in dormant mode and then an external process, usually a High Availability Controller, commands one of the pool’s servers to become the active server and the remainder to become standby servers.

The active server behaves as a normal netconfd-pro server but in addition replicates any configuration edits it receives to each of the HA pool’s standby servers to keep them continually up to date. If a configuration edit involves loading YANG modules the active server commands the standbys to load the same YANG modules. As the YANG modules can be loaded and unloaded by the servers without having to restart this further improves system availability. Servers in standby mode just receive configuration edits and do not act on them.

If the active server is taken out of service for maintenance or fails for some reason the external process commands one of the HA pools standby servers to become active. It then replicates configuration changes to the remaining standby servers in the pool. It is also responsible for system notifications and retrieving state data.

For more details please see the netconfd-pro user manual, Section 2.12 High Availability.

 


NETCONF

Fully Programmable Network Configuration

The YumaPro Server supports the complete NETCONF protocol. Any protocol operation, database object or notification message can be easily added to the server by providing a YANG data model defining the API. All mandatory and optional protocol features are supported, and fully configurable at boot-time.

High Performance Network-wide Commit and Rollback

The YumaPro Server includes a high performance transaction engine and internal database. All of the NETCONF features including XPath and Confirmed Commit are supported. An application can use the standard procedure (double commit) or use the YumaPro backup and restore operations to safely apply network-wide configuration changes.

NETCONF Capabilities Implemented in YumaPro Server
NameDescriptionRequirements
base:1.0RFC 4741 protocol versionnone
base:1.1RFC 6241 protocol versionnone
candidate:1.0Candidate database--target=candidate [default]
confirmed-commit:1.0Confirmed commit operations--target=candidate [default]
confirmed-commit:1.1Confirmed commit operations (base:1.1 version)--target=candidate [default]
writable-running:1.0Running database is the <edit-config> target --target=running
rollback-on-error:1.0Rollback on error for <edit-config>none
validate:1.0<validate> operation and ‘test-only’ <edit-config> test-option are supported;--with-validate=true [default]
validate:1.1<validate> operation and ‘test-only’ <edit-config> test-option are supported; (base:1.1 version) --with-validate=true [default]
startup:1.0Distinct startup database; <copy-config> to startup config needed to NV-save the running config--with-startup=true
url:1.0URL parameter support; The ‘file’ scheme is allowed in the <url> parameter to backup and restore named config files--with-url=true [default]
xpath:1.0Full XPath 1.0 + YANG extensions for <get> and <get-config> operationsnone
notification:1.0 NETCONF notifications; use <create-subscription> operation to start none
interleave:1.0Allow <rpc> requests while notifications are activenone
partial-lock:1.0<partial-lock> and <partial-unlock> operations--target=running
with-defaults:1.0<with-defaults> parameter for ‘report-all’, ‘trim’ and ‘explicit’ modes--default-style used to pick basic-mode [default=explicit]
YANG Modules Included with YumaPro Server
YANG Modules IncludedDescription
ietf-inet-typesStandard YANG networking data types from RFC 6021.
ietf-netconfStandard YANG data model for NETCONF protocol operations from RFC 6241.
ietf-netconf-acmStandard NETCONF Access Control Model (NACM) from RFC 6536.
ietf-netconf-monitoringStandard NETCONF monitoring data model and <get-schema> operation from RFC 6022 to retrieve YANG modules from the server.
ietf-netconf-notificationsStandard NETCONF Notification delivery with replay buffer and command interleave mode from RFC 5217.
ietf-netconf-partial-lockStandard NETCONF and operations from RFC 5717 to support concurrent non-overlapping database edits.
ietf-netconf-with-defaultsStandard NETCONF :with-defaults capability extensions to the <get> and <get-config> operations.
ietf-yang-typesStandard YANG data types from RFC 6021.
nc-notificationsNetconf Central YANG module for notification monitoring data model from RFC 5277.
notificationsNetconf Central YANG module for <create-subscription> operation from RFC 5277.
toasterExample SIL module.
yuma-arpNetconf Central YANG module for Linux ARP management.
yuma-interfacesNetconf Central YANG module for Linux interface monitoring.
yuma-mysessionNetconf Central YANG module for setting and retrieving session-specific session parameters.
yuma-nacmNetconf Central YANG module for NETCONF Access Control, used as the starting point for NACM in RFC 6536.
yuma-ncxNetconf Central YANG language extensions.
yuma-procNetconf Central YANG module for Linux /proc system information.
yuma-systemNetconf Central YANG module for NETCONF system management and notifications, which was used as the starting point for RFC 6470.
yuma-time-filterNetconf Central YANG module for time-stamp based filtered of configuration data.
yuma-typesNetconf Central YANG module for extended data types.
yumaworks-extensionsYumaWorks YANG language extensions.
yumaworks-idsYumaWorks YANG identities.
yumaworks-systemYumaWorks extensions for CM maintenance such as the backup, restore, and delete-backup operations.
yumaworks-typesYumaWorks YANG data type extensions.

 


YumaPro SDK Supports IETF RESTCONF

The YumaPro SDK includes RESTCONF as an additional interface.

RESTCONF is a REST like protocol running over an HTTP interface to access the YumaPro NETCONF server datastores. The RESTful interface provides a familiar model to a mature WEB development eco-system that includes:

  • large pool of experienced developers
  • many development tools
  • support by most integrated development environments (IDEs)
  • part of the standard CS educational curriculum
The REST resource model allows efficient management:
  • entity tags are fully supported for caching and multi-client edit protection
  • better encoding efficiency using JSON encoding, entity tags, and HEAD method
  • flexibility with JSON or XML encoding options
  • Server Notifications with standard W3C Server-Side Events
RESTCONF Operations

HTTP MethodNETCONF OperationMedia Type
POSTcreateapplication/yang.data
PUTreplaceapplication/yang.data
PATCHmergeapplication/yang.data
PATCHany edit operationapplication/yang.data
DELETEdeleteapplication/yang.data
POSTany <rpc> operationapplication/yang.operation
GET<get>, <get-config>application/yang.data
GET<create-subscription>text/event-stream
  • NETCONF: <config> subtree specifies data node targets
  • RESTCONF: request URI specifies target resource

For more details see: draft-ietf-netconf-restconf-13

 


CLI Access

yp-shell Adds Industry Standard CLI To YumaPro

The yp-shell program allows operators to login to the YumaPro Server and access the same YANG database objects as NETCONF or REST protocols. It is installed as the remote login shell for the user. Any SSH terminal program can be used to access the yp-shell program.

YANG driven interface

The commands available are automatically populated based on the YANG modules loaded into yp-shell. The command line syntax is derived from the YANG syntax. Access control is applied uniformly to NETCONF, CLI, and REST, simplifying security configuration.

Context Sensitive Editing

The command completion text and available help text is context-sensitive, based on the YANG definitions, the current command mode or sub-mode, and the cursor position in the command line.

Command Aliases

Aliases are user-created commands that can be used to customize the command set and reduce typing. Each user has their own set of aliases, which are saved for future sessions.

Configuration Mode

   yp-shell user@server> conf t
   yp-shell user@server(c)# interfaces int eth0
   yp-shell user@server(c interfaces interface eth0)# mtu 9000
   yp-shell user@server(c interfaces interface eth0)# exit

   Applying 1 edit

   yp-shell user@server(c)# exit
   yp-shell user@server>

Command Line History Features

Several familiar command line recall mechanisms are supported:

Command Recall
  • The history and recall commands are used to show recent command lines and recall a previously entered command line.
  • The control-P (previous line) and Control-N (next line) keystroke sequences can be used to scroll backwards or forwards through the history buffer.
  • The ! (bang character) can be used to recall commands by line number or by most recent match for the specified command string.
  • The command line history can be cleared, saved, or re-loaded from file.
  • Each user has their own command history that is saved across sessions and across server reboots.
The ‘?’ Help Key

The ‘?’ (question mark) key can be used to get context-sensitive help for the keyword(s) or value that is expected next within the current command line. The ‘tab’ key is used for short help text and the ‘?’ key is used for long help.

 


SIL Development

Server Instrumentation Library Development

Server Instrumentation Libraries (SILs) contain your code that hooks the YANG data models into the system, to perform the device and network changes associated with the configuration changes.

 

Step 1: Define a common YANG module

The operations and database contents are defined in a YANG data model module. The SIL code for this module will be protocol and encoding independent, providing REST, CLI, and NETCONF interfaces for the content defined in the YANG module.

address.yang

Step 2: Generate the SIL code stubs

To generate the source files for a YANG module named ‘address’, use the ‘make_sil_dir_pro’ script. This uses yangdump-pro to generate the individual C and H files.
make_sil_dir_pro –split address

 

The file y_address.c contains the glue code to hook the user callback code into the transaction engine. This file should never be edited.
The file u_address.c contains the user callback functions needed to hook the YANG defined configuration data to the underlying system. The code stubs in this file typically contain system-specific function calls to commit database changes.

  
Step 3: Decide which transaction phases need user callback functions.

 

  • Validate Phase: A user callback is only needed here if system validation or “description statement” validation is required. All machine-readable YANG statements related to validation are handled automatically by the transaction engine. The validate phase has to complete without error for all modified object instances. No system resources should be allocated or modified during this phase.
  • Apply Phase: A user callback is only needed here if system resource reservation is supported. The target database is modified by the transaction engine using fully recoverable edits, whether that is the candidate or running database. The user callback code may support recoverable resource reservation during this phase. After this callback is invoked, either the commit or rollback phases will follow, allowing the user callback code to commit or cleanup any system resources.
  • Commit or Rollback Phase: A user callback for the commit phase is needed to apply configuration changes to the system. Once the commit callback has been done for an object instance, no further callbacks will be done for the current transaction. Either the commit callback or the rollback will be invoked, but not both. The transaction engine will construct a new edit to undo configuration changes if a commit partially finishes and some completed edits need to be rolled back.
Step 4: Hook your system callbacks into the edit function.

example code

Check out the SIL Overview Slides.

 


netconfd-pro API Map

YumaPro netconfd-pro APIs:

(1) Utility APIs

  • Notification functions provide control over notifications.
  • XPATH Handling/Validation functions can be used to manipulate XPATH expressions.
  • Error Handling functions provide various alternative ways to record an error.
  • Transaction Management functions provide control on the transaction and can be invoked within, before, and after the transaction.
  • Timer Service functions allow some SIL code that may need to be called at periodic intervals to check system status, update counters, and/or send notifications.
  • YANG Object Tree manipulation functions let you retrieve object properties without accessing them directly.
  • Extension Access functions allow to manipulate with custom YANG extensions.
  • YANG Data Tree manipulation functions provide access functions to the data nodes.

(2) Server Instrumentation Library (SIL) Utility functions provide control on SIL libraries and allows them to be used more efficiently.

(3) YControl and DB-API Interface functions provide control on subsystem and DB-API interfaces.

(4) System Callback functions allow the creation and use of general system SIL libraries.

(5) Database Access functions allow validation, manipulation, and management of your database.

(6) Access Control functions allow configuration and and enforcement of a vendor specific access control model (ACM).

(7) SYSLOG and Log functions allow customized logging preferences.

 

Main Transaction Management APIs
APIDescription
EDIT-1 callbackagt_cb_fn_t: First generation callbacks are generated by yangdump-sdk using node-based APIs. An edit function is generated for every node, including terminal nodes (leaf, leaf-list, anyxml). The GET-1 API is assumed for read-only data, so code to generate virtual read-only nodes (Make Read Only MRO) is included in an EDIT-1 callback. This is the default in yangdump-sdk and make_sil_* scripts.
EDIT-2 callbackagt_cb_fn_t: Second generation callbacks are generated by yangdump-sdk using container or list-based APIs. An edit function is generated for “parent” list and container nodes only. The terminal child nodes are handled by this callback. Each nested container or list has its own EDIT-2 callback. This is generated in yangdump-sdk or make_sil_* scripts using the –sil-edit2 parameter. The same callback function signature as EDIT-1 is used, but the registration function and procedure is different.
GET-1 callbackgetcb_fn_t: Not used in an edit transaction but GET-1 virtual nodes for operational data are created by SIL code when the configuration node parent of the operational data is created.
GET-2 callbackgetcb_fn2_t: Not used in an edit transaction. GET-2 callbacks are independent of EDIT-1 or EDIT-2 callbacks. Not virtual read-only nodes are used if operational data uses GET-2 callbacks.
Candidate Reload callbackcfg_reload_candidate_cb_t: There can be one callback registered to be invoked each time the candidate datastore is reloaded from the running datastore, such as the <discard-changes> operation.
Module Load callbackncx_load_cbfn_t: There can be multiple callbacks registered to be invoked when a module is loaded into the server. A transaction to set module defaults will also be generated, in addition to this callback.
Module Unload callbackncx_load_cbfn_t: There can be multiple callbacks registered to be invoked when a module is loaded into the server. A transaction to set module defaults will also be generated, in addition to this callback.
Configuration Replay Start or Finish callbackagt_replay_fn_t: There can be one callback registered that is called at the start and again at the end of a configuration replay transaction.
Commit Complete callbackagt_commit_complete_t: There can be one callback registered that is invoked when the <commit> operation or the internal <replay-config> operation completes without errors.
NV-Load callbackagt_nvload_fn_t: There can be one callback registered that is invoked when the server needs to retrieve the configuration contents from non-volatile storage.

 


YumaPro Server Features

SYSLOG

FeatureDescription
Logging output integrated with SYSLOGStructured logging output can be sent to the SYSLOG deamon independently
of the normal logging options.
Vendor-configurable messagesLogging messages can be customized with vendor-specific callback functions.
Facility, Class, Severity supportSYSLOG formatted and filtered message output is supported.
External SYSLOG API supportThe default SYSLOG service can be replaced with vendor-specific callback functions.

CLI

FeatureDescription
YANG-driven interfaceThe commands available are automatically populated based on the YANG modules loaded into yp-shell. The command line syntax is derived from the YANG syntax.
Config ModeThe config command is used to enter configuration mode. The YANG data nodes become the keywords and familiar CLI syntax is used to create, modify and delete configuration data.
Command RecallSeveral familiar command line recall mechanisms are supported:
history and recall commands to show recent command lines and recall a command line.
control-P (previous line) and Control-N (next line) to scroll through the history buffer.
The ! (bang character) to recall commands by line number or by matching the specified command string.
Context Sensitive EditingThe command completion text and available help text is context-sensitive, based on the YANG definitions, the current command mode or sub-mode, and the cursor position in the command line.
Command AliasesAliases are user-created commands that can be used to customize the command set and reduce typing.
The '?' Help KeyThe ‘?’ (question mark) key can be used to get context-sensitive help for the keyword(s) or value that is expected next within the current command line. The ‘tab’ key is used for short help text and the ‘?’ key is used for long help.

Role Based Access Control

FeatureDescription
Bypass ProtectionThe access control enforcement is integrated into the engine so no operations can bypass it and allow unauthorized access to configuration data.
IETF NACM SupportThe (standard) IETF NETCONF Access Control Model is supported.
Yuma NACM SupportThe (pre-standard) Yuma NETCONF Access Control Model is supported.
External ACM SupportAn external (vendor-specific) access control model can be selected instead of Yuma NACM or IETF NACM, and easily integrated into the netconfd-pro server through a structured API.

Automation

FeatureDescription
All CRUDX database operationsThe built-in transaction engine automatically handles all Create, Retrieval, Update, Delete, and eXecution operations for all NETCONF standards and all YANG modules.
Smart XPath CachingThe built-in XPath handler automatically detects which database nodes are referenced in any YANG must or when XPath expressions, allowing XPath results to be cached safely with no development effort or doctored YANG files.
YANG Defaults HandlingThe built-in transaction engine automatically handles all CRUDX operations correctly, even if default leafs and/or default non-presence containers are involved.
YANG featuresStandard YANG feature statements can be used to easily manage optional data model sections across multiple product platforms and product versions. Separate feature sets can be specified for each platform and release.
YANG extensionsStandard YANG extension statements and structured APIs can be used automatically process vendor-specific custom language statements.
Full Database lockingAutomatic support for standard all NETCONF database locking features.
Backup and Restore ManagementIntegrated backup and restore operations to simplify configuration management changes. Delete named backups with the delete-backup operation and view backup information in the YumaWorks monitoring extension to the standard ietf-netconf-monitoring module.
Transaction auditingConfigurable server transaction auditing with separate audit log.
Optimized Transaction Validation HandlingThe built-in transaction engine automatically detects which commit validation tests can safely be skipped because the database nodes involved in the test have not changed value. This includes all YANG XPath expressions (must, when), all instance tests (min-elements, max-elements, mandatory, unique, key), and all edit operations.
XPath Expression PruningThe built-in XPath handler automatically prunes false AND expressions and true OR expressions, which can greatly improve XPath validation speed.
YANG deviationsStandard YANG deviation statements can be used to easily manage data model diversity across multiple product platforms and product versions. Separate deviation files are automatically patched into the main module.
YANG user-defined typesStandard YANG typedef statements can be used to add any user-defined data types for reuse across multiple YANG modules.
YANG insert operationsAutomatic order-list insertion management through full support for the YANG insert operation extensions to NETCONF.
Partial Database lockingAutomatic support for standard all NETCONF partial-lock data sub-tree locking features.
Transaction managementAutomatic support for fully recoverable database edits, using a 3 phase transaction model, providing separate Validate, Apply, Commit and Rollback callback interfaces.
Confirmed-Commit HandlingFull automated support for the latest standard NETCONF confirmed-commit operations.

Data Retrieval Automation

TypeDescription
Streamed or Bulk OutputThe netconfd-pro server is configurable so protocol messages can be streamed from data structures directly or buffered and sent in bulk transfer mode.
Subtree FilteringOptimized NETCONF sub-tree filtering with streamed output.
Time-stamp FilteringThe if-modified-since parameter is provided all NETCONF retrieval operations to minimize polling overhead. The <rpc-reply> will be empty if the running configuration has not changed since the specified date and time.
XPath FilteringFull XML Path Language (version 1.0) filtering with streamed output.

NETCONF Standards

Fully Supported IETF StandardDescription
RFC 4253Secure Shell (SSH) Transport Layer Protocol
RFC 4741NETCONF base 1.0
RFC 4742NETCONF over SSH v1
RFC 5277NETCONF Notifications
RFC 5717NETCONF Partial Locking
RFC 5789PATCH Method for HTTP
RFC 6020YANG 1.0
RFC 6021YANG Data Types v1
RFC 6022NETCONF Monitoring
RFC 6241NETCONF base 1.1
RFC 6242NETCONF over SSH v1.1
RFC 6243NETCONF With-Defaults Capability
RFC 6470NETCONF Base Notifications
RFC 6536NETCONF Access Control
RFC 6643Translation of SMIv2 to YANG
RFC 6991YANG Data Types v2
RFC 7230HTTP/1.1 Message Syntax and Routing
RFC 7231HTTP/1.1 Semantics and Content
RFC 7232HTTP/1.1 Conditional Requests
RFC 7895YANG Module Library
RFC 7950YANG v1.1
RFC 7951JSON Encoding of YANG Data

YANG Modules Included

YANG Modules IncludedDescription
ietf-inet-typesStandard YANG networking data types from RFC 6021.
ietf-netconfStandard YANG data model for NETCONF protocol operations from RFC 6241.
ietf-netconf-acmStandard NETCONF Access Control Model (NACM) from RFC 6536.
ietf-netconf-monitoringStandard NETCONF monitoring data model and <get-schema> operation from RFC 6022 to retrieve YANG modules from the server.
ietf-netconf-notificationsStandard NETCONF Notification delivery with replay buffer and command interleave mode from RFC 5217.
ietf-netconf-partial-lockStandard NETCONF and operations from RFC 5717 to support concurrent non-overlapping database edits.
ietf-netconf-with-defaultsStandard NETCONF :with-defaults capability extensions to the <get> and <get-config> operations.
ietf-yang-typesStandard YANG data types from RFC 6021.
nc-notificationsNetconf Central YANG module for notification monitoring data model from RFC 5277.
notificationsNetconf Central YANG module for <create-subscription> operation from RFC 5277.
toasterExample SIL module.
yuma-arpNetconf Central YANG module for Linux ARP management.
yuma-interfacesNetconf Central YANG module for Linux interface monitoring.
yuma-mysessionNetconf Central YANG module for setting and retrieving session-specific session parameters.
yuma-nacmNetconf Central YANG module for NETCONF Access Control, used as the starting point for NACM in RFC 6536.
yuma-ncxNetconf Central YANG language extensions.
yuma-procNetconf Central YANG module for Linux /proc system information.
yuma-systemNetconf Central YANG module for NETCONF system management and notifications, which was used as the starting point for RFC 6470.
yuma-time-filterNetconf Central YANG module for time-stamp based filtered of configuration data.
yuma-typesNetconf Central YANG module for extended data types.
yumaworks-extensionsYumaWorks YANG language extensions.
yumaworks-idsYumaWorks YANG identities.
yumaworks-systemYumaWorks extensions for CM maintenance such as the backup, restore, and delete-backup operations.
yumaworks-typesYumaWorks YANG data type extensions.

Login

Lost your password?