前言

随着超大型互联网数据中心的规模优势愈加明显，特别是在IPv4、IPv6双栈模式下，对于我们网络工程师而言，所面临的建设和维护压力也是越来越大。在上一篇文章《大型数据中心BGP路由协议规划》中，我们讨论了BGP路由协议在数据中心的规模部署，可以大大提升网络的路由性能，简化网络规划，但是数据中心网络毕竟与传统广域网不同，对于BGP的部署和运维要求也会存在差异，通过优化BGP协议可以进一步提升网络路由性能及简化运维。本文将通过某互联网公司工程师小李在建设DCN时候的亲身填坑经历来了解BGP协议在数据中心场景的优化特性。

-------------我是华丽丽的分割线------------

我是小李，我帅的一批。

我上大学念的是法律专业，为了省点网费，跟校园网部署的锐捷认证计费系统进行了多年的斗智斗勇，也因此爱上了网络这个行当，并且考取了锐捷网络的RCIE（锐捷认证网络专家）认证，毕业后顺利地进入了一家互联网企业工作，每天就是处理各种网络的建设、规划、配置、变更，也可谓是经验丰富的老司机。

下面，就是我的故事，请仔细听噢！

网络建设篇

早晨，小李吹着口哨听着歌，一进办公室就接到了老板一个大活，要建设一个可以容纳5万台以上服务器的数据中心，业务服务器需要运行IPv4和IPv6双栈模式，先给出详细的网络设计方案和规划。对于网络规划，除了物理组网外，比较复杂的就是路由、地址等规划，但是作为锐捷《大型数据中心BGP路由协议规划》文章的优秀读者，小李对于路由协议的选择和规划没有任何疑虑，但考虑到双栈模式下会有大量的接口地址以及管理地址，顿感烦躁！

摆在面前的情况是：

服务器双栈运行，意味着网络也要开启双栈模式；

大量设备互联地址及管理地址规划，包括IPv4和IPV6；

BGP的IPv4邻居和IPv6邻居配置。

按照传统配置方法当然能实现，这个没有任何问题，但小李作为一个有着创新意识的互联网一线大厂工程师，并未急于按照经验进行规划，有没有更简单的方案呢？经过一番厂家的交流，小李采用锐捷网络提供的规划方案：

1

基于Linklocal地址建立会话---简化IPv6地址的分配

Link-localaddress是IPv6协议栈引入的新地址类型，接口开启IPv6协议后，可以自动生成Link-localaddress（FE80::/10），并且地址为本地链路有效。设备支持基于Link-local地址建立多个BGP邻居，从而可以免去规划分配独立的IPv6地址。

2

单BGP会话双栈路由---减少BGP邻居数量

仅通过IPv4地址或者仅通过IPv6地址建立一个BGP邻居会话，同时实现IPv4、IPv6双栈路由传递的功能，从而达到节省设备邻居表项。

小李发现这两个功能在这种场景下的结合简直不要太完美，通过IPv6的Link-localaddress，通过指定邻居接口即可建立BGP邻居，并基于每个邻居激活IPv4、IPv6双栈路由模式，从而实现单IPv6会话，传递IPv4、IPv6双栈路由。

小李的规划提交给了领导后，马上获得审批通过，并立即开始建设执行，就在服务器批量上线的时候，小李又接到了一个新的需求，数据中心单独规划一个POD，这个POD服务器要运行Docker，宿主机要与TOR交换机之间需要通过BGP进行路由交换，宿主机的网段已经规划完成，但具体地址要等业务上线的时候才能拿到，做好心理准备吧！

小李大吃一惊，什么心理准备啊，还不是业务每上线一台宿主机我都要配合他们做一次BGP邻居对接配置吗？按照业务上线的习惯每次都要等到后半夜才能上线，难不成，每天就为了配置一个BGP邻居，一分钟不到的事情，还要跟他们一起加个班么？

加班虽好，但是工作内容价值不高。所以小李开始琢磨，既然网段已经规划好，如果BGP的邻居能基于网段建立，那不就不需要每天跟业务线的人一起加班了么？

通过翻阅设备手册，小李还真的发现了这个功能：

基于网段被动建立会话

网络设备配置基于网段的BGP邻居，配置此模式后，不会主动发起BGP邻居建立请求，而是被动接收到对端邻居发起建立请求后，根据邻居地址生成对应的真实邻居，并建立会话。

时间指向晚上八点钟，配置完成，大功告成。作为一个互联网一线大厂的优秀工程师，小李吹着口哨听着歌打卡下班了，还有时间健个身，心理美滋滋。

网络扩容篇

某日，小李得到领导安排的一项新的任务，近期公司要上线一批AI业务，规模虽然不大，但是原有网络的收敛比较高，恐怕不能满足高性能计算的需求，要求小李针对一个POD进行扩容，降低收敛比，但又不能影响原来在线的业务，扩容后的网络架构，如图一所示：

▲图一：POD扩容架构

