Back to Cisco & Networking CyberPatriot Hub

Cisco & Networking · Lesson 01

Cisco Competition Workflow

Turn the overall competition strategy into a practical networking workflow: understand the topology, collect a device baseline, trace required traffic, make controlled changes, and verify the real network path.

This lesson is the map for the Cisco pathway. Later lessons go deeper into addressing, subnetting, IOS, switching, VLANs, routing, ACLs, device hardening, troubleshooting, and Packet Tracer.

Lesson Snapshot

First-look areas6

Baseline commands12

Workflow stages8

Main goalControlled network defense

Learning objectives

Build a repeatable network-defense process

Turn the overall CyberPatriot strategy into a repeatable Cisco and networking workflow.

Read a topology and scenario before entering configuration mode or changing device settings.

Build a baseline using safe show commands and Packet Tracer evidence.

Trace required traffic from source to destination before deciding where the problem exists.

Separate high-confidence fixes from findings that need more evidence or coordination.

Make narrow configuration changes and verify end-to-end connectivity afterward.

Core idea

Networking is path reasoning

Do not treat every Cisco task as an isolated command. Understand where traffic starts, where it must go, which devices control it, and what evidence proves each step works.

Safety boundary

Inspect before configuration mode

Cisco IOS accepts powerful changes quickly. Collect the baseline first so you know what the network looked like before remediation.

Networking fundamentals

Six ideas behind the workflow

Topology

The topology shows the devices, links, network segments, VLANs, addressing, and traffic paths that make the network work.

Baseline

A baseline is the known current state of interfaces, VLANs, routes, ACLs, users, services, and management access before changes begin.

Traffic path

A network problem becomes easier when you follow traffic from source to destination instead of changing unrelated settings.

Control point

A control point is the device, interface, VLAN, route, ACL, or service that actually determines whether traffic is allowed or forwarded.

Change scope

A good competition change is narrow enough to fix the confirmed problem without disrupting required traffic or administration.

Verification

Verification proves both device state and real connectivity. A correct-looking configuration is not enough if the client still cannot reach the server.

First look

Understand the environment before touching configuration

Scenario requirements

Which users, devices, services, and management paths are required?

Which traffic should be allowed?

Which traffic should be blocked?

Are there restrictions on changing addresses, passwords, routes, or services?

Physical and logical topology

Which devices connect to each other?

Which switch ports and router interfaces are used?

Which VLANs or subnets exist?

Where are servers, clients, and management stations located?

Addressing

What IPv4 addresses and subnet masks are assigned?

What are the default gateways?

Which interfaces should be up?

Are any addresses duplicated or outside the intended subnet?

Switching

Which VLANs exist?

Which ports are access ports?

Which links are trunks?

Which VLANs must cross each trunk?

Routing

Which networks are directly connected?

Which static or dynamic routes exist?

Is there a default route?

Can every required subnet reach the next hop?

Policy and management

Which ACLs affect required traffic?

How is the device managed?

Are SSH, local accounts, and enable credentials configured appropriately?

Are unused or unnecessary management services exposed?

Baseline commands

Read the device before changing it

show running-config

Display the active configuration currently controlling the device.

show startup-config

Display the configuration stored for the next reload.

show ip interface brief

Summarize interface status, protocol state, and IPv4 addressing.

show interfaces

Display detailed interface state, counters, errors, duplex, speed, and line status.

show vlan brief

Display VLANs and access-port membership on a switch.

show interfaces trunk

Display trunk state, native VLAN, encapsulation, and allowed/active VLANs.

show mac address-table

Display learned MAC addresses and the switch ports associated with them.

show ip route

Display the IPv4 routing table and the source of each route.

show access-lists

Display configured ACL entries and counters where supported.

show cdp neighbors

Display directly connected Cisco neighbors when CDP is enabled.

show users

Display currently connected management users where supported.

show clock

Display device time so logs and events can be interpreted in context.

Platform note

Exact show-command support can vary by Cisco IOS version, device model, and Packet Tracer feature set. If a command is unavailable, use the closest supported inspection command rather than assuming the feature itself does not exist.

Command awareness

Know when you are observing and when you are changing

Inspection

show, ping, traceroute, show running-config, show interfaces, show ip route

Collects evidence without intentionally changing the device configuration.

Configuration mode

configure terminal, interface, vlan, line vty, ip access-list

Moves into a mode where commands can modify the active configuration.

Operational change

shutdown, no shutdown, clear, reload

Can directly affect device operation even if not entered from global configuration mode.

Save action

copy running-config startup-config, write memory

Persists the current running configuration so it survives a reload.

Competition workflow

Eight stages from topology to verified configuration

Read the scenario and map required traffic

Identify required users, services, network segments, management paths, and security requirements before opening configuration mode.

Identify the topology and device roles

Label routers, switches, endpoints, servers, VLANs, subnets, uplinks, trunks, and management interfaces.

Collect a read-only baseline

Use show commands, ping, traceroute, and Packet Tracer evidence to understand the current state.

Trace the failing or protected path

Follow traffic from source to destination and identify the first point where the expected behavior stops.

Classify the finding

Decide whether the issue is confirmed, suspicious, unknown, scenario-required, or dependent on another component.

Make the smallest justified change

Modify only the interface, VLAN, route, ACL, account, or service required to correct the confirmed issue.

Verify locally and end to end

Re-run show commands and test the real source-to-destination path after the change.

Document and save deliberately

Record important changes, confirm the running state is correct, and save only when you are confident the configuration should persist.

Trace the traffic

Ask the next network question in order

Can the source reach its default gateway?

Tests local addressing, access VLAN, switch path, and gateway availability.

