背景介绍
客户企业是一家200人左右规模的零售行业公司，公司网络做的是经典全千兆三层网络架构，部署出口iKuai软路由+内网某为交换机。大致拓扑如下图所示：
典型拓扑
网段规划如下：
- 无线网段：VLAN10-172.16.10.0/24
- 监控网段：VLAN20-172.16.20.0/24
- 办公网段：VLAN30-172.16.30.0/24
- 管理网段：VLAN100-192.168.90.0/24（含所有交换机、路由、服务器）
目前问题是：公司IT经常发现iKuai出口路由的CPU经常飙高到90%以上，访问页面特别卡，同时下面的终端上网都出现了卡顿、延时等问题，整网崩掉了。
已有分析
- 重启大法无效，重启了路由器、核心交换机，故障依旧；
- 路由器LAN口流量统计发现千兆链路的带宽被吃满了，但是WAN口却诡异的没有任何大流量？
- 把核心交换机拔掉，找台PC直连爱快路由，速度快到起飞！
上述测试说明路由器、交换机等设备应无大问题，遇到这种高吞吐统计的问题，推测网络中存在了环路导致广播风暴吃满带宽、破坏地址表？
排障分析
第一步：确认问题现象
我们使用VLAN30办公区PC ping测试百度IP：
可以看到丢包相当严重。
第二步：确认网络中的环路问题
我们常见的环路主要是二层环路，主要有两种表现：
- 广播风暴：导致端口带宽满载，地址表被破坏；
- 组播/广播泛洪：如DHCP、ARP等报文量过大流进CPU，也会导致CPU性能下降。
如上拓扑，因为路由器仅WAN和LAN口在用，从前面的流量统计分析中“WAN口无大流量而LAN口流量异常过大”。我们只需要在核心交换机上联接口查看数据统计即可，确认到底这个大流量是不是广播&组播！
命令如下：
从上图可以看到问题复现时，核心交换上联GE0/0/1接口的组播&广播报文在5秒内增长是非常缓慢的，基本排除了可能存在的二层环路以及报文泛洪的问题。
但是注意：细看核心交换上联接口统计，5秒内收/发单播包35000个/秒，相当于每秒同时双向收发7000个，这个量是非常惊人的！全网瘫痪的情况下单播包怎会有如此大的吞吐？
下一步需要抓取数据流分析。
第三步：内网主干路数据流分析
我们在核心交换机上做镜像抓取上联出口路由接口的流：
抓包如下：
从这条流分析如下：
该流为源VLAN20监控网访问目的172.16.40.0/24的UDP流，据统计这些流吞吐量高达1Gbps，它是占满千兆链路带宽的主要原因，也是路由器收发包满载导致CPU持续高位的主要原因。那么这些“异常流”为何会出现在核心交换与路由之间并且泛洪的呢？我们来看下数据包MAC地址对比一下：
按照时序看第一个：
按照时序看第二个：
分析得出：这个UDP包在交换机和路由器之间互转循环，即：SW—>R—>SW—>R。。。。一直循环到TTL=0然后才丢掉UDP包！
得出结论：
路由器和交换机之间发生了路由环路，监控网访问的目的网段是172.16.40.0/24。但很奇怪的是内网并不存在这个网段，即便是监控设备去访问该网段也会被路由器从WAN口发出去才对，怎么又弹回来了呢？那一定是和配置有关了！
第四步：检查核心交换机和路由器的路由表
核心交换机路由表如下：
核心交换配置是标准的没问题，再看看iKuai路由表：
iKuai上的回程路由，IT人员为了省事配成了172.16.0.0/16（即包含内网所有网段）下一跳给核心，这个做法简直灾难！一旦内网访问172.16.1.X、172.16.2.X、172.16.200.X主干路就环了，链路带宽就爆了呀！
总结及解决方案
小结如下
- 项目内网有3个VLAN网段，分别是172.16.10/20/30.X；
- 某为核心交换机全0路由下一跳指向iKuai出口路由器，保证上外网，此配置无问题；
- 为了省事，iKuai的回程静态路由配置成一条：目的172.16.0.0/16下一跳指向核心。这个配置下，一旦访问非内网段且处于172.16.0.0/16网段的IP时便发生路由环路，比如访问172.16.1.1，路径跟踪如下：
解决方案
回程路由一定要包含明细，不要搞大网段！如下：
