CN103944781A - 一种防止堆叠***单边***的方法及*** - Google Patents

一种防止堆叠***单边***的方法及*** Download PDF

Info

Publication number
CN103944781A
CN103944781A CN201410151728.4A CN201410151728A CN103944781A CN 103944781 A CN103944781 A CN 103944781A CN 201410151728 A CN201410151728 A CN 201410151728A CN 103944781 A CN103944781 A CN 103944781A
Authority
CN
China
Prior art keywords
keep
alive
local device
opposite equip
message
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
CN201410151728.4A
Other languages
English (en)
Other versions
CN103944781B (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.)
Maipu Communication Technology Co Ltd
Original Assignee
Maipu Communication Technology 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 Maipu Communication Technology Co Ltd filed Critical Maipu Communication Technology Co Ltd
Priority to CN201410151728.4A priority Critical patent/CN103944781B/zh
Publication of CN103944781A publication Critical patent/CN103944781A/zh
Application granted granted Critical
Publication of CN103944781B publication Critical patent/CN103944781B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种防止堆叠***单边***的方法及***,该方法主要包括:在虚拟交换链路中,本端设备与对端设备之间相互发送保活报文,收集对端设备的保活周期和最大保活次数;当本端设备发生***时,关闭与对端设备之间的虚拟交换链路,并同时启动定时器,所述对端设备检测到虚拟交换链路异常,则与本端设备进行决策***;定时器超时后,恢复关闭的虚拟交换链路。本发明所述方法及***能够保证堆叠***正常***,并且结合MAD等机制,可以避免不完全***对客户业务造成影响,增强了堆叠***故障恢复能力,特别是当硬件芯片无法做到Qos保证导致数据过载而丢包、远距离线路和中转设备较多无法保证线路质量时,效果特别明显。

Description

