2. Juniper路由故障诊断工具链精讲
在 Junos 平台上排查路由故障，真正决定效率的不是“知道有哪些命令”，而是“在什么现象下用哪条命令、看输出里的哪几个字段、据此得出什么结论”。本节把八类常用工具按信息深度和观测方向两个维度组织起来：show route 系列回答“路由表里有什么、这条路由从哪来、为什么被选中”，monitor traffic 与 traceoptions 回答“控制平面实际收到了什么、协议交互发生了什么”，ping、traceroute、mtr 回答“转发平面是否真的通、在哪一跳断”。
一、show route 三兄弟：从概览到逐字段解剖
show route 是最常用的入口，输出的是路由表的“摘要视图”。每一行给出前缀、协议来源（如 O OSPF、B BGP、D Direct、L Local）、下一跳和出接口。它的价值在于快速定位“这条前缀是否存在、由哪个协议产生、有几个候选”。例如：
user@R1> show route 10.10.10.0/24
inet.0: 18 destinations, 21 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[OSPF/10] 00:12:35, metric 20
> to 10.0.0.2 via ge-0/0/1.0输出中 * 表示该路由已装入转发表，[OSPF/10] 是协议与管理距离，metric 20 是度量值，> 表示这是被选中的下一跳。若同一前缀出现多行而无 *，说明存在候选但未激活，常见原因是管理距离更优的路由已存在，或下一跳不可达。
show route detail 在摘要基础上展开每条路由的属性：协议优先级、度量、下一跳、出接口、标签、Age、以及 BGP 的 AS Path、Local Preference、MED、Origin 等。排查 BGP 选路问题时，这一层是必看的——它直接告诉你“为什么这条没被选中”。
show route extensive 则进一步给出协议内部状态：BGP 的 peer 状态、Received/Advertised 计数、路由的 Local AS、Peer AS、Cluster List、Originator ID，以及 OSPF 的 area、LSA 类型、SPF 计算信息。它适合回答“这条路由在协议层面是否合法、是否被策略修改过”。
二、monitor traffic 与 traceoptions：控制平面的“听诊器”
monitor traffic 抓取的是接口上实际收发的报文，适合验证“对端是否真的把包发过来了”。常用形式：
user@R1> monitor traffic interface ge-0/0/1.0 matching "host 10.0.0.2 and ospf"
关键参数：interface 指定抓包点，matching 使用 BPF 语法过滤，no-resolve 避免 DNS 反查拖慢输出，write-file 可落盘供后续分析。若 OSPF 邻居起不来，先在这里确认 Hello 包是否双向可见——只看到自己发出的、看不到对端回的，问题多半在对端或链路。
traceoptions 是 Junos 的协议级日志，比抓包更“懂协议”。它记录的是协议状态机事件，例如 BGP 的 OPEN/KEEPALIVE/UPDATE 收发、OSPF 的邻居状态迁移、LSA 泛洪。配置示例：
user@R1# set protocols bgp traceoptions file bgp.log size 10m files 5
user@R1# set protocols bgp traceoptions flag update detail
user@R1# set protocols bgp traceoptions flag keepalive
user@R1# commit
user@R1> show log bgp.log | last 50解读要点：flag 决定记录哪些事件，detail 会展开报文内容；日志文件有 size 和 files 滚动限制，排查完务必 deactivate 或删除，否则长期运行会占用磁盘并影响性能。traceoptions 与 monitor traffic 的分工是：前者看“协议怎么想”，后者看“线上跑了什么”。
三、ping、traceroute、mtr：转发平面的连通性验证
ping 验证端到端可达性，Junos 下常用：
user@R1> ping 10.10.10.1 count 5 source 10.0.0.1 rapid
user@R1> ping 10.10.10.1 routing-instance VPN-A
source 指定源地址，用于验证“从特定源出发是否可达”，这在多宿主或策略路由场景中非常关键；routing-instance 用于 VPN 实例内测试。若 ping 不通但路由表有该前缀，优先怀疑：回程路由缺失、ACL/防火墙过滤、下一跳 ARP 未解析。
traceroute 逐跳显示路径，用于定位“在哪一跳开始丢包”。Junos 支持 no-resolve 加速、source 指定源、gateway 指定下一跳。注意：中间跳不响应 ICMP 并不代表故障，只要后续跳能通即可。
mtr 是 ping 与 traceroute 的结合体，持续对每一跳发包并统计丢包率与延迟。它最适合判断“是某一跳持续丢包，还是全网随机丢包”。在 Junos 上通常以 mtr 命令或 monitor 形式调用，输出中 Loss% 列是关键：若中间跳丢包但末端不丢，通常是该跳 ICMP 限速，不是真故障。
四、组合使用：一条典型排障路径
假设现象是“R1 到 10.10.10.1 不通”。合理的顺序是：
- 先
show route 10.10.10.1确认前缀是否存在、是否激活。若不存在，问题在控制平面，转去查协议。 - 若存在但下一跳异常，用
show route detail 10.10.10.1看下一跳、出接口、标签是否正确。 - 若路由正常但 ping 不通，用
ping 10.10.10.1 source <本端接口地址>排除源地址问题，再用traceroute定位断点。 - 若怀疑协议未收敛，用
monitor traffic确认 Hello/UPDATE 是否双向，再用traceoptions看状态机卡在哪一步。 - 若丢包呈间歇性，用
mtr持续观测，区分“某跳持续丢”与“末端随机丢”。
五、工具选择速查表
| 现象 | 首选工具 | 关键观察点 |
|---|---|---|
| 前缀是否存在 | show route | 协议来源、* 激活标记、下一跳 |
| 为什么没选这条 | show route detail | 优先级、度量、AS Path、Local Pref |
| 协议内部状态 | show route extensive | Peer 状态、LSA、SPF、策略痕迹 |
| 报文是否到达 | monitor traffic | 双向可见性、BPF 过滤结果 |
| 协议状态机卡住 | traceoptions | flag 事件、状态迁移、错误码 |
| 端到端是否通 | ping | source、routing-instance、丢包率 |
| 断在哪一跳 | traceroute | 逐跳响应、超时位置 |
| 间歇性丢包 | mtr | Loss% 列、中间跳与末端对比 |
掌握这套工具链的关键，不是记住命令拼写，而是建立“先看结果、再看过程、最后验证转发”的层次化思维。show route 系列负责缩小范围，monitor traffic 与 traceoptions 负责解释协议行为，ping/traceroute/mtr 负责确认数据平面真实状态。三者配合，才能在复杂路由故障中快速定位根因，而不是在大量输出中盲目翻找。