ARP and alias IPs

ARP and alias IPs

[Andrew Ryan]

The linux implementation of ARP is causing me problems.  Linux sends out an
ARP request with the default interface as the sender address, rather than then
interface the request came on. 

For example

eth0   10.1.1.100
eth0:1 192.16.1.101 

and an ARP is received on 192.16.1.101, linux responds with
10.1.1.100 as the source address in the ARP request, rather than 192.16.1.101
(which FreeBSD, Solaris, and tru64 do).  To me, this is just plain wrong. 
The sender address should be an address on the subnet that the request came
from, not a different one.  Is there any way to fix this?

Andy

Re: ARP and alias IPs

[Alex Riesen]

On Thu, Sep 05, 2002 at 10:09:50AM -0500, Andrew Ryan wrote:
> The linux implementation of ARP is causing me problems.  Linux sends out an
> ARP request with the default interface as the sender address, rather than then
> interface the request came on. 

http://www.rfc-editor.org/rfc/std/std37.txt

> For example
> 
> eth0   10.1.1.100
> eth0:1 192.16.1.101 

Are you really expect an aliased interface to work the way you described?

> and an ARP is received on 192.16.1.101, linux responds with
> 10.1.1.100 as the source address in the ARP request, rather than 192.16.1.101
> (which FreeBSD, Solaris, and tru64 do).  To me, this is just plain wrong. 
> The sender address should be an address on the subnet that the request came
> from, not a different one.  Is there any way to fix this?

Re: ARP and alias IPs

[Remco Post]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On donderdag, september 5, 2002, at 05:34 , Alex Riesen wrote:

> On Thu, Sep 05, 2002 at 10:09:50AM -0500, Andrew Ryan wrote:
>> The linux implementation of ARP is causing me problems.  Linux sends 
>> out an
>> ARP request with the default interface as the sender address, rather 
>> than then
>> interface the request came on.
>
> http://www.rfc-editor.org/rfc/std/std37.txt
>
>> For example
>>
>> eth0   10.1.1.100
>> eth0:1 192.16.1.101
>
> Are you really expect an aliased interface to work the way you 
> described?


if I read this version of the internet standard correctly, it should 
respond with the ip address that was requested:

"It then notices that it is a request, so it swaps fields, putting
EA(Y) in the new sender Ethernet address field (ar$sha), sets the
opcode to reply, and sends the packet directly (not broadcast) to
EA(X)."

Meaning that the reply must come from the ip-address that was beeing 
looked for in the first place, not just any address used on that 
interface. Though at the time of writing this was not something that was 
in use at all I guess.

So yes, I think it is reasonable to assume that if I do an arp request 
for one address, I do not get a reply for another address that happens 
to be on the same interface... There is no way of determining that this 
is indeed the address I was looking for in the first place. I have not 
checked to see if Linux does this, but if it does it is plain wrong...
- ---
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam    http://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167
PGP keys at http://home.sara.nl/~remco/keys.asc

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer 
industry
didn't even foresee that the century was going to end." -- Douglas Adams


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE9d4DTBIoCv9yTlOwRAm1zAJ9DyuMA3RlAFYZeJkulWYOFPPrFZwCdGIHx
pIvaA6utByxRaHKq58JdTso=
=jsvP
-----END PGP SIGNATURE-----

Re: ARP and alias IPs

[Chris Friesen]

Andrew Ryan wrote:
> 
> The linux implementation of ARP is causing me problems.  Linux sends out an
> ARP request with the default interface as the sender address, rather than then
> interface the request came on.
> 
> For example
> 
> eth0   10.1.1.100
> eth0:1 192.16.1.101
> 
> and an ARP is received on 192.16.1.101, linux responds with
> 10.1.1.100 as the source address in the ARP request, rather than 192.16.1.101
> (which FreeBSD, Solaris, and tru64 do).  To me, this is just plain wrong.
> The sender address should be an address on the subnet that the request came
> from, not a different one.  Is there any way to fix this?


I'm not sure how you're managing to get that behaviour.  I just reproduced the scenario on a 2.2.17
kernel and logged the output. 47.129.82.232 is configured as eth0:0, with 47.129.82.53 being eth0,
and pcary1ja maps to 47.129.82.54.


08:04:59.650707 eth0 > 0:0:0:0:0:0 0:30:65:a0:ff:c6 arp 42: arp who-has 47.129.82.232 tell pcary1ja
(0:30:65:a0:ff:c6)
                         0001 0800 0604 0001 0030 65a0 ffc6 2f81
                         5236 0000 0000 0000 2f81 52e8
08:04:59.650707 eth0 < 0:30:65:c0:23:c4 0:0:0:0:0:1 arp 64: arp reply 47.129.82.232 is-at
0:30:65:c0:23:c4 (0:30:65:a0:ff:c6)
                         0001 0800 0604 0002 0030 65c0 23c4 2f81
                         52e8 0030 65a0 ffc6 2f81 5236 5555 5555
                         5555 5555 5555 5555 5555 5555 5555 e796
                         9051

As you can see, the reply is properly sent out with the source IP address of 47.129.82.232.

Are you sure you aren't misreading something?  If you change the source IP address then the arp
reply is totally useless as it is a reply to another request entirely.

Chris