某栋楼一些用户断网的故障

湖南工业大学现代教育技术中心 郭兆宏

有一段时间，单位某栋K 楼有几个用户打电话说断网了，网络故障处理的老师去现场发现802.1X 认证有时成功有时不成功，ping 网关有时通有时不通，但过一段时间就好了，让用户查杀病毒。

某一天这栋K 楼有很多个电话打来说断网了，马上检查此楼的16 台交换机都运行正常，最近一个月都没有掉线的，于是开始网络排查起来。

交换机NFPP 保护造成断网

当某一天单位的某栋K楼有很多电话打来说断网时，笔者以为是交换机断网，但检查此楼的所有交换机都运行正常，最近一个月没有掉线的。此楼有1 台汇聚交换机16 台接入交换机，对反映较多的2 和4 楼各4 台接入交换机进行查看，流量带宽都不大，也没断网的记录。登录其中2 台接入交换机看了下在线时间都有30多天了。先将4 楼的4 台交换机重启，过一段时间此楼4 层还是有电话打来，登录汇聚交换机查看，CPU 正常，端口流量正常，用命令“sh nfpp arpguard hosts”、“sh nfpp ip-guard hosts”发现都有多个隔离的IP，平时也有隔离的IP，不过今天隔离的数量有点多，一看IP 地址基本是打电话说断网的，回复断网的电脑有安全问题，要杀电脑病毒。在4 楼2 台接入交换机上也发现一些NFPP隔离的IP 地址，其中有2 台里都有172.X.X.200，且在是上联端口，而这个地址段172.X.X.200 段用户实际不在这栋楼，是离这栋K 楼100米左右的另外一栋Y 楼的Y部门用的，只是网络从这栋K楼的汇聚上接的，马上登录这栋Y 楼的接入交换机，但发现NFPP 里没有隔离任何的IP 地址。

说明下单位使用的是锐捷交换机，锐捷交换机有网络基础保护策略（Network Foundation Protection Policy，NFPP）。在网络环境中经常发现一些恶意的攻击，这些攻击会给交换机带来过重的负担，引起交换机CPU 利用率过高，导致交换机无法正常运行。

NFPP 可以有效地防止系统受这些攻击的影响。在受攻击情况下，保护系统各种服务的正常运行，以及保持较低的CPU 负载，从而保障了整个网络的稳定运行。ARP-Guard 功能主要目标为保护设备CPU，防止大量攻击ARP 报文送CPU 导致CPU利用率升高，所以ARP-Guard实现了对送CPU ARP 报文的限速和攻击检测。IP-Guard可以识别当主机发出的报文目的地址为交换机直连网段不存在或未上线用户的IP地址时，交换机会发出ARP进行请求，如果存在这样的连续不断的攻击，会导致设备CPU 很高。当ARP 报文速率超过限速水线时，超限报文将被丢弃。当ARP 报文速率超过告警水线时，将打印警告信息，并发送TRAP，基于主机的攻击识别还可以对攻击源头采取硬件隔离措施。

调整交换机的NFPP 参数

又回到K 栋楼的4 楼2 台NFPP 隔离最多的接入交换机上，在端口上增加“arp-check”及“anti-arpspoofing ip 172.X.X.1”命令，刚刚做完4 台交换机配置就有从K 栋楼有信息反馈回来，说是表项不足，无法认证了！

笔者只好立即删除这2行新增加的命令，再检查发现此楼交换机NFPP 基本没配置，使用的都是默认值。因为此楼是行政办公楼，平时最多只有200 左右个用户，也就没配置。

先是在此楼的汇聚交换机上对NFPP 马上增加配置：

把这些配置也增加到16台接入交换机上，做完后再在汇聚及此楼接入交换机上查看，NFPP 隔离的IP 的数量明显减少了，同时回复让此栋K 楼内各个部门的用户都要多重软件查杀病毒，尽量少用或最好不用小路由器，下载时少开任务，下载后关闭下载的进程，平时少开窗口少开程序。

通过调整增加NFPP 参数、让此楼各个部门用户查杀病毒后，此栋K 楼反映断网的用户明显少了，登录交换机在NFPP 里隔离的IP 地址数量也少很多了。

发现172.x.x.200 可能是根源，查杀后基本无NFPP 隔离

通过调整增加NFPP 参数后，此栋K 楼反映断网的用户明显少了，但在汇聚及至4 楼1 台接入交换机上还是不断隔离172.X.X.200，还有其他几个不固定的IP 地址。登录Y 楼的接入交换机发现172.X.X.200 在8 号端口是不认证端口，此端口还有另外三个MAC 地址，这个IP:172.X.X.200 是这个Y 楼Y 部门一台业务服务器，先把此8 号端口加上认证，在行政楼的汇聚上的ACL 上增加禁止172.X.X.200，观察30多分钟还是一样不断隔离此IP，同时在Y 楼的交换机上也NFPP 也发现有几个IP 地址隔离了，有的也在8 号端口。

