| Message ID | 200907010154.27457.denys@visp.net.lb |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Wednesday 01 July 2009 01:55:59 Eric W. Biederman wrote: >> >> I have a problem with this patch. It stops gratuitous arps updating >> my arp cache. I'm still trying to figure out what the correct behaviour >> should be. >> >> Perhaps making the goto out; become if (sip == 0) goto out; > Yes, you are right. > > Proposing 3 simple patches against git next-next-2.6 . As attaches (sorry, > kmail). All of them equal, but since i am amateur in programming, i dont know > how it is should be done "nice way". > > If you want to test it - do it carefully. I didn't did runtime tests yet, but > they are compile tested. (But they are trivial). > > If someone can review and tell if any of them ok, i will submit it with proper > tags and etc. What problem were you originally trying to solve? Having a proxy arp gateway reply to addresses it routes is proper behaviour. There are some aspects of RFC 5227 ipv4 address conflict detection that we could implement in a better fashion. In particular the entirety of handling the pathological case of someone using one of our ip addresses in an arp message and replying to them to defend ourselves. Your changes seem aimed at having the linux kernel not reply to gratuitous arps, when according to our configuration the sender is misconfigured. You seem to want linux not to defend itself in cases where it should. Making us even less compliant with RFC 5227. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 01 July 2009 09:58:36 Eric W. Biederman wrote: > > What problem were you originally trying to solve? > > Having a proxy arp gateway reply to addresses it routes is proper > behaviour. > > There are some aspects of RFC 5227 ipv4 address conflict detection that > we could implement in a better fashion. In particular the entirety > of handling the pathological case of someone using one of our ip > addresses in an arp message and replying to them to defend ourselves. > > Your changes seem aimed at having the linux kernel not reply to > gratuitous arps, when according to our configuration the sender is > misconfigured. You seem to want linux not to defend itself in cases > where it should. Making us even less compliant with RFC 5227. > > Eric It is still answering to gratuitous arp and handling the case!!! But why patch was created, to NOT reply in case we have proxy_arp set, and we have default gateway. In this case, for example, Windows XP wont work at all in network where is Linux host with proxy_arp=1 installed. Because Linux will ALWAYS answer to arp requests. Just only one case i miss (which is not defined in RFC by the way), that some software use this packet to update ARP tables on other hosts. And i sent patches for that. But imho they should use more legitimate ARP packets for that. I did real testing even for my patch, and sure i sent patch only after that. ip addr ..... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:1e:8c:89:78:af brd ff:ff:ff:ff:ff:ff inet 10.0.1.21/29 brd 10.0.1.23 scope global eth0 I run windows vista (it sets correctly sip as 0.0.0.0) home ipv4 # tcpdump -ni eth0 11:48:11.416790 ARP, Request who-has 10.0.1.21 tell 0.0.0.0, length 46 11:48:11.416797 ARP, Reply 10.0.1.21 is-at 00:1e:8c:89:78:af, length 28 2.6.30 vanilla (sure patch is there) handling case correctly. The case i was trying to handle - proxy arp. Windows XP will be permanently disabled on reboot in case of proxy_arp enabled on Linux machine, and this Linux have default gateway (means answer to all proxy_arp). This is XP (no conflict) 11:51:28.297633 ARP, Request who-has 10.0.0.5 tell 10.0.0.5, length 46 11:51:29.283672 ARP, Request who-has 10.0.0.5 tell 10.0.0.5, length 46 11:51:30.284210 ARP, Request who-has 10.0.0.5 tell 10.0.0.5, length 46 This is Linux 2.6.30 with patch applied, and Windows XP, handling correctly IP conflict. 11:53:10.440541 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46 11:53:10.440551 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28 11:53:10.440796 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46 11:53:10.440799 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28 11:53:10.466743 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46 11:53:10.466752 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28 11:53:10.466976 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46 11:53:10.466979 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28 So WITH patch ip conflict detection working. And for sure it will work: <------>if (sip == 0 || tip == sip) { // Yes, sip == tip <------><------>if (arp->ar_op == htons(ARPOP_REQUEST) && // Yes it is request <------><------> inet_addr_type(net, tip) == RTN_LOCAL && // Yes this ip i have on my own host <------><------> !arp_ignore(in_dev, sip, tip)) // No i won't ignore this <------><------><------>arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha, <------><------><------><------> dev->dev_addr, sha); // Send the host who sent gratuitous ip - that i am using it already. <------><------>goto out; <------>} -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 01 July 2009 09:58:36 Eric W. Biederman wrote: > > What problem were you originally trying to solve? > > Having a proxy arp gateway reply to addresses it routes is proper > behaviour. It is not correct behavior to reply to gratuitous ARP, if you dont have this IP locally! IP conflict detection will fail then completely, if proxy arp machine have default route (means answer to ALL ARP requests). Sadly RFC 1027 (Proxy ARP) dated in 1987 and not explaining this case well. I found other source of information, it is not reliable (wikipedia), but it is also mentioned in one of HP patents (http://www.freepatentsonline.com/y2009/0073990.html). My point of view marked as (!!!!!!!). ARP announcements An ARP announcement (also known as Gratuitous ARP) is a packet containing valid sender hardware and protocol addresses (SHA and SPA) for the host that sent it, with identical destination and source addresses (TPA = SPA). Such a request (!!!!!!!) is not intended to solicit a reply, but merely updates the ARP caches of other hosts that receive the packet. Gratuitous ARP is usually an ARP request [3], but it may also be an ARP reply [4]. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Wednesday 01 July 2009 09:58:36 Eric W. Biederman wrote: >> >> What problem were you originally trying to solve? >> >> Having a proxy arp gateway reply to addresses it routes is proper >> behaviour. > It is not correct behavior to reply to gratuitous ARP, if you dont have this > IP locally! > > IP conflict detection will fail then completely, if proxy arp machine have > default route (means answer to ALL ARP requests). With proxy arp you pretend to have all of the IPs you are proxing for locally. You must do everything that the machine you are proxying for would do on that network. Having a default route and proxying everything is a misconfiguration. > Sadly RFC 1027 (Proxy ARP) dated in 1987 and not explaining this case well. > I found other source of information, it is not reliable (wikipedia), but it is > also mentioned in one of HP patents > (http://www.freepatentsonline.com/y2009/0073990.html). My point of view > marked as (!!!!!!!). > > ARP announcements > > An ARP announcement (also known as Gratuitous ARP) is a packet containing > valid sender hardware and protocol addresses (SHA and SPA) for the host that > sent it, with identical destination and source addresses (TPA = SPA). Such a > request (!!!!!!!) is not intended to solicit a reply, but merely updates the > ARP caches of other hosts that receive the packet. Gratuitous ARP is usually > an ARP request [3], but it may also be an ARP reply [4]. Of course a Gratuitous ARP is not intended to solicit a reply. Because two machines should not be configured to have the same IP address. In the case of two machines being configured with the same IP address replying to gratuitous ARP is correct behaviour. As it allows discovery of the network misconfiguration. The problem is that you have a proxy machine configured to proxy for the ip that is also assigned to another machine in the same broadcast domain. That is a bug. The only case where I can imagine proxying the default route would even approach being correct is on a point to point link. But that seems pointless as you could simply have a default route to the other side. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote: > > Of course a Gratuitous ARP is not intended to solicit a reply. Because > two machines should not be configured to have the same IP address. > > In the case of two machines being configured with the same IP address > replying to gratuitous ARP is correct behaviour. As it allows discovery > of the network misconfiguration. Yes, and it is doing that with my patch also. It is answering if there is same _local address_, so it is definitely ip conflict. But Proxy ARP answering to ARP Announce without checking if destination address taken - wrong. Because it should check if host in destination (proxied) network really is taken and should not answer if it is not. > > The problem is that you have a proxy machine configured to proxy for > the ip that is also assigned to another machine in the same broadcast > domain. That is a bug. Where it is defined as bug? Sometimes it can be used on purpose, to filter traffic in local segment with lot of unmanaged switches. > > The only case where I can imagine proxying the default route would even > approach being correct is on a point to point link. But that seems > pointless as you could simply have a default route to the other side. Examples just came in mind: 1)Mobile IP. 2)Port isolated setup, available on some switches and on wireless access points, when hosts cannot talk one to each other via broadcast domain, only via gateway. In this case gateway must give reply to legitimate arp requests, but ignore arp announce(gratuitous ARP). I will search more respectable sources of information for this case. Btw it is difficult to find out this days "generic" gateway host without default gateway :-) And last case, it breaks things for high availability ONLY because it doesn't update neighbor table. That can be fixed easily and i sent patches for that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote: > The only case where I can imagine proxying the default route would even > approach being correct is on a point to point link. But that seems > pointless as you could simply have a default route to the other side. > > Eric It seems Linux proxy_arp behavior is also RFC 1027 non-conformant. Quote from RFC: In 4.3BSD (and probably in other operating systems), a default route is possible. This default route specifies an address to forward a ! packet to when no other route is found. The default route must not ! be used when checking for a route to the target host of an ARP ! request. If the default route were used, the check would always succeed. But the host specified by the default route is unlikely to know about subnet routing (since it is usually an Internet gateway), and thus packets sent to it will probably be lost. This special case in the routing lookup method is the only implementation change needed to the routing mechanism. If i have linux host with eth0 10.0.0.1/24 eth1 10.0.1.1/24 sysctl -w net.ipv4.conf.eth1.proxy_arp=1 from other host in same ethernet segment eth1 Xpernet_137 ~ # arping -I eth1 2.4.6.8 ARPING to 2.4.6.8 from 1.0.0.1 via eth1 Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 501.685ms Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 0.198ms And RFC define to not do that (use default route for proxy_arp). -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote: >> The only case where I can imagine proxying the default route would even >> approach being correct is on a point to point link. But that seems >> pointless as you could simply have a default route to the other side. >> >> Eric > > It seems Linux proxy_arp behavior is also RFC 1027 non-conformant. > > Quote from RFC: > > In 4.3BSD (and probably in other operating systems), a default route > is possible. This default route specifies an address to forward a > ! packet to when no other route is found. The default route must not > ! be used when checking for a route to the target host of an ARP > ! request. If the default route were used, the check would always > succeed. But the host specified by the default route is unlikely to > know about subnet routing (since it is usually an Internet gateway), > and thus packets sent to it will probably be lost. This special > case in the routing lookup method is the only implementation change > needed to the routing mechanism. > > > > If i have linux host with > eth0 10.0.0.1/24 > eth1 10.0.1.1/24 > > sysctl -w net.ipv4.conf.eth1.proxy_arp=1 > > from other host in same ethernet segment eth1 > > Xpernet_137 ~ # arping -I eth1 2.4.6.8 > ARPING to 2.4.6.8 from 1.0.0.1 via eth1 > Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 501.685ms > Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 0.198ms > > And RFC define to not do that (use default route for proxy_arp). We agree that proxy_arp for the default route is problem behavior. The question is can you configure proxy_arp to not do that in your configuration? There is the medium_id tunable and the per interface proxy_arp tunable. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote: >> The only case where I can imagine proxying the default route would even >> approach being correct is on a point to point link. But that seems >> pointless as you could simply have a default route to the other side. >> >> Eric > > It seems Linux proxy_arp behavior is also RFC 1027 non-conformant. > > Quote from RFC: > > In 4.3BSD (and probably in other operating systems), a default route > is possible. This default route specifies an address to forward a > ! packet to when no other route is found. The default route must not > ! be used when checking for a route to the target host of an ARP > ! request. If the default route were used, the check would always > succeed. But the host specified by the default route is unlikely to > know about subnet routing (since it is usually an Internet gateway), > and thus packets sent to it will probably be lost. This special > case in the routing lookup method is the only implementation change > needed to the routing mechanism. > > > > If i have linux host with > eth0 10.0.0.1/24 > eth1 10.0.1.1/24 > > sysctl -w net.ipv4.conf.eth1.proxy_arp=1 > > from other host in same ethernet segment eth1 > > Xpernet_137 ~ # arping -I eth1 2.4.6.8 > ARPING to 2.4.6.8 from 1.0.0.1 via eth1 > Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 501.685ms > Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 0.198ms > > And RFC define to not do that (use default route for proxy_arp). I just looked at the kernel code in a bit more detail as well as some examples. With routing properly setup it appears largely fool proof. The relevant piece in arp_process appears to be: if (addr_type == RTN_UNICAST && rt->u.dst.dev != dev && Which says if when we consult the routing tables we would route the packet out an interface that it did not come in by do the whole proxy arp thing. Which says to me you do not have a route to the machine which is getting a address conflict on the network segment on which it is located. In summary the evidence I have suggests your routing is misconfigured. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 02 July 2009 23:51:29 Eric W. Biederman wrote: > > I just looked at the kernel code in a bit more detail as well as some > examples. With routing properly setup it appears largely fool proof. > The relevant piece in arp_process appears to be: > > if (addr_type == RTN_UNICAST && rt->u.dst.dev != dev && > > Which says if when we consult the routing tables we would route the > packet out an interface that it did not come in by do the whole > proxy arp thing. > > Which says to me you do not have a route to the machine which > is getting a address conflict on the network segment on which it > is located. > > In summary the evidence I have suggests your routing is misconfigured. > > Eric It just have default route. Using it in proxy_arp clearly VIOLATE RFC! I did small simulated setup. Example: default via 10.0.1.1 dev eth1 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2 10.0.1.0/24 dev eth1 proto kernel scope link src 10.0.1.2 eth0 attached to my tap0 defaulthost ~ # sysctl -w net.ipv4.conf.eth0.proxy_arp=1 net.ipv4.conf.eth0.proxy_arp = 1 Testing home ~ # arping -I tap0 10.0.1.6 ARPING 10.0.1.6 from 10.0.0.1 tap0 Unicast reply from 10.0.1.6 [52:54:00:12:34:56] 85.706ms Unicast reply from 10.0.1.6 [52:54:00:12:34:56] 0.683ms ^CSent 2 probes (1 broadcast(s)) Received 2 response(s) !!! Correct. Thats why i need proxy_arp, i can reach hosts in eth1 home ~ # arping -I tap0 5.6.7.8 ARPING 5.6.7.8 from 10.0.0.1 tap0 Unicast reply from 5.6.7.8 [52:54:00:12:34:56] 353.697ms Unicast reply from 5.6.7.8 [52:54:00:12:34:56] 0.740ms Unicast reply from 5.6.7.8 [52:54:00:12:34:56] 0.697ms ^CSent 3 probes (1 broadcast(s)) Received 3 response(s) !!! Not correct. It uses default route as reference "where i can route", which violates RFC. Laptop with ip 5.6.7.8 (have nothing to do to with this router) with Windows XP will not be able to work. He will get ip conflict. Network , for example, is on unmanaged switches, so i cannot isolate it from this router. If i do: defaulthost ~ # sysctl -w net.ipv4.conf.eth1.medium_id=2 net.ipv4.conf.eth1.medium_id = 2 defaulthost ~ # sysctl -w net.ipv4.conf.eth0.medium_id=2 net.ipv4.conf.eth0.medium_id = 2 home ~ # arping -I tap0 5.6.7.8 ARPING 5.6.7.8 from 10.0.0.1 tap0 ^CSent 3 probes (3 broadcast(s)) Received 0 response(s) Correct. Laptop will not get ip conflict home ~ # arping -I tap0 10.0.1.6 ARPING 10.0.1.6 from 10.0.0.1 tap0 ^CSent 3 probes (3 broadcast(s)) Received 0 response(s) Not correct. Oops, i cannot talk with 10.0.1.6 anymore, and proxy_arp supposed to help me with this. If i set different medium id - it will be same as default, 0. Any ideas how medium_id will help here? So once more again, i dont mind proxy_arp main purprose to help devices to communicate in different physical networks. But if it gives answers to ARP announce it is WRONG. Because ARP answer for ARP announce(gratitous), it should only answer if it really knows about ip conflict. In current setup - if it have ip on this machine. ARP announce main puprose to update ARP cache AND to check for possible IP conflicts. proxy_arp current behavior will just screw this idea even without default issue. If i have two networks proxy arp'ed 10.0.0.0/24 physical segment 10.0.1.0/24 physical segment proxy_arp host between them, so users can set on their laptops /22 and communicate freely like they are in one segment. Some user with XP on laptop with ip 10.0.0.66/22 will come to 10.0.1.0/24 physical segment. As second he will turn on his laptop - proxy_arp host will give him incorrect answer to his ARP announce "10.0.0.66 (ff:ff:ff:ff:ff:ff) tell 10.0.0.66", it will tell "Reply 10.0.0.66 is-at 52:54:00:12:34:56" - that IP is busy. And thats wrong. arp_proxy should help hosts to communicate, but should not give incorrect answers that ip is taken. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > If i have two networks proxy arp'ed > 10.0.0.0/24 physical segment > 10.0.1.0/24 physical segment > > proxy_arp host between them, so users can set on their laptops /22 and > communicate freely like they are in one segment. > > Some user with XP on laptop with ip 10.0.0.66/22 will come to 10.0.1.0/24 > physical segment. As second he will turn on his laptop - proxy_arp host will > give him incorrect answer to his ARP announce "10.0.0.66 (ff:ff:ff:ff:ff:ff) > tell 10.0.0.66", it will tell "Reply 10.0.0.66 is-at 52:54:00:12:34:56" - > that IP is busy. And thats wrong. arp_proxy should help hosts to communicate, > but should not give incorrect answers that ip is taken. The problem is you have machines on the wrong subnet. If you are not enforcing which network your laptops are in you want ethernet bridging not proxy_arp. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 03 July 2009 01:18:33 Eric W. Biederman wrote: > > The problem is you have machines on the wrong subnet. > > If you are not enforcing which network your laptops are in you > want ethernet bridging not proxy_arp. > > Eric > More important - feature must work CORRECTLY. Sometimes bridge is not fitting all needs. Probably behavior of well known networking vendor will be respected. Here is example tested on Cisco IOS ( Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(4)T1, RELEASE SOFTWARE (fc4)) interface FastEthernet1/0 ip address 10.0.1.2 255.255.255.0 duplex half ! interface FastEthernet2/0 ip address 10.0.2.2 255.255.255.0 duplex half ! ip default-gateway 10.0.2.1 fa 1/0 - tap0 fa 2/0 - tap1 home ~ # arping -I tap0 10.0.1.5 ARPING 10.0.1.5 from 10.0.1.21 tap0 ^CSent 3 probes (3 broadcast(s)) Received 0 response(s) home ~ # arping -I tap0 10.0.2.5 ARPING 10.0.2.5 from 10.0.1.21 tap0 Unicast reply from 10.0.2.5 [CA:00:0A:FC:00:1C] 6.477ms Unicast reply from 10.0.2.5 [CA:00:0A:FC:00:1C] 5.520ms Unicast reply from 10.0.2.5 [CA:00:0A:FC:00:1C] 4.842ms ^CSent 3 probes (1 broadcast(s)) Received 3 response(s) home ~ # arping -I tap0 4.5.6.7 ARPING 4.5.6.7 from 10.0.1.21 tap0 ^CSent 4 probes (4 broadcast(s)) Received 0 response(s) home ~ # ip addr add dev tap0 10.0.2.5 home ~ # arping -I tap0 10.0.2.5 ARPING 10.0.2.5 from 10.0.2.5 tap0 home ~ # tcpdump -ni tap0 -s 1500 -vvv tcpdump: WARNING: tap0: no IPv4 address assigned tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 1500 bytes 01:46:21.404454 01:46:31.404566 01:46:35.756623 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 (ff:ff:ff:ff:ff:ff) tell 10.0.2.5, length 28 01:46:36.756740 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 (ff:ff:ff:ff:ff:ff) tell 10.0.2.5, length 28 01:46:37.756821 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 (ff:ff:ff:ff:ff:ff) tell 10.0.2.5, length 28 they dont answer btw also for ip's who is not in their network, but this doesn't matter, not defined in RFC, but good manner. Also it make impossible situation with ARP announce answered by Cisco and will not make false positive IP conflict detection on Windows. home ~ # tcpdump -ni tap0 -s 1500 -vvv tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 1500 bytes 01:47:17.754393 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 (ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28 01:47:18.754581 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 (ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28 01:47:19.754628 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 (ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28 01:47:20.754674 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 (ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28 This is default behaviour,i just did 6 commands, no shutdown for interfaces, assign ip's, default gw and enable proxy arp on interfaces(btw seems they are enabled by default!), and it is CORRECT. Conclusion: 1)Do not use default gateway for proxy-arp 2)Do not answer for ip's who doesn't belong to this interface (at least) If i will put in network Linux machine, set default gw on other interface, and set proxy_arp - it will screw up whole network giving arp reply to all arp requests. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 03 July 2009 01:18:33 Eric W. Biederman wrote: and few more details if i set "ip local-proxy-arp" on Fa 1/0 it still respects ARP Announce (as mypatch was doing, but mistake in patch it was not updating ARP cache) home ~ # tcpdump -ni tap0 -vvv -s 1500 tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 1500 bytes 02:11:15.520588 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.8 (ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28 02:11:15.523696 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.1.8 is-at ca:00:0a:fc:00:1c, length 46 02:11:16.520616 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.8 (ca:00:0a:fc:00:1c) tell 10.0.1.3, length 28 02:11:16.523365 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.1.8 is-at ca:00:0a:fc:00:1c, length 46 02:11:17.520635 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.8 (ca:00:0a:fc:00:1c) tell 10.0.1.3, length 28 02:11:17.525146 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.1.8 is-at ca:00:0a:fc:00:1c, length 46 02:11:18.648310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.3 (ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28 02:11:19.648364 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.3 (ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28 02:11:20.648421 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.3 (ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What IOS is irrelevant to this discussion. Especially when I don't see the "ip proxy-arp" command. Having two networks: 10.0.0.0/24 physical segment 10.0.1.0/24 physical segment It is correct for proxy arp to answer to for 10.0.0.66 when it is plugged into the 10.0.1.0/24 network. Because in that case 10.0.0.66 is on the wrong subnet, and your network is misconfigured. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 03 July 2009 02:23:09 Eric W. Biederman wrote: > What IOS is irrelevant to this discussion. Directly relevant, Cisco usually following standards very well. > Especially when I don't see the "ip proxy-arp" command. From Cisco IOS manual: ip proxy-arp .... Defaults Enabled It will show in config only "no ip proxy arp" For example show running .... interface FastEthernet2/0 ip address 10.0.2.2 255.255.255.0 duplex half .... Router(config)#inter FastEthernet 2/0 Router(config-if)#no ip proxy-arp show running .... interface FastEthernet2/0 ip address 10.0.2.2 255.255.255.0 no ip proxy-arp duplex half .... > > Having two networks: > 10.0.0.0/24 physical segment > 10.0.1.0/24 physical segment > > It is correct for proxy arp to answer to for 10.0.0.66 > when it is plugged into the 10.0.1.0/24 network. It is not defined in standart, correct or not. > > Because in that case 10.0.0.66 is on the wrong subnet, and your > network is misconfigured. What Linux does care about this? It is not police inspector to block me from taking this ip in wrong subnet. And without emotions - it is not his job to give answers for wrong request (ARP Announce), from wrong ip (not linux with proxy arp enabled interface subnet). Especially because there is no use for current behavior, other than making problems. And most important what you are telling violates RFC again, i finally found this in RFC 1027: ..."The gateway is acting as an agent for host B, which is why this technique is called "Proxy ARP"; we will refer to this as a transparent subnet gateway or ARP subnet gateway. "... " An ARP subnet gateway implementation must not reply if the physical networks of the source and target of an ARP request are the same. In this case, either the target host is presumably either on the same physical network as the source host and can answer for itself, or the target host lies in the same direction from the gateway as does the source host, and an ARP reply from the would cause a loop. " Also not very clear, but maybe it is a reason why Cisco doesn't answer to ip who is not reachable from this interface " If the IP networks of the source and target hosts of an ARP request are different, an ARP subnet gateway implementation should not reply. This is to prevent the ARP subnet gateway from being used to reach foreign IP networks and thus possibly bypass security checks provided by IP gateways. " > > Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Denys Fedoryschenko <denys@visp.net.lb> Date: Fri, 3 Jul 2009 02:03:08 +0300 > Probably behavior of well known networking vendor will be respected. "cisco does it this way" used as the argument for how Linux should behave will generally be treated as no argumentat all. You have to give real technical reasons and so far Eric is the only person providing that successfully. Everything I've seen you argue so far is pure vapor. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Denys Fedoryschenko <denys@visp.net.lb> Date: Fri, 3 Jul 2009 02:46:17 +0300 > On Friday 03 July 2009 02:23:09 Eric W. Biederman wrote: >> What IOS is irrelevant to this discussion. > Directly relevant, Cisco usually following standards very well. No, IT IS TOTALLY FREAKIN IRRELEVANT! And if you don't understand that GO AWAY NOW. If you, on the other hand, give a coherent and reasonable explanation _WHY_ a certain behavior should be followed, that is convincing. And this is regardless of what Cisco does one way or the other. Just like us, Cisco does stupid misguided shit too. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: >> Having two networks: >> 10.0.0.0/24 physical segment >> 10.0.1.0/24 physical segment >> >> It is correct for proxy arp to answer to for 10.0.0.66 >> when it is plugged into the 10.0.1.0/24 network. > It is not defined in standart, correct or not. > >> >> Because in that case 10.0.0.66 is on the wrong subnet, and your >> network is misconfigured. > What Linux does care about this? > It is not police inspector to block me from taking this ip in wrong subnet. > > And without emotions - it is not his job to give answers for wrong request > (ARP Announce), from wrong ip (not linux with proxy arp enabled interface > subnet). Especially because there is no use for current behavior, other than > making problems. There is use. Talking to the machine that is known as 10.0.0.66 when it is plugged into the network it is configured to be on. > And most important what you are telling violates RFC again, i finally found > this in RFC 1027: > > ..."The gateway > is acting as an agent for host B, which is why this technique is > called "Proxy ARP"; we will refer to this as a transparent subnet > gateway or ARP subnet gateway. > "... > > " An ARP subnet gateway implementation must not reply if the physical > networks of the source and target of an ARP request are the same. > In this case, either the target host is presumably either on the > same physical network as the source host and can answer for itself, > or the target host lies in the same direction from the gateway as > does the source host, and an ARP reply from the would cause a loop. > " This is comedy. They are supposed to be on different physical networks as far as linux is configured. The fact the laptop is in the wrong place is something else again. As for the rest. I am not a great expert on how Cisco configuration works. In your example I believe you did not place the ports on different vlans. If both networks are run in the same vlan and the packets will be bridged and everything will work smoothly. Except when you explicitly configure it. Linux does not do anything layer 2. So by default when we have two interfaces coming into a linux box we do not bridge them. Is this perhaps where you are confused? Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 03 July 2009 06:14:44 Eric W. Biederman wrote: Actually problem doesn't worth a broken egg even. I am not confused. Just i am trying to explain that some feature implementation must follow standards somehow, especially because it break things. And it breaks. Actual use for proxy_arp in modern world is very small, and i think it is used rarely, only for PPP links for remote customers. But even in this case it will break things, if this box have default gateway. 1)If Linux have default gateway configured "some other" interface, enabling proxy_arp on ethernet interface will break communication for any network that is not configured on this Linux interface. It will just give ARP reply for all ARP requests. 2)ACD (Address conflict detection) used in DHCP, Mobile IP and etc, and it uses gratituous ARP/ARP Announce. Proxy ARP used to help route networks. Gratituous ARP/ARP Announce packet have no use for routing, it is for ACD and ARP cache updating (for clusters). Linux ARP proxy gives answer to such packets, which doesn't have use for routing, but breaks ACD (gives false positive ip conflict). Anyway, i ask advice from one of RFC authors. I will forward it here as soon as receive it. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Denys Fedoryschenko <denys@visp.net.lb> Date: Fri, 3 Jul 2009 14:02:34 +0300 > Anyway, i ask advice from one of RFC authors. I will forward it here > as soon as receive it. Regardless of what this person says, I must bring up the most important issue. If we change this behvaior we have now, which has been present for more than 10 years, we will break someone's setup potentially and that must be considered strongly against all the other arguments. I really never should have applied your initial patch, I severely regret it. Thanksfully it's reverted now and we can look into this issue more properly. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 03 July 2009 23:20:05 David Miller wrote: > I really never should have applied your initial patch, I severely > regret it. Thanksfully it's reverted now and we can look into > this issue more properly. If it was said before... Then maybe i will try to do some new sysctl value? By default it will be old behavior, but it can be changed to new on user choice. Let's say net.ipv4.arp_proxy_gateway net.ipv4.arp_proxy_gratuitous -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Friday 03 July 2009 23:20:05 David Miller wrote: > >> I really never should have applied your initial patch, I severely >> regret it. Thanksfully it's reverted now and we can look into >> this issue more properly. > If it was said before... > > Then maybe i will try to do some new sysctl value? > > By default it will be old behavior, but it can be changed to new on user > choice. > > Let's say > > net.ipv4.arp_proxy_gateway > net.ipv4.arp_proxy_gratuitous How do machines with addresses without routes to them get packets from machines in other subnets? Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 04 July 2009 03:46:15 Eric W. Biederman wrote: > Denys Fedoryschenko <denys@visp.net.lb> writes: > > On Friday 03 July 2009 23:20:05 David Miller wrote: > >> I really never should have applied your initial patch, I severely > >> regret it. Thanksfully it's reverted now and we can look into > >> this issue more properly. > > > > If it was said before... > > > > Then maybe i will try to do some new sysctl value? > > > > By default it will be old behavior, but it can be changed to new on user > > choice. > > > > Let's say > > > > net.ipv4.arp_proxy_gateway > > net.ipv4.arp_proxy_gratuitous > > How do machines with addresses without routes to them > get packets from machines in other subnets? > > Eric ARP proxy generally was supposed to not export default route(by RFC and by logic) it should be maybe other name, arp_proxy_no_default_gateway_export - but i guess it is too long. With exporting default gateway i have two choices - eat it and have answer to almost any ARP request, or loose for proxy_arp completely this interface (by setting same medium id). Btw usually proxy_arp "answers" only for directly attached networks, e.g. link layer routes (no gateway), but sure this is not a rule, and sometimes it is even useful to "proxy" gatewayed routes. I am concerned only about 0.0.0.0/0 route, which is equal to wildcard. If i understand question correctly. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Saturday 04 July 2009 03:46:15 Eric W. Biederman wrote: >> Denys Fedoryschenko <denys@visp.net.lb> writes: >> > On Friday 03 July 2009 23:20:05 David Miller wrote: >> >> I really never should have applied your initial patch, I severely >> >> regret it. Thanksfully it's reverted now and we can look into >> >> this issue more properly. >> > >> > If it was said before... >> > >> > Then maybe i will try to do some new sysctl value? >> > >> > By default it will be old behavior, but it can be changed to new on user >> > choice. >> > >> > Let's say >> > >> > net.ipv4.arp_proxy_gateway >> > net.ipv4.arp_proxy_gratuitous >> >> How do machines with addresses without routes to them >> get packets from machines in other subnets? >> >> Eric > ARP proxy generally was supposed to not export default route(by RFC and by > logic) it should be maybe other name, arp_proxy_no_default_gateway_export - > but i guess it is too long. With exporting default gateway i have two > choices - eat it and have answer to almost any ARP request, or loose for > proxy_arp completely this interface (by setting same medium id). > > Btw usually proxy_arp "answers" only for directly attached networks, e.g. link > layer routes (no gateway), but sure this is not a rule, and sometimes it is > even useful to "proxy" gatewayed routes. I am concerned only about 0.0.0.0/0 > route, which is equal to wildcard. > > If i understand question correctly. Problems occur when you have machines with ip addresses that you don't have routes to. How do machines with addresses without routes to them get packets from machines in other subnets. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 04 July 2009 18:00:58 Eric W. Biederman wrote: > > Problems occur when you have machines with ip addresses that you don't > have routes to. How do machines with addresses without routes to them > get packets from machines in other subnets. > > Eric They are not supposed to communicate then with this Linux host. But Linux poisoning them by ARP replies. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Saturday 04 July 2009 18:00:58 Eric W. Biederman wrote: >> >> Problems occur when you have machines with ip addresses that you don't >> have routes to. How do machines with addresses without routes to them >> get packets from machines in other subnets. >> >> Eric > They are not supposed to communicate then with this Linux host. > But Linux poisoning them by ARP replies. How can that possibly be a correct network configuration? Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote: > > How can that possibly be a correct network configuration? > > Eric It is a problem to have different networks, who doesn't communicate one with each other, in same ethernet segment? Does it violate anything? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 5 Jul 2009 01:00:08 +0300 Denys Fedoryschenko <denys@visp.net.lb> wrote: > On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote: > > > > How can that possibly be a correct network configuration? > > > > Eric > It is a problem to have different networks, who doesn't communicate one with > each other, in same ethernet segment? > > Does it violate anything? I'm pretty sure it doesn't. It's a common enough situation. A second subnet (or more) is assigned to a link because the first isn't large enough, and renumbering the hosts into a larger subnet is not practical at the time. A 'one-armed router' is used up stream to have traffic go between the different subnets, at the cost of traffic double traversing the link. (The worst example I've seen is 25 subnets operating this way!) Fundamentally it is no different to routing traffic to other subnets. IP was designed on the assumption that there'd only be a single subnet per link, so nothing was done to make this scenario more efficent. IPv6 has introduced the ability for hosts to be told by their default router that destinations they think are "offlink", because the address falls outside a locally assigned or learned prefixes, are actually "onlink", preventing this double traversing problem. Regards, Mark. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryschenko <denys@visp.net.lb> writes: > On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote: >> >> How can that possibly be a correct network configuration? >> >> Eric > It is a problem to have different networks, who doesn't communicate one with > each other, in same ethernet segment? > > Does it violate anything? The point of the internet protocol is communications between networks. Setting up a router to route traffic in and off of a network and not telling it about one of the networks on your ethernet segment is at the least very peculiar. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mark Smith <lk-netdev@lk-netdev.nosense.org> writes: > On Sun, 5 Jul 2009 01:00:08 +0300 > Denys Fedoryschenko <denys@visp.net.lb> wrote: > >> On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote: >> > >> > How can that possibly be a correct network configuration? >> > >> > Eric >> It is a problem to have different networks, who doesn't communicate one with >> each other, in same ethernet segment? >> >> Does it violate anything? > > I'm pretty sure it doesn't. > > It's a common enough situation. A second subnet (or more) is assigned > to a link because the first isn't large enough, and renumbering the > hosts into a larger subnet is not practical at the time. A > 'one-armed router' is used up stream to have traffic go between the > different subnets, at the cost of traffic double traversing the link. > (The worst example I've seen is 25 subnets operating this way!) > > Fundamentally it is no different to routing traffic to other subnets. > IP was designed on the assumption that there'd only be a single subnet > per link, so nothing was done to make this scenario more efficent. > > IPv6 has introduced the ability for hosts to be told by their default > router that destinations they think are "offlink", because the address > falls outside a locally assigned or learned prefixes, are actually > "onlink", preventing this double traversing problem. Multiple subnets on an ethernet segment sure. Multiple subnets subnets that don't communicate? Not telling your router about all of the subnets on the ethernet segment? The combination of not configuring the router to know about all of the subnets and enabling proxy arp is what is causing problems for Denys. That sure seems like a misconfiguration to me. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday 05 July 2009 03:07:11 Eric W. Biederman wrote: > > Multiple subnets on an ethernet segment sure. Multiple subnets > subnets that don't communicate? Not telling your router about all of > the subnets on the ethernet segment? > > The combination of not configuring the router to know about all of the > subnets and enabling proxy arp is what is causing problems for Denys. > > That sure seems like a misconfiguration to me. > > Eric Real example Still a lot of letters, but i hope it will help to understand situation. Big office network. We trust each other and we dont have much money. So unmanaged switches. Network separated to two locations Router in the middle. eth0 - 10.0.0.2/24 eth1 - 10.0.1.1/24 default gateway is 10.0.0.1 arp_proxy enabled on both. Users have on machines netmask /22, so they can communicate freely. DHCP assigning addresses for them. I just install few Windows XP machines in same network, and planned to do some tests only between them. I am just using same physical media, i dont think it is reasonable to install new switch and cables just for them. Sure if i had managed switches i can put them in separate VLAN, but it is just silly to do that, because proper network equipment will not interfere with this tests. So i assign them ip's 192.168.1.1 , 192.168.1.2, 1.3, 1.4 and etc. No default gateway. I dont want my traffic go outside. But whoops, on boot i got IP address conflict. Nice. Ok, let's say i manage it, it can be disabled in registry. I am trying to do tests, and packets supposed to go from 192.168.1.1 to 192.168.1.2 are being forwarded to router! WTF! In fact router by answering any ARP request, and is can be called "ARP spoofing", forwarding my packets to default gateway, and sure they wont come back. It makes difficult also to find problem, because ARP reply will be given by both hosts, legitimate and router who is violating RFC, and depends which come first and which last, it will work properly or not. Sure i can enable delay on sending proxy_arp request, but if windows host was down at this moment, it will give again, invalid "target" in MAC address. On your logics i must reconfigure router each time when i do tests and assign some ip's. Actually i am bringing and plugging to network a lot of different equipment, with different default ips. I cannot plug them sometimes directly over crossover cable to my PC, and have to use network. It doesn't look logic to reconfigure office router for each of those devices or to make isolation. Thats why in RFC mentioned " The default route must not be used when checking for a route to the target host of an ARP request. If the default route were used, the check would always succeed. But the host specified by the default route is unlikely to know about subnet routing (since it is usually an Internet gateway), and thus packets sent to it will probably be lost." -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 04 Jul 2009 17:07:11 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote: > Mark Smith <lk-netdev@lk-netdev.nosense.org> writes: > > > On Sun, 5 Jul 2009 01:00:08 +0300 > > Denys Fedoryschenko <denys@visp.net.lb> wrote: > > > >> On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote: > >> > > >> > How can that possibly be a correct network configuration? > >> > > >> > Eric > >> It is a problem to have different networks, who doesn't communicate one with > >> each other, in same ethernet segment? > >> > >> Does it violate anything? > > > > I'm pretty sure it doesn't. > > > > It's a common enough situation. A second subnet (or more) is assigned > > to a link because the first isn't large enough, and renumbering the > > hosts into a larger subnet is not practical at the time. A > > 'one-armed router' is used up stream to have traffic go between the > > different subnets, at the cost of traffic double traversing the link. > > (The worst example I've seen is 25 subnets operating this way!) > > > > Fundamentally it is no different to routing traffic to other subnets. > > IP was designed on the assumption that there'd only be a single subnet > > per link, so nothing was done to make this scenario more efficent. > > > > IPv6 has introduced the ability for hosts to be told by their default > > router that destinations they think are "offlink", because the address > > falls outside a locally assigned or learned prefixes, are actually > > "onlink", preventing this double traversing problem. > > Multiple subnets on an ethernet segment sure. Multiple subnets > subnets that don't communicate? Not telling your router about all of > the subnets on the ethernet segment? > > The combination of not configuring the router to know about all of the > subnets and enabling proxy arp is what is causing problems for Denys. > > That sure seems like a misconfiguration to me. > A misconfiguration if you don't intend it, otherwise, isolation between subnets on a common link can be useful. I've taken advantage of it in networking test labs. It can also be useful for basic traffic engineering. You set up two routers attached to the same link, but both with different configured prefixes. Nodes are assigned adresses out of one or the other prefix, to influence which outbound (and inbound) path their traffic takes. Leaving it like that would be a bit unusual, however it could be as part of a gradual transition to splitting the link to reduce the broadcast domain size. Regards, Mark. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -uprN net-next-2.6/net/ipv4/arp.c net-next-2.6.my3/net/ipv4/arp.c --- net-next-2.6/net/ipv4/arp.c 2009-07-01 01:00:58.000000000 +0300 +++ net-next-2.6.my3/net/ipv4/arp.c 2009-07-01 01:26:09.000000000 +0300 @@ -815,6 +815,7 @@ static int arp_process(struct sk_buff *s } if (arp->ar_op == htons(ARPOP_REQUEST) && + tip != sip && ip_route_input(skb, tip, sip, 0, dev) == 0) { rt = skb_rtable(skb);