CN105515978A - 实现分布式路由、物理主机接入的方法及装置 - Google Patents
实现分布式路由、物理主机接入的方法及装置 Download PDFInfo
- Publication number
- CN105515978A CN105515978A CN201610012009.3A CN201610012009A CN105515978A CN 105515978 A CN105515978 A CN 105515978A CN 201610012009 A CN201610012009 A CN 201610012009A CN 105515978 A CN105515978 A CN 105515978A
- Authority
- CN
- China
- Prior art keywords
- mac
- message
- described message
- local
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000013507 mapping Methods 0.000 claims description 16
- 230000008878 coupling Effects 0.000 claims description 14
- 238000010168 coupling process Methods 0.000 claims description 14
- 238000005859 coupling reaction Methods 0.000 claims description 14
- 238000004064 recycling Methods 0.000 claims description 6
- 238000004891 communication Methods 0.000 abstract description 14
- 230000000694 effects Effects 0.000 abstract description 2
- 239000003795 chemical substances by application Substances 0.000 description 61
- 230000008569 process Effects 0.000 description 18
- 230000004927 fusion Effects 0.000 description 6
- 230000006872 improvement Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 238000002955 isolation Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 241000208340 Araliaceae Species 0.000 description 2
- 235000005035 Panax pseudoginseng ssp. pseudoginseng Nutrition 0.000 description 2
- 235000003140 Panax quinquefolius Nutrition 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000007667 floating Methods 0.000 description 2
- 235000008434 ginseng Nutrition 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明揭示了一种实现分布式路由、物理主机接入的方法及装置,openstack网络节点及计算节点上安装分布式路由代理器,通过下发多级流表控制流量转发,为每个网络的虚拟网关分配特殊MAC,openstack为虚拟网关MAC分配的是以fa开头的MAC地址,特殊MAC以ea开头,其后字段相同。当本地及远端VM处于不同网段不同服务器时,流量做过分布式路由查找后将报文源MAC改写成特殊MAC,用以标记做过分布式路由的流量,将需进行跨服务器通信的流量引流到硬件交换机上转发。本发明基于OpenFlow多级流表实现分布式路由,避免单一节点性能瓶颈,实现物理主机即插即用,采用软硬结合突破大规模VM时转发性能瓶颈。
Description
技术领域
本发明涉及网络通信领域,尤其涉及一种实现分布式路由、物理主机接入的方法及装置。
背景技术
随着当今网络虚拟化技术的不断发展,软件定义网络(SoftwareDefinedNetwork,SDN)和云计算相结合的应用规模在不断地扩大,OpenStack作为虚拟云主机的管理平台之一,其关注度日益加大。伴随着虚拟主机的部署规模越来越大,OpenStack作为管理平台的瓶颈也日益凸显,例如转发性能,单节点故障,虚拟网络与物理网络的相互融合的需求。为解决上述问题,各个厂商提供了多种解决方案,下面以OpenStackNeutronDVR方案和OpenStackDragonFlow方案为例说明。
(1)OpenStackNeutronDVR方案分析
在OpenStack现有网络架构上,对于虚拟云主机(VirtualMachine,VM)跨网段的通信需求,无论是东西向(East-West,E-W)流量还是南北向(North-South,N-S)的流量都需要绕到虚拟路由器(VirtualRouter,VRouter)上,这样,在VM大量部署的情况下,网络节点(NetworkNode)上的转发性能将急剧下降,同时单一节点的故障率将对网络造成严重影响,虽然OpenStack支持了网络节点的高可用性集群(HighAvailable,HA)功能,但是随着规模的增大这种方式并不利于扩展。
自OpenStackJuno版本发布以来,对于上述情况提供了一种分布式路由(DistributedVirtualRouting,DVR)的解决方案,将原来只有在网络节点上的虚拟路由器分布式的部署在计算节点(ComputeNode)上,即将L3代理器(L3Agent)部署在每一个计算节点上,意在减小单一节点故障所导致的影响,避免单一节点转发性能下降问题。实现东西向流量通过DVR虚拟路由器完全分布式,至于南北向流量,对于分配了浮动IP(FloatingIP)的通过DVR虚拟路由器完全分布式,对于未分配到浮动IP的仍然绕行网络节点的虚拟路由器实现共享上网。其中东西向流量转发目前只支持vxlan模式。
这里,DVR虚拟路由器起在linux命名空间(Namespace)中,也就是说在每个计算节点上都要起一个linux命名空间,这样所有流量都需要走linux命名空间的协议栈,占用一部分资源,对性能造成浪费,而且实现技术复杂,不利于在生产环境中进行维护。
(2)OpenStackDragonFlow方案分析
由于OpenStackNeutronDVR实现的技术过于复杂,而且带来了不必要的额外开销,DragonFlow方案被提出,主旨解决在计算节点上无需建立linux命名空间的情况下,通过OpenFlow流表的形式,实现东西向流量的完全分布式。该方案将在网络节点上部署DragonFlowL3控制器,同时在计算节点上部署DragonFlowL2代理器,DragonFlowL3控制器通过开放式API(AESTAPI)调用Ryu控制器对每个节点进行流表的下发,流表的下发采用被动式,既首包数据报文会上送到DragonFlowL3控制器上,再由其决定流表下发的规则,该方案不对南北向流量产生影响。
这里,在大规模的情况下,数据报文被大量的送到DragonFlowL3控制器上,由于DragonFlowL3控制器并未支持高可用性集群方案,这样DragonFlowL3控制器将会成为转发性能的瓶颈。
综上所述,根据现有技术的分析,OpenStackNeutronDVR和OpenStackDragonFlow都能解决东西向流量的完全分布式需求,但是OpenStackNeutronDVR采用的是linux命名空间的方式,会产生资源和性能的浪费,而OpenStackDragonFlow会产生单一DragonFlowL3控制器的性能瓶颈,因此,第一个需要解决的问题是:避免采用过于复杂的技术实现东西向流量分布式的同时解决单一组件的性能瓶颈。
随着VM部署的规模越来越大,对于单一节点上建立的隧道(Tunnel)也随之越来越多,伴随而来的是服务器上转发性能越来越差。因此,第二个需要解决的问题是:突破大规模部署虚拟主机的情况下服务器上转发性能瓶颈,实现数据流量高性能转发。
以上两个方案都未涉及到虚拟网络和物理网络快速融合的方案,因此,第三个需要解决的问题是:实现物理主机即插即用,使得物理网络和虚拟网络方便扩展融合。
发明内容
本发明的目的在于提供一种实现分布式路由、物理主机接入的方法及装置。
为实现上述发明目的之一,本发明一实施方式提供一种实现分布式路由的方法,openstack的网络节点及计算节点上安装有分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述方法包括步骤:
S1:本地租户识别表识别本地VM和远端VM,若识别成功,则进入步骤S2,若识别失败,则丢弃;
S2:将报文送至本地二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤S3,若目的MAC为VM的MAC,则进入步骤S4;若目的MAC为广播或组播,则在对应网络内进行广播;
S3:将所述报文送至本地三层路由表中,判断报文的目的IP所属的VM与本地VM是否在同一服务器上,若为同一服务器,将目的MAC改写成远端MAC,进入步骤S5,若为不同服务器,将源MAC改写成特殊MAC,将目的MAC改写成远端VM的MAC,特殊MAC由网关MAC产生,进入步骤S6;
S4:判断报文的目的MAC所属的VM与本地VM是否在同一服务器上,若为同一服务器,则进入步骤S7,若为不同服务器,则进入步骤S8;
S5:利用报文的目的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S6:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S9,若识别失败,则丢弃所述报文;
S7:利用报文的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S8:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S10,若识别失败,则丢弃所述报文;
S9:将所述报文送至远端三层路由表中,利用报文的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S10:将所述报文送至远端二层转发表中,利用报文目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
作为本发明一实施方式的进一步改进,匹配及识别过程的参数还包括网络ID及/或vlan,其中,二层转发表的网络ID为分布式路由代理器为每个网络分配的本地ID,用于隔离不同网络内的二层流量,三层转发表的网络ID为分布式路由代理器为每个虚拟路由器分配的本地ID,用于隔离不同网络内的三层流量。
作为本发明一实施方式的进一步改进,步骤S1具体包括:
本地租户识别表匹配本地VM报文的端口信息及源MAC,若端口信息及源MAC均匹配成功,将本地分布式路由代理器为该网络分配的ID标记到报文上,进入步骤S2,若端口信息及/或源MAC匹配失败,则丢弃所述报文。
作为本发明一实施方式的进一步改进,当本地VM及远端VM位于不同服务器且服务器对应不同的交换机时,步骤“将所述报文送至远端VM”具体包括:所述报文由第一交换机的上联口通过隧道方式发送至第二交换机的上联口。
作为本发明一实施方式的进一步改进,当本地VM于所述第一交换机下创建成功时,对所述第一交换机的上联口下发隧道配置信息以及VNI与vlan的映射关系信息,所述vlan为租户对应的本地vlan,所述vlan在报文需要从服务器网卡发送到交换机上时被设置。
为实现上述发明目的之一,本发明一实施方式提供一种实现分布式路由的装置,包括安装于openstack的网络节点及计算节点上的分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述分布式路由代理器用于:
S1:本地租户识别表识别本地VM和远端VM,若识别成功,则进入步骤S2,若识别失败,则丢弃;
S2:将报文送至本地二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤S3,若目的MAC为VM的MAC,则进入步骤S4;若目的MAC为广播或组播,则在对应网络内进行广播;
S3:将所述报文送至本地三层路由表中,判断报文的目的IP所属的VM与本地VM是否在同一服务器上,若为同一服务器,将目的MAC改写成远端MAC,进入步骤S5,若为不同服务器,将源MAC改写成特殊MAC,将目的MAC改写成远端VM的MAC,特殊MAC由网关MAC产生,进入步骤S6;
S4:判断报文的目的MAC所属的VM与本地VM是否在同一服务器上,若为同一服务器,则进入步骤S7,若为不同服务器,则进入步骤S8;
S5:利用报文的目的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S6:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S9,若识别失败,则丢弃所述报文;
S7:利用报文的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S8:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S10,若识别失败,则丢弃所述报文;
S9:将所述报文送至远端三层路由表中,利用报文的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S10:将所述报文送至远端二层转发表中,利用报文目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
为实现上述发明目的之一,本发明一实施方式提供一种实现物理主机接入的方法,openstack的网络节点及计算节点上安装有分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述方法包括步骤:
s1:租户识别表识别本地VM,若识别成功,则进入步骤s2,若识别失败,则丢弃;
s2:将报文送至二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤s3,若目的MAC不为网关MAC,匹配该网络内通配的二层转发表,进入步骤s4;
s3:将所述报文送至三层路由表中,匹配默认路由将报文送往虚拟路由器,由虚拟路由器发送ARP报文请求物理主机的MAC,进入步骤s4,若匹配失败,则丢弃所述报文;
s4:将所述报文送至物理主机接入的交换机上,所述交换机通过识别VNI映射成本地vlan,再利用目的MAC进行匹配,若匹配成功,则接收所述报文,实现物理主机接入,若匹配失败,则丢弃所述报文。
作为本发明一实施方式的进一步改进,所述报文由第一交换机的上联口通过隧道送至第二交换机的上联口,所述第一交换机与虚拟网络服务器相连,所述第二交换机与物理主机或虚拟路由器相连。
作为本发明一实施方式的进一步改进,当本地VM于所述第一交换机下创建成功时,对所述第一交换机的上联口下发隧道配置信息以及VNI与vlan的映射关系信息。
为实现上述发明目的之一,本发明一实施方式提供一种实现物理主机接入的装置,包括安装于openstack的服务器的网络节点及计算节点上的分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述分布式路由代理器用于:
s1:租户识别表识别本地VM,若识别成功,则进入步骤s2,若识别失败,则丢弃;
s2:将报文送至二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤s3,若目的MAC不为网关MAC,匹配该网络内通配的二层转发表,进入步骤s4;
s3:将所述报文送至三层路由表中,匹配默认路由将报文送往虚拟路由器,由虚拟路由器发送ARP报文请求物理主机的MAC,进入步骤s4,若匹配失败,则丢弃所述报文;
s4:将所述报文送至物理主机接入的交换机上,所述交换机通过识别VNI映射成本地vlan,再利用目的MAC进行匹配,若匹配成功,则接收所述报文,实现物理主机接入,若匹配失败,则丢弃所述报文。
与现有技术相比,本发明的有益效果在于:本发明基于OpenFlow多级流表实现分布式路由,本发明的计算节点及网络节点上均设置有分布式路由代理器,避免了单一节点性能瓶颈,解决了东西向流量的分布式路由功能,本发明还实现物理主机即插即用,使得物理网络和虚拟网络方便扩展融合,采用软件和硬件转发芯片相互结合的方法突破大规模部署虚拟主机的情况下服务器上转发性能瓶颈,实现数据流量高性能转发。
附图说明
图1是本发明一实施方式的网络结构示意图;
图2是本发明一实施方式的实现分布式路由的方法流程图;
图3是本发明一实施方式的实现分布式路由的方法的一示例结构框图;
图4是本发明另一实施方式的网络结构图;
图5是本发明一实施方式的实现物理主机接入的方法流程图。
具体实施方式
以下将结合附图所示的具体实施方式对本发明进行详细描述。但这些实施方式并不限制本发明,本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本发明的保护范围内。
如图1所示,为本发明一实施方式的网络结构图,所述网络主要包括了Neutron插件(TorPlugin)3,云管理器(CloudManager)5a,交换机云代理器(CloudAgent)6a,分布式路由代理器(DVRAgent)8a。
插件3作为ML2插件2的驱动之一,被安装在控制节点(ControllerNode)上,其主要作用是通过Json-rpc4和云管理器5a建立连接,使云管理器5a能够对OpenStackNeutron数据库(datebase,DB)的数据进行查询,同时OpenStackNeutron数据库(datebase,DB)发生变化时也能通知到云管理器5a,同步的数据主要包括租户信息(tenant)/网络信息(network)/子网信息(subnet)/路由器信息(router)/端口信息(port)。
云管理器5a作为核心管理器5的管理者,被安装在控制节点上。云管理器5a实质为一个微型的交换机和服务器的集中式管理器,只具有消息透传的功能。云管理器5a通过Socket11和交换机云代理器6a、分布式路由代理器8a建立连接,从而将通过Json-rpc4收集到Neutron数据库的数据,组装成特定的格式包发往交换机云代理器6a、分布式路由代理器8a,同时可以在云管理器5a上做些全局属性的统一配置管理。
具体的,当网络为Overlay网络时,OpenStack云管理平台于该Overlay网络中创建一个VM,云管理器5a获取到该VM的信息后通过查找Neutron数据库,得到该VM所属的网络信息,根据网络信息就可以得到OpenStack云管理平台为该Overlay网络所分配的VNI,VNI可作为该Overlay网络的识别号。云管理器5a为该VM分配localvlan(交换机和网络分配一个localvlan,也就是说同一个网络在不同交换机上可能localvlan是不一致的),该localvlan与该VNI之间具有映射关系,云管理器5a将这种映射关系分发给交换机云代理器6a及分布式路由代理器8a。
当网络为Vlan网络时,OpenStack云管理平台于该Vlan网络中创建一个VM,云管理器5a获取到该VM的信息后通过查找Neutron数据库,得到该VM所属的网络信息,根据网络信息就可以得到OpenStack云管理平台为该VM所分配的vlan信息,云管理器5a将vlan信息分发给交换机云代理器6a及分布式路由代理器8a。
交换机云代理器6a作为交换机6的代理者,被安装在交换机6上,交换机云代理器6a负责管理各个交换机6的配置下发功能。交换机6可以通过Lldp协议发现下联的服务器8接口。
当网络为Overlay网络时,OpenStack云管理平台于该Overlay网络中创建一个VM,交换机云代理器6a通过云管理器5a获取到在该交换机6上VM所在网络的VNI和vlan的映射关系,当VM在该交换机6下挂的服务器8上创建成功时,对交换机6的上联口下发信息10,包括隧道配置信息以及VNI和Vlan的映射关系信息,对交换机6的下联口下发该vlan允许通过的配置信息。
当网络为Vlan网络时,OpenStack云管理平台于该Vlan网络中创建一个VM,交换机云代理器6a通过云管理器5a获取到在该交换机6上VM所在网络的vlan信息,当VM在该交换机6下挂的服务器8上创建成功时,对交换机6的下联口均下发该vlan允许通过的配置信息。上联口统一配置成允许所有vlan通过的配置信息。
分布式路由代理器8a作为服务器8的代理者,被安装在计算节点及网络节点上,分布式路由代理器8a负责管理各个节点上的流表和控制流量转发的功能。
具体的,网络节点和计算节点上所下发的转发流表都由各个节点上的分布式路由代理器8a进行计算和管理的,为了替代linux命名空间的复杂度,分布式路由代理器8a采用多级流表的方式实现东西向流量的分布式,由于多级流表的功能分布在各个节点上,从而能够避免了单一节点的性能瓶颈。分布式路由代理器8a在接收到云管理器5a的数据后,采用主动式下发流表的方式对节点的流量进行管理。
如图2所示,为本发明一实施方式的实现分布式路由的方法,openstack的网络节点及计算节点上安装有分布式路由代理器8a,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述方法包括步骤:
S1:本地租户识别表识别本地VM和远端VM,若识别成功,则进入步骤S2,若识别失败,则丢弃;
S2:将报文送至本地二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤S3,若目的MAC为VM的MAC,则进入步骤S4;若目的MAC为广播或组播,则在对应网络内进行广播;
S3:将所述报文送至本地三层路由表中,判断报文的目的IP所属的VM与本地VM是否在同一服务器上,若为同一服务器,将目的MAC改写成远端MAC,进入步骤S5,若为不同服务器,将源MAC改写成特殊MAC,将目的MAC改写成远端VM的MAC,特殊MAC由网关MAC产生,进入步骤S6;
S4:判断报文的目的MAC所属的VM与本地VM是否在同一服务器上,若为同一服务器,则进入步骤S7,若为不同服务器,则进入步骤S8;
S5:利用报文的目的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S6:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S9,若识别失败,则丢弃所述报文;
S7:利用报文的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S8:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S10,若识别失败,则丢弃所述报文;
S9:将所述报文送至远端三层路由表中,利用报文的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S10:将所述报文送至远端二层转发表中,利用报文目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
需要说明的是,上述步骤仅为本实施方式的示意步骤,顺序不以此为限,可依实际情况而定。
在本实施方式中,分布式路由代理器8a为每个网络的网关分配一个特殊MAC,OpenStack云管理平台中对网关MAC分配的范围是以fa为开头的一段MAC地址,这里,特殊MAC以ea开头,其后字段相同。当本地VM及远端VM处于不同网段时,即此时流量需要跨交换机转发,本实施方式利用多级流表将源MAC改写成特殊MAC,以此模拟经过虚拟路由器的过程,如此,降低了虚拟路由器的负担,避免了单一节点性能瓶颈,解决了东西向流量的分布式路由功能;另外,网关MAC全局可见,所以对于识别到ea开头的特殊MAC后,可容易识别出不同网段的数据流量。
在本实施方式中,步骤S1具体包括:本地租户识别表匹配本地VM报文的端口信息及源MAC,若端口信息及源MAC均匹配成功,将本地分布式路由代理器为该网络分配的ID标记到报文上,进入步骤S2,若端口信息及/或源MAC匹配失败,则丢弃所述报文。这里,租户识别表采用端口信息及源MAC的双重信息进行识别,可防止MAC欺骗。
在本实施方式中,继续参图1,多个交换机6的上联口之间配置有隧道,在Overlay网络场景下,OpenStack云管理平台在每个网络创建的时候会为其分配一个VNI,该VNI可以在隧道中作为识别号使用。当本地VM及远端VM位于不同服务器且服务器对应不同的交换机时,本地VM的原始报文携带vlan从服务器8网卡送出,从服务器8网卡送出的原始报文被送至与其连接的交换机6上,交换机6根据vlan与VNI的映射关系将原始报文进行加密封装并将封装好的隧道报文通过隧道送到另一个交换机6上,另一个交换机6通过vlan与VNI的映射关系进行解密而得到原始报文。这里,一方面,通过vlan与VNI的映射关系及隧道的设置实现了报文传送的加密解密过程,提高了传送过程的可靠性及封装性;另一方面,VNI的数量庞大,避免vlan数量上的限制;再一方面,将交换机6及隧道结合,采用软件和硬件转发芯片相互结合的方法突破大规模部署VM的情况下服务器上转发性能瓶颈,实现数据流量高性能转发。
在本实施方式中,匹配及识别过程的参数还包括网络ID及/或Vlan等等,可依据实际流表形式而定。
下面以具体示例来说明本发明实现分布式路由的方法。
多级流表结构分为:第一级table=0:用于租户识别表,第二级table=1:用于处理Flat网络的NORMAL表,第三级table=2:用于处理物理机接入的转发表,第四级table=7:用于处理虚拟网络内的二层转发表,第五级table=8:用于处理虚拟网络内的三层转发表,第六级table=9:用于处理虚拟网络内的广播表。Group流表用于对广播的支持。
以下在Overlay网络模式下介绍四种应用场景下实现分布式路由的方法。
(1)应用场景分析1:同网段同服务器内VM通信。具体包括:
对于本地VM,租户识别表采用in_port+src_mac进行唯一识别,可以防止MAC欺骗,具体流表形式为:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
租户识别表将识别到的本地VM的流量送本地的二层转发表table=7。
在table=7的本地二层转发表中,对于ARP报文的处理:因为是同网段,所以目的MAC为广播地址,目的IP地址为需要进行通信的远端VM的IP地址,具体流表形式为:
"table=7,priority=100,dl_dst=ff:ff:ff:ff:ff:ff,actions=goto_table:9"
二层转发表将识别到的广播流量送到广播表table=9,广播表采用meta_id进行唯一识别,该meta_id为分布式路由代理器8a为该网络所分配的网络ID,所以广播流量被限制在了一个网络内,具体流表形式为:
"table=9,priority=100,metadata=meta_id,actions=group:meta_id"
"group_id=meta_id,type=all,bucket=strip_vlan,output:ofport”
在table=7的本地二层转发表中,对于数据报文的处理:对于同网段内同服务器8内的VM的流量转发采用meta_id+vlan+dst_mac进行唯一识别,该meta_id为分布式路由代理器8a为该网络所分配的网络ID,可以对不用网段的流量进行隔离。具体流表形式为:
"table=7,priority=1000,metadata=meta_id,dl_vlan=vid,dl_dst=vm_mac,actions=strip_vlan,output:ofport"
(2)应用场景分析2:同网段不同服务器内VM通信。具体包括:
对于本地VM,租户识别表采用in_port+src_mac进行唯一识别,可以防止MAC欺骗,具体流表形式为:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
租户识别表将识别到的本地VM的流量送本地的二层转发表table=7。
在table=7的本地二层转发表中,对于ARP报文的处理:因为是同网段,所以目的MAC为广播地址,目的IP地址为需要进行通信的远端VM的IP地址,具体流表形式为:
"table=7,priority=100,dl_dst=ff:ff:ff:ff:ff:ff,actions=goto_table:9"
二层转发表将识别到的广播流量送到广播表table=9,广播表采用meta_id进行唯一识别,该meta_id为分布式路由代理器8a为该网络所分配的网络ID,广播报文携带vlan从服务器8网卡送出,从服务器8网卡送出去的报文被送到交换机6上,交换机6上根据vlan和隧道VNI的映射关系,从交换机6上联口将报文封装并送到远端,即报文由一个交换机6通过隧道送至另一交换机6。具体流表形式为:
"table=9,priority=100,metadata=meta_id,actions=group:meta_id"
"group_id=meta_id,type=all,bucket=output:external”
在table=7的本地二层转发表中,对于数据报文的处理:对于同网段不同服务器内的VM的流量转发采用meta_id+vlan+dst_mac进行唯一识别,该meta_id为分布式路由代理器8a为该网络所分配的网络ID,可以对不用网段的流量进行隔离。具体流表形式为:
"table=7,priority=1000,metadata=meta_id,dl_vlan=vid,dl_dst=vm_mac,actions=output:external"
对于远端的VM来说,由于位于不同服务器8,租户识别表采用vlan+src_mac进行唯一识别,具体流表形式为:
"table=0,priority=1000,dl_vlan=vid,dl_src=vm_mac,actions=write_metadata:meta_id,goto_table:7"
这里,meta_id为远端分布式路由代理器8a为该网络所分配的网络ID。
当报文到达远端VM的二级转发表(table=7)中时,利用报文中的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
(3)应用场景分析3:不同网段同服务器内VM通信。具体包括:
对于本地VM,租户识别表采用in_port+src_mac进行唯一识别,可以防止MAC欺骗,具体流表形式为:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
租户识别表将识别到的本地VM的流量送本地的二层转发表table=7。
在table=7的本地二层转发表中,对于ARP报文的处理:因为是不同网段,所以目的MAC为广播地址,目的IP地址为该网段网关(Gateway)的IP地址,对网关进行ARP代理后,ARP流量将不再绕行虚拟路由器(VRouter)。具体流表形式为:
"table=7,priority=500,metadata=meta_id,dl_type=0x0806,nw_dst=gateway_ip,
actions=strip_vlan,move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:gateway_mac->dl_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:gateway_mac->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:gateway_ip->arp_spa,in_port"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
在table=7的本地二层转发表中,对于数据报文的处理:对于不同网段同服务器内的VM的流量转发采用meta_id+vlan+gw_mac进行唯一识别。具体流表形式为:
"table=7,priority=2000,metadata=meta_id,ip,dl_vlan=vid,dl_dst=gateway_mac,actions=write_metadata:meta_id,goto_table:8"
这里,meta_id会被改写,该meta_id为分布式路由代理器8a为该VM所在的路由器所分配的网络ID。
二层转发表将识别到的本地VM需要做路由的流量送本地的三层转发表table=8。
对于不同网段同服务器内的VM的流量转发采用meta_id+dst_ip进行唯一识别,该meta_id为分布式路由代理器8a为该VM所在的路由器所分配的网络ID。具体流表形式为:
"table=8,priority=1000,metadata=meta_id,ip,nw_dst=dst_ip,vlan_vid=0x1000/0x1000,actions=strip_vlan,set_field:vm_mac->dl_dst,output:ofport"
(4)应用场景分析4:不同网段不同服务器内VM通信。具体包括:
对于本地VM,租户识别表采用in_port+src_mac进行唯一识别,可以防止MAC欺骗,具体流表形式为:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
租户识别表将识别到的本地VM的流量送本地的二层转发表table=7。
在table=7的本地二层转发表中,对于ARP报文的处理:因为是不同网段,所以目的MAC为广播地址,目的IP地址为该网段网关(Gateway)的IP地址,对网关进行ARP代理后,ARP流量将不再绕行虚拟路由器(VRouter)。具体流表形式为:
"table=7,priority=500,metadata=meta_id,dl_type=0x0806,nw_dst=gateway_ip,
actions=strip_vlan,move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:gateway_mac->dl_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:gateway_mac->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:gateway_ip->arp_spa,in_port"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
在table=7的本地二层转发表中,对于数据报文的处理:对于不同网段不同服务器内的VM的流量转发采用meta_id+vlan+gw_mac进行唯一识别。具体流表形式为:
"table=7,priority=2000,metadata=meta_id,ip,dl_vlan=vid,dl_dst=gateway_mac,actions=write_metadata:meta_id,goto_table:8"
这里meta_id会被改写,该meta_id为分布式路由代理器8a为该VM所在的路由器所分配的网络ID。
二层转发表将识别到的本地VM需要做路由的流量送本地的三层转发表table=8。
对于不同网段不同服务器内的VM的流量转发采用meta_id+dst_ip进行唯一识别,该meta_id为分布式路由代理器8a为该VM所在的路由器所分配的网络ID。具体流表形式为:
"table=8,priority=1000,metadata=meta_id,ip,nw_dst=dst_ip,vlan_vid=0x1000/0x1000,actions=set_field:router_mac->dl_src,set_field:vm_mac->dl_dst,mod_vlan_vid:vid,output:external"
对于远端的VM来说,租户识别表采用vlan+src_mac进行唯一识别,具体流表形式为:
"table=0,priority=1000,dl_vlan=vid,dl_src=router_mac,actions=write_metadata:meta_id,goto_table:8"
这里,该meta_id为分布式路由代理器8a为该VM所在的路由器所分配的网络ID。
当报文到达远端VM的三级转发表(table=8)中时,利用报文中的目的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。这里,当匹配到源MAC为特殊MAC(dl_src=router_mac)时,判断此时报文已经做过分布式路由,目的MAC已经发生改变,此时进入三层转发表利用目的IP地址进行匹配。
其中ofport为VM挂载在开放虚拟交换机(OpenvSwitch)上的端口号,vm_mac为VM的MAC地址,vid为该VM所属网络对应的Localvlan,gateway_mac为VM网关MAC地址,table=0中的meta_id为分布式路由代理器8a为每个网络所分配用于隔离网络流量的ID号,table=8中的meta_id为分布式路由代理器8a为每个路由器所分配用于隔离不在同一虚拟路由器的流量。router_mac为分布式路由代理器8a为每个VM网关分配的特殊MAC地址,external为服务器的网卡。
具体的,如图3所示,为应用场景分析4中不同网段不同服务器内VM通信的一具体示例。两个服务器8分别连接两个不同的交换机6,为方便说明,第一服务器8连接第一交换机6,第二服务器8’连接第二交换机6’,第一服务器8内本地VM的IP地址为1.1.1.1,第二服务器8’内远端VM的IP地址为2.2.2.2,即此时本地VM及远端VM处于不同网段。当本地VM需要发送报文至远端VM时,查询报文中所携带的信息得知本地VM的端口信息(第一服务器8与第一交换器6的通信端口)为Port_mac:1.1.1(源MAC),Port_ip:1.1.1.1,租户识别表识别成功后,分布式路由代理器8a识别到远端VM与本地VM位于不同网段,即识别到Dst_ip:2.2.2.2,此时通过多级流表将源MAC改写成特殊MAC,即Src_mac:route1_mac,如此,便模拟了不同网段报文传送时需经过虚拟路由器的过程,第一服务器8将改写后的报文由第一服务器8网关发送至对应的第一交换机6中,第一交换机6将报文封装后通过隧道送至第二交换机6’,第二交换机6’解密后将报文送至其下挂的第二服务器8’中,第二服务器8’内的分布式路由代理器8a’的多级流表匹配到源MAC为特殊MAC时即判断此时的报文已经做过流量分布式,目的MAC已经改变,需要进行IP地址的匹配,而后在多级流表的三层转发表中进行IP地址匹配,若匹配成功,则接收报文,若匹配失败,则丢弃报文。上述说明以第一服务器8中的报文发送至第二服务器8’为例,当然,在其他实施例中,也可由第二服务器8’发送至第一服务器8,类似的,此时利用多级流表可将源MAC改写成特殊MAC,即Src_mac:route2_mac,如此可模拟流量分布式,其他步骤可参考上述说明,在此不再赘述。
本发明一实施方式还提供一种实现分布式路由的装置,包括安装于openstack的网络节点及计算节点上的分布式路由代理器8a,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述分布式路由代理器8a用于:
S1:本地租户识别表识别本地VM和远端VM,若识别成功,则进入步骤S2,若识别失败,则丢弃;
S2:将报文送至本地二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤S3,若目的MAC为VM的MAC,则进入步骤S4;若目的MAC为广播或组播,则在对应网络内进行广播;
S3:将所述报文送至本地三层路由表中,判断报文的目的IP所属的VM与本地VM是否在同一服务器上,若为同一服务器,将目的MAC改写成远端MAC,进入步骤S5,若为不同服务器,将源MAC改写成特殊MAC,将目的MAC改写成远端VM的MAC,特殊MAC由网关MAC产生,进入步骤S6;
S4:判断报文的目的MAC所属的VM与本地VM是否在同一服务器上,若为同一服务器,则进入步骤S7,若为不同服务器,则进入步骤S8;
S5:利用报文的目的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S6:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S9,若识别失败,则丢弃所述报文;
S7:利用报文的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S8:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S10,若识别失败,则丢弃所述报文;
S9:将所述报文送至远端三层路由表中,利用报文的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S10:将所述报文送至远端二层转发表中,利用报文目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
在本实施方式中,分布式路由代理器8a为每个网络的网关分配一个特殊MAC,OpenStack云管理平台中对网关MAC分配的范围是以fa为开头的一段MAC地址,这里,特殊MAC以ea开头,其后字段相同。当本地VM及远端VM处于不同网段时,即此时流量需要跨交换机转发,本实施方式利用多级流表将源MAC改写成特殊MAC,以此模拟经过虚拟路由器的过程,如此,降低了虚拟路由器的负担,避免了单一节点性能瓶颈,解决了东西向流量的分布式路由功能;另外,网关MAC全局可见,所以对于识别到ea开头的特殊MAC后,可容易识别出不同网段的数据流量。
本实施方式的实现分布式路由的装置的其他说明可参考上述实现分布式路由的方法中的说明,在此不再赘述。
参图4,为本发明另一实施方式的网络结构图,图4与图1中的网络结构类似,相同的部件采用相同的标号,相同部件的功能可参考前述说明,在此不再赘述。图4中还包括物理交换机7及物理主机9,物理主机9连在物理交换机7下,物理交换机7可与其他交换机6进行交互。
虚拟网络和物理网络的虚实结合一直以来是麻烦的问题,OpenStack云管理平台所管理的虚拟主机无法获取到物理网络的任何信息,同时也就无法自动建立隧道完成通信。本实施方式通过多级流表的实现方式结合物理交换机的功能实现了一种可靠而且便捷的物理网络隧道接入的方法。交换机6与物理交换机7的上联口之间配置有隧道,在Overlay网络场景下,OpenStack云管理平台在每个网络创建的时候会为其分配一个VNI,该VNI可以在隧道中作为识别号使用。
结合图5,在本发明一实施方式的实现物理主机接入的方法中,openstack的网络节点及计算节点上安装有分布式路由代理器8a,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述方法包括步骤:
s1:租户识别表识别本地VM,若识别成功,则进入步骤s2,若识别失败,则丢弃;
s2:将报文送至二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤s3,若目的MAC不为网关MAC,匹配该网络内通配的二层转发表,进入步骤s4;
s3:将所述报文送至三层路由表中,匹配默认路由将报文送往虚拟路由器,由虚拟路由器发送ARP报文请求物理主机的MAC,进入步骤s4,若匹配失败,则丢弃所述报文;
s4:将所述报文送至物理主机接入的交换机上,所述交换机通过识别VNI映射成本地vlan,再利用目的MAC进行匹配,若匹配成功,则接收所述报文,实现物理主机接入,若匹配失败,则丢弃所述报文。
需要说明的是,上述步骤仅为本实施方式的示意步骤,顺序不以此为限,可依实际情况而定。
在本实施方式中,通过在网络节点及计算节点均设置分布式路由代理器8a,利用分布式路由代理器8a多级流表,可以实现物理主机9即插即用,使得物理网络和虚拟网络方便扩展融合。
这里,需要说明的是,步骤s2中,由于openstack的虚拟网络中并不知道物理网络中任意一个物理主机的MAC地址及IP地址,所以在二层转发表中,匹配一条该网络内通配的二层转发表。步骤s3中,由于openstack的虚拟网络中并不知道物理网络中任意一个物理主机的MAC地址及IP地址,无法通过多级流表进行精确的路由查找,所以将匹配默认路由将报文送往虚拟路由器。
本实施方式的实现物理主机接入的方法的其他说明可参考前述实现分布式路由的方法的说明,例如物理交换机7与交换机6之间也可通过隧道连接等等,具体说明不再赘述。
下面以具体示例来说明本发明物理主机接入的方法。
多级流表结构分为:第一级table=0:用于租户识别表,第二级table=1:用于处理Flat网络的NORMAL表,第三级table=2:用于处理物理机接入的转发表,第四级table=7:用于处理虚拟网络内的二层转发表,第五级table=8:用于处理虚拟网络内的三层转发表,第六级table=9:用于处理虚拟网络内的广播表。Group流表用于对广播的支持。
以下在Overlay网络模式下介绍两种应用场景下实现分布式路由的方法。
(1)应用场景分析1:同网段物理主机及虚拟服务器通信。具体包括:
对于本地VM,租户识别表采用in_port+src_mac进行唯一识别,可以防止MAC欺骗,具体流表形式为:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
租户识别表将识别到的本地VM的流量送本地的二层转发表table=7。
在table=7的本地二层转发表中,对于ARP报文的处理:因为是同网段,所以目的MAC为广播地址,目的IP地址为需要进行通信物理机的IP地址,具体流表形式为:
"table=7,priority=100,dl_dst=ff:ff:ff:ff:ff:ff,actions=goto_table:9"
二层转发表将识别到的广播流量送到广播表table=9,广播表采用meta_id进行唯一识别,报文携带vlan从服务器8网卡送出。从服务器8网卡送出去的报文被送到交换机6上,交换机6上根据vlan和隧道VNI的映射关系,从上联口将报文封装到远端,即报文由交换机6通过隧道送至物理交换机7上,此时报文封装到物理网络(包括物理交换机7及物理主机9)上。具体流表形式为:
"table=9,priority=100,metadata=meta_id,actions=group:meta_id"
"group_id=meta_id,type=all,bucket=output:external”
在table=7的本地二层转发表中,对于数据报文的处理:对于同网段不同服务器内的VM的流量转发采用meta_id+vlan进行唯一识别,可以对不用网段的流量进行隔离。服务器8网卡送出去的报文被送到交换机6上,交换机6上根据vlan和隧道VNI的映射关系,从上联口将报文封装到远端,即报文由交换机6通过隧道送至物理交换机7上,此时报文封装到物理网络(包括物理交换机7及物理主机9)上。具体流表形式为:
"table=7,priority=10,metadata=meta_id,dl_vlan=vid,actions=output:external"
物理交换机7解析出VNI后找到和物理主机9的vlan的映射关系,将报文从下联口发回到物理主机9上,对于远端的物理主机9来说,VM因为无法获取到物理主机9内对应VM的MAC地址(因为此时物理主机9内仍可能部署多个VM),虚拟网络对于回发的报文的处理在租户识别表将采用vlan进行唯一识别,具体流表形式为:
"table=0,priority=10,dl_vlan=vid,actions=write_metadata:meta_id,goto_table:2"
"table=2,priority=10,dl_vlan=vid,actions=goto_table:7"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
当报文到达二级转发表(table=7)中时,利用报文中的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
(2)应用场景分析2:不同网段物理主机及虚拟服务器通信。具体包括:
对于本地VM,租户识别表采用in_port+src_mac进行唯一识别,可以防止MAC欺骗,具体流表形式为:
"table=0,priority=1000,dl_vlan=0xffff,in_port=ofport,dl_src=vm_mac,actions=mod_vlan_vid:vid,write_metadata:meta_id,goto_table:7"
租户识别表将识别到的本地VM的流量送本地的二层转发表table=7。
在table=7的本地二层转发表中,对于ARP报文的处理:因为是不同网段,所以目的MAC为广播地址,目的IP地址为该网段网关(Gateway)的IP地址,对网关进行ARP代理后,ARP流量将不再绕行虚拟路由器(VRouter)。具体流表形式为:
"table=7,priority=500,metadata=meta_id,dl_type=0x0806,nw_dst=gateway_ip,actions=strip_vlan,move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:gateway_mac->dl_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:gateway_mac->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:gateway_ip->arp_spa,in_port"
在table=7的本地二层转发表中,对于数据报文的处理:对于不同网段不同服务器内的VM的流量转发采用meta_id+vlan+gw_mac进行唯一识别。具体流表形式为:
"table=7,priority=2000,metadata=meta_id,ip,dl_vlan=vid,dl_dst=gateway_mac,actions=write_metadata:meta_id,goto_table:8"
二层转发表将识别到的本地VM需要做路由的流量送本地的三层转发表table=8。
对于不同网段不同服务器内的VM的流量转发采用meta_id+dst_ip进行唯一识别。由于物理主机9的IP地址对于虚拟网络来说同样是不可见的,所以将报文送往虚拟路由器,具体流表形式为:
"table=8,priority=500,metadata=meta_id,dl_dst=gateway_mac,ip,vlan_vid=0x1000/0x1000,actions=strip_vlan,output:external/ofport”
这里,由虚拟服务器(VRouter)发送ARP报文请求物理主机9的MAC地址,从而将报文发往物理交换机7,物理交换机7解析出VNI后找到和物理主机9的vlan的映射关系,将报文从下联口发回到物理主机9上。也就是说,跨网段的虚拟网络与物理网络的虚实结合需要绕行虚拟服务器(VRouter)。
对于远端的物理主机9来说,VM因为无法获取到物理主机9内对应VM的MAC地址(因为此时物理主机9内仍可能部署多个VM),所以租户识别表采用vlan进行唯一识别,具体流表形式为:
"table=0,priority=10,dl_vlan=vid,actions=write_metadata:meta_id,goto_table:2"
"table=2,priority=500,metadata=meta_id,dl_src=gateway_mac,ip,vlan_vid=0x1000/0x1000,actions=strip_vlan,output:goto_table7"
这里,meta_id为分布式路由代理器8a为该网络所分配的网络ID。
当报文到达二级转发表(table=7)中时,利用报文中的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
其中ofport为VM挂载在开放虚拟交换机(OpenvSwitch)上的端口号,vm_mac为VM的MAC地址,vid为该VM所属网络对应的Localvlan,gateway_mac为VM网关MAC地址,table=0中的meta_id为分布式路由代理器8a为每个网络所分配用于隔离网络流量的ID号,table=7中的meta_id为分布式路由代理器8a为每个路由器所分配用于隔离不在同一虚拟路由器的流量。router_mac为分布式路由代理器8a为每个VM网关分配的特殊MAC地址,external为服务器的网卡。
本发明一实施方式还提供一种实现物理主机接入的装置,包括安装于openstack的服务器的网络节点及计算节点上的分布式路由代理器8a,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述分布式路由代理器8a用于:
s1:租户识别表识别本地VM,若识别成功,则进入步骤s2,若识别失败,则丢弃;
s2:将报文送至二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤s3,若目的MAC不为网关MAC,匹配该网络内通配的二层转发表,进入步骤s4;
s3:将所述报文送至三层路由表中,匹配默认路由将报文送往虚拟路由器,由虚拟路由器发送ARP报文请求物理主机的MAC,进入步骤s4,若匹配失败,则丢弃所述报文;
s4:将所述报文送至物理主机接入的交换机上,所述交换机通过识别VNI映射成本地vlan,再利用目的MAC进行匹配,若匹配成功,则接收所述报文,实现物理主机接入,若匹配失败,则丢弃所述报文。
在本实施方式中,通过在网络节点及计算节点均设置分布式路由代理器8a,利用分布式路由代理器8a多级流表,可以实现物理主机即插即用,使得物理网络和虚拟网络方便扩展融合。
本实施方式的实现物理主机接入的装置的其他说明可参考上述实现物理主机接入的方法中的说明,在此不再赘述。
综上所述,本发明openstack的网络节点及计算节点上安装有分布式路由代理器,通过逻辑运算,控制openvswitch,对其下发多级流表控制流量转发,本发明为每个网络的虚拟网关分配特殊MAC,openstack对虚拟网关MAC分配的范围是以fa为开头的MAC地址,特殊MAC以ea开头,其后字段相同。当本地VM及远端VM处于不同网段不同服务器时,利用多级流表在流量做过分布式路由查找后,将VM的源MAC改写成该网络所分配的特殊MAC,以用来标记做过分布式路由的流量,分布式路由代理器会将需要进行跨服务器通信的流量引流到硬件交换机上进行硬件转发。本发明基于OpenFlow多级流表实现分布式路由,避免了单一节点性能瓶颈,解决了东西向流量的分布式路由功能,实现物理主机即插即用,采用软件和硬件转发芯片相互结合的方法突破大规模部署VM的情况下服务器转发性能瓶颈,实现数据流量高性能转发。
应当理解,虽然本说明书按照实施方式加以描述,但并非每个实施方式仅包含一个独立的技术方案,说明书的这种叙述方式仅仅是为清楚起见,本领域技术人员应当将说明书作为一个整体,各实施方式中的技术方案也可以经适当组合,形成本领域技术人员可以理解的其他实施方式。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明,它们并非用以限制本发明的保护范围,凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
Claims (10)
1.一种实现分布式路由的方法,其特征在于openstack的网络节点及计算节点上安装有分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述方法包括步骤:
S1:本地租户识别表识别本地VM和远端VM,若识别成功,则进入步骤S2,若识别失败,则丢弃;
S2:将报文送至本地二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤S3,若目的MAC为VM的MAC,则进入步骤S4;若目的MAC为广播或组播,则在对应网络内进行广播;
S3:将所述报文送至本地三层路由表中,判断报文的目的IP所属的VM与本地VM是否在同一服务器上,若为同一服务器,将目的MAC改写成远端MAC,进入步骤S5,若为不同服务器,将源MAC改写成特殊MAC,将目的MAC改写成远端VM的MAC,特殊MAC由网关MAC产生,进入步骤S6;
S4:判断报文的目的MAC所属的VM与本地VM是否在同一服务器上,若为同一服务器,则进入步骤S7,若为不同服务器,则进入步骤S8;
S5:利用报文的目的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S6:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S9,若识别失败,则丢弃所述报文;
S7:利用报文的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S8:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S10,若识别失败,则丢弃所述报文;
S9:将所述报文送至远端三层路由表中,利用报文的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S10:将所述报文送至远端二层转发表中,利用报文目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
2.根据权利要求1所述的实现分布式路由的方法,其特征在于,匹配及识别过程的参数还包括网络ID及/或vlan,其中,二层转发表的网络ID为分布式路由代理器为每个网络分配的本地ID,用于隔离不同网络内的二层流量,三层转发表的网络ID为分布式路由代理器为每个虚拟路由器分配的本地ID,用于隔离不同网络内的三层流量。
3.根据权利要求1所述的实现分布式路由的方法,其特征在于步骤S1具体包括:
本地租户识别表匹配本地VM报文的端口信息及源MAC,若端口信息及源MAC均匹配成功,将本地分布式路由代理器为该网络分配的ID标记到报文上,进入步骤S2,若端口信息及/或源MAC匹配失败,则丢弃所述报文。
4.根据权利要求1所述的实现分布式路由的方法,其特征在于,当本地VM及远端VM位于不同服务器且服务器对应不同的交换机时,步骤“将所述报文送至远端VM”具体包括:所述报文由第一交换机的上联口通过隧道方式发送至第二交换机的上联口。
5.根据权利要求4所述的实现分布式路由的方法,其特征在于,当本地VM于所述第一交换机下创建成功时,对所述第一交换机的上联口下发隧道配置信息以及VNI与vlan的映射关系信息,所述vlan为租户对应的本地vlan,所述vlan在报文需要从服务器网卡发送到交换机上时被设置。
6.一种实现分布式路由的装置,其特征在于包括:
安装于openstack的网络节点及计算节点上的分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述分布式路由代理器用于:
S1:本地租户识别表识别本地VM和远端VM,若识别成功,则进入步骤S2,若识别失败,则丢弃;
S2:将报文送至本地二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤S3,若目的MAC为VM的MAC,则进入步骤S4;若目的MAC为广播或组播,则在对应网络内进行广播;
S3:将所述报文送至本地三层路由表中,判断报文的目的IP所属的VM与本地VM是否在同一服务器上,若为同一服务器,将目的MAC改写成远端MAC,进入步骤S5,若为不同服务器,将源MAC改写成特殊MAC,将目的MAC改写成远端VM的MAC,特殊MAC由网关MAC产生,进入步骤S6;
S4:判断报文的目的MAC所属的VM与本地VM是否在同一服务器上,若为同一服务器,则进入步骤S7,若为不同服务器,则进入步骤S8;
S5:利用报文的目的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S6:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S9,若识别失败,则丢弃所述报文;
S7:利用报文的目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S8:将所述报文送至远端VM,远端租户识别表识别源MAC,若识别成功,则进入步骤S10,若识别失败,则丢弃所述报文;
S9:将所述报文送至远端三层路由表中,利用报文的IP地址进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文;
S10:将所述报文送至远端二层转发表中,利用报文目的MAC进行匹配,若匹配成功,则接收所述报文,若匹配失败,则丢弃所述报文。
7.一种实现物理主机接入的方法,其特征在于openstack的网络节点及计算节点上安装有分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述方法包括步骤:
s1:租户识别表识别本地VM,若识别成功,则进入步骤s2,若识别失败,则丢弃;
s2:将报文送至二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤s3,若目的MAC不为网关MAC,匹配该网络内通配的二层转发表,进入步骤s4;
s3:将所述报文送至三层路由表中,匹配默认路由将报文送往虚拟路由器,由虚拟路由器发送ARP报文请求物理主机的MAC,进入步骤s4,若匹配失败,则丢弃所述报文;
s4:将所述报文送至物理主机接入的交换机上,所述交换机通过识别VNI映射成本地vlan,再利用目的MAC进行匹配,若匹配成功,则接收所述报文,实现物理主机接入,若匹配失败,则丢弃所述报文。
8.根据权利要求7所述的实现物理主机接入的方法,其特征在于,所述报文由第一交换机的上联口通过隧道送至第二交换机的上联口,所述第一交换机与虚拟网络服务器相连,所述第二交换机与物理主机或虚拟路由器相连。
9.根据权利要求8所述的实现物理主机接入的方法,其特征在于,当本地VM于所述第一交换机下创建成功时,对所述第一交换机的上联口下发隧道配置信息以及VNI与vlan的映射关系信息。
10.一种实现物理主机接入的装置,其特征在于包括:
安装于openstack的服务器的网络节点及计算节点上的分布式路由代理器,通过下发多级流表来控制转发路径,所述多级流表包括租户识别表、二层转发表及三层路由表,所述分布式路由代理器用于:
s1:租户识别表识别本地VM,若识别成功,则进入步骤s2,若识别失败,则丢弃;
s2:将报文送至二层转发表中,读取所述报文的目的MAC,若目的MAC为网关MAC,则进入步骤s3,若目的MAC不为网关MAC,匹配该网络内通配的二层转发表,进入步骤s4;
s3:将所述报文送至三层路由表中,匹配默认路由将报文送往虚拟路由器,由虚拟路由器发送ARP报文请求物理主机的MAC,进入步骤s4,若匹配失败,则丢弃所述报文;
s4:将所述报文送至物理主机接入的交换机上,所述交换机通过识别VNI映射成本地vlan,再利用目的MAC进行匹配,若匹配成功,则接收所述报文,实现物理主机接入,若匹配失败,则丢弃所述报文。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610012009.3A CN105515978B (zh) | 2016-01-08 | 2016-01-08 | 实现分布式路由、物理主机接入的方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610012009.3A CN105515978B (zh) | 2016-01-08 | 2016-01-08 | 实现分布式路由、物理主机接入的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105515978A true CN105515978A (zh) | 2016-04-20 |
| CN105515978B CN105515978B (zh) | 2018-11-02 |
Family
ID=55723634
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610012009.3A Active CN105515978B (zh) | 2016-01-08 | 2016-01-08 | 实现分布式路由、物理主机接入的方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105515978B (zh) |
Cited By (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105933235A (zh) * | 2016-07-07 | 2016-09-07 | 北京邮电大学 | 数据通信方法及装置 |
| CN106292369A (zh) * | 2016-09-09 | 2017-01-04 | 南京玛锶腾智能科技有限公司 | 舵机的分布式控制系统及方法 |
| CN106572014A (zh) * | 2016-10-27 | 2017-04-19 | 曙光信息产业(北京)有限公司 | 虚拟化网络系统 |
| CN106878136A (zh) * | 2016-12-28 | 2017-06-20 | 新华三技术有限公司 | 一种报文转发方法及装置 |
| CN107453998A (zh) * | 2016-05-31 | 2017-12-08 | 华为技术有限公司 | 传输报文的方法和装置 |
| CN107770062A (zh) * | 2016-08-16 | 2018-03-06 | 北京金山云网络技术有限公司 | 一种数据包发送方法、装置及网络架构 |
| CN108039968A (zh) * | 2017-12-12 | 2018-05-15 | 深圳市泰信通信息技术有限公司 | 网络优化方法、设备及计算机可读存储介质 |
| CN108123818A (zh) * | 2016-11-30 | 2018-06-05 | 江南大学 | 一种虚实网络灵活可扩展融合的仿真方法 |
| CN108183862A (zh) * | 2018-01-24 | 2018-06-19 | 上海宽带技术及应用工程研究中心 | 软件定义交换网的通信方法/系统、可读存储介质及设备 |
| CN108259333A (zh) * | 2016-12-29 | 2018-07-06 | 华为技术有限公司 | 一种bum流量控制方法、相关装置以及系统 |
| CN108768807A (zh) * | 2018-06-01 | 2018-11-06 | 中国电子信息产业集团有限公司第六研究所 | 一种云平台虚实互连的方法及装置 |
| CN109379267A (zh) * | 2018-10-18 | 2019-02-22 | 郑州云海信息技术有限公司 | 一种用于物理机加入虚拟局域网的方法和装置 |
| CN109547392A (zh) * | 2017-09-21 | 2019-03-29 | 杭州达乎科技有限公司 | 一种在sdn网络中支持多用户隔离的加密接入方法及系统 |
| CN110401923A (zh) * | 2019-04-19 | 2019-11-01 | 广州天链通信科技有限公司 | 一种vsat终端网桥和路由方式同时支持的方法和vsat终端 |
| CN110650092A (zh) * | 2019-09-24 | 2020-01-03 | 网易(杭州)网络有限公司 | 一种数据处理的方法和装置 |
| CN110752989A (zh) * | 2019-10-18 | 2020-02-04 | 苏州浪潮智能科技有限公司 | 一种东西向流量转发方法与装置 |
| CN111130939A (zh) * | 2019-12-26 | 2020-05-08 | 深圳前海环融联易信息科技服务有限公司 | 一种流量控制方法、装置、计算机设备及存储介质 |
| CN111756636A (zh) * | 2019-03-29 | 2020-10-09 | 杭州海康威视数字技术股份有限公司 | 数据包处理方法、装置及设备、存储介质 |
| CN112491710A (zh) * | 2020-11-09 | 2021-03-12 | 锐捷网络股份有限公司 | 一种基于Openflow的报文转发方法及设备 |
| CN114422471A (zh) * | 2020-10-10 | 2022-04-29 | 中国移动通信有限公司研究院 | 数据传输方法、流表配置方法、装置、设备及存储介质 |
| CN114466011A (zh) * | 2022-01-29 | 2022-05-10 | 苏州浪潮智能科技有限公司 | 一种元数据服务请求方法、装置、设备及介质 |
| CN114785733A (zh) * | 2022-06-20 | 2022-07-22 | 中电云数智科技有限公司 | 一种实现跨vpc网络流量转发中会话溯源的方法 |
| CN115022126A (zh) * | 2022-05-23 | 2022-09-06 | 苏州思萃工业互联网技术研究所有限公司 | 分布式边缘网关的实现方法和系统 |
| CN115442297A (zh) * | 2022-09-06 | 2022-12-06 | 中电云数智科技有限公司 | 一种基于bgp实现eip智能接入的系统和方法 |
| CN117014371A (zh) * | 2023-07-05 | 2023-11-07 | 曙光云计算集团有限公司 | 网络流量的处理方法、装置、电子设备及存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150071053A1 (en) * | 2011-05-23 | 2015-03-12 | Telefonaktiebolaget L M Ericsson (Publ) | Implementing epc in a cloud computer with openflow data plane |
| CN104869058A (zh) * | 2015-06-04 | 2015-08-26 | 北京京东尚科信息技术有限公司 | 一种数据报文转发方法和装置 |
| CN105099779A (zh) * | 2015-07-29 | 2015-11-25 | 北京京东尚科信息技术有限公司 | 多租户云平台架构 |
-
2016
- 2016-01-08 CN CN201610012009.3A patent/CN105515978B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150071053A1 (en) * | 2011-05-23 | 2015-03-12 | Telefonaktiebolaget L M Ericsson (Publ) | Implementing epc in a cloud computer with openflow data plane |
| CN104869058A (zh) * | 2015-06-04 | 2015-08-26 | 北京京东尚科信息技术有限公司 | 一种数据报文转发方法和装置 |
| CN105099779A (zh) * | 2015-07-29 | 2015-11-25 | 北京京东尚科信息技术有限公司 | 多租户云平台架构 |
Cited By (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107453998A (zh) * | 2016-05-31 | 2017-12-08 | 华为技术有限公司 | 传输报文的方法和装置 |
| CN107453998B (zh) * | 2016-05-31 | 2020-02-14 | 华为技术有限公司 | 传输报文的方法和装置 |
| CN105933235B (zh) * | 2016-07-07 | 2019-02-19 | 北京邮电大学 | 数据通信方法及装置 |
| CN105933235A (zh) * | 2016-07-07 | 2016-09-07 | 北京邮电大学 | 数据通信方法及装置 |
| CN107770062A (zh) * | 2016-08-16 | 2018-03-06 | 北京金山云网络技术有限公司 | 一种数据包发送方法、装置及网络架构 |
| CN106292369A (zh) * | 2016-09-09 | 2017-01-04 | 南京玛锶腾智能科技有限公司 | 舵机的分布式控制系统及方法 |
| CN106292369B (zh) * | 2016-09-09 | 2019-02-15 | 江苏新辰海智能科技有限公司 | 舵机的分布式控制系统及方法 |
| CN106572014A (zh) * | 2016-10-27 | 2017-04-19 | 曙光信息产业(北京)有限公司 | 虚拟化网络系统 |
| CN108123818B (zh) * | 2016-11-30 | 2020-10-09 | 江南大学 | 一种虚实网络灵活可扩展融合的仿真方法 |
| CN108123818A (zh) * | 2016-11-30 | 2018-06-05 | 江南大学 | 一种虚实网络灵活可扩展融合的仿真方法 |
| CN106878136A (zh) * | 2016-12-28 | 2017-06-20 | 新华三技术有限公司 | 一种报文转发方法及装置 |
| CN106878136B (zh) * | 2016-12-28 | 2020-01-03 | 新华三技术有限公司 | 一种报文转发方法及装置 |
| US11245631B2 (en) | 2016-12-29 | 2022-02-08 | Huawei Technologies Co., Ltd. | Bum traffic control method, related apparatus, and system |
| CN108259333A (zh) * | 2016-12-29 | 2018-07-06 | 华为技术有限公司 | 一种bum流量控制方法、相关装置以及系统 |
| CN108259333B (zh) * | 2016-12-29 | 2021-07-09 | 华为技术有限公司 | 一种bum流量控制方法、相关装置以及系统 |
| CN109547392A (zh) * | 2017-09-21 | 2019-03-29 | 杭州达乎科技有限公司 | 一种在sdn网络中支持多用户隔离的加密接入方法及系统 |
| CN109547392B (zh) * | 2017-09-21 | 2021-06-01 | 上海层峰网络科技有限公司 | 一种在sdn网络中支持多用户隔离的加密接入方法及系统 |
| CN108039968A (zh) * | 2017-12-12 | 2018-05-15 | 深圳市泰信通信息技术有限公司 | 网络优化方法、设备及计算机可读存储介质 |
| CN108039968B (zh) * | 2017-12-12 | 2021-02-23 | 深圳市泰信通信息技术有限公司 | 网络优化方法、设备及计算机可读存储介质 |
| CN108183862A (zh) * | 2018-01-24 | 2018-06-19 | 上海宽带技术及应用工程研究中心 | 软件定义交换网的通信方法/系统、可读存储介质及设备 |
| CN108768807A (zh) * | 2018-06-01 | 2018-11-06 | 中国电子信息产业集团有限公司第六研究所 | 一种云平台虚实互连的方法及装置 |
| CN109379267A (zh) * | 2018-10-18 | 2019-02-22 | 郑州云海信息技术有限公司 | 一种用于物理机加入虚拟局域网的方法和装置 |
| CN111756636A (zh) * | 2019-03-29 | 2020-10-09 | 杭州海康威视数字技术股份有限公司 | 数据包处理方法、装置及设备、存储介质 |
| CN110401923A (zh) * | 2019-04-19 | 2019-11-01 | 广州天链通信科技有限公司 | 一种vsat终端网桥和路由方式同时支持的方法和vsat终端 |
| CN110401923B (zh) * | 2019-04-19 | 2021-08-10 | 广州天链通信科技有限公司 | 一种vsat终端网桥和路由方式同时支持的方法和vsat终端 |
| CN110650092B (zh) * | 2019-09-24 | 2022-05-03 | 网易(杭州)网络有限公司 | 一种数据处理的方法和装置 |
| CN110650092A (zh) * | 2019-09-24 | 2020-01-03 | 网易(杭州)网络有限公司 | 一种数据处理的方法和装置 |
| CN110752989A (zh) * | 2019-10-18 | 2020-02-04 | 苏州浪潮智能科技有限公司 | 一种东西向流量转发方法与装置 |
| CN111130939A (zh) * | 2019-12-26 | 2020-05-08 | 深圳前海环融联易信息科技服务有限公司 | 一种流量控制方法、装置、计算机设备及存储介质 |
| CN114422471A (zh) * | 2020-10-10 | 2022-04-29 | 中国移动通信有限公司研究院 | 数据传输方法、流表配置方法、装置、设备及存储介质 |
| CN112491710A (zh) * | 2020-11-09 | 2021-03-12 | 锐捷网络股份有限公司 | 一种基于Openflow的报文转发方法及设备 |
| CN114466011B (zh) * | 2022-01-29 | 2023-08-04 | 苏州浪潮智能科技有限公司 | 一种元数据服务请求方法、装置、设备及介质 |
| CN114466011A (zh) * | 2022-01-29 | 2022-05-10 | 苏州浪潮智能科技有限公司 | 一种元数据服务请求方法、装置、设备及介质 |
| CN115022126B (zh) * | 2022-05-23 | 2023-09-01 | 苏州思萃工业互联网技术研究所有限公司 | 分布式边缘网关的实现方法和系统 |
| CN115022126A (zh) * | 2022-05-23 | 2022-09-06 | 苏州思萃工业互联网技术研究所有限公司 | 分布式边缘网关的实现方法和系统 |
| CN114785733A (zh) * | 2022-06-20 | 2022-07-22 | 中电云数智科技有限公司 | 一种实现跨vpc网络流量转发中会话溯源的方法 |
| CN114785733B (zh) * | 2022-06-20 | 2022-08-26 | 中电云数智科技有限公司 | 一种实现跨vpc网络流量转发中会话溯源的方法 |
| CN115442297A (zh) * | 2022-09-06 | 2022-12-06 | 中电云数智科技有限公司 | 一种基于bgp实现eip智能接入的系统和方法 |
| CN115442297B (zh) * | 2022-09-06 | 2023-08-22 | 中电云数智科技有限公司 | 一种基于bgp实现eip智能接入的系统和方法 |
| CN117014371A (zh) * | 2023-07-05 | 2023-11-07 | 曙光云计算集团有限公司 | 网络流量的处理方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105515978B (zh) | 2018-11-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105515978A (zh) | 实现分布式路由、物理主机接入的方法及装置 | |
| CN109660443B (zh) | 基于sdn的物理设备与虚拟网络通信方法和系统 | |
| KR102812234B1 (ko) | 세분화된 네트워크 엘리먼트를 포함하는 로직 라우터 | |
| JP5991424B2 (ja) | パケット書換装置、制御装置、通信システム、パケット送信方法及びプログラム | |
| CN109120494B (zh) | 在云计算系统中接入物理机的方法 | |
| JP5792894B2 (ja) | ポート拡張トポロジ情報の取得用方法、システム及び制御ブリッジ並びにアップリンクポートの処理方法及びシステム | |
| CN102857416B (zh) | 一种实现虚拟网络的方法、控制器和虚拟网络 | |
| US10205657B2 (en) | Packet forwarding in data center network | |
| ES2565827T3 (es) | Método de control de enrutamiento, aparato y sistema de red privada virtual de capa 3 | |
| US20130232492A1 (en) | Method and system for realizing virtual machine mobility | |
| CN113411243B (zh) | 数据传输方法及装置 | |
| EP3197107B1 (en) | Message transmission method and apparatus | |
| EP2843906B1 (en) | Method, apparatus, and system for data transmission | |
| US20150172222A1 (en) | Data center ethernet switch fabric | |
| CN108768817A (zh) | 一种虚拟化网络组网系统、数据包发送方法 | |
| US10572291B2 (en) | Virtual network management | |
| CN107947961A (zh) | 基于SDN的Kubernetes网络管理系统与方法 | |
| CN105681191A (zh) | 基于路由器虚拟化的sdn平台及实现方法 | |
| CN108111383A (zh) | 一种基于sdn的跨域容器虚拟网络组建方法 | |
| CN105897465A (zh) | 设备配置方法及装置 | |
| CN105531966B (zh) | 一种网络中实现报文路由的方法、设备和系统 | |
| CN111404797B (zh) | 控制方法、sdn控制器、sdn接入点、sdn网关及ce | |
| CN110311860A (zh) | Vxlan下多链路负载均衡方法及装置 | |
| CN103428252B (zh) | 一种云计算虚拟机迁移的方法、设备及系统 | |
| CN108696370B (zh) | 一种服务器与业务绑定和解绑定方法、装置及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address |
Address after: 215000 unit 13 / 16, 4th floor, building B, No.5 Xinghan street, Suzhou Industrial Park, Jiangsu Province Patentee after: Suzhou Shengke Communication Co.,Ltd. Address before: Xinghan Street Industrial Park of Suzhou city in Jiangsu province 215021 B No. 5 Building 4 floor 13/16 unit Patentee before: CENTEC NETWORKS (SU ZHOU) Co.,Ltd. |
|
| CP03 | Change of name, title or address |