I (and others) have asked this a couple times here and on the netdev list, and
so far nobody has answered it (not even negatively).
If I manually set some proxy arp entries and then list the arp entries, the
manually set ones do not show up when using "ip neigh" but they do show up with
the "arp" command.
Is there any way to see them using "ip neigh"? If not, are there any plans to
enable this?
If not, I may have to look at adding support for this, and this is why I'm
wondering.
Thanks,
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
Hello!
> I (and others) have asked this a couple times here and on the netdev list, and
> so far nobody has answered it (not even negatively).
:-) And me answered to this hundred of times: "no way". :-)
Ability to add/delete them with "ip neigh" will be removed in the next
snapshot as well. The feature is obsolete.
Alexey
On Thu, 18 Oct 2001 [email protected] wrote:
> Hello!
>
> > I (and others) have asked this a couple times here and on the netdev list, and
> > so far nobody has answered it (not even negatively).
>
> :-) And me answered to this hundred of times: "no way". :-)
>
> Ability to add/delete them with "ip neigh" will be removed in the next
> snapshot as well. The feature is obsolete.
>
> Alexey
> -
I need the ability to delete an arp cache entry using `arp -d ...`.
Is this being removed? If so, I can't test embedded systems that
all come alive with a phony IEEE station address. Software normally
re-programs the SEEPROM with a real IEEE station address from a
data-base, over the network. The target is then restarted to
enable the new IEEE station address, and the server has the old
one deleted from its arp cache. Failure to delete the arp cache
entry results in a failure to connect, or a timeout of 5 minutes
for the arp cache entry to expire. Either one can't be acceptible
in automated testing.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
[email protected] wrote:
> > I (and others) have asked this a couple times here and on the netdev list, and
> > so far nobody has answered it (not even negatively).
>
> :-) And me answered to this hundred of times: "no way". :-)
Whee, an answer!
> Ability to add/delete them with "ip neigh" will be removed in the next
> snapshot as well. The feature is obsolete.
Oh? Let me present a scenario in which I use it and then you can tell me how
better to do it.
I'm using the ethertap device (in 2.2, tun/tap in 2.4 should be similar) to pass
stuff up to userspace. I have an ethernet link. I want the kernel to proxy arp
for the ip address assigned to the ethertap device with the mac address of the
NIC, without enabling proxy arping for any other addresses.
Currently I have been doing this by manually setting proxy arping on the NIC for
the IP address assigned to the ethertap device. If this feature is going to be
removed, then how should I be doing this?
Thanks,
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
Alexey,
On Thu, Oct 18, 2001 at 11:25:42PM +0400, A.N.Kuznetsov wrote:
>
> > I (and others) have asked this a couple times here and on the netdev list, and
> > so far nobody has answered it (not even negatively).
>
> :-) And me answered to this hundred of times: "no way". :-)
>
> Ability to add/delete them with "ip neigh" will be removed in the next
> snapshot as well. The feature is obsolete.
Well, in solutions I ship to customers I need to use some proxy-arp features.
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!), and people, especially those called
customers, do make mistakes.
So far, the solution has been to manually create proxy arp entries, that are
known to be safe.
Are you opposing the idea of proxy arp entries being created not by an
automatic discovery (arp on other interface)?
Or you just want to cripple `ip'? :-)
Andrey
Hello!
> removed, then how should I be doing this?
Not using "ip neigh", apparently. :-)
Alexey
Hello!
> 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
by the same mistakes which you can make forced to add useless element
to configuration.
I am sorry, but each additional item to configure increases
probability of mistake by... count yourselves. :-)
> Or you just want to cripple `ip'? :-)
Rather to cure it amputating dead flesh alien for "ip".
"ip neigh add proxy" was added as a demo of "right" interface
to this feature mostly to have a reason to say several words
about sense of proxy arp in manual. As soon as people do not read docs
anyway (or I wrote some unintellibible shit there) this function
loses its sense.
Alexey
On Thu, 18 Oct 2001, Christopher Friesen wrote:
> [email protected] wrote:
>
> > > I (and others) have asked this a couple times here and on the netdev list, and
> > > so far nobody has answered it (not even negatively).
> >
> > :-) And me answered to this hundred of times: "no way". :-)
>
> Whee, an answer!
>
> > Ability to add/delete them with "ip neigh" will be removed in the next
> > snapshot as well. The feature is obsolete.
>
> Oh? Let me present a scenario in which I use it and then you can tell me how
> better to do it.
>
> I'm using the ethertap device (in 2.2, tun/tap in 2.4 should be similar) to pass
> stuff up to userspace. I have an ethernet link. I want the kernel to proxy arp
> for the ip address assigned to the ethertap device with the mac address of the
> NIC, without enabling proxy arping for any other addresses.
Not needed. Any address assigned to an "internal" device (tun/tap, dummy,
etc) is pingable and arpable from any other address on the system
(assuming rp_filter is set correctly per interface). I use this "feature"
all the time and there was even a big argument over "loose vs. strict"
host replies back in the Spring of 2001 about this.
> Currently I have been doing this by manually setting proxy arping on the NIC for
> the IP address assigned to the ethertap device. If this feature is going to be
> removed, then how should I be doing this?
If an IP address is routed to on the external network then it will be
available. It does _not_ matter what interface that address is assigned
to. EX:
ip addr add 10.1.1.1/24 dev dummy0
ip link set dev dummy0 up
now ping 10.1.1.1 from another machine on eth0 that has an appropriate
route. I suspect what is really biting you is that your rp_filters are way
too restrictive on your machine.
> Thanks,
>
> Chris
>
> --
> Chris Friesen | MailStop: 043/33/F10
> Nortel Networks | work: (613) 765-0557
> 3500 Carling Avenue | fax: (613) 765-2986
> Nepean, ON K2H 8E9 Canada | email: [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250 x101
Email: [email protected]
WWW: http://www.paktronix.com
--------------------------------------------------
"Matthew G. Marsh" wrote:
> > Currently I have been doing this by manually setting proxy arping on the NIC for
> > the IP address assigned to the ethertap device. If this feature is going to be
> > removed, then how should I be doing this?
>
> If an IP address is routed to on the external network then it will be
> available. It does _not_ matter what interface that address is assigned
> to. EX:
>
> ip addr add 10.1.1.1/24 dev dummy0
> ip link set dev dummy0 up
>
> now ping 10.1.1.1 from another machine on eth0 that has an appropriate
> route. I suspect what is really biting you is that your rp_filters are way
> too restrictive on your machine.
Sorry, I guess I explained it wrong. Ethertap has an IP address assigned to the
device in the linux kernel. It is then configured with a point to point route
to another IP address on the other concepual end of the link (ie in userspace).
It is this other IP address that I am proxy arping for.
Thus,
[[email protected] mtc]$ /sbin/ip add
<stuff removed>
4: tap0: <BROADCAST,MULTICAST,NOARP,UP> mtu 1500 qdisc noqueue
link/ether fe:fd:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.40.14.73 peer 10.40.14.74/32 brd 10.40.14.255 scope global tap0
[[email protected] mtc]$ /sbin/ip ro
10.40.14.74 dev tap0 proto kernel scope link src 10.40.14.73
<stuff removed>
[[email protected] mtc]$ /sbin/arp
Address HWtype HWaddress Flags Mask Iface
<stuff removed
10.40.14.74 * * MP eth1
Thus, anyone arping for 10.40.14.74 (which is on top of a protocol stack in
userspace) will get the MAC address of eth1 as a response.
I cannot turn on proxy arping for the interface in general as I have eth0 and
eth1 on the same subnet and turning on proxy arping causes bad things to
happen. Thus I have a single manual proxy entry in the arp table.
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
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
Hello!
> What do you think will happen when a broadcast ARP request for 1.2.3.4
> arrives to both eth0 and eth2?
Nothing. Linuxes attached to the segment even will not notice this.
Just check and guess why. :-)
Windows will dump a funny popup saying that someone uses
their address, but however will continue to work. Probably
with short periods of service deaths if the router is not a router
really, but drops everything instead.
> How can it be done better?
I permanently remind that the situation when a part of protocol
is firewalled, and part of it has _no_ firewall hooks does not smell well.
Proxy arp rules are essentially some underdeveloped private ARP-only
firewall rules.
So, if you rely on core facilities, believe to them and do not break
them with some additional filters.
If you broke them f.e. announcing a pseudo-router with forwarding
enabled but dropping everything with a firewall rule, ARP must not
take care of this. That part of code which drops IP is responsible
for ARPing being in sync to its rules.
Alexey
Hi,
On Sun, Oct 21, 2001 at 09:21:32PM +0400, A.N.Kuznetsov wrote:
>
> > What do you think will happen when a broadcast ARP request for 1.2.3.4
> > arrives to both eth0 and eth2?
>
> Nothing. Linuxes attached to the segment even will not notice this.
> Just check and guess why. :-)
>
> Windows will dump a funny popup saying that someone uses
> their address, but however will continue to work. Probably
> with short periods of service deaths if the router is not a router
> really, but drops everything instead.
Are you saying that proxy_delay is sufficient protection from diverting other
hosts to this "proxy", and from starting to answer proxy's own requests sent
to eth2 and seen on eth0?
> > How can it be done better?
>
[snip]
> If you broke them f.e. announcing a pseudo-router with forwarding
> enabled but dropping everything with a firewall rule, ARP must not
> take care of this. That part of code which drops IP is responsible
I would prefer to put it this way: with this kind of firewall rule, the
question of working ARP needs to be taken care.
I've been doing it by setting up necessary ARP entries manually, the feature
you're going to remove from ip :-)
> for ARPing being in sync to its rules.
Andrey