记一次公网 BGP Route Flap 路由震荡问题

1.问题发现

2024年4月18日晚22:50，我回到家打开邮箱，发现了一封来自 MoeDove LLC（我的上游之一、也是 Pigeon IX 的运营商）的邮件，大体内容为我网（AS151673）存在 Route Flap 现象，希望我及时修复，如图。

由于我近一周内（划重点，等会要考）没有操作过网内路由器，因此我登上 QQ ，欲询问另外一位维护者（daiyangcheng）是否动过路由配置，随后我看到了另一位好友 SerinaNya 的提醒，并同时询问了 daiyangcheng 有关此事。

以及收到某软件内的提醒

2.问题定位

猜测：由上方最右侧图，看到 Flap 现象在13日就已经出现，以及在13日、16-17日之间产生过一次中断，脑中突然闪过可能是13日新接上游 AS199310 的问题。恰好，我与他的 Session 有过一次中断，时间正是13日。

虽然当天就听到了 Flap 问题，但我未对此重视，最终确定问题是 RPKI 验证方面（再划重点 Flap 问题解决）。

确定：通过 NetOX 数据，基本确定了问题来自该上游。

一个小细节：我网内暂时还没有 iBGP 互联，我在中国香港接入了 AS199310 我香港的广播段为（2a0f:7803:fc20::/44），但是更新数据中它更像的内容为（2406:840:efa0::/44、2a0f:7803:fc70::/44 以及 2a0f:7803:fc80::/44）使我法兰克福的子网。

3.虚假的解决

技术上很简单，我中断了我方的 Session，并通知了上游，以及对其他人进行了道歉。

对方关闭了所有 BGP Session ，并进行修复，我第二天检查时也恢复了正常。

但是你以为就这么结束了？

注意上游是关闭了 BGP Session 而不是修复了问题，而且我方的 BGP Session 也是中断第二天，他对问题进行了修复

4.问题再现

由于个人原因，我当日并没有恢复 BGP Session，但是在我第三天再次检查是，Flap 问题再次出现，出现时间正是上游修复问题的时间。

点开内容，依旧是与之前相同的更新内容，此时一个奇怪的事情出现了，我并没有与他的 BGP Session（transit），但是却依旧会更新，十分令人不解，于是我想到了以下两点：

Pigeon IX 内我与他存在 Peer
在中国香港我还接入了 AS44324，而 AS44324 有一个上游正是 AS199310，与 AS Path 相同，这条上游正是 AS151673 -> AS44324 -> AS199310

此时问题就很明白了，Flap 从头至尾都是这条 AS Path ，在当日他中断了所有 BGP Session 后，也中断了其下游 BGP Session，问题才得以解决，而在他那天首次”修复“后，并没能解决实际问题，反倒由于重启了 BGP Session，导致问题再现。

5.彻底解决

我再一次通告了上游有关此问题，并要到了 AS44324 的 BGP Community 属性，对 AS199310 设置了不对其广播的 Community，至此，我网的 Route Flap 路由震荡问题得以彻底解决。

上游于后一日告诉我问题彻底修复，我也删除了原有的 Community 进行测试，证实了 Flap 已经解决，上游也对问题进行了解释（虽然我还是不大明白 Flap 具体原因，但总之是解决了）

6.经验教训

1.虽然具体问题原因我不清楚，但是也得到了日后 iBGP 及骨干网搭建的一些注意事项，如保证骨干网节点的链接稳定、注意过滤器有效，内网寻路技术的学习等

2.此次问题确实是在 NOC 邮箱收到邮件的第一时间处理，不过仍存在问题，该问题出现接近一周才被发现及解决，是我个人对网内状态的留意不足，深感惭愧。

3.作为 MANRS Network Operator 的参与者，保护路由安全是首要责任，虽然这次问题只是一个浪费互联网资源的事故（大概是给全球所有 IPv6 对等体都遭了一通吧），并不是严重的路由泄露问题（当然理应不会出现，毕竟 IRR RPKI 都是完全的，过滤器也是特别注意的情况下完成的），但是此次问题也理应敲响警钟，对网内状态严加注意，决不能影响公网的任何设施。