笔者直觉认为这个172.X.X.200 肯定有问题，直接关闭Y 楼接入交换机的8 号端口。在上网行为日志中查询发现172.X.X.200 最近一周的记录基本都是协之通XT800 的记录，差不多是20分钟一次，在安全设备的日志中发现172.X.X.200 有挖矿蠕虫被阻断几十个记录，于是将上面2 个日志的截图发给此Y 楼Y 部门的人，让他们必须查杀这台服务器，其他用户电脑也要查杀病毒，处理好后才能开通端口。再回来K 楼的汇聚及接入交换机用命令“sh nfpp arpguard hosts”、“sh nfpp ip-guard hosts”查看基本都是空白的。可以肯定172.x.x.200 就是这次K 楼一些用户断网的根源。

过两天后，Y 楼Y 部门说是查杀病毒了，并且172.X.X.200 是他们业务服务器，关闭网络影响了他们正常业务，只得打开8 号端口。而在关闭Y 交换机8 号端口的这两天，笔者也一直关注了K 楼汇聚交换机NFPP 基本没有隔离的IP 地址。再打开Y交换机8 号端口不一会，在K 楼的汇聚上NFPP 就隔离了172.X.X.200，在Y 楼的接入交换机NFPP 也隔离其他IP。

172.x.x.200 问题还在！必须要人工隔离172.X.X.200，在ACL 里增加禁止，先是在Y 楼的接入交换机和K 楼的汇聚交换机在ACL里是IP、TCP、UDP 协议禁止172.X.X.200，但观察一会儿后还是有NFPP 隔离172.x.x.200，就把能配置的协议ICMP、IGMP、EIGRP 全加上禁止，在K 楼的汇聚交换机的各接入交换机端口加上禁止172.X.X.200 的ACL，再 把K楼其他15 台接入交换机同时增加禁止172.X.X.200。

可是在K 楼汇聚及4 楼一台接入交换机上还是发现NFPP 不断隔离172.X.X.200，同时还隔离有其他IP，再次要求Y 楼的Y 部门马上查杀172.X.X.200 的病毒，这个问题严重行政办公楼的网络运行了，否则整个Y 部门断网。

在K 楼的汇聚交换机的Y 部门接入端口发现广播包有些大，在Y 部门接入交换机8 号端广播包也有点多，于是在Y 部门的接入交换机8 号端口增加storm-control broadcast pps 200，在汇聚交换机Y 部门上联口增加storm-control broadcast pps 1000，同时增加VLAN 的修剪。

后来Y 部门找来业务公司来处理了172.x.x.200 服务器安全问题，说是把远程控制的和挖矿的病毒杀掉了，这之后在K 楼的交换机里没再发现NFPP 里有隔离172.X.X.200 的了。但在K楼的汇聚及2 楼的一台接入交换机多次发现NFPP 隔离172.X.Y.18。找到此用户，通知其处理电脑的安全问题，他说此IP 是一台小路由器，是经常断网的，让他关掉此小路由器。再次调整K 楼的交换机的NFPP 参数，将每IP 的限速提到50，警告提到60，即：

又观察了几天K 楼交换机里NFPP 基本没有隔离，只是偶尔能看到1-2 个隔离的IP，且不固定，被NFPP 隔离的IP 地址的用户也没有报网络故障。这K 栋楼虽然还是有报网络故障，但通过查看交换机都不是当时NFPP隔离的IP，网络故障的是其他问题。至此K 楼一些用户报告断网的问题基本解决。

总结

单位某栋K 楼一些用户断网，通过排查交换机发现是NFPP 保护机制起做用，交换机自动对一些大量发包的IP 地址进行隔离，通过调整NFPP 的arp-guard、ip-guard 的参数，找到还在大量发包的一个IP：172.x.x.200，通过查此IP 地址的上网行为和安全设备日志记录，发现此IP 有大量非正常行为。

通知此IP 用户查杀病毒，并让K 楼所有用户查杀病毒。通过关闭、放开此IP地址所在接入交换机端口确认此楼一些用户断网跟此IP 有关，在此IP 用户彻底查杀病毒后，通过放大NFPP 的参数，此楼交换机NFPP 隔离的IP 地址基本没有了，K 楼报网络故障的数量明显减少了，虽然K 楼也还报有网络故障的但通过排查与NFPP隔离无关，是其他问题。