New knowledge base articles in For Developers

Data Center Knowledge Base

alexstev — Tue, 01 Jun 2021 18:06:50 GMT

Data Center Knowledge Base

For one-on-one help with these products, you can open a ticket at https://developer.cisco.com/site/support/. For other products, please contact Cisco TAC at https://www.cisco.com/c/en/us/support/index.html

Data Center

Start

Data Center Dev Center - on Cisco DevNet
Cisco Data Center - Cisco Ecosystem Exchange
Data Center Automation - Infrastructure as Code in the Modern Data Center - on DevNet
Data Center - DevNet Code Exchange
Data Center - DevNet Automation Exchange

Learn

Data Center Networking - Cisco Blogs
Cisco Certified DevNet Specialist - Data Center Automation and Programmability - Certification
Automating and Programming Cisco Data Center Solutions - Exam Overview and Topics
Developer Data Center - Cisco Community forums
Data Center - Cisco Community forums
Cisco Data Center Network Manager - Releases / Documentation

Collaboration Management Knowledge Base

Paul Zimmerman — Mon, 24 May 2021 14:34:26 GMT

Collaboration Management Knowledge Base

Administrative XML (AXL)

Start

AXL on DevNet
AXL Docs - DevNet

Learn

Administrative XML (AXL) Developer Cookbook
AXL Forum - Cisco Community forums
Administrative XML (AXL) - DevNet Developer Support

Cisco Emergency Responder (CER)

Start

CER Get Started - Cisco DevNet
CER Overview - DevNet

Learn

Cisco Emergency Responder (CER) API Documentation - Cisco DevNet
CER Datasheets - DevNet

IOS XE VoIP

Start

IOS XE - Cisco DevNet
Cisco IOS XE Sandboxes - DevNet

Learn

Programmability Guide for Cisco IOS XE Unified Communications VoIP Products - Cisco DevNet
IOS XE Programmability - DevNet Learning Labs

Platform Administrative Web Services (PAWS)

Start

PAWS - Get Started - Cisco DevNet
PAWS Home - DevNet
PAWS Overview - DevNet

Learn

PAWS API Reference - Cisco DevNet
Build a Development Lab for PAWS - DevNet

UC Manager Serviceability (SXML)

Start

What is Unified CM Serviceability? - Cisco DevNet
SXML - DevNet

Learn

SXML - Getting Started - Cisco DevNet
Developer Collaboration (including SXML) - Cisco Community forums
UC Manager Serviceability (SXML) discussions - DevNet Developer Support

User Data Services (UDS)

Start

UDS - Get Started - Cisco DevNet
What is UDS? - DevNet
Why Use UDS? - DevNet
How Does UDS Work? - DevNet

Learn

UDS - How To - Cisco DevNet
Download the XML Schemas
Run the Sample App
Review the How to Articles - tips and tricks for working with UDS
Learn How to Build a Development Lab for UDS
UDS Developer Forums - Cisco
Explore the UDS APIs with a browser plug-in
Review the API Reference Guide - information about UDS including authentication, detailed descriptions, and example requests and responses.
Browse the Developer Guide - Comprehensive documentation including troubleshooting information
Subscribe to the UDS blog for updates

Networking Automation and Analytics Knowledge Base

alexstev — Wed, 05 May 2021 16:38:10 GMT

Networking Automation and Analytics Knowledge Base

Networking Automation and Analytics - Make Network Automation simple with the community.

Start

Automating Webex Teams (Python) - Leverage your favorite automation tools to incorporate Webex Teams REST APIs.
NSO Basics for Network Automation - Learn network programmability and Next Generation Orchestration using Cisco’s Network Service Orchestrator through theory and practice. Easily automate any networking vendor’s infrastructure at scale and see how NSO provides an incomparable API into both legacy CLI devices and RESTCONF/YANG model devices.
IOS-XR CLI Automation - Cisco IOS-XR offers a comprehensive portfolio of APIs at every layer of the network stack, allowing users to leverage automated techniques to provision and manage the lifecycle of a network device.
Cisco SD-WAN with Ansible - Learn the basics of SD-WAN automation with Ansible.
Using NAPALM for Network Automation - Accomplish network automation and device management with NAPALM.
Networking 101 - Learn coding basics for Networking.
EN Networking - Build Apps with Cisco DNA Center Platform Solutions.
DC Networking - Explore Application Centric Infrastructure (ACI) programmability options and explore data center APIs.

Learn

Cisco DevNet Learning Labs (Automation) - All DevNet Learning Labs tagged with the keyword 'Automation'
Cisco DevNet Learning Labs (Analytics) - All DevNet Learning Labs tagged with the keyword 'Analytics'
DevNet Automation Exchange - DevNet Automation Exchange provides shared code repositories for network automation and guides teams through their journey with a walk-run-fly methodology.
DevNet Automation Bootcamp - an intensive, 9-day course delivered over 6 weeks for a team of up to 12 learners. This schedule gives your team time to absorb the new material they’re learning as they apply it to your infrastructure and business needs.
Networking Dev Center - Learn how you can integrate with the network through full system management solutions in the cloud, utilize automation platforms and controllers, or directly interact with devices with APIs and Interfaces.

IDEs - an Integrated Development Environment (IDE) is a software package available for download and use that can help simplify the development process. IDEs integrate many of the common tasks in software development to enable rapid application development.

PyCharm - an IDE with full support for Python, as well as for HTML, CSS, JavaScript, Node.js and more.
Komodo - another IDE with full support for Python, as well as Go, Perl, Ruby and more.
VS Code - Visual Studio Code is technically not an IDE. It's a lightweight but powerful source code editor which runs on your desktop and is available for Windows, macOS and Linux. It comes with built-in support for several programming languages and has a rich ecosystem of extensions for other languages and runtimes.

SDKs - a software development kit (SDK) differs fundamentally from an IDE. An SDK is a set of functions, packages, documentation and programs required for development on a specific platform or technology, whereas an IDE can be thought of as providing tools for application development using a specific language or technology.

Sandboxes - Cisco and Networking are practically synonymous! The Sandbox offers many networking labs with SDN controllers or API driven network gear!

Networking Sandbox Highlights - on Cisco DevNet
Explore ALL Networking Sandboxes - on DevNet

Learning Labs - just like our Sandboxes, the Learning Labs on Cisco DevNet are FREE to use!

Networking Labs - all of the Networking Learning Labs on Cisco DevNet
Network Programmability for Network Engineers - Learning Track on DevNet

Cisco Modeling Labs - Cisco Modeling Labs (CML) is our premier platform for network simulation. With an easy-to-use HTML5 UI and a comprehensive API, Cisco Modeling Labs makes it fun to design, test, troubleshoot, and learn.

Cisco Modeling Labs - on Cisco DevNet

Postman - Postman can be utilized to build and test APIs. In the context of network programmability where an API is already constructed and ready to be followed, administrators and developers can utilize Postman to debug code and test REST calls that need to be made. Postman also offers a browser extension for Google Chrome, available within the Chrome Web Store. There are similar easy-to-use tools like Insomnia and Paw that are popular as well.

Postman - collaboration platform for API development
Cisco DevNet Postman Collection - DevNet's Postman collection, which is hosted on Postman site

VIRL - Cisco Virtual Internet Routing Lab (VIRL) is an extensible network virtualization platform that enables the development of high-fidelity models of real or planned networks. VIRL includes current virtualized versions of Cisco network operating systems and allows integration with 'real' physical / external networks, network elements, and servers.

VIRL - get VIRL, deploy VIRL, as well as tutorials and resources.

Cisco Active Advisor - Cisco Active Advisor simplifies network discovery and finds security alerts that apply to your devices. It also analyzes contract coverage and end-of-life status, and can compare your network against Cisco Validated Designs. Best of all, it's free.

Cisco Active Advisor - Reduce network risk and boost security for free

Cisco Network Assistant - Cisco Network Assistant is a PC-based network management application optimized for wired and wireless networks for growing Small-Medium sized businesses. Cisco Network Assistant provides a centralized network view with a user-friendly GUI that simplifies configuration, management, and troubleshooting.

Cisco Network Assistant - Using Cisco Network Assistant, network administrators can easily apply common services, generate inventory reports and synchronize passwords across Cisco switches, routers, wireless LAN controllers, and access points.

Cisco Bug Search Tool - The Cisco bug tracking system maintains a comprehensive list of defects and vulnerabilities in Cisco products and software.

Cisco Bug Search Tool - Bug Search is a web-based tool that acts as a gateway to the bug tracking system and provides you with detailed defect information about your products and software.

Cisco Internetworking Troubleshooting Tools

Troubleshooting Tools - information about the wide variety of tools available to assist you in troubleshooting your internetwork. This includes information on using router diagnostic commands, Cisco network management tools, and third-party troubleshooting tools.

Docs

Network Management System: Best Practices White Paper (2018)
Cisco Guide to Harden Cisco IOS Devices (2020)

External Resources

Best Cisco Monitoring Tools for Network Performance and Routers - Tools for monitoring Cisco networks

Networking Tools Knowledge Base

alexstev — Wed, 05 May 2021 16:36:56 GMT

Networking Tools Knowledge Base

Networking Tools - Making a Network Engineer's life easier. Work smarter.

Start

Networking 101 - Learn coding basics for Networking.
EN Networking - Build Apps with Cisco DNA Center Platform Solutions.
DC Networking - Explore Application Centric Infrastructure (ACI) programmability options and explore data center APIs.

Learn

Networking Dev Center - Learn how you can integrate with the network through full system management solutions in the cloud, utilize automation platforms and controllers, or directly interact with devices with APIs and Interfaces.

IDEs - an Integrated Development Environment (IDE) is a software package available for download and use that can help simplify the development process. IDEs integrate many of the common tasks in software development to enable rapid application development.

PyCharm - an IDE with full support for Python, as well as for HTML, CSS, JavaScript, Node.js and more.
Komodo - another IDE with full support for Python, as well as Go, Perl, Ruby and more.

SDKs - a software development kit (SDK) differs fundamentally from an IDE. An SDK is a set of functions, packages, documentation and programs required for development on a specific platform or technology, whereas an IDE can be thought of as providing tools for application development using a specific language or technology.

Sandboxes - Cisco and Networking are practically synonymous! The Sandbox offers many networking labs with SDN controllers or API driven network gear!

Networking Sandbox Highlights - on Cisco DevNet
Explore ALL Networking Sandboxes - on DevNet

Learning Labs - just like our Sandboxes, the Learning Labs on Cisco DevNet are FREE to use!

Networking Labs - all of the Networking Learning Labs on Cisco DevNet
Network Programmability for Network Engineers - Learning Track on DevNet

Cisco Modeling Labs - Cisco Modeling Labs (CML) is our premier platform for network simulation. With an easy-to-use HTML5 UI and a comprehensive API, Cisco Modeling Labs makes it fun to design, test, troubleshoot, and learn.

Cisco Modeling Labs - on Cisco DevNet

Postman - Postman can be utilized to build and test APIs. In the context of network programmability where an API is already constructed and ready to be followed, administrators and developers can utilize Postman to debug code and test REST calls that need to be made. Postman also offers a browser extension for Google Chrome, available within the Chrome Web Store. There are similar easy-to-use tools like Insomnia and Paw that are popular as well.

Postman - collaboration platform for API development
Cisco DevNet Postman Collection - DevNet's Postman collection, which is hosted on Postman site

Cisco Active Advisor - Cisco Active Advisor simplifies network discovery and finds security alerts that apply to your devices. It also analyzes contract coverage and end-of-life status, and can compare your network against Cisco Validated Designs. Best of all, it's free.

Cisco Active Advisor - Reduce network risk and boost security for free

Cisco Network Assistant - Cisco Network Assistant is a PC-based network management application optimized for wired and wireless networks for growing Small-Medium sized businesses. Cisco Network Assistant provides a centralized network view with a user-friendly GUI that simplifies configuration, management, and troubleshooting.

Cisco Network Assistant - Using Cisco Network Assistant, network administrators can easily apply common services, generate inventory reports and synchronize passwords across Cisco switches, routers, wireless LAN controllers, and access points.

Cisco Bug Search Tool - The Cisco bug tracking system maintains a comprehensive list of defects and vulnerabilities in Cisco products and software.

Cisco Bug Search Tool - Bug Search is a web-based tool that acts as a gateway to the bug tracking system and provides you with detailed defect information about your products and software.

Cisco Internetworking Troubleshooting Tools

Troubleshooting Tools - information about the wide variety of tools available to assist you in troubleshooting your internetwork. This includes information on using router diagnostic commands, Cisco network management tools, and third-party troubleshooting tools.

Docs

Network Management System: Best Practices White Paper (2018)
Cisco Guide to Harden Cisco IOS Devices (2020)

External Resources

Best Cisco Monitoring Tools for Network Performance and Routers - Tools for monitoring Cisco networks

IoT Knowledge Base

Paul Zimmerman — Thu, 22 Apr 2021 20:54:11 GMT

IoT Knowledge Base

For one-on-one help with these products, you can open a ticket at https://developer.cisco.com/site/support/. For other products, please contact Cisco TAC (tac.cisco.com).

Internet of Things (IoT)

Start

Learn

Sandbox Remote Labs - IoT
Cisco Code Exchange - Cisco IoT
DevNet Automation Exchange - IoT
Edge Compute and Software
- Cisco Edge Intelligence
- IOx

Networking
- Cisco IPv6 Mesh
- Industrial NetDevOps
Security
- Manufacturer Usage Descriptions (MUD)

Certifications

Exam

Developing Solutions Using Cisco IoT and Edge Platforms (300-915 DEVIOT)

Courses and Exam Prep

IoT APIs

IOx - Host applications on Cisco hardware, including container-based deployments.

Cisco IPv6 Mesh - Create a communication network overlay for the electric distribution grid to enable street lighting, connectivity to solar or wind power, on-demand metering, and other smart city use cases.

Control Center - Automate connectivity management, deployment, and track activity for all your connected devices.

Cisco Kinetic - Integrate data routes with fog application data, extract data from data pipes with connectors, and move or keep categorized data with policies.

Cisco Kinetic for Cities - Aggregate and organize data from city infrastructure sensors and other data sources in a consistent format.

Manufacturer Usage Description - Facilitate device visibility and segmentation of IoT devices by defining the corresponding behaviors for that device.

Cisco Community Forums

Docs

YANG Tools Knowledge Base

alexstev — Wed, 05 May 2021 16:40:05 GMT

YANG Tools Knowledge Base

For one-on-one help with developer products, you can open a ticket at https://developer.cisco.com/site/support/. For other products, please contact Cisco TAC (https://www.cisco.com/c/en/us/support/index.html).

YANG Tools - You can use these YANG tools to deploy, configure, monitor, and troubleshoot.

1. YANG Suite - a set of tools related to YANG models and related technologies such as NETCONF

Cisco YANG Suite GitHub Repo
The Wait Is Over: Cisco YANG Suite Is Here! - Cisco Blogs
YANG Suite - Documentation on Cisco DevNet
yangsuite-support-ext@cisco.com - YANG Suite external mailer

2. YANG Development Kit - a Python SDK generated from YANG data models.

YANG Development Kit - on Cisco DevNet
YANG Development Kit - Cisco DevNet's GitHub Repository (Python)

3. ncclient - a Python library that facilitates client-side scripting and application development around the NETCONF protocol.

ncclient - official GitHub Repository

4. pyang - a YANG validator, and code generator, written in python.

pyang - official GitHub Repository

5. yang.connector - a package containing collections of tools to test YANG models via NETCONF and RESTCONF protocols.

yang.connector - Documentation on Cisco DevNet

6. yang-explorer- an open-source Yang Browser and RPC Builder Application to experiment with Yang Data Models

yang-explorer - on Cisco Code Exchange

Cisco Community Forums

YANG Tools

Docs

YANG Tools - on Cisco DevNet
GitHub Repos - List of YANG-related repositories on the official Cisco DevNet GitHub page.
APIs - Model Driven Programmability with YANG (for NX-OS)

External Resources

YANG Tools - Repository of YANG Tools on the OpenDaylight Wiki

Difference between USGMII and USXGMII and why USGMII is better than SGMII/QSGMII

Paul Zimmerman — Wed, 10 Mar 2021 03:18:34 GMT

Difference between USGMII and USXGMII:

USGMII is used for 8x10M/100M/1GE network ports, with each port maximum speed of 1GE. USXGMII-Single Port version can be used to support ONE network port with 10M/100M/1G/2.5G/5G/10G data rates
USGMII is used for 10M/100M/1G network port speeds, while USXGMII support 10M/100M/1G/2.5G/5G/10G.
There are two types of USXGMII: USXGMII-Single Port and USXGMII-Multiple Ports.
USGMII and USXGMII provide the same capabilities using the packet control header.

Why USGMII is better than SGMII/QSGMII:

SGMII supports a single 10M/100M/1G network port over 1,25Gbps SERDES between MAC and PHY, while QSGMII supports four 10M/100M/1G network ports over 5Gbps SERDES between MAC and PHY.
USGMII supports eight 10M/100M/1G network ports over 10Gbps SERDES between MAC and PHY. This is most critical for high density switches and PHY. USGMII also provides packet control header to pass control/status between PHY and MAC. One of the application is Time-Stamp for PTP and 802.1AS.

Contact Center Knowledge Base

Paul Zimmerman — Mon, 26 Apr 2021 19:33:33 GMT

Contact Center Knowledge Base

The Contact Center knowledge base contains information about developer topics for Finesse and Task Routing. For one-on-one help with these products, you can open a ticket at https://developer.cisco.com/site/support/. For other products, please contact Cisco TAC (support.cisco.com).

Finesse

Start

Finesse REST API

Documentation 101: How to read the table

Finesse JavaScript API

Learn

Task Routing

Start

Learn

DevNet Sandbox

Webex Developer resources

Dirk-Jan Uittenbogaard — Thu, 06 May 2021 07:45:53 GMT

Welcome!
To my Webex Developer resource overview

Like it?
Please scroll to the end and click the 'Helpful' button!

Contribute?
Something I should add? Let me know in the comments!

QUICK ACCESS TO THIS PAGE: cs.co/webexdevinfo

NEW: LinkedIn Webex Developer group cs.co/webexdevlink news/tips/announcements/&more

GENERIC

DOCS & TRAINING

Webex Developer Portal
Developer blog
What's New
Admin API
Developer support GREAT!
Developer Support / portal
Awesome Webex GREAT!
Youtube integration videos
Communities
Webex Ambassador group
DevNet Webex Teams
Community Developer / Partner

Developer Portal
Bots
Integrations
Widgets
Guest Issuer

Getting Started
guide - Admin
guide - Compliance
guide - Webhooks
guide - Hybrid
API change-log

Change calendar LIKE

Learning Labs GREAT!
DevNet Webex API tracks
DevNet Collaboration Dev Center
Training: Python for Everyone  GREAT!
Firewall traversal
Teams Buttons & Cards school LIKE!

Cisco Live Collab Dev session list

EXAMPLE CODE

USE CASES & EXAMPLES

Teams Space archiver v2 (video)
Python oAuth basic example
Python Translate bot
EURL.io Space Member code on Github
[PHP] Webex Teams API
Browser SDK examples
Widget examples
IoT & Raspberry to Wx Teams part 1 / part 2 NodeJS oAuth example
Webex Buttons and Cards School
OVERVIEWS
Starter Kits (open source)
DevNet Creations
Cisco Code Exchange
DevNet Github
Search Github 'webex teams'

DevNet Creations
Cisco Code Exchange
Youtube Channel: Webex Teams Integrations

Video problem reporting to Wx Teams
Hospital wait times
Webex Teams articles by WWT (partner)
Webex App Hub

UCS Director integration
App: Talk 2 Webex Teams mobile app for audio/video/TTS

WIDGETS & SDK

LIBRARIES & FRAMEWORKS

Widget Documentation
Widget Learning Labs

SDK iOS /   Android
SDK Browser   /   NodeJS
SDK JAVA / Community
SDK Learning Labs

SDK example (TestFlight) ^LIKE

Python webexteamssdk - support

FRAMEWORK
Webex Node Bot framework ^LIKE
Node.JS bot framework (ObjectIsAdvantag)
Flint & Node.JS framework (nmarus) |
Botkit framework (template / examples)
  lab: create teams bot
  lab: create conversational bot
Python Webex Teams bot framework
LIBRARY
Python Teams library (brbester)
...more in 'awesome webex'

TOOLS

DEVELOPMENT TOOLS

Teams Power Pack
Space Archiving tool GITHUB
Teams Forms
Video System Status browser
WebSocket Events link

Postman Collections
DevNet Collaboration Sandboxes
Webex Teams API Emulator
Deactivate Bot & Integration tokens
Node-red integration
Webhook Proxy (github)

Tool: Postman
Editor: Atom
Editor: Notepad++

INTEGRATION PLATFORMS

WEBEX MEETINGS

Built.io link
Zapier link
Gupshup link
IFTTT link
Botkit.ai link
+ Sameroom.io, Workato, Zenbot.io,
No native Teams integration, but usable with API's:
Flow XO, Elastic.io, APIANT, Integromat

Meeting API - get started
Meetings DevNet site
Meetings API Support
Meetings Community

xAPI

DOCUMENTATION

xAPI command reference (all releases)

xAPI REST documentation
roomos.cisco.com: xAPI guides

roomos.cisco.com: xAPI reference

roomos.cisco.com: xAPI examples
Customization Guides
CE software release notes PDF
RoomOS what's new

Awesome xAPI GREAT!
Room Devices on DevNet
Room Device Macro examples

Video Unit sandbox
xAPI Support (Webex Space)

GITHUB
- Video System Status Monitor
- Meeting Feedback
- Javascript xAPI library

- Virtual Background Logos new

Getting Started
xAPI introduction LAB
xAPI In Room controls LAB (try editor)
xAPI Macro tutorial PDF
xAPI examples

TOOLS
Postman collection

LEARN
CE customization lab
Create custom in-room controls lab
Customizing devices from code lab
Introduction to XAPI lab
Exploring XAPI Macros lab

CISCO LIVE SESSIONS

Zero to Hero - programmability course ^NEW

BRKCOL-3008 - Custom.&Integrations Room Devices

BRKDEV-3244 - Advanced coding for Video devices
DEVNET-2071 - Customizing Collaboration Devices
DEVNET-1462 - Webex Room APIs: "the power of..."

NEW: LinkedIn Webex Developer group cs.co/webexdevlink

CHANGELOG

April 2021 - added LinkedIn group URL, added virtual-background link
November 2020 - major overhaul of page
July 2020 - adding xAPI resources
Dec 2019 - updated links
July 2019 - Added some xAPI links
July 2019 - Complete re-write of this page (was needed
xpost in Collaboration / Collaboration documents here

How to enable ztp on IOS-XE sandbox

Chris Dixon — Tue, 27 Oct 2020 13:38:00 GMT

Symptoms

I'm using the devnet IOS-XE sandbox to try and test the ZTP feature, however I can see that when I ssh into the fresh box it already has a startup config and hence I dont think it will attempt to ztp on reboot. How do you get the lab IOS-XE device into a state to be able to test ZTP?

How to debug NSO service/action with Pycharm pro

Rodolphe Trujillo — Fri, 18 Sep 2020 18:19:59 GMT

Step 1 : configure debug server in Pycharm

Go to Run => Edit Configurations, click on "+" => Python Remote Debug

In "Local Host name " enter ip or host name of your local machine. Enter a available port in "Port :"

Give a name, here it's "NSO debug".

Click ok.

Step 2 : install pydevd_pycharm

The debug tool uses pydevd-pycharm library to attach to the local debug server we just created.

Run

python -m pip install pydevd-pycharm

with the python interpreter used by NSO.

Step 3 : run debug server

Select NSO Debug and click on the green bug (or Shift + F9).

The debug server is now listening on port 8885

Step 4 : call the server from the service/action thread.

Insert the following code in the callback function of the service/action (change host and port) :

import pydevd_pycharm
pydevd_pycharm.settrace('host', port=port, stdoutToServer=True, stderrToServer=True)

That's all , now the service/action callback will try to reach the debug server (don't forget to do a packages reload)

You can now debug with pycharm :

And have full information about the variables :

NSO Developer Days 2019: Nano Services – Another approach for Reactive Fastmap (RFM) services

Jan Lindblad — Fri, 18 Sep 2020 18:19:58 GMT

Abstract: RFM services can be hard to implement. Especially the lifecycle management of the delete case of the service can be a challenge. Nano Services uses an executable plan and kickers to supports the full lifecycle of a RFM service.

Speaker: Try Ryeng

deleted

peter8498 — Mon, 17 Aug 2020 08:24:10 GMT

Trying sandbox for WLC 9800 but timing out

carlocon — Fri, 24 Apr 2020 19:57:12 GMT

Hi team,

Starting to work with some of the sandboxes on this site, as a Wireless engineer I wanted to start with the WLC 9800 sandbox that is always on. Basically wanted to try APIs to read telemetry, however after reading the instructions I have tried several times to access a link to accept a "certificate" from a link wlc9800.cisco.com and always timing out. I have tried being out of the VPN or in but no result on any case. Since this is one of my first attempts I am wondering if I am missing something or doing something wrong, since the instructions for SandBoxes always on according to documentation don't require VPN access. Let me know your comments please

Regards
Carlos Contreras

Determining if a endUser password/pin is locked

stephan.steiner — Tue, 31 Mar 2020 15:37:39 GMT

I'm tasked with providing a credential unlock for CUCM endusers. Looking at the AXL schema and doing some trial & error I found that pinCredentials.pinResetHackCount / passwordCredentials.pwdResetHackCount is what I'm looking for.. setting this to true in a user update resets the history. But, extracting the user, it seems I'm missing some properties that are visible in ccmadmin. So, given that locking yourself out by trying the wrong credential for too many times does not set any property gettable by AXL, the question is: how can I know if a user's pin or password credential has been locked?

The same seems to be possible via CUPI. There's the "Hacked" property that if true means the user has been locked out for trying an incorrect credential too many times.

'Devices on rent' kind of services

Temmokan — Fri, 28 Feb 2020 03:28:20 GMT

Hello,

We are developing a network monitoring piece of software. To create monitoring presets, we would need to actually access a number of Cisco devices (via HTTPS/SNMP), within a sandbox environment.

I noticed there are several 'Cisco devices on rent' kind of services on the Net, but still waiting for response from them. Are there any well-known 'devices on rent' kind of services, with Cisco devices available?

Thanks.

CUCM Sandbox Version 12.5 - automatic deletion after 5 days

Thomas Biesterfeldt — Fri, 31 Jan 2020 16:40:16 GMT

Dear all,

our development Team is facing a Problem with the CUCM sandbox.

Everything in the sandbox is getting completely deleted after 5 days.

This is a big Problem for us, because we'd like to use the test Environment für a longer period of time.

What do we have to do so that the data is not being deleted?

Thank you very much in Advance for your support!

Best regards,

Thomas

NX-OS versions via APIC API

bdbauer — Thu, 23 Jan 2020 20:08:20 GMT

I'm able to pull the topology using the API GET

https://n.n.n.n/api/node/mo/topology/pod-1.json?query-target=children&target-subtree-class=fabricNode

(after authenticating and getting a cookie, of course)

But the version field is empty. I don't see a way to get the version of our NX-OS switches via APIC REST API. Is this something that can be done via API?

NSO and Network Management Datastore Architecture (NMDA)

Akira Iwamoto — Wed, 19 Aug 2020 01:59:32 GMT

NSO as the sample implementation of new technology

Cisco NSO is a product implimenting RFC 6020 (yang) faithfully, and we could use it for testing new in the automation technology before even going on implementing ourselves. The author of the RFC is also developing the product, and it is one of the software leading the industory.

From NSO 5.3, RFC 8342 Network Management Datastore Architecture (NMDA) has been implemented, and this article shows the rough introduction using NSO.

The all won't be explained, but the below are related RFCs.

Yang
- RFC 6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
- RFC 7950 The YANG 1.1 Data Modeling Language
- RFC 8342 Network Management Datastore Architecture (NMDA)
Netconf
- RFC 6241 Network Configuration Protocol (NETCONF)
- RFC 8526 NETCONF Extensions to Support the Network Management Datastore Architecture
Restconf
- RFC 8040 RESTCONF Protocol
- RFC 8527 RESTCONF Extensions to Support the Network Management Datastore Architecture

IETF Yang has been also updated refrecting NMDA. Here's the RFCs for it.

IETF Yang implementation

RFC 8343 A YANG Data Model for Interface Management
RFC 8344 A YANG Data Model for IP Management
RFC 8345 A YANG Data Model for Network Topologies
RFC 8346 A YANG Data Model for Layer 3 Topologies
RFC 8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)
RFC 8348 A YANG Data Model for Hardware Management
RFC 8349 A YANG Data Model for Routing Management (NMDA Version)

About Network Management Datastore Architecture

Network Management Datastore Architecture (NMDA) has been introduced since NSO 5.3, and it is described in RFC 8342. This gives new ideas of datastores we have been using, and it is meaningful to know about it. New datastores are added, and the usage of existing datastore is changed. NMDA is based on RFC 7950 (Yang 1.1), and reading RFC 8342 needs the knowledge from it as well.

RFC 8342 Section 5 gives the relations between datastores in a diagram. Previous model is in Section 4.

     +-------------+                 +-----------+
     | <candidate> |                 | <startup> |
     |  (ct, rw)   |<---+       +--->| (ct, rw)  |
     +-------------+    |       |    +-----------+
            |           |       |           |
            |         +-----------+         |
            +-------->| <running> |<--------+
                      | (ct, rw)  |
                      +-----------+
                            |
                            |        // configuration transformations,
                            |        // e.g., removal of nodes marked as
                            |        // "inactive", expansion of
                            |        // templates
                            v
                      +------------+
                      | <intended> | // subject to validation
                      | (ct, ro)   |
                      +------------+
                            |        // changes applied, subject to
                            |        // local factors, e.g., missing
                            |        // resources, delays
                            |
       dynamic              |   +-------- learned configuration
       configuration        |   +-------- system configuration
       datastores -----+    |   +-------- default configuration
                       |    |   |
                       v    v   v
                    +---------------+
                    | <operational> | <-- system state
                    | (ct + cf, ro) |
                    +---------------+

     ct = config true; cf = config false
     rw = read-write; ro = read-only
     boxes denote named datastores

Datastores defined in RFC 6020 / 6241

RFC 6020/6241 has defined the datastores are referred from the datastores used in network devices at the time. Today, the below datastores are still been actively used in many routers and switches.

startup
candidate
running

Startup datastore has configurations that is loaded when the device is booted up. Running datastore includes configurations that is currently running used on the device. Each session can have own candidate datastore on memory, and when commiting it, finally it's copied to running.

Data can be in two categories, configuration data and operational data. System becomes to the specific state with specific configuration data, and systems become always to the same state when the same configuration data is used. Operational data is something generated at runtime including like interface stats or VRRP state that users are not meant to configure.

On Yang model, "config" flag tells if the node is configuration or operational.

Configuration data
- config true
Operational data
- config false

Additions by RFC 8342 (NMDA)

Datastores are added as like the below. Operational may make misunderstanding, but this is not for "config false" data.

Datastore	Read/Write	Tag
startup	R/W	<startup>
candidate	R/W	<candidate>
running	R/W	<running>
intended	R	<intended>
operational state	R	<operational>

startup/candidate/running

There's no much differences when using startup, candidate and running datastores, however running datastore may not have some configurations that previously existed. For example, default configuration is not included.

Configuration example	description
inactive	inactive attribute can be added to configurations, and that config is not copied to intended datastore.
template-mechanism-oriented	The config is like a macro configuration, and the actual content will be expanded (configuration transformation) and set to operational datastore.

inactive would be used when operators want to disable it temporary, for example. They don't want to delete it and just mark the configuration is inactive.

In the example of template-mechanism-oriented, the macro configuration should be enough in running, and the actual content is redundant information. For instance, when config "A" is a template of config "B,C,D", having "A,B,C,D" in running doesn't make sense as the system should know "A" is "B,C,D" and it can calculate itself, so operators should not need to give "A,B,C,D"

In addition, with <intended> datastore explained next, these datastores are called conventional datastore.

intended datastore

Configurations derived from configurations in start/candidate/running datastore, and users can't modify contents on intended datastore. Depending on the configurations, the content of intended datastore is may be same with running datastore. When device is rebooted, the content in intended datastore is re-calculated from running datastore everytime.

It also can be validated at this time. In an example, when running datastore has a configuration with inactive, it's not affected in intended, so validation would work. Operators removes the inactive attributes, however the validation can fail and it cannot be injected into intended datastore.

operational state datastore

This datastore has the all required data to make the device in exactly same state. Because the oper-data (config false) is also included, when this datastore has the same data with another device, those two are behaving same.

This datastore includes other types of configurations like default configuration, learned configuration such as BGP RIB content and system configurations like chassis serial numbers.

Config examples

RFC 8342 Appendix C.2 (bgp configuration)

<running> datastore has the below configurations. BGP is being configured, and local-as, peer-as and peers (neighbors) are listed.

<bgp>
  <local-as>64501</local-as>
  <peer-as>64502</peer-as>
  <peer>
    <name>2001:db8::2:3</name>
  </peer>
</bgp>

We can confirm the all system state in <operational> datastore. If specific config is not found in <running>, origin attributes are set so that we can check where the config is from.

/bgp/peer/local-port is the data that operating system gives when BGP TCP session is created, so origin is system.

/bgp/peer/state is "config false" data, and it's not coming from anywhere, so there's no attributes attached.

<bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
      or:origin="or:intended">
  <local-as>64501</local-as>
  <peer-as>64502</peer-as>
  <peer>
      <name>2001:db8::2:3</name>
      <local-as or:origin="or:default">64501</local-as>
      <peer-as or:origin="or:default">64502</peer-as>
      <local-port or:origin="or:system">60794</local-port>
      <remote-port or:origin="or:default">179</remote-port>
      <state>established</state>
    </peer>
</bgp>

Configurations in <operational> are not modified immediately after users configure on <running>. When BGP peer is removed in <running>, it's removed also from <intended>, however it's not removed in <operational>. bgp needs to shutdown the peer, and tcp needs to close the session, and it takes while. In this case, the modification on <opoerational> happens delayed.

Config examples

RFC 8342 Appendix C.3 (preconfig)

Physical interfaces on routers are added/removed by inserting/removing line cards. Even when <running> has configurations of non-existing interfaces, that cannot be used in the system. However by preparing those in <running> in advance of card insertion, that config is appeared in <operational> when the card is available automatically. This will increase the maintenancebility in enterprises.

<interfaces>
  <interface>
    <name>et-0/0/0</name>
    <description>Test interface</description>
  </interface>
</interfaces>

<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
  <interface>
    <name>et-0/0/0</name>
    <description>Test interface</description>
    <mtu or:origin="or:system">1500</mtu>
  </interface>
</interfaces>

New NETCONF operation

NMDA capable netconf servers can process new operations.

<get-data>

Previously <get-config> for getting configuration data (config true) and <get> for both configuration data (config true) and operational data (config false).

<edit-data>

It used as like the <edit-config> operation. <config> node was previously defined as anyxml when using <edit-config>. As <config> node is anydata for <edit-data> operation, the data can be in JSON, for example.

Usage of RESTCONF for NMDA

"ds" resource has been added to RESTCONF URI, and datastores can be specified as like the below.

For running datastore, GET/POST/PUT/PATCH is available while intended datastore can accept only GET. operational datastore is also readonly, however it can accept also POST for action invocation.

http://..../restconf/ds/ietf-datastores:running/
http://..../restconf/ds/ietf-datastores:intended/
http://..../restconf/ds/ietf-datastores:operational/

NMDA with NSO

NMDA is supported from NSO 5.3, but origin attribute is not supported currently. Let's try the feature.

NETCONF hello

