Hi all I took the training which we published on GitHub last fall and fleshed it out with more context and details and made it into a devnet learning lab series: https://learninglabs.cisco.com/modules/nso-basics Title of series is "NSO Basics by Cisco IT" and also single lab on NSO python Maagic API: " Hands on with NSO's Python API" https://learninglabs.cisco.com/lab/hands-on-nso-simple-python/step/1 ... View more

For NSO 4.5.x+, is there a way to go to Web UI legacy by default by a change in  ncs.conf?   <webui>     <enabled>true</enabled>     <transport>       <tcp>         <enabled>true</enabled>         <ip>0.0.0.0</ip>         <port>8080</port>       </tcp>       <ssl>         <enabled>false</enabled>         <ip>0.0.0.0</ip>         <port>8888</port>         <key-file>${NCS_DIR}/var/ncs/webui/cert/host.key</key-file>         <cert-file>${NCS_DIR}/var/ncs/webui/cert/host.cert</cert-file>       </ssl>     </transport>     <cgi>       <enabled>true</enabled>       <php>         <enabled>false</enabled>       </php>     </cgi>   </webui> ... View more

Day 1 – Part 1: Context and Culture Previous Posts: Introduction: Free NSO Training Material for Enterprises (By Cisco IT) Introduction Before jumping into the details of NSO and how to use it, it is helpful to step back and look at what is meant by automation in general. Also it is very important to see NSO and automation as not merely a technological shift in tools, but also a cultural shift in thinking about problem solving and troubleshooting processes. Lifting and shifting your existing architectures, business processes and people into NSO or any automation platform is a recipe for headache and inefficiency. What is outlined in this post is not meant to be the end of the discussion regarding this shift, but rather to start the discussion and provide some contextual clues so that you can be asking the right questions. Context The slide below (credit to Brandon Black for creating it) is a helpful visualization of three ways of categorizing automation efforts: Ad-hoc / Scripting, Re-usable Frameworks and Orchestration. Some quick examples, in case the slide is not clear for each category are: Ad-hoc scripting : a standalone python file, or series of files which has statically defined inputs and outputs, often has passwords and commands statically defined for a specific use case. Common libraries used: Paramiko, Netmiko, pexpect. Re-usable frameworks : something along the lines of “insert your code here” or abstracting the complexity of coding, but still requiring moderate development work. Examples: Ansible, Ansible Tower/AWX, Django, company specific code standards. Orchestration : An application on a server maintains the state of the network and users use the platform to enact desired outcomes. Examples: NSO, ACI, DNA-C/APIC-EM What we are saying here is that every effort to automate the network can be categorized into one of these categories. There may be exceptions or other categories that come up over time, but this is our humble effort to try and provide some nomenclature around categorically different ways of automating the network. First off, there is a place for all three types of automation. This is not to say all automation needs to be orchestration, and none should be ad-hoc scripting. This is more to say that the maturity of a given automation can be evaluated by: How adaptable the automation is to varying inputs and output. How easy the code is to maintain and change. How easy the automation is to integrate into other platforms How much work is needed if any change to the use case is needed The level of detail needed to specify an intended outcome (intent based networking) Feel free to chime in the comments if you have any other criteria you have found useful in differentiating between types of automation! (I know these examples are focusing on configuration compliance rather than real-time monitoring and other operationally needed functions) One last thing to note is that NSO enables all three categories of automation. Obviously NSO is a powerful and robust multi-vendor orchestrator (hence the “O” in NSO). However, NSO provides out of box functionality to make scripting easier. Users can create standalone python, Java or REST based apps which read and write to the NSO APIs, making transactional changes to any piece of the configuration NSO has stored. NSO also provides bash commands which auto-generate package skeletons, making developing relatively trivial. By using NSO for ad-hoc scripts, it also bakes in the ability to rollback and keep track of changes since all API calls to NSO are logged in the rollback log. Culture In an enterprise context sometimes moving toward an automation platform for end-to-end configuration management can be a cultural and mind-set shifting issue as much as it is a technological one. It will take time to convince key business and technical decision makers of the value of moving to something like NSO. Here are some common objections we have heard from engineers when asked to learn NSO or automation skills in general: I am too busy to automate, or learn/practice automation skills I do not know where to start I get stuck setting up my environment I get interrupted when I finally get time to try I don’t see how I can automate this task, it is just easier to do it manually, since I know that will work There seems to be too many competing platforms (ansible, NSO, python, etc.), I don’t know which one to use I know how to use bash/SNMP/python/perl scripts, I don’t need anything more complex Most of these are valid concerns. One big thing for engineers to think about is that the skillset of a network engineer is changing. Cisco (along with most vendors) are moving to software-defined everything. This is not to say there is no place for the CLI or traditional certifications are less valuable. Rather it is to say that the coming years will include an expectation that engineers understand programmability at a basic to intermediate level in order to fully unlock the cool and new features on network devices. Routing and switching is still critical information, but being able to create a predictable, uniform and scalable network is quickly becoming an industry expectation, just as compute has done ten years ago. In contrast to the previous objections, here are some guiding statements that we found helpful as we have undergone this journey: Carve out time in your week where you can learn and practice the skills without interruption (no cell phone, no jabber/spark/email, etc.) Have a humble and teachable attitude, being patient while adjusting to the learning curve Teach others what you are learning to reinforce the concepts Pick a very small task to start with Read lots of examples and follow the logic Consider not only the problem at hand, but the business process around it Don’t be afraid to ask others for help if you get stuck Use version control (git) and do not hard code passwords in code Actively seek to apply your skills to your daily job Write code / templates with readability and reusability in mind Feel free to chime in with your own tips as well! ... View more

Introduction and Motivation I am in Cisco IT’s Network Team which supports our company’s Campus and Branch Cisco offices. We manage hundreds of sites and thousands of devices, including WAN connectivity, wireless, and ACL management for our partner and extranet sites. The scope of our responsibility is huge and humbling to think about how many depend on our team’s work. Over the past year we have begun learning Cisco/Tail-F’s NSO product and how to apply it to an Enterprise context. Most of the examples which are shared are for Service Provider Customers, especially the iconic L2 VPN Service Example (for those who have read the documentation). In order to scale out our development effort, we created a five-day training curriculum to help teach our (Cisco IT’s) traditional network operators, many of them with no coding background, how to use and develop services in NSO. Our goal and hope in sharing this content is for others to realize the benefit of NSO, as we are beginning to do so. One of the strengths (and weaknesses) of NSO is its flexibility. It is incredibly powerful and extensible. The labs and examples we give in our training were ones we thought up based on simple Enterprise situations and we hope that not only the lecture content inspires others, but also the lab content creates an excitement of the art of the possible. Structure of the Content                   The structure of the content was based on our five-day training: Day 1: What is NSO? Using NSO GUI/CLI Day 2: XML & Yang Day 3: Basic Services Day 4: Advanced Services Day 5: Python with NSO The amount of content is somewhat overwhelming, but taken at bite sized pieces, it is not too bad. Our training assumes no background in NSO, Yang or XML. The concepts are reinforced through the labs, and to really internalize how NSO works, working through the labs is required. All of our labs assume using NSO 4.4 and cisco-ios NED of 5.2. You can complete most of the labs with just a netsim and NSO, but having a real live Cisco IOS device is helpful. Here is a link to the training material: GitHub - NSO-developer/nso-5-day-training This will be the first in a series of blog posts meant to unpack our training, and share it in blog form, rather than just a monolith MS Power Point file. ... View more