First, the essential ideas
- Interface and medium
- An interface is a device's network connection, often called a port. The medium is what carries its signals, such as copper wire or glass fiber.
- Speed and duplex
- Speed is the link's signaling rate. Duplex describes whether the ends can transmit simultaneously: full duplex allows both directions at once; half duplex uses a shared transmission opportunity.
- Frame and packet
- A frame is the local-link container for data. An IP packet is the network-addressed message carried inside it. A switch forwards frames; it does not repair damaged cables.
- IP address, mask and gateway
- An IP address identifies an interface. The mask says which addresses share its network. A gateway is a router used to reach other networks; this same-network lab does not need one.
- VPCS and console
- VPCS means Virtual PC Simulator, a small practice computer in GNS3. Its console is a text window where you type commands after a prompt such as PC1>. Do not type the prompt itself.
- Ping and ICMP
- Ping sends an Internet Control Message Protocol echo request and waits for an echo reply. A reply confirms that exchange at that time; it does not measure cable quality or application performance.
- MAC address and ARP
- A MAC address identifies a local-link interface. Address Resolution Protocol, or ARP, discovers the MAC address for a local IPv4 neighbor before the first unicast exchange.
- Counter and CRC
- A counter is a running event total. CRC means cyclic redundancy check; a failed received-frame check is an error symptom, not a diagnosis naming the defective part.
- Transceiver and SFP
- A transceiver sends and receives signals. Small Form-factor Pluggable, or SFP, is a module format; the exact module specification determines supported media and link characteristics.
Start with the vocabulary below. A cable carries signals; a network interface is the device connection to that cable. We will first observe a small virtual network, then use clearly labeled paper evidence to discuss physical equipment. The two activities teach related skills but produce different evidence.
See the idea
One path: observe, disconnect, restore
Record the working path, change one link and verify recovery; physical-media measurements need suitable hardware.
Record the working path
PC1 sends a test through Switch1 and Switch2 to PC2, which replies on the same topology. The arrows summarize connectivity, not measured cable signals.
What this model leaves out: This virtual lab omits real copper, optics and duplex negotiation because built-in switches do not model physical faults. Hardware diagnostics are separate paper exercises.
Full visual explanation and references
PC1 connects through Switch1 and Switch2 to PC2. The diagram ends at PC2 and compares the intact path, a missing inter-switch link and the restored path.
This virtual lab omits real copper, optics and duplex negotiation because built-in switches do not model physical faults. Hardware diagnostics are separate paper exercises.
- Record the working path
PC1 sends a test through Switch1 and Switch2 to PC2, which replies on the same topology. The arrows summarize connectivity, not measured cable signals.
docs.gns3.com - Remove the middle link
Remove only the Switch1-to-Switch2 link. PC2 remains the destination, but no complete path reaches it; the same test receives no replies.
docs.gns3.com - Restore and retest
Restore the same inter-switch ports. Retest PC1 to PC2, then PC2 to PC1; record the returned replies without claiming physical-media quality.
docs.gns3.comdocs.gns3.com
One idea at a time
Start with something familiar.
You do not need to remember command syntax from earlier lessons. Follow the device names exactly, open the named console, and type one line at a time. The built-in switches have no Cisco command console; their connections are managed in GNS3's graphical workspace.
Why learn this?
A connection may be present but unreliable. Learning to record what changed, distinguish a symptom from a cause, and retest after one correction prevents random changes that hide the original problem.
An everyday comparison
As a memory aid, compare taking turns on a walkie-talkie with speaking and listening on a telephone. This is an organizational comparison, not a literal description of Ethernet signals or device behavior.
What happens in a network
The comparison helps distinguish taking turns from simultaneous communication. It does not explain link speed: talking louder is not equivalent to a faster network, and cable material alone does not set the rate.
Where the comparison stopsReal links follow electrical or optical specifications and supported negotiation rules. Do not infer collisions, throughput or signal quality from the conversation analogy.
Follow one worked example
- Draw PC1, Switch1, Switch2 and PC2 in order.
A single line between each pair creates one possible path between the endpoints. Every connection endpoint appears in both the diagram and lab table.
Why: One path makes the deliberate link removal easy to observe without introducing loops or alternate paths.
- Record addresses and establish a working baseline.
PC1 uses 192.168.6.10 and PC2 uses 192.168.6.20, both with mask 255.255.255.0. Test each computer against the other, never itself.
Why: A baseline separates a fault that you introduce deliberately from an unrelated setup mistake.
- Remove only the connection between the two switches.
The endpoints stay configured but their only connecting path disappears. The same remote ping can no longer receive replies.
Why: This controlled change illustrates a missing path, not optical damage or a measured duplex mismatch.
- Reconnect the same ports and repeat the tests.
Replies should return in both directions. Keep your failure and recovery notes together so the changed link and result can be compared.
Why: A repair is supported by a repeatable before-and-after observation, not by the fact that a command was accepted.
- Use the paper counter and media exercises separately.
You compare hypothetical port settings and time-stamped error counts. The numbers are teaching examples, not readings generated by your virtual switches.
Why: This preserves the boundary between software connectivity practice and physical measurements that require suitable hardware.
Your first small task
Before removing a link, open PC1's console and verify that it is 192.168.6.10. Ping 192.168.6.20, then perform the reverse test from PC2 and record both results.
Show a hint
If either test fails repeatedly, stop and correct the basic lab before introducing a second fault. A self-ping is not a substitute.
Check the expected result
Both remote tests should receive replies once local address discovery completes. Your notes identify the sender, destination and time for each test.
Pause and explain it in your own words
Does a successful virtual ping prove that a real fiber module is healthy?
Show a hint
Ask which device and signal were actually measured by your test, and which were only discussed on paper.
Show the explanation
No. This ping demonstrates a particular request-and-reply exchange in the virtual topology. The lab has no physical optical receiver to measure, so it cannot establish real fiber power, connector condition or transceiver health.
Short answer
What should you understand today?
Choose a cable and port combination that supports the required distance and link rate. Check both ends before changing settings, and compare new interface errors with a recorded baseline. This lesson uses an isolated GNS3 connectivity exercise plus paper examples for physical media, speed negotiation and duplex faults that its virtual switches cannot reproduce.
Before you begin
Learning targets
- Read Days 1, 2 and 5 for device roles and encapsulation; console instructions and essential terms are repeated here.
- Install GNS3 and complete its local-server setup before starting. Use built-in VPCS and Ethernet switch templates; no Cisco image is needed for this lab.
- Create a new isolated project with no Cloud, NAT, Internet, physical adapter or production-network connection.
- Use a notes editor: Notepad on Windows, TextEdit in plain-text mode on macOS, or a text editor such as Gedit on Linux.
- Compare copper and fiber by supported port, distance, connector and module requirements.
- Explain link speed, full duplex and the limited legacy context of half-duplex mismatches.
- Interpret interface state and changes in error counters without claiming that one symptom proves its cause.
- Build and verify a four-node GNS3 path, deliberately remove one link and demonstrate recovery.
- Separate observations from the virtual lab from paper-based Cisco physical-interface diagnostics.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Interface and medium
An interface is a device's network connection, often called a port. The medium is what carries its signals, such as copper wire or glass fiber.
Speed and duplex
Speed is the link's signaling rate. Duplex describes whether the ends can transmit simultaneously: full duplex allows both directions at once; half duplex uses a shared transmission opportunity.
Frame and packet
A frame is the local-link container for data. An IP packet is the network-addressed message carried inside it. A switch forwards frames; it does not repair damaged cables.
IP address, mask and gateway
An IP address identifies an interface. The mask says which addresses share its network. A gateway is a router used to reach other networks; this same-network lab does not need one.
VPCS and console
VPCS means Virtual PC Simulator, a small practice computer in GNS3. Its console is a text window where you type commands after a prompt such as PC1>. Do not type the prompt itself.
Ping and ICMP
Ping sends an Internet Control Message Protocol echo request and waits for an echo reply. A reply confirms that exchange at that time; it does not measure cable quality or application performance.
MAC address and ARP
A MAC address identifies a local-link interface. Address Resolution Protocol, or ARP, discovers the MAC address for a local IPv4 neighbor before the first unicast exchange.
Counter and CRC
A counter is a running event total. CRC means cyclic redundancy check; a failed received-frame check is an error symptom, not a diagnosis naming the defective part.
Transceiver and SFP
A transceiver sends and receives signals. Small Form-factor Pluggable, or SFP, is a module format; the exact module specification determines supported media and link characteristics.
Baseline
A written record of the intended configuration and observed results before a change, used to compare and restore the exercise.
Auto-negotiation
A supported link process by which the connected devices exchange capabilities and agree on compatible operating properties.
Privileged EXEC
An authorized Cisco operational command mode, commonly indicated by #, for inspections and other privileged commands rather than a VPCS prompt.
Choose the medium from the connection requirements
Begin with the two devices, the required distance and their supported ports. Copper carries electrical signals; fiber carries light. Neither is automatically the correct choice for every link. Check the actual module, cable and port documentation before buying or connecting anything. Connector shape alone is not compatibility evidence. For an optical link, record the module specification at both ends and the fiber type; never look into a fiber end or optical port. Treat installation, cleaning and eye safety as manufacturer-guided hardware work, not part of this software lab.
- Choose a supported combination, not a cable based only on its appearance.
- Record distance, connector, module and port requirements before selecting media.
- The virtual lines in this lesson represent connectivity, not measured optical or electrical behavior.
Understand negotiated speed and duplex before changing them
Link speed is a nominal signaling rate, not a promise that an application will transfer useful files at that rate. Full duplex allows simultaneous transmission in both directions on a compatible link. A mismatch is a disagreement between the ends about duplex operation. In this lesson, a half-versus-full mismatch is a paper example for suitable legacy 10/100 equipment, not an instruction to configure Cisco Gigabit Ethernet at half duplex. Check the exact platform's capabilities. When both devices support compatible auto-negotiation, begin with the vendor's recommended automatic settings instead of forcing one end in isolation.
- Inspect both ends and the platform guide before a configuration change.
- Do not present 1000 Mb/s half-duplex operation as a valid Cisco lab outcome.
- A displayed link rate is not a measurement of end-to-end application throughput.
Read interface evidence without overclaiming its meaning
On supported Cisco hardware, show interfaces reports an interface's operational information. An interface is the connection being inspected, not the whole network. Privileged EXEC mode is the operational command level commonly shown by a prompt ending in #; enable enters it when permitted. Configuration mode, commonly shown by (config)#, changes settings and is not required for the read-only paper exercise here. Interface names vary across equipment, so GigabitEthernet1/0/1 is an example name, not a universal port. Record link state, negotiated properties, counters and observation time before deciding what to change.
- Keep timestamps and compare counter changes, not just lifetime totals.
- A built-in GNS3 Ethernet switch does not provide Cisco IOS show commands.
- Hardware transceiver diagnostics and their availability depend on the platform and module.
Distinguish a symptom from a confirmed cause
A missing ping reply says that this test did not complete successfully. It does not by itself identify a damaged cable or a particular network layer. Incorrect addresses, a disconnected path, host filtering, rate limiting and other conditions can cause loss. Likewise, an increasing received-frame error counter warrants investigation but does not name a defective component. Record evidence from both link ends, keep the scope narrow and change one approved factor at a time. Existing totals normally remain after a repair; look for the rate of new errors to stop rather than expecting old errors to disappear automatically.
- Explain what was observed separately from the suspected cause.
- Do not clear counters until evidence is recorded and the operation is approved.
- A repeated baseline, fault and recovery test is stronger than one isolated successful ping.
Practice safely with a virtual path and paper diagnostics
The hands-on exercise uses PC1, Switch1, Switch2 and PC2 in one straight path. Its only induced fault is removal of the link between the switches. The endpoints share one IPv4 network, so a router and default gateway are unnecessary. There are no redundant links or changes to real interfaces. Separate paper tasks cover media choice, duplex compatibility and counter interpretation. This is intentionally honest about the environment: the built-in switches do not reproduce a Catalyst 9300, physical transceiver telemetry or genuine cable-induced CRC errors.
- Keep the project disconnected from production and from the host's physical network.
- Use virtual connectivity tests for path reasoning, not claims about physical media quality.
- Optional future hardware practice requires suitable equipment, authorization and platform-specific instructions.
Real-world walkthrough
Investigate an unreliable office connection with evidence
A hypothetical office reports interrupted file transfers on one desk connection. A support engineer has authorization to inspect that connection but not to change the rest of the network. The first task is to document the affected path and collect time-stamped evidence, rather than assuming that the first error counter identifies the cause.
- Identify the endpoint and its switch port using the organization's records. Confirm the actual interface before inspecting it, and record the user-visible symptom and when it occurs.
- Collect read-only interface information at both ends where available. Record speed, duplex and counter totals twice while noting traffic conditions; do not erase the initial evidence.
- Compare supported settings and look for newly increasing errors. A CRC increase is evidence to investigate, while a missed ping may also involve host filtering or rate limits.
- Arrange an approved, reversible test of one suspected factor, such as substituting a known-compatible cable. Do not change speed and cable simultaneously and then claim which one fixed the issue.
- Repeat the same observations and the affected application's test. Existing counter values need not return to zero; the useful question is whether new errors continue under comparable conditions.
- Document the confirmed result and any uncertainty. Escalate with the observations when the cause remains unknown rather than forcing unsupported settings or promising that all faults are resolved.
Guided GNS3 lab
GNS3 path recovery with separate physical-media paper tasks
Observe a working four-node path, deliberately remove its only inter-switch link, and verify recovery. Then interpret hypothetical media and interface evidence without claiming that GNS3 measured hardware faults.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| PC1 | Ethernet0 | 192.168.6.10/24 | Sender connected to Switch1 Ethernet0; no gateway needed. |
| Switch1 | Ethernet0, Ethernet1 | No IP address required | Ethernet0 to PC1; Ethernet1 to Switch2 Ethernet0. |
| Switch2 | Ethernet0, Ethernet1 | No IP address required | Ethernet0 to Switch1; Ethernet1 to PC2 Ethernet0. |
| PC2 | Ethernet0 | 192.168.6.20/24 | Destination connected to Switch2 Ethernet1; no gateway needed. |
Set up the lab
- Finish the official GNS3 local-server setup. If VPCS is unavailable on your installation, use the official installation guidance before continuing; do not substitute an unknown image.
- Create a new blank project named Day6-link-check. Do not add Cloud or NAT nodes, bridge host adapters or connect this exercise to shared networks.
- From End devices add two VPCS nodes and name them PC1 and PC2. From Switches add two built-in Ethernet switches and name them Switch1 and Switch2.
- Use Add a link to make exactly the three connections in the table. Turn on interface labels and verify each endpoint. Do not add a second link between the switches.
- Start the VPCS nodes with the green Start button. Built-in switches do not have Cisco consoles; their port settings are available through Configure in the GUI.
- Keep a plain-text notes file called Day6-baseline.txt in Notepad, TextEdit or a Linux text editor. Record device names, links and addresses before the deliberate fault.
Record the isolated topology
In the GNS3 workspace, check each device and cable against the addressing table. Record PC1 Ethernet0 to Switch1 Ethernet0, Switch1 Ethernet1 to Switch2 Ethernet0, and Switch2 Ethernet1 to PC2 Ethernet0. Confirm no Cloud or NAT node exists.
- What you should see
- Your notes show four named devices, exactly three connections and no external connection. Stop if the visible topology differs.
- Why this step matters
- A recorded baseline lets you restore the exact intended path without guessing which cable belonged to which port.
Configure PC1
Right-click PC1 and choose Console before typing. Wait for the VPCS prompt, normally PC1>. Type only each command below, then press Enter. If a different device console opens, close it and select PC1 again.
ip 192.168.6.10 255.255.255.0
show ipWhat each command means
ip 192.168.6.10 255.255.255.0- Assign PC1 the IPv4 address 192.168.6.10 with mask 255.255.255.0, placing it in network 192.168.6.0/24; no gateway is supplied.
show ip- Display PC1's current address information so you can verify the address and mask before testing the other endpoint.
- What you should see
- PC1 reports 192.168.6.10 with mask 255.255.255.0. Record it and correct any typing error before continuing.
- Why this step matters
- Confirming the local identity prevents an address error from being confused with the deliberate link fault later.
Configure PC2
Right-click PC2 and choose Console before typing. Confirm that this window belongs to PC2, then enter its own address. Do not paste PC1's address into both nodes; each endpoint must be unique.
ip 192.168.6.20 255.255.255.0
show ipWhat each command means
ip 192.168.6.20 255.255.255.0- Assign PC2 the IPv4 address 192.168.6.20 with mask 255.255.255.0, on the same network as PC1 but with a distinct host address.
show ip- Display PC2's address information and verify that it is the intended remote destination, 192.168.6.20.
- What you should see
- PC2 reports 192.168.6.20 with mask 255.255.255.0. Neither endpoint needs a default gateway for this same-network exchange.
- Why this step matters
- The two endpoints need matching network membership and different addresses before the connectivity test is meaningful.
Establish the forward baseline
Right-click PC1 and choose Console before typing. Check your notes: PC1 is 192.168.6.10, so the test below targets PC2, not itself. Run the test, record replies or timeouts, and repeat if the first exchange is delayed by address discovery.
ping 192.168.6.20What each command means
ping 192.168.6.20- Send ICMP echo requests from PC1 to PC2 at 192.168.6.20 and report whether replies return; this is not a bandwidth or cable-quality test.
- What you should see
- Repeated tests should receive replies from 192.168.6.20. One initial timeout can occur during address discovery, but persistent loss is a setup problem to resolve before proceeding.
- Why this step matters
- The fault exercise requires evidence that the same remote destination was reachable before you remove a link.
Establish the reverse baseline
Right-click PC2 and choose Console before typing. Send the reverse test to PC1 at 192.168.6.10. Record the sender and destination explicitly so that a successful self-ping cannot be mistaken for a test of the complete path.
ping 192.168.6.10What each command means
ping 192.168.6.10- Send ICMP echo requests from PC2 to PC1 at 192.168.6.10 and check that replies return over the same connected topology.
- What you should see
- PC2 receives replies from PC1 on repeated tests. If either direction repeatedly fails, inspect the recorded addresses, node state and three links before adding a fault.
- Why this step matters
- Testing both endpoints builds a clearer baseline, although neither direction establishes physical-media quality or application health.
Remove the single inter-switch link
In this isolated project only, select the cable joining Switch1 Ethernet1 to Switch2 Ethernet0 and delete that link through its context menu. Do not delete a node or an endpoint cable. Keep the original port pair in your notes for restoration.
- What you should see
- The workspace shows PC1 attached to Switch1 and PC2 attached to Switch2, but no connection between the two switches. Both VPCS nodes remain running.
- Why this step matters
- Removing one known path is a controlled connectivity fault. It does not simulate an optical-power reading or a physical duplex mismatch.
Verify loss of the remote path
Right-click PC1 and choose Console before typing. Repeat exactly the same destination used in the forward baseline. Leave both endpoint addresses unchanged; the only intended change is the missing link between Switch1 and Switch2.
ping 192.168.6.20What each command means
ping 192.168.6.20- Repeat the PC1-to-PC2 echo test with the inter-switch link absent, checking whether any remote reply can traverse the now-broken path.
- What you should see
- Expect no replies from PC2. A cached MAC address cannot carry traffic across a missing link. An unreachable message or timeout wording may vary with VPCS state.
- Why this step matters
- The controlled before-and-after comparison supports this known lab fault. A failed ping on an unknown real network would not, by itself, prove a cable fault.
Reconnect the recorded port pair
Use Add a link to connect Switch1 Ethernet1 back to Switch2 Ethernet0, matching the baseline exactly. Leave the endpoint links untouched. Confirm there is only one connection between the switches and all four device names remain visible.
- What you should see
- The original three-link topology is restored. The addresses remain unchanged, and the complete path again ends at PC2.
- Why this step matters
- Restoring the same connection preserves a fair test instead of changing several variables at once.
Verify forward recovery
Right-click PC1 and choose Console before typing. Repeat the original remote test and compare it with the recorded baseline and fault result. If repeated tests still fail, inspect the restored ports and addresses rather than changing speed or duplex.
ping 192.168.6.20What each command means
ping 192.168.6.20- Retest PC2 at 192.168.6.20 from PC1 after restoring the inter-switch link, using the same sender and destination as before.
- What you should see
- Replies should return on repeated tests after reconnection. Record recovery rather than claiming that a physical cable or transceiver has been tested.
- Why this step matters
- A successful repeat test supports recovery of this virtual path, with no unsupported claim about physical counters.
Verify reverse recovery
Right-click PC2 and choose Console before typing. Repeat the earlier reverse test to PC1 and record the result in Day6-baseline.txt. If recovery is incomplete, keep the project isolated and compare every endpoint with the saved table.
ping 192.168.6.10What each command means
ping 192.168.6.10- Retest PC1 at 192.168.6.10 from PC2 after restoration to confirm the reverse request-and-reply exchange also works.
- What you should see
- Repeated replies return from PC1. Your notes now contain successful baseline tests, expected loss and successful recovery with the same addresses.
- Why this step matters
- Keeping both directions and all three phases together makes the exercise evidence useful to another learner reviewing your work.
Compare media and duplex on paper
Do not type configuration commands into the built-in switches. In your notes, compare a short desk link and a longer inter-building link, listing unknown distance and port requirements. Then compare 100 Mb/s full versus 100 Mb/s half on compatible legacy hardware, and 1000 Mb/s full at both ends.
- What you should see
- Identify the legacy setting pair as a duplex disagreement and the second pair as matching. State that neither example was created or measured by GNS3 and that module and cable compatibility require actual specifications.
- Why this step matters
- A paper exercise teaches selection and compatibility without fabricating hardware capabilities or asking beginners to force an unsupported gigabit half-duplex mode.
Interpret time-stamped counters on paper
Use these hypothetical observations, not claimed device output: at 10:00 a port has 12 CRC errors; at 10:05 it has 27; after an approved correction, readings at 10:10 and 10:15 both show 27. Write the increase for each interval and a cautious next action.
- What you should see
- The first interval contains 15 additional errors; the final interval contains zero additional errors. Old totals remain. Investigate both ends and service behavior rather than asserting that CRC alone proves a bad cable.
- Why this step matters
- Counter differences and a controlled observation interval are more informative than expecting cumulative totals to reset automatically after a repair.
Read the Cisco command plan on paper
This is a read-only planning exercise, not a command block for VPCS. On authorized Cisco hardware, an operator uses enable if needed, identifies the actual interface, then uses the supported show interfaces command. An example is show interfaces GigabitEthernet1/0/1. Write what you would record: state, rate, duplex, counters and time.
- What you should see
- Your notes name the example command and its intended evidence, while marking the exact interface and optional transceiver telemetry as hardware-dependent. No Cisco command is run on a built-in GNS3 switch.
- Why this step matters
- Recognizing the right command and context is useful even without hardware. It is more accurate than promising optical telemetry from a software-only node.
Preserve notes and close safely
Verify the original three-link path is restored. Save Day6-baseline.txt in your notes editor; GNS3 saves the project topology as you work. Stop the nodes before closing the project. VPCS addresses may need re-entry when reopening, using the two documented address commands. Keep every test isolated.
- What you should see
- The project topology and notes are preserved. You have not changed a production interface, imported a Cisco image or applied a persistent physical-device configuration.
- Why this step matters
- Explicit cleanup prevents the practice fault from being mistaken for the intended baseline when the project is opened again.
Verify
- The drawing and topology contain PC1, Switch1, Switch2 and PC2 with all three named links and no external connection.
- PC1 is 192.168.6.10/24 and PC2 is 192.168.6.20/24; each ping targets the other endpoint, never itself.
- Record remote replies before removal, no replies with the only inter-switch link absent, and replies after restoring that exact link.
- Keep paper media choices and hypothetical counters labeled separately from actual VPCS observations.
- Do not claim that a green node icon, successful ping or zero hypothetical counter proves physical hardware quality.
Troubleshoot
- If a console does not open, check that the intended VPCS node is started and the GNS3 console application is configured. Built-in Ethernet switches do not expose an IOS console.
- For repeated baseline loss, compare both show ip results with the table, inspect every link endpoint and confirm default access VLAN 1 on the built-in switches. Do not introduce the fault until the baseline works.
- One initial timeout may reflect address discovery, but persistent loss requires investigation. On real networks, host firewalls, ICMP filtering and rate limiting can also affect ping; do not diagnose a layer from ping alone.
- If recovery fails, check that Switch1 Ethernet1 reconnects to Switch2 Ethernet0. Keep the endpoint addresses and remaining links unchanged so the test stays controlled.
- Physical CRC, optical power and duplex mismatch are not measured here. Use the cited platform documentation and suitably equipped, authorized hardware for those observations; never invent virtual readings.
- Perform troubleshooting only inside the isolated lab. Do not bridge the project to a physical network to make a failed exercise work.
GNS3 does not provide Cisco software images. Use a Cisco image only when the applicable Cisco license or entitlement legally permits that use, and do not share or redistribute Cisco image files. Cisco CML reference-platform images are licensed for use within CML unless a separate license permits outside use. Cisco Modeling Labs is the official alternative; built-in VPCS and Ethernet switch nodes do not require a Cisco image.
- Restore exactly the three baseline links and keep the project isolated from shared or production traffic.
- Save the baseline, failure and recovery notes in Day6-baseline.txt. GNS3 automatically saves the topology as you work; do not look for a separate topology Save button.
- Stop the project when finished. Re-enter the documented VPCS addresses after reopening if they were not retained; never save unrelated production changes.
Practice set
Answer before you reveal
01What should you record before choosing copper or fiber?
A connector that fits is not enough evidence. List unknowns and check the actual device documentation before claiming that a particular media combination will work.
02What does full duplex describe, and what does it not guarantee?
Separate a link's operating property from the result of an end-to-end application test. Two healthy full-duplex interfaces can still be part of a path with another bottleneck.
03Why must this lesson not force a Cisco gigabit link to half duplex?
A configuration example must respect the platform and speed's capabilities. The built-in GNS3 switches also do not provide the physical negotiation behavior needed to measure this fault.
04A CRC total rises from 12 to 27. How many additional errors were recorded?
Subtract the earlier cumulative total from the later one. Keep the observation interval and traffic context, and investigate the cause instead of treating the total as a diagnosis.
05Which Cisco command family helps inspect an identified interface?
For example, show interfaces GigabitEthernet1/0/1 inspects that particular port where it exists. Do not type IOS commands into VPCS or assume the example port exists on every device.
06What can you conclude from the link-removal experiment?
That controlled observation does not prove a real cable's category, an optical receiver's power or a duplex setting. The lesson keeps those hardware questions in separate paper exercises.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Select supported media using actual connection requirements and equipment specifications.
- Inspect both link ends; do not force unsupported gigabit half-duplex operation.
- Compare counter increases with recorded timestamps rather than expecting totals to reset after a correction.
- A ping tests one request-and-reply exchange, not cable quality or application throughput.
- Use an isolated, single-change experiment and repeat the same tests after recovery.
- Keep virtual connectivity observations separate from physical-media paper examples.