nssa和stub_Stub区域和NSSA区域比较

Stub区域

STUB区域就是一个对区域概念的最典型的应用。STUB区域的设计思想在于：在划分了区域之后，非骨干区域中的路由器对于区域外的路由，一定要通过ABR(区域边界路由器)来转发，或者说对于区域内的路由器来说ABR是一个通往外部世界的必经之路。既然如此，对于区域内的路由器来说，就没有必要知道通往外部世界的详细的路由了，代之以由ABR向该区域发布一条缺省路由来指导报文的发送。这样在区域内的路由器中就只有为数不多的区域内路由和一条指向ABR的缺省路由。而且无论区域外的路由如何变化，都不会影响到区域内路由器的路由表。由于区域内的路由器通常是由一些处理能力有限的低端路由器组成，所以处于STUB区域内的这些低端设备既不需要保存庞大的路由表，也不需要经常性的进行路由计算。有了STUB属性之后，网络的规划更符合实际的设备特点。

以上描述的只是STUB区域的设计思想，在协议文本中，对STUB区域的精确定义是：STUB区域一定是非骨干区域和非转换区域(可以配置虚连接的区域)，并且在该区域中不可传递Type 5类型的LSA。由于OSPF是链路状态算法的路由协议，LSA就是用来描述网络拓扑结构的一种数据结构。在OSPF中将LSA分为5类：type1、2两种用来描述区域内的路由信息；type3用来描述区域间的路由信息；type4、5用来描述自治系统外部的路由信息。因为协议的设计者认为路由表中的绝大部分路由均是来自自治系统外部的引入的路由。

需要注意的是定义中对于过滤TYPE5类型的LSA使用的描述语言是“不可传递”，这就意味着不仅区域外的ASE(自治系统外部)路由无法传递到STUB区域中，同时STUB区域内部的ASE路由也无法传递到本区域之外。换一句更通俗的话来描述：STUB区域内的路由器都不可引入任何外部的路由(包括静态路由)。这样的定义未免太过严厉了。因为在实际的组网中，并不是所有的设备都会运行OSPF协议。例如：用户拨号上网时使用的接入服务器就需要连接路由器上因特网，但通常接入服务器上并不支持(也不需要)OSPF协议，而是通过配置静态路由实现路由功能。很多时候ISP为了保密或易于管理的需要，在连接用户侧的路由器时使用静态路由。总之：在一个网络中所有的路由器上都配置OSPF，而不使用静态路由的情况几乎是不存在的。——也就是说STUB区域的适用条件也是不存在的

NSSA区域

STUB区域虽然为合理的规划网络描绘了美好的前景，但她在实际的组网中又不具备可操作性，未免遗憾。但此时的OSPF协议已经基本成型，不可能再做大的修改。为了弥补缺陷，协议设计者提出了一种新的概念NSSA，并且作为OSPF协议的一种扩展属性单独在RFC 1587中描述。

NSSA需要完成如下任务：

自治系统外的ASE路由不可以进入到NSSA区域中，但是NSSA区域内的路由器引入的ASE路由可以在NSSA中传播并发送到区域之外。即：取消了STUB关于ASE的双向传播的限制(区域外的进不来，区域里的也出不去)，改为单向限制(区域外的进不来，区域里的能出去)。

由于是作为OSPF标准协议的一种扩展属性，应尽量减少与不支持该属性的路由器协调工作时的冲突和兼容性问题。为了解决ASE单向传递的问题，NSSA中重新定义了一种LSA——Type 7类型的LSA，作为区域内的路由器引入外部路由时使用，该类型的LSA除了类型标识与Type 5不相同之外，其它内容基本一样。这样区域内的路由器就可以通过LSA的类型来判断是否该路由来自本区域内。但由于Type 7类的LSA是

新定义的，对于不支持NSSA属性的路由器无法识别，所以协议规定：在NSSA的ABR上将NSSA内部产生的Type 7类型的LSA转化为Type 5类型的LSA再发布出去，并同时更改LSA的发布者为ABR自己。这样NSSA区域外的路由器就可以完全不用支持该属性。从上述描述可以看出：在NSSA区域内的所有路由器必须支持该属性(包括NSSA的ABR)，而自治系统中的其他路由器则不需要。由于NSSA是由STUB区域的概念改进得来，所以她的名字叫做："not-so-stubby" area ，本意是：不是那么STUB的区域。