CN100421379C - 一种多点可达隧道通信的方法 - Google Patents
一种多点可达隧道通信的方法 Download PDFInfo
- Publication number
- CN100421379C CN100421379C CNB031568653A CN03156865A CN100421379C CN 100421379 C CN100421379 C CN 100421379C CN B031568653 A CNB031568653 A CN B031568653A CN 03156865 A CN03156865 A CN 03156865A CN 100421379 C CN100421379 C CN 100421379C
- Authority
- CN
- China
- Prior art keywords
- message
- access device
- address
- public
- private net
- 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.)
- Expired - Fee Related
Links
Images
Abstract
本发明涉及一种多点可达隧道通信的方法。一种多点可达隧道通信的方法,适用于多个私网接入的虚拟专用网,所述的多个私网通过接入设备连接于骨干网,所述的接入设备带有多点可达隧道接口,通过隧道接口的私网地址和公网地址的公私网地址映射表的标识,完成数据报文在接入设备间的传输;将所述虚拟专用网中的所有接入设备设置在一个组播组内;在接入设备间传送报文时,若发送方接入设备查看自身维护的公私网地址映射表不能发现接收方接入设备的公网地址,则以所述组播组的地址作为目的地址发送报文。本发明技术方案大大简化了VPN的配置管理,同时在没有固定公网地址的情况下依然可以构建VPN。
Description
技术领域
本发明涉及通信领域,尤其涉及一种多点可达隧道通信的方法。
技术背景
目前VPN已经得到了越来越多的应用。作为VPN的一种解决方案,隧道(Tunnel)技术有着广泛的应用。目前隧道技术已经由点到点演化到点到多点的方式。
多点可达的隧道技术如图1所示:
如图所示,Tunnel是一个虚拟的点到多点的连接。接入设备R1、R2,R3分别将Net1,Net2,Net3三个私网接入骨干网。R1,R2,R3各自有多点可达的Tunnel接口,假设他们的私网地址分别是pri_ip1,pri_ip2和pri_ip3,各自有一个骨干网可达的公网地址分别是g_ip1,g_ip2和g_ip3。从一个设备的一个Tunnel要到达不同的Tunnel对端,就要用不同的目的地址来封装,需要有如下的映射表:
表1设备、隧道和地址对应关系表:
接入设备 | R1 | R2 | R3 |
隧道 | Tunnel1 | Tunnel 2 | Tunnel 3 |
隧道上的私网地址 | pri_ip1 | Pri_ip2 | pri_ip3 |
骨干网可达的公网地址 | g_ip1 | g_ip2 | g_ip3 |
当骨干网由ISP等服务商提供,各个接入设备连接骨干网的地址也是ISP分配的。而为了节省投资,往往用户只申请动态的公网地址。这样每次连接的地址可能是不同的,无法静态配置。如何得到这样的映射表,需要提供特殊的解决方案。
现有的一种解决方案就是在这一组Tunnel隧道中,要求有一个必须分配固定的公网地址,作为Server,其他的可以分配动态的私网地址,作为Client。由于Server的地址是预先可以知道的,Client会主动把自己本次上线得到的动态私网地址等信息发送给Server;Server再把汇总得到的这些信息汇总成表1形式的映射表,再发送给各个Client,所有的节点就都有了这张映射关系表。
有时作为一个小企业,为节省投资,可能连一个固定的公网地址也没有申请,所有VPN节点都没有固定公网地址,都无法感知对方的存在,这样上面的C/S方案也无法应用。
发明内容
本发明的目的就是要提出一种方法,解决没有已知的固定公网地址时,无法建立多点隧道的问题。
为此,本发明采用如下方案:
一种多点可达隧道通信的方法,适用于多个私网接入的虚拟专用网,所述的多个私网通过接入设备连接于骨干网,所述的接入设备带有多点可达隧道接口,通过隧道接口的私网地址和公网地址的公私网地址映射表的标识,完成报文在接入设备间的传输;包括步骤:
将所述虚拟专用网中的所有接入设备设置在一个组播组内;
在接入设备间传送报文时,若发送方接入设备查看自身维护的公私网地址映射表不能发现接收方接入设备的公网地址,则以所述组播组的地址作为目的地址发送报文,所述报文中包含发送方接入设备的私网地址和公网地址以及接收方接入设备的私网地址;
与所述报文中的接收方接入设备私网地址一致的接收方接入设备接收该报文,并根据该报文中的信息更新自身维护的公私网地址映射表中的所述发送方接入设备的公私网地址映射关系。
所述的方法,接入设备间传送报文时,若发送方接入设备查看自身维护的公私网地址映射表能够知道接收方接入设备的公网地址,则以该查看到的公网地址作为目的地址发送报文。
所述的方法,还包括组播组的其他接入设备接收该报文的步骤,这些接入设备接收到该报文,根据该报文中的信息更新自身维护的公私网地址映射表。
所述的方法,还包括步骤:
接收方接入设备向发送方接入设备发送一响应报文,其中包括接收方接入设备的公网地址。
所述的方法,还包括步骤:
发送方接入设备接收该响应报文,并根据该报文中的信息更新自身维护的公私网地址映射表。
当公私网地址映射表更新后,在接入设备间传送报文时,发送方接入设备查看更新后的公私网地址映射表。
所述的报文是数据报文或者请求报文。
所述的报文,采用ARP协议的格式。
本发明技术方案大大简化了VPN的配置管理,同时在没有固定公网地址的情况下依然可以构建VPN。
附图说明
图1是现有技术中多点可达隧道技术组网图;
图2是本发明接入设备间传送数据报文的流程图;
图3是一个多点可达隧道的Tunnel ARP报文的示意图。
具体实施方式
下面结合说明书附图来说明本发明的具体实施方式。
本解决方案有一个前提,就是要求提供VPN接入的骨干网支持IP组播。由于目前基于组播的应用越来越多,大部分厂商提供的设备实际上都支持组播应用。
本解决方案的系统构成包括如图1所示网络,以3个接入设备为例。其中接入设备R1、R2,R3分别将Net1,Net2,Net3三个私网接入骨干网。R1,R2,R3各自有多点Tunnel接口,假设他们的私网地址分别是pri_ip1,pri_ip2和pri_ip3,各自有一个骨干网可达的公网地址分别是g_ip1,g_ip2和g_ip3,具体见表1。
我们可以称一个VPN中所有的接入设备为一个邻接组(Peer Group),它们彼此之间构成邻居关系,如R1、R2都是R3的Tunnel3上的邻居(Peer)。所有的这些Tunnel上的邻居所组成的连接多点可达的隧道连接。
图1中一个简单的数据传输过程可描述如下:
当Net1有数据要传送给Net2时,通过私网路由,数据报文发送给R1,R1根据自己的路由将报文发给Tunnel1接口;Tunnel1接口要根据路由表中的下一跳(Next Hop)地址pri_ip2,将数据用公网地址进行封装,封装的源公网地址为g_ip1,目的公网地址为g_ip2;这个报文再次查找公网路由,发送到R2;R2收到这个报文后,解封装,还原出原来的数据报文,再根据私网路由,发送给Net2。
在上述的过程中,要实现正确封装,就要建立一个公私网的映射表,如表2所示:
表2Tunnel的发送端要维护的一个公私网地址映射表(邻接表)
私网地址(Next Hop) | 对应的公网地址 | |
去往R1 | pri_ip1 | g_ip1 |
去往R2 | pri_ip2 | g_ip2 |
去往R3 | pri_ip3 | g_ip3 |
… | … | … |
当骨干网支持组播时,可以考虑采用组播的方式来实现。其工作原理类似于Ethernet上的ARP方式。如图2所示,是一个接入设备间传送数据报文的流程示意图,从图中可以看出,工作步骤如下:
将一个VPN的所有接入设备加入一个预先设定好的组播组G1。它们可以向这个组地址发送报文,也可以从这个组地址接收报文;
当一个接入设备R1要向R2发送报文时,它检查表2,如果知道pri_ip2对应的公网地址,则以该地址为目的地址发送数据,如果发现不知道pri_ip2对应的公网地址,这时,它用组播地址G1作为目的地址,发送一个请求(Request)报文,报文内携带pri_ip2,以及自己的pri_ip1、g_ip1等信息,向全网查询pri_ip2对应的g_ip2;
该组播报文经过骨干网的转发,最终会到达所有加入了这个组的VPN节点;
当R2收到这个报文后,确认自己是该请求数据报文的pri_ip2,会记录下这个信息,加入自己如表2形式的映射表中。同时,由于它已经从request报文中知道了R1的公网地址g_ip1和私网地址pri_ip1,它会向R1回一个单播封装的响应(Response)报文,报文内携带pri_ip2和g_ip2等信息;
其他不相关的节点收到这个请求后,发现不是请求自己的地址映射,它们只会记录R1的映射信息pri_ip1和g_ip1,不做其他处理;
当R1收到了来自R2的这个Response报文后,他就知道了pri_ip2和g_ip2的对应关系,更新自己的如表2形式的映射关系表;
此后,R1就可以通过Tunnel向R2发送数据了。
上述的Request和Response报文可以采用ARP协议的格式和含义,我们称之为Tunnel ARP报文,具体格式如下:
Delivery Header | Tunnel Header | Tunnel ARP Packet |
如图3所示,是一个多点可达隧道的Tunnel ARP报文的示意图,从图中可见,该硬件类型和协议类型的叫法实际上是沿用ARP上的名称,在这里硬件类型指承载协议(Delivery Protocol)的协议类型,在IP over IP的情况下就是0x0800,表示IP;协议类型指负载协议(Payload Protocol)的协议类型,在IP overIP的情况下也是0x0800;地址的长度这里指IPv4的地址长度,32bit即4字节;OP表示操作类型,1表示请求,2表示应答;最后4个字段,硬件地址就是指公网地址g_ip,协议地址就是指Tunnel上的私网地址pri_ip。在IP over IP的情况下,Deliver Header实际上就是IP头,在发送Request时,目的公网地址就用预先指定着组地址G,源公网地址就是发送端与Tunnel的私网地址对应的一个公网地址。
为了加快建立映射表的过程,每一个接入设备的Tunnel在配置好以后,就向组地址G发送免费Tunnel ARP报文ARP Response,宣布自己的存在,以定期刷新其邻居的映射表。
上述工作过程还可以采用另外的工作方式,即当一个接入设备的Tunnel配置好以后,定期向组地址G发送免费GRE ARP报文ARP Response,以定期刷新其映射表。当一个Tunnel在规定时间内没有收到其邻居的刷新报文,就认为邻居超时,从映射表中删除这一映射关系。
组播方式的好处是只需要预先配置一个组播组G就可以了,而且实际上也为所有的Tunnel之间通讯提供了一种广播的机制,效率高,并且为在支持RIP、OSPF等动态路由协议提供了方便。例如OSPF协议采用组播方式建立OSPF邻居时,可以直接将OSPF的组播协议报文封装在组播组G中,其效果等同于一个Ethernet那样的广播的网络。
作为一种VPN的解决方案,当连接骨干网的公网地址是固定的情况下,本方法同样适用。这样做还可以简化配置,只需配置一个组地址,而无须为每个VPN节点手工配置映射表。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求书的保护范围为准。
Claims (8)
1. 一种多点可达隧道通信的方法,适用于多个私网接入的虚拟专用网,所述的多个私网通过接入设备连接于骨干网,所述的接入设备带有多点可达隧道接口,通过隧道接口的私网地址和公网地址的公私网地址映射表的标识,完成报文在接入设备间的传输;其特征在于:
将所述虚拟专用网中的所有接入设备设置在一个组播组内;
在接入设备间传送报文时,若发送方接入设备查看自身维护的公私网地址映射表不能发现接收方接入设备的公网地址,则以所述组播组的地址作为目的地址发送报文,所述报文中包含发送方接入设备的私网地址和公网地址以及接收方接入设备的私网地址;
与所述报文中的接收方接入设备私网地址一致的接收方接入设备接收该报文,并根据该报文中的信息更新自身维护的公私网地址映射表中的所述发送方接入设备的公私网地址映射关系。
2. 如权利要求1所述的方法,其特征在于接入设备间传送报文时,若发送方接入设备查看自身维护的公私网地址映射表能够知道接收方接入设备的公网地址,则以该查看到的公网地址作为目的地址发送报文。
3. 如权利要求1所述的方法,其特征在于还包括组播组的其他接入设备接收该报文的步骤,这些接入设备接收到该报文,根据该报文中的信息更新自身维护的公私网地址映射表。
4. 如权利要求1所述的方法,其特征在于还包括步骤:
接收方接入设备向发送方接入设备发送一响应报文,其中包括接收方接入设备的公网地址。
5. 如权利要求4所述的方法,其特征在于还包括步骤:
发送方接入设备接收该响应报文,并根据该报文中的信息更新自身维护的公私网地址映射表。
6. 如权利要求5所述的方法,其特征在于当公私网地址映射表更新后,在接入设备间传送报文时,发送方接入设备查看更新后的公私网地址映射表。
7. 如权利要求1~6任意一项所述的方法,其特征在于所述的报文是数据报文或者请求报文。
8. 如权利要求1~6任意一项所述的方法,其特征在于所述的报文,采用ARP协议的格式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB031568653A CN100421379C (zh) | 2003-09-10 | 2003-09-10 | 一种多点可达隧道通信的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB031568653A CN100421379C (zh) | 2003-09-10 | 2003-09-10 | 一种多点可达隧道通信的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1595884A CN1595884A (zh) | 2005-03-16 |
CN100421379C true CN100421379C (zh) | 2008-09-24 |
Family
ID=34660113
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB031568653A Expired - Fee Related CN100421379C (zh) | 2003-09-10 | 2003-09-10 | 一种多点可达隧道通信的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100421379C (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100442775C (zh) | 2005-11-17 | 2008-12-10 | 华为技术有限公司 | 一种在MAC in MAC网络中实现组播的方法 |
CN101163088B (zh) * | 2007-07-31 | 2010-09-15 | 杭州华三通信技术有限公司 | 组播数据的传输方法和设备 |
CN101364888B (zh) * | 2008-09-16 | 2010-12-22 | 杭州华三通信技术有限公司 | 一种数据组播地址复用方法和一种骨干网边缘设备 |
CN104883287B (zh) * | 2014-02-28 | 2018-06-12 | 杭州迪普科技股份有限公司 | IPSec VPN系统控制方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001082097A1 (en) * | 2000-04-27 | 2001-11-01 | Fortress Technologies, Inc. | A method and apparatus for integrating tunneling protocols with standard routing protocols |
CN1324164A (zh) * | 2000-05-17 | 2001-11-28 | 日本电气株式会社 | 通信系统,通信控制方法和控制程序存储媒体 |
WO2003007561A1 (en) * | 2001-07-13 | 2003-01-23 | Ssh Communications Security Corp | Method for forming a secured network |
CN1505986A (zh) * | 2002-12-07 | 2004-06-23 | 蔡学富 | 鱼肉水饺 |
-
2003
- 2003-09-10 CN CNB031568653A patent/CN100421379C/zh not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001082097A1 (en) * | 2000-04-27 | 2001-11-01 | Fortress Technologies, Inc. | A method and apparatus for integrating tunneling protocols with standard routing protocols |
CN1324164A (zh) * | 2000-05-17 | 2001-11-28 | 日本电气株式会社 | 通信系统,通信控制方法和控制程序存储媒体 |
WO2003007561A1 (en) * | 2001-07-13 | 2003-01-23 | Ssh Communications Security Corp | Method for forming a secured network |
CN1505986A (zh) * | 2002-12-07 | 2004-06-23 | 蔡学富 | 鱼肉水饺 |
Non-Patent Citations (2)
Title |
---|
MPLS-VPN工作特性. 陈启美,张国强,薛健.电力自动化设备,第22卷第10期. 2002 |
MPLS-VPN工作特性. 陈启美,张国强,薛健.电力自动化设备,第22卷第10期. 2002 * |
Also Published As
Publication number | Publication date |
---|---|
CN1595884A (zh) | 2005-03-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100886433B1 (ko) | 확장된 브릿지를 이용한 무선통신 시스템에서의 IPv6지원 방법 | |
EP2708001B1 (en) | Label switched routing to connect low power network domains | |
CN101577722B (zh) | 实现强制mac转发功能的方法和装置 | |
CN101091357B (zh) | 网络中的路由操作控制方法、相关网络及其计算机程序 | |
CN101917707B (zh) | 无线传感器网络的ip寻址方法及系统 | |
US20140167979A1 (en) | Smart meter system, management router, and meter | |
CN107968750B (zh) | 报文传输方法、装置及节点 | |
CA2406051A1 (en) | Satellite routing protocol with dynamic ip addressing | |
CN102209121A (zh) | IPv6网络和IPv4网络之间互通的方法和装置 | |
JP2004120270A (ja) | 移動体通信装置及び移動体通信方法 | |
EP2115971A2 (en) | Multicast support by mobile routers in a mobile ad hoc network | |
CN102957589A (zh) | 业务数据传输的方法、网络节点及系统 | |
CN102694752A (zh) | 网关设备 | |
CN102959906B (zh) | 多归属站点内主机的路由选择方法和装置 | |
JP2006279168A (ja) | アドホック網を構成する通信装置、ブリッジ装置及び通信システム | |
CN102546407A (zh) | 报文发送方法及装置 | |
CN104618525B (zh) | 基于分层路由跨异构网络的无缝连接的方法 | |
CN102045249B (zh) | 一种网络通信中报文的转发方法和设备 | |
CN100421379C (zh) | 一种多点可达隧道通信的方法 | |
KR20160092645A (ko) | 식별자 및 위치자 분리 환경에서의 로컬 도메인 내 종단 호스트간의 통신 방법 및 시스템 | |
JP5976571B2 (ja) | 無線lanルータ | |
US7286542B2 (en) | Mobile communication network system, foreign agent router, address server and packet delivery method employed therein | |
CN102026330A (zh) | 一种提高自组织网络可用性的方法 | |
CN101494849B (zh) | 一种通信方法、系统及设备 | |
JP5465328B2 (ja) | 無線通信装置および無線通信方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080924 Termination date: 20150910 |
|
EXPY | Termination of patent right or utility model |