一种防止堆叠***单边***的方法及***
技术领域
本发明属于数据通信技术领域,具体涉及一种防止堆叠***单边***的方法及***的设计。
背景技术
随着宽带应用的普及和网络规模的不断增长,网络的整体速率不断提高,大吞吐数据交换和各种智能应用的需要也日益增加。为了满足大型网络对于端口数量的要求,通常利用堆叠技术将多台设备连接起来组成一个堆叠***(Stacking System,SS),这样不仅仅增加了端口数量,也简化了管理。堆叠***中的这些网络设备统称为堆叠***的成员设备。每两台成员设备之间建立的堆叠链路称为虚拟交换链路(VSL,Virtual Switching link),参与堆叠的多台成员设备中,其中一台设备为主设备(Master设备),其他设备都为从设备(Slave设备),其中Master设备为Active(活动)状态,充当管理者和控制者的角色,其配置生效,而Slave设备则为Standby(备用)状态,其配置不生效,作为备份设备。由于从设备都是主设备的备份设备,大大提高了网络的可靠性和稳定性。
在堆叠***中,如果虚拟交换链路出现故障,会造成堆叠******,然后通过MAD(Multi-Active Detection,多激活检测)关闭***出来的***的业务口,以保证部分***能够持续正常工作。但是,如果堆叠***中各成员设备间的虚拟交换链路由于数据过载、线路质量问题、软件处理异常等原因可能会造成一种现象:单边***;以最简单的两台设备堆叠为例,如图1所示,所谓单边***,就是指其中一台设备认为已经发生了***,设备已经从堆叠***中退出了,但是另一台设备却认为堆叠***完全正常,没有发生***。
如果是从设备认为自己***了,那么其会选举自己为主设备,此时堆叠***中出现两个主设备,多激活检测生效,用户业务不一定受到影响,只是由于主设备认为其从设备并没有***出去,所以其状态不正常,会出现报错,表项下发不成功等现象。
如果是主设备认为自己***了,从设备认为自己没有***,此时从设备就处于完全失控的状态了,如果此时主设备上更改配置等,很可能造成环路等问题,严重影响用户业务。
当前,业界主要是采用硬件Qos(Quality of Service,服务质量)软件优化保证不出现异常检测等方式来规避此问题,但是硬件芯片不支持无法保证线路质量,无法处理虚拟交换链路上数据过载,或因虚拟交换链路较远、转接设备很多等状况从而无法保证其每个环节都处理正常,因此当前没有一种好的方式一劳永逸地解决上述问题。由于实际环境中,虚拟交换链路的带宽都是小于用户业务带宽的,所以如果用户环境中跨成员设备数据很多,造成虚拟交换链路过载是很常见的事情,同时,不是所有的硬件和集成芯片都有完善的Qos保障,所以过载后数据很可能被丢弃,如果设备间虚拟交换链路保活报文被丢弃,且是单方向过载,则可能造成单边***现象。另外,如果堆叠的成员设备间的距离很远,中间有各种传输设备中转,那么我们不能保证所有的中间环节都处理正确,所以也可能出现单边***。
发明内容
本发明所要解决的技术问题是为了克服现有技术中堆叠***中产生的单边***的问题而提供一种防止堆叠***单边***的方法及***。
本发明解决其技术问题采用的技术方案是:一种防止堆叠***单边***的方法,包括如下步骤:
S1、在虚拟交换链路中,本端设备与对端设备之间相互发送保活报文,收集对端设备的保活周期和最大保活次数;
S2、当本端设备发生***时,关闭与对端设备之间的虚拟交换链路,并同时启动定时器,所述对端设备检测到虚拟交换链路异常,则与本端设备进行决策***;
S3、定时器超时后,恢复关闭的虚拟交换链路。
进一步的,所述步骤S1中保活报文包括:保活请求报文和保活响应报文,在堆叠***正常工作的情况下,堆叠***中各个成员设备之间组成虚拟交换链路的本端设备定时向对端设备发送保活请求报文,若本端设备在连续发送N次保活请求报文而未接收到对端设备发送的保活响应报文,则认为本端设备与该对端设备之间的虚拟交换链路发生异常,否则认为该虚拟交换链路工作正常。
更进一步的,所述保活报文包括:报文类型Type字段、序列号Seq字段、保活周期Time字段以及最大保活次数Count字段;所述Type字段用于表示当前发送的保活报文是保活请求报文还是保活响应报文;所述Seq字段用于表示发送的保活报文的序列号,每发送一次保活请求报文时,所述Seq字段的值加1。
更进一步的,所述N值为保活报文中Count字段的值,当本端设备发送的保活请求报文的序列号Seq和接收到的保活响应报文的序列号Seq之间差大于所述Count字段的值时,所述本端设备与对端设备之间的虚拟交换链路发生异常,则对端设备与本端设备进行决策***。
进一步的,所述步骤S2中,所述定时器的值为对端设备发送的保活报文中的保活周期Time×(最大保活次数Count+1)。
进一步的,所述步骤S2中,当本端设备发生***关闭与对端设备之间的虚拟交换链路时,本端设备的物理端口的状态为down;若本端设备与对端设备直接相连,则对端设备直接进行决策***;若所述本端设备与对端设备之间存在中转设备,则对端设备在定时器超时后与本端设备进行决策***。
本发明为解决技术问题还提供了一种防止堆叠***单边***的***,具体包括本端设备和对端设备,所述本端设备包括链路保活模块、***决策模块、链路管理模块以及定时模块;
所述链路保活模块,用于在虚拟交换链路中,本端设备与对端设备之间相互发送保活报文,收集对端设备的保活周期和最大保活次数;
所述***决策模块,用于决策本端设备是否应该从堆叠***中***;
所述链路管理模块,用于在本端设备发生***时,关闭与对端设备之间的虚拟交换链路,同时,检测虚拟交换链路物理端口状态;
所述定时模块,用于在定时器超时后,恢复关闭的虚拟交换链路。
进一步的,所述本端设备与对端设备之间相互发送的保活报文包括:保活请求报文和保活响应报文,在堆叠***正常工作的情况下,堆叠***中各个成员设备之间组成虚拟交换链路的本端设备定时向对端设备发送保活请求报文,若本端设备在连续发送N次保活请求报文而未接收到对端设备发送的保活响应报文,则认为本端设备与该对端设备之间的虚拟交换链路发生异常,否则认为该虚拟交换链路工作正常;
所述保活报文包括:报文类型Type字段、序列号Seq字段、保活周期Time字段以及最大保活次数Count字段;所述Type字段用于表示当前发送的保活报文是保活请求报文还是保活响应报文;所述Seq字段用于表示发送的保活报文的序列号,每发送一次保活请求报文时,所述Seq字段的值加1。
更进一步的,所述N值为保活报文中Count字段的值,当本端设备发送的保活请求报文的序列号Seq和接收到的保活响应报文的序列号Seq之间差大于所述Count字段的值时,所述本端设备与对端设备之间的虚拟交换链路发生异常,则对端设备与本端设备进行决策***。
进一步的,所述定时模块中定时器的值为对端设备发送的保活报文中的保活周期Time×(最大保活次数Count+1)。
本发明的有益效果:本发明一种防止堆叠***单边***的方法及***,通过在堆叠***的堆叠成员之间进行链路保活,在成员设备因线路过载、报文丢失而出现单边***的现象时能够与堆叠***完全***;在虚拟交换链路状态不稳定时,通过本发明方法及***能够保证堆叠***正常***,并且结合MAD等检测机制,可以避免不完全***对客户业务造成影响,增强了堆叠***故障恢复能力,特别是当硬件芯片无法做到Qos保证导致数据过载而丢包、远距离线路和中转设备较多无法保证线路质量时,效果特别明显。
附图说明
图1所示为本发明实施例的一种防止堆叠***单边***的方法的流程框图;
图2所示为本发明实施例中两台成员设备组成堆叠***的连接示意图;
图3所示为本发明实施例中四台成员设备组成堆叠***的连接示意图;
图4所示为本发明实施例中成员设备间存在中转设备时的堆叠***的连接示意图;
图5所示为本发明实施例的一种防止堆叠***单边***的***的示意框图。
具体实施方式
下面结合附图和具体的实施例对本发明作进一步的阐述。
如图1所示为本发明实施例的一种防止堆叠***单边***的方法的流程框图,包括如下步骤:
S1、在虚拟交换链路中,本端设备与对端设备之间相互发送保活报文,收集对端设备的保活周期和最大保活次数;
S2、当本端设备发生***时,关闭与对端设备之间的虚拟交换链路,并同时启动定时器,所述对端设备检测到虚拟交换链路异常,则与本端设备进行决策***;
S3、定时器超时后,恢复关闭的虚拟交换链路。
本发明实施例中的本端设备与对端设备是相对而言的,本端设备既可以是主设备也可以是从设备,对端设备既可以是主设备也可以是从设备。对于只有两台堆叠设备的堆叠***来说,本端设备与对端设备是指主设备与从设备之间互发保活报文;对于含有多台堆叠设备的堆叠***来说,本端设备与对端设备是针对相邻的成员设备而言的;本端设备与对端设备既可以是指主从设备之间互发保活报文,也可以是从设备与从设备之间互发保活报文;
本发明防止堆叠***单边***的方法,首先在堆叠***正常工作的情况下,对虚拟交换链路进行链路保活,通过在保活报文中携带保活周期和最大保活次数从而收集各成员设备的保活周期和最大保活次数;其次,当本端设备发生***时,则关闭对应的虚拟交换链路,并同时启动定时器,当定时器超时后,由于已经保证堆叠***彻底***了,此时开启虚拟交换链路的物理端口,恢复堆叠链路,使堆叠***合并,业务恢复。为了本领域技术人员能够理解并且实施本发明技术方案,下面将结合具体应用环境对本发明所述方法进行阐述:
所述步骤S1中保活报文包括:保活请求报文和保活响应报文,在堆叠***正常工作的情况下,堆叠***中各个成员设备之间组成虚拟交换链路的本端设备定时向对端设备发送保活请求报文,若本端设备在连续发送N次保活请求报文而未接收到对端设备发送的保活响应报文,则本端设备与该对端设备之间的虚拟交换链路发生异常,否则认为该虚拟交换链路工作正常;其中所述定时信息和所述N值都可由保活报文字段来设定,如表1所示为在本实施例中保活报文的格式:
表1-保活报文格式
Type Seq Time Count
上述保活报文包括:报文类型Type字段、序列号Seq字段、保活周期Time字段以及最大保活次数Count字段;所述Type字段用于表示当前发送的保活报文是保活请求报文还是保活响应报文;所述Seq字段用于表示发送的保活报文的序列号,每发送一次保活请求报文时,所述Seq字段的值加1。所述N值为保活报文中Count字段的值,当本端设备发送的保活请求报文的序列号Seq和接收到的保活响应报文的序列号Seq之间差大于所述Count字段的值时,所述本端设备与对端设备之间的虚拟交换链路发生异常,则对端设备与本端设备进行决策***。
其中,保活周期Time和最大保活次数Count都有默认值,在堆叠***中各个成员设备的默认值一致,比如保活周期Time为0.5秒,最大保活次数Count为6次,表示每0.5秒发送一个保活请求报文,如果连续6次未收到保活响应报文报文则认为线路异常,应进行决策***。但在实际应用中,保活周期Time和最大保活次数Count都可自行设置,其应根据各成员设备间链路稳定性评估来配置不同的值,比如主设备和从设备之间无中转设备,线缆很短,评估不容易出现问题,线路延迟很小,其实际应用情况可模拟为如图2所示的由两台成员设备组成的堆叠***时,可以使用默认值;但如果是异地灾备环境,堆叠***的各成员设备在不同城市,其实际应用情况可模拟为如图3所示的由四台成员设备组成的堆叠***时,则保活周期可以较长,其具体值可以根据线路情况分别设置。
在所述步骤S2中,当所述本端设备出现保活失败、端口故障、软件处理异常等原因,决策本端设备需要***时,则关闭与对端设备间的虚拟交换链路,关闭时间为对端设备定时信息中保活周期Time×(最大保活次数Count+1),即如果Time为0.5秒,Count为6,则定时器值为0.5×(6+1)=3.5秒;
关闭该虚拟交换链路后,本端设备链路中物理端口down,如果对端设备和本端设备直接相连,如图2所示,则对端设备对应的物理端口根据物理特性也会跟随down掉,此时对端设备会直接感知到虚拟交换链路异常,则与本端设备进行***决策,而不需要再等保活超时。但如果对端设备和本端设备不是直接相连,而是有中转设备,如图4所示,由于本端设备链路中物理端口down,对端设备不会感知到,但是本端设备由于虚拟交换链路已经关闭,所以不会再发送保活响应报文,而由于我们物理端口down的时间为对端设备保活周期Time×(最大保活次数Count+1),所以对端设备在保活超时后肯定能够检测到虚拟交换链路异常,进行***决策,***后,MAD等检测机制可以正常生效,保证用户业务不受影响。
在所述步骤S3中,本端设备在发生***后关闭虚拟交换链路的同时启动定时器,定时器值为对端设备定时信息中保活周期Time×(最大保活次数Count+1),当定时器超时后,重新恢复该虚拟交换链路,如果线路物理连接正常,则物理端口会重新UP,这样堆叠***可以正常合并,恢复业务。
本发明为解决技术问题还提供了一种防止堆叠***单边***的***,其具体包括本端设备和对端设备,所述本端设备包括链路保活模块、***决策模块、链路管理模块以及定时模块;
所述链路保活模块,用于在虚拟交换链路中,本端设备与对端设备之间相互发送保活报文,收集对端设备的保活周期和最大保活次数;
所述***决策模块,用于决策本端设备是否应该从堆叠***中***;
所述链路管理模块,用于在本端设备发生***时,关闭与对端设备之间的虚拟交换链路,同时,检测虚拟交换链路物理端口状态;
所述定时模块,用于在定时器超时后,恢复关闭的虚拟交换链路。
由于本发明实施例中,本端设备与对端设备是相对而言的,同理对端设备也包括链路保活模块、***决策模块、链路管理模块以及定时模块;具体功能和用途不再赘述。本发明实施例的防止堆叠***单边***的***如图5所示为该***的示意框图,
其中,所述本端设备与对端设备之间相互发送的保活报文包括:保活请求报文和保活响应报文,在堆叠***正常工作的情况下,堆叠***中各个成员设备之间组成虚拟交换链路的本端设备定时向对端设备发送保活请求报文,若本端设备在连续发送N次保活请求报文而未接收到对端设备发送的保活响应报文,则本端设备与该对端设备之间的虚拟交换链路发生异常,否则认为该虚拟交换链路工作正常;所述保活报文包括:报文类型Type字段、序列号Seq字段、保活周期Time字段以及最大保活次数Count字段;所述Type字段用于表示当前发送的保活报文是保活请求报文还是保活响应报文;所述Seq字段用于表示发送的保活报文的序列号,每发送一次保活请求报文时,所述Seq字段的值加1。
所述N值为保活报文中Count字段的值,当本端设备发送的保活请求报文的序列号Seq和接收到的保活响应报文的序列号Seq之间差大于所述Count字段的值时,所述本端设备与对端设备之间的虚拟交换链路发生异常,则对端设备与本端设备进行决策***。
本领域的普通技术人员将会意识到,这里所述的实施例是为了帮助读者理解本发明的原理,应被理解为本发明的保护范围并不局限于这样的特别陈述和实施例。本领域的普通技术人员可以根据本发明公开的这些技术启示做出各种不脱离本发明实质的其它各种具体变形和组合,这些变形和组合仍然在本发明的保护范围内。

