Configuration Management

Ongoing configuration assurance skill covering backup, drift detection, and
golden config validation. This skill identifies unauthorized or unintended
changes by comparing device configurations against known-good baselines and
organizational compliance rules.

Commands are labeled [Cisco], [JunOS], or [EOS] where syntax
diverges. Unlabeled statements apply to all three vendors.

Safety Note — Read-Write Operations: This skill includes procedures that
may modify device state (config archival to remote storage, rollback, config
replace). Steps that write to devices are marked with ⚠️ WRITE. Always
confirm authorization and maintenance window status before executing write
operations. Read-only assessment steps can be run at any time without risk.

When to Use

• - Scheduled configuration compliance audit against golden baselines
• Investigating suspected unauthorized configuration changes
• Post-maintenance verification that running config was saved to startup
• Validating configuration consistency across device groups or stacks
• Checking that security-mandated patterns (AAA, NTP, logging) are present
• Ensuring forbidden patterns (default credentials, telnet, SNMPv1) are absent
• Building or refreshing a configuration archive before a change window
• Periodic drift detection as part of operational hygiene (daily/weekly)

Prerequisites

• - SSH or console access to the device (read-only sufficient for assessment;

enable/configure privilege required for remediation or archival steps)

• - A golden config baseline or previous archived config for comparison
• Knowledge of organizational compliance requirements: required services (AAA,

NTP, syslog), forbidden protocols (telnet, HTTP management, SNMPv1/v2c without ACL), and mandatory security features (ACLs, CoPP)

• - For archival: reachable SCP/TFTP/FTP server or local flash storage
• Awareness of any active maintenance window that may explain expected drift

Procedure

Follow these steps sequentially. Steps 1–2 are always safe (read-only).
Steps 3–7 include optional write operations marked with ⚠️.

Step 1: Config Collection

Capture the current running and startup/saved configurations.

[Cisco]
CODEBLOCK0

[JunOS]
CODEBLOCK1

[EOS]
CODEBLOCK2

On JunOS, the candidate configuration model means the active config is the
committed config. Use show configuration to view committed state. See
references/cli-reference.md for architectural differences.

Step 2: Running vs Startup Comparison

Detect unsaved changes — running config that would be lost on reload.

[Cisco]
CODEBLOCK3

[JunOS]
CODEBLOCK4

[EOS]
CODEBLOCK5

Any differences indicate unsaved changes. Record the diff output and timestamp.
Classify the age of unsaved changes — see Threshold Tables for severity. If
changes are intentional (active maintenance), note the maintenance ticket.

Step 3: Config Archival

⚠️ WRITE — Back up the current configuration with timestamped naming.

[Cisco]
CODEBLOCK6

[JunOS]
CODEBLOCK7

[EOS]
CODEBLOCK8

Use consistent naming: {hostname}-{YYYYMMDD}-{HHMM}.cfg. Verify the backup
was written successfully by checking file size and comparing a hash of the
backup against the running config. Maintain a minimum of 3 archived configs per
device for rollback options.

Step 4: Golden Config Baseline

Retrieve the golden (intended-state) configuration for this device role. Golden
configs are maintained per device role (e.g., access-switch, core-router,
WAN-edge) and contain all mandatory configuration sections.

If no golden config exists yet, establish one:

1. 1. Start from a known-compliant device config
2. Remove device-specific values (hostnames, IPs, interface descriptions)
3. Keep all compliance-mandated sections (AAA, NTP, logging, SNMP, ACLs)
4. Document the golden config version and approval date

For comparison, normalize both configs before diffing — see
references/drift-detection.md for normalization rules.

Step 5: Drift Detection

Compare current config against the golden baseline section by section.

Partition the configuration into logical sections for structured comparison:

Section	Cisco Examples	JunOS Examples	EOS Examples
Routing	INLINECODE4, INLINECODE5	INLINECODE6	INLINECODE7, INLINECODE8
Switching

spanning-tree, vlan | vlans, protocols rstp | spanning-tree, vlan |
| Security | access-list, line vty | firewall, system login | ip access-list, management |
| Management | logging, ntp, snmp | system syslog, system ntp | logging, ntp, snmp-server |
| Services | ip dhcp, ip nat | forwarding-options | ip dhcp, ip nat |

For each section, identify additions, deletions, and modifications compared
to the baseline. Classify each difference by severity — see Threshold Tables.

Step 6: Compliance Validation

Check for required and forbidden configuration patterns.

Required patterns (must be present):

• - AAA authentication configured and active
• NTP synchronization to authorized time sources
• Syslog forwarding to centralized logging servers
• SNMP with ACL restrictions (no unrestricted community strings)
• Management access restricted to SSH only (no telnet, no HTTP)

Forbidden patterns (must be absent):

• - Default credentials (e.g., username admin password admin)
• Telnet or HTTP enabled for management (transport input telnet, no ip http secure-server)
• SNMPv1/v2c without source ACL restriction
• Unrestricted VTY access (no ACL applied to VTY lines)
• DHCP snooping or ARP inspection disabled on access ports

Reference references/drift-detection.md for full compliance rule definitions
with vendor-specific pattern matching.

Step 7: Remediation Guidance

⚠️ WRITE — Address drift findings based on severity classification.

For Critical drift (routing, security sections):

1. 1. Verify if the change was authorized (check change tickets)
2. If unauthorized, prepare a rollback to the last known-good config
3. [Cisco] INLINECODE38
4. [JunOS] rollback [n] then INLINECODE40
5. [EOS] INLINECODE41

For Warning drift (management plane, logging):

1. 1. Document the deviation in the drift report
2. Schedule remediation during the next maintenance window
3. Apply missing configuration elements incrementally

For Info drift (cosmetic — descriptions, banners, comments):

1. 1. Log the deviation for tracking
2. Remediate opportunistically during scheduled maintenance

After any remediation, re-run Steps 1–2 to confirm the config matches the
intended state and save the corrected running config to startup.

Threshold Tables

Drift Severity by Config Section

Config Section	Severity	Rationale
Routing (BGP, OSPF, static)	Critical	Direct traffic impact, potential outage
Security (ACLs, AAA, CoPP)

Critical | Exposure to unauthorized access | | Switching (STP, VLANs) | High | Loop risk, VLAN leakage | | Management (logging, NTP, SNMP) | Warning | Operational visibility loss | | Services (DHCP, NAT) | Warning | Service-level impact, no network-wide risk | | Cosmetic (descriptions, banners) | Info | No operational impact |

Unsaved Change Age

Age	Severity	Action
< 1 hour	Info	Likely active maintenance — verify with operator
1–4 hours

Warning | Check if maintenance window is active | | 4–24 hours | High | Likely forgotten save — prompt operator to save or revert | | > 24 hours | Critical | Unsaved changes at high risk of loss — immediate save or revert |

Config Archive Freshness

Last Archive	Status	Action
< 7 days	Current	No action needed
7–30 days

Stale | Schedule archive refresh | | 30–90 days | Warning | Archive before any changes | | > 90 days | Critical | Immediate archive required |

Decision Trees

Drift Detected

CODEBLOCK9

Running ≠ Startup

CODEBLOCK10

Compliance Violation

CODEBLOCK11

Report Template

CODEBLOCK12

Troubleshooting

Config Diff Shows False Positives

Diffs include generated lines (timestamps, certificate hashes, build
information) that change between captures but are not real drift. Normalize
configs before comparison by stripping timestamps, build strings, and
auto-generated comments. See references/drift-detection.md for normalization
patterns per vendor.

JunOS Candidate Config Confusion

JunOS uses a candidate-commit model. show configuration displays committed
(active) config. Uncommitted candidate changes appear only with show | compare. If drift analysis shows differences between a JunOS device and its
golden config, verify that no uncommitted candidate changes are pending —
uncommitted changes do not affect the running device but will take effect on
next commit.

Archive Transfer Failures

Config export to remote servers may fail due to: ACL on the device blocking
outbound SCP/TFTP, DNS resolution failure for server hostname, authentication
failure on SCP, or insufficient flash space for local copy. Test connectivity
with ping first, verify SCP credentials, and check available flash space with
dir flash: (Cisco/EOS) or file list /var/tmp/ (JunOS).

Large Config Diff Overwhelms Analysis

Configs exceeding 10,000 lines produce diffs that are difficult to analyze
holistically. Break the comparison into the section categories from Step 5 and
analyze one section at a time. Prioritize sections by severity tier from the
Threshold Tables. For structured configs (JunOS set-format, EOS section mode),
sort lines before diffing to reduce positional noise.

Compliance Rule Vendor Variations

The same security requirement maps to different config syntax per vendor. For
example, disabling telnet: Cisco uses transport input ssh on VTY lines, JunOS
uses delete system services telnet, and EOS uses no management telnet.
Reference references/drift-detection.md for vendor-specific compliance
patterns to avoid false positives or missed violations.