Friday 16 November 2018

Modernization of the Workforce Experience Journey

Collaboration technology is innovating at its fastest pace with more options than ever to increase productivity and empower workforces across the globe. CIOs are doing well in thinking about how they can use collaboration technology to their advantage, but there’s a drawback. Investments don’t always go as planned.

One of the main limitations we see is that organizations get caught in a vicious cycle, which traps them almost like quicksand (Figure 1).

Figure 1: Collaboration Investment Cycle

Cisco Study Materials, Cisco Guides, Cisco Learning, Cisco Tutorial and Material

To break this cycle and create a truly integrated work experience, companies first need to think about collaboration investments in terms of continually aligning three aspects: people and the culture, technology, and organizational vision (Figure 2).

Figure 2: Collaboration Investment Alignment

Cisco Study Materials, Cisco Guides, Cisco Learning, Cisco Tutorial and Material

Ideally all three aspects will carry equal weight because any breakdown will cause disruption to employee productivity. Figure 2 begins with organizational vision, in which investments are made from the bottom-up, rather than top-down, and driven by strong use-cases that highlight the need for specific change. Companies need to see how all the collaboration technology should work together in tandem to bolster productivity:

◈ People start work in documents and can share their content in real-time using a built-in Teams messaging application. They can easily choose who to share their content with (on their web browser, the application itself or their devices, or through email), as directories and Content Management Systems (CMS) are fully integrated
◈ When it’s time to join a meeting, employees can meet instantly with a “Join Now” option or simply use their email, which seamlessly links company directories and calendars
◈ Then people go into meetings in which they share their work to colleagues (both audibly and visually). People on-the-go can see and hear everything in high-quality format
◈ When the meeting ends, people can continue working in their documents and across Teams

Once an integrated vision is complete, organizations invest in the technology that will help turn this vision into a reality. However, this is where the disconnect between expectations and results often begins. Many companies purchase the collaboration products necessary for the integration but overlook the fact that they need services to truly tie everything together.

Cisco Services is the glue that helps customers with Cisco Collaboration products adapt and convert to a fully digitized collaboration environment, both efficiently and cost-effectively. We help organizations proactively solve issues ahead of time, such as network deficiencies that cause video quality issues, and reduce complexity with machine learning (ML) and artificial intelligence (A.I.) that can automate workflows for employees. We can even custom design a solution built around an organization’s unique needs and integrate with Content Management Systems for easy workflows with Webex Teams. The best part is, we can work with our partners to develop a hybrid go-to-market strategy for our customers, in which each party contributes a specialized portion of the solution.

We recently did this with a large global service provider who was able to ultimately lower its operational costs. Cisco helped the company create an enterprise-wide collaboration strategy and timeline through our “Strategy & Roadmap” service and devised an implementation plan through our Advise & Implementation service. One of our partners was brought in to enhance the collaboration solution through AI, natural voice recognition, and improved customer experience metrics while the other partner served as a systems integrator. This hybrid solution helped to ultimately win over the client with everybody’s combined credibility and experience. Cisco’s products and services, along with partner expertise, help our customers realize the value of their Collaboration technology investments more easily.

Throughout our experience, we’ve found that companies generally need help with digital integration in one or more different areas, which we call phases (Figure 3).

Figure 3: Digital Transformation Phases

Cisco Study Materials, Cisco Guides, Cisco Learning, Cisco Tutorial and Material

Phase 1 engages all employees and helps businesses deliver a seamless meeting experience – from scheduling to joining to fully experiencing video and audio quality at scale. At this stage, customers often use our Webex [and Webex Teams] Advise & Implement service to get expert help and guidance on planning, designing, and deploying a full collaboration solution that minimizes the time and expense needed to achieve success. Before we even begin, we verify a network’s ability to support the proposed Cisco solution, analyze gaps and address likely risks, and provide remediation steps to quickly “nip problems in the bud.” This will help support an integrated collaboration environment that provides seamless collaboration (i.e. calling, meeting, messaging, and Teams content sharing) and user experience.

Phase 2 helps customers evolve their work by enabling video-first meeting experiences and integrating team collaboration with existing workloads, workstyles, and systems. The goal is to tap the collective intelligence of the enterprise and speed decision making among employees. At this stage, customers usually rely on us for our “Hybrid Media Services,” which can help them migrate to the cloud slowly while delivering consistent user experiences at infinite scale, and our Business Critical Services,  which help to reduce complexity and costs through analytics, automation, and ML/AI. The real benefit from Business Critical Services is that they can help customers move to a more proactive IT model that can predict and fix problems automatically before reaching the end-user. Future corrective action could be as easy as fine-tuning the automation or additional configurations and could be as complex as predicting a crash that could render the network (and thus collaboration efforts) useless.

Finally, Phase 3 empowers teams by integrating the workflows from 3rd party applications, such as Office365, Box, ServiceNow, Microsoft Exchange and Active Directory, etc. Customers rave about our Custom Application Development &. Integration (CADI) service, which provides API integration for third party application. For one global financial institution, Cisco Services used its CADI service to combine Webex Teams with an automated assisted bot program powered by A.I. Ultimately, we were able to virtually eliminate manual, repetitive, time-consuming tasks that not only reduced OpEx by saving the organization thousands of man hours but also helped assemble packages for portfolio reviews and ensured quality, standardization, and better service for its customers. Other popular services at this stage include “Webex Teams Archival and eDiscovery” service, which enables storage, search, and retrieval of eDiscovery documents, and our “CloudLock” service, which helps to secure cloud communications.

Once customers are able to strongly link products and services for their collaboration technology, as well as successfully map out an organizational vision, the last step, as outlined in Figure 2, is to ensure that all employees are adopting the collaboration tools and using them to the best of their advantage. Businesses at this stage rely on Cisco Services for our Adoption (User Solution Empowerment (USE)) services, which provide customized processes, tools, and techniques from certified change management professionals that help end users adopt your collaboration products and technology with greater speed and effectiveness. Getting an organization’s employees to consistently use, and rely on, an integrated set of collaboration technologies is the final key to avoid the common disconnect between collaboration investment, expectations, and results (see Figure 1).

Wednesday 14 November 2018

Bridging the Gap between Data Scientists and IT

The Golden Gate Bridge was built to connect San Francisco and Marin County using a suspension bridge over a mile long.  It was built during the Great Depression and took over 4 years to construct with over 1.2 million rivets.

When I talk to data scientists and IT teams in the same room, I often feel that the distance between the 2 teams is much more than the mile that Golden Gate Bridge covers.  They have very different expertise and vocabulary making effective communication difficult.  The speed of execution for delivering machine learning projects has a huge financial impact.  Data scientists often work with data pipelines, and IT teams are focused on the infrastructure.  So, naturally, there may be some communication gaps between the two teams.  Recently, when I show data scientists and IT teams that Cisco Validated Designs are able to provide a scalable architecture supporting data pipelines, the dynamics of the room changed from one of indifference to that of tight collaboration.

What is a Data Pipeline?


First let’s talk about data pipelines.  As an example, the diagram below shows a data pipeline for a single data source. The data scientist has to collect, clean, and correlate the data before sending it for machine learning training.  Eventually, a good model emerges, enabling new data to be fed to the model for updated inference results.

Cisco Study Materials, Cisco Tutorial and Material, Cisco Data Center
Data Pipeline for Single Data Source

But increasingly, customers are working with much more sophisticated data pipelines.  As shown in the diagram below, often times, data scientists are working with multiple data sources, each with their own pipeline for collection, cleansing, and correlation.  The inferred data from each of these data sources is then fed to a second stage of learning gathering the information from multiple data sources.  In fact, this type of data pipeline with multiple data sources can be found in many verticals, from security to targeted marketing campaigns.  On any given day, data scientists can be focused on issues related to any part of the pipeline.  In fact, he or she is probably also wondering whether additional data sources, such as structured data, live news feed, geolocation data, and other sources, should be added to the mix to gain deeper insights into the business problem at hand.  Note that the focus on the data and its operations prevents the data scientists from focusing on the infrastructure that is needed to run the data pipelines.

Cisco Study Materials, Cisco Tutorial and Material, Cisco Data Center
Data Pipeline for Multiple Data Sources

