某棟樓一些用戶斷網的故障

湖南工業大學現代教育技術中心 郭兆宏

有一段時間，單位某棟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”查看基本都是空白的?？梢钥隙?72.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隔離無關，是其他問題。