CN106331206A - 域名管理方法及装置 - Google Patents

域名管理方法及装置 Download PDF

Info

Publication number
CN106331206A
CN106331206A CN201510384764.XA CN201510384764A CN106331206A CN 106331206 A CN106331206 A CN 106331206A CN 201510384764 A CN201510384764 A CN 201510384764A CN 106331206 A CN106331206 A CN 106331206A
Authority
CN
China
Prior art keywords
address
networking component
domain name
vtep
vxlan
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
Application number
CN201510384764.XA
Other languages
English (en)
Other versions
CN106331206B (zh
Inventor
李蔚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou H3C Technologies Co Ltd
Original Assignee
Hangzhou H3C Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou H3C Technologies Co Ltd filed Critical Hangzhou H3C Technologies Co Ltd
Priority to CN201510384764.XA priority Critical patent/CN106331206B/zh
Publication of CN106331206A publication Critical patent/CN106331206A/zh
Application granted granted Critical
Publication of CN106331206B publication Critical patent/CN106331206B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H04L61/3015—Name registration, generation or assignment
    • H04L61/3025—Domain name generation or assignment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种域名管理方法及装置。方法包括：基于SDN+VxLAN的Openstack Neutron网络内的SDN Controller将每个网络组件的域名与该网络组件的IP地址的对应关系保存在DNS配置列表中，其中，网络组件之间具有层级关系，网络组件的域名由该网络组件的标识及该网络组件在网络中的层位置信息组成；SDN Controller接收VTEP发来的DNS请求报文，根据自身的DNS配置列表，将该报文中的网络组件的域名解析成网络组件的IP地址，将该网络组件的IP地址携带在DNS应答报文中返回给所述VTEP，所述DNS请求报文为所述VTEP下挂的主机要访问一网络组件时发给所述VTEP的。本申请降低了网络部署成本。

Description

域名管理方法及装置
技术领域
本申请涉及域名技术领域，尤其涉及域名管理方法及装置。
背景技术
OpenStack是一个自由软件和开放源代码项目，是一个云平台管理的项目，它不是一个软件。这个项目由几个主要的组件组合起来完成一些具体的工作，是目前云计算IaaS(Infrastructure-as-a-Service，基础设施服务)应用最主流的云管理平台。目前Openstack管理云计算网络的主流软件项目是Neutron。目前Neutron定义IaaS的网络架构如图1所示。
从图1中可以看到，Neutron将网络架构分成3个层次，分别如下：
1)租户：拥有独立的IP地址空间、独立的vRouter(虚拟路由器)，可以建立多个vDC(Virtual Data Center，虚拟数据中心)。
2)vNet(虚拟网络)：独立的二层网络，可以对应一个或多个subnet(子网)。
3)VM(Virtual Machine，虚拟机)：对应一个IP地址。
SDN(Software Defined Network，软件定义网络)是Emulex网络的一种新型网络创新架构，其核心技术OpenFlow(开放流)通过将网络设备控制面与数据面分离开来，从而实现了网络流量的灵活控制。
目前业界的主流架构是用SDN作为网络控制器，北向连接OpenstackNeutron，接收管理员的指令；南向通过Openflow、Netconf(网络配置)等协议直接控制网络设备的转发行为。其中，接收SDN控制器转发表的设备可以是传统的硬件设备，也可以是软件设备如：OVS(Open vSwitch，开放虚拟交换机)。
Overlay(堆叠)网络就是应用层网络，它是直接面向应用层的(显示应用之间的点到点直连)，不用考虑具体物理网络的问题。详细说来，Overlay网络是指建立在现有物理网络上的另一个逻辑网络。该网络中的结点可以看作通过虚拟或逻辑链路而连接起来的。虽然在底层有很多条物理链路，但是这些虚拟或逻辑链路都与路径一一对应。
目前Overlay的主流实现技术有两种：VxLAN(Virtual eXtensible LocalArea Network，虚拟扩展局域网)和NVGRE(Network Virtualization usingGeneric Routing Encapsulation，使用通用路由封装的网络虚拟化)，VxLAN在Overlay网络领域应用更加广泛。
如图1所示，Openstack Neutron的网络架构中的二层网络定义为vNet，与VxLAN定义的二层网络相对应，也就是说同一个二层网络(VxLAN)中可以有一个subnet，也可以有多个subnet。另外，Neutron定义的vRouter可以是物理实体，也可以是逻辑实体。在SDN+VxLAN方案中，vRouter没有物理实体，其功能基本都由SDN控制器完成，也就是说vRouter的逻辑实体就是SDN控制器。
发明内容
本申请实施例提供域名管理方法及装置。
本申请的技术方案是这样实现的：
一种域名管理方法，该方法包括：
基于SDN+VxLAN的Openstack Neutron网络内的SDN控制器将每个网络组件的域名与该网络组件的IP地址的对应关系保存在自身的DNS(域名系统)配置列表中，其中，网络组件之间具有层级关系，网络组件的域名由该网络组件的标识及该网络组件在网络中的层位置信息组成；
SDN控制器接收VTEP(VxLAN隧道端点)发来的DNS请求报文，根据自身的DNS配置列表，将该报文中的网络组件的域名解析成网络组件的IP地址，将该网络组件的IP地址携带在DNS应答报文中返回给所述VTEP，其中，所述DNS请求报文为所述VTEP下挂的主机要访问一网络组件时发给所述VTEP的。
一种域名管理装置，位于基于SDN+VxLAN的Openstack Neutron网络内的SDN控制器上，该装置包括：
域名配置模块：将每个网络组件的域名与该网络组件的IP地址的对应关系保存在DNS配置列表中，其中，网络组件之间具有层级关系，网络组件的域名由该网络组件的标识及该网络组件在网络中的层位置信息组成；
域名解析模块：接收VTEP发来的DNS请求报文，根据DNS配置列表，将该报文中的网络组件的域名解析成网络组件的IP地址，将该网络组件的IP地址携带在DNS应答报文中返回给所述VTEP，其中，所述DNS请求报文为所述VTEP下挂的主机要访问一网络组件时发给所述VTEP的。
可见，本申请实施例通过为基于SDN+VxLAN的Openstack Neutron网络内的网络组件配置域名，域名由该网络组件的标识及该网络组件在网络中的层位置信息组成，并由SDN Controller负责域名解析，由VTEP代理DNS请求/应答，从而有效降低了网络部署成本，并提高了转发效率。
附图说明
图1为现有的Openstack Neutron定义IaaS的网络架构示意图；
图2为本申请一实施例提供的域名管理方法流程图；
图3为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的域名配置方法流程图；
图4为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络架构示例图；
图5为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的VM访问同一vDC内的不同subnet下的VM时的域名管理方法流程图；
图6为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的VM访问同一vDC内的指定subnet时的域名管理方法流程图；
图7为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的VM访问不同vDC内的VM时的域名管理方法流程图；
图8为本申请实施例提供的域名管理装置的组成示意图；
图9为本申请实施例提供的包含域名管理装置的SDN控制器的硬件架构示意图。
具体实施方式
Openstack Neutron网络中目前有几个明确的需求，包括：
1)负载分担。多个VM之间要对业务进行负载分担；
2)在Subnet内实现组播转发；
3)同一租户内，不同的vRouter(vDC)下的应用需要互通。
其中，对于多个VM之间要对业务进行负载分担，目前采用部署SLB(Server Load Balancer，服务器负载均衡器)的方案，该方案主要包括两种方式：
a、不对称流量，即三角流量部署方式。这种部署方式只有请求流量经过SLB，而应答流量不经过SLB；
b、对称流量，即对报文的源地址和目的地址都进行转换，双向流量都经过SLB。
该方案存在如下问题：
1)需要额外部署SLB，增加了成本。
2)不对称流量方式可以保证应答流量不经过SLB，减轻了SLB的流量压力，但是要求SLB与进行负载分担的服务器位于同一二层网络内，需要规划所有的流量路径，对部署要求更高；
对称流量方式中，双向流量都要经过SLB，因此对SLB本身的流量压力太大，会影响SLB的性能；同时，由于该方式对请求报文的源地址进行转换，所以一些基于源地址的安全监控无法使用，降低了系统的安全系数。
对于在subnet内实现组播存在如下问题：
由于一个VxLAN(vNet)可以有多个subnet，所以针对指定subnet的组播转发需要部署组播相关协议，将指定subnet内的VM对应的端口加入组播转发表项。这样的组播转发需要非常复杂的部署方案。
对于同租户内不同vRouter下的应用互通存在如下问题：
由于不同vDC的vRouter建立了不同的转发表，当在本vRouter的转发表中无法查找到目的地址时，通常会根据缺省路由将报文发到vDC外部，由外部的转发表指导转发，报文需要在vDC外部绕一圈，然后转发到目的vDC内的vRouter上进行路由查找、转发；返程报文也一样。这样报文虽然可达，但是转发路径要绕行到vDC外部，流量路径过长，做了多次不必要的转发，严重影响系统整体转发性能。同时，也给流量带来较大的时延，降低应用的性能，影响客户体验。
图2为本申请一实施例提供的域名管理方法流程图，其具体步骤如下：
步骤201：基于SDN+VxLAN的Openstack Neutron网络内的SDNController将每个网络组件的域名与该网络组件的IP地址的对应关系保存在自身的DNS(Domain Name System，域名系统)配置列表中，其中，网络组件之间具有层级关系，网络组件的域名由该网络组件的标识及该网络组件在网络中的层位置信息组成。
步骤202：SDN Controller接收VTEP(VxLAN Tunnel EndPoint，虚拟扩展局域网隧道端点)发来的DNS请求报文，根据自身的DNS配置列表，将该报文中的网络组件的域名解析成网络组件的IP地址，将该网络组件的IP地址携带在DNS应答报文中返回给所述VTEP，其中，所述DNS请求报文为所述VTEP下挂的主机要访问一网络组件时发给所述VTEP的。
本申请一实施例中，网络组件的域名由网络组件的标识以及该组件的各上级组件的标识组成。
本申请一实施例中，网络组件包括：主机或者进行负载分担的主机集合、子网Subnet、虚拟数据中心vDC三层，且主机和进行负载分担的主机集合的层级相同且层级最低，subnet的层级次低，vDC的层级最高；
且网络组件的标识满足：同一网络层内的任意两个网络组件的标识不同。
本申请一实施例中，网络组件的标识为字符串。
本申请一实施例中，步骤202中，将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步包括：
SDN Controller发现解析出的网络组件的IP地址为能够进行负载分担的多个主机的IP地址，则根据预设的负载分担算法，在该多个IP地址中选择一个，确定将所选择的IP地址携带在所述DNS应答报文中。
本申请一实施例中，步骤202中，将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步包括：
SDN Controller发现该网络组件的IP地址为subnet的组播IP地址，则根据自身维护的整网拓扑信息，计算出该组播IP地址对应的组播转发表项，将该组播转发表项发送给所述VTEP，该组播转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该组播IP地址，下一跳为该组播IP地址对应的subnet内的所有VTEP，VxLAN ID为该组播IP地址对应的subnet的VxLAN ID。
本申请一实施例中，步骤202中，将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步包括：
SDN Controller根据自身维护的整网拓扑信息，发现解析出的网络组件的IP地址与所述VTEP位于不同vDC内，则向所述VTEP和该网络组件接入的VTEP下发转发表项，其中，
向所述VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该网络组件的IP地址，下一跳为该网络组件接入的VTEP，VxLAN ID为该网络组件所在的subnet的VxLAN ID；
向该网络组件接入的VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为发出所述DNS请求报文的VM的IP地址，下一跳为所述VTEP，VxLAN ID为所述VTEP所在的subnet的VxLAN ID。
图3为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的域名配置方法流程图，其具体步骤如下：
步骤301：预先为基于SDN+VxLAN的Openstack Neutron网络内的每个网络组件(包括：主机、进行负载分担的主机集合、Subnet、vDC)分配标识；根据每个网络组件的标识以及该组件的各上级组件的标识为每个网络组件配置唯一的域名。
主机包括：VM和物理服务器。
在为网络组件分配标识时，可由管理员等手工分配。
进行负载分担的主机集合指的是，若多个主机能够进行负载分担，则该多个主机组成进行负载分担的主机集合，为该主机集合分配一个集合标识。
在为网络组件分配标识时，基本原则如下：
一)为基于SDN+VxLAN的Openstack Neutron网络内的所有vDC分配互不相同的标识，即任意两个vDC的标识都不能相同；
二)为每个vDC内的所有subnet分配互不相同的标识，即位于同一vDC内的任意两个subnet的标识都不能相同；
三)为每个subnet内的所有VM分配互不相同的标识，即位于同一subnet内的任意两个VM的标识都不能相同。
标识可以是字符串等。以图4所示的基于SDN+VxLAN的OpenstackNeutron网络为例，其中，VM1位于subnet1内，VM2、VM3位于subnet2内，VM4位于subnet3内，subnet1、subnet2位于vDC1内，subnet3位于vDC2内。则为各VM、各subnet、各vDC分配的标识如下：
1)VM1的标识为a1，VM2的标识为a2，VM3的标识为a3，VM4的标识为a4；且，VM2和VM3可以进行负载分担，则为VM2和VM3分配一个用于负载分担的集合标识：a23；
2)subet1的标识为b1，subnet2的标识为b2；
3)vDC1的标识为c1，vDC2的标识为c2。
对于网络组件：主机、进行负载分担的主机集合、Subnet、vDC来说，主机和进行负载分担的主机集合的级别相同且最低，subnet的级别次低，vDC的级别最高。
主机的域名由该主机的标识、该主机接入的subnet的标识、该主机所在的vDC的标识组成；subnet的域名由该subnet的标识、该subnet所在的vDC的标识组成；vDC的域名由该vDC的标识组成。
需要说明的是，为了使域名的表示形式标准化，在实际应用中，subnet的域名中也可包含主机标识，只不过该主机标识是一个无效主机标识，这样，SDN Controller在识别该域名时，就可以忽略该无效主机标识；同样地，vDC的域名也可包括subnet标识和主机标识，只不过subnet标识和主机标识都是无效标识，以便SDN Controller在识别该域名时，可以忽略该无效subnet标识和无效主机标识。
仍以图4为例，VM1的域名为：a1.b1.c1，subnet1的域名为：**.b1.c1，其中，“**”属于无效主机标识；VM2和VM3的用于负载分担的集合域名为a23.b2.c1。
步骤302：SDN Controller将基于SDN+VxLAN的Openstack Neutron网络内的每个网络组件的域名与该网络组件的IP地址的对应关系保存在自身的DNS配置列表中。
仍以图4为例，VM1的域名为：a1.b1.c1，VM1的IP地址为100.1.1.1，则SDN Controller保存a1.b1.c1与100.1.1.1的对应关系；
subnet1的域名为：**.b1.c1，subnet1的组播IP地址为100.1.1.255，则SDN Controller保存**.b1.c1与100.1.1.255的对应关系；
VM2和VM3的用于负载分担的集合域名为a23.b2.c1，VM2的IP地址为200.1.1.1，VM3的IP地址为200.1.1.2，则SDN Controller保存a23.b2.c1与200.1.1.1和200.1.1.2的对应关系。
需要说明的是，本申请实施例中的域名独立于Internet上的域名体系，只在基于SDN+VxLAN的Openstack Neutron网络内使用。
图5为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的VM访问同一vDC内的不同subnet下的VM时的域名管理方法流程图，其具体步骤如下：
步骤501：VM1要访问能够进行负载分担的VM2和VM3，发现自身未保存VM2和VM3的集合域名和IP地址的对应关系，则发出DNS请求报文，该报文携带VM2和VM3的用于负载分担的集合域名。
以图4为例，VM2和VM3的用于负载分担的集合域名为a23.b2.c1。
当VM2和VM3都能提供一业务功能时，会将VM2和VM3配置为能够进行负载分担，此时，可为VM2和VM3分配用于负载分担的集合标识(以图4为例，如a23)，并为该集合配置域名(以图4为例，如a23.b2.c1)；对于VM1来说，它只需知道该域名(以图4为例，如a23.b2.c1)对应主机(或主机集合)可以提供该业务功能即可，并不需要知道该域名是对应一台主机还是多台主机。
步骤502：VM1连接的VTEP1侦听到该DNS请求报文，将该报文截获并转发给SDN Controller。
步骤503：SDN Controller接收该DNS请求报文，根据自身的DNS配置列表，将该报文中的域名(以图4为例，如a23.b2.c1)解析成对应的VM2、VM3的IP地址(以图4为例，如200.1.1.1、200.1.1.2)，根据预设的负载分担算法在该两个IP地址中选择一个(以图4为例，如选择200.1.1.1)，将所选择的IP地址携带在DNS应答报文中发送给VTEP1。
步骤504：VTEP1接收该DNS应答报文，将该DNS应答报文转发给VM1。
步骤505：VM1接收该DNS应答报文，将该报文中的IP地址(以图4为例，如200.1.1.1)作为访问的目的地址，发出请求报文，报文的目的地址为网关MAC地址。
这里，设VM1与VM2不位于同一网段，因此，VM1发出的请求报文的目的MAC地址是网关MAC地址。以图4为例，VM1的网关就是VTEP1。
步骤506：VTEP1(即网关)接收该请求报文，根据报文的目的IP地址查找本地转发表，查找到对应的转发表项，该转发表项包括：目的IP地址，下一跳：即目的网关(以图4为例，为VTEP2)，VxLAN ID：目的subnet的VxLAN ID(以图4为例，为2000)，按照该转发表项封装该请求报文，将该请求报文转发到VTEP2。
若VTEP1根据请求报文的目的IP地址在本地转发表中未查找到对应的转发表项，则VTEP1将请求报文通过openflow协议上送到SDN Controller；SDN controller根据自身维护的整网拓扑信息，确定对应的转发表项，将该转发表项下发到VTEP1，VTEP1保存该转发表项并根据该转发表项封装并转发该请求报文。
步骤507：VTEP2接收该请求报文，对该报文进行解封装，得到原始请求报文，根据原始请求报文的目的IP地址查找本地转发表，根据查找到的转发表项将报文转发给VM2。
由于VM2已经知道了VM1的IP地址，因此，VM2向VM1发送应答报文时，直接在应答报文的目的IP地址字段填入VM1的IP地址即可，VM2向VM1发送应答报文的过程与VM1向VM2发送请求报文的过程类似，不再赘述。
图6为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的VM访问同一vDC内的指定subnet时的域名管理方法流程图，其具体步骤如下：
步骤601：VM1要访问本vDC内的另一subnet内的所有VM，发现自身未保存该subnet的域名与IP地址的对应关系，则发出DNS请求报文，报文中携带该subnet的域名。
以图4为例，设VM1要访问vDC1内的subnet2内的所有VM，则发出的DNS请求报文携带域名**.b2.c1。
步骤602：VM1接入的VTEP1侦听到该DNS请求报文，将该报文截获并转发给SDN Controller。
步骤603：SDN Controller接收该DNS请求报文，根据自身的DNS配置列表，将报文中的域名(以图4为例，如**.b2.c1)解析成对应的IP地址(以图4为例，如200.1.1.255)，将该IP地址携带在DNS应答报文中返回给VTEP1，并同时向VTEP1下发该IP地址对应的组播转发表项。
该IP地址对应的组播转发表项的内容包括：目的IP地址：该IP地址，下一跳：该IP地址对应的subnet内的所有VTEP，VxLAN ID：该IP地址对应的subnet的VxLAN ID。以图4为例，SDN Controller向VTEP1下发的组播转发表项：目的IP地址200.1.1.255，下一跳是VTEP2和VTEP3，VxLANID是2000。
需要说明的是，SDN Controller在解析域名时，是按照从右向左的顺序分级解析的，即先解析域名中的vDC的标识部分，再解析subnet的标识部分，最后解析主机(或主机集合)的标识部分，若有一部分为无效标识，则忽略该部分。例如：对于域名**.b2.c1，SDN Controller先解析c1，再解析b2，最后解析**，发现**为无效标识，则确认**.b2.c1对应vDC1内的subnet2，则将该域名解析成vDC1内的subnet2的组播IP地址200.1.1.255。
步骤604：VTEP1接收该DNS应答报文，将该报文转发给VM1；同时接收并保存SDN Controller下发的组播转发表项。
步骤605：VM1接收该DNS应答报文，发出请求报文，报文的目的IP地址为DNS应答报文中的IP地址(以图4为例，如200.1.1.255)。
步骤606：VTEP1接收VM1发出的请求报文，在本地转发表中查找报文的目的IP地址对应的转发表项，得知下一跳为VTEP2和VTEP3，则复制该报文，对该两报文进行封装后分别发送给VTEP2、VTEP3。
步骤607：VTEP2接收请求报文，对报文进行解封装后发送给VM2；VTEP3接收该请求报文，对报文进行解封装后发送给VM3。
图7为本申请实施例提供的基于SDN+VxLAN的Openstack Neutron网络内的VM访问不同vDC内的VM时的域名管理方法流程图，其具体步骤如下：
步骤701：VM1要访问VM4，发现自身未保存VM4的域名与IP地址的对应关系，则发出DNS请求报文，报文携带VM4的域名(以图4为例，如a4.b3.c2)。
步骤702：VM1接入的VTEP1侦听到该DNS请求报文，将该报文截获并转发给SDN Controller。
步骤703：SDN Controller接收该DNS请求报文，根据自身的DNS配置列表，将报文中的域名(以图4为例，如a4.b3.c2)解析成对应的IP地址(以图4为例，如300.1.1.1)，将该IP地址携带在DNS应答报文中返回给VTEP1；同时，SDN Controller根据自身维护的整网拓扑信息，发现VM1和VM4位于不同的vDC内，则向VM1接入的VTEP1下发VM4的IP地址对应的转发表项，向VM4接入的VTEP4下发VM1的IP地址对应的转发表项。
以图4为例，SDN Controller向VTEP1下发的转发表项：目的IP地址300.1.1.1，下一跳是VTEP4，VxLAN ID是3000；向VTEP4下发的转发表项：目的IP地址100.1.1.1，下一跳是VTEP1，VxLAN ID是1000。
步骤704：VTEP1接收该DNS应答报文，将该报文转发给VM1；同时，接收并保存SDN Controller下发的转发表项；VTEP4接收并保存SDNController下发的转发表项。
步骤705：VM1接收该DNS应答报文，发出请求报文，请求报文的目的IP地址为DNS应答报文中的VM4的IP地址(以图4为例，如300.1.1.1)。
VM1还可以保存DNS应答报文中的VM4的域名和IP地址的对应关系，此后再接收到用户输入的VM4的域名时，就可以直接将该域名转换为IP地址携带在请求报文中。
步骤706：VTEP1接收VM1发出的请求报文，在本地转发表中查找报文的目的IP地址对应的转发表项(即步骤703中SDN Controller下发的转发表项)，根据查找到的转发表项，对报文进行封装后发送给VTEP4。
步骤707：VTEP4接收该报文，对报文解封装后转发给VM4。
由于VM4已经知道了VM1的IP地址，因此，VM4向VM1发送应答报文时，直接在应答报文的目的IP地址字段填入VM1的IP地址即可，VM4向VM1发送应答报文的过程与VM1向VM4发送请求报文的过程类似，不再赘述。
本申请实施例通过为基于SDN+VxLAN的Openstack Neutron网络内的网络组件配置域名，并由SDN Controller负责域名解析，由VTEP代理DNS请求/应答，从而有效降低了网络部署成本，并提高了转发效率，具体地：
一)无需部署SLB，就可以实现应用的负载分担，有效降低了成本，同时简化了部署难度；
二)支持任意指定subnet内的组播转发；
三)实现了不同vDC之间的应用的直接转发，不需要绕行到vDC外转发，提高了转发效率。
图8为本申请实施例提供的域名管理装置的组成示意图，该装置位于基于SDN+VxLAN的Openstack Neutron网络内的SDN控制器上，该装置主要包括：
域名配置模块：将每个网络组件的域名与该网络组件的IP地址的对应关系保存在域名系统DNS配置列表中，其中，网络组件之间具有层级关系，网络组件的域名由该网络组件的标识及该网络组件在网络中的层位置信息组成；
域名解析模块：接收VxLAN隧道端点VTEP发来的DNS请求报文，根据域名配置模块保存的DNS配置列表，将该报文中的网络组件的域名解析成网络组件的IP地址，将该网络组件的IP地址携带在DNS应答报文中返回给所述VTEP，其中，所述DNS请求报文为所述VTEP下挂的主机要访问一网络组件时发给所述VTEP的。
一种实施例中，域名配置模块保存的网络组件的标识满足：同一网络层内的任意两个网络组件的标识不同；网络组件包括：主机或者进行负载分担的主机集合、子网Subnet、虚拟数据中心vDC三层，且主机和进行负载分担的主机集合的层级相同且层级最低，subnet的层级次低，vDC的层级最高。
一种实施例中，域名解析模块将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步用于，发现解析出的网络组件的IP地址为能够进行负载分担的多个主机的IP地址，则根据预设的负载分担算法，在该多个IP地址中选择一个，确定将所选择的IP地址携带在所述DNS应答报文中。
一种实施例中，域名解析模块将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步用于，发现该网络组件的IP地址为subnet的组播IP地址，则根据自身维护的整网拓扑信息，计算出该组播IP地址对应的组播转发表项，将该组播转发表项发送给所述VTEP，该组播转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该组播IP地址，下一跳为该组播IP地址对应的subnet内的所有VTEP，VxLAN ID为该组播IP地址对应的subnet的VxLAN ID。
一种实施例中，域名解析模块将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步用于，根据自身维护的整网拓扑信息，发现解析出的网络组件的IP地址与所述VTEP位于不同vDC内，则向所述VTEP和该网络组件接入的VTEP下发转发表项，其中，
向所述VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该网络组件的IP地址，下一跳为该网络组件接入的VTEP，VxLAN ID为该网络组件所在的subnet的VxLAN ID；
向该网络组件接入的VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为发出所述DNS请求报文的VM的IP地址，下一跳为所述VTEP，VxLAN ID为所述VTEP所在的subnet的VxLAN ID。
本申请实施例还提供包含域名管理装置的SDN控制器，该SDN控制器可以是软硬件结合的可编程设备，从硬件层面而言，该设备的硬件架构示意图具体可以参见图9。该SDN控制器中包括：机器可读存储介质、CPU和其它硬件，其中：
机器可读存储介质：存储指令代码；所述指令代码被CPU执行时完成的操作主要为上述域名管理装置完成的功能。
CPU：与机器可读存储介质通信，读取和执行机器可读存储介质中存储的所述指令代码，完成上述域名管理装置完成的功能。
当上述域名管理装置作为一个逻辑意义上的装置时，其是通过CPU运行机器可读存储介质中对应的计算机程序指令形成的。当对应的计算机程序指令被执行时，形成的域名管理装置用于按照上述实施例中的域名管理方法执行相应操作。
机器可读存储介质可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。
本申请所描述的任一机器可读存储介质都可以被认为是非暂时性的。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种域名管理方法，其特征在于，该方法包括：
基于软件定义网络SDN+虚拟扩展局域网VxLAN的Openstack Neutron网络内的SDN控制器Controller将每个网络组件的域名与该网络组件的IP地址的对应关系保存在自身的域名系统DNS配置列表中，其中，网络组件之间具有层级关系，网络组件的域名由该网络组件的标识及该网络组件在网络中的层位置信息组成；
SDN Controller接收VxLAN隧道端点VTEP发来的DNS请求报文，根据自身的DNS配置列表，将该报文中的网络组件的域名解析成网络组件的IP地址，将该网络组件的IP地址携带在DNS应答报文中返回给所述VTEP，其中，所述DNS请求报文为所述VTEP下挂的主机要访问一网络组件时发给所述VTEP的。
2.根据权利要求1所述的方法，其特征在于，所述网络组件包括：主机或者进行负载分担的主机集合、子网Subnet、虚拟数据中心vDC三层，且主机和进行负载分担的主机集合的层级相同且层级最低，subnet的层级次低，vDC的层级最高；
且所述网络组件的标识满足：同一网络层内的任意两个网络组件的标识不同。
3.根据权利要求1所述的方法，其特征在于，所述将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步包括：
SDN Controller发现解析出的网络组件的IP地址为能够进行负载分担的多个主机的IP地址，则根据预设的负载分担算法，在该多个IP地址中选择一个，确定将所选择的IP地址携带在所述DNS应答报文中。
4.根据权利要求1所述的方法，其特征在于，所述将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步包括：
SDN Controller发现该网络组件的IP地址为subnet的组播IP地址，则根据自身维护的整网拓扑信息，计算出该组播IP地址对应的组播转发表项，将该组播转发表项发送给所述VTEP，该组播转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该组播IP地址，下一跳为该组播IP地址对应的subnet内的所有VTEP，VxLAN ID为该组播IP地址对应的subnet的VxLAN ID。
5.根据权利要求1所述的方法，其特征在于，所述将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步包括：
SDN Controller根据自身维护的整网拓扑信息，发现解析出的网络组件的IP地址与所述VTEP位于不同vDC内，则向所述VTEP和该网络组件接入的VTEP下发转发表项，其中，
向所述VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该网络组件的IP地址，下一跳为该网络组件接入的VTEP，VxLAN ID为该网络组件所在的subnet的VxLAN ID；
向该网络组件接入的VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为发出所述DNS请求报文的VM的IP地址，下一跳为所述VTEP，VxLAN ID为所述VTEP所在的subnet的VxLAN ID。
6.一种域名管理装置，位于基于SDN+VxLAN的Openstack Neutron网络内的SDN控制器上，其特征在于，该装置包括：
域名配置模块：将每个网络组件的域名与该网络组件的IP地址的对应关系保存在域名系统DNS配置列表中，其中，网络组件之间具有层级关系，网络组件的域名由该网络组件的标识及该网络组件在网络中的层位置信息组成；
域名解析模块：接收VxLAN隧道端点VTEP发来的DNS请求报文，根据DNS配置列表，将该报文中的网络组件的域名解析成网络组件的IP地址，将该网络组件的IP地址携带在DNS应答报文中返回给所述VTEP，其中，所述DNS请求报文为所述VTEP下挂的主机要访问一网络组件时发给所述VTEP的。
7.根据权利要求6所述的装置，其特征在于，所述域名配置模块保存的网络组件的标识满足：同一网络层内的任意两个网络组件的标识不同；
所述网络组件包括：主机或者进行负载分担的主机集合、子网Subnet、虚拟数据中心vDC三层，且主机和进行负载分担的主机集合的层级相同且层级最低，subnet的层级次低，vDC的层级最高。
8.根据权利要求6所述的装置，其特征在于，所述域名解析模块将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步用于，
发现解析出的网络组件的IP地址为能够进行负载分担的多个主机的IP地址，则根据预设的负载分担算法，在该多个IP地址中选择一个，确定将所选择的IP地址携带在所述DNS应答报文中。
9.根据权利要求6所述的装置，其特征在于，所述域名解析模块将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步用于，
发现该网络组件的IP地址为subnet的组播IP地址，则根据自身维护的整网拓扑信息，计算出该组播IP地址对应的组播转发表项，将该组播转发表项发送给所述VTEP，该组播转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该组播IP地址，下一跳为该组播IP地址对应的subnet内的所有VTEP，VxLAN ID为该组播IP地址对应的subnet的VxLAN ID。
10.根据权利要求6所述的装置，其特征在于，所述域名解析模块将该报文中的网络组件的域名解析成网络组件的IP地址之后进一步用于，
根据自身维护的整网拓扑信息，发现解析出的网络组件的IP地址与所述VTEP位于不同vDC内，则向所述VTEP和该网络组件接入的VTEP下发转发表项，其中，
向所述VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为该网络组件的IP地址，下一跳为该网络组件接入的VTEP，VxLAN ID为该网络组件所在的subnet的VxLAN ID；
向该网络组件接入的VTEP下发的转发表项的内容包括：
目的IP地址、下一跳和VxLAN ID，其中，目的IP地址为发出所述DNS请求报文的VM的IP地址，下一跳为所述VTEP，VxLAN ID为所述VTEP所在的subnet的VxLAN ID。
CN201510384764.XA 2015-06-30 2015-06-30 域名管理方法及装置 Active CN106331206B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510384764.XA CN106331206B (zh) 2015-06-30 2015-06-30 域名管理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510384764.XA CN106331206B (zh) 2015-06-30 2015-06-30 域名管理方法及装置

