返回 登录
5

下一代超大规模软件定义网络技术实践

云计算的 IT 架构已经在企业应用中表现出明显优势,但网络设计理念却必须是一种推倒重来的思想。为了适应云计算的灵活、弹性扩展、高效和低成本,网络设计要进化为集中式软件管理,可编程化,控制转发层面分离等。本次陈海泉分享了关于下一代超大规模软件定义网络技术实践。

以下是本次分享的内容整理。


大家好,我是 QingCloud 的工程师陈海泉,今天给大家分享一些 SDN/NFV 2.0 架构的网络技术。我解释一下什么是 SDN,SDN 就是软件定义网络。当然也不是所有网络定制一定要软件来实现,因为有很多硬件方案也可以做到 SDN 的效果。

青云QingCloud 用软件定义来实现虚拟网络,我们 2013 年的时候,在公有云上线了第一代产品。当时 SDN 还是一个比较新鲜的事情,用户用的还比较少。到了今天,SDN已经开始普及,连私有云用户也在使用基于SDN的VPC。

随着用户量越来越大,第一版的 SDN 提供的私有网络里面的 VM 超过一定的数量的时候,我们发现性能就有一个比较大的损失,已经无法满足企业用户的需求。所以我们在去年下半年的时候,花了很大功夫去做 SDN/NFV 2.0 的事情。

17.pic_hd.jpg

考虑到很多人对计算机网络不熟悉,我先补充下网络基本原理:计算机网络分 7 层。 SDN 相关的主要是二层和三层网络。二层是数据链路层,使用 MAC 为地址通信,二层网络中的成员通过交换机连接起来。成员间的应用软件虽然以 IP 为地址通信,但是通信之前,操作系统会通过 ARP 协议,把目标 IP 转换成 MAC 地址,然后再发送数据包。交换机根据数据包的目标 MAC 地址,进行数据包的投递。二层网络中,会用到单播,广播和组播三种方式。

三层是网络层,使用 IP 为地址通信。三层网络就是用路由器将不同的二层网络连接在一起,形成一个可扩展的网络。通信方式可以是单播和组播,但不能是广播。路由器的作用就是根据路由表,找出目标 IP 对应的 MAC 地址。数据包往往通过多个路由器之间转发,才会送到目标地址。

基本知识介绍到这里,现在说一下为什么需要 SDN 。

首先,虚拟化技术带来的好处是用户的 VM 分布在物理机集群上面,出于负载均衡,和服务高可用的目的,需要在物理机之间迁移 VM ,并且迁移之后 IP 地址不变。

在早期的虚拟化方案中,物理机集群比较小,全部是一个二层网络, VM 使用物理设备分配的 IP 地址时,发生迁移之后, IP 本身就不会变化。但是随着云计算的发展,虚拟化的物理集群需要被部署在更大的三层网络上,这时候 VM 再使用物理 IP 地址,是不能够保证 IP 不变的,因为迁移到了别的二层网络,对应的路由器就不认识原来的地址了, VM 要继续工作,必须更换成当前网络的 IP 地址。

这个时候,就需要网络虚拟化技术,也就是通过 SDN 给 VM 定义虚拟的 IP 段,这个虚拟的网络可以分散在整个三层网络上,使得 VM 迁移后, IP 地址不变。这个IP地址跟物理的路由器,交换机没什么关系,可以随便定义。随着云计算的发展,单靠网络虚拟化技术,仍然满足不了用户大规模部署的需求,这时就需要有 VPC 。

VPC 是什么意思呢? VPC 是用户定义的一个专属的大型三层网络。在 VPC 网络内,用户可以自定义 IP 地址范围、创建子网,并在子网内创建主机/数据库/大数据等各种云资源。

简单的说,虚拟网络指的是虚拟二层网络, VPC 指的是虚拟三层网络。在 VPC 里面,还需要能做到不同 VPC 之间, IP 地址复用。因为私有 IP 段有限制,不同的用户,可以使用相同的 IP 地址,却不互相影响。

