OSPF数据库溢出

译者：陶刚 西安交通大学硕士，主要研究方向OSPF、路由器原理及实现

摘要

OSPF路由协议正确运转需要所有OSPF路由器维护同一个OSPF链路状态数据库的副本。但是，当链路状态库的数据量变得很大时，一些路由器可能由于存储资源不足，没有能力保存整个数据库时，我们术语称这个数据库溢出。当预见到数据库溢出，资源有限的路由器可以通过配置OSPF的stub域和NSSA来适应较少的资源。本文详述了一种处理不可预料的数据库溢出的较好的办法。

1. 概述

OSPF需要所有在同一个域中的OSPF路由器维护同一个OSPF链路状态数据副本。但是，当链路状态数据库变得很大时，一些路由器由于资源短缺，不能保留整个数据库。术语上我们称其为“数据库溢出”。例如，一个地区的网络会有一个非常大的OSPF数据库，因为它引入了大量的外部路由给OSPF。除非数据库溢出能被正确处理，路由器将由不一致的网络视图引起的不正确的路由而无法工作。

对付数据库溢出的方法之一就是将资源较少的路由器归入到OSPF的stub域（见[1]中节3.6），或者，NSSA（[2]）。来自这些域的AS外部LSA会被忽略，由而可以控制数据库大小。但是，无法预计到的数据库溢出不能用上述方法处理。本文描述了一种动态限制数据库大小不超过溢出条件的方法。基本机制如下：

  1. 一个参数，ospfExtLsdbLimit。它在每一个路由器中被配置，以指出允许放在链路状态数据库中的AS外部LSA的最大数目，(不包括那些描述默认路由的LSA）。在路由域中所有路由器中，这个参数必须设成一致的（见节2.1）：参数的同步经网络管理来实现。
  2. 在任一个路由器的链路状态数据库中，AS外部LSA的数目（除默认外）不允许超过ospfExtLsdbLimit。如果一个路由收到一个可能引起ospfExtLsdbLimit被超过的非默认AS外部LSA，它就丢弃LSA而不认可它。
  3. 如果在一个路由器的数据库非默认AS外部LSA达到ospfExtLsdbLimit，该路由器a）刷新自己产生的所有非默认AS外部LSA(见节2.2），b)进入OverflowState[溢出状态]。
  4. 当在OverflowState[溢出状态]下，路由器拒绝产生任何非默认AS外部LSA（见节2.3.2）。
  5. 从进入OverflowState时,在可配置参数ospfExitOverflowInterval时间后，路由器企图离开OverflowState状态。仅当此时，路由器才恢复产生非默认AS外部LSA。

限制非默认AS外部LSA，而不是其他类型的LSA的原因有两部分，首先，非默认AS外部LSA最可能在那些拥有大数据库的网络中占重要比例（也就是地区网络，见[5]）。第二，非默认AS外部LSA在下列情况下是可选的:没有它们路由器也可能被监控/重配置。（但是，相似策略，也可限制其他类型LSA。见节5）

这里所描述的对付数据库溢出的方法有下列理想的特性：

  • 经过短暂收敛期，所有路由器将具有相同的链路状态库。这个数据库包含少于ospfExtLsdbLimit的非默认AS外部LSA。
  • 任何时候，在OSPF自治系统内路由将保持不变。在其他情形中，这意味着这些路由器将还是易于管理的。
  • 到外部目的地的默认路由将保留。这意味着，尽管采取不太有效的路由，大量到外部连通性保留了下来。
  • 如果参数ospfExitOverflowInterval被配置，那么，出现短暂的数据库溢出情形（见节2.4）后，OSPF系统将自动完全恢复（也就是，无网络管理员介入）。

2.实现细节

本节更加详细地描述了对付数据库溢出的机制。本节的组织围绕着OverflowState的概念，描述了路由器如何进入OverflowState，在OverflowState下的操作，以及何时离开OverflowState。

2.1 配置

支持数据库溢出处理，下面的配置参数需要加上。这些参数由网络管理员来设置。

  • ospfExtLsdbLimit
    当一个路由器的链路状态数据库中的非默认AS外部LSA达到ospfExtLsdbLimit时，路由器进入OverflowState。路由器从不会保存多于ospfExtLsdbLimit个非默认AS外部LSA在它的数据库中。ospfExtLsdbLimit必须在连到OSPF主干/任何通常OSPF域的所有路由器上配置相同。（本文不讨论路由器在OSPF的stub域或NSSA，因为这些路由器不会收到AS外部LSA）。如果ospfExtLsdbLimit不是在所有路由器中设置相同。那么当数据库溢出时，1）路由器不会在同一个链路状态数据库收敛；2）错误的路由，可能包括路由环；3）AS外部LSA会定时重传。由网络管理员来保证ospfExtLsdbLimit的一致性。当ospfExtLsdbLimit在路由器中设定，路由器必须有办法保证它能在它的链路状态数据库中保存众多非默认AS外部LSA。其中一个办法就是先为设定好的LSA数分配资源（即内存）。
  • ospfExitOverflowInterval
    进入OverflowState后，一个路由器将离开OverflowState的秒数。这允许路由器可以再次产生非默认AS外部LSA。当它设为零时，路由器将不离开OverflowState直到重启。ospfExitOverflowInterval的缺省设置为0。ospfExitOverflowInterval不必在所有路由器上设为一致。在产生越重要AS外部LSA的路由器上这个值可以设得越小。实际上，如果设成一致可能会引起一些问题，因为多个路由器会企图同时离开OverflowState。由此，使用前，ospfExitOverflowInterval的值必须在加减10%的范围内随机改变。

2.2. 进入OverflowState

当数据库中的非默认AS外部LSA的数目达到ospfExtLsdbLimit，路由器进入OverflowState。发生时有两种情形，第一种情形，正在接收一个洪泛中的LSA，在这种情形下，若这个LSA非数据库中实例，将按[1]中节13第5步来加入到数据库中。第二种情形是路由器自己产生一个非默认AS外部路由器。只要路由器进入OverflowState，它就刷新所有自己产生的非默认AS外部LSA。刷新由[1]中节14.1所述的早衰[premature aging]方案来实现。只有自己产生的LSA被刷新，那些由其他路由器产生的将在链路状态数据库中保留。

2.3在OverflowState中的操作

当在OverflowState中时，洪泛和非默认AS外部LSA的产生用下面方式修改。

2.3.1. 洪泛的修改

在OverflowState状态下的洪泛如下修改。如果在[1]中节13中第5步中，收到一个非默认AS外部LSA，a)没在当前数据中，b)会引起非默认AS外部LSA超过ospfExtLsdbLimit，那这个LSA会被丢弃，既不会被放入链路状态库中，也不会对它进行确认。当所有路由器具有同样的ospfExtLsdbLimit值时（必须），在短暂收敛期中，上述修改过的洪泛将被调用。在收敛时，会重传LSA，但是，在收敛后，重传将停止，因为少于ospfExtLsdbLimit的非默认AS外部LSA在路由器的数据库中。

