First, the essential ideas
- Layer and model
- A layered model is a diagram or checklist that organizes troubleshooting steps by grouping related network jobs. A layer is one such group. The OSI model has seven layers; the four-layer TCP/IP model groups jobs differently. Models structure questions; they do not detect or indicate a fault on their own and are not physical boxes.
- OSI and TCP/IP
- Open Systems Interconnection (OSI) describes physical, data link, network, transport, session, presentation and application jobs. This lesson uses four TCP/IP layers: link, internet, transport and application. Some teaching sources split link into physical and data link, giving five layers. These are grouping conventions, not different networks. TCP/IP means Transmission Control Protocol/Internet Protocol.
- Frame and packet
- A frame carries data across one local link. An IP packet carries data toward an IP destination, inside a frame on Ethernet. A router reads the destination IP and builds a new outgoing frame; a switch forwards local frames.
- Address and gateway
- An IP address identifies a network interface. With /24, the first three octets (numbers) identify the network: 192.168.1.x uses mask 255.255.255.0. A default gateway is the local router address used to reach another network. A MAC address identifies an Ethernet interface on a local link.
- Interface and segment
- An interface is a device connection such as GigabitEthernet0/0. A local Ethernet segment lets devices exchange frames without routing. Router separates the two IP networks. Administratively down means an interface is disabled by configuration; no shutdown enables that mapped port but does not repair a cable. Up/up is local physical and protocol status, not proof of end-to-end delivery.
- VPCS and Console
- Virtual PC Simulator (VPCS) is GNS3's lightweight practice computer. A Console is its text-control window: right-click the node and choose Console. A prompt such as PC1> means it is ready. Type only the command, then press Enter. The built-in Switch has no IOS console.
- Router command modes
- The router's prompt may use its configured hostname. A > prompt is user EXEC; enable opens privileged EXEC (#), which permits inspection and changes. configure terminal enters (config)#; interface selects (config-if)#. exit goes back one level; end returns to #. Never type the prompt.
- Ping and ICMP
- Ping sends an Internet Control Message Protocol (ICMP) echo request and waits for an echo reply. ICMP belongs with IP at the TCP/IP internet layer, not TCP/UDP transport. A host is a network-connected computer. No reply means the exchange timed out, not proof of a failed layer. Host settings, filters and either path direction can affect it. A self-ping tests the local IP stack, not the peer path; a reply does not prove application health.
- ARP and intermittent loss
- Address Resolution Protocol (ARP) finds a local Ethernet MAC address for an IPv4 next hop. An initial request can time out during discovery. Repeat the same peer test; intermittent loss can also reflect links, load or filtering. Persistent failure needs evidence, not a guess.
- ACL number and name
- An ACL is an ordered permit/deny rule list. access-list 199 identifies a numbered list; ip access-list extended LAB_FILTER identifies a named list. An ip access-group line binds a list to an interface: in means arriving through that port, out means leaving. A rule's sequence number is not its ACL identifier. A per-rule match counter counts matched packets since initialization or clearing, not the number of rules; availability varies by image.
- Baseline and rollback
- A baseline records the known configuration, cabling and successful tests before a change. Running-config is active; startup-config is the saved boot configuration. Rollback returns only our changes to that recorded state. Copying startup-config into running-config merges settings; it is not a reliable rollback.
- Filtering boundary
- This router ACL checks ICMP and IP addresses, not TCP/UDP port numbers or application health. After the specific deny, permit ip any any permits other IPv4 traffic evaluated by this ACL. It does not create routes or expose services by itself. Use this permissive teaching policy only in the fully disconnected lab; never copy it to a production or shared network.
Use these definitions before the diagram, walkthrough or commands. First establish a working peer exchange, then change one known rule and compare observations. An analogy can help remember a job, but it is not literal forwarding behavior. Our checklist narrows possibilities; it does not prove a faulty layer from one symptom.
See the idea
Packet Journey
Trace the peer exchange and collect evidence. A missing reply does not identify a faulty layer by itself.
PC1 sends to PC2
PC1 reaches Router's LAN1 through Switch. Router builds a new Ethernet frame on LAN2 for PC2. The request's IP addresses remain PC1 to PC2; Router's LAN2 IP is not the source IP. See the address table.
What this model leaves out: This wired IPv4 lab tests an ICMP exchange and one router ACL. It omits wireless, Internet services and application traffic because they are outside this isolated path.
Full visual explanation and references
PC1 sends through Switch and Router to PC2; the reply follows the reverse path. The request path ends at PC2, not Router.
This wired IPv4 lab tests an ICMP exchange and one router ACL. It omits wireless, Internet services and application traffic because they are outside this isolated path.
- PC1 sends to PC2
PC1 reaches Router's LAN1 through Switch. Router builds a new Ethernet frame on LAN2 for PC2. The request's IP addresses remain PC1 to PC2; Router's LAN2 IP is not the source IP. See the address table.
www.rfc-editor.org - PC2 replies to PC1
PC2 uses gateway 192.168.2.1 to return through Router and Switch to PC1. Replies confirm this ICMP exchange, not a working website or every application.
www.cisco.com - Check Router filtering
ACL 199 blocks PC1's echo request at Router's LAN1 input; PC2 does not receive it or generate a reply. The rule does not deny replies arriving on LAN2. Compare counters and use the lab's ownership-checked rollback.
www.cisco.com
One idea at a time
Start with something familiar.
Read the definitions above first; no command experience is assumed. This introductory walkthrough is a paper prediction using PC1, Switch, Router and PC2. Do not type commands yet. The later Practice network section supplies all installation, console, addressing, baseline and rollback steps in order. A paper prediction is not a tested network result.
Why learn this?
A missing reply is a symptom, not a diagnosis. Layer names help organize questions about the cable, local delivery, IP routing and application. Compare a working baseline with one controlled change so you can explain which evidence supports your conclusion.
An everyday comparison
Imagine a parcel-delivery checklist. This is a memory aid, not a literal delivery process; real devices do not forward packets like parcels. Reading an address or asking about a reply organizes questions, not device actions.
What happens in a network
In the real network, Switch handles Ethernet frames and Router selects an IP path and builds a new frame. PC2 receives the request and needs a return path. Each parcel comparison is an organizational metaphor, not a literal device action; our test uses ICMP, not postal delivery.
Where the comparison stopsThis is a memory aid, not a literal network rule or fault detector. A device can silently drop a packet. Neither a parcel story nor one ping result proves where a network failed; delivery of ICMP does not prove an application works.
Follow one worked example
- On paper, draw PC1 - Switch - Router - PC2 and the reverse reply path.
PC1 at 192.168.1.10/24 sends toward PC2 at 192.168.2.10/24. They are different IP networks. PC1 therefore uses its local gateway, Router at 192.168.1.1.
Why: The destination is PC2, not PC1's own address or the gateway. A self-ping would not test this path.
- Label Router's Switch-facing cable LAN1 and its PC2-facing cable LAN2 on your drawing.
These are role names, not commands. Before configuration, Lab Step 2 requires Router's actual interface inventory and cable mapping in your baseline notes. GigabitEthernet0/0 is only the example LAN1 name.
Why: Record the actual two interface names before any changes. Every configuration and rollback command must use that recorded mapping.
- Trace PC1's frame to Switch and Router, then trace the new frame from Router to PC2.
Switch handles the local frame. Router reads the packet's destination IP and selects its directly connected PC2 network. Router creates an outgoing frame for PC2; it does not forward the incoming frame unchanged.
Why: The four-layer TCP/IP model groups ICMP with IP at the internet layer. Ethernet delivery belongs to link; some teaching conventions split link into two layers.
- Trace the reply from PC2 through Router and Switch back to PC1.
PC2 uses gateway 192.168.2.1 for the return path. In the real lab, repeated peer replies establish a baseline only after both endpoints and mapped router ports are configured.
Why: A reply supports this ICMP round trip. It does not test TCP/UDP ports or an application. Initial ARP delay is possible, but intermittent or persistent loss needs investigation.
- Mark a prediction that the lab-only ACL blocks PC1's echo request at Router; do not configure it during this paper exercise.
Lab Steps 7-10 first require a clean baseline with ACL 199 unused, then attach the complete new list to mapped LAN1. Expected peer loss must agree with the exact deny counter and attachment; the gateway test is not the full peer path.
Why: An ACL number identifies a rule list. Never append into an existing 199, replace an existing binding or claim a cause from one timeout.
- Draw the restored path and write the cleanup order: detach our binding, delete our list, repeat peer tests, compare the baseline.
Lab Step 11 provides the full Router console sequence; Steps 12-14 verify both peers and the saved configuration. This paper prediction does not establish that an actual router was repaired.
Why: Remove only the changes you own. Never erase all configuration or use a startup-to-running merge as a substitute for rollback.
Your first small task
Using paper only, write PC1's own address and PC2's destination address beside your drawing. Trace both directions. Circle the planned filter and write two other possible causes of a timeout. Do not change a live network. Perform later tests only in the isolated lab setup, not on networks with production traffic or shared use.
Show a hint
Compare your drawing with the visual's node labels and addressing table. Follow the reply as well as the request. Use the later lab to measure results only after recording a stable baseline.
Check the expected result
PC1 is 192.168.1.10 and PC2 is 192.168.2.10. The planned filter is at Router. Missing replies can also involve endpoint settings, either route direction, ARP/link trouble or ICMP filtering. These are predictions, not captured results.
Pause and explain it in your own words
After rollback, PC1 repeatedly receives ping replies from PC2. Does this prove PC2's web application works?
Show a hint
Separate the internet-layer ICMP exchange from transport ports and the application. Neither a self-ping nor a gateway-only test reaches PC2.
Show the explanation
No. Repeated peer replies support the tested IP/ICMP exchange and its underlying path at that time. They do not establish TCP/UDP service availability or application health. A web application needs its own authorized test; this lab contains no web-server test.
Short answer
What should you understand today?
A layered model is a diagram or checklist that organizes troubleshooting steps by grouping related network jobs. Use OSI and TCP/IP to ask about links, local delivery, routing and services, then collect evidence. A missing ping reply does not identify a faulty layer; a successful reply does not prove a web application works.
Before you begin
Learning targets
- For clicking, typing and notes, read https://www.qcsstudio.com/courses/ccna/start-here. Recap Day 2's device roles; this lesson reintroduces every console action.
- Use a computer that can run GNS3 and a legally permitted Cisco IOS router image with two routed Ethernet ports and extended IPv4 ACL support.
- Without a permitted image or suitable computer, follow the labelled paper exercises only. Do not type lab commands or claim observed results.
- Use seven OSI categories and the four-layer TCP/IP convention to organize questions, not automatically diagnose faults.
- Distinguish changing Ethernet frames from endpoint IP addresses on the PC1-Switch-Router-PC2 path without NAT.
- Interpret repeated peer pings and interface or ACL evidence without claiming application health from ICMP alone.
- In a disconnected lab, record a clean baseline, apply only the owned test ACL and verify its careful removal.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Layered model
A diagram or checklist that organizes related network jobs for troubleshooting. It helps structure questions, but does not detect faults by itself.
Frame and packet
An Ethernet frame delivers data on one local link. The IPv4 packet inside names IP endpoints; routing creates a new outgoing Ethernet frame.
Inbound and outbound
Inbound traffic arrives at a router through the selected interface. Outbound traffic leaves through that interface. Direction is relative to that port.
ACL binding
An ip access-group setting attaches an access control list to a named interface and direction. A list definition and its attachment are separate configuration items.
Match counter
A per-rule count of matched packets since initialization or clearing, where the platform exposes it. It is not an ACL identifier or rule sequence number.
Peer test
A test to the other named endpoint, such as PC1 testing PC2, rather than testing the source computer's own address.
Baseline and rollback
The baseline records the clean configuration and repeatable observations. Rollback removes only authorized changes and verifies that recorded state again.
Permit ip any any
After the narrow deny in this example, this rule permits other IPv4 traffic evaluated by the ACL. Do not copy this permissive teaching policy to production; it does not itself create routes or services.
TTL and NAT
IPv4 time-to-live (TTL) limits forwarding hops. Network address translation (NAT) changes IP addresses under a configured translation policy; it is not present in this lab.
Introduction to Layered Network Models
A layered model is a diagram or checklist that organizes troubleshooting steps by grouping related network jobs. A layer is one group, not a separate physical box. OSI has seven layers: physical moves signals; data link handles local frames; network handles IP delivery; transport handles communication between applications; session organizes exchanges; presentation concerns data representation; application provides network functions used by software. These categories help organize questions, but the model does not detect faults on its own. One device or program may perform jobs associated with several layers. Consider a parcel-delivery checklist as a memory aid, not a literal delivery process: real devices do not forward packets like parcels. Asking about a destination is an organizational metaphor for checking an address, not a description of a router's actions. Asking whether a reply arrived is an organizational metaphor for checking a return path, not a postal mechanism implemented by a device.
- A model organizes troubleshooting questions; it does not detect faults by itself.
- Seven OSI categories describe jobs, not seven separate devices.
- Every parcel comparison here is a memory aid, not literal device behavior.
Map OSI Jobs to the TCP/IP Path
This lesson uses four TCP/IP layers. Link groups OSI physical and data link jobs; internet corresponds to OSI network jobs; transport corresponds to OSI transport; application groups OSI session, presentation and application jobs. Some textbooks split link into two and use a five-layer teaching convention. ICMP belongs with IP at the internet layer, not with TCP or UDP at transport. In our Ethernet path, PC1 puts an ICMP request in an IPv4 packet and carries that packet in a local frame. Switch forwards the local frame toward Router. Router removes that frame, reads the destination IP, chooses LAN2 and creates a new Ethernet frame addressed to PC2's MAC address. The outgoing frame's source MAC belongs to Router's LAN2 interface. The packet's source remains PC1 at 192.168.1.10 and its destination remains PC2 at 192.168.2.10: there is no NAT, or network address translation, in this lab. Not every packet bit is unchanged: Router reduces the IPv4 time-to-live (TTL), a forwarding limit, and updates the IPv4 header checksum, its error-check value.
- A frame provides local delivery; the IP packet identifies the endpoint destination.
- Router creates a new Ethernet frame on its outgoing link.
- Without NAT, endpoint IP addresses stay the same; IPv4 TTL and checksum change at Router.
What a Ping Result Can and Cannot Tell You
Ping asks a named IP peer to return an ICMP echo reply. A reply supports that particular request-and-reply exchange at that time, including the links and routing it depended on. It does not test TCP connections, UDP services or a web application. A missing reply means the exchange did not finish before the timeout, not that one specific layer failed. Check the destination identity, addressing, both path directions and relevant policy. In real networks, missed ping replies may involve host firewalls, link problems or rate limits, as well as routing and endpoint state. ARP discovers the MAC address of the local next hop; initial discovery can delay a first test. Repeated success is consistent with that possibility, but does not prove ARP caused an earlier timeout. Persistent or intermittent loss needs investigation before introducing a controlled fault.
- Use the named peer address, not a self-ping, for the before-and-after comparison.
- Host firewalls, link problems and rate limits are possible real-network causes of lost replies.
- A permit rule predicts permitted traffic; it does not prove untested applications work.
Read Layered Evidence and ACL Bindings
Begin with read-only observations: inspect cable endpoints and interface state, compare addresses and gateways, and review the tested path and policy. An ACL is an ordered permit/deny rule list. Its identifier can be a number, such as 199, or a name. An ip access-group command binds that list to an interface: inbound means arriving at Router through that port; outbound means leaving Router through that port. A rule's match counter counts matching packets since the counter was last initialized or cleared. It is not the ACL identifier, the number of rules, or a rule sequence number. Counter availability and display vary by image. Correlate a supported counter change with the exact test, attachment and baseline; missing or stale counters are not proof of a particular cause. In real networks, missed ping replies may involve host firewalls, link problems or rate limits even when an ACL exists. An up/up interface is evidence about that local interface, not proof of end-to-end connectivity.
- ACL 199 identifies the list; a rule sequence and its match count are separate values.
- Inbound and outbound describe direction relative to the selected router interface.
- Inspect the complete configuration for other references and stop on unfamiliar ownership.
Use a Controlled Fault and Restore the Baseline
Perform these tests only in the isolated lab setup, not on networks with production traffic or shared use. The detailed Practice network steps below supply the exact console actions; these teaching examples are paper predictions, not instructions to configure a device now. Establish repeated PC1-to-PC2 replies and save the clean baseline before creating a filter. ACL 199 must be unused, and the selected ports must have no pre-existing policy. The lab's narrow deny blocks PC1's echo requests to PC2. The following permit ip any any allows other IPv4 traffic evaluated by this ACL; it does not create routes, open services or demonstrate their health. Never copy this permissive teaching policy to production. Before rollback, compare the actual LAN1 interface with both your baseline and current interface inventory, then inspect every reference to 199. Stop if another interface or feature uses it. Detach only our known LAN1 inbound binding before deleting the lab-owned list, and repeat the identical peer test. This is our safety procedure, not a claim that IOS always prevents deletion of an attached definition. Copying startup-config into running-config merges settings and is not a reliable rollback.
- Use a clean, disposable, fully disconnected project and record the baseline before any fault.
- Inspect all references, detach the known lab-owned binding, then delete only the lab-owned list.
- An unexpected binding is a stop condition, not permission to remove every ACL.
- Successful cleanup requires configuration comparison as well as the original peer test.
Real-world walkthrough
Investigate an Office Ping Report Without Removing Its Controls
An office reports that a server no longer replies to ping. This is a paper incident discussion, not an instruction to run the lab fault on that office. The responsible operator first confirms permission to inspect the relevant systems and gathers evidence without changing security policy.
- Record the reported source, destination, time and affected service. A web-service complaint and an ICMP timeout are different observations; ask which was actually measured.
- Within the approved read-only scope, compare cable and interface state, addresses, gateways and the recorded path with the known baseline. An up/up port alone does not prove the server is reachable.
- Consider both directions and endpoint behavior. Missed ping replies may involve host firewalls, link problems or rate limits, not only router ACLs.
- Ask the authorized operator to inspect the relevant ACL identifiers, interface directions and supported match counters. Treat deliberately filtered ICMP as possible intended policy, not automatically a fault to remove.
- Report what is known and what remains uncertain. An approved service-specific test may be needed; this lesson's isolated lab does not run a production web-service test.
- Do not detach or delete office ACLs as a diagnostic shortcut. Any real change requires the organization's approval and rollback process. Reproduce the educational before/fault/after exercise only in the fully disconnected disposable lab.
Guided GNS3 lab
Locate a controlled ICMP fault with layered evidence
Build one working routed path, record a clean baseline, block only its test request with a temporary numbered ACL, and restore the identical peer test. Learn what each observation supports and what it cannot prove.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| PC1 | Ethernet0 | 192.168.1.10/24 | Source; default gateway 192.168.1.1 |
| Router | GigabitEthernet0/0 (LAN1) | 192.168.1.1/24 | Router port cabled to Switch; map the observed name |
| Router | GigabitEthernet0/1 (LAN2) | 192.168.2.1/24 | Router port cabled to PC2; map the observed name |
| PC2 | Ethernet0 | 192.168.2.10/24 | Destination; default gateway 192.168.2.1 |
Set up the lab
- Open GNS3. Choose File > New blank project, name it Day4-Isolated and confirm its new folder. Reopen with File > Open project. The clean-baseline step separately saves Router's configuration. Drag templates from the device browser; Start/Resume all devices starts them. To return, right-click the named node and choose Console. Stop the disposable nodes before closing; do not alter other projects.
- Complete the start-here guide and recap Day 2's console and gateway concepts. Keep existing projects untouched. For Windows notes, click Start, type Notepad and press Enter. Choose File > New or New tab. Type a heading, choose File > Save As, select Documents, enter Day4-baseline.txt and click Save. Keep this window open; click below existing notes, paste copied console output, and press Ctrl+S after each addition. A dated paper notebook is an alternative.
- For notes on Mac, open TextEdit from Applications and select Format > Make Plain Text. On Linux, open an installed text editor such as Gedit; use nano in Terminal only if you already know it. Save as Day4-baseline.txt, then use the editor's Save command after additions. A paper notebook also works. These are notes editors, not network consoles: on every operating system, right-click the named GNS3 node and choose Console before typing device commands.
- Before installing Router, confirm legal permission that permits this Cisco IOS image in GNS3. GNS3 supplies no Cisco images; never share or redistribute them. Use two routed Ethernet ports and extended IPv4 ACLs. Without permission, skip remaining setup and all commands: read the diagram, predict on paper and answer practice questions. Do not claim execution. Cisco Modeling Labs is a separately configured alternative; a CML license alone does not grant GNS3 image rights.
- Drag two VPCS nodes and one built-in Ethernet switch into the project, add the authorized router template and rename the nodes exactly PC1, Switch, Router and PC2. Select Add a link, then each device and named port from the connection plan. Click the toolbar Start/Resume all devices button, or right-click each node and select Start. Wait until each node is running before opening Console. Switch uses default access ports and has no IOS console.
- In show ip interface brief, map the port wired to Switch as LAN1 and the port wired to PC2 as LAN2. Example: if the router shows GigabitEthernet0/0/0 and GigabitEthernet0/0/1, use those instead of GigabitEthernet0/0 and GigabitEthernet0/1 in EVERY command, including ACL removal. Record that two-row mapping beside the address table.
- If either expected port is absent, stop. Check the correct console and template in GNS3, stop Router before changing its adapter settings, select two supported Ethernet adapters, reconnect and restart. Re-run the inventory and record actual names; never guess an interface name or paste a placeholder.
- Router may show Router> or a different hostname; enable reaches #. If prompted for a password, use only your authorized lab credential. Decline an initial configuration dialog for this new practice router. PC1> and PC2> are VPCS prompts, not IOS. At --More-- press Space to read the remaining output. Keep consoles open for comparison.
Isolate and record the connection plan
Create the new disposable project and connect the four named devices using the topology above. Keep Cloud, NAT and real network adapters out. Create Day4-baseline.txt using the setup instructions, or use a notebook. Record the cable endpoints. In Step 2, match each router port to show ip interface brief and record LAN1 and LAN2 before any router configuration. To copy output, drag over its text in the console and use that console's Copy menu; paste into your notes and save.
- What you should see
- Four started nodes and exactly three links match the plan. Your existing projects are unchanged, and baseline notes identify this working copy.
- Why this step matters
- Isolation and an explicit record prevent an educational filter from changing a real service or an unrelated project.
Inspect and record the untouched router
In the isolated project, right-click Router and choose Console before typing. Start at > or #. Copy the complete output to Day4-baseline.txt. Require two unused routed ports, no existing ip access-group on either, and no ACL 199 anywhere. If any pre-existing setting is present, stop and choose a clean disposable router; do not remove or replace it. This lab targets Cisco IOS/IOS XE, not ASA or NX-OS. At privileged #, show ip access-lists lists IPv4 ACLs; if rejected, use show access-lists and check your image documentation. These are read-only inspections: do not create ACL 199 here. Stop if neither form supplies the required evidence; never change settings to force counters to appear. Type one command per line and press Enter; do not type the prompt.
enable
show ip interface brief
show running-config
show ip access-listsWhat each command means
enable- Enter privileged EXEC on this lab Router so the baseline can include its active configuration.
show ip interface brief- List actual router interface names, assigned IPv4 addresses and link status; use this output to map LAN1 and LAN2.
show running-config- Read the complete active configuration. Record interface blocks and all ACL references before making any change.
show ip access-lists- List existing IPv4 ACL identifiers and rules. A numbered list uses an identifier such as 199, not a rule sequence number. If rejected, use show access-lists; do not create or change a list.
- What you should see
- Your baseline shows no ACL 199 and no ACL attachment or existing IP address on the two selected ports. If it does not, stop without changing that router.
- Why this step matters
- A numbered ACL can be shared by other features. Confirm it is absent everywhere before reserving 199 for this exercise.
Configure the two mapped router ports
In the isolated project, right-click Router and choose Console before typing. Use the exact interface mapping from your notes. These full commands assume LAN1 is GigabitEthernet0/0 and LAN2 is GigabitEthernet0/1. Administratively down means disabled by configuration; no shutdown enables only those approved lab ports. Down/down reports physical and protocol down; up/down reports physical up but protocol down. Check both cable endpoints and started peers; do not proceed without the expected up/up baseline. Type one command per line and press Enter; do not type the prompt.
enable
configure terminal
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet0/1
ip address 192.168.2.1 255.255.255.0
no shutdown
end
show ip interface briefWhat each command means
enable- Select Router's privileged mode before starting this interface-configuration block.
configure terminal- Enter global configuration mode to make the recorded lab-only address changes.
interface GigabitEthernet0/0- Select LAN1, the port connected to Switch. Substitute its observed full interface name if different.
ip address 192.168.1.1 255.255.255.0- Assign LAN1 its local gateway address and /24 mask; 255.255.255.0 describes this first network.
no shutdown- Enable LAN1 if administratively down. This removes a configuration disable; it does not fix missing cabling.
exit- Return from LAN1 interface mode to global configuration before selecting the other port.
interface GigabitEthernet0/1- Select LAN2, connected directly to PC2; substitute the second recorded full interface name.
ip address 192.168.2.1 255.255.255.0- Assign LAN2 its different /24 network address so Router can join the two directly connected networks.
no shutdown- Enable LAN2 on this isolated router; its PC2 connection must also exist and be started.
end- Leave configuration mode and return to privileged EXEC before reading router status.
show ip interface brief- Verify both mapped ports have the intended addresses and read up/up after their links initialize.
- What you should see
- LAN1 is 192.168.1.1 and LAN2 is 192.168.2.1 with up/up state. Administratively down means configured shutdown; a missing port or other down state needs inspection, not repeated blind commands.
- Why this step matters
- Interface status gives local Layer 1/2 evidence. Correct addresses add Layer 3 configuration, but neither alone proves a successful remote exchange.
Configure the source computer
In the isolated project, right-click PC1 and choose Console before typing. At PC1's VPCS prompt (PC1>), use the format ip address/prefix gateway. In the exact command below, 192.168.1.10 is PC1's address, /24 selects its mask and 192.168.1.1 is its gateway. Type the whole command, not the prompt, then press Enter. Do not enter Router IOS commands here. Type one command per line and press Enter; do not type the prompt.
ip 192.168.1.10/24 192.168.1.1
show ipWhat each command means
ip 192.168.1.10/24 192.168.1.1- Set PC1 to 192.168.1.10 with a /24 mask and default gateway 192.168.1.1 for remote networks.
show ip- Confirm PC1's own IPv4 address, mask and gateway before choosing a different peer address for testing.
- What you should see
- PC1 reports 192.168.1.10/24 and gateway 192.168.1.1. It must not use either Router address or PC2's address.
- Why this step matters
- A self-ping stays local and cannot verify the switch, router or destination; record the source identity first.
Configure the destination computer
In the isolated project, right-click PC2 and choose Console before typing. At PC2's VPCS prompt (PC2>), use the format ip address/prefix gateway. In the exact command below, 192.168.2.10 is PC2's address, /24 selects its mask and 192.168.2.1 is its gateway. Type the whole command, not the prompt, then press Enter. Record this separately from PC1. Type one command per line and press Enter; do not type the prompt.
ip 192.168.2.10/24 192.168.2.1
show ipWhat each command means
ip 192.168.2.10/24 192.168.2.1- Set PC2's address to 192.168.2.10/24 and its local default gateway to 192.168.2.1 for the reply path.
show ip- Check PC2's own address and gateway. PC2 is the destination of PC1's test, not the source of that command.
- What you should see
- PC2 reports 192.168.2.10/24 with gateway 192.168.2.1. Both endpoints have unique addresses in different networks.
- Why this step matters
- An echo reply also needs a return route. A correct forward path cannot compensate for a wrong destination gateway.
Establish the working peer exchange
In the isolated project, right-click PC1 and choose Console before typing. Compare show ip with the destination: 192.168.2.10 must be PC2, not PC1. Run the peer test twice. An initial timeout can occur during ARP discovery; repeated or intermittent loss is not a reliable working baseline. Stop and troubleshoot until repeated replies work before adding a filter. Type one command per line and press Enter; do not type the prompt.
show ip
ping 192.168.2.10
ping 192.168.2.10What each command means
show ip- Recheck that this console belongs to source 192.168.1.10 before sending packets to another host.
ping 192.168.2.10- Send ICMP echo requests from PC1 to PC2 and record replies or timeouts for this first peer exchange.
ping 192.168.2.10- Repeat the same PC1-to-PC2 exchange after address discovery; compare results rather than declaring a fault from one timeout.
- What you should see
- Repeated replies establish the test baseline. A timeout only shows no timely reply; cabling, ARP, addresses, return routing, host state or filtering can contribute. A reply does not test a website.
- Why this step matters
- Changing a filter before a stable baseline would make the cause of a later failure ambiguous.
Save the clean pre-filter baseline
In the isolated project, right-click Router and choose Console before typing. Copy this output and both successful endpoint tests to Day4-baseline.txt. Confirm ACL 199 and interface ACL bindings are still absent. On this disposable router only, save the known working configuration; at Destination filename [startup-config]? press Enter. Never save the later fault configuration. Type one command per line and press Enter; do not type the prompt.
enable
show running-config
show ip access-lists
copy running-config startup-configWhat each command means
enable- Return to Router's privileged EXEC to record the clean configuration before any filtering change.
show running-config- Record the full working configuration, including both IP addresses and the absence of interface ACL bindings.
show ip access-lists- Check again that ACL 199 is unused before the exercise claims ownership of that identifier; use show access-lists if this form is rejected.
copy running-config startup-config- Save this clean disposable-router baseline for a subsequent boot; press Enter to accept the proposed startup-config filename.
- What you should see
- Baseline notes and startup-config contain the working path without ACL 199. Record the timestamp and router identity; do not continue if an existing filter is discovered.
- Why this step matters
- A recorded known state makes rollback verifiable. Later detach only our attachment and delete only our new list; never erase unrelated ACLs.
Apply the one lab-owned ICMP filter
In the isolated project, right-click Router and choose Console before typing. Continue only from the clean Step 7 baseline. If resuming after interruption, inspect running-config and ACLs first; never append into an existing 199. After the specific deny, permit ip any any permits other IPv4 traffic evaluated by this ACL; it does not create routes or services. Use this permissive teaching policy only in the fully disconnected lab, never on production or shared networks. Build the complete list before binding it inbound on mapped LAN1. The deny blocks only PC1's echo requests to PC2. Type one command per line and press Enter; do not type the prompt.
enable
configure terminal
access-list 199 deny icmp host 192.168.1.10 host 192.168.2.10 echo
access-list 199 permit ip any any
interface GigabitEthernet0/0
ip access-group 199 in
end
show ip interface GigabitEthernet0/0
show ip access-lists 199What each command means
enable- Open Router privileged EXEC for the isolated, recorded ACL experiment.
configure terminal- Enter global configuration to define the complete new numbered extended list.
access-list 199 deny icmp host 192.168.1.10 host 192.168.2.10 echo- In list 199, deny only ICMP echo requests from PC1 to PC2. host selects one exact address; echo selects the request type.
access-list 199 permit ip any any- Permit other IPv4 traffic after the narrow deny; without this entry the implicit final deny would block other traffic too.
interface GigabitEthernet0/0- Select the recorded LAN1 interface connected to Switch, not the PC2-facing port.
ip access-group 199 in- Attach our complete ACL 199 to packets arriving at Router from LAN1; in means inbound on this selected port.
end- Return to privileged EXEC without saving the deliberately faulty running configuration.
show ip interface GigabitEthernet0/0- Confirm LAN1's inbound access list is 199. Substitute the same mapped interface name used in the configuration.
show ip access-lists 199- Before the next ping, save the deny match count and separately note your computer's clock time in Day4-baseline.txt. If rejected, use show access-lists and find list 199. Do not assume a missing count means zero; record unavailable.
- What you should see
- Only the test-owned list 199 is attached inbound on LAN1. Record the pre-test deny count or mark it unavailable before Step 9. Startup-config remains the clean baseline; interfaces and cables remain unchanged.
- Why this step matters
- Changing one narrowly scoped filter provides a known cause that can be checked with before-and-after rule counts and the identical peer test.
Compare filtered peer and gateway tests
In the isolated project, right-click PC1 and choose Console before typing. Reconfirm the source address, repeat the exact peer ping, then test the local gateway. Record results without changing addresses, cables or masks. A filter timeout or unreachable response is not evidence of a broken physical link. Type one command per line and press Enter; do not type the prompt.
show ip
ping 192.168.2.10
ping 192.168.1.1What each command means
show ip- Confirm the current console still belongs to PC1 at 192.168.1.10 before comparing destinations.
ping 192.168.2.10- Repeat the baseline PC1-to-PC2 request; the lab's inbound rule should now prevent echo replies from that peer.
ping 192.168.1.1- Test Router's LAN1 gateway from PC1; this destination is not denied by the specific test rule.
- What you should see
- The PC2 echo exchange fails while the gateway should still reply. This difference is evidence to investigate; use the matching ACL counter next rather than diagnosing a layer from the ping alone.
- Why this step matters
- An ICMP filter can hide otherwise available connectivity. Outside this controlled lab, local host settings and firewalls can also suppress replies.
Inspect the actual filter evidence
In the isolated project, right-click Router and choose Console before typing. Read the numbered list and compare its deny match count with the value recorded in Step 8. Subtract before from after: for example, 8 after minus 3 before means 5 new matches, not 8 from this test. Do not clear counters between readings. Presentation varies by image; if either count is unavailable, record that limitation instead of inventing a delta. If it does not increase, verify source, target and inbound port before attributing the loss to this filter. Type one command per line and press Enter; do not type the prompt.
enable
show ip access-lists 199
show ip interface GigabitEthernet0/0
show ip interface briefWhat each command means
enable- Use privileged EXEC to inspect the temporary Router filter without altering the experiment.
show ip access-lists 199- Read the same deny rule after the peer tests; if rejected, use show access-lists and find list 199. Record its count and your computer's clock time beside Step 8's reading, then compare the two observations.
show ip interface GigabitEthernet0/0- Verify 199 is still the inbound list on mapped LAN1, where requests from PC1 enter.
show ip interface brief- Compare interface status and addresses with the working baseline while the peer ICMP test is filtered.
- What you should see
- The exact deny rule has matching traffic evidence and the intended attachment, while the mapped links remain up/up. Missing counters are a limitation to investigate, not invented successful evidence.
- Why this step matters
- Multiple observations distinguish a known Layer 3 policy decision from a link or addressing problem; ping alone cannot do that.
Detach and delete only test ACL 199
In the isolated project, right-click Router and choose Console before typing. Run only the four inspection commands first. Confirm LAN1 matches BOTH your baseline record and current show ip interface brief, and check its current inbound binding. Read all of running-config: 199 must have only our known LAN1 use. If any mapping or ownership is uncertain, stop before configure terminal; never paste this whole block blindly. The Step 7 baseline had no ACL attached. If 199 is not solely ours, stop. Detach our binding before deleting the list; leave any unexpected binding untouched. Type one command per line and press Enter; do not type the prompt.
enable
show ip interface brief
show running-config
show ip interface GigabitEthernet0/0
configure terminal
interface GigabitEthernet0/0
no ip access-group 199 in
exit
no access-list 199
end
show ip access-lists
show ip interface GigabitEthernet0/0What each command means
enable- Return to Router privileged EXEC to begin explicit rollback of this lab-owned change.
show ip interface brief- Match the current full LAN1 name, address and link to your recorded baseline and GNS3 cable endpoints. Stop on any mismatch.
show running-config- Inspect the entire configuration for every reference to ACL 199. Stop if another interface or feature uses it; this lab owns only its LAN1 inbound binding.
show ip interface GigabitEthernet0/0- Use the recorded LAN1 name. Confirm its inbound binding is our 199 and the original baseline had none. Stop here if uncertain; continue only after all three checks agree.
configure terminal- Enter global configuration before selecting the port with our test binding.
interface GigabitEthernet0/0- Select the same LAN1 interface used for the test; use its recorded actual name if different.
no ip access-group 199 in- Detach only list 199 in the inbound direction from LAN1, restoring its recorded unfiltered baseline.
exit- Leave interface mode for global configuration; ACL deletion belongs at the global level.
no access-list 199- Delete the entire numbered ACL 199 created by this lab, not an arbitrary numbered entry or a named ACL.
end- Return to privileged EXEC before checking the removal; do not save a fault configuration.
show ip access-lists- Check that the test-owned list 199 is absent and unrelated lists have not been changed; use show access-lists if this form is rejected.
show ip interface GigabitEthernet0/0- Verify LAN1 no longer has the temporary inbound binding, matching the recorded baseline.
- What you should see
- ACL 199 and its inbound LAN1 binding are absent. Other configuration is unchanged. An absent list message is acceptable; verify attachment removal separately.
- Why this step matters
- Deleting an ACL definition and detaching it are separate operations. Explicit commands and ownership checks prevent a vague remove-all cleanup.
Retest the restored forward exchange
In the isolated project, right-click PC1 and choose Console before typing. Check the source and repeat exactly the same destination test twice after rollback. Compare with the saved working result, not with a ping of PC1's own address. Type one command per line and press Enter; do not type the prompt.
show ip
ping 192.168.2.10
ping 192.168.2.10What each command means
show ip- Verify the restored test still originates at PC1, not PC2 or the router console.
ping 192.168.2.10- Repeat the original PC1-to-PC2 exchange after detaching and deleting the test ACL.
ping 192.168.2.10- Confirm repeated peer replies rather than accepting one isolated response as a stable restoration.
- What you should see
- Repeated replies to PC1 resume after the lab-owned filter is removed. If they do not, compare interface status, addressing and remaining attachments with the baseline.
- Why this step matters
- The same source, destination and command make the before/fault/after comparison meaningful.
Verify a separate reverse peer exchange
In the isolated project, right-click PC2 and choose Console before typing. Compare PC2's own 192.168.2.10 with destination 192.168.1.10. The destination must be PC1, never PC2's own address. This is an additional check after rollback, not a substitute for the original PC1 test. Type one command per line and press Enter; do not type the prompt.
show ip
ping 192.168.1.10What each command means
show ip- Confirm PC2's identity, /24 mask and gateway 192.168.2.1 before testing the other computer.
ping 192.168.1.10- Send a new ICMP echo exchange from PC2 to PC1 to check this reverse-direction test after restoration.
- What you should see
- PC2 receives replies from PC1 through Router and Switch. Neither peer test proves TCP, UDP, DNS or an application works.
- Why this step matters
- Peer tests from both named endpoints avoid accidental self-tests and expose endpoint-specific settings.
Verify baseline restoration and close
In the isolated project, right-click Router and choose Console before typing. Compare both outputs with the clean Step 7 baseline, especially the two interface blocks and ACLs. Do not copy startup-config into running-config as a rollback: that merges settings. If unexpected differences remain, stop and investigate or discard only this disposable working project; preserve original projects and baseline notes. Type one command per line and press Enter; do not type the prompt.
enable
show running-config
show startup-configWhat each command means
enable- Use Router privileged EXEC for the final read-only configuration comparison.
show running-config- Verify the active configuration matches the pre-filter baseline, with no test ACL or attachment remaining.
show startup-config- Check the saved boot baseline was not overwritten while the deliberate fault was active.
- What you should see
- The pre-filter interface and ACL baseline is restored, both peer tests reply, and your original projects are untouched. Stop the disposable nodes when finished.
- Why this step matters
- A successful ping is not sufficient cleanup evidence; configuration comparison verifies that the temporary policy change is gone.
Verify
- Compare node identities and show ip before each peer test. PC1 tests 192.168.2.10; PC2 tests 192.168.1.10. Neither command is a self-ping.
- Record repeated PC1-to-PC2 replies before applying 199. Initial ARP discovery may delay a reply; intermittent or persistent loss must be investigated before changing policy.
- With the test ACL active, correlate lost PC2 echo replies with the exact deny-rule count and inbound LAN1 attachment. A timeout alone does not locate the faulty layer.
- After detaching and deleting only ACL 199, repeat the identical forward peer test and a separate reverse test. Compare interfaces and ACL settings to the saved pre-filter baseline.
- Record that ping exercises an IP/ICMP round trip and underlying dependencies. Host behavior, firewall rules and ICMP filtering can cause missing replies; success does not test transport ports or applications.
Troubleshoot
- Perform these tests only in the isolated lab setup, not on networks with production traffic or shared use. Baseline comparison and rollback here apply only to the disposable project and changes you own. Do not diagnose an office incident by removing its security controls.
- Console confusion: right-click the actual node and choose Console. PC1> or PC2> is VPCS, which accepts ip/show ip/ping. Router> and Router# are IOS modes; enable selects privileged EXEC. The built-in Switch has no IOS console. If the expected prompt is absent, stop and select the correct device.
- Missing interface: compare show ip interface brief with GNS3's actual adapter and cable-endpoint list. Stop Router before modifying supported adapter settings, then reconnect, restart and inventory again. Map the observed names; never invent a port name or configure an unrelated interface.
- Administratively down means configured shutdown. In the Router console, repeat Step 3's full enable/configure terminal/interface/no shutdown/end sequence only for the mapped lab port. If down/down persists, inspect its cable and started peer. Up/down requires checking both sides and link settings; no shutdown alone is not proof of health.
- ACL identifier: show running-config may display access-list 199 deny icmp or ip access-list extended 199 for a numbered list. A named example is ip access-list extended LAB_FILTER. The interface's ip access-group 199 in or ip access-group LAB_FILTER in names the attachment. show access-lists confirms the identifier. Rule sequence numbers are different. This exercise removes only its own 199, never LAB_FILTER or a pre-existing binding.
- Ping loss: repeat the same remote target, inspect show ip, cables, router ports, ARP and ACL counters. Initial ARP discovery or intermittent links can delay replies; ICMP filtering, host state and the return path can also prevent them. Never conclude that all Layer 3 routing is broken from a single failed ping.
- Rollback uncertainty: compare the timestamped pre-filter running-config, interface bindings and saved startup-config. This lab requires no prior ACL binding; if one existed, stop instead of deleting it. Step 11 shows detach then delete for lab-owned 199. Do not erase configuration, remove all ACLs or assume a startup-config merge reverses changes.
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.
- Perform these tests only in the isolated lab setup, not on networks with production traffic or shared use. Before rollback, confirm the mapped interface, baseline and every current use of ACL 199; stop on any unfamiliar binding or doubt.
- Perform Step 11 on Router: detach only our inbound ACL 199, exit interface mode, delete only numbered ACL 199, then verify the list and binding are absent. Never remove an unknown named or numbered ACL.
- Repeat Steps 12-13 peer tests and Step 14 configuration comparison against the clean Step 7 baseline. Check both addresses, interface state and original absence of ACL bindings. Do not save the fault state.
- Stop the disposable GNS3 nodes. Preserve baseline notes and original projects. To undo the entire exercise, discard only its new working project; do not run erase commands or change shared network settings.
Practice set
Answer before you reveal
01PC1 cannot ping PC2, although Router's mapped ports show up/up and addresses match the plan. What read-only evidence could you inspect next?
Up/up is local interface evidence, not proof of peer connectivity. The ACL is one hypothesis. Compare the exact source and destination, gateway settings and policy; real host firewalls, link problems or rate limits can also affect replies.
02A first peer ping times out, then repeated tests reply. Name one possible explanation and what the observation does not prove.
ARP resolves the local next-hop MAC address. On PC1's cross-subnet request, that next hop is its gateway, not remote PC2. Transient loss can have other causes, so record the observation and establish a stable baseline before the controlled fault.
03PC1 receives gateway replies but not PC2 replies. Does that prove Router's ACL is the cause?
Check actual peer addresses, both gateways, the remaining links and policy evidence. General hosts may also block ICMP or be unavailable. Those are conceptual alternatives; this VPCS lab does not simulate a host firewall product.
04During isolated-lab cleanup, you discover an unfamiliar second reference to ACL 199. Should you detach every reference and delete the list?
Perform rollback only in the isolated lab, never on production or shared networks. The required baseline had no 199. This lab authorizes only its known LAN1 inbound binding; another interface or feature reference breaks that ownership assumption. Detachment-before-deletion is a safety procedure, not a guarantee enforced by IOS.
05The deny counter does not change after PC1's failed peer ping. Which checks prevent an unsupported conclusion?
Read the complete running configuration and relevant interface output in the Router console. A wrong port, direction, source or target can prevent a match; unavailable counters are also a measurement limitation. Do not invent a count or conclude that missing counts prove routing is broken.
06After the isolated rollback, PC1 receives repeated replies from PC2. What is verified, and what still needs a separate test?
Compare the same peer test and the recorded configuration baseline before calling the lab restored. Successful ICMP does not establish TCP/UDP services or application health. Any application test belongs to a separately authorized environment; there is no web server in this lab.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Use layers to organize evidence, not to guess a faulty device from one timeout.
- Track both endpoint IP addresses separately from the changing local Ethernet frames.
- A peer ping tests one ICMP exchange; it does not establish application health.
- Use only an isolated disposable lab with the exact mapped interfaces and a clean baseline.
- Stop on unfamiliar ACL references; detach the known lab binding before deleting its list.
- Compare the same peer tests and configuration before and after rollback; never claim an unexecuted test passed.