详解R6诡异的ping
上述分析只是解释了R3的下一跳问题，但是开篇提到的最根本问题仍然没有回答。
为什么R6以56.1.1.6为源可以ping 4.4.4.4，但是以6.6.6.6接口地址为源反而不行?
在分析此问题之前，先说说一个背景知识，网络设备如何做负载均衡。
网络设备负载均衡浅谈
简单聊完负载均衡以后，回到话题。
对R3来说，去往4.4.4.4有两个下一跳，一个是正确的下一跳R4，另外一个则是错误的
下—跳R2。
从负载均衡的特性来看，R6通过不同IP地址ping R4的还回地址4.4.4.4，并得到了不同
的结果。
其原因可能就是遭糟遇了负载均衡算法的影响。
那如何证明此猜想是正确的。
还真有办法，方法就是去查阅转发表。
如下所示：
#上述内容为转发表FIB针对4.4.4.4/32的表项
# 接下来就是见证奇迹的时刻。
#我们可以通过一个命令来确认R3针对某个IP源、目标地址组合会采用那一个下一跳。
如下所示：
#上述命令询问R3,要是一个源地址为56.1.1.6目标地址为4.4.4.4的数据包，你选那一个接口？
#R3回答：送它去R4(34.1.1.4)
#同理，当源地址为6.6.6.6目标为4.4.4.4的数据包来时。
#R3说，送它去R2(23.1.1.2)
看了上面的输出，瞬间豁然开朗。
原来这就是R6出现如此奇葩i问题的根本原因。
再次证明，当出现某些奇葩问题时，先从每一个环节出发，掌握细节部分，逐个击破。
问题并不—定都是硬件设备故障或者软件BUG。
但是，故事还没有完，请继续。
把偶尔变成必然
综上所述，你可能质疑上述实验是一个“巧合”，现实生活中并不一定存在。
让我逐个澄清：
关于重分发度量值为1的情况，其实日常工作环境中，出现的比例相当高。例如在上述RIP网络中，R4后面可能还有更多的网络节点，而这些节点都通过RIP发布网段到网络中，最终导致R3上肯定有某一条路由和R2“"环路""的方式发布过来的度量值相同。
此时问题就发生了
而针对第二项，的确是一个概率性问题，而其导致的问题就是，你不知道什么时候某一个网段不工作了。
例如上述案例中是6.6.6.6为源到4.4.4.4不通，但是可能某一天又变为56.1.1.6为源到4.4.4.4不通了。
原因是转发表会把之前随机选择的端口记录超时掉，然后重新选择。(就好比打麻将，玩完一局以后洗牌再重来。)
但是，我个人认为上述"所谓的巧合"案例是极其值得分享，至少你遇到此种问题时，知道如何下手分析。
必然发生的网络环路：
最后，再给你演示—个必然发生的网络环路。
再次奉上R3的4.4.4.4路由条目:
你是否考虑过，如果R4哪一天突然不发送4 .4 4.4/32的RIP更新给R3了?例如接口down掉了。
会有什么事情发生?
实际操作一把看看:
再次查看R3的路由表：
恐怖的事情发生了，4.4.4.4/32仍然健在。
此时，网络中任何流量去往4.4.4.4都是像进入网络黑洞环路诞生了。
以R6为例，之前源为56.1.1 .6的IP地址可以与4.4.4.4通讯,现在再看看:
R6无法ping通R4的4.4.4.4了，traceroute也证实了环路诞生。
不光是R6,随便挑一个路由器，咱们就挑R3吧，如下所示：
R3也环路了！幸好这是实验室，若在现网设备，估计核心交换机都要挂掉了。
让我们简述下上述问题：
R4 down掉其lo0的4.4.4.4以后，R3就全盘相信R2发来的4.4.4. 4/32路由，而R2从R5学到此路由，R5又从R1，R1其实也是从R3学来的，R3从R2学习到，以此类推，网络路由环路就诞生了。
相信很多朋友也有类似的经历，无论是计划维护，还是由于意外事故导致某个网段下线了，但是很神奇的是此网段仍然在全网的路由表里面可见，而伴随此奇怪现象的是很多网络设备的CPU利用率开始飙升。若对于某些老旧型号，并未做路由弓|擎防护策略的设备来说，冲垮它是分分钟的事情，包HSRP/VRRP离线，设备失去响应，OSPF邻居down掉等。
环路问题如何解？
对于以上路由环路问题，什么才是最根本的解法?
有人说，谁让你放两台路由器在那里的，还做了双向重分发。放一台不就没这问题了么?
道理上来说，放一台的确解决了此问题。
但是这就如饮鸩止渴，现在的问题解决了，但是更重要的网络高可用性，冗余性就没有了。
所以，两台甚至多台路由器做双向重分发仍然是需要的。
而解决方法，则是路由过滤。
再次复盘上述环路问题。
实问题的根源就在于一个路由协议域内的路由跑到了其他路由协议域内，然后通过另外一台路由器又跑回来了。
这就好比你买了一套有前后门的房子,然后叫家里小孩从家里前门出去超市给你买包烟，结果他刚从前门出去，马上又从后跑进屋玩"吃鸡"了。
唯一阻止的方法就是做标记。
标记如何做？
重点分析RIP -> OSPF方向，下述操作需要在R1和R2同时执行:
首先当R1以及R2重分发RIP路由到OSPF时，采用对应的策略工具把从RIP域里面重分发过来的路由打上一个特定的标记，此标记是一个数字，由你自己定义。(本例的Cisco工具为route-map)通过标记以后，当这些路由到达OSPF域内部时,我们可以很轻松的挑出这些从RIP来的路由。
接下来，当OSPF域里面的路由即将要被另外一台路由重分发回到RIP时，需要使用同样的策略工具，匹配上述定义的标记，从而把原来RIP来的路由网段给挑选出来，并禁止它们再次进入RIP域。(deny拒绝掉)
这样做，RIP域内部的路由器就不会收到重复的网段路由，例如R3就不会再收到从R2发过来的4.4.4.4/32路由，因为此路由在R1重分发OSPF- >RIP时，就被策略工具给过滤掉了。
在本例中，当R3不在收到R2发来的4 4.4.4/32后，任何问题都迎刃而解了。
配置演示：
R1和R2配置完全相同，你需要同时在R1和R2上都做如下配置操作，此次仅以R1配置为例：
#定义从rip重分布ospf时的策略route-map ,打上标记100。
#定义从ospf重分发到rip时的策略route-map,首先匹配任何标记为100的路由，并把它拒绝。
#同时允许其他所有路由。（这点很重要，因为你需要考虑到那些没有标记100的路由，该如何处置他们。）
#最后，把两个route-map策略分别应用到对应的路由协议上：
配置相当简单，但是为了说明这个故障，我们花了非常大的篇幅来讲解故障细节，所以
理解细节是多么的重要。
让我们看看效果:
#R3路由表：
#R6ping和Traceroute测试：
#最后，让我们通过一条命令看看那些被打上标记，挑出来的RIP路由：
#此命令在R5上执行，因为R5仅仅加入OSPF域，不会引起阅读上的误解。
#为了简化输出，我特地加入了一个include entry，只挑出带“entry”关键字的输出项。
#你会发现，上述路由网段，全都是RIP的路由
#这也变相证明我们的目的达到了
一切恢复正常， 并没有任何环路。
R6的两个源地址均能顺畅的与R4的4.4.4.4通讯了。
问题圆满解决。
题外话：为什么不标记OSPF重分发的路由？
有朋友发现，上述操作一直针对的是RIP进入OSPF的路由，并给他们打上标记。
为什么不对OSPF进入RIP的路由也打上标记呢?
同样的，你的测试一直针对R4的问题， 难道同样的问题不会发生在R6身上么?即R6的6.6.66是否也会在R5.上存在两个下一跳?
其实这样做不是偷懒，而是有原因的。
因为OSPF和RIP的管理距离问题。
此问题最根本的原因，因为RIP的管理距离120不及OSPF的110来的优先。从而导致R2一方面学习到R3发来的4.4.4. 4/32,同时也学习到了R5发来的路由。
但是因为R5发来的是OSPF E2类型外部路由，虽说是外部E2路由。但是瘦死的骆驼比马驮，外部路由仍然是OSPF路由，AD. 上仍然是110。从而导致R1只认R5传来的4.4.4.4/32,并把它放入路由表，然后进而影响了后续的OSPF->RIP的重分发。
回过头来看R6。
当R1或者R2把R6的6.6.6.6重分发到RIP, R3收到以后，通过RIP发给R1或者R2。R1、R2看都不会看一眼，因为R3的RIP路由相比OSPF来说，弱爆了。(管理距离问题，不是因为长相。)
所以此问题就不会产生，自然而然，我们也不需要做什么过滤。
总结：
此篇文章,通过一个典型的OSPF和RIP双向双重分发的案例，向你讲述了一个经典的路由环路产生的过程，复现率100%。
以及如何通过简单的路由策略过滤解决掉此问题。
用一句话总结此篇文章:当两个路由协议通过多个节点互相重分发时，务必小心管理距离较低的一方，此处一定会产生次优路由，从而在特定环境下导致环路。
解决方法为，当管理距离较低的协议路由经过重分发进入管理距离较高的协议时，务必打上标记。等到从其他节点回来时，过滤掉这些带标签的，禁I上他们再次进入管理距离较低的网络。