正是因为云计算需要虚拟网络,也需要 VPC 。所以需要一个 SDN 方案解决这两个需求,现有的 SDN 方案主要分成两个方向:

  1. 用软件来定义,但是用硬件来实现。比如某些带 SDN 功能的交换机,把它采购进来,部署到产品里,用硬件厂商提供的 API ,就能定义虚拟网络,实现 VPC 功能。

  2. NFV,就是网络功能虚拟化,用软件的方式来实现虚拟的交换机和路由器,把他们组织,并管理起来,让上层应用能够定义虚拟网络。其代表有 VMware NSX 、 JuniperOpenContrail、OpenStackDVR 等等。

37.pic_hd.jpg

QingCloud 在 SDN 方案的选型上也做过讨论,用软件还是用硬件方案?其中考虑的问题主要是以下三个方面:

  1. 成本。在公有云上面大家拼的是成本,谁的硬件成本低,谁就能把价格降到最低。如果我们采用硬件方案,在网络设备上面需要增加了很多投资,要替换掉几乎所有的网络设备。
  2. 设备依赖。我们的私有云卖的是软件,客户可以按照偏好选择自己的硬件,假如 QingCloud 的 SDN 绑定了某款硬件产品,那我们在面对企业客户的时候,可能连招标的机会都没有,因为客户往往有自己的采购渠道,指定的硬件品牌。
  3. 情怀。对于工程师来说,自然是想把产品做得更优秀。参考下优秀的传统行业,就能明白这一点。

其实,计算机网络跟传统快递行业非常的接近,我在后面解释网络知识时,也会拿快递打比方。

为什么说快递跟计算机网络接近呢?因为网络中的交换机、路由器,其实跟快递行业里的快递员和包裹集散中心非常相似,用户发包裹给快递员以后,快递员会送到快递集散中心,这里可以查询包裹应该被送到哪个地方,然后再将包裹经过多个快递集散中心层层转运,才会送到收件人那里。

顺丰在中国应该是最好的快递公司之一,因为它把转运环节都做全了,只有方方面面都能够控制才能实现压倒性的优势。

上面的插图给了顺丰航空的一个截图。我是看到了这张图,才明白为什么他们能够比别家送得快。因为他们不仅有自营的快递转运点,连飞机都是自己买的。

因此,我们如果把数据包转发的每个流程都控制到,就有可能在整体系统上面做到最优,而采用硬件设备实现这些功能的话,最后带来的是同质化,跟竞争对手相比不会有任何的优势。

综合以上三方面的原因,我们决定开发一套新的 SDN/NFV2.0 方案,取代 1.0 。

开发一套新的SDN/NFV 2.0 方案, 也就是自营航空公司。既然定了要自己做一套新的方案,怎么去实现?我们做了一些总结,新的产品首先需要满足传统 SDN 的功能。需要做到三点:

  1. 数据封装。也就是实现一个虚拟网络;
  2. 实现控制平面。对二层、三层的网络数据进行转发和路由规则的同步,然后下发到虚拟的交换机和路由器里面去,同时需要做到 ARP 泛洪抑制;
  3. 实现数据平面。我们使用了叫做 DVR 的linux kernel模块实现的数据平面,同时还提供了虚拟边界路由器,提供vpn,隧道等高级功能。

下面分别解释这三点:

首先解释下虚拟网络。 虚拟网络直接说比较难以理解,但是类比到传统行业,就好解释了。

在一些大公司里会提供一种叫内部邮件的服务给员工,比如要给财务部门某同事发一个报销单,会查他的工位,比如 2pw067 。然后准备一个信封,把要填的单子放在里面, 收件人地址就填 2pw067 。我不需要知道这个人是在北京,还是在上海,直接用工位号就能发件。我把这个信封交给公司的收发室。收发室其实不具备邮递能力,但是他们也能做快递业务,方法就是对这个信封进行重新封装,收发室有个地址本,能查到 2pw067 这个工位对应的办公楼具体地址。

然后用一个大信封,把我原来的信封装进去,收件人填目标办公楼的收发室员工名字,收件地址是实际的街道地址,然后把具有新地址的信封交给真正的快递公司,比如顺丰。快递公司会把信封发送到对应的办公楼,然后那边的收发室把外层信封拆掉,将里面的信封交给具体的收件人。

拿计算机的术语来讲,内部邮件系统就是虚拟快递公司,真正派件的快递公司,叫做物理快递公司。虚拟网络非常类似,允许用户通过自己定义的地址,进行传输。这个地址用户随便定义,反正物理网络看不到这个地址,也就不受任何限制。

物理机收到 VM 发的包后,会对数据包做封装,再套一个信封,也就是加个包头,写上目标物理机的地址。物理网络设备,根据新的包头把这个数据包发送到对应的物理机,然后物理机那边的终端会把数据包拆开,将里面的数据包转发到目标 VM 。

这里的封包,拆包就是 Overlay 技术,也叫数据封装。听起来很高大上,其实传统行业几百年前就实现了。

下面就是具体的计算机技术细节:实现虚拟网络,比较流行的数据封装协议是 VXLAN ,因为 VXLAN 相比传统的 GRE 协议有一系列的优势。

  1. 隧道连接一组物理机。 VXLAN 发包时,可以任意指定目标物理 IP 地址和 ID ,不像 GRE 那样,要在两边配置点对点的连接;
  2. 使用 UDP 协议。 UDP 协议的特点是有端口。发包时每个连接都使用不同的源端口。当数据包交给目标服务器网卡的时候,网卡根据这个数据的包头的 IP/端口做 HASH 运算,用于选择不同的网卡队列。而每个网卡队列会绑定到一个 CPU 上面,这样把包会交给不同的 CPU 处理,提升总体性能;
  3. 使用基于组播的 Flood & Learn 模式自动管理虚拟网络。这个功能会大幅降低组件虚拟网络的复杂度,因为 VXLAN 的终端,会根据数据包包头的内容,自动建立,并维护一个转发表。回包的时候,根据转发包找到目的物理机的地址。

这里的转发表,拿之前的例子说明,就是企业内部邮件收发室的地址本,把虚拟地址和物理地址对应上。 VXLAN 的这个特殊功能,就是能够自动建立地址本。

基于以上几点,我们觉得 VXLAN 不错,但是仔细的去想,就发现它有两个非常大的不足:

  1. 发送广播包时,使用了组播协议,大规模部署会受硬件设备组播路由限制。它在二层网络中使用时,没什么问题,但是在三层网络中使用时,物理路由器上会建立大量的组播路由条目,影响路由器性能,并且增加了路由器运维的难度。
  2. Flood& Learn 的机制,会把原来在二层广播的 ARP 包扩大到三层网络。

第二点解释起来比较复杂,先从 ARP 原理讲起。 ARP 的作用是把 IP 地址转换成 MAC 地址。在发包方,如果遇到不认识的 IP 地址,会发个广播包到当前的二层网络,内容大概是:谁的 IP 是 1.2.3.4 ,请告诉 1.2.3.5 。所有网络成员都会收到这个包,但是只有 1.2.3.4 会回包给 1.2.3.5 。这样, 1.2.3.5 就知道了 1.2.3.4 的 MAC 地址,接下来他们就能够通过 MAC 地址互相通信。 Flood & Learn 的原理就是学习 ARP 广播包的行为,建立转发表。

拿之前的企业内部邮件做例子,收发室收到目标地址是 2pw067 的邮件时,他一开始不知道这个地址在几楼的哪个办公室,他会群发 Email 到写字楼的全体员工,说有 2pw067 的包裹。这样收件人会到收发室取邮件,同时把自己的 Email 告诉收发室。

此时,收发室的这个人,会默默在自己的小本上加一行: 2pw067 的 Email 是 XXX@yunify.com 。这样下次在有到 2pw067 的邮件,他直接给 XXX@yunify.com 发邮件,通知他来取件,而不是群发所有人。这个方式最大的问题是,收发室老会群发邮件,而且他每隔一段时间,就要确认下 2pw067 的 Email 有没有发生变化。这样随着规模扩大,广播越来越多,会严重的浪费带宽资源。

虽然物理网络也会使用 ARP 广播,但是广播被限制在二层网络里面。而虚拟网络的载体,实际是三层的物理网络,广播实际上可能被发送到整个数据中心的所有物理机。在大规模部署虚拟网络时,ARP 浪费的带宽可能占网络流量的一半以上。

要解决这个问题,需要做到两点:

  • 拦截 ARP 广播,避免发送到全局;
  • 使用控制器同步地址本,代替 Flood & Learn 功能。

所以,需要有 SDN 控制器,通过同步规则,取代 VXLAN 自有的 Flood& Learn 功能。

也就是说,有个 HR ,每当有员工人入职,工位变动时,就把他的工位发到公司所有写字楼的收发室,不让他们用广播的方式学习地址。而且收发室收到群发邮件时,会主动回包,而不是把广播包转发到别的收发室。

