BGP “代理” 宣告

问题：BGP 宣告的时候，可以宣告 node 自己看不见的 ip 作为路由的下一跳么？ 你可以理解为帮别的 node 宣告

从 BGP 协议角度：技术上完全可以宣告自己看不见的 IP 作为 next hop。BGP UPDATE 消息不强制验证 next hop 的本地可达性。

但实际会遇到问题：

1. 下游路由器的 next-hop 校验：

   • 大多数 BGP 实现会检查 next hop 是否可达
   • 如果路由表中找不到到 next hop 的路由，会标记该路由为 invalid 或 inactive
   • 即使接受了路由，流量也无法转发（黑洞）

2. eBGP 的 next-hop-self 要求：

   • eBGP 规范建议 next hop 应该是 peer 之间共享网段的地址
   • 否则需要手动配置静态路由指向 next hop

3. 实际使用场景（"代理宣告"）：

   • Route Reflector：RR 转发路由时保持原始 next hop（不是自己）
   • 第三方 next hop：BGP peer 在同一广播域，可以直接到达第三方 next hop
   • 特殊拓扑：如 MPLS VPN、BGP confederation

Kube-OVN 的实现

在 Kube-OVN speaker 中，不支持"代理宣告" 。查看 bgp.go:202：

**
从 BGP 协议角度**：技术上完全可以宣告自己看不见的 IP 作为 next hop。BGP UPDATE 消息不强制验证 next hop 的本地可达性。

但实际会遇到问题：

1. 下游路由器的 next-hop 校验：

   • 大多数 BGP 实现会检查 next hop 是否可达
   • 如果路由表中找不到到 next hop 的路由，会标记该路由为 invalid 或 inactive
   • 即使接受了路由，流量也无法转发（黑洞）

2. eBGP 的 next-hop-self 要求：

   • eBGP 规范建议 next hop 应该是 peer 之间共享网段的地址
   • 否则需要手动配置静态路由指向 next hop

3. 实际使用场景（"代理宣告"）：

   • Route Reflector：RR 转发路由时保持原始 next hop（不是自己）
   • 第三方 next hop：BGP peer 在同一广播域，可以直接到达第三方 next hop
   • 特殊拓扑：如 MPLS VPN、BGP confederation

Kube-OVN 的实现

在 Kube-OVN speaker 中，不支持"代理宣告" 。查看 bgp.go:202：

关键点：

• netlink.RouteGet(neighborAddress) 确保 next hop 是本地到 neighbor 路由的源 IP
• 这保证了 BGP peer 能够通过已建立的 BGP 会话路径反向到达 next hop
• 不会宣告第三方 IP 作为 next hop

比如这个 ip 应该是 nat gw 的 net1 的主 ip（一个内网网段）

GoBGP 会发送这个 UPDATE，但：

1. 对端路由器可能拒绝（next hop 不可达）
2. 即使接受，流量也会黑洞（无法转发到 next hop）

结论：技术上可行，但 Kube-OVN 设计上不支持，且实际场景中很少需要（除非构建 RR 或特殊拓扑）。