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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه