Avatar

Let me just start by saying this…10 minutes before we even started the webinar, the questions started rolling in. The first question, of course, being “Do I need to understand programming to be a network engineer?” Something we’re hearing over and over these days. If you’re asking my honest answer on that, I would say…it couldn’t hurt.

In this TechWiseTV workshop we cover a lot, from YANG data modeling, to encoding, to transport protocols…and then we even dive into Python, specifically for the Catalyst 9000 switches just recently announced. Jeff McLaughlin and Fabrizio Maccioni are the experts on this subject. Check out the corresponding TechWiseTV episode with these guys.

Now the workshop itself is full of demos, so you can’t miss it. Make sure to click the link or copy and paste this in your favorite browser: https://engage2demand.cisco.com/LP=6629?dtid=odicdc000016

I did want to spend a little time talking about YANG data modeling and things like NETCONF and XML, JSON. If you’ve only really heard these words before, but aren’t entirely sure how they work together or even what they have to do with programmability that’s definitely okay! You can still start diving into programmability and learn along the way. I highly recommend the Learning Labs on DevNet.

Here’s a quick primer, though:

 

Network Management Protocols and Encoding

There are three fairly common network management protocols: NETCONF, RESTCONF, and gRPC. Due to the lack of scalability, I’m leaving the old SNMP out here. Besides, everyone is probably pretty familiar with it already. These three protocols are really about transport…how we’re delivering or communicating the information.

NETCONF

  • Uses XML encoding
  • Goes over HTTP 1.1

RESTCONF

  • Uses XML or JSON encoding
  • Uses the same tools as REST, but is not the same as say a REST API

gRPC

  • Uses Google Protocol Buffers (GPB encoding)
  • Goes over HTTP2
  • Allows you to create your own CRUD methods

The encoding is really the format in which the machine can read the calls we are sending it (or some other machine or service is sending it). Machines have trouble just reading human language so we have to send it a format it expects. XML is a bit older and is not very easily read by humans so many people prefer JSON. JSON is still formatted for a machine, but it’s a lot easier for the human mind to comprehend. GPB is really just numbers, no strings. So, obviously not very easily read by a human, but there are benefits to using number codes as well.

Data Modeling Language

YANG (Yet Another Next Generation) has become a standard data modeling language, at least in the world of network devices. What it actually reminds me of is a class in an object oriented programming language. The data model tells us what the machine is looking for, maybe we want to change the speed of a port programmatically. The YANG data model provides that template for what can be configured for a port. Then we can use something like XML or JSON to describe that the port should be 10GB.

As YANG becomes a standard data modeling language used to structure data for multiple devices, we can more easily integrate these devices and utilize the same kinds of programmability skills to interact with them.

Still confused? Make sure to watch the workshop and head on over to DevNet for more information. Or maybe we answered some of your questions during the live Q&A. Here’s a sample, but you can find the rest on SlideShare:

Q. Do the Cisco Catalyst 9500 Series Switches support Bidirectional Forwarding Detection BFD)?

A. Yes. Capabilities are parity with existing Catalyst platforms plus more capabilities.

Q. Will the Cisco Catalyst 9000 Series Switches support VXLAN?

A. Cisco Catalyst 9000 Series Switches support VXLAN encapsulation (data plane). The Software-Defined Access (SDA) use VXLAN encapsulation.

Q. Is there an ordering guide for the Cisco Catalyst 9000 Series Switches yet? Can you provide the link?

A. The ordering guide is not available yet but the datasheets are posted. Please visit: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/datasheet-c78738977.html

Q. Is a virtual switching system (VSS) or any Multi-Chassis Link Aggregation Group MC-LAG) feature available?

A. Cisco Stackwise Virtual technology is supported on Cisco Catalyst 9500, which is equivalent to VSS for redundancy.

Q. Are these Cisco Catalyst 9000 Switches the same platform like the software defined data center Nexus 9000 switches?

A. These are new Cisco Catalyst switches designed for the campus, unlike the Nexus 9000 switches positioned for the data center.

Q. Can you repeat the comparable previous generation models?

A. Cisco Catalyst 9300 is a replacement for the Catalyst 3850. The Catalyst 9400 is a replacement for the Catalyst 4500. The Catalyst 9500 is a replacement for the Catalyst 4500-X.

Q. Can you post the part numbers for mGig versions of Cisco Catalyst 9300?

A. C9300-48UXM-E/A

Q. Are there Cisco Small Form-Factor Pluggable (SFP) models planned?

A. There are SFP Models present in the Cisco Catalyst 9500 Series. They include the 40G and 10G models.