7-4 Python on Box / Guest Shell — 機器の上の実行環境

1. 前節の振り返りと本節の内容

前節 7-3 gNMI と Model-Driven Telemetry は、csr1000v 17.03.08a で NETCONF の動的購読と CLI で設定した購読（dial-out）を、cat9000v-uadp 17.15.03 で gNMI の 4 つの RPC を撮りました。

7-3 の末尾（§13）は、7-3 のプログラムがどこで動いたかを書いて、本節へ渡しています。本節は、この予告を同じ順で次の場所で受けます。

本節は出典に基づく部分と、本ラボの実測に基づく部分を分けて書きます。§2 は出典の説明で、§2.6 の表の右の列だけに本ラボの表示の語を並べます。§3〜§11 は、各節の中で資料の段落（引用を含む）と本ラボの段落を分けます。

§12 は撮っていないことと撮れなかったことです。§13 は落とし穴・補足で、資料と実機が割れた所は両方を並べ、どちらが正しいとも、何が原因とも書きません。本ラボで見えた表示（ip のコマンド・python3 -c の引用符・syslog の日付）も §13 に置きます。

以下に貼る実機出力は改変していません。長い出力から一部を抜き出した箇所には …（省略） を置きました。文の後ろの（数えた）は、保存した出力や原典の行を数えた値であることを示します。地の文のインラインコードは、機器の出力の空白の連続を 1 つに詰めて書きます。

プロンプトとコマンドを 1 行にまとめた表記（CSR1# …・privilege 1 の利用者の CSR1> …・COL の shell の COL $ …・Guest Shell の bash の [guestshell@guestshell ~]$ …）は本節の組み立てで、取得の記録ではコマンドが見出しの行として別に残っています。設定の投入は、configure terminal のエコーからそのまま載せます。

コードブロックの直前の文には、機器と版と RAM（例: csr1000v 17.03.08a・RAM 4096 MB）か、〔ツール側〕を書きます。RAM の値は CML の設定値（〔ツール側〕CML の API の読み返し）で、機器の側の値は show version の物理メモリの行です（§3.1）。

パスワードは撮影ごとの使い捨てで、本文には載せていません。保存した running-config の username の 2 行（netops と viewer）は、取得スクリプトが伏せました（伏せた行の印の username / enable secret は伏せる規則の名前で、day0 に enable secret の行は入れていません）。利用者名は伏せておらず、syslog の行と設定変更の記録に netops・viewer のまま出ています。

時刻は機器の時計（UTC）で、show clock と syslog の行頭の値をそのまま書きます。show clock の日付は Mon Oct 19 2026 です（Guest Shell の LOG の行の中の日付は、月の値が行頭と違います。§13.15）。COL の受け手が記録した時刻は COL の時計の値で、機器の時計とのずれは測っていません。

2. Guest Shell と IOx（用語と要件）

2.1 Guest Shell

Guest Shell は、Cisco IOS XE の機器の上で Linux のアプリケーションを動かすための、仮想化された Linux の環境です。17.3 の Guest Shell 章は次のように定義しています。

The Guest Shell is a virtualized Linux-based environment, designed to run custom Linux applications, including Python for automated control and management of Cisco devices. Using the Guest Shell, you can also install, update, and operate third-party Linux applications.

（Guest Shell 章「Guest Shell Overview」）

同じ節は、Guest Shell がシステムイメージに同梱され、IOS の guestshell enable で導入できると書いています。

The guest shell is bundled with the system image and can be installed using the guestshell enable Cisco IOS command.

（Guest Shell 章「Guest Shell Overview」）

同じ節は、Guest Shell の環境を、ネットワークの機能のためではなく、道具・Linux のユーティリティ・管理のためのものと位置づけています。

The Guest Shell environment is intended for tools, Linux utilities, and manageability rather than networking.

（Guest Shell 章「Guest Shell Overview」）

2.2 IOx と CAF

Guest Shell のコンテナは IOx が管理します。Guest Shell 章は、IOx を IOS XE の機器の Application Hosting の基盤と書いています。

Guest Shell container is managed using IOx. IOx is Cisco’s Application Hosting Infrastructure for Cisco IOS XE devices.

（Guest Shell 章「Guest Shell Overview」）

Application Hosting 章は、IOx (IOs + linuX) を、Cisco の機器でさまざまな種類のアプリケーションをホストするフレームワークとし、Guest Shell をその上のアプリケーションの 1 つとしています。

Cisco IOx (IOs + linuX) is an end-to-end application framework that provides application-hosting capabilities for different application types on Cisco network platforms. The Cisco Guest Shell, a special container deployment, is one such application, that is useful in system deployment.

（Application Hosting 章「Cisco IOx Overview」）

同じ章の Application Hosting Overview は、application hosting が提供するサービスを並べ、その基盤を CAF (Cisco Application Framework) と呼んでいます。

Application hosting provides the following services: Launches designated applications in containers. Checks available resources (memory, CPU, and storage), and allocates and manages them. Provides support for console logging. Provides access to services through REST APIs. Provides a CLI endpoint. Provides an application-hosting infrastructure referred to as Cisco Application Framework (CAF). Helps setup platform-specific networking (packet-path) through management interfaces. Data ports are supported on platforms that have AppGigabitEthernet port functionality.

（Application Hosting 章「Application Hosting Overview」）

2.3 ソフトウェアの要件

17.3 の Guest Shell 章の Guest Shell Software Requirements は、Intel x86 の機種の Guest Shell を、CentOS 8.0 の最小の rootfs を持つ LXC（Linux Container）としています。

The Guest Shell container allows users to run their scripts and apps on the system. The Guest Shell container on Intel x86 platforms will be a Linux container (LXC) with a CentOS 8.0 minimal rootfs.

（Guest Shell 章「Guest Shell Software Requirements」）

同じ節の Table 1 は、Guest Shell の OS と Python の版を IOS XE の版ごとに書いています。CentOS 8 は 17.3.1 以降で、注は CentOS が対応する Python を 3.6 だけとしています。

Guest Shell Environment CentOS 7 supported in Cisco IOS XE Amsterdam 17.2.1 and previous releases. CentOS 8 supported in Cisco IOS XE Amsterdam 17.3.1 and later releases. Note CentOS supports only Python 3.6.

（Guest Shell 章「Table 1. Guest Shell Software Requirements」）

Table 1 の Python 3.6 の行は、17.3.1 以降の既定を Python V3 としています。

Python 3.6 Supported in Cisco IOS XE Amsterdam 17.1.1 and later releases. In Cisco IOS XE Amsterdam 17.1.1 and Cisco IOS XE Amsterdam 17.2.1, Python V2 is the default. However, in Cisco IOS XE Amsterdam 17.3.1 and later releases, Python V3 is the default.

（Guest Shell 章「Table 1. Guest Shell Software Requirements」）

Table 1 は、あらかじめ入っている Python のライブラリとして、Embedded Event Manager と IOS XE の CLI を挙げています。

Pre-installed Custom Python Libraries Cisco Embedded Event Manager Cisco IOS XE CLIs

（Guest Shell 章「Table 1. Guest Shell Software Requirements」）

Table 1 の Python 2.7 の行と、CLI Python Module 章の Python 2.7 の記述は、§13.5 で実機と並べます。

2.4 ハードウェアの要件と資源の既定値

Guest Shell 章の Hardware Requirements for the Guest Shell の Table 2 は、CSR1000v（Cisco Cloud Services Router 1000V Series）の最低メモリを 4 GB としています。

Table 2. Guest Shell Resource Requirements Platforms Minimum Memory Cisco 1000 Series Integrated Services Routers 4 GB Cisco Cloud Services Router 1000V Series 4 GB

（Guest Shell 章「Hardware Requirements for the Guest Shell」）

同じ章の Table 3 は、Guest Shell に割り当てる資源の既定値と最小・最大を書いています。Memory の行は、既定を 256 MB とし、CSR1000v を 512 MB としています（列の順は Default・Minimum/Maximum）。

Memory 256 MB 512 MB (Cisco Cloud Services Router 1000V Series) 256/256 MB 512/512 MB (Cisco Cloud Services Router 1000V Series)

（Guest Shell 章「Table 3. Resources Available to Guest Shell and Guest Shell Lite」）

本ラボの予約の値は §5.4、Table 2・Table 3 と実機の並びは §13.1・§13.2 にあります。

2.5 Guest Shell を扱うコマンドと cli モジュール

Guest Shell 章は、IOS のコマンドで Guest Shell を有効にし、中で Linux のプログラムを動かし、止め、消すと書いています。guestshell enable は Guest Shell を導入し、無効にした Guest Shell を再び有効にする時にも使います。

The guestshell enable command installs Guest Shell. This command is also used to reactivate Guest Shell, if it is disabled. When Guest Shell is enabled and the system is reloaded, Guest Shell remains enabled.

（Guest Shell 章「Enabling and Running the Guest Shell」）

guestshell run bash は Guest Shell の bash のプロンプトを開きます。

The guestshell run bash command opens the Guest Shell bash prompt. Guest Shell must already be enabled for this command to work.

（Guest Shell 章「Enabling and Running the Guest Shell」）

guestshell disable は Guest Shell を止めて無効にします。

The guestshell disable command shuts down and disables Guest Shell. When Guest Shell is disabled and the system is reloaded, Guest Shell remains disabled.

（Guest Shell 章「Disabling and Destroying the Guest Shell」）

guestshell destroy は flash のファイルシステムから rootfs を消し、中のファイルと入れたアプリケーションは戻せないと書かれています。

The guestshell destroy command removes the rootfs from the flash filesystem. All files, data, installed Linux applications and custom Python tools and utilities are deleted, and are not recoverable.

（Guest Shell 章「Disabling and Destroying the Guest Shell」）

CLI Python Module 章は、Guest Shell の中で動く Python のスクリプトから、ホストの機器の IOS の CLI のコマンドを実行するためのモジュールを Cisco が用意していると書いています。以下、このモジュールを cli モジュールと呼びます（§7）。

Python run in a virtualized Linux-based environment, Guest Shell. For more information, see the Guest Shell chapter. Cisco provides a Python module that allows user’s Python scripts to run IOS CLI commands on the host device.

（CLI Python Module 章「Python Scripts Overview」）

2.6 用語のまとめ

用語は以下のとおりです（出典層。本ラボの表示の語は右の列）。

3. 本ラボの構成

本ラボは CML 上の 4 ノード（CSR1・COL・mgmt-sw・ext）で組みました。ノードとリンクの形は取得スクリプトの設計で、show の出力には出ません（〔ツール側〕取得スクリプトは起動の前にリンク 4 本を確かめています）。図の VPG0 は VirtualPortGroup0 の略です（show app-hosting detail は eth0 の Network name を VPG0 と表示します。§5.4）。

Gi1 は 7-1〜7-3 と同じく Mgmt-vrf に置き、Guest Shell の通信路（VirtualPortGroup0 と NAT）は global の経路表に置きました。NAT の outside は Gi2 だけで、Gi2 の先は COL だけです。Guest Shell からの通信を Mgmt-vrf・本番の LAN・インターネットへ出さないための設計です。

Guest Shell 章の 2 か所の見本の説明は、Guest Shell がインターネットに届く形（1 つ目の節）と、前面のポートをインターネットにつなぐ形（2 つ目の見本の前文）で書かれていて、本ラボはこれと違う形です（§5.1）。本ラボは name-server も設定していません。

図の CSR1 の枠の中の IOSd の箱は、IOS の CLI の側（vty 0 の netops）を表します。IOSd は Guest Shell 章が使う語です。IOSd と Guest Shell の間の緑の 2 本の線は向きだけを示していて、guestshell run と cli モジュールが IOS と Guest Shell の間をどう通るかは撮っていません（§12.1）。

3.1 版と RAM

CSR1 の RAM は、CML の csr1000v の node definition の値（〔ツール側〕取得スクリプトの判定メモでは 3072 MB）を、起動の前に 4096 MB に上書きしました。Table 2 が CSR1000v の最低メモリとして書く 4 GB に合わせた値です（§2.4）。

〔ツール側〕CML の API で読み返した CSR1 の ram の値は以下のとおりです（単位の MB は判定メモの側にあり、この表示には付きません）。

4096

機器の側では、show version の物理メモリの行が 3978408K でした。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の show version の抜粋は以下のとおりです。

CSR1# show version
Cisco IOS XE Software, Version 17.03.08a
Cisco IOS Software [Amsterdam], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 17.3.8a, RELEASE SOFTWARE (fc3)
…（省略）
cisco CSR1000V (VXE) processor (revision VXE) with 2071576K/3075K bytes of memory.
Processor board ID 9ZPGQT9EVTC
Router operating mode: Autonomous
2 Gigabit Ethernet interfaces
32768K bytes of non-volatile configuration memory.
3978408K bytes of physical memory.
6188032K bytes of virtual hard disk at bootflash:.
…（省略）

CML の設定値 4096 と、物理メモリの行 3978408K の対応（差の内訳）は確かめていません。

3.2 経路表

global の経路表に既定経路はありません。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の iox を入れる前の show ip route は以下のとおりです。

CSR1# show ip route
…（省略）
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.7.4.1/32 is directly connected, Loopback0
C        10.7.41.0/24 is directly connected, GigabitEthernet2
L        10.7.41.1/32 is directly connected, GigabitEthernet2

Mgmt-vrf の経路表の既定経路は 172.16.1.1 です。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の show ip route vrf Mgmt-vrf は以下のとおりです。

CSR1# show ip route vrf Mgmt-vrf

Routing Table: Mgmt-vrf
…（省略）
Gateway of last resort is 172.16.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 172.16.1.1
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.1.0/24 is directly connected, GigabitEthernet1
L        172.16.1.241/32 is directly connected, GigabitEthernet1

3.3 起動時の設定と SSH の入口

CSR1 の起動時の設定（day0）は、7-1〜7-3 の §3 と同じ形です（ホスト名・利用者 netops・Mgmt-vrf と Gi1・Loopback0・CLI 用の SSH・logging buffered 512000 informational）。本ラボでは、privilege 1 の利用者 viewer（§11.3）と login on-success log の行も入れました。iox・app-hosting・archive・VirtualPortGroup・nat・guestshell・pnp の語を含む行は、iox を入れる前の running-config に 0 行でした（数えた）。

機器の表示では、CLI の SSH の接続元は 192.168.1.63 に見えます。本ラボの設計では WSL の取得スクリプトの接続ですが、出力では確かめていません。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の iox を入れる前の show users は以下のとおりです。

CSR1# show users
    Line       User       Host(s)              Idle       Location
*  1 vty 0     netops     idle                 00:00:00 192.168.1.63

  Interface    User               Mode         Idle     Peer Address

3.4 COL — 外への通信の受け手

COL は、Guest Shell から外への通信を受ける Ubuntu です。受け手の rx74.py は本ラボで書いた道具で、受けた要求の送信元・ヘッダ・本文を JSON のファイルに記録します（コードは公開していません）。〔ツール側〕COL の shell が表示した OS は以下のとおりです。

COL $ uname -a; python3 -V; head -3 /etc/os-release; date -u
Linux col 6.8.0-59-generic #61-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 11 23:16:11 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Python 3.12.3
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
Mon Oct 19 05:22:32 UTC 2026

COL の 192.168.35.0/24 には unreachable の経路を入れました。NAT が効かない時に、Guest Shell の送信元のままの通信への返りを COL の既定経路へ出さないための設計です。〔ツール側〕COL のアドレスと経路は以下のとおりです。

