Page MenuHomeVyOS Platform

Add NETCONF server with YANG data modeling
Open, LowPublicFEATURE REQUEST

Description

NETCONF is the standard for installing, manipulating and deleting configuration of network devices while YANG is used to model both configuration and state data of network elements.

netconfd - YANG-based NETCONF-over-SSH server
https://manpages.debian.org/bullseye/netconfd/netconfd.1.en.html

YANG is most likely required to write vendor-specific modules
https://github.com/YangModels/yang

Additional links:
Netopeer2 is a server for implementing network configuration management based on the NETCONF Protocol.
https://github.com/CESNET/netopeer2
https://hub.docker.com/r/sysrepo/sysrepo-netopeer2
https://www.sysrepo.org/
RFC 6020 https://datatracker.ietf.org/doc/html/rfc6020

podman run -it --rm -p 830:830 --name netopeer --net host docker.io/sysrepo/sysrepo-netopeer2


root@r11-roll:/home/vyos# ssh netconf@localhost -p 830 -s netconf
Interactive SSH Authentication
Type your password:
Password: 
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:candidate:1.0</capability><capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability><capability>urn:ietf:params:netconf:capability:validate:1.1</capability><capability>urn:ietf:params:netconf:capability:startup:1.0</capability><capability>urn:ietf:params:netconf:capability:xpath:1.0</capability><capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&amp;also-supported=report-all,report-all-tagged,trim,explicit</capability><capability>urn:ietf:params:netconf:capability:notification:1.0</capability><capability>urn:ietf:params:netconf:capability:interleave:1.0</capability><capability>urn:ietf:params:xml:ns:yang:ietf-yang-metadata?module=ietf-yang-metadata&amp;revision=2016-08-05</capability><capability>urn:ietf:params:xml:ns:yang:1?module=yang&amp;revision=2017-02-20</capability><capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&amp;revision=2013-07-15</capability><capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&amp;revision=2013-07-15</capability><capability>urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&amp;content-id=32</capability><capability>urn:sysrepo:plugind?module=sysrepo-plugind&amp;revision=2020-12-10</capability><capability>urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&amp;revision=2018-02-14</capability><capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&amp;revision=2013-09-29&amp;features=writable-running,candidate,rollback-on-error,validate,startup,url,xpath</capability><capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&amp;revision=2011-06-01</capability><capability>urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&amp;revision=2012-02-06</capability><capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&amp;revision=2010-10-04</capability><capability>urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&amp;revision=2008-07-14</capability><capability>urn:ietf:params:xml:ns:netmod:notification?module=nc-notifications&amp;revision=2008-07-14</capability><capability>urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name?module=ietf-x509-cert-to-name&amp;revision=2014-12-10</capability><capability>urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&amp;revision=2014-08-06</capability></capabilities><session-id>1</session-id></hello>]]>]]>
root@r11-roll:/home/vyos# podman exec -it netopeer ls -la /etc/sysrepo/yang/
total 380
drwxrwxrwx 2 root root  4096 Jan 27  2021 .
drwxrwxrwx 5 root root  4096 Dec 14 17:54 ..
-rw-rw-r-- 1 root root  4203 Jan 27  2021 iana-crypt-hash@2014-08-06.yang
-rw-rw-r-- 1 root root 69447 Jan 27  2021 ietf-crypto-types@2019-07-02.yang
-rw-rw-r-- 1 root root  2615 Jan 27  2021 ietf-datastores@2018-02-14.yang
-rw-rw-r-- 1 root root 14048 Jan 27  2021 ietf-keystore@2019-07-02.yang
-rw-rw-r-- 1 root root 13169 Jan 27  2021 ietf-netconf-acm@2018-02-14.yang
-rw-rw-r-- 1 root root 17425 Jan 27  2021 ietf-netconf-monitoring@2010-10-04.yang
-rw-rw-r-- 1 root root 12357 Jan 27  2021 ietf-netconf-nmda@2019-01-07.yang
-rw-rw-r-- 1 root root 10171 Jan 27  2021 ietf-netconf-notifications@2012-02-06.yang
-rw-rw-r-- 1 root root 19334 Jan 27  2021 ietf-netconf-server@2019-07-02.yang
-rw-rw-r-- 1 root root  3598 Jan 27  2021 ietf-netconf-with-defaults@2011-06-01.yang
-rw-rw-r-- 1 root root 26724 Jan 27  2021 ietf-netconf@2011-06-01.yang
-rw-rw-r-- 1 root root 26969 Jan 27  2021 ietf-netconf@2013-09-29.yang
-rw-rw-r-- 1 root root  3812 Jan 27  2021 ietf-origin@2018-02-14.yang
-rw-rw-r-- 1 root root 13895 Jan 27  2021 ietf-ssh-common@2019-07-02.yang
-rw-rw-r-- 1 root root 11658 Jan 27  2021 ietf-ssh-server@2019-07-02.yang
-rw-rw-r-- 1 root root  5059 Jan 27  2021 ietf-tcp-client@2019-07-02.yang
-rw-rw-r-- 1 root root  3627 Jan 27  2021 ietf-tcp-common@2019-07-02.yang
-rw-rw-r-- 1 root root  3860 Jan 27  2021 ietf-tcp-server@2019-07-02.yang
-rw-rw-r-- 1 root root 11903 Jan 27  2021 ietf-tls-common@2019-07-02.yang
-rw-rw-r-- 1 root root  8991 Jan 27  2021 ietf-tls-server@2019-07-02.yang
-rw-rw-r-- 1 root root  8874 Jan 27  2021 ietf-truststore@2019-07-02.yang
-rw-rw-r-- 1 root root 11000 Jan 27  2021 ietf-x509-cert-to-name@2014-12-10.yang
-rw-rw-r-- 1 root root 16255 Jan 27  2021 ietf-yang-library@2019-01-04.yang
-rw-rw-r-- 1 root root  2603 Jan 27  2021 nc-notifications@2008-07-14.yang
-rw-rw-r-- 1 root root  2364 Jan 27  2021 notifications@2008-07-14.yang
-rw-rw-r-- 1 root root  6282 Jan 27  2021 sysrepo-monitoring@2021-01-15.yang
-rw-rw-r-- 1 root root   433 Jan 27  2021 sysrepo-plugind@2020-12-10.yang

