分析演示：静态路由和CEF的方式导致HSRP接管故障后丢失通信-阿里云开发者社区

分析目标：

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

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

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

演示环境： 如图1所示的演示环境

背景说明：首先实施路由器R1、R2、R3的静态路由配置，具体配置如下所示，不需要在路由器R1和R2去配置，相互通过彼此到30.30.30.0的路由，让它们都通过R3到达30.30.30.0。然后去实施HSRP冗余组，要求R1为活动路由器，然后测试和分析如果R1的E1/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

演示步骤：

第一步：为路由器R1和R2配置HSRP冗余组具体配置如下所示：

路由器R1的HSRP配置：

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

路由器R2的HSRP配置：

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组中的活动路由器。

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

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

制造R1的E1/0故障：

R1(config)#intee1/0

R1(config-if)#shutdown

R1(config-if)#exit

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

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

首先需要确定：当R1的E1/0接口故障后，R2是否能顺利接管，可以通过在路由器R2上执行show standby brief指令查看HSRP的角色信息，然后再到主机上跟踪一次到30.30.30.1的所有路径，会发现，R2是成功的接管了R1的活动路由器角色，如图6所示，为什么这样讲呢？从跟踪的结果可以看出，主机到30.30.30.1的流量是通过R2(172.16.1.2)在转发，所以HSRP冗余组中的R2在R1故障后，成功的接管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的静态路由的，所以综合上述两个理由，排障人员有理由怀疑是R3（30.30.30.1）返回给172.16.1.0网络主机的流量出现问题。

为了进一步确定怀疑的问题，需要在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.1、192.168.2.2、192.168.4.1，可以看到只有通过下一跳192.168.2.2的数据包能成功的到达172.16.1.100，当数据通过下一跳192.168.1.1和192.168.4.1时出现了问题，现在可以确定怀疑的问题了，那么接下来要做的分析工作就是分析这个问题是如何产生的。

确定故障问题，发析问题的产生原由：现在确定的问题是当数据通过下一跳192.168.1.1和192.168.4.1时出现了问题，产生这个故障的原因是：路由器R1的E1/0接口故障，并不会影响R1的E1/1和S2/0，更不至于影响R3的E1/0和S2/0链路，所以R3的E1/0和S2/0接口状态为up ,那么R3路由表如图8所示，具备三条路径到172.16.1.0。默认情况下路由器R3会使用使用这三条链路来完成对172.16.1.0数据转发的负载均衡，如图9所示，只要有数据通过下一跳192.168.4.1和192.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.100、172.16.1.101、172.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通过不同目标进行负载均衡的原则所造成的，事实上，你的“整个网络”在遵守“通一断二”的现象，只有三分之一的主机可达。这种论断正确吗？如果希望在同一个目标主机上看到“通一断二”的现象，该怎么办？