OSPF 广播多路访问网络

bluerainyumen

tjkckj 发表于 2014-5-19 10:39
我是这么理解的
就是有两个LSACK，R1是DR，R2是BDR,R3和R4是DROTHER
DR和BDR都是接收全网LSU的，然后通过 ...

R3发出的LSU（DIP：224.0.0.6），DR、BDR都能收到，为什么只有BDR（R2：192.168.0.2）回复LSAck？DR不回复么？

bluerainyumen

q0066421 发表于 2014-5-19 19:16
我试着解释：
R3拓扑变化，产生lsu，目的地址224.0.0.6
每台都会收到，但drother不监听，不处理；bdr只接 ...

牛逼

q0066421

白书生 发表于 2014-5-20 19:53
理解四句话就ok了：
                        1.DRother发送LSA给DR/BDR用224.0.0.6（D ...

四句话显然不ok啊，没讲明白lsack的问题啊。到底什么时候需要lsack

bluerainyumen

blue丶wd 发表于 2014-5-19 10:55
DRother发送LSA使用的目标地址为224.0.0.6  而DR/BDR同时可以监听224.0.0.5、224.0.0.6两个地址
DR/BDR发 ...

“全网第一次LSA泛洪时目标地址是组播地址，以后的触发更新都是单播了”
触发更新是用的单播么？

ihorse

我做的实验结果是：第一个问题，两个ack问题
1，DRother路由器本地 更新一条路由，DR不会给他回复ack，BDR却给改DRother回复ack；2，dr路由器本地 更新一条路由，则它会收到ack。

你这里10.1 DR 10.2是BDR
第一个acl是由10.2回的，很正常了
第二个ack是由10.4回的，应该是10.4收到了DR给他的update消息了，它给DR ack一下，打个招呼，不能白拿人家update啊，呵呵；

第二问题，updata目的地址问题
1，第一次更新flood
2，之后你再次宣告一条路由后的触发，uptate目的地址也是flood,
是我的实验效果。

ihorse

R1是DR R2是BDR--DR BDR监听224.0.0.5、224.0.0.6
R3 4是DRother--DRother监听224.0.0.5
R3触发更新报文向224.0.0.6，只能被DR BDR收到
DR收到后，会向224.0.0.5发update
R3没回ack，因为tm是我R3本地更新的路由，我还用得着像别人确认？呵呵
R4回了ack给225.0.0.6即给DR做了确认。
纠结的地方：
BDR收到DR的update报文后也发ack。目的地址是224.0.0.5。为什么不是224.0.0.6呢？
如果是224.0.0.6那么该报文只能有DR收到。
此处确实224.0.0.5，莫非他既想然DR收到，又想让DRother收到？
也就是说，既想让发updata的人收到，也想让改lsa起源路由器收到，双保险？
再说了，ack只是为update做确认，那该地址为何是224.0.0.6?而不是224.0.0.5，不得而知。

hdjsjxczx

我先学习学习

bluerainyumen

ihorse 发表于 2014-5-20 23:21
我做的实验结果是：第一个问题，两个ack问题
1，DRother路由器本地 更新一条路由，DR不会给他 ...

辛苦了

q0066421

ihorse 发表于 2014-5-20 23:30
R1是DR R2是BDR--DR BDR监听224.0.0.5、224.0.0.6
R3 4是DRother--DRother监听224.0.0.5
R3触发更新报文 ...

我觉得这和dr、bdr在网络中作用、关系；以及ospf设计理念有关系。
梳理一下流程：
-首先是R3（drother）发lsu，以224.0.0.6为目的，这个不用说，因为它想让dr和bdr都知道；
-R1（dr）收到lsu，它要不要确认？要，因为不确认，drother不知道dr是否收到，就还得继续发。但R1会以泛洪这条lsu的形式来对R3进行确认，也就是隐式确认。目的224.0.0.5
-R2（bdr）先收到R3的lsu，它有两种选择：1，确认，2，不确认。我们来分析，如果它确认，有意义吗？只要R1不确认，R3就会继续发，不管你R2确认与否；R1一旦确认，R3就不再发了，同样不管你R2确认与否，因为R1负责数据库的同步。可见，R2对于R3的lsu是不需要也不会确认的。

接下来是各位对于dr所发lsu的反映：
-R2收到R1的lsu，同样两种选择。如果不确认，R1肯定要再发，直到R2确认，所以R2只得确认。而确认又有多种方式：单播给R1；组播224.0.0.5；224.0.0.6、如何抉择？
单播的话，只有R1收到，而对于此lsu的最初发送者R3，它其实还一直惦记的，毕竟给R2的消息没有得到确认。所以最好是让R1和R3都收到。这个lsack其实是身兼数职：对R1的显式确认，对R3的隐式确认。
-R3收到R1的lsu，因为是自己所出，不回复亦可。
-R4收到R1的lsu，那必须回复。

上面的基本可以说明问题，但是我觉得我们还可以再进一步去理解ospf的设计理念，它确实是很科学的。
1，R3收到R1的lsu，为什么可以不确认，仅仅因为是出自它自己？不，还因为，lsack的目的是保证可靠传输，保证同区域ospf数据库的一致。R3能发送lsu给R1，说明R3活着，而且与R1之间链路正常，R1的lsu，R3理应能收到；即使没收到，也不会影响数据库的一致，R1也不需要重发lsu。所以R3完全没有确认的必要。
2，R2对R1的lsu以224.0.0.5进行确认，全网段ospf路由器都收到了，R1、R3理应的，不说；假如还有R5、R6、Rxx的都收到了，对它们岂不是豪无意义的负担，ospf这么做与设计dr、bdr来减少数据包数量的目的不是相违背吗？并不是，因为ma网络的dr、bdr很重要，它们一旦出事，就必须马上有接班人顶上；而它们健在时，也要经常向下面宣布：我活的好好的呢，你们都老实点，别动歪心思！dr泛洪的lsu有这个作用，bdr泛洪的lsack也有同样的作用。这个可以通过实验来验证：将全部的hello-interval适当改大数倍，目的增大dead time，让现象更明显。然后对R3的端口shutdown，no shutdown反复操作，在R4上不断show ip ospf neighbor，可以看到，即使没有收到对方hello包，dead time一项也会随着路由更新而被刷新。
你不对我say hello，但是你都给我糖吃了，我当然知道你还活着。

通过这样的设定，每个可能导致数据库不一致的lsu都会有确认，包括显式和隐式。drother发的lsu都会收到dr和bdr的确认，大家一致认为现在的领导很负责任，不需要重新选举。

其实我还在想，是否还有其它机制保证ospf MA网络的稳定，比如：当大家没有收到bdr的lsack时，是否不等到dead time超时，就可以通过某种方式查询并竞选bdr？还没想好实验方案。

q0066421

白书生 发表于 2014-5-21 18:42
霸气····我居然无聊得看完了·····你是讲师吧··能说这么长····理解的人看起来还 ...

还是那句话啊，你概括的里面我是无法看出lsack到底什么时候需要，什么时候不需要。而楼主这个问题最初就是盯着lsack的。这个问题真能说明白的，我不认为鸿鹄论坛能有几个人，最关键的是，明白的人都忙，都没空理我们这些人。
印象中听说过，bdr抢夺dr的问题，一般不是等到与dr的dead time超时才抢，具体不记得了，应该是怎样抢夺，可否赐教？算了，算我没问吧，你2句话解释完，我还是不懂。
我理解能力差，确实得承认，别人一句话就能明白的东西，我得翻译成自己的好几句话，还得偷着琢磨半天才行。
我觉得自己很多问题都是开始自己以为理解了，却经不起问，问问就犯蒙了。我们不是一个量级的人，我的苦恼你是不会懂的。

Bulade

好贴，学校中