那么这个控制器需要多少个呢?我之前曾经了解过一些 SDN 方案,通常只有一个。它负责同步整个集群中所有节点的规则,这么做带来一个问题,当 VM 创建、销毁、迁移的时候,控制器需要把新的规则同步到整个集群所有的节点中。

而优秀的云计算平台,能够让用户秒级创建资源。 VM 创建、销毁、迁移这种事情,在集群中无时无刻都存在,同步规则会变得相当频繁。所以我们做了一个分布式控制器,不仅把控制器分布到每个 VPC ,还分布到每个虚拟网络里。

刚才说了虚拟网络和控制器,第三点 SDN 需要做的就是控制数据平面,其作用就是把数据包从网卡拷贝到 VM 。

传统的数据平面,比如 OpenStack 通常会用 OVS 。 OVS 会有一个问题,它会把数据包传到 UserSpace ,因为有个应用程序,根据流表决定数据包如何转发,这样会带来性能的下降。

而我们的方案完全避免了这个问题,使用自己研发的 DVR 取代 OVS ,所有数据转发都在 LinuxKernel 中完成。 DVR 就是分布式虚拟路由器。它实际上是一个带路由器的交换机,同时具有二层交换,和三层路由的功能。

DVR 这个概念,几乎在所有先进的 NFV 方案的 SDN 中都有,比如 OpenStack 的 DVR , VMware NSX 的逻辑路由器,OpenContrail 的 vRouter 。

他们名字虽然不同,但是本质是相同的,也就是说,让每个计算节点都拥有虚拟的交换机和路由器。听起来很简单,但是实现它有很大困难,其中之一就是:同一个网络的 DVR, MAC,IP 地址都是相同的,这在物理网络里面是无法想象的,因为打破了网络的基本规律。

但是 DVR 却是 NFV 方案的一个关键。

如上图所示,我们解释一下为什么需要 DVR 。左边是这张是物理拓扑图,物理世界中 A 和 B 通信,需要把信息发送到 A 的交换机,然后到路由器,然后路由器转给 B 的交换机,B 的交换机再发送给 B ,A 和 B 通常需要 4 跳才能发一个数据包。

我们 1.0 的时候,也是用 NFV 实现的 SDN ,我们会模仿物理世界,发明出虚拟的路由器和交换机提供给用户。请看中间这张图,如果 A、B、C、D、E 这五个设备分别位于五个不同的物理机上,在逻辑上,A-> B 的包经过 C、E、D 才能到 B ,逻辑上是 4 跳。但是虚拟设备每一跳都要通过物理机去转发,而物理机之间发包都需要 4 跳,这样总得转发量实际上需要 16 跳。

这也就是为什么我们 SDN 1.0 的性能总是上不去。随着规模增加,逻辑上每增加 1 跳,物理上就增加 4 跳,性能随规模衰减得厉害。

为了解决这个问题,我们引入了 DVR 。请看右边这张图, A 和 B 的物理机都有 DVR ,从 A 到 B 只在两个 DVR 之间直接交换一下数据就可以了,这样在逻辑上只有一跳。所以物理层面上跟左边的图一样, 4 跳完成一个数据包的转换,这样就可以非常接近物理机的性能,在大规模部署时,保持高性能。

使用 DVR 的另外一个原因,就是虚拟网络设备性能弱于物理设备,在物理设备部署拓扑上,经常有汇聚节点,成为网络瓶颈。由于物理设备能力很强,很容易就能达到 40 G ,或更高带宽,汇聚几次没什么关系;而虚拟设备作为汇聚节点时,往往就限制了它管理的网络整体能力,因为虚拟汇聚设备会成为性能瓶颈。使用 DVR 同时意味着不再有汇聚节点,因为所有成员都是点对点直接通信。

这个在物理设备上无法实现,因为不可能把所有设备连成一个大网,而虚拟网络设备上,是可以实现的,因为他们相连,只是加几条转发规则而已,而不是真的需要去点对点地连接网线。

有了上面三个功能,就是通常意义上的 SDN 了。然而我们在做云计算平台时,通过长时间的积累,还发现了很多需求:

  1. VPC,并且 VPC 主机直接绑定公网 IP 。
  2. 负载均衡器。可在公网网关上对入流量进行分流,转发到多个负载均衡器节点。
  3. VM 使用基础网络时,也就是物理网络的 IP 地址在迁移后不变。
  4. VPC 和物理网络高效连接。

