Hi, Julian.
Let me explain my setup, and then you can hopefully explain why I'm
wrong. I work for a company that writes routing software. We support
and test on a mixture of Unix OSs, one being Linux, and RTOSs. Here's
an example setup:
---+----+--- (192.168.1/24)
| |
A B
| |
---+----+--- (10.10/16)
A: 192.168.1.1, 10.10.0.1
B: 192.168.1.2, 10.10.0.2
A and B usually have default routes pointed to 192.168.1.254, as this is
the router connecting the testbed to the workstations. In this example,
A is Linux, B is any other OS we test against ([Free|Net|Open]BSD, BSDi,
Solaris, AIX, True64). Both are running ISIS, which does *not* use IP
as a transport (this is important, I'll explain later). ISIS installs a
new default route on A that points at 10.10.0.2. If, at this point,
there is no ARP entry in A's ARP cache for 10.10.0.2, it will send an
ARP reqest to the 10.10/16 network as follows:
whohas 10.10.0.2 tell 192.168.1.1
This happens every time in this situation. If we were running, say,
OSPF (which does use IP as a transport), then A's ARP cache would always
have an entry for 10.10.0.2, and this situation would not show up.
However, we have confirmed that, if you clear the ARP cache on A, and
then change it's default route from one network to another, it will
always generate these bizarre ARP requests. Since all the other OSs we
run will not answer that request, this results in A being completely
unreachable from off of it's directly connected networks. Those ARP
reqests are generated even if the packets being sent are pings to
10.10.0.2. To me, this seems broken, and has resulted in us not
recommending Linux to any of our customers. (The company is historically
largely a BSD house. I'm trying to change this bias somewhat). 2.4.16
does this, as well as 2.2.*. I've gotten a patch for 2.2.19 that fixes
the problem, but all I've heard about 2.4 is "That's how it's supposed
to work". If this is not broken, how do I get it to work?
I'm not on linux-net so please CC me.
Thanks for your time,
Daniel
On Tue, 2002-07-16 at 19:41, Julian Anastasov wrote:
>
> Hello,
>
> On 16 Jul 2002, Daniel Gryniewicz wrote:
>
> > Okay, I have no problem with this. What I have a problem with is Linux
> > sending an ARP request out an interface and using the address of
>
> Please apply rp_filter_mask and be happy :) By this way
> you can safely use rp_filter with hubs if that is your problem.
>
> > *another interface* as the tell address. This is just broken.
>
> From routing perspective it is not broken: ARP request is
> built from data approved from routing and extracted from the
> IP packet. If you provide different sender IP in the ARP request
> you risk this probe to be answered on another target host's interface,
> i.e. the remote host can answer it on eth0 and then our IP packet (with
> different src IP) will be dropped on this device if it is allowed
> on eth1 and the rp_filter_mask I mentioned in previous mail is not
> supported/set (and it is usually not). This happens if the remote host
> has 2 devices attached to the same hub we are connected and in such
> case it usually accept one ARP probe on one interface (eth*/rp_filter=1).
> This is the reason Linux ARP to use addresses from the IP packets.
> You must not break this rule or you risk problems. Do you see the
> symmetry? If you lie in your ARP probe then you can receive wrong MAC for
> that target. Note that we resolve the path (SRCIP->DSTIP), not only DSTIP.
> We ask "where should I send traffic from SRCIP to DSTIP?". The
> question "where is DSTIP" is too ambiguous, you risk to receive
> wrong answer (as usually happens). This is not mentioned in RFC826.
> Nor the word "hub" :)
>
> Again, you are welcome on linux-net where we can find solution for
> every setup which involves Linux ARP :)
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
--
Recursion n.:
See Recursion.
-- Random Shack Data Processing Dictionary
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
