Introduction
As a NOC engineer for a manager service provider, access to the networks we manage/support is often a painful process. I have seen this accomplished in many ways, from the fairly standard Remote Access VPN and jumpbox, to grainy remote Webex/Teams access , TeamViewer sessions in a pinch, and my all time "favourite" the backseat driver, where you watch almost helplessly as someone else butchers the command line on your behalf (the pain).
All of this ends with Cisco’s amazing Remote Automation Development Kit or (RAD)Kit.
While this benefits my day to day work, in my DevNet Associate journey, I have been looking into more and more ways to manage my own lab. This has evolved very quickly over a short space of time to meet my needs.
I’ll try to be brief here about my personal lab. I run Cisco Modelling Labs (CML) via VMWare workstation on my desktop. The CML VM has the IP address of 192.168.200.100/24 (this full range, 192.168.200.0/24 will now be referred to as the “Management Network”).
From here I can spin up Cisco Devices (e.g. Catalyst 8k IOS-XE) through a Web-GUI. However accessing them often comes with similar problems that I see out in the wild. There is always a series of hoops to jump through...
Access the First
To initially connect, I can utilize the console view within the Web-GUI of the CML Lab, this is fine, but it just isn’t comfortable.
The reality is, I want my familiarity, I just want to use MobaXTerm, or PuTTY, something that I am used to / use regularly.
Access the Second
Thankfully, CML has a great breakout tool that allows me to use port forwarding, meaning I can spin up a CML device, and console on via telnet on port… 9000 (for example). Without the need to even configure an IP address on the device.
This is great because I can set this session up in MobaXterm, but I comes with a downside. I can’t use my new python scripts to ssh on to the devices.
Access the Third
By adding an external connector in CML, and connecting devices to it (via an unmanaged switch) I can now configure a management interface on the Cisco devices, letting them either be DHCP, or configure them with a static IP (in the Management Network).
By doing this I can now access my CML lab devices through MobaXterm on my machine… BUT I set up my python environment in WSL (Windows Subsystem for Linux), so scripting still doesn’t work seamlessly, and even though I could jimmyrig it, its not a very close representation of the networks I deal with daily.
What I can do however is set up a jumpbox. In to the rescue comes a fresh VM install of Ubuntu Server, and purely for fun, Kali Linux, with VSCode.
Access the Fourth
Even at this point this is great, but I also like working on my laptop, To access my lab, I need to RDP on to my desktop to spin up the Kali VM to run scripts in my CML environment. And sadly, I’m now dealing with tiny text that I keep having to adjust settings for.
We are there… Scripts CAN be run from inside the lab!!! … But can it be better?
The Ultimate Access
Enter Cisco (RAD)Kit. The concept is simple, a single lightweight service running inside my lab environment. That can be connected to, remotely from anywhere.
To achieve this, I use my existing (VM) Ubuntu Server for this, as it is already on the management network. All my Cisco devices can communicate with this Server, and the server has internet access. This is where I will install my (RAD)Kit service.
On my laptop I install the (RAD)Kit client, (there are windows, mac, and linux installers).
Between the client and service? Lives the (RAD)Kit AWS cloud.
The (RAD)Kit service
In short, the (RAD)Kit Service will act as my proxy, but the way this works is genius.
Setting this up is fairly easy, but I would advise spending a good bit of time here after you have set up your first couple devices.
When you install the service, you will receive a “Service ID” (e.g. 1234-5678-9ABC) number. This is your services unique identifier.
In the wild, a managed customer would need to provide you (the engineer) this number.
Next, set up any “Remote users”. The easiest was is by using an email address. A really cool feature here is "Time-slice", this allows the customer to provide either unlimited never ending access, OR a scheduled time slot to the environment, before access is revoked, which is great for those strict security environments.
Finally, set up your device(s). This needs very little information:
A name (that is only locally relevant to (RAD)Kit
Management IP address
Connection preference (Terminal, Netconf, etc)
Any relevant username, password or ports
You can configure more here, such as labels and OS but the main parts are above.
That is the minimum set up for the server.
The (RAD)Kit Client
On the client you need to login with the email address (that was set up as the remote user on the service) and enter the Service ID. With this you can now access the service inventory. In the image below I have created a filter for all my devices where the name includes "bgp-lab". I then used this to view the routing table bgp routes for every device in this lab, all from one place.
This is just a small taste of the things you can achieve, you can:
Create a terminal session with any device listed
Issue a command to a single device
Issue multiple commands to a single device
Issue a command on multiple devices
Issue multiple commands to multiple devices
Compare different outputs
Upload files on to devices
Download files from devices
Send outputs as a file directly to a Cisco TAC case
All of this I haven’t even got to the scripting yet!?
I think the key take away here is the advantage that this can have if deployed in your customer networks for you the engineer who needs to manage it. But after testing this in my lab, it holds great benefit even at small scale.
It is RADical.