小李接到任务后，心理自喜，采用Spine-Leaf的一个最大的好处就是横向扩容方便，于是就按照规划割接第一台POD-Spine设备上线，这时候业务反馈有少量的丢包。啊？虽然是少量丢包，但也引发了小李深深的思考，到底是怎么回事呢？

检查配置OK、路由学习正常，为什么有丢包呢？经过仔细分析，小李发现原来问题的根源在于路由表项的安装差异上，新的POD-Spine上线后，向POD-Leaf以及Spine通告了自己的路由，并学习网络的路由，就在此时，对于POD-Leaf来说，ECMP由两条，立刻变成了三条，并且发送数据流量，与此同时新上线的POD-Spine设备虽然完成了网络路由的学习，但安装这些路由表项需要一定的时间，从而有一个时间差，导致服务器的流量出现了少量的丢包，那如何解决这个问题呢？小李此时想如果设备能够先将路由学习并安装完成以后，再向邻居通告自己完整的路由，那这个时间差不就不存在了吗？想到这里，小李通过翻阅设备手册发现：

BGP路由延迟通告

将学习到的路由先安装到硬件路由表项后，再向邻居通告这些路由

有了这个功能后应该就能解决这个问题了吧！小李立刻进行了第二台POD-Spine设备的上线，并开启了此功能，同时还请业务组同事实时监控服务器的丢包情况，发现第二台设备上线后没有造成任何的丢包。搞定，胜利，欧耶~

故障处理篇

天有不测风云，人有旦夕祸福，小概率事件也是会发生的。

如图二所示：

▲图二：网络维护区域

这天工程师小王找小李哭诉，由于Spine节点设备出现故障、宕机，导致小王被业务部门投诉，表示出现了10多秒的丢包。咱们网络有10K多的路由，收敛也需要时间啊，丢点包怎么了，业务又没断。咦？你负责的区域应该同样会受到这台设备故障牵连，你怎么还能那么潇洒呢，业务部门没有投诉你吗？

这时小李低声说，告诉你一个秘籍吧，保你轻松应对“黑天鹅事件”，这个秘籍叫做：

BGP的PIC（prefixindependent

convergence）快切

BGP的PIC快切实现了路由前缀无关的收敛，收敛速度与路由规模无关，因此能实现大规模路由的快速切换。

PIC快切功能基于AS号来实现，在EBGP之间启用，开启PIC快切功能后，BGP发布路由时会携带PIC扩展团体属性，接收该BGP路由的交换机会根据发布者的AS号和router-id分配一个唯一的索引ID，通过优选计算后会携带该索引下发到转发面。当发布者上行链路全部中断，无法收到此AS的路由信息时，通过查找对应的索引ID，通告转发面将关联该ID的路由一次性完成切换，从而实现业务的快速收敛，无需等待逐条删除路由来收敛（普通路由收敛需要逐条删除失效路由信息，因此收敛时间与路由规模强相关）。

简单来说呢，就是来自故障节点设备（Spine）发布的路由，POD-Spine设备通过BGP的私有属性进行了归类分组，并且携带私有属性将路由通告下游（POD-Leaf），一旦Spine节点故障，POD-Spine自身会快速切换，并通过私有属性通告POD-Leaf全部路由失效并进行切换。这样，我的这个POD内部就能够实现快速的收敛了。这种实现方式做到了与前缀无关的路由收敛，并且非常适用于大规模的路由切换，实测数据显示：

12K路由收敛实测：

未开启PIC快切：13S

开启PIC快切：1S以内(0.7S)（此切换时间不随路由规模变化而变化，在大规模路由情况下尤为适用）

那既然是私有属性，只能自己识别，别的设备不支持会影响路由学习吗？小王疑惑地问。不会的，对于不支持这个属性的设备，会自动过滤掉这个信息，不会影响其他设备路由的正常学习。好吧，今天又涨知识了，带着满脸佩服表情的小王回到了自己的工位，并将所学知识点立即应用到自己的网络，降低“黑天鹅事件”发生后产生的损失。

核心迁移篇

有人问这次互联网寒冬到底有多冷，小李表示，到底有多冷我不知道，但要做的事情一点没有少。这不，又接到了一个新机房建设任务。接到任务的小李，立即进行了网络的规划以及硬件核对，发现还缺少两台POD-Spine设备？难不成这个设备也要从那个机房迁移过来吗？小李得到的回复是肯定的，那个老机房的业务没有按照预期计划部署，流量没有那么高了，将收敛比提高一下，并下线两台POD-Spine设备吧，但一定不能影响业务哦~

▲图三：某某机房网络架构

设备下线，要先将待下线设备流量迁移走，保证不影响业务，这时小李通过与设备厂家沟通，获取了几种BGP流量迁移的方式：

Neighborshutdown

通过向邻居发送notification报文来告知邻居已经人为shutdown邻居关系，常用于框式设备单线卡隔离变更。

Gracefulshutdown

向邻居设备发送UPDATE报文，用于通告优先级最低的路由（local-preference值为0或MED值为），并且会携带知名的gshut