Hands-On Lab: Working with the Cisco IOS File System (IFS)

This hands-on lab explores the Cisco IOS File System commands used to navigate, list, and manage files across a router's different storage locations, including flash, NVRAM, and remote file systems referenced by URL-style prefixes.

Cisco IFS CommandsFlash and NVRAM NavigationFile System URL Prefixes

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Navigate a router's file system using IFS commands, list files in flash and NVRAM, and use URL-style prefixes to reference both local and remote file system locations directly within a single command.

Lab Purpose

Nearly every file operation covered in earlier labs — copying an IOS image, backing up a configuration — relies on the Cisco IOS File System underneath. Understanding how to navigate it directly, rather than only using specific copy commands, is essential for troubleshooting storage issues and managing multiple files across a device's various storage locations.

Lab Topology

R1 with an IOS image and saved configuration
already present in flash and NVRAM
respectively, from earlier labs in this series

Task 1: List the Available File Systems

Display every file system the router recognizes, including flash, NVRAM, and any others.

Task 2: Navigate Into Flash and List Its Contents

Change the current directory to flash and list its files.

Task 3: View NVRAM Contents

List the contents of NVRAM, where the startup configuration is stored.

Task 4: Reference a File Using a Full URL-Style Path

Without changing directories, display the contents of the startup configuration using its full IFS URL-style path directly.

Task 5: Check Free Space Across File Systems

Confirm the free space reported by IFS commands matches what was seen using show flash in an earlier lab.

Solution and Verification

R1# show file systems

File Systems:

     Size(b)     Free(b)      Type  Flags  Prefixes
   524288000   198254592     disk     rw   flash:
       32768       28454     nvram    rw   nvram:
           -           -   opaque     rw   system:
           -           -   network    rw   tftp:

R1# cd flash:
R1# dir

Directory of flash:/

    1  -rw-  93326848  Jun 15 2026 12:34:56  c2900-universalk9-mz.SPA.157-3.M.bin
    2  -rw-      1284  Jun 15 2026 09:12:03  R1-backup.txt

R1# cd nvram:
R1# dir

Directory of nvram:/

    1  -rw-      1412             startup-config
    2  ----        24             private-config
-- The startup configuration is stored here,
-- separate entirely from flash, which is
-- why "copy startup-config running-config,"
-- used during password recovery in the
-- previous lab, references a distinct
-- location from the IOS image itself

R1# more nvram:startup-config

Building configuration...

Current configuration : 1412 bytes
!
hostname R1
!
interface GigabitEthernet0/0
 ip address 192.168.75.1 255.255.255.0
...
-- Referencing the file with its full IFS
-- prefix (nvram:) works regardless of which
-- directory is currently active, without
-- needing to first "cd" into nvram:

R1# show flash

-524288000 bytes total (104960640 bytes free)
-- The free space figure is lower than the
-- earlier lab's reading, since the backup
-- file and IOS image copied in previous
-- labs now consume that flash space --
-- matches exactly what "show file systems"
-- reported above for the flash: prefix

Key Takeaway

Every copy command used throughout this series — copy tftp: flash:, copy running-config startup-config, copy startup-config tftp: — is built entirely on this same underlying IFS prefix system, where flash:, nvram:, tftp:, and similar prefixes identify a specific file system location regardless of the current working directory, making commands like more nvram:startup-config work correctly from anywhere without first navigating there.

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

مقالات مرتبط

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

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

ادامه

Hands-On Lab: Configuring BGP over DMVPN

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

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

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

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

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

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

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

ادامه

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

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

ادامه