In|previous|blogs in the NetDevOps Series we explored the most important building blocks for programmability and seeing how to apply DevOps automation principles to Network configuration with CI/CD workflows. It is now time to see how you can use APIs to build more business-relevant solutions that help managing your network. And what better way to learn about it than getting your hands dirty by going through a new demo?

Our new demo is called VPN HEMP (Head End Management Platform).

Business challenge

Managing connections from extranet environments usually involves a great amount of workload, especially around VPN configurations at central hub points. Our choice to implement this type of environment is to pre-configure VPN endpoints at remote locations, and then complete the required configuration from the central head-end point as connectivity is required. This configuration will explicitly define the authorized end-points and type of traffic that can traverse the connection.

Once connectivity to a certain remote location is no longer required, you can remove the associated relevant configuration from the central head-end, disabling that specific VPN and hence discontinuing connectivity.

As you might guess, scaling this type of environment would really benefit from automation. Specially because most of the configuration will be very similar for each different location, with just some parameters being different. The more remote locations from different 3rd-party entities (i.e., partners, vendors), the longer the process to configure VPNs, ACLs with type of traffic and authorized end-points, etc. Implementing these long VPN configurations via CLI is of course an error-prone process due to the required human interaction, so automation will also take care of this challenge and provide the required consistency and reliability all along the network.

This demonstration will focus onhow to automate the lifecycle of extranet VPN connections- from setting them up, to checking everything is correct, providing related metrics, and tearing them down once they are no longer required. It also includes a simple graphical user interface (GUI) that uses APIs to demonstrate how easy it could be to manage those VPN connections for users without the required permissions to connect via CLI to network devices, or even the knowledge to configure them.

Topology

Our demo setup will include 1 central hub location with a headend router that will concentrate VPN connections from 4 remote partner locations.

We will also have some switches acting as hosts exchanging traffic, and another router simulating internet, providing connectivity between the headend and partner locations.

All devices will be simulated using VIRL as per the diagram below.

Building blocks

These are the components we will use to build the demo:

• Cisco Network Services Orchestrator: formerly Tail-f, it provides end-to-end automation to design and deliver services much faster
• VIRL: network modelling and simulation environment
• Ansible: simple automation

The provided GUI portal to manage HEMP uses the following technologies:

• Python, Flask, and JavaScript for the primary web interface
• Telegraf, InfluxDB, and Grafana for visualizing operational metrics collected via SNMP

For ease of deployment and portability, all of the above components are run as a docker compose stack which can be executed directly on your sandbox devbox.

Setup process

As with the previous demo, this one also requires a DevNet Sandbox: an environment where you have all the required platforms and elements that you will need for those demos. You may find here the required sandbox for this demo, and book it for up to one week exclusively for you!

(Note: when doing the reservation please choose 'None' for simulation, as we will be launching the required topologies as part of the setup process. Spinning up the whole system will take roughly 15 minutes -So go grab a coffee, or fix yourself a sandwich, or call your mom, or ...)

Once the setup is ready you will receive an email with all required information to VPN into your sandbox. If you do not have a VPN client you may download AnyConnect here. Connectto yourVPN, and you are now ready to start setting up your demo!

Environment setup

Once you are connected via VPN to your reserved sandbox, please open a terminal window (i.e., putty on Windows or terminal on OSX) andssh to your devboxwith the following credentials:developer/C1sco12345

$ssh [email protected]

Once in, and before starting the setup phase, please edit the/opt/nso/etc/ncs/ncs.conffile. Delete the line<dir>/opt/nso/packages/neds/</dir>, and save the file:

Now you are ready to start the setup, so clone the repository that includes all required files to build the demo environment into yourdevbox.

[developer@devbox ~]$git clone https://github.com/DevNetSandbox/sbx_multi_ios.git

With that, your sandboxdevboxincludes now all required info to start building the environment.

Go into thehempdirectory and run thesetup.shscript to set the complete environment up.

[developer@devbox ~]$cd sbx_multi_ios/hemp[developer@devbox hemp]$./setup.sh

setup.shwill perform the following steps in the sandboxdevbox:

1. Install the required software tools and dependencies in a python virtual environment
2. Launch VIRL simulations for the whole network, including 4 remote partner locations and 1 central hub headend
3. Setup and start NSO
4. Add all VIRL network devices into NSO
5. Synchronize all existing configurations from network devices to NSO
6. Display the status for VIRL network devices
7. Start a HEMP management GUI, implemented with containers
8. Use Ansible to pre-configure the headend and activate 2 out of the 4 remote locations VPNs

The process will take approximately 15 minutes. Soooo, did you call your Mom last time, or just make yourself a sandwich?

Congrats! Your environment is now completely setup and ready to run the demonstration!

See you next week to cover how you can run the demo. Stay tuned!

Any questions or comments please let me know in the comments section below, Twitter or LinkedIn.

We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel