Jason Edelman's Blog

Automated Testing & Intent Verification for Network Operations

Mon, 23 Oct 2017 00:00:00 +0000

The most important part of writing quality software is testing. Writing unit tests provide assurance the changes you’re making aren’t going to break anything in your software application. Sounds pretty great, right? Why is it that in networking operations we’re still mainly using ping, traceroute, and human verification for network validation and testing?

The Network is the Application

I’ve written in the past that deploying configurations faster, or more generally, configuration management, is just one small piece of what network automation is. A major component much less talked about is automated testing. Automated testing starts with data collection and quickly evolves to include verification. It’s quite a simple idea and one that we recommend as the best place to start with automation as it’s much more risk adverse to deploying configurations faster.

In our example, the network is the application, and unit tests need to be written to verify our application (as network operators) has valid configurations before each change is implemented, but also integrations tests are needed to ensure our application is operating as expected after each change.

DIY Testing

If you choose to go down the DIY path for network automation, which could involve using an open source framework as a foundation, e.g. Salt, Ansible, Puppet, you may also go down the path of writing tests manually. The types of tests that you should be using for production network changes are limitless from verifying neighbors to the quantity routes to even more basic things such as MTU consistency and the enforcement of Enterprise standards for names and descriptions. Writing these tests to verify your intent is no easy feat. It’ll take time and dedicated resources for each part of your network.

Commercial Testing Platforms

On the other hand, if you prefer to have a hand to shake, or throat to choke, you may also want to consider platforms such as Forward Networks or Veriflow. I recently saw Veriflow at the latest Networking Field Day and Forward at ONUG. Veriflow has dozens of built-in consistency and intent-checks–they basically collect the output of operational show commands and offer a platform to define automated tests/checks against that data. If I must admit, Veriflow was one of my favorite presentations of the NFD event. It’s worth noting that everything they offer is also exposed via a RESTful API.

From API to Platform Integrations

These types of vendors that are focused on intent-based verification need to provide more than an API though. In conversations with both companies, the focus is using the UI and doesn’t fully reflect an API-first strategy. We haven’t quite crossed the chasm of network automation going main stream, but as they say, skate to where the puck is going, not where it is. What do I mean by this?

In the network automation space, the puck is heading to leveraging CI/CD pipelines for network operations. This means companies need integrations, not just APIs (same as I’ve said in the past about network vendors touting APIs). In this case, companies have the opportunity to be CI platforms for the network. This could be in the form of git integrations, e.g. just like Travis has a native plug-in to GitHub. Think about describing your tests in a YAML config file stored in a repo that triggers Veriflow tests when ever a pull request is opened. Think about doing a deployment with Ansible, but having Ansible trigger post-deployment verification tests (if you aren’t already writing your own tests with Ansible).

Closing

The truth is all of that is possible today, but wouldn’t it be nice if there were native integrations available so that everyone wasn’t re-inventing the wheel?

The network automation space and its surrounding ecosystem of tools is still in its infancy and I truly look forward to its future.

Thanks,

Jason (@jedelman8)

Arista's Programmability Strategy

Sun, 01 Oct 2017 00:00:00 +0000

Arista is largely known for its operating system, best known as EOS. Arista has been known to deploy new features at a more rapid pace than other vendors and to have a more open OS–since EOS was the first production-grade network network operating system to expose any form of Linux to end users.

Because of this, I believe it’s perceived Arista has a better programmability strategy than other vendors. From what I can tell, it is not the case. However, given a few features Arista has in EOS, it makes programming EOS a bit easier than other platforms. Let’s take a look.

At Network Field Day 16, Arista reviewed their programmability strategy. There were 5 core components reviewed:

EAPI
OpenConfig
NetDB Streaming
Turbines
EosSdk

Before diving into each of these, I’ll first point out that when I look at “OS programmability,” what is important [to me] is device-level programmability (not controllers or streaming capabilities–those are important topics, but should be covered on their own). Programmability is the ability to program change on a device, isn’t it? Now let’s look at the 5 components in Arista’s strategy.

EAPI - it’s a great API for learning to program an EOS switch. This is on par with Cisco’s Nexus NX-API CLI. However, EAPI (same for NX-API) is not a robust RESTful API. They are great APIs for learning because they still use commands. It’s the kind of API you need when the OS was built before an API-first strategy, which is totally fine (but shouldn’t be the final strategy). You simply send commands to the device via HTTP/S and get JSON responses back (if the command is supported).

OpenConfig (OC) - on its own, OC should not be a programmability strategy without more context provided. What transports are supported? Is it streaming only? Is it for configuration management? What models are supported? In Arista’s case, this is gRPC only and for streaming data only.

NetDB Streaming - I’m hard-pressed to include this one for two reasons. It’s for streaming (not programming) and you need to engage with Arista as a customer to understand it / use it in more detail.

Turbines - as you can see from the photo, these are custom apps on top of CVP. As mentioned previously, I’d rather not conflate device level programmability and controller programmability. In addition, it’s still a work in progress.

EosSdk - it is in fact an avenue for device level programmability, but for the control plane of the switch (compared to management plane). I think this is slick and great knowing it’s there, but out of reach and not needed for the majority of EOS users.

Update: shortly after this published, I was informed the latest release of EOS has gRPC support for streaming and also configuration of certain models. Some of these models are also exposed via NETCONF too.

Summary

When I take a step back and look at Arista’s strategy for programmability, this is what I’m left with:

Arista should consider creating a real object-based RESTful API–one that doesn’t use CLI commands, even if this uses custom models. RESTCONF comes to mind.
There needs to be a differentiation between programmability and streaming telemetry.
Be very explicit with what’s supported with regards to OpenConfig. See above for more context.
If a platform is supporting YANG models, it would be much preferred to support NETCONF and/or RESTCONF for a real API (in the context of configuring the management plane). These are preferred over gRPC for the majority of users at this point in time. For example, in Python it’s quite easy to get started with Python requests and ncclient. How would one would get started with a vendor-neutral gRPC client? From what I’ve seen, every vendor has been developing their own gRPC clients thus far. Does this mean it’s not standard gRPC?

What makes eAPI a valid strategy (and more programmable than other OSs) is not the API itself, but EOS supporting two features: config replace (atomic config replace) and configuration sessions (batch transactions like a candidate configuration). Having an open OS and these features are great, but shouldn’t minimize the focus on proper [configuration] API development.

General thoughts? Feel free to comment below!

Thanks,

Jason (@jedelman8)

Intent-Based Network Automation with Ansible

Wed, 06 Sep 2017 00:00:00 +0000

The latest in all the networking buzz these days is Intent-Based Networking (IBN). There are varying definitions of what IBN is and is not. Does IBN mean you need to deploy networking solely from business policy, does IBN mean you must be streaming telemetry from every network device in real-time, is it a combination of both? Is it automation?

This article isn’t meant to define IBN, rather, it’s meant to provide a broader, yet more practical perspective on automation and intent.

Intent isn’t New

One could argue that intent-based systems have been around for years, especially when managing servers. Why not look at DevOps tools like CFEngine, Chef, and Puppet (being three of the first)? They focused on desired state–their goal was to get managed systems into a technical desired state.

If something is in its desired state, doesn’t that mean it’s in its intended state?

These tools did this eliminating the need to know the specific Linux server commands to configure the device–you simply defined your desired state with a declarative approach to systems management, e.g. ensure Bob is configured on the system without worrying about the command to add Bob. One major difference was those tools used the term “declarative” and not “intent-based” when it comes to industry terms and hype. That said, it’s actually quite a solid approach to systems management.

Using DevOps Tools for Networking

Using a declarative approach for systems management was solid enough that eventually these tools were extended to manage network devices. The only caveat was the companies that developed these tools never employed anyone focused on network integrations. Then along came Ansible–they were the same in that they employed no one that developed network integrations (circa 2014-15). There was a major difference between Puppet/Chef and Ansible though. It was that Ansible was dead simple and the network community drove the initial Ansible <–> network device integrations. Even vendors like Juniper and Arista wrote their own modules. Finally, Ansible made investments and continues to do so, and now has a full team dedicated to networking.

Since I mentioned all other popular “configuration management” tools, there is even the newest of these tools: Salt by SaltStack, that has a growing interest in the community to be used for network automation.

Intent-Based Network Automation with Ansible

Let’s get back to Ansible. Ansible is interesting because it’s often debated if it’s imperative or declarative. This partially goes back to defining something as intent-driven or not. More on this later though.

Major point: certain tools are not tools–they are mere platforms that you can build on. This is how I see Ansible. If you look at a single task (in Ansible terminology) today, you may in theory be using CLI commands or making specific API calls. What’s great about this is that you know 100% what is being sent to the device. What’s not so great about this? It may not be considered intent-based by industry pundits. However, platforms like Ansible have building blocks.

Within Ansible, there are modules, tasks, plays, and roles that allow you to build your own abstractions that perform how you need them to fit your environment. This means you can write an Ansible playbook to automate your network that enforces your precise intent. Of course, if you look inside the playbook, you may see some imperative tasks, but who cares? This is why there are platform architects (who build robust playbooks) and users of the system (who execute the playbooks).

You should be able to define your desired state according to your Enterprise standards.

Using CLI Commands to Drive Intent

All we do at Network to Code is network automation. If all we had was something that could be used for greenfield deployments or that only worked in the WAN, Campus, or DC, we wouldn’t exist as a services company. Our major selling point is that we make network automation consumable and something that can be adopted and deployed in a gradual, yet effective, fashion across a wide variety of network types. This means using CLI commands to even drive intent–let’s face it, it’s the world we live in.

If there is any solution categorized as Intent-Based Networking (open source of commercial), I guarantee you it’s using CLI commands if it’s managing devices such as Cisco Nexus, IOS, or Arista EOS. All this means is that the solution built more logic on top to enforce intent, perform real-time checks, and allows you to see and mange this with a slick UI.

Network Intent with NAPALM

This post wouldn’t be complete without mention of NAPALM. NAPALM at its core is a Python library that was built to offer a uniform way (in Python) to manage network device configurations. While this isn’t meant to be a primer on NAPALM, there is a way to declaratively manage full device configurations with NAPALM. This means if your desire is to have a particular running configuration on the device, you can use NAPALM to do so. The subtle, but major difference here to traditional automation, is you do not have to issue any “no” or “delete” commands to do this.

You literally focus on what your intent is with CLI commands, which in my opinion isn’t a bad thing because CLI devices is what’s mostly deployed today in production environments (forget about what transport is used - CLI over API or CLI over SSH…it’s still being used). Looking back, NAPALM was arguably the first networking library that offered intent (but uses declarative in their terminology just as the initial DevOps tools did). Again, the real value here is that NAPALM is a collection of device drivers, so why not build atop NAPALM. In fact, any commercial tool is using something equivalent like NAPALM to manage device configurations.

Using Ansible and NAPALM

Because Ansible was extensible, there were NAPALM modules written pretty early on, pre-dating any network module in core today. We could go onto say that Ansible has been doing IBN for over several years now! In either case, systems have building blocks. These days you can use native modules in Ansible core (much more of this coming with Ansible 2.4), or NAPALM modules with Ansible to write pretty robust playbooks–each playbook could do something like manage a configuration of device with intent in mind or something that makes adoption easier, managing each feature with intent in mind!

