超强CCNP OSPF学习笔记第一集

NP跨年班继续了，像OSPF这么高深的东西本来我们是不敢乱写的，但大家实在是太抬举我了，我也顶不住萌爷的一再嘱托，更有大哥发帖求帖子，没办法，我只有厚着脸皮以我鄙陋的见识来窥探一下OSPF的奥义，仅仅起个抛砖引玉的作用，跪求各种大神给出真正的OSPF的帖子。刚好今天是四六级考试，小生侥幸一次考过，趁着今天宿舍一人，安安心心的写个帖子。
说到OSPF还是得从他的历史说起。随着网络技术的迅速发展，网络的拓扑变得越来越复杂，早期的路由协议RIP（version2）越来越hold不住了，网络协议的开发者们急需开发出一种新的协议来适应新的网络情况。IETF作为IAB（Internet Architecture Board因特网体系结构委员会）下属的一个组织，专门负责关于因特网的协议开发和标准化，因此，这个光荣而又艰巨的任务就落在了他的头上。但是IETF又不像IEEE那样成立的早，底子厚，说话做事底气足，更让他们窝火的是IEEE老说自己是个草根班子，开发的东西稀烂，于是乎我们的IETF就立下雄心壮志一定要整出个惊天地泣鬼神的协议出来让大伙看看野百合也有春天的。打点好一切就放手干起来了。
既然放出话来要亮瞎xx狗眼，考虑起协议的设计来当然是无所不用其极。OSPF要作为一个高级的路由协议存在，首先当然是无类的，人家RIPv2都无类了，你现在还整个有类出来，自己都想抽自己两巴掌；第二是要快，RIP的那个收敛和查询实在是太慢了，在大型网络中实在不堪重荷，OSPF一定要快起来跟上时代的步伐；第三点是无环，RIP这种基于距离矢量的路由协议从理论上来说是有出环的可能的，为了防止他出环RIP做了大量的工作，OSPF想的是能不能从算法就杜绝出环的可能，从而避免这种情况，这个时候的链路状态协议IS-IS给了OSPF一些借鉴意义，OSPF看到了用链路状态来描述路由（path，这里强调的路径状况）的优势，觉得这个可以有；第四是扩展性，OSPF想的是既然做了我就要做漂亮，我要让你们看到我除了路由之外还有其他的强大之处。当然，OSPF还有很多的优点，比如他是增量更新，不像RIP一样一变化就是给的整张表又浪费链路资源，等等，这里不一一列举，在后面的介绍中，大家自己来总结他的优点。上面所说的四点其实也是任何一个高级路由协议要考虑的，就是无类、快、无环、扩展性，大家看看EIGRP也完全是具有这些特性的。
关于OSPF的无类没什么好说的，这点大家都懂的。但是关于他的快，是需要讲一下的。
一个协议想要快起来你就不能太被动，你得主动。就好比你喜欢上一个姑娘，你得积极主动才能尽可能早的获得人家芳心。OSPF就是通过主动发送Hello来建立neighbor这种关系来做到积极主动的。当然，OSPF的快是通过一系列完整的机制来达到了，这里只是简单的引出neighbor这个概念来方便下文的展开。
OSPF使用了LS来获得关于全网的拓扑，并使用SPF算法来计算出每台路由器自己达到目的地的路径，从而做到的无环，而不是像DV协议那样“听取流言式”的方式来获得路由，然后通过一大堆机制来防环。其实一直以来很多人都是只知道SPF算法能够算出无环路径，但是怎么做的搞不清，不过确实，我们没必要搞那么清楚，因为SPF本身就固化在OSPF里，这一步由路由器来完成的，我们并不需要理解，但总有那么一些人想知道SPF是怎么回事，这里我也简单的给出关于SPF的一些东西，仅供大家参考。郑重声明：不感兴趣的同学请跳过！！！
SPF算法又叫Dijkstra（迪杰斯特拉，该算法的开发者）算法。该算法是数据结构中单源点的最短路径问题中的一种解法。即给定带权有向图G和源点v，求从v到G中其余各顶点的最短路径。带权就是说的两点之间的长短，类似于cost，有向指的是只算自己到别人那去的路，而不考虑别人到我这的路。Dijkstra提出了一个按路径长度递增的次序产生最短路径的算法。
Dijkstra算法：