Claims (10)

1.一种防止堆叠***单边***的方法,其特征在于,包括如下步骤:
S1、在虚拟交换链路中,本端设备与对端设备之间相互发送保活报文,收集对端设备的保活周期和最大保活次数;
S2、当本端设备发生***时,关闭与对端设备之间的虚拟交换链路,并同时启动定时器,所述对端设备检测到虚拟交换链路异常,则与本端设备进行决策***;
S3、定时器超时后,恢复关闭的虚拟交换链路。
2.如权利要求1所述的方法,其特征在于,所述步骤S1中保活报文包括:保活请求报文和保活响应报文,在堆叠***正常工作的情况下,堆叠***中各个成员设备之间组成虚拟交换链路的本端设备定时向对端设备发送保活请求报文,若本端设备在连续发送N次保活请求报文而未接收到对端设备发送的保活响应报文,则认为本端设备与该对端设备之间的虚拟交换链路发生异常,否则认为该虚拟交换链路工作正常。
3.如权利要求2所述的方法,其特征在于,所述保活报文包括:报文类型Type字段、序列号Seq字段、保活周期Time字段以及最大保活次数Count字段;所述Type字段用于表示当前发送的保活报文是保活请求报文还是保活响应报文;所述Seq字段用于表示发送的保活报文的序列号,每发送一次保活请求报文时,所述Seq字段的值加1。
4.如权利要求3所述的方法,其特征在于,所述N值为保活报文中Count字段的值,当本端设备发送的保活请求报文的序列号Seq和接收到的保活响应报文的序列号Seq之间差大于所述Count字段的值时,所述本端设备与对端设备之间的虚拟交换链路发生异常,则对端设备与本端设备进行决策***。
5.如权利要求4所述的方法,其特征在于,所述步骤S2中,所述定时器的值为对端设备发送的保活报文中的保活周期Time×(最大保活次数Count+1)。
6.如权利要求1至5任一项所述的方法,其特征在于,所述步骤S2中,当本端设备发生***关闭与对端设备之间的虚拟交换链路时,本端设备的物理端口的状态为down;若本端设备与对端设备直接相连,则对端设备直接进行决策***;若所述本端设备与对端设备之间存在中转设备,则对端设备在定时器超时后与本端设备进行决策***。
7.一种防止堆叠***单边***的***,其特征在于,具体包括本端设备和对端设备,所述本端设备包括链路保活模块、***决策模块、链路管理模块以及定时模块;
所述链路保活模块,用于在虚拟交换链路中,本端设备与对端设备之间相互发送保活报文,收集对端设备的保活周期和最大保活次数;
所述***决策模块,用于决策本端设备是否应该从堆叠***中***;
所述链路管理模块,用于在本端设备发生***时,关闭与对端设备之间的虚拟交换链路,同时,检测虚拟交换链路物理端口状态;
所述定时模块,用于在定时器超时后,恢复关闭的虚拟交换链路。
8.如权利要求7所述的***,其特征在于,所述本端设备与对端设备之间相互发送的保活报文包括:保活请求报文和保活响应报文,在堆叠***正常工作的情况下,堆叠***中各个成员设备之间组成虚拟交换链路的本端设备定时向对端设备发送保活请求报文,若本端设备在连续发送N次保活请求报文而未接收到对端设备发送的保活响应报文,则本端设备与该对端设备之间的虚拟交换链路发生异常,否则认为该虚拟交换链路工作正常;
所述保活报文包括:报文类型Type字段、序列号Seq字段、保活周期Time字段以及最大保活次数Count字段;所述Type字段用于表示当前发送的保活报文是保活请求报文还是保活响应报文;所述Seq字段用于表示发送的保活报文的序列号,每发送一次保活请求报文时,所述Seq字段的值加1。
9.如权利要求8所述的***,其特征在于,所述N值为保活报文中Count字段的值,当本端设备发送的保活请求报文的序列号Seq和接收到的保活响应报文的序列号Seq之间差大于所述Count字段的值时,所述本端设备与对端设备之间的虚拟交换链路发生异常,则对端设备与本端设备进行决策***。
10.如权利要求9所述的***,其特征在于,所述定时模块中定时器的值为对端设备发送的保活报文中的保活周期Time×(最大保活次数Count+1)。
CN201410151728.4A 2014-04-15 2014-04-15 一种防止堆叠***单边***的方法及*** Active CN103944781B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201410151728.4A CN103944781B (zh) 2014-04-15 2014-04-15 一种防止堆叠***单边***的方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410151728.4A CN103944781B (zh) 2014-04-15 2014-04-15 一种防止堆叠***单边***的方法及***

