NASP/rpki

Fork 0

xiuting.xu 8d6173f605 rtr的输入换成ccr文件

2026-03-30 10:03:43 +08:00

5.7 KiB

Raw Blame History

rtr_debug_client

rtr_debug_client 是一个轻量级的 RTR 调试客户端，用于手工联调和协议行为观察。

它适合以下场景：

在开发阶段验证 RTR server 的行为
发送 Reset Query 和 Serial Query
观察服务端返回的各类 PDU
检查会话状态、session_id、serial 的变化
排查 ErrorReport、CacheReset、SerialNotify、RouterKey、ASPA
联调纯 TCP 和 TLS 两种 RTR 传输方式

它不是生产级 router client，而是一个便于调试和观察协议细节的小工具。

当前支持的能力

当前版本支持：

纯 TCP 连接
TLS 连接
TLS 服务端证书校验
可选的 TLS 客户端证书认证
发送 Reset Query
发送 Serial Query
保持长连接持续接收服务端 PDU
格式化展示以下 PDU：
- Serial Notify
- Serial Query
- Reset Query
- Cache Response
- IPv4 Prefix
- IPv6 Prefix
- Router Key
- ASPA
- End of Data
- Cache Reset
- Error Report
结构化展示 ErrorReport：
- 错误码及语义名称
- encapsulated PDU 的 header 摘要
- encapsulated PDU 原始 hex
- arbitrary text 是否为 UTF-8
- arbitrary text 内容
根据 EndOfData 的 timing hint 自动轮询
收到 ErrorReport 后默认暂停自动轮询
通过 --keep-after-error 保持错误后的自动轮询

构建

cargo build --bin rtr_debug_client

基本用法

基本形式：

cargo run --bin rtr_debug_client -- <addr> <version> [reset|serial <session_id> <serial>] [options]

默认值：

addr: 127.0.0.1:323
version: 1
mode: reset
timeout: 30
poll: 600

TCP 示例

发送 Reset Query：

cargo run --bin rtr_debug_client -- 127.0.0.1:323 1 reset

发送 Serial Query：

cargo run --bin rtr_debug_client -- 127.0.0.1:323 1 serial 42 100

持续观察错误路径：

cargo run --bin rtr_debug_client -- 127.0.0.1:323 1 reset --keep-after-error

TLS 示例

只做服务端证书校验：

cargo run --bin rtr_debug_client -- \
  127.0.0.1:324 1 reset \
  --tls \
  --ca-cert tests/fixtures/tls/client-ca.crt \
  --server-name localhost

双向 TLS 认证：

cargo run --bin rtr_debug_client -- \
  127.0.0.1:324 1 reset \
  --tls \
  --ca-cert tests/fixtures/tls/client-ca.crt \
  --server-name localhost \
  --client-cert tests/fixtures/tls/client-good.crt \
  --client-key tests/fixtures/tls/client-good.key

双向 TLS + 错误后继续自动轮询：

cargo run --bin rtr_debug_client -- \
  127.0.0.1:324 1 reset \
  --tls \
  --ca-cert tests/fixtures/tls/client-ca.crt \
  --server-name localhost \
  --client-cert tests/fixtures/tls/client-good.crt \
  --client-key tests/fixtures/tls/client-good.key \
  --keep-after-error

说明：

开启 --tls 时必须提供 --ca-cert
如果目标地址本身不适合直接作为 TLS 名称，显式提供 --server-name
客户端认证必须同时提供 --client-cert 和 --client-key

命令行参数

--tls 使用 TLS 而不是纯 TCP。
--ca-cert <path> 用于校验服务端证书的 CA 证书文件，PEM 格式。
--server-name <name> TLS 握手时用于校验证书的服务端名称。
--client-cert <path> 双向 TLS 时使用的客户端证书，PEM 格式。
--client-key <path> 与 --client-cert 配套的客户端私钥，PEM 格式。
--timeout <secs> 等待下一个 PDU 的读取超时时间，单位秒。
--poll <secs> 在尚未拿到 EndOfData timing hint 前，默认使用的自动轮询间隔。默认值为 600 秒，对齐 draft 第 6 节的默认 Retry Interval。
--keep-after-error 收到 ErrorReport 后不暂停自动轮询。

运行中可用命令

程序启动后，可以在控制台输入以下命令：

help 显示帮助。
state 打印当前客户端状态。
reset 发送 Reset Query。
serial 使用当前 session_id 和 serial 发送 Serial Query。
serial <sid> <serial> 使用显式参数发送 Serial Query。
timeout 查看当前读取超时设置。
timeout <secs> 修改读取超时。
poll 查看当前自动轮询间隔、轮询来源以及暂停状态。
poll <secs> 手工覆盖当前轮询间隔。
poll pause 暂停自动轮询。
poll resume 恢复自动轮询。
keep-after-error 查看当前是否启用了错误后持续轮询。
quit 退出客户端。

自动轮询行为

客户端会保持连接，并周期性地向服务端发起下一次查询。

选择下一次轮询间隔的优先级如下：

retry，当最近一次 ErrorReport 是 No Data Available 或 Transport Failure
refresh，如果已经从 EndOfData 中拿到
启动参数里的默认轮询间隔

收到 ErrorReport 后的默认行为：

默认暂停自动轮询
连接保持不关，方便继续观察
你可以手工输入 reset、serial 或 poll resume 继续

如果带了 --keep-after-error：

收到 ErrorReport 后不会暂停
会继续按当前有效轮询间隔自动轮询

特殊情况：

当最近一次错误是 No Data Available 或 Transport Failure 时，恢复自动轮询后会优先参考 retry，而不是继续只看 refresh

ErrorReport 展示内容

ErrorReport 会展示以下内容：

错误码及其语义名称
encapsulated PDU 长度
encapsulated PDU 的 header 摘要
- PDU 类型
- version
- length
- field1（按类型解释为 session_id 或 error_code）
encapsulated PDU 原始 hex
arbitrary text 长度
arbitrary text 是否是 UTF-8
arbitrary text 内容

这样在排查协议问题时，不需要先手工拆原始 hex，就能快速知道是哪一个请求触发了错误。

5.7 KiB Raw Blame History Unescape Escape