以下的文章主要向大家讲述的是动态ARP检测， 引发上网断断续续， 为了帮助各位归纳这方面故障的经验， 本文就是从实战角度出发， 来向各位还原一则由动态ARP检测功能引发的上网断断续续故障的排查过程， 希望下面的内容能起到抛砖引玉的作用!
局域网网络使用起来很方便， 但管理起来却不是一件容易的事情， 单单用户不同的上网需求， 就能让网络管理员忙得不亦乐乎， 更不用说频繁出现的各种网络故障了。 这不， 上网断断续续故障现象十分常见， 引起该故障的因素也是复杂、多变， 该故障解决起来自然也容易多走弯路;`为了帮助各位积累这方面故障的经验， 本文现在就从实战角度出发， 来向各位还原一则由动态ARP检测功能引发的上网断断续续故障的排查过程， 希望下面的内容能起到抛砖引玉的作用!
组网环境
某单位大楼局域网规模适中， 位于中心机房的核心交换机采用的是H3C品牌的S8500交换机， 所有客户端系统通过超5类网络线缆连接到分布在六个楼层中的接入交换机上， 接入交换机统一采用2组堆叠的H3C品牌S3050交换机， 这些交换机全部位于每个楼层的弱电间中， 所有接入交换机全部使用千兆多模光纤与局域网核心交换机相连。
为了抑制局域网中的网络风暴现象， 网络管理员特意按照工作部门的不同， 将局域网网络划分成12个虚拟工作子网， 各个虚拟工作子网的网关全部设置在局域网核心交换机上;此外， 为了提高网络管理效率， 局域网中还专门架设了一台DHCP服务器， 局域网中的每一台客户端系统都采用动态获取地址方式进行上网， 平时局域网中的所有系统都能快速、稳定地上网访问。
考虑到最近一段时间ARP病毒比较猖獗， 为了保证网络能够始终运行， 网络管理员在各个接入交换机中分别启用了防ARP病毒功能。 为了配合单位大楼建设视频传输系统的要求， 将位于各个楼层中办公室内的视频设备划分到同一个虚拟工作子网中， 并调整了各个接入交换机的相关配置， 例如统一增加了两个虚拟工作子网。
故障现象
自从接入交换机被调整过之后， 局域网网络运行一直就不稳定， 许多用户纷纷打来电话反映情况， 说他们的客户端系统托盘区域处经常弹出网络连接受限的提示信息， 这个提示说明客户端系统普遍存在无法从局域网DHCP服务器那里获得正确的上网参数。
即使有的客户端系统能够勉强上网， 网络连接也是断断续续， 使用ping命令测试线路连通性时， 发现网络传输延迟现象非常的严重， 而且数据丢包率一直很高;由于各个楼层的所有客户端系统都存在相同的故障现象， 笔者下意识以为局域网的核心交换机出现了类似缓存溢出这样的软错误， `于是尝试着重新启动了一下核心交换机后台系统， 发现故障现象依然存在。 后来， 笔者顺便重新启动了一台普通楼层接入交换机， 发现对应交换机下面的客户端系统在交换机刚刚启动稳定的那一刻， 上网速度稍微有点正常， 可是没有多长时间， 相同的故障现象又出现了。
排查故障
既然重新启动楼层接入交换机， 可以暂时让上网速度恢复正常， 那问题看来与楼层接入交换机有关系。 为了能够探清究竟， 笔者立即以系统管理员身份登录进入其中一个楼层的接入交换机后台系统， 使用“dis dia”命令对交换机的各个交换端口进行扫描检查， 看看它们的数据流量状态是否正常， 结果果然发现局域网中有广播数据包存在， 并且该广播数据包容量在不断变大， 难道是局域网网络中存在有网络病毒或网络环路现象？
为了排除这方面因素的干扰， 笔者立即进入流量异常的交换端口视图模式状态， 在该状态下执行字符串命令“shutdown”， 将数据流量不正常的交换端口全部关闭， 可是这样的努力没有换来任何效果， 显然上网断断续续故障与网络病毒或网络环路没有任何关系。
后来， 笔者随意找了一台客户端系统， 依次单击“开始”/“运行”命令， 在弹出的系统运行对话框中， 执行ping命令来测试对应客户端系统所在虚拟工作子网的网关地址， 发现数据丢包率达到了惊人的85%， 同时数据传输延迟时间平均达到500ms左右。
可是， 当笔者尝试从局域网的核心交换机上， 使用ping命令测试Internet网络中的某个站点时， 发现这项测试操作一切正常， 并且数据丢包率仅仅只有1%左右， 显然局域网与Internet网络之间的连接是正常的， 而问题可能出现在核心交换机与故障客户端系统之间。
为了能找到具体的故障原因， 笔者在局域网的核心交换机后台系统， 使用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资源， 最终会引发上网断断续续的故障现象。
故障解决
找到故障原因之后， 笔者立即重新调整了各个楼层的接入交换机配置参数， 去掉连接视频传输系统的VLAN， 并新增加了一台新交换机， 让所有使用视频传输系统的客户端系统单独使用新的交换机进行上网， 如此一来既能保证原来系统的上网稳定， 又能方便管理新的视频传输系统。
总结该故障的排除过程， 笔者发现该故障的发生纯属巧合， 如果不在楼层的接入交换机中同时增加相同的VLAN， 或者这些楼层的接入交换机没有同时启用动态ARP检测功能和DHCP嗅探功能的话， 那么这种网络掉线的故障就不会发生。
而以往我们在解决网络掉线问题的时候， 经常使用的方法就是先观察交换机设备的信号灯状态是否正常， 如果不正常的话再尝试重新启动一下交换机后台系统， 相信多数网络故障就能被自动解决了。 没有想到， 这次故障的解决费了这么大麻烦!
……