lkml.org 
[lkml]   [2001]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: how to see manually specified proxy arp entries using "ip neigh"
Hi,

On Fri, Oct 19, 2001 at 09:13:12PM +0400, A.N.Kuznetsov wrote:
>
> > I don't want to turn on proxy arp on an interface basis, because subtle
> > mistakes in network configuration with proxy arp turned on may have serious
> > consequences, including arp storm (sic!),
>
> Andrey, do not fuck me brains. :-) (translate this to English :-))
> No "serious" consequences exist. And not serious ones are surely covered

An offtopic note about consequences:
let's suppose proxy_arp is turned on on eth0 with the primary goal to proxy
addresses available via eth1. There is another interface eth2 were
1.2.3.0/24 routed to. Forwarding is turned on everywhere.
Someone decided to save on equipment (or simply made a mistake) and short-cut
eth0 and eth2 segments, unconscious forming "shared media".
What do you think will happen when a broadcast ARP request for 1.2.3.4
arrives to both eth0 and eth2?
Right, "is-at" reply with eth0 MAC address of this poor "proxy" on that
shared media.

> by the same mistakes which you can make forced to add useless element
> to configuration.

Well, what I want is to make the host an arp "proxy" on all interfaces for
all addresses reachable through devX. I do not want to mess with how
customer configures all other interfaces.
Right now all routes to devX are /32, for all of them proxy arp entries are
created by the same script, and all are happy.

How can it be done better?
New mechanism of fine-grained control over proxy arp? :-)

Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:08    [W:0.053 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site