COL $ ip -4 -br addr; ip route
lo               UNKNOWN        127.0.0.1/8
ens2             UP             172.16.1.242/24
ens3             UP             10.7.41.2/24
default via 172.16.1.1 dev ens2 proto static
10.7.41.0/24 dev ens3 proto kernel scope link src 10.7.41.2
172.16.1.0/24 dev ens2 proto kernel scope link src 172.16.1.242
unreachable 192.168.35.0/24

〔ツール側〕ip route get 192.168.35.2 は終了コード 2 で、標準エラーの行は以下のとおりです。

RTNETLINK answers: No route to host

3.5 撮影の段階

撮影は段階に分け、1 本の取得スクリプトで続けて撮りました。

show clock を撮っていない段の前後は、取得スクリプトが撮った順（〔ツール側〕）と syslog の行頭の時刻で書きます。lowmem の run は、main の run の後始末の後に別のラボで撮ったもので、2 つの run の機器の時計の関係は確かめていません。

4. IOx の有効化

4.1 iox を入れる前の応答

資料は、IOx が有効でない時の表示を 2 か所で書いています。1 つ目は、次の文言がコンソールに出たら IOx が有効でないことを示すので、show iox-service で状態を見るという注です。

If the following message is displayed on the console, it means that IOx is not enabled; check the output of the show iox-service command to view the status of IOx. The process for the command is not responding or is otherwise unavailable

（Guest Shell 章「Enabling and Running the Guest Shell」の注）

2 つ目は、IOx が設定されていない時にコンソールに出る文言です。

IOx must be configured, and running for Guest Shell access to work. If IOx is not configured, the following message is displayed on the device console. iox feature is not enabled.

（Guest Shell 章「Managing the Guest Shell」の Before you begin）

本ラボで iox を入れる前に撮った show iox-service は、表を返しました。CAF と IOxman は Not Running、Libvirtd は Running です。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の表示は以下のとおりです。

CSR1# show iox-service

IOx Infrastructure Summary:
---------------------------
IOx service (CAF)              : Not Running
IOx service (HA)               : Not Supported
IOx service (IOxman)           : Not Running
IOx service (Sec storage)      : Not Supported
Libvirtd                       : Running

同じ時点の show app-hosting list は、1 つ目の注の文言と同じ文字列を返しました。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の表示は以下のとおりです。

CSR1# show app-hosting list
The process for the command is not responding or is otherwise unavailable

guestshell enable は、2 つ目の文言から末尾のピリオドを除いた形の 1 行（行頭に空白 1 つ）を返しました。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の応答は以下のとおりです。

CSR1# guestshell enable
 iox feature is not enabled

iox を入れる前の 3 つのコマンドの応答は、表（show iox-service）・1 つ目の注の文言（show app-hosting list）・2 つ目の文言のピリオドの無い形（guestshell enable）で、それぞれ違う形でした。

4.2 iox の投入と 3 つのサービス

Guest Shell 章の Managing IOx は、IOx の起動に最大 2 分かかり、Guest Shell を有効にするには CAF・IOXman・Libvirtd が動いている必要があると書いています。

IOx takes upto two minutes to start. CAF, IOXman, and Libvirtd services must be running to enable Guest Shell successfully.

（Guest Shell 章「Managing IOx」の Before you begin）

同じ節の手順は、設定モードの iox の後に、show iox-service と show app-hosting list で状態を見る形です。

Step 3 iox Example: Device(config)# iox Configures IOx services. Step 4 exit Example: Device(config)# exit Exits global configuration mode and returns to privileged EXEC mode. Step 5 show iox-service Example: Device# show iox-service Displays the status of the IOx service Step 6 show app-hosting list Example: Device# show app-hosting list Displays the list of app-hosting services enabled on the device.

（Guest Shell 章「Managing IOx」）

本ラボの iox の投入のエコーは以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
CSR1(config)#iox
CSR1(config)#end
CSR1#

本ラボは投入の後、show iox-service を show clock と組にして 2 回撮りました。1 回目（05:23:21.805）は IOxman が Not Running で、CAF の行は名前の後に版の数字 1.11.0.7 を付けて、状態の欄が Running でした。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の 1 回目は以下のとおりです。

CSR1# show clock
*05:23:21.805 UTC Mon Oct 19 2026
CSR1# show iox-service

IOx Infrastructure Summary:
---------------------------
IOx service (CAF) 1.11.0.7     : Running
IOx service (HA)               : Not Supported
IOx service (IOxman)           : Not Running
IOx service (Sec storage)      : Not Supported
Libvirtd                       : Running

2 回目（05:23:36.331）は、CAF・IOxman・Libvirtd の 3 行がそろって Running で、Libvirtd の行にも版の数字 1.3.4 が付きました。HA と Sec storage は、iox の前と iox の後の 2 回のどれも Not Supported です。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の 2 回目は以下のとおりです。

CSR1# show clock
*05:23:36.331 UTC Mon Oct 19 2026
CSR1# show iox-service

IOx Infrastructure Summary:
---------------------------
IOx service (CAF) 1.11.0.7     : Running
IOx service (HA)               : Not Supported
IOx service (IOxman)           : Running
IOx service (Sec storage)      : Not Supported
Libvirtd 1.3.4                 : Running

iox の投入の後の show logging | include IOX|IM-|UICFGEXP の行は 2 行でした。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の表示は以下のとおりです。

CSR1# show logging | include IOX|IM-|UICFGEXP
*Oct 19 05:23:16.897: %UICFGEXP-6-SERVER_NOTIFIED_START: R0/0: psd: Server iox has been notified to start
*Oct 19 05:23:36.533: %IM-6-IOX_ENABLEMENT: R0/0: ioxman: IOX is ready.

フィルタの無い最後の show logging では、この 2 行の間に %SYS-5-CONFIG_I の行（05:23:19.577）と %WSMAN-3-INVALID_TRUSTPOINT の行（05:23:20.211）もありました。どちらの行も、何を受けて出たかは確かめていません。

「Server iox has been notified to start」の行（05:23:16.897）から「IOX is ready.」の行（05:23:36.533）までは、機器の時計で 19.636 秒です。「IOX is ready.」の行は 2 回目の show clock（05:23:36.331）の 0.202 秒後ですが、show iox-service の出力に時刻は無いので、2 回目の show iox-service とこの行のどちらが先かは言えません。IOxman が Running に変わった時点も、1 回目の show iox-service の後から 2 回目の show iox-service までの間としか言えません。2 回目の show clock（05:23:36.331）は 2 回目の show iox-service の前に打ったので、変わった時点の上限にはなりません。

show iox-service に Dockerd の行は、iox の前と iox の後の 2 回の 3 本とも 0 行でした（数えた）。資料の 2 つの見本との違いは §13.6 に並べます。

5. Guest Shell の通信路と有効化

5.1 資料の 2 つの見本

Guest Shell 章は、VirtualPortGroup と NAT の設定を 2 か所で見本にしています。1 つ目は Managing the Guest Shell Using Application Hosting の例で、GigabitEthernet1 を NAT の outside、VirtualPortGroup0 を inside にし、ip nat inside source list で変換します。

Device(config)# interface GigabitEthernet1 Device(config-if)# ip address dhcp Device(config-if)# ip nat outside Device(config-if)# exit Device(config-if)# interface VirtualPortGroup0 Device(config-if)# ip address 192.168.35.1 255.255.255.0 Device(config-if)# ip nat inside Device(config-if)# exit Device(config)# ip nat inside source list GS_NAT_ACL interface GigabitEthernet1 overload Device(config)# ip access-list standard GS_NAT_ACL Device(config)# permit 192.168.0.0 0.0.255.255 Device(config)# app-hosting appid guestshell Device(config-app-hosting)# app-vnic gateway1 virtualportgroup 0 guest-interface 0 Device(config-app-hosting-gateway)# guest-ipaddress 192.168.35.2 netmask 255.255.255.0 Device(config-app-hosting-gateway)# exit Device(config-app-hosting)# app-default-gateway 192.168.35.1 guest-interface 0 Device(config-app-hosting)# end Device# guestshell enable Device# guestshell run python

（Guest Shell 章「Managing the Guest Shell Using Application Hosting」）

同じ節は、Guest Shell が VirtualPortGroup を送信元の IF にして、NAT を通って外のネットワークへ出ると書いています。

For front panel networking, you must configure the GigabitEthernet and VirtualPortGroup interfaces as shown above. The Guest Shell uses a Virtualportgroup as the source interface to connect to the outside network through NAT.

（Guest Shell 章「Managing the Guest Shell Using Application Hosting」）

同じ節は、inside の NAT を組むコマンドで、Guest Shell がインターネットに届くとも書いています。

The following commands are used to configure inside NAT. They allow the Guest Shell to reach the internet; for example, to obtain Linux software updates: ip nat inside source list ip access-list standard permit

（Guest Shell 章「Managing the Guest Shell Using Application Hosting」）

2 つ目は Sample VirtualPortGroup Configuration の見本です。前文は、VirtualPortGroup をルーティングのプラットフォームだけのものとし、前面のポートをインターネットにつなぎ、VirtualPortGroup と前面のポートの間に NAT を組むと書いています。

VirtualPortGroups are supported only on Cisco routing platforms. When using the VirtualPortGroup interface for Guest Shell networking, the VirtualPortGroup interface must have a static IP address configured. The front port interface must be connected to the Internet and Network Address Translation (NAT) must be configured between the VirtualPortGroup and the front panel port.

（Guest Shell 章「Sample VirtualPortGroup Configuration」）

見本の VirtualPortGroup 0 には no mop enabled と no mop sysid があり、NAT の行は ip nat outside source list の形です（1 つ目の例との違いは §13.9）。

The following is a sample VirtualPortGroup configuration: Device> enable Device# configure terminal Device(config)# interface VirtualPortGroup 0 Device(config-if)# ip address 192.168.35.1 255.255.255.0 Device(config-if)# ip nat inside Device(config-if)# no mop enabled Device(config-if)# no mop sysid Device(config-if)# exit Device(config)# interface GigabitEthernet 0/0/3 Device(config-if)# ip address 10.0.12.19 255.255.0.0 Device(config-if)# ip nat outside Device(config-if)# negotiation auto Device(config-if)# exit Device(config)# ip route 0.0.0.0 0.0.0.0 10.0.0.1 Device(config)# ip route 10.0.0.0 255.0.0.0 10.0.0.1 !Port forwarding to use ports for SSH and so on. Device(config)# ip nat inside source static tcp 192.168.35.2 7023 10.0.12.19 7023 extendable Device(config)# ip nat outside source list NAT_ACL interface GigabitEthernet 0/0/3 overload Device(config)# ip access-list standard NAT_ACL Device(config-std-nacl)# permit 192.168.0.0 0.0.255.255 Device(config-std-nacl)# exit

（Guest Shell 章「Sample VirtualPortGroup Configuration」）

この見本の NAT の行は本ラボでは投入しておらず、この版で受理されるかと、どの向きのアドレスを変換するかは確かめていません（§12.1・§13.9）。

5.2 VirtualPortGroup0・NAT・app-hosting の投入

本ラボでは、VirtualPortGroup0 に 192.168.35.1/24 と ip nat inside を、Gi2 に ip nat outside を入れ、ACL GS_NAT_ACL で 192.168.35.0/24 を ip nat inside source list … overload に通しました。VirtualPortGroup0 の no mop enabled と no mop sysid は 2 つ目の見本にある行です。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の投入のエコーは以下のとおりです。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
CSR1(config)#interface VirtualPortGroup0
CSR1(config-if)# ip address 192.168.35.1 255.255.255.0
CSR1(config-if)# ip nat inside
CSR1(config-if)# no mop enabled
CSR1(config-if)# no mop sysid
CSR1(config-if)#interface GigabitEthernet2
CSR1(config-if)# ip nat outside
CSR1(config-if)#ip access-list standard GS_NAT_ACL
CSR1(config-std-nacl)# permit 192.168.35.0 0.0.0.255
CSR1(config-std-nacl)#ip nat inside source list GS_NAT_ACL interface GigabitEthernet2 overload
CSR1(config)#app-hosting appid guestshell
CSR1(config-app-hosting)# app-vnic gateway1 virtualportgroup 0 guest-interface 0
CSR1(config-app-hosting-gateway1)#  guest-ipaddress 192.168.35.2 netmask 255.255.255.0
CSR1(config-app-hosting-gateway1)#  exit
CSR1(config-app-hosting)# app-default-gateway 192.168.35.1 guest-interface 0
CSR1(config-app-hosting)#end
CSR1#

エコーの中に % で始まる行は 0 行でした（数えた）。サブモードのプロンプトは、ACL の行の後が config-std-nacl、app-vnic の行の後が config-app-hosting-gateway1 でした（1 つ目の例のプロンプトの表記は config-app-hosting-gateway）。

受理された app-hosting の形は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show running-config | section app-hosting
app-hosting appid guestshell
 app-vnic gateway1 virtualportgroup 0 guest-interface 0
  guest-ipaddress 192.168.35.2 netmask 255.255.255.0
 app-default-gateway 192.168.35.1 guest-interface 0

VirtualPortGroup0 の running-config は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show running-config interface VirtualPortGroup0
Building configuration...

Current configuration : 119 bytes
!
interface VirtualPortGroup0
 ip address 192.168.35.1 255.255.255.0
 ip nat inside
 no mop enabled
 no mop sysid
end

show ip interface brief で、VirtualPortGroup0 は up/up でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       172.16.1.241    YES TFTP   up                    up
GigabitEthernet2       10.7.41.1       YES TFTP   up                    up
Loopback0              10.7.4.1        YES TFTP   up                    up
VirtualPortGroup0      192.168.35.1    YES manual up                    up

global の経路表には、VirtualPortGroup0 の connected と local の 2 行が加わり、既定経路は無いままでした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show ip route
…（省略）
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.7.4.1/32 is directly connected, Loopback0
C        10.7.41.0/24 is directly connected, GigabitEthernet2
L        10.7.41.1/32 is directly connected, GigabitEthernet2
      192.168.35.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.35.0/24 is directly connected, VirtualPortGroup0
L        192.168.35.1/32 is directly connected, VirtualPortGroup0

NAT の statistics は、outside が GigabitEthernet2、inside が VirtualPortGroup0 の 1 つずつで、変換は 0 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
  GigabitEthernet2
Inside interfaces:
  VirtualPortGroup0
Hits: 0  Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 1] access-list GS_NAT_ACL interface GigabitEthernet2 refcount 0
…（省略）

Mgmt-vrf の経路表は、この投入の前（§3.2）と全行が同じで、VirtualPortGroup0 を含む行は 0 行でした（数えた）。

5.3 guestshell enable — DEPLOYED → ACTIVATED → RUNNING

本ラボでは、設定変更の記録の設定（§8.1）の後に guestshell enable を打ちました。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の出力は以下のとおりです。

CSR1# guestshell enable
Interface will be selected if configured in app-hosting
Please wait for completion
guestshell installed successfully
Current state is: DEPLOYED
guestshell activated successfully
Current state is: ACTIVATED
guestshell started successfully
Current state is: RUNNING
Guestshell enabled successfully

状態の行（Current state is:）は DEPLOYED → ACTIVATED → RUNNING の順に 3 行出ました。successfully を含む行は installed・activated・started・enabled の 4 行です。この出力に時刻は無く、enable にかかった時間は撮っていません。

次に撮った show app-hosting list で、guestshell は RUNNING でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show clock
*05:26:59.829 UTC Mon Oct 19 2026
CSR1# show app-hosting list
App id                                   State
---------------------------------------------------------
guestshell                               RUNNING

