策略路由惹故障

引言： 本文介紹一則由策略路由引起的故障及排除過(guò)程，期間抓包驗(yàn)證“數(shù)據(jù)包來(lái)回路徑不一致”被防火墻檢測(cè)丟棄的現(xiàn)象。本文重點(diǎn)分享了解決網(wǎng)絡(luò)疑難問(wèn)題的過(guò)程與方法，并給出一種在防火墻存在狀態(tài)下不影響源端網(wǎng)段間互訪的策略路由寫法。

故障現(xiàn)象

一天，某單位資深工程師給筆者打了求助電話，起因是該單位外網(wǎng)內(nèi)部分網(wǎng)段無(wú)法訪問(wèn)局域網(wǎng)內(nèi)系統(tǒng)，但均能上互聯(lián)網(wǎng)辦公。在筆者的要求下，工程師畫了該單位外網(wǎng)的簡(jiǎn)單拓?fù)鋱D如圖1所示。

該單位外網(wǎng)采用高可用性網(wǎng)絡(luò)架構(gòu)。出口采用電信運(yùn)營(yíng)商和政務(wù)網(wǎng)雙出口冗余熱備；核心層采用虛擬化技術(shù)，由兩臺(tái)國(guó)產(chǎn)H3C 7500系列高端交換機(jī)IRF虛擬化成一臺(tái)交換機(jī)；接入層（服務(wù)器區(qū)）采用多模光纖聚合鏈路上聯(lián)?，F(xiàn)在的現(xiàn)象是：某些網(wǎng)段（如172.18.49.0/24網(wǎng)段下）的計(jì)算機(jī)無(wú)法訪問(wèn)172.18.54.0/24網(wǎng)段下的服務(wù)器，無(wú) 法Ping通，但是該核心交換機(jī)下的其他網(wǎng)段卻正常，并且所有網(wǎng)段均能上網(wǎng)。

故障分析

這個(gè)網(wǎng)絡(luò)架構(gòu)屬于經(jīng)典的網(wǎng)絡(luò)架構(gòu)圖。核心交換機(jī)（可以看成一個(gè)交換機(jī)）下面的網(wǎng)段同屬于一個(gè)交換區(qū)，如果沒有特別的網(wǎng)絡(luò)策略或防火墻，理論上，互通沒有任何問(wèn)題（H3C交換機(jī)默認(rèn)是開啟網(wǎng)段間路由的）。問(wèn)題出現(xiàn)了，本著“分析驗(yàn)證”的思路，逐步開展以下分析。

1.排除服務(wù)器區(qū)域故障點(diǎn)

部分網(wǎng)段能訪問(wèn)服務(wù)器區(qū)網(wǎng)段，說(shuō)明服務(wù)器服務(wù)應(yīng)該正常。該工程師還給筆者強(qiáng)調(diào)前幾天還是正常的，期間沒人動(dòng)過(guò)服務(wù)器配置，這使筆者暫時(shí)排除服務(wù)器及服務(wù)器所在網(wǎng)段的設(shè)備問(wèn)題。

2.排除接入網(wǎng)段故障

故障點(diǎn)所在的接入交換機(jī)網(wǎng)段能夠正常上網(wǎng)，說(shuō)明接入交換機(jī)的設(shè)備和網(wǎng)路也應(yīng)正常。

3.排除核心交換機(jī)故障

有網(wǎng)段能訪問(wèn)，說(shuō)明核心交換機(jī)網(wǎng)段間路由是沒被關(guān)閉的。再說(shuō)，該工程師強(qiáng)調(diào)“前幾天都正?！薄ⅰ熬W(wǎng)段間是直接鏈路聚合上聯(lián)交換機(jī)的”、“沒有網(wǎng)絡(luò)阻攔策略和防火墻”。如果這樣的話，理論上沒問(wèn)題。

圖1 外網(wǎng)拓?fù)浜?jiǎn)圖

圖2 原數(shù)據(jù)包流圖分析

筆者要求遠(yuǎn)程查看核心交換機(jī)的配置，發(fā)現(xiàn)該單位為了流量負(fù)載均衡，部分網(wǎng)段采用了策略路由配置。在核心交換機(jī)上定義策略DianXinPre，為類DianXin指定流行為DianXinBehavior（下一跳為電信路由接口），為類ZhenWu指定流行為ZhenWuBehavior（下一跳為政務(wù)路由接口）。和故障網(wǎng)段相關(guān)的配置信息簡(jiǎn)述如下：