You shouldn’t have to change your Enterprise standards to adopt automation.

From Automating Configurations to Automating Intent

This brings me to another point and question not often talked about when it comes to automation, configuration drift, intent, and declarative configuration management.

If you’re managing network devices, what is the source of truth (SOT)? Where are the desired (or intended, if we want to use current terminology) configuration inputs held? Is it in a custom database? IPAM solution? YAML files? Any answer is better than, “it’s the network device and that’s the only thing we trust!” However, after you consider where the SOT is and where you want it to be, you have to ask yourself, what about “additional configurations” that are on the device after you’ve automated your desired configuration?

What if you desire 5 BGP neighbors and those 5 exist, but there are also 2 others?
What if you need 10 VLANs on each switch, but there is also an additional 2-3 on each switch?
What about SNMP community strings? Do all of your SNMP tools work, but you still see the aging comm strings for the past 20 years that you’re afraid to delete?

We can ask these types of questions for every feature on a network device. This is why there is actually a major difference with what we refer to as basic network automation (ensure your desired configuration exists) and fully declarative intent-based management per feature or per device (ensure your intended and desired configuration exists and remove all other configurations not in your SOT).

Using Ansible as a Platform

If you treat Ansible as a platform, you get all of this today. It’s up to you to choose what level of abstraction is right for your organization and the users of the platform. For example, we at Network to Code have been hard at work deploying solutions like this leveraging Ansible as a platform. We’ve deployed Ansible Tower (self-service via Tower Surveys) on top of Ansible if that meets customer requirements, and we’ve developed custom integrations (including front-ends) that are more network centric that sit above Ansible (or Tower).

Note: the alternative is to use Ansible as a power tool and not as a platform, in which there is still great value, but it’s then just automating CLI commands faster than you.

Realize there is a difference using something as a platform or a tool.

Tabling Operational State

This post didn’t cover operational state as that’s a bit more complex to enforce and then you get into event-driven and auto-remediation systems, but in all of these tools and platforms, you have the ability to collect any information from the device (config or operational state), and then based on that data, work through your logic and intent-based deployment.

Let’s Meet at AnsibleFest SF 2017

A few of us from the NTC team are at AnsibleFest in SF tomorrow, September 7. If you’re interested in hearing more about our model-driven intent-based network automation services and solutions with Ansible, feel free to stop by our booth!

Network Automation with Python & Ansible Training

In the spirit of AnsibleFest, NTC is offering 50% off any of our public training courses until 9/15. Just email info@networktocode asking for your promo code.

Happy Automating!

-Jason (@jedelman8)

Using the Ansible ios_config Module

Wed, 03 May 2017 00:00:00 +0000

I get asked often on how to perform specific network automation tasks with Ansible. There were a few questions recently pertaining to the ios_config module within Ansible core, so I decided to record a video to show different options you have when using it to deploy global configuration commands on IOS devices.

Here is a summary of the four (4) options covered:

Embed commands in your playbook and reference them using the commands (or lines) parameter.
Use the src parameter and reference a configuration file with one or more commands in it.
Use the src parameter and reference a Jinja2 template such that it inserts variables into the template, creating a list of commands, and deploys them to a device.
Use two tasks. In Task 1, use the template module and reference a Jinja2 template to auto-generate a configuration file. In Task 2, use the ios_config module and reference the config file built in Task 1 to deploy the commands from the file. This is often used instead of option #3 since it allows you to store/view the config file before deploying fully de-coupling the build and deploy processes.

The video does assume some existing knowledge on using Ansible. The goal was to highlight different options available to you when using the ios_config module specifically for deploying global configuration commands.

Note: The video does NOT cover sending commands in any other configuration mode such as interface configuration mode or router configuration mode. I’d recommend simply starting with global configuration commands and expand from there exploring how to further use the module issuing the command ansible-doc ios_config on your Ansible machine.

-Jason

@jedelman8

Self Driving Cars and Network Automation

Sat, 22 Apr 2017 00:00:00 +0000

Last year at Interop, there was a great mini-conference dedicated to the DevOps for Networking community. In that session, I kicked off the day with a general view of where the industry was with respect to the intersection of DevOps and networking with a focus on network automation.

One of the analogies I made was comparing network automation to self-driving cars posing the question, “Are they real?”…“Are they real for us (the consumer)?”

No, they are not, but I continued to make the analogy. Is complete network automation real today? While, the answer is yes, it’s not really a reality for most…yet.

So, what’s the connection between self-driving cars and network automation?

Start small and expand. Pick a problem, solve it, and integrate it.

Self-Driving Cars are Coming

While self-driving cars aren’t a reality for us to buy and purchase today, intelligent cars are– these are cars that have high-value services and features enhancing the way we drive, our safety, and much more generally, the way we in which we consume the streets and infrastructure around us.

These include automated features like self-parking, back-up cameras, automated beeping as you back-up, automatic-brakes, GPS, and computer systems that give you a plethora of visibility about the inner workings of the car (complex system). So yes, you better believe it. The self-driving car is coming– one feature, chip, feedback loop, and computer program at a time.

Network Automation is Coming

All of the pieces are actually here already!

Achieving network automation is hard, very hard. But it’s actually not if you break it down into achievable milestones. Maybe it’s something like the following:

Generate automated reports and documentation for Campus Access layer and expand networks from there. You don’t need to start with every network type.
Create proper configuration templates for each new device type or for each new service being deployed. Again, you don’t need to start with every device or network type.
Create a compliance check for credentials in one part of the network and gradually expand compliance checks and networks checked against.
Standing up a new site? Look into zero touch provisioning.
Having a problem with bad switches in a stack or linecards in a chassis? Perfect problem to solve.

As use-cases like this are being solved week after week, you’ll have short-term wins proving the value of automation, but also be moving towards the bigger picture of deploying services, integrating into 3rd party platforms, creating relevant feedback loops, offering APIs to the business, and much more.

The biggest takeaway is to make sure you build a plan, know it’ll take time to achieve, and break it up into achievable milestones. It’ll be a win for everyone involved.

-Jason

@jedelman8

Automate When You Can, Program When You Must

Sun, 02 Apr 2017 00:00:00 +0000

I’ve had a general thought I’ve wanted to write about for quite some time now and after just seeing Matt Oswalt’s latest post Learn Programming or Perish(?), the thought finally makes it to paper so to speak in this post. The thought I want to expand on is something I say quite a bit as I talk about network automation. It is automate when you can, program when you must.

After reading Matt’s post, I’ll re-phrase to automate when you can, script when you must specifically targeting network engineers (note: even though this is what I mean, the word script makes it a bit clearer). This is a twist on the network industry’s old saying of switch when you can, route when you must.

Automate When You Can

Automate when you can is saying use some form of tooling when you can to do network automation. Why re-invent the wheel when you don’t have to? I’m a little biased these days, but this means using some form of extensible tooling, preferably open source, that does automation. Some of my favorites right now are Red Hat’s Ansible and Extreme’s StackStorm. However, this could just as well be other open source tools such as Puppet, Chef, or SaltStack, or even commercial solutions from vendors like Cisco, VMware, Arista, and insert favorite vendor. Ideally, you (your network team) are automating 80% of the time.

Program When You Must

Program when you must, now re-phrased as script when you must is saying, when the tool cannot do what you need it to do, or when the tool becomes too complex to perform a certain operation, script it, and when you script it, hopefully you’re extending the tool of your choice. In Ansible, scripting means you’re writing a custom module or enhancing an existing one or writing a custom Jinja2 filter. This is NOT hard-core programming that requires years of professional training as a software engineer. You can script (yes, it’s still programming) amazing things in 30-40 lines of code (maybe it’s a little more or less). We aren’t talking about writing 1000s of lines of code though. Ideally, you (your network team) are scripting/programming 20% of the time.

Note: I used the word programming in that last sentence because if you do have full-time scripters on the team, they should be pushing themselves to get to the next level.

The 80/20 Rule for Network Automation

The net result comes back to the 80/20 rule when looking at a team of current network engineers. If you’re on a team of 10 people, 8 of them should be using using a tool day to day. If it’s ~7, that’s more than okay. Learning a tool to manage production environments is a challenge in itself, forget about everyone learning to write production code. Of these 7-8 people, there will likely be a few that script more than others for sure- that’s the reality.

Of the remaining 2-3 people though, they are scripting more frequently than the others. These are the few that may straddle scripting and programming. That said, the more the scripters script, the more they realize they need to write better-quality code. These folks realize that and may make that gradual transition to worry about things like code review and automated tests. This could mean they evolve more into more of a software engineer in the long run. However, that DOES NOT happen over night.

Becoming an Expert Over Night?

Did anyone with advanced network certifications get them over night? Heck no. It’s a gradual process. I often equate it to the CCNA, CCNP, and CCIE. Does one learn BGP as a CCNA? Sure, I bet if you ask someone who just passed the CCNA about BGP, they can tell you all they know about BGP and think that’s all they need to know. Then they get to the CCNP routing book and realize there is so much more to learn; the process repeats again for the CCIE. Oh, and this happens yet again for managing a production environment running BGP.

So you’re a network engineer without any automation/programming knowledge? That’s awesome. Embrace it and learn as much as possible, but do not shoot for the CCIE of programming tomorrow; go for the NA - learn to write small scripts, understand data types, and data formats!

Network Automation Takeaways

First and foremost, realize there is no right or wrong path here, but let’s summarize this a bit for some key takeaways:

As a network engineer…

If you’re just getting started with automation, experiment with a few tools, and then pick one. Then stick with it.
No matter the tool, you need to understand data types. This is not programming. Seeing a curly brace or two is okay, but still not programming.
You should understand data formats like JSON regardless of your tool of choice.
You should understand how to script to either a) get something done your tool can’t do well or b) troubleshoot (diving into a stacktrace) c) extend your tool of choice such that a new task that your tool couldn’t do is now easily integrated into workflows your tool does do. The value here is now others on your team can use your integration/plug-in without programming.

Final Thought

Try and de-couple personal learning objectives with and when managing production environments. It doesn’t make much sense to build a FULL tool from scratch (excluding APIs and/or front-ends) unless you’re dedicating several full-time software engineers, and even then, is that the best approach? If you’re thinking along those lines, where do existing [open source] tools fall short for you?

Happy Automating!

-Jason

@jedelman8

Automating Cisco Nexus Switches with Ansible

Mon, 05 Dec 2016 00:00:00 +0000

For the past several years, the open source [network] community has been rallying around Ansible as a platform for network automation. Just over a year ago, Ansible recognized the importance of embracing the network community and since then, has made significant additions to offer network automation out of the box. In this post, we’ll look at two distinct models you can use when automating network devices with Ansible, specifically focusing on Cisco Nexus switches. I’ll refer to these models as CLI-Driven and Abstraction-Driven Automation.

Note: We’ll see in later posts how we can use these models and a third model to accomplish intent-driven automation as well.

For this post, we’ve chosen to highlight Nexus as there are more Nexus Ansible modules than any other network operating system as of Ansible 2.2 making it extremely easy to highlight these two models.

CLI-Driven Automation

The first way to manage network devices with Ansible is to use the Ansible modules that are supported by a diverse number of operating systems including NX-OS, EOS, Junos, IOS, IOS-XR, and many more. These modules can be considered the lowest common denominator as they work the same way across operating systems requiring you to define the commands that you want to send to network devices.

