CN109218206A - 一种限制链路状态通告数量的方法和装置 - Google Patents

一种限制链路状态通告数量的方法和装置 Download PDF

Info

Publication number
CN109218206A
CN109218206A CN201811025867.7A CN201811025867A CN109218206A CN 109218206 A CN109218206 A CN 109218206A CN 201811025867 A CN201811025867 A CN 201811025867A CN 109218206 A CN109218206 A CN 109218206A
Authority
CN
China
Prior art keywords
link state
state notification
database
currently
network equipment
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
CN201811025867.7A
Other languages
English (en)
Other versions
CN109218206B (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 DPTech Technologies Co Ltd
Original Assignee
Hangzhou DPTech 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 DPTech Technologies Co Ltd filed Critical Hangzhou DPTech Technologies Co Ltd
Priority to CN201811025867.7A priority Critical patent/CN109218206B/zh
Publication of CN109218206A publication Critical patent/CN109218206A/zh
Application granted granted Critical
Publication of CN109218206B publication Critical patent/CN109218206B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/021Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/20Traffic policing

Landscapes

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

Abstract

本申请提供一种限制链路状态通告数量的方法和装置,所述方法包括:监控运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小;若所述网络设备当前能提供给OSPF协议的可用内存大小变化,则计算得出链路状态数据库能储存的链路状态通告数量;获取所述数据库当前储存的链路状态通告数量,若所述数据库当前储存的链路状态通告数量等于限制值,则进行限制链路状态通告数量增加的操作。

Description

一种限制链路状态通告数量的方法和装置
技术领域
本申请涉及网络技术领域,特别是涉及一种限制链路状态通告数量的方法和装置。
背景技术
在网络中,相连的运行OSPF(Open Shortest Path First,开放最短路径优先)协议的网络设备之间会将链路状态通告交换储存在链路状态数据库中,这会占用网络设备的内存,因此,当网络规模达到一定程度时,链路状态通告数量就会变得非常庞大,从而给OSPF协议的计算以及网络设备的内存带来巨大的压力。一方面,网络中各个网络设备的内存大小可能不同,另一方面,同一个网络设备启用的功能可能不同,因此,网络设备提供给OSPF协议的可用内存大小很难确定,从而链路状态数据库能储存的链路状态通告数量很难界定。
为了保证网络正常,必须对网络进行细致规划同时时刻警惕网络设备接收的或者自己产生的链路状态通告数量有没有超量。
这就造成一旦网络规划不细致或网络管理员未注意,使大量链路状态通告进入链路状态数据库,超出链路状态数据库能储存的数量,将导致网络设备无法支持或OSPF协议崩溃,进而导致网络崩溃。
发明内容
有鉴于此,本申请提供了一种限制链路状态通告数量的方法和装置,以解决链路状态数据库能储存的链路状态通告数量很难界定造成的链路状态通告涌入很难控制的问题。
具体地,本申请是通过如下技术方案实现的:
一种限制链路状态通告数量的方法,其特征在于,包括:
监控运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小;
若所述网络设备当前能提供给OSPF协议的可用内存大小变化,则计算得出链路状态数据库能储存的链路状态通告数量;所述数据库能储存的链路状态通告数量的计算方法为:利用所述网络设备当前能提供给OSPF协议的可用内存减去OSPF协议运行基础功能所用内存,得出所述数据库可用内存,再利用所述数据库除以每条链路状态通告所需占用的内存,得出所述数据库能够储存的链路状态通告数量;
获取所述数据库当前储存的链路状态通告数量,若所述数据库当前储存的链路状态通告数量等于预设限制值,则进行限制链路状态通告数量增加的操作。
本申请还提供一种限制链路状态通告数量的装置,其特征在于,包括:
监控单元,用于监控运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小;
计算单元,用于若所述网络设备当前能提供给OSPF协议的可用内存大小变化,则计算得出链路状态数据库能储存的链路状态通告数量;所述数据库能储存的链路状态通告数量的计算方法为:利用所述网络设备当前能提供给OSPF协议的可用内存减去OSPF协议运行基础功能所用内存,得出所述数据库可用内存,再利用所述数据库除以每条链路状态通告所需占用的内存,得出所述数据库能够储存的链路状态通告数量;
限制单元,用于获取所述数据库当前储存的链路状态通告数量,若所述数据库当前储存的链路状态通告数量等于预设限制值,则进行限制链路状态通告数量增加的操作。
由以上技术方案可以看出,本申请中,能够根据网络设备当前能提供给OSPF协议的可用内存大小变化,随时计算链路状态数据库能储存的链路状态通告数量,以此设置限制值,并对当前储存的链路状态通告的数量进行监控,由于限制值不大于数据库能够储存的链路状态通告数量,所以当前储存的链路状态通告的数量不会超过链路状态数据库能够储存的链路状态通告数量。
附图说明
图1是本申请根据一示例性实施例示出的一种限制链路状态通告数量应用场景示意图;
图2是本申请一示例性实施例示出的一种限制链路状态通告数量的方法的流程示意图;
图3是本申请一示例性实施例示出的一种限制链路状态通告数量的装置的结构示意图;
图4是本申请根据一示例性实施例示出的一种限制链路状态通告数量的装置所在设备的一种硬件结构图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
随着信息技术的发展,网络的规模越来越大,结构越来越复杂,为了满足大型、异构的网络的需要,OSPF协议被开发并在市场中广泛使用。运行OSPF协议的网络设备会将自己的链路状态通告根据对应的扩散范围,发给与自己相连的邻居,邻居将收到的链路状态通告放入链路状态数据库,之后邻居再发给自己的所有邻居,并且在传递过程中,绝对不会有任何更改。通过这样的过程,最终,网络中所有运行OSPF协议的网络设备都拥有其所在范围的所有的链路状态通告。因此,当网络规模达到一定程度时,链路状态通告的数据将变得非常庞大,由于链路状态通告储存于链路状态数据库中,而链路状态数据库占用的是网络设备的内存,所以势必会给OSPF计算以及网络设备内存和性能带来巨大的压力。
目前,运行OSPF协议的网络设备必须时刻警惕与其连接的邻居发送的链路状态通告或者自己产生的链路状态通告有没有超过链路状态数据库的储存能力,一旦网络规划不细致或网络管理员未注意链路状态数据库所能储存的链路状态通告的最大数量,极端情况下,网络中大量的链路状态通告涌入网络设备或网络设备自身产生大量新的链路状态通告,严重超过链路状态数据库实际储存能力,导致网络设备内存不足,无法继续支持OSPF计算,从而导致OSPF协议崩溃,进而导致网络崩溃。
参见图1所示,为本申请根据一示例性实施例示出的一种限制链路状态通告数量应用场景示意图:
如图1所示的应用场景中,以最简单的3台运行OSPF协议的网络设备为例,分别是路由器A、路由器B和路由器C,路由器A能储存的链路状态通告数量为10万,已有3万,路由器B能储存的链路状态通告数量为6万,已有1万,路由器C能储存的链路状态通告数量为10万,已有4万。
路由器B会分别和路由器A、路由器C先后建立连接关系。
路由器A与路由器B连接,相互交互学习对方的链路状态通告,路由器A的链路状态通告数量为3万加上路由器B的链路状态通告数量1万,总量为4万,同理路由器B的链路状态通告数量也为4万,二者链路状态通告数量都没达到限制值;路由器C与路由器B连接,相互交互学习对方的链路状态通告,路由器B已有链路状态通告数量为4万,到达自己极限所能储存的链路状态通告数量6万时OSPF协议崩溃,导致与路由器A的连接关系也断掉了,网络陷入瘫痪。
另一种情况是,路由器B本身已有1万的链路状态通告,通过引入其他种类的路由等方式自身产生6万的链路状态通告,到达自己极限,最终导致路由器OSPF协议崩溃,进而导致网络陷入瘫痪。
针对上述问题,本申请提出一种限制链路状态通告数量的方法,该方法能够根据网络设备当前能提供给OSPF协议的可用内存大小变化,随时计算链路状态数据库能储存的链路状态通告数量,以此设置限制值,并对当前储存的链路状态通告的数量进行监控和限制。
为了使本技术领域的人员更好地理解本申请实施例中的技术方案,将结合以下附图对本申请实施例中技术方案作进一步详细的说明。
图2是本申请一示例性实施例示出的一种限制链路状态通告数量的方法的流程示意图。如图1所示,该方法包括如下步骤:
步骤201,监控运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小。
与现有技术不同的是,本申请考虑到运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小是需要事先确定的。
一方面,运行OSPF的不同网络设备内存和性能不同,能提供给OSPF协议的可用内存是不同的,另一方面,同一个网络设备启用功能不同和启用同一功能的不同时刻,会使网络设备的内存进行不同的分配,网络设备能提供给OSPF协议的可用内存会随之变化,综上两个原因,网络设备能提供给OSPF协议的可用内存需要监控确定。
步骤202,若所述网络设备当前能提供给OSPF协议的可用内存大小变化,则计算得出链路状态数据库能储存的链路状态通告数量;所述数据库能储存的链路状态通告数量的计算方法为:利用所述网络设备当前能提供给OSPF协议的可用内存减去OSPF协议运行基础功能所用内存,得出所述数据库可用内存,再利用所述数据库除以每条链路状态通告所需占用的内存,得出所述数据库能够储存的链路状态通告数量。
为了能较为准确的知道数据库能够储存的链路状态通告数量,确定好运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小后,就可以进行以下计算:由于OSPF协议运行基础功能需要占用部分内存,因此,链路状态数据库可用内存为网络设备能提供给OSPF协议的可用内存减去OSPF协议运行基础功能所用内存,得出链路状态数据库可用内存后,再利用链路状态数据库可用内存除以每条链路状态通告所用内存,得出链路状态数据库能够储存的链路状态通告的数量。
步骤203,获取所述数据库当前储存的链路状态通告数量,若所述数据库当前储存的链路状态通告数量等于限制值,则进行限制链路状态通告数量增加的操作;所述限制值不大于所述数据库能够储存的链路状态通告数量。
由步骤201到步骤202的描述可以看出,由这两个步骤可以获得的链路状态数据库能够储存的链路状态通告的数量。在正常的运行中,运行OSPF协议的网络设备以相互交互学习的方式,接收储存邻居的链路状态通告,并且网络设备也会根据自身需要,产生新的链路状态通告,使链路状态数据库中的链路状态通告数量不断增加。
为了避免链路状态通告数量超过链路状态数据库的最大储存能力,需要对链路状态数据库当前储存的链路状态通告数量进行限制。
已知步骤202计算得出链路状态数据库能储存的链路状态通告数量,根据需要选择一个不大于它的数值作为限制值,当链路状态数据库当前储存的链路状态通告数量到达限制值时,采取操作对链路状态通告数量增加进行限制。
由步骤201到步骤202的描述还可以看出,计算得到的链路状态数据库能够储存的链路状态通告的数量是一个较为理想的数值,因此可以根据网络设备运行需要,设置不同的限制值,也是对网络设备正常运行的又一个保障。
由上述描述可以看出,计算链路状态数据库能储存的链路状态通告数量,并以此设置限制值,由于限制值不大于数据库能够储存的链路状态通告数量,所以避免了当前储存的链路状态通告的数量超出链路状态数据库的储存能力的问题。
作为一种实施方式,上述步骤203中,进行限制链路状态通告数量增加的操作,可以包括:
若所述网络设备当前在接收链路状态通告,则停止接收链路状态通告;
若所述网络设备当前在自身产生链路状态通告,则停止自身产生新的链路状态通告。
在该实施方式中,当链路状态数据库当前储存的链路状态通告数量等于限制值,网络设备可以进行限制链路状态通告数量增加的操作。
由于网络设备在运行过程中以相互交互学习的方式,接收储存邻居的链路状态通告,同时也会根据自身需要,产生一些链路状态通告,这些链路状态通告都会存入链路状态数据库中,当链路状态数据库当前储存的链路状态通告数量到达了限制值,就可以根据链路状态通告的来源,分别进行限制。
对于网络设备当前在接收链路状态通告,需要停止接收。在实际情况下,网络设备接收链路状态通告的过程分为请求获取和接收储存两部分,因此停止接收的过程也可以分为不再请求获取和拒绝接收储存。
进一步地,在停止接收和停止产生时,可以同时发出警告。发出警告是为了通知网络管理员链路状态通告数量过多,需要及时排查。
举例来说,假设现在有三个网络设备路由器A,路由器B和路由器C,路由器A能储存的链路状态通告数量为10万,已有3万,路由器B能储存的链路状态通告数量为6万,已有1万,路由器C能储存的链路状态通告数量为10万,已有4万。限制值设定为各路由器能储存的链路状态通告数量的85%,即路由器A的限制值为8.5万,路由器B的限制值为5.1万,路由器A的限制值为8.5万。
路由器B会分别和路由器A、路由器C先后建立连接关系。
路由器A与路由器B连接,相互交互学习对方的链路状态通告,路由器A的链路状态通告数量为3万加上路由器B的链路状态通告数量1万,总量为4万,同理路由器B的链路状态通告数量也为4万,二者链路状态通告数量都没达到限制值;路由器C与路由器B连接,相互交互学习对方的链路状态通告,路由器B已有链路状态通告数量为4万,在路由器B到达限制值5.1万时,停止接收链路状态通告,同时发出警告,通知网络管理员链路状态通告数量过多,需要及时排查。
作为一种实施方式,在上述步骤中,还包括:
若计算得出所述数据库能够储存的链路状态通告数量小于所述数据库当前储存的链路状态通告数量,则按预设规则删除所述数据库当前储存的链路状态通告。
在该实施方式中,考虑到实际情况下,网络设备突然开启了其他功能,占用了内存,导致网络设备当前能提供给OSPF协议的可用内存变小,此时若计算得出所述数据库能够储存的链路状态通告数量小于所述数据库当前储存的链路状态通告数量,就是说明当前链路状态数据库可用内存无法储存现有的链路状态通告了,因此要删除部分链路状态通告。
考虑到实际网络设备运行的需要,可选的,优先删除所述网络设备自身产生的链路状态通告。
进一步地,在删除所述网络设备自身产生的链路状态通告时,可以同时发出警告。发出警告是为了通知网络管理员链路状态通告数量过多,需要及时排查。
作为一种实施方式,在上述步骤中,还包括:
设置小于限制值的提醒值,若所述数据库当前储存的链路状态通告数量等于提醒值时,发出提醒。
由上述描述已经知道,在当前储存的链路状态通告数量等于限制值时进行限制链路状态通告数量增加的操作,我们可以在限制链路状态通告数量增加的操作之前,设置一个提醒,用于当收到的链路状态通告数量接近该提醒值时,进行提醒,主要是通知网络管理员,网络中链路状态通告将会有过多的危险,要及早进行排查和监视。
作为一种实施方式,在上述步骤中,还包括:
所述网络设备在接收链路状态通告时,若接收到同一个链路状态通告的多个实例,则进行以下处理:
比较实例的序列号,接收序列号最大的实例;
若序列号相同,则比较实例的校验和值,接收校验和值最大的实例;
若校验和值相同,则接收生存时间等于最大生存时间MaxAge的实例;
若实例生存时间都不等于MaxAge,则通过最大生存时间差距算法计算实例的时间差,若时间差大于预设值,则接收生存时间最小的实例;
若实例的时间差小于预设值,则任意接收一个。
当一台网络设备收到了一个链路状态通告的多个实例,那此时需要通过如下的机制来比较实例的新旧程度:
序列号:当始发网络设备每产生一个实例时序列号增加1,序列号越大,实例越新;
校验和值:当序列号相同时比较校验和值,校验和值越大,该实例越新;
生存时间:当前两者均相同时,比较所有的实例,如果没有实例的生存时间差大于最大生存时间MaxAge,那么认为最小的实例为最新,否则认为最大生存时间的实例为最新。
经过以上三个要素的比较,如果仍然相同,那么认为这些实例也相同。
与前述限制链路状态通告数量的方法实施例相对应,本申请还提供了限制链路状态通告数量的装置实施例。
请参见图3,为本申请一示例性实施例示出的一种限制链路状态通告数量的装置的结构示意图,其中,所述装置可以应用于可以上述方法实施例中的网络设备,如图3所示,该限制链路状态通告数量的装置可以包括:
监控单元301,用于监控运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小;
计算单元302,用于若所述网络设备当前能提供给OSPF协议的可用内存大小变化,则计算得出链路状态数据库能储存的链路状态通告数量;所述数据库能储存的链路状态通告数量的计算方法为:利用所述网络设备当前能提供给OSPF协议的可用内存减去OSPF协议运行基础功能所用内存,得出所述数据库可用内存,再利用所述数据库除以每条链路状态通告所需占用的内存,得出所述数据库能够储存的链路状态通告数量;
限制单元303,用于获取所述数据库当前储存的链路状态通告数量,若所述数据库当前储存的链路状态通告数量等于预设的限制值,则进行限制链路状态通告数量增加的操作;所述限制值不大于所述数据库能够储存的链路状态通告数量。
进一步地,所述限制单元303,可以具体用于进行限制链路状态通告数量增加的操作,包括:
限制接收子单元,用于若所述网络设备当前在接收链路状态通告,则停止接收链路状态通告,同时发出警告;
限制产生子单元,用于若所述网络设备当前在自身产生链路状态通告,则停止自身产生新的链路状态通告,同时发出警告。
进一步地,所述装置还包括:
删除单元,用于若计算得出所述数据库能够储存的链路状态通告数量小于所述数据库当前储存的链路状态通告数量,则按预设规则删除所述数据库当前储存的链路状态通告。
进一步地,所述装置还包括:
提醒单元,用于设置小于限制值的提醒值,若所述数据库当前储存的链路状态通告数量等于提醒值时,发出提醒。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
本申请限制链路状态通告数量的装置的实施例可以应用在网络设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在设备的处理器运行存储器中对应的计算机程序指令形成的。从硬件层面而言,如图4所示,为本申请根据一示例性实施例示出的一种限制链路状态通告数量的装置所在设备的一种硬件结构图,除了图4所示的处理器、网络接口、以及存储器之外,实施例中装置所在的设备通常根据该设备的实际功能,还可以包括其他硬件,对此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

Claims (10)

1.一种限制链路状态通告数量的方法,其特征在于,包括:
监控运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小;
若所述网络设备当前能提供给OSPF协议的可用内存大小变化,则计算得出链路状态数据库能储存的链路状态通告数量;所述数据库能储存的链路状态通告数量的计算方法为:利用所述网络设备当前能提供给OSPF协议的可用内存减去OSPF协议运行基础功能所用内存,得出所述数据库可用内存,再利用所述数据库除以每条链路状态通告所需占用的内存,得出所述数据库能够储存的链路状态通告数量;
获取所述数据库当前储存的链路状态通告数量,若所述数据库当前储存的链路状态通告数量等于限制值,则进行限制链路状态通告数量增加的操作;所述限制值不大于所述数据库能够储存的链路状态通告数量。
2.根据权利要求1所述的方法,其特征在于,所述进行限制链路状态通告数量增加的操作,包括:
若所述网络设备当前在接收链路状态通告,则停止接收链路状态通告;
若所述网络设备当前在自身产生链路状态通告,则停止自身产生新的链路状态通告。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
若计算得出所述数据库能够储存的链路状态通告数量小于所述数据库当前储存的链路状态通告数量,则按预设规则删除所述数据库当前储存的链路状态通告。
4.根据权利要求3所述的方法,其特征在于,所述预设规则为优先删除所述网络设备自身产生的链路状态通告。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括:
设置小于限制值的提醒值,若所述数据库当前储存的链路状态通告数量等于提醒值时,发出提醒。
6.根据权利要求1所述的方法,其特征在于,所述方法还包括:
所述网络设备在接收链路状态通告时,若接收到同一个链路状态通告的多个实例,则进行以下处理:
比较实例的序列号,接收序列号最大的实例;
若序列号相同,则比较实例的校验和值,接收校验和值最大的实例;
若校验和值相同,则接收生存时间等于最大生存时间MaxAge的实例;
若实例生存时间都不等于MaxAge,则通过最大生存时间差距算法计算实例的时间差,若时间差大于预设值,则接收生存时间最小的实例;
若实例的时间差小于预设值,则任意接收一个。
7.一种限制链路状态通告数量的装置,其特征在于,包括:
监控单元,用于监控运行OSPF协议的网络设备当前能提供给OSPF协议的可用内存大小;
计算单元,用于若所述网络设备当前能提供给OSPF协议的可用内存大小变化,则计算得出链路状态数据库能储存的链路状态通告数量;所述数据库能储存的链路状态通告数量的计算方法为:利用所述网络设备当前能提供给OSPF协议的可用内存减去OSPF协议运行基础功能所用内存,得出所述数据库可用内存,再利用所述数据库除以每条链路状态通告所需占用的内存,得出所述数据库能够储存的链路状态通告数量;
限制单元,用于获取所述数据库当前储存的链路状态通告数量,若所述数据库当前储存的链路状态通告数量等于预设的限制值,则进行限制链路状态通告数量增加的操作;所述限制值不大于所述数据库能够储存的链路状态通告数量。
8.根据权利要求7所述的装置,其特征在于,所述限制单元包括:
限制接收子单元,用于若所述网络设备当前在接收链路状态通告,则停止接收链路状态通告;
限制产生子单元,用于若所述网络设备当前在自身产生链路状态通告,则停止自身产生新的链路状态通告。
9.根据权利要求7所述的装置,其特征在于,所述装置还包括:
删除单元,用于若计算得出所述数据库能够储存的链路状态通告数量小于所述数据库当前储存的链路状态通告数量,则按预设规则删除所述数据库当前储存的链路状态通告。
10.根据权利要求7所述的装置,其特征在于,所述装置还包括:
提醒单元,用于设置小于限制值的提醒值,若所述数据库当前储存的链路状态通告数量等于提醒值时,发出提醒。
CN201811025867.7A 2018-09-04 2018-09-04 一种限制链路状态通告数量的方法和装置 Active CN109218206B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811025867.7A CN109218206B (zh) 2018-09-04 2018-09-04 一种限制链路状态通告数量的方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811025867.7A CN109218206B (zh) 2018-09-04 2018-09-04 一种限制链路状态通告数量的方法和装置

Publications (2)

Publication Number Publication Date
CN109218206A true CN109218206A (zh) 2019-01-15
CN109218206B CN109218206B (zh) 2021-03-23

Family

ID=64986074

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811025867.7A Active CN109218206B (zh) 2018-09-04 2018-09-04 一种限制链路状态通告数量的方法和装置

Country Status (1)

Country Link
CN (1) CN109218206B (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1889464A (zh) * 2006-07-26 2007-01-03 华为技术有限公司 一种实现通信接管的方法及装置
WO2012171414A1 (zh) * 2011-06-14 2012-12-20 中兴通讯股份有限公司 终端和终端链路状态数据库溢出的处理方法
EP2571208A1 (en) * 2011-09-16 2013-03-20 Telefonaktiebolaget L M Ericsson (PUBL) Open shortest path first (OSPF) nonstop routing (NSR) with link derivation
CN106941460A (zh) * 2016-01-05 2017-07-11 中兴通讯股份有限公司 报文发送方法和装置
CN107070798A (zh) * 2016-12-23 2017-08-18 华为技术有限公司 网络区域划分方法、网络设备和系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1889464A (zh) * 2006-07-26 2007-01-03 华为技术有限公司 一种实现通信接管的方法及装置
WO2012171414A1 (zh) * 2011-06-14 2012-12-20 中兴通讯股份有限公司 终端和终端链路状态数据库溢出的处理方法
EP2571208A1 (en) * 2011-09-16 2013-03-20 Telefonaktiebolaget L M Ericsson (PUBL) Open shortest path first (OSPF) nonstop routing (NSR) with link derivation
CN106941460A (zh) * 2016-01-05 2017-07-11 中兴通讯股份有限公司 报文发送方法和装置
CN107070798A (zh) * 2016-12-23 2017-08-18 华为技术有限公司 网络区域划分方法、网络设备和系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
康威: "OSPF路由协议安全性分析与研究", 《中国优秀硕士学位论文全文数据库》 *
贺雪飞: "OSPFv3协议链路状态数据库溢出控制实现", 《中国优秀硕士学位论文全文数据库》 *

Also Published As

Publication number Publication date
CN109218206B (zh) 2021-03-23

Similar Documents

Publication Publication Date Title
CN105991325B (zh) 处理至少一个分布式集群中的故障的方法、设备和系统
CN106375404B (zh) 数据存储控制方法、数据存储方法、数据获取方法及装置
CN105847237B (zh) 一种基于nfv的安全管理方法和装置
CN106294073B (zh) 服务调用方法及装置
CN109391505A (zh) 网络实例管理方法及相关设备
CN105103495B (zh) 用于允许或拒绝第一和第二设备之间的测量请求的接纳控制
CN103607424B (zh) 一种服务器连接方法及服务器系统
CA3157501A1 (en) Latency-based routing and load balancing in a network
CN105229591A (zh) 为了存储管理而创建全局聚合命名空间
CN111628941A (zh) 一种网络流量的分类处理方法、装置、设备及介质
JP2013226037A (ja) 電力系統のイベント処理システム
CN108696392A (zh) 一种通信状态监控方法、网络节点及计算机可读存储介质
CN106464516B (zh) 网络管理系统中的事件处理
CN109101357A (zh) 一种osd故障的检测方法及装置
CN104579765A (zh) 一种集群系统的容灾方法和装置
CN109542627A (zh) 节点切换方法、装置、管理机、节点设备和分布式系统
CN112737800A (zh) 服务节点故障定位方法、调用链生成方法及服务器
CN109271273A (zh) 一种通讯异常恢复的方法、异常恢复设备及存储介质
CN104283780A (zh) 建立数据传输路径的方法和装置
CN110324166B (zh) 一种在多个节点中同步目标信息的方法、装置及系统
CN105357069A (zh) 分布式节点服务状态监测的方法、装置及系统
CN108259195A (zh) 异常事件的影响范围的确定方法及系统
US10817512B2 (en) Standing queries in memory
CN110502581A (zh) 分布式数据库系统监测方法及装置
CN109412890B (zh) 基于dds的联合试验平台中间件节点状态检测方法

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