What Tools are Available to Implement Data Pipelines?


There are many tools available to implement data pipelines. Each data scientist will have preferences depending on familiarity, data type and software package  A small sample of tools is listed in the diagram below.  At the end of the day, these sophisticated data pipelines are still software running on servers:  It’s NOT rocket science.

Cisco Study Materials, Cisco Tutorial and Material, Cisco Data Center
Data Pipeline Software Tools

Infrastructure Solutions for Date Pipelines


As Cisco works with customers from different verticals, some patterns start to emerge. While not all customers will have the same architecture, we see that many customers end up having a combination of

◈ Data Ingestion Infrastructure: For storing, staging, and streaming the information before going to the next part of the data pipeline.  Often, this can be a Hadoop layer where the data is close to the compute enabling high parallel processing of the data.
◈ Compute Intensive Infrastructure:  For compute intensive workloads like machine learning and deep learning training, a dedicated cluster can be used to accelerate the processing
◈ Storage Infrastructure:  At some point, the raw and processed data needs to be stored.  Having a dedicated storage infrastructure makes it easier to provide scalable storage capable of delivering proper backup and ease of management.

Cisco Study Materials, Cisco Tutorial and Material, Cisco Data Center
Infrastructure Solutions for the Data Pipeline

While not every customer will have separate clusters for each of the functions cited above, we do find that many customers do have the various functions such as data ingestion, storage, etc.  For example, the Cisco Validated Design with Cloudera Data Science Workbench, incorporates data ingestion and storage as part of the Hadoop cluster that includes Apache Spark and Hadoop File System.  In addition, Cloudera Data Science Workbench creates a compute-intensive cluster capable of using servers with GPUs running deep learning frameworks, such as TensorFlow.

Building a Bridge between Data Science and IT through the Artificial Intelligence and Machine Learning Partner Ecosystem


Cisco is continuing to work with machine learning ecosystem partners to help bridge the gap between data scientists and IT.  In fact, Cisco is delighted to see Google adding Kubeflow Pipelines to the Kubeflow open source project.  This latest contribution expands TensorFlow’s capability to compose a data pipeline with reusable components accelerating the work of data scientists.  Cisco is also contributing code to the Kubeflow project, ensuring a consistent hybrid cloud architecture for machine learning.

Cisco is also participating in NVIDIA’s new NGC-Ready program, ensuring that Cisco servers, such as the recently announced UCS C480 ML, can take advantage of the NGC container registry and its large repository of pre-built and optimized containers with the latest machine learning and deep learning frameworks.

“Powerful software benefits from powerful systems,” said Kari Briski, Sr. Director, Accelerated Computing Software and AI Product, NVIDIA. “With NGC-Ready, users of the Cisco UCS C480 ML, with its 8 NVIDIA Tesla V100 GPUs interconnected with NVLink, can leverage NGC containers to create an ideal solution for large-scale deep learning workloads.”

In working with the artificial intelligence and machine learning ecosystem, Cisco is bridging the gap between data scientist and IT.  At the end of the day, Cisco’s goal is to accelerate your the machine learning deployment and refine the mining of your data.

Where are you in your journey to adopt artificial intelligence and machine learning?  Check out some of the Cisco Validated Designs to help you accelerate.  Reach out to your Cisco account team, and we can have a deeper conversation.  If you are attending SC18 in Dallas, Texas, stop by the Cisco Booth, #2803.

Sunday 11 November 2018

Get Started with the Whole of Branch Provisioning – Virtual and Physical

Earlier blogs have covered PnP use cases for simple deployments of a single switch.  This blog covers the design and automated deployment of a complete branch infrastructure. There will be no need to connect to the Command Line Interface (CLI) of any device.

Topology


In this example, Enterprise Network Compute Server (ENCS) is used to host the virtual network function(s).  This simple example has only a single function, an ISR router (ISRv).  This could easily be extended to include Cisco and third party virtual network functions.

The example shows automated provisioning of both virtual (ISRv) and physical (Catalyst 9300).  There are two connections between the ISRv and the 9300.  This could be simplified, but the two connection model provides all choices of connections between the ENCS running ISRv and the 9300 (L2, L3, PortChannel, ECMP etc).

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Process