We’ll look at an example of this model managing VLANs on Nexus switches.

The first thing we are going to do is define an appropriate data model for VLANs. The more complex the feature (and if you want to consider multiple vendors), the more complex and advanced a data model can be. In this case, we’ll simply create a list of key-value pairs and represent each VLAN by having a VLAN ID and VLAN NAME.

The data model we are going to use for VLANs is the following:

---

vlans:
  - id: 10
    name: web_servers
  - id: 20
    name: app_servers
  - id: 30
    name: db_servers

Once we have our data (variables), we’ll use a Jinja2 template that’ll create the required configurations that we’ll ultimately deploy to each device.

Below is the Jinaj2 template we’ll use to create our configurations. In our template, we are requiring a VLAN name be present for each VLAN.

{% for vlan in vlans %}
vlan {{ vlan.id }}
  name {{ vlan.name }}
{% endfor %}

Once the configuration commands are built from the template, we need to deploy (ensure the required commands exist) them to the device. This is where we can use the nxos_config Ansible module.

The *_config modules exist for a large number of network operating systems, which is why we’re calling them the lowest common denominator.

We can create the required configurations and do the deployment with two Ansible tasks:

    - name: BUILD CONFIGS
      template:
        src: vlans.j2
        dest: configs/vlans.cfg

    - name: ENSURE VLANS EXIST
      nxos_config:
        src: configs/vlans.cfg
        provider: "{{ nxos_provider }}"

You could use the commands parameter in the nxos_config task rather than using a separate template task; however, it’s a little cleaner using templates. Yes, this is subjective.

You could also eliminate the task that uses the template module all together and just do source: vlans.j2, but adding the secondary step offers the flexibility of validating the build step (command generation) before a deployment.

In this example, we are going to deploy the same VLANs to all devices.

If we run a playbook that has these tasks, it’ll ensure all VLANs in the variables file get deployed on the Nexus switches.

But, what if you need to subsequently remove VLANs?

In this current model, it’s up to you to either create a second template that uses no vlan <id> or make a more complex template and based on some other variable, render the commands to either configure or un-configure VLANs.

Abstraction-Driven Automation

Using the nxos_config module is simply one way you can manage NX-OS devices with Ansible. While it offers flexibility, you still need to develop templates or commands for everything you want to configure or un-configure on a given device. For some tasks, this is quite easy; for others, it could get tedious.

Another approach is to use Ansible modules that offer abstractions, eliminate the need to use commands or templates, while also making it quite easy to ensure a given configuration does NOT exist.

We aren’t talking about high level abstractions here such as services or tenants, but still network-centric objects and abstractions such as VLANs without the need for you to define the commands that are needed for configuring a given resource or object.

You can in fact stitch together multiple network-centric objects to create a higher level abstraction such as tenants quite easily with Ansible.

Let’s take a look at the same VLANs example from above, but instead of using nxos_config, we are going to use nxos_vlan.

This module only manages VLANs globally on Nexus switches.

Using this model, the single task we need to ensure the VLANs exist on each switch is the following:

    - name: ENSURE VLANS EXIST
      nxos_vlan:
        vlan_id: "{{ item.id }}"
        name: "{{ item.name }}"
        state: present
        provider: "{{ nxos_provider }}"
      with_items: "{{ vlans }}"

And if we need to remove the same VLANs:

    - name: ENSURE VLANS DO NOT EXIST
      nxos_vlan:
        vlan_id: "{{ item.id }}"
        name: "{{ item.name }}"
        state: absent
        provider: "{{ nxos_provider }}"
      with_items: "{{ vlans }}"

The only change required to ensure the VLAN does not exist is to change the state parameter to absent.

If you take a look at the Ansible docs for network modules you can see how many Nexus modules exist now in Ansible core. For those new to Ansible, being in Ansible Core means you get them when you install Ansible.

Here is a list of all the Nexus modules that you’ll also find at the Ansible docs link above.

nxos_aaa_server_host.py         nxos_hsrp.py            nxos_pim.py             nxos_udld_interface.py
nxos_aaa_server.py              nxos_igmp_interface.py  nxos_pim_rp_address.py  nxos_udld.py
nxos_acl_interface.py           nxos_igmp.py            nxos_ping.py            nxos_vlan.py
nxos_acl.py                     nxos_igmp_snooping.py   nxos_portchannel.py     nxos_vpc_interface.py
nxos_bgp_af.py                  nxos_install_os.py      nxos_reboot.py          nxos_vpc.py
nxos_bgp_neighbor_af.py         nxos_interface_ospf.py  nxos_rollback.py        nxos_vrf_af.py
nxos_bgp_neighbor.py            nxos_interface.py       nxos_smu.py             nxos_vrf_interface.py
nxos_bgp.py                     nxos_ip_interface.py    nxos_snapshot.py        nxos_vrf.py
nxos_command.py                 nxos_mtu.py             nxos_snmp_community.py  nxos_vrrp.py
nxos_config.py                  nxos_ntp_auth.py        nxos_snmp_contact.py    nxos_vtp_domain.py
nxos_evpn_global.py             nxos_ntp_options.py     nxos_snmp_host.py       nxos_vtp_password.py
nxos_evpn_vni.py                nxos_ntp.py             nxos_snmp_location.py   nxos_vtp_version.py
nxos_facts.py                   nxos_nxapi.py           nxos_snmp_traps.py      nxos_vxlan_vtep.py
nxos_feature.py                 nxos_ospf.py            nxos_snmp_user.py       nxos_vxlan_vtep_vni.py
nxos_file_copy.py               nxos_ospf_vrf.py        nxos_static_route.py    nxos_gir_profile_management.py
nxos_overlay_global.py          nxos_switchport.py      nxos_gir.py             nxos_pim_interface.py

Beyond Configuration Management

Notice that not only are there a significant amount of modules for configuration management, but there are also quite a few for common operational tasks such as copying files to devices, rebooting devices, testing reachability (using ping), upgrading devices, and rolling back configurations (using the NX-OS checkpoint feature).

Let’s look at one of these. We’ll walk through how you can use multiple tasks in a given playbook to upgrade the operating system on Nexus switches.

Upgrading NX-OS Devices

While there is one module called nxos_install_os and that module does perform the actual upgrade, we’ll walk through the complete process starting with checking to see the current version of software on the Nexus switches and finishing with a task to assert the upgrade completed successfully.

The first three tasks we are going to have in our playbook are the following:

Get current facts of each device so we can print the current version of NX-OS to the terminal during playbook execution
Print (debug) the current version of NX-OS to the terminal
Ensure the SCP server is enabled on each device so we can copy files

Here is what these tasks look like:

- name: GATHER FACTS TO RECORD CURRENT VERSION OF NX-OS
  nxos_facts:
    provider: "{{ nxos_provider }}"

- name: CURRENT OS VERSION
  debug: var=os

- name: ENSURE SCP SERVER IS ENABLED
  nxos_feature:
    feature: scp-server
    state: enabled
    provider: "{{ nxos_provider }}"

Note: nxos_provider is a variable that contains common parameters for the nxos_* modules. In this particular case, it’s a dictionary that has the following keys: username, password, transport, and host.

After we know that scp is enabled, we can confidently copy the required file(s) to each device. Our example requires the OS image file exists on the Ansible control host.

- name: ENSURE FILE EXISTS ON DEVICE
  nxos_file_copy:
    local_file: "{{ image_path }}/{{ nxos_version }}"
    provider: "{{ nxos_provider }}"

In addition to nxos_provider, we used two other variables to define the local_file parameter. They are defined as the following:

nxos_version: nxos.7.0.3.I2.2d.bin
image_path: ../os-images/cisco/nxos
nxos_version_str: 7.0(3)I2(2d)

But, we also have a third variable that is the string representation of the new version (nxos_version_str), which we’ll use in an upcoming task.

Based on your deployment, think about using the delegate_to directive when using nxos_file_copy so you can copy files from another host in the data center, or some location that is closer to your devices than the Ansible control host.

Once we copy the image file to each switch, we’re ready to perform the final step: the upgrade. It sounds like a single task, but in reality, it’s a bit more than that. We’ll summarize these steps as the following:

Start the Upgrade (which initiates the reboot)
Ensure the device starts rebooting
Ensure the device comes back online
Gather facts again to collect new OS version
Print (debug) the OS to the terminal
Assert and Verify the expected version is running on the device

If we translate these steps into Ansible tasks, we end up with the following:

- block:
    - name: ENSURE OS IS CORRECT
      nxos_install_os:
        system_image_file: "{{ nxos_version }}"
        provider: "{{ nxos_provider }}"
  rescue:
    - name: WAITING FOR DEVICE TO PERFORM ALL UPGRADE CHECKS AND STARTS REBOOT
      wait_for:
        port: 22
        state: stopped
        timeout: 300
        delay: 60
        host: "{{ inventory_hostname }}"

    - name: REBOOT IN PROGRESS - WAITING FOR DEVICE TO COME BACK ONLINE
      wait_for:
        port: 22
        state: started
        timeout: 300
        delay: 60
        host: "{{ inventory_hostname }}"

  always:

    - name: GATHER FACTS TO RECORD CURRENT VERSION OF NX-OS
      nxos_facts:
        provider: "{{ nxos_provider }}"

    - name: CURRENT OS VERSION
      debug: var=os

    - name: VERIFY CURRENT VERSION IS EXPECTED VERSION
      assert:
        that:
          - "'{{ os }}' == '{{ nxos_version_str }}'"

As you read through the preceding tasks, take note of the feature being used within the playbook called Ansible blocks. This is a critical feature to be aware of to account for errors when running a playbook and conditionally execute a group of tasks when an error occurs. Because Ansible doesn’t yet allow for a device to lose connectivity within a task, we need to assume a failure is going to occur. Basically, whenever you use nxos_install_os, the task will fail when the switch reboots (for now). Within a block, when a failure condition occurs, the tasks within the rescue block start executing.

The rescue tasks shown above ensure the device starts rebooting within 5 minutes and ensure the device comes back online within 5 minutes. Note that these tests were executed against Nexus 9396s and 9372s - if you are using 7K or 9K chassis devices, you may want to increase the timeout values.

Finally, the last three tasks always get executed and verify the upgrade was successful.

In upcoming posts, we’ll take a look at a few other use cases and show some live demos. Over time, we’ll get more complete examples on GitHub too.

Thanks,

Jason

@jedelman8

Network Automation Survey

Tue, 15 Nov 2016 00:00:00 +0000

Network Automation is just getting started and it’s odd to say that as IT professionals from other technology disciplines are always surprised to see how much manual interaction there still is between the networking engineering/operations teams and the actual devices they manage.

I’ll never forget the days in 2012-2013 performing my best Google searches to find ways to program or to automate network routers and switches. I didn’t care what programming language was being used or even what tool, but I found nothing. Every time I heard someone say they were using a network script, I’d say “email it to me, that sounds interesting.” Unfortunately, 100% of the time, it ended up being a notepad or a Word file, not a script. What a bummer.

I like to think I’m a solid Googler too. It was amazing though - there was near nothing. Do a search today on network automation or network programming and you’d be amazed on what you’ll find - we’ve come a long way in the past 36 months with respect to network automation, but I truly believe we’re still in the 2nd or 3rd inning (if we were playing a game of baseball, of course).

