Configure NETCONF/YANG on Cisco Devices
Today I am going to talk about the Data model as an open source. The data model which I am talking about is NETCONF/YANG. Many of you heard about YANG and NETCONF is many of discussions where the agenda is to have the programmatic and standard based configurations and Monitoring. We will discuss on both YANG and NETCONF one by one.
YANG Model:
YANG is a standards-based data modeling language used to make box/device configuration needs or the requests for operational (show command) data. It has a organized set-up like to a computer program that is human understandable. Numerous applications are accessible that can be run on a consolidated administration platform to make these configuration and operational data requests.
There are both standard YANG data models that operate to all vendors (for example, a demand to restrict or shut down an ethernet interface should be matching for both Cisco and non-Cisco devices) as well as device (native, vendor specific) data models that simplify configuring or gathering operational data related with patented vendor qualities.
 |
| Fig 1.1- YANG/NETCONF Data models |
NETCONF- Network Configuration Protocol
NETCONF is a standard based and Extensible Markup Language (XML) programmed protocol that delivers the transport to interconnect the YANG structured configuration or functioning data request from an application that runs on a consolidated administration platform to the OEM device that a worker needs to design or appeal functioning data from. It offers contract-based services such as terminating the complete configuration appeal when a percentage of that configuration request fails.
NETCONF usages a simple Remote Procedure Call (RPF) built mechanism to simplify interaction between a client (centralized management platform script or application) and a server (Cisco switch or router). It uses Secure Shell (SSH) as the transport layer across network devices. Some NETCONF operations include get, get-config, edit-config, and rpc.
Verify NETCONF/YANG on the Cisco Catalyst 9300 Switch
Step-1
RouteXP_9300-1# show platform software yang-management process
confd: Running
nesd: Running
syncfd: Running
ncsshd: Running
dmiauthd: Running
vtyserverutild: Running
opdatamgrd: Running
ngnix: Running
Step-2
Ensure that the centralized management platform can reach the Cisco Catalyst 9300 (192.168.10.10) on the network
NB_User-ZP-111: ~ USER1$ ping 192.168.10.10
PING 192.168.10.10(192.168.10.10): 56 data bytes
64 bytes from 192.168.10.10: icmp_seq=0 ttl=247 time=3.912 ms
64 bytes from 192.168.10.10: icmp_seq=1 ttl=247 time=6.917 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=247 time=4.063 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=247 time=4.371 ms
Step-3
Confirm SSH connectivity to the Cisco Catalyst 9300, here we took 192.168.10.10 in this sample from the centralized management platform with the username and password from the above Catalyst 9300 configuration. The reply will be a extensive catalog of NETCONF abilities from the Catalyst 9300 surveyed by a hello message.
TCP port 830 = netconf-ssh
NB_User-ZP-111: ~ USER1$ ssh -s Routexp1@192.168.10.10-p 830 netconf
Routexp1@192.168.10.10 password: networksbaseline
<?xml version="1.0" encoding="UTF-8"?>
<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:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
</capabilities>
<session-id>2870</session-id></ hello>]]>]]>
Use < ^C > to exit