Publications (2)

Publication Number Publication Date
CN106331206A true CN106331206A (zh) 2017-01-11
CN106331206B CN106331206B (zh) 2019-08-23

Family

ID=57726426

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510384764.XA Active CN106331206B (zh) 2015-06-30 2015-06-30 域名管理方法及装置

Country Status (1)

Country Link
CN (1) CN106331206B (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106878193A (zh) * 2017-02-10 2017-06-20 新华三技术有限公司 一种负载分担方法及装置
CN106953945A (zh) * 2017-05-26 2017-07-14 北京奇虎科技有限公司 基于sdn实现的域名智能解析方法及装置、服务器
CN107995031A (zh) * 2017-11-22 2018-05-04 郑州市景安网络科技股份有限公司 一种sdn网络的建立方法、系统及相关装置
US20190005260A1 (en) * 2016-01-07 2019-01-03 Alibaba Group Holding Limited Method and system for isolating application data access
CN109729183A (zh) * 2018-05-16 2019-05-07 平安科技（深圳）有限公司 请求处理方法、装置、设备及存储介质
CN110620715A (zh) * 2018-06-20 2019-12-27 中国电信股份有限公司 虚拟扩展局域网通信方法、隧道端点和控制器
CN111213348A (zh) * 2017-10-11 2020-05-29 华为技术有限公司 数据中心系统中域名解析的方法、装置和系统
CN113518134A (zh) * 2021-07-09 2021-10-19 烽火通信科技股份有限公司 一种mesh组网下通过域名访问主路由器的方法与装置
CN114338817A (zh) * 2021-12-22 2022-04-12 中国人民银行清算总中心 多平面网络访问控制方法及多平面网络

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101730987A (zh) * 2007-05-07 2010-06-09 莫克纳公司 使用usb密钥来管理网络组件
CN103209121A (zh) * 2013-03-15 2013-07-17 中兴通讯股份有限公司 基于开放流协议的控制面设备的发现处理方法及装置
WO2014166551A1 (en) * 2013-04-12 2014-10-16 Nec Europe Ltd. Method and system for providing an information centric network
CN104734963A (zh) * 2015-03-24 2015-06-24 电子科技大学 一种基于SDN的IPv4和IPv6网络互连方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101730987A (zh) * 2007-05-07 2010-06-09 莫克纳公司 使用usb密钥来管理网络组件
CN103209121A (zh) * 2013-03-15 2013-07-17 中兴通讯股份有限公司 基于开放流协议的控制面设备的发现处理方法及装置
WO2014166551A1 (en) * 2013-04-12 2014-10-16 Nec Europe Ltd. Method and system for providing an information centric network
CN104734963A (zh) * 2015-03-24 2015-06-24 电子科技大学 一种基于SDN的IPv4和IPv6网络互连方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
李翔: "基于VXLAN和SDN的云数据中心解决方案", 《电子科学技术》 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190005260A1 (en) * 2016-01-07 2019-01-03 Alibaba Group Holding Limited Method and system for isolating application data access
US10831915B2 (en) * 2016-01-07 2020-11-10 Alibaba Group Holding Limited Method and system for isolating application data access
CN106878193B (zh) * 2017-02-10 2022-03-22 新华三技术有限公司 一种负载分担方法及装置
CN106878193A (zh) * 2017-02-10 2017-06-20 新华三技术有限公司 一种负载分担方法及装置
CN106953945A (zh) * 2017-05-26 2017-07-14 北京奇虎科技有限公司 基于sdn实现的域名智能解析方法及装置、服务器
CN111213348A (zh) * 2017-10-11 2020-05-29 华为技术有限公司 数据中心系统中域名解析的方法、装置和系统
CN107995031B (zh) * 2017-11-22 2021-02-23 郑州市景安网络科技股份有限公司 一种sdn网络的建立方法、系统及相关装置
CN107995031A (zh) * 2017-11-22 2018-05-04 郑州市景安网络科技股份有限公司 一种sdn网络的建立方法、系统及相关装置
WO2019218441A1 (zh) * 2018-05-16 2019-11-21 平安科技（深圳）有限公司 请求处理方法、装置、设备及存储介质
CN109729183A (zh) * 2018-05-16 2019-05-07 平安科技（深圳）有限公司 请求处理方法、装置、设备及存储介质
CN110620715A (zh) * 2018-06-20 2019-12-27 中国电信股份有限公司 虚拟扩展局域网通信方法、隧道端点和控制器
CN110620715B (zh) * 2018-06-20 2021-10-22 中国电信股份有限公司 虚拟扩展局域网通信方法、隧道端点和控制器
CN113518134A (zh) * 2021-07-09 2021-10-19 烽火通信科技股份有限公司 一种mesh组网下通过域名访问主路由器的方法与装置
CN114338817A (zh) * 2021-12-22 2022-04-12 中国人民银行清算总中心 多平面网络访问控制方法及多平面网络
CN114338817B (zh) * 2021-12-22 2023-11-10 中国人民银行清算总中心 多平面网络访问控制方法及多平面网络

Also Published As

Publication number Publication date
CN106331206B (zh) 2019-08-23

Similar Documents

Publication Publication Date Title
AU2019307597B2 (en) Multi-cloud connectivity using SRv6 and BGP
US11516037B2 (en) Methods to optimize multicast routing in overlay networks
US20210036951A1 (en) Segment routing with fast reroute for container networking
US10826829B2 (en) Scalable handling of BGP route information in VXLAN with EVPN control plane
US10374878B2 (en) Forwarding tables for virtual networking devices
CN106331206A (zh) 域名管理方法及装置
US10320664B2 (en) Cloud overlay for operations administration and management
US10348838B2 (en) Scaling service discovery in a micro-service environment
EP2982097B1 (en) Method and apparatus for exchanging ip packets among network layer 2 peers
CN103200069B (zh) 一种报文处理的方法和设备
US10530656B2 (en) Traffic replication in software-defined networking (SDN) environments
CN107113241B (zh) 路由确定方法、网络配置方法以及相关装置
US20150358232A1 (en) Packet Forwarding Method and VXLAN Gateway
US10237179B2 (en) Systems and methods of inter data center out-bound traffic management
CN105656796B (zh) 实现虚拟扩展局域网三层转发的方法和装置
US20150304117A1 (en) Automatic fabric multicast group selection in a dynamic fabric automation network architecture
US9716687B2 (en) Distributed gateways for overlay networks
US20190280979A1 (en) Flow-based local egress in a multisite datacenter
WO2021093372A1 (zh) 一种数据报文的处理方法、设备、存储介质及系统
CN105635190A (zh) 数据中心网络中的服务执行方法及装置
WO2024093064A1 (zh) 一种大规模多模态网络中标识管理及优化转发方法和装置
KR20230035674A (ko) 경로 광고 방법 및 관련 디바이스
US12003417B2 (en) Communication method and apparatus
US9853891B2 (en) System and method for facilitating communication
US20240205184A1 (en) MEDIA ACCESS CONTROL (MAC) ADDRESS ASSIGNMENT FOR VIRTUAL NETWORK INTERFACE CARDS (VNICs)

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information
CB02 Change of applicant information

Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Applicant after: Xinhua three Technology Co., Ltd.

Address before: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Applicant before: Huasan Communication Technology Co., Ltd.

GR01 Patent grant
GR01 Patent grant