[LARTC] Bug in the HOWTO: proxy-arp (?)

[LARTC] Bug in the HOWTO: proxy-arp (?)

[SHuelbrock]

Hello alltogether,
I'm new to the list, so please excuse any violations of listiquette...

I didn't have to much to do with linux based firewalling and routing for
quite a time and found that proxy-arp changed in between...

As I struggled with it I found that the Advanced routing... howto wasn't to
helpfull. Especially the documentation seems to be rather vice versa to
what I found out using a 2.4.17 kernel. This is why I'm writing this mail
to the list...
What I wanted the machine to do was to answer with it's own MAC address on
the external Interface if a certain different IP on the network was
ARPrequested. The machine didn't need to route this address because it was
natted.

Cited from the howto (chap 13):
---8<---8<---8<
/proc/sys/net/ipv4/conf/DEV/proxy_arp
If you set this to 1, all other interfaces will respond to arp queries
destined for addresses on this interface. Can be very useful when building
'ip pseudo bridges'. Do take care that your netmasks are very correct
before enabling this!
---8<---8<---8<

I interpret this in a way that if I enable this proxy_arp setting on
(example) eth0 the machine will answer arp requests for the IPs in the
network bound to eth0 on all other interfaces.

What I found out was different (and makes significantly more sense to me):
If I enable proxy_arp on an interface, _this_ interface answers with
proxy-ARPs for all the IP addresses that are in it's local network, that
are routed to other interfaces.
Example:
---8<---8<---8<-
ifconfig eth0 192.168.1.1 netmask 255.255.255.0
ifconfig eth1 172.16.1.1 netmask 255.255.0.0
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
route add -host 192.168.1.2 gw 172.16.1.2
Then this machine answers ARP requests on eth0 for 192.168.1.2 and
192.168.1.1. (And by the way not for any addresses in the 172.16 network on
eth0 and also not for any addresses in the 192.168.1.0 network on eth1).
---8<---8<---8<---
Maybe I do only get something wrong but in my opinion this is rather the
opposite to what's explained in the howto...

Still another thing I found out is that ip_forward needs to be turned on
for this to work.

Any comments?
Open questions from my side are:
- Why did they change the old behaviour? Ok, a pro for this behaviour is
that it does figure out the right (tm) mac address on it's own so changing
the NIC doesn't result in strange behaviour. But this also worked before
with "arp -Ds 192.168.1.2 eth0 pub".
- How do I proxy ARP for _another_ MAC address? Imagine a veryvery stupid
device in the network that can't do ARP itself although it has a MAC
address and should receive IP packets. I know of at least one device that's
produced today that's that stupid. So there needs to be someone in the
network that answers ARPs as a proxy for this device with the MAC for the
device. I found no solution to configure this with Linux.

Anyhow this new behaviour seems to be not overly the "unixway" to do
things... (ok I'm a traditionalist and that's no reason not to change
things).

Enough whining.
Thanks for the patience
Stefan


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/

Re: [LARTC] Bug in the HOWTO: proxy-arp (?)

[Ard van Breemen]

On Fri, Feb 01, 2002 at 09:08:28AM +0100, SHuelbrock@Datasystems.de wrote:
> What I found out was different (and makes significantly more sense to me):
You are right about your findings. The /proc list is mostly a copy of
the routing howto or a document like that. So expect to see some bugs
there.
> If I enable proxy_arp on an interface, _this_ interface answers with
> proxy-ARPs for all the IP addresses that are in it's local network, that
> are routed to other interfaces.
> Example:
> ---8<---8<---8<-
> Maybe I do only get something wrong but in my opinion this is rather the
> opposite to what's explained in the howto...
> 
> Still another thing I found out is that ip_forward needs to be turned on
> for this to work.
Yep: proxy_arp is used for routing stuff, it will only answer to queries
which the box can and will route.
> Any comments?
> Open questions from my side are:
> - Why did they change the old behaviour? Ok, a pro for this behaviour is
> that it does figure out the right (tm) mac address on it's own so changing
> the NIC doesn't result in strange behaviour. But this also worked before
> with "arp -Ds 192.168.1.2 eth0 pub".
> - How do I proxy ARP for _another_ MAC address? Imagine a veryvery stupid
> device in the network that can't do ARP itself although it has a MAC
> address and should receive IP packets. I know of at least one device that's
> produced today that's that stupid. So there needs to be someone in the
> network that answers ARPs as a proxy for this device with the MAC for the
> device. I found no solution to configure this with Linux.
That is not called proxyarp. Proxyarp is using your own mac to respond
to things you can route, so that you do not have to install hundreds of
routes on your clients.
If you really need something that "answers" to arps, you should use a
seperate box with the same mac, and use arping to broadcast unsollicited
arp replys.
Ehhh, it means that you can only do that on hub.
A switch will probably get confused seeing the same mac on multiple ports.

-- 
<ard@telegraafnet.nl> Telegraaf Elektronische Media  http://wwwijzer.nl
http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html 
Let your government know you value your freedom. Sign the petition:
http://petition.eurolinux.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/