NEXUS Dashboard and NEXUS Cloud Open Integrations

As NEXUS Dashboard has become mainstream and NEXUS Cloud is soon ready to launch General Availability (GA), Cisco will support open systems integrations. This podcast with Cisco Champions Alex Deca and myself and Mayuri Kulkarni and Will Zupan from the Cisco BU discuss what the NEXUS Dashboard and the NEXUS Cloud day two operation platforms are and what new integrations are supported.

First, let’s define the two platforms; both allow you to quickly onboard ACI sites, NX-OS vPC sites, and DCNM sites (NEXUS Cloud won’t support this at initial GA but will later this year). NEXUS Dashboard is comprised of 3-7 physical or virtual nodes to form a platform cluster, while NEXUS Cloud is a SaaS-based model in the public Cloud. An easy way to view it is to think of Office 365 running on your laptop (NEXUS Dashboard) or Office 365 running in the public Cloud (NEXUS Cloud). Both offer 90% of the same capabilities; however, since NEXUS Dashboard is on-prem, it has support for end-to-end flow telemetry and deeper analytics, as sending multiple gigabits telemetry flows to the public Cloud is not feasible. One crucial feature of NEXUS Cloud is that upgrades get done automatically. When a major or minor part is added to these platforms, NEXUS cloud, because it is a SaaS model, the platform will perform the updates on the backend, and no user intervention is required. NEXUS Dashboard requires an update to all the service nodes and the applications consumed, such as NEXUS insights or NEXUS Dashboard Orchestrator.

The podcast discusses using Terraform and Ansible playbooks in the NEXUS Dashboard and NEXUS Cloud to manage and configure day-to-day tasks of reliably adding networking constructs using automation. Terraform and Ansible have Providers and playbooks that can automate all the required tasks, and we see Cisco favoring the use of Terraform as we advance.

Modern cloud networking products and controllers have automation as one of their main goals. The Nexus-as-Code(NAC) project uses existing code to meet best practices through an easy-to-use data model. Nexus-as-Code aims at users with limited experience with Ansible, Terraform, or those who prefer automating through an inventory-driven approach. Take a look at this page for information on the NEXUS as-code project; https://developer.cisco.com/docs/nexus-as-code/#!introduction/cisco-nexus-as-code

Most of the Nexus-as-Code project leverages this data model-driven approach through Hashicorp Terraform. Terraform is commonly used to define Cloud and on-prem resources in a human-readable configuration that you can version, reuse, and share. The Nexus-as-Code project page includes additional examples in the NDFC-NXOS and Other Examples section, using Ansible and Terraform to automate Application Centric Infrastructure (ACI), Nexus Dashboard Fabric Controller (NDFC), and NX-OS standalone-based networks. These examples do not adhere to the same data model-driven approach but offer valuable resources for more experienced users.

Cisco’s Cloud Networking vision is to provide a single methodology for creating policy and networking as code and applying it to multi-cloud, SDWAN, and Edge using ITSM tools and Open APIs.

As NEXUS Dashboard and NEXUS Cloud mature, more partners will become integration points. Whether Terrform and Ansible for automation, F5, Palo, Splunk, Algosec, Tufin, AppD, and Cisco for security and application visibility, or ServiceNow for ticket management of issues and remediation tracking.

Finally, Cisco’s ultimate vision is cross-domain support coming in future versions. Integrating Thousand Eyes, SD-WAN vManage, vCenter integration, DNA Center, Intersight, and AppD support, as well as the Open APIs and vendor agnostic integration, we have fully automated and complete end-to-end visibility never before possible. Once we apply AI and ML training to these integrations, we can predictively see faults and problems and potentially repair them before they become an outage for users and applications. Tickets could get opened by an AI chatbot, approved by a human, and fixed and closed by the same AI chatbot. This AI Chabot scenario is not science fiction but precisely where Cisco and other vendors visualize the future.

At WWT, we are in lockstep with Cisco to create these integrations and will have labs and articles as this vision becomes a reality. In the meantime, look at the NEXUS Dashboard content already on the WWT platform and look for future announcements of new labs and integrations. https://www.wwt.com/article/examinining-cisco-nexus-dashboard-using-new-hands-on-labs

Ask the customer, Cisco Nexus Dashboard

