加群交流在后台回复“加群”，添加小编微信，小编拉你进去
后台回复“724”获取入门资料
多个路由协议?再正常不过了
作为一名网络行业从业者，我多么希望面对的网络架构是完美的。
就好比玩游戏可以开挂，要是生活、工作也能开挂多好。
但日常工作中，你会发现企业网络也好,其他类型的网络也好。
总是存在各种瑕疵，各种不和谐。
其中一个不和谐，就是一张网同时由存在多个路由协议互联互通。
再奇葩一点，多个路由协议之间通过多台路由器重分发路由，来提供两两之间的可达性。
此话怎么讲?
让我们来看一个拓扑:
上图中，存在两个路由域，OSPF域以及RIP域， 两个域通过两台路由器互联在一起。
同时，为了交换两个域内的路由，让OSPF内的设备能够与RIP设备互联互通，我们需要在两台路由器上作双点双向重分发。
什么时候存在多个路由域?
总之，不管什么原因，当两个不同的路由协议同时存在于网络中，并有两台路由器做双向重分发时。
若不采取人为干涉，网络故障就发生了。
网络故障，什么网络故障，可否说清楚点?
这里故意卖个关子，先看一个案例，你就明白了。
一个诡异的路由问题：
上面以OSPF和RIP组成的拓扑为例讨论此问题。
既然这样，就顺水推舟，采用此拓扑搭建一个实验环境。
让我们一起来看看，当OSPF和RIP两个点互相重分发以后，到底会发什么事情?
拓扑如下:
拓扑简介
上述拓扑中，存在两个路由协议，分别是OSPF (下方) ，RIP (上方)。
OSPF内部有R5，R6四台路由器。
RIP内部有R3，R4四台路由器。
R1和R2则是同时处于RIP和OSPF域中。
路由器之间的IP地址为路由器的数字名称组合而成。例如R1和R3之间的链路则是: 13.1.1.0/24。
R1是13.1.1.1/24，R3则是13.1.1.3/24, 以此类推，非常容易理解。
为了验证连通性, R4和R6_ 上开启了两个还回接口lo0。
R4的Io0 IP为4.4.4.4/32。R6的lo0 IP为6.6 6.6/32。
重分发说明:
此实验中，R1和R2同时双向重分发OSPF和RIP。即向OSPF里重分发了RIP的路由,向RIP内重分发了OSPF的路由。
实验目的：
很简单，只需要让R4和R6的I0IP地址互 联互通即可。
实验配置：各路由器配置如下:
#####R4:
interface Loopback0
ip address 4.4.4.4 255.255.255.255
interface Ethernet0/0
ip address 34.1.1.4 255.255.255.0
router rip
version 2
network 4.0.0.0
network 34.0.0.0
no auto-summary
#####R3:
interface Ethernet0/0
ip address 13.1.1.3 255.255.255.0
interface Ethernet0/1
ip address 23.1.1.3 255.255.255.0
interface Ethernet0/2
ip address 34.1.1.3 255.255.255.0
router rip
version 2
network 13.0.0.0
network 23.0.0.0
network 34.0.0.0
no auto-summary
####R1:
interface Ethernet0/0
ip address 13.1.1.1 255.255.255.0
interface Ethernet0/1
ip address 15.1.1.1 255.255.255.0
router ospf 1
#重点来了，OSPF重分发RIP
redistribute rip subnets
network 15.1.1.0 0.0.0.255 area 0
router rip
version 2
#RIP重分发OSPF
redistribute ospf 1 metric 1
network 13.0.0.0
no auto-summary
#####R2
interface Ethernet0/0
ip address 23.1.1.2 255.255.255.0
interface Ethernet0/1
ip address 25.1.1.2 255.255.255.0
router ospf 1
redistribute rip subnets
#OSPF重分发RIP
network 25.1.1.0 0.0.0.255 area 0
router rip
version 2
redistribute ospf 1 metric 1
#RIP重分发OSPF
network 23.0.0.0
no auto-summary
####R5
interface Ethernet0/0
ip address 25.1.1.5 255.255.255.0
interface Ethernet0/1
ip address 15.1.1.5 255.255.255.0
interface Ethernet0/2
ip address 56.1.1.5 255.255.255.0
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
####R6
interface Loopback0
ip address 6.6.6.6 255.255.255.255
interface Ethernet0/0
ip address 56.1.1.6 255.255.255.0
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
上述配置浅显易懂，也没有什么复杂的网络技术,简单说来就是在R1和R2上开启了两个路由协议，并做了互相重分发。
但是，往往越简单的东西，破坏力越大。
一段时间以后，各个路由协议收敛完成。
接下来看看各个路由器的路由表:
R4:
R3:
R1:
R2:
R5:
R6:
上面的路由表，不知道你是否看出来端倪。(悄悄提示:注意4. 4.4.4/32的路由。)没看出来也无所谓，请继续往下走。
实验结果验证：
接下来进行验证环节。
很简单，验证方法为R6是否能够ping得通R4的还回地址4.4.4.4。
###R6测试：
以R6的接口56.1.1.6/32为源来ping 4.4.4.4
非常完美
以R6的环回6.6.6。6为源来ping 4.4.4.4
居然不通？？？？
神奇的事情发生了，R6以56.1.1.6为源ping 4.4.4.4没有问题，但是以6.6.6.6为源ping 4.4.4.4则失败。
为了验证数据包的路径，这一次试试traceroute,如下所示：
采用R6的接口56.1.1.6为源
上述结果没有问题，数据包经过4跳后到达R4。
让我们继续采用R6的环回6.6.6.6为源做traceroute
##哎呀，环路了。
##怪不得，ping不通呢
从上面的traceroute发现一个很奇怪的问题，当以R6的接口IP地址6.6.6.6为源时， 就出现环路。
“全网路由都正常，4.4.4. 4和6.6 66都在路由表里面，逻辑上没问题。”
“莫非此网络还出神灵了不成，估计是Cisco bug，让我们重启路由器试试，不行的话再报case报修"。
这是很多朋友遇到此问题第一时间的反应。
但是，小编喜欢
刨根问底，分析细节。
环路问题分析
首先，从环路的信息开始分析。
上述traceroute环路发生在R1，R2, R3, R5之间，
R3做了 一件很诡异的事情。
首先R3收到到达4.4.4 4的数据包，由于R3是唯一一台去往R4的路由器， 逻辑上来讲,
不犹豫R3会把此数据包直接转发给R4。
但是R3不仅没有，反而发送给了R2。
那是什么神奇的力量让R3做如此选择呢?让我们再看看R3的路由表:
有意思，R3去往R4的4.4.4.4居然有两个下一跳。
第一个是去往真正的目的地，即R4。
第二个则是去往R2。
凭什么让R2认为它自己可以到达R4的4.4.4.4?
这次查看R2的路由表:
R2从R5学习到的4.4.4.4。
这件事情越来越有意思了。
以此类推，往下追查: .
R5的路由：
R1的路由：
最后发现，R5的路由来源于R1,而R1的4.4. 44/32则是来源于R3的RIP。
所以R1这里算是回到正轨了。
那为什么R5会有R1传来的4.4.4. 4/32路由，还是OSPF。
答案是:重分发。
看到这里，相信你对于此问题的理解心中已有八九分。
因为上述原因，R3又收到了一份R2发过来的4.4.4.4/32路由。凑巧的是，R3从R4那里学到的4.4.4.4/32度量值metric为1，而R1在做OSPF>RIP重分发时，也指定了metric度量值为1。为此，R3上的4.4.4.4/32同时存在两个下—跳:
现在，我们总算了解清楚为什么R3上有两个下一跳的原因。
接着往下走。
详解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吧，如下所示：