#通過(guò)Acl匹配，定義不同數(shù)據(jù)流向的類

# 定義不同類的下一跳數(shù)據(jù)路徑

redirect next-hop 電信路由下聯(lián)口IP

traffic behavior ZhenWuBehavior

redirect next-hop 政務(wù)路由下聯(lián)口IP

#把類和特定流向關(guān)聯(lián)，形成策略

4.排除策略路由配置錯(cuò)誤

看到目標(biāo)網(wǎng)段有策略路由配置，我們知道，策略路由的優(yōu)先級(jí)高于靜態(tài)路由，莫非數(shù)據(jù)包從接入交換機(jī)上聯(lián)口進(jìn)入核心交換機(jī)時(shí)，被直接策略轉(zhuǎn)向電信路由器后沒有回包，導(dǎo)致無(wú)法被Ping通？我繪制了如圖2所示的數(shù)據(jù)包流圖。

172.18.49.0/24 ping 172.18.54.0/24數(shù)據(jù)包流圖沿虛線流向，數(shù)據(jù)包沿虛線①-②方向到目標(biāo)網(wǎng)段，目標(biāo)網(wǎng)段因?yàn)橛胁呗月酚?，故回包沿③先到電信路由器（不是直接通過(guò)核心交換機(jī)轉(zhuǎn)給源端），然后電信路由器要寫條目的為172.18.49.0/24的回程靜態(tài)路由指向核心交換機(jī)（即線路④）返回到核心交換機(jī)，然后再沿線路⑤回包到源端。問(wèn)題有可能出現(xiàn)在線路④上。

可是，經(jīng)驗(yàn)老道的工程師當(dāng)時(shí)就打消了我的疑問(wèn)。工程師說(shuō)，這點(diǎn)他還是知道的，明確有回程路由，否則前幾天不會(huì)通。在我的要求下，他自己又登錄設(shè)備驗(yàn)證了有回程路由。

分析陷入了僵局，筆者要求分別從源端和目的端抓包分析（如圖3和圖4）。

圖3 源端抓包

圖4 目的端抓包

圖5 新數(shù)據(jù)包流圖分析

由圖3和圖4可以看出，源端發(fā)包只有request包，就是沒有服務(wù)器響應(yīng)包，無(wú)法建立TCP連接，而服務(wù)器端抓包正常（能Ping通源地址）。原因已經(jīng)很明確了，源地址在訪問(wèn)服務(wù)器的時(shí)候，服務(wù)器端沒有回程數(shù)據(jù)包！

可是，工程師不承認(rèn)上面的分析。筆者要求，遠(yuǎn)程桌面親自查看，工程師登錄了設(shè)備，原來(lái)是一臺(tái)某大廠商的防火墻，并找出回程靜態(tài)路由配置。筆者問(wèn)，不是說(shuō)是路由器嗎，怎么會(huì)是防火墻？工程師說(shuō)，上個(gè)星期把出口換成防火墻了，但路由器的配置一一對(duì)應(yīng)遷移到防火墻了，后來(lái)測(cè)試“一切”正常。一看到防火墻，筆者猶豫了，是不是有什么阻攔策略呢？查看發(fā)現(xiàn)，回程靜態(tài)路由確實(shí)存在并且正確。問(wèn)題出在哪里呢？

再次結(jié)合數(shù)據(jù)包流圖分析過(guò)程并特別留意服務(wù)器回程的數(shù)據(jù)包，問(wèn)題突然豁然開朗。

如 圖5所 示，172.18.49.0/24 沿虛線①-②傳輸數(shù)據(jù)包，由于172.18.54.0/24網(wǎng)段做策略路由，優(yōu)先級(jí)高于靜態(tài)路由，回包被策略到電信出口防火墻，由于是狀態(tài)檢測(cè)包過(guò)濾的防火墻，事先沒有請(qǐng)求包通過(guò)而直接返回?cái)?shù)據(jù)包，防火墻認(rèn)為是攻擊行為，故直接攔截掉了。筆者啟用了該防火墻的非狀態(tài)檢測(cè)包過(guò)濾功能，困擾該工程師的難題立刻解決了。