At this point, the industry needs feedback. We need to primarily see what our peers are doing and maybe more importantly ensure vendors are aware for the need of better tools, libraries, and APIs. We need a collective voice.

In order to help make that happen, a public and anonymous Network Automation Survey was created that was initiated by several folks on the Network to Code Community Slack team. I played a very small part in helping create it and now just doing a small part to make more people aware of it…

So, please, do your part. Take the Survey!

Until the results are reviewed and cleaned up, they are even available in raw format - full transparency along the way.

Happy Automating!

Thanks,

Jason

@jedelman8

NETCONF, RESTCONF on IOS XE

Fri, 14 Oct 2016 00:00:00 +0000

There is a lot of buzz around network APIs such as NETCONF and RESTCONF. Here we’ll take a quick a look at these APIs on Cisco IOS XE. On the surface, it seems Cisco IOS XE is the first network device platform that supports NETCONF and RESTCONF both driven from YANG models.

Technically, RESTCONF isn’t officially supported or even seen in the CLI to enable it, but more on that later.

YANG

When APIs are model driven, the model is the source of truth. If done right, all API documentation and configuration validation could occur using tooling built directly from the models. YANG is the leading data modeling language and as such, all API requests using RESTCONF/NETCONF are directly modeled from the YANG models IOS XE supports. For this post, we’ll just say the models can easily be represented as JSON k/v pairs or XML documents. We’ll cover YANG in more detail in a future post.

NETCONF

You can directly access the NETCONF server on IOS XE using the following SSH command (or equivalent from a SSH client).

The NETCONF server is a SSH sub-system.

$ ssh -p 830 ntc@csr1kv -s netconf

The full response from the IOS XE NETCONF server can be seen below.

When you get the response from the device, you need to respond with client capabilities, and then can you can enter NETCONF request objects into that terminal session directly communicating to the device using NETCONF — all without writing any code. This is a good way to ensure your XML objects are built properly before testing them out in any type of script.

So first, we can paste this object into the terminal:

<?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>]]>]]>

Now the client and the server have exchanged capabilities and the client is now able to send NETCONF request objects.

We are going to query the device for the IP configuration on the GigabitEthernet2 interface. We’ll do this by sending the following object to the device (still in the same terminal session from above).

This is not a typical interactive session, so don’t be alarmed if you aren’t getting feedback from the device before pasting in this object.

<?xml version="1.0"?>
<nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <nc:get>
        <nc:filter type="subtree">
            <native xmlns="http://cisco.com/ns/yang/ned/ios">
             <interface>
              <GigabitEthernet>
               <name>2</name>
                 <ip></ip>
              </GigabitEthernet>
             </interface>
            </native>
        </nc:filter>
    </nc:get>
</nc:rpc>
]]>]]>

This is the response we get back:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"><data><native xmlns="http://cisco.com/ns/yang/ned/ios"><interface><GigabitEthernet><name>2</name><ip><address><primary><address>10.1.1.1</address><mask>255.255.255.0</mask></primary></address></ip></GigabitEthernet></interface></native></data></rpc-reply>]]>]]>

And if we clean up the response:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
   <data>
      <native xmlns="http://cisco.com/ns/yang/ned/ios">
         <interface>
            <GigabitEthernet>
               <name>2</name>
               <ip>
                  <address>
                     <primary>
                        <address>10.1.1.1</address>
                        <mask>255.255.255.0</mask>
                     </primary>
                  </address>
               </ip>
            </GigabitEthernet>
         </interface>
      </native>
   </data>
</rpc-reply>]]>]]>

We can see the structured XML response that makes it extremely easy to programmatically get data out of devices (as well as configure them). Say good bye to manual parsing forever.

RESTCONF

The RESTCONF API on IOS XE is built from the same models NETCONF is using. You also have your choice if you want to use XML or JSON data encoding when using RESTCONF.

Here we’ll use JSON.

The following URL using an HTTP GET accomplishes the same thing as shown in the previous NETCONF GET operation.

HTTP GET
http://csr1kv/restconf/api/config/native/interface/GigabitEthernet/2/ip/address

The JSON response returned back to us is this:

{
  "ned:address": {
    "primary": {
      "address": "10.1.1.1",
      "mask": "255.255.255.0"
    }
  }
}

This maps nicely back into a Python dictionary that we can easily parse and work with.

Closing

RESTCONF and NETCONF are both model driven APIs on IOS XE
RESTCONF is NOT the same REST API that has been on the CSR1KV or IOS XE - it’s a brand new API
You’ll need 16.3.1 to test this - the testing for this post used the CSR1KV
The RESTCONF/NETCONF APIs support 100s of YANG models - all testing here was using the native Cisco IOS model. This is a personal favorite of mine as the full running configuration is modeled in JSON/XML.

RESTCONF, as good as it seems, is not yet officially supported by TAC and it’s actually hidden in the CLI. Why? Who knows? But if you’re interested in it, make sure Cisco is aware.

As you can see, there is no RESTCONF command:

csr1(config)#rest?
% Unrecognized command
csr1(config)#rest

But, watch this:

csr1(config)#
csr1(config)#restconf
csr1(config)#
csr1(config)#do show run | inc restconf
restconf
csr1(config)#

And it then works like a charm.

Want to test NETCONF/RESTCONF?

Check the Network to Code Labs.

NETCONF Server Capabilities

RESPONSE AS DESCRIBED ABOVE

<?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>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
<capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
<capability>http://tail-f.com/ns/netconf/actions/1.0</capability>
<capability>http://tail-f.com/ns/netconf/extensions</capability>
<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=report-all</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?revision=2011-06-01&amp;module=ietf-netconf-with-defaults</capability>
<capability>http://cisco.com/ns/example/enable?module=enable</capability>
<capability>http://cisco.com/ns/yang/ned/ios?module=ned&amp;revision=2016-07-01</capability>
<capability>http://cisco.com/ns/yang/ned/ios/asr1k?module=ned-asr1k&amp;revision=2016-04-07</capability>
<capability>http://cisco.com/yang/cisco-ia?module=cisco-ia&amp;revision=2016-05-20</capability>
<capability>http://cisco.com/yang/cisco-odm?module=cisco-odm&amp;revision=2016-05-16</capability>
<capability>http://cisco.com/yang/cisco-self-mgmt?module=cisco-self-mgmt&amp;revision=2016-05-14</capability>
<capability>http://tail-f.com/ns/aaa/1.1?module=tailf-aaa&amp;revision=2015-06-16</capability>
<capability>http://tail-f.com/ns/mibs/IPV6-TC/199812010000Z?module=IPV6-TC&amp;revision=1998-12-01</capability>
<capability>http://tail-f.com/ns/mibs/SNMP-COMMUNITY-MIB/200308060000Z?module=SNMP-COMMUNITY-MIB&amp;revision=2003-08-06</capability>
<capability>http://tail-f.com/ns/mibs/SNMP-FRAMEWORK-MIB/200210140000Z?module=SNMP-FRAMEWORK-MIB&amp;revision=2002-10-14</capability>
<capability>http://tail-f.com/ns/mibs/SNMP-MPD-MIB/200210140000Z?module=SNMP-MPD-MIB&amp;revision=2002-10-14</capability>
<capability>http://tail-f.com/ns/mibs/SNMP-NOTIFICATION-MIB/200210140000Z?module=SNMP-NOTIFICATION-MIB&amp;revision=2002-10-14</capability>
<capability>http://tail-f.com/ns/mibs/SNMP-TARGET-MIB/200210140000Z?module=SNMP-TARGET-MIB&amp;revision=2002-10-14</capability>
<capability>http://tail-f.com/ns/mibs/SNMP-USER-BASED-SM-MIB/200210160000Z?module=SNMP-USER-BASED-SM-MIB&amp;revision=2002-10-16</capability>
<capability>http://tail-f.com/ns/mibs/SNMP-VIEW-BASED-ACM-MIB/200210160000Z?module=SNMP-VIEW-BASED-ACM-MIB&amp;revision=2002-10-16</capability>
<capability>http://tail-f.com/ns/mibs/SNMPv2-MIB/200210160000Z?module=SNMPv2-MIB&amp;revision=2002-10-16</capability>
<capability>http://tail-f.com/ns/mibs/SNMPv2-SMI/1.0?module=SNMPv2-SMI</capability>
<capability>http://tail-f.com/ns/mibs/SNMPv2-TC/1.0?module=SNMPv2-TC</capability>
<capability>http://tail-f.com/ns/mibs/TRANSPORT-ADDRESS-MIB/200211010000Z?module=TRANSPORT-ADDRESS-MIB&amp;revision=2002-11-01</capability>
<capability>http://tail-f.com/ns/webui?module=tailf-webui&amp;revision=2013-03-07</capability>
<capability>http://tail-f.com/yang/acm?module=tailf-acm&amp;revision=2013-03-07</capability>
<capability>http://tail-f.com/yang/common-monitoring?module=tailf-common-monitoring&amp;revision=2013-06-14</capability>
<capability>http://tail-f.com/yang/confd-monitoring?module=tailf-confd-monitoring&amp;revision=2013-06-14</capability>
<capability>http://tail-f.com/yang/netconf-monitoring?module=tailf-netconf-monitoring&amp;revision=2014-11-13</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-acl-oper?module=cisco-acl-oper&amp;revision=2016-03-30</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-bfd-state?module=cisco-bfd-state&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-bgp-state?module=cisco-bgp-state&amp;revision=2015-10-16</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-bridge-common?module=cisco-bridge-common&amp;revision=2014-09-25&amp;features=configurable-bd-mac-limit-notif,configurable-bd-mac-limit-max,configurable-bd-mac-limit-actions,configurable-bd-mac-aging-types,configurable-bd-flooding-control</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-bridge-domain?module=cisco-bridge-domain&amp;revision=2014-12-01&amp;features=parameterized-bridge-domains,configurable-bd-storm-control,configurable-bd-static-mac,configurable-bd-snooping-profiles,configurable-bd-sh-group-number,configurable-bd-mtu,configurable-bd-member-features,configurable-bd-mac-secure,configurable-bd-mac-features,configurable-bd-mac-event-action,configurable-bd-ipsg,configurable-bd-groups,configurable-bd-flooding-mode,configurable-bd-flooding,configurable-bd-dai,clear-bridge-domain</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-cfm-stats?module=cisco-cfm-stats&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-cfm-stats-dev?module=cisco-cfm-stats-dev&amp;revision=2015-05-27</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-checkpoint-archive?module=cisco-checkpoint-archive&amp;revision=2015-05-20</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-efp-stats?module=cisco-efp-stats&amp;revision=2015-07-07</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-environment?module=cisco-environment&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-ethernet?module=cisco-ethernet&amp;revision=2016-05-10</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-flow-monitor?module=cisco-flow-monitor&amp;revision=2015-10-26</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-ip-sla-stats?module=cisco-ip-sla-stats&amp;revision=2015-05-29</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-ip-sla-stats-dev?module=cisco-ip-sla-stats-dev&amp;revision=2015-06-30</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-lldp-state?module=cisco-lldp-state&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-memory-stats?module=cisco-memory-stats&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-mpls-fwd?module=cisco-mpls-fwd&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-platform-software?module=cisco-platform-software&amp;revision=2015-07-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-process-cpu?module=cisco-process-cpu&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-process-memory?module=cisco-process-memory&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-qos-action-marking-cfg?module=cisco-qos-action-marking-cfg&amp;revision=2015-05-09&amp;features=set-wlan-user-priority-support,set-vlan-inner-support,set-srp-priority-support,set-qos-grp-support,set-prec-tunnel-support,set-prec-support,set-mpls-exp-top-support,set-mpls-exp-imp-support,set-fr-fecn-becn-support,set-fr-de-support,set-dscp-tunnel-support,set-discard-class-support,set-dei-support,set-dei-imp-support,set-cos-support,set-cos-inner-suppport,set-atm-clp-support</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-qos-action-oper?module=cisco-qos-action-oper&amp;revision=2015-05-09&amp;features=queue-peak-size-stats-support,priority-bandwidth-exceed-drops-support,marking-stats-support,drop-pkts-no-buffer-stats-support,drop-pkts-flow-stats-support,aggregate-priority-stats-support</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-qos-action-qlimit-cfg?module=cisco-qos-action-qlimit-cfg&amp;revision=2015-05-09&amp;features=qos-grp-based-queuing-support,mpls-exp-based-queuing-support,disc-class-based-queuing-support</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-qos-common?module=cisco-qos-common&amp;revision=2015-05-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-routing-ext?module=cisco-routing-ext&amp;revision=2016-07-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-storm-control?module=cisco-storm-control&amp;revision=2014-09-25&amp;features=configurable-storm-control-actions</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-virtual-service?module=cisco-virtual-service&amp;revision=2016-04-19</capability>
<capability>urn:cisco:params:xml:ns:yang:govern?module=govern&amp;revision=2014-07-16</capability>
<capability>urn:cisco:params:xml:ns:yang:pim?module=pim&amp;revision=2014-06-27&amp;features=bsr,auto-rp</capability>
<capability>urn:cisco:params:xml:ns:yang:pw?module=cisco-pw&amp;revision=2014-12-01&amp;features=static-label-direct-config,pw-vccv,pw-tag-impose-vlan-id,pw-status-config,pw-static-oam-config,pw-short-config,pw-sequencing,pw-preferred-path,pw-port-profiles,pw-oam-refresh-config,pw-mac-withdraw-config,pw-load-balancing,pw-ipv6-source,pw-interface,pw-grouping-config,pw-class-tag-rewrite,pw-class-switchover-delay,pw-class-status,pw-class-source-ip,pw-class-flow-setting,preferred-path-peer,predictive-redundancy-config,flow-label-tlv-code17,flow-label-static-config</capability>
<capability>urn:cisco:params:xml:ns:yang:table-map?module=cisco-table-map&amp;revision=2015-05-19&amp;features=table-map-template-support</capability>
<capability>urn:ietf:params:xml:ns:yang:c3pl-types?module=policy-types&amp;revision=2013-10-07&amp;features=protocol-name-support,match-wlan-user-priority-support,match-vpls-support,match-vlan-support,match-vlan-inner-support,match-src-mac-support,match-security-group-support,match-qos-group-support,match-prec-support,match-packet-length-support,match-mpls-exp-top-support,match-mpls-exp-imp-support,match-metadata-support,match-ipv6-acl-support,match-ipv6-acl-name-support,match-ipv4-acl-support,match-ipv4-acl-name-support,match-ip-rtp-support,match-input-interface-support,match-fr-dlci-support,match-fr-de-support,match-flow-record-support,match-flow-ip-support,match-dst-mac-support,match-discard-class-support,match-dei-support,match-dei-inner-support,match-cos-support,match-cos-inner-support,match-class-map-support,match-atm-vci-support,match-atm-clp-support,match-application-support</capability>
<capability>urn:ietf:params:xml:ns:yang:cisco-ospf?module=cisco-ospf&amp;revision=2016-03-30&amp;features=graceful-shutdown,flood-reduction,database-filter</capability>
<capability>urn:ietf:params:xml:ns:yang:cisco-policy?module=cisco-policy&amp;revision=2016-03-30</capability>
<capability>urn:ietf:params:xml:ns:yang:cisco-policy-filters?module=cisco-policy-filters&amp;revision=2016-03-30</capability>
<capability>urn:ietf:params:xml:ns:yang:cisco-policy-target?module=cisco-policy-target&amp;revision=2016-03-30</capability>
<capability>urn:ietf:params:xml:ns:yang:common-mpls-static?module=common-mpls-static&amp;revision=2015-07-22&amp;deviations=common-mpls-static-devs</capability>
<capability>urn:ietf:params:xml:ns:yang:common-mpls-types?module=common-mpls-types&amp;revision=2015-05-28</capability>
<capability>urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&amp;revision=2014-04-04&amp;features=crypt-hash-sha-512,crypt-hash-sha-256,crypt-hash-md5</capability>
<capability>urn:ietf:params:xml:ns:yang:iana-if-type?module=iana-if-type&amp;revision=2014-05-08</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-diffserv-action?module=ietf-diffserv-action&amp;revision=2015-04-07&amp;features=priority-rate-burst-support,hierarchial-policy-support,aqm-red-support</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-diffserv-classifier?module=ietf-diffserv-classifier&amp;revision=2015-04-07&amp;features=policy-inline-classifier-config</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-diffserv-policy?module=ietf-diffserv-policy&amp;revision=2015-04-07&amp;features=policy-template-support,hierarchial-policy-support</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-diffserv-target?module=ietf-diffserv-target&amp;revision=2015-04-07&amp;features=target-inline-policy-config</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&amp;revision=2013-07-15</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-interfaces?module=ietf-interfaces&amp;revision=2014-05-08&amp;features=pre-provisioning,if-mib,arbitrary-names&amp;deviations=ietf-ip-devs</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-interfaces-ext?module=ietf-interfaces-ext</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-ip?module=ietf-ip&amp;revision=2014-01-08&amp;features=ipv6-privacy-autoconf,ipv4-non-contiguous-netmasks</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing?module=ietf-ipv4-unicast-routing&amp;revision=2015-05-25</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing?module=ietf-ipv6-unicast-routing&amp;revision=2015-05-25</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-key-chain?module=ietf-key-chain&amp;revision=2015-02-24&amp;features=independent-send-accept-lifetime,hex-key-string,accept-tolerance</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&amp;revision=2012-02-22</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&amp;revision=2010-10-04</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&amp;revision=2012-02-06</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-ospf?module=ietf-ospf&amp;revision=2015-03-09&amp;features=ttl-security,te-rid,router-id,remote-lfa,prefix-suppression,ospfv3-authentication-ipsec,nsr,node-flag,multi-topology,multi-area-adj,mtu-ignore,max-lsa,max-ecmp,lls,lfa,ldp-igp-sync,ldp-igp-autoconfig,interface-inheritance,instance-inheritance,graceful-restart,fast-reroute,demand-circuit,bfd,auto-cost,area-inheritance,admin-control&amp;deviations=ietf-ospf-devs</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-routing?module=ietf-routing&amp;revision=2015-05-25&amp;features=router-id,multiple-ribs&amp;deviations=ietf-ipv4-unicast-routing-devs,ietf-ipv6-unicast-routing-devs,ietf-ospf-devs,ietf-routing-devs</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-yang-smiv2?module=ietf-yang-smiv2&amp;revision=2012-06-22</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&amp;revision=2013-07-15</capability>
<capability>urn:ietf:params:xml:ns:yang:nvo?module=nvo&amp;revision=2015-06-02&amp;deviations=nvo-devs</capability>
<capability>urn:ietf:params:xml:ns:yang:policy-attr?module=policy-attr&amp;revision=2015-04-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ATM-FORUM-TC-MIB?module=ATM-FORUM-TC-MIB</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ATM-MIB?module=ATM-MIB&amp;revision=1998-10-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ATM-TC-MIB?module=ATM-TC-MIB&amp;revision=1998-10-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:BGP4-MIB?module=BGP4-MIB&amp;revision=1994-05-05</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:BRIDGE-MIB?module=BRIDGE-MIB&amp;revision=2005-09-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-AAA-SERVER-MIB?module=CISCO-AAA-SERVER-MIB&amp;revision=2003-11-17</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-AAA-SESSION-MIB?module=CISCO-AAA-SESSION-MIB&amp;revision=2006-03-21</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-AAL5-MIB?module=CISCO-AAL5-MIB&amp;revision=2003-09-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ATM-EXT-MIB?module=CISCO-ATM-EXT-MIB&amp;revision=2003-01-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ATM-PVCTRAP-EXTN-MIB?module=CISCO-ATM-PVCTRAP-EXTN-MIB&amp;revision=2003-01-20</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ATM-QOS-MIB?module=CISCO-ATM-QOS-MIB&amp;revision=2002-06-10</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-BGP-POLICY-ACCOUNTING-MIB?module=CISCO-BGP-POLICY-ACCOUNTING-MIB&amp;revision=2002-07-26</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-BGP4-MIB?module=CISCO-BGP4-MIB&amp;revision=2010-09-30</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-BULK-FILE-MIB?module=CISCO-BULK-FILE-MIB&amp;revision=2002-06-10</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CBP-TARGET-MIB?module=CISCO-CBP-TARGET-MIB&amp;revision=2006-05-24</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CBP-TARGET-TC-MIB?module=CISCO-CBP-TARGET-TC-MIB&amp;revision=2006-03-24</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CBP-TC-MIB?module=CISCO-CBP-TC-MIB&amp;revision=2008-06-24</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CDP-MIB?module=CISCO-CDP-MIB&amp;revision=2005-03-21</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CEF-TC?module=CISCO-CEF-TC&amp;revision=2005-09-30</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONFIG-COPY-MIB?module=CISCO-CONFIG-COPY-MIB&amp;revision=2005-04-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONFIG-MAN-MIB?module=CISCO-CONFIG-MAN-MIB&amp;revision=2007-04-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONTEXT-MAPPING-MIB?module=CISCO-CONTEXT-MAPPING-MIB&amp;revision=2008-11-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DATA-COLLECTION-MIB?module=CISCO-DATA-COLLECTION-MIB&amp;revision=2002-10-30</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DIAL-CONTROL-MIB?module=CISCO-DIAL-CONTROL-MIB&amp;revision=2005-05-26</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DOT3-OAM-MIB?module=CISCO-DOT3-OAM-MIB&amp;revision=2006-05-31</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DYNAMIC-TEMPLATE-MIB?module=CISCO-DYNAMIC-TEMPLATE-MIB&amp;revision=2007-09-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DYNAMIC-TEMPLATE-TC-MIB?module=CISCO-DYNAMIC-TEMPLATE-TC-MIB&amp;revision=2012-01-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-EIGRP-MIB?module=CISCO-EIGRP-MIB&amp;revision=2004-11-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-EMBEDDED-EVENT-MGR-MIB?module=CISCO-EMBEDDED-EVENT-MGR-MIB&amp;revision=2006-11-07</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ENTITY-ALARM-MIB?module=CISCO-ENTITY-ALARM-MIB&amp;revision=1999-07-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ENTITY-FRU-CONTROL-MIB?module=CISCO-ENTITY-FRU-CONTROL-MIB&amp;revision=2013-08-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ENTITY-SENSOR-MIB?module=CISCO-ENTITY-SENSOR-MIB&amp;revision=2015-01-15</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ENTITY-VENDORTYPE-OID-MIB?module=CISCO-ENTITY-VENDORTYPE-OID-MIB&amp;revision=2014-12-09</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ETHERLIKE-EXT-MIB?module=CISCO-ETHERLIKE-EXT-MIB&amp;revision=2010-06-04</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-FIREWALL-TC?module=CISCO-FIREWALL-TC&amp;revision=2006-03-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-FTP-CLIENT-MIB?module=CISCO-FTP-CLIENT-MIB&amp;revision=2006-03-31</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-HSRP-EXT-MIB?module=CISCO-HSRP-EXT-MIB&amp;revision=2010-09-02</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-HSRP-MIB?module=CISCO-HSRP-MIB&amp;revision=2010-09-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-ATM2-PVCTRAP-MIB?module=CISCO-IETF-ATM2-PVCTRAP-MIB&amp;revision=1998-02-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-ATM2-PVCTRAP-MIB-EXTN?module=CISCO-IETF-ATM2-PVCTRAP-MIB-EXTN&amp;revision=2000-07-11</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-BFD-MIB?module=CISCO-IETF-BFD-MIB&amp;revision=2011-04-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-FRR-MIB?module=CISCO-IETF-FRR-MIB&amp;revision=2008-04-29</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-ISIS-MIB?module=CISCO-IETF-ISIS-MIB&amp;revision=2005-08-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-MPLS-ID-STD-03-MIB?module=CISCO-IETF-MPLS-ID-STD-03-MIB&amp;revision=2012-06-07</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-MPLS-TE-EXT-STD-03-MIB?module=CISCO-IETF-MPLS-TE-EXT-STD-03-MIB&amp;revision=2012-06-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-PW-ATM-MIB?module=CISCO-IETF-PW-ATM-MIB&amp;revision=2005-04-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-PW-ENET-MIB?module=CISCO-IETF-PW-ENET-MIB&amp;revision=2002-09-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-PW-MIB?module=CISCO-IETF-PW-MIB&amp;revision=2004-03-17</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-PW-MPLS-MIB?module=CISCO-IETF-PW-MPLS-MIB&amp;revision=2003-02-26</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-PW-TC-MIB?module=CISCO-IETF-PW-TC-MIB&amp;revision=2006-07-21</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IETF-PW-TDM-MIB?module=CISCO-IETF-PW-TDM-MIB&amp;revision=2006-07-21</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IF-EXTENSION-MIB?module=CISCO-IF-EXTENSION-MIB&amp;revision=2013-03-13</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IMAGE-LICENSE-MGMT-MIB?module=CISCO-IMAGE-LICENSE-MGMT-MIB&amp;revision=2007-10-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IMAGE-MIB?module=CISCO-IMAGE-MIB&amp;revision=1995-08-15</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IP-LOCAL-POOL-MIB?module=CISCO-IP-LOCAL-POOL-MIB&amp;revision=2007-11-12</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IP-TAP-MIB?module=CISCO-IP-TAP-MIB&amp;revision=2004-03-11</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IP-URPF-MIB?module=CISCO-IP-URPF-MIB&amp;revision=2011-12-29</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IPMROUTE-MIB?module=CISCO-IPMROUTE-MIB&amp;revision=2005-03-07</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IPSEC-FLOW-MONITOR-MIB?module=CISCO-IPSEC-FLOW-MONITOR-MIB&amp;revision=2007-10-24</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IPSEC-POLICY-MAP-MIB?module=CISCO-IPSEC-POLICY-MAP-MIB&amp;revision=2000-08-17</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IPSLA-AUTOMEASURE-MIB?module=CISCO-IPSLA-AUTOMEASURE-MIB&amp;revision=2007-06-13</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IPSLA-ECHO-MIB?module=CISCO-IPSLA-ECHO-MIB&amp;revision=2007-08-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IPSLA-JITTER-MIB?module=CISCO-IPSLA-JITTER-MIB&amp;revision=2007-07-24</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-IPSLA-TC-MIB?module=CISCO-IPSLA-TC-MIB&amp;revision=2007-03-23</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-MEDIA-GATEWAY-MIB?module=CISCO-MEDIA-GATEWAY-MIB&amp;revision=2009-02-25</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-MPLS-LSR-EXT-STD-MIB?module=CISCO-MPLS-LSR-EXT-STD-MIB&amp;revision=2012-04-30</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-MPLS-TC-EXT-STD-MIB?module=CISCO-MPLS-TC-EXT-STD-MIB&amp;revision=2012-02-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-NBAR-PROTOCOL-DISCOVERY-MIB?module=CISCO-NBAR-PROTOCOL-DISCOVERY-MIB&amp;revision=2002-08-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-NTP-MIB?module=CISCO-NTP-MIB&amp;revision=2006-07-31</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-OSPF-MIB?module=CISCO-OSPF-MIB&amp;revision=2003-07-18</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-OSPF-TRAP-MIB?module=CISCO-OSPF-TRAP-MIB&amp;revision=2003-07-18</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-PIM-MIB?module=CISCO-PIM-MIB&amp;revision=2000-11-02</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-PING-MIB?module=CISCO-PING-MIB&amp;revision=2001-08-28</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-PRODUCTS-MIB?module=CISCO-PRODUCTS-MIB&amp;revision=2014-11-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-PTP-MIB?module=CISCO-PTP-MIB&amp;revision=2011-01-28</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-QOS-PIB-MIB?module=CISCO-QOS-PIB-MIB&amp;revision=2007-08-29</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-RADIUS-EXT-MIB?module=CISCO-RADIUS-EXT-MIB&amp;revision=2010-05-25</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-RF-MIB?module=CISCO-RF-MIB&amp;revision=2005-09-01</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-RTTMON-TC-MIB?module=CISCO-RTTMON-TC-MIB&amp;revision=2012-05-25</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SESS-BORDER-CTRLR-CALL-STATS-MIB?module=CISCO-SESS-BORDER-CTRLR-CALL-STATS-MIB&amp;revision=2010-09-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SESS-BORDER-CTRLR-STATS-MIB?module=CISCO-SESS-BORDER-CTRLR-STATS-MIB&amp;revision=2010-09-15</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SMI?module=CISCO-SMI&amp;revision=2012-08-29</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SONET-MIB?module=CISCO-SONET-MIB&amp;revision=2003-03-07</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-ST-TC?module=CISCO-ST-TC&amp;revision=2012-08-08</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-STP-EXTENSIONS-MIB?module=CISCO-STP-EXTENSIONS-MIB&amp;revision=2013-03-07</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SUBSCRIBER-IDENTITY-TC-MIB?module=CISCO-SUBSCRIBER-IDENTITY-TC-MIB&amp;revision=2011-12-23</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SUBSCRIBER-SESSION-MIB?module=CISCO-SUBSCRIBER-SESSION-MIB&amp;revision=2012-08-08</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SUBSCRIBER-SESSION-TC-MIB?module=CISCO-SUBSCRIBER-SESSION-TC-MIB&amp;revision=2012-01-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-SYSLOG-MIB?module=CISCO-SYSLOG-MIB&amp;revision=2005-12-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-TAP2-MIB?module=CISCO-TAP2-MIB&amp;revision=2009-11-06</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-TC?module=CISCO-TC&amp;revision=2011-11-11</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-UBE-MIB?module=CISCO-UBE-MIB&amp;revision=2010-11-29</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-VLAN-IFTABLE-RELATIONSHIP-MIB?module=CISCO-VLAN-IFTABLE-RELATIONSHIP-MIB&amp;revision=2013-07-15</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-VLAN-MEMBERSHIP-MIB?module=CISCO-VLAN-MEMBERSHIP-MIB&amp;revision=2007-12-14</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-VOICE-COMMON-DIAL-CONTROL-MIB?module=CISCO-VOICE-COMMON-DIAL-CONTROL-MIB&amp;revision=2010-06-30</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-VOICE-DIAL-CONTROL-MIB?module=CISCO-VOICE-DIAL-CONTROL-MIB&amp;revision=2012-05-15</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-VOICE-DNIS-MIB?module=CISCO-VOICE-DNIS-MIB&amp;revision=2002-05-01</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-VPDN-MGMT-MIB?module=CISCO-VPDN-MGMT-MIB&amp;revision=2009-06-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-VTP-MIB?module=CISCO-VTP-MIB&amp;revision=2013-10-14</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DIAL-CONTROL-MIB?module=DIAL-CONTROL-MIB&amp;revision=1996-09-23</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DIFFSERV-DSCP-TC?module=DIFFSERV-DSCP-TC&amp;revision=2002-05-09</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DIFFSERV-MIB?module=DIFFSERV-MIB&amp;revision=2002-02-07</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DISMAN-EVENT-MIB?module=DISMAN-EVENT-MIB&amp;revision=2000-10-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DISMAN-EXPRESSION-MIB?module=DISMAN-EXPRESSION-MIB&amp;revision=2000-10-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DRAFT-MSDP-MIB?module=DRAFT-MSDP-MIB&amp;revision=1999-12-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DS1-MIB?module=DS1-MIB&amp;revision=1998-08-01</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:DS3-MIB?module=DS3-MIB&amp;revision=1998-08-01</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ENTITY-MIB?module=ENTITY-MIB&amp;revision=2005-08-10</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ENTITY-SENSOR-MIB?module=ENTITY-SENSOR-MIB&amp;revision=2002-12-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ENTITY-STATE-MIB?module=ENTITY-STATE-MIB&amp;revision=2005-11-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ENTITY-STATE-TC-MIB?module=ENTITY-STATE-TC-MIB&amp;revision=2005-11-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:ETHER-WIS?module=ETHER-WIS&amp;revision=2003-09-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:EXPRESSION-MIB?module=EXPRESSION-MIB&amp;revision=2005-11-24</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:EtherLike-MIB?module=EtherLike-MIB&amp;revision=2003-09-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:FRAME-RELAY-DTE-MIB?module=FRAME-RELAY-DTE-MIB&amp;revision=1997-05-01</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:HCNUM-TC?module=HCNUM-TC&amp;revision=2000-06-08</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IANA-ADDRESS-FAMILY-NUMBERS-MIB?module=IANA-ADDRESS-FAMILY-NUMBERS-MIB&amp;revision=2000-09-08</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IANA-RTPROTO-MIB?module=IANA-RTPROTO-MIB&amp;revision=2000-09-26</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IANAifType-MIB?module=IANAifType-MIB&amp;revision=2006-03-31</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IEEE8021-TC-MIB?module=IEEE8021-TC-MIB&amp;revision=2008-10-15</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IF-MIB?module=IF-MIB&amp;revision=2000-06-14</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IGMP-STD-MIB?module=IGMP-STD-MIB&amp;revision=2000-09-28</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:INET-ADDRESS-MIB?module=INET-ADDRESS-MIB&amp;revision=2005-02-04</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:INT-SERV-MIB?module=INT-SERV-MIB&amp;revision=1997-10-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:INTEGRATED-SERVICES-MIB?module=INTEGRATED-SERVICES-MIB&amp;revision=1995-11-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IP-FORWARD-MIB?module=IP-FORWARD-MIB&amp;revision=1996-09-19</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IP-MIB?module=IP-MIB&amp;revision=2006-02-02</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IPMROUTE-STD-MIB?module=IPMROUTE-STD-MIB&amp;revision=2000-09-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:IPV6-FLOW-LABEL-MIB?module=IPV6-FLOW-LABEL-MIB&amp;revision=2003-08-28</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:MPLS-L3VPN-STD-MIB?module=MPLS-L3VPN-STD-MIB&amp;revision=2006-01-23</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:MPLS-LDP-GENERIC-STD-MIB?module=MPLS-LDP-GENERIC-STD-MIB&amp;revision=2004-06-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:MPLS-LDP-STD-MIB?module=MPLS-LDP-STD-MIB&amp;revision=2004-06-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:MPLS-LSR-STD-MIB?module=MPLS-LSR-STD-MIB&amp;revision=2004-06-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:MPLS-TC-MIB?module=MPLS-TC-MIB&amp;revision=2001-01-04</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:MPLS-TC-STD-MIB?module=MPLS-TC-STD-MIB&amp;revision=2004-06-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:MPLS-TE-STD-MIB?module=MPLS-TE-STD-MIB&amp;revision=2004-06-03</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:NHRP-MIB?module=NHRP-MIB&amp;revision=1999-08-26</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:NOTIFICATION-LOG-MIB?module=NOTIFICATION-LOG-MIB&amp;revision=2000-11-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:OSPF-MIB?module=OSPF-MIB&amp;revision=2006-11-10</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:OSPF-TRAP-MIB?module=OSPF-TRAP-MIB&amp;revision=2006-11-10</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:P-BRIDGE-MIB?module=P-BRIDGE-MIB&amp;revision=2006-01-09</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:PIM-MIB?module=PIM-MIB&amp;revision=2000-09-28</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:PerfHist-TC-MIB?module=PerfHist-TC-MIB&amp;revision=1998-11-07</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:RFC-1212?module=RFC-1212</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:RFC-1215?module=RFC-1215</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:RFC1155-SMI?module=RFC1155-SMI</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:RFC1315-MIB?module=RFC1315-MIB</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:RMON-MIB?module=RMON-MIB&amp;revision=2000-05-11</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:RSVP-MIB?module=RSVP-MIB&amp;revision=1998-08-25</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:SNMP-FRAMEWORK-MIB?module=SNMP-FRAMEWORK-MIB&amp;revision=2002-10-14</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:SNMP-PROXY-MIB?module=SNMP-PROXY-MIB&amp;revision=2002-10-14</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:SNMP-TARGET-MIB?module=SNMP-TARGET-MIB&amp;revision=1998-08-04</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:SNMPv2-MIB?module=SNMPv2-MIB&amp;revision=2002-10-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:SNMPv2-TC?module=SNMPv2-TC</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:SONET-MIB?module=SONET-MIB&amp;revision=2003-08-11</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:TCP-MIB?module=TCP-MIB&amp;revision=2005-02-18</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:TOKEN-RING-RMON-MIB?module=TOKEN-RING-RMON-MIB</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:TOKENRING-MIB?module=TOKENRING-MIB&amp;revision=1994-10-23</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:TUNNEL-MIB?module=TUNNEL-MIB&amp;revision=2005-05-16</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:UDP-MIB?module=UDP-MIB&amp;revision=2005-05-20</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:VPN-TC-STD-MIB?module=VPN-TC-STD-MIB&amp;revision=2005-11-15</capability>
</capabilities>
<session-id>729</session-id></hello>]]>]]>

Launching Network to Code On Demand Labs

Fri, 07 Oct 2016 00:00:00 +0000

I changed things up this week and wrote an article on LinkedIn about the launch of the Network to Code On Demand Labs platform.

It is a cloud based service that allows you to launch any number of network topologies in minutes for simulations, labs, demos, and testing.

Check it out if you want 22 hours free of on-demand network access to devices of your choice!

Thanks,

Jason

@jedelman8

OpenConfig, RESTCONF, and Automated Cable Verification at iNOG9

Wed, 05 Oct 2016 00:00:00 +0000

Last week I was in Dublin for business which just so happened to overlap with iNOG9, which was last Wednesday. As luck would have it, I had the opportunity to speak at iNOG9 about network automation.

You can watch the video if you want to see the presentation, but the three mini demos I gave were:

Cable verification on Juniper vMX devices using Ansible
Automating BGP on IOS-XR using OpenConfig BGP models using Ansible
Using Postman to explore and demo the new RESTCONF/YANG interface on IOS XE.

Few words about each.

Cable verification

Usually when the topic of network automation comes up, configuration management is assumed. It should not be as there are so many other forms and types of automation. Here I showed how we can verify cabling (via neighbors) is accurate on a Junos vMX topology. Of course, the hard part here is having the discipline to define the desired cabling topology first. Note: links for sample playbooks can be found below on the GitHub repo.