NSO NETCONF Northbound interface responds as the below to <hello> operation. yang-library 1.1 capability is included.

$ netconf-console --hello
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

//snip//

    <capability>urn:ietf:params:netconf:capability:yang-library:1.0?revision=2019-01-04&amp;module-set-id=3f1f4f98aba52a2290a6a29a1a8d9c0b</capability>
    <capability>urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&amp;content-id=3f1f4f98aba52a2290a6a29a1a8d9c0b</capability>

Sample NSO package for NMDA testing

The below simple yang model is created for testing. test1 module has a conatiner "server", and apps are running on it. Each application has a leaf with config false node to have a version information.

module test1 {
  namespace "http://com/example/test1";
  prefix test1;

  container server {
    list app {
      key name;
      leaf name {
        type string;
      }
      leaf version {
        config false;
        type string;
      }
    }
  }
}

app1, app2, app3 and app4 will be created on this example, but let's set app2, app3 and app4 with inactive attribute. On NSO, we can add inactive annotation by deactivate/activate command from CLI, and NETCONF/RESTCONF can accept in normal attribute in nodes.

Creating app1 and app2 from CLI

admin@ncs# conf
Entering configuration mode terminal
admin@ncs(config)# server app app1
admin@ncs(config-app-app1)# server app app2
admin@ncs(config-app-app3)# exit
admin@ncs(config)# deactivate server app app2
admin@ncs(config)# commit dry-run outformat xml
result-xml {
    local-node {
        data <server xmlns="http://com/example/test1">
               <app>
                 <name>app1</name>
               </app>
               <app inactive="inactive">
                 <name>app2</name>
               </app>
             </server>
    }
}
admin@ncs(config)#
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)#

Creating app3 from NETCONF

First, here's the payload for the NETCONF <edit-data> operation. Please note that inactive attribute is added.

$ cat server-app3.xml
<server xmlns="http://com/example/test1">
  <app inactive="inactive">
    <name>app3</name>
  </app>
</server>

Then, netconf-console is used with the xml payload to create app3.

$ netconf-console --edit-data=server-app3.xml
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

Creating app4 from RESTCONF

In the same way, app4 is created with inactive attribute using RESTCONF.

$ cat server-app4.xml
<app inactive="inactive">
  <name>app4</name>
</app>
$ curl -X POST -u admin:admin -H 'Content-Type: application/yang-data+xml' \
http://localhost:8080/restconf/ds/ietf-datastores:running/test1:server \
-d @server-app4.xml
$

Set any data on /server/app/version

/server/app/version is a leaf of config false node. This is supposed to be entered by any app, but in this example, let's set data manually.

$ ncs_cmd -o -c 'set /server/app{app1}/version 1.0'
$ ncs_cmd -o -c 'set /server/app{app2}/version 1.0'
$ ncs_cmd -o -c 'set /server/app{app3}/version 1.0'
$ ncs_cmd -o -c 'set /server/app{app4}/version 1.0'

Status confirmation

So far, we have configured 4 apps in running, however app2, app3 and app4 are at inactive status.

$ netconf-console --get-data --db running -x /server
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <server xmlns="http://com/example/test1">
      <app>
        <name>app1</name>
      </app>
      <app inactive="inactive">
        <name>app2</name>
      </app>
      <app inactive="inactive">
        <name>app3</name>
      </app>
      <app inactive="inactive">
        <name>app4</name>
      </app>
    </server>
  </data>
</rpc-reply>

Next, let's check the intended datastore. As you can see, app2, app3 and app4 are not listed.

$ netconf-console --get-data --db intended -x /server
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <server xmlns="http://com/example/test1">
      <app>
        <name>app1</name>
      </app>
    </server>
  </data>
</rpc-reply>

Then, let's check operational datastore. Please notice that config false data is shown.

$ netconf-console --get-data --db operational -x /server
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <server xmlns="http://com/example/test1">
      <app>
        <name>app1</name>
        <version>1.0</version>
      </app>
    </server>
  </data>
</rpc-reply>

From NCS CLI, we can see running and operational datastore as the below.

admin@ncs# show running-config server
server app app1
!
! Inactive
server app app2
!
! Inactive
server app app3
!
! Inactive
server app app4
!
admin@ncs#

To see the operational datastore, we will look at the operation-state container information. It is populated only when it's configured to do so in ncs.conf as like the below.

<ncs-config xmlns="http://tail-f.com/yang/tailf-ncs-config">
  <cli>
    <nmda>
      <show-operational-state>true</show-operational-state>
    </nmda>
  </cli>
</ncs-config>

Now we can show it in CLI.

admin@ncs# show operational-state server
server app app1
 version 1.0
!
admin@ncs#

Create a 'commserver' for USB Serial console ports with a Raspberry Pi

Emmanuel Tychon — Wed, 10 Feb 2021 16:49:46 GMT

Introduction

As a person working with Cisco's portfolio of IoT products you have probably realized that some new platforms are ditching away the old RJ45-based RS232 serial communication console in favour of the newer USB-based serial communication port. If this a good news for technicians as they are now able to connect a computer straight to the router console using just a mini-USB cable, this is not such a great news for those who need to operate serial connections remotely.

The purpose of a commserver is to map a serial console port to TCP port, so that using Telnet to the commserver one can actually talk directly to the equipment console port. This is very handy to have out-of-band management this way, as it works even when the main network is down, an access-list has been misconfigured, a router is stuck in ROMMON mode and plenty other hair pulling scenario.

With the classic RJ45 serial it was a simple task to use a router with a number of serial lines and connect them to console ports for out of band access. But you can't do that with USB... unless you want to use an active USB-to-RJ45 converter, which is messy and they are not that easy to find.

Proposed Solution

I had an old Raspberry Pi 2B+ lying around that I wanted to leverage, but it only has USB ports. You have four USB ports as standard, but I wanted more therefore added an additional board called UUGear BIG7 USB HUB but I'm sure other alternatives will work equally well. The purpose is really to extend the number of USB ports available from 4 up to 11.

Making serial USB ports predictable and persistent

I have used Raspbian as a base operating system, and on my setup and by default the first USB-to-serial connection will be device /dev/ttyACM0. This is not desirable! What we want is to be able to predict which Cisco device console is connected to which USB port, to map a predictable serial device name and ultimately map it to a specific TCP port. For example, if we connect a gateway console to the first USB, we want to map it to /dev/csco1, and to TCP/2001. We will do this my modifying the udev rules, but first we need to uniquely identify the USB ports.

To identify how your ports are mapped: plug in a Serial USB console and watch using "dmesg" on which port this new serial connection has been mapped. For example in my case it shows ttyACM0:

[16201.694459] usb 1-1.3.1: new full-speed USB device number 17 using dwc_otg
[16201.851950] usb 1-1.3.1: New USB device found, idVendor=05a6, idProduct=0009, bcdDevice= 0.00
[16201.851975] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[16201.851987] usb 1-1.3.1: Product: Cisco USB Console
[16201.851997] usb 1-1.3.1: Manufacturer: Cisco
[16201.883380] cdc_acm 1-1.3.1:1.0: ttyACM0: USB ACM device

Now that I know the device name is ttyACM0, let's check for some unique identifier using:

udevadm info --name=/dev/ttyACM0 --attribute-walk

You should see a long list of attributes but the beginning is what is interesting for us. It could be something like:

looking at device '/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/tty/ttyACM0':
  KERNEL=="ttyACM0"
  SUBSYSTEM=="tty"
  DRIVER=="" 
[...]
looking at parent device '/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.1':
  KERNELS=="1-1.3.1"
  SUBSYSTEMS=="usb"
  DRIVERS=="usb"
  ATTRS{manufacturer}=="Cisco"

Since there can only be one USB driver in 1-1.3.1 this is enough for us to write the rules. Try other ports and see how the numbers are changing, for me this was the first USB port and then it goes 1-1.3.2, 1-1.3.3, ... 1-1.3.7. The udev mapping can be done by editing (or creating) the file in /etc/udev/rules.d/99-usb-serial.rules with the following content:

SUBSYSTEM=="tty",DRIVERS=="usb",KERNELS=="1-1.3.1",SYMLINK+="csco1"
SUBSYSTEM=="tty",DRIVERS=="usb",KERNELS=="1-1.3.2",SYMLINK+="csco2"
SUBSYSTEM=="tty",DRIVERS=="usb",KERNELS=="1-1.3.3",SYMLINK+="csco3"
SUBSYSTEM=="tty",DRIVERS=="usb",KERNELS=="1-1.3.4",SYMLINK+="csco4"
SUBSYSTEM=="tty",DRIVERS=="usb",KERNELS=="1-1.3.5",SYMLINK+="csco5"
SUBSYSTEM=="tty",DRIVERS=="usb",KERNELS=="1-1.3.6",SYMLINK+="csco6"
SUBSYSTEM=="tty",DRIVERS=="usb",KERNELS=="1-1.3.7",SYMLINK+="csco7"

Make sure that you restart udev with:

sudo /etc/init.d/udev restart

From this point on, when a serial-to-usb device is connected to USB port 1, it will be mapped to a serial device /dev/csco1, the USB port 2 will be mapped to /dev/csco2, and so on. This will make it very predictable for the next step.

Using ser2net to map serial ports to Telnet TCP ports

Now in order to map specific USB / Serial ports to TCP / Telnet connections there is a very handy software called ser2net. We are very lucky as this is in the Raspbian repository and it can therefore be installed with:

sudo apt install ser2net

Ater the previous where we made the serial ports predictable this will be very simple. One can configure ser2net by editing the file /etc/ser2net.conf with the following:

2001:telnet:600:/dev/csco1:9600 8DATABITS NONE 1STOPBIT -XONXOFF -RTSCTS banner kickolduser
2002:telnet:600:/dev/csco2:9600 8DATABITS NONE 1STOPBIT -XONXOFF -RTSCTS banner kickolduser
2003:telnet:600:/dev/csco3:9600 8DATABITS NONE 1STOPBIT -XONXOFF -RTSCTS banner kickolduser
2004:telnet:600:/dev/csco4:9600 8DATABITS NONE 1STOPBIT -XONXOFF -RTSCTS banner kickolduser
2005:telnet:600:/dev/csco5:9600 8DATABITS NONE 1STOPBIT -XONXOFF -RTSCTS banner kickolduser
2006:telnet:600:/dev/csco6:9600 8DATABITS NONE 1STOPBIT -XONXOFF -RTSCTS banner kickolduser
2007:telnet:600:/dev/csco7:9600 8DATABITS NONE 1STOPBIT -XONXOFF -RTSCTS banner kickolduser

The "kickolduser" is optional but can be very handy: it will disconnect any existing session still active on that serial port and give precedence to the last arrived.

Make sure to restart ser2net for the configuration to take effect (sudo systemctl restart ser2net).

Testing

You can then telnet straight to a given console by using the corresponding TCP port number, for example for the console connected to my first USB port:

etychon@ETYCHON-M-D2ZR~ telnet 192.168.2.7 2001
Trying 192.168.2.7...
Connected to 192.168.2.7.
Escape character is '^]'.
ser2net port 2001 device /dev/csco1 [9600 N81] (Debian GNU/Linux)
ic3k>

That's it - now I'm on the IC3000 serial-USB console using Telnet on a Raspberry Pi!

Thank you for reading, and let us know in the comments should you have any other ways you are willing to share?

NSO Developer Days US 2019: NSO 5.x Migration

Nicklas Wagerth — Mon, 16 Dec 2019 11:19:06 GMT

Martin Akerstrom, NSO Solutions Architect

NSO Developer Days US 2019:NSO in Docker

Nicklas Wagerth — Fri, 13 Dec 2019 12:27:51 GMT

Kristian Larsson, Architect
See how placing NSO in a Docker container can help you streamline your development, testing and deployment flow. Kristian goes through why you might want to use Docker for your NSO development and shows the official NSO Dockerfile as well as how to apply it to your NSO projects.

NSO Developer Days US 2019: What's Up NSO? Optimize and Troubleshoot

Nicklas Wagerth — Tue, 10 Dec 2019 13:05:02 GMT

Speaker Sebastian Strollo, Principal Engineer

Learn more about your NSO system fundamentals and how to optimize and troubleshoot in case performance is slower than you expect.

NSO Developer Days US 2019: A Low Code Approach to Brownfield Service Discovery

Nicklas Wagerth — Thu, 05 Dec 2019 21:07:56 GMT

Dan Sullivan, Principal Solutions Architect

A low code approach to brownfield service discovery in NSO

NSO Developer Days US 2019: NSO In and On Kubernetes - Lab instructions

Nicklas Wagerth — Thu, 05 Dec 2019 15:43:28 GMT

See the slides here

NSO Developer Days US 2019: NSO In and On Kubernetes

Nicklas Wagerth — Thu, 05 Dec 2019 15:44:40 GMT

Fredrik Jansson, Principal Engineer & John Mullooly, Distinguished Architect, Sales
In the first half of this lab, we build a k8s deployment of NSO from the ground up. We will start packaging NSO in a docker container, from there we will gradually build up to having Helm charts that can deploy NSO in a k8s cluster. In the second half, we will turn things upside down. We will use NSO to orchestrate deployment and "day-n" configuration of an example cloud-native application running in k8s via NSO integration with Helm. This is an intermediate lab; You need to be comfortable with container concepts. You need to be comfortable with container concepts, hands-on container experience will help but is not mandatory.

Find lab instructions here.

NSO Developer Days US 2019: Key Note by Fredrik Lundberg

Nicklas Wagerth — Thu, 05 Dec 2019 14:52:04 GMT

Fredrik Lundberg, Dir. Strategy & Planning, NSO

NSO State of the Union

NSO Developer Days US 2019: Fastmap Templates in Cisco NSO

Nicklas Wagerth — Thu, 05 Dec 2019 14:45:00 GMT

Michael Maddern, Technical Marketing Engineer

This session will demonstrate the use of template-based fastmap in Cisco NSO. It’s easy to underestimate how quickly and simply a new service can be configured based on a synced configuration and templates. Rapid service velocity can be a major competitive differentiator. The presentation will include an introduction to the templating functionality and a demo focused on creating a service from scratch using template-based fastmap in Cisco NSO.

NSO Developer Days US 2019: Network Automation Delivery Model

Nicklas Wagerth — Thu, 05 Dec 2019 14:31:04 GMT

Fredrik Swahn, Product Marketing Manager
Network automation is high on the agenda, but remains a daunting challenge, with results often failing to live up to expectations. Many are struggling with both the technical and organizational changes it requires. With years of experience of implementing network automation using the Cisco Network Services Orchestrator (NSO), we have developed a Network Automation Delivery Model (NADM) that aims to guide customers in their journey towards a fully automated network. A powerful, standardized, model that covers the essential parts of a network automation transformation will be presented and discussed. The model covers all four perspectives of People, Process, Technology, and Organization and therefore targets all the stakeholders from C-level decision makers to the network engineers that execute the operations of the network as of today. During the session, both challenges and success factors for implementing network automation will be presented and put into context.

NSO Developer Days US 2019: Workflow vs NSO Service vs Nano Service

Nicklas Wagerth — Thu, 05 Dec 2019 14:16:22 GMT

Viktor Leijon, Technical Leader, NSO

In this presentation, Viktor gives an overview of the design choices that goes into designing an orchestration solution, explaining the motivation for key NSO features and explain how that position NSO within the larger automation landscape. We will take a look at the principles behind orchestration in general and NSO in particular and discuss how they combine to form the system we have today as well as how to integrate that into a larger solution.

NSO Developer Days US 2019: A Breakneck Journey into Network Service Based Automation in DevNet Sandbox

Nicklas Wagerth — Thu, 05 Dec 2019 13:55:49 GMT

Hank Preston, Principal Engineer, Cisco DevNet
Sandbox is a public Software as a Service offering from Cisco DevNet that provides developers access to Cisco hardware and software (as well as relevant third-party and open source solutions) for building applications and automation using the APIs and platforms provided in them. Under the hood, this means we operate data center networks that aren’t that different from most enterprises, but with some unique design and scale needs. We recently decided to go all-in with network automation and chose Cisco NSO to be our tool for defining and managing the network services that power Sandbox. As stars aligned, we also were building a new data center with a very short timeline… hence our breakneck journey into network service automation.

NSO Developer Days US 2019: Nano services presentation

tryeng — Thu, 05 Dec 2019 11:09:57 GMT

Presentation performed at NSO Developer days in New York 2019

Getting a gateway serial number from Cisco IOx

Emmanuel Tychon — Tue, 24 Sep 2019 12:37:53 GMT

If you are required to retrieve the gateway serial number from an IOx application, environment variables set by the Cisco Application Framework (CAF) are automatically set in the execution environment in the /data/.env file.

You can access this file from your IOx application directly, or invoke it to set all the variables as environment variables, such as:

/ # source /data/.env
/ # echo $CAF_SYSTEM_SERIAL_ID
FGL23362022

To see all the variables available in an IOx container, this can be done by accessing the console with the ioxclient utility. The following command (to get console to the application called iox-serial) and then list all the variables:

 etychon@squeeze:~/iox/iox-serial$ ioxclient app con iox_serial
Currently active profile :  default
Command Name:  application-console
Console setup is complete..
Running command : [ssh -p 2222 -i iox_serial.pem appconsole@192.168.2.231]
/ # cat /data/.env
#!/bin/sh
export CAF_APP_PERSISTENT_DISK_SIZE_KB=102400
export CAF_APP_MEMORY_SIZE_KB=51200
export CAF_SYSTEM_PRODUCT_ID=IR829M-2LTE-EA-EK9
export CAF_SYSTEM_NAME=IR800
export CAF_SS_PORT=9443
export CAF_APP_APPDATA_DIR=/data/appdata
export CAF_APP_CONFIG_DIR=/data
export CAF_SS_IP_ADDR=192.168.1.6
export CAF_APP_CORE_DIR=/tmp/cores
export CAF_APP_LOG_DIR=/data/logs
export CAF_SYSTEM_SERIAL_ID=FGL23362022
export CAF_APP_PERSISTENT_DIR=/data
export CAF_APP_CPU_SHARES=342
export CAF_APP_ID=iox_serial
export CAF_APP_USERNAME=root
export HOST_DEV1=/dev/ttyACM0
export CAF_SYSTEM_UUID=7581eb7b-8c04-4412-b2bb-503598f06a72/

To learn more about these variables check the "Environment Variables" section of Cisco IOx DevNet Documentation: https://developer.cisco.com/docs/iox/#!application-development-concepts/application-development-concepts

Getting a gateway Cellular RSSI from Cisco IOx

Emmanuel Tychon — Mon, 23 Sep 2019 18:10:06 GMT

How to I get the gateway Cellular RSSI from Cisco IOx ?

If you have an IOx application that requires tp capture the cellular modem signal strength (for example to include in telemetry data along with GPS position and map signal with location), you will find that there is no direct way to get it from IOx. The reason is that the application hosting environment is virtualized and therefore Cisco IOS metrics are not directly accessible.

Simple Network Management Protocol (SNMP) which is an IOS feature can be leverage to exposed this variable or any other SNMP variable. SNMP can be easily configured on the gateway with just a few lines:

On a Cisco IR829 with guest-os running in the 192.168.1.0/24 range, where 192.168.1.1 is being assigned to the virtual Gigabit Ethernet 5 interface, then this is what it takes to give SNMP access to all the virtual instances running on the gateway:

IR829(config)# access-list 10 permit 192.168.1.0 0.0.0.255
IR829(config)# snmp-server community public RO 10

The IOx application can then poll the right SNMP OIDs straight from the gateway, and this OID may change depending on the particular model. Always refer the device's MIB.

For example in Python to poll both cellular interface's RSSI on a Cisco IR829M:

from pysnmp.entity.rfc3413.oneliner import cmdgen
import time

SNMP_HOST = '192.168.1.1'
SNMP_PORT = 161
SNMP_COMMUNITY = 'public'


cmdGen = cmdgen.CommandGenerator()

errorIndication, errorStatus, errorIndex, varBinds = cmdGen.getCmd(
    cmdgen.CommunityData(SNMP_COMMUNITY),
    cmdgen.UdpTransportTarget((SNMP_HOST, SNMP_PORT)),
    '1.3.6.1.4.1.9.9.661.1.3.4.1.1.1.20',
    '1.3.6.1.4.1.9.9.661.1.3.4.1.1.1.21'
)

for name, val in varBinds:
    print('%s = %s' % (name.prettyPrint(), val.prettyPrint()))

You should see the RSSI signal (in dBm) returned like so:

SNMPv2-SMI::enterprises.9.9.661.1.3.4.1.1.1.20 = -128
SNMPv2-SMI::enterprises.9.9.661.1.3.4.1.1.1.21 = -128

Help me Caculator PortIndext Cisco ASR 9010+7600

minhanh01081 — Sat, 06 Jul 2019 10:18:44 GMT

example:

Name/OID: ifDescr.447; Value (OctetString): TenGigE0/7/1/2

please help me , how to caculator ifDescr of interface.

gi0/1/1/1-->ifDescr=?.....

thank!

NSO Developer Days 2019: EXPERIENCE THE THRILL OF FOILING Two Flying Dutchman stories demystified

Nicklas Wagerth — Mon, 01 Jul 2019 08:16:30 GMT

Abstract: Telindus, SURFnet and T-Mobile share their outcomes of different automation strategies. How to go above and beyond the traditional way of networking to experience the thrill of foiling. The thrill to master core and B2B connectivity services in full flight with automation is changing the networking landscape for good. The future of networking is like foiling is for sailing: agility and speed with less effort and reduced risks. Telindus enabled this foiling state with Cisco NSO for T-Mobile and SURFnet with different approaches.

Speakers:

Wouter Huisman, SurfNet

Albert Lentink, Telindus

NSO Developer Days 2019: Telefonica - A Glance At Our Automation Journey

Nicklas Wagerth — Thu, 27 Jun 2019 10:34:21 GMT

Abstract: From Telefonica International we are proud to share with the community our experience using Cisco NSO. The evolution from NetOps towards NetDevOps perspective to carry out our daily network operations and the use of Cisco NSO as core SDN controller of proprietary integrated solutions are the base of our automation journey to perform current and arising network challenges.

Speakers:

Carlos Cabrera, Telefonica, Network Developer

Javier Marquez, Telefonica, Network Developer

NSO Developer Days 2019: AUTLAN – The Automation Journey of an Integrated Telecommunications Company

Nicklas Wagerth — Thu, 27 Jun 2019 10:25:54 GMT

Abstract: With a strategy to lead in customer experience, technology and business productivity, Deutsche Telekom has some great aspirations. We are more than an infrastructure company; in this complex digital world we make life easier for people enriching it at every opportunity - at home and at work, anytime, anyplace.

Speakers:

Johannes Peternek, DT, Referent Technikbereitstellung IP

Annand Sanghani, Itential, Sales Engineer

NSO Developer Days 2019: Intelsat – Automation Journey

Nicklas Wagerth — Thu, 27 Jun 2019 10:09:17 GMT

Abstract: Shortly after adopting automation and Cisco NSO, Intelsat is automating its network provisioning routines, for both infrastructure and customer networks. This session will be jointly delivered by an Intelsat Principal Architect and Cisco CX Software Architect and will provide a look into Intelsat’s Automation journey – joining hands with Cisco CX in establishing an automation team, learning and implementing software development concepts and processes for setting the foundation of future automation expansion.

Speakers:

Darren Bono, Intelsat, Senior Principal Design Engineer

Ohad Harel, Cisco CX, Software Architect

NSO Developer Days 2019: Audience Feedback on Roadmap through Mentimeter

Jan Lindblad — Thu, 27 Jun 2019 09:33:11 GMT

During NSO Developer Days, the Mentimeter tool is often used to poll and interact with the audience. Here are the results from the questions on the NSO Roadmap content.

NSO Developer Days 2019: Roadmap and Future outlook

Jan Lindblad — Thu, 27 Jun 2019 11:21:19 GMT

Abstract: Future outlook and industry trend. Also a deeper look into how Merkle trees could be used to optimize future versions of NSO.

Speaker: Carl Moberg, Charlotta Spik

NSO Developer Days 2019: Network Programmability with YANG -- The YANG Book

Jan Lindblad — Thu, 27 Jun 2019 09:00:44 GMT

Abstract: For about a decade or so, many of us have often talked about the need for a book that describes the Model-Driven Network Automation Architecture that we all work with. Going all the way from an automation business case down to the actual protocol operations. Especially covering the reasons why things are the way they are in NETCONF/YANG, which isn't something you can read about in the RFCs. Finally, a trio of Cisco IETF participants got around and did it. This presentation gives some peeks into the result.

Speaker: Jan Lindblad

NSO Developer Days 2019: NETCONF Call Home

Jan Lindblad — Thu, 27 Jun 2019 08:58:22 GMT

Abstract: Introduction to NETCONF call home capabilities in NSO and ConfD. Why it's needed in certain environments and how you set it up in NSO and ConfD, with a demo at the end.

Speaker: Fredrik Jansson

NSO Developer Days 2019: NSO Interop, EANTC and YANG

Jan Lindblad — Thu, 27 Jun 2019 08:54:28 GMT

Abstract: The IETF NETMOD working group is constantly at work adding features to the YANG language family, such as RFC 8528 YANG Schema Mount leveraged by NSO 5.x. Over 30 other IETF working groups have released YANG modules for their respective areas during the last year. YANG related interoperability is advancing, both at the yearly EANTC interop event, and through the NSO Interop Lab.

Speaker: Jan Lindblad

NSO Developer Days 2019: Service Provider as an API

Jan Lindblad — Thu, 27 Jun 2019 08:51:22 GMT

Abstract: As most industries are evolving into API based consumption models for its resources, this presentation gives an overview of the opportunities, challenges and how to overcome some challenges to transform all aspects of a service provider into API consumable entities

Speaker: Hari Sudhakar

NSO Developer Days 2019: The business case of network automation

Jan Lindblad — Thu, 27 Jun 2019 08:48:51 GMT

Abstract: How can I sell the NSO automation inside my organization? And how should I plan it? How can I evaluate the return on investment of each use case, and how should I design the use cases, so it is maximized? How should I measure success? How can I make clear my stakeholders the benefit of investing in NSO and automation? This presentation will guide you through these questions and help you to build an answer. When you leave you will know how to prepare for a senior conversation about the importance of automation investment, and how it should be planned.

Speaker: Joao Serrano

NSO Developer Days 2019: Automated NED Validation

Jan Lindblad — Thu, 27 Jun 2019 08:40:52 GMT

Abstract: This session will help you understand automation of the NED validation process which is usually done manually and takes from days to weeks. We’ll help you understand the impact of automation, and how to save time and resources on your projects.

Speaker: Eswaramoorthy Ramasamy

NSO Developer Days 2019: Intent Based Network Analysis with Interoperability between NSO & Forward Networks

Jan Lindblad — Thu, 27 Jun 2019 08:39:02 GMT

Abstract: NSO offers the best configuration management capabilities for multi-vendor networks. Forward Networks offers the best intent-based network path analysis, Network Assurance & topology generation with extremely valuable meta data capabilities if it is able to consume live network configuration. Interoperability between NSO & Forward Networks using OpenConfig standards would be symbiotic and would unleash enormous value to customers with automated network verification & network remediation.

Speaker: Krishna Venkatraman

NSO Developer Days 2019: Automate NSO PackageTesting and Delivery Process with CI/CD pipeline

Jan Lindblad — Thu, 27 Jun 2019 08:35:16 GMT

Abstract: The goal of this presentation is to share best practices implementing a CI/CD (Continuous Integration/Continuous Delivery) methodology for NSO, being able to implement a complete build process that could be applied to code delivery and test automation. We now have the possibility to continuously retest our deliverables providing better quality NSO services with less effort. This is positively impacting Time to Market and OPEX for our customers.

Speaker: Artur Cieszkowski

NSO Developer Days 2019: Leaving breadcrumbs, an agile journey towards requirement storytelling

Jan Lindblad — Fri, 05 Jul 2019 20:03:48 GMT

Abstract: Learn how Data Ductus increased their quality of delivery when they used the unknown to their advantage and tried different paths to find their way. It will explain how these new paths led them to use storytelling as a means to communicate requirements with their customers and inspired them to break new ground within innovation and automation.

Speaker: Mia Johansson

NSO Developer Days 2019: Improving efficiency and quality using Data Ductus NSO Toolkit

Jan Lindblad — Thu, 27 Jun 2019 08:24:21 GMT

Abstract: A demonstration of the development tools and frameworks that were developed by Data Ductus to speed up deliveries, shorten team ramp up time while focusing on high quality deliveries.

Speakers: Kristoffer Hansson, Jesper Sigården, Data Ductus

NSO Developer Days 2019: Automated Validation of Data Plane Functions in Multi-Cloud Environments

Nicklas Wagerth — Tue, 25 Jun 2019 12:55:52 GMT

Abstract:

A key challenge when adopting a multi-cloud strategy is to achieve a solution that is fully automated, highly secure and quality assured. A core component in the multi-cloud is the cloud exchange that interconnects end-users securely to applications in various cloud locations, across virtual networks and virtual functions. This is where Cisco's Secure Agile Exchange (SAE) provides a unique offering.

This session explains how Cisco SAE works together with Netrounds to achieve automated active assurance of newly created network services and virtual service chains. The live demo will show an innovative assurance solution with Cisco NSO deploying Netrounds Active Test Agents as part of service chains running on Cisco SAE.

Netrounds on SAE enables advanced and automated sectionalisation of the virtualised data plane and ensures that new services are delivered right the first time, and that they remain right all the time during their life cycle.

Speakers:

- Sujay Murthy – Cisco NSO Application Team/SAE

- Jonas Krogell, Technical Product Manager Netrounds

NSO Developer Days 2019: Fun@DevDays -- A couple of mid-event photos

Jan Lindblad — Tue, 25 Jun 2019 08:51:55 GMT

Speaker: Nicklas Wägerth

NSO Developer Days 2019: NSO 5.1 Migration

Jan Lindblad — Tue, 25 Jun 2019 08:50:30 GMT

Abstract: Migrating to the Common Data Model

Speaker: Martin Åkerström

NSO Developer Days 2019: The life and death of NEDs

Jan Lindblad — Fri, 05 Jul 2019 15:59:15 GMT

Abstract: As the legs of NSO, NEDs are crucial for NSO getting anywhere. NEDs have a different life cycle and release rhythm than NSO itself, so how then can new NEDs be added, verified, upgraded, upgraded again, tested and finally retired? NSO 5.x changes the NED landscape quite a bit. We will also touch on what other features NSO 5.2 brings.

Speaker: Denys Knertser & Jan Lindblad

NSO Developer Days 2019: Lifecycle NSO -- A presentation focused on the IT persona

Jan Lindblad — Tue, 25 Jun 2019 08:47:13 GMT

Abstract: If you are an IT administrator managing NSO, you want to attend this session. We will look at the different aspect of NSO IT app lifecycle: plan, install, secure, manage and upgrade. We plan to make it an iterative session with lots of time for questions and experience sharing.

Speaker: Roque Gagliano

NSO Developer Days 2019: Brownfield Service Reconcile Operations

Jan Lindblad — Fri, 05 Jul 2019 17:05:32 GMT

Abstract: A low code approach to brownfield service discovery in NSO

Speaker: Dan Sullivan

NSO Developer Days 2019: Opening Welcome

Jan Lindblad — Thu, 27 Jun 2019 08:12:25 GMT

Opening Welcome by NSO Business Unit Engineering leader Fredrik Lundberg. Warning: ends up a bit in the weeds ;-)

Speaker: Fredrik Lundberg, Cisco

NSO Developer Days 2019: NSO History and Design Principles

Jan Lindblad — Tue, 25 Jun 2019 08:19:45 GMT

Abstract: Today NSO is the established market-leader in network service orchestration, but when NSO (tail-f NCS) took form in 2010, the market was crowded with competition and NSO had to be unique to win against established automation tools. We will give an overview of the reasoning and motivation for key NSO features and technical decisions and explain how that positions NSO within the larger automation landscape. We will take a look at the principles behind orchestration in general and NSO in particular and discuss how they combine to form the system we have today.

Speakers: Viktor Leijon and Stefan Wallin (Netrounds)

NSO Developer Days 2019: Performance Improvements

Jan Lindblad — Tue, 25 Jun 2019 08:18:10 GMT

Abstract: We have made some significant performance enhancements in the area of memory management, when-expression evaluation, and filtering of dynamic instances when reading data from external data providers. This talk will describe the internals of those enhancements and how it impacts NSO users.

Speaker: Johan Bevemyr

NSO Developer Days 2019: Network Automation Delivery Model

Jan Lindblad — Tue, 25 Jun 2019 08:16:41 GMT

Abstract: Network Automation is high on the agenda, but remains a daunting challenge, with results often failing to live up to expectations. Many are struggling with both the technical and organizational changes it requires. With years of experience of implementing network automation using the Cisco Network Services Orchestrator (NSO), we have developed a Network Automation Delivery Model (NADM) that aims to guide customers in their journey towards a fully automated network.

Speaker: Fredrik Swahn

NSO Developer Days 2019: Softbank NSO Use Case and NFV initiative

Nicklas Wagerth — Mon, 24 Jun 2019 14:51:11 GMT

Abstract: Softbank has deployed SDN gateway service with NSO from 2016 and has completed a major NSO version upgrade in 2018. In this presentation Softbank share their NSO use case and their experience of SDN service development as well as their SDN NFV Initiative.

Speakers: Hironori Nakano, Director, Solution Service Department

Kentaro Momeya, Softbank, Network Engineer

NSO Developer Days 2019: NSO and the Orange International Wholesale transformation

Nicklas Wagerth — Mon, 24 Jun 2019 14:45:54 GMT

Abstract: How the introduction of Cisco NSO as a network tool finally drove the whole transformation of Orange International Wholesale transformation to the final benefit of the customer.

Speaker:Cédric Bonnet, Head of Wholesale IP Services Engineering department

NSO DevDays 2019: Marcus Hacke's keynote: SD-WAN as a Service @ ngena

Jan Lindblad — Mon, 24 Jun 2019 13:48:15 GMT

The presentation material for Marcus Hacke's keynote speech at NSO Developer Days 2019.

CiscoSimple_SimplifyIoTForYourCommunity_Webinar_Presentation_5.8.19

cadodd — Wed, 08 May 2019 14:01:28 GMT

Presentation from the Public Sector 5.8.19 Simple IT webinar, "Simplify IoT For Your Community" on IoT.

Using the PSIRT API with python

Seb Rupik — Mon, 15 Apr 2019 12:42:43 GMT

At some point you may be asked to complete a vulnerability audit of your network estate. In the past this would have required searching a near endless list of Cisco vulnerabilities and then cross referencing these against an even longer list of BugIds. Thankfully Cisco released the PSIRT API which can ease the pain of this process.

My previous post on this topic required an APIC-EM instance to act as the source of information for the network inventory. This time round I will use something a little more static, a CSV:

platform,ios_version
3560,12.2(50)SE3
3560C,12.2(55)EX3

The first step is to obtain the OAuth token which will allow us to use the API:

API_TOKEN_URL = "https://cloudsso2.cisco.com/as/token.oauth2"
PROXIES = {}


def get_api_token(url):
    response = requests.post(url, verify=False, proxies=PROXIES, data={"grant_type": "client_credentials"},
                             headers={"Content-Type": "application/x-www-form-urlencoded"},
                             params={"client_id": CLIENT_ID, "client_secret": CLIENT_PASS})

    if response is not None:
        return json.loads(response.text)["access_token"]

    return None

You will need to sign up to apiconsole.cisco.com to obtain your own unique client ID and password.

With the token and the IOS version number a PSIRT REST GET query is created and the from the returned JSON response we pluck the key/value pairs we are interested in and return it as a dictionary:

def get_advisories_by_release(token, platform, ver):
    platform_dict = {"platform": platform, "release": ver, "advisories": []}
    requests.packages.urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
    response = requests.get(API_GET_ADVISORIES.format(ver), verify=False, proxies=PROXIES,
    headers={"Authorization": "Bearer {0}".format(token), "Accept": "application/json"})

    if response.status_code == 200:
        platform_dict["advisories"] = build_dictionary_relevant_advisories(json.loads(response.text)["advisories"])
        return platform_dict

    return {"platform": platform, "release": ver, "advisories": [], "state": "ERROR", "detail": response.status_code}


def build_dictionary_relevant_advisories(advisories):
    adv_list = []
    for adv in advisories:
        adv_dict = dict()
        adv_dict["advisory_id"] = adv["advisoryId"] if "advisoryId" in adv else "Unknown"
        adv_dict["advisory_title"] = adv["advisoryTitle"] if "advisoryTitle" in adv else "Unknown"
        adv_dict["bug_ids"] = adv["bugIDs"] if "bugIDs" in adv else "Unknown"
        adv_dict["first_fixed"] = adv["firstFixed"] if "firstFixed" in adv else "Unknown"
        adv_list.append(adv_dict)

    return adv_list

Iterate through the CSV file one line at a time the returned dictionaries are stored in a list:

def load_csv(input_csv, token):
    big_list = []
    with open(input_csv, "r") as file:
        for device_row in csv.DictReader(file):
            big_list.append(get_advisories_by_release(token, device_row["platform"], device_row["ios_version"]))

    return big_list

The next step is to iterate through the list and print the output in a most readable format. We could use json.dumps(, indent=2) but since the dictionary has the key/value pair 'advisories' which itself is a list of dictionaries the resulting output is not that readable. The following method takes information from both the CSV and the PSIRT API to provide information for each platform/ release pair:

def print_advisories(source_dict, detail=True):
    for item in source_dict:
        print("Platform: {0}, Current release: {1}".format(item["platform"], item["release"]))
        print(" {0} advisories".format(len(item["advisories"])))
        if len(item["advisories"]) == 0:
            message = "ERROR encountered during lookup: {0}".format(item["detail"]) if item["state"] == "ERROR" \
                else "None found"

            print(" {0}".format(message))
        else:
            detail_t = ""
            fixed_releases = []
            for adv in item["advisories"]:
                if adv is not None:
                    detail_t = detail_t + DETAIL_TEXT.format(adv["advisory_id"], adv["advisory_title"],
                               ", ".join(adv["first_fixed"]), ", ".join(adv["bug_ids"]))
                    fixed_releases = fixed_releases + adv["first_fixed"]

            print(" Minimum suggested release: {0}".format(sorted(fixed_releases)[len(fixed_releases)-1]))
            if detail:
                print(detail_t)

In the event that an error was encountered during the PSIRT API lookup process, the error message is displayed under the platform/ release pair, to notify the use that it occurred, otherwise the advisories list would be empty giving the impression that no vulnerabilities were present.
For each platform/ release the first-fixed values are add to a list, then sorted and the highest value picked to give the Recommended Release value. The output looks like:

Platform: 3560, Current release: 12.2(50)SE3
  32 advisories
  Minimum suggested release: 15.0(2a)SE9
  ID cisco-sa-20180926-cmp -- Cisco IOS and IOS XE Software Cluster Management Protocol Denial of Service Vulnerability
    First fixed: 12.2(55)SE13
    Bug IDs: CSCvg48576
  ID cisco-sa-20180926-tacplus -- Cisco IOS and IOS XE Software TACACS+ Client Denial of Service Vulnerability
    First fixed: 12.2(55)SE13
    Bug IDs: CSCux66796
  ID cisco-sa-20180926-vtp -- Cisco IOS and IOS XE Software VLAN Trunking Protocol Denial of Service Vulnerability
    First fixed: 12.2(55)SE13
    Bug IDs: CSCvd37163

As much as I like text files, the data is much more useful if you can tabulate it. Lets first turn it into a dictionary, where each key/value pair can represent a line.
This next method will first take our PSIRT generated list and for each dictionary contained within it, will take the "platform" value and use it as a key for value and create a boolean dictionary, "platforms". The data structure will look like:

{
"3560": False,
"3750-X": False
}

Now we take the PSIRT list, and for each element, we extract the advisories and add it to csv_dict, but only if we haven't done so already. This way we end up with a list of unique advisories. Against each advisory we store a copy of the "platforms" dictionary from earlier, and every time a platform is recorded as having this advisory we change the boolean for True. The data structure (the section we are interested in will look like:

{
  "advisory_id": "cisco-sa-20180926-cmp"
  "affected_platforms": {
                         "3560": True,
                         "3750-X": False
                        }
}

What you will end up with is a list of dictionaries, where each dictionary is a unique advisory ID with a dictionary of affected platforms:

def build_csv_dict(source_list):
    csv_dict = dict()
    platforms = dict()

    for p in source_list:
        platforms[p["platform"]] = False

    for item in source_list:
        for adv in item["advisories"]:
            if adv is not None:
                if adv["advisory_id"] not in csv_dict:
                    csv_dict[adv["advisory_id"]] = adv
                    csv_dict[adv["advisory_id"]]["affected_platforms"] = platforms.copy()

                csv_dict[adv["advisory_id"]]["affected_platforms"][item["platform"]] = True

    print(json.dumps(csv_dict, indent=2))
    return csv_dict, list(platforms.keys())

Next we start the process of writing each dictionary in the list as a line in a CSV file:

def write_to_csv(source_dict, platform_list):
    headernames = ["advisory_id", "advisory_title", "first_fixed", "bug_ids"] + platform_list

    with open("vuln_checker_output" + ".csv", "w", newline="") as csvfile:
        csvwriter = csv.writer(csvfile, delimiter=",")
        csvwriter.writerow(headernames)

        for adv in source_dict:
            print(adv)
            row = [source_dict[adv]["advisory_id"], source_dict[adv]["advisory_title"],
                  "/ ".join(source_dict[adv]["first_fixed"]), "/ ".join(source_dict[adv]["bug_ids"])]
            for p in platform_list:
                row.append(source_dict[adv]["affected_platforms"][p])

            csvwriter.writerow(row)

Take the CSV sling it into your favourite spreadsheet app, add some formatting and the task is nearly complete:

It is worth pointing out that although a device is marked as True for being affected by a vulnerability you will have to take the manual step of cross-referencing the BugID against your running configs to determine if it really is vulnerable.

Full source can be found here:
https://github.com/sebrupik/vuln_checker/blob/master/vuln_checker.py

https://configif.wordpress.com/2019/03/29/vuln_checker/

Getting Started with APIC-EM

ashherri — Fri, 01 Mar 2019 12:45:46 GMT

Today there are about six billion things connected to the internet. This number will triple by the year 2020, putting an even greater demand on the network. Thus, companies will need solutions that come from its very foundation – the network.

So what’s the next step in helping companies towards their journey of digitization? Software Defined Networking (SDN) which simplifies and automates operations. With this overview video, learn how Cisco is delivering SDN to enterprise networks with the Application Policy Infrastructure Controller Enterprise Module (APIC-EM). Along with SDN, APIC-EM is also helping to provide companies with the business outcomes they want through simplicity, automation and open programmability.

Health Monitoring NSO in Kubernetes

frjansso — Fri, 04 Jan 2019 22:46:01 GMT

Introduction

In k8s we have two probes that are used to monitor the health and availability of a container, readiness and liveness probes. This post shows some examples on how to use them. The post will hopefully interest you in trying to take advantage of those probes when running NSO in k8s.

The more you can check in your liveness probe, the more certain you can be that NSO is actually up and running and does what it should.

