OSPF的距离矢量特征

tea

我们时常说，OSPF是链路状态路由选择协议，其实这厮也有距离矢量特征的，巴扎黑



    上图中，假设所有的OSPF接口cost=1，那么R5更新5.5.5.0这条路由，R3是能学习到的，R3会怎么走呢？直观的来看，R3去往5.5.5.0走R4，cost会更小，然而实际的结果是，R3去R5会走R1。
因为R1作为ABR产生的3类LSA，而R4不是ABR（还记得ABR的概念么？）无法下发3类LSA，那么R3将只会从R1收到3类LSA，因此不管从R4走cost如何小，R3将只能通过R1到5.5.5.0网络。
其实，OSPF在区域内部，的确是链路状态协议的处理方式，然而在区域之间，OSPF的对路由的处理却有典型的距离矢量特性。




    我们看上面的图，R1宣告1.1.1.1/32这条直连链路，R1将在area1内泛洪自己的LSA1，其中就包含这段直连链路，这是典型的链路状态协议的特征。随后R2搜集到LSA1，并且为area0生成LSA3，注意，这时候LSA3的通告路由器就变成了2.2.2.2也就是R2，同时R2为路由加上自己的接口metric，64+1=65。随后这条LSA3被R3接收，R3将信息改写，仍然是这条路由，通告路由器变成了3.3.3.3也就是R3，同时，R3在自己接收到的metric 65的基础上，累加上自己接口的cost，得到129，并将这条LSA3再注入到area2 – 上述动作，是典型的距离矢量路由协议的特征，RIP不就是这么干的么？路由一跳一跳的传递，每跳路由器累加一跳然后发出去。好了那么RIP作为距离矢量路由协议，有水平分割等防环机制，那么OSPF呢？OSPF则要求，所有的非骨干区域的3类LSA的传递必须经过area0来中转，也就是说，所有常规区域必须与骨干区域area0直连，以此来达到防止环路的目的。
    这么一来本小节的第一个图就能理解了，既然3类LSA只能通过area0进行中转，且中转的动作必须由ABR来完成，那么R4这个屌丝自然无法为area1或area2去生成3类LSA。

接下去，我们来看一个典型的问题：




        上图中，编号1、2、3、4并非实际的协议运行步骤，只是我们观察点的一个转移而已。R1、R2、R3、R4都会在area1内泛洪自己的LSA，从而描述自己所有直连的OSPF接口（Link），因此R3将4.4.4.0的路由装载进路由表，这是经过SPF算法计算得出的最短路径，路由的类型为O，区域内的路由。接下去我们将视角切换到R1、R2，这两个ABR都会收到area1内路由器的1LSA的泛洪，它两会各自将area1内的LSA1及LSA2（若有）搜集后归纳成LSA3，并且在area0内进行泛洪，LSA3的LINKID就是其描述的路由的前缀，在R1及R2上查看OSPF database可以看到，在area0中，R1及R2都会各自泛洪4条3类LSA，分别描述10.1.13.0、10.1.34.0、10.1.24.0、4.4.4.0这四个网段，如此一来，在area0中，就有共计8条3类LSA在泛洪。接下去我们将视角放到R1，R1从R2收到这四个网段的3类LSA，会将这些LSA的通告路由器改为R1自身，并且进一步在area1内泛洪，如此一来R3将从R1收到四条3类LSA，尽管R3并不需要这些LSA，R3会将忽略它们，甚至不会安装进自己的LSDB。
OK，那么现在我们在R3上 定义个ACL，匹配4.4.4.0，随后debug ip routing access-list x去跟踪这条路由的更新，然后在R4上DOWN掉4.4.4.0，这个时候会出现个诡异的现象：


*Mar  1 11:08:00.057: RT: del 4.4.4.4/32 via 10.1.34.4, ospf metric [110/65]
*Mar  1 11:08:00.057: RT: delete subnet route to 4.4.4.4/32 // 路由delete，因为R4的告知
*Mar  1 11:08:00.057: RT: NET-RED 4.4.4.4/32
*Mar  1 11:08:00.121: RT: SET_LAST_RDB for 4.4.4.4/32
  NEW rdb: via 10.1.13.1

*Mar  1 11:08:00.121: RT: add 4.4.4.4/32 via 10.1.13.1, ospf metric [110/193]
*Mar  1 11:08:00.125: RT: NET-RED 4.4.4.4/32   //路由竟然又回来了，因为R1还没收敛，仍然通告LSA3
R3#
*Mar  1 11:08:05.125: RT: del 4.4.4.4/32 via 10.1.13.1, ospf metric [110/193]
*Mar  1 11:08:05.125: RT: delete subnet route to 4.4.4.4/32  //路由delete R1收敛了
*Mar  1 11:08:05.129: RT: NET-RED 4.4.4.4/32
*Mar  1 11:08:05.129: RT: SET_LAST_RDB for 4.4.4.4/32
  NEW rdb: via 10.1.34.4

*Mar  1 11:08:05.133: RT: add 4.4.4.4/32 via 10.1.34.4, ospf metric [110/321]  //又回来了，R4凌乱了
*Mar  1 11:08:05.133: RT: NET-RED 4.4.4.4/32
*Mar  1 11:08:05.265: RT: del 4.4.4.4/32 via 10.1.34.4, ospf metric [110/321]
*Mar  1 11:08:05.265: RT: delete subnet route to 4.4.4.4/32
*Mar  1 11:08:05.265: RT: NET-RED 4.4.4.4/32                        //终于平静了


        我们可以看到，R3上关于这条路由经历了上面这个诡异的过程，造成这种现象的原因，还是在于LSA3，OSPF处理LSA3的行为，是典型的距离矢量的行为，是不是有感觉了？
        当然，对于LSA3，OSPF也是存在类似水平分割的机制，如下图：





R2将area1内的路由归纳成LSA3注入area0，R3收到后，将这些LSA3的信息修改，通告路由器变成自身，同时累加路由的metric，然后再传入area2，那么在这个过程中，R3是不会将这些LSA3再注入回area0的。
我们刚才那个的双ABR的环境比较特殊，因此存在上述的问题。



红茶三杯（朱SIR）
网络工程 | 项目管理 | IT服务管理 | CCIE培训
学习 沉淀 成长 分享
微博：http://weibo.com/vinsoney
博客：http://blog.sina.com.cn/vinsoney

子杰

沙发！！哈

jkrh9

先看下

gekey

经典不能错过·······

Jeff.

耿叔继续发威。

victor_huang

这个都被你发现了，不错不错~！~

bookpig

好东西，鉴定完了。。。巴扎黑！

a773545812

长知识了！

葡萄哦特曼

有恍然的赶脚

wjlovezzd

有恍然的赶脚