Can the source reach another host in the same subnet?

Helps isolate Layer 2 and local host addressing problems.

Can the source reach the next routed hop?

Tests whether routing and interface state work beyond the local segment.

Does the routing table contain the destination network?

Determines whether the router knows where to forward the traffic.

Does an ACL affect the path?

Checks whether policy intentionally or accidentally blocks the traffic.

Does the destination service respond?

Separates network reachability from application or service problems.

Troubleshooting layers

Move from the link outward

Physical / Link

Device power, cable connection, interface state, speed, duplex, line protocol.

Layer 2

VLAN membership, access ports, trunks, MAC learning, native VLAN, port security.

Layer 3

IP address, subnet mask, default gateway, routed interfaces, routing table.

Policy

ACLs, management restrictions, permitted sources, required service exposure.

Services

DHCP, DNS, SSH, HTTPS, or other scenario-defined services.

End-to-end verification

Ping, traceroute, application test, management login, and Packet Tracer simulation.

Classification

Not every unfamiliar configuration is a problem

Required

The scenario explicitly needs the device, interface, VLAN, route, account, service, or traffic flow.

Protect it and verify it after every related change.

Confirmed issue

Evidence clearly shows a configuration or security problem.

Remediate narrowly, then verify.

Suspicious

The finding has warning signs but needs more evidence before a destructive change.

Preserve configuration evidence and investigate further.

Unknown

The purpose is not yet clear.

Do not remove or disable it merely because it is unfamiliar.

Controlled IOS actions

Understand the effect before typing the command

Enter privileged EXEC mode

enable

This changes command privilege, not device configuration by itself.

Enter global configuration mode

configure terminal

Commands entered from here can modify the active running configuration.

Select one interface

interface GigabitEthernet0/1

Confirm the correct physical or logical interface before making changes.

Review current interface configuration

do show running-config interface GigabitEthernet0/1

The do prefix can run eligible EXEC show commands while in configuration mode.

Exit one configuration level

exit

Moves back one mode; it does not undo commands already entered.

Return to privileged EXEC

end

Exits configuration mode but does not save or roll back changes.

Change tracking

Record enough to explain and reverse important changes

Device

Which router, switch, or network node was changed.

Interface / feature

The exact interface, VLAN, ACL, route, line, or management feature involved.

Finding

What the baseline evidence showed before the change.

Action

The exact configuration change made.

Verification

The show command or end-to-end test proving the result.

Rollback

The previous value or configuration needed to reverse the change.

High-risk shortcuts

Actions that create avoidable network outages

Entering configuration mode before collecting a baseline

You lose confidence about what was already present and may change the wrong component.

Using shutdown/no shutdown as random troubleshooting

Can interrupt required links and hide the real configuration problem.

Deleting ACLs instead of tracing their purpose

Can open unauthorized traffic or remove a required security boundary.

Changing multiple layers at once

Makes it difficult to know which change fixed or broke the network.

Saving immediately after every command

Can persist a bad configuration before full verification.

Reloading the device to solve an unclear issue

Causes downtime and can load a different startup configuration than the current running state.

Verification

Prove both configuration and connectivity

Interfaces

Required interfaces are up/up and use the intended addressing or switchport mode.

VLANs and trunks

Required VLANs exist, access ports are correct, and trunks carry only the needed VLANs.

Routing

The routing table contains the required networks and next hops.

ACLs

Required traffic is permitted and prohibited traffic remains blocked according to the scenario.

Management

Authorized administrators can still reach and authenticate to the device through the required management path.

End-to-end

Clients can reach required gateways, servers, and services across the actual path.

Defensive lab

Review a fictional competition network before changing it

Read the fictional scenario: Morgan manages the network from VLAN 99, Staff uses VLAN 10, Students use VLAN 20, and an HTTPS server lives on VLAN 30.

Draw or label the topology: two switches, one router, client ports, trunk links, VLANs, gateways, and the server connection.

Collect a read-only baseline with show running-config, show ip interface brief, show vlan brief, show interfaces trunk, show ip route, and show access-lists.

Trace required traffic from a Staff client to the HTTPS server and from Morgan's management workstation to the router and switches.

Classify each finding as Required, Confirmed issue, Suspicious, Unknown, or Dependency.

Apply only the single fictional change supported by the evidence and record the prior value for rollback.

Verify device state with show commands and test both required traffic paths end to end.

Only after verification, decide whether the running configuration should be saved to startup configuration.

Lesson checklist

Before moving on

I read the scenario before entering configuration mode.

I identify device roles, VLANs, subnets, links, servers, clients, and management paths.

I collect a baseline with show commands before making changes.

I know the difference between inspection commands, configuration commands, operational changes, and save actions.

I trace required traffic from source to destination before choosing a fix.

I classify findings instead of treating every unfamiliar configuration as wrong.

I change one narrow area at a time when possible.

I preserve required administration and business traffic.

I verify the local device state after each meaningful change.

I verify end-to-end connectivity from the user or service perspective.

I document important changes and rollback information.

I save the running configuration only after confirming the desired final state.

Reflection

Check your reasoning

Question 1

Why should the topology be understood before configuring individual interfaces?

Question 2

What is the difference between running-config and startup-config?

Question 3

Why can a failed ping be caused by multiple layers of the network?

Question 4

Why should an unfamiliar route or ACL be investigated before removal?

Question 5

What evidence would you collect before changing a trunk?

Question 6

Why is end-to-end verification stronger than checking only one router or switch?

Carry this forward

Understand the topology, collect the baseline, trace the traffic, classify the evidence, make the smallest justified change, and verify the real network path afterward.

Back to Cisco & Networking CyberPatriot Hub

Next Lesson →