下面分别解释。

首先是 VPC ,青云QingCloud VPC 功能是 1 月 6 号上线的,我们只上线了一周就卖掉了第一批上线的所有物理资源。因为我们公有云的大用户已经深深的认识到必须要有一个 VPC 才能支持自己的海量的资源。业务真的到了一千个 VM 以上的时候,就需要有一个高效的三层网络,取代二层网络。

我们 VPC 设计是支持 64000 台虚拟机,代表着我们控制器控制规则有可能是 6 万条,假如我们把跟 6 万条规则同步到每个 DVR 上去,这同步量非常大。

相信靠我写的代码完全不可能实现。所以设计一开始就给他设计了一个学习的能力。学习不是是基于泛洪的学习,而是根据用户的行为对他进行学习。

这个学习功能,还是拿快递打比方。

快递员通常收到邮件时,会把邮件发到邮件集散中心,那里有人去查地址本,决定邮件对应的下一个邮件集散中心是哪个。然后会交给邮递员经行投递。我们假设每个快递员都能够把包裹投递到任何一个地方,也就是拥有 DVR 的能力。

当发件邮递员投送发给oc的包裹到北辰购物中心 2 号楼时,他多做一件事情,给收件的快递员打个电话,告诉他说:哥们,你以后再收到发给 oc 的包,直接交给我,不用送到邮件集散中心。这样收件快递员更新自己的地址本,记上: oc 的包,给快递员老王,让他直接去派送。下次,再有包给 oc 时,他把包交给老王,老王直接派送给 oc ,不必去邮件集散中心绕路。

这就是 VPC 主动学习功能的基本原理,能够实现超大规模的三层网络,却不必同步大量的转发规则。

请看上面的图。有两个虚拟网络,都在同一个 VPC 之间,当他们建立之后,两个 VM 分别加入两个网络,它们没有任何的沟通。最开始通信的时候,左边 VM 跟右边的 VM 发包,通过默认路由线路(邮件集散中心),经过两个节点中转,当 DVR 发现这两个虚拟机真的要互相访问的时候,才会把规则同步过去。

虽然一开始的时候性能稍微差一点。但是用着用着就快了,因为 DVR 学习到了规则。这样,不需要真的同步 6 万条规则到 6 万个 DVR 节点,真正的用户即使有了 6 万台虚拟机,也不可能时时刻刻都进行着点对点互相访问,一定会按照自己的业务往下拓展,某些 VM 之间才需要互相访问,大部分 VM 之间其实不需要互相访问。这样看来,完全没必要同步所有 6 万条规则,只需要学到其中几千条有用的就行了。

DVR 除了实现 VPC 功能之外,还有许多别功能。请看上面这张图,除了 VPC ,还有其他四个方向。

  • 第一个就是公网网关,为了提高公网访问性能,DVR 跟公网网关可以直连;
  • 第二是 VPC 的虚拟机要能跟硬件设备进行高度的互访,因为我们私有云用户的机房里,不止有虚拟机,还有 Oracle 的数据库、F5 的路由器等等,假如我们让用户把这些业务放到虚拟网络里,虚拟网络就要跟硬件网络进行高速的互访,VPC 跟物理网络互访通过给 VM 绑定物理网络 IP 实现,也就是说一个 VPC 的虚机,除了有自定义的虚拟 IP 地址外,还能有一个对应的物理网络 IP , DVR 会做地址转换,把物理 IP 转换成私有 IP ,实现跟硬件网络高速互联。
  • 第三是 VPC ,可以让用户定义 255 个 C 段,加起来可以有 60000 多个虚拟机。
  • 第四,我们还提供了一个边界路由器,可以让用户虚拟资源跟远程的 IDC 之间做一个互通。

除了 VPC ,我们为私有云用户设计了 VBC 功能。 VBC 的特点是里面的 VM ,全部可以直接使用物理网络定义的 IP 地址,而且具备 VPC 的所有功能。 VBC 是一个私有网络和物理路由器的混合网络,能够做到使用物理IP地址的同时,能让 VM 在集群中任意迁移,有保持 IP 地址不变。

