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.

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.

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.

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.

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.

Continue reading

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).

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.

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

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.

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

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.

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.

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.

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.

The final step is to review and deploy.

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.

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.

Step 1 is just a preview.

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

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.

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.

Final step is to review and deploy.

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.

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.

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.

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

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.

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.

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

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.

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

Finally, review the summary and save.

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

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   

Continue reading

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.

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.

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.

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"

Continue reading

Five Proven Innovation Principles that Drive Business Success and Positive Social Impact

The innovation toolbox is broad and deep, with a growing array of methods, technologies, and tools for bringing a diverse group of innovators to the table. Though the fields of business and social change can seem very different, the things that make business innovation successful can also drive positive social impact. Think of design strategy, systems thinking, community engagement, and advanced technologies. By integrating these elements into regular operations, companies can reframe social responsibility as an integral part of their business model, rather than something that happens alongside.

As an innovation catalyst for Cisco and our customers, Cisco CHILL has identified several key principles that are essential for innovating across industries. We can use these same principles to take on some of the world’s thorniest social problems:

Collaboration

Multi-party innovation is key to solving big, global problems. As James Moore pointed out more than 25 years ago, business innovation requires ecosystems to attract capital, partners, and suppliers. Ecosystems built for social innovation create the same network effect. The more complex and global the challenges we tackle, the more we must grow a network across company, industry, and sector lines. The more intractable the problem, the more difficult it is it create a process to collaborate, but it is the only way to ensure a sustainable, inclusive future.

Technology

“We won’t experience 100 years of progress in the 21st century—it will be more like 20,000 years of progress (at today’s rate),” wrote Ray Kurzweil in 2001. Large, global data networks and the onslaught of new technologies are providing new tools to power social impact innovation. Imagine AI-enabled chatbots to coordinate aid distribution. Or an IoT-powered urban infrastructure that saves energy and lives. By applying new technologies to challenging problems, we can discover new ways to address complex challenges.

Stakeholder Engagement

In the Cisco CHILL innovation practice, we live by the principle of “massive inclusion”: everyone who might influence the success of a project is at the table. These are a project’s stakeholders. There are a lot of them and they don’t always agree! Leaders at the top of the organization must champion the company’s innovation agenda and involve stakeholders at every level from the very beginning of the design process (more on that below). This will help reduce friction internally and develop a culture of learning and trust. In the same way, a company’s agenda for community accountability and social responsibility must also be led from the highest levels so all employees and business functions can see how their work can affect real change.

Metrics

Founder of modern management Peter Drucker said, “What gets measured gets managed.” As with all business functions, determining the metrics for innovation success is important to achieving results. However, in both innovation and corporate social responsibility, the horizon can be long—it may be decades before we see impact. Innovators must carefully choose which indicators to track so we measure progress toward the end goal, not just activity for the sake of doing things.

Listening and Learning

Every step of the way, we must involve the people our initiatives will touch (often called “users” in the tech world). They too are stakeholders. It is crucial that the innovation process includes everyone and everything that a new technology or service will affect, positively or negatively.

At a CHILL Lab focused on healthcare, cancer patients and caregivers gave immediate feedback on prototypes and were the ultimate arbiters of success for all innovation concepts.

This expansive view must extend from people whose jobs or lives might be impacted, all the way to the global natural systems of air, water, climate, and environmental health. We can’t do this sitting behind a screen in an office: we must get out of the building to listen and learn, and leave ourselves open to wherever the conversation takes us. Co-innovation through prototypes is a great way to develop empathy and understand the needs of people affected by our solutions. At CHILL, we try out our ideas by building a quick prototype designed to test a specific assumption in a real and tangible way. Then we listen to feedback, adjust our approach, and try it again.

After spending the first ten years of my career in nonprofit organizations, I transitioned to enterprise innovation because I believe that to achieve a better world we need to embrace business transformation. The timing couldn’t be better. More and more, companies see the integrated connection between good business and being an accountable champion for a more just world. They see that having a profitable business doesn’t have to come at the cost of over-extracted resources, exploited populations, and pushing the long-term effects onto future generations. As Cisco CEO Chuck Robbins said recently during a Fortune Global Forum panel, “I think we’re going to move to a place where you’re not going to talk about CSR (corporate social responsibility) anymore; you’re just going to talk about what you do as a company.”

Today, more organizations like Cisco partner with innovative startups to take on broad social challenges. They champion the work of human service agencies in our communities and design products and regenerative processes to improve the quality of life for those with the least access. Together, we are taking steps toward a more sustainable, healthy, and equitable future for everyone.

Continue reading

Secure Access to Any Application With Duo Security

Over the past decade, several trends have broadly influenced the way businesses provide users access to applications and services. These trends include the wide adoption of:

◈ Mobile devices
◈ Cloud services (SaaS and IaaS)
◈ Accessing applications from anywhere

As businesses have transformed to a multi-cloud approach, users now have 24×7 access to business applications using any device, from any location. This approach has significantly increased productivity and business agility.

During this same time, business risk has increased as the volume of security incidents has skyrocketed. The result has been major impacts on brand reputation and increased costs in the management and remediation of security incidents. Meanwhile, attackers have developed more sophisticated methods of attack, although many older methods used today (like social engineering, phishing and stolen passwords) still prove effective.

Over the past five years, the Verizon Data Breach Investigations Report has shown credential theft as the most common factor of a breach. In the 2018 report, Verizon reported the number one action involved in a breach was the use of stolen credentials.

When we look back at the legacy solutions that were previously available to protect against credential theft, products such as RSA SecurID, Vasco and Safenet come to mind. These legacy solutions are known for introducing friction into the end user workflow. They’re seen as being overbearing for the end user, costly to manage, difficult to deploy and integrate with distributed multi-cloud environments. These are not attributes you want in a solution you’re trusting to secure access to critical applications and data.

When Duo Security started, our mission was – and still is – to democratize security by focusing on mitigating and reducing the risk of credential theft in a way that is easy and intuitive for the end user; easy for admins to deploy and manage – while easily protecting any application. We do this by verifying the trust of the user and the device at the time of access – the moment when a user attempts to access a business application. And we apply the same level of protection to all applications, whether they’re hosted in the cloud or on-premises.

It’s a three-prong, unified approach to secure access:

Verify User Trust

Duo verifies the trust of a user by sending a push notification to the user’s mobile device for one-tap approval and login, after the user completes primary authentication (username and password). For more sensitive applications, Duo can apply adaptive authentication controls and policies to establish a higher level of trust. This can include the user’s location, mobile biometrics such as TouchID and FaceID, as well as many other factors.

Verify Device Trust

Duo also verifies the trust of a user’s device by ensuring the device is up to date and adheres to an organization’s security policies before granting access. When a device is up to date, the risk of a device being compromised is significantly reduced. For higher risk applications, Duo allows for stronger controls, such as only allowing company-managed devices to gain access.

Secure Any Application

Duo extends the ability to verify the trust of the user and device to protect any application – in the cloud or on-premises – and supports the ability to apply these security controls to multi-cloud environments including SaaS, IaaS, VPN, Remote Access, Privileged Access, and other core business applications.

Duo’s ability to focus on the user experience while aligning with industry trends such as the broad adoption of mobile devices and cloud services puts Duo in a unique position to enable business agility by providing secure, frictionless access to any application, from anywhere, while significantly reducing the risk of a breach.

Continue reading