背景介绍
客户企业是一家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口流量异常过大”。我们只需要在核心交换机上联接口查看数据统计即可,确认到底这个大流量是不是广播&组播!
命令如下:
<核心交换机>dis int g0/0/1
释义:查看上联口数据统计,每隔5s敲一次确认报文变化量
从上图可以看到问题复现时,核心交换上联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,路径跟踪如下:
解决方案
回程路由一定要包含明细,不要搞大网段!如下: