how to see manually specified proxy arp entries using "ip neigh" command?

how to see manually specified proxy arp entries using "ip neigh" command?

[Christopher Friesen]

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: cfriesen@nortelnetworks.com

Re: how to see manually specified proxy arp entries using "ip neigh"

[kuznet]

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

Re: how to see manually specified proxy arp entries using "ip neigh"

[Richard B. Johnson]

On Thu, 18 Oct 2001 kuznet@ms2.inr.ac.ru 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.

Re: how to see manually specified proxy arp entries using "ip neigh"

[Christopher Friesen]

kuznet@ms2.inr.ac.ru 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: cfriesen@nortelnetworks.com

Re: how to see manually specified proxy arp entries using "ip neigh"

[kuznet]

Hello!

> removed, then how should I be doing this?

Not using "ip neigh", apparently. :-)

Alexey

Re: how to see manually specified proxy arp entries using "ip neigh"

[Matthew G. Marsh]

On Thu, 18 Oct 2001, Christopher Friesen wrote:

> kuznet@ms2.inr.ac.ru 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: cfriesen@nortelnetworks.com
> -
> 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/
>

--------------------------------------------------
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250 x101
Email: mgm@paktronix.com
WWW:  http://www.paktronix.com
--------------------------------------------------

Re: how to see manually specified proxy arp entries using "ip neigh"

[Christopher Friesen]

"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, 

[mtc@10.40.14.70 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

[mtc@10.40.14.70 mtc]$ /sbin/ip ro
10.40.14.74 dev tap0  proto kernel  scope link  src 10.40.14.73
<stuff removed>

[mtc@10.40.14.70 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: cfriesen@nortelnetworks.com

Re: how to see manually specified proxy arp entries using "ip neigh"

[Andrey Savochkin]

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

Re: how to see manually specified proxy arp entries using "ip neigh"

[kuznet]

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

Re: how to see manually specified proxy arp entries using "ip neigh"

[Andrey Savochkin]

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

Re: how to see manually specified proxy arp entries using "ip neigh"

[kuznet]

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

Re: how to see manually specified proxy arp entries using "ip neigh"

[Andrey Savochkin]

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

Re: how to see manually specified proxy arp entries using "ip neigh"

[Julian Anastasov]

	Hello,

Andrey Savochkin wrote:

> 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? :-)

	I can tell you what Alexey and Andrey will answer on netdev :)
Make proxyarp a route flag. When arp_filter is not suitable for filtering
non-local input routes you can also solve the problem with the route's
noarp flag (known in netdev). The proxyarp flag for route can allow
the feature to work even on one device (indev==outdev) may be for NAT
purposes), probably running send_redirects=0 (send_redirects is another
candidate for a route flags). Of course, the target hosts should filter
these ARP probes with a simple rp_filter policy, only our box should
reply. We need only space for route flags and imagination :)

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: how to see manually specified proxy arp entries using "ip neigh"

[kuznet]

Hello!

> 	I can tell you what Alexey and Andrey will answer on netdev :)
> Make proxyarp a route flag.

It was Andrey's suggestion. I even do not know whether he still believes
that it is right. At least, his last note was that he does not believe
to routing tables more. :-)

What's about me, it does not cause an emetic reflex.
However I am not sure that it is really convenient solution.

Alexey

Re: how to see manually specified proxy arp entries using "ip neigh"

[Andrey Savochkin]

Hi,

On Sat, Oct 20, 2001 at 07:56:47PM +0000, Julian Anastasov wrote:
> 
> Andrey Savochkin wrote:
> 
> > 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? :-)
> 
> 	I can tell you what Alexey and Andrey will answer on netdev :)
> Make proxyarp a route flag. When arp_filter is not suitable for filtering

I may end up doing it, but I don't share Alexey's enthusiasm about
removing the options from ip and moving to some fine-grained control over
proxy arp.

I certainly prefer simpler solutions.
Solutions based on static configuration, without dynamic resolution
protocols, are simpler.
That is what I have now: I add entries, which I want to expose and to be used
for answering arp requests, one by one by `ip proxy neigh add'.
Simpler solutions are less error-prone and more easy to debug.

	Andrey

> non-local input routes you can also solve the problem with the route's
> noarp flag (known in netdev). The proxyarp flag for route can allow
> the feature to work even on one device (indev==outdev) may be for NAT
> purposes), probably running send_redirects=0 (send_redirects is another
> candidate for a route flags). Of course, the target hosts should filter
> these ARP probes with a simple rp_filter policy, only our box should
> reply. We need only space for route flags and imagination :)