So what has changed in the past 20 years? Take for example the network equipment that was manufactured in 1997, how did you configure that equipment? I would imagine it involved a serial port, HyperTerminal and trusty command line. Was API even a thing back in 1997, was it common to have an API interface in network equipment like today? Why do we even need an API on the equipment in the first place? What changed?
Well the year isn’t 1997 anymore, that past us 20 years ago and the equipment we work with today looks and operates much differently than it did in 1997. We work in a world now that operates with Gbps/Tbps not Kbps/Mbps. With the need for speed CLI isn’t the fastest thing anymore to configure or monitor network devices. This industry is moving into automated ways to configure and monitor network devices. So in this post we’ll look at enabling the NX-API that’s in the Cisco Nexus 9000 and 3000 family switches. Doing this we’ll get introduced into the Cisco NX-API sandbox.
To enable this API jump right into CLI and configure the management interface, we’ll be able to use this API using the management IP address of the switch.
vrf context management interface mgmt0 description OOB Management vrf member management ip address 172.16.1.192/24
Once the management interface is configured we now can enable the NX-API by one command.
nx-osv9000-1# config t nx-osv9000-1(config)# feature nxapi
Open a web browser to the management IP address and login with a username and password.
Welcome to NX-API Sandbox! With this we can play around to get a further understanding of how to use this API. Like being able to configure and or monitor this device with either a custom home-grown system, or the use some network automation software like Puppet or Chef.
So now what? Well if you are like me and really don’t have much programming experience or just enough to be dangerous this where you get comfortable and use this sandbox to understand what it can and cannot do. For example on the upper right hand side, if I select XML on the message format, then cli_show on the command type, followed by typing the command show hostname in the CLI command box, and finishing by selecting the post button, I should see an output of an XML request as well as the XML response from the switch.
<?xml version="1.0" encoding="UTF-8"?> <ins_api> <type>cli_show</type> <version>1.0</version> <sid>eoc</sid> <outputs> <output> <body> <hostname>nx-osv9000-1</hostname> </body> <input>show hostname</input> <msg>Success</msg> <code>200</code> </output> </outputs> </ins_api>
Note: Sandbox is a loose term here as any configuration viewed or applied is live on the equipment, don’t play in the sandbox on production equipment. 🙂
This post just scratches the surface of what you could do with this API, being able to either write something yourself or using third-party software to help configure and maintain network equipment makes your job easier. Although we still have equipment and even people today that still like those three letters “CLI”, being able to use an API that can configure and maintain provides options for these devices, and who doesn’t like that?