核心内容摘要
困境中的双向奔赴：解读“女生困团里男生困困”现象
多个路由协议?再正常不过了作为一名网络行业从业者我多么希望面对的网络架构是完美的。
就好比玩游戏可以开挂要是生活、工作也能开挂多好。
但日常工作中你会发现企业网络也好,其他类型的网络也好。
总是存在各种瑕疵各种不和谐。
其中一个不和谐就是一张网同时由存在多个路由协议互联互通。
再奇葩一点多个路由协议之间通过多台路由器重分发路由来提供两两之间的可达性。
此话怎么讲?让我们来看一个拓扑:上图中存在两个路由域OSPF域以及RIP域 两个域通过两台路由器互联在-起。
同时为了交换两个域内的路由让OSPF内的设备能够与RIP设备互联互通我们需要在两台路由器上作双点双向重分发。
什么时候存在多个路由域?总之不管什么原因当两个不同的路由协议同时存在于网络中并有两台路由器做双向重分发时。
若不采取人为干涉网络故障就发生了。
网络故障什么网络故障可否说清楚点?这里故意卖个关子先看一个案例你就明白了。
一个诡异的路由问题上面以OSPF和RIP组成的拓扑为例讨论此问题。
既然这样就顺水推舟采用此拓扑搭建一个实验环境。
让我们一起来看看当OSPF和RIP两个点互相重分发以后到底会发什么事情?拓扑如下:拓扑简介上述拓扑中存在两个路由协议分别是OSPF (下方) RIP (上方)。
OSPF内部有R5R6四台路由器。
RIP内部有R3R4四台路由器。
R1和R2则是同时处于RIP和OSPF域中。
路由器之间的IP地址为路由器的数字名称组合而成。
例如R1和R3之间的链路则是:
13.
1.
0/24。
R1是
13.
1.
1/24R3则是
13.
1.
3/24, 以此类推非常容易理解。
为了验证连通性, R4和R6_ 上开启了两个还回接口lo0。
R4的Io0 IP为
4.
4.
4/32。
R6的lo0 IP为
6
6/32。
重分发说明:此实验中R1和R2同时双向重分发OSPF和RIP。
即向OSPF里重分发了RIP的路由,向RIP内重分发了OSPF的路由。
实验目的很简单只需要让R4和R6的I0IP地址互 联互通即可。
实验配置各路由器配置如下:#####R4:interface Loopback0ip address
4.
4.
4
255.
255.
2
255interfaceEthernet0/0ip address
34.
1.
4
255.
255.
2
0router ripversion 2network
4.
0.
0network
34.
0.
0noauto-summary#####R3:interfaceEthernet0/0ip address
13.
1.
3
255.
255.
2
0interface Ethernet0/1ip address
23.
1.
3
255.
255.
2
0interfaceEthernet0/2ip address
34.
1.
3
255.
255.
2
0router ripversion 2network
13.
0.
0network
23.
0.
0network
34.
0.
0no auto-summary####R1:interface Ethernet0/0ip address
13.
1.
1
255.
255.
2
0interface Ethernet0/1ip address
15.
1.
1
255.
255.
2
0router ospf 1#重点来了OSPF重分发RIPredistribute rip subnetsnetwork
15.
1.
0
0.
0.
255 area 0router ripversion 2#RIP重分发OSPFredistribute ospf 1 metric 1network
13.
0.
0no auto-summary#####R2interface Ethernet0/0ip address
23.
1.
2
255.
255.
2
0interface Ethernet0/1ip address
25.
1.
2
255.
255.
2
0router ospf 1redistribute rip subnets#OSPF重分发RIPnetwork
25.
1.
0
0.
0.
255 area 0router ripversion 2redistribute ospf 1 metric 1#RIP重分发OSPFnetwork
23.
0.
0no auto-summary####R5interfaceEthernet0/0ipaddress
25.
1.
5
255.
255.
2
0interfaceEthernet0/1ipaddress
15.
1.
5
255.
255.
2
0interfaceEthernet0/2ipaddress
56.
1.
5
255.
255.
2
0router ospf 1network
0.
0.
0.
0255.
255.
2
255 area 0####R6interfaceLoopback0ip address
6.
6.
6
255.
255.
2
255interface Ethernet0/0ip address
56.
1.
6
255.
255.
2
0router ospf 1network
0.
0.
0
255.
255.
2
255 area 0上述配置浅显易懂也没有什么复杂的网络技术,简单说来就是在R1和R2上开启了两个路由协议并做了互相重分发。
但是往往越简单的东西破坏力越大。
一段时间以后各个路由协议收敛完成。
接下来看看各个路由器的路由表:R4:R3:R1:R2:R5:R6:上面的路由表不知道你是否看出来端倪。
(悄悄提示:注意
4.
4.
4/32的路由。
)没看出来也无所谓请继续往下走。
实验结果验证接下来进行验证环节。
很简单验证方法为R6是否能够ping得通R4的还回地址
4.
4.
4。
###R6测试以R6的接口
56.
1.
6/32为源来ping
4.
4.
4非常完美以R6的环回
6.
6。
6为源来ping
4.
4.
4居然不通神奇的事情发生了R6以
56.
1.
6为源ping
4.
4.
4没有问题但是以
6.
6.
6为源ping
4.
4.
4则失败。
为了验证数据包的路径这一次试试traceroute,如下所示采用R6的接口
56.
1.
6为源上述结果没有问题数据包经过4跳后到达R4。
让我们继续采用R6的环回
6.
6.
6为源做traceroute##哎呀环路了。
##怪不得ping不通呢从上面的traceroute发现一个很奇怪的问题当以R6的接口IP地址
6.
6.
6为源时 就出现环路。
“全网路由都正常
4.
4.
4和
6 66都在路由表里面逻辑上没问题。
”“莫非此网络还出神灵了不成估计是Cisco bug让我们重启路由器试试不行的话再报case报修。
这是很多朋友遇到此问题第一时间的反应。
但是小编喜欢刨根问底分析细节。
环路问题分析首先从环路的信息开始分析。
上述traceroute环路发生在R1R2, R3, R5之间R3做了 一件很诡异的事情。
首先R3收到到达
4.
4 4的数据包由于R3是唯一一台去往R4的路由器 逻辑上来讲,不犹豫R3会把此数据包直接转发给R4。
但是R3不仅没有反而发送给了R2。
那是什么神奇的力量让R3做如此选择呢?让我们再看看R3的路由表:有意思R3去往R4的
4.
4.
4居然有两个下一跳。
第一个是去往真正的目的地即R4。
第二个则是去往R2。
凭什么让R2认为它自己可以到达R4的
4.
4.
4?这次查看R2的路由表:R2从R5学习到的
4.
4.
4。
这件事情越来越有意思了。
以此类推往下追查: .R5的路由R1的路由最后发现R5的路由来源于R1,而R1的
4.
44/32则是来源于R3的RIP。
所以R1这里算是回到正轨了。
那为什么R5会有R1传来的
4.
4.
4/32路由还是OSPF。
答案是:重分发。
看到这里相信你对于此问题的理解心中已有八九分。
因为上述原因R3又收到了一份R2发过来的
4.
4.
4/32路由。
凑巧的是R3从R4那里学到的
4.
4.
4/32度量值metric为1而R1在做OSPFRIP重分发时也指定了metric度量值为1。
为此R3上的
4.
4.
4/32同时存在两个下—跳:现在我们总算了解清楚为什么R3上有两个下一跳的原因。
接着往下走。
详解R6诡异的ping上述分析只是解释了R3的下一跳问题但是开篇提到的最根本问题仍然没有回答。
为什么R6以
56.
1.
6为源可以ping
4.
4.
4但是以
6.
6.
6接口地址为源反而不行?在分析此问题之前先说说一个背景知识网络设备如何做负载均衡。
网络设备负载均衡浅谈简单聊完负载均衡以后回到话题。
对R3来说去往
4.
4.
4有两个下一跳一个是正确的下一跳R4另外一个则是错误的下—跳R2。
从负载均衡的特性来看R6通过不同IP地址ping R4的还回地址
4.
4.
4并得到了不同的结果。
其原因可能就是遭糟遇了负载均衡算法的影响。
那如何证明此猜想是正确的。
还真有办法方法就是去查阅转发表。
如下所示#上述内容为转发表FIB针对
4.
4.
4/32的表项# 接下来就是见证奇迹的时刻。
#我们可以通过一个命令来确认R3针对某个IP源、目标地址组合会采用那一个下一跳。
如下所示#上述命令询问R3,要是一个源地址为
56.
1.
6目标地址为
4.
4.
4的数据包你选那一个接口#R3回答送它去R4(
34.
1.
1.
#同理当源地址为
6.
6.
6目标为
4.
4.
4的数据包来时。
#R3说送它去R2(
23.
1.
1.
看了上面的输出瞬间豁然开朗。
原来这就是R6出现如此奇葩i问题的根本原因。
再次证明当出现某些奇葩问题时先从每一个环节出发掌握细节部分逐个击破。
问题并不—定都是硬件设备故障或者软件BUG。
但是故事还没有完请继续。
把偶尔变成必然综上所述你可能质疑上述实验是一个“巧合”现实生活中并不一定存在。
让我逐个澄清关于重分发度量值为1的情况其实日常工作环境中出现的比例相当高。
例如在上述RIP网络中R4后面可能还有更多的网络节点而这些节点都通过RIP发布网段到网络中最终导致R3上肯定有某一条路由和R2“环路的方式发布过来的度量值相同。
此时问题就发生了而针对第二项的确是一个概率性问题而其导致的问题就是你不知道什么时候某一个网段不工作了。
例如上述案例中是
6.
6.
6为源到
4.
4.
4不通但是可能某一天又变为
56.
1.
6为源到
4.
4.
4不通了。
原因是转发表会把之前随机选择的端口记录超时掉然后重新选择。
(就好比打麻将玩完一局以后洗牌再重来。
)但是我个人认为上述所谓的巧合案例是极其值得分享至少你遇到此种问题时知道如何下手分析。
必然发生的网络环路最后再给你演示—个必然发生的网络环路。
再次奉上R3的
4.
4.
4路由条目:你是否考虑过如果R4哪一天突然不发送4 .4
4/32的RIP更新给R3了?例如接口down掉了。
会有什么事情发生?实际操作一把看看:再次查看R3的路由表恐怖的事情发生了
4.
4.
4/32仍然健在。
此时网络中任何流量去往
4.
4.
4都是像进入网络黑洞环路诞生了。
以R6为例之前源为
56.
1 .6的IP地址可以与
4.
4.
4通讯,现在再看看:R6无法ping通R4的
4.
4.
4了traceroute也证实了环路诞生。
不光是R6,随便挑一个路由器咱们就挑R3吧如下所示R3也环路了幸好这是实验室若在现网设备估计核心交换机都要挂掉了。
让我们简述下上述问题R4 down掉其lo0的
4.
4.
4以后R3就全盘相信R2发来的
4.
4.
4/32路由而R2从R5学到此路由R5又从R1R1其实也是从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/32路由因为此路由在R1重分发OSPF- RIP时就被策略工具给过滤掉了。
在本例中当R3不在收到R2发来的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通讯了。
问题圆满解决。
题外话为什么不标记OSPF重分发的路由有朋友发现上述操作一直针对的是RIP进入OSPF的路由并给他们打上标记。
为什么不对OSPF进入RIP的路由也打上标记呢?同样的你的测试一直针对R4的问题 难道同样的问题不会发生在R6身上么?即R6的
6.
66是否也会在R
上存在两个下一跳?其实这样做不是偷懒而是有原因的。
因为OSPF和RIP的管理距离问题。
此问题最根本的原因因为RIP的管理距离120不及OSPF的110来的优先。
从而导致R2一方面学习到R3发来的
4.
4.
4/32,同时也学习到了R5发来的路由。
但是因为R5发来的是OSPF E2类型外部路由虽说是外部E2路由。
但是瘦死的骆驼比马驮外部路由仍然是OSPF路由AD. 上仍然是110。
从而导致R1只认R5传来的
4.
4.
4/32,并把它放入路由表然后进而影响了后续的OSPF-RIP的重分发。
回过头来看R6。
当R1或者R2把R6的
6.
6.
6重分发到RIP, R3收到以后通过RIP发给R1或者R2。
R
R2看都不会看一眼因为R3的RIP路由相比OSPF来说弱爆了。
(管理距离问题不是因为长相。
)所以此问题就不会产生自然而然我们也不需要做什么过滤。
总结此篇文章,通过一个典型的OSPF和RIP双向双重分发的案例向你讲述了一个经典的路由环路产生的过程复现率100%。
以及如何通过简单的路由策略过滤解决掉此问题。
用一句话
总结此篇文章:当两个路由协议通过多个节点互相重分发时务必小心管理距离较低的一方此处一定会产生次优路由从而在特定环境下导致环路。
解决方法为当管理距离较低的协议路由经过重分发进入管理距离较高的协议时务必打上标记。
等到从其他节点回来时过滤掉这些带标签的禁I上他们再次进入管理距离较低的网络。
不想错过文章内容读完请点一下“在看”加个“关注”您的支持是我创作的动力 期待您的一键三连支持点赞、在看、分享~