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 <[email protected]>
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
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 :)