The Stub Lab is a fully functional Cisco Lab provided as a free service to the community by Free CCNA Workbook. All you need to do to gain access to a top notch Cisco Lab that has ISR’s, Multi-layer switches, Cisco ASA’s and more is sign up at the Stub Lab Schedule Portal and reserve lab time. When your lab time comes you can log into the lab devices remotely using Telnet and have access to real Cisco hardware to perform educational labs on for the purposes of obtaining Cisco certifications.

For years though Free CCNA Workbook has received countless emails requesting information on how the Stub Lab operates. How does Free CCNA Workbook provide free lab time? How does the Schedule Portal work? How do you detect abusive commands and kick users from the lab? This blog entry is going to be very helpful for anyone looking to build their own publicly accessible Cisco Lab.

This blog entry will address all the questions previously asked regarding how all this cool stuff works… So lets get started shall we?

Stub Lab Schedule Portal

First, lets start off with the Schedule Portal. The Stub Lab Schedule Portal is a custom designed PHP application that runs on top of RedHat 6 and integrates with MySQL and NET-SNMP. From the user perspective the schedule portal allows for users to register and set their timezone where they can then reserve lab time on the Stub Lab. When a user schedules a lab session the schedule portal then places that information into the back-end database for the schedule portal but also modifies the Free RADIUS database which also resides in MySQL.

Free RADIUS Controls the user authentication for the Stub Lab console server which is an OpenGear IM4216. Free RADIUS stores authentication information regarding the username, SHA1 password hash, date and time in which the lab session is permitted.

The back-end of the Schedule Portal, the Admin portal allows for more administrative control over the Lab operations. The Admin portal allows for staff members to control power for the device via SNMP, modify and/or delete schedule lab sessions, disable and/or delete user accounts and post announcements visible to everyone who logs into the portal.

Unfortunately Stub Lab Schedule Portal is a proprietary software development and is not available for free download.

Opengear Console Server Overview

The Opengear IM4216 is the bread and butter of the Stub Lab. This console server manufactured by Opengear makes everything possible. One of the biggest limitations of the lab is to ensure that individuals that use the lab cannot perform specific commands that could be harmful to the lab such as format flash: or delete flash:/image.bin. Commands like this would make devices inoperable for other users and would require manual intervention to fix the problems created by users with malicious intent.

While the Stub Lab is free for anyone to use, there are individuals out there with malicious intent that want to ruin the lab experience for everyone else.

The Opengear Console server gives the ability to detect specific serial string patterns received by the Lab device and when received they will execute a specific function such as disconnect the user and run a script which will break the abusive command using the CTRL+C function then powering off the device.

Because the Opengear console server is based on linux, the console server can perform cron jobs which ultimately can execute scripts. From the Stub Lab’s perspective, a Cron job is executed once every 3 hours to disconnect all users and power off all devices to conserve electricity. Another cron job is executed 10 minutes before the end of each session warning users that are currently logged into the devices that the lab session will end in 10 minutes.

Another unique feature of the Opengear console server platform is the ability to control APC smart PDU’s which control the power to each lab device. This gives users of the lab the ability to power on and off devices remotely to perform password-recovery and any other lab that requires a power cycle. Once you log into the lab device, you can access the power menu by typing ~p. This will bring up a menu that looks like this;

Power Commands:

 O - Power ON
 P - Power OFF
 R - Power cycle off then on again
 s - Show current power status
 . - Exit power menu
 ? - Show this message

[R1] Power > 

From this menu you can power control power to each lab device individually. To exit the power menu you would type period (.) and press enter.

Stub Lab Console Server Deep Dive

So now that you have a basic understanding of how the Stub Lab works, lets take a deep dive into the operations of the Opengear console server. In this section we will discuss how you can setup your very own Opengear Console Server to provide free public access to users around the world.

First we’ll start off with Serial Port and RPC Configuration then Bash scripting and followed by Auto-Response.

Serial Port and Remote Power Control (RPC) Configuration

After you have configured the basics of the Opengear Console Server such as the IP Address, authentication, time settings (NTP) and so on you will the need to configure the Serial Ports. The Serial Port configuration gives you the ability to specify a Name on a per port basis and the operating parameters of each port such as the baud rate, data bits, parity, stop bits and flow control. Other parameters that can be configured in this section is the serial port operational mode. There are 5 modes that the port can operate in. The first “Console Server Mode” which is what you’ll use to access Lab devices allows for users to remotely access the console ports of a connected device remotely via TCP/IP using Telnet and/or SSH.

Device Mode, can be used to specify exactly what type of device is connected to the console server to allow for more advanced controls of the connected device such as a Battery Backup (USP), or Smart PDU, known as an RPC (Remote Power Controller) or an environmental sensor used to detect and report environmental statistics such as humidity and temperature.

SDT (Secure Desktop Tunneling) Mode if a feature developed by Opengear which allows for Secure desktop tunneling of VNC or RDP through the use of an SSH Tunnel over the internet to authenticated endpoints.

Terminal Server Mode gives the console server the ability to interconnect to a terminal server using the configured terminal type.

And lastly, Serial Bridged mode is used to bridge serial over TCP/IP and is commonly used in hospital environments where specialized label printers operate using Serial ports and not parallel or native TCP/IP.

When building your own Stub Lab you will be using the Console Server mode. If you have an APC 7901 or 7902 you can then use the Console Server to control the power to this device by configuring the RPC via SNMP in Network Host(s) first. Once you have defined the RPC Network Host you must then define the RPC Connection settings. This is where you’ll name the RPC and provide the SNMP community string and label the outlets. Shown below is a screenshot of the Network Host configuration page.

Once you have the RPC defined and configured you must then define each “Managed Device”. This is where you will pair up the Serial Port with the RPC Outlet. You must doe this for every device in the lab. Once completed you then have the ability to enable the “Power Menu” function on the Serial Port configuration page.

After all the configuration has been completed properly you’ll be able to control the power of each device independently through Telnet and/or SSH.

Auto-Response Configuration

One of the obstacles in the way of providing free access to a Cisco lab is the ability to prevent people from executing harmful commands such as format flash. Fortunately, Opengear gives you the ability to prevent users from executing commands using the “Auto-Response” function. The Auto-Response function is very powerful as in it has the ability to recognize serial pattern strings and execute a specific action once the string has been detected.

The Stub Lab makes use of this function by preventing users from executing abusive commands. When a user executes a command that is harmful to the lab environment, the console server will automatically disconnect the user immediately before they can continue to execute the command. After the user has been disconnected it will then execute a bash script which will be discussed in the next section which sends the CTRL+C command to the port which the user executed the abusive command on and finally powering off the device.

When it comes to the Stub Lab, the Auto-Repsonse is used to detect Rx (Receive data) serial strings and execute a function upon being triggered. Because all abusive commands when executed will prompt you for additional confirmation, we can use this to our advantage and trigger an action when detected by the console server. Below is a list of (Rx) strings that are used.

Abusive Command	Rx String
Debug All	This may severely impact network performance.
Format Operation	Format operation may
Erase Flash:	Erasing the flash filesy
IOS Upgrade Attempt	Source filename \[.*\]:
Delete BIN File	Delete filename \[.*\.bin\]\?
Save File to Flash	Destination filename \[(?!(running|startup)-config\]).*\?
ASA Erase Flash	Erase operation may take a while. Continue\?
No SVC Password Recovery	Executing this command will disable password rec

When the Auto-Response is triggered based on Rx string detection it will execute a trigger function. On the stub lab, trigger executes a customized bash script that is provided in the next section. However the configuration of the trigger must pass an Argument to the bash script so the bash script knows which port the abusive command was executed on and can take action on that specific port only.

Provided below is a screenshot;

The Argument $AR_DEV_REF is a very special argument which passes the port configuration label into the bash script. You can of course pass your own defined arguments but this one is used to define which port the auto-response was triggered on.

