現象：

[[email protected] ~]# ping -I 172.17.1.6 -c 10 172.17.1.48
PING 172.17.1.48 (172.17.1.48) from 172.17.1.6 : 56(84) bytes of data.

--- 172.17.1.48 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 19000ms

分析：

  抓包

[[email protected] ~]# tcpdump -vv -i eth0 dst host 172.17.1.6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:50:58.390250 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:50:59.390342 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:00.390283 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:02.390206 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:03.390285 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:04.390276 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:06.390214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:07.390277 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:08.390329 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
10:13:00.457215 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
 

接到icmp request，但是不傳送icmp reply

[[email protected] ~]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
172.17.1.106             ether   18:31:bf:09:1a:e5   C                     eth0
172.17.1.6                       (incomplete)                              eth0
 

問題所咋arp廣播時沒有返回網絡卡mac地址（如果防火牆做了相關ping禁止不影響arp響應）

解決：

  如果將網絡卡配置檔案中mac地址註釋掉，然後刪除70-persistent-net.rules檔案重啟呢？答案是不行

  在網上看到是反向路由檢查的問題

Linux核心有反向路由檢查的機制。當Linux IP協議棧收到一個IP包時，會找路由。
本機的包會往上層協議送，而非本機的包會根據路由轉發。

為了防止非法的包被轉發或送給上層協議，查詢路由後Linux還會呼叫fib_validate_source()以
檢查其來源的合法性，基本原理是根據包的源地址查詢路由的出介面，然後比較包的原始入介面是
否和查到的出介面一致;如果一致則放過，如果不一致查詢skb->dev的rp_filter值，為1時將丟棄這
個包，0時放過。

{ 例項
本網路有三臺機器，R1, R2 和PC，子網掩碼都是255.255.0.0。
R2 (10.1.0.2) ---- (10.1.0.1) R1 (10.3.0.1) ---- (10.3.0.2) PC
R2 (10.2.0.2) ---- (10.2.0.1) R1

注意，設定R2的預設路由為10.1.0.1
現在，從PC上能夠ping通10.1.0.2，但是ping不通10.2.0.2。
tcpdump顯示，R2接到icmp request，但是不傳送icmp reply。

PC
$ ip a
inet 10.3.0.2/16 brd 10.3.255.255 scope global eth0
$ ip r
10.3.0.0/16 dev eth0  proto kernel  scope link  src 10.3.0.2 
default via 10.3.0.1 dev eth0 

R1
$ ip a
inet 10.1.0.1/16 brd 10.1.255.255 scope global eth1
inet 10.2.0.1/16 brd 10.2.255.255 scope global eth2
inet 10.3.0.1/16 brd 10.3.255.255 scope global eth3
$ ip r
10.1.0.0/16 dev eth1  proto kernel  scope link  src 10.1.0.1 
10.2.0.0/16 dev eth2  proto kernel  scope link  src 10.2.0.1 
10.3.0.0/16 dev eth3  proto kernel  scope link  src 10.3.0.1 

R2
$ ip a
inet 10.1.0.2/16 brd 10.1.255.255 scope global eth1
inet 10.2.0.2/16 brd 10.2.255.255 scope global eth2

$ ip r
10.1.0.0/16 dev eth1  proto kernel  scope link  src 10.1.0.2
10.2.0.0/16 dev eth2  proto kernel  scope link  src 10.2.0.2 
default via 10.1.0.1 dev eth1 

假設R2的兩個介面分別為A(10.1.0.2)、B(10.2.0.2)。
從PC ping 10.2.0.2時，包的路徑是PC-->10.3.0.1-->10.2.0.2，
此時包的 ,
以進行反向路徑檢查, 得到輸出裝置是A，
因為目的地址是10.3.0.2，只能使用預設路由。A!=B，反向路徑檢查失敗，
丟棄該包！}

每個介面的rp_filter配置在

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter 

echo 0 > /proc/sys/net/ipv4/conf/ethN/rp_filter

其值為1時是使能該介面反向路由檢查機制，為0時則關閉該機制，或者
vim /etc/sysctl.conf
net.ipv4.conf.default.rp_filter = 0
禁用反向路徑檢查。

在實際運用時該機制可能會帶來問題。對於一些虛介面上來的包，如gre0,ipsec0來的包，如果沒有
IP地址，從該虛介面上來的包可能被認為來源不合法而被核心DROP。
這時需要根據實際情況設定rp_filter為0，並配置IP地址。

以上分析是根據2.6.32核心程式碼而來。
更高版本的kernel可能已經解決這個問題，如3.6.3核心，對該機制有改進，對IPSEC的介面不做反射路
由檢查。