Please join Cisco and WWT for a webinar showing customers experience with Cisco Nexus Dashboard and Insights, real-life use case’s and how WWT can help you get Cisco Nexus Dashboard and Insights into your infrastructure to monitor your network for a free trial run proactively. Learn new features from Cisco and how WWT can help get customers onboarded for the trial. WWT also offers an SKU-based service that many customers have leveraged to help set up Cisco Nexus Dashboard and Insight and create use cases to evaluate the product in your network.

If you feel up to doing it yourself, navigate to WWT.com and look for the two-part white paper for installing Cisco Nexus Dashboard and Insights and creating 20+ use cases. The first part of the white paper shows installing the physical or virtual form factors nodes to build the Cisco Nexus Dashboard Cluster. Then we onboard sites and any 3rd party Apps.

Part 2 of the white paper contains over 20 use cases, so a customer has an easy way to validate and test the ND and Insights in a trial period. Most customers that we have helped install the Dashboard or used our 2 part white paper found Cisco Nexus Dashboard and Insights so valuable that they purchased the licensing and are delighted with the accessible troubleshooting insights.

In the webinar, we see a real-life WWT customer scenario of changing their troubleshooting time from hours and multiple teams to 10 minutes and a single team (Netops) using Insights. We perform a live demo showing how that is accomplished in these day 2 tools, reducing MTTI (Mean Time To Innocence) and MTTR dramatically.

Also, for our customers that are replacing vPC-based 7k/5k/2k 3-tier networks with Nexus 9300 and 9500 switches, we can now leverage the functionality of Insights to these devices even though they are not ACI or in an EVPN fabric. Most customers assumed that Cisco Nexus Dashboard and Insights were only for ACI fabrics. What most Nexus 9k NX-OS customers dont know, is that you can gather most of the telemetry of what ACI can send to Insights with NX-OS-based switches. You need Nexus Dashboard Fabric Controller (NDFC) to proxy the telemetry to Dashboard as a site and eventually into the correlated database that can be used by Insights the same way we do with ACI. Integrating your NX-OS fabric is very simple, and you can gain unprecedented visibility from your existing NX-OS-based 9k-based infrastructure. Instead of needing a team for initial troubleshooting with Insights, you can quickly find the root cause, rule out the network, or find the issue in the network.

You can sign up at the link below and join Cisco and WWT for a deep look into how Cisco Nexus Dashboard and Insights can provide faster MTTI (Mean Time To Innocence) and then find the root cause, make the changes and restore the outage in 10 minutes instead of all day and engaging multiple teams.

Please sign up for the Webinar on Sept 21st from 10:00-11:00 PDT and hope to see you there!

https://webinars.cisco.com/amer/insider-series-cloud-nexus-dashboard#xd_co_f=MDEyNjRiZTAtNjA4Yy00MzY4LTkxOGUtMDIzY2Q0ZmQyNjM0%7E

Congratulations! Your blog has been selected as a finalist in the Most Inspirational category of the 2020 IT Blog Awards

It is our pleasure to announce the 2020 #ITBlogAwards finalists. Congratulations! http://cs.co/6019HudID It is now up to the community to weigh in and help select the winners in each category. Show the love. Vote now.

I was very excited to see this in the email last night, in my blogs I inspire people to challenge themselves to do better so I am very proud I was chosen for Most Inspirational IT Blog. Please support me in this award it would mean a lot to win this and inspire me do do more next year! https://www.ciscofeedback.vovici.com/se/705E3ECD2A8D7180 Please follow the link and under Most Inspirational, choose my blog “The Journey of Binary Bits”(Highlighted)

I was submitting my application for #CiscoChampion2021 and it asked if I felt like I was an influencer. I never thought about it, but yes, I am most definitely an influencer. An influencer’s end goal in IT is to become the trusted advisor which I’ve been doing for the past 20+ years. I think each of us is an influencer in some shape or fashion as we influence our children, friends and family, coworkers, and for us in IT sales, customers looking to make hard decisions on multi-million dollar purchases.

To be an influencer, you must have the trust of the people you are trying to help. Trust is everything in life; without that, you cannot have any relationship professionally or non-professionally. And that trust must be ongoing; you cannot gain someone’s trust and then go behind them where you may lose that trust. If you do, it is tough to get back. Along with trust, you must also be honest, but that goes without saying if you are trustworthy

To become a trusted advisor, you must have the person’s trust and be empathetic to the person’s situation and be somewhat humble. In this field, we have many brilliant engineers, and most try to be the smartest in the room. In general, I find that people that are not empathetic and humble can be abrasive, making trust that much more challenging.

One of my favorite things to do is teach; whether customers, co-workers, friends, or family. I have done hundreds of training classes, and workshops and the most important thing I try to do is inspire my students to look deeper into newer technologies and have a more open mind as to not what is, but the art of the possible. I always try and get them to look ahead 3-5 years of what’s coming and why it is important to learn specific skill sets that they need in 3-5 years (such as DevNet skills)

However, to inspire students (or anyone), you must have their trust and be empathetic. One way I do this for both classes and workshops as well as meeting new customers is during the introductions. I usually let the class or customers go first and ask them their pain points, problems, and other issues. I find that discussing your credentials while being humble and the work you’ve done similar to their problems shows both trust and empathy. These two opening things will at least gain you the beginnings of trust. Throughout the training class or workshop, show them your knowledge apply it to their problems while being empathetic. If you can achieve this, you are trusted and well on your way towards being a trusted advisor.

As I look back over 2020 and my blogs and people I’ve helped I am very proud of what I’ve accomplished. Its been a great year and i look to help even more people out in 2021!

Remember “Journey before Destination”

Jumping into the DevNet waters! Part 3

I’m a big fan of analogies, and I gave this some thought as to the stages of where I am. Some of this may or may not resonate with the reader but this has helped me get 6″ off the ground. I am going to continue with the sausage analogy for my phases of DevNet learning.

As I mentioned earlier, I’ve been doing networking as a Pre-Sales Engineer for 10+ years. I don’t do installs and I build labs here and there just to keep skill sets up. As automation and open-switch and open-flow started to be looked at by customers I saw some college’s go headfirst, while I spent my time over the last 5-6 years learning to be a data center SME expert focusing on ACI, NSX and others on how to help sell these new solutions. I was able to use some of the DevNet tools such as Postman and Ansible to create objects via APIs from a sales standpoint to show how “easy” ACI or NSX is to automate and program. These were simple exports or other engineers Postman scripts, but I could not look at the actual XML, JSON or Yaml files to figure out what they were doing. I was more focused on serving the DevNet Sausage to the customer as a appetizer to help sell ACI and NSX. I’ll call this phase 1, I don’t know how to cook or make the sausage but I can sell it off the menu and serve it to the customer as a appetizer to help close the ACI or NSX deal.

The next phase of DevNet is learning how to actually learn how to cook the sausage and what vegetables and sides go with it, and for that you need to learn the right tools like a pan, knives, spices. In the DevNet world that is GitHub, learning how to install Python and packages, editors, Docker hub and others. I’ve tried doing Python a few times and some of these other tools and here was here I was at. Basically the sausages are on fire and I burnt the kitchen down!

Since I was not the only engineer at WWT or customer that had his kitchen on fire, this was noticed by our growing automation team. We are super lucky at WWT to have some very passionate engineers dedicated to helping customers and engineers at WWT learn DevNet skills. Last year 9 of them formed a study group to go after the new DevNet certification and 9 out of 9 passed https://www.wwt.com/article/nine-out-of-nine-in-the-devnet-500

They decide it would be a good idea to create a curriculum that they used to pass the test and some of them were in the same boat as me with their sausages causing a large grease fire.

I decided to join the next study group as they had a good path and obviously had great sucess. The first thing I did was start with https://developer.cisco.com/ if you have a CCO login its a great place to start. I also has instructions on setting up your laptop for coding. Next get a GitHub account https://github.com/ and learn how to manage code repositories, branches merges etc. Next get a Docker hub account https://hub.docker.com/ and install docker desktop. Docker is really good for getting a container built that has all of the necessary Python versions, packages etc so you can learn Python and other automation and not worry your laptop is configured properly. We are very fortunate that the 9 out of 9 built docker containers with everything needed pre built we can use.

Also WWT has developed a program ability lab so if your one of our customers that’s a great place to start for free. https://www.wwt.com/lab/programmability-foundations-lab

A couple of other good sites to learn programming and DevNet are https://www.udemy.com/ https://www.codecademy.com/ https://auth.acloud.guru/ https://www.oreilly.com/ https://app.pluralsight.com/id/

In the study group we learned to install and use some of these tools as well as have some Python learning. I tried my best with the Python but looking at any code it looks like goop and for me, and what I needed to know in the near term was how to use tools to recognize what the code is doing and run the code but not yet quite learn to write the code.

While some of the folks in the class saw the Python code exercises like this

To me I saw this a giant bowl of mish mosh in the Python exercises

So I decided to learn the tools first so I could understand and use them and eventually once I got a grip on git hub, docker, some of the editing tools I could still work on learning python. Since we are converting all of our labs docs to doc as code in the near term, I need to learn how to convert word docs to markdown, push it to GitHub, learn how to branch and then modify the lab docs in this environment. So again my goal at this point is to take the sausage someone has created and learn how to cook it really well, and being able to sell it off the menu to my customer (my favorite dish is Andouille sausage, Kielbasa, and chicken Jambalaya!). Sausage making(Python) is going to have to wait a little!

Jumping into the DevNet waters! Part 2

I find myself in a similar situation to a lot of network engineers that do not have a computer science or programming background. A lot of us started as electrical engineers, or came from other disciplines and maybe had to take a programming course or two in college. At that point, we knew programming was not something we wanted to do every day. Then there is the group of network engineers that were computer science, majors, because they liked coding, and went into IT after college and ended up in networking. Now that automation and DevNet are where the industry is going we see the network engineers that embraced programming early on in their careers whether it be through schooling or as a hobby flourish and take to it easily. The rest of us that didn’t do any programming for 10,15,20 years after college are looking in from the sidelines trying to figure out where to start.

I’ve tried over the years to learn DevNet, but have stopped and started so many times and got super frustrated and hung it up. I’ve just never found a good path to what you need to actually know, I need a baseline, a self-assessment, where the hell am I am where do I go? Also, one thing that always threw a wrench into things was having a Windows laptop for work and it not supporting a lot of coding stuff without installing all kinds of Python packages and other tools and invariably things would fail missing packages etc

For the last 10 years, I have been doing pre-sales and not even doing and installs so any real installs were building training labs and there was not a huge need for programming. After ACI came out and controller-based platforms started becoming more widely deployed there was a need to be able to show customers how you could do things faster with controller-based networking.

As a pre-sales SME in ACI, I was fairly comfortable exporting the XML or JSON from ACI or taking someones XML or JSON and programming an ACI fabric, I did a little work with Ansible playbooks configuring MP-BGP EVPN but did it so infrequently that I never really used it much in a pre-sales role selling DC switching. I would run an Ansible playbook, or Postman script to show customers how “easy” it was to automate, but all I was really doing was serving the sausage not making and cooking the sausage.

After changing roles from pre-sales focused and becoming more lab focused and working on more R&D type projects I started looking at where the industry as a whole was going. For a great number of years, networking has really taken a back seat in IT while computing and virtualization and storage have leaped ahead. Networking was always built to be very stable and static, you needed a change window to make any changes. If you take VMWare for instance, a virtual machine (VM) can be dynamically moved from a box that is utilizing too much CPU and memory to one that is not using DRS. This requires no human interaction but rather a feedback mechanism that says if the host uses X% of CPU, move workloads dynamically to another box that has a lower CPU any time of the day.

Now that SDN is fairly mature and ways to automate configuration and provisioning of networks using controllers is being embraced in production settings there needs to be another step taken. For folks that are not yet SDN savvy and just dipping their toes into SDN, I use these slides when I teach students SDN concepts.

This first picture shows how we do non-SDN networking today. Each network device uses some control plane protocol to talk with other network devices about the best path to take. As network traffic moves from device to device, it uses its LOCAL control plane information to program the local device where to send the traffic next.

What SDN does is move the control plane function to a single point of management and the single controller then programs all of the local devices on where to send it next. The forwarding path is the same, only how the forwarding path is programmed into the local devices is different.

The final piece is how the network operator talks to the controller using API calls and how the controller talks to the individual devices using agents. If you notice all of the arrows point from the controllers to the devices and most SDN implementations are about automating Day 0 and doing Moves, Adds, Changes (MAC). There is nothing dynamic about this, we are just automating mundane daily tasks using automation tools

However, with the advances in AI, big data analytics and machine learning we can now pull information off the individual network devices and potentially make changes to the path traffic takes on the fly, just like moving a VM to a different device if the CPU is too high.