Publications (2)

Publication Number Publication Date
CN103944781A true CN103944781A (zh) 2014-07-23
CN103944781B CN103944781B (zh) 2017-08-29

Family

ID=51192274

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410151728.4A Active CN103944781B (zh) 2014-04-15 2014-04-15 一种防止堆叠***单边***的方法及***

Country Status (1)

Country Link
CN (1) CN103944781B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104639454A (zh) * 2015-01-30 2015-05-20 杭州华三通信技术有限公司 一种成员设备离开的发现方法和设备
CN110224950A (zh) * 2019-06-21 2019-09-10 深圳市信锐网科技术有限公司 堆叠***检测***、方法、装置及计算机可读存储介质
CN113949623A (zh) * 2021-10-18 2022-01-18 迈普通信技术股份有限公司 Mlag双主异常修复方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101621407A (zh) * 2009-08-11 2010-01-06 杭州华三通信技术有限公司 软件版本不一致的处理方法和堆叠***中的成员设备
CN102315975A (zh) * 2011-10-17 2012-01-11 杭州华三通信技术有限公司 一种基于irf***的故障处理方法及其设备
CN102404172A (zh) * 2011-12-21 2012-04-04 迈普通信技术股份有限公司 一种多激活检测方法和设备
US20150063117A1 (en) * 2013-09-05 2015-03-05 Avaya Inc. Tunnel Keep-alive Timeout Mechanism Based On Quality of Service (QoS) Value of Received Keep-alive Messages

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101621407A (zh) * 2009-08-11 2010-01-06 杭州华三通信技术有限公司 软件版本不一致的处理方法和堆叠***中的成员设备
CN102315975A (zh) * 2011-10-17 2012-01-11 杭州华三通信技术有限公司 一种基于irf***的故障处理方法及其设备
CN102404172A (zh) * 2011-12-21 2012-04-04 迈普通信技术股份有限公司 一种多激活检测方法和设备
US20150063117A1 (en) * 2013-09-05 2015-03-05 Avaya Inc. Tunnel Keep-alive Timeout Mechanism Based On Quality of Service (QoS) Value of Received Keep-alive Messages

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104639454A (zh) * 2015-01-30 2015-05-20 杭州华三通信技术有限公司 一种成员设备离开的发现方法和设备
CN104639454B (zh) * 2015-01-30 2018-02-09 新华三技术有限公司 一种成员设备离开的发现方法和设备
CN110224950A (zh) * 2019-06-21 2019-09-10 深圳市信锐网科技术有限公司 堆叠***检测***、方法、装置及计算机可读存储介质
CN113949623A (zh) * 2021-10-18 2022-01-18 迈普通信技术股份有限公司 Mlag双主异常修复方法、装置、电子设备及存储介质
CN113949623B (zh) * 2021-10-18 2024-04-26 迈普通信技术股份有限公司 Mlag双主异常修复方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN103944781B (zh) 2017-08-29