syslog には、「Guestshell is up」と書く IOX_INST_INFO の行が 05:26:57.471 に出ていました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging | include IOX|IM-|GUESTSHELL|APP
*Oct 19 05:23:36.533: %IM-6-IOX_ENABLEMENT: R0/0: ioxman: IOX is ready.
*Oct 19 05:26:57.471: %IM-6-IOX_INST_INFO: R0/0: ioxman: IOX SERVICE guestshell LOG: Guestshell is up at 09/19/2026 05:26:57

IOX_INST_INFO の行の中の日付は 09/19/2026 で、行頭の Oct 19（10 月）と月の値が違います（§13.15）。iox の前から no iox → iox までの段の全体は、§10 の図にまとめています。

5.4 予約と資源

show app-hosting detail appid guestshell は、Type が lxc、Name が GuestShell、Version が 3.1.0 で、予約（Resource reservation）は Memory 256 MB・Disk 1 MB・CPU 800 units・VCPU 1 でした。eth0 は 192.168.35.2 で、Network name は VPG0 です（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show app-hosting detail appid guestshell
App id                 : guestshell
Owner                  : iox
State                  : RUNNING
Application
  Type                 : lxc
  Name                 : GuestShell
  Version              : 3.1.0
  Description          : Cisco Systems Guest Shell XE for x86_64
  Path                 : /guestshell/:guestshell.tar
  URL Path             :
Activated profile name : custom

Resource reservation
  Memory               : 256 MB
  Disk                 : 1 MB
  CPU                  : 800 units
  VCPU                 : 1

Attached devices
  Type              Name               Alias
  ---------------------------------------------
  serial/shell     iox_console_shell   serial0
  serial/aux       iox_console_aux     serial1
  serial/syslog    iox_syslog          serial2
  serial/trace     iox_trace           serial3

Network interfaces
   ---------------------------------------
eth0:
   MAC address         : 52:54:dd:20:5b:8a
   IPv4 address        : 192.168.35.2
   Network name        : VPG0

Port forwarding
  Table-entry  Service  Source-port  Destination-port
  ---------------------------------------------------

show app-hosting resource の Memory は Quota 1024(MB)・Available 768(MB) で、差の 256 は予約の Memory と同じ数でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show app-hosting resource
CPU:
  Quota: 7(Percentage)
  Available: 7(Percentage)
VCPU:
  Count: 0
Memory:
  Quota: 1024(MB)
  Available: 768(MB)
Storage space:
  Total: 5995(MB)
  Available: 3992(MB)

Quota・Available と予約の値の関係は確かめていません。CPU は Quota と Available が同じ 7(Percentage) で、VCPU の Count は 0 でした。

show app-hosting utilization appid guestshell の Memory Used は 61204 KB でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show app-hosting utilization appid guestshell
Application: guestshell
CPU Utilization:
  CPU Allocation: 800 units
  CPU Used:       0.00 %
Memory Utilization:
  Memory Allocation: 256 MB
  Memory Used:       61204 KB
Disk Utilization:
  Disk Allocation: 1 MB
  Disk Used:       0.00 MB

Allocation の 3 つ（800 units・256 MB・1 MB）は、detail の予約の CPU・Memory・Disk と同じ数です。Table 3 の CSR1000v の Memory の 512 MB と、この予約の 256 MB は §13.1 で並べます。

5.5 bootflash と guest-share

enable の後の dir bootflash: に guest-share のディレクトリがありました。名前に guestshell を含む行と .tar を含む行は 0 行でした（数えた）。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の dir bootflash: の抜粋は以下のとおりです。

CSR1# dir bootflash:
Directory of bootflash:/

306433  drwx             4096  Oct 19 2026 05:27:12 +00:00  tracelogs
72577   drwx             4096  Oct 19 2026 05:26:57 +00:00  gs_script
217729  drwx             4096  Oct 19 2026 05:23:45 +00:00  SHARED-IOX
129025  drwx             4096  Oct 19 2026 05:23:18 +00:00  iox_host_data_share
112897  drwx             4096  Oct 19 2026 05:23:17 +00:00  guest-share
…（省略）

6286540800 bytes total (4407930880 bytes free)

dir bootflash:guest-share/ は空でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# dir bootflash:guest-share/
Directory of bootflash:guest-share/

No files in directory

6286540800 bytes total (4407930880 bytes free)

show app-hosting detail の Path（/guestshell/:guestshell.tar）の実体の置き場所と、gs_script・SHARED-IOX・iox_host_data_share の中身は撮っていません。

6. Guest Shell の中

本ラボでは、IOS の CLI で guestshell run <コマンド> を打ち、Guest Shell の中のコマンドの出力を撮りました。保存した出力で最初の guestshell run は guestshell run cat /etc/os-release で、CentOS Linux 8 を示しました。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の出力の抜粋は以下のとおりです。

CSR1# guestshell run cat /etc/os-release
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8 (Core)"
…（省略）

6.1 OS・カーネル・ユーザー

uname -a は 4.19.279 のカーネルを示しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run uname -a
Linux guestshell 4.19.279 #1 SMP Fri Jun 9 13:34:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

whoami は guestshell でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run whoami
guestshell

id は uid 1000 の guestshell で、group に network-admin・tty・wheel が並びました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run id
uid=1000(guestshell) gid=1000(guestshell) groups=1000(guestshell),100000(network-admin),5(tty),10(wheel)

group で何ができるか（sudo の可否を含む）は撮っていません。資料が Guest Shell の利用者について書く文は §11.3 にあります。

6.2 Python の版と名前

資料は、17.3.1 以降の既定を Python V3 としています（§2.3）。Guest Shell 章の Managing the Guest Shell の Step 3 の注は、17.3.1 以降は Python 3 だけを支えると書いています。

In Cisco IOS XE Amsterdam 17.3.1 and later releases, only Python version 3 is supported.

（Guest Shell 章「Managing the Guest Shell」の Step 3 の注）

本ラボの python3 -V は Python 3.6.8 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run python3 -V
Python 3.6.8

python は、env がファイルを見つけられない行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run python -V
env: 'python': No such file or directory

python2 も同じ形の行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run python2 -V
env: 'python2': No such file or directory

ls -la /usr/bin/python* の応答は、ls: cannot access で始まる 2 行でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run ls -la /usr/bin/python*
ls: cannot access '/usr/bin/python': No such file or directory
ls: cannot access '/usr/bin/python2.7': No such file or directory

ls に渡った引数（* がどこで展開されたか）は撮っていないので、この 2 行を /usr/bin の中身の根拠にはしません。同じ /usr/bin を find で見ると、python3.6m・python3.6・python3 の 3 本のシンボリックリンクがありました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run find /usr/bin -maxdepth 1 -name python* -ls
    54406      0 lrwxrwxrwx   1  root     root           32 Nov 20  2019 /usr/bin/python3.6m -> /usr/libexec/platform-python3.6m
    30647      0 lrwxrwxrwx   1  root     root           31 Nov 20  2019 /usr/bin/python3.6 -> /usr/libexec/platform-python3.6
    48599      0 lrwxrwxrwx   1  root     root           25 Jun  1  2020 /usr/bin/python3 -> /etc/alternatives/python3

find の出力に python2 を含む行は 0 行でした（数えた）。find は /usr/bin の直下だけを見ていて、PATH のほかの場所と、/etc/alternatives/python3 の先は撮っていません。

6.3 pip と site-packages

pip3 -V は pip 9.0.3 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run pip3 -V
pip 9.0.3 from /usr/lib/python3.6/site-packages (python 3.6)

pip3 list の 1 行目は DEPRECATION の警告の行で、エスケープの文字を含むので省略しました。パッケージの行は 4 行でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run pip3 list
…（省略）
gpg (1.10.0)
pip (9.0.3)
rpm (4.14.2)
setuptools (39.2.0)

pip3 list に cli・eem・pnp の名前で始まる行は 0 行でした（数えた）。

資料（CLI Python Module 章）は、cli モジュールと EEM（Embedded Event Manager）のモジュールが機器にあらかじめ入っていると書いています。

The Cisco CLI Python module and EEM module are pre-installed on devices. However, when you update the Python version by using either Yum or prepackaged binaries, the Cisco-provided CLI module must also be updated.

（CLI Python Module 章「Updating the Cisco CLI Python Module」）

site-packages のディレクトリの一覧には、cli・eem・pnp・errors のディレクトリと dohost.py がありました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run ls -la /usr/lib/python3.6/site-packages/
total 15
drwxr-xr-x. 13 root root 1024 Jun  1  2020 .
drwxr-xr-x.  3 root root 1024 Nov 21  2019 ..
drwxr-xr-x.  3 root root 1024 Jun  1  2020 cli
drwxr-xr-x.  8 root root 1024 Jun  1  2020 dnf
drwxr-xr-x.  2 root root 1024 Jun  1  2020 dnf-plugins
-rw-r--r--.  1 root root  424 Jun  1  2020 dohost.py
-rw-r--r--.  1 root root  126 Nov 12  2019 easy_install.py
drwxr-xr-x.  2 root root 1024 Jun  1  2020 eem
drwxr-xr-x.  2 root root 1024 Jun  1  2020 errors
drwxr-xr-x. 10 root root 1024 Jun  1  2020 pip
drwxr-xr-x.  2 root root 1024 Jun  1  2020 pip-9.0.3.dist-info
drwxr-xr-x.  4 root root 1024 Jun  1  2020 pkg_resources
drwxr-xr-x.  2 root root 1024 Jun  1  2020 pnp
drwxr-xr-x.  5 root root 1024 Jun  1  2020 setuptools
drwxr-xr-x.  2 root root 1024 Jun  1  2020 setuptools-39.2.0.dist-info

pip3 list の行と site-packages の一覧は並べるだけで、cli・eem・pnp・errors・dohost.py を import できるかと中身は、ここでは撮っていません（cli は §7 で import しました）。

6.4 マウントとメモリ

df -h のマウント先には、/cisco/.iosp_socket と /bootflash/guest-share がありました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop3      968M  260M  660M  29% /
tmpfs           1.9G  6.0M  1.9G   1% /cisco/cisco_cli
tmpfs           1.9G   16M  1.9G   1% /cisco/.iosp_socket
/dev/vda11      5.9G  1.5G  4.2G  27% /bootflash/guest-share
tmpfs            64K     0   64K   0% /sys/fs/cgroup
devfs            64K     0   64K   0% /dev
/dev/loop2      3.0M   28K  2.8M   1% /data
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  4.1M  1.9G   1% /run
none            1.9G   20K  1.9G   1% /var/volatile

free -m の total は 3885 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run free -m
              total        used        free      shared  buff/cache   available
Mem:           3885        1706          59         206        2118        1915
Swap:             0           0           0

show version の物理メモリの行の 3978408K を 1024 で割ると 3885.16… で、整数の部分が free の total と同じ数になります。2 つの出力の単位が同じものかは出力からは確かめていません。予約の 256 MB（§5.4）との関係も、Guest Shell の中でメモリの上限を試しておらず、確かめていません。

6.5 ディレクトリ

Guest Shell の /bootflash/ に見えた項目は、guest-share の 1 つでした。IOS の dir bootflash: の一覧（§5.5）の項目は 26 行です（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run ls -la /bootflash/
total 10
drwxr-xr-x.  3 root   root          1024 Oct 19 05:26 .
drwxr-xr-x. 23 root   root          1024 Oct 19 05:26 ..
drwxrwxr-x.  2 nobody network-admin 4096 Oct 19 05:23 guest-share

/home/guestshell/ の項目は、.bash_logout・.bash_profile・.bashrc・.ssh の 4 つでした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run ls -la /home/guestshell/
total 6
drwx------. 3 guestshell users 1024 Oct 19 05:26 .
drwxr-xr-x. 3 root       root  1024 Jun  1  2020 ..
-rw-r--r--. 1 guestshell users   18 Nov  8  2019 .bash_logout
-rw-r--r--. 1 guestshell users  141 Nov  8  2019 .bash_profile
-rw-r--r--. 1 guestshell users  312 Nov  8  2019 .bashrc
drwx------. 2 guestshell users 1024 Oct 19 05:26 .ssh

/cisco/ には、.iosp_socket（1 文字目が s）・cisco_cli・guestshell・nginx_shared・python3 がありました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run ls -la /cisco/
total 4
drwxr-xr-x.  6 root   root   1024 Oct 19 05:26 .
drwxr-xr-x. 23 root   root   1024 Oct 19 05:26 ..
srw-rw-rw-.  1 nobody nobody    0 Oct 19 05:22 .iosp_socket
drwxr-xr-x.  3 nobody nobody   60 Oct 19 05:30 cisco_cli
drwxr-xr-x.  2 root   root   1024 Oct 19 05:26 guestshell
drwxr-xr-x.  2 nobody nobody   80 Oct 19 05:23 nginx_shared
drwxr-xr-x.  3 root   root   1024 Jun  1  2020 python3

これらのファイルとディレクトリが何に使われるかは確かめていません。

資料（CLI Python Module 章）は、スクリプトを Guest Shell から見えるように、Guest Shell に mount された bootflash/flash に置くよう書いています。

Python scripts can run in non-interactive mode by providing the Python script name as an argument in the Python command. Python scripts must be accessible from within the Guest Shell. To access Python scripts from the Guest Shell, save the scripts in bootflash/flash that is mounted within the Guest Shell.

（CLI Python Module 章「Python Script」）

6.6 IF と経路

Guest Shell で ip のコマンドを呼ぶと、env が見つけられない行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run ip addr
env: 'ip': No such file or directory

IF の名前は /sys/class/net で読みました。eth0 と lo の 2 つです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run ls /sys/class/net
eth0  lo

eth0 の MAC アドレスは、show app-hosting detail の eth0 の MAC address（§5.4）と同じ文字列でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run cat /sys/class/net/eth0/address
52:54:dd:20:5b:8a

経路は guestshell run cat /proc/net/route で読みました。出力はタブ区切りなので、値を表に書き写します（CSR1 csr1000v 17.03.08a・RAM 4096 MB の出力の 2 行。右端の列は計算）。

10 進の値は、16 進の 8 桁を 2 桁ずつに分けて逆の順に並べた計算で、逆の順に読むことは計算の前提です。本ラボの出力では確かめていません。計算した 192.168.35.1 は、app-hosting の app-default-gateway 192.168.35.1 guest-interface 0 と同じ文字列です。Guest Shell の中で eth0 の IPv4 アドレスは撮っていません。

6.7 名前解決

/etc/resolv.conf の見出しを除いた 56 行は、# で始まる行と空行だけで、nameserver で始まる行は 0 行でした（数えた）。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の resolv.conf の抜粋は以下のとおりです。

CSR1# guestshell run cat /etc/resolv.conf
…（省略）
#nameserver <ip-addr-1>
#nameserver <ip-addr-2>
#nameserver <ip-addr-3>
…（省略）

7. cli モジュールによる show と設定

7.1 資料の 6 つの関数

Python API 章は、CLI のコマンドを実行できる関数を 6 つとし、import cli で使うと書いています。

The Python programming language uses six functions that can execute CLI commands. These functions are available from the Python CLI module. To use these functions, execute the import cli command.

（Python API 章「Cisco Python Module to Execute IOS CLI Commands」）

6 つの関数の資料の説明は以下のとおりです（出典層）。

cli.execute と cli.cli の説明の文は以下のとおりです。

cli.execute(command) —This function executes a single EXEC command and returns the output; however, does not print the resulting text No semicolons or newlines are allowed as part of this command. Use a Python list with a for-loop to execute this function more than once. The following is sample output from the cli.execute(command) function:

（Python API 章「Cisco Python Module to Execute IOS CLI Commands」）