• void ShortestPath(Graph G, int v0，int P[n][n], int D[])
• { int k,w,i,j,min;
• int S[maxvex];
• for(w=0;w<G.VEXNUM;W++)
• {
• S[w]=0; //若顶点Vw∈S，则S[w]=1,否则为0
• d[w]=g.arcs[v0][w];
• for(k=0;k<G.VEXNUM;K++)
• p[w][k]=0;
• if(d[w]<INTMAX) intmax="32767
• {
• p[w][v0]=1;
• p[w][w]=1;
• }
• }
• d[v0]=0;S[v0]=1;
• for(i=1;i<G.VEXNUM;I++) 对其余的每一个顶点
• {
• min=intmax;
• for(w=0;w<G.VEXNUM;W++)
• if(!S[w])
• if(d[w]<MIN)
• {
• k=w;
• min=d[w];
• }
• S[k]=1;
• for(w=0;w<G.VEXNUM;W++)
• if(!S[w] && (min+g.arcs[k][w]<D[W]))
• {
• d[w]=min+g.arcs[k][w];
• for(j=0;j<G.VEXNUM;J++)
• p[w][j]=p[k][j];
• p[w][w]=1;
• }
• }
• }
  

复制代码
其实这问题扩展开了来讲要讲蛮久的，我也就坑爹的丢了段代码上来，能看懂的就看，看不懂也拉到，萌爷经常对我们讲，这个不要求我们理解，Dijkstra也在2002年“无耻的死掉了”（萌爷原话），我们得感谢他给我们留了这么一东西，坑了一代又一代（不说别的，光是关于这个的课程设计都不知道死了多少人了）。
上面说到了关于neighbor这个概念，OSPF要想主动的获取关于整个拓扑的信息就必须有通过邻居来交换信息，这点在SPF算法中也有体现，因为任何一个结点都只知道与自己相连结点之间的信息，所以他得靠与自己相连结点告知自己才能知道整个网络的拓扑。OSPF通过邻居的建立来相互交换信息，从而每台路由器LSDB都相同，当大家的LSDB同步后再一起进行计算从而得到RIB。其实从SPF的角度考虑，每个人只需要算自己的，但是OSPF设计让大家的LSDB同步后再一起算，这样做是因为在OSPF的邻居交互中你并不知道自己拿到的是否是完整的信息了，必须要大家都同步才能确认自己已经得到了全网拓扑了，不然假如你先计算了，这是邻居又给你一条信息，那你又得重新计算。这也是OSPF的缺陷所在，就是只要有一个人变了，大家都得跟着变，其实就现在的硬件水平来说，我觉得运行SPF到是花不了多少代价，其实他的空间复杂度和时间复杂度并没有想象中那么高，关键就是，一变都得变这一点挺头疼。因为现在的网络越来越大，拓扑越来越复杂，你一变人家都跟着你变，这是相当不稳定的。另外，假如你的拓扑足够大，还有可能你连的网络垮了，你的通告还没到别人，别人的数据已经到你这了，这也是不能接受的。当然，上面是我自己的观点，如果你接受不了就还是认为由于运行SPF的代价太大，所以尽量避免他的计算这是OSPF的缺点所在，都没问题的，反正最终都是减少了SPF的计算。由于一变皆变的特性存在，有些人不爽，希望减小这种变化对自己的影响，于是提出了区域的概念，即将变化控制在一个区域内，让外面的人不要受到影响（这里指的是不运行SPF）。但是单区域设计多大也是个需要考虑的问题，假如有个区域设计过于大，那么前面的问题依然存在。其实关于区域大小，目前没有个标准，这也不好定标准。但是思科根据自己多年做项目的经验给出的建议是：每个区域包含的路由器数量不应超过50台；每台路由器所属的区域数不应超过3个。（可以参考Cisco的《Internetworking Design Guide》中“Designing Large Scale IP Internetworks”相关内容）
前面说了这么一大堆其实就是这么个情况：neighbor----RTP---->topology----SPF---->RIB，另外就是进行SPF的必要条件是拓扑发生了变化（本来是充要条件，由于区域的提出，非变化区域不满足充分性了）。
下面我们来讲讲OSPF的neighbor的建立。
首先就是P2P的环境：

R1和R2用s0/0相连，地址分别是192.168.12.1/24和12.2/24，R1和R2上各有一个环回口0，地址分别是192.168.100.1/32和100.2/32，router-id分别是1.1.1.1和2.2.2.2我先在R1上起的OSPF

大家可以看到前14个包都是R1在向组播224.0.0.5发送Hello，因为这时R2的OSPF进程还未打开。R1这时处于down状态，因为他还没有与其他路由器交换信息；
第15包是R2向组播发送的Hello，这时R2的OSPF进程刚刚开启，R2也处于down状态；
第16个包是R1向组播发送的Hello，但这个Hello跟前14个Hello又不一样，点开第14个Hello和第16个Hello来看：