在OverflowState中，非默认AS外部LSA在下列情况下会被接收：

  1. 如果LSA更新一个当前在路由器的链路状态数据库已存在的LSA。
  2. 具有MaxAgeLS时限的LSA总被接收。这些LSA的处理按[1]中节13和14所述的过程进行。
  3. 如果向路由器的数据库中加入LSA后，将使路由器中非默认AS外部LSA不超过ospfExtLsdbLimit（包含等于时），那么LSA将被接收。

2.3.2. 产生AS-external-LSAs

产生[1]节12.4.5中所述的AS外部LSA。当路由器在OverflowState，它不产生非默认AS外部LSA。换句话说，在OverflowState中，只有链路状态ID为0.0.0.0的路由器可产生AS外部LSA。

2.3.3. 接收自产生LSAs

接收自产生LSA在[1]中节13.4中描述。当在OverflowState状态下，一个路由器，使用[1]节14.1中所述的早衰[premature aging]方案，通过在路由域中刷新它，来对接收到自产生非默认AS外部LSA作出反应。

2.4. 离开OverflowState

如果ospfExitOverflowInterval非零，那么只要路由器进入OverflowState，它就设置一个定时器值等于ospfExitOverflowInterval(加或减一个在10%范围内的随机数)。当这个定时器起动时，该路由器离开OverflowState并开始再次产生非默认AS外部LSA。

这使得一个路由器可以从很短的溢出状态下恢复。例如，一个AS边界路由器，它收到大量路由，会导致崩溃。其他路由器接着可能开始输入这些路由，直到崩溃的AS边界路由器或重启或它的AS外部LSA过时，那将会有大副度超过平时的数据库。保证在MaxAge时间（1小时）内出离溢出状态，如果溢出的发生，自动恢复可能是合理的（足够快）。只要路由器离开OverflowState，根据节2.2所述它符合条件则会再次进入OverflowState。

3. 实例

举一个例子，假定一个路由器实现了数据库溢出逻辑，并且它的ospfExtLsdbLimit设为10,000，它的ospfExitOverflowInterval设为600秒。再假定路由器本身产生400非默认AS外部LSA，在路由器中当前非默认AS外部LSA的当前数目是9,997。