Bash Scripting

Because the Opengear console servers are built on top of Linux, you have the ability to execute Bash scripts which make the console extremely powerful. The Stub Lab makes use bash scripting to help with the management of the lab. Provided below is a summary of each script and the script its self to help you build your own stub lab.

The following script “abusive_cmd.sh” is used by the Auto-Response to send 3x CTRL+C’s to break any abusive command executed. This script also powers off the device.

#!/bin/sh

#The $AR_DEV_REF variable feeds the 
#port info from the config location 
#config.ports.port# into $1

#Strip down to just the port number 
get_port=$(echo $1 | sed 's/[^0-9]*//g')

#Pad the 1-9 ports with a 0 
number=`printf "%02d" $get_port`

#Execute three CTRL+C to Cancel Command and display message.
printf "\003\003" > /dev/port$number

#Power Off Device After Command Canceled
pmpower -r 172.16.28.8 -c private -o $get_port off

Up next is the “10min_warning.sh” Script which executes a set of echo commands to all ports in the Bash array warning the user the lab session will end in 10 minutes;

#!/bin/bash

### WHICH PORTS TO ECHO 10 MINUTE WARNING ON ###
PORTS=( 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 );

### EXECUTE LOOP TO ECHO WARNING ON EACH PORT IN $PORTS ARRAY ###
for PORT in "${PORTS[@]}"
do
echo -en "

  ###################################################
  ####  YOUR LAB SESSION WILL END IN 10 MINUTES  ####
  ####    PLEASE ERASE ALL LAB DEVICE CONFIGS    ####
  ###################################################

" > /dev/port$PORT
done

The next script used is the “end_session.sh” script which will disconnect all current telnet and ssh sessions on the lab devices defined in the bash array.

#!/bin/bash

### DEFINE WHICH PORTS TO EXECUTE SESSION TERMINATION ON ###
PORTS=( 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 17 )

### EXECUTE SESSION TERMINATION LOOP ON EACH PORT DEFIEND IN $PORTS ARRAY ###
for PORT in "${PORTS[@]}"
do
### Find process ID(s) of pmshell for port, if any ###
procs=`ps aux | grep pmshell | grep port$PORT | awk '{print $1}'`

### KILL PIDS ###
for pid in $procs
do
kill $pid
done
done

### EXECUTE KILL POWER SCRIPT ###
/bin/sh /etc/config/scripts/kill_power.sh

The “kill_power.sh” script which is used by the “end_session.sh” script makes use of the pmpower command on the Opengear to send an SNMP SET query to the RPC to turn off the outlet(s).

#!/bin/sh

pmpower -r 172.16.28.8 -c private -o 1 off
pmpower -r 172.16.28.8 -c private -o 2 off
pmpower -r 172.16.28.8 -c private -o 3 off
pmpower -r 172.16.28.8 -c private -o 4 off
pmpower -r 172.16.28.8 -c private -o 5 off
pmpower -r 172.16.28.8 -c private -o 6 off
pmpower -r 172.16.28.8 -c private -o 7 off
pmpower -r 172.16.28.8 -c private -o 8 off
pmpower -r 172.16.28.8 -c private -o 9 off
pmpower -r 172.16.28.8 -c private -o 10 off
pmpower -r 172.16.28.8 -c private -o 11 off
pmpower -r 172.16.28.8 -c private -o 12 off
pmpower -r 172.16.28.8 -c private -o 13 off
pmpower -r 172.16.28.8 -c private -o 14 off
pmpower -r 172.16.28.8 -c private -o 15 off
pmpower -r 172.16.28.8 -c private -o 16 off

The next script which is executed automatically by the opengear console server when a user successfully authenticates to a lab device is the “/etc/config/pmshell-start.sh” script. This script is designed to prevent ROOT access to the console lines and it will also display a welcome msg and login banner to authenticated users;

#!/bin/sh
#
################################################################
#                                                              #
#  OPENGEAR CONSOLE SERVER (ver 3.10.0) PMSHELL START SCRIPT   #
#      Published by: Matthew George, Free CCNA Workbook        #
#                                                              #
################################################################