DNA Center provides the automation tools for this deployment. There are three main steps illustrated below:

1. Design phase. This is where IP address pools, site specific settings like credentials, DNS, AAA are defined.  In addition a network profile is defined, which include the “design” of the ENCS network functions and their internal network connectivity.  Finally, the network profile is mapped to one or more “sites.”  Site hierarchy is also defined in this phase.

2. Once the device is connected to the network, it uses PnP to discover the DNAC and will appear as an “unclaimed” device. The “claim” process simply assigns the device to a site.

3. Once the device is assigned to a site, it can be provisioned. This step places any device specifc settings (for example interfaces).  Most of this information has already been defined in the design, so cannot be changed.   The ISRv is also provisioned, but there is very little to change.  Once the WAN services are up, the Catalyst 9300 automatically uses PnP to obtain it’s configuration.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Example


This example assumes the design has been complete (just to show how simple it is).  I will come back to the design later on.

Claim Step

This example assumes a new ENCS device has been connected to the WAN, and it is able to discover DNA Center.  It will appear as an unclaimed device under the provisioning workflow.  Provision -> Unclaimed Devices

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Next step is to select the nfvis device (nfvis is the default name for the device), and claim it.  All that is required is a site, in this example “Brisbane”.  Click Apply.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Click on the inventory tab, and you will soon see the device added to inventory, but in the “unprovisioned” state.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Provision Step

Now to provision the ENCS based on the network profile in the design phase.

Select the device, then go up to the “Actions” menu and select “provision”.  This will begin the provisioning workflow.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

In the first step, there is little to do, unless you are provisioning multiple devices at once.  The main thing to remember is the “Next” button at the bottom of the screen to progress to the next step.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Step 2 (router WAN) is where the WAN interface for the ISRv is done.  Click on the small circle that links the ENCS to the WAN.  Then fill in details for the IP address, WAN interface on ENCS, and bandwidth.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Step 3 is the Integrated Switch configuration. ENCS has built in switch with up to eight ports.   In this example there are internal networks map to the two vlans.  In this example,  vlan 20 (service) is mapped to the service-net on ISRv and exposed on interface GigabitEthernet1/0 on the ENCS switch.  Similarly, vlan 10 mapps to mgmt-net and interface GigabitEthernet1/1 on the ENCS switch.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

The final step is to review and deploy.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

After a short period of time, the ENCS will be provisioned, which will create all of the internal networking and spin up the ISRv, and add it to the inventory.  You can check on the status of the provisioning by clicking on the hotlink on the far left of the ENCS entry.  Note also the ISRv is added, but not yet provisioned.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Provisioning ISRv

The same workflow is followed for configuring the ISRv. In this example a pre-defined configuration template will be applied.  The template was defined and applied during the design phase.  This is exactly the same workflow as with the ENCS.

Firstly, select the ISRv, goto actions and select provision.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Step 1 is just a preview.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Step 2 is the router WAN configuration.  Again there is nothing to configure here as WAN configuration was done in the ENCS workflow.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Step 3 is the Router LAN configuration.  In this deployment, the router has a layer three connection (routed, OSPF) to the downstream Cat 9300, so this is not really required.  In this case Gig3 appears in the dropdown menu as it has a “LAN” tag.  Just select DHCP and the single address pool.  These come from the ENCS configuration.

Due to the deployment model (the service network is going to be used to connect to the switch, rather than the LAN network), these settings do not really matter.  In other deployment models, they are.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Step 4 is the custom configuration template.  In this example, there are no device specific variables in the template.  If there were, they would be filled in here.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Final step is to review and deploy.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Once deployment starts, it can be monitored in the same way as ENCS.

The end result is the ISRv will be deployed, and due to the DHCP configuration on the device, the Catalyst  9300 will also use PnP to automatically provision based on a pre-defined rule.   There are now three devices in the inventory.  You will notice the ISRv is “Out of date” as I made some changes to the configuration template post-deployment.  The 9300 is not fully provisioned as it has a day 0 configuration.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

I now have a fully deployed branch.

Details


This section shows the detailed configuration and how to define the network profile, along with ENCS/ISRv templates.  The templates augment the base configuration.

