First, the essential ideas
- ACL and ACE
- An access control list (ACL) contains permit or deny tests. An access control entry (ACE) is one test. A standard IPv4 ACL examines source IPv4 addresses, not destination ports. Its host lookup and wildcard ordering both matter.
- Wildcard mask
- A zero bit in an ACL wildcard must match the address; a one bit is ignored. Thus 0.0.0.255 ignores the final octet, unlike a subnet mask used to define an interface network.
- Host hash and wildcard order
- A hash table is an indexed lookup, not encryption. Cisco IOS XE 17 standard ACLs check exact 32-bit host entries there first. Only a host miss reaches wildcard rules in sequence order; their first match decides.
- Implicit deny
- A packet matching neither a host entry nor a wildcard rule in an existing populated ACL is denied by an invisible final rule. Displayed sequence numbers alone do not predict host lookup or counters.
- Inbound and outbound
- Direction is relative to the router interface. Inbound traffic enters that interface; outbound traffic leaves it. The label does not mean into or out of the entire company.
- Transit traffic
- Transit packets pass through the router between other devices. A ping generated by the router is a different test and may not encounter an outbound ACL in the same way.
- Console and VPCS
- Console is the text window for a selected lab node. VPCS is a lightweight simulated PC, with its own ip and ping commands rather than the IOS configuration language.
- Counter and baseline
- A counter records matches reported by the device. A baseline records the intended configuration and observed working tests before a change; counters alone do not prove an application works.
Write the policy in words before writing IOS syntax: only PC-A may reach the second subnet. Then identify what this ACL can actually inspect. Destination restrictions arise from where you attach this source-only filter, not from a hidden destination field in its rules.
See the idea
IOS XE 17 standard ACL lookup
TO-B: .10 keeps its host permit; fault entry 5 changes .20 from deny to permit.
Exact-host case: .10
Before and during the fault, .10 matches host permit 10. Do not infer that wildcard permit 5 replaced this lookup from display order.
What this model leaves out: IOS XE 17 standard ACL TO-B on R1's PC-B-facing exit. These are alternate source cases, not serial hops or observed counters.
Full visual explanation and references
Two source cases compare .10's exact-host hit with .20's host miss and wildcard decision, before and during the fault.
IOS XE 17 standard ACL TO-B on R1's PC-B-facing exit. These are alternate source cases, not serial hops or observed counters.
- Exact-host case: .10
Before and during the fault, .10 matches host permit 10. Do not infer that wildcard permit 5 replaced this lookup from display order.
www.cisco.com - Wildcard case: .20
No .20 host entry exists. Baseline: deny 20. Fault: permit 5 precedes deny 20 in the wildcard list, so .20 is wrongly permitted.
www.cisco.com - Restore denial
Remove only 5. Predict .20 denied by 20 and .10 still permitted by its host entry. Retest both; these are predictions, not measured counters.
www.cisco.com
One idea at a time
Start with something familiar.
Start with the packet's source address. For this Cisco IOS XE 17 standard ACL, check the exact-host lookup first. Only if it misses, read wildcard rules in sequence order until one matches. Mark that decision and stop; then identify the attached interface and direction.
Why learn this?
A valid list can block the wrong traffic when attached too early in the path. For a source without a host entry, a broad wildcard permit before the intended wildcard deny also changes the policy. A small written test matrix separates these mistakes.
An everyday comparison
Imagine a reception desk checking a directory of individual addresses first. If an address has no directory entry, the clerk uses an ordered list of area-wide rules. This separates an exact lookup from the fallback rules.
What happens in a network
The directory resembles the standard ACL's host hash; the area rules resemble its wildcard list. The desk's location resembles the attached interface. Moving the same policy to another interface can affect different destinations.
Where the comparison stopsAn IP address is not an authenticated human identity. Addresses can change or be spoofed. An ACL neither encrypts a packet nor checks whether a permitted person should use a particular application.
Follow one worked example
- Predict two source decisions before configuring.
PC-A at 192.0.2.10 should pass; the same isolated PC temporarily using .20 should fail. Both attempt to reach PC-B at 198.51.100.10.
Why: Changing only the source makes the standard ACL's limited matching field directly visible.
- Separate rule content from attachment.
The named list allows one host and denies the rest. The attachment is outbound on the port toward PC-B, so the filter protects only that exit in this topology.
Why: A source-only rule placed inbound near PC-A would also affect its traffic toward other routed destinations.
- Repair the wildcard fault, then retest.
A temporary sequence 5 permit any makes .20 pass because .20 has no host entry. Remove only that sequence and repeat both source cases.
Why: The wildcard permit precedes wildcard deny any. Source .10 retains its separate host permit; sequence 5 does not prove that host entry was bypassed.
Your first small task
On paper, use TO-B: 10 permit host 192.0.2.10; 20 deny any. Evaluate .10 and .20 before and after adding 5 permit any. For all four cases, record host hit or miss, selected entry and permit or deny using the documented IOS XE 17 lookup order.
Show a hint
Separate exact-host lookup from ordered wildcard rules. Do not infer the selected entry or an actual counter increment from the lowest displayed sequence number.
Check the expected result
Before: .10 host hit, sequence 10 permit; .20 host miss, sequence 20 deny. With the fault: .10 still uses host permit 10; .20 misses the host lookup and reaches wildcard permit 5 before wildcard deny 20.
Pause and explain it in your own words
Can a standard ACL allow .10 to one TCP port but deny it to another?
Show a hint
Identify the fields available in a standard IPv4 entry, not the fields you wish it could inspect.
Show the explanation
No. It sees the IPv4 source address, not TCP destination ports. Use an extended ACL for a protocol-and-port policy; placement can limit the affected destination path but cannot add port matching.
Short answer
What should you understand today?
A standard IPv4 ACL filters source addresses. Cisco IOS XE 17 checks exact host entries before ordered wildcard rules; unmatched traffic is implicitly denied. Build the complete list before attaching it, choose its interface and direction deliberately, and test allowed and denied sources.
Before you begin
Learning targets
- Review IPv4 /24 addressing, routed interfaces and the IOS configuration modes.
- Use GNS3 2.2 with a separately entitled CSR1000v IOS XE 17.3 image and two VPCS nodes.
- Keep a direct console open; this disposable lab has no production, Cloud or NAT connection.
- Explain the source-only boundary and why standard ACL placement matters.
- Create and inspect named and numbered standard ACLs without mixing their identifiers.
- Verify allowed and denied tests, rule order, counters and attachment direction.
- Introduce one overbroad entry, observe its effect, remove it and repeat the original tests.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
ACL and ACE
An access control list (ACL) contains permit or deny tests. An access control entry (ACE) is one test. A standard IPv4 ACL examines source IPv4 addresses, not destination ports. Its host lookup and wildcard ordering both matter.
Wildcard mask
A zero bit in an ACL wildcard must match the address; a one bit is ignored. Thus 0.0.0.255 ignores the final octet, unlike a subnet mask used to define an interface network.
Host hash and wildcard order
A hash table is an indexed lookup, not encryption. Cisco IOS XE 17 standard ACLs check exact 32-bit host entries there first. Only a host miss reaches wildcard rules in sequence order; their first match decides.
Implicit deny
A packet matching neither a host entry nor a wildcard rule in an existing populated ACL is denied by an invisible final rule. Displayed sequence numbers alone do not predict host lookup or counters.
Inbound and outbound
Direction is relative to the router interface. Inbound traffic enters that interface; outbound traffic leaves it. The label does not mean into or out of the entire company.
Transit traffic
Transit packets pass through the router between other devices. A ping generated by the router is a different test and may not encounter an outbound ACL in the same way.
Console and VPCS
Console is the text window for a selected lab node. VPCS is a lightweight simulated PC, with its own ip and ping commands rather than the IOS configuration language.
Counter and baseline
A counter records matches reported by the device. A baseline records the intended configuration and observed working tests before a change; counters alone do not prove an application works.
Turn the policy into a source test
Our policy is deliberately narrow: permit PC-A at 192.0.2.10 toward PC-B's subnet and deny other sources on that exit. A standard ACL cannot express a destination or service test in each entry. This makes it suitable for learning source matching but unsuitable for saying that a user may browse one server while being denied SSH to it. Numbered standard lists use 1-99 or 1300-1999; a name such as TO-B describes intent more clearly than the number 10.
- A rule identifier is not its interface number or a subnet number.
- Source addresses are not proof of user identity or trustworthy software.
Read wildcard bits in the correct direction
The wildcard 0.0.0.0 requires all address bits to match. The host keyword expresses that exact-address test. A wildcard of 0.0.0.255 ignores the last eight bits, so 192.0.2.0 0.0.0.255 matches the entire /24. It is not a mask assigned to an interface. For a contiguous /24, subtracting each subnet-mask octet from 255 produces this wildcard; noncontiguous wildcard uses require separate reasoning.
- The any keyword covers every IPv4 source in a standard entry.
- A wildcard describes matching; it does not assign addresses or create routes.
Host lookup, wildcard order and final denial
Cisco's IOS XE 17 Sequence Numbering Behavior documentation distinguishes exact 32-bit host entries, stored in a hash table, from wildcard entries ordered by sequence. The host lookup runs first; a miss reaches the wildcard list. Do not treat displayed sequence order as universal execution order. The implicit final deny drops traffic with no match; explicit deny any gives a visible counter. Build and inspect the entire list while unattached. Editing a live list affects traffic immediately; an empty or nonexistent attachment is not reliably fail-closed.
- Write the intended allow and deny examples before attaching a list.
- A host lookup is distinct from first-match evaluation within the wildcard list.
Place a source-only filter with care
A customary starting point is to put standard filtering near the destination it protects, because denying a source near its origin can remove access to unrelated destinations. This is a design heuristic, not a law. In our two-subnet lab, outbound on R1 GigabitEthernet2 means traffic being routed toward PC-B. Inbound on the same interface would instead inspect packets arriving from PC-B. The list and the attachment must both be inspected.
- Direction is defined at the named interface, not from the viewer's perspective.
- Use a transit endpoint test; router-originated pings do not duplicate this policy path.
Use several observations before diagnosing
An ACL counter increment supports the claim that traffic matched an entry, but other traffic may share that entry. Pair counters with the attachment display, exact source address, destination and test time. A failed ping could also come from bad masks, a stopped peer or an unavailable route. Establish the unrestricted baseline first, then compare allow and deny cases after attachment. Avoid clearing shared counters just to obtain a prettier result.
- Record observed output separately from this lesson's predicted behavior.
- IPv4 ACL success says nothing about parallel IPv6 traffic or application authorization.
Recognize equivalent syntax and limited coverage
Named and numbered lists can represent the same source policy. They are not applied simultaneously in the same direction on this lab interface; first build number 10 while the named list is still active, then replace the attachment and repeat tests. This chapter addresses the standard named and numbered portion of v1.1 5.6 and announced v2.0 4.6. Extended ACLs are reserved for Day 50. The current v1.1 remains applicable through 2 February 2027; v2.0 starts on 3 February.
- The course ledger must combine this partial coverage with the extended-ACL lesson.
- A paper trace demonstrates reasoning, not successful execution on a Cisco platform.
Real-world walkthrough
The printer subnet disappeared after a source filter
In a fictional branch change, an operator wants to stop a training workstation from reaching a printer subnet. They attach a source-only denial inbound on the workstation's gateway. Printing stops, but so do unrelated routed services from that workstation. The command was accepted; the placement implemented a broader policy than intended.
- Draw the workstation, router interfaces and intended printer exit before considering any changes. Identify which paths cross the current inbound filter.
- Read the list and interface attachment separately. Determine whether the rule denies the entire source or a destination-specific service.
- Compare an affected printer test with an unrelated allowed service test from the same workstation. Record both source and destination addresses.
- Design the correct destination-side placement or use an extended policy for destination and port matching. Obtain approval rather than moving a production ACL experimentally.
- In a disconnected reproduction, verify the permitted and denied matrix, restore the baseline, and document precisely which traffic was tested.
Guided GNS3 lab
Compare two sources through a standard filter
Build one routed path, apply a source-only policy, observe a reversible ordering fault, and compare a numbered equivalent. All results below are predictions; neither CSR1000v nor VPCS was executed during authoring.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| PC-A | Ethernet0 | 192.0.2.10/24; gateway 192.0.2.1 | Permitted source; .20 is the temporary denied source. |
| R1 | GigabitEthernet1 | 192.0.2.1/24 | PC-A gateway. |
| R1 | GigabitEthernet2 | 198.51.100.1/24 | PC-B gateway and outbound ACL attachment. |
| PC-B | Ethernet0 | 198.51.100.10/24; gateway 198.51.100.1 | Transit ping destination. |
Set up the lab
- Use fresh disposable nodes and save a stopped-project baseline. Confirm entitlement before obtaining or importing any Cisco image.
- Record show version and actual port labels. The example requires the CSR GigabitEthernet1/2 mapping; if different, map and substitute consistently before starting.
- Without that authorized image, perform the four-case host/wildcard worksheet. A practical alternative is an entitled CML router with mapped ports; its image must stay inside CML.
- Enter one command at a time, omit prompts, and stop on errors. Do not save temporary faults or overwrite any shared startup configuration.
Build R1's two local networks
In GNS3, right-click R1 and choose Console before typing. Use fresh routed ports with no existing ACLs. Inspect the release and map both cables, then configure the two gateway addresses. The connected routes remove any need for a static route in this experiment.
enable
show version
configure terminal
interface GigabitEthernet1
ip address 192.0.2.1 255.255.255.0
no shutdown
interface GigabitEthernet2
ip address 198.51.100.1 255.255.255.0
no shutdown
end
show ip interface briefWhat each command means
enable- Enter privileged EXEC on this authorized lab device; stop if access is not authorized.
show version- Record the actual CSR software release and platform.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1- Select the routed port directly cabled to PC-A.
ip address 192.0.2.1 255.255.255.0- Set the gateway on the first /24 network.
no shutdown- Enable the selected isolated PC-A link.
interface GigabitEthernet2- Select the routed port directly cabled to PC-B.
ip address 198.51.100.1 255.255.255.0- Set the second subnet's local gateway.
no shutdown- Enable the PC-B link without changing other ports.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip interface brief- Verify both mapped addresses and interface states.
- What you should see
- Expect both ports to become up/up after the endpoints start; record actual states before proceeding.
- Why this step matters
- Directly connected subnets make ACL behavior easier to separate from unrelated routing configuration.
Address the destination endpoint
In GNS3, right-click PC-B and choose Console before typing. Set the address and return gateway before testing from the other network. Check the displayed mask carefully; the reply must leave PC-B through R1.
ip 198.51.100.10/24 198.51.100.1
show ipWhat each command means
ip 198.51.100.10/24 198.51.100.1- Assign PC-B its address, /24 mask and local router gateway.
show ip- Read back PC-B's address, mask and gateway.
- What you should see
- Expect PC-B's displayed values to match the addressing table exactly.
- Why this step matters
- A destination can receive a request yet fail to reply when its gateway is wrong; that is not proof of an ACL denial.
Establish the unrestricted transit baseline
In GNS3, right-click PC-A and choose Console before typing. Configure the permitted source and ping PC-B. Wait for neighbor resolution and repeat if needed. Do not attach a filter until this cross-subnet exchange works.
ip 192.0.2.10/24 192.0.2.1
show ip
ping 198.51.100.10What each command means
ip 192.0.2.10/24 192.0.2.1- Assign PC-A the intended permitted source and gateway.
show ip- Confirm this test really uses .10 in the first subnet.
ping 198.51.100.10- Test PC-B through R1, including PC-B's return path.
- What you should see
- Expect replies from PC-B before any ACL exists; stop if the baseline fails.
- Why this step matters
- Later differences are meaningful only when a previously working source, destination and route are known.
Build and attach the named policy
In GNS3, right-click R1 and choose Console before typing. From #, create the complete TO-B list before applying it outbound toward PC-B. Its explicit final denial provides a counter; it is not an extra permission. Keep the console open independently of data traffic.
configure terminal
ip access-list standard TO-B
10 permit host 192.0.2.10
20 deny any
exit
interface GigabitEthernet2
ip access-group TO-B out
end
show ip interface GigabitEthernet2
show access-lists TO-BWhat each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
ip access-list standard TO-B- Create a named standard source-only ACL.
10 permit host 192.0.2.10- Permit only the exact .10 IPv4 source at sequence 10.
20 deny any- Explicitly deny remaining IPv4 sources at sequence 20.
exit- Leave ACL configuration for global configuration.
interface GigabitEthernet2- Select the outgoing PC-B-facing interface.
ip access-group TO-B out- Attach the completed source filter in the outbound direction.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip interface GigabitEthernet2- Confirm the outbound ACL identifier and interface status.
show access-lists TO-B- Inspect entry ordering and current match counters.
- What you should see
- Expect TO-B as the outbound list, with the host permit before deny any.
- Why this step matters
- Creating a list alone does not filter this interface; direction and attachment complete the policy.
Measure permitted and denied sources
In GNS3, right-click PC-A and choose Console before typing. First retest .10, then change only this isolated PC's address to the unused .20. Leave its mask and gateway unchanged. Record both test results before making any ACL edit.
ping 198.51.100.10
ip 192.0.2.20/24 192.0.2.1
show ip
ping 198.51.100.10What each command means
ping 198.51.100.10- Check that the intended permitted source still gets replies.
ip 192.0.2.20/24 192.0.2.1- Change only PC-A's source address to the denied test value.
show ip- Confirm .20 is active before interpreting the next result.
ping 198.51.100.10- Send the same transit test from the denied source.
- What you should see
- Expect .10 replies and .20 failure; a timeout alone is not sufficient without attachment and counter evidence.
- Why this step matters
- The two source cases test both sides of the requirement instead of treating any single failure as success.
Capture counters and introduce the safe fault
In GNS3, right-click R1 and choose Console before typing. Record counters after the .20 test. In this disconnected project only, insert wildcard permit 5 before wildcard deny 20. The .10 host lookup remains separate. Keep both original entries and do not save this fault.
show access-lists TO-B
configure terminal
ip access-list standard TO-B
5 permit any
end
show access-lists TO-BWhat each command means
show access-lists TO-B- Record actual host-permit and explicit-denial counters after the baseline tests.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
ip access-list standard TO-B- Re-enter the exact named standard list.
5 permit any- Add wildcard permit 5 ahead of wildcard deny 20; this does not bypass .10's host lookup.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show access-lists TO-B- Confirm entry 5 and unchanged entries 10/20; display order alone does not establish host matching or counters.
- What you should see
- Expect wildcard permit 5 before wildcard deny 20. Source .20 has no host entry and can now match 5; .10 retains its host permit. Record actual output and counters; do not claim both original entries are shadowed.
- Why this step matters
- This controlled failure changes .20's wildcard decision without changing addressing, routing or endpoint software.
Observe the undesired permission
In GNS3, right-click PC-A and choose Console before typing. Keep PC-A at .20 and repeat the same destination. If it still fails, preserve that observation and inspect the attachment and baseline rather than claiming the predicted outcome.
show ip
ping 198.51.100.10What each command means
show ip- Verify the supposedly denied source is still .20.
ping 198.51.100.10- Test .20: after its host lookup misses, wildcard permit 5 is reached before wildcard deny 20.
- What you should see
- Expect .20 replies: its host lookup misses and permit any precedes deny any in the wildcard list.
- Why this step matters
- An unintended success is a security failure even when connectivity appears healthier to the user.
Remove only the known bad entry
In GNS3, right-click R1 and choose Console before typing. Remove sequence 5, leaving the original permit and deny unchanged. Review the resulting list before returning to the endpoint. This is a specific inverse, not a general rollback method for unknown edits.
configure terminal
ip access-list standard TO-B
no 5
end
show access-lists TO-BWhat each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
ip access-list standard TO-B- Select the same list containing the deliberate fault.
no 5- Remove the temporary sequence 5 entry only.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show access-lists TO-B- Verify sequences 10 and 20 remain in their intended order.
- What you should see
- Expect the original two entries with no broad earlier permit.
- Why this step matters
- A narrow repair preserves the known policy and avoids replacing it with a new untested configuration.
Retest the restored policy
In GNS3, right-click PC-A and choose Console before typing. Test .20 while it is still active, then restore .10 and test again. Preserve actual results and timestamps; the successful .10 result alone would not establish that the deny was restored.
ping 198.51.100.10
ip 192.0.2.10/24 192.0.2.1
ping 198.51.100.10What each command means
ping 198.51.100.10- Confirm the restored policy denies the .20 source.
ip 192.0.2.10/24 192.0.2.1- Restore PC-A's intended permitted address.
ping 198.51.100.10- Confirm the original source is allowed after the repair.
- What you should see
- Expect .20 failure followed by .10 replies, matching the original policy matrix.
- Why this step matters
- Restoration requires both intended access and intended denial, not just an accepted no command.
Replace the attachment with a numbered equivalent
In GNS3, right-click R1 and choose Console before typing. Create number 10 completely while TO-B remains attached. Replace this interface's outbound attachment only after reviewing the numbered entries. No other interface or direction changes.
configure terminal
access-list 10 permit host 192.0.2.10
access-list 10 deny any
interface GigabitEthernet2
ip access-group 10 out
end
show ip interface GigabitEthernet2
show access-lists 10What each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
access-list 10 permit host 192.0.2.10- Create the numbered standard permit for the exact source.
access-list 10 deny any- Add the explicit denial to the numbered list.
interface GigabitEthernet2- Return to the same outbound filtering interface.
ip access-group 10 out- Replace the outbound attachment with number 10.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip interface GigabitEthernet2- Verify number 10, not TO-B, is now the outbound ACL.
show access-lists 10- Inspect the numbered policy before traffic tests.
- What you should see
- Expect the interface to reference 10 and the numbered list to express the same source policy.
- Why this step matters
- Named and numbered are identifier styles; equivalent outcomes still require a repeated verification matrix.
Verify numbered behavior and restore the source
In GNS3, right-click PC-A and choose Console before typing. Repeat both source cases for the numbered attachment, then leave PC-A at .10. Do not infer numbered behavior from the earlier named-list observations.
ping 198.51.100.10
ip 192.0.2.20/24 192.0.2.1
ping 198.51.100.10
ip 192.0.2.10/24 192.0.2.1What each command means
ping 198.51.100.10- Check the permitted source under numbered ACL 10.
ip 192.0.2.20/24 192.0.2.1- Temporarily select the denied source again.
ping 198.51.100.10- Check the numbered list rejects .20.
ip 192.0.2.10/24 192.0.2.1- Restore the baseline PC-A address before cleanup.
- What you should see
- Expect the same permitted and denied decisions as TO-B; record deviations instead of reporting equivalence automatically.
- Why this step matters
- Equivalent configuration syntax is useful only when the installed policy and observed outcomes agree.
Detach the exercise policy and preserve evidence
In GNS3, right-click R1 and choose Console before typing. Return the router to its unrestricted baseline in this disposable project. Detach first, then remove the two exercise lists. After this block, reopen PC-A Console and repeat its original ping manually as the final baseline check.
configure terminal
interface GigabitEthernet2
no ip access-group 10 out
exit
no access-list 10
no ip access-list standard TO-B
end
show ip interface GigabitEthernet2What each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet2- Select the sole exercise attachment point.
no ip access-group 10 out- Detach the numbered filter without resetting the interface.
exit- Return to global configuration after detaching.
no access-list 10- Remove the unused exercise numbered ACL.
no ip access-list standard TO-B- Remove the unused named exercise ACL.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip interface GigabitEthernet2- Confirm no outbound exercise list remains.
- What you should see
- Expect the baseline attachment state restored; the required PC-A retest should again receive replies.
- Why this step matters
- Detach-before-delete avoids relying on empty-list behavior and preserves a clear record of the intended cleanup.
Verify
- Record R1's actual release, both cable mappings and successful unrestricted PC-A to PC-B replies.
- For the named list, verify outbound attachment, explicit entries, .10 success and .20 failure together.
- For the fault, record sequence 5 and the same .20 test before removing only that entry.
- After repair and after numbered replacement, repeat the complete allow-and-deny matrix.
- After detaching cleanup, reopen PC-A Console, run ping 198.51.100.10, and retain actual baseline-recovery evidence.
Troubleshoot
- If neither endpoint works initially, fix the address, gateway, link or connected route before attributing anything to an ACL.
- If .20 passes unexpectedly, inspect its source, attachment and wildcard permit 5. With no .20 host entry, permit 5 bypasses wildcard deny 20. Do not apply that explanation to .10's host lookup.
- If counters do not change, verify that the tested traffic is transit traffic through the attached interface; avoid substituting a router-generated ping.
- If sequence editing is rejected on a different image, stop and use the declared platform or a paper trace. Do not delete an active shared ACL experimentally.
GNS3 does not provide Cisco images. A license or entitlement must permit the image in the selected environment; do not share or redistribute image files. Cisco Modeling Labs is an official alternative. Its supplied Cisco reference images are licensed for use within CML, not automatically for export to GNS3. An unlicensed learner must use the explicitly labeled paper alternative, not report simulated Cisco execution.
- Remove the temporary sequence 5 before comparing named and numbered policies.
- Detach the exercise ACL, remove only TO-B and number 10, restore PC-A .10, and repeat the baseline ping.
- Keep private before/fault/repair notes and stop the disconnected nodes; do not distribute licensed images.
Practice set
Answer before you reveal
01Why does TO-B's sequence 5 permit .20 without bypassing .10's host entry?
Cisco IOS XE 17 standard ACLs consult the host hash before ordered wildcard rules. Compare both source decisions; do not infer counters from numeric display order.
02What does 192.0.2.0 0.0.0.255 match?
The wildcard ignores the final octet. It is not the /24 interface mask and does not create a connected route.
03Why test from PC-A rather than R1?
A locally generated packet is not the same forwarding case. Use the actual source endpoint and record its address.
04What happens to an unmatched packet in the populated list?
An explicit deny is not needed to create the rejection, but provides visible evidence for the controlled test.
05Why attach TO-B near the protected destination?
Placement limits the paths affected; it does not turn a standard ACL into a destination-aware or port-aware filter.
06Does a matching permit counter prove user authorization?
Authentication, application permissions and encryption require separate controls. Even an allowed ping has only a narrow reachability meaning.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Standard ACLs inspect IPv4 source addresses, not services or destination ports.
- A wildcard zero bit must match; a one bit is ignored.
- On IOS XE 17, check the host lookup first, then wildcard order on a miss; no match means deny.
- Validate the list and its interface direction as separate pieces of policy.
- Test both allowed and denied traffic using real transit endpoints.
- Coverage and deterministic checks are not claims of runtime or independent approval.