一、所遇问题描述
![]()
如上图所示
,
交换机端口
1
:
1
-
1
:
12
、
2
:
1
-
2
:
8
在同一个
VLAN
中,网关指向
CISCO7206
的下行端口
FA0/0
的
IP
。另外
1
:
13
下接一个大客户,
1
:
14
下接一个大客户,他们的网关指向
BIG400
上本
VLAN
的
IP
,也就是说这两个大客户是在
BIG400
上作三层转发,所以他们的
ARP
广播是不会影响
CISCO7206
的。
客户运维工程师向我们反映一下问题:
问题一:在用户侧
PC
执行
ping
指令到
BIG400
上的
VLAN
的
IP
,出现
ping
几个包就会出现一个延时比较大的
ICMP REPLY
的报文。改
ping
上端
CISCO
路由器的
IP
有时也如此。
问题二:如图一所示,在
BIG400
上端连接的是
CISCO7206
路由器。一段时间以来先后两次发现下面的用户上网时出现丢包的情况,此时查看
CISCO7206
的
ARP
表发现
ARP
表满,他们清空
ARP
表后用户上网出现正常。
二、问题分析与逐一解答
问题一:在用户侧
PC
执行
ping
指令到
BIG400
上的
VLAN
的
IP
,出现
ping
几个包就会出现一个延时比较大的
ICMP REPLY
的报文。改
ping
上端
CISCO
路由器的
IP
有时也如此。
答:先看
PING
到
BIG400
的
VLAN IP
的情况:在交换机中为了保证设备转发正常业务流的高优先级,我们在设备中作了设置
(
系统出厂缺省
)
凡是
PING CPU
也就是本地
Vlan IP
的报文优先级比较低,优先保证设备转发用户底业务流。所以,
PING
本机
VLAN
的
IP
时出现一定的延时是正常的,用户不用担心。
再看客户提到的
PING
上端路由器的
FA0/0
的
IP
,有时也出现一定的延时的情况。当时我接到客户的这个问题后登陆到
BIG400
看了一下配置,发现
BIG400
上
FDB
(
MAC
地址表)老化时间改为
10
秒了,系统缺省为
80
秒。经咨询这个参数是当时开始测试
BIG400
时设置上的。
8
月
17
日
修改到
80
秒系统缺省参数后,
8
月
18
日
我们观察时就没有出现延时包。
再多说几句,如果您从
BIG400
上执行
PING
指令到
CISCO7206
,因为源
IP
仍未
BIG400
的
CPU
的
IP
,所以还是象刚才谈到的设备对这种数据的优先级问题,毕竟
ICMP
是一个双向协议。另外,执行这样的
PING
指令到
CISCO7206
的
FA0/0
即使出现偶尔的延时的情况,从技术角度讲也是正常的,因为宽带网络中难免有突发流,
CPU
的利用状况出现一定程度的抖动是常见的。
问题二:如图一所示,在
BIG400
上端连接的是
CISCO7206
路由器。一段时间以来先后两次发现下面的用户上网时出现丢包的情况,此时查看
CISCO7206
的
ARP
表发现
ARP
表满,他们清空
ARP
表后用户上网出现正常。可以看出是因为
CISCO7206
受到大量的
“
伪
”ARP
广播的影响导致
CPU
资源紧张,最终导致转发数据丢包。所以,找到和切断使
CISCO7206
的
ARP
表满的元凶是解决问题最好的方法!
(真实环境下实际上是两台路由器,铁通是采用了思科的
HSRP
热备份的技术,始终有一台保持激活工作状态。所以,对
BIG400
来说可以看作上端只有一台
CISCO7206
路由器。)
分析一:这些
ARP
广播表项是不是由
BIG400
产生的呢?让我们通过从现场用
sniffer
抓到的报文来找答案吧!
我此时在 BIG400 上作了一个端口镜像:把 BIG400 的上联端口 1 : 1 镜像到端口 1 : 5 ,在 1 : 5 端口上连接我的笔记本,打开 sniffer 程序开始抓包,然后查看抓到的报文。如图 2 所示: ![]()
就象图
2
这样,在
sniffer
抓到的报文中没有由
BIG400
发出的异常的大量的
ARP
报文。说明这些大量
ARP
并不是由于
BIG400
发出,再者,
BIG400
作为一台交换设备,对外发大数量级的
“
伪造
”ARP
广播的可能性从技术也讲不通。
那么我们分析看,
BIG400
下面的
Vlan yazhou
和
Vlan shilongtv
两个
VLAN
的用户因为是通过
BIG400
作三层交换的,所以他们的
ARP
广播不会透过三层本
VLAN
的。
最后再来看看图
1
的网络拓扑,大家可以看到从端口
1
:
1
-
1
:
12
、
2
:
1
-
2
:
8
下面连接了大量的铁通机房用户,而这些端口和上面的
CISCO7206
路由器的
FA0/0
端口都属于一个
VLAN
,也就是处于一个广播域内。大家思考一下,如果
BIG400
上这些端口上的用户设备发出大量
ARP
广播时,因为
BIG400
对于这些用户来说是二层,所以
BIG400
上不会生成这些
ARP
表项,而作为他们网关(或路由下一跳)的
CISCO7206
来说将生成大量的
ARP
表项。
从上面的分析看到如果这些异常的
ARP
广播是在
Vlan uplink
这个大的广播域里产生的,那么
CISCO7206
的
ARP
表就会受到冲击。那么,是不是的确这些
ARP
广播是从这里发起的?如果是从这里发起的的话,那么是计算机中了病毒还是有人蓄意攻击?这两个问题我不敢武断的判断!需要铁通的维护工程师们最后确定!毕竟这些
ARP
广播正如铁通机房的维护工程师所说并不是总发,我去现场的偶然时间里也没有发现狂发
ARP
的设备。但我的怀疑是建立对在实际的网络拓扑的分析以及对当时抓的包的分析基础上的。那好,让我们先看看当时在
Vlan uplink
这个大广播域中抓到的包吧!
我此时把刚开始在
BIG400
上作的端口镜像功能删掉了,也就是说从端口
1
:
5
上抓到的包就是充斥整个
Vlan uplink
当然还包括
CISCO7206
的
FA0/0
端口的数据包。我截取一个典型的情况给大家看:如下图
3
![]()
大家看到了,这是一个
“
扫描程序
”
!
从报文的源
IP
、目的
IP
可以看出,这些包都是从一个
IP
地址为
63.230.122.145
的主机发出,目的
IP
是采用
“
遍历
”
方法针对
211.98.168.0
网段扫描,这个网段是属于广州铁通。另外,从
sniffer
的
rel. time
一栏可以看出发包的频率是相当的快!大家再看图
3
中
sniffer
的分析中(上图点黑处)指示这些遍历搜索的端口号是
TCP
的
1433
端口,也就是
MS-SQL-Server
的通信端口。可见这是在利用
MS
-
SQL
-
Server
的漏洞进行的搜索。
这时,你不禁要问了:
“
这个包来自那里呢?
”
分析:首先假设这些包不是有人制造出来的的,那么
63.230.122.145
这个
IP
就是一个真实存在的主机的
IP
地址,我们利用
Trace
跟踪的手段就能查询出这个
IP
的来源。我当时用跟踪软件跟踪的结果如下图
4
所示:
![]()
显示
IP
为
63.230.122.145
的主机是位于美国卡罗拉多州的某个地方。但,这些报文这是从这里发出的吗?答案是
“
否
”
!
让我们从图
3
中
sniffer
抓到的包中找原因。回头看看图
3
中的
MAC
地址部分,可以看到在这条报文中,目的
MAC
为
00-e0-f c-02-12 -b7
,源
MAC
为
00-d0-63-52-d0-00
;经过查询
BIG400
的
FDB
表和
CISCO7206
的
ARP
表源
MAC
是
CISCO7206
的,然而目的
MAC
却是这个一个不存在的
MAC
地址,而且翻阅
sniffer
抓到的包,发现这个目的
MAC
有时变为:
00-e0-fc-02-12-b6
,显然是人为制造的一个在此网络并不存在的
MAC
地址,所以这个包不可能是路由器的外部发出的,因为对于一个并不存在的
MAC
地址,路由器作三层转发时是无法完成二层
MAC
地址部分的再次封装的。所以说这些报文是在
Vlan uplink
下面连接的这个大广播域中发出的。这些报文势必对处在一个广播域中的
CISCO7206
路由器造成一定的影响。
这只是我当时偶然在抓到的报文发现的一个问题。在此提出希望能引起铁通维护工程师的注意!当然从抓到的报文看这些搜索
IP
的报文并没有产生大量的
ARP
广播,但大家想想看如果这个搜索
IP
的软件或病毒等换成了那个产生
ARP
广播的软件或工具,
CISCO7206
的
ARP
表项突然变满也就不奇怪了。
|