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->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之间基本没有关联性,也就不具备可比性。
标签:+----+,customer,Wedgies,链路,BGP,provider,peer,路由 From: https://blog.51cto.com/basilguo/7243448