cisco-ios-patterns
affaan-m/everything-claude-code
Review Cisco IOS/IOS-XE configs safely with patterns for show commands, ACLs, wildcard masks, and change verification.
What is cisco-ios-patterns?
Patterns and checklists for reviewing Cisco IOS and IOS-XE configurations before deployment. Use this when validating ACL placement, wildcard masks, interface configuration, and building safe change-window verification steps to avoid locking out management access or breaking routing.
- Provides read-only show commands for collecting device state without risk
- Explains IOS configuration modes and hierarchy (global, interface, routing process, line)
- Validates ACL wildcard masks, direction (in/out), and placement before applying to interfaces
- Documents interface hygiene patterns with descriptions, switchport modes, and native VLANs
- Defines before/after verification checks for routing and ACL changes
- Lists anti-patterns to avoid (subnet mask vs wildcard mask confusion, saving before validation, disabling security to troubleshoot)
How to install cisco-ios-patterns
npx skills add https://github.com/affaan-m/everything-claude-code --skill cisco-ios-patternsHow to use cisco-ios-patterns
- 1.Capture current device state using the provided read-only show commands (show version, show running-config, show ip route, etc.)
- 2.Review the exact candidate configuration and identify the specific section being changed (interface, ACL, routing process)
- 3.Confirm management access paths (console, out-of-band, SSH) and verify the change cannot lock you out
- 4.Apply the smallest change in a maintenance window using configure terminal and mode-specific commands
- 5.Re-read the relevant show command output and compare to the baseline to validate behavior
- 6.Save the change to startup-config only after post-change checks pass, using copy running-config startup-config
Use cases
- Reviewing a candidate IOS configuration before a planned maintenance window change
- Choosing safe read-only show commands to troubleshoot without risking device state
- Validating an ACL wildcard mask and confirming it matches the intended traffic range
- Checking that management access (SSH, console) cannot be locked out by a new ACL
- Building a change-window checklist with before/after state captures and rollback paths
- Network engineers planning IOS/IOS-XE configuration changes
- DevOps or infrastructure teams managing Cisco routers and switches
- Operators troubleshooting network issues without making incidents worse
- Anyone reviewing generated or templated Cisco configs before deployment
cisco-ios-patterns FAQ
running-config is the active configuration in memory. startup-config is what persists after a reload. Do not save a change just because a command was accepted; validate behavior first, then intentionally save only after validation.
IOS ACLs and many routing statements use wildcard masks (inverse of subnet masks). For example, 255.255.255.0 subnet mask becomes 0.0.0.255 wildcard mask. Review the wildcard mask before deployment; using a subnet mask where a wildcard is expected can match far more traffic than intended.
Confirm the traffic direction (in or out), verify management traffic is explicitly permitted, ensure required routing/DNS/NTP/monitoring traffic is permitted, check that you have a rollback command and active console or out-of-band access, and use hit counters from a safe test source rather than removing protections to test.
Use read-only show commands to collect state (show logging, show ip route, show interfaces, show ip access-lists). Read counters, logs, and route state first. Do not troubleshoot by disabling ACLs, route policies, or authentication.
Capture current state with read-only commands, review the exact candidate config, confirm management access cannot be locked out, apply the smallest change in a maintenance window, re-read state and compare to baseline, then save only after validation passes.
Full instructions (SKILL.md)
Source of truth, from affaan-m/everything-claude-code.
name: cisco-ios-patterns description: Cisco IOS and IOS-XE review patterns for show commands, config hierarchy, wildcard masks, ACL placement, interface hygiene, and safe change-window verification. metadata: origin: community
Cisco IOS Patterns
Use this skill when reviewing Cisco IOS or IOS-XE snippets, building a change-window checklist, or explaining how to collect evidence from a router or switch without making the incident worse.
When to Use
- Reviewing IOS or IOS-XE configuration before a planned change.
- Choosing read-only
showcommands for troubleshooting. - Checking ACL wildcard masks and interface direction.
- Explaining global, interface, routing process, and line configuration modes.
- Verifying that a change landed in running config and was saved intentionally.
Operating Rules
Treat IOS examples as patterns, not paste-ready production changes. Confirm the platform, interface names, current config, rollback path, and out-of-band access before making changes on a real device.
Prefer this workflow:
- Capture current state with read-only commands.
- Review the exact candidate config.
- Confirm management access cannot be locked out.
- Apply the smallest change in a maintenance window.
- Re-read state, compare to the baseline, then save only after validation.
Mode Reference
Router> enable
Router# show running-config
Router# configure terminal
Router(config)# interface GigabitEthernet0/1
Router(config-if)# description UPLINK-TO-CORE
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# end
Router# show running-config interface GigabitEthernet0/1
running-config is active memory. startup-config is what survives reload.
Do not save a change just because a command was accepted; validate behavior
first, then use copy running-config startup-config if the change is approved.
Read-Only Collection
show version
show inventory
show processes cpu sorted
show memory statistics
show logging
show running-config | section line vty
show running-config | section interface
show running-config | section router bgp
show ip interface brief
show interfaces
show interfaces status
show vlan brief
show mac address-table
show spanning-tree
show ip route
show ip protocols
show ip access-lists
show route-map
show ip prefix-list
Collect the specific section you need instead of dumping full config into a ticket when the config may contain secrets, customer names, or private topology.
Wildcard Masks
IOS ACL and many routing statements use wildcard masks, not subnet masks.
Subnet mask Wildcard mask
255.255.255.255 0.0.0.0
255.255.255.252 0.0.0.3
255.255.255.0 0.0.0.255
255.255.0.0 0.0.255.255
Review wildcard masks before deployment. A subnet mask accidentally used as a wildcard can match far more traffic than intended.
ip access-list extended WEB-IN
10 permit tcp 192.0.2.0 0.0.0.255 any eq 443
999 deny ip any any log
Every ACL has an implicit deny at the end. Add an explicit logged deny when the operational goal includes observing misses, and confirm logging volume is safe.
ACL Placement Review
Before applying an ACL to an interface, answer these questions:
- Which traffic direction is being filtered,
inorout? - Is management traffic sourced from a known jump host or management subnet?
- Is there an explicit permit for required routing, DNS, NTP, monitoring, or application traffic?
- Are hit counters available from a safe test source?
- Is there a rollback command and an active console or out-of-band path?
Do not test reachability by removing firewall or ACL protections. Read counters, logs, and route state first.
Interface Hygiene
interface GigabitEthernet0/1
description UPLINK-TO-CORE
switchport mode trunk
switchport trunk allowed vlan 10,20,30
switchport trunk native vlan 999
no shutdown
Use clear descriptions, explicit switchport mode, and documented native VLANs. On routed interfaces, confirm the mask, peer addressing, and routing process before assuming link state means forwarding is correct.
Change-Window Verification
Use before/after checks that match the actual change.
show running-config | section interface GigabitEthernet0/1
show interfaces GigabitEthernet0/1
show logging | include GigabitEthernet0/1|changed state|line protocol
show ip route <prefix>
show ip access-lists <name>
For routing changes, also capture neighbor state and route tables before and after the change. For ACL changes, compare hit counters from a planned test source rather than relying on a generic ping.
Anti-Patterns
- Applying a generated config without a device-specific diff.
- Saving configuration before post-change checks pass.
- Using a subnet mask where IOS expects a wildcard mask.
- Applying an ACL to the wrong interface direction.
- Troubleshooting by disabling ACLs, route policies, or authentication.
- Pasting full configs into public tools without sanitizing secrets and topology.
See Also
- Agent:
network-config-reviewer - Agent:
network-troubleshooter - Skill:
network-config-validation - Skill:
network-interface-health
Related skills
More from affaan-m/everything-claude-code and the wider catalog.

ck
Persistent per-project memory for Claude Code with auto-loaded context and deterministic session tracking.

claude-api
Anthropic Claude API patterns for Python and TypeScript with streaming, tool use, vision, and batches.

claude-devfleet
Orchestrate parallel coding tasks across multiple Claude agents with dependency chains and isolated worktrees.

click-path-audit
Trace button handlers through state changes to find bugs where functions undo each other or leave UI inconsistent.

clickhouse-io
ClickHouse patterns for high-performance analytics, query optimization, and data engineering at scale.

code-tour
Create guided CodeTour `.tour` files with real file anchors for onboarding, architecture, and PR walkthroughs.