操作系统: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'。
除了这个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系统的配置策略不一致的问题。
机器和网络配置:
测试机器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系统的配置策略不一致的问题。