Configuring interfaces on Cisco Router using NETCONF (any IOS below 16.x)
First, the Networking fundamentals picture plus explanation. Check drawing below:
| Any Cisco Router running any IOS below 16.x |
| hostname devnetlearning1 username cisco1 privilege 15 password 0 cisco1 aaa new-model aaa authorization exec default local ip domain-name devnetlearning.com snmp-server enable traps snmp authentication linkdown linkup snmp-server enable traps syslog snmp-server manager ! crypto key generate rsa 2048 ip ssh logging events ip ssh version 2 ! netconf max-sessions 16 netconf max-message 2147483 netconf ssh ! line vty 0 4 transport input ssh ! interface Ethernet0/0 ip address 10.0.0.254 255.255.255.0 no sh ! |
| Client (human) |
| You can use any OS bash or netconf-console. The demo and example output will come from the Ubuntu 18.04.5 LTS OS. |
Client must have IP connectivity and Router must have enable netconf ssh in order to be able to listen request via TCP:22
STEP (1) – Client connects to NETCONF SSH subsystem.
Human connecting to the router via bash using> ssh -p 22 cisco1@10.0.0.254 -s netconf
STEP(2) – Server (router) responds with Hello that includes NETCONF-supported capabilities.
Router replies back to the client with a HELLO NETCONF INTRO displaying the router NETCONF capabilities as following>
| <?xml version=’1.0′ encoding=’UTF-8′?> <nc:hello xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″> <nc:capabilities> <nc:capability>urn:ietf:params:netconf:base:1.0</nc:capability> <nc:capability>urn:ietf:params:netconf:capability:writeable-running:1.0</nc:capability> <nc:capability>urn:ietf:params:netconf:capability:startup:1.0</nc:capability> <nc:capability>urn:ietf:params:netconf:capability:url:1.0</nc:capability> <nc:capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</nc:capability> <nc:capability>urn:cisco:params:netconf:capability:notification:1.0</nc:capability> </nc:capabilities> </nc:hello> |
STEP(3) – Client responds with supported capabilities
In this step, the client must respond with the client capabilities. If the Router did not receive any capability whatsoever, the router can not continue with the NETCONF process. Client to respond with supported capabilities as following:
| <?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> </capabilities></hello>]]>]]> |
Keep in mind, all the exchange data is using the same pattern. the same data format. XML.
STEP(4) – Client issues NETCONF request (rpc/operation/content)
In this particular step, client provide any request that want to consume from the server (router). Remember that the NETCONF capabilities were exchanged already, therefore, client and server are aware of what is and what is not capable of each other. In this example, Client is already aware that the router is capable to receive interface configuration via NETCONF and proceed to request interface configuration change on interface Ethernet 0/1 configuring 76.05.17.66/31 as following:
| <?xml version=”1.0″ encoding=”UTF-8″?> <rpc message-id=”101″ xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0″> <edit-config> <target> <running/> </target> <config> <cli-config-data> <cmd>hostname devnetlearning1</cmd> <cmd>interface Ethernet0/1</cmd> <cmd>ip address 76.05.17.66 255.255.255.254</cmd> </cli-config-data> </config> </edit-config> </rpc>]]>]]> |
NOTE between step 3 and 4, server (router) is quiet. Client is the only one who is talking.
STEP(5) – Server (Router) issues response/performs operation
Notice that this is the last Step of the communication process. The Server (router) send a response acknowledging the operation of the client request, confirms the Ethernet 0/1 was configured and communication is closed
[…] NETCONF vs RESTCONFConfiguring interfaces on Cisco Router using NETCONF (any IOS below 16.x) […]