Cisco & Networking · Lesson 18
Cisco & Networking Final Review Checklist
Bring the full pathway together into one competition-ready review: topology, switching, VLANs, trunks, routing, ACLs, services, NAT, hardening, troubleshooting, verification, and safe persistence.
This is not a list of commands to run blindly. It is a structured final review that helps you decide what is required, what is confirmed wrong, what still needs evidence, and what should be left alone.
Final Snapshot
Learning objectives
Finish the network with confidence, not guesswork
Review the complete Cisco & Networking pathway from topology through management hardening.
Use a competition-ready final review sequence without forcing every check into one universal workflow.
Verify switching, VLANs, trunks, inter-VLAN routing, routing, ACLs, services, NAT, and management access.
Separate confirmed issues from suspicious findings and harmless differences.
Preserve required services while reducing unnecessary exposure.
Finish with documented evidence, end-to-end verification, and a deliberate save decision.
Final review principle
Protect required functionality while reducing unnecessary exposure
The best final state is not the most restrictive configuration. It is the configuration that satisfies the scenario, preserves required services, and removes only what evidence shows is unsafe or unnecessary.
Final warning
Do not create a last-minute outage
Broad ACL edits, trunk changes, route changes, management ACLs, account removal, and service shutdowns should not be rushed during the final pass.
Review mindset
Six rules for the final pass
Required traffic first
A secure device that breaks the required network is not a successful result. Preserve the services and communication paths the scenario says must work.
Evidence before action
Read operational state and configuration before making changes. A suspicious setting is not automatically wrong.
Narrow changes
Fix the exact interface, VLAN, route, ACL entry, service, account, or management setting supported by the evidence.
Verify after every meaningful change
Retest the original requirement plus one unaffected path so a fix does not silently break something else.
Document as you go
Keep short notes about findings, changes, verification, and rollback so the final review is based on facts rather than memory.
Save only when stable
Do not make the running configuration persistent until the required paths and management access have been verified.
Pathway recap
What each lesson contributed
Cisco Competition Workflow
Scenario, topology, baseline, packet path, evidence, narrow change, verification.
Networking Foundations & the OSI Model
Layered reasoning, MAC vs IP, transport ports, encapsulation, device roles.
IPv4 Addressing & Subnet Masks
Network/host portions, masks, prefixes, valid hosts, private ranges, block size.
Subnetting for Competition
Capacity, equal-size subnetting, VLSM, overlap detection, competition calculations.
Cisco IOS CLI & Safe Navigation
Modes, help, show commands, running vs startup config, safe command habits.
Switching, MAC Tables & Ethernet
MAC learning, forwarding, interfaces, counters, ARP, duplex and speed.
VLANs & Access Ports
Broadcast domains, access mode, VLAN membership, endpoint segmentation.
Trunks, Native VLANs & 802.1Q
Multiple VLANs, tagging, native VLAN, allowed lists, trunk troubleshooting.
Inter-VLAN Routing
Router-on-a-stick, SVIs, gateways, Layer 3 forwarding between VLANs.
Switch Port Security
Secure MACs, sticky learning, limits, violations, defensive access-port controls.
Router Interfaces & Static Routing
Layer 3 interfaces, connected routes, next hops, static and default routing.
Routing Concepts & Dynamic Protocol Awareness
RIP, OSPF, EIGRP, route source, AD, metrics, neighbors.
Access Control Lists
First match, implicit deny, standard vs extended, wildcard masks, direction.
DHCP, DNS & NAT Concepts
Client configuration, relay, name resolution, translation, service dependencies.
Cisco Device Hardening & Management Plane
SSH, VTY, accounts, web management, SNMP, logging, source restriction.
Network Troubleshooting Workflow
Symptom scope, packet path, layered evidence, hypothesis, controlled fix.
Packet Tracer Defensive Practice
Known-good baselines, hidden faults, verification matrices, timed drills.
First look
Read the environment before touching it
Scenario
What services, users, management paths, and restrictions are explicitly required?
Topology
Which switches, routers, interfaces, VLANs, subnets, and servers form the expected path?
Management path
How will you maintain authorized access while hardening the device?
Critical dependencies
Which paths must remain working before you change anything?
Known differences
Are there platform or Packet Tracer limitations that affect commands or features?
Rollback
Do you have a clean copy, console path, or documented original state before major changes?
Rapid baseline
Collect useful operational state quickly
show running-configReview the active configuration before changing it.
show startup-configCompare persistent configuration where useful.
show ip interface briefCheck Layer 3 addressing and interface state.
show interfaces statusCheck switchport status, VLAN, speed, and duplex.
show vlan briefReview VLANs and access-port membership.
show interfaces trunkReview trunk operation, native VLAN, and allowed VLANs.
show mac address-tableCheck Layer 2 learning and port placement.
show ip routeReview connected, static, and dynamic routes.
show access-listsReview traffic policy and counters.
show usersReview current management sessions.
show loggingReview recent events where available.
Switching
Verify the Layer 2 foundation
Required access ports are connected
show interfaces status and endpoint testing confirm the correct physical or simulated link.
Access ports are in the intended VLANs
show vlan brief and show interfaces <interface> switchport match the topology plan.
Endpoint MAC addresses appear where expected
show mac address-table confirms source MAC learning on the expected access or uplink interfaces.
Speed and duplex are reasonable
show interfaces shows no obvious mismatch or steadily increasing error pattern.
Required uplinks are operational
Relevant switch uplinks are connected and forwarding.
Unused ports are understood
Do not shut down ports merely because they are currently quiet. Confirm role first.
VLANs & trunks
Verify segmentation and VLAN transport
Required VLANs exist
show vlan brief confirms the documented VLAN IDs and names where supported.
Access ports use the correct VLAN
Each endpoint-facing port matches the intended user or service zone.
Trunks are operational
show interfaces trunk shows the intended interfaces operating as trunks.
Allowed VLAN list is correct
Required VLANs cross each trunk without unnecessary broadening.
Native VLAN design matches on both ends
Compare trunk configuration and operational state at both ends.
STP is not unexpectedly blocking the needed path
Use show spanning-tree vlan <id> where relevant.
Inter-VLAN routing
Verify Layer 3 gateways between VLANs
Each VLAN has the intended gateway
Endpoints and Layer 3 interfaces use matching subnet design.
Subinterfaces or SVIs are operational
show ip interface brief confirms the Layer 3 gateway interfaces are up.
802.1Q encapsulation matches the VLAN plan
Router-on-a-stick subinterfaces use the intended VLAN IDs.
Native VLAN configuration is deliberate
Do not mix native and tagged expectations accidentally.
Permitted inter-VLAN traffic succeeds
Test the real service, not only ping.
Restricted inter-VLAN traffic remains blocked
ACL or policy behavior still matches the scenario after fixes.
Routing
Verify every required Layer 3 path
Connected routes are present
Operational Layer 3 interfaces produce the expected connected networks.
Static routes use valid next hops
The configured next hop is reachable and belongs to the intended path.
Default route points toward the real edge
0.0.0.0/0 does not hide a missing internal route.
Dynamic neighbors are intentional
OSPF or EIGRP adjacencies exist only on required transit links.
Passive interfaces are deliberate
User-facing networks can be advertised without unnecessary neighbor formation.
Route preference makes sense
Longest prefix match, administrative distance, and metric explain which route wins.
Return routes exist
The destination side has a valid path back to the source.
ACLs
Verify policy without breaking required traffic
ACL purpose is known
Every important ACL should map to a scenario requirement or documented design.
Rule order is correct
Specific exceptions appear before broader rules when required.
Implicit deny is accounted for
Required traffic is explicitly permitted before the end of the list.
Wildcard masks are correct
The intended hosts or subnets are matched precisely.
Protocol and ports are correct
TCP, UDP, ICMP, and destination ports match the real application.
Interface and direction are correct
ip access-group placement matches the actual packet path.
Counters support the conclusion
Controlled traffic causes the expected ACE counters to move where supported.
Services
Verify the service chain individually
DHCP
Clients receive the intended IP, mask, gateway, DNS server, and lease from the correct scope.
DHCP relay
Client-facing routed interfaces use the correct helper-address when the server is remote.
DNS
Required names resolve to the intended IP address and the resolver itself is reachable.
NAT
Inside/outside roles, classification, and translation entries match the intended edge path.
HTTPS / application
The real required service responds, not merely ICMP.
Management
SSH and other required administration services work only from authorized sources.
Management plane
Finish hardening without losing authorized access
Authorized admin accounts are known
Review usernames, privileges, and current sessions before removing anything.
Privileged EXEC is protected
Use enable secret or the platform's supported stronger credential mechanism.
SSH is functional
Test an authorized SSH login before removing Telnet.
VTY transport is deliberate
transport input reflects required management protocols only.
Management source restriction is correct
VTY access-class or equivalent permits authorized sources and blocks unintended ones.
HTTP / HTTPS management is justified
Disable unnecessary web management without removing a required service.
SNMP is intentional
Review version, source restrictions, and whether monitoring is actually required.
Logs and time remain useful
Do not erase evidence; maintain accurate timestamps where supported.
Port security
Review endpoint controls without treating every port the same
Port-security is used only on appropriate access ports
Do not apply endpoint assumptions to trunks or infrastructure uplinks.
Maximum secure MAC count matches the role
A phone-plus-PC port may legitimately require more than one secure MAC.
Secure MAC addresses are expected
Compare learned or sticky addresses with the authorized endpoint design.
Violation mode is understood
Protect, restrict, and shutdown behaviors have different operational impact.
Err-disabled state is investigated before recovery
Do not simply bounce the interface without identifying the cause.
Command reference
Choose the command that answers the question
Interfaces
show ip interface briefshow interfaces statusshow interfaces <interface>VLANs
show vlan briefshow interfaces <interface> switchportTrunks
show interfaces trunkshow running-config interface <interface>MAC / ARP
show mac address-tableshow arpRouting
show ip routeshow ip protocolsshow ip ospf neighborshow ip eigrp neighborsACLs
show access-listsshow ip access-listsshow ip interface <interface>DHCP
show ip dhcp poolshow ip dhcp bindingshow ip dhcp conflictNAT
show ip nat translationsshow ip nat statisticsManagement
show usersshow ip sshshow loginshow running-config | section lineLogs
show loggingshow clockSymptom patterns
Use scope to decide where to look first
One host fails, peers in the same VLAN work
Endpoint configuration, access port, port security, NIC, cable, host firewall.
One entire VLAN fails
Gateway, trunk allowance, SVI/subinterface, helper-address, VLAN-specific ACL.
Same VLAN works, remote subnet fails
Gateway, routing table, next hop, ACL, return path.
Ping works, one application fails
Service process, transport port, ACL, DNS if name-based.
Name fails, raw IP works
DNS resolver, DNS server, record, port 53 policy.
Inside works, outside fails
Default route, NAT classification, outside interface, upstream path.
SSH fails from one subnet only
VTY source ACL, management routing, intentional source restriction.
Only one VLAN fails across trunk
Allowed VLAN list, VLAN existence, STP, native mismatch depending on design.
High-risk actions
Commands and shortcuts that deserve extra caution
erase startup-config / write eraseDestroys persistent configuration and is not an appropriate troubleshooting shortcut.
reloadCan create downtime and may boot into an older or incomplete startup configuration.
default interfaceCan remove multiple required settings at once.
permit ip any anyCan destroy intended policy and hide the real ACL issue.
switchport trunk allowed vlan allCan expose unnecessary VLANs and hide a precise trunking problem.
no shutdown everywhereCan activate unused or intentionally disabled interfaces.
clear tables before reviewCan erase useful MAC, ARP, NAT, or counter evidence.
remove every unfamiliar accountCan break required administration or services.
Evidence classification
Know what you know before changing anything
Required
The scenario or design explicitly depends on this service, route, VLAN, account, or communication path.
Confirmed issue
Operational evidence proves the current state violates the expected design.
Suspicious
The setting deserves investigation but has not yet been proven wrong.
Unknown
The purpose is not yet understood. Preserve it until more evidence is available.
Dependency
Another required service or path relies on this configuration.
Reasoning check
Do not confuse hardening with indiscriminate removal
A trunk carries all VLANs
Weak response
It must be wrong because trunks should always be tightly restricted.
Better reasoning
Compare the allowed set to the documented design. Broad carriage may be unnecessary, but change only when the requirement is clear.
An unknown administrator account exists
Weak response
Delete it immediately.
Better reasoning
Check scenario documentation, privilege, current sessions, and service dependencies before deciding whether it is unauthorized.
One ACL has zero hits
Weak response
Remove it because it is unused.
Better reasoning
Zero hits may mean no recent matching traffic, wrong test path, or an inactive requirement. Investigate before removal.
A static route and OSPF route both exist
Weak response
Delete the static route because dynamic routing is better.
Better reasoning
Compare destination prefix, administrative distance, topology purpose, and scenario design before changing route preference.
HTTP management is enabled
Weak response
Replace it with HTTPS without checking anything else.
Better reasoning
First determine whether web management is required at all. Disable unnecessary exposure rather than automatically substituting another service.
A port is currently unused
Weak response
Shut down every quiet port immediately.
Better reasoning
Confirm the port is truly unused and not reserved for a required device or delayed connection before changing it.
Final pass order
One complete review before saving
Topology & interface sanity
Confirm device roles, link state, IP addressing, and access-port placement.
Layer 2 integrity
Review VLANs, trunks, native VLAN expectations, MAC learning, and STP evidence.
Layer 3 reachability
Review gateways, routes, next hops, dynamic neighbors, and return paths.
Policy & services
Review ACLs, DHCP, DNS, NAT, application reachability, and required restrictions.
Management plane
Review accounts, SSH, VTY, web management, SNMP, logs, and source restrictions.
End-to-end verification
Run the required application tests from the relevant source zones.
Persistence & documentation
Confirm notes, rollback, and final save only after the network is stable.
End-to-end verification
Test the actual required outcomes
Staff
Authorized Staff endpoint reaches its gateway and required internal services.
Students
Student endpoint receives correct addressing and reaches only permitted services.
Servers
Required DNS, DHCP, HTTPS, or other fictional services respond correctly.
Management
Authorized admin source can SSH to required network devices.
Inter-VLAN
Permitted inter-VLAN paths work and restricted paths remain restricted.
Routing
Remote networks work in both directions through the intended path.
NAT
Required inside traffic translates outward and return traffic succeeds.
Resilience
Unrelated known-good traffic still works after the final changes.
Documentation
Keep a short evidence trail
Finding
VLAN 30 missing from trunk allowed list.
Evidence
show interfaces trunk lists 10,20,99 but not 30.
Impact
Server VLAN unreachable across the uplink.
Change
Added only VLAN 30 to the existing allowed list.
Verification
VLAN 30 traffic works; other VLANs unchanged.
Rollback
Restore previous allowed list if unexpected behavior appears.
Competition day checklist
A compact sequence to keep beside you
Read the scenario before touching configuration.
Identify required services and prohibited changes.
Map the topology and management path.
Collect a fast baseline with show commands.
Do not assume suspicious means wrong.
Preserve working traffic while hardening.
Use one change at a time for high-impact settings.
Retest the actual application after every major fix.
Keep a short change log.
Verify return paths, not only forward paths.
Preserve authorized management access.
Save only after the final verification pass.
Final readiness
You should be able to explain the network, not just make it pass
I can identify the role of each major device in the topology.
I can explain why each required VLAN and trunk exists.
I can identify each VLAN gateway and the route to remote networks.
I can explain which ACLs restrict which traffic and why.
I can verify DHCP, DNS, NAT, and application dependencies separately.
I can preserve authorized SSH management while reducing unnecessary exposure.
I can distinguish confirmed issues from suspicious or unknown settings.
I can make one narrow change and verify its effect.
I can test both forward and return paths.
I can document a final stable state and save it deliberately.
Reflection
Final reasoning check
Question 1
Why is a suspicious setting not enough evidence to justify a change?
Question 2
Which checks should happen before an ACL or route is modified?
Question 3
Why can a network pass ping tests and still fail the competition requirement?
Question 4
What is the difference between a required dependency and an unknown configuration item?
Question 5
Why should management-plane verification happen before the final save?
Question 6
What would make you delay a change even if it appears to improve security?
Cisco pathway complete
You now have a complete progression from networking foundations through Packet Tracer defensive practice and final competition review. The remaining work is wiring navigation, testing every route, running the final build, and then enabling the section on the main CyberPatriot hub.