Similar Documents

Publication Publication Date Title
CN100589408C (zh) 一种通讯网络连接方法及其装置
CN108900415B (zh) Mlag接口故障下的主从设备切换方法及***
CN102315975B (zh) 一种基于irf***的故障处理方法及其设备
CN102014001B (zh) 一种实现快速以太环网的方法及交换设备
EP1982447A2 (en) System and method for detecting and recovering from virtual switch link failures
CN101729426B (zh) 一种虚拟路由冗余协议主备用设备快速切换的方法及***
EP2627039A1 (en) Method and device for switching aggregation links
CN102006189A (zh) 用于双机冗余备份的主用接入服务器确定方法及装置
CN102891769A (zh) 链路故障通告方法和设备
CN107465613B (zh) 链路聚合接口通信状态切换方法及装置
CN104486128B (zh) 一种实现双控制器节点间冗余心跳的***及方法
CN101674208A (zh) 一种lacp mad检测的方法及设备
CN101841432A (zh) 一种业务接入路由器的端口备份方法、装置和***
CN102255751A (zh) 一种堆叠冲突的处理方法和设备
CN105656645A (zh) 堆叠***的故障处理的决策方法和装置
CN102932183B (zh) 双上行链路故障处理方法及设备
CN102255757A (zh) 一种链路切换方法及其装置
CN104333470B (zh) 故障处理方法和装置
CN103944781A (zh) 一种防止堆叠***单边***的方法及***
CN101599906B (zh) 端口状态设置的方法及装置
CN109194592B (zh) 一种解决multi-link网络中孤岛问题的方法和***
KR20110046897A (ko) 서브넷에서 마스터 노드를 선출하는 방법
CN102118266A (zh) 工业以太网双链路冗余技术
CN104253747A (zh) 一种报文在链路聚合组中进行1:1保护的传输方法及装置
CN108337162B (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
CP02 Change in the address of a patent holder

Address after: 610041 nine Xing Xing Road 16, hi tech Zone, Sichuan, Chengdu

Patentee after: MAIPU COMMUNICATION TECHNOLOGY Co.,Ltd.

Address before: 610041 Sichuan city of Chengdu province high tech Zone nine Hing Road No. 16 building, Maipu

Patentee before: MAIPU COMMUNICATION TECHNOLOGY Co.,Ltd.

CP02 Change in the address of a patent holder