DCN场景下的BGP协议优化特性总结
发布时间:2019-11-21

前言

随着超大型互联网数据中心的规模优势愈加明显,特别是在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-local address,通过指定邻居接口即可建立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(prefix independent
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流量迁移的方式:


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

Graceful shutdown
向邻居设备发送UPDATE报文,用于通告优先级最低的路由(local-preference 值为0或MED值为4294967295),并且会携带知名的gshut community,从而使邻居设备进行路由更新,使其流量预先切换到备份链路或其他等价链路上。

BGP advertise-map
通过向邻居发送UPDATE报文携带的withdraw routes字段,告知邻居路由失效,邻居收到UPDATE报文之后会更新本地路由表,从而将相关的路由都删除。从使其的流量切换到备份链路或其他等价链路上。


通过原理的对比分析,小李总结出这几种流量迁移方式的差异点,如表1所示


▲ 表一:BGP流量迁移方式总结

经过对比分析,小李发现Neighbor shutdown方式太暴力,还会丢包;Graceful shutdown虽然不丢包,但需要等待路由收敛,时间比较长,而第三种BGP Advertise-Map直接通告路由失效的方式,既快捷又不丢包,而且特殊场景还可以通过ACL加以控制,就用它了。

总结

技术路漫漫,只有通过不断地学习、积累和实践才能进取前行。在DCN场景下的BGP优化主要的侧重点在于在双栈模式下简化BGP协议的部署、提高BGP协议的收敛性能以及平稳的流量迁移。网工小李把他工作中的经历毫无保留地分享给了其他的网工,希望他们有所收获。而他也在技术路上不断的成长,终于穿上了他心爱的格子衫,并且。。。。。。

他头上的发量,始终是个谜。

 

相关推荐:

大型数据中心BGP路由协议规划

大型数据中心网络路由协议选择

新一代数据中心网络架构

Clos组网技术

如何实现数据中心网络架构“去”堆叠

未来30年不落后的网络架构,智能网络

互联网数据中心网络25G组网架构设计

锐捷互动
搜索“锐捷互动”
或扫码关注
随时了解更多信息

返回顶部