From: Richard Underwood <hidden> Date: 2003-08-19 14:37:20
Alan Cox wrote:
You increase it and you shortcut on shared lans. Thats really a seperate
issue to the question of which source is used. If you loopback someone
elses address on your own lo device I'm not suprised weird
shit happens, put the alias on eth0 where it belongs.
Woah! I'm not talking about JUST load-balanced networks. This is a
far more generic problem.
As an example, I have a router/firewall for the office that has two
interface cards, both with perfectly valid internal addresses - these
addresses aren't used anywhere else on the network.
Two of the interfaces are: 172.20.240.2/24 and 172.24.0.1/16. My
default gateway is 172.20.240.1 and there aren't any other non-interface
routes. If I do:
# arp -d 172.24.0.80
# ping -I 172.20.240.2 172.24.0.80
I see:
16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2
16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37
Now, since 172.24.0.80 is a Linux box, it's happily adding
172.20.240.2 into its ARP table and reply to it, hence the reply.
But if I was to do this in the other direction (arp -d 172.20.240.1;
ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
route because 172.20.240.1 won't accept ARP packets from IP numbers not on
the connected subnet. The <incomplete> ARP entry will block any further ARP
requests from valid IP numbers.
This, in my opinion, isn't on. There must be thousands of Linux
installations out there that (1) have more than one interfaces and (2) are
connected to routers or firewalls that drop ARP requests in the same way.
Actually, it's not that bad in this case as the next hop will
probably send an ARP request at some point which will override it - but
that's really not the point.
If the routeing was asymetric, or the next hop had a static ARP
entry for me, all communication would quite simply be lost. It'd just take
the first packet after an ARP entry times out to be from the wrong IP
address, and the host would be off the net.
I personally don't think "shared LANs" should be favoured over best
practice. Even in the case of shared LANs, nothing "breaks" as David Miller
suggests would happen if the ARPs were fixed.
Thanks,
Richard
Hello,
On Tue, Aug 19, 2003 at 03:34:43PM +0100, Richard Underwood wrote:
As an example, I have a router/firewall for the office that has two
interface cards, both with perfectly valid internal addresses - these
addresses aren't used anywhere else on the network.
Two of the interfaces are: 172.20.240.2/24 and 172.24.0.1/16. My
default gateway is 172.20.240.1 and there aren't any other non-interface
routes. If I do:
# arp -d 172.24.0.80
# ping -I 172.20.240.2 172.24.0.80
I see:
16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2
16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37
Now, since 172.24.0.80 is a Linux box, it's happily adding
172.20.240.2 into its ARP table and reply to it, hence the reply.
But if I was to do this in the other direction (arp -d 172.20.240.1;
ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
route because 172.20.240.1 won't accept ARP packets from IP numbers not on
the connected subnet. The <incomplete> ARP entry will block any further ARP
requests from valid IP numbers.
This is exactly the case I calmly discussed privately with David then Alexey.
Both explained me that in fact, the remote host shouldn't be filtering the ARP
requests based on the source IP they provide, but agreed that it seems to be a
general trend today. Alexey proposed a slight change which can at least solve
this very common case by preventing the system from using the local address as
a source IP if it is not on the interface through which the request is sent.
Obviously it will not solve all very special cases, which people can work
around with arptables, but it will solve this common one.
Cheers,
Willy
From: Stephan von Krawczynski <hidden> Date: 2003-08-19 15:10:09
On Tue, 19 Aug 2003 16:54:03 +0200
Willy Tarreau [off-list ref] wrote:
This is exactly the case I calmly discussed privately with David then Alexey.
Both explained me that in fact, the remote host shouldn't be filtering the
ARP requests based on the source IP they provide,
Hm, what rule is broken by the remote host, then? I mean "remote host shouln't"
reads like "according to RFC-XYZ he should not".
IFF of course the remote host is not broken, then our idea must be broken. Else
world would have kind of a definition gap in this layer of networking, and I
hardly believe that.
Regards,
Stephan
From: Bill Davidsen <hidden> Date: 2003-08-19 16:03:07
On Tue, 19 Aug 2003, Willy Tarreau wrote:
Hello,
On Tue, Aug 19, 2003 at 03:34:43PM +0100, Richard Underwood wrote:
quoted
Now, since 172.24.0.80 is a Linux box, it's happily adding
172.20.240.2 into its ARP table and reply to it, hence the reply.
But if I was to do this in the other direction (arp -d 172.20.240.1;
ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
route because 172.20.240.1 won't accept ARP packets from IP numbers not on
the connected subnet. The <incomplete> ARP entry will block any further ARP
requests from valid IP numbers.
This is exactly the case I calmly discussed privately with David then Alexey.
Both explained me that in fact, the remote host shouldn't be filtering the ARP
requests based on the source IP they provide, but agreed that it seems to be a
general trend today. Alexey proposed a slight change which can at least solve
this very common case by preventing the system from using the local address as
a source IP if it is not on the interface through which the request is sent.
Obviously it will not solve all very special cases, which people can work
around with arptables, but it will solve this common one.
I wonder if a change to add a flag preventing *any* packet from being sent
on a NIC which doesn't have the proper source address would be politically
acceptable. I did that type of patch for 2.4.16 to prevent killing
routers by having the MAC change for an IP. It will hurt performance on at
least some routers, and the patch eliminated the problem.
I later changed to using source routing, since the number of IPs was
modest and didn't change, but I am still fighting the issue in a test
environment, where the number of IPs is high and I can't just grab a range
in some cases.
--
bill davidsen [off-list ref]
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
From: David S. Miller <hidden> Date: 2003-08-19 16:05:13
On Tue, 19 Aug 2003 17:07:51 +0200
Stephan von Krawczynski [off-list ref] wrote:
Hm, what rule is broken by the remote host, then?
It means that systems (like Linux) that make IP addresses owned by the
host instead of specific interfaces cannot correctly interoperate with
such remote systems.
It is also the case that a host cannot possibly be aware of all
subnets present on a given LAN, therefore is should be liberal in it's
replies to ARP requests.
Finally, it violates the most basic rule of IP networking:
"Be liberal in what you accept, and conservative in what you send"
-Jon Postel
In general, when a host posses the information necessary to allow
other hosts to communicate, it should provide that information
whenever possible.
From: David S. Miller <hidden> Date: 2003-08-19 16:21:42
On Tue, 19 Aug 2003 11:53:29 -0400 (EDT)
Bill Davidsen [off-list ref] wrote:
I wonder if a change to add a flag preventing *any* packet from being sent
on a NIC which doesn't have the proper source address would be politically
acceptable.
This would disable things like MSG_DONTROUTE and many valid
uses of RAW sockets.
From: Stephan von Krawczynski <hidden> Date: 2003-08-19 17:16:53
On Tue, 19 Aug 2003 09:53:02 -0700
"David S. Miller" [off-list ref] wrote:
On Tue, 19 Aug 2003 18:52:19 +0200
Stephan von Krawczynski [off-list ref] wrote:
quoted
On Tue, 19 Aug 2003 08:57:17 -0700
"David S. Miller" [off-list ref] wrote:
quoted
"Be liberal in what you accept, and conservative in what you send"
-Jon Postel
If I understood what Richard said in this thread Jon just shot you
down. The conservative way to _request_ arp would definitely be to
request it from the "correct" subnet, because as a sender you ought
to give credit to knowing that "bad" boxes out there won't answer if
you do otherwise.
In the ARP request we are using the source address in the packet we
are building for output.
If ARP doesn't work using that source address, we can only assume IP
communication is not possible either.
It is the box not responding to this ARP which is preventing
communication not the box creating the ARP request.
Please read my example from other email. Very simple to prove you wrong here.
Regards,
Stephan
From: David S. Miller <hidden> Date: 2003-08-19 17:20:01
On Tue, 19 Aug 2003 19:12:46 +0200
Stephan von Krawczynski [off-list ref] wrote:
On Tue, 19 Aug 2003 09:53:02 -0700
"David S. Miller" [off-list ref] wrote:
quoted
In the ARP request we are using the source address in the packet we
are building for output.
If ARP doesn't work using that source address, we can only assume IP
communication is not possible either.
It is the box not responding to this ARP which is preventing
communication not the box creating the ARP request.
Please read my example from other email. Very simple to prove you wrong here.
Not really, the RFC you keep quoting is broken in several
regards:
1) It is non-functional in environments containing systems
using the host ownership model for IP addresses which the
RFC standards fully allow.
2) It does not consider the cases where a host is not completely
aware of all subnets present on a given link. This is actually
quite common.
Dropping such ARP requests can only be done when the
the host is aware of all subnets that exist, which is cannot
be possibly true.
From: David S. Miller <hidden> Date: 2003-08-19 17:31:52
On Tue, 19 Aug 2003 18:52:19 +0200
Stephan von Krawczynski [off-list ref] wrote:
On Tue, 19 Aug 2003 08:57:17 -0700
"David S. Miller" [off-list ref] wrote:
quoted
"Be liberal in what you accept, and conservative in what you send"
-Jon Postel
If I understood what Richard said in this thread Jon just shot you
down. The conservative way to _request_ arp would definitely be to
request it from the "correct" subnet, because as a sender you ought
to give credit to knowing that "bad" boxes out there won't answer if
you do otherwise.
In the ARP request we are using the source address in the packet we
are building for output.
If ARP doesn't work using that source address, we can only assume IP
communication is not possible either.
It is the box not responding to this ARP which is preventing
communication not the box creating the ARP request.
From: Bill Davidsen <hidden> Date: 2003-08-19 17:39:54
On Tue, 19 Aug 2003, David S. Miller wrote:
On Tue, 19 Aug 2003 11:53:29 -0400 (EDT)
Bill Davidsen [off-list ref] wrote:
quoted
I wonder if a change to add a flag preventing *any* packet from being sent
on a NIC which doesn't have the proper source address would be politically
acceptable.
This would disable things like MSG_DONTROUTE and many valid
uses of RAW sockets.
Probably would, but since it's a flag people could use it or not. I did
that via a patch and it didn't show any problems in a tcp/udp environment.
I would assume that source routing would produce the same problem in some
cases, would it not? And I bet that using rp_filter can break some things
as well, so there is precedent for having capabilities which could impact
some valid procedures.
I appreciate your point (which I totally overlooked), but I don't see that
we have avoided other capabilities which could cause problems if
misconfigured. It is clearly the responsibility of the admin to do
configuration, and this seems (based on my actual experience) to work in
an environment where arp/tcp/udp are being used.
Unless you have additional issues, I would suggest that there are good
reasons to add this capability.
- no more dangerous than source routing and much easier to use
- saves much discussion and time
- much better to have one change done properly than lots of half-assed
patches
I understand your objections to the hidden patch, I think the approach I
suggest could be done at the proper level and would provide a standard way
to solve a common problem. If this can be reasonably done I would think
you would support it just to be able to say "use default_source_routing"
when the hidden patch visits the next time ;-)
--
bill davidsen [off-list ref]
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
From: Stephan von Krawczynski <hidden> Date: 2003-08-19 17:59:48
On Tue, 19 Aug 2003 08:57:17 -0700
"David S. Miller" [off-list ref] wrote:
On Tue, 19 Aug 2003 17:07:51 +0200
Stephan von Krawczynski [off-list ref] wrote:
quoted
Hm, what rule is broken by the remote host, then?
It means that systems (like Linux) that make IP addresses owned by the
host instead of specific interfaces cannot correctly interoperate with
such remote systems.
It is also the case that a host cannot possibly be aware of all
subnets present on a given LAN, therefore is should be liberal in it's
replies to ARP requests.
Finally, it violates the most basic rule of IP networking:
"Be liberal in what you accept, and conservative in what you send"
-Jon Postel
If I understood what Richard said in this thread Jon just shot you down. The
conservative way to _request_ arp would definitely be to request it from the
"correct" subnet, because as a sender you ought to give credit to knowing that
"bad" boxes out there won't answer if you do otherwise. There can be no doubt
what "conservative" means here.
Additionally, the remote box is not really bad behaving:
<quote RFC-985>
A.3. ARP datagram
An ARP reply is discarded if the destination IP address does not
match the local host address. An ARP request is discarded if the
source IP address is not in the same subnet. It is desirable that
this test be overridden by a configuration parameter, in order to
support the infrequent cases where more than one subnet may
coexist on the same cable (see RFC-925 for examples).
</quote>
This means the remote box is completely ok if not answering to a request with
source ip from another subnet.
So from what I read here requesting arp should really only happen with a source
ip from the same subnet.
Regards,
Stephan
But if I was to do this in the other direction (arp -d 172.20.240.1;
ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
route because 172.20.240.1 won't accept ARP packets from IP numbers not on
the connected subnet. The <incomplete> ARP entry will block any further ARP
requests from valid IP numbers.
One thing I agree with you about is that an ARP resolution for an
address via one path should not block a resolution for it by another
path since to begin with the two paths may be to different routers
one of which is down.
From: David S. Miller <hidden> Date: 2003-08-19 19:34:08
On Tue, 19 Aug 2003 21:19:44 +0200
"Bas Bloemsaat" [off-list ref] wrote:
quoted
Indeed, would people stop quoting from RFC 985 and
RFC 826.
RFC 826 is referenced from 1009 as describing ARP. So in effect it does
define a standard.
The RFC 826 document clearly says, at the top, "This is not
an Internet Standard"
It does not define a standard. And given that it really isn't
surprising it has errors in it as we've clearly shown in these
threads. The authors of said document didn't scuritinize it
to the level it would need to be in order to truly be a standards
document people must follow to have a conformant implementation.
From: Stephan von Krawczynski <hidden> Date: 2003-08-19 21:53:34
On 19 Aug 2003 20:08:20 +0100
Alan Cox [off-list ref] wrote:
quoted
But if I was to do this in the other direction (arp -d 172.20.240.1;
ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
route because 172.20.240.1 won't accept ARP packets from IP numbers not on
the connected subnet. The <incomplete> ARP entry will block any further ARP
requests from valid IP numbers.
One thing I agree with you about is that an ARP resolution for an
address via one path should not block a resolution for it by another
path since to begin with the two paths may be to different routers
one of which is down.
Sounds logical.
Can you explain to me why there should be a difference in the source ip of an
arp request originated by an ip packet from another address of the same host
compared to a forwarded packet from another host, coming in on some secondary
interface?
If I understood David correctly the first case will do an arp request with
source ip equal to source ip of the packet (originated locally).
In the second case (the box has to forward some foreign packet) for sure its
interface address will be used, correct? Or does that read: _some_ interface
address will be used?
Why this difference? The destination host cannot distinguish between these two
cases, so they can be as well handled just the same. But it seems obvious that
a foreign IP cannot be used as a source for an arp request.
And overall, looking at an arp table, what is visible is: interface, MAC and
corresponding IP. So as soon as an arp request is successfully completed the
box doesn't even remember the source ip of the former arp request, right?
Regards,
Stephan
From: Stephan von Krawczynski <hidden> Date: 2003-08-20 14:15:24
On Wed, 20 Aug 2003 10:49:46 +0200
Roman Pletka [off-list ref] wrote:
Bas Bloemsaat wrote:
quoted
quoted
Indeed, would people stop quoting from RFC 985 and
RFC 826.
RFC 826 is referenced from 1009 as describing ARP. So in effect it does
define a standard.
RFC 1009 is obsolete too (by 1812 for the sake of completeness).
Please stop quoting obsolete RFC's.
-- Roman
One of the big advantages of RFCs is that everybody can read them. In fact if
one names a special RFC for proving something he said, he should at least have
read it once:
<quote RFC 1812>
3.3.2 Address Resolution Protocol - ARP
Routers that implement ARP MUST be compliant and SHOULD be
unconditionally compliant with the requirements in [INTRO:2].
...
INTRO:2.
Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts - Communication Layers", STD 3,
RFC 1122, USC/Information Sciences Institute, October 1989.
</quote>
=>
<qoute RFC 1122>
2.3.2 Address Resolution Protocol -- ARP
2.3.2.1 ARP Cache Validation
An implementation of the Address Resolution Protocol (ARP)
[LINK:2] MUST provide a mechanism to flush out-of-date cache
entries. If this mechanism involves a timeout, it SHOULD be
possible to configure the timeout value.
...
[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
November 1982.
</quote>
=>
RFC-826 is _valid_
Why do you think it is not valid, Roman? Where do you read that?
Regards,
Stephan
From: Roman Pletka <hidden> Date: 2003-08-20 14:50:50
Stephan von Krawczynski wrote:
<qoute RFC 1122>
2.3.2 Address Resolution Protocol -- ARP
2.3.2.1 ARP Cache Validation
An implementation of the Address Resolution Protocol (ARP)
[LINK:2] MUST provide a mechanism to flush out-of-date cache
entries. If this mechanism involves a timeout, it SHOULD be
possible to configure the timeout value.
...
[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
November 1982.
</quote>
Please read carefully what you have quoted:
It says: *An* implementation... and then goes on with a citation of RFC 826.
A simple citation does not make a valid standard yet. It just refers to it
as an example for this specific issue. That's all.
-- Roman
From: Stephan von Krawczynski <hidden> Date: 2003-08-20 15:55:13
On Wed, 20 Aug 2003 16:43:42 +0200
Roman Pletka [off-list ref] wrote:
Stephan von Krawczynski wrote:
quoted
<qoute RFC 1122>
2.3.2 Address Resolution Protocol -- ARP
2.3.2.1 ARP Cache Validation
An implementation of the Address Resolution Protocol (ARP)
[LINK:2] MUST provide a mechanism to flush out-of-date cache
entries. If this mechanism involves a timeout, it SHOULD be
possible to configure the timeout value.
...
[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
November 1982.
</quote>
Please read carefully what you have quoted:
It says: *An* implementation... and then goes on with a citation of RFC 826.
A simple citation does not make a valid standard yet. It just refers to it
as an example for this specific issue. That's all.
Sorry, but my reading is this "An implementation of the ( Address Resolution
Protocol (ARP) [LINK:2] ) ..."
Do you understand what I mean?
If you insist on RFC-826 being only one of several (possible) ARP
implementations, can you then please name an RFC where ARP as a protocol is
clearly defined? I mean there must be one, or not?
Regards,
Stephan
From: Roman Pletka <hidden> Date: 2003-08-20 16:49:45
Stephan von Krawczynski wrote:
>On Wed, 20 Aug 2003 16:43:42 +0200
>Roman Pletka [off-list ref] wrote:
>
>
>>Please read carefully what you have quoted:
>>It says: *An* implementation... and then goes on with a citation of RFC 826.
>>A simple citation does not make a valid standard yet. It just refers to it
>>as an example for this specific issue. That's all.
>
>
>Sorry, but my reading is this "An implementation of the ( Address Resolution
>Protocol (ARP) [LINK:2] ) ..."
>Do you understand what I mean?
>
>If you insist on RFC-826 being only one of several (possible) ARP
>implementations, can you then please name an RFC where ARP as a protocol is
>clearly defined? I mean there must be one, or not?
This is not the point. As has already been mentioned some days ago by davem
RFC 826 explicitely states at the beginning that it is not the specification
of an Internet Standard and thats what I meant.
So let's stop spinning round on this.
-- Roman