### DECLARE VARIABLES ###
PORT="$1"
USER="$2"
LABEL=$(config -g config.ports.port$PORT.label | cut -f2- -d' ')


### PROHIBIT ROOT USER AUTHENTICATION ON CONSOLE PORTS ###
if [ "$USER" == "root" ]; then
echo "Permission denied for Super User"
exit 1
fi


### DISPLAY SWITCH BANNER PASSWORD WARNING AFTER AUTHENTICATION ###
if [[ $PORT = [6-9] ]]; then
echo ""
echo ""
echo "####################################################################"
echo "#                                                                  #"
echo "# WARNING: LEAVING PASSWORDS ON LAB SWITCHES WILL RESULT IN A BAN  #"
echo "#                                                                  #"
echo "####################################################################"
fi


### DISPLAY WELCOME AFTER AUTHENTICATION ###
if [ -z "$LABEL" ]; then
echo ""
echo ""
echo "Welcome $USER, you are connected to Port $PORT"
echo ""
echo ""
else
echo ""
echo ""
echo "Welcome $USER, you are connected to Port $PORT ($LABEL)"
echo ""
echo ""
fi

And the last script which is not really script is the CRONTAB configuration. The Stub Lab is provides free lab access using 3 hour sessions. Every 3 hours the CRON process will execute a script. First it will execute the “/etc/config/scripts/10min_warning.sh” script informing users that they have 10 minutes left before their lab session ends. Then once the lab session ends, it will execute the “/etc/config/scripts/end_session.sh” script which will disconnect the user from all lab devices and power off the entire lab to save energy.

### SESSION 1 ###
50 2 * * * /etc/config/scripts/10min_warning.sh
0 3 * * * /etc/config/scripts/end_session.sh

### SESSION 2 ###
50 5 * * * /etc/config/scripts/10min_warning.sh
0 6 * * * /etc/config/scripts/end_session.sh

### SESSION 3 ###
50 8 * * * /etc/config/scripts/10min_warning.sh
0 9 * * * /etc/config/scripts/end_session.sh

### SESSION 4 ###
50 11 * * * /etc/config/scripts/10min_warning.sh
0 12 * * * /etc/config/scripts/end_session.sh

### SESSION 5 ###
50 14 * * * /etc/config/scripts/10min_warning.sh
0 15 * * * /etc/config/scripts/end_session.sh

### SESSION 6 ###
50 17 * * * /etc/config/scripts/10min_warning.sh
0 18 * * * /etc/config/scripts/end_session.sh

### SESSION 7 ###
50 20 * * * /etc/config/scripts/10min_warning.sh
0 21 * * * /etc/config/scripts/end_session.sh

### SESSION 8 ###
50 23 * * * /etc/config/scripts/10min_warning.sh
0 0 * * * /etc/config/scripts/end_session.sh

With the following scripts provided you should have enough to get your own Opengear Console Server configured to allow for free remote access without having to worry about people screwing up your hardware.

While some of the scripts are not perfect, they are indeed functional and work as intended. I have however made a feature request to Opengear requesting that Opengear build a function that would allow for the console server to receive a RADIUS A/V Pair such as “Session-End” = “Date/Time” which would automatically execute a script in /etc/config/scripts/ to provide the functionality of allowing for more diverse lab session management without using the CRON function.

Our Appreciation!

Last but not least, Free CCNA Workbook and on the behalf of all the registered users of the Stub Lab would like to thank Opengear for sponsoring the Stub Lab by providing us with a free Opengear IM4216. Without this gracious sponsor, free access to the Stub Lab would not be possible.

If you are interested in learning more about Opengear products such as the Console Server or Infrastructure Manager, please check out Opengear Products page. If you are interested in inquiring about products for educational classroom purposes you can reach out to the Opengear VP of Sales, Todd Rychecky at 303-346-6853. Please let him know that Matthew George from Free CCNA Workbook referred you.