There are options where a single connection can be used to connect the 9300 and the ENCS.  In this scenario, there are limitations around topology (for example port channel will not auto-negotiate).  Using the management interface to PnP provision the switch, means any configuration can be applied to the front panel ports, without needing to establish connectivity first.

For example in the L3 connection, there is no default route provided to the 9300. It can only communicate to the outside world once OSPF is configured and comes up via the front panel ports.

In this case the service network and the management networks are being used and the LAN network is not required.  When other services such as firewall are used, the services network would link the router and the firewall and the LAN interface connect to the firewall.

The complete topology is configured via a network profile, and fully automated by DNA Center.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Design


IPAM

Three IP address pools are required for provisioning. They are:

◈ LAN for the LAN network.Typically this will be the connection to the end user devices.  As I am using a L3 link to the 9300 switch, the Lan networks will be terminated on the 9300, and this network is not being used.
◈ Service for the service network.In this example this will be a L3 connection to the 9300 switch.  In other topologies it will be used to link services such as Firewall into a chain.
◈ Management for the management network.Note, the management IP address is used to discover the ISRv router, so there needs to be reachability to it.

The current subnet masks are very generous, and would be optimized depending on the deployment scenario.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Templates

While most of the ENCS configuration is automated, extra configuration can be supplied in a template.  This allows capabilities that are not supported in the design workflow to be implemented. For example PortChannel on the switch ports. Currently, the switch vlan are used, but not defined via the design.  The ‘encs’ template contains these extra commands.

switch vlan 10
switch vlan 20

This template is used to configure the ISRv router. This is an extension to the base configuration, which includes everything to make the router discoverable by DNA Center. Although ospf is configured on the router, we need to change the networks that are advertised. DHCP scopes to allow PnP for the switch and the service interface for the 9300 switch are also defined.

router ospf 100
network 10.10.2.0 0.0.0.255 area 0
no network 192.168.200.0 0.0.0.255 area 0
network 192.168.200.0 0.0.1.255 area 200
   
ip dhcp excluded-address 192.168.200.129 192.168.200.180
!
ip dhcp pool PnP-mgmt
 network 192.168.200.128 255.255.255.128
 default-router 192.168.200.146
 option 43 ascii "5A1N;B2;K4;I10.10.10.181;J80"
   
ip dhcp excluded-address 192.168.200.1 192.168.200.60
!
ip dhcp pool PnP-service
 network 192.168.200.1 255.255.255.128

This is the configuration template for the 9300 switch. This template will be used in a PnP rule.

hostname $hostname
vtp mode off
enable password cisco
username cisco privilege 15 password 0 cisco123

interface Loopback0
ip address 1.1.1.1 255.255.255.255

ip routing  
router ospf 100
network 192.168.200.0 0.0.0.255 area 200

int vlan1
  no shut
  ip address dhcp
snmp-server community public RO
line vty 0 15
login local

Site Profile

To create a site profile, Design->Network Profiles -> Add Profile

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Select the type as “Routing & NFV”.  The first step  will be to choose the type of device and the WAN connections.  Service Provider Profile is defined under Design -> Network Settings -> SP Profiles.

You will also need to configure the WAN connection from the device to the WAN cloud.

Finish by editing the  services.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Editing services is where you add the VNF (ISRv) and configure the internal networking.   Make sure you have uploaded an ISRv image into the image repository first, so you can chose the VNF profile for the ISRv.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Next step is to click on the service-net and the mgmt-net and add a vlan tag, as well as make it an access network.

In my case, service-net = vlan 20 and mgmt-net = vlan 10

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Step two is to configure the connection between the ISR and the switch.  In this case it is L3.  The protocol is OSPF and the number is 100.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Third step is to configure the VLAN on the switch. In this case, both vlan 10 and 20 are used.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Finally, review the summary and save.

The only thing required to do is to add a site to the profile.

Cisco Tutorial and Materials, Cisco Guides, Cisco Learning, Cisco Study Materials

Validation


Once the desing and deployment is completed, the design can be verified by connecting to the 9300 router.  The OSPF peering has been established between the 9300 and the ISRv.