cli.cli(command) —This function takes an IOS command as an argument, runs the command through the IOS parser, and returns the resulting text. If this command is malformed, a Python exception is raised. The following is sample output from the cli.cli(command) function:

（Python API 章「Cisco Python Module to Execute IOS CLI Commands」）

cli.configure の戻り値の資料の書き方は、§13.3 で本ラボの戻り値と並べます。

7.2 Guest Shell の bash でのスクリプトの作成

CLI Python Module 章は、Guest Shell のスクリプトを機器のプロンプトで guestshell run python /bootflash/guest-share/script.py として動かすと書いています。

To run a Python script from the Guest Shell, execute the guestshell run python /bootflash/guest-share/script.py command at the device prompt.

（CLI Python Module 章「Python Script」）

本ラボでは、IOS の CLI で guestshell run bash を打って Guest Shell の bash に入り（プロンプトは [guestshell@guestshell ~]$）、heredoc で /bootflash/guest-share/ に 3 本のスクリプトを書いて、IOS の CLI の guestshell run python3 で動かしました。1 本目の p74_show.py は、cli.execute と cli.cli で show を読んで print します。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の Guest Shell の bash のエコーは以下のとおりです。

cat > /bootflash/guest-share/p74_show.py <<'PYEOF'
> import cli
>
> print("== cli.execute show clock")
> print(cli.execute("show clock"))
> print("== cli.cli show ip interface brief")
> print(cli.cli("show ip interface brief"))
> print("== cli.execute show users")
> print(cli.execute("show users"))
> print("== cli.execute show tcp brief all")
> print(cli.execute("show tcp brief all"))
> PYEOF
…（省略）

Guest Shell の中の sha256sum の値は ea88593d668b8706 で始まり（全 64 桁の先頭 16 桁）、〔ツール側〕取得スクリプトが手元の本文から計算した値と一致しました。ls -la の大きさは 318 バイトです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

[guestshell@guestshell ~]$ ls -la /bootflash/guest-share/p74_show.py
-rw-rw-r--. 1 guestshell guestshell 318 Oct 19 05:32 /bootflash/guest-share/p74_show.py

2 本目の p74_conf.py は、cli.configure に正しい 3 行のリスト（VALID）と、無効な行を含むリスト（INVALID）を順に渡し、戻り値の型と値、または例外の型と文字列を print します。description の値は実行時に "set-by-" + "guestshell-p74" で組み立て、本文に完成形の文字列を置いていません。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の Guest Shell の bash のエコーは以下のとおりです。

cat > /bootflash/guest-share/p74_conf.py <<'PYEOF'
> import cli
>
> DESC = "set-by-" + "guestshell-p74"
> VALID = ["interface Loopback74", "description " + DESC, "ip address 10.7.4.74 255.255.255.255"]
> INVALID = ["interface Loopback74", "no-such-command-p74"]
>
>
> def attempt(label, lines):
>     try:
>         res = cli.configure(lines)
>     except Exception as exc:
>         print("== %s raised type=%s text=%s" % (label, type(exc).__name__, exc))
>         return
>     print("== %s returned type=%s" % (label, type(res).__name__))
>     if isinstance(res, (list, tuple)):
>         for i, item in enumerate(res):
>             print("item %d: %r" % (i, item))
>     else:
>         print("value: %r" % (res,))
>
>
> attempt("cli.configure(valid)", VALID)
> attempt("cli.configure(invalid)", INVALID)
> PYEOF
…（省略）

sha256sum の値は c8781164f382795e で始まり、ls -la の大きさは 719 バイトです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

[guestshell@guestshell ~]$ ls -la /bootflash/guest-share/p74_conf.py
-rw-rw-r--. 1 guestshell guestshell 719 Oct 19 05:32 /bootflash/guest-share/p74_conf.py

3 本目の p74_post.py は、cli.execute で show ip interface brief の出力を取り、http://10.7.41.2:8074/p74 へ POST します（§9 で動かしました）。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の Guest Shell の bash のエコーは以下のとおりです。

cat > /bootflash/guest-share/p74_post.py <<'PYEOF'
> import sys
> import urllib.request
>
> import cli
>
> URL = "http://10.7.41.2:8074/p74"
> try:
>     body = cli.execute("show ip interface brief")
>     req = urllib.request.Request(URL, data=body.encode("utf-8"), headers={"Content-Type": "text/plain"}, method="POST")
>     with urllib.request.urlopen(req, timeout=10) as resp:
>         print("status %s" % resp.status)
>         print(resp.read().decode("utf-8", "replace"))
> except Exception as exc:
>     print("%s: %s" % (type(exc).__name__, exc))
>     sys.exit(1)
> PYEOF
…（省略）

sha256sum の値は d1d87df8114bc32d で始まり、ls -la の大きさは 497 バイトです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

[guestshell@guestshell ~]$ ls -la /bootflash/guest-share/p74_post.py
-rw-rw-r--. 1 guestshell guestshell 497 Oct 19 05:32 /bootflash/guest-share/p74_post.py

bash を exit で抜けると、IOS のプロンプトに戻りました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

exit
exit

CSR1#

Guest Shell が書いた 3 本は、IOS の dir bootflash:guest-share/ にも同じ大きさで見えました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# dir bootflash:guest-share/
Directory of bootflash:guest-share/

112900  -rw-              497  Oct 19 2026 05:32:08 +00:00  p74_post.py
112899  -rw-              719  Oct 19 2026 05:32:06 +00:00  p74_conf.py
112898  -rw-              318  Oct 19 2026 05:32:04 +00:00  p74_show.py

6286540800 bytes total (4406988800 bytes free)

ファイルの属性の列は、IOS の dir が -rw-、Guest Shell の ls -la が -rw-rw-r--.（所有者と group は guestshell）でした。IOS の側からファイルの中身を読むことは撮っていません。

7.3 show の読み取り — cli.execute と cli.cli

IOS の CLI で打った guestshell run python3 /bootflash/guest-share/p74_show.py の出力は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run python3 /bootflash/guest-share/p74_show.py
== cli.execute show clock
*05:32:19.050 UTC Mon Oct 19 2026

== cli.cli show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       172.16.1.241    YES TFTP   up                    up
GigabitEthernet2       10.7.41.1       YES TFTP   up                    up
Loopback0              10.7.4.1        YES TFTP   up                    up
VirtualPortGroup0      192.168.35.1    YES manual up                    up

== cli.execute show users
    Line       User       Host(s)              Idle       Location
   1 vty 0     netops     192.168.1.5          00:00:01 192.168.1.63
  Interface    User               Mode         Idle     Peer Address

== cli.execute show tcp brief all
TCB       Local Address               Foreign Address             (state)
7F66CA355000  172.16.1.241.22            192.168.1.63.56710          ESTAB
7F66CA6E0460  192.168.1.6.30209          192.168.1.5.16023           ESTAB
7F66C62542F8  ::.21111                   *.*                         LISTEN
7F6736B2F050  0.0.0.0.21111              *.*                         LISTEN
7F67319F5000  ::.443                     *.*                         LISTEN
7F66C9AD5000  0.0.0.0.443                *.*                         LISTEN

スクリプトが print した 4 つの見出しの下に、show clock・show ip interface brief・show users・show tcp brief all の表示が並びました。cli.execute と cli.cli の戻り値の型は撮っておらず（print しただけ）、同じコマンドを両方で打っていないので、表示の違いも比べていません。

スクリプトの中の show users は、vty 0 の netops の行の Host(s) が 192.168.1.5 で、行頭に * がありませんでした。IOS の CLI で打った show users（§3.3）は Host(s) が idle で、行頭に * があります。スクリプトの中の show tcp brief all には、Local Address 192.168.1.6.30209・Foreign Address 192.168.1.5.16023 の ESTAB の行が 1 行加わっていました。192.168.1.5 と 192.168.1.6 が何か、この接続を誰が張ったかは確かめていません。

7.4 設定の投入 — cli.configure の戻り値と失敗

IOS の CLI で打った guestshell run python3 /bootflash/guest-share/p74_conf.py の出力は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run python3 /bootflash/guest-share/p74_conf.py
== cli.configure(valid) returned type=str
value: 'Line 1 SUCCESS:  interface Loopback74\nLine 2 SUCCESS:  description set-by-guestshell-p74\nLine 3 SUCCESS:  ip address 10.7.4.74 255.255.255.255\n'
== cli.configure(invalid) raised type=IOSPCLIConfError text=ConfigError: There was a problem with 1 commands while configuring the device.
Line 1 SUCCESS:  interface Loopback74
Line 2 FAILURE:  no-such-command-p74
**CLI Line 2:      ^

VALID の呼び出しは戻り、型の名前は str でした。値は、Line 1 SUCCESS: から Line 3 SUCCESS: で始まる 3 行が、それぞれの後ろに改行（\n）を付けて 1 つの文字列になったものです。list と tuple の分岐の print（item で始まる行）は 0 行でした（数えた）。

INVALID の呼び出しは例外で、型の名前は IOSPCLIConfError、例外の文字列は ConfigError で始まり、続く行に Line 1 SUCCESS: interface Loopback74 と Line 2 FAILURE: no-such-command-p74 が出ました。5〜7 行目が 4 行目と同じ 1 本の print の続き（例外の文字列の中の改行の後）か、別の書き込みかは、出力からは区別していません。資料の戻り値と例外の名前との違いは §13.3・§13.4 に並べます。

p74_conf.py の後に撮った show running-config interface Loopback74 には、VALID の description と ip address が入っていました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show running-config interface Loopback74
Building configuration...

Current configuration : 101 bytes
!
interface Loopback74
 description set-by-guestshell-p74
 ip address 10.7.4.74 255.255.255.255
end

撮ったのは 2 回の呼び出し（VALID → INVALID）の後の 1 本だけで、2 回の間の running-config は撮っていません。下の図は、vty の guestshell run から Guest Shell の Python・設定・機器の外への流れを 6 つの段で示しています（④ は §8.2、⑤・⑥ は §9）。

8. 設定変更の記録と PnP の profile

本ラボでは、Guest Shell の cli.configure による設定の変更が設定変更の記録にどう出るかを撮りました。Guest Shell を使う前後に機器が出した PnP の profile と syslog の行も、3 つの時点で撮りました。どちらも逐語を時刻とともに並べるだけで、理由は確かめていません。

8.1 archive の設定と「前」

設定変更の記録（archive の log config）は、guestshell enable の前に有効にしました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
CSR1(config)#archive
CSR1(config-archive)# log config
CSR1(config-archive-log-cfg)#  logging enable
CSR1(config-archive-log-cfg)#  notify syslog contenttype plaintext
CSR1(config-archive-log-cfg)#  hidekeys
CSR1(config-archive-log-cfg)#  exit
CSR1(config-archive)# exit
CSR1(config)#end
CSR1#

show running-config | section archive は 4 行で、投入した hidekeys を含む行は 0 行でした（数えた。CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show running-config | section archive
archive
 log config
  logging enable
  notify syslog contenttype plaintext

有効にした直後の show archive log config all（前）は idx 33〜37 の 5 行で、user@line はどれも netops@vty0 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show archive log config all
 idx   sess           user@line      Logged command
   33     1         netops@vty0     |  logging enable
   34     1         netops@vty0     |  notify syslog contenttype plaintext
   35     1         netops@vty0     |  hidekeys
   36     1         netops@vty0     |  exit
   37     1         netops@vty0     |   exit

idx が 33 から始まることと、投入した archive・log config・end に当たる行が無いことの理由は確かめていません。

8.2 Guest Shell の変更と vty 0 の変更

Guest Shell の p74_conf.py（§7.4）の後に、比べる相手として、IOS の CLI（vty 0）から Loopback75 に description を入れました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
CSR1(config)#interface Loopback75
CSR1(config-if)# description set-by-vty-p74
CSR1(config-if)#end
CSR1#

2 つの変更の後に撮った show logging | include CONFIG|PARSER|CFGLOG|Loopback7 の、05:32 台の 9 行は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging | include CONFIG|PARSER|CFGLOG|Loopback7
…（省略）
*Oct 19 05:32:28.893: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback74, changed state to up
*Oct 19 05:32:28.901: %PARSER-5-CFGLOG_LOGGEDCMD: User:netops  logged command:interface Loopback74
*Oct 19 05:32:28.904: %PARSER-5-CFGLOG_LOGGEDCMD: User:netops  logged command:description set-by-guestshell-p74
*Oct 19 05:32:28.922: %PARSER-5-CFGLOG_LOGGEDCMD: User:netops  logged command:ip address 10.7.4.74 255.255.255.255
*Oct 19 05:32:28.957: %PARSER-5-CFGLOG_LOGGEDCMD: User:netops  logged command:interface Loopback74
*Oct 19 05:32:37.497: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback75, changed state to up
*Oct 19 05:32:37.499: %PARSER-5-CFGLOG_LOGGEDCMD: User:netops  logged command:interface Loopback75
*Oct 19 05:32:40.684: %PARSER-5-CFGLOG_LOGGEDCMD: User:netops  logged command:description set-by-vty-p74
*Oct 19 05:32:43.937: %SYS-5-CONFIG_I: Configured from console by netops on vty0 (192.168.1.63)

CFGLOG の行は、Guest Shell の変更（Loopback74・set-by-guestshell-p74）も vty 0 の変更（Loopback75・set-by-vty-p74）も User:netops で、vty の番号を含みませんでした。Loopback74 の CFGLOG の 4 行（05:32:28.901〜05:32:28.957）の次の行は 05:32:37.497 の Loopback75 の LINEPROTO で、その間の行は 0 行です（このフィルタは CONFIG を含みます）。05:32 台の %SYS-5-CONFIG_I は、Loopback75 の CFGLOG の 2 行の後の 05:32:43.937 の 1 行だけでした。

フィルタの無い最後の show logging でも、05:32:28.957 の行と 05:32:37.497 の行は隣り合っています。これはこの撮影の 1 回の観測で、Guest Shell の変更の性質としては確かめていません。この show logging の見出しの行には 3 messages rate-limited が出ていて、どの行がいつ rate-limit を受けたか、バッファに入ったかどうかは、出力からは分かりません。

2 つの変更の後の show archive log config all（後）は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show archive log config all
 idx   sess           user@line      Logged command
   33     1         netops@vty0     |  logging enable
   34     1         netops@vty0     |  notify syslog contenttype plaintext
   35     1         netops@vty0     |  hidekeys
   36     1         netops@vty0     |  exit
   37     1         netops@vty0     |   exit
   38     0         netops@vty116   |interface Loopback74
   39     0         netops@vty116   | description set-by-guestshell-p74
   40     0         netops@vty116   | ip address 10.7.4.74 255.255.255.255
   41     0         netops@vty116   | interface Loopback74
   42     0         netops@vty0     |interface Loopback75
   43     0         netops@vty0     | description set-by-vty-p74

「前」の 5 行（idx 33〜37）に 6 行が加わりました。Loopback74 と set-by-guestshell-p74 の 4 行（idx 38〜41）の user@line は netops@vty116、Loopback75 と set-by-vty-p74 の 2 行（idx 42〜43）は netops@vty0 で、sess はどちらも 0 でした。idx 38〜40 は VALID の 3 行と、idx 41 の interface Loopback74 は INVALID の 1 行目と、順と文字列が合います。no-such-command-p74 を含む行は 0 行です（数えた）。

vty116 が何の line か、sess の値の意味は確かめていません。p74_conf.py を動かしている間の show users も撮っていません。

8.3 PnP の profile の 3 点

PnP の profile は、iox を入れる前（1 点目）、guestshell enable の後で最初の guestshell run の前（2 点目）、最初の guestshell run の後（3 点目）の 3 つの時点で撮りました。2 点目と 3 点目の前後は、取得スクリプトが撮った順（〔ツール側〕）で言っています。1 点目の show pnp profile は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show pnp profile
PnP Profiles: Active:0, Created:0, Deleted:0, Hidden:0

first-profile-created-name=[-] by:[-])
last-profile-created-name=[-] by:[-]
last-profile-deleted-name=[-] by:[-]

Name            CBType Node     Primary-Path           Primary-Trans  Backup-Trans

-------------- show pnp http tracking ---------------
…（省略）

1 点目の show logging | include PNP は 5 行で、どれも起動時の行（05:22:16.575〜05:22:27.702）でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging | include PNP
*Oct 19 05:22:16.575: %PNP-6-PNP_DISCOVERY_STARTED: PnP Discovery started
*Oct 19 05:22:16.578: %PNP-6-PNP_GOOD_UDI_UPDATE: Good UDI [PID:CSR1000V,VID:,SN:9ZPGQT9EVTC] identified via (platform-registry)
*Oct 19 05:22:16.578: %PNP-6-PNP_CDP_UPDATE: Device UDI [PID:CSR1000V,VID:,SN:9ZPGQT9EVTC] identified for CDP
*Oct 19 05:22:27.701: %PNP-6-PNP_BEST_UDI_UPDATE: Best UDI [PID:CSR1000V,VID:V00,SN:9ZPGQT9EVTC] identified via (entity-mibs)
*Oct 19 05:22:27.702: %PNP-6-PNP_DISCOVERY_STOPPED: PnP Discovery stopped (Startup Config Present)

2 点目の show pnp profile・show running-config | section pnp・show logging | include PNP の 3 本は、1 点目とバイト単位で同じでした（cmp）。

3 点目の show pnp profile は Active:1・Created:1・Hidden:1 になり、pnp_python という profile が載っていました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show pnp profile
PnP Profiles: Active:1, Created:1, Deleted:0, Hidden:1

first-profile-created-name=[pnp_python] by:[pid=19, pname=SSH Process, time=05:27:38 UTC Mon Oct 19 2026])
last-profile-created-name=[pnp_python] by:[pid=19, pname=SSH Process, time=05:27:38 UTC Mon Oct 19 2026]
last-profile-deleted-name=[-] by:[-]

Name            CBType Node     Primary-Path           Primary-Trans  Backup-Trans
pnp_python      User   hidden   /pnp_python            HTTP           none


Listener Profile pnp_python: 0 open connections: 0 closing connections
…（省略）
  Listening to path /pnp_python.  Max Idle 0 ms.  Accepting post on plaintext connections.
  Established at *05:27:38.888 UTC Mon Oct 19 2026
…（省略）

3 点目の show logging | include PNP には、起動時の 5 行の後に PNP_PROFILE_CREATED の行が 1 行加わっていました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging | include PNP
*Oct 19 05:22:16.575: %PNP-6-PNP_DISCOVERY_STARTED: PnP Discovery started
*Oct 19 05:22:16.578: %PNP-6-PNP_GOOD_UDI_UPDATE: Good UDI [PID:CSR1000V,VID:,SN:9ZPGQT9EVTC] identified via (platform-registry)
*Oct 19 05:22:16.578: %PNP-6-PNP_CDP_UPDATE: Device UDI [PID:CSR1000V,VID:,SN:9ZPGQT9EVTC] identified for CDP
*Oct 19 05:22:27.701: %PNP-6-PNP_BEST_UDI_UPDATE: Best UDI [PID:CSR1000V,VID:V00,SN:9ZPGQT9EVTC] identified via (entity-mibs)
*Oct 19 05:22:27.702: %PNP-6-PNP_DISCOVERY_STOPPED: PnP Discovery stopped (Startup Config Present)
*Oct 19 05:27:38.843: %PNP-6-PNP_PROFILE_CREATED: PnP profile (pnp_python) created (1/3) by (pid=19, pname=SSH Process, time=05:27:38 UTC Mon Oct 19 2026)

3 点の show running-config | section pnp は、どれも出力に文字のある行が 0 行でした（数えた）。3 点目は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show running-config | section pnp

時刻を並べると以下のとおりです（どれも機器の時計）。

2 点目と 3 点目の間に保存したファイルは、2 点目の残りの 4 本（section pnp・include PNP・show users・show tcp brief all）と、最初の guestshell run の 1 本です（取得スクリプトの連番 =〔ツール側〕）。保存しないコマンドを取得スクリプトが打ったかは、保存した出力からは言えません。pnp_python が何のための profile か、pid=19, pname=SSH Process がどのセッションのどのプロセスか、created (1/3) の 1/3 と Hidden:1 の意味は確かめていません。

profile の名前 pnp_python の文字列は、出典の 5 つの章の本文に 0 件です（数えた）。

8.4 Gi1 側の接続の確認

本ラボは、PnP の profile の設定と Gi1 側の TCP の接続を、3 点目の直後と §9 の後に撮りました。Guest Shell を使った後に、機器が Mgmt-vrf の側へ自分から接続を張っていないかを見るためです。section pnp に Mgmt-vrf・GigabitEthernet1 を含む行は 0 行で、show tcp brief all の Local Address が 172.16.1.241 の行は port 22 の 1 行だけでした（数えた）。3 点目の直後の show tcp brief all は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show tcp brief all
TCB       Local Address               Foreign Address             (state)
7F66CA355000  172.16.1.241.22            192.168.1.63.56710          ESTAB
7F66C62542F8  ::.21111                   *.*                         LISTEN
7F6736B2F050  0.0.0.0.21111              *.*                         LISTEN
7F67319F5000  ::.443                     *.*                         LISTEN
7F66C9AD5000  0.0.0.0.443                *.*                         LISTEN

この確認は撮った瞬間の表の上の判定で、撮影と撮影の間に開いて閉じた接続と、TCP 以外の通信は見ていません。LISTEN の 4 行（21111・443）が何の待ち受けかも確かめていません。

9. Guest Shell から機器の外へ

9.1 受け手の待ち受けと POST

資料は、Guest Shell が VirtualPortGroup を送信元の IF にし、NAT を通って外のネットワークへ出ると書いています（§5.1）。

本ラボの外への通信の受け手は COL の rx74.py です。〔ツール側〕COL の受け手の待ち受けは以下のとおりです。

COL $ ss -ltnp | grep -E ':8074\b'; cat /home/labuser/rx74.log
LISTEN 0      5          10.7.41.2:8074      0.0.0.0:*    users:(("python3",pid=1191,fd=3))
rx74: listening on 10.7.41.2:8074 -> /home/labuser/rx74

IOS の CLI で打った guestshell run python3 /bootflash/guest-share/p74_post.py の出力は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run python3 /bootflash/guest-share/p74_post.py
status 200
rx74 ok req-01.json

p74_post.py の出力の 1 行目は status 200 です。2 行目の末尾の req-01.json は、受け手の dir に在ったファイルの名前と同じ文字列でした（COL の側では応答の本文を撮っていません）。p74_post.py の終了コードは撮っていません。宛先は IP アドレスの文字列で、名前解決は撮っていません。

9.2 NAT の変換表と受け手の記録

p74_post.py の実行の次に撮った show ip nat translations は 1 行でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show ip nat translations
Pro  Inside global         Inside local          Outside local         Outside global
tcp  10.7.41.1:5062        192.168.35.2:40400    10.7.41.2:8074        10.7.41.2:8074
Total number of translations: 1

Inside local は 192.168.35.2:40400 で、IP の部分は Guest Shell の eth0 のアドレス（§5.4）です。Inside global は 10.7.41.1:5062 で、IP の部分は Gi2 のアドレスです。Outside local と Outside global は、どちらも 10.7.41.2:8074 でした。

〔ツール側〕受け手の記録（req-01.json）の peer は 10.7.41.1:5062 で、変換表の Inside global と同じ文字列でした。User-Agent は Python-urllib/3.6 です。〔ツール側〕記録の抜粋は以下のとおりです。

