Author basilguo@163.com
Date Aug. 25, 2023
Description BGP Wedgies
[TOC]
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->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。
- 【正常】如果1->4之间的路径断了，那么1->2作为备份路径就会发挥作用，构成1->2->3->4，转发路径则是4=>3=>2=>1。
- 【异常】如果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之间基本没有关联性，也就不具备可比性。
