Hands-On Lab: Configuring Guestshell for On-Box Python Scripting

This hands-on lab enables the Guestshell container on a router, installs a Python package inside it, and runs a simple script that reads live interface data from the IOS CLI, demonstrating on-box programmability distinct from the external NETCONF/RESTCONF automation covered in earlier labs.

Guestshell ContainerOn-Box Python Scriptingcli Python Module

~3 min read · Updated Sep 26, 2026

Lab Objective

Enable the Guestshell Linux container on a router, verify Python is available inside it, install a package using the container's own package manager, and run a Python script using the cli module to query live interface information directly from within the same device.

Lab Purpose

NETCONF and RESTCONF, covered in earlier labs, enable an external management station to automate a device remotely. Guestshell instead runs directly on the router itself, providing an isolated Linux container where custom scripts can execute locally — useful for on-box automation that needs to react immediately to local conditions without depending on network connectivity to an external controller.

Lab Topology

R1 ---- Gi0/0: 192.168.253.1/24, Gi0/1: 10.5.5.1/30

Goal: run a script INSIDE R1 itself that
reads and reports on these interfaces,
without any external system involved

Task 1: Enable Guestshell

Enable the Guestshell container on the router.

Task 2: Access the Guestshell and Verify Python

Enter the Guestshell and confirm Python 3 is available.

Task 3: Write a Python Script Using the cli Module

Write a script that uses the IOS-provided cli Python module to execute a show command and parse its output.

Task 4: Run the Script and Verify Output

Execute the script and confirm it correctly reports interface information pulled from the live device state.

Task 5: Verify This Runs Entirely On-Box

Confirm no external network connectivity was required for the script to function.

Solution and Verification

R1(config)# iox
R1(config)# exit
R1# guestshell enable

-- iox enables the underlying container
-- infrastructure; guestshell enable
-- actually activates the Guestshell
-- container itself

R1# guestshell

[guestshell@guestshell ~]$ python3 --version
Python 3.6.8
-- Confirms a full Python interpreter is
-- available inside the container, entirely
-- separate from the router's own IOS
-- process space

[guestshell@guestshell ~]$ cat > check_interfaces.py << 'EOF'
from cli import cli

output = cli("show ip interface brief")
print("Interface status from R1 itself:")
print(output)
EOF

-- The cli module is provided specifically
-- by the IOS Guestshell environment,
-- allowing Python code to execute IOS
-- commands and capture their output
-- directly, without SSH or any external
-- connection to itself

[guestshell@guestshell ~]$ python3 check_interfaces.py

Interface status from R1 itself:
Interface              IP-Address      OK? Method Status    Protocol
GigabitEthernet0/0     192.168.253.1   YES manual up         up
GigabitEthernet0/1     10.5.5.1        YES manual up         up
-- The script successfully retrieved live
-- interface state by calling directly into
-- IOS's own CLI engine from within the
-- container

-- Disconnecting the router's network
-- cables entirely and re-running the
-- script from within an existing Guestshell
-- session:

[guestshell@guestshell ~]$ python3 check_interfaces.py

Interface status from R1 itself:
Interface              IP-Address      OK? Method Status         Protocol
GigabitEthernet0/0     192.168.253.1   YES manual administratively down  down
GigabitEthernet0/1     10.5.5.1        YES manual administratively down  down
-- The script still runs and reports
-- correctly (now showing the interfaces
-- down, since they are physically
-- disconnected) -- confirming the entire
-- operation happens on-box and never
-- depended on any external network path

Key Takeaway

Guestshell's cli Python module bridges directly into the router's own command execution engine from inside an isolated Linux container running on the same physical device — this is fundamentally different from NETCONF or RESTCONF automation covered in earlier labs, which require a working management network path to an external station, making Guestshell the right choice specifically for local, self-contained automation that must function even during broader network connectivity problems.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue