分析演示:静态路由和CEF的方式导致HSRP接管故障后丢失通信

简介:

分析目标

静态路由的问题导致HSRP接管故障后丢失通信

分析静态路由造成的流量接管问题

3 CEF的模式导致有些主机丢包,有些主机正常的原因

演示环境: 1所示的演示环境

wKiom1PW-JfTXyUiAAEz3cU58sU445.jpg

背景说明:首先实施路由器R1R2R3的静态路由配置,具体配置如下所示,不需要在路由器R1R2去配置,相互通过彼此到30.30.30.0的路由,让它们都通过R3到达30.30.30.0。然后去实施HSRP冗余组,要求R1为活动路由器,然后测试和分析如果R1E1/0接口故障后,R2是否能成功接管HSRP冗余组中活动路由器的角色,流量是否能从R1切换到R2,再到达30.30.30.0,如果出现问题请分析原因。

 

路由器R1上到30.30.30.0的静态路由配置:

R1(config)#ip route 30.30.30.0255.255.255.0 192.168.1.3

R1(config)#ip route 30.30.30.0255.255.255.0 192.168.4.3

 

路由器R2上到30.30.30.0的静态路由配置:

R2(config)#ip route 30.30.30.0255.255.255.0 192.168.2.3

 

路由器R3上到172.16.1.0的静态路由配置:

R3(config)#ip route 172.16.1.0255.255.255.0 192.168.1.1

R3(config)#ip route 172.16.1.0255.255.255.0 192.168.4.1

R3(config)#iproute 172.16.1.0 255.255.255.0 192.168.2.2

 

 

演示步骤:

第一步:为路由器R1R2配置HSRP冗余组具体配置如下所示:

 

路由器R1HSRP配置:

R1(config)#intee1/0

R1(config-if)#standby 1 ip 172.16.1.254 

R1(config-if)#standby 1 priority 110  *配置优先级使R1成为活动路由器

R1(config-if)#standby 1 preempt * 配置抢占功能

R1(config-if)#exit

 

路由器R2HSRP配置:

R2(config)#intee1/0

R2(config-if)#standby 1 ip 172.16.1.254

R2(config-if)#standby 1 preempt

R2(config-if)#exit

 

注意:R2为什么不需要配置优先级?因为背景要求R1成为活动路由器,并将优先级配置为110,而R2使用默认的优先级100,所以R2不需配置优先级,这样就可以保证R1成为HSRP组中的活动路由器。

 

完成上述配置后,可以分别在R1R2上使用show standby brief指令查看HSRP的角色信息,如23所示,如预期所评估的那样,R1成为HSRP组中的活动路由器,R2为备份路由器。然后此时,在172.16.1.0网络的主机上执行一次到30.30.30.1的路由跟踪,发现当前的路径是通过R1(活动路由器)进行转发的。如4所示。至此为止,为后面的故障分析完成了所需要的基础配置。

wKiom1PW-Ouw4EpzAAJWz3NzCb0254.jpg


第二步:此时,如果R1E1/0接口(启动HSRP功能的接口),发生网络故障或者是被关闭,HSRP组会正常收敛吗?路由器R2会接管R1活动路由器的角色吗?如果发生有些主机能正常收敛,有些主机确不能,这是为什么?

   

制造R1E1/0故障:

R1(config)#intee1/0

R1(config-if)#shutdown

R1(config-if)#exit

   

    当制造R1E1/0接口故障时(手工关闭该接口),事实上网络上有一部分主机,对的错只是一部分主机,出现如5所示的现象,流量中断,丢包;而另一部分主机却可以连接通信,这是什么原因所致呢?下面开始进行详细的分析。


wKioL1PW-kOTqcU2AAG23pdKQnI574.jpg

按照一般思路:路由器R1E1/0(启动HSRP)的接口故障,R2应该快速收敛,接替活动路由器的角色,而且R1E1/0接口那是启动HSRP的接口,属于HSRP的冗余的组内接口,按常理这种收敛应该是最快的,可现在为什么会出现这样的情况?

首先需要确定:R1E1/0接口故障后,R2是否能顺利接管,可以通过在路由器R2上执行show standby brief指令查看HSRP的角色信息,然后再到主机上跟踪一次到30.30.30.1的所有路径,会发现,R2是成功的接管了R1的活动路由器角色,如6所示,为什么这样讲呢?从跟踪的结果可以看出,主机到30.30.30.1的流量是通过R2(172.16.1.2)在转发,所以HSRP冗余组中的R2R1故障后,成功的接管R1活动路由器这个角色是没有问题的,只是流量到达R2(172.16.1.2)后才产生的丢包,所以至此为止,不用再去思考HSRP的状态切换,因为它很正常。

然后需要思考的是:为什么流量到达R2(172.16.1.2)后丢包,难到是R2没有到30.30.30.1的可达性路由?经过认真思索后,可以肯定的讲,不是这个原因,理由可以通过两方面的取证来分析:一、从根据的结果上来分析,是Request time out(请求超时),根据笔者以前所著的《思科CCNA认证详解与实验指南(200-120)》对ICMP的分解,所谓Request time out(请求超时)一般发生在数据包可以从信源(源主机)成功的发送到信宿(目标主机),只是目标主机不能返回数据包给源主机,而源主机一直等待,以至于超时。二、在本实验前面的背景说明中就可以看出,在R2上是成功的配置了到30.30.30.0的静态路由的,所以综合上述两个理由,排障人员有理由怀疑是R330.30.30.1)返回给172.16.1.0网络主机的流量出现问题。


wKioL1PW-nHynV_FAAGM1nfXLVE339.jpg

为了进一步确定怀疑的问题,需要在R3上对返回172.16.1.0的数据流量的路径进行取证:

     7所示,在路由器R3上执行可扩展的路由跟踪指令,跟踪的目标是172.168.1.100;以源IP地址30.30.30.1发起路由跟踪。不难发现,跟踪的事实是:当前R3以源30.30.30.1发送数据包到172.16.1.1.100,它正在通过三条路径做发送,这三和路径的下一跳分别是192.168.1.1192.168.2.2192.168.4.1,可以看到只有通过下一跳192.168.2.2的数据包能成功的到达172.16.1.100当数据通过下一跳192.168.1.1192.168.4.1时出现了问题,现在可以确定怀疑的问题了,那么接下来要做的分析工作就是分析这个问题是如何产生的。

wKioL1PW-qWgeLi3AAI2aMvgozI455.jpg


确定故障问题,发析问题的产生原由:现在确定的问题是当数据通过下一跳192.168.1.1192.168.4.1时出现了问题,产生这个故障的原因是:路由器R1E1/0接口故障,并不会影响R1E1/1S2/0,更不至于影响R3E1/0S2/0链路,所以R3E1/0S2/0接口状态为up ,那么R3路由表如8所示,具备三条路径到172.16.1.0。默认情况下路由器R3会使用使用这三条链路来完成对172.16.1.0数据转发的负载均衡,如9所示,只要有数据通过下一跳192.168.4.1192.168.1.1转发,那就必不可达,虽然数据包能到达R1上,但是R1的内侧接口E1/0是故障的,故不能转发到172.16.1.100,这会造成路由黑洞,唯一可达的就是通过下一跳192.168.2.2转发。可以更直白的讲:“如果同时从R3上发3个包到172.16.1.100,那么只有一个包能到达,另外两个包必丢弃,也就是“通一断二”的现象。

 

此时用户可能产生一个疑问(一些主机丢包,一些主机不丢包):

     在自己做测试时,并不是“通一断二”的现象。而是有些主机全丢包,有些主机不丢包,这是为什么?这是因为R3默认是启动了ip cef功能,如果有三条路径到同一目标172.16.1.0,那么路由器默认将基于不同的目标来进行负载均衡,以三台不同的目标主机172.16.1.100172.16.1.101172.16.1.102为例,其行为是:假设到172.16.1.100为第一个目标主机,那么所有到这一个目标的数据都会通过同一个路径转发,如果此时通过下一跳为192.168.1.1转发,结果是必丢包,而且全丢弃;同理172.16.1.101为第二个目标主机,那么所有到这第二个目标的数据都会通过同一个路径转发,如果此时通过下一跳为192.168.4.1转发,结果是必丢包,而且全丢弃;如果172.16.1.102为第三个目标主机,那么所有到这第三个目标的数据都会通过同一个路径转发,如果此时通过下一跳为192.168.2.2转发,结果是不丢包,全部可达。再次强调:造成这种现像的是CEF通过不同目标进行负载均衡的原则所造成的,事实上,你的“整个网络”在遵守“通一断二”的现象,只有三分之一的主机可达。这种论断正确吗?如果希望在同一个目标主机上看到“通一断二”的现象,该怎么办?

wKioL1PW-v2R_qFaAAMKy5aeti8437.jpg

wKiom1PW-ebBKUdBAAGwRbTCWtk932.jpg

如何在单一主机上看到“通一断二”的现象

只要在路由器R3(config)#no ip cef暂时关闭ip cef,那么R3就不在执行基于不同目标的负载均衡,而是将数据包平均的通过三条路径转发,此时在单一主机上做连继的ping,就可以看到如10所示的“通一断二”的现象。

wKioL1PW-0LTFlQtAAF8X7e8S7c978.jpg

在这个环境中的其它注意事项:

如果现在到路由器R1E1/0接口恢复,然后其它配置保持本实验前面的配置不变,现在请问:如果R1E1/1S2/0接口故障,HSRP冗余组中的R2能成为活动路由器,然后接管R1的转发工作吗?

不能,因为整个网络使用的静态路由,而路由器R1R2之间没有相关的静态路由,并且在R1上没有配置接口跟踪功能,所以R1E1/1S2/0故障后,R2无法成为活动路由器,接管R1的故障。



本文转自 kingsir827 51CTO博客,原文链接:http://blog.51cto.com/7658423/1531880,如需转载请自行联系原作者

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
网络协议 网络虚拟化 网络架构
【华为数通HCIP | 网络工程师】821-BGP高频题、易错题(1)
【华为数通HCIP | 网络工程师】821-BGP高频题、易错题(1)
2574 0
|
传感器 消息中间件 运维
Mqtt开发笔记:Mqtt服务器搭建
Mqtt开发笔记:Mqtt服务器搭建
Mqtt开发笔记:Mqtt服务器搭建
|
网络协议 算法 数据库
|
人工智能 大数据 区块链
|
计算机视觉 异构计算
目标检测实战(四):YOLOV4-Tiny 源码训练、测试、验证详细步骤
这篇文章详细介绍了使用YOLOv4-Tiny进行目标检测的实战步骤,包括下载源码和权重文件、配置编译环境、进行简单测试、训练VOC数据集、生成训练文件、准备训练、开始训练以及多GPU训练的步骤。文章还提供了相应的代码示例,帮助读者理解和实践YOLOv4-Tiny模型的训练和测试过程。
1405 0
|
NoSQL 安全 Shell
MongoDB 用户管理
10月更文挑战第12天
413 0
|
Java 数据库连接 数据库
告别繁琐 SQL!Hibernate 入门指南带你轻松玩转 ORM,解锁高效数据库操作新姿势
【8月更文挑战第31天】Hibernate 是一款流行的 Java 持久层框架,简化了对象关系映射(ORM)过程,使开发者能以面向对象的方式进行数据持久化操作而无需直接编写 SQL 语句。本文提供 Hibernate 入门指南,介绍核心概念及示例代码,涵盖依赖引入、配置文件设置、实体类定义、工具类构建及基本 CRUD 操作。通过学习,你将掌握使用 Hibernate 简化数据持久化的技巧,为实际项目应用打下基础。
1011 0
|
传感器 数据采集 人工智能
【STM32+k210项目】基于AI技术智能语音台灯的设计(完整工程资料源码)
【STM32+k210项目】基于AI技术智能语音台灯的设计(完整工程资料源码)
1443 2
|
人工智能 运维 Prometheus
运维之巅:构建高效自动化运维体系的实战指南
在信息技术飞速发展的今天,企业对IT系统的依赖程度不断加深。如何确保这些复杂系统的稳定性与可靠性,是每一个运维人员面临的挑战。本文将深入探讨构建一个高效自动化运维体系的关键要素,包括工具选择、流程优化、监控告警以及故障响应机制等。通过具体实例和数据分析,揭示自动化运维对企业效率和稳定性的积极影响,并提出一系列可行的实施建议。
328 0
|
边缘计算 运维 安全
云上物联网边缘节点:重塑连接智能世界的桥梁
结语 云上物联网边缘节点作为物联网技术的重要组成部分,正以其独特的优势和潜力推动着物联网的快速发展。面对未来的机遇和挑战,我们需要不断创新和完善边缘节点的技术架构和应用模式,推动物联网技术的深度融合和广泛应用,为构建智慧社会贡献力量。
441 0

热门文章

最新文章