隧道上跑 BGP
把 BGP 会话建在隧道之上（GRE、IPsec、DMVPN、VXLAN 等 Overlay）是跨互联网互联与专线备份的常规做法：隧道负责地址与承载，BGP 负责动态路由与切换。相比直连物理链路，隧道多了一层封装，于是接口 MTU、隧道稳定性与隧道内地址规划这三项直接决定会话质量，其中由 MTU 引发的故障最常见。
基本信息
| 承载类型 | GRE / IPsec / DMVPN / VXLAN 等 Overlay |
|---|---|
| 邻居地址 | 隧道接口地址，或隧道内可达的环回地址 |
| 关键参数 | 接口 MTU、TCP MSS、Keepalive 与 Hold 时间 |
| 封装开销 | GRE 为 24 字节起（外层 IPv4 20 + GRE 4），IPsec 按算法与模式另加 50~70 字节 |
| 适用平台 | Cisco IOS/IOS-XE、华为 VRP、Linux（ip tunnel + FRR/BIRD） |
典型使用场景
- 企业总部与分支的备份路径：主用专线中断时由隧道顶替，BGP 决定切不切
- 无专线可用时的跨运营商对等：在互联网上建立隧道后跑 IBGP 或 EBGP
- DMVPN 多分支组网：分支与总部动态建隧道，用 BGP 交换各站点网段
- 云上 VPC 与本地机房互联：IPsec 隧道上跑 BGP，实现网段自动宣告与冗余
- 迁移过渡期：先用隧道打通路由与策略，再整段切换到新专线
建邻前先验 MTU
建邻前先验 MTU
# 隧道两端接口地址互 ping，逐步加大包长找真实 MTU
ping 10.255.0.2 size 1400 repeat 5 # 小包正常说明隧道本身可用
ping 10.255.0.2 size 1472 df-bit repeat 5 # DF 置位，超过真实 MTU 会失败
# 不确定时抓包看是否收到 ICMP 需要分片
tcpdump -ni Tunnel0 -c 20 icmp # Linux 视角，观察 need-to-fragment隧道接口输出逐列读法
| 字段 | 含义 | 正常与异常 |
|---|---|---|
| MTU | 隧道接口有效 MTU | 与封装开销推算值一致；明显低于 1400 需确认是否叠加了多重封装 |
| Tunnel source / destination | 隧道起止地址 | 与规划一致；任一端变更未同步则隧道起不来 |
| Tunnel protocol/transport | 封装协议与承载 | GRE/IP、IPsec 等与设计一致，换协议需两端同时改 |
| Input errors / CRC | 底层接口错误计数 | 持续增长说明物理链路或光模块有问题，与会话抖动同源 |
隧道稳定性会直接传导为 BGP 抖动：隧道断一次，会话就重建一次。用 BFD 或接口状态联动能更快发现故障，但探测间隔过短会把瞬时丢包升级为会话中断，需按承载质量取值。
MTU 与 MSS 配套设置
MTU 与 MSS 配套设置
interface Tunnel0
ip mtu 1400 # 兼顾叠加封装后的有效 MTU
ip tcp adjust-mss 1360 # 让 TCP 协商不超过隧道 MTU
keepalive 10 3 # 部分平台支持，探测隧道端点是否仍可达隧道上建 EBGP 时两端通常同网段直连，若改用 ebgp-multihop 建立多跳会话，要同时考虑 TTL 与 GTSM 的配合：隧道外侧丢包时，现象常常是会话先掉，而不是路由属性变化。