Enter Intent-Based Networking (IBN), which is what is driving me down the DevNet path. If we look at a basic IBN architecture we can discuss how it works and why Devnet is going to become even more important. IBN is nothing new, its concepts have been around for quite years. IBN takes both business (HR needs access to their apps and data no matter where they are working) and the IT (HR cannot access Finance applications data) Intent to form a policy. That policy is then applied to the controller via a human or automated fashion (Translated). This policy is then automatically applied (Activation) to all the devices to ensure that both business and IT compliance are met. What has been missing is Assurance to pull data and telemetry real-time, process it using high-speed AI and machine learning, and feedback any changes required to keep traffic in compliance with the intent. Just like we did using DRS in VMWare, we can now move traffic around dynamically and on the fly. The reason we have never been able to do this is how complicated traffic patterns and the large size of networks now being controlled.

What I have become interested in is this feedback mechanism using assurance engines and in order to understand it deeply, I need to learn how API’s talk and that requires a DevNet skill set I do not have. I found myself far behind the curve from a DevNet skill set while I am a CCIE route switch, NEXUS, and ACI expert. In order to progress and dive deeper in to IBN, I must first learn super basic skill sets which we will cover in my next post.

Jumping into the DevNet waters! Part 1

First I am not a programmer, didn’t take computer science in college, I’m just not a “software/programmer” guy. I started in Electrical Engineering doing high power RF and Microwave at the RHIC particle Accelerator and my passion is and always will be hardware.

I did a career change in the early 90’s going into IT doing the MCSE path then CCNA-CCIE path. None of this required a lick of programing skills. I did take Pascal and Fortran in the early ’80s in College but programming was not for me and ive had a very sucessful career for the last 25 years without programing.

Over the years as we see SDN and in general software-defined anything become commonplace in IT we see that new skill sets are needed in understanding how API calls and programming is used to interact with these platforms. The industry for networking, storage compute and virtualization is moving to a controller-based approach for managing multiple IT assets using API driven controllers. I can remember being at the CiscoLive 2014 NetVet event and John Chambers telling a room full of CCIE’s to get ready as someday you will no longer configure a network device using the command line of each device. That became a reality with ACI as you must configure everything from the APIC controller. Also now that most companies are migrating some or in cases a lot of workloads to the public cloud we find that there are significant advantages to understand how API’s work and how to automation function with tools like Ansible and Terraform.

I’ve worked with ACI for many years and could do some basic programming with Postman and some very basic stuff controlling MP-BGP EVPN fabrics with Ansible, but never could get very deep. And while I am a top expert in data-center switching, MPLS, routing, compute, and virtualization I found myself very lacking in DevNet. Taking the next step in keeping up with the industry and being able to deeply learn API calls and how to interact with platforms with automation tools is starting to become a necessary skill especially in my new role in R&D work with Cisco and other OEM’s. As the years have gone by, I’ve watched a lot of coworkers take to programming and automation very easily, however, most of them took computer science then went directly into IT so they had the necessary programming background to easily transition from a network engineer to a network engineer using DevNet to automate.

I felt more and more like the dog in Chevy Chase’s Vacation and had to figure out a way to keep up as I was being dragged along and not keeping up. “Poor little guy probably kept up with yah for a mile or so”

One of my biggest challenges was how to get started with Python and setting up my Windows laptop for being able to program. I think the Windows platform was one of the biggest hindrances as I would try and do installs of these software packages, they would fail I would get frustrated. Add that to just tons of work and traveling and it wasn’t super relevant in a pre-sales role, I could never get started and just kept getting dragged along like the Griswalds pooch.

One of the things the WWT Automation practice came up with was some program-ability labs and the concept of a “CONE”. Now when I think of CONE I think of Cone-head or something like this (let us see if anyone knows where my hats from)

That’s not exactly how WWT defines a CONE but rather a “CONE” is a Crusty Old Network Engineer. What we are seeing in our customer base as well as in our engineers is the lack of DevNet skills to get today’s network engineers up to speed using automation tools.

Two of my co-workers Joel King and Jeff Andiorio https://www.wwt.com/article/turning-cones-into-unicorns https://blogs.cisco.com/developer/get-certified wrote great posts on why “CONE’s” need to learn automation skills and become “Unicorns”. An experienced CCIE that can do automation is very rare in the industry and as the industry turns to more and more programmable infrastructures a CCIE with Devnet Certs becomes a very valuable asset to the company. Also as the command-line configuration of individual devices is removed (like in ACI), any network engineer will need to know how to interact via API calls and will need to know how to do this. One of the things I was also lacking was a structured way of doing that and we shall get into that in part 2.