Details

Version
-
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)

Event Timeline

Unknown Object (User) subscribed.Jul 30 2022, 5:53 AM

+1
OpenConfig should be used as a basic YANG model.
If something is missing, add proprietary ones
https://www.openconfig.net/

including information about Netopee2/sysrepo services, how to integrate it with FRR, where we can utilize the advantages netconf/yang :

https://github.com/opensourcerouting/frr/wiki/Architecture

it could be interesting for the future.

dmbaturin edited projects, added VyOS 1.5 Circinus; removed VyOS 1.4 Sagitta.

I am tired of Network Management complacation, I am tired to change different management cli command if switch diffrent brand router, I need automation, so I switch to netconf to config, I ask chatgpt, what router support, It said VyOS, But VyOS not support NetConf infact, I hope someday it could.

I’ve developed a script that automatically generates a YANG model from rendered VyOS XML configuration files. I publised the current model output here (https://github.com/yahyacivelek/vyos-yang/tree/main) for your review. I’d like to ask whether this is still a relevant gap and if there is any ongoing work in this area.

If this would be useful and not already being actively developed, I’d appreciate guidance on how best to contribute (e.g., repository, or location).

Hi, @yahyacivelek !

Yes, this is still relevant. While it may not be one of the top priorities, it is definitely one of the gaps we would be very happy to address.

What is currently missing is an end-to-end solution, including clear instructions on how to use this efficiently and how to test it in practice. If you could provide a model along with integration and usage instructions, that would likely be a very good starting point. From there, we could begin exploring how to make it a native part of the system.

What do you think? Is this something you could try to do?

I’d be happy to explore this further. I’m thinking of building an end-to-end prototype along these lines:

  • A script that generates basic YANG models from rendered VyOS XML configuration data
  • A gNMI server acting as a translation layer between the generated model and the existing VyOS config system:
  • Path mapping (e.g. /interfaces/interface[name=eth0]/address => set interfaces ethernet eth0 address X)
  • Optional validation of incoming Set requests using the generated model
  • Applying config via the VyOS HTTP API or directly via VyOS libraries
  • Handling transaction semantics (commit / confirm / rollback on failure)

I’d also include:

Clear usage instructions (how to run, configure, and test)
A couple of end-to-end test scenarios using open-source gNMI clients like gnmic

I'm planning to develop the server in Rust. Does this direction make sense to you?

The general direction seems really good. I would only invite @dmbaturin to share his view on two topics:

  1. Execution of configuration - through the API or directly via VyOS libraries. I feel the latter is preferred here, especially if we want to integrate the service directly into the operating system at some point.
  2. Development language - @dmbaturin might have preferences or constraints regarding Rust.