OpenConfig BGP Automation with Ansible

I built a custom Ansible module built around NETCONF (ncclient), but uses the OpenConfig YANG model for global BGP configuration. For example, this is the XML representation of this YANG model that would be pushed over NETCONF:

Note: this is why Ansible is a great and extensible platform as this was a custom module built in just a few hours for this demo/presentation.

<config>
 <bgp xmlns="http://openconfig.net/yang/bgp" nc:operation=create>
  <global>
   <config>
    <as>65512</as>
    <router-id>100.1.1.1</router-id>
   </config>
  </global>
 </bgp>
</config>

In theory, the Ansible task below should work on any vendor supporting NETCONF + OC-BGP. Over time, we’ll try and add gRPC and RESTCONF transport types too. Yes, it’s basic now as it only supports BGP AS and ROUTER ID, but the point is to show what vendor neutral data models offer.

      - name: ENSURE DEVICES HAVE PROPER ASN AND RID
        oc_bgp:
          username: ""
          password: ""
          host: ""
          asn: 65536
          router_id: 10.1.1.1
          state: present

The oc_bgp Ansible module can found at the link below along with the sample playbook used at iNOG, etc.

Thanks to @GabrieleGerbino for helping update some portions of the code.

RESTCONF on IOS-XE

I only had 20 short minutes to speak at iNOG and wish I could have spent more time showing off the new RESTCONF (and NETCONF) interfaces on IOS XE (yes, they are fully driven by YANG models). The RESTCONF interface is pretty awesome if I may say - it’s an http wrapper for using the same models that have been predominantly exposed by NETCONF/XML interfaces on other device types, but now with RESTCONF we can access them with native REST and use JSON or XML encoding!

Even better, and this is what I demo’d, is the proper implementation of HTTP verbs for a REST API. The example I gave was this:

The following API call as a HTTP PATCH simply adds two routes to the static routing table.

 http://csr/restconf/api/config/native/ip/route  (PATCH)

{
  "ned:route": {
    "ip-route-interface-forwarding-list": [
      {
        "prefix": "10.1.20.0",
        "mask": "255.255.255.0",
        "fwd-list": [
          {
            "fwd": "10.0.0.2"
          }
        ]
      },
      {
        "prefix": "10.1.30.0",
        "mask": "255.255.255.0",
        "fwd-list": [
          {
            "fwd": "10.0.0.2"
          }
        ]
      }
    ]
  }
}

This is standard and most commonly done today by network operators using the CLI.

Here is the magic though. The next API call using a HTTP PUT declaratively states that this route(s) should be the only routes that exist in the static routing table - this means any other route in the static routing table will be purged.

 http://csr/restconf/api/config/native/ip/route  (PUT)

{
  "ned:route": {
    "ip-route-interface-forwarding-list": [
      {
        "prefix": "0.0.0.0",
        "mask": "0.0.0.0",
        "fwd-list": [
          {
            "fwd": "10.0.0.2"
          }
        ]
      }
    ]
  }
}

The end result is a single default static route in the static RT.

This is massively valuable. This means you do NOT need any command negations, i.e. imagine having a 100 static routes and you wanted to remove them all today. How would you do it today? How will you do it tomorrow? Command negations is one of the barriers to get over with any form of automation.

Closing

As always, any questions, just reach out. All materials from this presentation including slides, playbooks, and files can be found here.

The video from iNOG9 can be found here.

Thanks,

Jason

@jedelman8

Network to Code and General Update

Tue, 04 Oct 2016 00:00:00 +0000

It’s been a long time since my last post, way longer than I’d like. For the last several months we’ve been neck deep in network automation. This post focuses on the highlights of not only what I’ve been up to, but also the rest of the Network to Code team. More detailed posts will come over the coming days and weeks.

Training

As you can see from the website, we have a good number of public courses on network automation and even a few starting early next year that are completely virtual, but the majority of our training engagements have been private on-site instructor-led courses with Enterprises and Global Carriers. The private courses have varied from using the same course outline you see on the website, but have also been modified for a particular vendor, device type, and/or API. Popular topics covered in our training include Ansible, Python, NETCONF/RESTCONF/YANG, and various vendor APIs including Nexus NX-API, Arista eAPI, Juniper’s XML API, to Cisco’s new NETCONF/RESTCONF APIs on IOS XE.

Software Development

We’ve contributed to various open source projects, but key highlights include contributions to Ansible modules that are now part of core as well as adding Palo Alto Networks (PAN) drivers to both netmiko and NAPALM.

Professional Services

We’ve worked with companies of all shapes and sizes over the past several months to adopt network automation strategies and tooling. Performing small automation tasks and writing playbooks is quite easy to get started, but does not compare to the intricate detail and patience needed to automate workflows in production environments.

On Demand Labs

I originally wrote about this months ago, but we’re finally at a place to fully offer up the Network to Code On Demand Labs platform. This is a cloud platform that allows you to launch nearly any network topology in a matter of minutes lowering the barrier to start testing and automating.

We already have close to twenty pre-built topologies and a growing amount of tutorials, but will be adding even more over the coming weeks. Several companies have already purchased promotion codes in bulk for various use cases ranging from lab testing to simulation to vendor POCs and demos.

Check it out here.

Closing

I’m merely using this post as a vehicle for providing everyone an update on where I’ve been and what’s been going on, but clearly this is not just me doing all of the work. Huge thanks to the team for making all of this happen, and I’m sure we’ll have more to update everyone on in the coming months. By the way, we are hiring, so please apply if you’re interested.

As always- if you’re interested in talking automation or exploring how we can help, don’t hesitate to reach out - jason at networktocode dot com.

Thanks,

Jason

@jedelman8

On Demand Network Labs [FREE]

Sat, 20 Feb 2016 00:00:00 +0000

Way too often do we want to learn a new technology, but end up spending countless hours just getting the product, tool, or technology downloaded, installed, and at a point to begin using. This is unacceptable.

We need a platform that offers on-demand network infrastructure labs that makes it extremely easy to test and learn how to use network device APIs, how to write code against a network device, and how to use DevOps tool chains in the context of networking.

It’s true, this has all become easier with tools such as Virtual Box and Vagrant, but you can still spend the same amount of time getting the underlying infrastructure setup as you spend on the actual tests you need to perform. In that model, you also need to be able have enough horsepower to run enough virtual machines as well, which often isn’t the case. On top of that, many Enterprises don’t allow tools such as these to be installed.

On Demand Network Labs