{
  "received_utc": "2026-10-19T05:32:59.947242Z",
  "peer": "10.7.41.1:5062",
  "method": "POST",
  "path": "/p74",
  "request_version": "HTTP/1.1",
  "headers": {
    "Accept-Encoding": "identity",
    "Content-Length": "567",
    "Host": "10.7.41.2:8074",
    "User-Agent": "Python-urllib/3.6",
    "Content-Type": "text/plain",
    "Connection": "close"
  },
…（省略）

〔ツール側〕受け手のログと、受け手の dir の一覧は以下のとおりです。

COL $ cat /home/labuser/rx74.log; ls -la /home/labuser/rx74
rx74: listening on 10.7.41.2:8074 -> /home/labuser/rx74
10.7.41.1 - - [19/Oct/2026 05:32:59] "POST /p74 HTTP/1.1" 200 -
rx74: stopped
total 12
drwxrwxr-x 2 labuser labuser 4096 Oct 19 05:32 .
drwxr-x--- 5 labuser labuser 4096 Oct 19 05:32 ..
-rw-rw-r-- 1 labuser labuser 1058 Oct 19 05:32 req-01.json

3 つの文字列を並べると、Inside local 192.168.35.2:40400 → Inside global 10.7.41.1:5062 → 受け手が記録した送信元 10.7.41.1:5062 です。受け手の記録の port（5062）は、Inside local の port（40400）と違う数でした。変換表の行と受け手の記録が同じ TCP の接続のものかは、文字列が同じこと以上は確かめていません（パケットは撮っていません）。受け手の記録の本文は show ip interface brief の 7 行で、Loopback74 と Loopback75 の行を含んでいました。

変換表の次に撮った show ip nat statistics は、§5.2 で撮った statistics と見出しの行を除いて同じでした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
  GigabitEthernet2
Inside interfaces:
  VirtualPortGroup0
Hits: 0  Misses: 0
Expired translations: 0
…（省略）

変換表の Total number of translations の 1 と、statistics の Total active translations の 0・Hits の 0 の関係は確かめていません。

9.3 外への通信の後の確認

§8.4 と同じ確認を p74_post.py の後にも撮りました。section pnp に Mgmt-vrf・GigabitEthernet1 を含む行は 0 行で、show tcp brief all は p74_post.py の前と同じ 5 行でした。8074・10.7.41・192.168.35 を含む行は 0 行です（数えた）。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の show tcp brief all は以下のとおりです。

CSR1# show tcp brief all
TCB       Local Address               Foreign Address             (state)
7F66CA355000  172.16.1.241.22            192.168.1.63.56710          ESTAB
7F66C62542F8  ::.21111                   *.*                         LISTEN
7F6736B2F050  0.0.0.0.21111              *.*                         LISTEN
7F67319F5000  ::.443                     *.*                         LISTEN
7F66C9AD5000  0.0.0.0.443                *.*                         LISTEN

Guest Shell の中（192.168.35.2）の TCP がこの表に載るかは確かめていません。〔ツール側〕受け手を止めた後の COL の経路も、§3.4 と同じでした（unreachable 192.168.35.0/24 の行と、ip route get 192.168.35.2 の No route to host）。Gi2 の COL のほか（Gi1・Mgmt-vrf・本番の LAN・インターネット）への通信は試していません。

10. disable / destroy / no iox で残るもの

資料は、disable は Guest Shell を止めて無効にし、destroy は flash から rootfs を消して、ファイル・データ・入れたアプリケーション・自作の Python の道具を戻せない形で消すと書いています（§2.5）。IOx を外した時については、Guest Shell へのアクセスは無くなるが rootfs は影響を受けないと書いています。

Removing IOx removes access to the Guest Shell, but the rootfs remains unaffected.

（Guest Shell 章「Managing the Guest Shell」の Before you begin）

本ラボでは、Guest Shell の bash から印のファイルを書き、disable・destroy・no iox の後に cat で読みました。印の中身は bash の算術（$((6*7)) など）で作り、送った行に完成形の文字列（42・48・77）が現れないようにしました。

10.1 印の書き込み

home の印（/home/guestshell/p74-home-marker.txt）を書いた行は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB の Guest Shell の bash）。

[guestshell@guestshell ~]$ echo p74-home-$((6*7)) > /home/guestshell/p74-home-marker.txt

guest-share の印（/bootflash/guest-share/p74-flash-marker.txt）を書いた行は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB の Guest Shell の bash）。

[guestshell@guestshell ~]$ echo p74-flash-$((6*8)) > /bootflash/guest-share/p74-flash-marker.txt

2 つの echo の行の応答からエコーとプロンプトを除いた残りは 0 行でした（〔ツール側〕取得スクリプトの記録の作り）。

書いた後の ls -la の大きさは、home の印が 12 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

[guestshell@guestshell ~]$ ls -la /home/guestshell/p74-home-marker.txt
-rw-rw-r--. 1 guestshell guestshell 12 Oct 19 05:33 /home/guestshell/p74-home-marker.txt

guest-share の印の大きさは 13 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。この時点では、どちらの印も cat していません。

[guestshell@guestshell ~]$ ls -la /bootflash/guest-share/p74-flash-marker.txt
-rw-rw-r--. 1 guestshell guestshell 13 Oct 19 05:33 /bootflash/guest-share/p74-flash-marker.txt

10.2 disable → enable

guestshell disable の応答は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell disable
Guestshell disabled successfully

disable の後の show app-hosting list は DEPLOYED でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show app-hosting list
App id                                   State
---------------------------------------------------------
guestshell                               DEPLOYED

次の guestshell enable の出力の successfully を含む行は activated から始まり、installed と DEPLOYED を含む行は 0 行でした（数えた。CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell enable
Interface will be selected if configured in app-hosting
Please wait for completion
guestshell activated successfully
Current state is: ACTIVATED
guestshell started successfully
Current state is: RUNNING
Guestshell enabled successfully

enable の後の show app-hosting list は RUNNING でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show clock
*05:34:00.042 UTC Mon Oct 19 2026
CSR1# show app-hosting list
App id                                   State
---------------------------------------------------------
guestshell                               RUNNING

home の印の cat は p74-home-42 を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run cat /home/guestshell/p74-home-marker.txt
p74-home-42

guest-share の印の cat は p74-flash-48 を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run cat /bootflash/guest-share/p74-flash-marker.txt
p74-flash-48

disable の間（DEPLOYED の間）に guestshell run を打った応答と、disable の後の dir bootflash:guest-share/ は撮っていません。

10.3 destroy → enable

guestshell destroy の応答は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell destroy
Guestshell destroyed successfully

destroy の後の show app-hosting list は No App found でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show app-hosting list
No App found

destroy の後の dir bootflash:guest-share/ には、guest-share の印と 3 本のスクリプトの 4 本が残っていました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# dir bootflash:guest-share/
Directory of bootflash:guest-share/

112901  -rw-               13  Oct 19 2026 05:33:31 +00:00  p74-flash-marker.txt
112900  -rw-              497  Oct 19 2026 05:32:08 +00:00  p74_post.py
112899  -rw-              719  Oct 19 2026 05:32:06 +00:00  p74_conf.py
112898  -rw-              318  Oct 19 2026 05:32:04 +00:00  p74_show.py

6286540800 bytes total (5435736064 bytes free)

次の guestshell enable の出力の successfully を含む行は installed から始まり、最初の enable（§5.3）と全行が同じでした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell enable
Interface will be selected if configured in app-hosting
Please wait for completion
guestshell installed successfully
Current state is: DEPLOYED
guestshell activated successfully
Current state is: ACTIVATED
guestshell started successfully
Current state is: RUNNING
Guestshell enabled successfully

05:36:05.163 の show app-hosting list は RUNNING でした。この後の home の印の cat は、ファイルが無いという行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run cat /home/guestshell/p74-home-marker.txt
cat: /home/guestshell/p74-home-marker.txt: No such file or directory

guest-share の印の cat は、destroy の後も p74-flash-48 を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run cat /bootflash/guest-share/p74-flash-marker.txt
p74-flash-48

dir bootflash:guest-share/ の空きの表示は、最初の enable の後（空のとき）が 4407930880 bytes free、スクリプトを書いた後が 4406988800、destroy の後が 5435736064、destroy → enable → no iox の後が 4407087104 でした。値を並べるだけで、destroy が消した量とは書きません。

syslog の「Guestshell is up」の行は、disable → enable の後と destroy → enable の後に 1 行ずつ増え、それぞれの show app-hosting list の show clock の 2.265 秒前・2.208 秒前の時刻でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging | include IOX|IM-|GUESTSHELL|APP
*Oct 19 05:23:36.533: %IM-6-IOX_ENABLEMENT: R0/0: ioxman: IOX is ready.
*Oct 19 05:26:57.471: %IM-6-IOX_INST_INFO: R0/0: ioxman: IOX SERVICE guestshell LOG: Guestshell is up at 09/19/2026 05:26:57
*Oct 19 05:33:57.777: %IM-6-IOX_INST_INFO: R0/0: ioxman: IOX SERVICE guestshell LOG: Guestshell is up at 09/19/2026 05:33:57
*Oct 19 05:36:02.955: %IM-6-IOX_INST_INFO: R0/0: ioxman: IOX SERVICE guestshell LOG: Guestshell is up at 09/19/2026 05:36:02

disable と destroy を打った時刻は撮っていません。最後に撮った show logging のバッファで disable・destroy の語を含む行は、起動時の LOG_CONFIG_CHANGE の 1 行（xml disabled の語）だけで（数えた）、この数を disable・destroy の性質としては読みません。

10.4 rootfs の印と no iox

destroy → enable の後の bash で、home に rootfs の印（/home/guestshell/p74-rootfs-marker.txt）を書きました（CSR1 csr1000v 17.03.08a・RAM 4096 MB の Guest Shell の bash）。

[guestshell@guestshell ~]$ echo p74-home-$((7*11)) > /home/guestshell/p74-rootfs-marker.txt

ls -la の大きさは 12 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。この印は、ここでは cat していません。

[guestshell@guestshell ~]$ ls -la /home/guestshell/p74-rootfs-marker.txt
-rw-rw-r--. 1 guestshell guestshell 12 Oct 19 05:36 /home/guestshell/p74-rootfs-marker.txt

no iox の投入のエコーは以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
CSR1(config)#no iox
CSR1(config)#end
CSR1#

直後の show iox-service は、3 行とも Running を表示しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show iox-service

IOx Infrastructure Summary:
---------------------------
IOx service (CAF) 1.11.0.7     : Running
IOx service (HA)               : Not Supported
IOx service (IOxman)           : Running
IOx service (Sec storage)      : Not Supported
Libvirtd 1.3.4                 : Running

同じ時の show app-hosting list は Internal error の行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show app-hosting list
% Internal error: Connection to peer process lost

guestshell run id は、iox を入れる前の guestshell enable（§4.1）と同じ文字列の行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run id
 iox feature is not enabled

dir bootflash:guest-share/ には、4 本が残っていました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# dir bootflash:guest-share/
Directory of bootflash:guest-share/

112901  -rw-               13  Oct 19 2026 05:33:31 +00:00  p74-flash-marker.txt
112900  -rw-              497  Oct 19 2026 05:32:08 +00:00  p74_post.py
112899  -rw-              719  Oct 19 2026 05:32:06 +00:00  p74_conf.py
112898  -rw-              318  Oct 19 2026 05:32:04 +00:00  p74_show.py

6286540800 bytes total (4407087104 bytes free)

syslog の「Server iox has been notified to stop」の行は 05:36:43.173 で、最後に撮った show logging の no iox の設定変更の記録の行（05:36:42.640）の 0.533 秒後でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging | include UICFGEXP|IM-
*Oct 19 05:23:16.897: %UICFGEXP-6-SERVER_NOTIFIED_START: R0/0: psd: Server iox has been notified to start
*Oct 19 05:23:36.533: %IM-6-IOX_ENABLEMENT: R0/0: ioxman: IOX is ready.
*Oct 19 05:26:57.471: %IM-6-IOX_INST_INFO: R0/0: ioxman: IOX SERVICE guestshell LOG: Guestshell is up at 09/19/2026 05:26:57
*Oct 19 05:33:57.777: %IM-6-IOX_INST_INFO: R0/0: ioxman: IOX SERVICE guestshell LOG: Guestshell is up at 09/19/2026 05:33:57
*Oct 19 05:36:02.955: %IM-6-IOX_INST_INFO: R0/0: ioxman: IOX SERVICE guestshell LOG: Guestshell is up at 09/19/2026 05:36:02
*Oct 19 05:36:43.173: %UICFGEXP-6-SERVER_NOTIFIED_STOP: R0/0: psd: Server iox has been notified to stop

10.5 iox を戻した後

iox を戻した投入のエコーは以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
CSR1(config)#iox
CSR1(config)#end
CSR1#

本ラボは iox を戻した後、enable は打たずに show iox-service を 64 回撮りました。IOxman は 64 回とも Not Ready でした。1 回目（05:37:09.728）は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show clock
*05:37:09.728 UTC Mon Oct 19 2026
CSR1# show iox-service

IOx Infrastructure Summary:
---------------------------
IOx service (CAF) 1.11.0.7     : Running
IOx service (HA)               : Not Supported
IOx service (IOxman)           : Not Ready
IOx service (Sec storage)      : Not Supported
Libvirtd 1.3.4                 : Running

64 本の出力は、show clock の行を除いた中身が同じでした。64 回目（05:52:17.713）の show clock と IOxman の行は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show clock
*05:52:17.713 UTC Mon Oct 19 2026
CSR1# show iox-service
…（省略）
IOx service (IOxman)           : Not Ready
…（省略）

IOxman の Not Ready は、最初の iox の 1 回目の Not Running（§4.2）とは違う文字列です。続けて show app-hosting list を 64 回撮り、64 回とも not responding の文字列でした。1 回目（05:52:22.090）は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show clock
*05:52:22.090 UTC Mon Oct 19 2026
CSR1# show app-hosting list
The process for the command is not responding or is otherwise unavailable

64 回目（06:07:30.092）も同じ文字列でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show clock
*06:07:30.092 UTC Mon Oct 19 2026
CSR1# show app-hosting list
The process for the command is not responding or is otherwise unavailable

この文字列は、iox を入れる前の show app-hosting list（§4.1）と同じです。guestshell run id は、not responding の行と disabled state の行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run id
The process for the command is not responding or is otherwise unavailable

Error, guestshell is in disabled state, execute 'guestshell enable' before attempting this CLI

rootfs の印の cat も、同じ 2 行を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run cat /home/guestshell/p74-rootfs-marker.txt
The process for the command is not responding or is otherwise unavailable

Error, guestshell is in disabled state, execute 'guestshell enable' before attempting this CLI

iox を戻した後の show logging | include UICFGEXP|IM- の行は、START の行（05:37:04.817）の後に「waiting for webservice to be up」の行が 27 行と、INITIALIZATION_FAILED の行が 3 行でした。フィルタの無い最後の show logging では、START の行の後に %SYS-5-CONFIG_I の行（05:37:07.496）もありました。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の show logging | include UICFGEXP|IM- の抜粋は以下のとおりです。

CSR1# show logging | include UICFGEXP|IM-
…（省略）
*Oct 19 05:37:04.817: %UICFGEXP-6-SERVER_NOTIFIED_START: R0/0: psd: Server iox has been notified to start
*Oct 19 05:38:13.237: %IM-5-IOX_NOTICE: R0/0: ioxman: app-hosting: waiting for webservice to be up
…（省略）
*Oct 19 05:46:13.292: %IM-5-IOX_NOTICE: R0/0: ioxman: app-hosting: waiting for webservice to be up
*Oct 19 05:47:13.300: %IM-2-INITIALIZATION_FAILED: R0/0: ioxman: Initialization of CAF webservices failed for IOx Manager -Traceback= 1#a52da9b69279044a950689c3e4c13eda   errmsg:7FD9575B3000+D20 :555D9E0CE000+2A526 :555D9E0CE000+525AD :555D9E0CE000+507AC c:7FD942D2B000+240FD :555D9E0CE000+1764A
*Oct 19 05:48:16.692: %IM-5-IOX_NOTICE: R0/0: ioxman: app-hosting: waiting for webservice to be up
…（省略）
*Oct 19 06:06:19.829: %IM-5-IOX_NOTICE: R0/0: ioxman: app-hosting: waiting for webservice to be up
*Oct 19 06:07:19.838: %IM-2-INITIALIZATION_FAILED: R0/0: ioxman: Initialization of CAF webservices failed for IOx Manager -Traceback= 1#a52da9b69279044a950689c3e4c13eda   errmsg:7F8837904000+D20 :56336A35D000+2A526 :56336A35D000+525AD :56336A35D000+507AC c:7F882307C000+240FD :56336A35D000+1764A

waiting の行は 60.006〜60.008 秒の間隔で 9 行ずつ並び、9 行の後に INITIALIZATION_FAILED の行が 1 行ずつ出ました（3 行の間隔は 603.457 秒と 603.081 秒）。START の行（05:37:04.817）の後に「IOX is ready.」と「Guestshell is up」を含む行は、どちらも 0 行でした（数えた）。

show iox-service の 64 回と show app-hosting list の 64 回は、順に撮りました。show iox-service は 05:37:09.728〜05:52:17.713（907.985 秒）、show app-hosting list は 05:52:22.090〜06:07:30.092（908.002 秒）です。IOxman の Not Ready は前半の約 15 分、not responding は後半の約 15 分に撮った状態で、2 つを同じ時間には撮っていません。

iox の設定変更の記録の行（05:37:04.286）から最後の show app-hosting list までは 1825.806 秒（約 30 分）です。最後の show iox-service より後の IOxman の状態は撮っていません。rootfs の印（77）が no iox → iox の後に残るかは、この run では撮れませんでした（§12.2）。IOx が戻らなかったのは main の run の 1 回の観測で、iox を戻すと毎回こうなるとは言えません。

11. 機器の上と機器の外（7-1〜7-3 との比較）

7-1〜7-3 のプログラムは、どれも機器の外で動きました。NETCONF・RESTCONF・gNMI のクライアントは、機器の外から機器の管理アドレスへ接続を張り、利用者名とパスワードで認証しました。7-3 の CLI で設定した購読（dial-out）では、機器が機器の外の受信器へ接続を張りました。本ラボ（csr1000v 17.03.08a・RAM 4096 MB）の Guest Shell のプログラムと並べると、以下のとおりです。

11.1 スクリプトの本文

スクリプトの本文（heredoc のエコー。§7.2）の 3 本の計 48 行に、password・username・secret・netops・172.16.1.241・localhost・CSR1 のどれかを含む行は 0 行でした（大文字と小文字を区別せずに数えた）。本文に在る IPv4 アドレスの形の文字列は、p74_conf.py の設定の行の 10.7.4.74・255.255.255.255 と、p74_post.py の宛先の 10.7.41.2 の 3 つです。cli の関数の呼び出しは 3 本で計 6 か所（execute 4・cli 1・configure 1）で、引数はどれもコマンドの文字列か、設定の行のリストでした。

スクリプトの本文に資格情報の文字列が無いことと、Guest Shell の中から IOS へ届く経路と権限は別の話です。経路と権限は撮っていません（§12.1）。

11.2 起動した CLI のセッション

p74_show.py・p74_conf.py・p74_post.py は、IOS の CLI で打った guestshell run python3 /bootflash/guest-share/p74_….py で動かしました。〔ツール側〕取得スクリプトは、この CLI に netops で SSH のログインをしています。syslog の LOGIN_SUCCESS の行で user が netops の行は 1 行で（数えた）、以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging
…（省略）
*Oct 19 05:22:32.844: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: netops] [Source: 192.168.1.63] [localport: 22] at 05:22:32 UTC Mon Oct 19 2026
…（省略）

このログインの行の Source（192.168.1.63）は、show users の Location と、show tcp brief all の Foreign Address の IP の部分と同じ文字列です。show users は §3.3 と PnP の 3 点で撮った 4 回で、どれも vty 0 の netops の 1 行でした。show tcp brief all の 172.16.1.241.22 の行は、撮った 6 回とも同じ TCB（7F66CA355000）でした。

p74_show.py の実行中にスクリプトが撮った show users（§7.3）も、vty 0 の netops の 1 行でした。ほかの guestshell run の時点の vty は撮っていません。netops のログインの行が 1 行で TCB も 6 回とも同じなので、§3 と図では guestshell run を打った CLI を vty 0 と書いています。

11.3 privilege 1 の利用者

資料（Guest Shell 章）は、Guest Shell へのアクセスを IOS の最高の特権（15）の利用者に限り、Guest Shell 経由のコマンドは IOS の端末にログインした利用者と同じ特権で動くと書いています。

During the Guest Shell installation, SSH access is setup with a key-based authentication. The access to the Guest Shell is restricted to the user with the highest privilege (15) in Cisco IOS. This user is granted access into the Linux container as the guestshell Linux user, who is a sudoer, and can perform all root operations. Commands executed through the Guest Shell are executed with the same privilege that a user has when logged into the Cisco IOS terminal.

（Guest Shell 章「Accessing Guest Shell on a Device」）

本ラボでは、privilege 1 の利用者 viewer で SSH のログインをし、show privilege と guestshell run id を打ちました。viewer の show privilege は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1> show privilege
Current privilege level is 1

viewer が打った guestshell run id の応答は以下のとおりで、uid= を含む行は 0 行でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1> guestshell run id
     ^
% Invalid input detected at '^' marker.

同じ guestshell run id を netops の CLI で打った時の応答（§6.1）は、uid=1000(guestshell) の行でした。viewer の応答の ^ が入力のどの文字を指すかは、保存した出力からは言えません。viewer のログインとログアウトの syslog の行は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# show logging
…（省略）
*Oct 19 05:33:15.537: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: viewer] [Source: 192.168.1.63] [localport: 22] at 05:33:15 UTC Mon Oct 19 2026
*Oct 19 05:33:25.905: %SYS-6-LOGOUT: User viewer has exited tty session 2(192.168.1.63)
…（省略）

Guest Shell の中で動く処理の権限と、guestshell run を打った IOS の利用者の権限の関係（資料の文が書く話）は撮っていません（§12.1）。

11.4 接続の向きと設定変更の記録

接続の向きは §9 のとおりで、Guest Shell のプログラムの通信は、機器の中の 192.168.35.2 から VirtualPortGroup0 と NAT を通り、Gi2 の 10.7.41.1 を送信元として COL の受け手に届きました（変換表と受け手の記録の文字列）。設定変更の記録では、Guest Shell の cli.configure の変更の user@line が netops@vty116、vty 0 からの変更が netops@vty0 でした（§8.2）。

12. 本ラボで確かめていないこと

本ラボの実測は、main の run と lowmem の run の 1 回ずつの撮影です。以下は観測していません。各項目の末尾に、関係する節を書きます。

12.1 撮らなかったもの

