考慮到網絡管理員先前已經掃描過各個交換端口的流量情況，并沒有看到有異常情況，這說明局域網中并不存在重要數據端口瓶頸現象，也就是說上網不穩定故障現象與端口瓶頸因素也沒有關系。同時，重要交換端口的數據流量大小正常，也反映了局域網中不存在廣播風暴或者網絡環路現象，因為這些現象要是存在的話，我們應該能夠看到重要交換端口的輸出廣播包大小應該不斷增加才對，可事實卻沒有，這就意味著上網不穩定故障不是由網絡廣播風暴或網絡環路現象引起的。

　　在初步排除了端口瓶頸因素、網絡環路因素、廣播風暴因素以及網絡病毒因素后，網絡故障還是不能消除，這讓網絡管理員萬分的懊惱。以前提到上網不穩定故障，網絡管理員可能會下意識地認為是網絡連接不牢靠的因素，可是現在他怎么也不會懷疑到網絡連接因素上，因為這種上網不穩定的故障幾乎在各個部門的工作子網中都會出現，如果真的是網絡連接不牢靠的話，那也不可能局域網中所有計算機都同時出現不牢靠現象吧。

　　有沒有可能是網絡設備自身性能不穩定，造成了上網不穩定現象呢?聯想到夏天的時候，一些設備由于散熱不好，造成自身工作性能下降，經常出現上網掉線或速度緩慢現象，為此網絡管理員推斷可能是局域網中的路由器或交換機過熱，造成自身工作性能不穩定。于是，網絡管理員立即來到公司機房，先是觀察了路由器、交換機的信號燈狀態，發現一切正常，之后用手觸摸這些設備的表面溫度時，也沒有覺察到有什么異常現象。

　　在萬般無奈的情況下，網絡管理員決定登錄進入局域網的防火墻系統，查看其中的一些運行狀態信息，看看有沒有什么值得懷疑的地方。讓他感到非常意外的事情出現了，網絡管理員看到局域網防火墻竟然記錄了許多IP地址為0.0.0.0主機的通訊痕跡，那0.0.0.0究竟是什么樣的主機地址呢?經過上網搜索，網絡管理員發現該地址是Windows系統對所有未知IP的地址描述，包括網卡設備通過dhcp方式取得的地址，pppoe的IP地址，以及其它非本機指定的IP地址;此外，0.0.0.0地址也代表全零網絡，它能幫助路由器發送路由表中無法查詢的包。如果設置了全零網絡的路由，路由表中無法查詢的包都將送到全零網絡的路由中去。通過上面的描述，網絡管理員認為該地址其實就是一個不存在的地址，那么究竟是什么因素讓外網不停地與局域網中一個根本不存在的主機進行通信呢?如果真的是外網與 0.0.0.0地址不斷進行通信的話，那么外網的數據包是如何進入到局域網中的呢，因為單位局域網中的防火墻已經被設置，阻止那些使用明顯虛假地址的主機進行通信的?

　　解決故障

　　經過進一步查看防火墻記錄，網絡管理員看到0.0.0.0地址沒有進行任何通信操作，難道它們真的被防火墻攔截了?會不會是局域網遭到了非法攻擊，攻擊包在進入內網之后，將其IP地址喬裝成0.0.0.0地址了呢?可事實情況是，那個IP地址為0.0.0.0的主機沒有進行任何通信操作，那么非法攻擊包即使在嘗試攻擊內網，也沒有成功，如此一來它也不會造成上網不穩定的現象;為此，網絡管理員斷定不存在外網攻擊的事情，那個0.0.0.0地址肯定來自局域網內部，那么這個不可能的IP地址究竟是怎么產生的呢?再次上網咨詢相關信息，網絡管理員發現一些重要網絡設備的內存容量不夠時，可能會在通信過程中丟棄一些數據包信息，造成某些上網內容無法有效組合在一起，此時就容易產生一些0.0.0.0地址。

　　依照上述理論分析，網絡管理員推斷0.0.0.0地址很可能來自內網，并且該地址很可能是由于局域網中的交換機或路由器內存容量不夠引起的。由于上網不穩定故障在各個部門都存在，網絡管理員估計問題多半出在與個工作子網都有關的路由器設備上，于是這一次準備通過遠程連接方式登錄進入局域網路由器后臺系統，在遠程登錄過程中，網絡管理員感覺到登錄速度明顯遲鈍，看來路由器設備真的出現問題了。之后，他使用Console控制線直接連接到路由器后臺系統，查看其內存的使用狀態時，發現該設備的內存容量確實不足了，很明顯在上網高峰期間，路由器的內存容量就更顯不足了，如此一來路由器自然就無法正常轉發數據信息了，這也正是各個部門上網不穩定的原因。

　　找到了故障原因后，網絡管理員立即重新啟動了一次路由器系統，發現各個部門的上網狀態立即又恢復正常了，此時再次監控路由器的內存容量時，發現該內存占用率也在不斷變大，看來要真正解決問題，還得需要升級路由器設備，要不然過一段時間，又要重新啟動路由器系統了。