ENAUTO – NETCONF Deployment review, some of the requirements for deploying, and commands for deployment as well!

A nice Cisco 9k for the low price of $65k – $75k for your lab!

I was actually looking at Nexus 2k switches around the net for like $100, and started talking myself into rebuilding a new lab for Automation with Physical switches, but had to fight the urge to start getting 5 lbs boxes shipped en masse to my door step 🙂

I miss the humming of my physical lab, it kept me going through some hard doubtful nights of studying, someone offered to come lift it out of my house with a dolly for free and I still just.. can’t let it go yet:

There is something to be said for having physical routers / switches / phones that light up and have cables running everywhere, I am talking myself back into a new physical lab again, so I better get back to NETCONF here 🙂

Back to work – NETCONF Implementation notes and considerations!

NETCONF was meant to be implemented by software applications, not manually by network engineers on devices via a Controller, as it uses XML code to talk, and is meant to be able to Automate talking to dozens or hundreds of devices at once.

NETCONF allows for the option of a “Global Session Lock” meaning it will prevent other Line sessions from connecting / making config changes while NETCONF Session is open, once NETCONF disconnects it will unlock – There is also an “Unlock” command as well.

NETCONF can be manually invoked (what I just said isn’t supposed to be done, yes) to play around with it in a lab environment, and perform testing and labbing configs with it using Postman / Python scripts / cURL (Linux command line tool) / Terminal window.

Unfortunately most current Cisco Network devices do not natively run NETCONF 😦

NETCONF is being natively integrated in IOS images for Nexus Switches such as IOS-XE and IOS-XR, however on your 3750 from CCNP R/S studies you cannot turn on NETCONF.

All the same I’ll go over the requirements to enable NETCONF on a switch device:

• Must create a self-signed “TrustPoint” (certificate) if none exists, which you can do by typing “ip http secure-server” which automatically generates this TrustPoint, which also enables SSH, at which point I’d also update SSH to ver 2 if not yet ver 2.
• Must have a username password “database” / statement with priv 15 level access
• Enable NETCONFIG / YANG with the command “netconf-yang” in global config
• Can optionally change from TCP Port 830 to a random TCP Port with “netconf-yang ssh port #” command also in global config mode
• Cisco Documentation states AAA Authentication and Authorization must be enabled for NETCONF to work properly, though it can work without it

I haven’t gotten a chance to play with this myself yet, but for exam purposes I am being told by the instructor it is documented by Cisco that NETCONF requires AAA but he has turned it on and used it without AAA – So something to keep in mind for exam day!

This is believed to be so all devices don’t need the local username / password and can reference a single point in the network to authenticate devices, however in smaller lab environments where you can get away with username/password it seems to work fine.

Commands on the router and in Linux to get connected with NETCONF!

“sh netconf-yang session” to show details of an open NETCONF session to a device, which will show the session ID / username / Host IP Addy / if any locks are enabled.

That Session ID will be needed to clear the session as well (which consoled in users can do to boot out NETCONF users), but issuing “clear netconf-yang session #”

“sh netconf-yang datastores” as well to show the current Datastores on the device.

From Linux Terminal, type “ssh -p 830 (username)@deviceIPAddy” :

Unfourtnately I do not have a NETCONF capable device @ 192.168.128.101, otherwise that would have connected and spit out a bunch of NETCONF / XML output of the session initiating, the “-p” in the line is to change the port # as Linux would otherwise consider SSH to be port 22 by default.

However once this connects it automatically engages the running config lock, if a user even tries to issue a “conf t” on this device a NETCONF message will pop up saying the session is locked by NETCONF Session ID #.

That does it for my NETCONF review, on to RESTCONF coming up next!

I will try to add a bit more NETCONF content if I can somehow get my hands on a local NETCONF capable switch, however I am wrapping up NETCONF here, later! 🙂