本文主要給大家詳細的介紹了對于動態(tài)路由被阻擋引發(fā)的問題，我們將如何解決？下面的文章將給予我們詳細的介紹，希望此文對大家有所幫助。

前些時候，某單位內網訪問出現了一則奇怪的故障現象，主要問題是該單位內網的防火墻設備由于工作時間比較長，性能不是很穩(wěn)定，于是新買回來一臺同品牌的防火墻設備，來替換原來的舊設備，原本以為完成替換操作后，內網運行穩(wěn)定性更好了；可誰曾想到，新防火墻設備投入運行后，該單位內網訪問不但穩(wěn)定性沒有提高，而且所有終端都無法正常訪問內網系統了。內網網絡發(fā)生這樣蹊蹺的故障，事關重大，我們趕快對故障現象進行追蹤、排查。

網絡環(huán)境

局域網中的普通客戶機，通過100M雙絞線分別連接到八臺Cisco型號的二層交換機上，所有二層交換機通過多模光纖連接到Cisco型號的核心交換機上，核心交換機通過路由器連接內網平臺系統；為了保證網絡訪問安全，網管特意在核心交換機與路由器之間，放置了硬件防火墻設備，并且防火墻設備工作于透明模式狀態(tài)。為了防止廣播風暴以及網絡病毒影響整個局域網的運行，網管特意將單位的所有客戶機劃分成了6個虛擬工作子網，每個虛擬工作子網的網關全部建立在Cisco型號的核心交換機上。

故障現象

平時，舊防火墻設備工作在透明模式狀態(tài)下時，局域網中的所有終端都能正常訪問內網系統；但是，自從使用新防火墻設備替換舊設備之后，就出現網絡訪問故障了。局域網中的所有終端都不能成功訪問內網平臺系統，任意登錄一臺終端，并在該系統中執(zhí)行ping命令，測試路由器的IP地址是否連通時，發(fā)現都不能成功。起初，網管還以為是新防火墻設備存在設置不當的因素，可是仔細查詢之后，發(fā)現新防火墻也是工作在透明模式狀態(tài)下，同時沒有設置任何安全過濾規(guī)則，按理來說，防火墻不會對終端的網絡訪問進行攔截呀！后來，網管擔心新的硬件防火墻設備存在質量問題，于是臨時去掉該防火墻，將路由器設備和新防火墻設備直接連接在一起，結果發(fā)現局域網中的所有終端都能順利地訪問到內網平臺了，這么一來網管確認新的防火墻設備肯定存在問題。

故障排查

由于去掉硬件防火墻，局域網中的終端都能正常訪問內網，同時硬件防火墻后臺系統中也沒有設置明顯的安全過濾規(guī)則，為此網管將故障排查重點“鎖定”在硬件防火墻身上。既然從硬件防火墻的設置上找不出問題，那多半是該設備的質量出現了問題；為此，網管立即聯系了該設備供應商的網管，請求他們到現場來幫忙解決問題。在故障現場，網管了解了故障現象后，初步判斷問題可能出在軟件設置方面。

為了檢查硬件防火墻的軟件設置是否存在問題，網管立即通過console端口登錄進入該設備的后臺管理界面，查看安全過濾規(guī)則時，果然發(fā)現只設置了一條any到any的安全規(guī)則，這條訪問規(guī)則應該對任何網絡訪問都予以放行呀。繼續(xù)查詢之后，他發(fā)現這臺防火墻設置了管理IP地址和網關地址，原來該地址是網管為了方便遠程管理新防火墻用的，難道是這里的設置讓硬件防火墻變成了“攔路虎”？網管嘗試著刪除了這個管理地址，同時重啟防火墻設備后臺系統；待重新啟動穩(wěn)定后，網管在防火墻后臺系統ping測試了一下路由器的IP地址，結果發(fā)現測試成功，再測試核心交換機的IP地址時也是正常的，難道問題這么快就解決好了？

可是，當網管嘗試從終端中進行上網測試時，發(fā)現內網還是不能正常上網，顯然問題的根源還是沒有真正找到。不得已，網管只好將防火墻的所有設置全部恢復到默認狀態(tài)，之后重新進行了一下配置操作，結果發(fā)現核心交換機與路由器之間仍然可以相互ping通，但是局域網中的終端就是不能正常訪問內網；由于ping測試操作正常，網管認為問題肯定與防火墻設備沒有任何關系，無法訪問的故障現象很可能是內網自身引起的。

于是，網管自己也開始懷疑內網有問題了；為此，他從局域網中任意選擇了一臺終端，開始對數據包的發(fā)送進行跟蹤測試，結果發(fā)現數據包始終無法達到內網的路由器，難道是防火墻或者核心交換機丟棄了目標數據包？考慮到防火墻沒有設置任何過濾規(guī)則，網管估計可能是核心交換機將上網數據包自動過濾掉了，于是登錄進入核心交換機后臺系統，執(zhí)行字符串命令“show access-list”，來查看核心交換機究竟對哪些內容進行過濾了，可是讓他沒有想到的是，這個訪問列表中竟然沒有任何內容，這也就意味著核心交換機沒有執(zhí)行數據包過濾操作；順便執(zhí)行字符串命令“show ip route”，查看它的路由表記錄時，發(fā)現路由記錄明顯不正常，竟然沒有達到內網的路由，這也難怪局域網中的終端不能正常訪問內網了。

故障解決

核心交換機上為什么沒有指向內網的路由記錄呢？在這種狀態(tài)下，為什么連接舊硬件防火墻可以正常訪問內網呢？想到核心交換機直接連接到路由器上時，局域網中的終端也能夠正常訪問內網，于是網管估計核心交換機肯定啟用了ospf協議，這樣一來它就能獲得通往內網的動態(tài)路由，否則終端絕對不肯能訪問到內網；為了驗證自己的猜測是否正確，網管又在核心交換機后臺系統，執(zhí)行了“show runn”字符串命令，結果發(fā)現核心交換機果然啟用了動態(tài)路由功能；在查看該路由協議的具體配置時，網管發(fā)現ospf鄰居無法找到，怪不得核心交換機上無法獲得通往內網的動態(tài)路由。

會不會是路由器中沒有啟用ospf協議功能，造成核心交換機無法從路由器那里獲得動態(tài)路由呢？可是轉念一想，在核心交換機直接連接到路由器上時，局域網中的終端可以正常訪問內網，這說明直接連接時，核心交換機可以從路由器那里學到動態(tài)路由，那為什么在連接了硬件防火墻后，核心交換機無法從路由器那里獲得動態(tài)路由呢？對于這樣的問題，網管認為ospf協議在尋找建立動態(tài)鄰居時，需要以組播方式向網絡發(fā)送hello包，可是硬件防火墻在默認狀態(tài)下是不允許組播數據包通過，那樣一來硬件防火墻就會阻礙核心交換機從路由器那里學到動態(tài)路由，在動態(tài)路由被“擋”之后，局域網中的終端自然就不能訪問內網平臺了。

弄清楚故障原因之后，網管立即在硬件防火墻中重新配置了合適的訪問規(guī)則，確保該設備不會“阻擋”動態(tài)路由，果然經過這樣的設置后，網管再次在核心交換機上執(zhí)行“show ip ospf neighbor”字符串命令時，發(fā)現到了ospf鄰居，這個時候進行上網測試時，發(fā)現終端已經能夠順利地訪問內網了，至此，無法訪問內網的故障現象就被成功解決了。