What I am proposing and getting ready to launch is a cloud based platform that allows you to launch pre-built network topologies in minutes. Upon launch, they are ready to be used, automated, and managed - fully eliminating the time and hassle often required to get started.

When launched, this will be the Network to Code On Demand Network Labs platform.

Many vendors have online labs - this is that, but from a multi-vendor and independent perspective. Need a leaf spine from vendor X? Need a multi-node routed WAN from vendor Y? Want to see first hand how to use Puppet on a network device from vendor Z? Sweet, well in just about 10 minutes, we get the virtual labs spun up and give you access to not only a pre-built jump host, but also a public IP address per device! And yes, there are tutorials to follow.

Here is a sneak peak:

Calling Early Adopters

Are you interested in being an early user of our platform? If so, you need to do one thing. Email us at labs@networktocode.com and tell us the following:

What platforms you are most interested in, i.e. Cisco Nexus, Cisco IOS, Cisco IOS-XR, Arista, OpenDaylight, Citrix VPX, Cumulus, Juniper vMX, vSRX, etc.
What topology you’d like to see given the combination of platforms you’re requesting.
What tools you’re most interested in and want to learn how to use, i.e. just raw Python, gerrit, Jenkins, Puppet, Chef, Ansible, etc.

If you email us and include those three things, we’ll offer you at least two (2) FREE labs of 4 hours each!

Testing & Learning to CI Pipelines

As much as this platform is meant for dev/test of learning automation automation technologies, it can be used for testing any feature the platform supports. Additionally, we’ve had requests for infrastructure that can be used for Continuous Integration testing such that as users deploy CI pipelines, they can test again our cloud-based virtual platforms since often times, they don’t have enough physical kit to do this kind of testing on their premises.

We look forward to hearing from the early adopters and continue to work hard preparing for a formal launch in the next several weeks!

UPDATE- This is only offering “free” labs to people that wish to be an early adopter. The on-demand labs will not be “free” at launch (unless the vendors are sponsoring them). And if you are a vendor, and want to take part and learn more, please reach out.

Thanks, Jason @jedelman8

P.S. If you’re interested in formal instructor-led Network Automation training that covers Ansible and Python, check this out: Network Automation Course Schedule.

Big Switch Meets Ansible

Thu, 28 Jan 2016 00:00:00 +0000

Big Switch offers on demand labs to get instant access to Big Cloud Fabric (BCF) and Big Monitoring Fabric (BMF). Using these labs, it’s quite easy to experience the products first hand and see what they are all about. The labs also come with lab guides that walk you through step-by-step on how to get started using BMF and BCF.

For me, one of the more appealing aspects of these labs is that Big Switch also exposes the APIs such that you can access them directly from your personal machine. This makes it possible to not only test the product, but also test the API on each controller platform (BMF and BCF).

The best part is, you don’t even need to use any docs because they offer a command that shows the API calls being made by certain show commands.

controller> debug rest
***** Enabled display rest mode *****
REST-SIMPLE: GET http://127.0.0.1:8080/api/v1/data/controller/core/controller/role
controller> 

Like the output from a show version? Ensure debug rest is enabled, and then just issue the command to grab the APIs being called to generate the text output on the CLI.

controller> show version
REST-SIMPLE: GET http://127.0.0.1:8080/api/v1/data/controller/core/version/appliance
REST-SIMPLE: http://127.0.0.1:8080/api/v1/data/controller/core/version/appliance done, 0:00:00.012266
~~~~~~~~~~~~~~~~~~~~~~~~~~~ Appliance  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name            : Big Cloud Fabric Appliance
Build date      : 2015-12-20 07:06:05 UTC
Build user      : bsn
Ci build number : 75
Ci job name     : bcf-3.5.0
Release string  : Big Cloud Fabric Appliance 3.5.0 (bcf-3.5.0 #75)
Version         : 3.5.0
REST-SIMPLE: GET http://127.0.0.1:8080/api/v1/data/controller/core/controller/role
REST-SIMPLE: http://127.0.0.1:8080/api/v1/data/controller/core/controller/role done, 0:00:00.013763

We can see that one of the APIs being called is this:

GET http://127.0.0.1:8080/api/v1/data/controller/core/version/appliance

Pretty cool.

This has to be going somewhere, right? Absolutely…can’t just play with an API and not build anything.

Big Switch Ansible Modules

Over the past few days, I spent time working with these APIs and ended up developing Ansible modules to collect facts for BMF and BCF. They can be found here.

Facts is a great place to get started because you can now use this information to use as inputs into other modules (more in the future!) and even more important, the facts collected can be used to create dynamic reports, etc.

So, if you’re using BMF and/or BCF, these modules can be used to help keep track of that inventory or to do health checks in real-time.

Here is a sample playbook using the module bcf_get_facts to collect facts from Big Cloud Fabric.

---

   - name: GATHER FACTS FROM BIG SWITCH CONTROLLERS
     hosts: bcf
     connection: local

     tasks:

       - name: GATHER FACTS
         bcf_get_facts: controller= username= password=

       - name: DUMP FACTS TO TERMINAL
         debug: var=bsnbcf

The facts returned is a dictionary and are stored in the key bsnbcf or bsnbmf based on which module you are using.

This is an example of facts gathered from Big Cloud Fabric:

{
    "var": {
        "bsnbcf": {
            "cluster": {
                "controllers": [
                    {
                        "hostname": "10.10.12.20",
                        "role": "active",
                        "uptime": 33807223
                    }
                ],
                "description": null,
                "name": "bigswitchcluster",
                "redundancy_status": {
                    "msg": "Single node configured",
                    "status": "standalone"
                },
                "virtual_ip": null
            },
            "fabric_nodes": [
                {
                    "dpid": "00:00:00:00:00:02:00:01",
                    "fabric_state": "connected",
                    "name": "R1L1",
                    "role": "leaf",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:02:00:02",
                    "fabric_state": "connected",
                    "name": "R1L2",
                    "role": "leaf",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:02:00:03",
                    "fabric_state": "connected",
                    "name": "R2L1",
                    "role": "leaf",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:02:00:04",
                    "fabric_state": "connected",
                    "name": "R2L2",
                    "role": "leaf",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:02:00:05",
                    "fabric_state": "connected",
                    "name": "R3L1",
                    "role": "leaf",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:02:00:06",
                    "fabric_state": "connected",
                    "name": "R3L2",
                    "role": "leaf",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:01:00:01",
                    "fabric_state": "connected",
                    "name": "S1",
                    "role": "spine",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:01:00:02",
                    "fabric_state": "connected",
                    "name": "S2",
                    "role": "spine",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                },
                {
                    "dpid": "00:00:00:00:00:01:00:03",
                    "fabric_state": "connected",
                    "name": "S3",
                    "role": "spine",
                    "sw": "Switch Light Virtual 3.5.0 2015-12-15.00:38-db7144c trusty-amd64"
                }
            ],
            "hostname": "controller",
            "platform": "Big Cloud Fabric Appliance 3.5.0 (bcf-3.5.0 #75)",
            "summary": {
                "controllers": 1,
                "errors": 18,
                "leaf_groups_configured": 3,
                "leaves_configured": 6,
                "leaves_connected": 6,
                "overall_status": "NOT OK",
                "spines_configured": 3,
                "spines_connected": 3,
                "tenants": 0,
                "vswitches_connected": 0,
                "warnings": 14
            },
            "vendor": "big_switch_networks",
            "version": "3.5.0"
        }
    }
}

And here is a sample from Big Monitoring Fabric:

    "var": {
        "bsnbmf": {
            "cluster": "N/A",
            "fabric_nodes": [
                {
                    "alias": "Filter-Switch",
                    "dpid": "00:00:00:00:00:00:00:0b",
                    "serial_number": "",
                    "sw": "Switch Light Virtual 3.1.0 2015-10-07.00:17-60a8572 trusty-amd64"
                },
                {
                    "alias": "Core-Switch",
                    "dpid": "00:00:00:00:00:00:00:0c",
                    "serial_number": "",
                    "sw": "Switch Light Virtual 3.1.0 2015-10-07.00:17-60a8572 trusty-amd64"
                },
                {
                    "alias": "Delivery-Switch",
                    "dpid": "00:00:00:00:00:00:00:0d",
                    "serial_number": "",
                    "sw": "Switch Light Virtual 3.1.0 2015-10-07.00:17-60a8572 trusty-amd64"
                }
            ],
            "hostname": "N/A",
            "platform": "Big Tap Controller 5.5.0 (2015.10.14.1909-m.bsc.bigdb)",
            "summary": {
                "active_policies": 0,
                "core_interfaces": 4,
                "delivery_interfaces": 2,
                "delivery_switches": 1,
                "filter_interfaces": 1,
                "filter_switches": 1,
                "match_mode": "bigtap-l3l4",
                "num_policies": 0,
                "num_services": 0,
                "service_interfaces": 2,
                "service_switches": 1,
                "total_switches": 3
            },
            "vendor": "big_switch_networks",
            "version": "N/A"
        }
    }
}

Feel free to contribute: https://github.com/networktocode/bsn-ansible

Happy Automating.

Thanks, Jason @jedelman8

The Network Automation Book

Mon, 28 Dec 2015 00:00:00 +0000

From OpenFlow to Software Defined Networking (SDN), there has been a lot of hype, 100s of millions of dollars in venture funding, and billions in exits within the network industry over the past 5+ years. The one thing we know for certain about the industry in all of this is that change is here, and more is coming, which is exactly the reason for this post!

Ironically, I also started this blog 5+ years ago. In the beginning, this blog was a lot of speculation around OpenFlow and the future of Software Defined Networking (SDN). Nowadays, it’s rare to hear me mention SDN at all, and the focus is much more practical on tools and technology that can help solve real problems. For those that have been reading for a while, you probably saw this shift in addition to the career shift I made 18+ months ago. These shifts go hand in hand with a new project I’ve been working on.

It’s with great pleasure that I’m finally able to announce a project that started several months ago that falls in-line with exactly the same topics you read about frequently on this blog.

What is the Project?

It’s a book! Yep, that’s right. I’m honored to say I am a co-author of a book focused on Network Automation. The title is Network Programmability and Automation Skills for the Next-Generation Network Engineer and is being published by O’Reilly.

Who’s Involved?

I’m ecstatic to say the other authors are Matt Oswalt and Scott Lowe. Both are friends and industry leaders — they are each helping pave the way forward across the industry.

Check out their announcements here and here.

And all three of us use Jekyll and GitHub pages for our blogs, so you won’t find any pop-ups for ads. That’s just a bonus.

When is it Getting Released?

It’s already in the O’Reilly early release program, so you can literally start reading today!

You can also pre-order a copy from Amazon if you’d like.

Or navigate directly to Safari.

Because this is an early release, it’s not complete yet and may very well change before it is final. That said, we’re actively taking feedback and will be making updates over the coming months.

What Topics Does the Book Cover?

We cover topics such as Python for the Network Engineer, Linux, Network Configuration Templating, Device APIs, and how to use DevOps tools such as Puppet, Chef, and Ansible automating network devices! They are all important skills for the next-gen network engineer.

Summary

Please give us feedback. If you sign up for the early release program, you’ll see we have a dedicated email alias to send all comments/feedback too. If it’s easier, just email me, Scott, or Matt directly!

Happy Reading!

Thanks, Jason @jedelman8