这是一份基础网络运维的事故复盘报告。

因为一些历史原因，我司各个环境之间的互联互通采用了串行连接，并且核心链路和转发节点使用了共享资源，既下图中红色部分。因为共享资源的可靠性和稳定性表现不佳且故障场景下的权限不足，倍受困扰后下定决心要改变这种局面。在梳理了现有资源之后，基础网络架构跃迁历程如下：

于是问题排查的重心调整到高可用方向。

优先确认了所有EBGP邻居的关系状态，确保均为established。

其次检查办公环境和托管IDC内网出口方向的路由宣告详情，确认两侧BGP进程路由宣告成功。

再次则分别排查内网出口方向的前缀列表，确认已生效的过滤逻辑不存在误杀情况。

2.4 手搓新网段，触发路由更新

最后尝试在办公环境内网出口设备上新增loopback，配置并发布一个新的子网和相应的路由，随后检查EBGP邻居的路由收发情况，发现情况依旧。

经过上述测试排查，发现如下特征————

综上，办公环境和托管IDC内网出口方向，两端设备都向云上L3节点宣告了本地路由，云上L3节点也能正常收到路由信息并加入自身的路由表，但是，云上L3节点并不会把这些路由信息再转发到远端的云下设备。折腾了近2个小时，过程中我甚至想到了古早概念-水平分割，但想到产品经理明确强调过：“专线接入点就是个渠道，当成链路看待就可以了”，加之方案设计时还额外增加了子接口的配置，结果还是在防环上踩了坑。最终又拉上云服务商的售后升级确认，才真正破案。万万妹想到哇，555555

针对问题情况，揪着售后一起确认了各种细节后，敲定了解决方案————

整体看下来，问题其实很简单，认为有了子接口，又是不同as之间的EBGP邻居，不会受到as-path、水平分割这类防环逻辑的限制，但其实是思维定势的误区，造成了后面的周折和时间损耗。

诚然，BGPv4仍是当代互联网的基础，但云服务带来了新鲜内容，基于云的各种能力和产品，相较企业网和数通的传统技术概念有了明显变化，应该在掌握基础的前提下，明了新产品和新特性的更新迭代，真正理解这些不同之处的关联场景和针对的痛点，才能正确的发挥优势体现价值，给上层服务提供稳定和持久的支撑。

宛景瑞，转转基础设施运维负责人。