arp_ignore背後的rp_filter與arp_filter

作業系統：Debian 3

機器和網絡配置：

測試機器eth0：

inet addr:192.168.1.82

當事機配置：

eth0：

inet addr:192.168.1.247/HWaddr 00:15:17:F4:9A:E0 

eth1：

inet addr:192.168.1.246/HWaddr 00:15:17:F4:9A:E1

eth0和eth1插于同一台交換機上，配置同一網段ip，路由如下：

192.168.1.0 * 255.255.255.0 eth0

192.168.1.0 * 255.255.255.0 eth1

測試過程：

1.将當事機的核心參數net.ipv4.conf.XXX.arp_ignore設定為0

2.清除測試機的arp緩存

3.在測試機上ping當事機的eth0或者eth1

期望結果：

既然arp_ignore設定成了0，那麼如果在測試機上抓取arp的回複包的話，應該有兩條回複，分别來自當事機的eth0和eth1：

15:20:34.665840 arp reply 192.168.1.247 is-at 00:15:17:f4:9a:e1

15:20:34.665856 arp reply 192.168.1.247 is-at 00:15:17:f4:9a:e0

然後測試機取晚到的那一個作為自己的arp緩存項。可是隻抓取到了一個arp回複包，并且在當事機的eth1上抓取arp請求包，已經抓到了，隻是eth1沒有回複：

很顯然隻有eth0回複了，而eth1沒有回複，這是怎麼回事呢？檢視當事機的路由，發現始終是：

...

即使将eth1 down掉然後再起來路由也依然如此，并沒有交換位置，而arp回複的恰恰就是eth0的mac位址，直覺感覺和路由有關系，再看arp處理的源代碼，發現核心功能全在arp_process，而最最核心的莫非下面的小段：

if (arp->ar_op == htons(ARPOP_REQUEST) && [0]ip_route_input(skb, tip, sip, 0, dev) == 0) {

    rt = (struct rtable*)skb->dst;

    addr_type = rt->rt_type;

    if (addr_type == RTN_LOCAL) { //查找本機的ip位址對應的mac，路由結果必然是local的

        n = neigh_event_ns(&arp_tbl, sha, &sip, dev);

        if (n) {

            int dont_send = 0;

            if (!dont_send) //ignore判斷，太熟悉了，略過

                [2]dont_send |= arp_ignore(in_dev,dev,sip,tip);

            [1]if (!dont_send && IN_DEV_ARPFILTER(in_dev)) //filter判斷，本質上也是在確定arp回複包路由結果的出口裝置和arp請求的入口裝置相一緻

                dont_send |= arp_filter(sip,tip,dev); 

            if (!dont_send)

                arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha);

            neigh_release(n);

可見影響arp回複的是上述的[0]，[1]和[2]，而不僅僅是[2]，是以肯定是[0]或者[1]中使得arp回複沒能發送，先看[0]，那就是一個路由選擇，注意，一般情況下，路由選擇僅僅根據目的ip位址進行查找，一般不管出入口裝置資訊的，是以，根據當事機上的路由表情況，如果發現要有包去往192.168.1.0/24網段，那麼肯定會選擇第一個找到的路由，就是eth0出口的路由，在ip_route_input的内部如果路由的結果是本機的話(對于一般的arp請求，這是肯定的)，那麼會調用fib_validate_source(細節在rfc1812)：

if (res.type == RTN_LOCAL) {

    int result;

    result = fib_validate_source(saddr, daddr, tos,

                loopback_dev.ifindex,

                dev, &spec_dst, &itag);

正是這個fib_validate_source使得本來能成功的路由查找失敗了：

int fib_validate_source(...)

{

    struct in_device *in_dev;

    //将目的位址和源位址反轉，驗證如此的路由出口是否和正方向的入口一緻。比如如果一個包的源位址是s1，目的位址是d1，從e1進入，那麼在開啟源驗證的情況下，源為d1，目的為s1的路由出口必須是e1，正所謂從哪裡進入，從哪裡出去

    struct flowi fl = { .nl_u = { .ip4_u =

                      { .daddr = src,

                    .saddr = dst,

                    .tos = tos } },

                .iif = oif };

    ...

    in_dev = __in_dev_get(dev);

    if (in_dev) {

        no_addr = in_dev->ifa_list == NULL;

        rpf = IN_DEV_RPFILTER(in_dev); //是否啟用源位址驗證，這是通過核心參數net.ipv4.conf.eth0.rp_filter的值來決定的

    }

    if (fib_lookup(&fl, &res))

        goto last_resort;

    if (FIB_RES_DEV(res) == dev)

    {

        //...如果反方向向的路由出口裝置和正方向的入口裝置一緻，那麼不會有問題，也是期望的

        return ret;

    if (rpf) //如果開啟了源位址驗證，而反方向的出口又和正方向的入口不一緻，那麼出錯！

        goto e_inval;

}

現在由于eth1已經抓到了arp請求包，并且ip_route_input也可以路由：

可是卻沒有發送arp回複，根據上面的理論分析看一下net.ipv4.conf.eth0.rp_filter這個值，果然在當事機上該值為1，很顯然是在fib_validate_source失敗了，現在将其改為0，再次進行上述測試，和期望的一樣，得到了兩條arp回複，核心文檔Documentation/networking/ip-sysctl.txt中有rp_filter的條目，其最後：

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

是以我們知道，Debian 3就是這裡的one of 'some distributions'。

     除了這個rp_filter之外，另一個影響arp回複的就是arp_filter，net.ipv4.conf.XXX.arp_filter這個值得預設值是0，也就是不做檢查，如果将之設定成1，即使rp_filter為0(停用源位址驗證)，arp回複也是不會發送的，看arp_filter的代碼，發現其和fib_validate_source的實作很類似，隻是簡單很多。既然rp_filter已經能搞定出口入口相一緻的問題，為何要在arp子產品中再次存在arp_filter呢？這是一個層次的問題，rp_filter是對整個路由系統起作用的，而arp_filter僅僅針對arp系統，二者的共存旨在解決路由系統和arp系統的配置政策不一緻的問題。

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1271138