問題背景如下：

為建甌等地區用戶提供了全套網頁設計制作服務，及建甌網站建設行業解決方案。主營業務為做網站、成都網站設計、建甌網站設計，以傳統方式定制建設網站，并提供域名空間備案等一條龍服務，秉承以專業、用心的態度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

1,公司內網到某機房公網不通（ping，traceroute，curl都不行）

2,在某機房此公網的機器到公司內網也不通（ping，traceroute，curl都不行）

3,但是某機房此公網哪個的機器可以通過網關通外網，并且外網環境也能訪問某機房公網ip，只有公司內網到這些ip不同。

4,公司內網到其它幾個機房的公網都沒問題

公司內網到某機房公網不通的traceroute結果：

$ traceroute x.x.x.x
traceroute  to x.x.x.x (x.x.x.x), 30 hops max, 60 byte  packets
 1 * * *
 2 10.x.253.1  (10.x.253.1) 7.092 ms 7.388 ms 7.384 ms
 3  10.x.2.2 (10.x.2.2) 7.372 ms 7.615 ms 8.347  ms
 4 10.x.1.2 (10.x.1.2) 7.595 ms 8.335  ms 8.331 ms
 5  192.x.168.254  (192.x.168.254) 8.879 ms 9.325 ms 10.077  ms
 6 * * *
 ......

30 * * *

公司內網到其它機房公網正常的traceroute結果：

$ traceroute xx.xx.xx.xx
traceroute  toxx.xx.xx.xx (xx.xx.xx.xx), 30 hops max, 60 byte  packets
 1 * * *
 2 10.x.253.1  (10.x.253.1) 7.092 ms 7.388 ms 7.384 ms
 3  10.x.2.2 (10.x.2.2) 7.372 ms 7.615 ms 8.347  ms
 4 10.x.1.2 (10.x.1.2) 7.595 ms 8.335  ms 8.331 ms

 5  * * *

 6  111.111.111.111  (111.111.111.111) 8.879 ms 9.325 ms 10.077  ms
 7  * * *

 8 xx.xx.xx.xx

問題分析解決步驟：（發現這個問題之后，感覺和奇怪，雖然不影響服務，但是好奇心還是驅使著想把問題搞清楚）

一，分析了一下某機房機器的路由，都正常沒有發現異常

二，我測試了某機房和其它機房之間的網絡，外網到某機房的網絡都是正常的。第一個懷疑對象就是覺得公司內網有限制，因為看traceroute結果，數據包還沒有出公司內網。所以，就和公司IT部門排查了一番，發現并沒有任何限制

三，然后，懷疑公司機房是否有相關限制呢。所以，又找網絡組查了一番，結果仍然是沒有任何限制

四，排除外部因素之后，就懷疑可能是系統有問題了。并且，通過在某機房的外網機器上抓包能抓到公司內網送達的traceroute包，只是某機房的機器沒有回復數據包，那就更確定是系統本身的問題了。通過強大的google發現了rp_filter這個參數導致了這個問題，因為我們某機房機器此參數為1.

rp_filter參數的作用：

rp_filter - INTEGER
	0 - No source validation.
	1 - Strict mode as defined in RFC3704 Strict Reverse Path
	    Each incoming packet is tested against the FIB and if the interface
	    is not the best reverse path the packet check will fail.
	    By default failed packets are discarded.
	2 - Loose mode as defined in RFC3704 Loose Reverse Path
	    Each incoming packet's source address is also tested against the FIB
	    and if the source address is not reachable via any interface
	    the packet check will fail.

	Current recommended practice in RFC3704 is to enable strict mode
	to prevent IP spoofing from DDos attacks. If using asymmetric routing
	or other complicated routing, then loose mode is recommended.

	The max value from conf/{all,interface}/rp_filter is used
	when doing source validation on the {interface}.

	Default value is 0. Note that some distributions enable it
	in startup scripts.

置為1的作用為：數據包從哪個網口進來從哪個網口出去，如果不匹配 丟棄。

結論：

公司內網到某機房機器的request數據包從公網網卡進入，而reply的數據包根據機器的路由規則則從某機房機器的內網網卡流出。而某機房機器rp_filter為1,從而導致數據包被系統丟棄。而rp_filter這個參數默認是0,由于歷史原因被調整成了1,我們重新把管理的所有機器都調整為了默認值以解決類似問題。

另外有需要云服務器可以了解下創新互聯scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

文章名稱：rp_filter導致的網絡異常-創新互聯
當前路徑：http://vcdvsql.cn/article38/pgpsp.html

成都網站建設公司_創新互聯，為您提供網站維護、用戶體驗、關鍵詞優化、Google、品牌網站制作、移動網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