大家首先看到的就是两个包的大小不一样，第14个是80个字节，而第16个是84个字节，说明第16个肯定是加东西了，再看看OSPF Hello Packet下的Options，第16个包里多了个Active neighbor：2.2.2.2的字段，这表明R1这时收到了R2发送的Hello了，而且建邻居所必须的参数也都匹配了（这个问题后面会讲），于是R1这时处于init（初始化）的状态，因为这时R1并不确定R2是否有收到自己的Hello，大家可以看到这个包是R1往组播发送的，目的是告诉R2自己看到他了，在RFC文档上其实规定的是R1这时应该使用单播告诉R2自己看到他了，这里是思科做出的改动，思科认为，既然我是P2P的，那么反正对端也就一个人，我往组播里发，总是你收，这里单播改组播简化了在P2P上的操作；
第17个包是R2向组播发送的DBD：

大家可以看到这个包的DB Description的I、M、MS三个比特都为1，I比特为1是说这是我的第一个DBD，M为1是说我还有更多，MS为1是说我自己是master，这是R2为了跟R1协商主从关系而发的，另外这里R2都开始在DBD了，说明R2已经收到了R1发的关于说R1看到R2的那个Hello了，所以这时R2处于2-way状态；
第18个包是R2发送的Hello，也是84个字节，这个包的option里同样也有Active neighbor：

后面写的是1.1.1.1，说明这是R2为了让R1知道自己也看到他了，从而让R1 2-way的包，很多情况下抓的包你会看到这个包的时间与上一个包（17）的时间是一样的，而且与接下来R1发送的两个包（19和20）这样很有可能也是一样的，这很容易让人迷惑的，这次抓包人品还算好看到了R2发送的DBD与Hello时间不一致，说明还是DBD（17）在前的，Hello（18）在后面的；
第19个包是R1发的DBD，同样这是为了协商主从关系的DBD：

这个包的I、M、MS也都为1，R1也说这是他的第一个，他还有更多，自己是master；
第20个包是R1发的DBD，大家先看看这个包的I、M、MS这三个比特：

这三个比特分别是0、1、0，这说明R1说这不是我的第一个包，因为前面他已经发过DBD了，当然不是第一个了，我还有更多，我不是master，也就是我是slave，大家再看看第19和20个包的计时器，这两个包是同时发送的，这说明第19个包是R1用来回应R2那个让自己2-way的包的，因为自己收到R2这个Hello后才2-way，2-way后R1当然要参与master的选举，以确定谁来主导交互信息，但这个时候R1发现自己还收到的有R2发来的一个DBD，上面的router-id比自己还要大，于是R1还发送了第20个包，说明自己不是master，于是R1与R2之间的主从协商完成，由R2来主导双方的交互，另外大家还是发现第18、19、20三个包的时间是一样的，可能大家会认为这三个包是同时的，但大家看到了第17和18个包有0.01s的差距，而第19个包是用来响应第18个包的，第20个包是用来响应第17个包的，所以应该还是有时间先后上的差别的，只不过由于这个交互太过迅速，几乎就是同时的，所以没看到他们的差别（这点我是根据我抓了好多次包猜测的，没有翻阅RFC进行考证，希望有考证后的人给出说法）。
这里大家还要注意一下每个DBD里都包含有个DD sequence，在双方还没协商出谁是master时，大家都自己随机起一个DDsequence，但是一旦协商出谁是master后，就以master的DD sequence来相互隐性确认自己收到了对方前面发的DBD了（直接回对方的DDsequence而不是加1），这一点跟eigrp是一样的（我觉得就是eigrp抄袭ospf的，个人观点）。大家不要把这个sequence与LS的sequence混淆了，LS的sequence是用来确认LSA新旧用的；
第21就是R2向R1描述自己连接着哪些网络；
第22就是R1向R2描述自己连接着哪些网络；
这里他们相互之间都描述一下，让对方清楚自己后面的情况，从而对方能够知道request什么，也就是请求自己没有的网络的信息。
第23个包是R2发送的request，这时他已经知道R1后面的情况，于是R2要请求R1上自己没有的信息；
第24个包是R1发送的update，把R2请求的信息发给R2；
第25个包是R2发送的update，大家可以看见这个update的大小和R1发送的update的大小是一样的，这时的R2是在收到R1的update后给出的update，让R1好看看R1的数据库有没有和R2的数据库同步（因为R2是master，交互由master主导，所以当master的数据库更新后要丢出update方便slave也进行更新）；
第26个包是R1发送的update，该包比他自己发送的前一个update（第24个包）在描述自己所连网络上并没有什么差别，但是大家看到这个update的大小比前一个多了12个字节，那么多的内容是什么呢：


