| |
为了能找到具体的故障原因，笔者在局域网的核心交换机后台系统，使用ping命令测试了其中一台接入交换机的管理IP地址，测试反馈回来的结果是无法ping通，会不会是核心交换机与楼层接入交换机之间的物理连接存在问题呢?为了排除物理线缆因素，笔者特意找来了专业的光功率计，来测试连接核心交换机与楼层接入交换机的多模光纤线路连通性，结果发现光纤线路具有收发信号，看来问题还是出在楼层接入交换机上。
不得已，笔者只好再次使用Console控制线缆直接连接到楼层接入交换机上，使用“display interface”命令查看该交换机与核心交换机的级联端口状态，发现级联端口的数据流量还是特别大，同时大量的广播数据包依然存在;为了阻止广播数据包影响局域网的稳定运行，笔者特意在该接入交换机后台系统，启用了广播风暴抑制功能，然而该功能的启用并没有带来任何改变。之后，笔者随手执行了“display cpu”字符串命令，查看了故障交换机的系统资源消耗情况，结果让笔者很是吃惊，该交换机的系统CPU资源消耗率竟然达到了惊人的100%，而正常情况下交换机的系统CPU资源消耗率应该为25%左右，这也难怪笔者无法从局域网的核心交换机上ping通故障楼层接入交换机。将故障楼层接入交换机与局域网核心交换机之间的物理连接断开之后，笔者再次执行了“display cpu”字符串命令，结果看到该交换机的CPU资源消耗率迅速下降到30%左右;可是重新连接之后，故障楼层接入交换机的CPU资源消耗率很快又回到了100%，这是什么原因呢?
经过仔细分析、对比，笔者认为自从在接入交换机中启用了防ARP病毒功能后，局域网中才出现了上网不稳定的故障现象，会不会是这项功能在暗中“捣乱”呢?为了验证自己的猜想是否正确，笔者立即将接入交换机的动态ARP检测功能给关闭掉，之后又在对应交换机后台系统，使用“display cpu”命令查看了系统CPU资源消耗情况，果然CPU使用率立即从原先的100%下降到30%左右，对应交换机下面的客户端系统上网速度也恢复了正常。与此同时，另外几台暂时没有关闭动态ARP检测功能的接入交换机，其CPU使用率仍然一直居高不下，并且这些交换机下面的客户端系统上网速度还是断断续续，数据丢包现象仍然十分严重。很显然，局域网中的上网断断续续故障现象，与动态ARP检测功能有关。
原因解密
上网搜索了动态ARP检测功能的工作原理，笔者发现该功能会自动截取来自不信任网络端口发送过来的ARP数据请求，同时会自动验证对应数据包的数据绑定行为是否合法，看看它的地址绑定关系与DHCP绑定表中的是否一致，如果一致的话就对ARP数据包进行放行，要是不一致的话就对ARP数据包进行丢弃，这项功能可以有效地预防中间人攻击，也能防止局域网用户自行修改网卡物理地址和IP地址，避免局域网中发生地址冲突现象。经过进一步了解，笔者发现该功能往往与DHCP嗅探功能配合使用，并且该功能还存在一个明显的缺陷，那就是对ARP数据包的动态检测操作，需要不停消耗交换机系统的CPU资源，如果处理的ARP数据包流量特别大的话，那么交换机系统的CPU资源消耗率就会很高，严重时就能出现CPU资源被100%消耗的现象。
而DHCP嗅探功能在工作的时候，DHCP服务器会将分配出去的动态IP地址，以及客户端系统的网卡物理地址之间的对应关系，自动记录保存到一个地址绑定表中，任何客户端系统进行网络连接的时候，该功能会自动检查数据包的IP地址与网卡物理地址之间的对应关系，看看这种对应关系与地址绑定表中的记录是否一致，如果一致的话就允许目标数据包通过，否则将不允许数据包通过，这种功能可以有效地防止局域网其他不合法DHCP服务器的功能。
当一台交换机系统同时启用了动态ARP检测功能和DHCP嗅探功能的时候，既能有效防范非法DHCP服务器的干扰，又能禁止上网用户随意改动客户端系统的上网地址以及网卡物理地址来偷偷上网，如此一来就能实现安全、稳定相互兼顾的效果;但让笔者感到非常纳闷的是，这里的楼层交换机也是同时启用了这两项功能，为什么它们没有发挥应有的作用呢，反而只有关闭了动态ARP检测功能，才能解决上网断断续续故障现象呢?经过与集成商的沟通、交流，笔者终于找到了问题的答案，原来当交换机系统同时启用了上面两项功能，如果每一台交换机上都划分有相同的虚拟工作子网时，那么广播数据包就会在接入交换机之间不停地被发送或转发，如此一来就会大量消耗交换机系统的CPU资源，最终会引发上网断断续续的故障现象。 |
| 【收藏】【打印】【进入论坛】 |
|
|
|
|
| |
|
|
|
