操作系统：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没有回复：
15:20:34.665856 arp reply 192.168.1.247 is-at 00:15:17:f4:9a:e0
很显然只有eth0回复了，而eth1没有回复，这是怎么回事呢？查看当事机的路由，发现始终是：
192.168.1.0 * 255.255.255.0 eth0
192.168.1.0 * 255.255.255.0 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也可以路由：
192.168.1.0 * 255.255.255.0 eth1
可是却没有发送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'。
机器和网络配置：
测试机器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没有回复：
15:20:34.665856 arp reply 192.168.1.247 is-at 00:15:17:f4:9a:e0
很显然只有eth0回复了，而eth1没有回复，这是怎么回事呢？查看当事机的路由，发现始终是：
192.168.1.0 * 255.255.255.0 eth0
192.168.1.0 * 255.255.255.0 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也可以路由：
192.168.1.0 * 255.255.255.0 eth1
可是却没有发送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