大家看到了第26个包多了个Type PTP的东西，这个刚好12个字节，正是多出的部分，这个东西后面写着ID：2.2.2.2 Data：192.168.12.1 Metric：64，这是R1在说自己跟一台Router-id为2.2.2.2的路由器通过自己的IP为192.168.12.1接口相连，到该路由器的metric是64，这么做的目的是为了更好的描述出拓扑，方便自己SPF计算得出与路由相关的信息；
第27个包是R2对于R1的显式的Acknowledge，确认对方的信息自己都收到了；
第28个包是R1对于R2的显式的Acknowledge，确认对方的信息自己都收到了；
至此，双方的邻居关系建立完毕，信息交互也完成了。
但是大家可能发现第32个包R2又发送update了，这是因为我在R2上network 192.168.100.2 0.0.0.0 area 0慢了，在R1和R2的邻居关系建立和信息交互之后，所以这个时候起的接口所在的网络信息R2将通过update的方式发送，R1收到后回了个显示的Acknowledge（第34个包），表明自己收到了。
其实这个抓包还没有让大家看到完整的P2P下两台路由器之间的邻居建立和信息交互的过程。比如，由于R2上我network环回口晚了，R2在DBD时（第21个包）直接说自己没了，而细心的人可能看见第20个包也就是R1说自己是slave的那个包的大小比其他的DBD都大，为88个字节，而其他的DBD都只有68个字节，这个包携带了一个叫LSA Header的东西，刚好20个字节，这是R1在向R2描述自己所连网络，而R2之所以没发这种包，是因为这个时候R2上只有与R1相连的这段网络参与到OSPF进程之下，而R2受到R1的DBD后发现自己所连的网络R1上都有，于是没有东西给R1描述，于是没有这种包。正常情况下，若R2上也有R1所不知道的网络信息R2是会用这种DBD发给R1的。另外，大家可能看到了只有R2向R1发送了request而R1并没有向R2发送request，道理还是一样，R2都没有向R1发送关于R1所不知道网络信息的DBD，R1当然也没有需要请求的内容，所以R1没有发送request，正常也应该有。另外，关于今天下午我在群里说我抓包抓出shi了，有很多次不同的抓包有一些难以理解的包发出来，当然到最后除了一次抓包中有一点不能以上面的流程解释外，其他都可以，彪哥告诉我，有可能是GNS3的问题，要嘛就是别的问题，所以，小概率事件姑且先放着，等我发现有什么不妥的地方我会及时的放出来的。
总结一下，在P2P上邻居关系建立的流程：
R1先起OSPF进程，此时处于down状态，R1----向组播发送Hello------->
<----R2向组播发送Hello---- R2后起OSPF进程， down
R1收到R2的Hello，此时R1处于Init状态，R1-----发送含有Active Neighbor的Hello----->
<-----R2发送DBD，自己的第一个，还有更多，自己是master-----R2收到R1Hello，知道R1看见自己，自己2-way
<----R2发送含有Active Neighbor的Hello-----R2发送Hello让R1能够2-way
R1收到R2的Hello，知道R2看见了自己，R1 2-way，R1----发送DBD，自己的DBD，还有更多，自己是master----->
R1看到了R2的DBD中RID更大，主从关系建立，此时R1处于Exstart状态，R1----发送DBD，自己是slave，用对方的DD sequence，含有LSA Heaer，描述自己所连网络--->发送过程R1处于Exchange状态
<----R2发送DBD，含有LSA Header描述自己连接哪些网络-----R2收到R1的DBD，知道他有哪些自己没有的网络和自己有哪些网络R1没有，R2处于Exchange状态
R1收到R2的DBD，R1处于Exchange，R1-----发送DBD，不含LSA Header，说自己没了---->
<----R2发送DBD，不含LSA Header，说自己没了----R2收到R1的DBD，R2处于Exchange
<-----R2发送Request，请求R1上所连接的自己没有网络信息----R2处于Load状态
R1处于Load状态，R1----发送request，请求R2上所连接的自己没有的网络信息---->
R1处于Exchange状态，R1----发送DBD，来隐性确认R2的那个说R2没了的DBD，因为交互由R2发起，所以R1要对R2进行交互终止确认---->这个DBD和Request是同时发出的
R1收到R2的Request，R1 处于Load状态，R1----发送Update---->
<----R2发送Update----R2收到R1的Request，R2处于Load状态
<----R2发送更新后的Update，含有Type :P2P----R2收到R1的Update，R2 Load
R1收到R2的Update，R1 Load，R1----发送Update，含有Type :P2P---->
<----- R2发送Acknowledge----R2收到R1的Update，R2处于Full状态
R1收到R2的Update，R1 Full，R1----发送Acknowledge---->
至此双方的邻居关系建立和信息交互完毕。
今天由于抓了几个让我很费解的包，耽误了不少时间，所以这个帖子给出的东西也不多，后续会继续放出余下内容的，欢迎批评指正。


超强CCNP OSPF学习笔记第二集
http://bbs.vlan5.com/forum.php?mod=viewthread&tid=978&fromuid=55

路过占楼而已

有道理。。。感谢攻城狮论坛

我是个凑数的。。。

支持一下:lol

小手一抖，金币到手！

找到好贴不容易，我顶你了，谢了

学习了，谢谢分享、、、

找到好贴不容易，我顶你了，谢了