All code for this can be found here on the NSO-developer GitHub (https://github.com/NSO-developer/container-examples).

NOTE, the actions in the example are toy examples, but hopefully they'll set you off with some ideas on how you can create readiness and most importantly a good liveness probe for your system. The liveness probe could in theory do a number of things, including touching devices.

Readiness

The readiness probe determines when a container is ready for service. NSO can sometimes take some time before it's ready for service.

See the k8s-liveness-readiness/is-ready.sh script. It first checks if NSO is started at all, if that succeeds, the script calls a simple action (/k8s/ready).

Please see k8s-liveness-readiness/lr-test/python/lr_test/main.py

Liveness

After the container has been running for a while, we need to make sure it's still alive. This is also done using an action (/k8s/alive). The example action simply creates a config transaction and writes a leaf (/k8s/last-live-check), this is to test that we can successfully commit a configuration transaction.

To run the examples, please see instructions below.

Base Image

You'll need to build the NSO system install base image. This is a somewhat minimized image that installs NSO.

Please note that you need to supply your own NSO installer binary and modify the Makefile for a correct container name. See the CONTAINER and VER variables in nso-system-install-base/Makefile.

cd nso-system-install-base
make image push

Once you have managed to build the base image, you can move on to the example.

Example Deployment

Please note that you'll need to modify the Dockerfile here (FROM containers.cisco.com/frjansso/nso-system-base) to match your image name from above.

cd k8s-liveness-readiness
make image push deploy

This will launch a deployment in k8s. If you look at the pods, you'll see that the NSO container is not yet ready:

kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
nso-deployment-7d6bb7c698-zb77f   0/1     Running   0          8s

It will be stuck in this state until we tell NSO that it's ready. Please note, this is just for a demo purposes.

kubectl exec -it $(kubectl get pod | grep nso-deployment | awk '{print $1}') bash
root@nso-deployment-7d6bb7c698-zb77f:/# ncs_cli -u admin
admin@ncs> request k8s set-ready
admin@ncs> exit
root@nso-deployment-7d6bb7c698-zb77f:/# exit

Now if we look again at our pods, you'll see that the pod is ready

kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
nso-deployment-7d6bb7c698-mlqn4   1/1     Running   0          59s

Please note that the number of restarts is zero. To simulate a failure, we'll go back into the NSO CLI.

kubectl exec -it $(kubectl get pod | grep nso-deployment | awk '{print $1}') bash
 
root@nso-deployment-7d6bb7c698-mlqn4:/# ncs_cli -u admin
admin@ncs> request k8s set-dead
admin@ncs> exit
root@nso-deployment-7d6bb7c698-mlqn4:/# exit

Again, look at our pods

kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
nso-deployment-7d6bb7c698-mlqn4   0/1     Running   1          3m3s

You'll see that the pod has been restarted. This means that k8s health check worked as expected.

The code is hopefully self explanatory:

k8s-liveness-readiness/deployment.yml
k8s-liveness-readiness/is-alive.sh
k8s-liveness-readiness/is-ready.sh

k8s-liveness-readiness/lr-test/python/lr_test/main.py

Cisco Kinetic v2 APIs documentation

Steve Zhang — Thu, 29 Nov 2018 01:59:13 GMT

Kinecit API Docs (US): https://developer.cisco.com/docs/kinetic-api/?version=US

Kinecit API Docs (EU): https://developer.cisco.com/docs/kinetic-api/?version=EU

Steps to try out the APIs directly from the current documentation:

Use the v2 API “POST /v2/users/access_token” under the Users section to generate a token using your Cisco Kinetic email/password as input or you can use a valid API key that is generated from Cisco Kinetic.
Copy the token that is generated in the response (or if using API key, copy the API key).
For any API that you want to try, expand the API and click on the “Red” button on the right side of the API section.
In the popup, in the value field, type “Token” followed by a space and paste the access token copied in step 2.
You can now try out any of the listed APIs. You will need to provide the required input parameters/values for the APIs, as necessary.
Please note that if you reload your browser, the above 5 steps will need to be repeated again.

NSO Deep Dive Tech Talk - NSO Developer Connect NYC, 2018

Nicklas Wagerth — Tue, 27 Nov 2018 09:51:27 GMT

Sebastian Strollo delivered this "Deep Dive Tech Tack" at NSO Developer Connect in NYC

Main subjects: Transactions, the new feature Progress Trace and Understanding Sync.

Automation Advisory Services - NSO Developer Connect NYC, 2018

Nicklas Wagerth — Tue, 27 Nov 2018 09:50:28 GMT

Shafi uses the Red Whale metaphor to show the importance to do things right from start and build a sustainable solution that can be maintained and supported over time throughout the organization. It’s important to work together selecting the use cases and include all stakeholders. Cisco comes ready with CX Advisory Services to help connect the top-down approach with the bottom-up, drive change management when necessary and help teams secure the right business outcome.

NFV0 - NSO Developer Connect NYC, 2018

Nicklas Wagerth — Tue, 27 Nov 2018 09:49:31 GMT

NFVO update from by Fredrik Jansson and John Mullooly at NSO Developer Connect in NYC.

The Art of Network Engineering - NSO Developer Connect NYC, 2018

Nicklas Wagerth — Fri, 01 Mar 2019 12:22:46 GMT

Kevin Corbin talks about how Network Engineering is changing from an art of “figuring out what command to run on which device and when” to a structured process using Consistent Version Controlled Infrastructure deployed with Parallel & Automated Provisioning. He provides examples of what NSO means for the networking guy and the big savings that can be made in the day-to-day work by using a single favorite CLI to all network devices, in contrast to learning many CLIs. The NSO CLI is, in fact, an API, just like NETCONF!

NSO Onboarding Best Practice - NSO Developer Connect NYC, 2018

Nicklas Wagerth — Fri, 01 Mar 2019 12:22:45 GMT

Learn how basic software practice can be used in Network Automation. Simple things like using version control, taking small incremental steps instead of giant leaps and automating your tests make a huge difference. Viktor Leijon has long experience from working side by side with Network Engineers and his interest in how we work has helped him understand how software practice is best used in networking. A very nice side effect of a model-based framework like NSO is that you can minimize the coding and automate the manual, boring work and focus on what makes your company unique.

Cisco Kinetic EFM License Explanation and Issues

Emmanuel Tychon — Thu, 22 Nov 2018 11:19:14 GMT

The purpose of this article is to sort out and clarify how licenses are effectively working in Cisco Kinetic Edge & Fog Processing Module (EFM). It does not address ordering licenses, prices, or anything related to the Cisco Kinetic Cloud (GMM and DCM).

Type of License

There is fundamentally only one license in Cisco EFM, but it can activate two separate features:
the EFM broker (the logic engine that runs the data flow amongst other things), and
the visualizations (DGLux5).

Initial license: during the EFM installation process, the installer package will automatically create a license for the EFM broker. This means that a new license will never need to be generated again unless the graphical data flow editor is being used.

Since there is only one license, if you ever want to start using the data visualisation, you'll be offered an option to request a trial version. If your instance has internet access it is granted immediately using an on-line activation process. However now the entire license will now be 180-days. After 180-days your license will expire and you won't have a broker, you won't have a data flow editor, and you won't have visualizations.

Workaround 1: Use separate users for EFM broker and visualization

During the installation, install only the broker as one user, and the visualization as another user. This way you have separate licenses per user, and expiration of one will not affect others. This is described in:

https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/cisco-edge-fog-fabric/1_2_0/Kinetic-EFM-1-2-0_Install_EFM_DGLux5.pdf

Workaround 2: Reinstall EFM.

This very effective approach will wipe all of your installation, including tokens, data flow, etc... unless you backup them manually. Since the WebUI is not working this is quite a long process that is not recommended if all you want is a new working license. However if you do re-install make sure you separate EFM broker and visualization components on two users as see before.

Workaround 3: Regenerate License

Remove the user's ~/.dglogik directory, and perform an in-place upgrade of EFM. You will essentially reinstall the same version of EFM, but the installer will generate a new EFM broker license. You'll get access to the data flow editor, and none of your data will be lost.

Generic REST NED Reference

hoatruo — Mon, 19 Nov 2018 12:55:41 GMT

Reference

1. Introduction
2. Device commands and NSO CLI commands
3. Adapting an existing NED - Step One
4. Adapting an existing NED - Step Two
5. Commands and Java correlation
6. Setting up a NED-instance
7. Debugging and trouble-shooting

Please see the attached file for all the detailsnso

Creating a GENERIC NED v 1.0

hoatruo — Mon, 19 Nov 2018 16:23:11 GMT

Creating a GENERIC NED v 1.0

Content list
1. Introduction
2. NED demo video overview:
3. Device commands
4. Adapting the demo-ned to your device
5. Setting up a NED instance to communicate with the device
6. Debugging and trouble-shooting
7. Contents:

1 Introduction:
The idea of this article, the reference file, video, demo-ned and more is to provide a guide which
explains how to conveniently develop a bare minimum Generic NED with what is available after
installing NSO.

In the past ncs-make-package was used for generating new NEDs. Nowadays a NED generator is used and demo-ned is the result of a NED generator when requiring a Generic REST NED.

2. NED demo video overview:
This demo video will:
go through how the device work
show the commands to list and modify config which the NED supports
explain the YANG model
explain the Java Code
show how to set up a NED instance
demonstrate how to fetch config - sync-from
demonstrate how to output config changes - commit dry run
demonstrate how to create/delete config – commit
demonstrate the logging functionality

The name of the demo video is "Generic REST NED Development"

3. Device commands
What the NEDs sends to the device is determined by what commands the device require. This means that different
NEDs for different devices will send different commands.
This is also the part to adapt when adapting the demo-ned to another device.
For details refer to section "Device commands and NSO CLI commands" in the Reference file.

4. Adapting the demo-ned to your device
There are two steps when adapting the demo-ned to the any device. The first step is mandatory and covers device
communication. The second step is optional and covers namespace, ids and other NED internal details.
If you just need to quickly create a NED that communicates to any device, doing the first step is enough.
However, if the NED is to be used with other NEDs or if further development is expected then it is a good idea to do the
second step as well.

First step
In this first step only the java file JVXNedGeneric needs to be modified.
The methods to be modified are:
public void show(NedWorker worker, int th) throws NedException, IOException {

private void edit(NedWorker worker, NedEditOp[] ops, StringBuilder dryRun, int th) throws Exception {When fetching config from a device the NED command sync-from needs to be issued. Sync-from will call show.

When sending commands to the device the NED command commit needs to be issued. Commit will call prepare, which
in turn will call edit to fetch the command to be sent.
If just printing the commands to be sent is enough then the NED command commit dry-run needs to be issued. Commit
dry-run will call prepareDry, which in turn will call edit to fetch the command to be sent.

The key here is to:
adapt show so that it issues the device commands which lists config.
adapt edit so that it issues the correct command to either create, modify or delete config.
The idea with the NED is to emulate the procedure and use the same commands used when communicating to the
device from the CLI or REST API.

This part will be covered in the video.

For more details refer to the section "Commands and Java correlation" in the Reference file.

Second step - editing the NED details
The second step requires more file editing. Demo-ned and test-device-ned has the same functionality.
Test-device-ned is demo-ned after applying the second step where this replacement has been used.
GRX - devname
JVX - dn
DVX - Cisco
The details and where to replace values can be found in the section "Adapting an existing NED – Step Two" in the
Reference file.

5. Setting up a NED instance to communicate with the device
Once the demo-ned has been adapted to a device a NED instance has to be created so that the NED can communicate
with a device.
How to do this is described in section "Setting up a NED-instance" in the Reference file.

6. Debugging and trouble-shooting
One can also insert logging into the NED so that data can be printed out into log files.
How to do this is described in section "Debugging and trouble-shooting" in the Reference file.

NSO Kubernetes Lab

frjansso — Wed, 07 Nov 2018 17:31:44 GMT

NOTE: This is WIP, and I'm aiming to have this hosted on dCloud as a hands on lab. Stay tuned!

The aim with this lab is to build a Kubernetes (k8s) cluster with three nodes. In this cluster we will install NSO, one master and two slaves. Using these we going to experiment with leader election and fail over.

The master node (kube-1) is hosting the bulk part of the k8s machinery, i.e. API, controller and scheduler. In a production environment, you will typically not schedule any pods on the master node. For this lab we'll remove that restriction and use the master node as well.

The first test will not have persistent storage for NSO, so if all pods die, all data is lost. We will therefore move on to install a persistent storage provider (GlusterFS) on all three nodes. With this in place, we will setup NSO again, but now on persistent storage. Leader election and failover will still work as before. But now we can take an outage of all three NSO pods.

Credentials

The nodes are called kube-1, kube-2 and kube-3.

Kube-1 will serve as as the k8s master.

Credentials

The credentials on the nodes are:

username: test

password: cisco123

Install Kubernetes on Three Nodes

This lab is based on this document: https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

SSH to the Master Node (kube-1)

ssh test@X.X.X.X

Initialize k8s on the master node

Make sure docker is working and can pull images

test@kube-1:~$ docker run --rm -it alpine:latest /bin/sh
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
8e3ba11ec2a2: Pull complete
Digest: sha256:7043076348bf5040220df6ad703798fd8593a0918d06d3ce30c6c93be117e430
Status: Downloaded newer image for alpine:latest
/ # exit

Next we're going to use kubeadm to setup the master node, later followed by the slave nodes.

Sometimes kubeadm times out when downloading the images, therefore it's a good idea to pull the images first. Please run the following until all images are pulled.

test@kube-1:~$ kubeadm config images pull
[config/images] Pulled k8s.gcr.io/kube-apiserver-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/kube-controller-manager-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/kube-scheduler-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/kube-proxy-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/pause:3.1
[config/images] Pulled k8s.gcr.io/etcd-amd64:3.2.18
failed to pull image "k8s.gcr.io/coredns:1.1.3": exit status 1

If you get an error as above, please run again.

test@kube-1:~$ kubeadm config images pull
[config/images] Pulled k8s.gcr.io/kube-apiserver-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/kube-controller-manager-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/kube-scheduler-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/kube-proxy-amd64:v1.11.2
[config/images] Pulled k8s.gcr.io/pause:3.1
[config/images] Pulled k8s.gcr.io/etcd-amd64:3.2.18
[config/images] Pulled k8s.gcr.io/coredns:1.1.3

Pod Networking

When installing k8s, you have a wide variety of pod networking to choose from. For the lab, we've decided to use Flannel (https://github.com/coreos/flannel). "Flannel is responsible for providing a layer 3 IPv4 network between multiple nodes in a cluster. Flannel does not control how containers are networked to the host, only how the traffic is transported between hosts."

To install k8s, we'll use the kubeadm init command, and since we're going to use Flannel as our pod network, we will pass the 10.244.0.0/16 CIDR to kubeadm. This means that our containers will end up with 10.244.x.y addresses.

test@kube-1:~$ sudo kubeadm init --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.11.2
[preflight] running pre-flight checks
I0820 14:49:38.345563    5854 kernel_validator.go:81] Validating kernel version
I0820 14:49:38.345804    5854 kernel_validator.go:96] Validating kernel config
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [kube-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.0.0.4]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [kube-1 localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [kube-1 localhost] and IPs [10.0.0.4 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 40.001870 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.11" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node kube-1 as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node kube-1 as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kube-1" as an annotation
[bootstraptoken] using token: pahwji.frci87slyux729v0
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
 
Your Kubernetes master has initialized successfully!
 
To start using your cluster, you need to run the following as a regular user:
 
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
 
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
 
You can now join any number of machines by running the following on each node
as root:
 
  kubeadm join 10.0.0.4:6443 --token pahwji.frci87slyux729v0 --discovery-token-ca-cert-hash sha256:8fdd45a2a0004788cde9c6b89fcdec56931fcda1c74322ac7bccfa6f88a14ee2

Now get kubectl into the user's home directory

test@kube-1:~$ mkdir -p $HOME/.kube
test@kube-1:~$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
test@kube-1:~$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

If we check the nodes, we'll see our master node, but it's not ready. To fix that, we need to install a pod network..

test@kube-1:~$ kubectl get nodes
NAME      STATUS     ROLES     AGE       VERSION
kube-1    NotReady  master    33s       v1.11.2

Install Flannel

To install Flannel we simply apply the YAML provided by the Flannel project:

test@kube-1:~$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created

After Flannel is installed, you should shortly see the master node coming up

test@kube-1:~$ kubectl get nodes
NAME      STATUS    ROLES     AGE       VERSION
kube-1    Ready     master    21m       v1.11.2

Allow scheduling on the master node

To allow scheduling of workloads on the master node, we need to untaint it.

test@kube-1:~$ kubectl taint nodes --all node-role.kubernetes.io/master-
node/kube-1 untainted

If we don't do this, no pods will be scheduled on the master node. In a production system this makes sense, but for this lab we want to use all three nodes.

Add Slave Nodes

Next thing is to add our two slave nodes, kube-2 and kube-3, to the k8s cluster.

The kubeadm init command for kubeadm will print a join command that can be used by the slaves, but you can also generate a new one:

test@kube-1:~$ kubeadm token create --print-join-command
kubeadm join 10.0.0.4:6443 --token w23h6m.ze6f4j7c0xanskd2 --discovery-token-ca-cert-hash sha256:bbb0d19cdc33a13db449121676326dcf5b140925bc0ab973365d5a17b7158008

NOTE: You cannot copy the join commands from here, you have to generate your own as explained above or copy the one outputted by the kubeadm init command.

NOTE: You have to do the following on both kube-2 and kube-3.

SSH to kube-2 and kube-3

test@kube-1:~$ ssh kube-2
 
test@kube-2:~$ sudo kubeadm join 10.0.0.4:6443 --token qohtw7.ufsn3xma6imzj80n --discovery-token-ca-cert-hash sha256:4629539b
39ea7f7663e80fc2ea902a7b39e467df396d848c4242c13088ad61a2
[preflight] running pre-flight checks
I0821 09:28:45.475918     673 kernel_validator.go:81] Validating kernel version
I0821 09:28:45.476369     673 kernel_validator.go:96] Validating kernel config
[discovery] Trying to connect to API Server "10.0.0.4:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.0.0.4:6443"
[discovery] Requesting info from "https://10.0.0.4:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.0.0.4:6443"
[discovery] Successfully established connection with API Server "10.0.0.4:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.11" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kube-2" as an annotation
 
This node has joined the cluster:
* Certificate signing request was sent to master and a response
  was received.
* The Kubelet was informed of the new secure connection details.
 
Run 'kubectl get nodes' on the master to see this node join the cluster.
 
test@kube-2:~$ exit

Please redo the same for kube-3.

After a while the new nodes should come up

test@kube-1:~$ kubectl get nodes
NAME      STATUS    ROLES     AGE       VERSION
kube-1    Ready     master    59m       v1.11.2
kube-2    Ready     <none>    35m       v1.11.2
kube-3    Ready     <none>    36s       v1.11.2

We now have a working k8s cluster.

Create a local Docker registry

We're going to push our containers to a local registry, this will speed up and simplify things when we build our own NSO containers.

To start the registry, on kube-1:

test@kube-1:~$ docker run -d -p 5000:5000 --restart=always --name registry registry:2

To test the docker registry, first pull an image from Docker Hub

test@kube-1:~$ docker pull alpine:latest
latest: Pulling from library/alpine
Digest: sha256:7043076348bf5040220df6ad703798fd8593a0918d06d3ce30c6c93be117e430
Status: Image is up to date for alpine:latest

Next, let's tag it for our local registry

test@kube-1:~$ docker tag alpine:latest kube-1:5000/alpine:latest

Now push it into the registry

test@kube-1:~$ docker push kube-1:5000/alpine:latest
The push refers to a repository [10.0.0.4:5000/alpine]
73046094a9b8: Pushed
latest: digest: sha256:7e8e16517347ec0b19fac1700682cc0b905b4c10d91a5f409452d2327fe49b8d size: 528

To make sure we can pull from our registry, we'll remove the local image

test@kube-1:~$ docker rmi kube-1:5000/alpine
Untagged: kube-1:5000/alpine:latest
Untagged: kube-1:5000/alpine@sha256:7e8e16517347ec0b19fac1700682cc0b905b4c10d91a5f409452d2327fe49b8d
Deleted: sha256:11cd0b38bc3ceb958ffb2f9bd70be3fb317ce7d255c8a4c3f4af30e298aa1aab
Deleted: sha256:73046094a9b835e443af1a9d736fcfc11a994107500e474d0abf399499ed280c

Then we pull it back

test@kube-1:~$ docker pull kube-1:5000/alpine:latest
latest: Pulling from alpine
f031366bd5fe: Pull complete
Digest: sha256:7e8e16517347ec0b19fac1700682cc0b905b4c10d91a5f409452d2327fe49b8d
Status: Downloaded newer image for kube-1:5000/alpine:latest

All good!

Create NSO base image

We're going to create an NSO base image that we'll base the project image on. This is not necessary, but I've found that it saves time during development to have a base image onto which I install the NSO project.

Go the the k8s-lab/base-container directory, where you'll find a number of files, the most interesting files is the Dockerfile.

It will install a couple of packages needed by NSO. It also installs curl which will be helpful later on.

FROM ubuntu:16.04
 
COPY nso-4.6.1.3.linux.x86_64.installer.bin /tmp/nso
RUN apt-get update; \
    apt-get install -y openssh-client default-jre-headless python curl; \
    /tmp/nso /app/nso; \
    echo '. /app/nso/ncsrc' >> /root/.bashrc; \
    apt-get -y clean autoclean; \
    apt-get -y autoremove; \
    rm -rf /tmp/* /var/tmp/* /var/lib/{apt,dpkg,cache,log}/
 
EXPOSE 8080 830 2022 2023 4569

It installs NSO in /app/nso and cleans up after apt. Last it exposes a number of ports that NSO uses.

To build and push the image to the local registry please run (NOTE, this can take a couple of minutes).

test@kube-1:~$ ./build.sh
Sending build context to Docker daemon 188.5 MB
Step 1/4 : FROM ubuntu:16.04
---> 7aa3602ab41e
Step 2/4 : COPY nso-4.6.1.3.linux.x86_64.installer.bin /tmp/nso
---> Using cache
---> 5a3f5d3eb822
Step 3/4 : RUN apt-get update;     apt-get install -y openssh-client default-jre-headless python git curl;     /tmp/nso /app/nso;     echo '. /app/nso/ncsrc' >> /root/.bashrc;     apt-get -y clean autoclean;     apt-get -y autoremove;     rm -rf /tmp/*
/var/tmp/* /var/lib/{apt,dpkg,cache,log}/
 
...
 
Successfully built a35fb1e9e6d3
The push refers to a repository [kube-1:5000/nso-base]
6b7ec8654278: Pushed
869384c52942: Pushed
bcff331e13e3: Pushed
2166dba7c95b: Pushed
5e95929b2798: Pushed
c2af38e6b250: Pushed
0a42ee6ceccb: Pushed
latest: digest: sha256:bbd34574f8af11322ce726d160f48bb9766367d9ebcdd8aece8629bfd1f6f0d6 size: 1783

NSO Container

Next we will build our NSO container that contains the packages we use for this test. Please navigate to k8s-lab/nso-container

This Dockerfile is quite simple, just adding the NSO project to the base container.

from kube-1:5000/nso-base
 
COPY nso-app /app/nso_project
COPY run-nso.sh /.
 
EXPOSE 4570
 
ENTRYPOINT ["/run-nso.sh"]

To build, simply run

test@kube-1:~$ ./build.sh
Sending build context to Docker daemon     64kB
Step 1/5 : from kube-1:5000/nso-base
---> 7c3dc8b25152
Step 2/5 : COPY nso-app /app/nso_project
---> cec6b567551b
Step 3/5 : COPY run-nso.sh /.
---> c671eee6e239
Step 4/5 : EXPOSE 4570
---> Running in f8c5440dd665
Removing intermediate container f8c5440dd665
---> 53814cc9fce8
Step 5/5 : ENTRYPOINT ["/run-nso.sh"]
---> Running in 51cc1c16771a
Removing intermediate container 51cc1c16771a
---> f1dd50c21e62
Successfully built f1dd50c21e62
Successfully tagged kube-1:5000/nso-k8s-lab:latest
The push refers to repository [kube-1:5000/nso-k8s-lab]
c8c8f4c5557e: Pushed
7f37e62a2dda: Pushed
e291435ad52b: Mounted from nso-base
4458e05c75c6: Mounted from nso-base
d7232280c8c4: Mounted from nso-base
07663827a77f: Mounted from nso-base
87a2d0000622: Mounted from nso-base
4a7a5ec0f29e: Mounted from nso-base
8823818c4748: Mounted from nso-base
latest: digest: sha256:3a80da141f03dc3205c91d9afec2c7606edaa5d19acaa951c434ef7a6bcf2ab9 size: 2199

Now we have the NSO container we'll use for the rest of the lab.

NSO Service and RBAC

To access NSO we'll create a couple of k8s services, we'll also install a k8s role for leader election.

Please go to the k8s-lab/nso-service directory

We will register two services for NSO, please see nso-service.yml

kind: Service
apiVersion: v1
metadata:
  name: nso-svc
spec:
  clusterIP: None
  ports:
  - protocol: TCP
    port: 8080
    name: webui
  selector:
    app: nso-app
---
kind: Service
apiVersion: v1
metadata:
  name: nso-svc-master
spec:
  ports:
  - protocol: TCP
    port: 2024
    name: ssh
  - protocol: TCP
    port: 8080
    name: webui

nso-svc

The service will service all NSO instances and could be used for RO access, port 8080 is exposed.

nso-svc-master

This service will service only the NSO HA master and will expose ports 8080 and 2024.

To get leader election to work, we also need to give the default user access to k8s endpoints, please see rbac.yml

# Create role to allow user to read endpoints
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: endpoint-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["endpoints"]
  verbs: ["get", "watch", "list", "update"]
---
# This role binding allows "default" to read endpoints in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-endpoints
  namespace: default
subjects:
- kind: User
  name: system:serviceaccount:default:default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: endpoint-reader
  apiGroup: rbac.authorization.k8s.io

Make sure you apply both these files

test@kube-1:~$ kubectl create -f nso-service.yml
service/nso-svc created
service/nso-svc-master created
 
test@kube-1:~$ kubectl create -f rbac.yml
role.rbac.authorization.k8s.io/endpoint-reader created
rolebinding.rbac.authorization.k8s.io/read-endpoints created

Make sure the services are registered

test@kube-1:~/nfs/kube-ha/k8s-lab/nso-service$ kubectl get svc
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP             6h
nso-svc          ClusterIP   None            <none>        8080/TCP            14s
nso-svc-master   ClusterIP   10.108.126.92   <none>        2024/TCP,8080/TCP   14s

It will also simplify if we export the IP address to NSO master

test@kube-1:~$ export NSO_IP=$(kubectl get service nso-svc-master | tail -n +2 | awk '{print $3}')
 
test@kube-1:~$ echo $NSO_IP
10.102.2.60

Test deployment of NSO

In our first test, we will deploy NSO with one master and two slaves, distributed on the three nodes.

To select a master between themselves, we're launching a leader elector container as a sidecar to NSO. The leader-elector exposes a HTTP API, where each pod can query for the master. This is done by a HTTP GET on URL http://localhost:4040. The call returns the hostname of the master.

Please go to the k8s-lab/test-deployment directory and look at nso.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nso
spec:
  selector:
    matchLabels:
      app: nso-app
  serviceName: nso-svc
  # Deploy three instances of NSO
  replicas: 3
  template:
    metadata:
      labels:
        app: nso-app
    spec:
      # Specify anti-affinity to make sure NSO nodes are not
      # scheduled on the same k8s node
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - nso-app
              topologyKey: "kubernetes.io/hostname"
      containers:
        - name: nso-master
          image: kube-1:5000/nso-k8s-lab
          # Probes for liveness and readiness
          livenessProbe:
            httpGet:
              path: /restconf/data/ncs-state
              port: 8080
              httpHeaders:
                - name: Authorization
                  # echo -n "admin:admin" | base64
                  value: Basic YWRtaW46YWRtaW4=
          readinessProbe:
            httpGet:
              path: /restconf/data/ncs-state
              port: 8080
              httpHeaders:
                - name: Authorization
                  # echo -n "admin:admin" | base64
                  value: Basic YWRtaW46YWRtaW4=
          ports:
          - containerPort: 2024
            name: ssh
          - containerPort: 8080
            name: webui
        # The leader elector side car. HTTP GET on http://localhost:4040
        # will return the leader
        - name: elector
          image: fredrikjanssonse/leader-elector:0.6
          args:
            - --election=nso-svc
            - --http=localhost:4040
          ports:
            - containerPort: 4040
              protocol: TCP

And to deploy the test

test@kube-1:~$ kubectl create -f nso.yml
statefulset.apps/nso created

NOTE: This might take a while since the NSO image have to be pulled from the registry to each of the k8s nodes.

To continuously check status you can watch the pods.

NOTE: the nodes on which each NSO pod is scheduled on may vary on your system.

test@kube-1:~$ watch kubectl get pod -o=wide
NAME      READY     STATUS    RESTARTS   AGE       IP           NODE      NOMINATED NODE
nso-0     2/2       Running   0          2m        10.244.2.2   kube-3    <none>
nso-1     2/2       Running   0          1m        10.244.1.2   kube-2    <none>
nso-2     2/2       Running   0          1m        10.244.0.4   kube-1    <none>

After a while you should see the pods deployed, one on each node.

To see which was elected as leader, you have a couple of options

test@kube-1:~$ kubectl describe endpoints nso-svc
Name:         nso-svc
Namespace:    default
Labels:       <none>
Annotations:  control-plane.alpha.kubernetes.io/leader={"holderIdentity":"nso-0","leaseDurationSeconds":10,"acquireTime":"2018-08-21T22:17:15Z","renewTime":"2018-08-21T22:19:44Z","leaderTransitions":0}
Subsets:
  Addresses:          10.244.0.4,10.244.1.2,10.244.2.2
  NotReadyAddresses:  <none>
  Ports:
    Name   Port  Protocol
    ----   ----  --------
    webui  8080  TCP
 
Events:  <none>

Or you can log into one of the pods

test@kube-1:~$ kubectl exec -it nso-0 bash
Defaulting container name to nso-master.
Use 'kubectl describe pod/nso-0 -n default' to see all of the containers in this pod.
 
root@nso-0:/# curl http://localhost:4040
{"name":"nso-0"}
 
root@nso-0:/# exit

We can also query the NSO HA status

test@kube-1:~$ kubectl exec -it nso-0 bash
Defaulting container name to nso-master.
Use 'kubectl describe pod/nso-0 -n default' to see all of the containers in this pod.
 
root@nso-0:/# ncs_load -F o -o -p /ncs-state/ha
{
  "data": {
    "tailf-ncs-monitoring:ncs-state": {
      "ha": {
        "mode": "master",
        "node-id": "nso-0",
        "connected-slave": ["nso-1", "nso-2"]
      }
    }
  }
}
 
root@nso-0:/# exit

So we can see that NSO have connected two slaves

Test HA

To test HA we can modify some data in NSO. For this there is a simple action in NSO, the action will simply increase a counter (in config) and store which host (i.e. the master) last made a change.

We can invoke the test action as follows

test@kube-1:~$ http_proxy="" curl -H "Content-Type: application/yang-data+json" -d "" -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test/ping

And to check the result

test@kube-1:~$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test
 
<ha-test xmlns="http://example.com/ha-test"  xmlns:ha-test="http://example.com/ha-test">
  <count>2</count>
  <last-host>nso-0</last-host>
</ha-test>

So in my run above, I can see the nso-0 is the master.

Let's kill the nso-0 pod and force a leadership change.

Sometimes the restart of the master is so quick, that a new leader is not elected. If that happens, we can use a trick to force selection of a new leader. The pods are configured to not run on the same node (see nso.yml), so if we disable scheduling on one node, we can prevent one of the pods to come up.

First let's see where each pod is running

test@kube-1:~$ kubectl get pods -o=wide
NAME                     READY     STATUS    RESTARTS   AGE       IP            NODE      NOMINATED NODE
nso-0                    2/2       Running   0          1m        10.244.2.10   kube-3   <none>
nso-1                    2/2       Running   0          59s       10.244.1.11   kube-2    <none>
nso-2                    2/2       Running   0          42s       10.244.0.4    kube-1    <none>

Here I see that nso-0, the leader, is running on kube-3. Let's disable scheduling on that node

NOTE: Make sure you select the correct node for your system.

test@kube-1:~$ kubectl cordon kube-3
node/kube-3 cordoned

And now if we delete nso-0, it will not come up until we uncordon the node

test@kube-1:~$ kubectl delete pod nso-0
pod "nso-0" deleted

Now we can redo the action test again

test@kube-1:~$ http_proxy="" curl -H "Content-Type: application/yang-data+json" -d "" -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test/ping

And to check the result

test@kube-1:~$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test
 
 
<ha-test xmlns="http://example.com/ha-test"  xmlns:ha-test="http://example.com/ha-test">
  <count>4</count>
  <last-host>nso-1</last-host>
</ha-test>

And voila, the new master is nso-1 and more importantly, the data is not lost.

Let's uncordon our node again to let nso-0 be scheduled.

test@kube-1:~$ kubectl uncordon kube-3
node/kube-3 uncordoned
 
test@kube-1:~/nfs/kube-ha/k8s-lab/test-deployment$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
nso-0                    1/2       Running   0          1m
nso-1                    2/2       Running   0          14m
nso-2                    2/2       Running   0          14m

All good... but what will happen if we kill all pods?

test@kube-1:~$ kubectl get pods | grep nso | awk '{print $1}' | xargs kubectl delete pod
pod "nso-0" deleted
pod "nso-1" deleted
pod "nso-2" deleted

Wait for the pods to come back up

test@kube-1:~$ watch kubectl get pod -o=wide
NAME      READY     STATUS    RESTARTS   AGE       IP           NODE      NOMINATED NODE
nso-0     2/2       Running   0          2m        10.244.2.2   kube-3    <none>
nso-1     2/2       Running   0          1m        10.244.1.2   kube-2    <none>
nso-2     2/2       Running   0          1m        10.244.0.4   kube-1    <none>

Now let's check the config again

test@kube-1:~$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test

Empty CDB, when all pods are gone and there is no persistent storage, all data is lost.

Let's delete the current deployment

$ kubectl delete -f nso.yml
statefulset.apps "nso" deleted

Shortly the pods should be removed

$ kubectl get pod
No resources found.

NSO with Persistent Storage

Install GlusterFS

We'll install GlusterFS as our replicated storage.

On the master node, we've already checked out a git repo that will help setting up GlusterFS.

First thing we need to do is load a couple of modules on the k8s nodes. Please go to k8s-lab/install-glusterfs.

There you'll run an ansible playbook that will load the relevant modules on all the hosts.

test@kube-1:~$ ansible-playbook -i hosts.yml glusterfs.yml
 
PLAY [Build Hosts] ***************************************************************************************************
 
TASK [Gathering Facts] ***********************************************************************************************
ok: [kube-2]
ok: [kube-3]
ok: [kube-1]
 
TASK [Modprobe] ******************************************************************************************************
ok: [kube-3] => (item=dm_mirror)
ok: [kube-1] => (item=dm_mirror)
ok: [kube-2] => (item=dm_mirror)
ok: [kube-2] => (item=dm_snapshot)
ok: [kube-3] => (item=dm_snapshot)
ok: [kube-1] => (item=dm_snapshot)
ok: [kube-2] => (item=dm_thin_pool)
ok: [kube-1] => (item=dm_thin_pool)
ok: [kube-3] => (item=dm_thin_pool)
 
PLAY RECAP ***********************************************************************************************************
kube-1                     : ok=2    changed=0    unreachable=0    failed=0
kube-2                     : ok=2    changed=0    unreachable=0    failed=0
kube-3                     : ok=2    changed=0    unreachable=0    failed=0

Please go to ~/gluster-k8s/deploy.

There you'll find a file called topology.json

{
  "clusters": [
    {
      "nodes": [
        {
          "node": {
            "hostnames": {
              "manage": [
                "kube-1"
              ],
              "storage": [
                "10.0.0.4"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/sdb"
          ]
        },
        {
          "node": {
            "hostnames": {
              "manage": [
                "kube-2"
              ],
              "storage": [
                "10.0.0.5"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/sdb",
          ]
        },
        {
          "node": {
            "hostnames": {
              "manage": [
                "kube-3"
              ],
              "storage": [
                "10.0.0.6"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/sdb",
          ]
        }
      ]
    }
  ]
}

It already have the correct names and IP address for your k8s nodes.

To install GlusterFS we simply run the gk-deply script, with -g to provision gluster pods as well.

$ ./gk-deploy -v -g
...
 
Deployment complete!

Now navigate back to k8s-lab/install-glusterfs, there you'll find a file called storage-class.yml.

NOTE: This file will need to bo modified to point to the heketi/glusterfs service

$ kubectl get service heketi
NAME                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
heketi                     ClusterIP   10.98.79.86     <none>        8080/TCP            15m

Edit storage-class.yml to match the IP address above

$ vim storage-class.yml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: glusterfs-storage
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://10.98.79.86:8080"

NOTE: If you're behind a proxy, you'll need to add the IP address above to the no_proxy for k8s. Please modify /etc/kubernetes/manifests/kube-controller-manager.yaml

...
    - name: no_proxy
      value: .cisco.com,localhost,127.0.0.1,10.0.0.0/8,kube-1,kube-2,192.168.0.0/16,10.98.79.86
...

Modifying this file will automatically reload k8s controller service.

Now let's create the storage class

$ kubectl create -f storage-class.yml
storageclass.storage.k8s.io/glusterfs-storage created

To test the storage, we will create a persistent volume claim, please see pvc.yml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
    name: test
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: glusterfs-storage

$ kubectl create -f pvc.yml
persistentvolumeclaim/test created

After a while you should see

$ kubectl get pvc
NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
test      Bound     pvc-be2c9bcd-a61e-11e8-9703-0050568923a4   1Gi        RWO            glusterfs-storage   24s

We can also check the persistent volume created from this claim

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM          STORAGECLASS        REASON    AGE
pvc-be2c9bcd-a61e-11e8-9703-0050568923a4   1Gi        RWO            Delete           Bound     default/test   glusterfs-storage             1m

When we know it works, we're can delete the volume claim

$ kubectl delete -f pvc.yml
persistentvolumeclaim "test" deleted

After about a minute, the claim and the volume should be gone

$ kubectl get pv,pvc
No resources found.

With that we have a persistent, distributed storage installed.

Let's move back to NSO to utilize this.

NSO on GlusterFS

The next step is to run our NSO containers on the persistent storage.

The directories that needs to be persisted in an NSO project are logs, ncs-cdb and the state directory.

Please navigate to k8s-lab/persistent-nso and check out nso.yml. It has been modified from the previous version

FIXME: Export NC port

FIXME: Use HA state for readiness and liveliness

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nso
spec:
  selector:
    matchLabels:
      app: nso-app
  serviceName: nso-svc
  replicas: 3
  template:
    metadata:
      labels:
        app: nso-app
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - nso-app
              topologyKey: "kubernetes.io/hostname"
      containers:
        - name: nso-master
          image: kube-1:5000/nso-k8s-lab
          livenessProbe:
            httpGet:
              path: /restconf/data/ncs-state
              port: 8080
              httpHeaders:
                - name: Authorization
                  # echo -n "admin:admin" | base64
                  value: Basic YWRtaW46YWRtaW4=
          readinessProbe:
            httpGet:
              path: /restconf/data/ncs-state
              port: 8080
              httpHeaders:
                - name: Authorization
                  # echo -n "admin:admin" | base64
                  value: Basic YWRtaW46YWRtaW4=
          ports:
          - containerPort: 2024
            name: ssh
          - containerPort: 8080
            name: webui
          volumeMounts:
            - name: logs
              mountPath: /app/nso_project/logs
            - name: state
              mountPath: /app/nso_project/state
            - name: cdb
              mountPath: /app/nso_project/ncs-cdb
 
        - name: elector
          image: fredrikjanssonse/leader-elector:0.6
          args:
            - --election=nso-svc
            - --http=localhost:4040
          ports:
            - containerPort: 4040
              protocol: TCP
  volumeClaimTemplates:
  - metadata:
      name: cdb
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: glusterfs-storage
      resources:
        requests:
          storage: 1Gi
  - metadata:
      name: logs
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: glusterfs-storage
      resources:
        requests:
          storage: 1Gi
  - metadata:
      name: state
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: glusterfs-storage
      resources:
        requests:
          storage: 1Gi

FIXME: Certificates for NSO SSL, from Bruce

So for each of cdb, logs and state, we will create a persistent volume claim for 1Gb of storage.

Let's deploy this

$ kubectl create -f nso.yml
statefulset.apps/nso created

This will take some time and you can check the status

$ watch kubectl get pods,pvc,pv
 
Every 2.0s: kubectl get pods,pvc,pv                                                                                                                                                                                                                       kube-1: Wed Aug 22 10:15:32 2018
 
NAME                         READY     STATUS    RESTARTS   AGE
pod/glusterfs-4dgmv          1/1       Running   0          17m
pod/glusterfs-b45nm          1/1       Running   2          2h
pod/glusterfs-gvqfq          1/1       Running   1          2h
pod/heketi-86f98754c-cmt6s   1/1       Running   4          2h
pod/nso-0                    2/2       Running   0          1m
pod/nso-1                    2/2       Running   0          43s
pod/nso-2                    0/2       Pending   0          8s
 
NAME                                STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
persistentvolumeclaim/cdb-nso-0     Bound     pvc-cf316753-a62e-11e8-a520-0050568923a4   1Gi        RWO            glusterfs-storage   1m
persistentvolumeclaim/cdb-nso-1     Bound     pvc-e05c7112-a62e-11e8-a520-0050568923a4   1Gi        RWO            glusterfs-storage   43s
persistentvolumeclaim/cdb-nso-2     Pending                                                                        glusterfs-storage   8s
persistentvolumeclaim/logs-nso-0    Bound     pvc-cf31f0ac-a62e-11e8-a520-0050568923a4   1Gi        RWO            glusterfs-storage   1m
persistentvolumeclaim/logs-nso-1    Bound     pvc-e059086b-a62e-11e8-a520-0050568923a4   1Gi        RWO            glusterfs-storage   43s
persistentvolumeclaim/logs-nso-2    Pending                                                                        glusterfs-storage   8s
persistentvolumeclaim/state-nso-0   Bound     pvc-cf3289c0-a62e-11e8-a520-0050568923a4   1Gi        RWO            glusterfs-storage   1m
persistentvolumeclaim/state-nso-1   Bound     pvc-e05ba39d-a62e-11e8-a520-0050568923a4   1Gi        RWO            glusterfs-storage   43s
persistentvolumeclaim/state-nso-2   Pending                                                                        glusterfs-storage   8s
 
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                 STORAGECLASS        REASON    AGE
persistentvolume/pvc-cf316753-a62e-11e8-a520-0050568923a4   1Gi        RWO            Delete           Bound     default/cdb-nso-0     glusterfs-storage             55s
persistentvolume/pvc-cf31f0ac-a62e-11e8-a520-0050568923a4   1Gi        RWO            Delete           Bound     default/logs-nso-0    glusterfs-storage             59s
persistentvolume/pvc-cf3289c0-a62e-11e8-a520-0050568923a4   1Gi        RWO            Delete           Bound     default/state-nso-0   glusterfs-storage             55s
persistentvolume/pvc-e059086b-a62e-11e8-a520-0050568923a4   1Gi        RWO            Delete           Bound     default/logs-nso-1    glusterfs-storage             25s
persistentvolume/pvc-e05ba39d-a62e-11e8-a520-0050568923a4   1Gi        RWO            Delete           Bound     default/state-nso-1   glusterfs-storage             21s
persistentvolume/pvc-e05c7112-a62e-11e8-a520-0050568923a4   1Gi        RWO            Delete           Bound     default/cdb-nso-1     glusterfs-storage             29s

After a while you should see all pods get status running, at that point press ctrl-c to break the watch.

Let's create some configuration data in NSO

$ http_proxy="" curl -H "Content-Type: application/yang-data+json" -d "" -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test/ping

And to check the result

$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test
 
<ha-test xmlns="http://example.com/ha-test"  xmlns:ha-test="http://example.com/ha-test">
  <count>1</count>
  <last-host>nso-0</last-host>
</ha-test>

Now let's get the HA status

$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ncs-state/ha
 
<ha xmlns="http://tail-f.com/yang/ncs-monitoring"  xmlns:tfnm="http://tail-f.com/yang/ncs-monitoring">
  <mode>master</mode>
  <node-id>nso-0</node-id>
  <connected-slave>nso-1</connected-slave>
  <connected-slave>nso-2</connected-slave>
</ha>

Test HA Failover

By running the command above, we can see that nso-0 is the master.

First test is simply to kill that pod and make sure everything comes up again.

NOTE Make sure you kill the pod that's the leader when you run.

$ kubectl delete pod nso-0
pod "nso-0" deleted

After a short while, nso-0 will be back. Sometimes, depending on timing, nso-0 might still be the leader.

$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ncs-state/ha
 
<ha xmlns="http://tail-f.com/yang/ncs-monitoring"  xmlns:tfnm="http://tail-f.com/yang/ncs-monitoring">
  <mode>master</mode>
  <node-id>nso-0</node-id>
  <connected-slave>nso-1</connected-slave>
  <connected-slave>nso-2</connected-slave>
</ha>

If nso-0 is still the leader, we can use the cordon/uncordon trick to force selection of a new leader.

First let's see where each pod is running

$ kubectl get pods -o=wide
NAME                     READY     STATUS    RESTARTS   AGE       IP            NODE      NOMINATED NODE
glusterfs-4dgmv          1/1       Running   0          1h        10.0.0.4      kube-1    <none>
glusterfs-b45nm          1/1       Running   2          3h        10.0.0.6      kube-3    <none>
glusterfs-gvqfq          1/1       Running   1          3h        10.0.0.5      kube-2    <none>
heketi-86f98754c-cmt6s   1/1       Running   4          3h        10.244.1.7    kube-2    <none>
nso-0                    2/2       Running   0          1m        10.244.2.10   kube-3   <none>
nso-1                    2/2       Running   0          59s       10.244.1.11   kube-2    <none>
nso-2                    2/2       Running   0          42s       10.244.0.4    kube-1    <none>

Here I see that nso-0, the leader, is running on kube-3. Let's disable scheduling on that node

$ kubectl cordon kube-3
node/kube-3 cordoned

And now if we delete nso-0, it will not come up until we uncordon the node

$ kubectl delete pod nso-0
pod "nso-0" deleted

And now if we check the pods

test@kube-1:~/nfs/kube-ha/k8s-lab/persistent-nso$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
glusterfs-4dgmv          1/1       Running   0          1h
glusterfs-b45nm          1/1       Running   2          3h
glusterfs-gvqfq          1/1       Running   1          3h
heketi-86f98754c-cmt6s   1/1       Running   4          3h
nso-0                    0/2       Pending  0          23s
nso-1                    2/2       Running   0          3m
nso-2                    2/2       Running   0          3m

We'll also see a new leader elected

$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ncs-state/ha
 
<ha xmlns="http://tail-f.com/yang/ncs-monitoring"  xmlns:tfnm="http://tail-f.com/yang/ncs-monitoring">
  <mode>master</mode>
  <node-id>nso-1</node-id>
  <connected-slave>nso-2</connected-slave>
</ha>

Last, we can uncordon the node to let nso-0 be scheduled.

$ kubectl uncordon kube-3
node/kube-3 uncordoned
 
$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
glusterfs-4dgmv          1/1       Running   0          1h
glusterfs-b45nm          1/1       Running   2          3h
glusterfs-gvqfq          1/1       Running   1          3h
heketi-86f98754c-cmt6s   1/1       Running   4          3h
nso-0                    2/2       Running   0          2m
nso-1                    2/2       Running   0          5m
nso-2                    2/2       Running   0          4m
 
$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ncs-state/ha
 
<ha xmlns="http://tail-f.com/yang/ncs-monitoring"  xmlns:tfnm="http://tail-f.com/yang/ncs-monitoring">
  <mode>master</mode>
  <node-id>nso-1</node-id>
  <connected-slave>nso-0</connected-slave>
  <connected-slave>nso-2</connected-slave>
</ha>

Let's do the HA test again

$ http_proxy="" curl -H "Content-Type: application/yang-data+json" -d "" -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test/ping

And to check the result

$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test
 
<ha-test xmlns="http://example.com/ha-test"  xmlns:ha-test="http://example.com/ha-test">
  <count>3</count>
  <last-host>nso-1</last-host>
</ha-test>

All good!

Now if we redo the test where we kill all the NSO pods

$ kubectl get pods | grep nso | awk '{print $1}' | xargs kubectl delete pod
pod "nso-0" deleted
pod "nso-1" deleted
pod "nso-2" deleted

Deleting and spinning up the pods may take a while, watch the status

$ watch kubectl get pod -o=wide

When the NSO pods are up, let's check the config again

$ http_proxy="" curl -u admin:admin http://$NSO_IP:8080/restconf/data/ha-test
 
<ha-test xmlns="http://example.com/ha-test"  xmlns:ha-test="http://example.com/ha-test">
  <count>3</count>
  <last-host>nso-1</last-host>
</ha-test>

All came up with no data lost.

Clean up Persistent Volume Claims

By default, when the NSO stateful set is deleted, k8s will not delete the volume claims. To clean up we can do this (NOTE: this will remove all PVCs):

$ kubectl get pvc | tail -n +2 | awk '{print $1}'  | xargs kubectl delete pvc
persistentvolumeclaim "cdb-nso-0" deleted
persistentvolumeclaim "cdb-nso-1" deleted
persistentvolumeclaim "cdb-nso-2" deleted
persistentvolumeclaim "logs-nso-0" deleted
persistentvolumeclaim "logs-nso-1" deleted
persistentvolumeclaim "logs-nso-2" deleted
persistentvolumeclaim "state-nso-0" deleted
persistentvolumeclaim "state-nso-1" deleted
persistentvolumeclaim "state-nso-2" deleted

YDK python API documentation page can't be reached

vipaoqun@hotmail.com — Fri, 19 Oct 2018 06:50:17 GMT

YDK python API documentation page http://ydk.cisco.com/py/docs can't be reached................

Finesse – Display CUIC report in a new tab in Finesse Agent using a Permalink

mark.baker@midlandsco-op.com — Tue, 21 Aug 2018 14:16:37 GMT

Symptoms

Reqested to display a CUIC report in Finesse Agent Desktop

Diagnosis

User wanted stats from a report they had created in CUIC to be displayed as a new tab in Finesse Agent Desktop.

Solution

Attached is a solution I got to work using UCCX 10.6.1

Cisco 5921 Reference System Getting Started v2

fcolumbu — Tue, 21 Aug 2018 09:21:42 GMT

This presentation discusses how to create a reference PC for integrating the Cisco 5921 Embedded Services Router.

5921 ESR with VM as Reference System.pdf

fcolumbu — Tue, 21 Aug 2018 09:18:42 GMT

5921 ESR Reference System Operations in a Virtual Machine

Cisco 5921 ESR Demo Guide for dCloud

fcolumbu — Tue, 21 Aug 2018 09:14:44 GMT

Introduction to the Cisco 5921 Embedded Services Router v1

The demonstration section walks the user through the highlights and features of this solution, to improve the end user’s familiarity with the Cisco 5921 ESR. No previous Linux experience is required.

The purpose of the lab sections of this document is to enhance your skills as an integrator by giving a concrete example of how to qualify a Linux embedded core build for use with the Cisco 5921 Embedded Services Router (ESR), as well as, taking you through the install and troubleshooting of the Cisco 5921 ESR installation on that system.

Finally, we have included reference materials to provide additional information about this product.

This demo will launch in mid October 2015 and will be listed in Internet of Everything and under Training and Labs.

Please visit https://dcloud.cisco.com to learn more.

Cisco dCloud lab - CONFIGURING SITE TO SITE IPSEC VPN TUNNEL BETWEEN CISCO ROUTERS - c5921_ubuntu32_1 - View

fcolumbu — Tue, 21 Aug 2018 09:06:12 GMT

This configuration is used with “Introduction to the Cisco 5921 Embedded Services Router v1” in dCloud.

Derived from:

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/867-cisco-router-site-to-site-ipsec-vpn.html

Lines in BOLD ORANGE are changes made to the existing configuration to do the lab exercise.

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.11.21 23:08:52 =~=~=~=~=~=~=~=~=~=~=~=

c5921_ubuntu32_1#wr t

Building configuration...

Current configuration : 5442 bytes

! Last configuration change at 23:06:09 PST Sat Nov 21 2015

! NVRAM config last updated at 23:06:13 PST Sat Nov 21 2015

version 15.5

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service call-home

hostname c5921_ubuntu32_1

boot-start-marker

boot-end-marker

enable secret 5 $1$x.6O$4UZX1B5lYLF1DeOul7GiV1

enable password cisco

no aaa new-model

bsd-client server url https://cloudsso.cisco.com/as/token.oauth2

clock timezone PST -8 0

mmi polling-interval 60

no mmi auto-configure

no mmi pvc

mmi snmp-timeout 180

call-home

! if contact email address in call-home is configured as sch-smart-licensing@cisco.com

! The email address configured in Cisco Smart License Portal will be used as contact email address to send SCH notifications

contact-email-addr sch-smart-licensing@cisco.com

profile "CiscoTAC-1"

active

destination transport-method http

no destination transport-method email

ip name-server 8.8.8.8

ip cef

no ipv6 cef

multilink bundle-name authenticated

crypto pki trustpoint SLA-TrustPoint

enrollment pkcs12

revocation-check crl

crypto pki certificate chain SLA-TrustPoint

certificate ca 01

30820321 30820209 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030

32310E30 0C060355 040A1305 43697363 6F312030 1E060355 04031317 43697363

6F204C69 63656E73 696E6720 526F6F74 20434130 1E170D31 33303533 30313934

3834375A 170D3338 30353330 31393438 34375A30 32310E30 0C060355 040A1305

43697363 6F312030 1E060355 04031317 43697363 6F204C69 63656E73 696E6720

526F6F74 20434130 82012230 0D06092A 864886F7 0D010101 05000382 010F0030

82010A02 82010100 A6BCBD96 131E05F7 145EA72C 2CD686E6 17222EA1 F1EFF64D

CBB4C798 212AA147 C655D8D7 9471380D 8711441E 1AAF071A 9CAE6388 8A38E520

1C394D78 462EF239 C659F715 B98C0A59 5BBB5CBD 0CFEBEA3 700A8BF7 D8F256EE

4AA4E80D DB6FD1C9 60B1FD18 FFC69C96 6FA68957 A2617DE7 104FDC5F EA2956AC

7390A3EB 2B5436AD C847A2C5 DAB553EB 69A9A535 58E9F3E3 C0BD23CF 58BD7188

68E69491 20F320E7 948E71D7 AE3BCC84 F10684C7 4BC8E00F 539BA42B 42C68BB7

C7479096 B4CB2D62 EA2F505D C7B062A4 6811D95B E8250FC4 5D5D5FB8 8F27D191

C55F0D76 61F9A4CD 3D992327 A8BB03BD 4E6D7069 7CBADF8B DF5F4368 95135E44

DFC7C6CF 04DD7FD1 02030100 01A34230 40300E06 03551D0F 0101FF04 04030201

06300F06 03551D13 0101FF04 05300301 01FF301D 0603551D 0E041604 1449DC85

4B3D31E5 1B3E6A17 606AF333 3D3B4C73 E8300D06 092A8648 86F70D01 010B0500

03820101 00507F24 D3932A66 86025D9F E838AE5C 6D4DF6B0 49631C78 240DA905

604EDCDE FF4FED2B 77FC460E CD636FDB DD44681E 3A5673AB 9093D3B1 6C9E3D8B

D98987BF E40CBD9E 1AECA0C2 2189BB5C 8FA85686 CD98B646 5575B146 8DFC66A8

467A3DF4 4D565700 6ADF0F0D CF835015 3C04FF7C 21E878AC 11BA9CD2 55A9232C

7CA7B7E6 C1AF74F6 152E99B7 B1FCF9BB E973DE7F 5BDDEB86 C71E3B49 1765308B

5FB0DA06 B92AFE7F 494E8A9E 07B85737 F3A58BE1 1A48A229 C37C1E69 39F08678

80DDCD16 D6BACECA EEBC7CF9 8428787B 35202CDC 60E4616A B623CDBD 230E3AFB

418616A9 4093E049 4D10AB75 27E86F73 932E35B5 8862FDAE 0275156F 719BB2F0

D697DF7F 28

quit

license udi pid CISCO5921-K9 sn 91J81443B9I

license platform throughput level c5921-x86-level3

redundancy

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key cisco123 address 172.23.1.121

crypto ipsec transform-set myset esp-3des esp-md5-hmac

mode tunnel

crypto map CMAP 10 ipsec-isakmp

set peer 172.23.1.121

set transform-set myset

match address VPN-TRAFFIC

interface Loopback0

ip address 10.0.0.120 255.255.255.255

interface Loopback1

description Inside interface

ip address 10.1.1.1 255.255.255.0

ip nat inside

ip virtual-reassembly in

interface Ethernet0/0

description Outside interface

ip address 172.23.1.120 255.255.255.0

ip nat outside

ip virtual-reassembly in

duplex full

speed 1000

no mop enabled

crypto map CMAP

interface Ethernet0/1

ip address 172.23.2.1 255.255.255.0

shutdown

duplex full

speed 1000

interface Ethernet0/2

ip address 172.23.3.1 255.255.255.0

shutdown

duplex full

speed 1000

interface Ethernet0/3

ip address 172.23.4.1 255.255.255.0

shutdown

duplex full

speed 1000

interface Ethernet1/0

description TAP interface

ip address 198.18.134.131 255.255.192.0

interface Ethernet1/1

no ip address

shutdown

interface Ethernet1/2

no ip address

shutdown

interface Ethernet1/3

no ip address

shutdown

router ospf 100

network 10.0.0.0 0.255.255.255 area 0

network 172.23.1.0 0.0.0.255 area 0

network 172.23.2.0 0.0.0.255 area 0

network 172.23.3.0 0.0.0.255 area 0

network 172.23.4.0 0.0.0.255 area 0

network 198.18.128.0 0.0.63.255 area 0

default-information originate

ip forward-protocol nd

no ip http server

no ip http secure-server

ip nat inside source list 100 interface Loopback1 overload

ip route 0.0.0.0 0.0.0.0 198.18.134.120

ip access-list extended VPN-TRAFFIC

permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

snmp-server community public RO

access-list 100 remark -=[Define NAT Service]=-

access-list 100 deny ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

access-list 100 permit ip 10.2.2.0 0.0.0.255 any

control-plane

line con 0

logging synchronous

line aux 0

line vty 0 4

password cisco

transport input all

ntp server 198.18.134.132

end

c5921_ubuntu32_1#show crypto session

Crypto session current status

Interface: Ethernet0/0

Session status: UP-ACTIVE

Peer: 172.23.1.121 port 500

Session ID: 0

IKEv1 SA: local 172.23.1.120/500 remote 172.23.1.121/500 Active

IPSEC FLOW: permit ip 10.1.1.0/255.255.255.0 10.2.2.0/255.255.255.0

Active SAs: 4, origin: crypto map

c5921_ubuntu32_1#show crypto isakmp sa detail

Codes: C - IKE configuration mode, D - Dead Peer Detection

K - Keepalives, N - NAT-traversal

T - cTCP encapsulation, X - IKE Extended Authentication

psk - Preshared key, rsig - RSA signature

renc - RSA encryption

IPv4 Crypto ISAKMP SA

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.

1001 172.23.1.120 172.23.1.121 ACTIVE aes md5 psk 2 23:08:57

Engine-id:Conn-id = SW:1

IPv6 Crypto ISAKMP SA

c5921_ubuntu32_1# show crypto ipsec sa

interface: Ethernet0/0

Crypto map tag: CMAP, local addr 172.23.1.120

protected vrf: (none)

local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)

current_peer 172.23.1.121 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

#pkts decaps: 14, #pkts decrypt: 14, #pkts verify: 14

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 172.23.1.120, remote crypto endpt.: 172.23.1.121

plaintext mtu 1390, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0

current outbound spi: 0x9FF24064(2683453540)

PFS (Y/N): N, DH group: none

inbound esp sas:

spi: 0x1C810439(478217273)

transform: esp-256-aes esp-sha512-hmac ,

in use settings ={Tunnel, }

conn id: 1, flow_id: SW:1, sibling_flags 80000070, crypto map: CMAP

sa timing: remaining key lifetime (k/sec): (4282818/527)

IV size: 16 bytes

replay detection support: Y

Status: ACTIVE(ACTIVE)

inbound ah sas:

spi: 0x87BD5EC6(2277334726)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

conn id: 1, flow_id: SW:1, sibling_flags 80000070, crypto map: CMAP

sa timing: remaining key lifetime (k/sec): (4282818/527)

replay detection support: Y

Status: ACTIVE(ACTIVE)

inbound pcp sas:

outbound esp sas:

spi: 0x668F64B(107542091)

transform: esp-256-aes esp-sha512-hmac ,

in use settings ={Tunnel, }

conn id: 2, flow_id: SW:2, sibling_flags 80000070, crypto map: CMAP

sa timing: remaining key lifetime (k/sec): (4282821/527)

IV size: 16 bytes

replay detection support: Y

Status: ACTIVE(ACTIVE)

outbound ah sas:

spi: 0x9FF24064(2683453540)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

conn id: 2, flow_id: SW:2, sibling_flags 80000070, crypto map: CMAP

sa timing: remaining key lifetime (k/sec): (4282821/527)

replay detection support: Y

Status: ACTIVE(ACTIVE)

outbound pcp sas:

c5921_ubuntu32_1#sh ver

Cisco IOS Software, C5921 Software (C5921_I86-UNIVERSALK9-M), Version 15.5(2)T, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Compiled Wed 25-Mar-15 15:49 by prod_rel_team

ROM: Bootstrap program is Linux

c5921_ubuntu32_1 uptime is 1 hour, 6 minutes

System returned to ROM by reload at 0

System restarted at 22:04:40 PST Sat Nov 21 2015

System image file is "unix:./c5921i86-universalk9-ms.SPA"

Last reload reason: Unknown reason

This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and

use. Delivery of Cisco cryptographic products does not imply

third-party authority to import, export, distribute or use encryption.

Importers, exporters, distributors and users are responsible for

compliance with U.S. and local country laws. By using this product you

agree to comply with applicable laws and regulations. If you are unable

to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to

export@cisco.com.

Cisco C5921 (Intel-x86) processor with 381079K bytes of memory.

Processor board ID 100

8 Ethernet interfaces

512K bytes of NVRAM.

License Info:

License UDI:

-------------------------------------------------

Device# PID SN

-------------------------------------------------

*0 CISCO5921-K9 91J81443B9I

Packet forwarding: Enabled

Enforced traffic rate: 50 Mbps

Configuration register is 0x0

c5921_ubuntu32_1#

Cisco dCloud lab - CONFIGURING SITE TO SITE IPSEC VPN TUNNEL BETWEEN CISCO ROUTERS - c5921_ubuntu32_2 - View

fcolumbu — Tue, 21 Aug 2018 09:04:19 GMT

This configuration is used with “Introduction to the Cisco 5921 Embedded Services Router v1” in dCloud.

Derived from:

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/867-cisco-router-site-to-site-ipsec-vpn.html

Lines in BOLD ORANGE are changes made to the existing configuration to do the lab exercise.

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.11.21 23:16:28 =~=~=~=~=~=~=~=~=~=~=~=

c5921_ubuntu32_2#wr t

Building configuration...

Current configuration : 5052 bytes

! Last configuration change at 22:46:05 PST Sat Nov 21 2015

! NVRAM config last updated at 22:49:44 PST Sat Nov 21 2015

version 15.5

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service call-home

hostname c5921_ubuntu32_2