cisco-ios-router-troubleshooting

Extract the tarball into scratch space, inventory logs, configs, and show outputs, then run broad keyword searches for tracebacks, LINK/LINEPROTO events, and routing protocol messages. Correlate findings across logs, state, and config before forming hypotheses.

Check the neighbor down reason first: dead timer expired points to lost Hellos from link loss, congestion, filtering, or CPU starvation, while interface down points to local state. Verify timers, network type, MTU, authentication, and correlate with interface counters and config changes.

Cisco pyATS/Genie parsers handle structured parsing of supported show commands, while TextFSM with ntc-templates covers outputs Genie misses. For configuration queries, ciscoconfparse works well, and raw text remains the source of truth if a parser fails.

No, %SYS-5-CONFIG_I is a configuration change marker, not a failure. Treat it as a timeline anchor and correlate it with nearby adjacency or interface events and archive config diffs to test a change-induced outage hypothesis.

IOS debug output often dominates bundles with repetitive per-packet lines. Collapse repeated flows by source, destination, interface, and time range, then prioritize unusual outcomes like unroutable, encapsulation failed, ACL denies, or missing reverse traffic.

A traceback indicates a possible software defect only when corroborated by IOS version, reload reason, matching crashinfo, recurrence, and timing aligned with the symptoms. An isolated traceback outside the symptom window should not be called the root cause.