为什么要排时间线
一次广域网故障通常伴随一串连锁事件：链路 down 触发路由撤销，路由撤销触发备份路径切换，切换又造成短暂丢包与重传。如果只盯着最后看到的那条告警，很容易把结果当成原因。时间线方法要求把两端设备、中间设备以及业务侧探测的记录，按统一时区合并排序，找出最早出现的异常事件作为触发源，再看后续事件的时间差是否符合预期传导路径。这比逐台设备翻配置快得多，也是向运营商报障时最有说服力的材料。
基本信息
| 取证范围 | 两端设备、中间设备、业务侧探针与运营商通告 |
|---|---|
| 时间基准 | 所有设备先经 NTP 对齐，统一到同一时区 |
| 关键事件 | 接口 up/down、路由变化、邻居状态、认证与加密事件 |
| 输出形式 | 按时间排序的事件表，标注触发源与因果链 |
| 常用命令 | show logging、display logbuffer、journalctl |
典型使用场景
- 故障复盘：确认首次异常发生在哪台设备、什么时间
- 运营商报障：用带时间戳的双向证据推动工单
- 变更验证：把变更时刻与后续事件做前后对照
- 间歇性故障：靠多次时间线比对同一模式是否重复出现
- 责任界定：区分是本端配置、运营商线路还是业务侧问题
取证命令骨架
取证命令骨架
# Cisco：导出关键类别日志
show logging | include UPDOWN|BGP|CRYPTO|LINEPROTO
show clock # 记录时间基准与该设备时区
# 华为
display logbuffer | include brief
display clock
# Linux 侧（如隧道终结或业务主机）
journalctl --since '-2h' | grep -E 'established|deleted|timeout'事件与线索对照
| 时间线现象 | 常见含义 | 下一步 |
|---|---|---|
| 接口 down 出现在所有事件之前 | 物理层或运营商侧中断 | 查光功率、CRC 计数与运营商通告 |
| 接口正常但 BGP 邻居先掉 | 链路在、转发中断或 Hold Timer 超时 | 结合 BFD 状态与丢包窗口判断 |
| 加密相关事件与业务告警同时出现 | 隧道重协商造成短暂中断 | 查 rekey/reauth 周期与两端参数 |
| 多台设备日志时间乱序 | 时间未对齐，当前时间线不可信 | 先排查 NTP 同步再重新分析 |
合并时间线时把原始日志留档，不要只保留加工后的表格；后续若发现时区或基准有偏差，还能回到原始记录重新对齐。
设备本地缓冲区容量有限，重启或长时间未转存会丢历史日志；关键链路应配置日志服务器转存，否则事后只能拿到断裂的片段。