SHARE

The most common way for the last thirty years to configure our network devices is the command-line interface (CLI). The CLI is great for humans, not so great for computers.

We use configuration commands to configure everything and show or debug commands to verify our work. The output of show (and debug) commands is formatted, so it’s easy to read for humans, it’s a pain however to use the CLI for scripts or network automation tools. You have to parse a show command to get the information you want, and the output is different for each show command.

Configuration commands are also an issue. On Cisco IOS, when you enter a command, there is no confirmation whether the router or switch accepts the command or not. You only see the empty prompt. If you paste a lot of commands, sometimes the console can’t keep up. For us humans, it’s easy to spot this and work around this. For CLI scripts or network automation tools, it’s a problem and you have to take this into account.

An alternative to the CLI to configure network devices is through application programming interfaces (APIs). APIs use data formats to exchange information. In this lesson, we’ll discuss the most popular data formats and structures.

Data Formats

There are two common data formats that APIs often use:

Extensible Markup Language (XML) JavaScript Object Notation (JSON)

We also call these data formats “data serialization languages”. Another data format we often use for device configuration is YAML. Let’s talk about these three data formats.

Extensible Markup Language (XML)

(XML) is a tag-based language and if you know HTML, this will look familiar.

Each item you add has to start with < and end with >. Here is a simple example:

<router> <name>CSR1000V</name> <vendor>Cisco</vendor> <type>virtual</type> </router> <router> <name>1921</name> <vendor>Cisco</vendor> <type>hardware</type> </router> </devices>

The output above shows the tag with two tags in it. One contains information about a CSR1000V router, the second tag contains information about a 1921 router.

Let me show you the output of an actual router. Here is the output of show running-configuration as seen from the CLI:

hostname R1 ! ip cef ! interface GigabitEthernet0/1  ip address 192.168.12.1 255.255.255.0 duplex auto speed auto media-type rj45 ! interface GigabitEthernet0/2  ip address 192.168.1.254 255.255.255.0 duplex auto speed auto media-type rj45 ! end

In XML, it looks like this:

R1#show running-config | format <?xml version=”1.0″ encoding=”UTF-8″?> <Device-Configuration   xmlns=”urn:cisco:xml-pi”> <version> <Param>15.6</Param> </version> <service> <timestamps> <debug> <datetime> <msec/> </datetime> </debug> </timestamps> </service> <service> <timestamps> <log> <datetime> <msec/> </datetime> </log> </timestamps> </service> <service operation=”delete” > <password-encryption/> </service> <hostname> <SystemNetworkName>R1</SystemNetworkName> </hostname> <ip> <cef/> </ip> <interface> <Param>GigabitEthernet0/1</Param> <ConfigIf-Configuration> <ip> <address> <IPAddress>192.168.12.1</IPAddress> <IPSubnetMask>255.255.255.0</IPSubnetMask> </address> </ip> <duplex> <auto/> </duplex> <speed> <auto/> </speed> <media-type> <rj45/> </media-type> </ConfigIf-Configuration> </interface> <interface> <Param>GigabitEthernet0/2</Param> <ConfigIf-Configuration> <ip> <address> <IPAddress>192.168.1.254</IPAddress> <IPSubnetMask>255.255.255.0</IPSubnetMask> </address> </ip> <duplex> <auto/> </duplex> <speed> <auto/> </speed> <media-type> <rj45/> </media-type> </ConfigIf-Configuration> </interface> <end></end> </Device-Configuration>

One more example, here is show arp with the CLI output:

R1# show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.1.1 67 fa16.3ee0.d9a3 ARPA FastEthernet0/0 Internet 192.168.1.2 8 fa16.3ee0.c9b2 ARPA FastEthernet0/0 Internet 192.168.1.3 – fa16.3ee0.a5a5 ARPA FastEthernet0/0

And in XML, it looks like this:

<?xml version=”1.0″ encoding=”UTF-8″?> <ShowArp xmlns=”ODM://disk0:/spec.odm//show_arp”> <ARPTable> <entry> <Protocol>Internet</Protocol> <Address>192.168.1.1</Address> <Age>67</Age> <MAC>fa16.3ee0.d9a3</MAC> <Type>ARPA</Type> <Interface>FastEthernet0/0</Interface> </entry> <entry> <Protocol>Internet</Protocol> <Address>192.168.1.2</Address> <Age>8 </Age> <MAC>fa16.3ee0.c9b2</MAC> <Type>ARPA</Type> <Interface>FastEthernet0/0</Interface> </entry> <entry> <Protocol>Internet</Protocol> <Address>192.168.1.3</Address> <MAC>fa16.3ee0.a5a5</MAC> <Type>ARPA</Type> <Interface>FastEthernet0/0</Interface> </entry> </ARPTable> </ShowArp>

These XML outputs are indented which makes them easier to read for us humans. Indentation however, is not a requirement of XML.

JavaScript Object Notation (JSON)

(JSON) is newer than XML and has a simple syntax. JSON stores information in key-value pairs and uses objects for its format. It’s easier to read and has less overhead than XML.

Objects start with { and end with }. Commas separate objects. Double quotes wrap names and strings. Lists start with [ and end with ].

Let’s convert our first XML example into JSON.

XML:

<router> <name>CSR1000V</name> <vendor>Cisco</vendor> <type>virtual</type> </router> <router> <name>1921</name> <vendor>Cisco</vendor> <type>hardware</type> </router> </devices>

JSON:

“devices”: { “router”: [ { “name”: “CSR1000V”, “vendor”: “Cisco”, “type”: “virtual” }, { “name”: “1921”, “vendor”: “Cisco”, “type”: “hardware” }    ] } }

If you look at the output above, you can see we used the tag twice in XML. In JSON, we only need a single “router” object. This is a list with two objects.

YAML (YAML Ain’t Markup Language)

According to the official website, YAML is a human friendly data serialization standard for all programming languages. YAML is a superset of JSON. This means that a YAML parser understands JSON, but not necessarily the other way around.

YAML is easier to look at than XML or JSON.

Key-value pairs are separated by : (colon). Lists begin with a – (hyphen). Indentation is a requirement. You have to use spaces, you can’t use tabs. You can add comments with a #.

We often use YAML files for configuration management because it’s easy to read and comments are useful.

Let’s compare JSON with YAML, here’s the JSON object I showed you before:

JSON:

{ “devices”: { “router”: [ { “name”: “CSR1000V”, “vendor”: “Cisco”, “type”: “virtual” }, { “name”: “1921”, “vendor”: “Cisco”, “type”: “hardware” }    ] } }

Here it is in YAML:

devices: router: – name: CSR1000V vendor: Cisco type: virtual – name: 1921 vendor: Cisco type: hardware

YAML is easier to read without the commas and brackets of JSON. One disadvantage of YAML is that indentation with spaces is a requirement. It’s easy to make indentation errors where you have a space too few or too many.

When you work with XML, JSON, or YAML files, you can make your life much easier if you use an editor that helps with visualization and indentation. I use Visual Studio Code for almost everything nowadays.

Data Models Yet Another Next Generation (YANG)

SNMP is widely used to monitor networks. You can use SNMP to configure network devices but in reality, we don’t use it much. CLI scripting is a more popular option.

YANG is a modeling language and an alternative to SNMP Management Information Base (MIBs). YANG is a standard, described in RFC 6020 and increasing in popularity. YANG uses data models that describe:

What you can configure on a device. What you can monitor on a device. Administrative actions you can perform on a device like clearing interface counters or resetting the OSPF process.

Data models can be:

Common data models: industry-wide standard YANG models from organizations like IETF and IEEE. Vendor data models: specific models that only apply to products or features from a vendor.

These data models allow a uniform way for us to configure, monitor, and interact with network devices. YANG uses a hierarchical tree structure, similar to the XML data format. There is a clear distinction between configuration data and state information.

A YANG module defines a data model through the data of a network device, and the hierarchical organization and constraints of that data. YANG identifies each module with a namespace URL.

You can find a collection of YANG modules in the YANG git repository. In this repository, there are also Cisco modules. For example, take a look at the modules for IOX XE 16.10.1

LEAVE A REPLY

Please enter your comment!
Please enter your name here