CN112769698B - 一种路由实现方法和装置 - Google Patents
一种路由实现方法和装置 Download PDFInfo
- Publication number
- CN112769698B CN112769698B CN202110013699.5A CN202110013699A CN112769698B CN 112769698 B CN112769698 B CN 112769698B CN 202110013699 A CN202110013699 A CN 202110013699A CN 112769698 B CN112769698 B CN 112769698B
- Authority
- CN
- China
- Prior art keywords
- target
- ospf
- user space
- routing protocol
- routing
- 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.)
- Active
Links
Images
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/12—Shortest path evaluation
-
- 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/026—Details of "hello" or keep-alive messages
-
- 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
本发明公开了一种路由实现方法,所述方法包括:所述代理用户空间接收所述路由协议端通过代理传输通道发送的目标hello报文;根据所述目标hello报文查找目标发包端口,并通过所述目标发包端口向交换机发送所述目标hello报文;接收所述交换机反馈的目标应答报文,并将所述目标应答报文经所述代理传输通道发送至所述路由协议端,以使得所述路由协议端基于所述目标应答报文更新路由信息。本申请提供的技术方案,可以在DPDK产品中实现OSPF动态路由协议。
Description
技术领域
本发明涉及互联网技术领域,特别涉及一种路由实现方法和装置。
背景技术
随着云计算的快速发展,多租户技术在数据中心中得到越来越多的运用。通过使用多租户技术,可以在共用的数据中心中,通过单一的系统架构为多个客户端提供相同的或者定制化的服务,并且还可以在各个客户端之间实现数据的隔离。
为扩展云端业务,人们引入了OSPF(Open Shortest Path First,开放式最短路径优先)等动态路由协议,以实现业务的横向扩展。然而基于传统内核的动态路由协议方案,多租户的实现依赖于Linux的网络隔离底层技术,通常一个租户对应一个命名空间,然后在每个命名空间中为每个租户启动一个OSPFD进程和一个Zebra进程,这种部署方式虽然可以实现用户的安全隔离,但为每个租户各启动一个OSPFD进程与一个Zebra进程,会极大的消耗系统资源。同时在NFV(Network Functions Virtualization,网络功能虚拟化)等高性能场景中,将产品进行DPDK(Data Plane Development Kit,数据平面开发套件)化成为一种趋势,而DPDK技术绕过了Linux的内核协议栈,因此基于内核命名空间的OSPF动态路由方案也无法应用于NFV等高性能场景中。
鉴于此,有必要提供一种新的路由实现方法和装置以解决上述不足。
发明内容
本申请的目的在于提供一种路由实现方法和装置,可以在DPDK产品中实现OSPF动态路由协议。
为实现上述目的,本申请一方面提供一种路由实现方法,所述方法应用于DPDK服务器中,所述DPDK服务器中配置有路由协议端和负载均衡端,其中所述负载均衡端设置有代理用户空间,所述方法包括:所述代理用户空间接收所述路由协议端通过代理传输通道发送的目标hello报文;根据所述目标hello报文查找目标发包端口,并通过所述目标发包端口向交换机发送所述目标hello报文;接收所述交换机反馈的目标应答报文,并将所述目标应答报文经所述代理传输通道发送至所述路由协议端,以使得所述路由协议端基于所述目标应答报文更新路由信息。
为实现上述目的,本申请另一方面还提供一种路由装置,所述装置应用于DPDK服务器中,所述DPDK服务器中配置有路由协议端和负载均衡端,其中所述负载均衡端设置有代理用户空间,所述装置包括:传输通道模块,用于使所述代理用户空间接收所述路由协议端通过代理传输通道发送的目标hello报文;信息中转模块,用于根据所述目标hello报文查找目标发包端口,并通过所述目标发包端口向交换机发送所述目标hello报文,以及接收所述交换机反馈的目标应答报文,并将所述目标应答报文经所述代理传输通道发送至所述路由协议端,以使得所述路由协议端基于所述目标应答报文更新路由信息。
为实现上述目的,本申请另一方面还提供一种路由装置,所述路由装置包括存储器和处理器,所述存储器用于存储计算机程序,当所述计算机程序被所述处理器执行时,实现上述路由的方法。
由此可见,本申请提供的技术方案,DPDK服务器中设置有路由协议端和负载均衡端,其中路由协议端设置有唯一的OSPF主进程,负载均衡端设置有多个访问用户空间(即多个租户)和用于与外界交换机进行信息交互的代理用户空间。上述OSPF主进程可以基于各个访问用户空间的OSPF配置文件生成相应的OSPF控制报文,然后通过设置在负载均衡端和路由协议端之间的代理传输通道传递上述OSPF控制报文,当OSPF控制报文到达负载均衡端后,代理用户空间可以基于OSPF控制报文携带的信息查找发包端口,然后将其发送至交换机,交换机接收到上述OSPF控制报文后便可以与代理用户空间建立邻居关系。代理用户空间专用于与交换机对接,交换机反馈的应答报文也将通过代理用户空间被发送至路由协议端,从而使得OSPF主进程可以根据上述应答报文中携带的信息查找相应的OSPF实例,然后将上述应答报文放入相应的OSPF处理逻辑中,以更新路由信息。在上述过程中,OSPF协议的运行和多租户的负载均衡是分隔开的,这就规避了OSPF动态路由协议无法适用于NFV场景的问题,而在建立OSPF邻居的过程中,所有的OSPF控制报文都经代理用户空间中转,路由协议端并不直接与交换机交互OSPF控制报文,这样就可以采用单一的OSPF进程实现多个租户的OSPF实例,既可以解决物理交换机OSPF进程数量的限制瓶颈,又可以减少运维成本和系统资源,使之更适用于NFV场景。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施方式中路由实现方法的整体框架图;
图2是本申请实施方式一中路由实现方法的流程图;
图3是本申请实施方式中路由装置的功能模块示意图;
图4是本申请实施方式中路由装置的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
随着云计算的快速发展,多租户技术在数据中心中得到越来越多的运用。通过使用多租户技术,可以在共用的数据中心中,通过单一的系统架构为多个客户端提供相同的或者定制化的服务,并且还可以在各个客户端之间实现数据的隔离。
然而现有的云产品大都采用主备的方式,这就使得当单点遇到瓶颈之后,产品难以进行业务的扩展,为此人们引入了OSPF等动态路由协议,以实现业务的横向扩展。但是像OSPF这种基于传统内核的动态路由协议方案,多租户的实现依赖于Linux的网络隔离底层技术,在实际应用中,通常一个租户对应一个命名空间,然后在每个命名空间中为每个租户启动一个OSPFD进程和一个Zebra进程,这种部署方式虽然可以实现用户的安全隔离,但为每个租户各启动一个OSPFD进程与一个Zebra进程,会极大的消耗系统资源,并且分布式的部署也极大的增加了运维的难度。
同时在NFV等高性能场景中,利用DPDK技术实现用户态的多租户隔离成为一种趋势,由于DPDK技术绕过了Linux的内核协议栈,因此Linux命名空间技术已经不再适用于高性能的NFV场景,基于内核命名空间的OSPF动态路由方案也就无法应用于NFV等高性能场景中。并且在实际应用中,公网与内网之间的数据流量需要经过物理交换机,而在有些交换机上可以同时运行的OSPF进程存在数量限制,这显然无法满足数以千计的租户要求。
因此,如何在DPDK产品中实现OSPF动态路由协议,并解决物理交换机的OSPF进程数量的限制,便成为本领域亟需解决的课题。
本申请提供的技术方案可以解决上述不足。
为便于理解本申请中涉及到的OSPF动态路由协议以及DPDK技术的内容,下面对其进行简要介绍。
OSPF动态路由协议是一个内部网关协议(Interior Gateway Protocol),是对链路状态路由协议的一种实现。OSPF动态路由协议在实现动态选路时,需要经过三个阶段,即邻居发现,通过发送hello报文形成邻居关系;路由通告,邻居间发送链路状态信息形成邻接关系;路由计算,根据最短路径算法算出路由表。
如果两台路由器位于同一条数据链路上,并且它们根据互相的hello报文中指定的某些信息(比如id等)协商成功,那么它们就建立了邻居关系。两台邻居路由器之间再相互发送链路状态信息(Link State Advertisement,LSA)形成邻接关系,每一台路由器都会在所有形成邻接关系的邻居之间发送LSA,LSA描述了路由器所有的链路、接口、邻居等信息。每一台接收到来自邻居路由器发送的LSA的路由器都会把这些信息记录在它的链路状态数据库(Link State DataBase,LSDB)中,并且发送一份LSA的拷贝给该路由器的其他所有邻居,这样当LSA传播到整个区域后,区域内所有的路由器都会形成同样的LSDB。当这些路由器的LSDB完全相同时,每一台路由器都会以自身为根结点,使用最短路径算法(Shortest Path First,SPF)计算一个无环路的拓扑图,这个拓扑图就是SPF算法树,每台路由器都会从自己的SPF算法树中构建出自己的路由表,用于动态选路,如果网络拓扑发生了变化,比如有节点故障或者新增节点,那么各个路由器将重新开始交换信息并计算路由。
DPDK是一个用来进行数据包加速处理的软件库,DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包,其绕过了Linux内核协议栈直接在用户态收发包,可以解决网络IO瓶颈。DPVS是基于DPDK技术和Linux虚拟服务器技术(LVS)开发的负载均衡软件,是一种高性能第4层负载均衡器。
请参阅图1,为本申请实施方式中路由实现方法的整体框架图。
本申请提供的路由实现方法,应用于由交换机和DPDK服务器组成的物理架构中,DPDK服务器中设置有路由协议端和负载均衡端,其中,路由协议端采用FRR(FRRouting)路由协议套件,负载均衡端采用DPVS架构。
路由协议端主要包括OSPFD进程和Zebra进程,OSPFD进程用于实现OSPF协议;Zebra进程作为DPVS的一层抽象,用于获取DPVS的链路与路由状态信息,并向OSPFD进程提供上述信息,以使得OSPFD进程进行路由表更新、接口查找等工作,维护OSPF状态机。DPVS通过多租户隔离技术同时为多个用户提供服务,DPVS中设置有与外界交换机进行信息交互的代理用户空间(记为switch_ns),以及其他配置在DPDK服务器上的多个访问用户空间(记为qlbaas_n,n为正整数)。代理用户空间与交换机的信息交互包括OSPF控制报文交互和用户的真实数据流量交互,代理用户空间和OSPFD进程之间以代理的方式交互OSPF控制报文,同时代理用户空间在接收到交换机发送的用户真实数据流量后,可以按照数据流量中携带的IP地址,将上述数据流量导向对应的访问用户空间中,以实现负载均衡的效果。
请参阅图2,为本申请实施方式一中路由实现方法的流程图。
S101:所述代理用户空间接收所述路由协议端通过代理传输通道发送的目标hello报文。
在一个实施方式中,DPVS端可以为多个租户提供服务,因此需要为各个租户设置相应的DPVS配置文件,以在DPVS端创建相应的用户空间资源。
以代理用户空间为例,其DPVS配置文件可以为:
同时,DPVS端还需要向Zebra进程提供接口,从而使得Zebra进程可以获取到DPVS端的interface/router/addr等信息。在实际应用中,DPVS端向Zebra进程提供接口可以通过如下方式实现:
(1)SOCKOPT_GET_IFADDR_SHOW
通过该接口向Zebra进程提供addr信息。
(2)SOCKET_NETIF_GET_PORT_BASIC
通过该接口向Zebra进程提供interface信息。
(3)SOCKET_GET_ROUTE_SHOW
通过该接口向Zebra进程提供router信息。
这样,当Zebra进程启动后,Zebra进程便可以调用DPVS端提供的接口,进而获取到DPVS端的链路与路由状态信息,当Zebra进程获取到上述信息后,可以将其发送给OSPFD进程,以供OSPFD进程维护其状态机。
在一个实施方式中,路由协议端可以配置一个OSPFD进程,并且为运行在DPVS端的每一个租户对应设置一个OSPFD配置文件,上述OSPFD配置文件中至少包括该租户的虚拟IP和用户名称。当设置在路由协议端的OSPFD进程启动后,该OSPFD进程可以加载各个租户的OSPFD配置文件,进而产生与各个租户相对应的OSPF控制报文(例如hello报文),这样便可以通过一个OSPFD进程实现多个OSPF实例。当路由协议端产生OSPF控制报文后,路由协议端可以通过代理传输通道将其发送至代理用户空间,然后通过代理用户空间将上述OSPF控制报文发送至交换机,在此过程中,路由协议端和交换机之间并不直接交互OSPF控制报文,而是通过代理用户空间中转OSPF控制报文。由于所有的OSPF控制报文都通过代理用户空间发送至交换机,因此交换机上可以只设置一个OSPFD进程,用于与代理用户空间交互OSPF控制报文,这就解决了物理交换机的OSPF进程数量的限制。
在实际应用中,代理用户空间的OSPFD配置文件可以为:
交换机的OSPFD配置文件可以为:
#interface Vlanif1
#ip address 192.168.1.2 255.255.255.0
#ospf dr-priority 255
#ospf 1router-id 192.168.1.2area 0.0.0.0
#network 192.168.1.0 0.255.255.255
在一个实施方式中,为通过代理用户空间中转OSPF控制报文,负载均衡端和路由协议端之间需要建立代理传输通道,在负载均衡端和路由协议端之间建立代理传输通道可以通过如下方式实现:
首先,在路由协议端建立第一监听端口,并在负载均衡端建立第二监听端口;然后,基于上述第一监听端口和上述第二监听端口建立代理传输通道。
在实际应用中,OSPFD进程可以创建socket以建立第一监听端口(例如,127.0.0.1:600),同时DPVS端可以在内部创建socket以建立第二监听端口(例如,127.0.0.3:600)。在建立第一监听端口和第二监听端口后,负载均衡端和路由协议端便可以通过上述第一监听端口和第二监听端口传递OSPF控制报文,其中,第一监听端口用以接收代理用户空间发往OSPFD进程的OSPF控制报文,第二监听端口用以接收OSPFD进程发往代理用户空间的OSPF控制报文。
以OSPFD进程向代理用户空间发送信息为例对代理交互进行说明:假设OSPFD进程向代理用户空间发送的实际报文为:192.168.2.1->224.0.0.5,那么OSPFD进程可以根据第一监听端口和第二监听端口的端口信息,重新封装上述实际报文,将其封装为127.0.0.1->127.0.0.3:600。此时,实际报文变成重新封装的报文的数据内容,而重新封装的报文将按照新的路由路径(即代理传输通道)到达代理用户空间,当代理用户空间接收到上述重新封装的报文后,通过解封装便可以得到实际报文,即192.168.2.1->224.0.0.5。
在一个实施方式中,代理用户空间接收路由协议端通过代理传输通道发送的目标hello报文之前,路由协议端可以首先判断负载均衡端的链路是否正常,具体的,OSPFD进程可以通过Zebra进程提供的链路信息,判断DPVS端的链路是否正常。如果负载均衡端链路正常,那么OSPFD进程可以根据上述多个租户(即访问用户空间)中任意一个租户(即目标访问用户空间)的OSPFD配置文件,以sendmsg中的双缓冲结构创建由第一监听端口指向第二监听端口的目标hello报文。目标hello报文的双缓冲结构具有如下形式:
在上述报文结构中,第一部分缓冲内容保存有实际的数据报文,第二部分缓冲内容保存有OSPF控制报文。
S102:根据所述目标hello报文查找目标发包端口,并通过所述目标发包端口向交换机发送所述目标hello报文。
在一个实施方式中,由于目标hello报文中封装有代理传输通道的端口信息,因此上述目标hello报文将通过代理传输通道发送至代理用户空间。当目标hello报文到达代理用户空间后,代理用户空间可以根据目标hello报文中的用户名称(即ns_name)信息和源地址(即saddr)信息,查找相应的发包端口(即目标发包端口),然后通过目标发包端口将上述目标hello报文发送至交换机,交换机在接收到目标hello报文后,便可以与代理用户空间建立邻居关系。当交换机与代理用户空间建立邻居关系后,代理用户空间可以将目标访问用户空间的虚拟IP通告给交换机,从而使得交换机可以学习到目标访问用户空间对应的路由信息。通过重复上述操作,代理用户空间可以将各个访问用户空间的虚拟IP通告给交换机,这样交换机便可以学习到各个访问用户空间对应的路由信息。
举例说明,假设switch_ns的OSPF配置文件为:
{
Network 1.1.1.1/24area 0(OSPFD管理IP)
Network 10.10.10.10/32area 0(虚拟IP)
}
交换机的OSPF配置文件为:
Network 1.1.1.2/24area 0(OSPFD管理IP)
那么,交换机可以学习到如下路由:
DEST GW Interface
10.10.10.10 1.1.1.1 2
如果交换机接收到一个发往目地的10.10.10.10的报文,那么下一跳将被指定为1.1.1.1,即数据将从交换机相应的端口发送出去,并被导向switch_ns。通过上述方式,可以在三层交换机上产生一条路由,将下一跳指定为switch_ns的管理IP,这样当外网发送的数据流量经过交换机后,所有的数据流量均会被交换机导向DPVS中的代理用户空间,即switch_ns。
S103:接收所述交换机反馈的目标应答报文,并将所述目标应答报文经所述代理传输通道发送至所述路由协议端,以使得所述路由协议端基于所述目标应答报文更新路由信息。
在一个实施方式中,当交换机接收到目标hello报文后,交换机可以向代理用户空间反馈目标应答报文,代理用户空间在接收到上述目标应答报文后,可以将目标应答报文经代理传输通道发送至路由协议端,具体的,代理用户空间可以基于第一监听端口和第二监听端口重新封装上述目标应答报文,以使得重新封装后的目标应答报文由第二监听端口指向第一监听端口。
在实际应用中,代理用户空间可以采用sendmsg中的双缓冲结构,将第一监听端口和第二监听端口的端口信息封装在目标应答报文中,并将其封装为127.0.0.3→127.0.0.1:600,从而使得重新封装后的目标应答报文由第二监听端口指向第一监听端口。
当路由协议端接收到代理用户空间发送的重新封装后的目标应答报文后,设置在路由协议端的OSPFD进程可以通过解封装得到实际的OSPF控制报文,然后根据上述目标应答报文中的ns_name信息,通过哈希算法查询与目标访问用户空间相对应的OSPF实例(即目标OSPF实例)。在查找到目标OSPF实例后,上述OSPFD进程可以运行目标OSPF实例,并将解封装得到的实际OSPF控制报文放入相应的OSPF处理逻辑中,然后根据解析得到的recv_ifp信息获取ospf_interface接口状态信息(即目标访问用户空间的接口状态),进而根据目标访问用户空间的接口状态更新目标访问用户空间的路由信息,以完成OSPF控制报文的梳理过程。
在一个实施方式中,由于为各个访问用户空间分配的虚拟IP具有唯一性,因此可以利用各个访问用户空间的虚拟IP进行数据流量的负载均衡。具体的,代理用户空间可以获取并解析各个访问用户空间的OSPFD配置文件,然后根据解析的结果获取各个访问用户空间的用户名称和对应的虚拟IP,进而根据上述用户名称和虚拟IP之间的映射关系,建立端口映射表。当代理用户空间接收到交换机发送的携带有目的IP的数据流后,代理用户空间便可以基于上述端口映射表查询与上述目的IP相对应的目的用户名称,然后将上述数据流导向与目的用户名称相对应的目的访问用户空间(即qlbaas_n)中,从而完成数据流量的负载均衡工作。
由于OSPF协议与接口的状态有关,而当链路发生变化时(例如接口UP、DOWN,或者40s没有收到OSPF组播包等),都会引起OSPFD进程添加或者删除相应的路由,因此在一个实施方式中,可以在DPVS内部设置定时器,以定期更新各个访问用户空间的路由信息。具体的,可以为代理用户空间设置更新周期(例如3s),这样每间隔3s,代理用户空间都将遍历并解析各个访问用户空间的OSPFD配置文件,然后根据解析的结果获取各个访问用户空间最新的虚拟IP,并根据上述最新的虚拟IP,更新端口映射表,从而保证代理用户空间可以正常执行后继的负载均衡工作。
请参阅图3,本申请还提供一种路由装置,所述装置应用于DPDK服务器中,所述DPDK服务器中配置有路由协议端和负载均衡端,其中所述负载均衡端设置有代理用户空间,所述装置包括:
传输通道模块,用于使所述代理用户空间接收所述路由协议端通过代理传输通道发送的目标hello报文;
信息中转模块,用于根据所述目标hello报文查找目标发包端口,并通过所述目标发包端口向交换机发送所述目标hello报文,以及接收所述交换机反馈的目标应答报文,并将所述目标应答报文经所述代理传输通道发送至所述路由协议端,以使得所述路由协议端基于所述目标应答报文更新路由信息。
在一个实施方式中,代理传输通道建立过程包括:
在所述路由协议端建立第一监听端口,并在所述负载均衡端建立第二监听端口;
基于所述第一监听端口和所述第二监听端口建立所述代理传输通道。
在一个实施方式中,所述装置还包括:
链路判断模块,用于判断所述负载均衡端链路是否正常,若所述负载均衡端链路正常,则基于所述多个访问用户空间中任意一个目标访问用户空间的OSPFD配置文件,创建由所述第一监听端口指向所述第二监听端口的所述目标hello报文。
在一个实施方式中,所述信息中转模块,还用于基于所述第一监听端口和所述第二监听端口重新封装所述目标应答报文,以使得重新封装后的所述目标应答报文由所述第二监听端口指向所述第一监听端口。
在一个实施方式中,所述路由协议端基于所述目标应答报文更新路由信息包括:
根据所述目标应答报文查询所述目标访问用户空间对应的目标OSPF实例;
运行所述目标OSPF实例,以通过所述目标应答报文获取所述目标访问用户空间的接口状态,并基于所述接口状态更新所述目标访问用户空间的路由信息。
在一个实施方式中,所述装置还包括:
关系表模块,用于解析各个所述访问用户空间的OSPFD配置文件,以获取各个所述访问用户空间的用户名称和虚拟IP,并基于所述用户名称和所述虚拟IP之间的映射关系,建立端口映射表。
在一个实施方式中,所述装置还包括:
数据分流模块,用于接收所述交换机发送的携带有目的IP的数据流,并基于所述端口映射表查询与所述目的IP相对应的目的用户名称,以将所述数据流导向与所述目的用户名称相对应的目的访问用户空间中。
请参阅图4,本申请还提供一种路由装置,所述路由装置包括存储器和处理器,所述存储器用于存储计算机程序,当所述计算机程序被所述处理器执行时,可以实现如上述的路由实现方法。具体地,在硬件层面,该路由装置可以包括处理器、内部总线和存储器。所述存储器可以包括内存以及非易失性存储器。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行。本领域普通技术人员可以理解,图4所示的结构仅为示意,其并不对上述路由装置的结构造成限定。例如,所述路由装置还可包括比图4中所示更多或者更少的组件,例如还可以包括其他的处理硬件,如GPU(Graphics Processing Unit,图像处理器),或者对外通信端口等。当然,除了软件实现方式之外,本申请并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等。
本实施方式中,所述的处理器可以包括中央处理器(CPU)或图形处理器(GPU),当然也可以包括其他的具有逻辑处理能力的单片机、逻辑门电路、集成电路等,或其适当组合。本实施方式所述的存储器可以是用于保存信息的记忆设备。在数字系统中,能保存二进制数据的设备可以是存储器;在集成电路中,一个没有实物形式的具有存储功能的电路也可以为存储器,如RAM、FIFO等;在系统中,具有实物形式的存储设备也可以叫存储器等。实现的时候,该存储器也可以采用云存储器的方式实现,具体实现方式,本说明书不做限定。
需要说明的是,本说明书中的路由装置,具体的实现方式可以参照方法实施方式的描述,在此不作一一赘述。
由此可见,本申请提供的技术方案,DPDK服务器中设置有路由协议端和负载均衡端,其中路由协议端设置有唯一的OSPF主进程,负载均衡端设置有多个访问用户空间(即多个租户)和用于与外界交换机进行信息交互的代理用户空间。上述OSPF主进程可以基于各个访问用户空间的OSPF配置文件生成相应的OSPF控制报文,然后通过设置在负载均衡端和路由协议端之间的代理传输通道传递上述OSPF控制报文,当OSPF控制报文到达负载均衡端后,代理用户空间可以基于OSPF控制报文携带的信息查找发包端口,然后将其发送至交换机,交换机接收到上述OSPF控制报文后便可以与代理用户空间建立邻居关系。代理用户空间专用于与交换机对接,交换机反馈的应答报文也将通过代理用户空间被发送至路由协议端,从而使得OSPF主进程可以根据上述应答报文中携带的信息查找相应的OSPF实例,然后将上述应答报文放入相应的OSPF处理逻辑中,以更新路由信息。在上述过程中,OSPF协议的运行和多租户的负载均衡是分隔开的,这就规避了OSPF动态路由协议无法适用于NFV场景的问题,而在建立OSPF邻居的过程中,所有的OSPF控制报文都经代理用户空间中转,路由协议端并不直接与交换机交互OSPF控制报文,这样就可以采用单一的OSPF进程实现多个租户的OSPF实例,既可以解决物理交换机OSPF进程数量的限制瓶颈,又可以减少运维成本和系统资源,使之更适用于NFV场景。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件来实现。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种路由实现方法,其特征在于,所述方法应用于DPDK服务器中,所述DPDK服务器中配置有路由协议端和负载均衡端,其中所述路由协议端配置有唯一的OSPFD进程,所述负载均衡端设置有代理用户空间和多个访问用户空间,所述方法包括:
所述代理用户空间接收所述路由协议端通过代理传输通道发送的目标hello报文,其中,所述目标hel lo报文由所述OSPFD进程加载所述多个访问用户空间中任意一个目标访问用户空间的OSPFD配置文件生成;
根据所述目标hello报文查找目标发包端口,并通过所述目标发包端口向交换机发送所述目标hello报文;
接收所述交换机反馈的目标应答报文,并将所述目标应答报文经所述代理传输通道发送至所述路由协议端,以使得所述路由协议端基于所述目标应答报文更新路由信息。
2.根据权利要求1所述的方法,其特征在于,代理传输通道建立过程包括:
在所述路由协议端建立第一监听端口,并在所述负载均衡端建立第二监听端口;
基于所述第一监听端口和所述第二监听端口建立所述代理传输通道。
3.根据权利要求2所述的方法,其特征在于,在所述代理用户空间接收所述路由协议端通过所述代理传输通道发送的目标hello报文之前,所述方法还包括:
判断所述负载均衡端链路是否正常,若所述负载均衡端链路正常,则基于所述多个访问用户空间中任意一个目标访问用户空间的OSPFD配置文件,创建由所述第一监听端口指向所述第二监听端口的所述目标hello报文。
4.根据权利要求3所述的方法,其特征在于,将所述目标应答报文经所述代理传输通道发送至所述路由协议端包括:
基于所述第一监听端口和所述第二监听端口重新封装所述目标应答报文,以使得重新封装后的所述目标应答报文由所述第二监听端口指向所述第一监听端口。
5.根据权利要求4所述的方法,其特征在于,所述路由协议端基于所述目标应答报文更新路由信息包括:
根据所述目标应答报文查询所述目标访问用户空间对应的目标OSPF实例;
运行所述目标OSPF实例,以通过所述目标应答报文获取所述目标访问用户空间的接口状态,并基于所述接口状态更新所述目标访问用户空间的路由信息。
6.根据权利要求1所述的方法,其特征在于,所述方法还包括:
解析各个所述访问用户空间的OSPFD配置文件,以获取各个所述访问用户空间的用户名称和虚拟IP;
基于所述用户名称和所述虚拟IP之间的映射关系,建立端口映射表。
7.根据权利要求6所述的方法,其特征在于,在建立端口映射表之后,所述方法还包括:
设置更新周期,以使得所述代理用户空间基于所述更新周期遍历各个所述访问用户空间的OSPFD配置文件,以更新所述端口映射表。
8.根据权利要求6所述的方法,其特征在于,在所述路由协议端基于所述目标应答报文更新路由信息之后,所述方法还包括:
接收所述交换机发送的携带有目的IP的数据流;
基于所述端口映射表查询与所述目的IP相对应的目的用户名称,以将所述数据流导向与所述目的用户名称相对应的目的访问用户空间中。
9.一种路由装置,其特征在于,所述装置应用于DPDK服务器中,所述DPDK服务器中配置有路由协议端和负载均衡端,其中所述路由协议端配置有唯一的OSPFD进程,所述负载均衡端设置有代理用户空间和多个访问用户空间,所述装置包括:
传输通道模块,用于使所述代理用户空间接收所述路由协议端通过代理传输通道发送的目标hello报文,其中,所述目标hello报文由所述OSPFD进程加载所述多个访问用户空间中任意一个目标访问用户空间的OSPFD配置文件生成;
信息中转模块,用于根据所述目标hello报文查找目标发包端口,并通过所述目标发包端口向交换机发送所述目标hello报文,以及接收所述交换机反馈的目标应答报文,并将所述目标应答报文经所述代理传输通道发送至所述路由协议端,以使得所述路由协议端基于所述目标应答报文更新路由信息。
10.一种路由装置,其特征在于,所述装置包括存储器和处理器,所述存储器用于存储计算机程序,当所述计算机程序被所述处理器执行时,实现如权利要求1至8中任一权利要求所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110013699.5A CN112769698B (zh) | 2021-01-06 | 2021-01-06 | 一种路由实现方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110013699.5A CN112769698B (zh) | 2021-01-06 | 2021-01-06 | 一种路由实现方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112769698A CN112769698A (zh) | 2021-05-07 |
CN112769698B true CN112769698B (zh) | 2022-12-02 |
Family
ID=75700196
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110013699.5A Active CN112769698B (zh) | 2021-01-06 | 2021-01-06 | 一种路由实现方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112769698B (zh) |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103825760B (zh) * | 2014-02-25 | 2017-06-06 | 新华三技术有限公司 | 一种基于ospf协议建立邻居关系的方法和装置 |
WO2016000107A1 (zh) * | 2014-06-30 | 2016-01-07 | 华为技术有限公司 | 动态路由设备的主备系统切换的方法及其装置 |
CN105049519B (zh) * | 2015-08-07 | 2018-07-17 | 北京思特奇信息技术股份有限公司 | 一种基于soap协议的消息路由方法和系统 |
CN110692268B (zh) * | 2017-01-25 | 2023-08-22 | 无线通信与技术公司 | 混合网状网络中的岛拓扑和路由 |
CN107483628B (zh) * | 2017-09-12 | 2020-09-18 | 网宿科技股份有限公司 | 基于dpdk的单向代理方法及系统 |
CN108881027B (zh) * | 2018-06-01 | 2020-04-10 | 武汉绿色网络信息服务有限责任公司 | 一种基于Linux系统实现路由器的radius报文转发方法和装置 |
CN110602262A (zh) * | 2018-06-13 | 2019-12-20 | 网宿科技股份有限公司 | 路由器及其处理数据报文的方法 |
CN111447144A (zh) * | 2020-04-01 | 2020-07-24 | 中核武汉核电运行技术股份有限公司 | 一种基于透明代理的应用路由方法 |
CN111756830A (zh) * | 2020-06-22 | 2020-10-09 | 浪潮云信息技术股份公司 | 公有云网络的内网负载均衡实现方法 |
CN111934939B (zh) * | 2020-09-17 | 2021-02-02 | 北京搜狐新媒体信息技术有限公司 | 一种网络节点故障检测方法、装置及系统 |
-
2021
- 2021-01-06 CN CN202110013699.5A patent/CN112769698B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN112769698A (zh) | 2021-05-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112470436B (zh) | 用于提供多云连通性的系统、方法、以及计算机可读介质 | |
EP4258598A1 (en) | Computing power application traffic forwarding method and apparatus | |
US9647954B2 (en) | Method and system for optimizing a network by independently scaling control segments and data flow | |
US10103902B1 (en) | Auto-discovery of replication node and remote VTEPs in VXLANs | |
WO2022007503A1 (zh) | 一种业务流量处理方法及装置 | |
CN113810206B (zh) | 一种网络自动化编排管理方法、实体、控制器及电子设备 | |
US11863454B2 (en) | Systems and methods for scalable validation of multiple paths in a network using segment routing | |
US20230231795A1 (en) | Method for Synchronizing Topology Information in SFC Network, and Routing Network Element | |
CN116633934A (zh) | 负载均衡方法、装置、节点及存储介质 | |
US20220166715A1 (en) | Communication system and communication method | |
US20230269164A1 (en) | Method and apparatus for sending route calculation information, device, and storage medium | |
CN110752989A (zh) | 一种东西向流量转发方法与装置 | |
CN107483628B (zh) | 基于dpdk的单向代理方法及系统 | |
CN112769698B (zh) | 一种路由实现方法和装置 | |
CN108900422B (zh) | 组播转发方法、装置及电子设备 | |
CN109600431B (zh) | 面向移动通信网路的内容增量传输方法、移动通信系统 | |
CN116530067A (zh) | 使用内部网关协议(interior gateway protocol,IGP)的边缘计算数据和服务发现 | |
WO2023169364A1 (zh) | 路由生成方法、数据报文的转发方法及装置 | |
Desmouceaux | Network-Layer Protocols for Data Center Scalability | |
CN115225634B (zh) | 虚拟网络下的数据转发方法、装置及计算机程序产品 | |
EP4246915A1 (en) | Routing advertisement method and device | |
CN116708508A (zh) | 一种网络靶场通信方法、装置、电子设备及存储介质 | |
CN117615017A (zh) | 算力请求方法、装置及系统 | |
CN117527876A (zh) | 建立连接的方法、装置及存储介质 | |
CN117118912A (zh) | 报文传输方法、网络设备和通信系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |