Am Donnerstag, 15. März 2007 17:31 schrieb Dirk Nehring:
> On Thu, Mar 15, 2007 at 03:08:07PM +0100, Ralph Passgang wrote:
> > Hello,
> >
> > I noticed that our freewrt routers answer to arp request for ip adresses
> > on all available interfaces, even if the requested ip is not bound to the
> > interface where the request was recieved. This has nothing to do with
> > vlans, furthermore this happens even for completely diffrent physical
> > interfaces.
> >
> > in my case the IP 192.168.1.1 was configured on eth0.6, but even if I
> > pinged 192.168.1.1 from an external system, that was connected to eth0.0,
> > the box replied via arp on eth0.0, even if the ip isn't reachable via
> > eth0.0 at all.
> >
> > This means that it is not possible to use the same IPs in diffrent VLANs
> > or physical LANs at all without serious trouble.
> >
> > To disable this "feature" of arp-replying on all interfaces, it is
> > possible to set arp_filter = 1 via the proc interface per interface or
> > global for all interfaces.
> >
> > Even if the default linux behaviour is to repsond to arp request on all
> > interfaces (arp_filter = 0) it might be more clever to enable this filter
> > on all freewrt installations per default. It shouldn't break anything on
> > a already working setup, but should help to reduce strange network errors
> > that are hard to resolve, that might get caused without this filter.
> >
> > Waldemar told me, that he would like to enable this filter globally, so
> > if no one protests about it, we will enable it for branch/1.0 in 5 days
> > from now on.
>
> Hi Ralph,
>
> sounds logical to me. Perhaps you should make some tests with arp_ignore
> as well, see
> http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disa
>ble_ARP.

the arp_filter sysctrl setting solves the arp problem that might occour if the 
same media is connected to more than just one port. I used this setting on 
some linux routers in the past and never had a problem with arp_filter at 
all.

But your right, arp_ignore is an interessting feature too. It seems so that 
with arp_ignore an arp request is just answered if the destination of the 
request was the local interface address of the interface where the arp 
request has been recieved.

I think the arp_filter does this by checking if there is an direct route 
configured to the source of the arp request. So it's working a bit different 
to the arp_ignore feature. In theory both methods should work fine on normal 
interfaces, but I never checked the arp_ignore feature, so it would need more 
testing for more complex setups like bridging, but brings in the end just the 
same effect as using arp_filter.

Or is there a reason why we need arp_ignore? It seems to be more flexible, 
because it knows more modes than just enabling it.

--Ralph

> Dirk
> _______________________________________________
> freewrt-developers mailing list
> [email protected]
> https://www.freewrt.org/lists/listinfo/freewrt-developers
_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers

Reply via email to