GTSM 用 TTL 做来源校验
GTSM（通用 TTL 安全机制，RFC 5082）利用这样一个事实：直连或固定跳数的对端发出的报文，TTL 到达本端时必定落在可预期的范围内。接收侧要求 BGP 报文的 TTL 不低于「255 减配置跳数加 1」，从而丢弃来自远处伪造的 179 报文，是一种成本很低的建邻加固手段。
基本信息
| 原理 | 接收侧校验到达报文的 TTL 是否在预期范围内 |
|---|---|
| 配置方式 | 邻居下设置 ttl-security hops <跳数> |
| 适用场景 | 直连 eBGP、多跳但路径固定的对等 |
| 与 multihop 关系 | GTSM 在部分场景下替代多跳配置，两者目的不同需协调 |
| 生效要求 | 两端都要按实际跳数配置，跳数不一致会导致报文被丢弃 |
典型使用场景
- 公网直连对等：防御来自远端伪造源地址的 179 报文
- 数据中心出口：与上游对等时作为基础安全配置项
- 多跳固定路径：跳数稳定时同样可以应用，需先确认实际跳数
- 安全加固清单：把 GTSM 与来源地址过滤、前缀过滤一起纳入基线
- 事故复盘：出现伪造路由注入嫌疑时，评估是否需要补充 TTL 校验
配置与验证
配置与验证
# 直连对等：跳数为 1
router bgp 65001
neighbor 10.0.0.2 ttl-security hops 1
!
show ip bgp neighbors 10.0.0.2 | include TTL
# 关注 external TTL security 与实际生效的跳数
!
# 华为侧类似能力以命令帮助为准
# display bgp peer 10.0.0.2 verbose跳数与校验范围
| 场景 | 配置跳数 | 到达 TTL 预期 |
|---|---|---|
| 直连 eBGP | 1 | 255 附近，路径上无中间设备 |
| 两跳对等 | 2 | 约 254 左右，需与实际路径一致 |
| 多跳环回建邻 | 按实际跳数 | 跳数变化会导致校验失败 |
| iBGP 直连 | 1 | 通常也可启用，视平台支持而定 |
启用失败时的核对
启用失败时的核对
# 1) 确认路径实际跳数是否与配置一致
traceroute 10.0.0.2
# 2) 确认两端是否都启用了相同设置
show running-config | include ttl-security
# 3) 抓包查看 TTL 值
tcpdump -i eth0 -nn -v 'tcp port 179'
# 关注 IP 头中的 ttl 字段是否落在期望区间GTSM 只提高伪造报文的成本，并不能替代其它防护：来源地址过滤、前缀过滤与最大前缀限制仍是必需项。直连对等建议默认启用，路径跳数发生变化时需同步调整配置。