接下来，它收到来自邻居路由器的一个链路状态更新报文，其中包含了6个非默认AS外部LSA，当前数据库中没有这些LSA。那么头两个LSA将被加入到数据库中。第三个LSA也会加入到数据库中，但是会引起路由器进入OverflowState状态。进入OverflowState状态会引起路由器进行刷新它自身产生的400个非默认LSA（经过早的老化）。但是，这400个LSA扔被视作为这个链路状态数据库中的一部分，直到收到它们再次的洪泛（期限设为MaxAge）(见[1]中节14)。由此，所收的剩下三个LSA不经证实便被丢弃。

经过一小段时间后，所有路由器将收敛致同一个数据库，拥有少于10,000个非默认AS外部LSA。在这个收敛期中，一些链路状态数据会重传；例如，上面所述链路状态更新报文的发送者将重传后三个被丢弃的报文。如果这次重传在刷新400个自产生的LSA之后，得到证实，那这3个LSA将被接受。进入OverflowState也会引起路由器设置定时器，它将在下540到660秒后起动。当定时器起动时，这个路由器将离开OverflowState且再次产生400个非默认AS外部LSA，倘若当前数据库有不超过9600(10,000-400)个非默认AS外部LSA。如果超过，定时器只是简单重启。

4. 对数据库溢出的管理

一旦链路状态数据库溢出，在所有路由被恢复前，可以采取网络管理手段来干预。（如果溢出状态短暂，路由会自动恢复，细节见节2.4）。SNMP陷门指示一个溢出状态（见附录B）。网络管理员可能采取的对策包括：

  • 增加ospfExtLsdbLimit的值。也许它被设得太保守了，路由器可以支持比现在配置下所得到的更大的数据库。
  • 将资源有限的路由器置于OSPF stub域或NSSA中。这将使其他路由器可以增加 ospfExtLsdbLimit的值。
  • 估计引入某种外部路由的需要，如果ospfExtLsdbLimit不能再增加，网络管理员要定出所要引入的较重要的路由，关闭一些不重要的路由。

5. 运作经验

述及的数据库溢出方案已在Proteon路由器上实现多年。与本文有几点不同，首先，路由器不离开OverflowState直至重启。（也就是，ospfExitOverflowInterval总是0）。第二，不区分默认AS外部LSA与非默认AS外部LSA。运行中方案执行理想：在溢出条件下，路由器所收敛的整个数据库拥有不超过配置个数的AS外部LSA。

6. 可能的改进

可能的改进包括下面所述：

  • 其他LSA类型，除了经过LSA(router-LSAs和network-LSAs), 可采用相同方式加以限制。例如，可以限制summary-LSA的数目，或group-membership-LSA的数目(见[6])。
  • 只要数据库达到ospfExtLsdbLimit，进入OverflowState时，路由器刷新一定数量的而不是全部非默认AS外部LSA。这将允许路由器区分AS外部LSA的优先次序，首先刷新不重要的LSA。

A. 相关MIB参数

在本文中，定义下面OSPF MIB变量以支持对数据库溢出的自理过程。（更详细信息见[4]）

  • ospfExtLsdbLimit：在本文中节2.1所述，可以存放在数据库中的非默认AS外部LSA最大数目。如果设为-1，就是没有限制。
  • ospfExitOverflowInterval：在本文中节2.1所述，进入OverflowState后，一个路由器将离开OverflowState的秒数。这允许路由器产生非默认AS外部LSA。当设为0，路由器不离开OverflowState直至重启。
  • ospfLsdbOverflow：陷门，意味着非默认AS外部LSA超过或达到ospfExtLsdbLimit。换句话说，这个陷门指出路由正在进入OverflowState。
  • ospfLsdbApproachingOverflow：一个陷门，指出非默认AS外部LSA的数目已经超过ospfExtLsdbLimit的90%。

参考文献

[1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
[2] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587,RainbowBridge Communications, Stanford University, March 1994.
[3] Moy, J., Editor, "OSPF Protocol Analysis", RFC 1245, Proteon,Inc., July 1991.
[4] Baker F., and R. Coltun, "OSPF Version 2 Management Information Base", Work in Progress.
[5] Moy, J., Editor, "Experience with the OSPF Protocol", RFC 1246,Proteon, Inc., July 1991.
[6] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc.,March 1994.

翻译声明

由于水平和时间的限制，本人对文章中翻译错误以及由此带来的各种问题不负任何责任。本文只针对不熟悉英文者，建议有英文基础的参看原文RFC 1765。欢迎指正文中错误。