First, the essential ideas
- IPv4 address and prefix
- An IPv4 address has 32 bits, usually written as four decimal numbers. A prefix such as /24 states how many leading bits identify the subnet.
- Subnet and interface
- A subnet is an address block defined by a network address and prefix. An interface is a device's network connection; each routed interface belongs to its configured subnet.
- Default gateway and route
- A route tells a device where to send traffic for a destination. A host's default gateway is its local router address for destinations without a more specific route.
- Packet and frame
- An IP packet carries source and destination IP addresses. An Ethernet frame carries a packet across one local link using link-layer addresses.
- MAC address and ARP
- A MAC address identifies an Ethernet interface on a local link. Address Resolution Protocol, or ARP, discovers the MAC address associated with a local IPv4 next hop.
- ICMP and ping
- Internet Control Message Protocol carries IP control messages. Ping sends echo requests and checks for echo replies; a reply requires both outward and return paths.
- VPCS and Console
- VPCS means Virtual PC Simulator, GNS3's lightweight practice computer. Console is its text window: right-click the named node and choose Console before typing.
- Router command modes
- A router prompt ending in > is user EXEC mode; enable enters privileged EXEC mode, shown by #. Configure terminal enters configuration mode, shown by (config)#.
- DHCP and APIPA
- DHCP can supply an address, mask and gateway automatically. APIPA is Windows terminology for automatic private IP addressing using IPv4 link-local addresses when appropriate configuration is unavailable.
- Address scope
- The intended reach of an address, such as one local link, an organization's internal networks, or global communication. Scope alone does not prove a working or secure path.
- Baseline and rollback
- A baseline records intended settings and working observations. Rollback restores those exact settings after a controlled test, then repeats the original checks.
- NAT and firewall
- Network Address Translation changes address information in traffic. A firewall applies traffic policy; having a private address is not the same as having an effective firewall policy.
Begin with the words below. This lesson asks two separate questions: what is an address intended for, and does this particular configured path work? Classifying an address cannot answer the second question. We will record settings, test a working path, change one setting and compare the result without touching a real network.
See the idea
A reply needs the right gateway
PC1 and PC2 use different local gateways on Router1; a remote ping needs a working return path as well as an outward path.
PC1 chooses its gateway
PC2 is outside PC1's /24. PC1 sends the packet toward local gateway 192.168.11.1, while the packet's destination remains PC2 at 192.168.12.10.
What this model leaves out: Only the disconnected PC1-Router1-PC2 path is shown. Internet access, DHCP, APIPA selection and firewall policy are omitted because this lab tests static addressing and a wrong return gateway.
Full visual explanation and references
PC1 sends through Router1 to PC2, which replies through Router1 to PC1. The outward diagram ends at PC2; the return stage reverses the same two links.
Only the disconnected PC1-Router1-PC2 path is shown. Internet access, DHCP, APIPA selection and firewall policy are omitted because this lab tests static addressing and a wrong return gateway.
- PC1 chooses its gateway
PC2 is outside PC1's /24. PC1 sends the packet toward local gateway 192.168.11.1, while the packet's destination remains PC2 at 192.168.12.10.
www.rfc-editor.orgwww.cisco.com - Router1 forwards to PC2
Router1 selects its connected 192.168.12.0/24 network and sends a new Ethernet frame to PC2. The outward path ends at PC2, not at the router.
www.rfc-editor.org - PC2 needs a return route
PC2 replies via 192.168.12.1 and Router1 to PC1. Replacing that gateway with unused 192.168.12.254 breaks the reply path; restoring .1 restores the intended route.
www.rfc-editor.org
One idea at a time
Start with something familiar.
You do not need to know router commands yet. Read the introductory definitions, then identify PC1, Router1 and PC2 in the drawing. A command belongs to the named virtual device's Console window, not to PowerShell, Terminal or your physical computer's network settings.
Why learn this?
A computer can have a plausible-looking address and still fail to reach another network. Separating address purpose, local connectivity and the return route helps you collect useful evidence before changing unrelated equipment.
An everyday comparison
As a memory aid, picture rooms within two buildings and a reception desk that directs visitors between buildings. This is an organizational metaphor, not a literal description of packets or devices.
What happens in a network
The host checks whether the destination belongs to its local subnet. For a remote destination in this simple example, it uses the local router as its next hop; the destination IP remains the remote host's address.
Where the comparison stopsNetworks use addresses, masks and routing decisions, not human directions. The analogy does not explain MAC learning, ARP, access controls or why a return route might differ.
Follow one worked example
- Read the address, prefix and gateway together.
PC1 uses 192.168.11.10/24 with gateway 192.168.11.1. Its target PC2 uses 192.168.12.10/24, so the target is not on PC1's local /24 subnet.
Why: The prefix supplies the boundary needed for the local-versus-remote decision; the address alone is incomplete evidence.
- Identify the local next hop without changing the destination.
PC1 sends the packet toward Router1's local interface. Router1 routes it through its other interface and places it in a new Ethernet frame addressed to PC2.
Why: The packet is for PC2, while the Ethernet next hop changes across the router; these are different addressing jobs.
- Trace PC2's reply as a separate decision.
PC2 also sees a remote destination when replying to PC1. With gateway 192.168.12.1, it can send the reply to Router1; a nonexistent gateway cannot provide that return route.
Why: Seeing an outward request is not enough to call a ping successful. A corresponding reply must reach the sender.
- Change one lab setting, then restore and repeat.
After a working baseline, change only PC2's gateway to 192.168.12.254, repeat the same PC1 ping, restore .1, and repeat it again. Record what you actually observe.
Why: One controlled change makes the comparison meaningful; unexpected results call for investigation, not an invented success record.
Your first small task
On paper, sort 10.4.8.2, 172.20.3.4, 172.32.3.4, 192.168.5.6 and 169.254.8.9. Label known private or link-local examples; do not send traffic to any of these sample addresses.
Show a hint
Compare the entire prefix range, especially the second number in the 172.16.0.0/12 allocation.
Check the expected result
The first, second and fourth are private; the last is link-local. 172.32.3.4 is outside RFC 1918, which alone does not establish ownership or reachability.
Pause and explain it in your own words
PC2 can reach its local router but a remote ping fails after its gateway changes. What should you check next?
Show a hint
Reaching the local router does not require using the default route that a remote reply needs.
Show the explanation
Compare PC2's gateway with the baseline and trace the reply destination. Restore the correct gateway in this lab, then rerun the identical cross-subnet test rather than declaring the router broken.
Short answer
What should you understand today?
Classify an IPv4 address before deciding how it should be used, then check its prefix and gateway. Private addresses can communicate across internal routers, but IPv4 link-local addresses stay on their link. In this lab, changing PC2's gateway breaks the return path for a cross-subnet ping; restoring it restores the intended path.
Before you begin
Learning targets
- Complete Days 8-10, or review how an IPv4 address and /24 prefix identify a subnet.
- Have GNS3 working with two built-in VPCS nodes and an authorized Cisco router template with two routed Ethernet interfaces.
- Use a new disconnected project and have legal permission to run its Cisco image in GNS3; otherwise use the paper exercise or Cisco Modeling Labs.
- Keep notes in Notepad on Windows, TextEdit on macOS or a plain-text editor on Linux; no operating-system terminal commands are required.
- Recognize the three RFC 1918 private IPv4 blocks without treating every 172 address as private.
- Explain why a non-private address is not automatically a globally usable address.
- Separate an IPv4 link-local observation from an unsupported claim that a DHCP server has failed.
- Test the local gateway, the remote endpoint and the return path in an isolated two-subnet lab.
- Restore a deliberately wrong gateway and record the same successful baseline checks again.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
IPv4 address and prefix
An IPv4 address has 32 bits, usually written as four decimal numbers. A prefix such as /24 states how many leading bits identify the subnet.
Subnet and interface
A subnet is an address block defined by a network address and prefix. An interface is a device's network connection; each routed interface belongs to its configured subnet.
Default gateway and route
A route tells a device where to send traffic for a destination. A host's default gateway is its local router address for destinations without a more specific route.
Packet and frame
An IP packet carries source and destination IP addresses. An Ethernet frame carries a packet across one local link using link-layer addresses.
MAC address and ARP
A MAC address identifies an Ethernet interface on a local link. Address Resolution Protocol, or ARP, discovers the MAC address associated with a local IPv4 next hop.
ICMP and ping
Internet Control Message Protocol carries IP control messages. Ping sends echo requests and checks for echo replies; a reply requires both outward and return paths.
VPCS and Console
VPCS means Virtual PC Simulator, GNS3's lightweight practice computer. Console is its text window: right-click the named node and choose Console before typing.
Router command modes
A router prompt ending in > is user EXEC mode; enable enters privileged EXEC mode, shown by #. Configure terminal enters configuration mode, shown by (config)#.
DHCP and APIPA
DHCP can supply an address, mask and gateway automatically. APIPA is Windows terminology for automatic private IP addressing using IPv4 link-local addresses when appropriate configuration is unavailable.
Address scope
The intended reach of an address, such as one local link, an organization's internal networks, or global communication. Scope alone does not prove a working or secure path.
Baseline and rollback
A baseline records intended settings and working observations. Rollback restores those exact settings after a controlled test, then repeats the original checks.
NAT and firewall
Network Address Translation changes address information in traffic. A firewall applies traffic policy; having a private address is not the same as having an effective firewall policy.
Start with scope, then test the path
An address is a setting, not a health certificate. First record the complete address and prefix. Next identify its intended scope, the local network connection and the expected next hop. Finally collect observations for a named destination. Keep these questions separate in your notes: a correctly classified private address can still have a wrong mask, and a correctly configured host can encounter a filtering rule elsewhere. A successful ping answers a narrow question about an ICMP exchange at that time, not whether a website, file transfer or security policy is healthy.
- Write the address and prefix together before classifying or testing it.
- Name the target and the observed result; do not substitute a general health claim.
Recognize private addresses without guessing
RFC 1918 reserves three private blocks: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The middle block includes second-octet values 16 through 31, not every address beginning with 172. Organizations may route these addresses internally. They are not globally unique public allocations, and two independent organizations can choose overlapping private ranges. Private addressing does not itself enforce security policy; translating an address also does not replace a reviewed access policy. Treat scope and protection as separate design decisions.
- The private 172 range ends at 172.31.255.255, not 172.255.255.255.
- Private addresses may be routed inside an organization; private does not mean unreachable or protected.
Outside private space does not automatically mean public
Use a classification checklist instead of the rule that anything outside RFC 1918 is public. IPv4 has special-purpose blocks with different permissions and reach. Examples include loopback 127.0.0.0/8, shared provider space 100.64.0.0/10 and documentation space such as 192.0.2.0/24. The special-purpose registry records distinctions such as whether a block is forwardable or globally reachable. Even an ordinary public allocation needs appropriate ownership, routing and policy before it can be used or reached. Never test a random real-world address merely because it looks public.
- Not private is an incomplete classification, not proof of global usability.
- Public scope does not prove reachability, ownership or permission to test a device.
Understand link-local and APIPA as evidence
IPv4 link-local uses 169.254.0.0/16 for communication on one link and is not forwarded by routers. APIPA is the Windows name commonly associated with automatic use of this space when suitable configuration is unavailable. Seeing a link-local address should trigger an evidence check, not a declaration that a DHCP server is definitely down. The client, its link, the network path or an intended configuration may explain the observation. In this lesson, link-local is a paper comparison only: manually assigning a 169.254 address to VPCS would not demonstrate Windows APIPA or its address-selection process.
- A link-local address is not a substitute for an ordinary routed address and gateway.
- Our static VPCS experiment does not simulate APIPA, DHCP leasing or a wireless connection.
A gateway serves the next hop, not the final destination
A host with no more specific route uses its default gateway for a remote destination. In this lab, each gateway is the router interface on that host's own subnet. PC1's IP packet remains addressed to PC2; PC1 uses ARP to learn the local next hop's MAC address. Router1 processes the packet and sends it in a new Ethernet frame on the other link. PC2 needs its own route for the reply. A wrong return gateway can therefore prevent a complete exchange even when Router1 can deliver the original request. The router does not need an Internet default route here because both destination subnets are directly connected.
- Keep the final IP destination distinct from the local Ethernet next hop.
- Check the return path as carefully as the outward path when interpreting ping.
Use a baseline, one fault and a verified rollback
Perform the hands-on exercise only in the disconnected practice project. First show that both local gateways and both directions of cross-subnet communication work. Record the addresses, mapped interfaces and actual outputs. Only then change PC2's gateway. Repeat exactly the earlier PC1-to-PC2 ping and expect failure because the reply cannot use its intended return path. Restore PC2's original gateway and repeat that same check. Do not attribute success to a fresh ARP cache or treat a received request without a reply as a successful ping. Outside this controlled test, missing replies can also reflect filtering, host settings, links or rate limiting.
- Change only one setting after a verified baseline, then restore it explicitly.
- Expected results are predictions for the learner to test, not a claim that QCS executed the virtual lab.
Choose a lawful lab platform
GNS3 supplies the environment, not a general right to use Cisco software. Check the applicable license before installing any Cisco image. Cisco Modeling Labs is an official alternative with its own included platforms and licensing terms; its reference images are licensed for use within CML unless separately permitted. Older community instructions are not a replacement for current license conditions. If you lack an entitled router image for GNS3, do the paper trace now and use an authorized platform later. The addressing and return-path reasoning remain useful without pretending a paper result is a measured lab result.
- Use only a Cisco image that the applicable license permits in your chosen environment.
- A paper exercise is a valid learning alternative, but it is not an executed device test.
Real-world walkthrough
A workstation reaches its router but not another subnet
An operator has a report that a workstation can reach its local router but cannot complete a ping to a remote test workstation. Instead of restarting equipment, the operator records both workstations' addresses, masks and gateways, and compares them with the approved baseline. In our isolated reproduction, the only deliberate change is PC2's gateway. In real networks, host firewalls, filtering, link faults and rate limits are other possible causes, so this example must not become a universal diagnosis.
- Name the expected endpoints and obtain permission before any real-world testing; this lesson's commands belong only to the disconnected lab.
- Compare PC1 and PC2 with the addressing table, including their /24 prefixes and the router interface on each local subnet.
- Confirm each host reaches its own local gateway before relying on a cross-subnet result.
- Repeat the named PC1-to-PC2 test and reason separately about the reply that PC2 must send back to PC1.
- In the lab, restore PC2 from 192.168.12.254 to its recorded gateway 192.168.12.1 and rerun exactly the same test.
- Record the observations and the change made; do not expand an ICMP success into a claim about every application or security control.
Guided GNS3 lab
Break and restore one return gateway
Build a disconnected two-subnet path, establish a working baseline, change only PC2's gateway, observe a failed cross-subnet ping, and restore and verify the original configuration.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| PC1 | Ethernet0 | 192.168.11.10/24 | Source endpoint; gateway 192.168.11.1. |
| Router1 | LAN1: GigabitEthernet0/0 | 192.168.11.1/24 | Mapped router interface connected to PC1. |
| Router1 | LAN2: GigabitEthernet0/1 | 192.168.12.1/24 | Mapped router interface connected to PC2. |
| PC2 | Ethernet0 | 192.168.12.10/24 | Destination endpoint; gateway 192.168.12.1. |
Set up the lab
- Create a new GNS3 project named Day11-Gateway. Use no Cloud, NAT or bridge to a physical adapter. Perform every test only in this disconnected lab, never on shared or production networks.
- Before router installation, confirm legal permission to use its image in GNS3. Use your authorized router appliance template, not an Ethernet-switch template. If none is available, use the paper trace or Cisco Modeling Labs instead; its console and host commands differ from this GNS3 procedure.
- Drag two built-in VPCS nodes from the device list and rename them PC1 and PC2. Add the authorized router and rename it Router1. The router must expose two routed Ethernet ports and accept the IOS IPv4 commands below.
- Using Add a link, connect PC1 Ethernet0 to the first chosen Router1 port and its second chosen port to PC2 Ethernet0. Record the port names shown by GNS3 and turn on interface labels. Start the nodes with the green Start control.
- Right-click Router1 and choose Console. If an initial setup dialog appears on this new lab router, answer no and press Enter for the prompt. If a password or unfamiliar preexisting configuration appears, stop and obtain the authorized lab baseline rather than bypassing it.
- Open Notepad on Windows, TextEdit in plain-text mode on macOS, or a Linux text editor. Create Day11-baseline.txt and record the project, exact cable endpoints, interface mapping, addresses and observed test results.
- Interface mapping example: if the PC1 cable ends at GigabitEthernet0/0/0, use that as LAN1 wherever the example says GigabitEthernet0/0. If PC2 ends at GigabitEthernet0/0/1, use that as LAN2 instead of GigabitEthernet0/1. Confirm names against both GNS3 link labels and show ip interface brief; never guess.
Inspect Router1 before changing it
Right-click Router1 and choose Console before typing. Press Enter for the prompt; use enable if it ends in >. Inspect the existing configuration and copy the two exact interface names into your baseline. If a name is missing or already belongs to another purpose, stop and correct the template or mapping first.
enable
show ip interface brief
show running-configWhat each command means
enable- Enter privileged EXEC mode, indicated by a prompt ending in #; if already at #, this repeats the same mode.
show ip interface brief- List IPv4 interface names, addresses and status so they can be matched to the two GNS3 cable endpoints.
show running-config- Display the existing configuration for the baseline; press Space if output pauses at a More prompt.
- What you should see
- Both intended routed Ethernet interfaces are listed and mapped to the correct cable endpoints. Record the initial state, even if the fresh interfaces are administratively down.
- Why this step matters
- The same-looking interface name on a different template can mean another port; a verified mapping prevents configuration on the wrong link.
Configure the two mapped router ports
Right-click Router1 and choose Console before typing. At the # prompt, configure only the mapped LAN1 and LAN2 ports. Replace each example interface name using your verified baseline mapping. The shutdown state is an administrative setting; no shutdown enables the selected lab interface.
configure terminal
interface GigabitEthernet0/0
ip address 192.168.11.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
no shutdown
end
show ip interface brief
show ip route connectedWhat each command means
configure terminal- Enter global configuration mode, where the prompt includes (config).
interface GigabitEthernet0/0- Select the verified LAN1 port connected to PC1; substitute the actual mapped name if different.
ip address 192.168.11.1 255.255.255.0- Assign LAN1 the router address 192.168.11.1 with the /24 mask.
no shutdown- Administratively enable this isolated LAN1 interface.
exit- Leave interface mode and return to global configuration mode.
interface GigabitEthernet0/1- Select the verified LAN2 port connected to PC2; substitute its actual mapped name if different.
ip address 192.168.12.1 255.255.255.0- Assign LAN2 the router address 192.168.12.1 with the /24 mask.
no shutdown- Administratively enable this isolated LAN2 interface.
end- Return to privileged EXEC mode, shown by a prompt ending in #.
show ip interface brief- Check that both addresses are on the intended ports and that each shows up/up after its endpoint starts.
show ip route connected- Check that the router has connected routes for 192.168.11.0/24 and 192.168.12.0/24.
- What you should see
- Both mapped ports show the intended addresses and up/up state, and both /24 networks appear as connected routes. Investigate a missing route or down state before continuing.
- Why this step matters
- These two connected routes support the lab's routing; an Internet default route is neither needed nor configured.
Set PC1's baseline
Right-click PC1 and choose Console before typing. Confirm the window belongs to PC1 and shows a VPCS prompt. Enter its address, prefix and local gateway, then copy the displayed values into the baseline file. Do not type these commands on Router1 or your physical computer.
ip 192.168.11.10/24 192.168.11.1
show ipWhat each command means
ip 192.168.11.10/24 192.168.11.1- Set PC1's static IPv4 address and its local default gateway in VPCS.
show ip- Display PC1's current settings to catch a mistyped address, mask or gateway.
- What you should see
- PC1 displays 192.168.11.10/24 and gateway 192.168.11.1; its own address is not either ping target used later.
- Why this step matters
- A visible configuration check avoids testing with a setting that was assumed rather than actually applied.
Set PC2's baseline
Right-click PC2 and choose Console before typing. Confirm PC2's VPCS prompt, apply its own distinct address and local gateway, then record the output. This is a different subnet from PC1, not a second address on PC1.
ip 192.168.12.10/24 192.168.12.1
show ipWhat each command means
ip 192.168.12.10/24 192.168.12.1- Set PC2's address on LAN2 and its correct local default gateway.
show ip- Display PC2's address, prefix and gateway for comparison with the addressing table.
- What you should see
- PC2 displays 192.168.12.10/24 and gateway 192.168.12.1. The two endpoint addresses and the router addresses are distinct.
- Why this step matters
- Correct reply routing begins with the receiving host's own settings, not just the sender's settings.
Check PC1's local gateway
Right-click PC1 and choose Console before typing. Ping the router address on PC1's own subnet, not PC1's own address. Record replies or missing replies. If the first attempt is lost while local address resolution occurs, repeat; persistent loss must be resolved before adding a fault.
ping 192.168.11.1What each command means
ping 192.168.11.1- Send ICMP echo requests to Router1's LAN1 address and observe whether echo replies return.
- What you should see
- The local router replies. If it does not, stop to check the address, cable, interface mapping and interface state.
- Why this step matters
- A local gateway check establishes the near side without yet claiming that a remote subnet or application is reachable.
Check PC2's local gateway
Right-click PC2 and choose Console before typing. Test its local Router1 address and record the observation. This check uses the local link and does not establish that PC2's default route works for remote reply destinations.
ping 192.168.12.1What each command means
ping 192.168.12.1- Send echo requests from PC2 to Router1's LAN2 interface, not to PC2's own address.
- What you should see
- The LAN2 router interface replies. Resolve persistent failure before starting the cross-subnet comparison.
- Why this step matters
- Both local sides must work before a deliberate gateway fault can be interpreted cleanly.
Record the outward baseline
Right-click PC1 and choose Console before typing. Ping the actual remote PC2 address 192.168.12.10 and record the result. Confirm in your notes that this differs from PC1's own 192.168.11.10; a self-ping would not exercise Router1.
ping 192.168.12.10What each command means
ping 192.168.12.10- Test an ICMP exchange from PC1 through Router1 to PC2 and back through the correct return gateway.
- What you should see
- Replies arrive from PC2 after ordinary initial address resolution. Persistent failure means the baseline is not ready; do not proceed to the fault.
- Why this step matters
- The deliberate failure will be compared with this exact target and sender, not a different test.
Record the reverse baseline
Right-click PC2 and choose Console before typing. Ping PC1's remote address and record the result alongside the preceding test. If either direction is persistently unsuccessful, fix the baseline settings and links before continuing.
ping 192.168.11.10What each command means
ping 192.168.11.10- Test an echo exchange initiated by PC2 to PC1, independently checking the opposite direction.
- What you should see
- PC1 replies, establishing a working baseline for both directions in this isolated topology.
- Why this step matters
- A second direction provides a clearer baseline than assuming the first observation describes every possible initiation.
Introduce one wrong gateway
Right-click PC2 and choose Console before typing. Change only the gateway to the intentionally unused 192.168.12.254. Keep PC2's address and /24 prefix unchanged, and check the displayed settings. This is a controlled fault inside the disconnected lab only.
ip 192.168.12.10/24 192.168.12.254
show ipWhat each command means
ip 192.168.12.10/24 192.168.12.254- Replace PC2's gateway with a nonexistent next hop while retaining its own address and prefix.
show ip- Confirm that PC2 now displays the deliberately wrong gateway .254 and the unchanged host address.
- What you should see
- PC2 shows gateway 192.168.12.254. No node in this lab owns that address, so it cannot provide PC2's return route to PC1.
- Why this step matters
- Changing one field isolates the hypothesis and leaves a simple, explicit rollback.
Observe the broken return path
Right-click PC1 and choose Console before typing. Repeat the identical ping to 192.168.12.10. Expect failure: PC2 cannot send the reply toward remote PC1 through its nonexistent gateway. Do not record success from a delivered request without a returned reply.
ping 192.168.12.10What each command means
ping 192.168.12.10- Repeat the baseline test while PC2 has the wrong gateway; the requested echo reply lacks its intended return path.
- What you should see
- The cross-subnet ping fails. If replies unexpectedly continue, stop and verify PC2's actual settings, the target and every node before drawing a conclusion.
- Why this step matters
- A fresh ARP cache does not make this wrong-gateway configuration a valid success; the intended reply path is broken.
Restore PC2's original gateway
Right-click PC2 and choose Console before typing. Restore the exact baseline gateway 192.168.12.1, keeping the address and prefix unchanged. Display the settings and compare all three fields with your saved baseline before retesting.
ip 192.168.12.10/24 192.168.12.1
show ipWhat each command means
ip 192.168.12.10/24 192.168.12.1- Restore the real Router1 LAN2 address as PC2's default gateway.
show ip- Verify the restored address, mask and gateway against the baseline record.
- What you should see
- PC2 again shows 192.168.12.10/24 and gateway 192.168.12.1, with no .254 gateway remaining.
- Why this step matters
- Rollback is a confirmed configuration change, not simply closing a console or assuming a restart fixed it.
Repeat the original test after rollback
Right-click PC1 and choose Console before typing. Repeat the same ping to PC2 and record the result in the restored row of your evidence table. The sender, destination, topology and prefixes must match the original baseline.
ping 192.168.12.10What each command means
ping 192.168.12.10- Repeat the original PC1-to-PC2 echo exchange after restoring PC2's return gateway.
- What you should see
- PC2 replies again. If persistent failure remains, compare all saved settings and inspect links rather than claiming rollback succeeded.
- Why this step matters
- An identical post-change check establishes whether the intended behavior was restored, not merely whether a command was accepted.
Verify the reverse path is restored
Right-click PC2 and choose Console before typing. Repeat its original ping to PC1. Save the observation in your notes; keep actual output separate from the expected result printed in this lesson.
ping 192.168.11.10What each command means
ping 192.168.11.10- Repeat the reverse baseline test using PC2's restored local gateway.
- What you should see
- PC1 replies, matching the earlier reverse-direction baseline in the isolated lab.
- Why this step matters
- Both baseline directions should be rechecked before declaring this controlled exercise finished.
Verify
- The diagram, GNS3 links and notes name exactly PC1, Router1 and PC2, with no physical-network bridge or hidden extra gateway.
- The two router interfaces match both the link endpoints and the names printed by show ip interface brief; both connected /24 routes exist.
- Each endpoint reaches its own local gateway, and cross-subnet baseline tests receive replies in both directions.
- The wrong-gateway test changes only PC2 to 192.168.12.254 and makes the same PC1-to-PC2 ping fail because of the broken return path.
- Restoring PC2 to gateway 192.168.12.1 is followed by the same successful baseline checks, with actual observations recorded.
- No ping targets are the sending PC's own address, and no ICMP result is treated as proof of application health or firewall effectiveness.
Troubleshoot
- Perform these checks only in the disconnected lab, never on production or shared networks. If a router interface is missing, compare the template and GNS3 cable endpoints before issuing configuration commands; do not guess a substitute.
- Administratively down indicates the selected interface is disabled. Right-click Router1 and choose Console before typing; after confirming the baseline mapping, use configure terminal, interface followed by the exact mapped name, no shutdown and end. If it remains down/down, check the cable endpoint and that the attached VPCS node is started.
- A missing echo reply is not proof of a failed OSI layer. In broader networks, ICMP filtering, host firewalls, link problems or rate limits can prevent replies; the deliberately isolated single-change test narrows the explanation only within its declared boundary.
- If the wrong-gateway test unexpectedly succeeds, right-click PC2 and choose Console before typing show ip. Confirm .254 really replaced .1, verify the destination is PC2 rather than a self-test, and look for an extra node or configuration outside the stated project.
- If baseline pings never worked, do not add more faults. Verify both masks, both local gateway addresses, both routed ports and the two connected routes, then establish a baseline first.
- A 169.254 address observed on a real workstation is a clue about link-local use, not proof that a particular DHCP server failed. Document the approved configuration and link state before escalating; this static VPCS lab cannot validate that DHCP diagnosis.
GNS3 does not provide Cisco software images. Use Cisco images only when the applicable license permits use in that environment; do not share or redistribute Cisco image files. Cisco Modeling Labs is the official alternative. Its reference images are licensed for use within CML unless separately permitted; a CML subscription alone does not authorize exporting them to GNS3.
- Perform rollback only in the disconnected lab. Confirm PC2's gateway is restored to 192.168.12.1 and both baseline directions work before stopping the nodes.
- Keep Day11-baseline.txt with the actual interface mapping, original settings, controlled change and observed results. Do not replace observations with the lesson's expected text.
- Stop the three nodes with the red Stop control. Preserve the project if you need to revisit it, or remove only this disposable Day11-Gateway project after verifying its name; do not reset unrelated devices.
- Do not share or redistribute Cisco image files with the project. The commands and your own notes may be kept separately from licensed software.
Practice set
Answer before you reveal
01Which private block contains 172.20.3.4, and does it also contain 172.32.3.4?
The second octet runs from 16 through 31 in this private block. Being outside that block still does not prove a particular address is reachable or authorized for your use.
02Why can two companies using the same private subnet have a problem when their networks are joined?
Private addresses are reusable, not globally unique allocations. Record the overlap and design an approved interconnection plan instead of assuming that adding a cable or router removes the conflict.
03Does observing 169.254.8.9 prove that the DHCP server has crashed?
The client, link, configuration or DHCP path may explain the observation. Gather the intended settings and actual evidence before assigning blame; this lesson does not simulate DHCP.
04Why is PC1's default gateway 192.168.11.1 rather than Router1's 192.168.12.1 address?
PC1 belongs to 192.168.11.0/24. Router1's LAN1 interface is local to it; LAN2 belongs to the other subnet and is not the appropriate directly reachable next hop for PC1.
05PC2 reaches 192.168.12.1 even with gateway .254. Why can the remote ping still fail?
A local-subnet exchange does not test the default route. In the declared lab, the remote echo reply cannot use the nonexistent .254 next hop; this is not a successful one-way ping.
06What three observations make the deliberate gateway experiment useful?
Keep the source, destination and topology constant and record real output. This supports the limited lab conclusion without asserting that every real-world ping failure has the same cause.
07May a CML image automatically be copied to GNS3 because you have a CML subscription?
Cisco's CML reference images are licensed for CML unless separately permitted. GNS3 does not supply Cisco images; use an authorized platform or a clearly labeled paper exercise.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Classify the address purpose, then separately verify the configured path.
- Private IPv4 space is reusable and internally routable, not a security policy.
- IPv4 link-local addresses stay on their link; a link-local observation is not a complete DHCP diagnosis.
- A host's local gateway is a next hop, while the packet still names its final destination.
- A cross-subnet ping needs a reply path; test the wrong gateway and rollback as distinct steps.
- Use authorized lab software, keep experiments disconnected, and distinguish predictions from actual observations.