encs-9k#show ip ospf ne

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.202.17    1   FULL/DR         00:00:36    192.168.200.16  Vlan1

The 9300 and ISR are connected over an L2 link with the peering point on an SVI – vlan 1. It is very simple to change g1/0/1 to a routed interface, or to run an etherchanel underneath, depending on requirements.

encs-9k#show ip int br | inc up
Vlan1                  192.168.200.3   YES DHCP   up                    up      
GigabitEthernet0/0     192.168.200.183 YES DHCP   up                    up      
GigabitEthernet1/0/1   unassigned      YES unset  up                    up      
Loopback0              1.1.1.1         YES TFTP   up                    up   

Wednesday 7 November 2018

On-Box Python for Cisco Devices – the Why, What, and How

As a junior network engineer at a university I wrote a lot of management scripts in Perl.  I had scripts to do things such as check switchport configurations and upgrade switch code. Times have changed a lot since then. The university’s web server now runs in the cloud, rather than on my personal workstation, and Python has surpassed Perl as the scripting language du jour. Network automation with Python is now a major focus, making Python an extremely important tool.

Today I’m going to show you how to use Python scripts hosted on the box and integrated into IOS. This is far more powerful than my earlier-career scripts, and I have some simple examples for PCI compliance, Dynamic DNS ACL updates, and configuration validation.

As with many things in IT, we seem to be continually oscillating between “centralized” and “distributed.”  On-box hosting of Python scripts is an example of moving back toward distributed. My view on the argument is that it’s never about the extremes, but more about the balance—a bit like a pendulum constantly swinging as technology advances change what’s possible and practical.

Cisco Study Material, Cisco Guides, Cisco Learning, Cisco Tutorial and Material

Today, I want to demonstrate why Python scripts running on-box can be awesome.  I also want to explain how easy it is, based on the application hosting environment we’ve just released.  In addition, I’ll give some examples of how Python is even more powerful when combined with some of the existing IOS infrastructure such as Embedded Event Manager (EEM).

Why on-box Python?


There are three main advantages for Python scripts running on the device itself rather than externally.

◈ Scale: If I have a “sanity” script that I need to run regularly and it takes six seconds per device * 1000 devices, that would be 6,000 seconds, or one hour and 40 minutes.I could run them in parallel, but that still consumes resources on my management station, processing the data. It also potentially transports lots of data back to the management station, only to discard much of it.  An alternative is to distribute the work to the devices and get them to provide an update when they’re done.
◈ Security: Instead of having “utility” logins that connect into devices and export information for external processing, you can have the device process its data locally and just export the summary state. Data stays on the device, and less external connections are required.
◈ Autonomy: The biggest limitation of centralized processing is that it needs a network connection to the device. There is a set of use cases to modify device behaviour when it loses connectivity to other devices.  This can only be done on-box.

To illustrate the “what,” I’ve provided some sample scripts and use cases for the three points above. The code is published @  https://github.com/aradford123/on-box-python.git

To get started, we’re going to want to make sure Git is installed on your network device, run the following commands (after you’ve enabled guestshell; see section at the end for details).  The reason for using /flash/gs_script is that it’s a persistent directory and will be available on a switch stack switchover.

# install git
[guestshell@guestshell ~]$ sudo yum install git

# now install scripts into /flash/gs_script
[guestshell@guestshell ~]$ git clone https://github.com/aradford123/on-box-python.git /flash/gs_script

Example 1 – PCI compliance

Here’s an example of a use case that I think you’ll find interesting. One of our customers had a PCI requirement to ensure that any switch ports that were unused for more than seven days were disabled. (This was to prevent people from plugging in unauthorized devices.)
The script looks at all interfaces on the switch, and those that have been inactive (no traffic send/received) for more than seven days are shutdown. All interfaces that were shut down in a logged in a Cisco sparkroom. The interface description is updated with a message indicating the time/date it was shutdown by the PCI-check application.

Cisco Study Material, Cisco Guides, Cisco Learning, Cisco Tutorial and Material

To run the script, we’ll use the Embedded Event Manager.  EEM is a really powerful piece of IOS infrastructure that can be used to schedule the Python script to run.  The EEM cron job runs the Python script at 15 minutes past the hour, Monday to Friday.

event manager applet PCI-check
 event timer cron cron-entry "15 * * * 1-5"
 action 1.0 cli command "enable"
 action 1.1 cli command "guestshell run python bootflash:gs_script/src/pci-tool/pci_check.py --apply"

This script can now be run hourly (instead of weekly). It’s an example of scaling using on-box Python.

Example 2 – DNS ACL

Another customer had a requirement to keep an ACL updated with the latest DNS entries. For example, they wanted the ACL to reflect the real IP addresses of www.cisco.com and www.amazon.com.
This script automatically schedules its next execution based on the minimum Time To Live (TTL) of the DNS response. It ensures we don’t attempt to update more often than necessary.
The script logs entries that are added to the ACL via syslog, but that could be Cisco Spark or any other notification mechanism.

show logging
*Jul 12 11:44:11.174: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "Looking up cisco.com"
*Jul 12 11:44:11.253: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "Looking up amazon.com"
*Jul 12 11:44:11.341: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 72.163.4.161 to ACL: status: Success"
*Jul 12 11:44:11.351: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.25.208 to ACL: status: Success"
*Jul 12 11:44:11.360: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.17.6 to ACL: status: Success"
*Jul 12 11:44:11.370: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.26.128 to ACL: status: Success"
*Jul 12 11:44:11.379: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.17.7 to ACL: status: Success"
*Jul 12 11:44:11.389: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.25.200 to ACL: status: Success"
*Jul 12 11:44:11.398: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.25.192 to ACL: status: Success"
*Jul 12 11:44:17.605: %SYS-5-USERLOG_NOTICE: Message from tty5(user id: ): "reschedule in : 557 seconds: status: Success"

Here is the resulting ACL. Notice how the remarks are used to indicate the time the ACL changed. The last two entries were added at a later date.

9300#show run | sec canary
ip access-list extended canary_ip_in
remark Added 72.163.4.161 @Wed Jul 12 11:44:11 2017
permit ip any host 72.163.4.161
remark Added 54.239.25.208 @Wed Jul 12 11:44:11 2017
permit ip any host 54.239.25.208
remark Added 54.239.17.6 @Wed Jul 12 11:44:11 2017
permit ip any host 54.239.17.6
remark Added 54.239.26.128 @Wed Jul 12 11:44:11 2017
permit ip any host 54.239.26.128
remark Added 54.239.17.7 @Wed Jul 12 11:44:11 2017
permit ip any host 54.239.17.7
remark Added 54.239.25.200 @Thu Jul 13 16:34:37 2017
permit ip any host 54.239.25.200
remark Added 54.239.25.192 @Thu Jul 13 16:34:37 2017
permit ip any host 54.239.25.192
deny ip any any

This script uses a different type of EEM trigger, a countdown timer. The script self-updates the trigger based on the TTL of the DNS response. In the case below, it will fire in the next 557 seconds.

9300#show run | sec even
event manager applet DNS_update
 event timer countdown time 557
 action 1.0 cli command "enable"
 action 1.1 cli command "guestshell run python bootflash:gs_script/src/dns-update/DNS_update.py cisco.com amazon.com"

This is an example of security using on-box Python. No external access to the device is required.

Example 3 – Configuration change

This example uses an EEM event to look for a syslog message and execute a Python script. In this case, it looks for a configuration event, and fires the script.

This script will do two things:

◈ A sanity check. This example is a simple test to see if an IP address is reachable, but it could be more sophisticated. If the sanity check fails, then the configuration is rolled back.
◈ Log the changes to the configuration in a spark room.

This screenshow shows the configuration diff posted to a spark room.

Cisco Study Material, Cisco Guides, Cisco Learning, Cisco Tutorial and Material

Here’s an example of the sanity check:  I have a very simple sanitiy check that is looking for connectivity to 1.1.1.1.   While this example is trivial, the sanity check could be much more sophisticated (checking for OSPF neighours, number of connected hosts, etc.).

I shut down the loopback address 1.1.1.1, which is being checked by the sanity function.  The sanity function fails, triggering configuration rollback, and the current (working) configuration is restored.

9300(config)#int loopback 2
9300(config-if)#shut
9300(config-if)#exit
9300(config)#end
9300#
Jul 14 12:01:04.859: %SYS-5-CONFIG_I: Configured from console by vty0 (10.61.215.206)
Jul 14 12:01:15.648: %MLANG-3-LOG: config_check.py: Sanity 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Jul 14 12:01:15.690: Rollback:Acquired Configuration lock.
Jul 14 12:01:15.690: %SYS-5-CONFIG_R: Config Replace is Done 
Jul 14 12:01:16.579: %MLANG-3-LOG: config_check.py: 
Total number of passes: 1
Rollback Done
Jul 14 12:01:18.127: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback2, changed state to up
Jul 14 12:01:18.127: %LINK-3-UPDOWN: Interface Loopback2, changed state to up

There are lots of other options for this script, including checking into a git repository and more enhanced sanity checks.

This Python script uses EEM in a different way. The first line of the script embeds an EEM registration. If there is a syslog message with pattern “CONFIG_I” in it, the script will be executed. (NOTE: This is actually a Python script, and the normal Python code is after this.)

::cisco::eem::event_register_syslog pattern "CONFIG_I" maxrun 60
# this is an example of an EEM policy trigger
# based of Joe Clarke version
#https://github.com/CiscoDevNet/python_code_samples_network/blob/master/eem_configdiff_to_spark/sl_config_diff_to_spark.py

I then tell EEM to look for the registration in the config_check.py script.

event manager directory user policy flash:
event manager policy config_check.py

This is an example of autonomy; if the configuration is changed, a sanity check is run to make sure the device is still functioning (and connected) to the network. If the sanity check fails, the configuration is rolled back.

Upgrade sanity check

It’s pretty simple to extend the use case above to check the status of the device before downloading and installing new software. Once the new code is installed, it will re-run the sanity check and either remove the old version of code or roll back depending on the status of the sanity check.
This is another example of autonomy using on-box Python.

How does this really work?


Python runs in a guestshell on the device.  The guestshell is CentOS or Montevista shell running as an application on the device. In order to enable application hosting you need to use the application hosting framework IOX.  To enable IOX is quite easy:

9300# conf t
9300(config)#iox

You then need to enable guestshell. This will take a few seconds.

9300# guestshell enable
Management Interface will be selected if configured
Please wait for completion

On switches running 16.8.1 and later, you need to configure a management interface, as shown below. This was added to allow access to guest shell from ports other than the mangement interface (GigabitEthernet0/0).

9300# conf t
app-hosting appid guestshell
 app-vnic management guest-interface 0
end

9300# guestshell enable
Management Interface will be selected if configured
Please wait for completion

Once it has started, you can either run a command or get an interactive shell session.

9300#guestshell run echo "hello world"
hello world

9300#guestshell
[guestshell@guestshell ~]$ 

The very first thing you will do is update the DNS settings. You can use vi, or just a simple echo statement.

echo -e "nameserver 8.8.8.8\ndomain cisco.com" > /etc/resolv.conf

Now to install some Python modules. This is pretty simple. Just use pip install. I am using the “-E” option as my switch needs a proxy to get to the internet.

[guestshell@guestshell ~]$ sudo -E  pip install netaddr
Collecting netaddr
  Downloading netaddr-0.7.19-py2.py3-none-any.whl (1.6MB)
    100% |################################| 1.6MB 257kB/s 
Installing collected packages: netaddr
Successfully installed netaddr-0.7.19

DevOps

The next question you’re asking is how do I keep the scripts on the device updated? It would be a pain to have to copy/install new scripts all the time.
The solution is pretty simple. Store the scripts in a git repository (so you have full version control), then use an EEM script to “git pull” regularly to keep them updated.

Here’s a simple git update script:

[guestshell@guestshell ~]$ cat /flash/gs_script/utils/update_git.sh 
#!/bin/bash
(cd /flash/gs_script; git pull)

All that’s required is another EEM cron job to keep the device updated with the latest git repository.

event manager applet GIT-sync
 event timer cron cron-entry "0,30 * * * *"
 action 1.0 cli command "enable"
 action 1.1 cli command "guestshell run bootflash/gs_script/src/util/update_git/sh"