From: Ard van Breemen <ard@telegraafnet.nl>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Bug in the HOWTO: proxy-arp (?)
Date: Fri, 01 Feb 2002 11:49:46 +0000 [thread overview]
Message-ID: <marc-lartc-101256419422524@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101255096021250@msgid-missing>
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/
prev parent reply other threads:[~2002-02-01 11:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-01 8:08 [LARTC] Bug in the HOWTO: proxy-arp (?) SHuelbrock
2002-02-01 11:49 ` Ard van Breemen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-101256419422524@msgid-missing \
--to=ard@telegraafnet.nl \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.