最后一个就是负载均衡器集群,设计是这样,我们有一个网关集群连着因特网。比如我有一个 IP 1.2.3.4 ,入流量发送到 VG 1 这里。VG 1 会做第一次的流量转发,把流量转发到用户自己私有的负载均衡器节点里(LB node1、2、3)。它的特点是,返回流量不需要经过进来的 VG 1,而是经过 LB node 对应的不同物理网关发送到因特网。

因为当 VG1 能力受到限制的时候,假如我们所有流量都从它回去的时候,它自己的网络带宽实际上就是整个集群的能力,而我们把它分散之后,就可以做到,出去的流量几乎是没有限制,只要我们的 VG 设备有多少,它的带宽就会有多少,因为流量不需要从默认的线路回去。同时随着用户拓展负载均衡器节点的数量,也扩展了 HTTPS 的卸载能力。

并且我们做到了 4 层/ 7 层的完全透明,也就是说用户通过因特网访问到他们业务的时候,我们在所有转发过程中,都会保留其原地址,用户这边得到的包是直接来自因特网用户的 IP 地址。

QA

1、问题:有的 SDN 必须更换新的物理服务器;有的 SDN 不需要。请帮忙分析一下。

必须更换新的物理服务器的这种 SDN ,属于硬件方案,软件定义网络,硬件实现网络。典型的产品是思科N9000 系列交换机。有的 SDN 不需要换设备,因为代码跑在 X86 服务器上,也就是 NFV 实现。

2、问题:据了解你们新的 SDN 里面 VM 迁移可以保持 IP 不变,你是怎么实现的?

因为 VM 的 IP 在二层网上,使用了虚拟网络,将分散在不同物理机上的 VM ,都连成了一个二层网,但是路由器使用的是物理路由器,做到了迁移后,IP 不变,也就是虚拟交换机+物理路由器。

3、问题:LB 能否直接连接后端服务器?

可以,不管是 VPC ,还是基础网络,都可以,而且 TCP/HTTP/HTTPS 全透明,后端直接获得客户端源地址。

4、提问:刚才提到 DVR ,能不能详细介绍一下。怎么实现?

具体实现比较复杂,我们改了 LinuxKernel ,让它能够适应 DVR、MAC、IP 重复的情况。因为同一个网段的 VM ,网关的 MAC、IP 都的是一样,而这些 VM 又需要有各自的 DVR 。我们改了很多虚拟交换机的逻辑,也发明了一些功能才做到,但是不太容易解释。而且虚拟网络还能让用户使用虚 IP ,这也是 DVR 的一个难点。我之后还看了下 AWS 的 VPC 功能,他们还不能允许用户定义随便 VIP 。

5、提问:计算机都是和本地 L3 出去,在两个网端,那你这个从本地的 L3 到外网那个 L3 这怎么算?

从本地的 L3 到外网那个 L3 ,在 DVR 层面就是两个虚拟路由器之间的转发,逻辑上也是一跳。

6、提问:SDN和NFV有啥区别?

SDN 只要求软件定义网络,可以是硬件实现, NFV 表示用软件实现虚拟网络,属于 SDN 的一种。

7、提问:一个 VPC 对应一个 VXLANID ?可以对应多个吗?

青云QingCloud 的 VPC 可以包含 253 个 VXNET ,就是虚拟网络,每个 VXNET 对应一个 VXLAN ID 。 VXLAN 网关是分布式,一个 VXLAN 有很多 DVR 。

8、提问:一个 VPC 内网关是不是分布式的,同一个 HOST 内的两台 VM ,不同网段互访可以本地 DVR 转发,还是要到专门的网关设备?

本地 DVR 转发,通过学习功能建立路由表。

9、提问:VXLAN 控制平面的自动学习是怎么实现的?

我们自己发明的一个学习方法,要求 DVR 之间能够互相沟通。之前有讲过,就是那个快递员之间打电话的例子。

10、提问:SDN Controller 是你们自己研发的,还是开源的?

是我们研发的

11、提问:DVR 的配置下发是怎么实现的,是由 SDN Controller 下发的嘛?南向用了什么协议?

Controller 下发部分规则,建立默认的路由表,更多是靠 DVR 的学习功能,里面学习机制的通信是我们定义的,路由同步是标准的 BGP/OSPF 这些。

原文链接: https://community.qingcloud.com/topic/336/

评论