First, the essential ideas
- CLI and Console
- A command-line interface, or CLI, accepts typed instructions. Console is the device text window. In GNS3, right-click the named node and choose Console before typing; this is not your computer's PowerShell or Terminal window.
- Prompt and mode
- A prompt is the text before your typing position. A mode determines which commands are available. Router>, Router#, Router(config)# and Router(config-if)# mean user, privileged, global configuration and interface configuration modes.
- Command, argument and syntax
- A command names an operation. An argument supplies a value such as an address. Syntax is their required order. Type the command text, not the sample prompt; write complete commands before learning abbreviations.
- Running and startup configuration
- Running configuration is the active configuration. Startup configuration is the saved configuration normally read during startup. Editing the active state and saving it are separate operations; a successful save is not a test of connectivity.
- Interface and administrative state
- An interface is a device connection. Administrative state is whether configuration enables it. The shutdown command disables the selected interface; no shutdown enables it but cannot repair a missing cable or stopped peer.
- IPv4 address and subnet mask
- An IPv4 address identifies an interface. The mask separates network bits from host bits. In this lab, 192.0.2.1 and 192.0.2.10 with mask 255.255.255.0 share one local subnet.
- VPCS and the peer
- Virtual PC Simulator, or VPCS, is GNS3's lightweight simulated computer. PC1 is the peer that tests Router1. VPCS commands differ from IOS commands; enable and configure terminal belong on Router1, not PC1.
- Ping, ICMP and ARP
- Ping uses ICMP echo requests and replies to test a particular IP destination. ARP learns an IPv4 neighbor's local Ethernet address. Initial discovery can affect early probes; a reply does not prove Internet or application access.
- Baseline and expected result
- A baseline records the known starting settings and observations. An expected result is a prediction to check. Save your actual output and time; never replace an unexpected observation with the answer the guide predicted.
- Rollback and persistence
- Rollback restores an intended earlier state. Persistence means a setting has been saved for a later start. Returning to the # prompt is neither rollback nor a save; neither operation proves the device performed its intended network job.
- Scope and isolation
- Scope is the exact device, interface and change you are allowed to touch. Isolation keeps this disposable project disconnected from production and shared networks. An available command is not permission to run it elsewhere.
Treat every command as a small decision with a target, a purpose and a check. The prompt tells you where you are; the baseline tells you what should already exist. The guided experiment deliberately separates a changed interface, a saved configuration and a successful peer test.
See the idea
Five topology comparisons
Record the baseline. Verify the active change. Save only the intended working state.
Record the baseline
Identify Router1 and its exact port. Record active settings, saved settings and the same PC1 peer test before changing anything.
What this model leaves out: This workflow omits boot behavior and production approval systems. Saving is shown only after verification; it does not itself prove connectivity.
Full visual explanation and references
Changed is not saved
A baseline record leads to active running configuration, then to verified startup settings. These are workflow records, not network devices or a packet route.
This workflow omits boot behavior and production approval systems. Saving is shown only after verification; it does not itself prove connectivity.
- Record the baseline
Identify Router1 and its exact port. Record active settings, saved settings and the same PC1 peer test before changing anything.
docs.gns3.comwww.cisco.com - Inspect the active change
An accepted shutdown affects running state immediately. end changes the CLI mode; it does not undo the shutdown or save it.
www.cisco.comwww.cisco.com - Save only verified state
After confirming the intended working state, copy running configuration to startup configuration. A successful save is not a traffic test.
www.cisco.comwww.cisco.com
PC1 tests Router1, then retests
PC1 sends a ping over one isolated Ethernet cable to Router1. After the port is restored, the same request reaches Router1 and replies return to PC1.
Only PC1, Router1 and one cable are simulated. Console management is separate; Internet access, applications and reboot persistence are not tested.
- Establish peer replies
PC1 tests Router1 at 192.0.2.1, not its own address. Record actual replies before introducing the interface fault.
docs.gns3.comwww.cisco.com - Observe the disabled port
Router1's mapped port is shut down without saving. PC1's same target should not reply; record the interface evidence as well as the failed test.
www.cisco.comwww.cisco.com - Restore and repeat
Restore the same port with no shutdown. Repeat PC1's original ping; replies return from Router1 to PC1 without proving any Internet service.
www.cisco.comdocs.gns3.com
One idea at a time
Start with something familiar.
Open the definitions before using commands. You can first draw the prompts and record expected changes on paper. In the practical lab, open the named node's Console, check its prompt and enter one line at a time. These instructions were checked against sources; no router runtime output is claimed.
Why learn this?
Typing the right words into the wrong device or mode can fail or change the wrong setting. A saved mistake can also survive a restart. Learning to inspect the target, verify behavior and preserve evidence is more useful than memorizing a long block of commands.
An everyday comparison
As a memory aid, compare a working notebook with a saved reference copy. This is an organizational metaphor, not a literal description of computer memory or a claim that devices behave like a document editor.
What happens in a network
The working notebook represents active settings and the saved reference represents startup settings. A separate test asks whether those settings achieve the intended result. These are three different questions.
Where the comparison stopsMany IOS configuration commands take effect as they are accepted. Do not assume they wait for a Save button. Copy operations have defined directions, and loading an old file may merge settings rather than replace them.
Follow one worked example
- Identify the window before identifying the command.
The GNS3 node label identifies Router1 or PC1. Inside the router Console, read the hostname and mode marker. A node label and the IOS hostname can differ; changing the label does not configure the router.
Why: This prevents typing an IOS command into VPCS or assuming a renamed diagram node changed the device configuration.
- Write a before, change and after record.
Record the actual cable port, address, administrative state and successful peer test. Specify shutdown as the only later fault and no shutdown as the planned restoration on that same port.
Why: A small change has a clear boundary. Without a baseline, an operator cannot know whether a later difference was intended.
- Inspect the active and saved states separately.
After building a working link, save it. Then disable only its router port without saving the fault. Compare running and startup output and test from PC1.
Why: The example makes active effects visible without claiming a restart is necessary or that a saved file guarantees current reachability.
- Restore and repeat the original verification.
Re-enable the same mapped router port, allow discovery, and repeat the identical PC1 target. Compare the final interface settings with the saved working configuration.
Why: Accepted restoration syntax is only the start. Actual interface and peer-test evidence is needed to close the experiment.
Your first small task
On paper, place Router>, Router#, Router(config)# and Router(config-if)# in order. Under each prompt, write whether it is an EXEC mode or configuration mode. Circle the marker that must appear before entering an interface-specific change.
Show a hint
The word config identifies a configuration mode. The extra -if narrows it to one selected interface; # on its own does not make every command read-only.
Check the expected result
The first two are user and privileged EXEC. The last two are global and interface configuration. The selected interface is changed at (config-if)#.
Pause and explain it in your own words
You entered shutdown and then end, but did not save. Should the port still carry traffic?
Show a hint
Separate when IOS applies a configuration command from when it stores the startup configuration.
Show the explanation
No. The accepted shutdown changes the selected interface's active state immediately. end only leaves configuration mode. The old startup configuration may still be present, but it does not keep the running interface enabled.
Short answer
What should you understand today?
An IOS change is not complete when the command is accepted. Check the device and prompt, record the baseline, change only the intended setting, verify configuration and behavior, and save the verified state when authorized. Running configuration is active now; startup configuration is saved for a later start. Leaving configuration mode does not undo a change or save it.
Before you begin
Learning targets
- Complete the earlier IPv4 and interface lessons; this chapter repeats the Console basics.
- Use one fresh authorized IOS XE 17.x router with a routed Ethernet interface and one GNS3 VPCS node.
- Record the exact software release and port name; these commands are not an IOS XR, NX-OS or Layer 2 switch-port recipe.
- Keep the project disconnected and prepare notes in Notepad, TextEdit or a Linux plain-text editor.
- Identify user, privileged, global configuration and interface configuration prompts.
- Use context help without executing an incomplete command.
- Separate running configuration, startup configuration and observed traffic behavior.
- Build and verify one local link, then test a bounded shutdown and restore the same port.
- Explain why a configuration merge or a no command is not universal rollback.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
CLI and Console
A command-line interface, or CLI, accepts typed instructions. Console is the device text window. In GNS3, right-click the named node and choose Console before typing; this is not your computer's PowerShell or Terminal window.
Prompt and mode
A prompt is the text before your typing position. A mode determines which commands are available. Router>, Router#, Router(config)# and Router(config-if)# mean user, privileged, global configuration and interface configuration modes.
Command, argument and syntax
A command names an operation. An argument supplies a value such as an address. Syntax is their required order. Type the command text, not the sample prompt; write complete commands before learning abbreviations.
Running and startup configuration
Running configuration is the active configuration. Startup configuration is the saved configuration normally read during startup. Editing the active state and saving it are separate operations; a successful save is not a test of connectivity.
Interface and administrative state
An interface is a device connection. Administrative state is whether configuration enables it. The shutdown command disables the selected interface; no shutdown enables it but cannot repair a missing cable or stopped peer.
IPv4 address and subnet mask
An IPv4 address identifies an interface. The mask separates network bits from host bits. In this lab, 192.0.2.1 and 192.0.2.10 with mask 255.255.255.0 share one local subnet.
VPCS and the peer
Virtual PC Simulator, or VPCS, is GNS3's lightweight simulated computer. PC1 is the peer that tests Router1. VPCS commands differ from IOS commands; enable and configure terminal belong on Router1, not PC1.
Ping, ICMP and ARP
Ping uses ICMP echo requests and replies to test a particular IP destination. ARP learns an IPv4 neighbor's local Ethernet address. Initial discovery can affect early probes; a reply does not prove Internet or application access.
Baseline and expected result
A baseline records the known starting settings and observations. An expected result is a prediction to check. Save your actual output and time; never replace an unexpected observation with the answer the guide predicted.
Rollback and persistence
Rollback restores an intended earlier state. Persistence means a setting has been saved for a later start. Returning to the # prompt is neither rollback nor a save; neither operation proves the device performed its intended network job.
Scope and isolation
Scope is the exact device, interface and change you are allowed to touch. Isolation keeps this disposable project disconnected from production and shared networks. An available command is not permission to run it elsewhere.
Read the device and mode before you type
Use four prompt examples as a navigation map, not as text to paste: Router> is user EXEC, Router# is privileged EXEC, Router(config)# is global configuration and Router(config-if)# is interface configuration. Commands belong to particular contexts. Privileged mode includes consequential operations as well as show commands, so its availability is not a safety guarantee.
- Type command lines without copying sample prompts.
- Do not bypass a password or authorization error; use an authorized clean lab instance.
Help is a way to inspect syntax, not a substitute for judgment
At the appropriate prompt, a question mark displays available commands or the next argument. The distinction between a complete keyword followed by a space and a partial keyword matters. An incomplete command needs more information; an invalid-input marker identifies where parsing failed, not necessarily the whole cause. A wrong mode or unsupported software can be responsible.
- A question mark can leave partial input on the line; clear it before the next command.
- Use the exact software release documentation instead of guessing an equivalent command.
Active, saved and working are three different claims
The running configuration describes current configuration, while startup configuration is the saved startup source under the normal boot process. Many IOS changes apply as they are entered. The lab's copy running-config startup-config saves the entire running configuration, not only the last command. A complete save can preserve an unintended setting just as efficiently as a correct one.
- Review the complete intended change before saving, especially on shared systems.
- A configuration display cannot replace an actual test to the intended peer.
Choose a change whose failure you can explain
Use only a disconnected disposable project with one cabled router port. A successful baseline is mandatory before the intentional shutdown. The GNS3 Console remains your management path, so the experiment does not depend on the data interface being up. On a remotely managed real device the same interface shutdown could remove your access; this lesson does not authorize that operation.
- Keep a device, port, source, destination and timestamp with each test.
- A missed ping on a real network can involve filtering, host behavior or rate limits; it does not identify a faulty layer by itself.
Rollback means restoring a known state, not trying a magic word
A no command negates a particular setting according to its command definition; it does not remember the previous value. Copying a saved file into running configuration can combine its commands with current configuration. It is not a general replacement or an automatic removal of every line introduced since the backup. Advanced replacement procedures require their own platform-specific planning.
- Write the intended inverse before making the controlled fault.
- If the baseline or selected interface is uncertain, stop rather than broadening the change.
Close the change with evidence and an honest scope statement
A useful handover records the release, target, baseline, commands actually accepted, observed failure, restoration and retest. Keep real output private if it contains configuration secrets or identifying data. Label predictions as predictions. This lesson practices CLI navigation and a small local-link diagnosis; it does not certify a production change, switching design or complete exam domain.
- A score or checklist is not evidence that a router emulator was executed.
- Use the paper alternative when images are unavailable; do not invent screenshots or runtime results.
Real-world walkthrough
The configuration was saved, but the connection is down
In a hypothetical training environment, a learner says the network must work because the configuration was saved earlier. Another learner later disabled the router's cable port without saving. An operator should distinguish the old saved state from the active port and the actual peer test. This is an invented teaching scenario, not a claimed customer incident.
- Record which Console and port you are inspecting. Confirm that only the disconnected practice network is in scope and that the direct Console remains available.
- Read the active interface state and the running configuration, then inspect the startup configuration separately. Record their relevant difference without assuming the saved copy is active.
- From PC1, test the original Router1 destination, not PC1 itself. Record the actual result with the interface observation; a failure outside this controlled lab could have other causes.
- Restore only the known shutdown change on the exact port. Repeat the same interface checks and ping, preserving unexpected results instead of reporting a predicted success.
- Document that the local link recovered and the saved working settings were compared. Do not extend that conclusion to DNS, Internet reachability, applications or reboot persistence.
Guided GNS3 lab
Change, observe and restore one router interface
Navigate IOS modes, build one isolated peer link, save its working configuration, observe an unsaved shutdown and restore it. These are source-reviewed instructions and predicted results; QCS did not execute the Cisco router image during authoring.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| Router1 | Mapped Ethernet port | 192.0.2.1 / 255.255.255.0 | Local peer destination on the isolated documentation subnet. |
| PC1 | Ethernet0 | 192.0.2.10 / 255.255.255.0 | Originates tests to Router1; no default gateway is needed for this local-only exercise. |
Set up the lab
- Create a new GNS3 project named Day15-CLI. Select an authorized router template supporting IOS XE 17.x routed-interface commands. Do not download unofficial Cisco images or reuse a production configuration.
- Drag that router and one VPCS from End devices into the workspace. Rename the GNS3 nodes Router1 and PC1. These labels do not change the IOS hostname. Use Add a link from PC1 Ethernet0 to one router Ethernet port and record the port selection.
- Start both nodes. If the fresh router asks for the initial configuration dialog, answer no, then press Enter for its prompt. A password prompt requires your authorized lab credentials; do not bypass it.
- Write the exact port mapping: sample GigabitEthernet0/0 means the router port you actually cabled. For example, if the chosen port is GigabitEthernet0/0/0, use that name in every router block. Do not select a management-only or Layer 2 switch port.
- Prepare Day15-baseline.txt in Notepad on Windows, TextEdit in plain-text mode on macOS, or a Linux editor such as Gedit. Keep a clean stopped-project snapshot or independent clean lab copy before this exercise.
- GNS3 does not provide Cisco images. Confirm legal permission to use the chosen image in GNS3; CML reference images must not be exported into it. Cisco Modeling Labs is an official alternative, but its endpoint commands require a separate guide.
- If no authorized compatible router is available, draw Router1 and PC1 and a before/fault/restored worksheet on paper. Predict prompt and configuration changes, clearly labeling the exercise unexecuted. Do not attach your physical computer to simulate a missing node.
Record Router1 before changing it
In the isolated project, right-click Router1 and choose Console before typing. At >, use enable; if already at #, skip that first line. Save the exact software release, interface list and both configuration displays privately. At --More-- press Space for the next page or Enter for one line. If startup configuration is absent on this fresh instance, record that fact rather than treating it as corruption.
enable
show version
show ip interface brief
show running-config
show startup-configWhat each command means
enable- Enter privileged EXEC mode using authorized credentials if requested; do not type the displayed prompt.
show version- Record the actual software release and verify the guide matches this platform.
show ip interface brief- Find the cabled routed interface and record its exact spelling and current state.
show running-config- Record active settings, including any existing addresses or unrelated configuration.
show startup-config- Inspect saved settings; a fresh instance may not have a saved startup configuration.
- What you should see
- Your notes identify the actual port and distinguish active configuration from the saved file or its absence. Stop if the node contains unrelated or production settings.
- Why this step matters
- The later experiment depends on knowing the device and baseline rather than assuming a template's interface name or saved state.
Record PC1 and identify its Console
In the isolated project, right-click PC1 and choose Console before typing. Confirm the prompt belongs to VPCS, normally PC1>. Run show ip and record the initial address and mask. Do not enter enable or configure terminal here. If the node is not the intended fresh VPCS instance, stop and correct the project selection.
show ipWhat each command means
show ip- Display PC1's current IP settings so a later peer test cannot be confused with another node.
- What you should see
- PC1's starting settings are recorded; it has not yet been assigned the lesson address by this procedure.
- Why this step matters
- The two Console windows use different command languages. Naming the endpoint before typing prevents cross-device mistakes.
Explore help and return to EXEC
In the isolated project, right-click Router1 and choose Console before typing. Start at #. Type show ip ? to display help without pressing Enter, then press Ctrl+U to clear the remaining input. Enter the remaining lines one at a time, observing #, (config)# and # again. No interface is changed in this step. If help does not match the platform, stop and record it.
show ip ?
configure terminal
exitWhat each command means
show ip ?- Request context help for show ip, then clear the incomplete line with Ctrl+U before continuing.
configure terminal- Enter global configuration mode and observe the (config)# suffix.
exit- Leave global configuration mode for privileged EXEC; exit is context-dependent and is not a save.
- What you should see
- The prompt returns to # and you have observed help without treating the displayed command list as instructions to execute.
- Why this step matters
- Context and complete input matter more than typing speed. Clearing partial help input prevents accidentally joining two commands.
Configure the mapped Router1 port
In the isolated project, right-click Router1 and choose Console before typing. At #, enter each line separately using the recorded cable port. Confirm it is a routed interface with no existing address assignment; do not convert an unrelated switch port. Stop on any rejection because earlier accepted commands may already be active. The subnet is confined to this disconnected project.
configure terminal
interface GigabitEthernet0/0
ip address 192.0.2.1 255.255.255.0
no shutdown
exit
endWhat each command means
configure terminal- From the # prompt, enter global configuration mode; this command alone does not save anything.
interface GigabitEthernet0/0- Select Router1's recorded cable port; replace GigabitEthernet0/0 with that exact name.
ip address 192.0.2.1 255.255.255.0- Assign the router-side documentation address and /24 mask to this one interface.
no shutdown- Enable the selected interface administratively; the peer and cable still have to work.
exit- Move from interface configuration to global configuration without undoing the accepted settings.
end- Leave configuration mode and return to #. Already accepted changes remain active; this is not save or undo.
- What you should see
- The configured port has 192.0.2.1/24 and is enabled. Its operational state will be checked after PC1 is configured.
- Why this step matters
- This is a bounded active change. The end command does not defer its effect or save it to startup configuration.
Assign PC1 its distinct local address
In the isolated project, right-click PC1 and choose Console before typing. Enter the address with its dotted mask, then inspect it. No gateway is required because the only destination is in the same /24. Confirm PC1 has .10, not Router1's .1. If the address command is unsupported, use VPCS help and verify the installed version before continuing.
ip 192.0.2.10 255.255.255.0
show ipWhat each command means
ip 192.0.2.10 255.255.255.0- Assign PC1 the documentation host address with a /24 mask; this is VPCS syntax, not IOS syntax.
show ip- Verify the actual PC1 address and mask rather than assuming the command was accepted.
- What you should see
- PC1 shows 192.0.2.10 with mask 255.255.255.0. Router1 remains the different .1 destination.
- Why this step matters
- A self-ping or duplicate address can give misleading evidence, so the target and source must be checked explicitly.
Inspect Router1 active port state
In the isolated project, right-click Router1 and choose Console before typing. From #, read the mapped port state and active configuration. Match the actual cabled interface with your baseline. If it is administratively down, recheck the selected port and no shutdown; if the interface is missing, stop and inspect the template and cable mapping.
show ip interface brief
show interfaces GigabitEthernet0/0
show running-configWhat each command means
show ip interface brief- Check address, status and protocol for the exact cable port.
show interfaces GigabitEthernet0/0- Inspect that interface's detailed operational information; substitute the mapped port name.
show running-config- Verify the active interface stanza has the intended address and no intentional shutdown.
- What you should see
- With both nodes started and the cable correct, expect the router port up/up with 192.0.2.1. Record actual output before saving.
- Why this step matters
- An address line alone does not establish a working link; the selected port and both status fields matter.
Establish the PC1 peer-test baseline
In the isolated project, right-click PC1 and choose Console before typing. First check the source settings, then ping .1, not PC1's .10. Allow initial discovery and repeat the same ping if an early probe is lost. Continue only after repeatable replies; if baseline fails, troubleshoot before deliberately disabling anything.
show ip
ping 192.0.2.1What each command means
show ip- Confirm the test originates from PC1 at 192.0.2.10/24.
ping 192.0.2.1- Ask Router1 at 192.0.2.1 for ICMP echo replies across the only cable.
- What you should see
- Expect replies from Router1 after discovery. Record any initial loss and repeat result; this proves only the selected local echo exchange.
- Why this step matters
- A controlled fault is meaningful only when the same test worked beforehand. Internet and application health are outside the experiment.
Save the verified Router1 baseline
In the isolated project, right-click Router1 and choose Console before typing. At #, review the complete running configuration and confirm no unexpected changes exist. Run the copy command only after the peer test passed. If prompted Destination filename [startup-config]?, press Enter to accept startup-config, wait for completion, then run the display. If saving fails, stop before the fault.
show running-config
copy running-config startup-config
show startup-configWhat each command means
show running-config- Review active settings before copying the entire configuration, not merely the last line.
copy running-config startup-config- Save active configuration to startup configuration on this disposable router; respond only to the expected destination prompt.
show startup-config- Inspect the resulting saved interface address and enabled setting; do not rely on a generic success message alone.
- What you should see
- The saved configuration contains the working port's intended settings. Output may omit default commands; compare the relevant meaning, not timestamps or byte-for-byte identity.
- Why this step matters
- Saving preserves the current configuration whether correct or wrong. Verification must precede persistence.
Save PC1 separately
In the isolated project, right-click PC1 and choose Console before typing. Save the endpoint's settings after confirming they match the working baseline. Router1's copy command does not save VPCS. Record the result and keep the test worksheet; this step does not perform a restart or prove boot behavior.
show ip
saveWhat each command means
show ip- Recheck PC1's correct address and mask before saving its state.
save- Write the VPCS startup configuration using its own save command.
- What you should see
- VPCS reports its save result. Router1 and PC1 now have separately recorded saved working settings.
- Why this step matters
- Each device owns its own saved state. One successful router save cannot establish that the endpoint was saved too.
Apply only the unsaved shutdown fault
In the isolated project, right-click Router1 and choose Console before typing. Before entering configuration mode, confirm the cable port matches your baseline and the successful test. Keep the direct GNS3 Console open. Disable only that port and do not save this fault. Inspect both configurations afterward; never run this exercise on a remote-access or production port.
configure terminal
interface GigabitEthernet0/0
shutdown
end
show ip interface brief
show running-config
show startup-configWhat each command means
configure terminal- From the # prompt, enter global configuration mode; this command alone does not save anything.
interface GigabitEthernet0/0- Select Router1's recorded cable port; replace GigabitEthernet0/0 with that exact name.
shutdown- Disable this single isolated data interface; Console access is not through this cable.
end- Leave configuration mode and return to #. Already accepted changes remain active; this is not save or undo.
show ip interface brief- Observe the administrative-down state for the exact port.
show running-config- Confirm shutdown is present in the active interface configuration.
show startup-config- Compare with the previously saved working port state without copying or loading it.
- What you should see
- Expect the current interface administratively down while the startup configuration still reflects the saved working baseline. Record both observations.
- Why this step matters
- This demonstrates an active unsaved change. Leaving configuration mode did not undo it, and the saved file did not keep the port operational.
Observe the same PC1 target fail
In the isolated project, right-click PC1 and choose Console before typing. Repeat exactly the baseline destination while Router1's mapped port remains administratively down. Do not change addresses, cables or security controls. If replies continue, stop and verify the actual destination and port; do not force the expected answer or proceed with uncertain evidence.
ping 192.0.2.1What each command means
ping 192.0.2.1- Repeat the original local Router1 target to compare behavior after the single interface change.
- What you should see
- Expect no successful echo replies through the disabled interface; the VPCS error wording may vary. Record the actual failure, not a fabricated transcript.
- Why this step matters
- The known change and separate interface evidence explain this controlled failure. A failed ping elsewhere would not by itself establish the cause.
Restore the same Router1 interface
In the isolated project, right-click Router1 and choose Console before typing. Confirm the original port mapping again. The recorded working state had this port enabled, so restore no shutdown only there. Do not copy startup configuration into running configuration, reload the node or change any other interface. Stop if the actual baseline does not match this plan.
configure terminal
interface GigabitEthernet0/0
no shutdown
end
show ip interface briefWhat each command means
configure terminal- From the # prompt, enter global configuration mode; this command alone does not save anything.
interface GigabitEthernet0/0- Select Router1's recorded cable port; replace GigabitEthernet0/0 with that exact name.
no shutdown- Restore the enabled state on the exact port disabled by the experiment.
end- Leave configuration mode and return to #. Already accepted changes remain active; this is not save or undo.
show ip interface brief- Check the mapped port returns toward up/up with its original address.
- What you should see
- Expect the original address and enabled interface state. Allow the peer and link to settle before the next traffic check.
- Why this step matters
- This inverse is valid because the fault and prior state are known. It is not a rule that every no command restores any previous configuration.
Retest PC1 after restoration
In the isolated project, right-click PC1 and choose Console before typing. Recheck the source and repeat the identical destination. Allow discovery, then compare actual replies with the baseline. If recovery fails, preserve evidence and recheck port, cable and address state; do not save an unverified new workaround.
show ip
ping 192.0.2.1What each command means
show ip- Verify that PC1 retained the planned address and mask throughout the experiment.
ping 192.0.2.1- Repeat the original Router1 test after its port was restored.
- What you should see
- Expect peer replies again after discovery. The before, fault and restored worksheet now records the same source and destination in all three states.
- Why this step matters
- Restoration is established by the repeated evidence, not just an accepted no shutdown command or a successful save.
Close with configuration evidence
In the isolated project, right-click Router1 and choose Console before typing. From #, compare the restored active interface settings with the saved working baseline and record the final state. No new save is required if the relevant configuration matches and no other changes were made. If differences remain, stop and review them rather than overwriting startup blindly. Keep the working lab for later or stop both nodes in GNS3 after preserving notes.
show ip interface brief
show running-config
show startup-configWhat each command means
show ip interface brief- Record the restored interface address and operational state alongside the final PC1 result.
show running-config- Check the active interface configuration and look for unintended changes.
show startup-config- Confirm the saved working settings still correspond to the intended final configuration.
- What you should see
- The intended port configuration and peer test match the working baseline. Timing lines and operational counters need not match saved configuration text.
- Why this step matters
- Closing evidence separates current behavior, saved settings and the limits of what was tested. No reboot, Internet service or full application path was verified.
Verify
- Identify the exact Router1 software release and cable port before changing configuration.
- Record both running and startup configuration; record absence of startup configuration honestly on a fresh node.
- Require a successful PC1-to-Router1 baseline before introducing shutdown.
- Confirm the unsaved fault is active even after end, while saved working settings remain unchanged.
- After no shutdown, repeat the same source and destination test and compare relevant configuration meaning.
- These instructions were source-reviewed only; no router emulator or physical network runtime was executed during authoring.
Troubleshoot
- For invalid input, record the node, prompt, full command and caret location. Check mode, spelling and platform support. Stop the sequence because previously accepted commands may already be active; do not paste an entire replacement configuration.
- If the expected interface is absent, inspect the GNS3 template and cable mapping. If administratively down, check the exact interface and intended shutdown state. If up/down, check the peer is started and the cable is attached; do not alter unrelated ports.
- If ping fails before the intentional fault, recheck PC1 is .10/24 and the target is Router1 .1. Allow neighbor discovery and repeat. A reply to your own address is not a peer test. Real networks may also filter or rate-limit ICMP.
- If copy fails or startup output lacks the intended state, do not proceed with the fault. Preserve the message and consult the matching image documentation for storage or permission issues; do not erase files or reload to make the message disappear.
- If restoring the selected port does not restore the baseline, stop and compare all recorded facts. These changes are permitted only in the isolated lab; never apply them to production traffic or shared-use networks.
GNS3 does not provide Cisco images. Use them only when the applicable license or entitlement permits use in your selected environment. Do not share or redistribute image files. Cisco Modeling Labs is the official alternative; its reference images are not licensed for export into GNS3 simply because you own CML. Without an authorized image, complete the labeled paper exercise without claiming router execution.
- Leave Router1 and PC1 in the verified working lab state; the temporary shutdown must be removed and the peer retest recorded.
- Preserve private baseline/fault/restored notes, then stop both nodes using GNS3. Do not erase startup configurations, reload real devices or reset shared interfaces.
- For a completely clean repeat, use the separately preserved stopped-project snapshot or fresh authorized instances after saving evidence. Do not distribute Cisco images or private configurations.
Practice set
Answer before you reveal
01Does Router# mean that every available command is read-only?
The prompt identifies command context, not permission or safety. Select a specific authorized operation and know its effect before typing.
02What changes when exit is entered from interface configuration?
Mode navigation and configuration state are separate. The effect depends on the mode you leave, so exit from another context can have a different navigation result.
03Why clear the input after using show ip question-mark help?
Clear it with Ctrl+U before starting a new command. Otherwise the next words may be appended to the old input and produce misleading syntax errors.
04An unsaved shutdown is active. Why did end not restore service?
Saving determines persistence, not whether an accepted configuration line is active now. Restore the known working state and repeat the peer test.
05Why is copying startup configuration into running configuration not universal rollback?
Extra active commands can remain. Use an explicit reviewed inverse for this bounded lab fault; advanced replacement requires a separate supported procedure.
06Which ping destination tests the link from PC1 in this lab?
A self-test does not require the intended external path. Verify the source settings and destination before interpreting a success or failure.
07Does a saved configuration prove that DNS and Internet access work?
Inspect the saved state and run tests for the intended outcome. This isolated exercise tests only one local echo exchange and does not perform a reboot.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Check the device, mode and intended port before every command block.
- An accepted configuration change can be active before it is saved.
- end and exit navigate modes; they are not universal undo or save commands.
- Verify active settings, saved settings and behavior as separate facts.
- A merge or a no command is not automatic restoration of all previous state.
- Record the same source and destination before, during and after the isolated fault.
- Keep licensing, privacy and runtime limitations explicit; never fabricate lab evidence.