1 问题背景
2 探索
2.1 邻居状态确认
2.2 路由有效性检查
2.3 路由过滤
2.4 手搓新网段，触发路由更新
3 分析原因
4 解决方案
5 总结
1 问题背景
这是一份基础网络运维的事故复盘报告。
因为一些历史原因，我司各个环境之间的互联互通采用了串行连接，并且核心链路和转发节点使用了共享资源，既下图中红色部分。因为共享资源的可靠性和稳定性表现不佳且故障场景下的权限不足，倍受困扰后下定决心要改变这种局面。在梳理了现有资源之后，基础网络架构跃迁历程如下：
互联方式由之前身不由己的纯静态路由调整为全BGP环境。因为是混合云架构，所有邻居之间全部基于EBGP对接，子接口部署，路由结构如下图所示：
as分布如图所示，看起来很棒：闭合连接/双上行/EBGP，这些特性配合BFD和触发更新，完全有能力在异常情况下实现毫秒级的路由收敛，踢出故障链路后使流量快速切换到备用路径。
然而，不出意外的，我们遇到了意外———割接很顺利，架构变更按计划完成，但在验证高可用能力的过程中遇到了光路中断，造成EBGP-5邻居状态idle，导致办公环境与托管IDC失联：
确认问题链路两端模块的光功率均在合理区间，基本排除了模块故障的可能性。托管IDC侧挂表测试，OTDR显示近端衰减，确认链路状态不可用，锁定位置后反馈有管井临时施工造成链路中断。但EBGP邻居down了，理论上应该能够通过冗余路径学到路由才是，为什么会失联呢？
2 探索
于是问题排查的重心调整到高可用方向。
2.1 邻居状态确认
优先确认了所有EBGP邻居的关系状态，确保均为established。
2.2 路由有效性检查
其次检查办公环境和托管IDC内网出口方向的路由宣告详情，确认两侧BGP进程路由宣告成功。
2.3 路由过滤
再次则分别排查内网出口方向的前缀列表，确认已生效的过滤逻辑不存在误杀情况。
2.4 手搓新网段，触发路由更新
最后尝试在办公环境内网出口设备上新增loopback，配置并发布一个新的子网和相应的路由，随后检查EBGP邻居的路由收发情况，发现情况依旧。
3 分析原因
经过上述测试排查，发现如下特征————
两端设备配置正确，且路由宣告正常； 云上网络组件L3节点本地路由表中有直连邻居宣告的路由，说明可以收到正确且完整的路由更新； 跨过云上网络组件后，再下一跳设备（也就是本文中问题链路的远端设备）的路由表中就找不到相应的路由信息了； 再进一步测试，在托管IDC本地开debug实时打印路由更新，确认从云上EBGP邻居处收到的路由更新中，并不包含办公环境所属网段的路由信息。
综上，办公环境和托管IDC内网出口方向，两端设备都向云上L3节点宣告了本地路由，云上L3节点也能正常收到路由信息并加入自身的路由表，但是，云上L3节点并不会把这些路由信息再转发到远端的云下设备。折腾了近2个小时，过程中我甚至想到了古早概念-水平分割，但想到产品经理明确强调过：“专线接入点就是个渠道，当成链路看待就可以了”，加之方案设计时还额外增加了子接口的配置，结果还是在防环上踩了坑。最终又拉上云服务商的售后升级确认，才真正破案。万万妹想到哇，555555
4 解决方案
针对问题情况，揪着售后一起确认了各种细节后，敲定了解决方案————
在云上再单独创建一个L3节点； 这个新建的L3节点为办公环境和托管IDC分别连接一个专线接入点； 托管IDC和办公环境的内网出口节点，各自再创建一个子接口，用于和新增的专线接入点对接，并与云上新建的L3节点建立EBGP邻居EBGP-6和EBGP-7； 托管IDC和办公环境的内网出口节点，分别将本地的路由信息通过新建子接口发布给云上这个新的EBGP邻居； 新增的EBGP-6和EBGP-7这两组邻居关系，可以为EBGP-5提供冗余路径和路由更新渠道，调整后的方案如下图所示：
5 总结
整体看下来，问题其实很简单，认为有了子接口，又是不同as之间的EBGP邻居，不会受到as-path、水平分割这类防环逻辑的限制，但其实是思维定势的误区，造成了后面的周折和时间损耗。
诚然，BGPv4仍是当代互联网的基础，但云服务带来了新鲜内容，基于云的各种能力和产品，相较企业网和数通的传统技术概念有了明显变化，应该在掌握基础的前提下，明了新产品和新特性的更新迭代，真正理解这些不同之处的关联场景和针对的痛点，才能正确的发挥优势体现价值，给上层服务提供稳定和持久的支撑。
关于作者
宛景瑞，转转基础设施运维负责人。
想了解更多转转公司的业务实践，欢迎点击关注下方公众号：
