CliDeck
PlatformLog in
Workspace

A Short Guide to Initial Configuration of Cisco Catalyst 9200/9300/9400/9500 (IOS XE 17.x)

Network Device Recovery
#Cisco#Catalyst config#Network Device Recovery#network-operations
← Back to Blog

Short answer

For an initial Cisco Catalyst 9200, 9300, 9400, or 9500 setup, start by confirming the console session and device identity, then set the management baseline, administrator access, interface roles, and required VLAN or routing settings. Save the configuration and verify management reachability before handing the switch over.

Configuration Parameters Used in the Examples

ItemValuePurpose
Management IP192.168.10.2Switch management address
Default Gateway192.168.10.1Management gateway
NTP Server192.168.10.5Time synchronization
VLAN 10USERSUser segment
Uplink VLANs10,20,30Allowed VLANs
Access PortsGi1/0/1–24Client-facing interfaces
Uplink InterfaceTe1/1/1Upstream connection

1. Initial Access and Configuration Reset

enable
write erase
reload

Skip setup dialog:

no

2. Basic System Settings

conf t
hostname SW-CORE01
ip domain-name example.local

3. Enable SSH and Generate Keys

crypto key generate rsa modulus 2048
ip ssh version 2

4. Create a Local Administrator

username admin privilege 15 secret <PASSWORD>

5. Enable AAA

aaa new-model
aaa authentication login default local
aaa authorization exec default local

6. VLAN and Access Ports

vlan 10
name USERS
exit

interface range GigabitEthernet1/0/1-24
switchport mode access
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enable

7. Uplink Trunk

interface TenGigabitEthernet1/1/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,20,30

8. Management Interface

Catalyst 9300/9400/9500:

interface GigabitEthernet0/0
ip address 192.168.10.2 255.255.255.0
no shutdown
ip default-gateway 192.168.10.1

Catalyst 9200:

interface AppGigabitEthernet1/0/1
ip address 192.168.10.2 255.255.255.0
no shutdown
ip default-gateway 192.168.10.1

9. System Services

service password-encryption
logging buffered 64000
no ip http server
no ip http secure-server

10. Time and NTP

clock timezone CST -6
ntp server 192.168.10.5

11. Basic Management Plane Security

ip ssh time-out 30
ip ssh authentication-retries 2
login block-for 120 attempts 3 within 60

12. Save the Configuration

end
write memory

Summary

This short reference covers everything required to bring a Catalyst 9K switch into service: VLANs, trunks, AAA, SSH, management access, and a minimal security baseline. The format makes it easy to use in the field or integrate into automation systems—for example, storing reusable templates in CliDeck.com and applying them to new devices as needed.

Who this is for

This guide is for network engineers, operations teams, field technicians, and lab engineers who need to make and verify a controlled network configuration or recovery change on approved network devices inside a planned change or lab scope.

When to use this

Use this guide when:

  • The task is inside an approved change, recovery, lab, or troubleshooting scope.
  • You need a practical checklist before touching a production or customer device.
  • You need to verify the result and document what changed.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Workflow

  • Confirm device identity, access path, and approved scope.
  • Collect read-only baseline information before making changes.
  • Run only the commands or checks required for the task.
  • Verify the final state with commands, logs, or observable behavior.
  • Document the result, exceptions, and next action.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace can help keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace. Console Server Go is useful for portable rack-side console access, while Net Controller is better for repeatable multi-device processing and evidence-style results.

FAQ

Can CliDeck help with this workflow?

Yes, depending on the workflow. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful for portable rack-side console access. Net Controller is better for batch device processing, ITAD workflows, provisioning, recovery, barcode tracking, and evidence-style logs.

Should I follow this guide instead of vendor documentation?

No. Use this article as practical guidance alongside vendor documentation, site policy, and your approved change or recovery process.

What should I verify before closing the work?

Verify device identity, scope, final state, logs or notes, and any rollback or exception handling required by your organization.

Related guides