BGP Wedgies

Author [email protected]

Date Aug. 25, 2023

Description BGP Wedgies

RFC 4262，这是在BGPv4出来之前的，不知道现在还是否存在，以及如何解决的，是否还是需要主动断开连接来解决。【看了BGP Wedgies, and how to avoid them，目前应该还是需要手动恢复】

BGP wedgies主要是指在链路状态变化并恢复后，导致的实际链路和本地策略不一致的情形。

简单案例

+----+peer                peer+----+
|AS 3|------------------------|AS 4|
+----+                        +----+
 |provider             provider|
 |                             |
 |                             |
 |customer                     |
+----+                          |
|AS 2|                          |
+----+                          |
 |provider                     |
 |                             |
 |                             |
 |customer             customer|
 +---------------+  +----------+
   backup service|  |primary service
                +----+
                |AS 1|
                +----+

后面路由路径使用->，转发路径使用=>

1. 【正常】1->2是backup链路，1->4是primary链路，正常情况下，是1要先向4宣告路由并标记为primary，4->3->2，然后链路建立。后1向2宣告路由并标记为backup only（depref-me community，但是尴尬的是没找到这个更多地信息，也不是well-known类型的community属性）。这样2也不会选择转发路径2=>1，而是2=>3=>4=>1。
2. 【正常】如果1->4之间的路径断了，那么1->2作为备份路径就会发挥作用，构成1->2->3->4，转发路径则是4=>3=>2=>1。
3. 【异常】如果1->4之间恢复了，那么4再把1的前缀宣告给3，而3根据peer-peer、customer-provider之间的关系，会优先选择2->3的路由，这时无法恢复到最初始的状态了。此时只能是AS1主动断开和AS2之间的连接。如果这时1-2之间还有通信也会一并不可达了。

load balance案例

    +----+peer                  peer+----+
    |AS 3|--------------------------|AS 4|
    +----+                          +----+
      |provider               provider|
      |                               |
      |                       customer|
      |customer                       |
    +----+                          +----+
    |AS 2|                          |AS 5|
    +----+                          +----+
      |provider               provider|
      |                               |
      |                               |
      |customer               customer|
      +-----------------+  +----------+
                        |  |
 backup (192.0.2.0/25)  |  |primary service (192.0.2.0/25)
primary (192.0.2.128/25)|  |backup service (192.0.2.128/25)
                       +----+
                       |AS 1|
                       +----+

BGP Wedgie：对于192.0.2.0/25的流量都走AS5，对于192.0.2.128/25的流量都走AS2。如果AS3和AS4之间的链路断了或者重置了，那么AS3会从AS2学习两条路由，AS4会从AS5学习两条路由。这样即便AS3和AS4之间的路由恢复了，那么也没用，不会恢复到之前的状态了，分析其实就是最短路径策略和商业关系策略的叠加（喜好customer的流量多于peer的流量）。

这时不管如何只是断开一条连接，都很难恢复到最初的状态。这种断连接可能导致四种稳定路由情形，即P1 and P2 Wedged，P1 Wedged，P2 Wedged以及Intended，所谓wedged就是搞成了那种不想要的情形，具体图例可以参考第7页。

这时可选的方式是让AS1主动withdraw backup路由的发送。然后等路由稳定后重新宣告backup路由。但这个时间多久可以定下来，是不能提前预知的。在这个例子中就是需要AS2和AS5分别学习到长路径到AS1才行。不过这也很难实现的，例如1-2在Moscow，而1-5在Tokyo，就非常难以实现了。因为这里只是AS，而不是BGP router。

多方BGP Wedgies

+----+ peer              peer +----+
|AS 3|------------------------|AS 4|
+----+                        +----+
  ||provider             provider|
  |+----------------+            |
  |                 |            |
  |customer         |customer    |
+----+peer   peer+----+          |
|AS 2|-----------|AS 5|          |
+----+           +----+          |
  |provider  provider|           |
  |                  |           |
  |                  |           |
  |customer  customer|   customer|
  +---------------+  |+----------+
    backup service|  ||primary service
                 +----+
                 |AS 1|
                 +----+

这是一个更加复杂的案例，理想状态下的AS2和AS5都是AS1的backup provider，AS4是primary provider。1-4之间的链路断掉随后恢复。3将持续使用2或5转发流量到1。1-2之间链路重启并不能恢复到初始状态。因为这样也只会选择AS5作为最佳路径。

因为AS2和AS5都是备份链路，假设AS3选择了AS2作为到AS1的转发路径，那么AS5其实目前并没有流量，AS1只能观测到AS2有流量，所以它就只会重启1-2之间的链路，但是这样就会导致AS3选择AS5作为到AS1的转发路径。

可能可行的解决方案是同时withdraw到备份路径的路由。例如同时关闭1-2和1-5的session，等路由重新稳定之后，再开启session。但是这需要很多non-local的知识，而且因为本来只有1-2之间有流量，1-5之间无流量，怎么确定1-5之间session确实重启了也很难。

实际情形以及解法

这个图示就很像他上边举得例子了。NA是AS3, AP是AS4，EMEA是AS2，LA是AS5，AU是AS1。

数学理论上，最短路径依赖的理论公式是：p(best(a, b)) = best(p(a), p(b))，这里p是路由策略，a和b都是路由。如果上述公式失效了，那么协议就是policy-rich的。新的数学公式应该是best(p(a), a) = a，也即a就是最佳路由，不管是否有策略作用于a。但是这个解法或许只是本地局部最优，而不是全局最优。

如何确保新的公式成立？首先问题在于a所在的路由器不是p(a)所在的路由器，a位于RA，那么p(a)所在的可能是RA的邻居。这个公式在一个AS内部成立应该不难，但是在AS之间应该很有挑战性，需要网络运营商之间的合作。另外路由策略其实就是确定local preference，这个确实是本地的，不同的运营商AS之间基本没有关联性，也就不具备可比性。