• yum・dnf・pip による外部からの取得と名前解決。resolv.conf に nameserver の行は 0 行で、name-server も設定していません（§3・§6.7）
• Sample VirtualPortGroup Configuration の見本の NAT の行（ip nat outside source list … interface … overload）がこの版で受理されるかと、変換の向き。本ラボは inside source list の形だけを投入しました（§13.9）
• AppGigabitEthernet と管理 IF（mgmt-if）の形。Guest Shell 章は、これらを Catalyst のスイッチの手順としています。本ラボは VirtualPortGroup の形だけを使いました（§3）
• Day Zero のプロビジョニング・Guest Shell Lite・スタック。Day Zero は 7-6 の範囲です
• Guest Shell の中の権限（sudo の可否・wheel・network-admin の group で何ができるか）と、IOS の権限の継承（§11.3 の資料の文が書く話）。IOS の利用者と Guest Shell の中の利用者（guestshell）の対応も撮っていません（§6.1・§11.3）
• cli モジュールが Guest Shell の中から IOS へ届く経路と認証。df の /cisco/.iosp_socket（§6.4）と、二重引用符の形のエラーの行に見えた環境変数の名前（§12.2）は並べるだけで、経路の根拠にしません
• cli.configure が例外を上げた時に、同じリストのほかの行が running-config に反映されるか。設定変更の記録には INVALID の 1 行目（interface Loopback74）が残りました（§8.2）。その行は既に在る Loopback74 を選ぶ行で、running-config で反映の有無を区別できる行は入れていません（§7.4）
• pnp_python が何のための profile か（§8.3）
• EEM の Python のポリシー。資料の文を §15 に引いただけで、本ラボでは動かしていません
• COL のほかへの通信（Gi1・Mgmt-vrf・本番の LAN・インターネット）と、https・UDP・ICMP。Guest Shell と VirtualPortGroup0 の間・CSR1 と COL の間のパケットも撮っていません（§9）
• 192.168.1.5・192.168.1.6・192.168.1.63 が何か（§3.3・§7.3）と、vty116 が何の line か（§8.2）
• 同じ手順を繰り返した時に同じ値になるか。main の run の 1 回分からは言えません

12.2 撮れなかったもの

• no iox → iox の後に rootfs が残るか。iox を戻した後、前半の約 15 分の show iox-service（64 回）で IOxman は Not Ready、後半の約 15 分の show app-hosting list（64 回）は not responding で、rootfs の印（77）の cat は disabled state の行を返しました。enable を打った時の応答も撮っていません（§10.5）
• guestshell run python3 -c の引用符の 3 形のうち 2 形。二重引用符と単一引用符の形では、この撮影で 42 が出ませんでした（各形は 1 回ずつ）。42 が出た引用符なしの形は §13.14 にあります

二重引用符の形は、bash の syntax error の 2 行を返しました。2 行目の env の後ろの引数は長いので省略しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB の生の受信。エコーの行・出力・プロンプトの行）。

guestshell run python3 -c "print(6*7)"
bash: -c: line 0: syntax error near unexpected token `('
…（省略）

CSR1#

省略した 2 行目の env の後ろには、「名前=値」の形の引数が 15 個並んでいました（名前が SHELL_SESSION_ で始まるもの 9 個・IOSP_ で始まるもの 5 個・TERM）。何に使われるかは確かめていません。単一引用符の形は、エコーの行の次がプロンプトの行で、間の行は 0 行でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB の生の受信）。

guestshell run python3 -c 'print(6*7)'
CSR1#

12.3 RAM 3072 MB の run で撮っていないもの

lowmem の run（RAM 3072 MB）で撮ったのは、版と物理メモリ・IOx の有効化・通信路・Guest Shell の有効化と状態・python3 -V・os-release・p74_show.py の系統だけです。iox の前の応答・PnP の profile・設定変更の記録・cli.configure・外への通信・privilege 1 の利用者・disable と destroy・no iox は、RAM 3072 MB では撮っていません（§13.2）。

13. 落とし穴・補足

13.1 予約の 256 MB と Table 3 の 512 MB

Table 3 の Memory の行は、既定を 256 MB とし、CSR1000v を 512 MB としています（§2.4）。本ラボの CSR1000v の予約は 256 MB でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB と RAM 3072 MB の両方・§5.4・§13.2）。show app-hosting detail の Activated profile name は custom で、この profile の中身と由来は撮っていません。両方を並べ、どちらが正しいとも、何が原因とも書きません。

13.2 Table 2 の 4 GB と CML の既定の 3072 MB

Table 2 は CSR1000v の最低メモリを 4 GB としています（§2.4）。〔ツール側〕CML の csr1000v の node definition の RAM は 3072 MB で、main の run はこれを 4096 MB に上書きして撮りました。同じ版を 3072 MB のまま起動した lowmem の run（COL なし・別のラボ）でも、撮った系統を並べます。以下は、この環境（CML の csr1000v 17.03.08a・RAM 3072 MB）で見た挙動で、4 GB 未満の対応を意味しません。

〔ツール側〕CML の API で読み返した、lowmem の run の CSR1 の ram の値は以下のとおりです。

3072

lowmem の run の CSR1（csr1000v 17.03.08a・RAM 3072 MB）の show version の物理メモリの行は 3012036K でした。

CSR1# show version
Cisco IOS XE Software, Version 17.03.08a
…（省略）
cisco CSR1000V (VXE) processor (revision VXE) with 1104920K/3075K bytes of memory.
Processor board ID 9IGFJEKOAED
Router operating mode: Autonomous
2 Gigabit Ethernet interfaces
32768K bytes of non-volatile configuration memory.
3012036K bytes of physical memory.
…（省略）

iox の投入の後の 1 回目の show iox-service（06:12:03.230）で、3 行とも Running でした。CSR1（csr1000v 17.03.08a・RAM 3072 MB）の表示は以下のとおりです。

CSR1# show clock
*06:12:03.230 UTC Mon Oct 19 2026
CSR1# show iox-service

IOx Infrastructure Summary:
---------------------------
IOx service (CAF) 1.11.0.7     : Running
IOx service (HA)               : Not Supported
IOx service (IOxman)           : Running
IOx service (Sec storage)      : Not Supported
Libvirtd 1.3.4                 : Running

同じ run の show logging | include IOX|IM-|UICFGEXP は以下のとおりです（csr1000v 17.03.08a・RAM 3072 MB）。

CSR1# show logging | include IOX|IM-|UICFGEXP
*Oct 19 06:11:24.184: %IOXN_APP-6-PRE_INIT_DAY0_GS_INFO: Day0 Guestshell pre-initilization API is being invoked
*Oct 19 06:11:24.799: %UICFGEXP-6-SERVER_NOTIFIED_START: R0/0: psd: Server iox has been notified to start
*Oct 19 06:11:39.220: %IOXN_APP-6-PRE_INIT_DAY0_GS_INFO: Day0 Guestshell de-initilization API is being invoked
*Oct 19 06:11:56.755: %IM-6-IOX_ENABLEMENT: R0/0: ioxman: IOX is ready.
*Oct 19 06:11:58.187: %IOXN_APP-6-PRE_INIT_DAY0_GS_INFO: Day0 Guestshell destroyed

%IOXN_APP で始まるタグの行は、この出力に 3 行ありました。main の run で撮った出力には、最後の show logging の全体を含めて 0 行です（数えた）。

出力の 1〜3 行目（06:11:24.184・06:11:24.799・06:11:39.220）は、L0 の show clock（06:11:53.386）より前の時刻です。取得の順（〔ツール側〕）では、iox の投入は L0 の show clock より後なので、この 3 行は iox の投入より前の行です。その時点の show iox-service と running-config は撮っていません。行の文言（綴りは出力のまま）が何を指すかは確かめていません。

guestshell enable の出力は main の run と全行が同じで、予約の Memory は 256 MB、resource の Memory は Quota 1024(MB)・Available 768(MB) で、どれも main の run と同じ文字列でした。CSR1（csr1000v 17.03.08a・RAM 3072 MB）の show app-hosting detail の抜粋は以下のとおりです。

CSR1# show app-hosting detail appid guestshell
App id                 : guestshell
Owner                  : iox
State                  : RUNNING
Application
  Type                 : lxc
  Name                 : GuestShell
  Version              : 3.1.0
  Description          : Cisco Systems Guest Shell XE for x86_64
  Path                 : /guestshell/:guestshell.tar
  URL Path             :
Activated profile name : custom

Resource reservation
  Memory               : 256 MB
  Disk                 : 1 MB
  CPU                  : 800 units
  VCPU                 : 1
…（省略）
eth0:
   MAC address         : 52:54:dd:47:6b:8c
   IPv4 address        : 192.168.35.2
   Network name        : VPG0
…（省略）

Guest Shell の中の python3 -V は Python 3.6.8 で、p74_show.py の cli.execute と cli.cli も show の表示を返しました。CSR1（csr1000v 17.03.08a・RAM 3072 MB）の p74_show.py の出力の抜粋は以下のとおりです。

CSR1# guestshell run python3 /bootflash/guest-share/p74_show.py
== cli.execute show clock
*06:16:11.360 UTC Mon Oct 19 2026
…（省略）
== cli.execute show users
    Line       User       Host(s)              Idle       Location
   2 vty 1     netops     192.168.1.5          00:00:02 192.168.1.63
  Interface    User               Mode         Idle     Peer Address
…（省略）

main の run と違ったのは、show version の 3 行（processor・Processor board ID・物理メモリ）、syslog の %IOXN_APP の行と時刻、Gi2 の行と経路表の 10.0.0.0 の段（lowmem の run は COL が無い構成）、MAC address でした。Storage space の Available、Memory Used、show users の vty の番号と Idle、show tcp brief all の行の順と port と TCB、時刻も違いました。iox の後の 1 回目の show iox-service も違い、main の run は IOxman が Not Running で Libvirtd の行に版の数字が無く、lowmem の run は IOxman が Running で Libvirtd 1.3.4 でした。lowmem の run の START の行は、上の syslog のとおり iox の投入より前の時刻です。

2 つの run は RAM のほかに、ラボ・撮った時刻・COL の有無も違い、どの違いがどの行に関わるかを分ける撮り方をしていません。差の原因は確かめていません。

lowmem の run の出力は、この環境で見た挙動で、4 GB 未満の対応を意味しません。

13.3 cli.configure の戻り値

Python API 章の help(configure) は、戻り値を list(ConfigResult) と書いています。資料のこの出力は、guestshell run python と Python 2.7.5 の起動の表示の後に置かれています。

Args: configuration (str or iterable): Configuration commands, separated by newlines. Returns: list(ConfigResult): A list of results, one for each line. Raises: CLISyntaxError: If there is a syntax error in the configuration.

（Python API 章「Cisco Python Module」の help(configure)）

cli.configure の説明は named tuple の list を返すと書き、見本は ConfigResult の list を示しています。

cli.configure(command) —This function configures the device with the configuration available in commands. It returns a list of named tuples that contains the command and its result as shown below: [Think: result = (bool(success), original_command, error_information)]

（Python API 章「Cisco Python Module to Execute IOS CLI Commands」）

>>>cli.configure([“interface GigabitEthernet1/0/7”, “no shutdown”, “end”]) [ConfigResult(success=True, command=‘interface GigabitEthernet1/0/7’, line=1, output=’’, notes=None), ConfigResult(success=True, command=‘no shutdown’, line=2, output=’’, notes=None), ConfigResult(success=True, command=‘end’, line=3, output=’’, notes=None)]

（Python API 章「Cisco Python Module to Execute IOS CLI Commands」の見本）

同じ章の cli.configurep の説明は、cli.configure と同じ働きで、結果の文字列を返す代わりに stdout へ表示すると書き、見本の表示は Line 1 SUCCESS から Line 3 SUCCESS の行です。

cli.configurep(command) —This function works exactly the same as the cli.configure(command) function, except that it prints the resulting text to stdout rather than returning it. The following is sample output from the cli.configurep(command) function:

（Python API 章「Cisco Python Module to Execute IOS CLI Commands」）

>>> cli.configurep([“interface GigabitEthernet1/0/7”, “no shutdown”, “end”]) Line 1 SUCCESS: interface GigabitEthernet1/0/7 Line 2 SUCCESS: no shut Line 3 SUCCESS: end

（Python API 章「Cisco Python Module to Execute IOS CLI Commands」の見本）

本ラボの cli.configure は str を返し、値は Line 1 SUCCESS: から Line 3 SUCCESS: で始まる 3 行が、それぞれの後ろに改行を付けて 1 つの文字列になったものでした（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§7.4）。行の形は、資料の configurep の見本の表示の行と同じ形です。両方を並べ、どちらが正しいとも、何が原因とも書きません。見本を撮った機器の機種と版は書かれていません。

13.4 例外の名前

資料が挙げる例外の名前は、help(configure) と help(execute) の Raises の欄の CLISyntaxError、help(configure) の使い方の例の except 節の CLIConfigurationError、help(cli) の Raises の欄の errors.cli_syntax_error と errors.cli_exec_error です。help(configure) の使い方の例は以下のとおりです。

configuration = ‘‘‘interface gigabitEthernet 0/0 no shutdown’’’ # push it through the Cisco IOS CLI. try: results = cli.configure(configuration) print “Success!” except CLIConfigurationError as e: print “Failed configurations:” for failure in e.failed: print failure

（Python API 章「Cisco Python Module」の help(configure)）

本ラボで INVALID の呼び出しが上げた例外の型の名前は IOSPCLIConfError でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§7.4）。p74_conf.py の出力に ConfigResult・CLIConfigurationError・CLISyntaxError・cli_syntax_error を含む行は 0 行です（数えた）。IOSPCLIConfError のクラスが在るモジュールと継承は撮っていません。

13.5 Python 2.7 の記述と実機

CLI Python Module 章は、IOS XE の機器が Guest Shell の中で Python Version 2.7 を支えると書いています。

The Cisco IOS XE devices support Python Version 2.7 in both interactive and non-interactive (script) modes within the Guest Shell. The Python scripting capability gives programmatic access to a device’s CLI to perform various tasks and Zero Touch Provisioning or Embedded Event Manager (EEM) actions.

（CLI Python Module 章「About Python」）

同じ章は、Guest Shell に Python 2.7 が入っていると書いています。

Guest Shell is pre-installed with Python Version 2.7. Guest Shell is a virtualized Linux-based environment, designed to run custom Linux applications, including Python applications for automated control and management of Cisco devices. Platforms with Montavista CGE7 support Python Version 2.7.11, and platforms with CentOS 7 support Python Version 2.7.5.

（CLI Python Module 章「Supported Python Versions」）

同じ章の注は、Python 2 と 3 が併存する時の guestshell run python を Python Version 2 と書いています。

When you update to Python Version 3 on a device that already has Python Version 2, both versions of Python exist on the device. Use one of the following IOS commands to run Python: The guestshell run python2 command enables Python Version 2. The guestshell run python3 command enables Python Version 3. The guestshell run python command enables Python Version 2.

（CLI Python Module 章「Updating the Cisco CLI Python Module」）

同じ章の Table 1 の Python Version 3.6 の行は、17.3.1 以降は Python V3 が既定と書いています。

In Cisco IOS XE Amsterdam 17.1.1 and Cisco IOS XE Amsterdam 17.2.1, Python V2 is the default. However, in Cisco IOS XE Amsterdam 17.3.1 and later releases, Python V3 is the default.

（CLI Python Module 章「Table 1. Python Version Support」）

Guest Shell 章の Table 1 は、Python 2.7 の行を次のように書いています。

Python 2.7 Supported till Cisco IOS XE Amsterdam 17.3.1

（Guest Shell 章「Table 1. Guest Shell Software Requirements」）

同じ Guest Shell 章の 17.3.1 以降の節は、Python は V3.6 だけとし、guestshell run python3 で Python 3.6.8 を表示する見本を載せています。

The following example shows how to enable Guest Shell. In Cisco IOS XE Amsterdam 17.3.1 and later releases, only Python V3.6 is supported.

（Guest Shell 章「Example: Managing the Guest Shell」）

In Cisco IOS XE Amsterdam 17.3.1 and Later Releases The following example shows how to enable Python on Cisco Catalyst 9000 Series Switches: Device# guestshell run python3 Python 3.6.8 (default, Nov 21 2019, 22:10:21) [GCC 8.3.1 20190507 (Red Hat 8.3.1-4)] on linux

（Guest Shell 章「Accessing the Python Interpreter」の 17.3.1 以降の見本）

本ラボの Guest Shell の python3 は Python 3.6.8 で、python と python2 は env: で始まる行を返し、/usr/bin の直下の find の出力に python2 を含む行は 0 行でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§6.2）。版の数字 3.6.8 は、Guest Shell 章の 17.3.1 以降の見本と同じです。

CLI Python Module 章の対話の Python の見本は、guestshell run python を打って Python 2.7.5 を表示しています。

The following example shows how to enable the interactive Python prompt: Device# guestshell run python Python 2.7.5 (default, Jun 17 2014, 18:11:42) [GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] on linux2

（CLI Python Module 章「Interactive Python Prompt」）

Guest Shell 章の §5.1 の見本（16.7.1 以降の手順）と §13.9 の見本（版の条件なし）は、末尾が guestshell run python です。資料の中の版による書き分けと本ラボの表示を並べ、どちらが正しいとも書きません。

13.6 show iox-service の 2 つの見本と実機

Guest Shell 章の show iox-service の見本には Dockerd の行があり、HA は Running、Sec storage は Not Running です。

The following is sample output from the show iox-service command: Device# show iox-service IOx Infrastructure Summary: ————————— IOx service (CAF) 1.10.0.0 : Running IOx service (HA) : Running IOx service (IOxman) : Running IOx service (Sec storage) : Not Running Libvirtd 1.3.4 : Running Dockerd 18.03.0 : Running Application DB Sync Info : Available Sync Status : Disabled

（Guest Shell 章「Managing IOx」）

Application Hosting 章の見本も Dockerd の行を持ち、どのサービスも Not Running の形です（Libvirtd だけ Running）。

show iox-service Displays the status of all the Cisco IOx services. Example: Device# show iox-service IOx Infrastructure Summary: ————————— IOx service (CAF) : Not Running IOx service (HA) : Not Running IOx service (IOxman) : Not Running IOx service (Sec storage) : Not Running Libvirtd : Running Dockerd : Not Running Application DB Sync Info : Not available

（Application Hosting 章「Verifying the Application-Hosting Configuration」）

本ラボの show iox-service に Dockerd の行は、iox の前・iox の後の 2 回・no iox の後・iox を戻した後の 64 回のどれも 0 行で、HA と Sec storage は Not Supported でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§4・§10）。見本はどちらも機種と版を書いていません。

13.7 destroy の資料の文と guest-share

資料は、destroy が rootfs を消し、すべてのファイル・データ・入れたアプリケーション・自作の Python の道具が消えて戻せないと書いています（§2.5）。本ラボの destroy → enable の後、home の印の cat はファイルが無いという行でしたが、/bootflash/guest-share/ の印は p74-flash-48 を返し、3 本のスクリプトも dir bootflash:guest-share/ に残っていました（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§10.3）。§6.4 の df では、/ が /dev/loop3、/bootflash/guest-share が /dev/vda11 で、別のデバイスでした。/home/guestshell のほかのファイルと、Guest Shell の中に入れたパッケージがどうなるかは撮っていません。

13.8 管理 VRF と「not VRF-aware」

Guest Shell 章の Managing the Guest Shell の Step 2 の注は、guestshell enable がネットワークに管理 VRF を使うと書いています。

The guestshell enable command uses the management virtual routing and forwarding (VRF) instance for networking.

（Guest Shell 章「Managing the Guest Shell」の Step 2 の注）

同じ注は続けて、前面のポートのネットワークに VirtualPortGroup を使う時は、その VPG を先に設定すると書いています。

When using VirtualPortGroups (VPGs) for front panel networking, the VPG must be configured first. The guest IP address and the gateway IP address must be in the same subnet.

（Guest Shell 章「Managing the Guest Shell」の Step 2 の注）

同じ章の Accessing Guest Shell Through the Management Port の注は、管理ポートの無い機種では VirtualPortGroup を Guest Shell に結び付けられると書いています。

For platforms without a management port, a VirtualPortGroup can be associated with Guest Shell in the Cisco IOS configuration. For more information, see the Sample VirtualPortGroup Configuration section.

（Guest Shell 章「Accessing Guest Shell Through the Management Port」の注）

同じ章の Managing the Guest Shell Using Application Hosting の注は、Managing the Guest Shell の手順を Everest 16.6.x 以前の版のためのものとしています。

Use this procedure (Managing the Guest Shell Using Application Hosting) to enable the Guest Shell in Cisco IOS XE Fuji 16.7.1 and later releases. For Cisco IOS XE Everest 16.6.x and previous releases, use the procedure in Managing the Guest Shell.

（Guest Shell 章「Managing the Guest Shell Using Application Hosting」の注）

Application Hosting 章の Restrictions は、application hosting を VRF-aware でないと書いています。

Application hosting is not virtual routing and forwarding aware (VRF-aware).

（Application Hosting 章「Restrictions for Application Hosting」）

同じ Application Hosting 章の冒頭の注は、application hosting が扱うのを Docker のアプリケーションだけとしています。

Application hosting supports only Docker application.

（Application Hosting 章の冒頭の注）

本ラボは VirtualPortGroup0 と NAT を global に置く設計で（§3）、Guest Shell の通信は global の Gi2 から COL へ出ました。Mgmt-vrf の経路表は、投入の前と後で同じでした（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§5.2）。本ラボの Mgmt-vrf は、day0 で設定した VRF の名前です（§3）。Mgmt-vrf を使う形は撮っていません。

13.9 VirtualPortGroup と NAT の 2 つの見本の形

§5.1 の 2 つの見本は、NAT の行の形が違います。Managing the Guest Shell Using Application Hosting の例は ip nat inside source list GS_NAT_ACL interface GigabitEthernet1 overload、Sample VirtualPortGroup Configuration の見本は ip nat outside source list NAT_ACL interface GigabitEthernet 0/0/3 overload で、後者は静的経路 2 本と、SSH などの port の転送（ip nat inside source static tcp …）も持ちます。

app-hosting の行も 2 つの見本で違います。前者には app-default-gateway の行があり、後者の app-hosting の部分には無く、後者は app-resource profile custom で cpu と memory を指定しています。

! App-hosting configuration Device(config)# app-hosting appid guestshell Device(config-app-hosting)# app-vnic gateway1 virtualportgroup 0 guest-interface 0 Device(config-app-hosting-gateway)# guest-ipaddress 192.168.35.2 netmask 255.255.255.0 Device(config-app-hosting-gateway)# exit Device(config-app-hosting)# app-resource profile custom Device(config-app-resource-profile-custom)# cpu 1500 Device(config-app-resource-profile-custom)# memory 512 Device(config-app-resource-profile-custom)# end Device# guestshell enable Device# guestshell run python

（Guest Shell 章「Sample VirtualPortGroup Configuration」）

本ラボの投入の NAT の行は前者と同じ inside source list の形で、app-hosting には app-default-gateway の行を入れ、app-resource profile の行は入れていません（§5.2）。p74_post.py の後の変換表に、Inside local 192.168.35.2 の行が 1 行ありました（§9.2）。後者の NAT の行は投入していないので、この版で受理されるかと、受理された時にどの向きのアドレスを変換するかは確かめていません（§12.1）。

13.10 カーネルの 2 つの書き方

Guest Shell 章は、Guest Shell Overview で Guest Shell がホストとカーネルを共有すると書いています。

Guest Shell shares the kernel with the host (Cisco switches and routers) system. Users can access the Linux shell of Guest Shell and update scripts and software packages in the container rootfs. However, users within the Guest Shell cannot modify the host file system and processes.

（Guest Shell 章「Guest Shell Overview」）

同じ章の Guest Shell Security は、Guest Shell がホストのカーネルから隔離されていると書いています。

Cisco provides security to ensure that users or apps in the Guest Shell do not compromise the host system. Guest Shell is isolated from the host kernel, and it runs as an unprivileged container.

（Guest Shell 章「Guest Shell Security」）

本ラボの Guest Shell の uname -a は 4.19.279 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§6.1）。IOS XE の側（ホスト）のカーネルの版を出すコマンドは撮っておらず、同じものかは確かめていません。

13.11 「Python Version 3.0」の語

Software Requirements の本文は、Yum で入れられる Python のライブラリの例に「Python Version 3.0」を挙げています。同じ節の Table 1 は、CentOS が対応する Python を 3.6 だけとしています（§2.3）。

You can install other Python libraries such as, Python Version 3.0 during runtime using the Yum utility in CentOS 8.0. You can also install or update python packages using PIP.

（Guest Shell 章「Guest Shell Software Requirements」）

本ラボは yum と pip による外部からの取得を撮っていません（§12.1）。

13.12 見本の uname と実機

Example: Guest Shell Usage の uname -a の見本は、5.4.85 のカーネルです。

[guestshell@guestshell~]$ uname -a Linux guestshell 5.4.85 #1 SMP Tue Dec 22 10:50:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

（Guest Shell 章「Example: Guest Shell Usage」）

本ラボの uname -a は 4.19.279 でした（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§6.1）。見本がどの機種・版のものかは書かれていません。

13.13 Guest Shell の ip のコマンド

本ラボの Guest Shell では、guestshell run ip addr が env: 'ip': No such file or directory を返しました（CSR1 csr1000v 17.03.08a・RAM 4096 MB。§6.6）。IF と経路は /sys/class/net と /proc/net/route で読みました。ifconfig・hostname -I などは撮っていません。

13.14 python3 -c の引用符

guestshell run python3 -c の 3 形のうち、この撮影で 42 が出たのは引用符を付けない形だけでした（各形は 1 回ずつ）。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の生の受信は以下のとおりです（エコーの行・出力・プロンプトの行）。

guestshell run python3 -c print(6*7)
42

CSR1#

二重引用符と単一引用符の形は §12.2 に置きました。3 形の直後に、Guest Shell がこの時点でも応答することの確認として打った guestshell run python3 -V は Python 3.6.8 を返しました。本ラボのスクリプトは、/bootflash/guest-share/ にファイルとして書き、引用符を含まない guestshell run python3 <パス> の行で動かしました（§7）。

13.15 Guest Shell の syslog の日付

Guest Shell の LOG を載せた IOX_INST_INFO の行は、行頭の syslog の時刻が Oct 19、行の中の日付が 09/19/2026 でした（§5.3・§10.3）。show clock の日付は Mon Oct 19 2026 です。CSR1（csr1000v 17.03.08a・RAM 4096 MB）の Guest Shell の最初の run の後の show clock は以下のとおりです。

CSR1# show clock
*05:27:59.275 UTC Mon Oct 19 2026

その次に撮った Guest Shell の中の date -u は以下のとおりです（CSR1 csr1000v 17.03.08a・RAM 4096 MB）。

CSR1# guestshell run date -u
Mon Oct 19 05:28:06 UTC 2026

show clock と date -u の 2 本は別の瞬間に撮ったので、値の差を時計のずれとは書きません。LOG の行の中の日付の月の値が違う理由と、Guest Shell の時計の合わせ方は確かめていません。

14. まとめ

Guest Shell は、IOS XE の機器の上の仮想化された Linux の環境で、IOx が管理します。csr1000v 17.03.08a（RAM 4096 MB）では、iox を入れると 2 回目の show iox-service で CAF・IOxman・Libvirtd の 3 行がそろって Running でした（Libvirtd は iox の前から Running）。「Server iox has been notified to start」から「IOX is ready.」の syslog の行までは 19.636 秒でした。VirtualPortGroup0 と NAT と app-hosting を入れて guestshell enable を打つと、状態は DEPLOYED → ACTIVATED → RUNNING と進み、予約の Memory は 256 MB でした（§4・§5）。

Guest Shell の中は CentOS Linux 8 で、python3 は Python 3.6.8 でした。python・python2・ip は、どれも env: で始まる見つからないという行を返しました。site-packages には cli・eem・pnp のディレクトリがありました（§6）。

cli モジュールは、cli.execute と cli.cli で show の表示を返しました。cli.configure の戻り値は str で、その後の running-config に Loopback74 の設定が入っていました。無効な行を含む呼び出しは IOSPCLIConfError を上げました。資料の list(ConfigResult) と例外の名前とは違う表示です（§7・§13.3・§13.4）。

設定変更の記録では、Guest Shell の変更の user@line が netops@vty116、vty 0 からの変更が netops@vty0 でした。PnP の profile の pnp_python は、最初の guestshell run の後の 3 点目に初めて載り、syslog の PNP_PROFILE_CREATED の行は 05:27:38.843 でした（§8）。Guest Shell の p74_post.py の POST は、NAT の変換表の Inside global 10.7.41.1:5062 と同じ送信元で COL の受け手に記録されました（§9）。

disable → enable の後は home と guest-share の印がどちらも cat で読め、destroy → enable の後は home の印の cat がファイルが無いという行を返し、guest-share の印とスクリプトは残りました。no iox の後も guest-share の 4 本は残り、iox を戻した後は IOxman が 64 回とも Not Ready で（main の run の 1 回の観測）、rootfs の印が残るかは撮れませんでした（§10）。スクリプトの本文に CSR1 への接続先・利用者名・パスワードの文字列は無く、起動は netops の CLI の guestshell run で、privilege 1 の viewer の guestshell run id は % Invalid input の行を返しました（§11）。確かめていないことは §12 にまとめてあります。

15. 次節（7-5 Embedded Event Manager（EEM））

本節のプログラムは、IOS の CLI で打った guestshell run で起動しました。次節 7-5 は、EEM を扱い、アプレットと TCL のスクリプトを見ます。

17.3 の EEM Python Module 章の Python Scripting in EEM の節は、Python のスクリプトを EEM のポリシーとして登録でき、設定した EEM のポリシーが Guest Shell の中で動くと書いています。

Embedded Event Manager (EEM) policies support Python scripts. You can register Python scripts as EEM policies, and execute the registered Python scripts when a corresponding event occurs. The EEM Python script has the same event specification syntax as the EEM TCL policy.

（EEM Python Module 章「Python Scripting in EEM」）

Configured EEM policies run within the Guest Shell. Guest Shell is a virtualized Linux-based environment, designed to run custom Linux applications, including Python for automated control and management of Cisco devices. The Guest Shell container provides a Python interpreter.

（EEM Python Module 章「Python Scripting in EEM」）

この 2 つの引用は、Python のポリシーについての節の文です。本ラボで確かめたのは、Guest Shell の site-packages に eem のディレクトリがあったこと（§6.3）までで、EEM のポリシーは撮っていません。次節では、機器の中で起きたイベントを契機に動く EEM の仕組みを見ていきましょう。

16. 出典

本節が参照した資料です。6 件（5 章の 5 件と目次のページの 1 件）を 2026 年 10 月 17 日に取得しました。本文中の > の引用は、表の参照日の時点のページのテキストの逐語です。

17.3 の本の目次のページは、5 章の資料名と URL の出所で、> の引用の原典ではありません。CSR1 は csr1000v 17.03.08a なので、Cisco の 17.3.x のガイドを当てています。表の更新日は各ページの表記で、Application Hosting 章の本文は 17.5.1 など 17.3 より後の版にも触れています。