rp_filter導致的網(wǎng)絡異常

問題背景如下：

1,公司內(nèi)網(wǎng)到某機房公網(wǎng)不通（ping，traceroute，curl都不行）

2,在某機房此公網(wǎng)的機器到公司內(nèi)網(wǎng)也不通（ping，traceroute，curl都不行）

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

4,公司內(nèi)網(wǎng)到其它幾個機房的公網(wǎng)都沒問題

公司內(nèi)網(wǎng)到某機房公網(wǎng)不通的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  * * *

公司內(nèi)網(wǎng)到其它機房公網(wǎng)正常的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

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

一，分析了一下某機房機器的路由，都正常沒有發(fā)現(xiàn)異常

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

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

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

rp_filter參數(shù)的作用：

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的作用為：數(shù)據(jù)包從哪個網(wǎng)口進來從哪個網(wǎng)口出去，如果不匹配 丟棄。

結論：

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