為什么一開始服務(wù)器端卻能Ping通客戶端呢？其實(shí)，很好理解。服務(wù)器發(fā)起的訪問(wèn)包被策略路由沿虛線③轉(zhuǎn)發(fā)到防火墻（防火墻對(duì)合理的請(qǐng)求包是允許通過(guò)的），然后通過(guò)靜態(tài)路由沿虛線④到核心交換機(jī)，后到客戶端；客戶端回包，直接通過(guò)核心交換機(jī)返回到服務(wù)器端，一次通信連接順理成章地建立成功。

故障解決

知道問(wèn)題原因，故障暫時(shí)解決了。可是，該工程師說(shuō)，這不是長(zhǎng)久的解決辦法，啟用防火墻的非狀態(tài)檢測(cè)包過(guò)濾功能就意味著防火墻的部分安全功能被廢棄了。

確實(shí)如此，策略服務(wù)器網(wǎng)段的業(yè)務(wù)需求不能改變（因?yàn)橥饩W(wǎng)發(fā)布需要），其他網(wǎng)段的需求也不能妥協(xié)，能否有兼顧的解決辦法呢？登錄虛擬化的核心交換機(jī)并查看相關(guān)廠家文檔，研究后給出一種在防火墻存在狀態(tài)下不影響源端網(wǎng)段間互訪的策略路由寫法：

在原策略路由基礎(chǔ)上新增類Lan（到本地局域網(wǎng)網(wǎng)段的數(shù)據(jù)流），指定流行為L(zhǎng)anBehavior（采用流量過(guò)濾filter permit，而不是定義下一跳地址），然后在策略DianXinPre的首條增加Lan和LanBehavior的關(guān)聯(lián)。

#通過(guò)Acl匹配，新增本局域網(wǎng)網(wǎng)段間數(shù)據(jù)流的類

#對(duì)本局域網(wǎng)網(wǎng)段間的流量采用流量過(guò)濾，而不是定義下一跳地址

#在策略中首先匹配局域網(wǎng)內(nèi)數(shù)據(jù)流量

至此，故障完全解決。筆者在原來(lái)配置的基礎(chǔ)上加了特定局域網(wǎng)內(nèi)網(wǎng)段的數(shù)據(jù)包流量過(guò)濾的寫法。凡是目的為局域網(wǎng)內(nèi)部網(wǎng)段（ACL 3000匹配）的數(shù)據(jù)包，流行為是允許，并在策略的第一條不讓交換機(jī)給“扔”到上聯(lián)防火墻（或路由器）。H3C或華為設(shè)備的策略路由“流行為”，是對(duì)應(yīng)符合流分類的報(bào)文做出相應(yīng)的QoS動(dòng)作，例如流量監(jiān)管、流量過(guò)濾、流量重定向、重標(biāo)記、流量統(tǒng)計(jì)等。而平時(shí)，大家多用流量重定向（redirect nexthop IP），對(duì)流量過(guò)濾則很少使用，相關(guān)資料也很少提及，但這個(gè)功能是非常重要的。還有一點(diǎn)需要強(qiáng)調(diào)，在定義策略中為類指定采用的流行 為（classifier tcl-name behavior behavior-name）是從上向下匹配執(zhí)行的，上下順序也極為重要，不能顛倒。

經(jīng)驗(yàn)總結(jié)

1.數(shù)據(jù)包來(lái)回路徑不一致可以正常通信，不影響業(yè)務(wù)。但是中間有防火墻就會(huì)有例外就有可能會(huì)被阻攔（沒請(qǐng)求經(jīng)過(guò)而直接返回的連接會(huì)被攔截）。

2.策略路由寫法不全面不縝密，歸根結(jié)底是對(duì)策略路由技術(shù)理解的不夠到位不夠深刻。

出現(xiàn)問(wèn)題，要根據(jù)數(shù)據(jù)包流圖冷靜分析，不要被“原來(lái)‘一切’正?！?、“確定沒問(wèn)題”、“我驗(yàn)證過(guò)”所遮目，逐步分析每一個(gè)可能的故障點(diǎn)。以前一個(gè)小小的配置修改或者設(shè)備變動(dòng)就會(huì)為日后的故障埋下伏筆，特別是變更后問(wèn)題沒有及時(shí)發(fā)現(xiàn)，一段時(shí)間后才發(fā)現(xiàn)的故障，更難察覺。隨著信息化發(fā)展的規(guī)?；?、復(fù)雜化，只有不斷學(xué)習(xí)才能更好地適應(yīng)形勢(shì)發(fā)展要求。